8 bit microcontroller market
in [Embedded]
|
Prev: Tiny Bootloader
Next: Link&Locate 86?
From: Bill Giovino on 31 Aug 2006 15:50 "Jim Granville" wrote... > Chris Hills wrote: > > > > 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 :-) > > 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 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 http://Microcontroller.com
From: Eric on 31 Aug 2006 16:06 Joerg wrote: > However, there is one thing that I regularly had to consider as a > manager or when designing uC into otherwise analog circuitry for my > clients: Availability of programmers. This is where (so far) the 8051 > has beaten all others hands down. I agree that there's more programmers in the 8051 world today, but I wouldn't agree to take a new permanent job that doesn't let me dabble in Arm7 or MSP430 parts at least some of the time. People need a career path, and although many of us have fond memories of the 8051, I think most of us have our sites on something a little bigger over the long haul. I usually pick jobs where my past expereince will get me in the door, but I need to be attracted by something I want to do, beyond what I've already done. I don't mean this as a slam against the 8051 - it's still a fine choice in many applications. Eric
From: Ian Bell on 31 Aug 2006 13:55 Bill Giovino wrote: > > 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". > And has been for some considerable time. > Now, Microchip leads the pack in 8-bit, both literally and in spirit. Debatable - but they certianly lead in marketing hype ;-) > Japanese manufacturers prefer Japanese uC suppliers. I have seen anecdotal evidence of that too. > 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. Interesting and the subject of much debate - see 8052.com forum for instance. > 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. > http://www.microcontroller.com/news/ti_msp430_50newdevices.asp > (roadmap) > Time only will tell. > 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. > I can wait that long - but how do you get hold of the figures without paying big bucks? > BTW, whose figures are those above? > They are from the an esacademy FAQ here: http://www.esacademy.com/automation/faq/primer/3.htm Ian
From: Ian Bell on 31 Aug 2006 13:59 Chris Hills wrote: > 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 :-) > I will ;-) but I tend to agree with you. Ian
From: Jim Granville on 31 Aug 2006 17:59
Bill Giovino wrote: > "Jim Granville" wrote... > >>Chris Hills wrote: >> >>>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 :-) >> >> 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 > > > 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. If it takes one cycle to do a 32 bit add, that would be 32 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). 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 |