8 bit microcontroller market
in [Embedded]
|
Prev: Tiny Bootloader
Next: Link&Locate 86?
From: Jim Granville on 12 Sep 2006 18:08 Joerg wrote: > Hello Steve, > >> >>> Sometimes it helps to communicate before a chip design and not after. >>> Example: IMHO the decision by TI to take the ADC function out of the new >>> HW-multiplier equipped F2xxx device was not a good decision. It'll cost >>> design-wins. >> >> >> I'm not aware of these new HW multiplier F2 parts, is there a link >> somewhere with the announcement? >> > > I heard it from someone I know at TI. No idea if there was a formal > announcement but it's this one: > http://focus.ti.com/docs/prod/folders/print/msp430f2350.html > > MSP430F2350 in case the link doesn't work for you. Interesting devices, but they do have a Slope ADC, and they already have some others with MPY + Slope ADC, so likely they have a large user pushing that combination. I like the 16b SDM ADCs, but they don't come for free. Sometimes companies have one die, but release the lowest-spec devices first, and "add" ADCs later (gets the family out faster.., and covers their butts should the ADC not quite make it... ) eg the smaller siblings have three choices, of Slope/SAR/SDM ADCs, each with a significant price change. Seems they are releasing more devices in the 40-48 pin area, which was an uncovered area before. -jg
From: Paul Keinanen on 12 Sep 2006 18:13 On Tue, 12 Sep 2006 20:07:07 +0200, "John F" <spam(a)127.0.0.1> wrote: >> My father automated a whole cold-rolled steel line with 2k because >> that's all the early machines had. Nowadays the young lads need >> 128MB+ >> just to be able to write "Hello World". > >Using Java! SCNR > >2k are way too much for simple state machines... no floating point >will be available though, since (in my experience) the code for float >multiplications on an 8bitter can take up to 1k (depending on the >compiler. Implement one by hand might take a few hundred LOC maybe)... Implementing floating point multiplication is trivial on any 8 bitter, implementing floating point addition is slightly more demanding due to the normalisation/denormalisation stages. Paul
From: John F on 12 Sep 2006 18:21 Paul Keinanen wrote: > On Tue, 12 Sep 2006 20:07:07 +0200, "John F" <spam(a)127.0.0.1> wrote: > >>> My father automated a whole cold-rolled steel line with 2k because >>> that's all the early machines had. Nowadays the young lads need >>> 128MB+ >>> just to be able to write "Hello World". >> >> Using Java! SCNR >> >> 2k are way too much for simple state machines... no floating point >> will be available though, since (in my experience) the code for >> float >> multiplications on an 8bitter can take up to 1k (depending on the >> compiler. Implement one by hand might take a few hundred LOC >> maybe)... > > Implementing floating point multiplication is trivial on any 8 > bitter, > implementing floating point addition is slightly more demanding due > to > the normalisation/denormalisation stages. Well, yes. It just takes some LOC and thus some bytes. Inefficient C will bloat it towards 1k in some cases. I'll try to find the example I had here. Not very pretty output. -- Johannes You can have it: Quick, Accurate, Inexpensive. Pick two.
From: Joerg on 12 Sep 2006 20:27 Hello Paul, > >>>My father automated a whole cold-rolled steel line with 2k because >>>that's all the early machines had. Nowadays the young lads need >>>128MB+ >>>just to be able to write "Hello World". >> >>Using Java! SCNR >> >>2k are way too much for simple state machines... no floating point >>will be available though, since (in my experience) the code for float >>multiplications on an 8bitter can take up to 1k (depending on the >>compiler. Implement one by hand might take a few hundred LOC maybe)... > > > Implementing floating point multiplication is trivial on any 8 bitter,... Provided you have a whole lot of time for that routine to run. > implementing floating point addition is slightly more demanding due to > the normalisation/denormalisation stages. > -- Regards, Joerg http://www.analogconsultants.com
From: Joerg on 12 Sep 2006 20:35
Hello Jim, >>> >>>> Sometimes it helps to communicate before a chip design and not after. >>>> Example: IMHO the decision by TI to take the ADC function out of the >>>> new >>>> HW-multiplier equipped F2xxx device was not a good decision. It'll cost >>>> design-wins. >>> >>> I'm not aware of these new HW multiplier F2 parts, is there a link >>> somewhere with the announcement? >> >> I heard it from someone I know at TI. No idea if there was a formal >> announcement but it's this one: >> http://focus.ti.com/docs/prod/folders/print/msp430f2350.html >> >> MSP430F2350 in case the link doesn't work for you. > > Interesting devices, but they do have a Slope ADC, and they already > have some others with MPY + Slope ADC, so likely they have a large user > pushing that combination. Well, yes, but I can do slope with any old uC and it's slow. > I like the 16b SDM ADCs, but they don't come for free. > Sure, but the F2013 has one and is under $2. Not exactly a bargain but an ok price for many apps. The F427 price tag is not ok for most (of my) apps. > Sometimes companies have one die, but release the lowest-spec devices > first, and "add" ADCs later (gets the family out faster.., and covers > their butts should the ADC not quite make it... ) > That's understandable but I'd have hoped that they laid out a road map, with the understanding that some devices might not come to pass. That would allow us HW guys to plan ahead. For example by designing in a F427 with the assumption that something more reasonably priced is coming down the pike. > eg the smaller siblings have three choices, of Slope/SAR/SDM ADCs, each > with a significant price change. > > Seems they are releasing more devices in the 40-48 pin area, which was > an uncovered area before. > They also pushed into the really low-pin range which had been totally under-served. Also DIP packs so we can use them for designs that'll go onto phenolic. Except that their prices aren't quite there yet for phenolic stuff. -- Regards, Joerg http://www.analogconsultants.com |