Speeduino: Open-Source Engine Management

Because the FPGA makes your life easier,.. reasons off the top of my head:

- Trivial reconfigurable pinout for different input sensor and output driver use cases (e.g. DOHC direct-injected V6 vs. 4 rotor rotary engine with split ignition and staged injectors). The physical output drivers can be made universal, but making the software dynamic and correct is challenging. No, being able to reconfigure GPIO muxes on an AVR isn't the same.

- Truly parallel calculations (e.g. engine rotation modeling, engine aspiration modeling) and parallel driver outputs. Possible in a multi-core "microcontroller", but now you're synchronizing things.

- Ability to easily create complex chained high resolution timers for input capture, and outputs. Certain microcontrollers have hardware to do this (e.g. STM32F334) but you're limited by what the designers had in mind (e.g. the F334 was designed for digital power conversion).

- Ability to do PID and other complicated math with sensor feedback in specialized hardware (see: parallel calculations above). Try implementing flexible knock sensing for a complex engine without a dedicated DSP. It sucks.

It's one thing if you're building a product for production, with one specific application and pricing constraints, but these aftermarket ECUs tend to have many applications as almost every use-case is in some form a 'one off'.

FPGAs are cheap now. It makes sense to use them. They help prevent you from having to write a ton of interrupt handling code that looks like node.js call-back coleslaw.

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.

We can agree to disagree on engineering choices. I've been working on/with aftermarket ECUs for just under 20 years, and I'm sharing with you what I've seen from being "in the trenches".

I'd say it's generally a good idea to stick to "bolt on" style modifications at most for any vehicle you need to count on. Save any real deep tinkering like this for something you can afford to have out of commission.

Personally I'm now contemplating fuel injecting my gokart as a way to learn.

>A lot of car guys just aren't going to rip apart their wiring harnesses and do testing to make sure it'll work with their onboard sensors.

I'm not so sure about that.

My go-to mechanic is an older gentleman, late 60s, and oftentimes I'm surprised how quickly he updated his workshop to include electronics. He went from barely having a multimeter and not knowing how to use a computer in the early 2000s to having a well equipped electronics bench with oscilloscopes, scan tools, soldering equipment, etc. He told me he went to a bunch of courses to get updated on modern car technology because his clients started bringing newer cars. Keep in mind this is in a developing country (Mexico) so he has to keep repair costs down to keep clients, because the more affluent people will go to dealerships to get a proper fix. A lot of his repairs that I've seen involve what I'd charitably call "bodging" using parts that aren't original or intended, but they get the job done on a budget.

Similarly with car guys I hang around here, there has been a noticeable uptick in electronic knowledge, maybe not to the level of custom ECUs yet, but stuff like making an arduino controlled radiator fan or making a custom box to read the CAN-bus to get the steering wheel controls do stuff they weren't intended to do is pretty commonplace.

People working with cars are already used to complexity and learning new things, after all, so I don't think electronics will scare them off. We don't see as much of it yet because of all the lockdown and manufacturer's insistence at straight up replacing parts, but now that modern-style fully electronic cars (2010 or so) are becoming affordable enough to be "project cars" for average car guys, we'll see more and more stuff like this. A car guy might not want to rip into the wiring harness on his daily driver that he paid 15k for, but a 3k shitbox he bought as a second car for fun? Well, people are already doing that.