AFM measurement/backpressure (was Turbo speed sensor)

[Mike (Perth, Western Australia)]

At 05:40 AM 9/3/2000 -0600,  Tom Sharpe <twsharpe at mtco.com> wrote:

>> Well I think it is - for a reliable realtime o/s and scheduler its helpful
>> to have lots of grunt - given the typical overhead a really good o/s
>> introduces into the overall responsiveness.
>
>I kind of agree, but I rather see several small/fast processors (pics?)
handling
>those "extra" functions, ie. sampling and filtering each sensor (or pair),
>producing a set of outputs for the main processor to use.

Hi, just saw your email in overloaded in box,

Distributing functions is great and has heaps of advantages, the problem
we have with available devices is the method of transfers either use lots
of bus lines, registers, latches or use serial methods which are slow and
require devices to support more or less proprietary protocols, like SPI.

One 'kernal' however still needs to provide most of the high end functions
for overall control and therefore needs to be 'aware' of all process
variables relevant. Ive found that using SPI can simplify the software
a little and provides more elegant top-down type design in firmware.

In the setup I intend using, the main CPU handles all sensor inputs,
data logging, security and injection drive but off loads the ignition
to a slave cpu, synchronised through a single TDC pulse and tokens
passed via SPI. Another slave I intend using for auxilliary injection
for dual fuel, water injection and turbo control...

Rgds

:) mike



----------------------------------------------------------------------------
To unsubscribe from diy_efi, send "unsubscribe diy_efi" (without the quotes)
in the body of a message (not the subject) to majordomo at lists.diy-efi.org