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.

> 4 rotor rotary engine with split ignition and staged injectors

Please tell me you've got a link to some place I can read more about this, I'm a huge Mazda fan.

> The category of person that is going swap out their ECU cares about sub-milisecond timing. FPGA's are good at concurrency and operating in this domain. 8-bit 16Mhz Arduino's are not.

Depends on their goals. I'd oersonally assume that most people who are considering a DIY-friendly ECU are either looking to replace a carburetor or gain better tunability on a vehicle that has an '80s or '90s era EFI setup.

It's not like anyone's suggesting this be used on a brand new car. It's a relatively inexpensive option for a tinkerer to play around with. I'd be willing to bet that a lot of the cars this will go in to shipped with 8 bit ECUs from the factory. Ford used 'em as late as the early 2000s.

Also for the most part the people who are doing this sort of thing don't need to care all that much about emissions or any of the other things that make production ECUs so much more complicated. All it needs to do is deliver the right amount of fuel and trigger spark at the right times. A carefully programmed microcontroller can do this.

> Check out this HCCI engine tuning algorithm which runs 240,000 samples per second to provide realtime feedback to an fpga/raspberry pi hybrid board. An Arduino just ain't going to cut it

Considering there are absolutely zero HCCI engines in mass production I don't think that's really a concern for anyone other than those developing the technology.

edit: to be clear, of course I am definitely not saying I'm in any way against a DIY ECU project supporting FPGAs, obviously they enable even more potential capability, but I think you're making it out to be way more important than it is for the market that's likely to use these things. This is basically an open alternative to MegaSquirt 2