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!"

Comments

Death of 8-bit

[Anonymous Coward]

The death of the 8-bit uC market has long been predicted

Has Netcraft confirmed it?

Overkill

[jsin]

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.

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

[Pxtl]

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?

Re:Overkill

[Rolo Tomasi]

Exactly, sounds like marketing hype ... I mean, a lot of (most?) consumer electronics still use 4-bit MCUs.

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

[LurkerXXX]

Well, that kind of depends on the application. Say we are talking about stuff controlling machines in factories...

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.

Re:Overkill

[Tenareth]

Yes, but this isn't the consumer market. Heck, 80186's are still made and used today.

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

[Tassach]

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.

Manufacturers are not stupid, therefore I'd be shocked if the 32-bit uC's are not backward-compatible with the older 8-bit models. Not just code-level backward compatibility, but pin-level backward compatibility too.

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

[jsin]

Fair enough, I just hate to see hundreds of yuppies running to Williams-Sonoma to find an upgrade for Mr. Coffee....

Re:Overkill

[temojen]

So, when do I get my full-pentium-PC-on-a-chip so I can play X-Com on my watch?

AMD.

Re:Overkill

[jumpingfred]

This is not correct. That assumes that the 8 bit and 32 bit processors take the same die area. I would think that the 8 bit processor would take less die area and would be cheaper to manufacture.

Re:Overkill

[Grayputer]

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.

Re:Overkill

[Doesn't_Comment_Code]

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.

Re:Overkill

[pilgrim23]

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!"

Re:Overkill

[Christopher Thomas]

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.]

Re:Overkill

[AKAImBatman]

Also, 32bit probably drains more power and generates more heat.

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

[Urkki]

• 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.

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...

Re:Overkill

[El]

I hope you've got lot's of burn ointment, and big biceps to carry around all those batteries -- a full pentium-PC-on-a-chip would draw more power and disipate more heat that your average lightbulb -- not exactly what I'd want strapped to my wrist!

Re:Overkill

[joe270]

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

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.

even though they are a bit faster

Actually, the speed of the processor is only dependent on its clock speed, not the size of the word that it can handle. If your words are 32 bits, then a 32 bit processor is much faster because you don't have the overhead of using 4 registers to hold the word (and manually coding for carries in addition, etc.) So, without a specific model or application in mind, you can't really say anything definitive about speed.

Re:Overkill

[The Ego]

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.

Re:Overkill

[the morgawr]

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.

Re:Overkill

[pjrc]

a lot of (most?) consumer electronics still use 4-bit MCUs.

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

[pjrc]

The following statement seems to assume that 8 bit CPUs have a uniform instruction size of a single 8-bit opcode, and 32 bit CPUs have a single 32 bit instruction size, and that an arbitrary program would need the same number of instructions.

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.

Re:Overkill

[AJWM]

Reflashing the firmware in a million CPU-based systems is a hell of a lot cheaper than redesigning, remanufacturing and replacing a million ASICs.

Recalls do happen.

Re:Overkill

[letxa2000]

Very true. Many people today just don't understand what "embedded" really means. As much as some people would like to call Palm, WinCE, a Pentium-in-a-small-box, or any computer in a small enclosure "embedded" that completely redefines what embedded traditionally meant. It meant that the the microcontroller was embedded within the rest of the product. The microcontroller wasn't the focus of the product but rather it significantly reduced part counts by doing what used to take lots of ICs and board space. You can bet that anything that includes this kind of 32-bit chip for $3 is going to be doing some heavy marketing for browsing rights on what drives the product. But do you really think anyone cares if their washing machine is 32-bit?

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.

Not the death, but certainly less market

[Anonymous Coward]

The 8-bit MCU market has been shrinking for over a decade. It's no secret. Of course there will always be a market for small-time CPUs; certainly hobbyists will want them. But traditional places like your car computers need more real-time DSP computation and the like, and require the MCU to grow with them.

Re:Not the death, but certainly less market

[feloneous cat]

The 8-bit MCU market has been shrinking for over a decade. It's no secret. Of course there will always be a market for small-time CPUs; certainly hobbyists will want them. But traditional places like your car computers need more real-time DSP computation and the like, and require the MCU to grow with them.

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.

Re:Not the death, but certainly less market

[bob beta]

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.'

