Thanks for your interest!
I didn't want to be dependent on the number of hardware timer captures, so I did actually start with a system like you describe, with a single timer/compare and managing a linked list of upcoming events. On compare interrupt, it would iterate through any events that had passed in time, carefully setting the compare register each time to avoid potentially missing any changes. I actually thought it was pretty straightforward, but it had the effect of skewing similtaneous outputs: Each iteration cost almost a microsecond, so having 4 similtaneous changes would actually be splayed over 3.5ish uS.
Instead I am now effectively bitbanging the outputs with the dma controller. I manage a circular buffer of gpio pin changes (16 bits for "turn on", 16 bits for "turn of") for about a 128 uS window, and the DMA reads on a .25 uS interval from that buffer. There is a lot of complexity in ensuring the buffer's contents is accurate with event changes in a race-free manner, and testing that sufficiently has been where I've had to put most of my effort.
I appreciate that FPGAs are certainly one way of doing this, and your point are valid, but I respectfully disagree that it is an overall better approach. FPGAs are more expensive than these microcontrollers, are a separate device to program, and now mean you have to maintain both software and RTL together. I also don't believe that any of the issues you describe are very difficult to do in pure software:
- reconfigurable pinouts, why is gpio muxes not the same? I understand that if you want to be extremely flexible with pwm'ing peak and hold injectors, that is probably easier with an intermediate hardware interface, but all the other output settings seem trivial to change in software
- I would argue parallel computation isn't really even necessary. These chips are fast, and the computations aren't that intense. That aside, I personally manage that parallelism by using the dma controller to bitbang outputs
- Chained high resolution timers -- I'm not really sure where you're going with this. I personally dma input capture timestamps, and can't imagine needing more precision.
- PID and other software. If you're talking about an AVR, I completely agree that these chips are largely too anmemic by themselves, and extra hardware would help. A modern cortex m4 or m7, however, has plenty of oomf, and it all goes back to maintainence cost of software vs RTL+software.
Either way, FPGA's are certainly a valid way to solve these problems, but personally I like not being locked into specific hardware arrangements. My design is just a hobby design that nobody should use, but it can easily manage 1/4 uS output precision with plenty of spare cpu capacity.
edit: as an additional aside, its pretty hard to have a free and open source project if you depend on an fpga. The toolchains are all proprietary, which would limit the goals of a project to something like the lattice with the icestorm toolchain.
Fair enough. Having an FPGA can certainly make various aspects easier (especially for supporting higher precision outputs), but shouldn't be necessary for basic engine running.
As I understand it, most of the difficulty in modern engines is the tuning anyway. No longer is it just a VE and lambda table, there are so many dimensions that need to be taken into account for a stock car (variable valve timing or lift, electronic throttle control, etc), to get excellent emissions.
I'm not aware of any aftermarket EMS's using FPGAs, and there are quite a lot of them. The engine position sensing isn't something that requires a lot of specialized hardware: The sensors are usually one or two reluctors or hall effect sensors that give, say, 12 to 64 clock edges per engine rotation. Determining engine position is pretty easy with most microcontroller's built-in timers. I know that megasquirt, and freeems use hardware timer capture inputs for this purpose.
It is certainly something that is easy to cause engine damage if you get it wrong, but the application for these is usually offroad vehicles. There is a community of people that do convert their engines to use these systems. I've eyed rusefi for a while, I've personally used freeems, and even started to write my own EMS for fun (https://github.com/via/viaems/).
I don't think engine position sensing has changed even with the most modern engines, though the direct injection engines certainly have more specific timing requirements for fuel injection.
Instead I am now effectively bitbanging the outputs with the dma controller. I manage a circular buffer of gpio pin changes (16 bits for "turn on", 16 bits for "turn of") for about a 128 uS window, and the DMA reads on a .25 uS interval from that buffer. There is a lot of complexity in ensuring the buffer's contents is accurate with event changes in a race-free manner, and testing that sufficiently has been where I've had to put most of my effort.