Intro / CPU types

Steve Baldwin steveb at kcbbs.gen.nz
Fri May 6 07:49:49 GMT 1994


Hi,

I am an EE in New Zealand (go down to Australia and turn left).
I guess I am specialised in embedded control and microcontrollers. I was
an Application Engineer for Philips for a few years mostly developing
development tools for 8051's et al.
I'm now back in the real world designing industrial controllers. 
My project engine is a little different. A blown Flathead V8. The main
intention is to piss off traditionalist rodders and have some fun
learning about the physics of combustion.
I've used quite a variety of microcontrollers and before we dive in and
declare that XYZ is the only true way, it would make some sense to
determine what capabilities the system requires.

For example, take a hypothetical, worst case engine and take some punts
as to what resources it will require.
Say a V8 running up to 8000rpm.
How many analogue inputs do we need ? What resolution is realistic ?
(Note the word 'realistic'. 34 14 bit A/D channels is a bit over the
top)

IMHO, the more you can stuff in a microcontroller, the better. There are
several uC's around that are intended for ECU use.

I'm building a completely automated astronomical obsrvatory at the
moment using a Philips 80C552. This would be an ideal candidate. 8051
core, 8 channel 10 bit A/D, 2 PWM, 3 timers (one with 4 capture/compare
registers), I2C (for EEPROM, RTC, etc), ports, blah, blah, blah.
Disadvantage - Only assemblers available for free (at the moment).

I have access to PCB layout CAD and can get good pricing on PCB's. I
also have a good relationship with the local component suppliers
(advantage of working for one the largest electronics manufacturers in
the country).

As for EPROMs etc. Flash is the way to go. Intel have boot block parts
and some others have sector erasable parts. This means that you can be
running from one section while programming another.

Oops !  Gone into waffle mode. Sorry !

Anyway.....decide what it has to do and _then_ decide what can do it.


Steve.



More information about the Diy_efi mailing list