Re:And so it begins

[garcia]

Who wants to be able to program their TV to record TV from work? Who wants to program their lights to come on from work? Who wants to program their heat/AC to turn on/off from work? Who wants their oven to preheat from work?

I know I do.

Enough already!

[Anonymous Coward]

While I love to hear news of the latest whizbang doohicky, I cannot stand when people have to add "This is surely going to end anyone on the planet ever using last years widget..." As geeks we should be aware and PROUD of old technology. Serial ports? I use them every day at work. 8 bit microcontrollers. I love them to death. They work nice, are cheap enough, and are very easy to design for and around. So yes, many places where someone might have used X in the past will now be replaced with Y, but so freakin what? But part of the joy of hacking is taking what someone else thought was worthless and using it anyway. Hence the stories of people salvaging old laptops or modding their Amigas to be a multimedia console, etc. Yes, the newest latest greatest toys are spiffy and should be discussed, but how about we all just settle down and stop dumping on anything not cutting edge?

Power requirements? Hardening?

[mmclure]

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.

Sure they're cheap, but there's more that matters

[Anonymous Coward]

What about the heat dissipation and power usage? Sometimes that's a lot more important than the price. If it's just as cheap but uses more power, you might need a bigger power supply, more batteries, better heat dissipation, possibly a fan, etc., it doesn't help.

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

I think 8 bit has more life left in it.

[Dzimas]

I use Microchip processors extensively for work, and there's a heck of a lot that I can accomplish with their limited architecture -- my most recent design required less than 8K of flash memory and was mostly written in assembler. For low-end applications, 32-bit doesn't make sense, especially if its going to add $1 to the cost of manufacture. Given that small 8-bit MCUs can be purchased for well under $1 in large volume, I think there's a market for them.

Re:I think 8 bit has more life left in it.

[Eowaennor]

Microchip MCUs in fact do have PWM/CCP modules, as well at D/A converters built in.

Re:I think 8 bit has more life left in it.

[Dzimas]

D/A converters are almost free these days - 5 10-bit converters are quite common on 28 pin devices. Arguably, that pushes the cost to almost $2 a chip. :)

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.

Wrong..

[taharvey]

"Unit volume is dominated today by the 8-bit control and instrumentation segment with over 389,000,000 units shipped this calendar year. This is followed by the 4-bit watch segment and the 8-bit PC peripherals segment." - In-Stat 2003

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?

[RealAlaskan]

These are micro controllers, where 32 instead of 8 bits may not be an advantage. Even if they cost no more than the 8bit chip, they'll still have to have more transistors, and thus draw more power than an 8bit chip using the same technology. Since these will be going into embedded applications where power matters, even a little more current draw could be a big drawback.

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.

Re:And so it begins

[zoobaby]

Would be good to know if your frozen burrito has cooked or needs another minute. You could add more time from the comfort of your desk chair.

uClinux on these? not.

[tzanger]

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:Misleading Summary

[RadioheadKid]

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.

Re:And so it begins

[Oliver Wendell Jones]

Who wants to worry about someone hacking their TV and deleting all their recordings? Who wants to worry about whether or not you're lights will stay on/off because some scriptkiddie wrote a BlinkenLitez for your neighborhood? Who wants to come home to find out their house is heated to a balmy 97 degrees because someone hacked their thermostat? Who wants to come home to find their oven has been running all day on Broil?

I know I don't.

AVR line has still a lot of life in it

[haggar]

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.

Re:AVR line has still a lot of life in it

[seanadams.com]

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.

Re:And so it begins

[ElForesto]

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.

Re:Not just "Power"

[cmowire]

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.

About the OS

[doombob]

Does anyone else think that uClinux looks like a dirty word? But seriously folks, has anyone tried this out on anything? I need to hear someone who's used it on Slashdot.

Re:And so it begins

[infinite9]

Who wants their oven to preheat from work?


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

[Anonymous Coward]

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.

.___
/ _ \
|@ @| It looks like you're going shopping.
|| || Would you like me to make a list for you?
|\V/|
\__/

Yeah, sign me up.

Real Applications

