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?

Re:Death of 8-bit

[WebCowboy]

sounds like the end is nigh!

<sarcasm>Damn...first BSD and now the 8-bit uC? I don't know how I'll handle the loss</sarcasm>

Just the thing!

[ackthpt]

Excuse me doctor, could you please attach this to the metal plate you're putting in my skull?

I'm goin WiMax with uClinux! w00t!

"nigh!"
"No, no. 'Ni'. You're not doing it properly. No"

Re:Just the thing!

[Anonymous Coward]

I believe it was more like "Nugh"

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

[Anonymous Coward]

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.

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

[Kenja]

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

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

[Anonymous Coward]

So lets make all these machines super-secure by connecting them to the internet to deploy future upgrades.

Re:Overkill

[pavon]

Right, no-one is going to redesign for the sake of redesign. But for new devices why would someone choose to go with an 8-bit when the 32-bit is just as cheap and is easier to design for since it does not have as many restrictions as 8bit? If there are legitimate reasons why 8-bit is still better than 32-bit, in some situations, then it will stick around and coexist. But if not then it will die out eventually, and it is not hyperbole to say so.

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

[Enigma_Man]

This just means that 8-bit micros will cost $.10 instead of $.20 now, so things that don't need a lot of computing power will be that much cheaper.

8 BIT LIVES ON!

-Jesse

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

[iezhy]

moreover, they would consume less power, and this is VERY important in embeded systems

Re:Overkill

[Pxtl]

Good god, that rocks. So where's my 4" battery-operated DOS box? Aging gamers want to know!

Re:Overkill

[Doctor Memory]

Heh. Go lemmings, go!

Re:Overkill

[Anonymous Coward]

I would think that the 8 bit processor would take less die area and would be cheaper to manufacture.

They could be using a smaller feature size to give you the same die and power at 32 bits as you had for 8 bits. Still, that means a new 8 bits processor would be even better.

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

[Anonymous Coward]

Hint: 8-bit AVRs are still being sold by the truckload, and will continue to be for a long time. Don't think of these in terms of desktop processors.

Re:Overkill

[bsd4me]

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.

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

[Jason Hood]

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.


Actually this bring up a good point. There is a reason why the shuttle and many military aircraft still use 486s. 486 chips are rock solid, They can take far more Gs and a much wider operating temperature than pentiums can. Engineers would love to have the processing power, but they cannot afford to use a chip that craps out at 6Gs at extreme temps.

As for 486 Chips, I have washed mine in the washer, plugged it in 180 degress backwards until the smoke detector went off and had a 486 based computer fall off the back of a pickup and roll several times and it still worked. Try any of those feats of stoopidity with a modern processor.

Re:Overkill

[aldoman]

No, sorry, but that's a flawed assumtion. I'd guess it costs probably about $0.05 to produce the chip (max) and all the rest goes on transport and retailer markup.

Re:Overkill

[psetzer]

When designing something new, it's natural to want to improve it. One of the things that matters is adding new features or an easier to use UI. Really, a couple of LEDs and a dial may be enough for most applications, but a small LCD allows you to make things much easier.

For instance, I worked with an IBM robotic arm which had error lights on the control panel to tell you what was wrong. Each light was next to a two letter abbreviation or acronym. Sometimes some student would ask me why the robot wasn't working, and there was a light on the control panel. It would have made life ten times easier if the panel actually said that the arm was out of bounds, and they should manually reposition it to be within the working boundaries and turn the drive motors back on, rather than me having to tell them to do that every time.

Over time, when people replace the older robots and such from their factory, they switch to newer ones which tend to have more features, each of which needs more processing power. It may take time, but eventually 8-bit uCs are going to dissapear.

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

[Anonymous Coward]

Also, a lot of the cost of an embedded system isn't in the processor itself, but in the sockets they are plugged into, the memory and address busses which take up trace space on the circuit board -- if you can do a job with an 8 bit controller, it will be more expensive with a 16 bit one if you need twice as much real estate for intercomponent communication...

Re:Overkill

[Waffle Iron]

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.

That would be a wise move; the CPU market loves backwards compatibility. The latest Athlon-64s are still assembly-source compatible with the Intel 8008 from 1972.

Re:Overkill

[Anonymous Coward]

388 pin ball grid array?
can you say seven layer printed circuit board?

it's true that it does have peripherals (but no sram, flash, or eeprom?), but i have a VERY hard time calling something with that many pins a "microcontroller".

Re:Overkill

[AuMatar]

That kind of stuff doesn't have a CPU- its all custom ASICs.

Here's the layout on costs:

CPUs- most expensive, lowest development time for firmware. Good for quick mockups and revision 1.

FPGAs- still expensive but cheaper than CPUs, harder to develop on. Good for small runs

custom hardware- cheapest by far, can shave off dollars a unit. Large up front cost to produce the mask and long turn around time. Huge cost savings on large runs, if a 6 month lead isn't too high for you.

Something like a clapper has large volume, low complexity (easily done in pure hardware- its a mic that toggles a switch) and would barely change between revisions. Version 1 of it might be done via FPGA to get it out the door, but Version 2 and on would be done on custom hardware to slash costs.

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

[El]

Actually, "most consumer electronics" are already running 32-bit ARM processors, e.g. just about every cell phone and PDA currently sold. What are they still using 4-bit processors in?

Re:Overkill

[the chao goes mu]

Actually, it is not the memory holding data that the parent referred to, but the memory holding the instruction sets. 32 bit processors tend to take 32 bit instructions (OK, OK, CISC chips allow variable length instructions, but on 32-bit chips they still tend to average out larger than on 8-bit chips...) So, 32 bit chips would require more memory for the programs themselves.

Re:Overkill

[AndroidCat]

No problem! With all that extra processing power, just emulate the 8 bit CPU...

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

[SirTwitchALot]

I doubt a clapper is even that complicated. We're talking about 1980's technology... Though I've never seen the guts of one, I'd bet it's all analog.

Re:Overkill

[Anonymous Coward]

Note that the atmel avr mcu's use 16 bit instructions (with a few 32 bit instructions) and an 8-bit data bus, while the ARM7TDMI chips can run in ARM mode (32 bit instructions) or in thumb mode (16 bit instructions). Both arm modes have access to a 32 bit data bus. My experience has been that the AVR's have very high code density and IO operations are very fast. Toggling a pin on the avr running at N-MHz is almost as fast as toggling a pin on the an ARM running at (N*4)-MHz.

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

[Anonymous Coward]

How many PDA's and phones do you own?

Compare to how many dishwasher's, washing machines, electric cookers, TV's, wristwatches, remote controls, clock radios and so on do you own.....

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

[Rolo Tomasi]

I actually meant devices like washing machines, microwaves, etc. Cell phones and PDAs are multimedia devices, and I doubt that 512K Flash and 64K RAM would suffice for any current cell phone, let alone PDA.

The ARMs you're talking about are in a completely different league - the devices mentioned in the article have no provisions for external Flash or SDRAM, which you would need if you wanted more than the tiniest amount of memory.

Re:Overkill

[operagost]

Strap it to your pants instead and add cold grits.

Re:Overkill

[the morgawr]

Actually you can get simple micro's for as little as $.25 (FPGAs are more expensive then micro's) even in relatively small quantaties. Those ASICs arn't going to save you any money. Any production cost they save is outweighed by engineering costs.

Almost all new electronics designs start by seeing if you can do what you need to with a micro. Only if that doesn't work do you think of ASICs.

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

[frovingslosh]

