Break Points
Small is Beautiful
Jack Ganssle
3/9/2009 1:04 PM EDT
More and more it's a 32 bit world.
But the low end thrives, too. Every day it seems there are more offerings from Microchip, Silabs, and other vendors. Just last week Atmel announced a new line of TinyAVR microcontrollers that need just 0.7 volts; they're optimized to run from a single AAA battery. The price: a buck in 10K lots.
High-end processors are cool indeed, especially since so many are so cheap and require so little power. It's fascinating to see the 8051-ization of the ARM, for instance, as vendors like ST create extended families of parts using a 32 bit core surrounded by peripherals and memory. But the little 8 bitters are too often dismissed as antiques programmed by engineers who are dinosaurs. Many analysts predict that sliding costs will drive 8 bitters into oblivion.
They're wrong.
As 32 bit devices get cheaper, so do smaller ones. Tiny processors often make more efficient use of memory. And let's face it: An awful lot of control applications need just a tiny amount of smarts. A big CPU is overkill.
We have yet to see the dawn of the embedded revolution. Prices for the smallest devices will eventually fall to pennies and then even further. At some point smart dust will be a reality. Ad hoc mesh networking, energy scavenging and other technologies will let us instrument the planet in ways no one has yet imagined.
Tom Cantrell's "Silicon Update" column in the March issue of Circuit Cellar (subscription only) describes a new offering from Freescale. The RS08 is a scaled-down version of their venerable 9508, which itself derives from the prehistoric 6800.
The RS08 has even fewer registers: There's an accumulator, PC, a shadow PC, and a two bit condition code register. That's it.
Want a call stack? Well, you could implement one in software, much as we did in the old 1802 days, but the RS08 is designed for simple applications that don't do much calling.
Need interrupts? Tough. The part doesn't support any. If a device wants attention it sets a bit in a register, and then it wakes up the CPU if asleep. That's it.
The DFN package makes a pencil eraser look huge. Sporting six to eight pins (two are dedicated to power, of course) it's clear the devices are aimed a simple control systems.
At the high end vendors are cramming in bigger multi-level caches, speculative execution, branch prediction and all sorts of nifty performance-enhancing extras. But cache remains problematic for deterministic embedded systems; the other features are nice, but performance remains stymied by clock rates/power issues and the memory bus bottleneck. It's refreshing to see smaller parts that embrace simplicity, that are designed to fit a particular niche really well.
Jack G. Ganssle is a lecturer and consultant on embedded development issues. He conducts seminars on embedded systems and helps companies with their embedded challenges. Contact him at jack@ganssle.com. His website is www.ganssle.com.
|
|
|
|
|
krwada
3/9/2009 1:52 PM EDT
Let us not forget the Zilog Z80, or more importantly, the venerable 8085 core architecture. There are a lot of stuff out there that use the 808x architecture. From what I can tell though, the ARM7, ARM9 and 8051 are really the top dogs in the embedded space.
I myself, am a bit partial to the Texas Instruments MSP4xx ultra low power architecture. What's not to like about a processor that can get power from a grape???
Sign in to Reply
Alex OD.
3/9/2009 4:30 PM EDT
Did my first RS08 based project around Christmas time. I was told "it'll be a quick port from the 08 we're using", boy was that statement wrong.
The RS08 did all that I needed, manipulating PWMs for an RGB light show, but was quite tricky, I really had to be careful how I wrote the C code. Great controller, but you need to have an old fashioned mind set. The compiler worked, but assembler would have been easier I feel.
Sign in to Reply
B Kockoth
3/10/2009 5:21 AM EDT
I agree with Miro that the PIC is very inefficient when used with "C", but the tools to do so are inexpensive and easy to operate.
Some 10 years ago this discussion would have turned around the remaining 4-bitters, as far as I can tell they're all gone.
8 bit wide processing allows handy data representations, for example western character sets, or digital analogue values - according to rule of thumb 8 bits represent almost 30 dB which is enough dynamic range for many applications.
Sign in to Reply
inode
3/10/2009 9:19 AM EDT
Would be interesting to see how PIC24/dsPIC fit into Miro's table, because these are totally different design.
Sign in to Reply
theCemal
3/12/2009 11:32 AM EDT
The situation about PIC (at least in my country) is that they have good distribution channels (it is very very easy to reach a PIC then a MSP430 or M16C) and easier-to-learn architecture&command set especially about students who start from directly assembly language without C pointers&array,etc. One of our proverb says "The tree starts to bend over when it is young." In my opinion, these students will search for PIC series when they are grown up although they have learned C pointers&arrays, for the reason of they will feel more comfortable in PIC series.
Sign in to Reply
talulah
3/12/2009 11:47 AM EDT
In our industry (utility metering) we pick the cheapest microcontroller that is just capable of performing the requirements. That rarely selects a 32 bitter, but equally often selects 16 bit devices over 8 bits. Comparing memory efficiency must also take into account the relative cost of that memory from one manufacturer to another. At the end of the day, in volume manufacture cost is everything.
To answer the PIC 24 question, and present my benchmarks....
ARM 7TDMI (Atmel AT91SAM7S32, Arm) 5200
ARM 7TDMI (Atmel AT91SAM7S32, Thumb) 3020
Atmel 8051 (AT89C51RB2) 6473
Atmel 8051 (AT89LP2052) (single cycle) (*4) 6473
Atmel Atmega 162 4065
Atmel AVR32 (AT32AP7000) 3926
Atmel Xmega128A1 4149
Cambridge Consultants XAP4 4824
Cyan eCOG1 3624
EM Marin (EM6819) 10423
Freescale 68HC12 (MC68HC912B32) 2978
Freescale Coldfire (MCF52110) 3654
Intel 80C196KB 3455
Intel Celeron 1.8GHz 2486
Maxim MAXQ610 5655
Microchip dsPIC (30F2010) 4225
Microchip PIC 16/17 (PIC17C756A) 7534
Microchip PIC 18 (18F252) (*3) 6814
Microchip PIC24 5134
Microchip PIC24 5134
NEC 78K0 (78P0308GC) 4920
NEC 78K0R (uPD78F1162-64) 4751
NEC 78K0S (uPD78F9088) 6034
NEC V850 4380
NEC V850ES/SA2 (uPD703201) 3892
Renesas H8/300L (H8/3827R) 4518
Renesas H8300H (H8/36014) 4060
Renesas H8S (H8/2138a) 4022
Renesas M16C/26 (M30262F4) 3049
Renesas M7700 (M37906M4) 3463
Renesas R8C/26 3056
TI MSP430c337 2918
Zilog eZ80190 3976
Probably fairly similar results to QLs.
Sign in to Reply
ESD editorial staff: SRambo
3/19/2009 12:35 PM EDT
This e-mail was sent directly to Jack Ganssle:
Jack,
I just read your editorial on Embedded.com on the RS08 processor. This is a fun little processor.
We did some work on the instruction set design on this processor and wrote a C compiler for the RS08. This is a remarkable little processor that in the end out performed many people (including mine) expectations. The processor has family ties to the very old 6804, 6805 families and the various 6808 families with a dose of RISC processors in the way its call return is handled.
A lot of tradeoff's were made in the instruction set. The processor mapped the index register and index indirect into in memory space releasing all of the index specific instruction space to support a new tiny 16 byte address space.
Direct data access is limited to 8 bits address space very similar to the 6808 DIR space. A flexible paging system gives access to the full 14 bit linear address space (including ROM constants) and eliminates the need for EXT access found on the 6808. The RS08 does not have a data or subroutine return stack, this further reduces the opcode space from the 6808.
The RS08 has functionality not found in the 6808. Bit manipulation and bit branch instructions on the RS08 can access the full memory space where the 6808 can only do this on the first 256 bytes of address space. The memory to memory moves and constant to memory instructions can reference the full processor address space unlike the 256 address limit on the 6808. Both of these reduce data flow pressure on the single accumulator.
How well does it work? It works very well. Compiler technology is now very good at managing a compile time stack in global RAM space. Whole application optimizing compilers decide Tiny address space usage and nested subroutine support. Aggressive tail end recursion optimization further reduces RAM needs and accesses. Benchmarks run on the RS08 against the 6808 shows that over all it requires a few percent (6-8%) more code and execution cycles that the 6808. The die complexity is greatly reduced.
Byte Craft created syntax to support event driven processing to compensate for the lack of interrupts and RTOS real time support. Events are logical conditions (interrupt like flags and logical expressions on global data) that start the execution of a of a code block similar to interrupt support. Event bodies run to completion without interruption. This flat execution structure reduces the needed RAM to ROM ratio for applications running on the RS08 to about 30 to 1 instead of the more usual 20:1 for compiled code and 16:1 for the average hand coded assembler.
The background mode debugging facility has a second use suitable for many applications. The port may be used for inter processor communications in a multiprocessor environment where the RS08 is implements as a single function application. The BDM port allows asynchronous access to internal data buffers.
Some links on Byte Craft's web site referring to the RS08.
A technical overview of the C compiler for the RS08. www.bytecraft.com/downloads/rs08adv.pdf " target="_blank" style="">href="http://www.bytecraft.com/downloads/rs08adv.pdf"target="blank">www.bytecraft.com/downloads/rs08adv.pdf
The RS08 was the first processor that we implemented ISO 18037 on so that the whole instruction set can be encoded in C. This paper shows how we proved that anything that can be written in asm can be written in C with the same or less code space. www.bytecraft.com/C_versus_Assembly " target="_blank" style="">href="http://www.bytecraft.com/C_versus_Assembly"target="blank">www.bytecraft.com/C_versus_Assembly
www.bytecraft.com/When_Is_A_Branch_Not_A_Branch
" target="_blank" style="">href="http://www.bytecraft.com/When_Is_A_Branch_Not_A_Branch"target="blank">www.bytecraft.com/When_Is_A_Branch_Not_A_Branch
www.bytecraft.com/It_s_here
" target="_blank" style="">href="http://www.bytecraft.com/It_s_here"target="blank">www.bytecraft.com/It_s_here
www.bytecraft.com/taxonomy/term/116 " target="_blank" style="">href="http://www.bytecraft.com/taxonomy/term/116"target="blank">www.bytecraft.com/taxonomy/term/116
Regards,
Walter Banks
Byte Craft Limited
Sign in to Reply
Ray Keefe
3/22/2010 7:26 PM EDT
The majority of our projects are still implemented with 8 bit processors. And even our latest high end prower controller product uses an ARM processor with 2 8 bit processors for support - an asymmetrical multi-processor design.
With companies like Atmel producing excellent 8 bit products as well as 32 bit products (they even have a 4 bit product) things are very much alive and well in 8 bit land. Especially for very small low power systems.
That being said, there is definitely growth in 32 bit applications in embedded. Growth period. We are seeing more and more 8 bit and 32 bit systems every year as performance and price point make them commercially viable.
Ray Keefe
Successful Endeavours Pty Ltd
http://www.successful.com.au
Sign in to Reply