Programming a Microcontroller

1Purpose and structure of the course7 min

Programming a microcontroller means, in the most concrete sense, changing the state of some cells of non-volatile memory inside the chip, so that, on the next power-up, the central unit finds there a sequence of instructions it can execute. Nothing more. The microcontroller does not "understand" C, does not know what a function is and has no notion of a file - it has a program counter pointing to an address in Flash, reads a 16-bit word from there, interprets it as an instruction, executes it and moves on.

The second difference concerns where the work happens. The program is written, compiled and transformed on a host computer, of a different architecture than the target. A compiler that runs on x86 and produces code for an 8-bit AVR is called a cross-compiler, and the set of tools that go with it forms a toolchain - for AVR, it is called avr-gcc.

• List, in order, the five transformations the source code goes through on its way to bits in Flash, with the tool and resulting file for each
• Explain why an .elf file cannot be sent directly to the programmer
• Read a line of an Intel HEX file and check its checksum
• Compare programming via bootloader with ISP, in terms of the hardware needed and the space consumed
• Estimate the Flash and SRAM usage of a program and recognize the symptoms of each running out
• Identify the real cause of a program that "runs twice as slowly" or resets on its own

2The stages of programming: from source to ELF12 min

An IDE displays a single command, "Compile" or "Upload". Behind it, five successive transformations run in order, each producing an intermediate file with a precise role. IDEs delete the intermediate files at the end - which does not mean they never existed, just that the student never gets to see them.

1. Preprocessing