You're absolutely correct. This article seems to claim that low prices on 32 bit cpu's will drive dedicated logic designers to abandon 8 bit cpu's. But even if CPU's were free (they almost are), other cost factors come in. A 32 bit processor is more complex; it generally needs more data lines (I'll ignore adress lines because a good design can usually work around this). It may also need more power and other complexity that a simple project just doesn't need.

Sure, if a dedicate imbedded processor needs an embedded Linux OS then a 32 bit system might be a good choice. But often 8 bit CPU's are used in simple systems (sometimes where they replace dedicated logic that would be more complex and more costly), and in many of the applications the 8 bit micro is more than enough. In such cases there is no reason to move to a 32 bit processor and complicate both the support logic and the coding needed to drive it, when an 8 or 12 bit solution is right for the task.

Re:Overkill

[AuMatar]

For small runs, maybe. Not for large runs. If you have 1M units over the product lifetime at .2 cents per unit, thats 200K. More than the engineering cost. Small to medium runs may favor the micros, large ones do not.

Re:Overkill

[Anonymous Coward]

the speed of the processor is only dependent on its clock speed, not the size of the word that it can handle.

Uhh, no.

Generally speaking, 32-bit CPUs also have 32-bit data paths, which mean that they move data from memory-to-register four times faster than an 8-bit cpu.

Re:Overkill

[the morgawr]

Given that the auto industry is moving AWAY from ASICs to save money, I'm somewhat sceptical of your claims. Perhaps the 2/10 of a cent is only under certain production cicumstances that don't hold for the automotive industry?

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

[AuMatar]

Bleh, I meant to say .2 dollars. My bad.

As already posted- the auto industry is moving away from ASICS because they want to be able to upgrade code on existing automobiles. If you need that type of ability, micros are the way to go. Most consumer electronics do not.

Re:Overkill

[Twisted Grind]

*PEDANTIC ALERT!*
Since when does $.002 (.2cents) * 1,000,000 = $200,000? Sounds more like $2,000 to me...

Re:Overkill

[HeyLaughingBoy]

there is no reason they should dissapear just because something more powerful comes along.

Sure there is: economy of scale. If Atmel can make a device that offers 32 bits at 8 bit prices, then more manufacturers will start using it because they can now do both 32 bit and 8 bit designs with the same part, resulting in a lower cost of inventory, lower design cost since more code and design is reusable and as 8 bits are relegated to only legacy designs, the volume of the 32 bitters rises and the price drops.

I just completed a design with an Atmel chip that used up all of about 100 bytes of Flash ROM. Would it have been a better design if the chip (a 90S1200 8-bitter) had been 32bits? Nope, but if they both cost the same I'd probably have gone with the bigger one just in case the design requirements changed later.

You're right: whiteboard time is expensive. Having chips with much greater resources makes design easier and thus cheaper.

Re:Overkill

[kps]

You might think you're joking, but the current HP graphing calculators use a 32-bit CPU (ARM) emulating the 4-bit CPU (Saturn) of earlier models.

Re:Overkill

[Anonymous Coward]

To bad I can not get the encryption and authentication upgrade for my microwave. "Emmbedded covers a lot of ground.

Re:Overkill

[Anonymous Coward]

No I think almost all of the 4bitters are gone.
Killed by the PIC most likley

Re:Overkill

[Anonymous Coward]

Was there ever an 8 bit ARM7?
I do not think there was. Pin compatable... No 8 bit chips have a low pin count.

Re:Overkill

[pommiekiwifruit]

And the ARM7 in this chip is backward compatible with what pray tell, apart from other ARMs? No doubt the peripherals and hardware has some shared heritage, but I don't think the software will be very 8 bit compatible.

Since most GameBoy Advance games use a lot of C , it has been shown to support higher level languages anyway.

From the net: "The world's first commercial RISC processor and first ARM processor, ARM1, yield working silicon the first time it was fabricated, in April 1985 at VLSI Technology. It bettered the stated design goals while using fewer than 25,000 transistors. These samples were fabricated using 3m process."

The whole point of RISC was to throw away the inefficient architecture inheirited from the 8 bit days and start afresh.

Re:Overkill

[bob beta]

There are billions of 4-bit controllers out there and many instances where even 8-bit parts are overkill.

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.

Re:Overkill

[letxa2000]

Killed by the PIC most likley

Don't be silly, PICs are for kids!

Seriously, PICs are used mostly in the hobbyist/student area. Certainly there are exceptions so no need to point them out, but the majority of the 8-bit embedded industry is run by the 8051 microcontroller. It killed 4-bit probably a decade before PIC even existed.

Re:Overkill

[letxa2000]

Ok, so as soon as everyone stops buying TV remote controls, microwave ovens, washing machines, dryers, keyless remote controls, motion detector systems for alarms, alarm clocks, little devices that turn your lights on and off at certain times, etc. etc. then the demand for 8-bit CPUs will shrink and they will exceed the cost of 32-bit CPUs.

In the meantime, don't expect the demand for 8-bit to dry up.

Re:Overkill

[sketerpot]

In the mean time, try DOSBox, a DOS emulator.

Re:Overkill

[OrangeTide]

Well the point is that for the same price as people are paying for Rabbit2000 Z80-ish microcontrollers you can get a more advanced controller that actually has better code density (ARMthumb ISA is hard to beat).

Of course an 8051 is still like 80 cents. so that 8-bit is going to be around for a long long time.

Really the number of bits a micro's bus and registers have isn't so important for small embedded application. It's the I/Os, the devel tools, availability, price and that it has enough ram/rom for your project. Atmel's arm and Philips 's ARM microcontroller lines have both been very inexpensive and powerful. New embedded designs are taking advantages of these parts all the time.

TI MSP430 is also gaining popularity, not because it's 16-bit (versus 8-bit) but because it's extremely low power and has versions that can control an LCD directly which can significantly reduce costs.

Re:Overkill

[Nutria]

Generally speaking, 32-bit CPUs also have 32-bit data paths, which mean that they move data from memory-to-register four times faster than an 8-bit cpu.

Not true!!!

Some examples:

• the MC68000 had a 16-bit data path
  
• the MC68008 had an 8-bit path
  
• the 80386SX also had a 16-bit data path

And besides: if you are only dealing with 8-bit or 16-bit entities, it is very wasteful to have those extra 24 or 16 data lines on the PCB.

Re:Overkill

[mnmn]

Exactly.

New appliations will appear for 8-bitters now. For how long can you run a 32-bit ARM MCU on a watch battery? I can imagine 0.9V computers running on watch batteries for days, think of the old handheld nintendo games with LCD screens, imagine them in creditcard size and running for months. Try that with 32-bit chips.

I've seen TCPIP being run on 8-bit chips and USB controllers on 8-bit MCUs with huge flash and sram space. So bit size isnt an indication of the complexity of a chip.

Re:Overkill

[Nutria]

The latest Athlon-64s are still assembly-source compatible with the Intel 8008 from 1972.

Hmmm. I'd want proof of that.

Back when (in the early 1980s) I was learning 8086 assembly, I do remember that Intel made the 8086 similar to the 8080 so that cross-assemblers would be easy to write, but the 8080 is not directly source compatible with the 8086.

Re:Overkill

[Nutria]

Ok, so as soon as everyone stops buying TV remote controls, microwave ovens, washing machines, dryers, keyless remote controls, motion detector systems for alarms, alarm clocks, little devices that turn your lights on and off at certain times

When these products start getting 802.11X, and thus connected to the internet, the 8-bit controllers will go.

Re:Overkill

[Nutria]

There is a reason why the shuttle and many military aircraft still use 486s. 486 chips are rock solid, They can take far more Gs and a much wider operating temperature than pentiums can.

Harris made radiation-hardened 80286 chips; I bet that someone is making radiation-hardened 40486s, too.

Pentium (and newer) chips have so many more transistors, and the etchings are soooooo small, that it's probably impossible to make R-H variants.

Re:Overkill

[Nutria]

But even if CPU's were free (they almost are), other cost factors come in. A 32 bit processor is more complex; it generally needs more data lines (I'll ignore adress lines because a good design can usually work around this).

This isn't necessarily true. The MC68008, for example, multiplexed address and data on an 8-bit bus. (It powered the Sinclair QL, by the way.)

Re:Overkill

[Spy der Mann]

Have you ever tried to program a 32-bit multiplication using 8-bit registers?

Believe me, you DON'T want to do it. I already had enough trying to do 16-bit operations for my microcontroller course. *shudders*

Re:Overkill

[Waffle Iron]

You couldn't assemble the sources directly, but Intel provided software tools to automatically convert assembly source code from 8008 -> 8080, and also from 8080 -> 8086. (Since the 8086, of course, they've maintained full binary compatibility.)

To support this, they designed the chips to be a close enough match so that the source code conversion could be done mechanically. It's a kludge, but it was probably a valuable checklist feature to get their existing customers to feel that their investment in code written for the old architecture wasn't being lost.

If you could track down the original Intel conversion tools, you could run a script to convert and assemble an 8008 source file to run on today's machines.

Re:Overkill

[Anonymous Coward]

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.

Impossible. If the size of the external bus changes (e.g. 8-bit 68008, 16-bit 68000, 32-bit 68020), the pinout changes. If the internal architecture changes from 8-bit to 32-bit, your software compatability goes away.

The chip in question (ARM) never had an 8-bit version. The 8-bit CPUs made by Atmel are either AVR or 8051-compatible.

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.

Errr...are you sure you know what you're talking about?

A 32-bit core implies that they're using a more modern process

Not at all. 32-bit CPUs have been around for a long time. Cheap 32-bit CPUs are new, though :)

Re:Overkill

[Anonymous Coward]

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.

Embedded systems typically use byte-wide static RAM chips, rather than memory modules. I believe Mr. Batman was refering to the fact that a CPU with a 32-bit external bus needs FOUR such chips, versus ONE RAM chip for an 8-bit CPU. That eats up a lot of room on the printed circuit board.

That said, there are 32-bit CPUs that can handle either 32-bit or 8-bit memory, though the 8-bit accesses are much slower. 486-based PCs usually had a single 8-bit BIOS ROM chip. One of the first things the BIOS would do after initializing the memory controller was to copy ("shadow") itself to the faster, 32-bit RAM.

Re:Overkill

[letxa2000]

8-bit microcontrollers can be connected to the Internet already . You can even run a website on an 8-bit 8051 and can do it with fewer and cheaper components and on a smaller board than any 32-bit CPU can.

Really, believe me. 8-bit MCUs aren't going anywhere. Even if people, for some weird reason, want their alarm clocks, washing machines, and toasters on the Internet.

Re:Overkill

[Anonymous Coward]

ARM7TDMI chips can run in ARM mode (32 bit instructions) or in thumb mode (16 bit instructions).

x86 has 16- and 32-bit modes, and mixing the two is a BIG PAIN IN THE ASS. How are things with the ARM?

I took a chunk of code from a TCP/IP stack and compiled it with GCC for ARM, 68000, MSP430, SuperH, and x86. The ARM object code was the biggest! Is this why they introduced Thumb; to get rid of this pure-RISC bloat?

Re:Overkill

[Anonymous Coward]

exactly if 32 bit processors drop down to 3 dollars a pop, that means 8 bit processors will be even cheaper!.

Re:Overkill

[bhtooefr]

WHAT?!?!? A full Pentium III equivalent PC on an SFF board can consume 30W... Your average lightbulb is 60W.

Re:Overkill

[Anonymous Coward]

Posting AC because this needs to get out there...

Thermostats use 'em...

Re:Overkill

[bhtooefr]

Whoa... I'm going to assume that the mobo didn't survive...

Also, if a Pentium were on a LARGER process, it could take overvolting more easily than it does now. Also, Intel doesn't make Pentiums anymore, but they do make 486s.

Re:Overkill

[bhtooefr]

Checking the Intel site for info on the 486, I just proved myself wrong... They're making ALL of their old x86 CPUs for the embedded market, except for the 808x (the 186 is better, and more targetted towards embedded) and the 286 (the 186 does almost everything the 286 did, and if you need the features that the 286 added, go to the 386), and the Pentium Pro (go to the Pentium II for P6). They even have Xeons, for crying out loud!

