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!"
No, not really. That's how electronic components are priced. Unless your doing some custom one-time job, bulk pricing is how you price your build-of-materials. In fact, many times the actual price is even lower than the list price. Especially if you order larger quantities.
"Karma can only be portioned out by the cosmos." -Homer Simpson
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.
There is a difference between "insightful" and "inciteful" other than spelling.
Microchip MCUs in fact do have PWM/CCP modules, as well at D/A converters built in.
Sure they do. Microchip has many PICs in the $1 range that have a 5+ channel 10-bit DAC as well as a PWM module. They also have plenty of storage space for reasonable apps. Of course if you're going to write a web browser, spend the $5 for a larger part.
They als have the 10F series of 8-bit MCUs for under 50 cents, and in the SOT-23 package, they're about the size of a grain of rice.
That's the first rule of engineering, adjust the hardware to your functional requeriments as close as possible. Computation power excess it's only good when it comes for free and has no extra power compsumption.
For more than 100 units it is usually better to pay an experimented engineer rather than pay a beginner to program a 32 bit MCU in any strange/weird high level language, you'll save a bit on sofware but will lose money on every unit above 100.
The Atmel company has always gone to great pains ensuring that their chips are compatible. That's very smart, because developers can switch chips with little or no adjustments.
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.
Slashdot Syndrome: the sudden, extreme urge to correct someone in order to validate one's self.
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 ARM based processors are neat to poke at, but they just don't make sense in a lot of low end applications, where small 8-bit MCU will be around for a long, long time.
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.
:).
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.]
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.
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.
My rights don't need management.
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.
Actually I'm pretty sure the SX/Ubicom 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.
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. Compiler hides all the nasty stuff about handling memory and numbers anyway. I'm talking about stuff that is made millions, like household appliances.
So I'd say it's still a bit premature to declare the imminent death of 8-bit microcontrollers...
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.
... the fast 8-bit AtMEGA chips (AtMEGA128) actually do very well running 32-bit C++ code generated by AVR-GCC.
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 handle 32-bit code today.
Dahlmann tightly grips the knife, which he may have no idea how to use, and steps out into the plain.
Don't forget Automobiles: Engine, ABS, HVAC, and Airbag controllers all still use (well for the most part anyway) slow, cheep 8-bit micro-controllers.
The policy of the United States is worse than bad---it is insane. -- Ludwig von Mises, Economic Policy(1959)
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.
PJRC: Electronic Projects, 8051 Microcontroller Tools
The latest 8bit microcontrollers come with flash and SRAM on chip. No external components are need ed for memory. Even analog interfaces are on chip.
This is required for the most cost-sensitive applications.
Unless they integrate megabytes of flash and ram on these chips, 32bit cpu with an OS like uClinux wont supplant those 8bit applications.
All cpu's for embedded applications require a high level of integration to keep costs down.
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 memory addressing will average 2 bytes/instruction.
PIC: 12, 14 or 16 bits per instruction
AVR: 16 bits per instruction... some rarely used instructions are 32 bits.
Now, for the 32 bit ARM processor (the one article is about):
Normal Mode: 32 bits per instruction
Thumb Mode: 16 bits per instruction
So, you can easily see that in thumb mode, the 32 bit ARM chip has instructions comperable in code size to popular 8 bit chips. But the registers are 32 bits.
PJRC: Electronic Projects, 8051 Microcontroller Tools
Yes. At least GCC targets most 32-bit micros and some smaller ones like HC11/12 and AVR. Except for the Cypress M8 and Cygnal micros, I've been able to find free compiler and downloader tools (plus plans for homebrew interfaces) for just about every micro I've been interested in over the last ten years. AVR and PIC micros are starting to include UART bootloader support, and many 32-bit parts support generic JTAG for downloading and debug, if not by a serial port download process.
the LPC2100 series ARM7 micros from Philips have not only internal FLASH and RAM, but are also available with external RAM controllers. I have a devboard here that has one of these... it has two UARTS, two CAN interfaces, lots of GPIO, and tons of other goodies...
I often used 8-bit due to ease of programming. A 32-bit CPU with an OS is often much to complex. In the case of some medical equipment I was working on, I used a simple z80 processor. It was cheapish, but I have could have used less money. The issue was that I wanted something I could be 100% sure of real time on. This means that I wrote the code in assembler (if written correctly, assembler can be very easy to write and maintain) and I labeled each section of the code (not enough room for call instead of jmp) with clock counts. This made is much easier to be 100% sure of what was happening at any point in time.
I do look forward to playing with this atmel, however I will still actively use 8-bit controllers.
BTW.. as to some concerns mentioned regarding hobbiests. The fact is that you always have some form of surface mount in a project these days. So really, it's no added problem. I often design several projects at a time and then use someplace like www.4pcb.com to get the board made up. They charge $.50 per sq inch for a REALLY CHEAP board, but at least it's plated and through holed no solder mask though. As for mounting BGA chips, I have never walked into a small board shop and heard that they wouldn't solder down a few chips for $5 or even for free. It's typically the cost of a drive. Alternatively, I've had a great deal of luck with risking exceeding heat tolerances with a wallpaper peeling heat gun.