Arduino/Raspberry-Pi Powered ECU Sheild

[poptones]

That old thing has obdII?

[agilly1989]

No... It has got no sort of diagnostic port or output... What I have decided to do is basically put the microcontroller in parallel so I can monitor voltages and such and log them to an SD card or even straight to A pc with serial data... But if I can simulate the same data sequence that is ALDL or OBD or any other kind of automotive diagnostic... I can just use pre-existing diagnostic equiptment

[saabman]

Just been reading through this old thread and was quiet interested in your ideas.

How did you go with it or did it go in the too hard basket?

I stumbled across this thread while researching the posibillty of doing something very similar but for a VW Kombi :lol:

Id love to hear where you got to with it.

Bernie

[agilly1989]

saabman (aka Bernie)

After looking at calculations, Power ratings and interference tolerance, PCB layers and design for high voltage/current.. Its WAY out of my depth

In the right hands and the right knowledge, I do believe it is possible (with a fast enough Microprocessor)

[Seg]

I've thought about doing something like this. IMHO this is totally do-able. Just get yourself an old parts car with a run-able engine, and experiment. Read up on engine controls, there's plenty out there.

An Atmel ought to be plenty fast to run TBI, though you may need to get a little closer to the metal than the Arduino libraries. Sequential injection may require something faster...

I once owned a rusty 1981 Lincoln Mark VI with EEC-III, Ford's first fuel injection system, and my research indicates it is in fact the very first microprocessor based ECU to make it to market.



This is a classic read on the topic:

http://www.langston.com/Fun_People/1996/1996ACW.html

Just imagine how difficult it must be to reverse engineer an undocumented engine computer. You'd need a PROM burner, a data-acquisition system, and a good scope, for starters. And maybe a logic analyzer...

There'd be no real market for a product here, there's already lots of aftermarket ECUs out there, and stock ECU's such as Ford's EEC-IV has been reverse-engineered to hell and back to do anything you want. But making your own would be quite the educational project...

[agilly1989]

Seg... As you might have read I was going to base it off an old analog-ish (I think the Lucas-Bosh system was an analog/digital hybrid) but the reverse engineering and effort/time started to become ridiculous.

I would LOVE to see a simple replacement (a direct replacement would be awesome) for older EFI systems, something that uses pre-existing cable harnesses that could "upgrade" a car to a point.

Adding data logging, custom curves and other things would be good as well

BUT alas... it got too much for me, health, work, time, life in general got in the way

[senso]

There are cheap injection kits for low capacity 4 stroke(and to some extent there is people trying to run them in two strokes), and even the made in china ones, almost always use Freescale mcu's with eTPU's.
Or you could do like Pectel/Bosch racing ECU's and assign all the time sensitive signal aquisition/generation to an FPGA and ofload the rest to a mcu/cpu.

[Ryan]

I'm a bit into this project as already.  I'm putting a GM TBI system on my 1978 Bronco.  If I get it working, I'll likely upgrade to a Holly TBI unit, but I don't want to drop that much money into it until I get that far.

Being TBI, it's not really that hard.  If I was doing full multiport that would be a whole different animal.  We'll see how this goes before I start with that.

Right now, I am waiting for a few more parts. 

I have gotten this far:

I am only running a Uno.  So far that hasn't been a problem.  I have it working on the bench with a fake tach line (Function generator), Fake O2 sensor (variable voltage power supply) and the output going to fake injectors (my oscilloscope).  Since my engine has a simple thermal switch that tells if the engine is warm, I don't need to know the engine temperature.

I built a separate circuit to provide the RPM to the Arduino to simplify the arduino part of things, and I should be up and going soon.

I have the parts on their way for the onboard power supply (with large capacitor backup/filtering) after regulation, high current driver for the injectors and input buffering/voltage range adjustment for the rest of the lines.  The throttle bodies (I got two so I could mess with one outside of the truck when the other is on the truck) are here, cleaned and ready, and I expect the adaptor plate from Summit any day now.  Hopefully I'll have more to report soon.

If this works well and seems reliable, I may offer it as a kit for people like me that are good with Arduinos and engines,  but don't want to give thousands to Accell/Holley/etc...

[Stonent]

Just wanted to mention that the Arduino "group" specifically forbids the use of Arduinos for automobile purposes.

That being said there are versions of the ATMega64 and 128 that end in C1 that are considered for automotive purposes.

http://spaces.atmel.com/gf/project/arduinoallegro/

There's also this project:

http://sourceforge.net/projects/arduems/

[agilly1989]

I'm sorry guys, I have since cancelled this project because of money and skills, but feel free to continue discussing it

[timb]

Just to add, the Raspberry Pi would be basically the worst choice for this. You need something that can handle real time tasks, which Linux (barring something with Real Time extensions) isn't good at. The first time a background process does *anything* you're going to miss an incoming pulse or have the PWM start skipping, which will cause your engine to lose power, miss, etc.,.