Still, what I think is more interesting is the AMD Elan SC520. AMD 486 CPU (don't dare call it 5x86 - that's just a 4x multiplier) and PCI chipset all in one. If Intel would put a 266MHz PMMX (they've got them) and an i430TX on one die (even in one package would work), they'd have it made, especially on .13 or even .09. Something interesting that I saw, though - most of their embedded Pentiums were 296-pins - can you say Socket 5 (296 or 320 pins - Socket 7 is 321)? A PMMX on Socket 5 would be awesome for upgraders...

Re:Overkill

[AndroidCat]

Half serious, half joking. It sounds silly, but it makes sense sometimes. (4 bit graphing calculators? I remember when HP had 16 bit CPUs. Okay, not a single chip.)

Re:Overkill

[Nutria]

8-bit microcontrollers can be connected to the Internet already

And they can do the encryption needed for wireless?

Re:Overkill

[Nutria]

To support this, they designed the chips to be a close enough match so that the source code conversion could be done mechanically.

I think that's pretty much what I said.

If you could track down the original Intel conversion tools, you could run a script to convert and assemble an 8008 source file to run on today's machines.

Yes. If you could find similar hardware and OS.

BTW, this is how MicroPro got CP/M WordStar to run under MS-DOS 1.0. Remember that MS-DOS 1.0 bore a strong internal resemblance to CP/M.

Re:Overkill

[letxa2000]

And they can do the encryption needed for wireless?

Certain levels of encryption can be done with an 8-bit MCU but time-critical encryption for wireless transmission is usually handled by external chipsets.

Again, I'm not sure what kind of toaster, alarm clock, etc. is going to need to run a website over an encrypted wireless link. But whatever. Apparently you're a potential customer. :)

Re:Overkill

[drinkypoo]

Atmel is a popular provider of microcontrollers and having a 32 bit design lets you handle larger data types much easier than 8 bit. Many designs would benefit from the higher granularity that even 16 bit resolution would provide, and a 16 or 32 bit chip will be able to do that sort of math much more rapidly. 8 bit will eventually disappear just because it won't be any cheaper than 32 bit, not because there's anything particularly wrong with it. You'll only see 8 bit cores embedded so far that you can't even interface with them any more, though eventually you realize 32 bit will go the same way, yes?

Re:Overkill

[drinkypoo]

This isn't really true. A/C and Airbags are still 8 bit - assuming they're electronic at all, which they frankly don't need to be in most situations. Airbags are more about sensors than anything else and you can accomplish everything you need to accomplish with them using relays; They don't use relays because transistors are more reliable but there's no need whatsoever for them to actually contain a processor, ditto for non-automatic air conditioning, which ALSO doesn't need a processor but does benefit from having one.

My 1989 Nissan has a 6803 in it, which is an 8 bit core, but most modern ECUs have 16 or 32 bit microcontrollers in them, many of them utterly custom. For example the late model Ford Taurus has an (I believe) 16 bit core in its microcontroller, which was developed by Silicon Engineering in Scotts Valley, CA (Now part of Creative Labs.) At least, I think it was the Taurus, I don't remember the shape of the paperweight the core was embedded in, but it sat on the desk of the lead designer on that program, who was one of my users.

This is because automotive computers have increasingly required inter-computer communications, what in the trade is called electronic to electronic and categorized as an actuator even if it's a bidirectional bus. ECUs either control the automatic transmission themselves, which itself sometimes has some logic in it now, or talk to a separate computer which does the job. ABS is used for traction control. High-end Subarus even have an electronically controlled variable center differential which is also used for the traction control. Most nw domestic cars have a body control module (BCM) which handles all of your lighting and such, including fading dome lights off and whatnot. Typically all of these computers talk to one another if for no reason other than to generate trouble codes, and allow you to diagnose every sensor and actuator in the car from a single scan tool, plugged into the ECU/diagnostic connector.

Cool

[GR1NCH]

I dont know enough about electrical engineering to know what kind of changes cheap 32-bit processors will bring to the market, but I'm anxious to find out!

Re:Cool

[Anonymous Coward]

so what exactly have you added to the conversation by stating this?

and what exactly have i added to the conversation by pointing this out?

Re:Cool

[cloudreader]

probably GR1NCH, you and me have wasted a couple of kilobytes of hd. We may also be wasting 15 seconds of atleast 30% of ./ers (those who read all the posts)

And so it begins

[nizo]

Now we are one step closer to every single electronic device made in the future being web-enabled! Who wouldn't want their microwave oven to have its own built-in web server?

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.

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.

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.

Re:And so it begins

[nizo]

Well, I was kind of kidding in my post about the whole "web enable every freakin' thing", but I could actually see some interesting uses for some appliances to be web enabled:

- 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 have seen some like this already, not sure how they get updated for new food items).

Plenty more I am sure, but I have to admit I am a little leary of having my appliances accessible from outside my house, for both security and marketing reasons. For example, do I want the company that makes my microwave to know how many microwaved pizzas I eat a week? (I might be getting offers for "1st week free" at the local gyms however). How about my insurance company? It is my God-given right as an American to eat all the fat-filled food I want and not have my premiums go up!

Re:And so it begins

[phyruxus]

I know I want my VCR to flash "1337" instead of "1200", and my radio to switch from NPR to Rush Limbaugh against my wishes. I know I want my air conditioner to go from cold to hot in the middle of the night. So I'll make sure I look for the "powered by microsoft" sticker when I buy all these things.

Oh yeah... and I want my roomba to spell "pwned!" in my shag rug :)

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:And so it begins

[jasonshortphd]

Wooh! Now I can burn microwave popcorn from my office down the hall and have the microwave tell me before I smell it!

Re:And so it begins

[Anonymous Coward]

Damn your lazy ass,
You will ruin us all!!!!

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.

Re:And so it begins

[Anonymous Coward]

even better, who wants to have hackers/worms/virus writer be able to remotely hack you house!

Re:And so it begins

[Rakshasa Taisab]

I've written firmware to control your AC by SMS messages. This was on 8bit chips with a GSM terminal connected through RS232 cable. There's no need for 32 bit chip to get this functionality. What is lacking is a way to cheaply connect wirelessly to a central computer. (You really don't want the ability to control them directly from remote locations;)

Doubt every applicances will have WiFi or ethernet in the near future, the components cost to much.

Re:And so it begins

[kisielk]

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

Re:And so it begins

[Doesn't_Comment_Code]

At the time of this posting, the parent is modded Funny. But it's true! I've been looking into making small devices that I can communicate with via ethernet. And to do that, I need to impliment a tcp/ip stack on a microcontroller.

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 need to really get our hands dirty.

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:And so it begins

[Ziviyr]

It would be cool to go to the kitchen, start making breakfast, then come back to the computer and see a bunch of progress bars, for the toaster and the microwave, etc. blah percent complete, blah remaining.

Re:And so it begins

[XMyth]

I have an idea....maybe you shouldn't use it?

Wait nevermind, that's stupid.

Re:And so it begins

[Oliver Wendell Jones]

I thought I implied in my message that I don't want to use it.

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

[Anonymous Coward]

Such small minds.

Who about who wants to go on vacation and be able to double check that your iron is turned off.

Who wants to be able to be notified that your hot water heater has a short in it and is using twice the energy it should be.

Maybe program your water heater to turn off for that 1 week vacation and turn back on a few hours before you get back. Then you could analyze if you save more money by only running the water heater part of the day or keep it running all the time.

Who would like to get a notification when one of your outside lights burn out, instead of finding out by kicking one of the stops when you come home late.

You might want to put a notification (or lock down) on your refrigerator that you kids might have turned it up to extra high (frozen lettuce) or turned the freezer down too low (soft ice cream)

There are tons of uses which have nothing to do with 'web server in my microwave' or 'script kiddies have taken over my blow dryer'.

Re:And so it begins

[beebware]

As a father of six, I know I would never preheat the oven without first looking inside.

BTW: He was a father of seven before he realised this.

Re:And so it begins

[aminorex]

So your oven needs a webcam.

Re:And so it begins

[asdfghjklqwertyuiop]

Who wants to worry about someone hacking their DVR and deleting all their recordings? Who wants to worry about someone getting their credit card number after entering it into a fake website? Who wants to worry about someone hacking their cellphone via bluetooth and installing a porn dialer? Who wants to worry about their bank website username & password being copied from their PC?

Oh...wait... lots of people apparently.

I guess this security thing is doable after all.

Re:And so it begins

[mr.mighty]

Mmmm... network-enabled 32-bit burritos!

Re:And so it begins

[aliens]

Does this mean the burrito has a chip in it too?

Re:And so it begins

[hey!]

Trust me. Every generation exceeds the prior in technical adeptness. For your parents' generation, it was the blinking twelve. For us, it will be the security protocol to open the oven door.

Re:And so it begins

[bhsx]

Or a webcam in your oven? and in your bathroom?
ewwwwwewewew
Wait a second there...

Re:And so it begins

[Mordaximus]

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.

Excellent, and what a coincidence! I was thinking I would like to turn your oven on broil for the day while you're at work, shut off your heat while you're sleeping on the most bitter day in winter, and maybe screw with your lighting for the fun of it. All from my office in another country.

Some things really are best off simple, and disconnected.

Re:And so it begins

[Anonymous Coward]

Yeah, I saw them in Sears a few weeks ago. I was like WTF?! But y'know, if your recipies required chilling before baking (some doughs needs to be kept at a certain temperature before baking), it would be a godsend, because it means you don't have to baby it for all day. Hell'a conveniant, if you're a bake often, I guess. Very good idea.

Re:And so it begins

[iwadasn]

Timers are pretty useful though. My apartment is small, but my AC is smaller. It's nice to be able to set it to come on at 3:00 in order to have the apartment cool by 7:00 when I get home. Saves power, makes it easier on me, what's not to like.

As for TVs though, I got a TV tuner for my computer and never looked back. It's like a TV/Tivo/CableBox/DvdPlayer/Computer all in one, and it takes up less space than all those gadgets together, and is surely cheaper. My stereo met the same fate, it is now my computer's job to play music.

A lot of simple gadgets will meet their end at the hands of the general purpose computer. There is no need to put a web browser in a TV/Fridge/Toaster. If there is something that needs to be browsed, let the computer do it, if not, save your effort.

Re:And so it begins

[bob beta]

And to do that, I need to impliment a tcp/ip stack on a microcontroller.

No microcontroller I know of has ethernet built into it. You're going to need an ethernet module of some sort. Why not put the complexity of the networking right in the ethernet module? Surely that's a suitable place for that stuff, and you can just talk to the world through a serial or parallel link from the controller.

Re:And so it begins

[statusbar]

Oliver is a Luddite! What is he doing here? Burn him!!!

haha seriously, I agree with you, but unfortunately most people don't understand and will just accept the potential privacy and security problems and will probably not even use the fancy web-enabled features of their toaster after a few days.

A bigger problem for people will be the inherent un-future-proof in most of this stuff. Your web-enabled appliances will need security and bug fix updates and most people will apply them as often as they apply their updates to windows.

--jeff++

--jeff++

Re:And so it begins

[TheRagingTowel]

Buddy, it can be done even today with 8bit MCUs. Heck, I'm building one just now with an 8bit MCU from ATMEL which has much less features than this 32bit MCU. It's working - I can call from my mobile to the device and it'll turn on and off my bioler using 433MHz RF link.

Re:And so it begins

[winwar]

"It would be unfortunate if an action figure, or worse the cat, were to meet an early demise."

Mmmmmmm, cat, the other, other, white meat....

It would also solve the problem of "what's for dinner tonight".... :)

Re:And so it begins

[upsidedown_duck]

Would be good to know if your frozen burrito has cooked or needs another minute.

The ultimate paradox: could God use his web-enabled Java Microwave System (based on Debian, this time) to microwave a burrito so hot that he himself could not eat it?

Re:And so it begins

[rthille]

So that's what I need to get rid of the cat? 6 children. I guess I'll just stick with the cat...

MC68000 cluster computing?

[tty21]

Let's see now - 3$ X 50 and some 10$ cases = watch out Mr. Dell!! Does cLinux do X windows?

Re:MC68000 cluster computing?

[Timesprout]

Dell are safe for the moment. Its 3$ x 10000 and some 10$ cases and no one has actually run uCLinux on one yet.

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

[sl3xd]

Mod parent up. Just because some punk AC that has never done a line of embedded coding in his life says something doesn't make it so.

The 4-bit MCU isn't seeing any real decline either.

The fact that you can get a cheap 32-bit doesn't mean squat; it still uses more power (extremely important, espescially with battery-powered devices), requires more memory, requires more complex circuitry and costs significantly more than an 8-bit (and 4-bit) MCU's.

I don't see a need for a microwave oven with a 32-bit processor.

What it comes down to is that (in general) a low-bit MCU costs less, but usually requires development in assembly (or rather expensive dev tools). A 32-bit MCU frequently has cheap C compiler.

When you're making a few million items, the economics are sharply in favor if the cheaper 8- and 4-bit MCU's if it's able to do the job (lower-level programming notwithstanding).

When you're only making a few thousand, then a more powerful MCU makes more sense (mainly because of easier/cheaper programming) offsets the higher unit price.

But you're still not going to get the power use that you achieve with a 8 or 4-bit MCU ('new' tech notwithstanding, more transistors=more power). Battery capacity is fairly close to being limited by physics (many estimate maybe a doubling in power density, and that'll be about it). Fuel cells have issues as well.

