2.7. What you need to know before programming with microcontrollers


A compiler is a program that translates a source program written in a high-level programming language (such as C) into machine code for a specific computer architecture (in our case, for the microcontroller). The generated machine code can be then uploaded and executed on the microcontroller.

We are using the AVR GCC cross-platform compiler. Cross-platform refers to the fact that you compile the sources on a machine (in this case, your PC) and the machine code generated will be specific for an other machine (the microcontroller).

The compiler takes as input source code. It first checks it for syntactic errors - and aborts the compilation procedure if it finds any. Secondly, it may perform optimizations on your code. However, you can control the level of optimization by choosing between different performance levels, optimizing for application size or no optimizations.After this step is done, the compiler translates the optimized (or un-optimized) code into machine code.

The compiler can generate different types of files, according to what you need. On a PC, the compiler generates an executable file with the extension ”.exe”. However, microcontrollers need a different, dedicated format. For our microcontroller we will be using HEX (extension ”.hex”) files. Other possible formats generated by the compiler are: .elf, .map, .eeprom. You can read more about HEX formats at Resource 1.

In Section 2.5. you have learned how to build your project. This just tells the Atmel Studio to go ahead and gather all the sources, header files and resources in your project and compile them (according to the project settings) in order to generate the HEX file.

Figure 1. Compiling process.

Figure 1 details the compiling process.

  • AVR Libc represents the AVR library provided by Atmel. It defines all the register names (together with their bits), as well as other useful functions.
  • GCC represents the GNU Compiler Collection. Together with the GNU binutils it generates the HEX files.
  • In this class we will be using Atmel Studio to upload the .hex file on the microcontroller. However, there are other software programs dedicated for this task (e.g. AVRDUDE).
  • AVR-GDB, AVaRICE and SimulAVR can help simulate / debug the behaviour of your microcontroller application on a PC.

Testing and debugging with simulators

In Section 2.5. you have learned about the debugging process in Atmel Studio 6. This section will present to you other forms of testing and debugging your microcontroller application. This can be done either by using a software simulator, or by using a JTAG connector for on chip debugging.

Simulator versus emulator

An emulator only mimics the observable behaviour of a target, whereas a simulator also models the internal state of the target. In this respect, emulators are faster, but they might also be prone to behaviours / errors that the original target would not manifest.

What is a debugger?

The purpose of a debugger is to allow you to see what is going on “inside” another program while it executes - or what another program was doing at the moment it crashed[1].

Proteus ISIS

The Proteus Design Suite allows you to simulate both high- and low-level microcontroller code in the context of a mixed-mode SPICE circuit simulation. This means that you can use the ISIS schematic tool to design your hardware and you don't need to have a working physical prototype in order to test your code.

Proteus ISIS can help debug both your hardware design and your software. It provides source-level debugging with diagnostic and trace messaging. In Figure 2 you can see a screenshot of a schematic design created in ISIS.

Figure 2. Screenshot of the ISIS schematic editor showing a fully functional virtual representation of the Microchip™ PICDEM2+ Evaluation Board, containing PIC18F452,Alpha LCD, TC74 temp sensor, 24LC256 I2C EEPROM, RS232 terminal and various buttons, pots, LED's etc.[2]

There is, however, a disadvantage too: it is not free. It is a useful tool indeed, especially in a company where the software development and testing can begin as soon as the schematic is ready. In our case, though, we can use one of the next utilities to debug our code, if-need-be. If you want to learn more about Proteus ISIS you can watch the video tutorial in Resource 2, or visit their webpage (Resource 3).


AVR-GDB is the GDB for the Atmel AVR line of microcontrollers. GDB can do four main kinds of things (plus other things in support of these) to help you catch bugs in the act[1]:

  • Start your program, specifying anything that might affect its behavior.
  • Make your program stop on specified conditions.
  • Examine what has happened, when your program has stopped.
  • Change things in your program, so you can experiment with correcting the effects of one bug and go on to learn about another.

GDB is widely used and is supported by a large community of programmers. It is also free to distribute.

Since AVR GDB is a command-line tool, it is mostly recommended for more experienced users. However, there are many other simulators and debuggers that use AVR GDB, thus simplifying the debugging process.


