8 bit microcontroller market
in [Embedded]
|
Prev: Tiny Bootloader
Next: Link&Locate 86?
From: Ian Bell on 7 Sep 2006 17:19 Jonathan Kirwan wrote: > > Compromises and tradeoffs are the rule in my life. They are the rule of *any* engineers life. Anyone for whom this is not true is not an engineer. Ian
From: Yuriy K. on 7 Sep 2006 21:55 Joerg wrote: >> This is exactly what manager selecting CPU core is doing. > > The managers do not select the CPU core. A good manager educates the > staff in business matters. For example, how to be or become a good cost > thinker, what the importance of second-source is and so on. Then good > engineers will arrive at the proper CPU selection all by themselves :-) Good. Finally some reasonable description of managerial job. But it has nothing to do with the managers looking for the engineers who can specifically program x51 core. >>>> BTW, how many managers were polled to get these results? >>> No need to for me. > Ahm, I am not alone with this opinion. Not by a long shot. Agreed. There may be couple others, too... >>> Our apps are a lot more demanding. Realtime stuff in assembler, other >>> designs in C. >> >> Necessity to use assembler usually points to the inadequate processor >> selection. > > For hardcore realtime apps the is no alternative to assembler yet. What is *you* definition of "hardcore realtime"? I do *hard* realtime all the time. No need for assembler at all. Just do some thinking *before* the coding and choose proper processor for the job. >> :) These people never heard word transistor either. > My clients know them very well. World is not limited to EE. :) -- WBR, Yuriy. "Resistance is futile"
From: Yuriy K. on 7 Sep 2006 22:22 John F wrote: >>>> Necessity to use assembler usually points to the inadequate >>>> processor selection. >>> You can't mean what you are saying here. >> Yes, I can and I do. Assembler is needed in a very few, very special >> cases. > > No. It enables you to do a lot of things on hardware you would have > tossed and bought something three times more expensive. Yes. For typical processor (excluding specialized processors DSP and peripheral controllers like PIC) C is only 20-30% less effective than assembler. Depend on task it may even generate smaller code. >>> I even write ASM on high >>> speed DSPs to get the best out of the material. >> DSP is one of these special cases. > > But not the only one. No. As usual there are very rare special cases when assembler is really necessary. As long as they kept rare it is not a problem. >> And even for DSP assembler should not take a big percentage of the >> code. > > What do you mean? By LOC? By development time? By execution time? By the source code size. Best optimization is the algorithm optimization. Writing in assembler fast interrupt or inner loop could be acceptable as a last resort. >>> If you write an >>> interrupt-routine in C it says that you don't care about timing at >>> all. That's it. >> I write all my interrupt routines in C. It means the proper >> processor >> selection and good task division between interrupt and > > And? :-) And the rest of the software. Minimizing tasks you need to do in the interrupt is very helpful. > I have to disagree. Assembler is a very important instrument. If you > aren't able to use it you shouldn't do embedded systems IMHO. :) Unfortunately, I did quite a lot of x51 assembly programming. Just did not know better at that time. Fortunately, these days were long ago. >>> It shows your ignorance to hard realtime constraints. Hard realtime constraints have nothing to do with programming language. BTW it can be a hard 10 seconds response time. :-P >>> Compiler- and optimisation-independent timing is _very_ important. >> That's what timers, compare/capture units and other good hardware >> stuff is used for. > > Not at all. You might still introduce nasty glitches in mixed > signal-designs, phase noise in digital modulation systems if you don't > equal out conditional branches... You can screw up any design in a million different ways in any kind of language. 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. -- WBR, Yuriy. "Resistance is futile"
From: Dave on 7 Sep 2006 23:59 On Thu, 07 Sep 2006 22:32:02 +0000, Joerg wrote: > > Yep. He who thinks assembler is all stone age has probably never > programmed an engine control or something like that. There might only be > milliseconds between loss of loop lock and a destructive detonation, > pieces raining out of the sky and all that. Interesting example. I started programming in 68K assembly language many years ago and still use it. Over the last ten years, engine control software I have written has been sold in probably 15-20 million cars. And is still being sold. _Very_ little of the software is done in assembly. Some of the initialization code needing access to processor registers after power-up is in assembly. Also in assembly is "wrapper" code for one or two ISRs and none of these dealt with any engine control functions. The only significant use of assembly is in electronic throttle control where dual software paths are used. One path is assembly so as to be able to choose different registers and instructions from the higher-level language code. The SW which deals with loss of lock from the engine timing sensor is in the HLL, BTW. ;-) A rough count of lines of code for a recent model year (V6 engine) is Assembly 4288 2.97% C 7411 5.13% Modula-GM 132891 91.91% ---------------- ------- Total 144590 The C code is a recent addition and is used only for CAN communications. Of the C compilers I have looked at for 68K use (Diab, Metrowerks), none could generate 68K code to compete with the M-GM compiler. ~Dave~
From: Yuriy K. on 7 Sep 2006 23:31
Joerg wrote: >>>> Very good example. I vote for today's software over any 10-years old. >>>> And definitely over any 25-years old software... >>> >>> Sometimes, older stuffs are better. >> >> For example? >> > OrCad SDT-III 3.22 Inferior to almost any current PCB design package. Very limited capability. > Filter Design (Mildenberger, unfortunately not in English) Not familiar with. > MS-Works > DOS-Word Inferior to current MS office set. Or even to OpenOffice. Bad examples. -- WBR, Yuriy. "Resistance is futile" |