Posts: 67
Joined: Mon Jan 27, 2014 12:26 pm
Location: London

Re: RPi as car ECU?

Wed Apr 20, 2016 10:29 am

Hi a-q
I haven't totally given up on the RPi since the software I develop on the PIC can easily be ported to the RPi if I can get in to embedded Lazarus and true real time code. You have picked up most of the important points and I considered dumping the SD card to use a flash drive plugged in to the USB port so it would be a key as well as the code holder. In your case of just wanting to control the fuel you might get away with the pseudo real time operating system Linux that you mention but for totally control of everything 200 uS latency is just far too slow since one rev of the engine at 6000 rpm is 10 mS. Fuel injection on its own isn't critical but a delay of 200 uS and looking at the graph variable delays would be no good for critical timing applications. On the PIC the interrupts have a fixed delay in the region of 10uS but with the RPi running in true real time mode would be 100 times less so ideal for the task. It will be interesting to watch your project. Good Luck.

Posts: 2
Joined: Tue Apr 19, 2016 5:38 pm

Re: RPi as car ECU?

Thu Apr 21, 2016 5:52 pm

Cheers nice to see you're still thinking about it.

I think I was a bit pessimistic about the SD card in retrospect. After all, they are using in 50% of mobile phones with no problems and these have to go through 3-axis vibration testing as part of their type approval, so I'm sure the SD card connections can survive the relatively lower vibration you'll get in a car, assuming the Pi designers used a standard phone-grade SD card connector.

A simple foam mounting inside the ECU box will take care of some vibrations too.

You're right about the real-time for fast stuff, I calculate 1 degree of timing is about 25us, which indicates that ignition pulses and advance would best be generated by dedicated timer hardware, if I want to go there.

Posts: 1
Joined: Tue Oct 25, 2016 7:23 pm
Location: North Carolina

Re: RPi as car ECU?

Tue Oct 25, 2016 7:31 pm first thought would be to use a Megasquirt as it is already generally configured and tested, but if I was going to go the route of a raspberry, I would do what a lot of the manufacturers have been doing, and go the multiple controller route. A controller for the engine, a controller for transmission (if electronic), a controller for the airbags and maybe for the ABS or traction control. That way a failure of one doesn't affect the others, and allows for incremental changes on one system, leaving the others intact.

If you are talking about an ODBII controlled car, what I have seen when looking for a way to program (instead of simply monitor) the systems is that you will need a very good grasp of AT commands and possibly need to be able to decrypt certain data strings depending on the car manufacturer.

For more than engine controls, this is a non-trivial endeavor, but one that if successful, would get a LOT of attention from the automotive DIY community.

Posts: 1
Joined: Mon Mar 20, 2017 9:31 pm

Re: RPi as car ECU?

Thu Mar 23, 2017 11:00 am

Hi Gents (Girls?)

Had the same idea, but then 2 years later ;-))

I would love to prove the naysayers that it could be done.

a_q : did you continue on this? Ruptor: did you get back to it later?

my first idea was to do this outside of a car: just build a stand for a motor (any would do, as long as it has more than 1 cilinder and preferable is watercooled), than hook up stuff 1 by 1: ignition, injection, flow meter, o2 sensor etc.

My reason for wanting to do so: I am not a car specialist, and haven't got a clue of what is involved. It also would make things easier to explain to others through a series of videos.

My ultimate goal would be to hook things up to my MGB with a B series engine. (british 50-60ies lump of iron)

Posts: 1
Joined: Fri Jul 14, 2017 4:57 am

Re: RPi as car ECU?

Fri Jul 14, 2017 5:15 am

Ruptor, glad to see you didn't let the negative ppl get you down. Reading that spurred me to join this forum. New to rpi but I am a mechanic. Ecu go out all the time. It's not life or death. A blow out scares me more than an ecu failure ever will. Looked into mega squirt? I'm curious if you could run their software with tweaks?

Posts: 9726
Joined: Tue Jul 17, 2012 3:02 pm

Re: RPi as car ECU?

Sat Jul 15, 2017 6:11 pm

What a silly thread this is. Some say making an ECU from a Pi is impossible or at least not sensible. Other say it can be done. The naysayers are told they are "dragged down by pathogens" or otherwise stupid and are losers.

Then we have this from sezyal:
So much nonsense BS and jargon split. There is no such a thing as realtime computer BS or non-realtime ,delayed maybe sleeping CPU! It doesn't matter at all....
Car is a mechanical thing, it doesn't need so fast processing anyways. Data you get from an oxygen sensor won't change in 1ms. Sensors are even not that fast.
So 1Ghz CPU is > DSP, microcontroller, realtime cpu(whoever invented that marketing term)
Which displays some ignorance and needs commenting on in case it leads readers astray.

"real-time" is a thing in computing. It is not just a marketing term. It does have a technical meaning. "real-time" is about the ability of your software to reliably hit timing deadlines. It is not about raw speed. As wikipedia says:

In computer science, real-time computing (RTC), or reactive computing describes hardware and software systems subject to a "real-time constraint", for example from event to system response.[1] Real-time programs must guarantee response within specified time constraints, often referred to as "deadlines".

Systems like Unix/Linux are not designed to provide real-time guarantees. Rather they are designed to optimize throughput for a multi-user, multi-process, system. Often to the detriment of real-time behavior.

Anyway, I suggest the scientific approach. If one feels building an ECU from a Pi is a sensible goal and can even be done, then just try it. Please report back how it goes.

Posts: 2
Joined: Thu Dec 22, 2016 1:36 pm

Re: RPi as car ECU?

Tue Oct 17, 2017 5:51 pm

