32-bit Processors, Cheap 335
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!"
Death of 8-bit (Score:5, Funny)
The death of the 8-bit uC market has long been predicted
Has Netcraft confirmed it?
Overkill (Score:5, Insightful)
Anyone who has done this design knows that there is more cost in what happens on the whiteboard than something like this at the component level.
Not everything in the world has the "upgrade or else" fear that surrounds the personal computer industry.
Re:Overkill (Score:5, Interesting)
So, when do I get my full-pentium-PC-on-a-chip so I can play X-Com on my watch?
Re:Overkill (Score:5, Informative)
Re:Overkill (Score:2)
Re:Overkill (Score:3, Insightful)
Re:Overkill (Score:3, Informative)
There's still a lot of stuff that doesn't have and never will have any use for more than 8 bits in it's microcontroller, and having more will not be any improvement, only thing that matters is the component cost and availability of development tools. Com
Re:Overkill (Score:4, Informative)
Re:Overkill (Score:5, Insightful)
Actually, I don't see much demand for these "medium speed" controllers. For control applications, they're overkill most of the time, and for multimedia stuff, they're too slow/small.
Re:Overkill (Score:3, Interesting)
Re:Overkill (Score:3, Insightful)
Recalls do happen.
Re:Overkill (Score:5, Informative)
I've been playing with Atmel's 8-bit line. What makes these chips nice is that they're fast enough to do a lot of things in software that would otherwise require dedicated hardware (PWM, audio input/output/processing), while still leaving enough cycles free to do the high-level control work. Atmel also has a habit of throwing everything including the kitchen sink as peripherals into the controllers, making them very versatile. Yet, you can clock them down and turn off peripherals you don't need in order to get the same kind of power consumption you'd get with a simpler chip, when needed.
From Atmel's point of view, this type of architecture makes sense - instead of 20 similar lines of microcontrollers with different peripherals, they have two or three (for different voltages, mainly).
From a widget designer's point of view, this saves on learning curve and equipment (become familiar with and buy equipment for one or two families of device instead of dozens), and gives them a chip they can use as all-purpose glue with only a modest hit over an application-specific solution.
In summary: Go Atmel
[As for 8 vs. 32 bits, the 8 bit family will likely always be lower power for digital functions, due to fewer nodes being switched per operation.]
The other thing is.... (Score:3, Informative)
I recently ported a 3600 bps FSK modem, or at least the demodulator half of it, from Win32 (MSVC) to a 16 MHz AtMEGA128. I had very low expectations, but to my surprised the code was compiling under AVR-GCC in an afternoon and worked great with almost no tinkering needed. A native 32-bit controller would be even better, but many users would be surprised at just how well the 8-bit Atmel parts han
Re:Overkill (Score:3, Informative)
This was true about 10+ years ago.
ECN magazine, for example, sometimes would publish charts showing 4, 8, 16 and 32 cpu market share. I recall seeing one of these charts around 98 or 99, and indeed 8 bit chips had the vast majority of the market. I believe the topic of the article was about how 16 bit chips had failed to live up to marketing expectations... probably due to higher prices and maybe higher power consumption.
Re:Overkill (Score:3, Interesting)
Re:Overkill (Score:4, Interesting)
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/ [theregister.co.uk]
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.
Re:Overkill (Score:5, Funny)
Re:Overkill (Score:2)
Not just "Power" (Score:2)
With Atmel's line only having up to 64KB RAM and 512KB ROM, it doesn't seem to have much advantage over the 16 bit or 8 bit segmented memory uControlers on the market (8086 derivatives).
Annother concern with uControlers is pincount. 32 bit addressing seems likely to increase the number of pins if it can address external memory. This leads to higher system costs. One of the advantages of a SOC like the STAMP is that it has very few pins.
The 68HC11 and 68HC12 lines of uControlers can address similar amounts
Re:Not just "Power" (Score:4, Interesting)
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.
Re:Not just "Power" (Score:3, Interesting)
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 ba
Re:Overkill (Score:4, Insightful)
The main cost in a chip is the design, as you've noticed. Once you've masked out the die, it doesn't cost significantly more to fab a 32-bit chip as it does to fab an 8-bit chip. A 32-bit core implies that they're using a more modern process, so it's likely that they can now make a more powerful uC which uses less power & generates less heat than the previous generation.
Re:Overkill (Score:3, Insightful)
Re:Overkill (Score:4, Informative)
This is a pretty big, fundamental change. But based on their repuation, I think Atmel will provide the maximum amount of compatibility possible without being silly about it.
Re:Overkill (Score:2)
Sure there is. If the demand is low enough for the 8bit CPUs to make them cost more then the 32bit ones there is no reason for them to exist.
Re:Overkill (Score:2)
Re:Overkill (Score:2)
The reason to stick with an existing eight bit device is that it is a known entity. Depending on the application, a designed may chose a part with a proven track record over a new one.
For example, Motorola sold boatloads of their 68k based single board computers even when the PPC ones were available. Some of the sales were for existing products, but a lot were due to the fact that the 68k SBCs just plain old worked well.
Keep It Simple, Stanley. (Score:2)
Right. The 8-bit chips have fewer pins to tie down, so there's less that can go wrong. There are fewer registers, a simpler assembler language (for the 5% of the coding that takes 50% of the time :-), and everything is well-known.
But there are applications for a 32-bit computer on a chip. Want an IP-addressible toaster with built-in clock synced to NIST?
Re:Keep It Simple, Stanley. (Score:3, Insightful)
Actually, one of the things that makes that 5% of the code so difficult is often because you're trying to calculate 32-bit values with an 8-bit accumulator. On the fly. While handling interrupts...
Re:Overkill (Score:3, Interesting)
Re:Overkill (Score:2)
8 BIT LIVES ON!
-Jesse
Re:Overkill (Score:2)
Re:Overkill (Score:5, Insightful)
Also, 32bit probably drains more power and generates more heat. Staying 8bit was not generally a $$$ thing, it's that it's the right tool for the job.
Re:Overkill (Score:3, Insightful)
I'm surprised no one has mentioned memory. With 32 bit processors, you need four times the memory to run the same program as an 8 bit CPU. That makes these parts less flexible than their 8 bit counterparts, even though they are a bit faster.
Re:Overkill (Score:3, Insightful)
Not true...32 bit designs can still have memory that is addressable by the byte, and single bytes can still be loaded to or stored from the core registers. You just sign extend the upper 24 bits of the registers (fill with 0 if it's a positive value or 1 if it's negative). So you don't lose any flexibility there.
Re:Overkill (Score:3, Interesting)
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 t
Re:Overkill (Score:3, Informative)
With 32 bit processors, you need four times the memory to run the same program as an 8 bit CPU.
For some popular 8 bit microcontrollers:
8051: instructions 1 to 3 bytes. Heavy use of registers tends to average around 1.5 bytes/instruction, heavy use of direct memor
And so it begins (Score:2, Funny)
Re:And so it begins (Score:5, Insightful)
I know I do.
Re:And so it begins (Score:5, Insightful)
I know I don't.
Re:And so it begins (Score:2)
Wait nevermind, that's stupid.
Re:And so it begins (Score:2)
The parent comment that I respopnded to implied that every sentient being in the known universe would want this, I was pointing out that I don't.
Sorry if it went zipping right over your head.
Re:And so it begins (Score:2)
- Keep track of items you consume (microwaved dinners, loads of laundry, etc) and when you get ready to go shopping you get a list of items consumed to help you figure out if you need any more of said items.
- Cooking microwaveable dinners: you scan in the barcode and it sets your microwave to the right power settings to cook it (I hav
Re:And so it begins (Score:2, Funny)
Keep track of items you consume (microwaved dinners, loads of laundry, etc) and when you get ready to go shopping you get a list of items consumed to help you figure out if you need any more of said items.
Yeah, sign me up.
Re:And so it begins (Score:3, Informative)
Well, actually... you reminded me of a gadget I had read about a while ago. It was a combination oven and refrigerator. Now, before you go "WTF", let me explain. Let's say you prepare a roast that needs to marinade, and you'd like to have it ready to go by the time you get home from work. Well, you leave it in the oven with the fridge function on, and then you remotely tell it to start cooking so that it's done when you get home.
Yeah, it's total gadgety, but there *is* sometimes applicability.
It's called the Polara (Score:2)
And you don't turn it on remotely. You program it to switch from refridgerate to cook at a set time
Re:And so it begins (Score:5, Funny)
As a father of six, I know I would never preheat the oven without first looking inside. It would be unfortunate if an action figure, or worse the cat, were to meet an early demise.
Re:And so it begins (Score:3, Funny)
Re:And so it begins (Score:2, Funny)
That's very young to be a father, you know.
What's the world coming to, I ask myself.
I blame the parents.
Re:And so it begins (Score:4, Funny)
Re:And so it begins (Score:2)
In fact, there's no really good way, that I've ever seen, for a hobbyist to controll peripherals with his computer. What are your options? PCI... ParPort... SerialPort... Ethernet. None of these are easy to interface with. Small, powerful controllers are exactly what we nee
Not the death, but certainly less market (Score:5, Insightful)
Re:Not the death, but certainly less market (Score:4, Insightful)
Has the 8-bit MCU market shrunk? Sounds like "repeat it enough and EVENTUALLY some dumbass will believe it".
I've been writing 8 bit code for nigh 20 years. Somehow, whether it be luck or skill, I have remained employed. And so have a lot of programmers who, oddly enough, are still programming those "dead" 8 bitters.
"I'm not dead."
"What?"
"Nothing. There's your ninepence."
"I'm not dead."
"'Ere, he says he's not dead."
"Yes he is."
"I'm not."
"He isn't."
"Well, he will be soon, he's very ill."
Pretty much sez where we are with the 8 bitters. They aren't dead but there are those just ready to club them over the head (over and over and over) to try to make it so.
Enough already! (Score:5, Insightful)
Power requirements? Hardening? (Score:2, Interesting)
Sure they're cheap, but there's more that matters (Score:5, Insightful)
I'm pretty sure standard 8-bit uCs are overkill for most applications -- what would 32-bits buy you?
OK, you *can* put a web browser in your gas pump, but should you? Having seen BP's implementation, I would say not.
aQazaQa
Re:Sure they're cheap, but there's more that matte (Score:2)
Do they use a Schlumberger system?
Re:Sure they're cheap, but there's more that matte (Score:2)
Those 32 bits offer higher precision for certain applications. (Data logging, robotics, autonymous vehicles, remote sensing, etc.)
I think 8 bit has more life left in it. (Score:5, Insightful)
Re:I think 8 bit has more life left in it. (Score:2)
Re:I think 8 bit has more life left in it. (Score:2, Informative)
Re:I think 8 bit has more life left in it. (Score:2)
OK an ARM7 is going to kick its ass, but you can write reasonably powerful code in 68000.
Re:I think 8 bit has more life left in it. (Score:3, Informative)
There are quite a few new chips in the PIC18 series that are appearing with 24K+ of flash, 1K of EEPROM, and hardware UARTS. Useful for lots and affordable.
Re:I think 8 bit has more life left in it. (Score:2)
Of course you're right. However, when economies of scale make the bigger 32 bit processor cheaper than the smaller 8 bit processor, 32 bits may not be necessary but might make sense from a business perspective. And if that newly cheaper, overkill-class processor is far too powerful, perhaps you can get out of programming in assembly and start using a higher level language. Depending on wha
Wrong.. (Score:5, Interesting)
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.
8bit price, but how about 8bit power? (Score:5, Interesting)
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.
Hardly 8-bit price (Score:2)
Reliability (Score:2)
Also, the complexability of the board. To have a 32 bit processor you would have a more complex board. That leads into cost. A 10 or 20 cents over a million units is a hundred or two thousands of dollars you could have had as profit.
Re:Reliability (Score:2)
As a mere amateur (but then, this is Slashdot) I'd say that this particular design will mean that your board will be roughly equal in size to one built around an AVR. Except that there's more CPU power and memory to work with, which can be th
uClinux on these? not. (Score:2, Interesting)
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. :-(
Re:uClinux on these? not. (Score:2)
Has been the case for a few years (Score:2)
There are already a bunch of those in the market, and has been so for a few years. For example the ZFx86 [zflinux.com] is available, and some manufacturers do base SBCs and PC/104s on it, such as Tri-M's MZ104+ [tri-m.com].
And of course, it runs Linux! The full 32-bit version, and not the memory management-less ucLinux thing.
Re:Has been the case for a few years (Score:2)
I agree.
The only advantage I see for the SoC mentioned in the article, is the price point. At 3$ (albeit in quantities of 10,000), it is appealing for some applications. It is technologically handicapped though, because of the tight memory.
The ones I linked to above are much more feature complete.
The hobyist? (Score:2)
AVR line has still a lot of life in it (Score:3, Interesting)
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.
Re:AVR line has still a lot of life in it (Score:2)
Re:AVR line has still a lot of life in it (Score:3, Informative)
Actually I'm pretty sure the SX/Ubicom [ubicom.com] processors hold that title - certainly way faster that Atmel's and Microchip's 8-bit parts anyway. The ip2022 is 160 MIPS (@ 160MHz) running a PIC-like instruction set on an improved, pipelined architecture. That part can run two 10 base T ethernet MACs at full speed in software.
Re:AVR line has still a lot of life in it (Score:2)
Let me guess... FPSLIC? If you d in the FPSLIC product line, I would have a few questions for you.
About the OS (Score:3, Funny)
Not practical for Linux... (Score:2)
There is enough room for Linux, though even stripped down to the minimum kernel there is little room for anything else.
Another OS or a custom program with no OS would probably be much more practical.
DVD MP3 player for the car. (Score:2)
Atmel says SoCs from the AT91 series have already been designed into industrial automation systems, MP-3/WMA players, data acquisition products, pagers, point-of-sales terminals, medical equipment, GPS units and networking systems.
That being the case, I'd like to see a DIY project to use one of these to go with a half-height DVD player for a low cost car DVD MP3 player.
No doubt such things will eventually be cheap retail. But till then a recipe for a little DIY
Real Applications (Score:3, Insightful)
Even though this has already been done with 8-bit controllers, it would be much easier with 32 bits. This will make it just a little easier to connect your toaster/fridge/(fill_in_the_blank) to your network.
From my cold dead hands... (Score:2, Informative)
Not bloody likely. I use Philip's line of 8051 based chips everyday and don't have any wish to give them up. The majority of their line is way more powerful than I need, they're ultra cheap, and I can still get them in packages that are convenient for hand assembly (something important for a company like us who make a lot of custom, short run product lines).
These fancy
Clue alert: $3 in volume is EXPENSIVE (Score:5, Interesting)
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...
ARM7TDMI? (Score:2, Insightful)
ARM7TDMI, isn't that the same processor that's in the Gameboy Advance?
RegardselFarto
Dev kit costs?? That's what I find critical. (Score:5, Informative)
Having an inexpensive 32 bit uC is great. How much are the development kits? 500$?
The basic stamps are great. For an 8-bit 10kHz platform that runs PBASIC.
The SX & PIC chips are great for 8-bit systems that run at a few MHz (sx up to 50 MHz), that are programmed in assembly.
The TI MSP430 is a great 16-bit platform that runs at 8MHz, programmed in C/C++ (in a few weeks they will probably unveil a 25MHz version). They also include lots of things that I don't like to have to add-on myself. (12-bit A/D & D/A, op-amps, HW uarts/I2C, and so on)
There would definitely be a market for these things, but I'd like to see if they can match development costs for small developers. It seems to me that a key is opening development to the masses. That's what impresses me about the few I listed above. Dev kits from TI are 100$, and from Parallax are
I use uC's for embedding scientific devices onto smaller/cheaper/faster chips. That's great. Now for me to be able try it, and learn to use it, I can't go buy an expensive dev kit. Regardless of the end cost of the chip, I prefer to pay 30-50$ for a board with a chip, that I put in a box and use, than a uC with smt leads that I can't get to work in place without a few hundred to thousand dollars of dev costs.
"The death of the 8-bit uC market" (Score:5, Insightful)
pin count, component size, power consumption, and overall complexity are the other major factors in embedded designs. all of these factors are higher in 32bit uCs.
8bit designs arent used solely because they're less powerful, but because they are far simpler than the mess of logic required to support 16bit or 32bit uCs.
8bit uCs aren't in any danger of being killed off by this.
Good reasons for using 4/8/16 bit SOC controllers: (Score:4, Informative)
1) High code density: Even if you need more instructions to perform an operation, if the instructions are only 8 or 16 bits wide, you wind up with a smaller executable. Hence, you need fewer bytes of ROM to store the firmware. And if a lot of your data is byte sized anyway, (processing strings, or reading an 8 bit ADC or setting an 8 bit PWM) the code may be smaller still, since there is no byte packing/unpacking into a 32 bit space required. (Incidentally, this is a major problem with 64 bit and VLIW computing.)
2) Power consumption. An 8 bit processor has only 25% the bus width of a 32 bit processor. Registers, instruction decoders, and ALU are 25% as complex. Ergo, for the same manufacturing process and clock rate, an 8 bit core will always consume a lot less power. If you are trying to run an algorithm off a watch battery, this really matters. That is chiefly why the venerable 8 bit PIC with its horrid assembly code, continues to be popular.
3) Less die space. Same reasoning as above. if you are doing an ASIC and can get away with an an onboard 8 bit controller core, why would you waste silicon using 32 bits?
3) Backwards compatability, ability to run legacy code. Even in embedded systems, stuff gets reused. 95% of you will be reading this on an x86 PCm which happens to trace back to a 4.7 MHz 8 bit ancestor found in the original IBM PC, the 8088.
What it ultimately boils down to, is selecting the right tool for the job. And there will always be a niche somewhere for humble little lightweight 4 and 8 bit controllers.
Let's compare... (Score:3, Interesting)
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.
Proven Reliability (Score:3, Insightful)
As you go with smaller dies, you introduce the potential for problems in extreme environments..
You also have decades of experience and existing tools that have to be dealt with..
There is more to the cost of an embedded solution then the CPU cost..
Cutting through the fog (Score:3, Insightful)
Not so. Manufacturers, including ATMEL, run new and high volume products through the latest small geometry low voltage processes; Older 16/8/4bit parts in the main get left behind on higher power consumption lines, never to be die shrunk.
2) Goodbye 8bit
There will always be a place for the smaller parts. Rice Cookers for example are manufacutered in *huge* quantities; Do you think they will spend 10 cent more on a CPU because it is 'easier to code on'? No.
LQFP 40 and 64 pin packages can be soldered by your average electronics ham; I for one am looking forward to playing with an ARM CPU finally. If I can ever get one, which is unlikely. Atmel are not Microchip, sadly
Mike.
tight even on a PDP-11 (Score:3, Interesting)
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.
Not for those with a shaky hand... (Score:3, Insightful)
Re:Misleading Summary (Score:4, Informative)
Re:Misleading Summary (Score:2)
Re:Misleading Summary (Score:3, Insightful)
Not really (Score:2)
"...as low as..." implys that there are other, higher prices.
Re:MC68000 cluster computing? (Score:2)
Re:Why now..... (Score:3, Interesting)
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
Re:An offtopic vent - embedded development (Score:3, Informative)