Note: the router board is in early development, and not available yet. It likely won't be publicly available this year.
The router board is a add-on circuit board for MegaSquirt-II which converts the MegaSquirt-II batch injection pulse to a sequential setup, then 'routes' this pulse to specific injectors based on the instantaneous crank angle (this requires a crank wheel and cam sync).
Think of it as a sequencer and router/driver circuit. This can be extended for coil-on-plug (COP) ignition as well using timing signals for advance. The immediate advantage is that all existing MegaSquirt® installations can easily adapt to this by running the injector signal and timing signal to the new circuit. The router board can interpret the crank wheel signal and provide the tach signal back to the MegaSquirt.
The idea for the board is extremely simple, use a timer input capture port to measure fuel pulse width from MegaSquirt-II, (or any other programmable CAN enabled ECU for that matter) and then simply "route" this width to a specific injector based on crankshaft and camshaft position. The same can be done for ignition signals, but using the duration of a spark pulse signal for relaying the advance (relieving MegaSquirt-II of the strict timing requirements).
The router board gives us trigger wheel decoding, cam position sensing, sequential FI and COP with a CAN connection.
It will work with any reasonable toothed wheel, crank, cam or both, so you can get sequential individual control of cylinder fuel and spark. It will:
If you have a V10, or even more cylinders, it shouldn't be hard to use two routers and make one a slave to the other.
The router uses the MC9S12XDP512 microprocessor, and is independently configurable in the sense that you can put in trim tables for individual cylinders, plus all the info needed to interpret the signals from the toothed wheels. These will come through MegaTune/serial port just like now. It will get any other parameters it needs (eg, spark polarity, number of injectors) from MegaSquirt-II via CAN at startup.
The critical issue is that a fast processor is needed to handle, something like a 360 tooth wheel at 10,000 rpm, for example. The plan is for the router software to incorporate an algorithm that will allow it to handle any type of missing tooth crankshaft wheel, including those with several added/missing teeth at various locations.
It might be possible to provide the advance and fuel injection pulse width over the CAN communication network, so that direct timing measurement would not be required. But this will not work for MegaSquirt/MSnS-E because of the lack of CAN, so timing pulse measurement to obtain advance/FI pulse width will be needed for these. So a different mode would still be needed that measures the FI pulse width output. Expect to see both modes available (CAN and PW measurement).
There will be 8 injector channels and 8 ignition channels. These will be triggered based on crank wheel position, based on a running crank angle variable which is incremented at a rate to match the crankshaft angle in real time. This variable is corrected on each tooth received event.
So, all of the channels will have entries based on crankshaft degrees which trigger on crankshaft degree value. There will be individual entries available, so if you want all 8 injectors to open at 10 degrees crank then put in 10 degrees in all 8 trigger positions. More likely one would spread out the time over the crankshaft position that makes sense.
Note that there are some events which are based on crank values which are at the end of the pulse. For instance, ignition firing (when the pulse ends) needs to be timed to crankshaft position, but the dwell charge period(when the pulse begins) needs to be a fixed time interval (like, say 2 milliseconds), so a little calculation will need to be done each time the crank rotates to update the dwell time based on RPM and any occurring crank accel/decel values.
So, think of a rotating crank with "events" that occur based on position from 0 to 720 degrees. The user can set the channel events position directly.
Its a sure thing that the router board will have an FPGA (field progammable gate array). In fact code is being developed for it right now to handle crank-angle measurement. Probably the target device will be an Altera Cyclone, probably a 1C6. The reason for Cyclone and not Cyclone-II is that the first one has the multi-volt I/O which can handle 5V (via series current limit resistor). The output state mode can be set to open-drain mode, so a pull-up resistor to +5V will allow 0 to 5V swings. Since we are dealing with microsecond-type signals this setup is fine and eliminates the need for level translator chips. It also comes in a 144-pin TQFP.
The density of the Cyclone EP1C6 is more than sufficient to handle crank-angle measurement, and the size is not excessive such that power-on configuration takes too long.
For the processor, its still up in the air a bit. It would be nice to have a TQFP package for board manufacture. BGA is not out of the question but the board assembly and inspection costs go up. Also, routing BGA will require at least a 6-layer board, probably more - and this adds to the cost. So this requirement (and non-automotive temp parts) eliminates Xscale, i.MX, PowerPC
We looked at the ARM offerings, like Atmel, Luminary, Phillips LPC, etc. but each appear to lack enough hardware math functions (like hardware divide). There is TI 240-family that looks interesting. So does the new Coldfire single-chip version MCF322x.
However, the other requirement is automotive-temp, which starts throwing out some the list above. So it starts narrowing down to the HCS12X and Blackfin. The HCS12X has the math but the CPU tops out at 40 MHz. The Blackfin BF536 runs at 600 MIPs, but there is no H/W divide. You can get the Blackfin in TQFP and a BGA package that is real easy to route (there are 4-layer boards using the BF).
There are GNU tools for the HCS12, but not for the HCS12X Xgate module (yet). And there are GNU tools for the blackfin (blackfin.uclinux.org).
Of course, we want the biggest processor available, with hardware floating point. Since we want to experiment with ion sensing and peak detection without having to play games with assembly code optimization, etc. this may be the way to go. Probably the best one in automotive temp (at least to 105 deg C) is the Freescale MPC5200B, at 760 MIPS it screams. And there is a "automotive-grade linux" (AGL) from Freescale that operates on this device. The AGL is targeted to telematics apps and not towards powertrain apps, however the latencies are low enough that it may be possible to use, particularly since the FPGA is handling the critical wheel decoding/routing.
Using the MPC5200 does raise the board cost somewhat (~$50), but the resultant processing power capabilities is significant. The Blackfin may be sufficient as well, and would be a bit easier to lay out and lower cost, but there is no floating point. And the HCS12X is most likely more than sufficient for the task.
Links: