8 bit microcontroller market
in [Embedded]
|
Prev: Tiny Bootloader
Next: Link&Locate 86?
From: Joerg on 9 Sep 2006 12:42 Hello Dave, > >>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. > > I hate to disappoint you again, Joerg, but the knock sensors were handled > in M-GM also. And, unlike some functions (spark, fuel, engine timing > signals) which used the TPU, the knock sensors were controlled by the M-GM > code with no use of the TPUs. Sorry. ;-) > Hmm, now I begin to wonder why the knock adjustment in my Mitsubishi is kind of sluggish. It takes almost a second to adjust to major load changes such as shifting up when reaching the top of a grade with the monthly supplies from Costco in the back ;-) -- Regards, Joerg http://www.analogconsultants.com
From: Ulf Samuelsson on 9 Sep 2006 13:38 >>>> 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. I would be much, much better to have a little extra performance and a more advanced timer which would idle the CPU until a condition occurs. #define CYCLE_TIME 0x4711 uint16 TIMER_CNT=0; uint16 next_top = 0; sbit(START_TIMER,TIMER_CTRL); loop TIMER_TOP_VALUE += CYCLE_TIME; // do something... sbit(WAIT_UNTIL_TOP_VALUE,TIMER_CTRL); __sleep(); end loop; -- 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 9 Sep 2006 16:14 Hello Ulf, >>>>>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. > > I would be much, much better to have a little extra performance > and a more advanced timer which would idle the CPU until a condition occurs. > > #define CYCLE_TIME 0x4711 > > uint16 TIMER_CNT=0; > uint16 next_top = 0; > sbit(START_TIMER,TIMER_CTRL); > > loop > TIMER_TOP_VALUE += CYCLE_TIME; > // do something... > sbit(WAIT_UNTIL_TOP_VALUE,TIMER_CTRL); > __sleep(); > end loop; > Sure. But often we have to make do with the bare bones in CPU resources. Turn every dime around and around. Then there is (usually) only one timer besides the WDT which, of course, has already been taken. Just like that big piece of top sirloin from the buffet. Many times we use uCs as state machines and then they have to perform the same way as if we had done it in logic chips. IOW totally process-synchronous. I have another app coming up that I am trying to do analog/mixed. But if for some reason that doesn't pan out this would need three dozen uC per system all doing the same thing but with other input data. -- Regards, Joerg http://www.analogconsultants.com
From: Jim Granville on 9 Sep 2006 17:11 Walter Banks wrote: > We wrote the C compiler for thread based engine controller that > was used to program most of the current automotive engines > (eTPU). Most of the engine controller implementations that I > have seen do not have a single line of asm. The compiler can > however generate every individual machine code from C if > desired. (It is one of our tests) > > I agree with the basic point about the time critical nature of engine > control software. Does anyone know if the new V1 Coldfire cores from freescale will include eTPU capability (or is that pruned in the cost-down) ? -jg
From: Didi on 9 Sep 2006 17:16
> Sure. But often we have to make do with the bare bones in CPU resources. > Turn every dime around and around. ... That would make a real lot of dime turning... to save the few % power (which you are bound to have anyway in your system if it can do the task synchronously) it takes to do simple things like separating buffering, processing and real time actions... Perhaps an option if you have no real programmer around, I don't know. > Many times we use uCs as state machines and then they have to perform > the same way as if we had done it in logic chips. IOW totally > process-synchronous. You certainly don't need to do those state machines 100% synchronously, you just need to make sure the output states change when they have to and you take the input signals you need. There is such a lot of mechanisms to do these things I really have a problem to pick an example, perhaps a good one would be the output compare timer mechanism introduced to me many years ago with the HC11, or FIFO sort of things etc. It takes no programming genius to do most of these (but it does take some programming literacy allright). Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ Joerg wrote: > Hello Ulf, > > > >>>>>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. > > > > I would be much, much better to have a little extra performance > > and a more advanced timer which would idle the CPU until a condition occurs. > > > > #define CYCLE_TIME 0x4711 > > > > uint16 TIMER_CNT=0; > > uint16 next_top = 0; > > sbit(START_TIMER,TIMER_CTRL); > > > > loop > > TIMER_TOP_VALUE += CYCLE_TIME; > > // do something... > > sbit(WAIT_UNTIL_TOP_VALUE,TIMER_CTRL); > > __sleep(); > > end loop; > > > > Sure. But often we have to make do with the bare bones in CPU resources. > Turn every dime around and around. Then there is (usually) only one > timer besides the WDT which, of course, has already been taken. Just > like that big piece of top sirloin from the buffet. > > Many times we use uCs as state machines and then they have to perform > the same way as if we had done it in logic chips. IOW totally > process-synchronous. > > I have another app coming up that I am trying to do analog/mixed. But if > for some reason that doesn't pan out this would need three dozen uC per > system all doing the same thing but with other input data. > > -- > Regards, Joerg > > http://www.analogconsultants.com |