Arndt, Niclas

Abstract [en]

This thesis aims to answer a number of basic questions about microcontroller development:

• What’s the potential for writing more efficient program code and is it worth the effort? How could it be done?

Could the presumed trade-off between code space and development time be overcome?

• Which microcontroller hardware architecture should you choose?

• Which IDE (development ecosystem) should you choose?

This is an investigation of the above, using separate sets of incremental code changes (improvements) to a simple serial port communication test program. Two generations of Atmel 8-bit AVR microcontrollers (ATmega and ATxmega) and two conceptually different IDEs (BASCOM-AVR and Atmel Studio 6.1) are chosen for the comparison.

The benefits of producing smaller and/or faster code is the ability to use smaller (cheaper) devices and reduce power consumption. A number of techniques for manual program optimization are used and presented, showing that it’s the developer skills and the IDE driver library concept and quality that mainly affect code quality and development time, rather than high code quality and low development time being mutually exclusive.

The investigation shows that the complexity costs incurred by using memory-wise bigger and more powerful devices with more features and peripheral module instances are surprisingly big. This is mostly seen in the IV table space (many and advanced peripherals), ISR prologue and epilogue (memory size above 64k words), and program code size (configuration and initialization of peripherals).

The 8-bit AVR limitation of having only three memory pointers is found to have consequences for the programming model, making it important to avoid keeping several concurrent memory pointers, so that the compiler doesn’t have to move register data around. This means that the ATxmega probably can’t reap the full benefit of its uniform peripheral module memory layout and the ensuing struct-based addressing model.

The test results show that a mixed addressing model should be used for 8-bit AVR ATxmega, in which “static” (absolute) addressing is better at one (serial port) instance, at three or more the “structs and pointers” addressing is preferable, and at two it’s a draw. This fact is not dependent on the three pointer limitation, but is likely to be strengthened by it.

As a mixed addressing model is necessary for efficient programming, it is clear that the driver library must reflect this, either via alternative implementations or by specifying “interfaces” that the (custom) driver must implement if abstraction to higher-level application code is desired. A GUI-based tool for driver code generation based on developer input is therefore suggested.

The translation from peripheral instance number to base address so far used by BASCOM-AVR for ATxmega is expensive, which resulted in a suggestion for a HW-based look-up table that would generally reduce both code size and clock cycle count and possibly enable a common accessing model for ATmega, ATxmega, and ARM.

In the IDE evaluation, both alternatives were very appreciated. BASCOM-AVR is found to be a fine productivityenhancement tool due to its large number of built-in commands for the most commonly used peripherals. Atmel Studio 6.1 suffers greatly in this area from its ill-favored ASF driver library. For developers familiar with the AVRs, the powerful avrgcc optimizing compiler and integrated debugger still make it worthwhile adapting application note code and datasheet information, at a significant development time penalty compared to BASCOM-AVR.

Regarding ATmega vs. ATxmega, it was decided that both have its place, due to differences in feature sets and number of peripheral instances. ATxmega seems more competitively priced compared to ATmega, but incurs a complexity cost in terms of code size and clock cycles. When it’s a draw, ATmega should be chosen.