Embedded Programming Tips and Tricks for Beginners

Fast Division

On microcontrollers without a divide instruction very fast division can be done by bit shifting a variable right.
Each shift does a divide by two.

For example

 Y = Y >> 1;  (Will result in a divide by 2)

or

 X = X >> 4;  (Will result in a divide by 16)

By adding a multiplication you can achieve a limited number of other divisions.

For example

 Z = Z * 3;

 Z = Z >> 4;

This will result in a division of 5.33 (16/3 = 5.33)
Be sure to do the multiply first, otherwise bits will be lost.
Also check the variable size is large enough to store the multiplied value.

On modern microcontrollers signed data is stored in two's complement form, so this trick also works for signed variables.
A language like C will detect if the variable you're using is signed or not and use the correct shift instruction (bitwise for unsigned and arithmetic for signed).
However care should be taken when using signed variables.

Fast Multiplication

The same trick above can be used in reverse (shifting to the left) to multiple a number.

For example

 A = A << 1;  (Will result in a multiply by 2)

or

 B = B << 8;  (Will result in a multiply by 256)

To multiply with numbers other than power of two, a series of shifts and additions can be combined:

For example, A * 10 equals to A * 8 + A * 2, so;

 A = ( A << 3 ) + ( A << 1 );  (Will result in a multiply by 10)

Repeating Code Using Timer Overflow Interrupts

When writing embedded code you will quite often need to trigger code at a regular interval. (for example flashing an led)
Over your entire project there maybe many different code segments you wish to execute at different rates. To do this it can be useful to dedicate one of the microcontrollers hardware timers to perform all these timing tasks.

Since it's bad practice to put lots of code inside an interrupt handler the best approach is to just set flags and then test these flags inside your main program loop.

Such a system might look like this

AVR

#define complete 0
#define restart 1

volatile uint16_t clk1000ms=restart ; // initializing them to restart(1) insures there is an initial delay cycle when
volatile uint16_t clk100ms=restart ;  // the code first starts, otherwise they would all happen at
volatile uint8_t clk10ms=restart ;    // once during mcu poweron, which may not be desirable.

ISR (TIMER0_OVF_vect)
{		
	if (clk1000ms != complete) 
	{
		clk1000ms++;
		if (clk1000ms >= 10001) clk1000ms=complete ;
	}
	if (clk100ms != complete ) 
	{
		clk100ms++;
		if (clk100ms >= 1001) clk100ms=complete ;
	}
	if (clk10ms != complete ) 
	{
		clk10ms++;
		if (clk10ms >= 101) clk10ms=complete ;
	}
	// Timer clock is 1mhz, timer is 8bit.
	// Now we set the timer register to 156 so it takes 100 timer clocks to overflow.
 	// This will mean the interrupt code executes at 1mhz/100 = 10000Hz		
	TCNT0 = 156;	
}

void main(void)
{
	
	if (clk1000ms==complete )
	{	
		// put code here to run every second

		clk1000ms = restart ;
	}	
	if (clk100ms==complete )
	{
		// put code here to run 10 times a second

		clk100ms = restart ;
	}
	if (clk10ms==complete )
	{
		// put code here to run 100 times a second

		clk10ms = restart ;
	}
	
}

Global Variables

You may have been told in computer programming courses that 'global variables' are very bad and to never use them. The reason for this is that in computer programming applications are quite complex and lots of global variables make things very hard to follow. This rule, while still true for embedded programming, is much more relaxed, especially with 8/16bit micros.

In fact it can work against you and make your embedded code very unwieldy if you make every variable local and pass them around on almost every function in a small project. Doing this also increases the number of cycles needed to execute your functions as the variables needs to be loaded/unloaded every function call. On a low MHz micro with lots of small functions this can slow your code down.

Therefor, in small-scale embedded programming, it's perfectly acceptable to use global variables when the information is something most of your program needs access to. It's a balancing act to decide if a variable is something that should be passed to a function or available to every function as a global variable. Usually however, it is quite obvious.

When using global variables it can be a good idea to combine them were possible into structures 'struct' to reflect what they are for. An example maybe a struct for all your input/output data. The I/O may come from various sources like the ADC, SPI devices, mcu IO pins etc. But its a good idea to keep it all together.

For example

struct iodata {    
	volatile uint8_t p_dataready;  //pin change interrupt
	volatile uint8_t p_alarm;      //pin change interrupt
	volatile uint8_t p_pulsecount; //pin change interrupt

	uint8_t s_tempsensor; //spi
	uint8_t s_dac;        //spi
	
	uint8_t a_mainbusvolts; //adc
	uint8_t a_fanspeed;     //adc
	uint8_t a_currentz;     //adc
	uint8_t a_pot;          //adc 	
} global_io;

This global struct can then be used throughout your entire program to store and retrieve i/o data.

In general, the more complex your embedded project is (and faster your clock is) the more you should limit your global variables. But do use them when you think they make things easier and neater.

Common mistakes

The Equals Sign

One of the most common mistakes new (and old) programmers make in C is the following.

if (MyVariable=5)
{
     // run some code
};

The mistake here is the single equals sign. A single equals sign is used for doing an 'assignment' eg MyVariable=5
In the example above we want to do a 'comparison/relation' to produce a true/false answer for the if statement. The operator for this is double equals.

So the corrected code is

if (MyVariable==5)
{
     // run some code
};

Using the EEMEM attribute in GCC

If you are using the EEMEM attribute to put your variables and or arrays into the EEPROM memory instead of FLASH you need to keep in mind that you are giving the compiler the right to choose the exact memory location in EEPROM where they are stored.

This means that, if in the future the compiler decides to store them in a different order or a new compiler version stores them in a different way, you will run into major problems. EEPROM data will appear in the wrong location and cause all sorts of confusion.

This is especially a problem if you plan to distribute your application and allow users to flash new firmware. You can easily end up with multiple firmware versions storing data in slightly different EEPROM locations. This can sometimes go unnoticed until it's too late and data is corrupted.

You can mitigate the issue a little if you put all of your EEMEM variables into a struct. This way you at least know they will be in the correct order. And one would assume the struct will always start from the same eeprom address. However this is still taking a big risk.

The only solid solution is to write your own EEPROM read/write/update functions that work based on some fixed address.