[Bulk] Re: [Diy_efi] Modular approach to EFI controllers

[Mike]

At 11:47 PM 10/1/07, you wrote:
>On Mon, 2007-10-01 at 20:37 +0800, Mike wrote:
>> 
>> Something doesnt quite gel in all those calcs, when I do a back of the
>> envelope event schedule I get a far easier less tortuous branch path.
>
>Do share...

Well its predicated upon s/w starting the event and int finishing it
and very little has the immediacy of coincidence, in between the
inititation and the microsec or so of int and flag tidy the ECU can do a few
other things, ah lah state machine fashtion...

>>  I'm not saying an FPGA inst good to have to off load the CPU but
>> having done very short int ack routines and state logic I dont feel
>> its that necessary.
>
>Well spark timing and so on could be done, but I want to run a proper OS
>on the CPU, and thats going to muck up interrupt latency unless I waste
>a lot of time going RT. Im sure it *can* be done, I just dont want to
>and dont feel that doing it all on the CPU gives as neat or robust a
>design.

When you say a "proper OS" what does that mean ?

My thesis back in 1982 was running the CP/M OS on a Z80 at 4MHz,
when the ignition trigger came in it switched the whole eprom/ram over to
another bank from the NMI for the CPU, that little bit was done by two
chips in hardware. The only problem I had was to run the floppy drive
if the engine was on. So if I needed to dump stuff to floppy I'd kill
the engine, minor thing in those days as there wasnt that much data
to save...

So by "proper OS", you can run anything but might need to be a bit creative
re what the CPU expects to find in memory and preload alternate "banks"
in RAM with things like stack return addresses...

What sort of OS ?

>besides, for the W16 twinspark twininjector engine, the timing
>controller needs about 90-odd pins of output, and finding nice small CPU
>packages that arent hard to solder with THAT much GPIO (before you add
>anything else into the mix!) is not so easy.

If you are worried about ECU size as a result of hand soldering then there
are piggy back boards for a few, but you can do hand soldering of the finest
ECU's with a little care, you just need a little extra flux because trying to
rely on the amount in the solder will result in blobs, also some extra flux
is a great way to force the extra solder to bead up and suck off, escp if it
happens to bridge a couple of chip smt pins etc


>> btw: Have you had the chance to draw a 16 line (W16 type) event
>> schedule and factor in the perishable nature of the data set and fact
>> you wont need sequential ion samples from all cycles at that 10K rpm
>> rate ?
>
>well with the exception of ion sensing, the 'overlapping' nature of
>which depends on the exact engine configuration, all the other events
>happen that often, per cylinder, per cycle. You could lose a lot of
>spark events with a wasted-spark system but that just doesnt fit my idea
>of 'neat'.

Not sure I understand how to reply to this one, um, even a V12 has not
much overlapping in terms of CPU having to do stuff, if it is able to
initiate an event such as a injector turn on then use the timer to turn things
off via int. Same for the dwell time for ignition, if a int for dwell happens
at same time as int for injector then give injector priority, as one uS of
variance for dwell isnt going to do much...

>The ion sensing I've gone as far as to allow four 'cylinder banks' - IOW
>four cylinders (on seperate banks) can fire at once.

Isnt the time slice for the ion sense to be pretty short upon spark initiation ?

Whats your estimate of required sample rate and over what period, 10 bit
A/D for that event would be sufficient are you thinking you need more bits too  ?

>Obviously, if your engine doesnt have more than one bank, you only fit
>one ADC to the board.

mmmm, Depending on what period of time you need data, one ADC per
side (bank of 6) for a V12 might be ample, but if you can pin down the ion
sense period criticality then if the sample window is short you can probably
get away with one ADC muxed for a full V12... (maybe just ;-)

Regards

Mike



>> But, sure once you do a FPGA to handle a W16 then it will of course be
>> backwards compatible with other engines no problem given a scalable
>> register/inst set etc. And good to have it as a redundant timer in
>> event cpu fails,
>
>:-)
>
>> btw: What sort of amortised cost does one end up with for such an
>> FPGA, just broad brush estimates at this stage and the hard outgoings
>> to get it up to a spec ? 
>
>To be honest, I expect that the timing generator will fit easily into a
>CPLD, FPGA is probably overkill (I have a habit of calling all field
>programmable logic stuff FPGAs, my bad.
>
>CPLDs are cheap.
>
>That said, whilst cheap is good, I prefer maintainable / clean / robust,
>since this is a more or less non commercial project...
>
>_______________________________________________
>Diy_efi mailing list
>Diy_efi at diy-efi.org
>Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi
>Main WWW page:  http://www.diy-efi.org/diy_efi



Regards from


Mike
Perth, Western Australia
VK/VL Commodore Fuse Rail panel that wont warp, twist or melt, guaranteed  !
Twin tyres for most sedans, trikes and motorcycle sidecars
http://niche.iinet.net.au