Multi-cylinder upgrade.

[TechColab]

Hi, from my understanding, for a multi-cylinder upgrade, the NanoEFI would need the following additions:
Fuel injector 16-bit timer + control pin + driver + connector & CDI 16-bit timer + control pin + driver + connector.
These all have a cost in terms of component count & PCB space, and are needed for each additional cylinder.
No single NanoEFI version would satisfy all users if it designed for too many or too few cylinders for their purpose.
I propose dedicating the NanoEFI's outputs to drive the common components such as fuel pump + something else.
Then use a daughter-board for each cylinder, with a PIC16F18424 (2 x 16-bit timers @ 32MHz for under 1 USD) with drivers for the fuel injector & CDI.
On boot, the NanoEFI just needs to look-up a config for the relative delay each cylinder has from main timing pulse, then send that 'offset' to each daughter board to incorporate that offset in its timers.
The NanoEFI does the calculations as at present then sends the same fuel_delay, fuel_duration, spark_delay, spark_duration numbers to each daughter-board by I2C or SPI.
Then sends the timing pulse to them all when appropriate. The NanoEFI does not need to be interrupted by the fuel/spark timing.
If desired, it can send updated numbers at any time.
Each daughter board just listens for new numbers, adds its offset, runs its timers & outputs when appropriate.
This will scale to any number of cylinders (W16?) without any additional stress or compromise of the NanoEFI board.
It also means you only need to make one version of the NanoEFI and one version of the daughter board.
Users only need to pay for the components their configuration needs & they can have odd firing orders like staggered-big-bang.
You can migrate your EFI from a one machine to another. Any accidental frying of a daughter board won't write-off the whole NanoEFI.
Lastly, you can easily just add another daughter board for common injectors like boost fuel, H2O, N2O etc.

[TechColab]

I knew I'd forget something: With each cylinder's fuel/spark off-loaded to a daughter board and the NanoEFI's PWM driver intended for the fuel pump, the other integrated driver could be used to drive a cold-start valve.

[Travis Nano]

NanoEFI hardware supports 2 cylinders natively (with future software updates). Beyond that, I think much of what you're looking to achieve could be accomplished with the existing hardware without major changes. The nEFI board will be inexpensive enough with volume that multiple ECUs could be synchronized to run a 3+ cylinder engine at reasonable cost, in much the same fashion that you've described. One ECU per even number of cylinders.

Configuration could be pretty easily coordinated programmatically between boards over WiFi. The master ECU would be set in wireless AP mode, and each slave ECU set to connect to the master in station mode. You'd have one consolidated point of tuning and adjustment through the master, which would in turn convey the appropriate values (offsets, tables, etc) to the slave boards. Each ECU would be responsible for operating its set of cylinders autonomously. I'm interested in experimenting with this later.

Keep in mind though, the focus of NanoEFI is on small engines, which are mostly 1 to 2 cylinders. Being able to accommodate 4 to 16 cylinders is getting out of the scope of the project. But, it seems like it would be fun to try all the same.

[TechColab]

If the nEFI boards become as cheap as a PIC with a pair of MOSFETs (<2$) then why not! (Though I still think PICs would be cheaper, smaller & consume less power).
Runtime signals from master to slaves would need to be by SPI, I2C or RS422, as WiFi would have too much latency (& unreliability?)
So if using nEFI boards for the slaves too, they could be cheaper by not populating unneeded components like the WiFi module.
The only hardware change needed to the current design would be to bring out an SPI or I2C bus on some accessible pins. In fact, for future-proofing flexibility, why not bring out both SPI & I2C on either side of the IAT/TPS/MAP/O2/FPX pins? That would enable a lot of options.