Re:Not the death, but certainly less market

[squidwanker]

You obviously have no idea about the controller market. Don't bother posting if you're so ignorant.

Re:Not the death, but certainly less market

[pla]

I apologize for picking nits (I largely agree with you)...

But...


Battery capacity is fairly close to being limited by physics (many estimate maybe a doubling in power density, and that'll be about it).

A "High capacity" NiMH AA Battery holds 2300mAh (which at 1.2V means 1.92 Watt-hours).

A Typical NiMH AA battery weighs roughly an ounce (the 27 currently in my "charged" pile weigh an average of 28.5g each).

Octane yields 44811.1 Joules per gram, and one Joule equals 0.0002778 Watt-hour.

So... 28.5 grams of octane, on complete combustion, yields a bit under 1.28MJ, or 354.8 Watt-hours.

Thus, a perfectly efficient fuel cell running on octane could store 185.1 times as much energy as an equivalent NiMH battery.

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:Not the death, but certainly less market

[pla]

They might have a 32 KHz CPU clock and draw a fraction of a microampere most of the time.

Based on your concluding comment, I will take it you meant your entire response as tongue-in-cheek.

If, however, you meant that seriously, and don't refer to a uC that spends spends "most of the time" not even turned on, I would love to hear a part number for such a device...

Re:Not the death, but certainly less market

[Anonymous Coward]

I obviously have no idea of and have never written a line of code for a controller? Pu-lease. News flash, your printer, Aibo, and BMW don't have 6502s anymore.

Of course your microwave and pacemaker might not need any more performance, but Z80s aren't driving the industry anymore. They are simply the old standbys for small-time service. The definition of "small time" is what has been shrinking. Doubly so when you start involving signal processing or larger data rates. You can google around for stats on this, like this one:
http://www.techonline.com/community/tech_gro up/369 30?print

There's a good reason MIPS16 was invented, and that ARM, ARC, Tensilica, and others are growing while Zilog stagnates.

Re:Not the death, but certainly less market

[bob beta]

Depends on what you mean by 'not turned on.'

Many designs take an embedded hardware clock that will run in standby mode, and wake the chip up, say, every few seconds.

I know it is possible with the NEC 75000 series parts, which probably have morphed into some other product line since I worked with it. We set it up that way and the bosses demanded a lot of tweaking and adjustment to get 'quiescent' current down to the minimum possible.

A sure way to get moded down

[Anonymous Coward]

is to mention Beofwulf clusters BUT at $3 a pop you could have a 10,000 node cluster for $30k. It may even be able to OpenOffice. 64k * 10,000 = 640MB of ram which means it may even be able to run OpenOffice!

Misleading Summary

[OverlordQ]

Priced as low as $3 apiece in quantities of 10,000

That's a bit different then a flat $3 rate.

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

[OverlordQ]

I was meaning misleading to the majority of slashdot readers who think they'll be able to pickup like 10-20 for $3 and make a cluster of something.

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.

Re:Misleading Summary

[Anonymous Coward]

You don't have to have somebody build the PCB for you. It's quite straight forward and extremely cheap to etch one's own single-layer PCB; and a single-layer board is generally sufficient for Atmel processors. Thus, I agree with the original poster about the annoyance of these processors being sold only in large quantities. With any luck, however, some company will end up reselling them to hobbyists, in much smaller quantities, without increasing the price too much.

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?

Re:Enough already!

[Anonymous Coward]

modding their Amigas to be a multimedia console

Kids, THAT is what hacking is all about.

Re:Enough already!

[roskakori]

Hence the stories of people [...] modding their Amigas to be a multimedia console

You don't have to mod an Amiga to be a multimedia console. That was the whole idea behind it from the beginning.

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.

[Ironsides]

8-Bit MCUs may be under $1 in large volume but they don't have large ammounts of RAM and FLASH and also don't have a D/A Converter and PWM built into them. These things are cheap when compared to Motorola Processors and will give them a run for their money. The Motorolla 16 bit series are $15-$25 and teh 8 bit ones aren't much better. I think that once people start building developement boards for these Motorolla is gonna be in trouble.

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.

[Anonymous Coward]

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.

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

[Anonymous Coward]

Cost isn't the only problem. Battery life is *always* a problem. Since these processors use much more power, you won't see them in any portable device unless absolutely necessary.

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

[chrysrobyn]

For low-end applications, 32-bit doesn't make sense, especially if its going to add $1 to the cost of manufacture.

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 what you're doing, that might reduce your time to market.

Back when Computer Shopper was basically 1000 pages of ads ("Yeah, honey, I buy this for the articles!" *chuckle*), you could see 386 processors costing more than 486s and even Pentiums simply because the market was so small. When you can no longer keeping an entire production line open, you have to re-open for small production runs, driving up costs.

Perhaps the 8 bit microcontroller will not forever be the obvious choice for your application. Heck, you may enjoy the extra elbow room too.

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

[pommiekiwifruit]

MC68HC000FN8R2 costs $3.08 - hardly $15, although more expensive than taiwanese chips of similar power (and more peripherals).

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.

[Anonymous Coward]

But why program in assembler when you can use Visual Basic!

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.

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

[stienman]

For low-end applications, 32-bit doesn't make sense, especially if its going to add $1 to the cost of manufacture.

For low end applications, even $0.01 difference can add up to hundreds of thousands of dollars.

-Adam

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.

Re:Wrong..

[chipace]

Newer process 32bit microcontrollers could easily consume less power. All that needs to happen for the market to shift is one major player to offer new features powered by their 32bit adoption.

When the choice is 32bits or a sudden loss of sales, most companies will make the change.

I see the best part of 32bit microcontrollers is the increased addressing capability. They can use the wide ALU to process addresses.

Even if native data is 8bits, crunching it is inefficient, but moving it just got 4 times faster per cycle.

Re:Wrong..

[Anonymous Coward]

Newer process 32bit microcontrollers could easily consume less power

No, they couldn't. An ARM7 is about 130,000 gates. An 8051 is about 10,000 gates. For any given process and clock speed, the ARM is going to eat more power than the 8051.

It's not a matter of using a chip manufactured fifteen years ago versus a modern one. The design may be old, but the MCU cores themselves can be as new and trendy as a process gets when they're embedded into the latest ASIC. These things aren't used as discrete parts in many volume applications.

Re:Wrong..

[tepples]

True, but how does 130,000 gates compare to all the rest of the stuff on an ASIC?

Re:Sure they're cheap, but there's more that matte

[geomon]

OK, you *can* put a web browser in your gas pump, but should you? Having seen BP's implementation, I would say not.

Do they use a Schlumberger system?

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:FOIST POWST

[Anonymous Coward]

YOU FAIL IT. With the new "Nothing to see here" crap, getting FP is easier than ever, and yet you STILL fail it. Dumbass.

Reliability

[millahtime]

So, those cheap 8-bit processors are pretty reliable. But will the similar price 32-bit be the same for that same cheap price?

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

[faragon]

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.

Re:Reliability

[cmowire]

Actually, the whole *point* of this particular new line of ARM chips is that they become as integrated as your average AVR processor, with all of the usual trappings. There isn't any external memory or peripheral bus. 48-64 pins is the high-end of the AVR pin-count.

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 then used so that you have an easier time building the software.

And that's nothing to sneeze at. There's a definate potential to replace external parts with more software logic. Like moving the power conversion/battery control logic onto the chip instead of having it external.

There's the definate potential if you can get a 32-bit Atmel ARM for the same price as a PIC or AVR for people to pick the ARM and squeeze more functionality in, even if all it means is that the system has self-diagnostics that it wouldn't otherwise or is written in C instead of Assembler and uses a real embedded OS instead of a few handy subroutines.

The big thing is that Atmel is going after Microchip's PIC processors. I'd view it as a coup for them. The ARM is a "real" embedded processor that Atmel has been working with for a while. This is an act that it will be harder for Microchip to follow.

Translation

[Anonymous Coward]

An anonymous reader = MARKETROID

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

Not so fast young astros

[Anonymous Coward]

Has anyone checked the instruction processing time and I/O reaction times for this processor? What about core features? 8 bit simplicity will be there as long as tasks need to happen very very quickly.

Re:Not so fast young astros

[antispam_ben]

If I read TFA correctly, this is a version of the ARM processor, which is RISC, and though I'm not familiar with it, it should have fast, fixed interrupt response times. Predictable and low interrupt latency is absolutely the thing that small microcontrollers and DSP's have over the large, general-purpose CISC processors that take variable numbers of clock cycles for executing each of the different instructions in their pipelines, making interrupt response time a lottery.

Re:7UP Plus

[Anonymous Coward]

Isn't that just a Sprite Remix ripoff?

Predictable troll

[Anonymous Coward]

*praises Firefox's "hover and display URL" feature*

Re:Predictable troll

[Tenareth]

I love Firefox and use it, but uhm... every browser for the past 5 years has had that, or don't you know how to enable the status bar?

Has been the case for a few years

[kbahey]

There are already a bunch of those in the market, and has been so for a few years. For example the ZFx86 is available, and some manufacturers do base SBCs and PC/104s on it, such as Tri-M's MZ104+.

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

[azmodean]

This isn't nearly as revolutionary as the poster made it seem; also 32-bit processors won't "steal" applications from 8-bit. It's more like applications and features that have been on the back burner due to hardware cost might see some light now.
Frankly, I'm much more excited about the nuclear battery article a week or so ago, I think power is much more of a bottleneck in embedded systems than processor cost anyway.

Re:Has been the case for a few years

[kbahey]

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.

Not just "Power"

[temojen]

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 of memory, and some models are fairly zippy (for a uControler).

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.

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.

Re:Not just "Power"

[Lumpy]

TQFP package is not quite as hobyist-hackable as the old DIP packages

I disagree I LOVE TQFP and other legged surface mount for hobbiest work.

what absolutely sucks is the new BGA crap. nothing but solder balls under the chip making it impossible for a hobbiest to use these things outside of gluing it upside down on the board and running seperate wires from each blob.

BGA sucks and has no real value, no matter what any EE tells you.

Re:Not just "Power"

[LordByronStyrofoam]

Actually, the AVR line, from 4414 up, provides for adding external RAM.

Re:Not just "Power"

[iabervon]

Chances are that they'll have DIP packages as well, because most companies that use etched PCBs tend to do early prototypes or test things with good old breadboards (or the AVR development kit). Of course, the TQFP version is what they expect people to buy in quantity and use in real applications.

The large AVRs actually do have support for external memory. On the other hand, you can only have execute code in flash, not internal or external memory on them. And there's no reason you need a specially-designated address bus; there's support for a lot of pins you just control, plus i2c and various other things. Sure, the load instruction won't automatically pull in data from external RAM, but you can handle it like swap.

The hobyist?

[Gyorg_Lavode]

How does this effect the hobyist? I know Parallax stamp chips are wonderful for small projects. They have compilers on board, they are VERY simple to interface hardware with, etc. Can these 32bit offerings provide the same type of DIY play? I hope so as it would allow complex designs for little money from home-users.

Re:The hobyist?

[jotux]

When anyone buys a basic stamp, your paying for curriculum. Compared to even a slow avr(or pic for that matter, even though the basic stamp is based off the pic 16 series-I think) the basic stamp has no where near the speed or operational capabilities. If anyone is looking for hobby projects for little money, the first place I would send them is toward an 8-bit microcontroller. Compare the price of a single basic stamp($50) that can preform 4k operations/sec to a sub $1 avr that can do 8M operations/second...the only problem is there isn't a curriculum for beginners to get people started with the avrs. And it's not that they are that much harder to use, you can natively program them in C, but there are software packages that allow you to program them in BASIC. As far as hardware interfacing it is the same as the basic stamp, but you actually have to figure it out on your own instead of reading instructions out of a book. As I said, when you buy a basic stamp your buying curriculum...not performance that can even be compared to avrs/pics...ect.

Re:The hobyist?

[Gyorg_Lavode]

I agree. I think it is a fair tradeoff in most cases anyway. most hobbiests see the microcontroller as a means to an end and want to only learn about it in the context of their project.

That said, are there good free compilers and beginners kits (interface boards, beginner documentation, etc), for simple pic's or avr's?

Re:The hobyist?

[madcow_ucsb]

You can get gcc for AVRs and Atmel has their own compiler as well. There are also a couple commerical ones available.

I did some work with the ATMega128 a couple years back. Used an STK500/STK501 eval board to get started. Easy enough. Nothing scary in the board design. The datasheet tells you what you need to do (in terms of required passives, crystal, etc.) Just make sure to get the in-circuit programming stuff on there so you can modify the flash when it's on the board. And if you haven't done anything before, remember: headers are your friends. You'll probably screw *something* up and it's really nice to be able to probe things and have posts ready to wrap to when you need to bust out the blue wires. My first board (mp3 player, school project) looked like a porcupine with all the headers. And good thing, too, cuz we made some *really* stupid mistakes.

Never had a chance to use PICs (used AVRs as a hobbiest and more 32-bit DSPs at work...and I'm really a firmware guy so I don't get much input in the board designs anyway)

Re:The hobyist?

[Doppler00]

This effects the hobyist in no way. For one, about 95% (or more?) of all MCU are now surface mount components, meaning they are insanely difficult to solder yourself.

You are better off to buy a board that already has the MCU, some I/O terminals, display, etc. already attached. You'll probably pay about $50 or so for such a kit. The fact that the MCU is only a $3 component is pretty irrelevant unless you are buying these things in mass quantities.

For myself, I'm looking for a company that build a custom PCB AND do the necessary soldering of the surface mount components. I'd be willing to pay a couple hundred $$$ for a project I have in mind. Then I can spend my time writing the microcode for it, as it's not worth my time soldering microscopic components.

Re:The hobyist?

[Anonymous Coward]

"surface mount components, meaning they are insanely difficult to solder yourself."

Who are you, Don Lancaster? There's nothing difficult in soldering a SOIC or even a flatpack. You just need a good iron, thin solder, some flux and decent hands and vision.

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

[Jeffrey Baker]

Agreed. When using the AVR I frequently wish I had more serial ports, more interrupt pins, more ADCs, more DACs, and maybe a hardware quadrature implementation, but I never though to myself "Gee this would be so much better if I had 32 bit words!" I'm sure there's applications for this out there, but at the present time I'm not thinking of putting Linux on my oscilloscope.

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

[amigabill]

I hope so. I work at Atmel, and the product line I'm involved with has an AVR 8-bit micro in it... :p

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

[haggar]

the product line I'm involved with has an AVR 8-bit micro in it...

Let me guess... FPSLIC? If you d in the FPSLIC product line, I would have a few questions for you.

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

[Anonymous Coward]

As for Linux on your oscilloscope can't see why not. You probably already can get it:-) Was on a demo a few years back(2-3) and saw demo of a new Agilent (formerly HP) oscilloscope was running a cutdown version of win95 or 98. The salesrep. who demoed it told of one customer who thrashed the install on theirs as some of the techs tried installing Word on the damn thing:-)

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:AVR line has still a lot of life in it

[amigabill]

Uhm... No comment. I didn't do it. I wasn't even there!! No, really, officer!

Really, I'm not sure how much I can answer anyway, I'm mostly just a layout/design flow guy. wtoner @ "that company's name" dot com.

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

[Kiryat Malachi]

We have some Windows-based Tektronix scopes at work. They're kind of annoying, actually; I still use the old HP 2 channel + 16 channel logic analyzer scope whenever its open.

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

[Anonymous Coward]

ATtiny2313: at 20 MHz, that part produces almost 20 MIPS...
The PIC MCUs have about the 1/8th to 1/10th of this performance

The PIC 16F87X tops out at 10 Mhz, delivering 5 MIPs. The 18FX52 tops out at 40 MHz, delivering 10 MIPs. Be accurate. In addition, the hardware multiply on the 18FX52 parts has allowed me to do traditional DSP stuff on these: how about 256 point FFTs in 50 millisecs? I've been comparing AVR and PIC for a while now and I always end up with the PIC in a new design.

Now, that being said, I agree with you: I don't see either the AVR or PIC cores disapearing because of these 32-bit controllers.

Java

[Anonymous Coward]

I heard that a language named JAVA will make this possible.

better penetration of high performance systems

[Anonymous Coward]

The poster mentioning all the existing reasons (especially price) for keeping with 8-bit and 16-bit CPUs was dead on. Embedded is very price sensitive.

However, what this will mean is more low-cost, high-performance products. Think of that toy that should be interactive and maybe run Linux. How about that smart sales display? Could that pump controller now keep stats and be web-enabled? Could you use this with your HVAC (would be nice to control from your intranet and change via a secure link while on the road).

Linux is in a GREAT position to take advantage of this, especially uCLinux.

Re:FOIST POWST

[Anonymous Coward]

TROLL ALERT

What does uC mean?

[Anonymous Coward]

If the "u" stands for micro, what's the "C"? I've looked around but can't seem to find it.

Re:What does uC mean?

[Anonymous Coward]

If the "u" stands for micro, what's the "C"? I've looked around but can't seem to find it.

"Mu" stands for "micro", and the "C" is for "controller".

ref: http://www.uclinux.org/

which begs the question, "where exactly were you looking?!?!?!?

Not really

[Saeed al-Sahaf]

Misleading? No...

"...as low as..." implys that there are other, higher prices.

offtopic

[Revek]

does anybody here every order from tiger direct

Re:offtopic

[genner]

Yes, Yes I do.

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:About the OS

[amigabill]

Nah, it looks more like how someone with a stuffy nose would pronounce his request for "a kleenex".

Re:About the OS

[Anonymous Coward]

If it looks like a dirty word to you, maybe you should get your woman to wash.

Re:About the OS

[clueless_penguin]

But seriously folks, has anyone tried this out on anything? I need to hear someone who's used it on Slashdot.

uClinux has been around for many years. It merely provides patches for running linux without an mmu. Because linux is organized by architecture, this just adds a few more architectures to standard linux. It also packages a bunch of applications in a way that is convenient for embedded development.

Re:About the OS

[nchip]

Anyone using any of the Kiss Technology DivX/DVD players. These and all other Sigma Designs reference platforms based DVD/DivX players run uCLinux. So there are lots of people watching DVD's at their home who have no idea that their DVD player is running uCLinux. There is nothing "amazing" about uClinux, It's just Linux running on CPU's without MMU. ...And without MMU, any application can crash the system. Therefore you have to write every app as carefully as you would write a kernel module.

Not practical for Linux...

[Spoing]

Read the article. The total amount memory (flash + RAM) is well below 1MB -- and that is on the largest and most expensive chip in the series . That little memory can not be expanded.

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.

Keep It Simple, Stanley.

[RealProgrammer]

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.

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? IP stacks work better with 32 bits. Add a serial port, and your toaster alarm could control your UPS.

Anything where there's already a high level of complexity in the application can benefit from something like this.

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

DVD MP3 player for the car.

[ahfoo]

I thought this part sounded rather cool:

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 solder job would be cool. Besides, by the time DVD car MP3 players are cheap, the same design could probably be used for the Blu-Ray MP3 player.
They say it has USB2.0 already. So looks like a half-height DVD with a power supply in a USB case would get you pretty close. How do you get the sound out to an amp though?

Re:DVD MP3 player for the car.

[Anonymous Coward]

That would be okay if it was easy enough which is doubtful. On the other hand, you could get a ViaEPIA5000 for about a hundred bucks that would give you the same features and the ability to do MPEG2 video and a full featured OS. Gotta have a keyboard and mouse in the car. With an LCD in the car, you have a car computer. That's getting pricey, but it would give you so many more options. Then again, less options is not such a bad thing in a car.

Re:DVD MP3 player for the car.

[R4quez]

What I would be more interested in is a DIY ogg-vorbis player for in my car. That would be something I would be willing to put my time and effort into...

Re:Sure they're cheap, but there's more that matte

[sexylicious]

what would 32-bits buy you?

Those 32 bits offer higher precision for certain applications. (Data logging, robotics, autonymous vehicles, remote sensing, etc.)

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:7UP Plus

[Anonymous Coward]

This is so off topic that it's great. I made a pork and shrimp based Ch-Han last night, with some ginger/lime marinated grilled shrimp. Oh man that was so good.

The milk they buy at my job (Hood Brand) has a full day's supply of vitamin C! What the hell is that? What is milk doing with a full day's supply of vitamin C?

Hardly 8-bit price

[pommiekiwifruit]

I am using 16 bit chips (with cpu, audio, video, ADC, RAM, etc. on chip) which cost $1.30 or so; there would really have to be a compelling argument to buy something for over twice the price.

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.

I, for one...

[Discotechnica]

I, for one, welcome our new 32-bit microcontroller overlords.

Re:I, for one...

[Discotechnica]

err: I, for one, welcome our new cheap 32-bit microcontroller overlords

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:Clue alert: $3 in volume is EXPENSIVE

[Anonymous Coward]

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

How much volume do I have to purchase to get the price down to 0? Infinity?

Imagine an infinite... oh nevermind.

:)

