23-07-2012, 11:49 AM
Embedded Systems/C Programming
Embedded Systems.pdf (Size: 87.56 KB / Downloads: 111)
The C programming language is perhaps the most popular programming language for programming embedded
systems. (Earlier Embedded Systems/Embedded Systems Introduction#Which Programming Languages Will This
Book Use? we mentioned other popular programming languages).
Most C programmers are spoiled because they program in environments where not only is there a standard library
implementation, but there are frequently a number of other libraries available for use. The cold fact is, that in
embedded systems, there rarely are many of the libraries that programmers have grown used to, but occasionally an
embedded system might not have a complete standard library, if there is a standard library at all. Few embedded
systems have capability for dynamic linking, so if standard library functions are to be available at all, they often need
to be directly linked into the executable. Oftentimes, because of space concerns, it is not possible to link in an entire
library file, and programmers are often forced to "brew their own" standard c library implementations if they want to
use them at all. While some libraries are bulky and not well suited for use on microcontrollers, many development
systems still include the standard libraries which are the most common for C programmers.
Special Features
The C language is standardized, and there are a certain number of operators available that everybody knows and
loves. However, many microprocessors have capabilities that are either beyond what C can do, or are faster than the
way C does it. For instance, the 8051 and PIC microcontrollers both have assembly instructions for setting and
checking individual bits in a byte. C can affect bits individually using clunky structures known as "bit fields", but bit
field implementations are rarely as fast as the bit-at-a-time operations on some microprocessors.
storing data in ROM on a Princeton architecture microcontrollers
Princeton architecture microcontrollers use exactly the same instructions to access RAM as program Flash.
C compilers for such architectures typically put all data declared as "const" into program Flash. Functions neither
know nor care whether they are dealing with data from RAM or program Flash; the same "read" instructions work
correctly whether the function is given a pointer to RAM or a pointer to program Flash.
storing data in ROM on a Harvard architecture microcontrollers
Unfortunately, Harvard architecture microcontrollers use completely different instructions to access RAM than
program Flash.(Often they also have yet another set of instructions to access EEPROM, and another to access
external memory chips). This makes it difficult to write a subroutine ( such as puts() ) that can be called from one
part of the program to print out a constant string (such as "November") from ROM, and called from another part of
the program to print out a variable string in RAM.
Unfortunately, different C compilers (even for the same chip) require different, incompatible techniques for a C
programmer to tell a C compiler to put data in ROM. There are at least 3 ways for a C programmer to tell a C
compiler to put data in ROM.
(1) Some people claim that using the "const" modifier to indicate that some data is intended to be stored in ROM is
an abuse of notation. [3] Such people typically propose using some non-standard attribute or storage specifier, such as
"PROGMEM" or "rom"[4], on variable definitions and function parameters, to indicate a "typed pointer" of type
"value resides in program Flash, not RAM". Unfortunately, different compilers have different, incompatible ways of
specifying that data may be placed in ROM. Typically such people use function libraries that 2 copies of functions
that deal with strings (etc.); one copy is used for strings in RAM, the other copy is used for strings in ROM. This
technique uses the minimum amount of RAM, but it usually requires more ROM than other techniques.
C compilers for embedded systems
Perhaps the biggest difference between C compilers for embedded systems and C compilers for desktop computers is
the distinction between the "platform" and the "target". The "platform" is where the C compiler runs -- perhaps a
laptop running Linux or a desktop running Windows. The "target" is where the executable code generated by the C
compiler will run -- the CPU in the embedded system, often without any underlying operating system.
The GCC compiler is[citation needed] the most popular C compiler for embedded systems. GCC was originally
developed for 32-bit Princeton architecture CPUs. So it was relatively easily ported to target ARM core
microcontrollers such as XScale and Atmel AT91RM9200; Atmel AVR32 AP7 family; MIPS core microcontrollers
such as the Microchip PIC32; and Freescale 68k/ColdFire processors.
The people who write compilers have also (with more difficulty) ported GCC to target the Texas Instruments
MSP430 16-bit MCUs; the Microchip PIC24 and dsPIC 16-bit Microcontrollers; the 8-bit Atmel AVR
microcontrollers; the 8-bit Freescale 68HC11 microcontrollers.