[1] https://github.com/noisymime/speeduino/
Speeduino started as a way of getting a DIY ECU that was far cheaper than what Megasquirt offerred and it's currently about 1/3 the price. It's not on the same level for features at the moment, but I do new firmware releases every 2 months or so with more functionality etc.
A question for any of you more familiar with this project: Does it support MAF sensors for measuring intake air? Or is this purely a speed-density system? Scanning the documentation, I see mention of different MAP sensors, but a search finds nothing for MAF sensors. If this is presently only a speed-density system, is support for mass airflow on the roadmap, or this intended to remain only a speed-density system?
The easiest way if you really want to keep the MAF would be to use a hardware based frequency to voltage converter and such devices do exist. Otherwise, any reason not to convert to MAP?
There’s actually a pretty good reason. I can’t imagine starting a new engine management project in 2020 without using an FPGA to interface with engine positioning sensors and outputs. Modern engines tend to be way too complicated to coordinate without paying close attention to your modeling of where all the fast moving mechanical bits are currently.
It’s cool they released this as open-source but the tech would have been novel circa 1992.
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.
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.
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?
The other major reason not to use one is simply because these days I'm not sure they're really needed. The 'high speed' inputs to an ECU really aren't that fast, even at the highest end you're only looking at somewhere around 16Khz. With high speed MCUs (70+Mhz) available for a couple of dollars, the value in the FPGA is somewhat limited given the complexity of adding them.
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.
A note: took me a little too figure out which MCU this is build around. Surely it couldn't be the classical AVR arduino, but yes, it's a ATMega 2560.
Personally I'm now contemplating fuel injecting my gokart as a way to learn.
If you, for example, improve airflow in your car drastically, or install larger injectors, or a high flow exhaust...the stock ECU code/maps may not be flexible enough to optimize for that. Also for bolting fuel injection onto an engine that was previously had a carburetor.
