| 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. |
- 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.