The first tool to touch the source code is not the compiler, but the preprocessor - it does not know C, for it the file is just text. It executes the directives starting with a hash sign (#include, #define, #ifdef) and hands the compiler a text from which these have disappeared. This explains why a fifteen-line program grows, after preprocessing, to tens of thousands of lines: the header <avr/io.h> pulls in the device-specific file, with the definitions of all registers and their bits. When we write PORTB, the preprocessor replaces it with the physical address of the register; the compiler never sees the name, only access to an address.

2. Actual compilation

The compiler receives the preprocessed text and produces assembly for the target architecture. Here the high-level structure is permanently lost: loops, functions, data types become AVR instructions, and variables are placed in the 32 general registers or, if they do not fit, in SRAM.

3. Assembling

The assembler translates the mnemonics one-to-one into binary machine code - no optimization decisions, just a fixed correspondence. The result, the .o file, is not executable code: it is organized into sections (.text for instructions, .data for non-zero-initialized global variables, .bss for zero-initialized ones, .rodata for constants) and is incomplete - if it calls a function from another file, the assembler does not know its address and leaves a gap, noted in the relocation table.

4. Linking

The linker receives all the object files and libraries, with three tasks: resolving symbols (finds the definition of every name undefined locally - hence "undefined reference" and "multiple definition" errors), allocating addresses (concatenates sections of the same kind and places them in the address space, according to a linker script - for the ATmega328P, .text starts at address 0 in Flash, .data/.bss in SRAM) and relocation (fills in the gaps left by the assembler, now that the addresses are known).

The result is an ELF executable file - it contains the fully relocated code, plus debugging information (symbol names, address-to-line correspondence, variable types), essential for any debugger and the reason the .elf file must not be discarded.

3From ELF to Flash memory9 min

A chip programmer does not need symbols or debugging information - it needs an answer to a single question: what byte goes at what address. From the ELF, only the sections that actually end up in Flash are extracted (.text and the initial image of .data) and transcribed into the Intel HEX format, with the utility avr-objcopy.

The transfer into memory

The last stage is the only one that involves hardware. A program on the host computer (avrdude - AVR Downloader Uploader) reads the .hex file, splits it into pages and sends them, through a serial protocol, to the write logic in the microcontroller's Flash.

After writing, verification is recommended: the programmer reads back the content and compares it with the source. A mismatch indicates insufficient power, too high a programming frequency, or worn-out memory.

4The Intel HEX file format10 min

The .hex file is the last object a human can inspect before the program disappears into the chip - and the only one in the chain simple enough to be read with the naked eye. The format, defined in the 1970s for transfer over slow and unreliable serial links, is pure ASCII text, each line stands on its own and carries its own address, and each line has a checksum.

5The structure of Flash memory and the bootloader10 min

Who writes to Flash? The memory is internal to the chip, and its pins do not expose the memory bus directly. There are two answers: either an external device takes control of the chip through a dedicated serial interface, or the microcontroller programs itself, running a program already present in it, using the spm (store program memory) instruction, which writes a page into Flash. The program that does this is called a bootloader.

The two sections of Flash memory

For safety, the Flash of the ATmega328P is split into an application section (the lower part, from address zero, the user's program) and a boot section (the upper part, the bootloader). The distinction is enforced by hardware: the spm instruction has effect only when the PC is inside the boot section - an ordinary application program cannot rewrite Flash either by mistake or on purpose.

On reset, the bootloader initializes the communication interface and waits a few hundred milliseconds for a synchronization message. If it arrives, it receives code pages, writes them with spm and jumps to address zero. If it does not arrive, it jumps straight to the application - the explanation for the one-second delay observed when powering up an Arduino board.

6Programming Arduino boards8 min

On an Arduino Uno board, besides the ATmega328P, a second chip handles the USB-to-serial conversion - the host computer sees it as a virtual serial port, whose transmit/receive lines are wired to the RXD/TXD pins of the main microcontroller. This chip only carries bytes, it does not program anything.

Automatic reset

The bootloader only listens right after a reset. On old boards, the user had to press reset at exactly the right moment. The current solution: the DTR line of the virtual serial port is wired to the reset pin through a small capacitor. When the program on the computer opens the port, it toggles DTR, and the capacitor passes only the edge, generating a short reset pulse - the board resets itself at exactly the right moment.

avrdude -C avrdude.conf -p atmega328p -c arduino \
        -P /dev/ttyUSB0 -b 115200 -D \
        -U flash:w:prog.hex:i

The dialog protocol is called STK500: the host requests synchronization, asks for the chip's signature, sends the address and content of each page, requests the write, moves to the next page. The Optiboot bootloader implements only a subset, enough for writing to Flash - it cannot write the fuses or read EEPROM, precisely to stay within the 512 bytes allocated to it.

7Programming via ISP9 min

In-system programming (ISP, or ICSP) is the basic method, which does not depend on any code already present in the microcontroller. It uses the chip's synchronous serial SPI interface, in a special mode activated by holding the reset pin active - as long as the chip is held in reset, the central unit executes nothing, and the programming logic takes over control through MOSI/MISO/SCK.

The dialog: enable programming, read the chip's signature (three bytes: manufacturer and model), erase, load the pages, verify.

8Programming languages and the cost of libraries11 min

A microcontroller can, in principle, be programmed in any language with a compiler for that architecture. In practice, the choice is constrained by resources: with 32 KB of Flash and 2 KB of SRAM, there is no room for a virtual machine, a garbage collector or a rich standard library.

Assembly, C, C++

Assembly gives the most compact and fastest code possible, with perfectly known resource use - essential in loops with a strict deadline or interrupts with guaranteed timing. It becomes, however, hard to read and unportable beyond a few dozen lines; today it is used sparingly, in short, critical routines.

C holds the dominant position, for solid reasons: the types match the processor's natural units, bitwise operators allow direct manipulation of registers, pointers allow access to physical addresses. A good compiler generates, for carefully written code, a result comparable to hand-written assembly. The price: a steep learning curve and no safety net - C allows, without complaint, writing past the end of an array or an uninitialized pointer.

C++ adds classes and encapsulation - the Arduino libraries (Serial, Servo) benefit visibly. The cost: dynamic allocation, exception handling and runtime type identification consume memory that 2 KB of SRAM cannot sustain, which is why embedded practice uses a disciplined subset, without these mechanisms.

What the Arduino libraries hide

The Arduino environment hides the registers behind functions with readable names - a good pedagogical choice at first, costly later.

/* variant with Arduino functions */
void setup() { pinMode(13, OUTPUT); }
void loop() { digitalWrite(13, HIGH); digitalWrite(13, LOW); }

/* the same operation, directly on registers */
#include <avr/io.h>
int main(void) {
    DDRB |= (1 << PB5);
    while (1) {
        PORTB |= (1 << PB5);
        PORTB &= ~(1 << PB5);
    }
}

The difference in behavior is nil - on the Uno board, pin 13 is exactly PB5. The difference in cost is large: PORTB |= (1<<PB5) generates the sbi instruction, two cycles. digitalWrite(13, HIGH) translates the pin number into a port and bit by reading two tables from Flash, checks whether the pin is attached to a PWM channel and, if so, detaches it, disables interrupts, modifies the register and re-enables them - dozens of cycles, instead of two.

9Debugging a microcontroller9 min

Debugging a microcontroller is structurally harder than on a computer: it has no screen, console or file system for a log; it interacts with the physical world in real time (a motor does not stop for a breakpoint); many faults sit at the code-hardware boundary (a poorly soldered wire, a power supply that sags), invisible to a software debugger; and the resources needed for debugging - program memory, pins - are exactly the resources in short supply.

Hardware-level debugging

For small AVRs, the mechanism is called debugWIRE - it uses a single wire, the reset pin itself, turned into a bidirectional command link: it stops the processor, reads/writes registers and memory, executes step by step, sets breakpoints.

JTAG (four or five pins, on larger AVRs and most ARM chips) and SWD (the reduced two-pin variant, specific to ARM) offer the same basic functions - breakpoints, step-by-step execution, inspecting variables and the stack - working because the debugging device reads the .elf file and knows which address corresponds to which line of code.

Why serial messages remain the main tool

They need no extra hardware (the link already exists, the same one used for uploading), do not stop execution (the system keeps running while it reports), allow observing evolution over time - a value that drifts slowly shows up in a log, not in a single break.

10Flash full, SRAM exhausted: the memory budget11 min

Flash memory full

The simplest error, clearly reported by the development environment. The usual cause is not the code written by the student, but the included libraries - a graphics library, a networking one, or using floating-point arithmetic can each add thousands of bytes. Out of the 32768 bytes, the bootloader already consumes 512.

Solutions, in order of effort: removing unused libraries, giving up floating point where integers suffice, moving constant tables into Flash with PROGMEM, and, as a last resort, removing the bootloader and programming via ISP.

SRAM memory exhausted

Much more insidious - it produces no message. The program compiles, uploads, starts, works for a while, then produces absurd results or resets on its own.

/* consumes SRAM */
Serial.println("Temperature measured: ");
/* keeps the string in Flash */
Serial.println(F("Temperature measured: "));

11The clock and other confusions7 min

The clock configured differently than the code assumes

Shows up as wrong delays and garbled serial communication. The code does not measure time, it counts cycles: _delay_ms calculates the number of iterations starting from the F_CPU macro, defined at compile time; the same F_CPU is also used to calculate the speed divider of the serial interface.

Other frequent confusions

A wrongly selected board type leads to the wrong communication speed with the bootloader. The serial port occupied by another application makes the upload fail without a clear explanation. A pin used simultaneously by the application and the ISP interface (PB3, PB4, PB5) can prevent programming if an external circuit loads the lines too heavily. Omitting volatile on variables shared with interrupts produces a program that works at zero optimization and hangs at the default level - wrongly suggesting a compiler bug.

12Frequent mistakes4 min

• "The program compiled without errors, so it is correct." Compiling only checks syntax and types. A program that fits in Flash, but exhausts SRAM at run time, compiles flawlessly and behaves randomly on the board. Read the memory report shown at the end of compilation, not just the "Done compiling" line, and watch the percentage of SRAM used by global variables.
• "I changed the code, but the board behaves the same - it is probably a hardware problem." Most often the upload never happened: the wrong port is selected, the board chosen in the menu does not match, or the transfer failed, and the previous program remained in Flash. Check the message at the end of the upload (the number of bytes written and verified) before suspecting the hardware.
• "I can copy the .elf file directly onto the microcontroller, it is just an executable." False - ELF contains addresses, sections and debugging information the programmer cannot interpret; the microcontroller has no file system and no loader. The Intel HEX file, obtained through conversion with avr-objcopy, is sent to the programmer; the .elf is kept only for debugging.
• "I set F_CPU in the code, so the microcontroller will run at that frequency." F_CPU controls nothing in hardware - it is just a constant the compiler uses to calculate delay loops. The real frequency comes from the oscillator and the configuration fuses. Match F_CPU to the real oscillator; if delays come out twice as long or twice as short, that is where the cause is, not in the code.

13Summary and glossary5 min

Programming means writing to a non-volatile memory at exact physical addresses, not installing a file. The transformation chain runs from the source code through preprocessing, compiling, assembling and linking to an ELF executable, then through conversion to the Intel HEX text format, written page by page into Flash by avrdude. The ATmega328P's Flash splits into the application section and the boot section, where the bootloader lives - a program that writes itself, through spm, enabled only in its own zone, at the cost of 512 bytes and a startup delay. ISP is the universal alternative, which does not depend on any code present on the chip and has access to the fuses. C dominates microcontroller programming for its closeness to the machine; Arduino libraries trade speed and memory for readability. Debugging is structurally harder than on a computer - serial messages remain the main tool, and the most insidious faults (exhausted SRAM, mismatched clock) produce no error message.

14Self-check questions7 min

1. Describe, in order, the transformations a C source file goes through until the code is written into Flash, naming the tool and resulting file for each stage.
2. Explain why the .elf file cannot be sent directly to the programmer and what information is lost when converting to Intel HEX.
3. What are the three tasks of the linker? What does relocation mean?
4. Why can an ordinary application program not write to its own Flash memory, and what hardware condition must be met for spm to have any effect?
5. Compare programming via bootloader with ISP from the point of view of the hardware needed, the space consumed and access to the configuration bits.
6. Explain the mechanism by which an Arduino board resets itself at the start of an upload, and connect it to the fact that opening the serial monitor restarts the program.
7. A program uses twenty constant messages of forty characters each. Estimate the SRAM consumption and explain how the F() macro reduces it.

15Directions for further study2 min

The next lecture moves down from the toolchain to the simplest and most used peripheral of a microcontroller: the input-output ports - configuring them bit by bit, reading and writing directly through registers, and the electrical pitfalls of a digital pin (floating, pull-up, multiplexing).