Difference between Definition and Declaration ?


  •  Declaration of a variable is for informing to the compiler the following information: name of the variable, type of value it holds and the initial value if any it takes. i.e., declaration gives details about the properties of a variable. Whereas, Definition of a variable says where the variable gets stored. i.e., memory for the variable is allocated during the definition of the variable.
  • In C language definition and declaration for a variable takes place at the same time. i.e. there is no difference between declaration and definition. For example, consider the following declaration

int a;

  • Here, the information such as the variable name: a, and data type: int, which is sent to the compiler which will be stored in the data structure known as symbol table. Along with this, a memory of size 2 bytes(depending upon the type of compiler) will be allocated.
  • Suppose, if we want to only declare variables and not to define it i.e. we do not want to allocate memory, then the following declaration can be used

extern int a;

  • In this example, only the information about the variable is sent and no memory allocation is done. The above information tells the compiler that the variable a is declared now while memory for it will be defined later in the same file or in different file.
  • Declaration of a function provides the compiler the name of the function, the number and type of arguments it takes and its return type. For example, consider the following code,
int add(int, int);
  • Here, a function named add is declared with 2 arguments of type int and return type int. Memory will not be allocated at this stage.
  • Definition of the function is used for allocating memory for the function. For example consider the following function definition,

int add(int a, int b)

  {

    return (a+b);

  }

  • During this function definition, the memory for the function add will be allocated. A variable or a function can be declared any number of times but, it can be defined only once.

Content Source : GeeksforGeeks

Useful Links : Understanding “extern” keyword in C

How can I calculate the resolution of load cell?

 Let's assume that you have 5kg loadcell. 

Its output is specified for 1mV/V excitation meaning that if you have 5V excitation, you shall get 5mV output for a full-scale load of 5kgs.

Simply correlate this as 5000uV (microvolts) corresponding to 2000gm of load.

Next, your digital indicator has a full-scale input span of +/-20mV to give you a count of +/-20,000 meaning it will have a resolution of 1uV (microvolt).

        Resolution of Load Scale  = 5000 values for 5000 gm = 1gm ; 





What is Common-mode Voltage Gain ?

  • Common-mode voltage gain refers to the amplification given to signals that appear on both inputs relative to the common (typically ground).
  • You will recall from a previous discussion that a differential amplifier is designed to amplify the difference between the two voltages applied to its inputs.
  • Thus, if both inputs had +5 volts, for instance, with respect to ground, then the difference would be zero. Similarly, the output would be zero. This defines ideal behavior and is a characteristic of an ideal op amp. 
  • In a real op amp, common-mode voltages can receive some amplification and thus depart from the desired behavior. Since we are currently defining ideal characteristics you should remember that an ideal op amp has a common-mode voltage gain of zero.
  • This means the output is unaffected by voltages that are common to both inputs (i.e., no difference). Figure 1.13 further illustrates the measurement of common-mode voltage gains




What Is Static Code Analysis?

  • Static code analysis is a method of debugging by examining source code before a program is run. It’s done by analyzing a set of code against a set (or multiple sets) of coding rules. 
  • Static code analysis and static analysis are often used interchangeably, along with source code analysis. 
  • This type of analysis addresses weaknesses in source code that might lead to vulnerabilities. Of course, this may also be achieved through manual code reviews. But using automated tools is much more effective.
  • Static analysis is commonly used to comply with coding guidelines — such as MISRA. And it’s often used for complying with industry standards — such as ISO 26262.
  • Static code analysis is performed early in development, before software testing begins.

So, what’s the difference between static analysis and dynamic analysis?
  • Both types detect defects. The big difference is where they find defects in the development lifecycle.
  • Static analysis identifies defects before you run a program (e.g., between coding and unit testing).
  • Dynamic analysis identifies defects after you run a program (e.g., during unit testing). However, some coding errors might not surface during unit
    testing. So, there are defects that dynamic testing might miss that static code analysis can find.




WOW ! FRAMs as alternatives to flash memory in embedded designs

WOW ! FRAMs as alternatives to flash memory in embedded designs

 Ferroelectric random access memory (FRAM) is widely known as a non-volatile, stand-alone memory technology that has been a part of the semiconductor industry for more than a decade.

In recent years, integrated circuit manufacturers have been considering FRAM as a strong contender for embedded, non-volatile memory, as an alternative to flash technology. This article discusses key technology attributes of FRAM while exploring specific use cases that demonstrate FRAM’s advantages.

Today there are multiple memory technologies that have the potential to change the landscape of embedded processing. However, none so far have surfaced as a strong contender for replacing flash technology in microcontrollers (MCUs) until FRAM.

What is FRAM?

FRAM is non-volatile memory that has power, endurance and read/write speeds similar to commonly used static RAM (SRAM). Information stored in an FRAM cell corresponds to the state of polarization of a ferroelectric crystal that can hold its contents even after the power source is removed. This is what makes FRAM truly non-volatile. Also, since the energy required to polarize a crystal is relatively low when compared to programming a flash cell, FRAM writes are inherently lower power than flash.



Figure 1. FRAM allows for continuous ultra-low-power data logging and supports more than 150,000 years of continuous data logging (vs. less than 7 minutes with flash)
Here are a few typical applications that use microcontrollers with flash technology today. Let’s look at how leveraging FRAM-based MCUs, rather than flash-based MCUs, bring cost, energy and efficiency optimization.

Data logging:

A typical data logger application such as a temperature data logger can sample at rates anywhere between 1-1,000Hz. Now consider the write time of a single byte in flash memory is approximately 75µs.

In comparison, FRAM technology can be written to at a rate of about one byte every 125 nanoseconds. This is close to 1000 times faster than flash! Now consider the application reaches the end of a flash segment and needs to move to the next one, suddenly there is a 20 millisecond latency while waiting for a segment erase to complete.

