8 bit microcontroller market

I am trying to get a handle on the current (or at least fairly recent) 8 bit microcontroller market. There is plenty of anecdotal evidence around, usually to show a particular manufacturer in a favourable light but apart from spending several grand on a marketing report I have been unable to find a set of basic figures for recent years. There are broad figures up to

2000 in the FAQ but nothing more detailed or recent.

Any ideas where this can be found at little or no cost. I am thinking market share by value, shipments and processor type - that sort of thing.

Ian

Reply to
Ian Bell
Loading thread data ...

Hi, Ian!

First, let me tell you what I've been telling companies for the past, oh, eight years: "The death of the 8-bit microcontroller has been greatly exaggerated".

Now, Microchip leads the pack in 8-bit, both literally and in spirit. Japanese manufacturers prefer Japanese uC suppliers. The 8051 market saw it's first hit ever with ARM's acquisition of Keil, as ARM's own public analyst statements clearly show that their strategy is to move 8051 users into ARM. I'm seeing very strong growth in embedded

16-bit because 16-bit has more processing power than 8-bit, and lower power than 32-bit. That's why TI's 16-bit MSP430 is such a strong performer in the marketplace.
formatting link
(roadmap)

I'm presently working in an accurate analysis of the present market to be posted on Microcontroller.com, but it won't be ready for another month.

BTW, whose figures are those above?

Bill Giovino Executive Editor

formatting link

Reply to
Bill Giovino

In article , Bill Giovino writes

Absolutely... There are still 4 bit systems out there (Japanese toy market?)

I would say that the market will split into 8 bit and 32 bit. Apart from a few specialised parts like the MSP430 the 16 bit market will die out.

Book mark this post and get me to eat my hat in about 5 years time :-)

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris Hills

Do we have to wait ~5 years ?

Spin and marketing will conspire against such predictions.

A good, very current example, is the ZNEO from Zilog.

Zilog pitch this as a 16 bit uC, as the base opcode is 16 bits, with some larger opcodes. But it has 16 x 32 bit registers, and can do 64 bit operand maths. Compare that with the CortexM3 (another new core), it has

16 x 32 bit registers, and the base opcode is 16 bits, with some 32 bit ones. It can multiply to 64 bit result, but seems to lack a 64/32:32

- this is pitched as 32 bit controller.

Who is 'right' ?

This shows the flaw in trying to firstly pigenhole uC into boxes, and then moving pick winner(s) and looser(s).

Freescale look set to somewhat abandon these 8/16/32 bit pigenholes, so maybe in 5 years time, we'll look back on attempts to quantify complex devices with a single number, as quaint ? :)

-jg

Reply to
Jim Granville

And has been for some considerable time.

Debatable - but they certianly lead in marketing hype ;-)

I have seen anecdotal evidence of that too.

Interesting and the subject of much debate - see 8052.com forum for instance.

Time only will tell.

I can wait that long - but how do you get hold of the figures without paying big bucks?

They are from the an esacademy FAQ here:

formatting link

Ian

Reply to
Ian Bell

I will ;-) but I tend to agree with you.

Ian

Reply to
Ian Bell

Jim, the first thing I like to look at is the size of the ALU. Then, I try to look at the size of the internal register datapath. Easiest way for me to do this is look at instruction execution times. If it takes only one cycle to do a 16-bit ADD and they call it a 16-bit, I call it a 16-bit.

But if 16-bit moves take twice as long as 8-bit and 16-bit arithmetic takes about twice as long as 8-bit, it's an 8-bit to me. Just hardcoding an instruction to do "big math" isn't enough for me.

This is a quick view - pipelines and other considerations can make things more complicated.

Dataquest used to go by the size of the external databus (bad way to do it).

Bill Giovino Executive Editor

formatting link

Reply to
Bill Giovino

look at

look at

they call

If it takes one cycle to do a 32 bit add, that would be 32 bit ?

about twice

"big math"

Yes, and that's quite valid too.

Problem is, you now have a different yardstick to everyone else :)

The key point is, it is futile to pigenhole these things to any degree of precision, because everyone uses different yardsticks.

A break down by pin count, or Flash size, would be more informative, but those stats are not crunched.

-jg

Reply to
Jim Granville

that

