Prev: Tiny Bootloader
Next: Link&Locate 86?
From: Jonathan Kirwan on 13 Sep 2006 16:38 On Wed, 13 Sep 2006 20:05:31 GMT, Vladimir Vassilevsky <antispam_bogus(a)hotmail.com> wrote: >Jonathan Kirwan wrote: > >>>The user interface of a microwave oven is already too complicated to be >>>developed in asm... >> >> >> I honestly still don't understand where you are taking this. But I >> suspect that this example is a bit of a strawman. I think the user >> interface of a microwave oven is a good place for a mostly using a >> language other than asm, though I suppose there might be a small bit >> of asm in many of them. However, that isn't how you say things. >> >> You seem to suggest, perhaps unintentionally, that such things are >> also "too complicated" for asm. On that score, this sounds to me like >> something spoken by someone who probably hasn't developed significant >> applications entirely in asm. > >When I was young and stupid, I developed everything entirely in the asm. I can't agree that developing entirely in asm is always strictly a matter of being stupid or young or both, if that is your implication. >Mostly it was because the early C compilers were very inefficient, full >of bugs and poorly documented. I was too lazy to learn something new >and unintelligible, especially when I had such simple and clear tool as >the assembler seems to be. And you point? >Once I developed the application of 500k lines of asm. Finally that got >me to realize that this is not the right way to do things. It probably wasn't the right way for that application. I bow to your knowledge of your application experience here. If you think it was stupid, it was. All I can do is agree. But that does not provide you with the right to claim, by fiat, that everyone else is wrong in what they do. Much as you might imagine otherwise. >Then the AVR and IAR C appeared. After that, there was absolutely no >need for me to develop anything in the asm for 8-biter. And that is the kind of absolutist statement that anyone should be wary of. It is obviously ignorant of the myriad circumstances that exist in a world as complex as ours. But feel free to pontificate about your belief. Just others should realize that this isn't based on your god-like knowledge of everyone else's circumstances, but instead on your own narrow vision of them. > I've done applications spanning many, >> many hundreds of printed pages of asm (filling some 6 thick volumes, > >Why would you need the complete source code in the hardcopy? At the time, we printed listings and bound them for reference. >> actually, and including floating point routines, transcendentals, etc) > >No problem. I did all of that till I finally realized that there is no >reason in reinventing the wheel. A simplistic statement with grand, sweeping implications. But nature is impassive and unswayed by the force of your own realizations. I don't mean to be abrupt, but you really do seem to be telling everyone else their business. Feel free, but it really doesn't change things. >> providing timesharing services and interpreters for dozens of very >> active users entirely in asm and I'm quite sure that the user >> interface of a microwave oven would be rather trivial by comparison. >> So it's not out of the bounds, nor even particularly difficult. (In >> that case, I had little choice at the time, though, due to processing >> rate capabilities of 1960's technology and available options regarding >> tools. Today, I'd use a high level language for a very significant >> part of it.) >> >> Asm almost always has some place within the embedded applications I >> work on. Perhaps 2-5%, or so, in many cases. > >Agreed. At least, we have that. > In a few cases, 100%. > >Example? I could give several and justify them, but frankly you haven't made me interested in pursuing it with you. You could go through google and find some of my comments that discuss some details, though. >> It depends on circumstances. But reducing asm to zero almost doesn't >> happen, except in rather trivial test cases. And I'm not just talking >> about applications I personally write, but those of people I work with >> in similar product areas. It really isn't unusual. > >I did quute a lot of mixed C and assembly programming for the different >processors. Surprisingly, I never had to use any asm coding with AVR and >IAR EC++. That's nice for you and your applications. I have done the same with some of mine. But you don't find me making such bald claims about everyone else's choices for their application area as you seem to be making. Instead, I realize that there are times and places and that I can only speak better about applications I've actually considered and worked on. >> Of course, I'm sure that there are times and places where assembly is >> simply not used by the application developers -- but those places will >> be where priorities and trade-offs are be markedly different from >> mine. No criticism should be lobbed, either way. We know what we are >> doing, just as I'm sure you do. My solutions wouldn't make sense to >> some other application areas and their solutions wouldn't make sense >> to mine. >> >> My only suggestion might simply be that being facile with assembly is >> an enabling skill. > > From my experience, the people who are aggressively advocating the >assembler are the ignorants who stuck with the seeming clarity and >simplicity. I don't think anyone _advocates_ assembly. Instead, folks _do_ wind up having to deal with sweeping claims by people like you and trying to put some measure of balance into them. If you see that as advocacy, that's not my problem. There are (and were) times and places. Sometimes, the circumstances _do_ warrant some assembly. Sometimes, none. Sometimes, a lot. And even today, sometimes entirely. You really have no business telling anyone that this isn't the case. Though I definitely agree that time and tool availability has moved the lines around over time. > You can use it, or not, as the application >> requires. But if you don't have much facility or familiarity with it, >> enough that you are comfortable applying it, then you won't. Even >> when the situation might be improved or completed more quickly with >> it. (It would be manifestly wrong to suggest these situations do not >> ever occur.) > >If you have the right set of m
From: Vladimir Vassilevsky on 13 Sep 2006 17:35 Joerg wrote: > Hello Vladimir, > >> >>>> So, you are talking about using the asm for the really primitive >>>> applications, like toys, tools, timers, dimmers, etc. >>>> >> Primitive applications are developed by the primitive people who are >> paid the primitive money for their primitive job. The company can make >> a lot of money from it however it is a completely different story. >> > > What you call primitive applications are everywhere. Petty bother. The engineers I > have seen working on these are intelligent people, often more so than > those who do not have to find their ways around limited budgets. Their > jobs are not primitive but rather challenging. Have you ever designed a > consumer product that must be produced for less than $5? It's fun. It could be fun. However there is no money for the engineer in the development of the primitive stuff. It is the job for the technicians. The reality is the bigger is the project and the higher is the level of abstraction, the more money is paid. Just compare the salaries. > > Oh, and neither I nor clients have a problem receiving primitive money :-) > The simple stuff goes to China and India first ;) Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
From: Ulf Samuelsson on 13 Sep 2006 17:36 "Joerg" <notthisjoergsch(a)removethispacbell.net> skrev i meddelandet news:uQDNg.886$IA.0(a)newssvr11.news.prodigy.com... > Hello Ulf, > > >>>>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". ... > > > Does "Baltic Sea" imply that AVRs are designed in Viking country, like > MSP430s were really born in Teutonia (or rather Bavaria)? > Some peoiple claim that AVR means Alf and Vegard's Risc processor but Alf and Vegard claims it does not mean that at all. Vegard designed the initial CPU core and Alf wrote the compilers while studying in Trondheim, Norway which is indeed Viking country. The Analog cells are designed in Finland, which is not core Viking country. Some ASSPs like the PWM, CAN and USB AVRs are designed in Nantes, France which can hardy be claimed to be Viking country although that part was so close to the atlantic coast that they were bound to get the odd Viking "tourist". > >> 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. > > > Not necessarily. We have done mixed signal ASIC (full custom) with serious > logic functionality on board. These include front end amps that feature a > noise figure close to discrete solutions and up to 30MHz. > Sometimes it is a cost-performance tradeoff. Atmel Grenoble (just sold off) delivered 2 Gigasample ADCs so it can be done, but that does not mean that you can sell this in volume as part of a micro. When you build an ASIC you have design parameters that you have to meet. A little different when you design general purpose micros. Many of the current crop of AVR parts were designed for a certain white goods manufacturer. Sometimes specs are reduced to meet draconian cost targets. At the same time, I do believe that a smart microcontroller company needs to invest in analog technology to allow integration of discrete analog. > Just look at the analog tricks you can perform with a CD4007UBE (full > CMOS) or a 74HCU04 (also full CMOS). The main thing is to consult with > analog people before a SoC approach is chosen. That's not happening IMHO > so we analog guys end up doing designs discrete that could have been uC. > Over and over. > > 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. > > -- -- 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: Joerg on 13 Sep 2006 17:58 Hello Vladimir, >>> >>>>> So, you are talking about using the asm for the really primitive >>>>> applications, like toys, tools, timers, dimmers, etc. >>>>> >>> Primitive applications are developed by the primitive people who are >>> paid the primitive money for their primitive job. The company can >>> make a lot of money from it however it is a completely different story. >>> >> >> What you call primitive applications are everywhere. > > Petty bother. > Huh? > The engineers I > >> have seen working on these are intelligent people, often more so than >> those who do not have to find their ways around limited budgets. Their >> jobs are not primitive but rather challenging. Have you ever designed >> a consumer product that must be produced for less than $5? It's fun. > > > It could be fun. However there is no money for the engineer in the > development of the primitive stuff. It is the job for the technicians. > The reality is the bigger is the project and the higher is the level of > abstraction, the more money is paid. Just compare the salaries. > Maybe you have never worked on consumer gear. Or maybe you aren't living in the US. The folks who design thermostats, toys, entry systems or other consumer gear earn top Dollar. Just ask Jim Thompson here in the NG (who has for example done a chip design for an air freshener). You need to be a really good engineer to create such things in the presence of a tight BOM budget. >> >> Oh, and neither I nor clients have a problem receiving primitive money >> :-) >> > The simple stuff goes to China and India first ;) > The production of it goes to China, sure. Some of my designs are also being produced there right now. Also some design will go but, believe it or not, it's often the higher level code writing that goes there (to India). -- Regards, Joerg http://www.analogconsultants.com
From: Yuriy K. on 13 Sep 2006 19:57
Joerg wrote: >> BTW, does SDT have more than one undo level? > I don't remember since I generally do not need an undo command ;-) Hm-m-m. Are pencil and mylar tape good enough? >>> And we still have the same incompatibilities where the only way to >>> get the data into the layout package is a netlist. >> >> Try to use the same package for both schematic capture and PCB >> routing. You will see a huge improvement in compatibility. > Sure. My new CAD (Cadsoft Eagle) does that. Obviously, any modern package does that. BTW, what is the reason to use bad new software instead of good old SDT? :0 -- WBR, Yuriy. "Resistance is futile" |