Re:Clue alert: $3 in volume is EXPENSIVE

[coppice]

Damn right. $3 is the top end of the 8 bit price range, and for that you get a real system on chip, with complex peripherals taking a large part of the silicon area - LCD controller, high performance ADC, powerful timers, multiple serial ports, etc. Atmel isn't the first to do this. Several others already have similar devices. An ARM core, 64K/128K flash, some RAM, but very limited peripherals. They are all in the $3-$4 range for similar features. When you load it with peripherals the price can rise quite a bit. Consider power consumption. ARMs are famous for their power efficiency, but many 8 (and 16) bit devices beat them by a large margin for simple applications. A lot of 8 and 16 bitters go into battery powered applications. Power consumption really matters there. The 4 bit market isn't so big there days. 8 bit devices go down to 25 cents these days, PICs included.

It's called the Polara

[LordKronos]

http://polara.whirlpool.com/

And you don't turn it on remotely. You program it to switch from refridgerate to cook at a set time

And so it begins, the /. crowd gets fatter

[Cumstien]

You insensitive clod, I need that exercise, because lord knows it's burritos not burrito. Nonetheless, please email me when such a device is available.

-The Schmoo

Why now.....

[Anonymous Coward]

This is depressing. I'm a college student taking an intro to microcontrollers class, and we're programming for the Freescale 68HC12. 16-bit microcontroller, but 32-bits would definitely be nice. I know the purpose of the class is to familiarize yourself with using any kind of microcontroller, but 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. So goes the field of EE.

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.

