8 bit microcontroller market
in [Embedded]
|
Prev: Tiny Bootloader
Next: Link&Locate 86?
From: Joerg on 8 Sep 2006 10:57 Hello Yuriy, >>>>> 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. > In which ways is it inferior and limited? >> 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. > Sorry, but I don't think so. MS-Works does all my record keeping nicely. I can work on the files in DOS or a newer Win version, no problems. I would still use DOS-Word if it weren't for the fact that I must handle files created by others with Win versions and also because MS has (unfortunately) chosen to not pay much attention to backward compatibility. In Works they did, in Word they didn't :-( -- Regards, Joerg http://www.analogconsultants.com
From: Joerg on 8 Sep 2006 11:02 Hello Dave, > >>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. > Well, I should have mentioned that I meant turbines but in car engines there are also some routine that need to be really fast, like the knock sensor handling. -- Regards, Joerg http://www.analogconsultants.com
From: Joerg on 8 Sep 2006 11:12 Hello Yuriy, >>> 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. > It has to do with sitting down with the team, deciding on architectures based on EE facts as well as business facts and then looking for the right talent. BTW, it was not me who found the 8051 programmer. Before we decide on an architecture we gather the opinions of lots of people outside EE. For example the purchasing department. These guys can tell you point-blank what's likely going to fly over more than a decade and which lines not to trust too much. >>> 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. > Stopping or starting a process at precisely the same number of clock cycles after event X, every single time. Reaching sleep mode exactly 225 clock cycles after event Y (not 224 or 226). And so on. When you are receiving ultrasound signals over the same board you need to keep the process 100% (not 99.99%) PRF-synchronous at all times or the image will be noisy. In Doppler applications it's even more critical. -- Regards, Joerg http://www.analogconsultants.com
From: Hans-Bernhard Broeker on 8 Sep 2006 14:43 Jim Granville <no.spam(a)designtools.maps.co.nz> wrote: > One thing that surprises me, is the number of new PC motherboards that > use thru-hole electrolytics. I know SMD ones are expensive, but > I'd have expected the motherboard makers had enough clout to shrink > the difference. But maybe not enough. Mainboard capacitors have become a rather critical part --- at the kind of specs they need to fulfill (mainly for operative temperature), they're apparently expensive enough in through-hole that manufacturers feel tempted to shave off a little more than they should, leading to unintended explosive deconstruction at the customer. Given they think they can't afford through-hole capacitors of the necessary quality, even a small extra amount for SMD might actually break their neck. > It seems they prefer the leaded ones. Quite probably. Might be because those capacitors are often sufficiently closely packed that the only sensible place to have their terminals is underneath. Or, given their size, it may simply be impractical to mount them on the surface --- they'll fall off too easily. -- Hans-Bernhard Broeker (broeker(a)physik.rwth-aachen.de) Even if all the snow were burnt, ashes would remain.
From: Dave on 8 Sep 2006 20:21
On Fri, 08 Sep 2006 16:45:55 +1200, Jim Granville wrote: > Do you use the TPUs, and if so, how are they coded ? Yes. The product I mentioned has two 16-channel TPUs and we used both. One TPU was dedicated primarily to receiving engine timing signals and generating fuel and spark signals. The other TPU handled an assortment of inputs (e.g., engine and transmission speed) and generated various signals (a tach output was one). The microcode was developed in-house by a small group. I'm not sure what tools they used--there is a very limited tools availability for TPU microcoding. >> 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 > > Code size footprint for this set of stats ? Hmmm. From memory: 28k of RAM was available and we probably use 20K in normal use. Program code was probably 500K-600K and another 100K of calibration tables. >> 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. > > Is the M-GM compiler generally available, or do they keep this in-house. > > Someone should tell them it would be great PR to open source this ! :) It was developed by Intermetrics for our use and our customer. It was considered a competitive advantage so it was in-house only. It is currently still being used by a very small V8 group (two people?). That group is also handling maintenance for the V6 programs that used M-GM. ~Dave~ |