Atmel AVR Software Framework lets you stand on the shoulders of software giants

Atmel AVR Software Framework lets you stand on the shoulders of software giants

A large library of source code that will shave months of a design involving an Atmel AVR microcontroller, Atmel AVR Software Framework contains a vast body of source code neatly organized into five layers, and tops it off with over 500 application examples

BY HAAKON SKAR
Director AVR Microcontrollers, Atmel
www.atmel.com

If you are a software engineer like me, you probably love to write every line of source code yourself. You know from experience that true quality source code can only be achieved by sweating for weeks and months over the keyboard until every single line of source code is optimized, verified, and certified. Truly, high-quality code is built to operate flawlessly until the end of time.

Luckily, people like me also like to share the fruits of our hard labor so others following in our footsteps won’t have to do the same job all over again. So we share the code that we consider “commodities” with others, while holding on to the code that makes our product truly unique. More about that later.

Why reinvent the software wheel?

Why should you want to reinvent the wheel? Just think of a commodity like a communication driver for USB, Ethernet or Wi-Fi. No matter how many all-nighters and working weekends you put into that code, I bet you a million dollars the end user isn’t going to hook up a cable and utter “Wow, look at how all that data flows across the USB cable.” He won’t, because he obviously can’t see that data. Besides, he will be too busy looking for some buttons to push. To an end user, a communications driver can only be classified as “does not work,” which will make the user hate the product, or “works,” which will translate into the user not reflecting about it at all.

With no value added through these commodity drivers, it’s a good thing to outsource that part of the design work, and focus on the code that makes your product truly unique. There are undoubtedly many sources of high-quality code out there, both free and commercial, that allows you to stand on the shoulders of giants.

AVR Software Framework

This is exactly the reason why Atmel is offering the Atmel AVR Software Framework for their AVR microcontrollers. This is a library of source code for common tasks like communications; analog and digital I/O; environment sensors; integer-, fixed-, and floating-point math libraries; DSP libraries; audio and video multimedia; graphics and graphical user interfaces; file systems; RTOS; and more. All this code is provided license- and royalty-free to all Atmel customers no matter how big or small they may be.

Five layers

The code provided in Atmel AVR Software Framework (ASF) is organized in five seamless layers.

– Application

– Services

– External components

– Internal peripherals

– Board definition

Understanding the stack is best done from the bottom.

Fig. 1: Illustrates the 5 layers of the AVR Software Framework. This organization offers flexibility to quickly mix and match code from each layer when developing a new application.

Board definition

Understanding the stack is best done from the bottom. In the lower “board definition” layer, we assign digital and analog peripherals to each I/O pin. This gives us a convenient way to control which peripheral is assigned to each pin. For example, we may choose that our application will use one USB device port, four ADC channels, two I2C ports, one SPI port, 6 inputs for buttons, and three outputs for LEDs. This is also the layer where you assign logical names such “ANALOG_FILTER_INPUT”, “PLAY_BUTTON” and “GREEN_LED1” to each I/O pin. Assigning logical names has no effect on the code generated on the higher levels, but it will make our code on higher layers a lot easier to read and understand.

The board definition layer consists mainly of macros, so the code size is negligible.

Internal peripherals

Layer 2 is called the “peripherals” layer, and this is the only layer that speaks directly to the on-chip hardware. The driver layer is responsible for initiating and managing each of the on-chip peripherals, providing an upwards API interface that allows the higher levels to control the board and speak to external components. For example, the peripherals layer configures the USB, ADC, I2 C, SPI, and GPIO peripherals and lets the higher levels know they are ready for use. The peripheral layer also controls the interrupt-, peripheral event-, and DMA controllers.

The code in the peripheral layer written with a focus on providing the functionality that a typical user will need in each of the on-chip peripherals. This gives a significantly smaller code size compared to offering full flexibility in each driver. If the application calls for a peripheral to operate in a “non-typical” mode, it is easy for the user to modify the existing source code, or add an extra function call to the API.

External components

Above the peripherals layer sits the “components” layer, which is responsible for communicating with external components such as displays, keyboards, memories, board controllers, and sensors (light, gyroscope, accelerometer, compass). This layer contains the code that initiates, calibrates and communicates with the external components. This communication is stripped off and hidden from the higher level layers.

Much of the code on the components layer is contributed by the supplier of the external component. This ensures that the code is written by the world’s foremost experts on each component, and able to push the external component to the maximum of its performance. Atmel is actively seeking participation from more suppliers in every category in order to offer a complete library of drivers for every possible external component.

Services

The fourth layer in the AVR Software Framework is the “services” layer. This is the layer that holds the USB and TCP/IP communication stacks, DSP and math libraries, audio codecs, graphic decoders, graphical user interfaces, and a whole lot more. The common denominator for all this code is that it takes a long time to write, optimize, test and certify. This “commodity” code has great value to the developer because of the time it will shave off the design cycle. But it will not be highly regarded or even noticed by the end user unless it fails. So it is good to know that the code in the services layer has been tested and verified in thousands of products in the field.

Application layer

At the very top of AVR Software Framework sits the “applications” layer. This is the code that manages everything, by analyzing the data collected from internal and external components and feeding it through the libraries and communication stacks of the services layer. In other words, this is where the true magic happens, and what makes your application “truly unique”.

Atmel provides over 500 example applications, conveniently organized by components, boards, on-chip peripherals, and devices families. When venturing into a new design, these example applications provide valuable inspiration and a quick start for how the ASF expert would approach a particular task. ASF also contains several complete reference applications.

An LCD example

Figure 2 shows how each layer of ASF is used for driving graphics onto an LCD display. Each layer of the stack presents a tidy API to the level above. The board layer assigns the pins of the microcontroller capable of driving and SPI bus, and the SPI layer presents a transparent communication channel between the LCD component driver and the actual LCD display. Above the LCD display driver sits the graphics layer that puts graphics on the LCD display using the various draw and write function calls from the LCD layer. On top of it, sits the application that decides when and how to change the displayed graphics.

Fig. 2: Illustrates how each layer of an ASF is used for driving graphics onto an LCD display. Each layer of the stack offers a tidy API to the level above.

Utilities

In addition to the source code provided in the 5 main layers, there is also a “utils” toolbox with useful calculators and macros that automate the coding process. Utilities are not source code that is compiled into the finished binary, but rather tools that help calculate constants and calibration setpoints used by the other layers. ■

About the author

Haakon Skar is a Director of AVR Microcontrollers at Atmel Corporation. He joined the AVR development team in 1997, and holds a masters degree in electronics and telematics from the Norwegian University of Science and Technology.