[Doesn't_Comment_Code]

There are a few applications where this step up will really help. There are several projects that impliment a tcp/ip stack on a microcontroller. I've seen webservers about the size of a quarter! How cool is that!

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.

Re:And so it begins

[kisielk]

How about a password protected oven lock? Or even biometric / key card

From my cold dead hands...

[technothrasher]

My parts reps are always in here repeating that stupid marketing line, "Look at this wiz-bang chip! So, I guess 8-bit is dead now, huh?"

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.

Re:Misleading Summary

[RadioheadKid]

Yeah, right after they design and build a printed circuit board (PCB) and get the board built, which at low quanties is not cheap and makes the $3 insignificant. Which leads back to my first point, the people who will be using these parts will be using them in bulk, so that statement is legitimate. Plus they said as low as $3. There is nothing misleading there.

Clue alert: $3 in volume is EXPENSIVE

[Anonymous Coward]

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...

Re:And so it begins

[mrak and swepe]

As a father of six,

That's very young to be a father, you know.

What's the world coming to, I ask myself.

I blame the parents.

Re:Keep It Simple, Stanley.

[Doctor Memory]

a simpler assembler language (for the 5% of the coding that takes 50% of the time :-)

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:Not just "Power"

[jhoger]

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.

ARM7TDMI?

[elFarto the 2nd]

ARM7TDMI, isn't that the same processor that's in the Gameboy Advance?

Regards
elFarto

Dev kit costs?? That's what I find critical.

[francisew]

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"

[bani]

there are a lot of reasons to use 8-bit uCs. price is only one of them, and rarely the most significant factor. often, uC price is the least significant factor.

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:

[earthforce_1]

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...

[Anonymous Coward]

I read the article and the part looks like a good next step in the evolution of 32-bit MCUs. However, it will not kill off the market for 8-bit MCUs. 8-bit MCUs still beat this part in a few areas:

• Package size: The AT91SAM7A is impressive in how much it packs into a 64-pin TSSOP package, but Atmel's 8-bit ATtiny15L is also impressive in what it packs into an 8-pin SOIC. And if that's too big, Microchip just released the PIC10F 8-bit microcontroller in a 6-pin SOT23 package. Don't sneeze.
• Price: 8 bit MCUs are still cheaper, most under $1 in quantity, while the AT91SAM7A is $3 in quantity.
• Power supplies: The ATtiny15L works with one supply between 2.7V to 5.5V, so it could run off a loosely-regulated supply, or straight off batteries, eliminating the need for a regulator. The AT91SAM7A needs a 3.3V core supply, and a second 5.0V supply if any of the I/O pins need the higher voltage. There are some parts that you still can't get in 3.3V.
• Power consumption: That ATtiny15L takes 3.0 mA active and 0.001 mA sleeping. The AT91SAM7A uses 0.24 mA sleeping and up to 78 mA when running (those figures are buried in the full data sheet). Good to know when battery life is an issue.
• Compiler support: both ARM and AVR architectures are supported by GCC.
• Architecture: Both AVR and ARM architectures are RISC architectures.
• Clock: The AT91SAM7A can run up to 8 MHz with an external crystal or 30 MHz with an external oscillator (using an internal PLL). The AVRs can run to 8 MHz on an internal oscillator (no extra parts) or 16 MHz from an external oscillator (though the ATmega26 has a trick where you can run at 16 MHz from the internal oscillator).

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

[nurb432]

One thing the 8bits have going for them is a proven track record of reliability.

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..

Re:Why now.....

[Just Some Guy]

it feels like a waste of time because if the field has advanced beyond my education what have learned other than I have alot more to learn.

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.

Cutting through the fog

[Anonymous Coward]

1) 8 bit CPU are lower power than 32bit CPU's
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.

The other thing is....

[John Miles]

... 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.

tight even on a PDP-11

[jeif1k]

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.

Not for those with a shaky hand...

[arabagast]

Reading in the article, it states that it will be delivered in LQFP packages, which means that it will be a pain in the a.. to solder it yourself. offcourse it's possible, but i believe many DIY projects don't include either the equipment, or skill to manage to solder this thing. For the more advanced it's offcourse pretty cool, but I guess i'll still stick with the PIC - there's currently no need to use this chip for 99% (yes, I picked this number randomly, and it is therefore not valid but..) of all the DIY projects out there.
..as I strike down upon thee..

Re:An offtopic vent - embedded development

[ajlitt]

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.

Philips has them, too

[EmagGeek]

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...