Slashdot Mirror
32-bit Processors, Cheap
An anonymous reader writes "Atmel is sampling the first in a new line of 32-bit system-on-chip processors that could spell the death of the venerable 8-bit microcontroller market by offering 32-bit performance at 8-bit pricing. Priced as low as $3 each, the AT91SAM7 chips with ARM7TDMI RISC CPU cores and built-in RAM/flash memory may even be able to run a form of Linux called uClinux. The death of the 8-bit uC market has long been predicted -- sounds like the end is nigh!"
Well, consider how much more complicated embedded apps are getting - think about the onboard computer in the Audi, and the increasing numbes of mp3 players, movie players and whatnot. While "upgrade or else" is stupid, damn if this thing won't be useful.
So, when do I get my full-pentium-PC-on-a-chip so I can play X-Com on my watch?
There are so many embedded applications that do just fine with 8-bit controllers that there is no reason they should dissapear just because something more powerful comes along.
So why can't I continue to buy P2 machines at my local computer retailer, if all I want to do is surf the web and write letters to Grandma?
Hint: it has to do with suppliers discontinuing their product lines.
The big questions to be answered before these make the big time are power requirements and hardening - if they use the same or less power than the current crop, and are resistant to environmental extremes like the current crop, then we're onto something.
8 bits is all the majority of embedded applications need. Its lower power, and cheaper.
8 bits rules the world and will continue to do so for a long time.
If your application needs the extra capabilities that a 32 bit chip offers, this is a big deal, but if the old 8bit standby does the job an draws a few milliwatts less, you're better off sticking with the old fashioned, 8bit chip.
I think it's a little too early to say goodbye to 8bit microcontrollers.
See what I've been reading.
I'd like to see uClinux fit into 512kB Flash and 64k SRAM. None of these seem to have any access method to external memory.
If you can fit it in, I'd be interested; I was all excited because a product I use at work has a Hitachi H8 processor... sadly 1M Flash and 128k RAM isn't enough. :-(
The Reg just put out a story how all sorts of embedded controllers in factory machines are a huge risk for attacks because the chips in them don't have the horsepower to do new things that the equipment's designer didn't originally take into account.
http://www.theregister.co.uk/2004/10/08/cyber_thre ats_menace_factories/
Sometimes you don't realize when you will actually need more horsepower (perhaps for things like encryption and authentication) than you originially thought you would.
The Atmel AVR is probably the most powerful (as in, raw performance) line of 8-bit MCUs, and there is a ton of code and utilities out there. And guess what? The applications these MCUs are designed to work with/in/for do not need a 32 bit MCU. Take, for example, the ATtiny2313: at 20 MHz, that part produces almost 20 MIPS... that's power that barely any application can top. The PIC MCUs have about the 1/8th to 1/10th of this performance, and still noone complains that they are too slow.
I don't see the AVR core disappearing just because of the new 32 bit Atmel kid on the block. It will have it's applications, but most AVR developers won't find too many compelling reasons to switch just yet. Remember, this is not like the desktop computer market, you don't look under the hood of your automated wheat mill to see whatmakes it tick.
Sigged!
Ummm.. There's no provisions for external memory. This is aimed at AVR designers who want more oomph, so all memory and flash is internal. No address bus.
The problem, of course, is that a TQFP package is not quite as hobyist-hackable as the old DIP packages because it requires you to have etched PCBs or a prototype adapter, which makes breadboarding harder.
Gentoo Sucks
Actually, you are correct, which is why you are wrong:). As you correctly state, whiteboard (and setup) costs are significant. SO when a standard 32 bit design arrives that costs 'the same' as an 8 bit design, everyone will move to the off-the-shelf (OTS) 32 bit design manufactured in quantity instead of paying for custom runs of old 8 bit stuff that is no longer in stock. Now it will not happen overnight as stocks of 4/8/16 bit designs exist and tooling still exists BUT to use an OTS 32 bit item will become cheaper than retooling for a new run of old 4/8/16 bit stuff eventually. Consequently at some point all new development will move to the new 'standard controller' (admittedly rewriting old controller code may be more expensive than retooling so old products may go to 'mature mode'). The key is cost and a true 'standard controller'. If the cost of the 32 bit standard controller is not 'the same' as the 8 bit controller then it may still be cheaper to use 8 bit in some cases. If the 32 bit market fragments then a 'standard controller' may not exist and software retooling expense may make it non viable.
Bottomline, not much new development is done on 4 bit controllers, which used to own the market. Eventually not much new development will be happening on 8 bit controllers as 32 bit controllers mature and become more price competitive. IF a standard 32 bit controller emerges, people will move to it to reduce the whiteboard costs you mention. Especially if it runs something remotely standard and feature robust, like a version of Linux.
As an embedded systems consumer product design engineer by trade, I can state with great confidence that $3 is NOT cheap.
In fact, for everyone who's pointed out that PIC's cost well under a dollar:
That's not cheap either.
4-bit watch micros and the kind of thing that runs your toaster are priced in the 0-25cents range in volume -- that's right, a few *cents*.
To wit: $3 is greater than the complete cost-of-goods for much of the consumer electronics market. A TINY 4-bit chip, engineered with the same modern techniques as a 32-bit one, will be able to conserve even more power. This may not matter if it's a toaster, but if you want something to run off a battery for 10 years, you better start hunting for the smallest, simplest die you can find.
Coding for older platforms is also very easy, very fast, and easy to certify as bug-free. Put that in your kernel forum and smoke it.
Don't get me wrong, a dirt-cheap linux-capable uCs make me as happy as the next dork, but they're for a very different kind of task. Consider the myriad PDAs with flashy graphics/media capabilities already running on ARM processors and similar...
the question is: How difficult in a 32bit CPU, and how many lines of code will be needed to perform the most common home elctronic function out there: "CLAP ON!" "CLAP OFF!"
- Minutus cantorum, minutus balorum, minutus carborata descendum pantorum.
Come on... TQFP isn't that bad. The fact is you just can't get decent pricing on flash, ram as DIP.
Anyway the real scary thing for hobbyists is BGA.
Circuit cellar had an article recently on converting a reflow oven out of a toaster oven. Or you could just use a hot plate to reflow the solder. So surface mount parts are definitely doable, and PCB prototyping houses charge fairly reasonable rates. So you should consider not fussing with breadboarding/wirewrap.
Alternatively with a laser printer and label backing you can make artwork to etch your own PCBs.
I would have loved to compare to the AT91SAM7S described in the article, but data sheets weren't available on the web site. All that said, I think the more impressive product is on the horizon: the AT91SAM7X series with built-in Ethernet.
Best of luck to the uClinux folks trying to pack everything into 64K of RAM. I've never tried to use less than 1 MB. A better choice, IMHO, would be something like eCos, which can be stripped down more, because in embedded systems, you don't always need a POSIX-style file system hierarchy.
While there have been many advances in 32-bit MCUs, it would be foolish to assume that the 8-bit MCU market is still stuck in the land of the 6502/8051/6800 CISC architectures. It's had its share of advances as well. And nobody really wants to use a 32-bit MCU for a mouse or keyboard.
Did you really expect to learn the current state of the art in its entirety? Do you think that would actually help you in any way?
I had a processor design class less than five years ago where we dug into the core of a MIPS CPU. I learned a lot about the inner workings of a modern processor, but to this day I've never physically seen a MIPS machine. Was it a waste of my time? No way!
And such is yours. Like you said, your mission is to learn how to interface a generic processor with a generic system. Get that and substituting other variables is a piece o' cake.
Dewey, what part of this looks like authorities should be involved?
With 32 bit processors, you need four times the memory to run the same program as an 8 bit CPU
Absolutely not. Why should it be that way ? Think about it, if one processes a byte, it can be processed in the same way on an 8bit or on a 64bit processor.
Even instruction sizes are not correlated to 'bitness' (an overloaded term). Many 8-bitters had variable-size instructions, just like an x86. In general 64-bit processors do not have 64-bit instructions. Some 32bit processors have 16-bit instructions or the option to use 16-bit instruction formats for code-size optimization (e.g., the ARM Thumb).
If one were to use exclusively N-bit pointers (where N is the 'bit-size' of the processor), then yes. But why should one be that stupid ? If one only needs 64kB of memory for an application, one can use 16bits addresses to address it all, whether on an 8-bitter or a 32-bitter. Note also that many '8-bits' processors use 16bits addresses. One doesn't go very far by having only 256 addresses.
And even if one chose to use N-bit pointers, not everything needs to be adressed by a pointer. Displacement addressing can be very useful, even on machines with gobs of memory. I work pretty exclusively on 64-bit systems with GBs of memory, yet it is often useful to save memory by saving relative offsets (or array indices) when we know that we
can fit those values in 16 or 32 bits. For modern processors adding an offset to a base pointer already in registers is almost free, while blowing a cache line can cost you hundreds or thousands of cycles.
Even BSD UNIX on PDP-11 really wanted more than 64k of RAM and more than 512k of disk space, and that was for a 16bit processor.
I don't think it's worth worrying about porting Linux to this. Give it another year and they'll be up to 256k. Until then, there are other open source solutions one could run on this.
That's all very fine and well, but some of us work with microcontrollers that run on coin cells. They might have a 32 KHz CPU clock and draw a fraction of a microampere most of the time.
Why don't you go outside and play with your go-cart, fuel cell, and 'octane.'
"What's the frequency Kenneth?"
8-bit microcontrollers aren't going anywhere. Many 8051's are still less than a tenth of the cost of these 32-bit chips. And many 8051's have on-board "everything." Your program is flashed onto the MCU, you have a built in serial port which requires, at most, a MAX232 to convert to RS232 levels, many have A/D and D/A converters, some even have MP3 decoding capability (Atmel if I remember correctly).
In short, these cheap 32-bit micros don't mean the "end of anything." They're a good tool for the right jobs, which probably include cell phones, PDAs, etc. But microcontrollers are not microprocessors. That's why you're not going to see a 32-bit CPU in your TV's remote control, inside your microwave (probably), controlling your fridge, inside the remote control of your car's remote key entry system, inside an alarm clock, inside your PC keyboard, blah blah blah.