Editing 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.<br>
Each shift does a divide by two.<br>

For example<br>
  ''Y = Y >> 1;  (Will result in a divide by 2)<br>''
or<br>
  ''X = X >> 4;  (Will result in a divide by 16)<br>''

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

For example<br>
  ''Z = Z * 3;<br>''
  ''Z = Z >> 4;<br>''

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

On modern microcontrollers signed data is stored in two's complement form, so this trick also works for signed variables.<br>
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).<br>
However care should be taken when using signed variables.<br>

Rounding: With the method described above the result is effectively floored because the bits shifted out to the right are lost. These bits are the fraction of the result, and if the fraction is higher than 0.5, then the e MSB of the fraction equals 1.<br>
<br>
Using the example above, but with Z=30 to illustrate the flooring:<br>
<br>
On the calculator we see that 30*3/16 = 5.625 which is closer to 6<br>
In the binary world we see that (30*3)>>4 = 5 , why ? <br>
30*3 = 90 = 0101 1010 binary, where 1010 represents 10/16 > 0,5 and we get the rounding error.<br>
<br>
fast divison with rounding: example Z / (16/3)
<br>
  ''Z = Z * 3;''<br>
  ''Z = Z >> 4 + (Z >> 3) & 0x01;''<br>
<br>
(the & 0x01 masks the bit we want to isolate and add to Z)<br>
<br>
<br>
<br>

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

For example<br>
  ''A = A << 1;  (Will result in a multiply by 2)<br>''
or<br>
  ''B = B << 8;  (Will result in a multiply by 256)<br>''

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

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

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

In some cases, standard multiplication may be faster. For example, ATMega MCUs have a proper multiplication instruction, but only a shift-by-one instruction; therefore, shifting by 5 steps results in more and slower code than using the multiplication. Shifting by 8 is quick as it is moving a full byte.

=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)<br> 
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
(Note: This example does not cover enabling and configuring the hardware timer itself)

===AVR===
<pre>

#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 ;
	}
	
}
</pre>

=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.
 
Therefore, 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
<pre>
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;
</pre>

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 (typos) new (and old) programmers can make in C is the following.
<pre>
if (MyVariable=5)
{
     // run some code
}
</pre>
The mistake here is the single equals sign. A single equals sign is used for doing an 'assignment', i.e. setting the value of MyVariable to 5.

In the example above we intended to do a 'comparison/relation' to produce a true/false answer for the if statement. It is worth noting that an assignment always returns the value that was assigned, so in the above example, the code within the if block would always execute as long as the value being assigned can be considered "comparable to true" (usually any non-zero value).

The operator for comparison is double equals, so the correct code is:
<pre>
if (MyVariable==5)
{
     // run some code
}
</pre>

=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 its too late and data is corrupt all over the place.

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 a little risky.

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