8 bit microcontroller market
in [Embedded]
|
Prev: Tiny Bootloader
Next: Link&Locate 86?
From: Joerg on 12 Sep 2006 12:02 Hello Terran, >>so how do think other engineers design MSP430 products without this >>info? Same problem with the AVR datasheets. Design by experimentation > > We generally don't anymore. We tried a design using an AVR's internal > comparator. The next revision put it back in an external device. On the > other hand the ADC has been adequate for a lot of purposes. Our general > policy now is that any internal analog components on uCs should be > presumed worthless until proven otherwise, especially considering the > lack of adequate specifications. We suspect they let the digital guys > build them for fun or something. :) Sometimes it looks like it. It is also a reason why I never used SoC. Even a puny 10c opamp can often run circles around what's in there. Whenever I looked at the "analog" offerings in uC or SoC devices I couldn't resist the urge to yawn. Then did the whole design analog, like usual. Ended up being lower in cost anyways. -- Regards, Joerg http://www.analogconsultants.com
From: John F on 12 Sep 2006 14:07 Joerg wrote: > Hello John, Hello! nice to see you here :-) >>>>> Unfortunately, I did quite a lot of x51 assembly programming. >>>>> Just >>>>> did not know better at that time. Fortunately, these days were >>>>> long >>>>> ago. >>>> >>>> They are back! >>> >>> Not for me. :) >> >> Then your field of operation will be very limited. > > Yuriy probably has not yet worked in a cut-throat cost environment > like consumer or dispoable medical. Selecting too big a micro can > put > you out of business there. It's not even that. It's just the only way to get the most out of what you have. :-) Anything else derives from that possibility. >>>>> I could believe that you have specific constraints in the >>>>> particular design. I could not believe that using assembler is >>>>> the >>>>> only solution or even the best solution. >>>> >>>> It is the only solution. You can't guarantee in C that with every >>>> optimisazion you get the same length of execution time. It's just >>>> not >>>> possible. >>> >>> This code is not maintainable. >> >> It is! Of course not for someone like you. Someone fond of the >> underlying assembler would do. It has to be maintainable since it >> is >> production code. Every step is documented and the number of cycles >> taken is noted on every change. Has to be done, has to work. Is >> done, >> is working. >> > > The key word is "Every step is documented ...". Good point. Comments > in the code ain't enough although some people think it is. Yes. Unfortunately. In my programs it might be the other way... I often write more explaination than actual code: Not for such self documenting code... addc A,@R0; jnc NO_CARRY; DO_CARRY: xor A,A NO_CARRY: ... But I always add a few lines to describe the idea, the flow using pseudo code (maybe a C equivalent -> very good for such stuff). Using a lot of NOPs is quite common... > Anything > other than a top-down architecture with a thorough FRS and version > control isn't going to fly in the long run and would raise a red > flag > with FDA and agencies like that. Top down is a weird thing. I hold it as: Never jmp to a position outside a procedure. If I jump upwards I usually explain why and where the jump will end and briefly what is done there. >>>> I don't even do inline assembly because of the prologue and >>>> epilogue the compiler adds. >>>> >>>> You don't have any control over that in C. That's what C is >>>> about! >>>> It >>>> hides this stuff. >>> >>> Exactly. It improves software development time. >> >> It makes timing issues worse. I've done things on a 2k System you >> wouldn't even get into a 16k System. That's the difference between >> asm and C. C is a general purpose tool. ASM is the special case >> tool. >> That's it. You won't take a hammer to saw a brick of wood :-) >> > > 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)... -- Johannes You can have it: Quick, Accurate, Inexpensive. Pick two.
From: Joerg on 12 Sep 2006 14:33 Hello John, > >>>>>>Unfortunately, I did quite a lot of x51 assembly programming. >>>>>>Just >>>>>>did not know better at that time. Fortunately, these days were >>>>>>long >>>>>>ago. >>>>> >>>>>They are back! >>>> >>>>Not for me. :) >>> >>>Then your field of operation will be very limited. >> >>Yuriy probably has not yet worked in a cut-throat cost environment >>like consumer or dispoable medical. Selecting too big a micro can >>put >>you out of business there. > > It's not even that. It's just the only way to get the most out of what > you have. :-) Anything else derives from that possibility. > Or to modify an old saying in sales: If you don't find the lowest cost solution somebody else will. > >>Anything >>other than a top-down architecture with a thorough FRS and version >>control isn't going to fly in the long run and would raise a red >>flag >>with FDA and agencies like that. > > Top down is a weird thing. I hold it as: Never jmp to a position > outside a procedure. If I jump upwards I usually explain why and where > the jump will end and briefly what is done there. > In med electronics you often don't have much of a choice. The design process is pretty much prescribed. >>>It makes timing issues worse. I've done things on a 2k System you >>>wouldn't even get into a 16k System. That's the difference between >>>asm and C. C is a general purpose tool. ASM is the special case >>>tool. >>>That's it. You won't take a hammer to saw a brick of wood :-) >>> >>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)... > In those days it was pounding the Horner scheme and finding the solution where the multiplier coefficients would have the least amount of zeros, counting the number of clock cycles needed for the remaining shifts and adds, finding it still doesn't fit, letting off a cuss word or two, doing some more Horner scheme scribbling, cussing some more... Come to think of it, for very cost sensitive gear it's still the same. TI did announce the 430F2350 which finally will have a HW multiplier. No pricing yet. Sigh. But: They took out the ADC! Arrrrgh.... This leaves only the old 430F427 but that's too expensive for most of my apps. -- Regards, Joerg http://www.analogconsultants.com
From: Ulf Samuelsson on 12 Sep 2006 15:04 "Terran Melconian" <te_rem_ra_ove_an_forspam(a)consistent.org> skrev i meddelandet news:slrnegddb7.li1.te_rem_ra_ove_an_forspam(a)There-Are-Many-Things.consistent.org... > On 2006-09-06, steve <bungalow_steve(a)yahoo.com> wrote: >> >> Joerg wrote: >> so how do think other engineers design MSP430 products without this >> info? Same problem with the AVR datasheets. Design by experimentation > > We generally don't anymore. We tried a design using an AVR's internal > comparator. The next revision put it back in an external device. On the > other hand the ADC has been adequate for a lot of purposes. Our general > policy now is that any internal analog components on uCs should be > presumed worthless until proven otherwise, especially considering the > lack of adequate specifications. We suspect they let the digital guys > build them for fun or something. :) No, the designers doing the analog stuff for the AVR is separated from the digital designers by a significant ground plane it is so large that some people call it the "Baltic Sea". The truth is that you cannot expect to have the same analog capabilites in a a CMOS process suitable to do all the other nice things you want in a micro. I am sure that any micro would suck greatly in Nationals VIP (Vertically Integrated PNP) process. -- Best Regards, Ulf Samuelsson This is intended to be my personal opinion which may, or may not be shared by my employer Atmel Nordic AB
From: John F on 12 Sep 2006 15:20
Joerg wrote: > Hello John, Hi Joerg! > Or to modify an old saying in sales: If you don't find the lowest > cost > solution somebody else will. Yep. so true! >>> Anything >>> other than a top-down architecture with a thorough FRS and version >>> control isn't going to fly in the long run and would raise a red >>> flag >>> with FDA and agencies like that. >> >> Top down is a weird thing. I hold it as: Never jmp to a position >> outside a procedure. If I jump upwards I usually explain why and >> where the jump will end and briefly what is done there. >> > > In med electronics you often don't have much of a choice. The design > process is pretty much prescribed. I know. It's a pitty. It's necessary, but still a pitty :-) >>>> It makes timing issues worse. I've done things on a 2k System you >>>> wouldn't even get into a 16k System. That's the difference >>>> between >>>> asm and C. C is a general purpose tool. ASM is the special case >>>> tool. >>>> That's it. You won't take a hammer to saw a brick of wood :-) >>>> >>> 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)... > > In those days it was pounding the Horner scheme and finding the > solution where the multiplier coefficients would have the least > amount of zeros, counting the number of clock cycles needed for the > remaining shifts and adds, finding it still doesn't fit, letting off > a cuss word or two, doing some more Horner scheme scribbling, > cussing > some more... > Come to think of it, for very cost sensitive gear it's still the > same. > TI did announce the 430F2350 which finally will have a HW > multiplier. I'm not really convinced about that. I mean, that's some part you could take out of a DSP design and plug it into a regular ?C... I guess there won't be a lot of need for it in the "real" world :-) It will ease things a bit. So much for sure. > No pricing yet. Sigh. But: They took out the ADC! Arrrrgh.... This > leaves only the old 430F427 but that's too expensive for most of my > apps. I must admit that I'm just getting used to the 430 , not done much with it yet but what I know already it's one of the best on the market for what I usually need. -- Johannes You can have it: Quick, Accurate, Inexpensive. Pick two. |