AVaRICE provides an interface from avr-gdb to Atmel's JTAGICE box. It runs on a POSIX machine and connects to gdb via a TCP socket and communicates via gdb's “serial debug protocol”. This protocol allows gdb to send commands like “set/remove breakpoint” and “read/write memory”.

AVaRICE translates these commands into the Atmel protocol used to control the AVR JTAG ICE. Connection to the AVR JTAG ICE is via a serial port on the POSIX machine.

Because the GDB ←–> AVaRICE connection is via a TCP socket, the two programs do not need to run on the same machine[3]. You are required to know how to use AVR GDB in order to perform debugging actions.

AVaRICE is also a free product. However, it does require that you have an AVR JTAG ICE device. It currently only supports a limited number of microcontrollers, you can find the complete list in [3].


The SimulAVR program is a simulator for the Atmel AVR family of microcontrollers. (ATtiny and ATmega) SimulAVR can be used either standalone or as a remote target for avr-gdb. When used in gdbserver mode, the simulator is used as a back-end so that avr-gdb can be used as a source level debugger for AVR programs. The core of SimulAVR is functionally a library. This library is linked together with a command-line interface to create a command-line program[4].

Some important features are:

  • Execution timing should be nearly accurate, different access times for internal RAM / external RAM / EEPROM and other hardware components are simulated.
  • Tracing the execution of the program, these traces support all debugging information directly from the ELF-file.
  • The traces run step by step for each device so you see all actions in the multiple devices in time-correct order.
  • Run multiple AVR devices in one simulation. (only with interpreter interfaces or special application linked against simulavr library). Multiple cores can run where each has a different clock frequency.

Programming a microcontroller

How to program

In Section 2.5 you have learned how to use an In-System Programmer (ISP) to upload your program on a microcontroller. However, there are more ways to do this. Among the most popular choises are:

  • Programming through the serial interface
  • Programming through the USB port through a bootloader

Programming with an ISP requires that you have the ISP device and that your microcontroller has a SPI interface. You also have to reserve space on your board for a 6-pin connector. Moreover, programming through an auxiliary device is not as straight-forward as programming without it. For more information on in-system programming, consult Resource 4.

Programming through the serial interface can be done with little additional hardware that can be incorporated directly in the PC-to-board cable. For programming, you have to use a serial device programmer on the PC, such as PonyProg. Unfortunately, modern computers and laptops don't have a serial interface any more so this method of programming is rapidly becoming obsolete. Compatibility with old boards can be ensured by USB-to-Serial cables; you also need to install the appropriate drivers.

A bootloader is a program loaded at the end of the microcontroller's program memory. It is uploaded once (through an ISP or serial interface) and after this it allows you to upload your programs through a USB interface. You can only program the microcontroller for a brief period of time (a few seconds usually) after it is powered on (or reset); after this period passes, your previously loaded program will start executing. The main disadvantage is the space that the bootloader occupies in the microcontroller memory. If you try to upload a program that doesn't fit in the remaining space, it will overwrite part of the bootloader and the bootloader will have to be re-written. This is one case where size optimization at compile-time is extremely useful.

Optional: Fuse and locking bits

When programming an AVR device you can, in addition to programming the Flash and EEPROM memories, program a number of Fuses and Lock bits to enable/disable features and/or different memory protection modes. There are 3 bytes of permanent (by permanent I mean that they stick around after power goes out, but that you can change them as many times as you'd like) storage called the fuses. The fuses determine how the chip will act, whether it has a bootloader, what speed and voltage it likes to run at etc. Note that despite being called 'fuses' they are re-settable and don't have anything to do with protection from overpowering (like the fuses in a home)[5].

The fuses are documented in the datasheets, but the best way to examine the fuses is to look at a fuse calculator such as the AVR fuse calculator from the PalmAVR project - Resource 5.

Although it is important to know about fuse bits in general, for our 3PI applications this is not relevant. You can read more about fuse and locking bits in the article at Resource 6.



roboticsisfun/chapter2/ch2_7_programming_a_microcontroller.txt · Last modified: 2012/10/28 20:02 by liana.marinescu