Anda di halaman 1dari 4

CONFERENCE

TECHNICAL SESSION

TECHNOLOGY IN-DEPTH

Moving from 8- and 16-bit Microcontrollers to ARM Processors


Author: Mark Moran, Eastern Regional Manager, IAR Systems Software Inc. Synopsis:
The advent of ARM7 SoCs at aggressive price points opens up many opportunities for embedded developers who are considering the use of this part. The specific cost savings in the near and long term will be examined, as well as other factors that bear on cost reduction as a result of choosing ARM7. Some of the migration issues will be considered as well as the choice of software development will also be examined for its long an short term effect on total development and production costs. It will be shown that the ARM7 architecture offers significant opportunities to push the boundaries of tradeoffs that have been constraining design engineers who have previously been using 8- and 16-bit parts.

ts the economy, stupid! was the unofficial campaign slogan of the 1992 presidential election that pitted William Jefferson Clinton against George Herbert Walker Bush. This phrase may be just as applicable to the process of contemporary embedded systems design. Developers are being squeezed from every conceivable angle to minimize all costs associated with a design, b.o.m., production and maintenance, as well as non-recurring engineering. Domestic and foreign competitive pressure is driving down profit margins all the time. Project deadlines remain ambitious, as time to market dominates product planning and launch. The iron triangle of cost, performance and delivery time, which perpetually bedevils product development engineers, is more difficult than ever to accommodate. Systems-on-chip microcontrollers based on the ARM7TDMI core have garnered a lot of attention in the embedded marketplace in the last year. There is a lot to like about these parts with their aggressive price points, small footprints, versatile peripheral and memory configurations, and blazingly fast execution speeds. This article will focus primarily on ARM7 SoCs, and examine the impact of these parts on the iron triangle and discuss factors which must be considered in order to achieve optimal tradeoffs among sometimes conflicting objectives. In considering whether or not to choose such a part for a design, a developer must consider both the short term and long term ramifications of this choice. In the short term, the dominant factors are part price, functionality, and cost of development. Long term factors include potential obsolescence, software maintenance, including both bug fixes and functionality extension. We will look at each of these factors in turn with focus on how the ARM architecture lends itself towards pushing

the boundaries of the cost/performance in a favorable direction. Parts Cost It is no secret that ARM7 SoCs are pushing the price/performance ratio to heretofore unseen levels. The main target of comparison between ARM7 SoCs is traditional 8-and 16-bit microcontrollers. Long considered the cheapest mainstream alternative, 8-bit microcontrollers are facing considerable competitive pressure from ARM7 SoCs. For example, a traditional 8-bit microcontroller family capable of 10 MIPS execution speed, with 64K of flash memory, 4K of RAM, analog to digital converter, 3 timers, EEPROM memory, SPI and UART ports and anywhere between 40-64 pins is approximately $7.50 (averaged over six parts in the family) in low quantities. Comparable ARM7 SoCs with very similar resource configurations except RAM, ranges from $4.00 to $5.50 at similar quantity levels. Of course it is almost impossible to do an apples to apples comparison between microcontrollers with their wide variety of configuration options. However, the main differences in the above comparison would be for the 8-bit part, you would expect about 1K of EEPROM memory, whereas there would be none on the ARM7 SoC. On the other hand, one can reasonably expect 816K of RAM memory on the die of the ARM7. Similar comparisons exist with traditional 16-bit parts. At the production quantities that are to be reasonably expected from products using such parts, a cost delta of $2.00 - $3.00 per unit can add tens or hundreds of thousands of dollars to the companys bottom line over the lifetime of the product. Many developers with long experience in 8-bit design sometimes experience a sense of intimidation on reading an ARM7 data sheet. The ARM7 register set dwarfs the comparatively simplicity of many 8-bit controller register sets. It is true that one

Information Quarterly

[40]

Volume 4, Number 3, 2005

CONFERENCE

TECHNOLOGY IN-DEPTH

TECHNICAL SESSION

must deal with more registers when writing device drivers for ARM7 on-chip peripherals. This author has seen part choices that have turned on whether the device drivers could be created in a reasonable time/cost frame. However, the light at the end of the tunnel of this dilemma is that the number of ARM registers is somewhat inflated by the status, set and clear paradigm. In other words, where an 8-bit part might have one R/W register to deal with, the ARM architecture may have three registers for the same purpose. Another thing responsible for register inflation is the vector interrupt controller (VIC) which has a number of registers controlling the priorities and interrupt configuration. This is a one-time investment in the learning curve. The good news is that once the developer gains comfort with writing to separate registers to set and clear sfr values, doing business with ARM peripherals is pretty much the same as the 8- and 16-bit world. In part cost comparison, we noted that a user can typically expect 8-, 16- or even 32K of RAM on the die for less cost than 8- and

