Microcontrollers vs FPGAs

…or the future of microcontrollers 🙂 woow that sounds geek!

I have to confess that I had no intention to switch the discussion from smartphones (or Java lectures) towards such topic unless I had not received the newsletter from embedded.com: Tech Focus: FPGAs vs. MCUs/MPUs: It’s no longer either/or .

Well… I would think this is an absolutely valid topic, which is the next embedded design trend, how will it look like, the future of embedded systems, will we still largely use microcontrollers, or will those be gradually replaced by FPGAs?

Is it good to use dynamic memory allocation in embedded programming?

Before starting I have to mention few references which were really usefull resources in my “Embedded tips and tricks” – related posts. One of them is Dan Saks’ articles and columns on Embedded.com and another one is Netrino web site and Michael Barrs’ articles.

I thought of writing this post in order to explain possible benefits but also the drawbacks that are induced by dynamic memory allocation… in embedded programming. I excluded any faulty use of dynamic allocation such as memory leaks or dangling pointers, so my assumption is that data is correctly allocated and de-allocated.

First of all let me just integrate dynamic allocation in the general storage types classification, there are three types (at least in C):

Static storage – variables which exist during the whole program execution time; those are global variables and those variables explicitly declared as static

Automatic storage– variables which are allocated upon entrance into a block (something delimited by curly brackets {}) and de-allocated after existing that block (this is the case of local variables)

Dynamic storage– this one falls entirely on users’ responsibility; he manually creates the variables (via malloc, calloc or, in C++ new operator) and he also destroys them (via free or delete)

Dynamic allocation has the advantage of being completely in control of the programmer. Variables storage and lifetime is manipulated solely by the user and it is not necessary to overload the compiler with such task (actually dynamic allocation is done at run-time, so has nothing to do with compiler), but on the other hand he has to be aware that this “freedom” can provoke serious errors.

In embedded programming dynamic memory allocation should not be avoided at all, this is not a good practice, but instead it has to be used carefully.

C tips for embedded programming

Some very useful resource in writing this post were: an article on  Embedded.com , Nigel Jones’ “C Test” and C coding tips published under cprogramming.com website.

The driving idea was to share my knowledge with other “embedded programmers” but also to debate about several aspects which inherently occur when writing C code for microcontrollers. Those are some general guidelines which I usually try to follow in order to write more efficient code.

It is not very easy to find a starting point in this discussion, but I will “dump” things which I have into my mind along with those found on various web resources. I will struggle to cover embedded-specific topics as interrupts, I/O, timers, variable length, compiler particularities, C standard specifics. Unfortunately not all of them will be deeply explained in this post so I will come back later.

When you writing code for a certain microcontroller/microprocessor type first thing to take into consideration, in my opinion, is that the data type size should be appropriate for CPU used. For an 8-bit processor is more effective to work with 8-bit variables, same for 32-bit CPU and so on.

Another “rule of thumb” in programming (this time also in desktop programming) is that each line of code must have a corresponding line of comment or in any case, there should not be a big discrepancy in between “real code quantity” and its associated number of comment lines.

Be careful of some “delays” that you want to introduce in your embedded C code. Many compilers consider the “empty delay loops” as not useful code, so they are removed causing “unexpected behavior”. For example:


void delay(unsigned int);
//highly time dependent code
sent_data (0xAA);
delay(100);
sent_data (0x55);
delay(100);
void delay(unsigned int time)
{
for (i=0;i<10;i++); //considered to be not useful code
}


delay function can be transformed in

void (unsigned int time)
{
}


It is better and safer to use nop() instructions in case if corresponding microprocessors’ instruction set supports them.

Volatile meaning is…