Design Article
Embedded S/W design re-use: IDEs are rising to the challenge
Joerg Bertholdt, Atmel Corporation
10/30/2012 4:46 PM EDT
But wait, there's more…
Finally, the board module provides the hardware view of the MCU in its target environment. The board code abstracts the modules above the board from the physical wiring and initialization functions that take care of I/O and external devices. The board code also identifies which board features are available to the modules higher up in the software stack.
The board definition provides a convenient way to assign digital and analog peripherals to each I/O pin. An application, such as an audio interface for a PC, may call for the allocation of a USB port, ADC and DAC channels, an SPI port and several general-purpose digital I/O channels that, on the PCB, are connected to buttons and LEDs.
For example, an LED that shows whether the MCU is asleep or active might be called GPIO4. Instead of having to remember this name, the developer can assign the more logical name of ACTIVITY_LED to the bitmask that is used to access the specific bits within the actual I/O port's register that controls the LED state. Once defined, this constant can be used consistently throughout the application to provide access from I/O function calls to the LED.
To ensure consistency in the way that module APIs are used, code provided by the ASF uses standard techniques for initialization and other management tasks. This helps reduce training time on new functions as programmers can expect to use API calls in a similar way to known modules when they incorporate a new function. For example, starting and stopping a module is normally performed by module_start(…) and module_stop(…) API calls. When encountering an A/D converter module, the programmer can expect to use functions of the type adc_start(…) and adc_stop(…).
Function-call conventions and parameters remain the same across the range of Atmel MCUs, including the Atmel AVR UC3, megaAVR, AVR XMEGA, and the SAM Cortex-M processor-based product lines. The ASF takes full advantage of the IDE and the structure of C code to ensure maximum applications compatibility – even across architectures, allowing common code development for 8-bit and 32-bit targets, even using different compilers.
For example, differences between compilers and the way in which they interpret information in the source files are absorbed into architecture-specific header files. This structure allows ASF to support GCC and IAR compilers for both 8-bit and 32-bit AVR and ARM processor-based MCUs. Similarly, differences between peripherals across the various MCUs in the Atmel portfolio are absorbed into header and C source files using rules developed by the ASF architects to ensure maximum commonality and portability. In drawing up the ASF, the software architects employed a series of rules and techniques that ensure common application code does not have to be changed to deal with a change in target MCU (Figure 3).
Figure 3. Identical C-code applications across Atmel's
AVR, AVR XMEGA, AVR UC3, Cortex-M3 SAM3,
and Cortex-M4 SAM4 MCUs.
Streamlines prototype to production process
This commonality assures ease of scaling as market demands change. It also streamlines the process of moving from prototype to production. Very often, developers will choose a more flexible, higher performance device for prototyping, so they can be assured of having sufficient headroom for the application code and potential changes during the project.
As the project nears completion, it may become clear that there is potential for using a lower cost part for production – one that may even use a different core architecture. Using this framework-based approach makes it extremely straightforward for a different target to be accommodated quickly, and provides the engineering agility that organizations need in order to thrive.
Click Here to learn more and to download a free copy of the Atmel Software Framework.
About the author
Joerg Bertholdt is director of marketing for MCU tools and software at Atmel Corporation, which he joined in 2011. He is responsible for product and marketing strategy for the company's tools and software solutions, including Atmel Studio 6, Atmel Software Framework and hardware tools.
Joerg began his career as a software engineer for the German Aeronautics Agency. Around this time, he was also a professional volleyball player for Germany's national team. He has held a variety of senior-level marketing positions in companies including MontaVista Software, Wind River Systems, Crossbow Technology and XMOS. Joerg has a master's degree in computer science from Technische Universitat in Munich, Germany.
If you found this article to be interest, visit Microcontroller / MCU Designline where – in addition to my Max's Cool Beans blogs on all sorts of "stuff" – you will find the latest and greatest design, technology, product, and news articles with regard to all aspects of designing and using microcontrollers.
Also, you can obtain a highlights update delivered directly to your inbox by signing up for my weekly newsletter – just Click Here to request this newsletter using the Manage Newsletters tab (if you aren't already a member you'll be asked to register, but it's free and painless so don't let that stop you [grin]).
Last but certainly not least, make sure you check out all of the discussions and other information resources at All Programmable Planet. For example, in addition to blogs by yours truly, microcontroller expert Duane Benson is learning how to use FPGAs to augment (sometimes replace) the MCUs in his robot (and other) projects.
Finally, the board module provides the hardware view of the MCU in its target environment. The board code abstracts the modules above the board from the physical wiring and initialization functions that take care of I/O and external devices. The board code also identifies which board features are available to the modules higher up in the software stack.
The board definition provides a convenient way to assign digital and analog peripherals to each I/O pin. An application, such as an audio interface for a PC, may call for the allocation of a USB port, ADC and DAC channels, an SPI port and several general-purpose digital I/O channels that, on the PCB, are connected to buttons and LEDs.
For example, an LED that shows whether the MCU is asleep or active might be called GPIO4. Instead of having to remember this name, the developer can assign the more logical name of ACTIVITY_LED to the bitmask that is used to access the specific bits within the actual I/O port's register that controls the LED state. Once defined, this constant can be used consistently throughout the application to provide access from I/O function calls to the LED.
To ensure consistency in the way that module APIs are used, code provided by the ASF uses standard techniques for initialization and other management tasks. This helps reduce training time on new functions as programmers can expect to use API calls in a similar way to known modules when they incorporate a new function. For example, starting and stopping a module is normally performed by module_start(…) and module_stop(…) API calls. When encountering an A/D converter module, the programmer can expect to use functions of the type adc_start(…) and adc_stop(…).
Function-call conventions and parameters remain the same across the range of Atmel MCUs, including the Atmel AVR UC3, megaAVR, AVR XMEGA, and the SAM Cortex-M processor-based product lines. The ASF takes full advantage of the IDE and the structure of C code to ensure maximum applications compatibility – even across architectures, allowing common code development for 8-bit and 32-bit targets, even using different compilers.
For example, differences between compilers and the way in which they interpret information in the source files are absorbed into architecture-specific header files. This structure allows ASF to support GCC and IAR compilers for both 8-bit and 32-bit AVR and ARM processor-based MCUs. Similarly, differences between peripherals across the various MCUs in the Atmel portfolio are absorbed into header and C source files using rules developed by the ASF architects to ensure maximum commonality and portability. In drawing up the ASF, the software architects employed a series of rules and techniques that ensure common application code does not have to be changed to deal with a change in target MCU (Figure 3).
Figure 3. Identical C-code applications across Atmel's
AVR, AVR XMEGA, AVR UC3, Cortex-M3 SAM3,
and Cortex-M4 SAM4 MCUs.
Streamlines prototype to production process
This commonality assures ease of scaling as market demands change. It also streamlines the process of moving from prototype to production. Very often, developers will choose a more flexible, higher performance device for prototyping, so they can be assured of having sufficient headroom for the application code and potential changes during the project.
As the project nears completion, it may become clear that there is potential for using a lower cost part for production – one that may even use a different core architecture. Using this framework-based approach makes it extremely straightforward for a different target to be accommodated quickly, and provides the engineering agility that organizations need in order to thrive.
Click Here to learn more and to download a free copy of the Atmel Software Framework.
About the author
Joerg Bertholdt is director of marketing for MCU tools and software at Atmel Corporation, which he joined in 2011. He is responsible for product and marketing strategy for the company's tools and software solutions, including Atmel Studio 6, Atmel Software Framework and hardware tools.Joerg began his career as a software engineer for the German Aeronautics Agency. Around this time, he was also a professional volleyball player for Germany's national team. He has held a variety of senior-level marketing positions in companies including MontaVista Software, Wind River Systems, Crossbow Technology and XMOS. Joerg has a master's degree in computer science from Technische Universitat in Munich, Germany.
If you found this article to be interest, visit Microcontroller / MCU Designline where – in addition to my Max's Cool Beans blogs on all sorts of "stuff" – you will find the latest and greatest design, technology, product, and news articles with regard to all aspects of designing and using microcontrollers.
Also, you can obtain a highlights update delivered directly to your inbox by signing up for my weekly newsletter – just Click Here to request this newsletter using the Manage Newsletters tab (if you aren't already a member you'll be asked to register, but it's free and painless so don't let that stop you [grin]).
Last but certainly not least, make sure you check out all of the discussions and other information resources at All Programmable Planet. For example, in addition to blogs by yours truly, microcontroller expert Duane Benson is learning how to use FPGAs to augment (sometimes replace) the MCUs in his robot (and other) projects.
|
|
|
|
|
Navigate to related information