Moving to an ARM from the 8bit world? Some things you need to know.
It's a tight project. You need to keep costs down and the timescale is demanding. So, do you reach for the familiar development tools and the 8bit processor? Or go instead for a 32bit processor, with powerful software and development tools?
Until now, hardware cost might have put a 32bit device out of reach, but with the launch of products based on the ARM Cortex-M3 family, 32bit processing has become more accessible, with sufficient memory to use with an operating system and a high-level language compiler.
Perhaps it isn't quite as simple as that (E&T, April 10), but for many projects the move to 32bit is feasible. Architectural options for 32bit microcontrollers include MIPS and Power PC. But ARM has become a popular choice on the 32bit scene. ARM processor products from Philips, ST, Atmel, Oki and Texas Instruments, among others, are supported by a large ecosystem of software and hardware tools. The ARM7 has a significant share of the market, with over three billion manufactured and pricing can be below $4. But the new Cortex-M3 family has pushed prices down to less than $1 in some cases.
For an existing application, you need to ask some questions when considering a move to 32bit. Will it be a port or will it be worth starting again from scratch? Is the application peripheral-intensive, with lots of assembler, or compute intensive with minimal peripheral interaction? Or is it somewhere in between? Is the source code still available? If it is not, there is a case for a completely fresh start. If there is C code, is it strict ANSI C, or is it just C that runs? Some compilers have their own embedded extensions, which are implementation specific and cause porting problems. If there is uncertainty, most compilers have a 'strict ANSI C' option: recompiling with this selected will soon settle any doubts. The age of the oldest line in the code and the number of revisions the code has seen will also have an impact on how easy it is to port.
If the source code is available, a simple recompile is all that is necessary for it to run on an ARM 32-bit product. If the C/C++ source were targeted at the ARM instruction set, then moving to Cortex-M3 is a simple recompile, while source targeted for Thumb can be used as-is or re-compiled.
Assembler sources for the ARM architecture will need to be reassembled for Cortex-M3, but this can be done with ARM's RealView Developer Suite or similar development environments using Unified Assembler. Assembler sources for Thumb can either be used as-is or similarly reassembled. Other porting requirements may be to edit ISRs to remove assembler stubs, and removing the boot code and system configuration assembler.
Using an operating system can bring many advantages for the developer and the application, but what are the indications that an operating system may be useful? If the code size is over 64kb, there is probably a reason for looking at an operating system. If it is under 32kb, then an operating system is probably not appropriate. An operating system is also going to give advantages if the application is carrying out more than function, or if future developments may mean that there will be more than one function.
The advantages an operating system has over single-task programs are fourfold: performance, complexity, throughput and documentation. Performance is not a measure of sheer throughput but is, instead, a guarantee of the worst-case application response time to an external event, normally the time taken to process the interrupt and schedule the associated thread.
Complexity, or rather the reduction of complexity, is a direct result of not having to put processor allocation logic throughout the application. Just inserting the logic is difficult, but the operating system become even more useful when the application requires maintenance or upgrading. Related to reducing complexity is often an increase in processor throughput, caused by removing the processor allocation logic overhead, and an increase in the bounding responsiveness of the system. Dividing an application up into tasks, necessary for the efficient functioning of the operating system, makes the application easier to document and easier to understand, which should make it easier to maintain.
Making a choice
But there are a lot of operating systems available for ARM architectures, so what are the factors for making a choice? A significant issue is pricing. There are many different pricing models as the operating system suppliers attempt to meet different market needs while still making a return on their investment. Models exist for large organisations, for two-man shops and every size of establishment in between. Licenses may be processor specific (covering all designs using a specific processor), product or product family specific (covering either a single product or derivatives of that product) or site specific (covering everything produced at a specific site).
Some licenses have a low upfront charge and high per unit royalties. Others go for a higher fee with lower, or even zero, royalties. The pricing model has to be considered as an important part of the feature comparison of different operating systems. An important feature for any operating system should be kernel-aware debugging, allowing the debugging tool to display the status of data structures that are kernel specific. For kernel-aware debugging to be useful, the tool chain has to support this feature. Packaged with an operating system, or available as plug in options, can come a range of software components, such as flash file systems, stacks for USB, SAN or TCP/IP, networking software, embedded databases and embedded data management. There are two important questions here: which options are needed? And how seamlessly do they plug in?
Another consideration is whether the operating system is Eclipse-compatible - something that is becoming increasingly useful.
Since one reason for moving to 32bit is to use a higher-level language, compiler choice is important. Even though 32bit architectures provide a larger memory space, code size is still king: the efficiency of the compiler, both in the size of the code it produces and the efficiency with which the code executes, has to be the primary factor when carrying out an evaluation. And compiler efficiency also translates into lower system power consumption; the fewer instructions the processor has to execute the less power is consumed.
Today the first choice of language is C++, but there are more questions to ask. Is the compiler compliant with the Embedded Applications Binary Interface (EABI), allowing executables and shared objects to work together in different execution environments? Does it support the entire ARM product line, in terms of product families and instruction sets? And is the supplier committed to maintaining that support? What board-support packages are available?
In the embedded world, as in the real one, every decision has a price and the result of a series of decisions is usually a series of compromises. At each end of the application complexity spectrum the decisions on which architecture to use effectively make themselves. In the middle ground things are less clear-cut.
However, with the advent of low cost ARM Cortex-M3 based processors, supported by the full ARM ecosystem of development and debugging tools, the number of compromises is beginning to fall and moving to 32bit processors is realistic, even for products with low selling prices.