16-bit parts with 4K of RAM. This opens up interesting possibilities to enhance product functionality with the incorporation of things like TCP/IP stacks, embedded file systems and GUIs. It also makes the possibility of using an RTOS more appealing than in many applications using 8- and 16-bit parts. The astute reader will note that a bought-in RTOS is an added expense, contravening the notion of minimization of development costs. While true that proprietary RTOSes cost real money, they also represent significant potential savings in product maintenance and enhancement. Once the learning curve of how to use an RTOS is overcome, use of such a tool usually makes software development more systematic. Extension of functionality is often considerably easier, with less regression testing required as capability is added to the application. In short, software development is labor intensive and expensive, software maintenance is more so. Anything that lessens this cost is a good thing. Most RTOS vendors have white papers and other information readily available to

help developers determine whether or not an RTOS is right for their application. Developers from the 8- and 16-bit domain who have been used to getting by without an RTOS would do well to re-examine their position in light of the fact that most ARM7 SoCs have adequate resources to use them without compromising the b.o.m. cost. In summary, if you suspect that an RTOS has long term economic benefits in your situation, you now have the horsepower to run it without adding external memory. Another significant cost of embedded systems development is tools. There are a number of high level language development tools to choose from, and more appearing on the market every day. These range from GNU tools at no initial cost, to proprietary tools at varying price points and capability levels. Although we have seen that ARM7 SoCs have very favorable price/resource configurations, the developer from the 8- and 16-bit world would do well to remember all of the coding paradigms for writing efficient code learned while using those parts over the years.

Information Quarterly

[41]

Volume 4, Number 3, 2005

CONFERENCE

TECHNICAL SESSION

TECHNOLOGY IN-DEPTH

Memory is still the biggest cost of the die despite plummeting price per kilo or megabyte levels. It is worth bearing in mind that an ARM compiler is really two compilers, one for ARM and one for Thumb mode instructions. The Thumb instruction set with its superior code density is the key to economy of resources and hence cost. Using Thumb mode, code densities at least equal to, and in many cases significantly superior to traditional 8- and 16-bit controllers can be achieved.

A more recent entry into the ARM7 SoC world with larger pin count and on-board DAC has a delta of $2.52 USD between the 128K and 256K memory footprint devices. In this case, over a 5K unit production run the tools cost is amortized much earlier, at around 1,190 units. The cost savings on this run mounts up to $9,601 after recovering the cost of the tools. Finally, a new ARM7 SoC with on-board USB controller has a cost differential of $2.78 between the 128K and 256K memory footprint versions, yielding a break even point of 1,079 units and a cost savings of $10,900 over the production run. Show me a bean counter that would not take $10K right to the companys bottom line! Individual circumstances, will of course vary, but it is clear that a high quality compiler pays for itself and adds savings to the company in the long run (see table 1).

It is worth the while of ARM7 SoC users to critically evaluate compiler efficiency, regardless of up front cost. While reliable, the GNU compiler is not the best at producing optimized code. The ramifications of high quality code optimization are considerable. Consider a general purpose ARM7 SoC as a representative example. Such a part has 128 and 256Kbytes of flash memory respectively, along with 16K of SRAM, four channel 10Cost Differential Break even point bit A/D converter, two Peripheral/Memory Configuration between 128K and number of units UARTS, SPI and I2C, in-sys256K flash memory produced for a tem and in-application profootprint compiler assumed gramming and embedded to costing $3K USD trace macrocell in an $0.75 4,000 LQFP64 package. In 5K 4 channel, 10bit A/D, quantity a major North 2 UART, WDG, 212C, 2SPI, trace macrocell, American distributor IAP, ISP, LQFP64 charges $6.09 and $6.84 respectively for these deriva- 8 channel 10bit A/D $9.34 - $7.49 = 1,622 $1.85 tives. The delta of $0.75 2 UART, 212C, 2SPI, This case 128K between these parts repre- 4x16bit Timers 6ch PWM, DAC, WDG, flash vs 64K flash sents a $3,750.00 expendiLQFP64 ture on the bill of materials over the course of a 5,000 4 channel 12 bit A/D $14.16 - $11.38 = 1,079 $2.78 unit production run (a rea- WDG, RTC, 4 UART, sonable scenario given the 2SPI, 2 I2C, 5x16bit intended markets for which Timers, USB, TQFP64 these parts were designed). Table 1 A compiler capable of high degree of optimization can crunch an In addition, users of a high quality comapplication into 128K that would normalpiler can typically expect direct technical ly require the choice of the 256K code footsupport from the manufacturer. Again, print with a less capable compiler. A savwith software being one of the most labor ings in the range of $500 - $1,500 on the intensive and costly part of a project, this b.o.m. can be realized after tools amortitranslates directly into savings on NRE. zation. Further, with time to market being a critical issue in competitive marketplaces, In cases where more exotic peripherals are even several days, much less weeks of lost included on the chip, the delta between profits can potentially outweigh the cost of variants tends to be bigger. For example, development tools. Those days can be the delta between the CAN versions of the spent by engineers trolling the Internet for above controllers is $0.85USD. This further answers, or typically saved by calling a reduces the breakeven point of a compiler tools vendors direct tech support for quick to fewer units, and can yield savings of resolution of issues. $1,250.00 - $2,000 on the b.o.m. after cost recovery of the tools. Debugging frequently occupies a signifi-