The erase latency does not apply to FRAM as it is not required to pre-erase FRAM bytes between writes. A 20 millisecond latency every segment does not seem prohibitive until we calculate how significantly it impacts the maximum write speed. For the purpose of this discussion, consider that the block of memory being written to is 512 bytes in length. A flash memory block can be written 26 times per second including the time taken to complete an erase cycle every time 512 bytes are written. This brings us to a total speed of 13kBps [1].

In comparison, a 512 byte FRAM block can be written to at speeds greater than 8MBps [2]. Not every application requires such high write speeds, but consider if your target application was required to write only 1kB every second, the MCU with flash technology would spend 7% of the time staying active to perform the write. However an FRAM MCU would complete that task in 0.01% of the time allowing the MCU to remain in standby 99.9% of the time, providing significant power savings.

Energy harvesting
Many applications today are focused on using cleaner and greener energy, energy that is derived from natural sources such as sunlight, vibrations, heat or mechanical change. Such applications rely on small bursts of energy that provide power in short time intervals and the MCU is usually down to the wire in terms of how many lines of code can be executed before power is lost. Flash-based applications pay a premium in power, not only because of higher average power while accessing flash, but also because of higher peak power during flash write events.

This peak power is mainly due to the usage of a charge pump and can reach values of up to 7mA, making non-volatile writes virtually taboo in the energy harvesting world [1]. With FRAM there is no charge pump; therefore, no high current writes. The average power when writing to FRAM is the same as when reading from or executing out of FRAM (i.e. there is no penalty for non-volatile writes, making FRAM a truly flexible option for energy harvesting applications .)



Figure 2. All-in-one: FRAM microcontrollers deliver maximum read, write, power and memory benefits

RFID Tags:

Radio frequency identification (RFID) tags are making an appearance in many places: store shelves for displaying prices, name badges at conferences and on industrial automation floors to mark and identify objects on a conveyor belt. Some of these applications require memory writes up to 100 times a day.

Consider a byte of flash memory with a typical endurance of 10K write/erase cycles. To achieve 100K write/erase cycle endurance, the application will have to set aside 10 bytes of flash memory for every one byte of data, meeting the endurance requirements at the cost of high redundancy.

In comparison, an FRAM memory byte can endure 1015 write/erase cycles – 100 billion times more than a flash byte [3]. For applications that require high endurance in the order of millions of write/erase cycles, FRAM’s endurance specification is unmatched by other embedded non-volatile memory technologies available today.

Handheld metering:

Blood glucose metering is one example where loss of power is highly critical. In the case of power failure due to a depleted battery, the meter is required to save a time stamp, store the readings at the time of failure and perhaps even perform a few math functions before shutting down.

Consider a flash-based metering application with a battery that is depleted of charge, the power drop can be approximated to about 300mV in 0.01 seconds. In this time, up to 80K FRAM bytes can be written compared to about 8K bytes in flash. However this is without factoring in the high peak and average current requirements of a flash write, which will drain the battery rapidly, bringing down the backup capability significantly.

Another use case of system backup in power fail events is in energy metering where the energy reading needs to be preserved in non-volatile memory until power is restored. In such cases, the power usage during system backup is critical as backup battery sources are expected to last up to 10 years.

The list of applications where FRAM not only provides differentiation, but may also be the only viable option, is as diverse as is vast. To test drive an FRAM-based MCU check out the MSP430FR57xx series from Texas Instruments Incorporated (TI). Samples can be obtained for free and the MSP-EXP430FR5739 FRAM experimenter’s board is available online for $29.

FRAM can lower system cost, increase system efficiency and reduce complexity while being significantly lower power than flash. If your existing flash-based MCU application has energy, write speed, endurance or power fail backup constraints it may be time to make the switch to FRAM.

References:

What is Proof of concept POC ?

     


  • A Proof of Concept (POC) is a small exercise to test the design idea or assumption. The main purpose of developing a POC is to demonstrate the functionality and to verify a certain concept or theory that can be achieved in development. 
  • Prototyping is a valuable exercise that allows the innovator to visualize how the product will function, it is a working interactive model of the end product that gives an idea of the design, navigation and layout.  While a POC shows that a product or feature can be developed, a prototype shows How it will be developed.
  • Viability & Usability
  • While a POC is designed purely to verify the functionality of a single or a set of concepts to be unified into other systems.
  • The usability of it the real world is not even taken into consideration when creating a proof of concept because integration with technologies is not only time-consuming, but also might weaken the ability to determine if the principle concept is viable.This exercise is to identify the product features before jumping into development. 
  • A prototype is a first attempt at making a working model that might be real-world usable. Things go wrong in the process, but identifying these errors and stumbling blocks is principle purpose of building a prototype.
  • A prototype has almost all the functionalities of the end product, but will generally not be as efficient, artistically designed, or durable.
  • The POC method allows sharing internal knowledge among the team, explore emerging technologies, and provide an evidence of concept to the client for their product.
  • First, the developer assigned to the POC conducts research and begins to develop the feature with the goal of proving that it’s feasible. Once this is proven, the POC is extended to develop an integrated working model to provide a snippet of the final product. After that it’s either presented to the client and the product team to sell the idea for an upcoming project or it can be used internally within the development teams to share knowledge and stimulate innovation.
  • Prototyping is a quick and effective way of bringing a client’s ideas to life and serves a sample for the potential users to evaluate, test and share their feedback to make improvements. 
  • The final POC does not have to be bug-free but should ultimately show the functionality of the concept.
  • In conclusion, proof of concept says that it can be developed and validates the technical feasibility whereas and a prototype shows a potentially buggy, unrefined attempt at the final product. 

Credits : Entrepreneur