Re:Why now.....

[Anonymous Coward]

Heh. You're entering a world of pain if you're expecting to coast on existing knowledge in the EE business.

I have alot more to learn.

Fortunately, English doesn't change as often. "Alot" wasn't a word in Chaucer's time, and it still isn't. :-P

Re:Why now.....

[ajlitt]

Why would 32 bits necessarily be better? I cut my embedded teeth on 68HC11 (still 16 bit) and then moved on to 8-bit micros (PIC then AVR). I still prefer the cheap and simple to develop for 8 bit parts when possible, as most of my applications don't need much horsepower or memory. 32 bits is only really helpful if you must use a real OS for communications purposes (tcp/ip, device interfaces, etc), large data sets (because you often get complex storage features), or multitasking.

In embedded systems, your micro is just a means to an end, not the end itself. If an 8 bit micro can do the job for less money, why weigh down your design resources on a more complex part, even if it's all integrated on one chip?

Re:Why now.....

[Anonymous Coward]

yes you have...

playstation

Variation of the mips3000. Even the ps2 has a version of that. N64 had a mips10k variation.

The mips processor is everywhere. They just do not all have the name MIPS on them...

SOC is the future of computing even on desktops. I was surprised when AMD and Intel both jumped at 2 core processors instead of vast chunks of cache. Then eventually memory out right with no cache and the rest of the system components.

This doesn't change a thing

[Reaverkin]

In an industry where projects frequently run over-budget and technical snags incur huge excess cost, people tend to stick with what they know. Look at how many new projects are using a 20 year old 8051 variant - it does the job.

There will always be a niche for crappy 8 bit micros.

(really) smart cards anyone?

[nervesystem]

I'd love to see this chip in a USB smart card. The most advanced USB cards out there from Axalto only have 8-bit CPUs from ST with 4 KB of RAM and 64 KB of EEPROM. All sorts of fun and games would be possible with a secure 32-bit USB card. So anyone from Atmel want to comment on if you're talking to any of the Smart Card vendors? I'm sure the folks from the MUSCLE card group would be happy to create a linux driver.

Re:uClinux on these? not.

[Jesrad]

Even AVR microcontrollers can access external RAM (I know for we sticked 2 MB of SRAM on an ATMega 128 a couple years ago), but of course you can't use this RAM to store Linux. Fortunately the AT91 boards sold by Atmel, which use microcontrollers sporting an ARM core just like these new chips, run uC-Linux just fine, so I don't think there would be much trouble porting it to this new line.

ARM7TDMI?

[elFarto the 2nd]

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

Regards
elFarto

Re:Sure they're cheap, but there's more that matte

[Anonymous Coward]

"32 bits" doesn't get you better precision, just fewer clock cycles. A Z80 will add 32-bit numbers just as well as any 32-bit processor, just more slowly (assuming the same clock speed). Now addressing lots of memory is one thing where 32-bit CPUs are better, but I don't think the ones referenced by the article actually have address buses to allow additional RAM.

I think people forget how powerful 8-bit CPUs really are. Remember all those Spectrum or C-64 games? If one of those things can play some fairly complex games at 60fps, they can also control an ABS actuator or fuel injection system 60 or more times per second.

Just to get this straight, my point was not that 32-bit uCs don't have many uses, but that they won't be displacing 8-bit controllers from the market.

