DIYEFI.org Forum

newtyres1 wrote:I feel a wideband controller is the last thing you would want on the board, as they are still evolving. Probably similar with knock detection. That would make MS3 a good example of built-in obsolescence. How about just doing ignition and fuel really well, KIS, and leaving some I/O (and RAM/flash) for things that are evolving. Thinking outside the square maybe a double row of header sockets for "evolving MS3 plug-ins" (e.g. EGT, knock sensor, etc) would be an idea but maybe not practical.

Ian.

I couldn't have said it better myself!

Fred.

Certainly! I'm a fan of "suggested builds", or "support cards", keep it modular.

Certainly an EGT/AFR/ETC card, and a version number, would be great.

Then people can use version 2.1, and if they make a change they propose version 2.5. Then your computer stays upgradable, while still being "standardized" to retain supportability and as a sanity check. Also it makes it easier for people to actually DO something - instead of seeing a schematic and trying to hack out their own custom near-copy.

As i was saying back in January here...

ababkin wrote: First off, i am the proponent of having all the extra (non time- and safety-critical) stuff to be on a separate CPU/MCU, to offload all the extra number crunching off the main CPU as well as remove the risk factor of the extra non-critical code somehow undermining the safety of the critical code. This is of course a luxury at this point (having 2 CPUs, PCB's etc), but should be considered for the final "bullet-proof" solution nevertheless.

That would be all well and great, but what do you do with the 60 I/O pins on the injection/ignition/rpm/engine position CPU that aren't needed for those three functions? Waste them? I would prefer to use them, and I see no good reason not to. All things that aren't time critical just get done when the CPU isn't doing something more important. Hooray for interrupts :-)

Fred.

Admin wrote:That would be all well and great, but what do you do with the 60 I/O pins on the injection/ignition/rpm/engine position CPU that aren't needed for those three functions? Waste them? I would prefer to use them, and I see no good reason not to. All things that aren't time critical just get done when the CPU isn't doing something more important. Hooray for interrupts

Fred.

I do know exactly where this IO hunger/greed comes from
(and don't get me wrong, i also like to minimize waste)

Interrupts are all nice and good, but things done in main loop would also need to be snappy, which is inversly proportional to the IO handling count.
To handle many IOs while keeping time-critical non-interrupt things realtime (like the teeth counter/decoder for instance), we'd need to introduce concurrent loops with various priorities, etc. This increases complexity and introduces the risk of concurrency issues (like deadlocks, livelocks, racing, etc, and no you cannot test of even debug this easily) - the risk that i didn't want in the critical part of the EMS.

If that's the concern, get a smaller, dedicated chip for running the motor, and keep the i/o laden one for running the periferals.

Things like wheel sensors, etc, might overwhelm the cpu with interupts if you have a 40 tooth crank, 4 tooth cam, 100 tooth x 4 wheels, 50 tooth driveshaft, etc... Figure that's (per minute) 8000 rpm x (40 + 2 + 100x4wheels/4rear-end + 50) = 1536000 interuprts per minute at top gear, full tilt, low geared car. Can you run 25600 sub routines per second? It's over 3 thousand cpu cycles per interupt at 80 mhz.

My feeling is you would still use most of it on the chip. If I were to offload some things, it would be stuff like a wheel speed sensor. Perhaps you can get away without an interupt and merely have a counter you poll. Certainly various interupts take priority over each other, which does mean some debugging.... And honestly many of the things I would want a high amount of i/o for is low rate stuff: updating guages, turning on lights, enabling cooling fans, air conditioning.

The best thing to do is write some sub routines which do some generic math, light a light or something, and bang the chip at 30 khz with interupts out on different pins (I guess you could have it interupt itself if you're short on ways to drive it.

One must be careful what exactly they assume ;-)

For example, assuming that the fuel, advance and dwell calculations will be done in a slow "main loop" might be a touch foolhardy :-)

The chip is only 40MHZ though, not 80, and I really like the idea of a secondary chip taking care of heavy interrupt loads like wheel speed and driveshaft speed sensors. I like it a lot.

Like Flacid says, most I/O stuff is low speed and takes little to no calculation. Bit banging the LED's at the moment for example is a very fast process indeed. The sleep loop does 3000 iterations between doing anything for 1ms each loop uses more than one CPU cycle.

Fred.

There might be more overhead in actually realizing a situation like this (see, I'm trying to pace myself and not say everything at once) but what I really had in mind is a chip that would count and get polled, but if it saw more than x counts per second, or varied in rate by more than y amount (per second^2) it could interupt. Having to set that would suck, maybe. But, maybe not.

The more automatic it is, the more time is saves - and the more possibility for errors.

Bump for everyone to read the first post!

Fred