Well, ARM have to try and talk up their brand, and they _have_ brought the addresses of all the Keil customers, and doubtless will spam them, but I doubt it will change designers' decision process a whole lot. The core matters less and less, over time : other factors dominate selection. Peripherals, Flash Size, Speed, Pin Count... ( and that has to concern ARM )

-jg

Reply to
Jim Granville

I think you find that it was related to Flash Microcontrollers, not any microcontroller. The AVR has pretty high marketshare for flash micros, but I have no clue about the absolute figures.

--
Best Regards,
Ulf Samuelsson
 Click to see the full signature
Reply to
Ulf Samuelsson

Great, this discussion pops up again :-( So the AVR with its 16 bit instruction is a 16 bit uP? And the PIC12 is a 12 bit controller?

The only interesting thing is the width of the datapath in the instruction set. I.E: what is the maximum width the majority of the arithmetic instructions use. This probably puts the ZNEO in the 32 bit class.

--
Best Regards,
Ulf Samuelsson
 Click to see the full signature
Reply to
Ulf Samuelsson

The MC68000 is a 16 bit implementation of a 32 bit architecture and it takes

4 clocks to do a 16 bit add. Is this a 4 bit architecture?
--
Best Regards,
Ulf Samuelsson
 Click to see the full signature
Reply to
Ulf Samuelsson

Along with H8/H8S/H8SX/H8 Tiny.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
 Click to see the full signature
Reply to
Paul Carpenter

Of all the different ways people determine the bit-width of processors, this is the second least valid (after the internal flash width, giving us "12-bit" and "14-bit" PICs). Consider the 68k family mentioned by Ulf - the 68020 has a 32-bit external bus, the 68000 has a 16-bit bus, and the 68008 has an 8-bit external bus, yet all are virtually identical internally from the programmers' viewpoint.

There are two commonly used yardsticks for bit-width - the width of the processor's general purpose register(s), and the width of its ALU (with a total disregard for clock cycle counts - it's the programmer's viewpoint that is vital). In the great majority of cases, these are the same, and almost all cpu architectures can be easily and uniquely classified in this way. There are some major exceptions, such as the Z80, which would have to be classified as an 8/16-bit processor.

Certainly - bit-width of the processor is far from a complete description of the device, or its power or speed. There are plenty of fast 8-bit devices that are faster than slower 16-bit or 32-bit devices, and an embedded developer is interested in many more things than some raw speed measurement.

Reply to
David Brown

Correct - which is my point, that comparing these 'sectors' is worthless outside a very coarse scan, because companies make political decisions on where to place their stats. In Zilog's case, I can only guess it is to 'give some space' to their ARM9 offerings (which so far are looking flash-less?)

-jg

Reply to
Jim Granville

AVRs have a high share of engineering prototypes, as judged from discussions in these news groups. However, final products may or may not be AVRs, since costs and logistics are more important than architectures.

Reply to
linnix

"linnix" skrev i meddelandet news: snipped-for-privacy@i3g2000cwc.googlegroups.com...

There are plenty of AVRs in accessories for mobile phones and quite often this is due to price compared to competition.

Recently lost a significant project to an Renesas R8C, but eventually the purchaser seems to have understood that the external stuff they are going to need for the Renesas part will make the system solution more expensive than the AVR system solution, even if the AVR is a few cents more expensive.

--
Best Regards,
Ulf Samuelsson
 Click to see the full signature
Reply to
Ulf Samuelsson

Hello Jim,

Add to that: Power consumption and wide supply voltage tolerance. In low-cost battery apps those are crucial.

--
Regards, Joerg

http://www.analogconsultants.com
Reply to
Joerg

Yes, and it's not just battery apps that benefit, wide supply tolerance also means fewer parts to stock, and better distribution.

Companies might want to deploy a 5V design to drive Power MOSFETS, and use the same uC in a design that runs on 3.3V and the same uC again in a battery product.

That's where parts like the Silabs C8051F41x, and the new RS08 from Freescale, get a big tick :)

-jg

Reply to
Jim Granville

Op Sun, 03 Sep 2006 18:41:27 +0200 schreef Ulf Samuelsson :

The MC68000 takes four clocks to do an 8-bit add as well, and can't do

4-bit adds in four clocks or less. In fact, it needs four clocks to do a NOP, and all instructions take a multiple of four plus sometimes a multiple of two.
--
Gemaakt met Opera's revolutionaire e-mailprogramma:  
http://www.opera.com/mail/
Reply to
Boudewijn Dijkstra

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.