cant fraction of the software development budget of a project. There are probably nearly as many schools of thought on debugging as there are software engineers. Nevertheless, a consensus seems to be building in the marketplace as to the substantial advantages of JTAG debugging over traditional embedded debugging techniques. With in-circuit emulation all but rendered obsolete by cost considerations and clock speeds, JTAG debugging is the natural successor. There is a wide variety of JTAG debugger available on the market. Three factors are paramount in determining the cost of such a debugger, speed, trace capability and front-end software features. For most ARM7 SoC work, debuggers in the hundreds of dollars range are adequate. Some have respectable download speeds on the order of 128Kbits/sec, and these typically work with the front end debugging tools that come in contemporary compiler IDEs. Trace capability, which Cost saving on requires that the part B.O.M. after have on-board ETM recovery of tools trace macrocell impleinvestment mentation, bumps the cost of a debugger sig$750.00 nificantly into the thousands of dollars range. Trace capability is responsible for the biggest delta in debug$6,249.00 ger price points. Advanced debugger software features such as detailed control of breakpoint triggering $10,900.00 and similar features, is usually found in the debugger front ends that accompany hardware manufacturers debuggers. In most cases involving ARM7 SoCs, these are in the nice to have, not have to have category. For most ARM7 SoC work, many developers prefer a cheap and cheerful JTAG debugger that is easy to learn and use. Nothing, as the saying goes, is guaranteed in life except death and taxes. However, it is a good bet that the ARM architecture will be around for the foreseeable future. With major chipmakers such as Atmel, Cirrus Logic, Intel, Freescale, Oki, Philips, Samsung, Sharp, STMicroelectronics, Texas Instruments and others offering one form of ARM or another, its presence in the embedded marketplace is all but

Information Quarterly

[42]

Volume 4, Number 3, 2005

CONFERENCE

TECHNICAL SESSION

TECHNOLOGY IN-DEPTH

ensured. The probability of being stuck with an orphan part, often a designers worst nightmare is significantly reduced. Some developers are even going so far as to say that the ARM is the 8051 of this century. Another highly appealing virtue of the ARM architecture is that there is virtually infinite head room. Is your ARM7 processor running out of MIPS? Switch to an ARM9 processor, or move up to ARM11 processor! The same set of tools (carefully chosen) will support all of these architectures. Need something even cheaper than the prices discussed above? Although no price points have been officially released, market indicators strongly suggest that parts based on the Cortex core running a modified Thumb instruction set known as Thumb-II will continue to exert strong downward pressure on prices. Is a one dollar 32-bit part in the cards? That is not known right now. Extrapolating current trends suggests that it is a strong possibility that this price point or something close to it may be realized in the not to distant future.

Register for this session at the ARM Developers Conference Wednesday, October 5, 11:15-12:00

Upgrading from 8- and 16-Bit Microcontrollers to ARM Processors


Speaker: Mark Moran, IAR Systems Engineers who upgrade from an 8- or 16-bit environment to ARM face new challenges and requirements. Memory constraints and code size may no longer be as crucial as before, but the number of tools and solutions may seem overwhelming. In this seminar you will learn how to prepare existing projects so that they can be easily ported to the ARM environment.We will also discuss the evaluation and selection of development tools.

Information Quarterly

[43]

Volume 4, Number 3, 2005