aQazaQa

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.

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

[francisew]

sorry, html swallowed the parallax costs: less than 300$ (watch those angle brackets folks!)

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

[mrm677]

Having an inexpensive 32 bit uC is great. How much are the development kits? 500$?

Amen...for the hobbyist that is. I can name several development kits for 8-bit uCs that are less than $100.

On the other hand, a $500 development kit is a trivial business expense.

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

[francisew]

I agree, 500$ dev kits are cheap for a medium-to-large business.

I also wonder whether development will continue to be driven by larger businesses, or more like science and technology, be more geared towards innovation by small companies being incorporated into larger companies (so the large companies avoid risk in R&D).

I'd guess that as time passes, the dev kit costs will become more significant, as amateurs have access to dev tools which can compete with those of larger R&D labs.

Perhaps uC product adoption by masses of amateurs will drive a significant portion of the market.

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

[marcop]

I have recently tied out Atmel's 8051 based micros (actually, the AT89C51ED2). They can be programmed via ISP over RS232. Atmel has free software (FLIP) that is used to program the chip. You only need an RS232 transceiver (i.e., MAX232 chip) and a $5 cable. No special programmer is needed since it's all software. Of course, you need a prototype board however. Not sure if you can buy that off the shelf.

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

[stonedest]

You must not know about avr-gcc

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

[francisew]

avr-gcc: That's a compiler.

There are also open source compilers for basic stamps, SX chips, ARM, MSP430, and a whackload of other hardware.

What I'm talking about is an actual development board, with a uC and test-leads that you can use to attach it to the real world.

I prefer not to have to try hand convert surface mount 48 pin LQFP packages to dip format. I prefer to concentrate on developing devices, not the uC programmer itself...

I think that having the compilers freely available is great, but it's only a portion of the way.

Re:FOIST POWST

[Anonymous Coward]

Just out of curiosity what is on the site that this goes to. I'm in a corporate environment and don't want to risk clicking it. Anyone brave enough to follow it please let me know.

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

Re:Sure they're cheap, but there's more that matte

[sexylicious]

"32 bits" doesn't get you better precision, just fewer clock cycles. A Z80 will add 32-bit numbers just as well as any 32-bit processor, just more slowly (assuming the same clock speed).

Like I said, 32 bits give you better precision. With an 8 bit machine, you either have to use 4 8 bit numbers to represent a 32 bit number, or you have to cut your precision down to 8 bit precision. In the case of 4, 8 bit numbers, you have to use either at least 4 clock cycles, or 4 pipelines to manipulate the number. Going with a 32 bit machine is better in the case where you want a higher precision for your data.

That's why you'll see many data logging systems or system computers on aircraft using 32 bit processors over a 32 bit bus (or 16 bit processors over a 16 bit bus). Using an 8 bit machine to do the work grossly increases the amount of time it takes to manipulate a 32 bit number.

Does this mean more than 16 IRQs

[slave 6742]

Not reading the story, but does this mean more than 16 IRQs? Sure would be nice to have 256 rather than being confined by the 16 available. Been an issue for years.

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.

Re:Let's compare...

[Anonymous Coward]

This may seem like a nitpick but the AVR is not really a RISC architecture, despite what Atmel claims.

The "R" in RISC stands for reduced, but AVRs typically have 120+ instructions.

The microprocessor purists among us know that the RISC mentality originated at IBM and a core part of any RISC processor are pipelines and caches -- the AVR has a Fetch/Decode pipe and but no cache.

It's kind of dicey to call it RISC, despite Atmels branding.

And yeah it's a nitpicky rant.

Re:Let's compare...

[Anonymous Coward]

Ah... but it uses a Harvard architecture (instruction size different from data size, one word per instruction, and separate instruction and data buses) and a large 32 register file.

Neither caching nor pipelining wouldn't make sense for a processor of this size and power consumption.

Maybe it's VLIW but not RISC? That doesn't make sense to me.

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:Proven Reliability

[ajlitt]

Wha? Since when did 8 bit micros have to be made in large dies? I'm sure that many of the 8-bit parts made now are in .35-.18u processes, as that's what is common in many fabs. Especially since many micros are starting to offer larger and larger RAM and ROM capacities at lower prices, it only makes sense to shrink the process. Besides, the larger the die area of a part, the higher the probability of cosmic ray events intersecting the die. So technically larger parts make for better targets!

coming out?

[Anonymous Coward]

okay i KNOW i never ever use the full potential
of my rig (8Gflops CPU and some more Gflops on
the GPU) ... but isn't i just COOL if i double
click a icon and i can't notice a lag for the
program to open? isn't "real time" just super
cool?!
i think a part of my brain went into several
years of computer use strike after finishing a
project (~300 MB) on publisher, 64 MB Ram and
166 MHz. so call me dumb for buying so much
FLOPS, but at least my psychiatrist doesn't have
to wait for an answer for five minutes in the
future ...

Dude, you are at work too much.

[gosand]

Hmm, let's see...
Who wants to be able to program their TV to record TV from work?

Not me. There is nothing on TV that I have to absolutely watch. If there was, I would get a TiVO.

Who wants to program their lights to come on from work?

I can do that already - X10 module and ssh. I can also set a cronjob when away from home for an extended time.

Who wants to program their heat/AC to turn on/off from work?

I have my thermostat programmed, and I rarely change it.

Who wants their oven to preheat from work?

Not me. Too dangerous. Preheating takes 15 minutes. I can spare 15 minutes. And I actually do cook, so those 15 minutes are usually spent doing prep work of some kind.

I am all for technological advances, but honestly - it sounds like you are either extremely lazy, you work too much, or a little of both.

Answers my question

[ad0gg]

At least new technology will answer my question, "Did i leave the oven on?".

An offtopic vent - embedded development

[argoff]

Is it just me, or is it that every embedded device I've ever dealt with has a different development environment, a different compiler, and basterdized version of C that has all sorts of strange extensions and unpredictable unstandardized behavior. And every single one of them interfaces (uploads) in a different unique pain in the neck way!

Not to mention, almost all the development software and tools cost an arm and a leg. Sure there's FOSS stuff out there, but everytime I've tried to make it work - it's kicked my butt. Maybe this is just the punushment I get for comming from a CS background and not a EE one?

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.

Re:An offtopic vent - embedded development

[bhima]

No, it is not Just You.

Yes, every one is different.

Yes, vendors are inordinately proud of their development software tool

Yes, there is a lot of FOSS and yes it is more time consuming (and painful) to implement.

And, Yes it is punishment for being a CS major rather than EE major.

Still I think FOSS (particularly GCC) is worth it.

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.

Re:Cutting through the fog

[antispam_ben]

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.

I haven't taken a long, hard shopping trip to Wallmart or Target in a while, but the rice cookers I've seen don't have microcontrollers. Microwave ovens don't use 8-bit controllers, they use FOUR bit controllers(!) which are even cheaper in quantity, and are among the highest quantity processors in production.

Presuming microwave ovens become "smart" and on a network, they'll evolve to using 8-bit or 16-bit (such as MSP430) controllers with TCP/IP stack code. Then you can control the microwave through a webpage on the refrigerator's touchscreen.

But you're right, overall, rarely does any new introduction completely remove older technologies from the market, the older ones just get cheaper and find new niches to fill.

Re:Cutting through the fog

[renoX]

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

In theory you may be right, but older part are sometimes shrunk because:
- it is cheaper to produce in the new process.
- or the selling point is the ultra-low power consumption..

Look at this post for a reality check:
http://slashdot.org/comments.pl?sid=124929&thresho ld=-1&commentsort=0&tid=137&mode=nested&cid=104735 14

uCLinux and 8bit

[Anonymous Coward]

I don't have any problems with "uCLinux", but I keep stumbling over "8bit". First I de-l33t-ify it to "Sbit", and then I spell-correct that to "Shit".

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.

death of 8bit mcu

[Anonymous Coward]

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.

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:Not for those with a shaky hand...

[stienman]

Toaster oven soldering. My first batch turned out ok, and with some heavy handed big tip desoldering with desoldering braid they cleaned up very nicely. I have to learn to apply less solder paste.

It's not trivial, but it's not harder than soldering 40 pin dip packages.

I suppose, however, that were the MSP430 4xx available in dip I would have used that since it's cheaper to assemble (LCD is dip, not surface mountable).

-Adam

At last..

[tbcpp]

Yes!!! now I can make a beowulf clu.... wait, what am I thinking?

tbcpp

4-bit recommendations

[totoanihilation]

Have you any recommendations for 4-bit uCs for hobbyists? Some of the projects I work on sometimes require much less than even the lowliest of PICs... Which is why your comment piqued my interest :D
Thanks!

Reports of my death...

[Anonymous Coward]

"Reports of my death have been greatly overclocked!" - AT90 uC

"I thought I was dead, turned out, I was in Boise." - Z8

That being said:

I doubt that I would ever use a 32-bit controller for what I've been building these past years. I'm not about to strap a 500 hp motor to my lawnmower. Why would I use anything more powerful than my AT90s or AT89s for simple controls?

This is not to say that a 32 bit uC has no place. I've been seeing projects such as homebrew iPods using some of the upper end uCs. 32s would be great.

How about a dedicated Atmel based Freevo type device? Completely homebrewed without resorting to Intel/AMD.

This chip could be fun.

OMG! Scoring a 5 for an "insightful" fantasy?

[Anthony Fremont]

In the name of Truth, please mod parent down.....wayyyyyyyyyy down.

Re:Sure they're cheap, but there's more that matte

[Jeff DeMaagd]

Using an 8 bit machine to do the work grossly increases the amount of time it takes to manipulate a 32 bit number.

Avionics is hardly a general purpose task. If the task isn't time or CPU intensive, and needs to be cheap and low power, an 8 bit chip will do fine. If you need to have timing within a few clock cycles, or the chip is high-load then go for the 32 bit chip.

