Hacker News Reader

> I'm not aware of any aftermarket EMS's using FPGAs, and there are quite a lot of them.

Engine management has been using PLDs/FPGAs for years.. look at Autronic, Syvecs, Pectel, and a bunch of research engine management systems that are too expensive for mortals to buy. If you're building something in 2020, you'd be shortsighted to not put an FPGA between the engine position inputs, and your time-sensitive outputs.

> The engine position sensing isn't something that requires a lot of specialized hardware ... Determining engine position is pretty easy with most microcontroller's built-in timers.

Modern engines are not mechanically monolithic. Cams and cranks are coupled, but they're subject to tolerances and are affected by things like acceleration, belt stretch, and harmonics at different RPM ranges. Determining what's /actually/ going in inside an engine with any accuracy is not easy at all; thinking otherwise is naive.

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

I don't see a connection in the two points of this statement. The 'offroad vehicles' I work with, have engines that are 10x the cost of the 'onroad' equivalent.

> If you're building something in 2020, you'd be shortsighted to not put an FPGA between the engine position inputs, and your time-sensitive outputs.

Why? Without supporting information this sounds like cargo-culting. What are the timing requirements and why can't they be achieved with current microcontrollers?

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

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

These guys[0] are building them in the US. There's also Pac Performance[1] down in Australia.

[0] http://www.definedautoworks.com/mazda-rx7-engines-4-rotor.ht...

[1] https://www.pacperformance.com.au/

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.

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: https://www.raspberrypi.org/blog/machine-learning-engine-con... - at $40 for an TinyFPGA BX it's probably worth it vs the Arduino pro-mini at $10 if you're going to tune something worth more than $1000

> 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

>Depends on their goals.

I'm in this demographic and am confused why are you selling me on something less capable.

>Considering there are absolutely zero HCCI engines in mass production

This is false and trivially googled.

>You're making it out to be way more important than it is

The parent was requesting a concrete example which quite clearly can not be done on an Arduino but is trivial with an FPGA.

> Considering there are absolutely zero HCCI engines in mass production

Mazda's really close, no? Skyactiv-X is supposed to be HCCI, I think.

https://ca.finance.yahoo.com/news/mazda-touts-gasoline-engin...

I'm fairly confident that Motecs line of ECU products all have FPGA's internally. I vaguely remember taking apart an old M400 and it having an FPGA. Thankfully their ECU manager software abstracts that all away from you.

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 took a look at your project and I have a question.

I see that you have support for driving 16 outputs with 250 ns accuracy.

Are you using a single timer+compare unit to do this?

I struggled with this a little when I tried to do a similar project myself, but I think I came up with an algorithm that allows me to do it with one timer and one compare match register. The reason it was a little difficult was because the timers usually only have one or two compare match registers, so you can only ever have one event pending at a time. This problem would be trivial if the timer had 16/32 compare match registers.

So, you have to maintain a list of upcoming events and always be sure that the next one to occur has its value loaded in the register. There are a lot of races to watch out for (like if the time for the next event already passed before being able to load its value into the register). This requires a bunch of write-read check cycles and makes me feel uneasy.

How did you handle this?

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.