Raspberry Pi as an Automotive ECU

[psyolent]

OK, so lets clear things up. I think like a fruitcake - ask HQ355 aka Cheesy. ie: very out of the box / people may call me eccentric.
I have a busy mind which gets messy (GAD, Depression, etc) from time to time so I find thinking a good way to keep it busy.

So, no
-i don't want a digital dash
-i don't want a data logger
-i don't want an mp3 player/in car video player/pr0n remote surfing device
-i don't want a wifi pineapple for wardriving and remote hotspotting (well not using this rPi anyway)

Given the current Pi is nearing on some fairly decent specs with enough memory, CPU cores, expandability for additional inputs and outputs - i can't find any reasons why this couldn't be done, except for whether the Pi would be able to process in real time enough 'real time' parameters to have a complex ECU, but, may be able to match/lookup given a set of input parameters a set of tables (fuel, air temp, spark, ignition) and provide the required outputs.

In simplest terms if we think about single point EFI, using a non ECU controlled distributor, we have as inputs
-> throttle position (load)
-> spark event (negative coil)
-> we could use MAP as well (thinking v0.2)
-> water temp (v0.2 for cold starts and hot enrichment to make things safe)
-> air temp (v0.2 as above)

as outputs we need
-> a pulsed output to a single fuel injector (lets avoid PWM for simplicity in v0.1), just simple on off. we have fuel pressure behind it, it just needs to be switched off at the right amount of times and kept 'open' based on the load setting read from map

if i take input variables from all the sensors, match them to an array surely an rPi could pulse this sucker fast enough?

discuss/flame away.

[antus]

Its certainly possible, but a lot of work. You'd need to implement a lot of algorithms to end up with something better than the most basic after market computers. You could probably learn a lot from mega squirt. Do consider enough protection that when a wire breaks and shorts in the engine bay your Pi doesnt explode and doesnt stop running, and your code handles the error sainly and goes in to backup mode. Consider very carefully interrupt priority so that you can deliver accurate spark timing. You will need some tools like a scope which you can use to measure delays between setting an output and when the signal actually happens. Code bases like our '808 have this type of stuff built in and its required to keep your timing accurate when there is a lot going on.

You can get the megasquirt source here, but note that the license would prohibit using it on other hardware. Having said that its a good way to get an idea about algorithms and generally what you need to do.
http://www.msextra.com/downloads/dev/ms3/

There is also delco PIS firmware here http://pcmhacking.net/forums/viewtopic.php?f=27&t=476

The author seems to have disappeared and nobody had any luck connecting to this firmware running on a real device. Also the project is far behind 12p in terms of functionality. But from the point of view of fun and tinkering it is something you could pick up, get working and keep developing on the '808 hardware. Once you figured out the connection issue then you could figure out what algos you want to add next.

Edit: you also want to make sure you have good power supply filtering and source voltage of up to 15v and maybe above wont damage anything, and also very noisy power is smoothed enough that it doesnt cause issues either.

[psyolent]

hey mate, thanks for your input. was hoping you would
i hear you on the filtering. rPi needs 12v 2A, figure CRC, LM7812 and CRC will help smooth things.
good call on the fused inputs post sensors and default values in case one goes pear shaped.
will have a look at some of that other work as well to see where folks have got to.

[antus]

Does it need 12v? 8-9 isnt that uncommon while cranking even if its not what should be happening.

[psyolent]

yeah. they suffer when voltage fluctuates.
its also something that would need to be constantly powered like the existing ECU so whatever code is running on it is ready to get input.
easy way to let it know things are happening is a sense from 'sta' to say things are about to get real

[Chuff]

So as a car ECU, the Pi isn't looking too good.

But as a multimedia front-end running Kodi (formely XBMC) it fuckin' rocks!

But that's a whole other discussion.

[Jayme]

So as a car ECU, the Pi isn't looking too good.

But as a multimedia front-end running Kodi (formely XBMC) it fuckin' rocks!

But that's a whole other discussion.

haha sorry to get too off topic, but thats exactly what my rpi2 is being used for! I especially like the ability for the Pi to link to the tv through the HDMi cable and have remote control commands from the TV remote sent through the hdmi cable to kodi = one remote

[slewinson]

yeah. they suffer when voltage fluctuates.
its also something that would need to be constantly powered like the existing ECU so whatever code is running on it is ready to get input.
easy way to let it know things are happening is a sense from 'sta' to say things are about to get real

Getting a well filtered and stable 5volt supply from a car's 12V is not too hard at all. I see the biggest issues being protecting the inputs from spikes and noise, closely followed by getting the code to run in a deterministic manner where you can count on the timing of things happening. with the Raspi I don't think that a linux based solution will provide this.

On the other hand, using the Raspi as a frontend and calculation offload has a lot of merit... Picture this - 808 has the core code to fire injectors and do the sparky bits. Raspi sniffs the analog and digital inputs at the Delco CPU and does its thing, calculating and using maps to derive final advance and injection timing numbers that are passed back to the Delco to drive the hardware. Same could be done for the IAC steps. Driving a flex output and getting more information from analog inputs could be done by the Raspi itself. Failsafe could be also handled by the Delco with a basic map in the memcal that provides driveability if the Raspi craps out.

This would provide the best of both worlds - OEM hardware doing the hard bits and a flexible, customisable interface with lots of grunt to do the calculations and also provide a real-time tuning interface in the car with little hardware. Data logging would also be a snap with much higher resolution and data rates available.

I am good at the big picture design work but am way too rusty to a lot of the coding.

Flame away.....

Simon

[psyolent]

deterministic manner where you can count on the timing of things happening. with the Raspi I don't think that a linux based solution will provide this.

funny you should mention this. must be psychic or something. oh wait. was thinking about the exact same thing on the way home Simon. the interpolation between maps and then calculations to provide an output to modify an injector 'pulse' time i think would stretch the limits of what something like python or perl atop atop a debian OS would not be able to do quickly enough. the idea of mapping and logging though as a piggyback into the existing sensors however, would not be too much of an ask although some fuckery with A--D conversion might, again stretch the limits. interesting nonetheless. thanks heaps for your input.

[antus]

It could be done, but would but as you say ideally closer to the metal than a scripting language. Best preference would be with a real time linux kernel (such as used in real time audio mixing, and other time sensitive firmware). Otherwise you could do it in C, preferably with root but even without. Either way you'd need to tune kernel scheduling to make sure timer driven stuff has the most priority. You would need a high precision clock source. All in all though, I think EFI is best done in firmware straight on the hardware as the OS introduces complexity which complicates the problem space.

https://rt.wiki.kernel.org/index.php/Main_Page

And referencing the tagline of that page back with post #1 of this thread...
"Controlling a laser with Linux is crazy, but everyone in this room is crazy in his own way. So if you want to use Linux to control an industrial welding laser, I have no problem with your using PREEMPT_RT." -- Linus Torvalds "