Disappointed...

[Anonymous Coward]

No "You'll have to pry my 8051-core microcontroller from my cold dead hands!" comments?

8 Bit is alive...

[cavac]

..and will stay alive, until there are cheap 32 Bit processors with small pin count and aren't physically THAT small. I mean, yeah, generally small is good. Just not for your average geek (like me) who wants to solder things for himself.

No matter how cheap home appliances become, there are some things just not commercially available. Like the doorbell that is automatically muted on saturday mornings if came home late last night...

ATtiny11

[Anonymous Coward]

I just bought 50 Atmel ATtiny11 8 bit MCUs for $.25 a piece.
Price is what matters when you are doing hardware design.

Yup

[Andy Dodd]

Let's not forget that the average 8-bit microcontroller has a very clean instruction set, and is typically VERY easy to develop for.

Atmel's 8-bit AVR uCs can do some VERY impressive things, and are exceptionally easy to work with.

Who cares if it can run Linux? In the target market for these devices, Linux is *massive overkill*. One of Atmel's most popular AVR microcontrollers has *no* RAM whatsoever, just a tiny bit of ROM and 32 registers.

Volume

[Andy Dodd]

The automotive industry focuses on selling smaller volumes of very expensive ($10,000+) products.

In that industry, $0.02 per unit likely won't make much of a difference at all. Even a savings of $1 per unit won't.

Now, if you're selling millions of a product for $9.99 at your local Wally World, $0.02 will make a MUCH larger difference.

Re:Volume

[the morgawr]

$0.02 per unit likely won't make much of a difference at all.

Actually, for something like in ECU which would go in EVERY car the manufacturer makes (a few million) $.02 is a ton of money. (That's why Freescale chips tend to be more common in automotive stuff they are a few cents cheeper then the microchip stuff). Although for some reason freescale (now that it has been spun off) has decided to cancel that line of chips; I guess they weren't making money at the price they were charging *shrug*.

Despite that

[Andy Dodd]

I don't think Atmel has any intention of compatibility between the AT90 (8-bit AVR) and AT91 (32-bit ARM) lines. Both lines have existed for years, and have no compatibility. The AT91s are NOT intended to replace the AT90s, they are targeted at an entirely different market segment. (Admittedly, with the AtMEGA series AVRs, there's beginning to be quite a bit of overlap, the AtMEGAs are what Atmel is using to "replace" the lower-end AVRs with something compatible and more powerful.)

Then use a 32-bit chip

[Andy Dodd]

You just named one of the cases a 32-bit chip might make sense.

There are MANY applications for microcontrollers where there is NEVER a need to deal with more than 8 bits in a register. In those applications, a 32-bit CPU might actually be HARDER to work with than a simple 8-bit AVR.

Re:uClinux on these? not.

[tzanger]

Even AVR microcontrollers can access external RAM (I know for we sticked 2 MB of SRAM on an ATMega 128 a couple years ago), but of course you can't use this RAM to store Linux. Fortunately the AT91 boards sold by Atmel, which use microcontrollers sporting an ARM core just like these new chips, run uC-Linux just fine, so I don't think there would be much trouble porting it to this new line.

Accessing a static RAM device through I/O is an awful lot different than having it as system RAM; as someone who has done it I am sure you don't need to be told that. As for running uClinux on ARM cores -- of course you'll be able to run it if you give it enough RAM and ROM; throwing it in a core with enough is not at all the same as trying to get it to run on one of these beasts.

Re:I HAVE 32-BIT CHUNKS FOR YOUR 8-BIT FAILURE!

[Anonymous Coward]

Hey man, I've had some good ones in the past. I can't be 100% every single time.

They Have Been saying that for 15+ Years

[Anonymous Coward]

I attendded the 3rd Emmbedded Systems Conference.
The Keynote Topic. 8bit CPUs will be around for many more decades. if 16 (now 32) bits cost a dollar 8bits will cost a dime.
$3.00 some 8 bit chips cost $0.25. Ram and ROM included. and run on a milliamp.

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

overkill is overkill

[poptones]

Open up an electric blanket controller and you're likely to find a PIC. These things come in an 8 pin package, have A/D, D/A and zero crossing functions (just stick a 10M resistor on the 120VAC line and stick it to one of the CMOS inputs) and they cost, in the sorts of quantities a Norelco would purchase them at, less than five bits (that's about 63 cents to you yanks).

Even if the 32 bit chips could be sold for 50 cents and packed into 8 pin TSOPS they still would face an uphill battle because the NRE has already been paid on the PIC driven parts.

The notion of cheap 32 bit chips usurping 8 bit parts has been thrown around more than a decade. In that decade, use of parts like the AVR and the PIC has risen, not fallen. From an engineering POV, trying to displace these simple to use harvard machines with "real" microprocessors like the ARM is like trying to replace jellybeans with chocolate bars.

Re:overkill is overkill

[Anonymous Coward]

What PICs have d/a converters on them, specifically? I know you can use pwm to do d/a conversion, but I've never heard of small pics with dacs...

Danger Will Robinson

[John Jorsett]

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?

If an older technology is working, it's fine to keep using it, but beware. There's a danger of one day waking up to find out that you're one of the last ones still using it, and your skill set isn't up to date for the newer stuff that's in vogue. Potential employers don't want you because you aren't up to speed in the areas they need people. I've seen this happen where acquaintences are honed to perfection on the technology they've been using for 10 years, then the project comes to an end and they're scrambling to find someone who wants what they know. I've avoided this fate by always having at least a side project or two -- sometimes even unpaid -- using the latest stuff. That way I can always have the up-to-the-minute neato things on my resume, and know how to use them.

Re:So prices are coming down...

[ImaLamer]

No one gets the MAD Magazine reference?

Legacy goes back even further

[localroger]

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.

While not object-code compatible the 8088 was designed for easy portability of 8080A code, which was *truly* 8-bit as opposed to 16-bit core over 8-bit bus with the 8088. This takes us back *past* the TRS-80 home computers, which used the Z-80, which was designed (in a different way) to be legacy compatible with the 8080A. The very first home computer kit, the Altair, used an 8080 IIRC.

And the 8080 was in turn a direct descendent of the 8008, and in turn the 4004, the first single-chip microprocessor ever designed. So the PC-compatible CPU core has a long and venerable history indeed.

Re:Good reasons for using 4/8/16 bit SOC controlle

[MooseGuy529]

...the instructions are only 8 or 16 bits wide

Not necessarily--the PIC's are Harvard architecture chips (I believe), and, while the data memory is 8-bit, the instructions are some odd length like 12, 13, or 14 bits. There are ways to read and write program memory, though... a bit clumsy, due to the instruction size, but it's possible.

I never used 8-bit because of cost

[Anonymous Coward]

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.

ucXP?t

[hooqqa]

They have embedded XP!?

Dude

[Anonymous Coward]

Dude, were you just in a crash?

How can you tell?

You have "letni"(tm) imprinted on your forehead!

sigh

[Anonymous Coward]

ha - ha - ha :(

Re:Sure they're cheap, but there's more that matte

[Anonymous Coward]

What about the heat dissipation and power usage?

ARM has traditionally been a MIPS/Watt champion.

Intel once had a 200 MHZ StrongARM that ran off a 0.75 volt power supply and dissipated 40 milliwatts.

pwm is all you need

[poptones]

to drive electric blankets.

And toasters, and LEDs, and temp displays, and battery chargers, and...

Buy ATML

[Anonymous Coward]

in stock of course,)
Martha

ARM/Thumb interworking

[tepples]

x86 has 16- and 32-bit modes, and mixing the two is a BIG PAIN IN THE ASS. How are things with the ARM?

I am a homebrew GBA programmer; the GBA has an ARM7TDMI processor. The tools allow a developer to specify compiling any given module (i.e. C file) in ARM or Thumb, and the jump instruction bx can simultaneously jump and switch between ARM and Thumb, based on the low bit of the destination address. All this "interworking," as ARM calls it, happens nearly transparently in the end.

AVR and ARM teams happy with the developments.

[rootkill.za]

I was actually at the ATMEL seminar at Belvista Lodge in Bellville, South Africa, yesterday. :) We had both AVR and ARM senior engineers there. Quite interresting. ATMEL is basically producing chips to target all the niche/price-sensitive markets. So the 7SAM and the AVR basically is aimed at different segments of the market or totally different markets all together.

Bigger targets

[nurb432]

Yes,that is true, however with the larger areas for each gate, it takes more rays to have an effect.

With smaller gates, it takes fewer rays, so the percentage of errors go up.

Putting them on sapphire helps too... but that is beside my point.

Re:Sure they're cheap, but there's more that matte

[sexylicious]

Even outside avionics, if you want to work with data of a higher precision, then go with a 32 bit machine. 8 bit machines don't work with 32 bit numbers as easily as 32 bit machines do.

High load has no bearing on whether you choose 8 bits or 32 bits. That comes down to how many instructions per second the processor can accomplish. An 8 bit machine running at 20 MIPS is still slower than a 32 machine running at 100 MIPS. Even when you have an 8 bit machine at 20 MIPS and a 32 bit machine at 20 MIPS, you'll get about the same speed. 32 bits will allow you to work with either more data at once or larger numbers (if you can program it properly... such as funky math tricks to do the same operation on a string of 32 bits that is actually four 8-bit numbers simultaneously), so that's where the "speed bonus" comes from for 32 bit machines.

And the article was stating that 32 bit SOCs are getting as cheap as 8 bit SOCs. That's quite an improvement, regardless of bit-addressing issues, memory size, or chip size.

Oh and FYI, avionics is just as general purpose as a router, a GPS unit, a cell phone, or whatever. Each one is suited to the tasks it is designed to handle. And in many systems you'll see the same chip used in several different ways. So saying that "avionics is hardly a general purpose task", is pretty much a moot point.