I am building a 70 C10, I have a long ways to go. But I had some interest in using a RPi3 for some control ideas. there are some "car computers" out there that get most of the items I was thinking about done, however, they stop at tuning control and reporting issues. One of the ideas I had was from aftermarket ECU's that allow you to tune your engine on the fly, say to get better gas mileage, better torq ot more horse power. I was thinking of using the RPi3 as more of an interface to an aftermarket ECU for those purposes. This may also allow for monitoring critical systems and setting the RPi3 to take action in multiple ways such as to warn the driver of certain conditions and to take proper action I.E. overheating - displaying the coolant temp. and warning of overheating plus if the heat reaches a pre-determined value it could shut down the engine. The ECU would still handle it's responsibilities, the RPi3 would augment it as more of a user interface. Plus all of the other features that the RPi3 could handle easily - lights, environment, radio, GPS, trouble codes (not just the code but which unit is causing the code, clearing them etc...) just to name a few. Here is an example article about tuning ECUs that may be helpful. ... cu-tuning/

Posts: 2
Joined: Mon Aug 22, 2016 11:05 pm

Re: RPi as car ECU?

Fri Nov 24, 2017 1:39 am

Car ECUs need several key things...

1.) Fast boot time + RTOS.
2.) Hardware-assisted programmable timer units (microcoded TPU, etc.)
3.) Execute out of ROM (flash, PROM, etc - plus or minus cache).
4.) reliable non-'consumer" semiconductor processes. Older silicon processes
much more trusted. Complete different product/development/sales channel
often better than avg "industrial" spec.

Also most every production ECU I know of (my knowledge drops off early 2000s
but convinced still pretty true today) runs code out of flash ROM directly - perhaps
thru cache, but there is no "copy from file into RAM then run code out of RAM".
That just generally isn't done in the real embedded world, esp where minor errors
can glitch driveability and/or cost the manufacturer millions of dollars in fines for
emissions incidences. So there is true XIP.

After a certain point, "high calculations MIPS" in a CPU is far less important than
ultra-hardware-real time control. You can run an entirely competent ECU with a
relatively low MIPS CPU as long as very accurately-scheduled pulses are generated
for spark timing and injector on/off in relation to engine position. So the multichannel
microcoded timer module is the actual pulse creator & "engine position" determiner;
in the background regular CPU algorithms can run at a slower rate and serve up
these scheduled pulses calculated on airflow, manifold pressure=calculated load,
RPM, various temperature measurements, etc. These updates can happen at
the whole engine cycle level instead of "fraction of engine cycle". The timing processor
does very little adaptation other than what's prescheduled - sure, it can do early
fuel cut or some anti ping retardation on load change as "emergency", but calculating
WHAT spark/fuel measurements required mostly goes back to CPU.

Entirely competent engine controls were done with small microprocessors even into
mid 1990s - the 8061 CPU in Ford engines was a good 16 bit CPU that had elaborate
high speed I/Os with CAM memory, for example [that architecture was an Intel 8096
variant]. Quite a few fast 8051s were used with a "PCA" (programmable counter
architecture). In Japan, 8 and 16 bit versions of the 6502 (Mitsubishi MELPS 7K?
series had their own special complex pulse timer block and these were used in
many Japanese car ECUs, and so on.)

If you are gonna tune your car, find out how to hack the maps in your ECU's PROMs/flash,
if there's some "openness". If building a race car there are scratch-tunable ECUs built
with proper architecture and parts selection.

If you are going down the BeagleBoard, RasPi, etc. route and with Linux, you are doing it wrong.


Posts: 1
Joined: Tue Mar 06, 2018 12:39 pm

Re: RPi as car ECU?

Tue Mar 06, 2018 1:25 pm

Im new to the Rpi forum,making this my first post,

I have experience on the ECU side of things and would like to pass some knowledge on about ecus and what to do about some of the challenges you will face with running Rpi as an ECU.

All examples i give will be for 4 cylinder with displacement of 2000cc's,equipped with sequential port fuel injection.sequential coil on plug.

The load is determined by 2 sensors,TPS and Map,so thats throttle position and manifold pressure,wide open throttle = no vacuum/atmospheric pressure.

Part load is where the focus should be,this is where driveability matters.most processor loads are at part throttle,between 1200rpm and 4000rpm,since regular drivers drive in this range more than 80% of the time,accuracy matters in this load range,the resolution should be very high here with good attention to detail.

Load ranges 4000rpm to 7000rpm,you can decrease resolution in these ranges,fuel timing is not critical here,ignition timing becomes primary focus.

Idle is never a problem for even a slow cpu or microprocessor,unless you need rough running correction or cylinder specific timing values,then dont worry about realtime too much here.

I suspect you will need a separate microprocessor to do timing curves,only reason is to implement a failsafe with a default in case of something goes wrong,you can use the Rpi to calculate the correct load and then send values to microprocessor,no value from Rpi = default = failsafe.this method is used in various ECUs to keep things in check,same method should be used for turbo controller,keep it separated and use the failsafe!!!

The fuelling can be controlled from Rpi itself,pulse width accuracy is important,but not the timing of it,you will have a whole 40 degrees crank rotation to "time" the fuel,usually with modern engines,a few deg (2-5 degrees) before opening of the intake valve,depending on intake and exhaust valve overlap,then about 35-40 degrees since the intake valve starts opening,so anywhere in that range will give acceptable higher rpms this does not matter and save yourself the trouble of implementing sequential fuelling above 4000rpm,you will not need it,fire 1 and 4 together,and 2 and 3 together,same for ignition coils.

Hope this helps!!!

Return to “General programming discussion”

Who is online

Users browsing this forum: No registered users and 5 guests