Also, Arduino isn't a good fit for this either considering the harsh conditions of living in a car (heat, cold, humidity, voltage spikes, noise which also applies to the RPi above). You'd also have to hand code all the interrupts and subroutines so you might as well just use a straight up AVR as the Arduino Libraries would be basically useless.

If anyone was thinking about this, I'd recommend something like a TI Hercules Safety MCU or similar (which is designed for mission critical applications, like automotive or medical) combined with a safety RTOS.

[Seg]

I think you're confusing an educational project, with a finished product. Just get it working with an Arduino, then move on from there. Ryan has the right idea.

http://c2.com/cgi/wiki?DoTheSimplestThingThatCouldPossiblyWork

Also I constantly see people insisting X can't be done on a Raspi, when they obviously haven't even considered writing a kernel driver. Writing Linux kernel drivers is not black magic. (Mucking in kernel internals can be, but not drivers.) The kernel owns the CPU, put your code in the kernel and you too can own the CPU.

[timb]

 

Yes, doing the simplest thing that could possibly work is generally the best idea. However, in this case, it's not. Would you trust a several thousand dollar engine or even your life (or somebody else's) to an Arduino or a kernel driver you wrote yourself with no prior experience? Because I wouldn't.

I can see getting a Safety MCU dev board and getting it working on that, then mucking about with auto-proofing and RTOSes. But why start on a completely incompatible MCU and have to re-write all your code?

As for what the Raspberry Pi can and can't do, I'm writing a book on using the Pi for Robotics and trust me when I say, writing a real, working Kernel Driver to reliably control the Pi's hardware in such a manner that it's appropriate for real time critical tasks might not be black magic, but it's not easy. In fact, I'd say that for most people it would be a lot easier to slap an MCU on top and let it control critical low level tasks while the Pi does all the high level processing. Just write some firmware that makes it a dumb slave and talk to it over SPI or I2C. Now you have a little co-processor that can even act as a Watchdog to reset the Pi if it locks up. (Plus an ADC, DAC and more I/O!)

To me, that's doing the simplest thing to make it work. 

[NiHaoMike]

What about use a small FPGA or CPLD to handle the timing critical stuff? Might also be able to use it to handle some of the failsafes.

On the safety aspects, put in a few hardware overrides (such as a drop to idle when the brakes are engaged) and it would be good enough for experimental purposes.

[Seg]

We're not talking about a new engine here. We're talking TBI engines from the 80's. You'd use a junkyard engine for your prototype. You can easily get a junky old car with a runnable engine for $100 or less in the midwestern US.

And I don't see how a buggy ECU is going to kill anyone. Worst thing to happen is maybe run too lean and detonate a cylinder. It's not actually that hard to run an engine, it's been done with primitive mechanical thingies called carburetors for ages. Running an engine optimally in all conditions, that's the tricky part.

It's presumed anyone doing this is already a motorhead, knowledgeable in the appropriate safety practices, and not afraid to muck about with an engine. There's no more danger here than already exists when wrenching on an engine.

If you're not comfortable with this, then don't do it, obviously.

[Seg]

http://sites.google.com/site/hamlinhomeprojects/projects/raspberry-pi-isr

Raspi can handle 90,909 interrupts per second in kernel. Considering the engine spins at less than 10,000 RPM that's probably fast enough.

[Skimask]

Raspi can handle 90,909 interrupts per second in kernel. Considering the engine spins at less than 10,000 RPM that's probably fast enough.

If ALL is was doing was sitting there and waiting for the next injection event to occur...then, sure, a lowly ATTiny could probably handle the job.

[timb]

http://sites.google.com/site/hamlinhomeprojects/projects/raspberry-pi-isr

Raspi can handle 90,909 interrupts per second in kernel. Considering the engine spins at less than 10,000 RPM that's probably fast enough.

Did you read the entire article? It seems like an absolute nightmare to write a 3.2.x kernel driver for non-i386 hardware because, as the article mentioned, all the resources on the web assume you're working with a 2.7.x kernel and most examples assume you are compiling for i386 hardware and not cross-compiling.

Like I said, a kernel driver is feasible, for sure, but it's not the easiest route for this project. If you want to push the Raspberry Pi just to find the limits (as the guy in the article did) or can't use an external MCU/FPGA for whatever reason, by all means knock yourself out! However, in a case like this it's just not the right tool for the job.

A faulty MCU most likely won't kill anyone, but the potential for very bad things to happen seems awful high to me with a Raspberry Pi. You're driving along and it locks up, you slam on your brakes but the engine is dead so you lose power steering, power brakes, acceleration. It would take ~30 seconds to reboot... At least an MCU with a watchdog would be back on within a second.

Like I said, it just seems overly complicated and not fit for the job to me.