The 8-bit Atmel AVR architecture is a popular, though single-source, family of microcontrollers with a very large range of chip size, memory size, and peripherals. The Bound-T execution-time and stack-usage analyser is available for this family and supports most devices in the family. This page shows:
The Atmel AVR architecture is used in a large family of 8-bit microcontrollers. For an introduction to the AVR, the Wikipedia entry is useful. Another rich source of information on the AVR is the AVRfreaks forum.
Although sharing (part of) the name, the "AVR32" processors are quite different, having a 32-bit architecture; they are not under discussion here.
The devices in the (8-bit) AVR family have various sets of on-chip peripherals and different amounts of on-chip memory. Some devices may have access to off-chip memory, too.
The AVR is mostly an 8-bit processor, with 32 general 8-bit registers. The Program Counter (PC) register is wider, 16 or 22 bits depending on the program-memory size of the device. The Stack Pointer (SP) register can be absent (for very small AVRs), or 8 bits wide, or 16 bits wide, depending on the data-memory size of the device.
Most AVR instructions work on 8-bit operands and produce 8-bit results. However, a few instructions work on 16-bit operands formed of two adjacent 8-bit registers — a register pair. Still, most 16-bit or wider computations must be implemented by two or more 8-bit instructions chained together with the carry flag.
Three register pairs — those formed by the six highest-numbered registers, namely the pair r27:r26 which is known as X, r29:r28 or Y, and r31:r30 or Z — can be used as pointers to data in the data memory. The Z register pair, r31:r30, can also be used as a pointer to data in the program memory. If the device has more than 64 KiB or data/program, these "pointer" registers can be extended from 16 to 24 bits by 8 high-order bits from three special registers called RAMPX, RAMPY, and RAMPZ, respectively.
Bound-T/AVR models all standard AVR instructions and registers for 8-bit and 16-bit computations. Moreover, Bound-T/AVR detects many carry-chained pairs of 8-bit computations and models the corresponding 16-bit computation, too. Thus loops with 16-bit counters can often be bounded automatically. However, wider computations (24-bit or 32-bit) are not yet detected.
For stack usage analysis Bound-T models both the standard "hardware" AVR stack (whether or not there is a visible SP register) and compiler-defined "software" or "data" stacks. Compilers use such stacks to hold parameters and local variables because the AVR instruction set does not provide any SP-based addressing modes, but does provide addressing modes using the pointer registers X, Y, Z as base registers. For example, the IAR compilers use the Y registers as the stack pointer for the IAR-defined software stack. The SP stack is then used only for subprogram return addresses, well fitted to the AVR call and ret instructions.
The execution time of AVR instructions is generally the same in all AVR devices. However, the data and code memory size of an AVR device influences the operation of some instructions — for example, the existence and width of the SP, the width of the PC (and thus the size of a return address on the stack), and the width of the pointer registers X, Y, Z (and thus also the precise effect of the auto-increment and auto-decrement addressing modes).
Bound-T/AVR knows about some AVR devices and their memory sizes. Use the command-line option -help to get a list of these devices. If your device is not listed, please ask Tidorum if this devices is supported, or can be supported.
Many cross-compilers for the AVR exist, both "free" ones and commercially licensed ones. In principle Bound-T is able to analyse machine code from any compiler. However, different compilers create executable files in different formats, and Bound-T is not able to read all possible formats. Moreover, different compilers may generate different kinds of symbolic debugging information, which Bound-T uses to communicate with the user in source-level terms. Finally, each compiler may generate its own idiomatic instruction sequences, some of which need special analysis methods, and has its own set of library subprograms, some of which may not follow the ordinary parameter-passing and stack-handling rules and therefore need special attention in Bound-T. For these reasons, Bound-T often needs to adapt its analysis to the compiler that generated the code to be analysed.
The table below lists the AVR cross-compilers that Bound-T currently knows about, in the sense that some aspects of the code are analysed in compiler-specific ways. However, this does not mean that Bound-T will correctly analyse all code from these compilers, for all source programs. The -compiler column shows the compiler name to be used in the Bound-T/AVR command-line option -compiler. The name is not case-sensitive.
If your compiler is not listed in this table, please contact Tidorum to ask if this compiler is supported, or can be supported.
| Producer | Compiler | Notes |
|---|---|---|
| IAR Systems | IAR AVR C/C++ compiler | This is the best-supported compiler at present. |
| ImageCraft | ICCV7 AVR C compiler | Only some tests have been done with this compiler. The COFF output seems to have some peculiarities, under investigation. |
| GNU | gcc | While some analyses can be done on code from this compiler, some aspects of the calling protocol and other conventions are not yet taken into account. In particular, Bound-T does not yet make use of the convention that register r1 contains the constant zero. |
| Document (PDF) | Description |
|---|---|
| Atmel AVR Application Note | Describes the capabilities of Bound-T for the AVR and how to use it. See also the general Bound-T manuals. |
Here is a small AVR program with some examples of its WCET and stack-usage analysis with Bound-T.