True programable ecu ?

[Squid]

Saying that, if you can spare your engine go for it.

Creativity breeds innovation!!

I have some cool ideas of things to integrate into an ECU which I believe would make for some big advantages...

[timbosaurus]

Also, complexity often breeds unreliablilty. The code I wrote had no OS, very small size and limited functionality, and therefore a limited opportunity for error.

I really dont think it's possible for one person to use just their spare time to design and build a reliable home-made ECU using quite a powerful and complex processor (eg:MPC555), a feature packed RTOS, and total functionality for recent mainstream technoligies like boost control, VVT, closed loop lamba control and self tuning etc.

Having said that, if anyone has the time to try building their own ECU based around one of motorola's great ECU processors, i'd be more than willing to learn from it

[Squid]

Timbosaurus -> How do you handle multiple inputs coming from many locations in real time without any sort of threading?

[timbosaurus]

Mate, like i said, my system was VERY simple.

The inputs i used were load (from a freescale/motorola MPX4115 MAP sensor) and position (from a jaycar/soanar HME301 hall effect sensor). With decent signal conditioning these were quite clean, and gave me position, rpm, load and effective effeciency. I wasn't temp compensating at the time... only because i couldn't be arsed. If i was going to run a car on it, it would be one of the next things to add. I also didn't use closed loop feedback so had no O2 sensor.

The outputs drove the ignition coils (2 * dual output in wasted spark) using a darlington pair of BJT drivers per coil and a single injector (yea... i know, *only* one??? Effectively I was only trying to replace a carburettor ).

Oh, and the programmability was just interrupt driven UART. Nothing fancy.

These were all easily controlled using interrupts and timers in the micro. I guess using timers could be regarded as a simple form of threading, but it certainly wasn't using a commercial or open source multitasking OS. When i do get the time (in 30 years after retirement maybe ) I will do another. But this will certainly use something a little better than an AVR (in case you didn't notice, I do have a soft spot for the MPC555's) and a decent RTOS. THEN there will have to be countless hours (days, weeks) of bug checking and error handling to do.

[Squid]

OK I thought an mpc555 wouldn't be able to handle and process enough inputs and outputs to be able to run an engine at several thousand rpm without some sort of intrerupt queue forming and it all going to the doghouse.

I suppose the single point injection would help reduce the number of outputs...

Congrats for getting it working, it is by no means what i would consider a simple task.

PS I have learnt everything on motorola as well, and I have a soft sport for the 68000's, in particular the 908, nice and multi purpose does almsot anything. I have been out of the scene for a while so I don't know if the 908s have been replaced or upgraded or anything.

[Cressida91GLX]

Give me a couple of thousand $$$ and I will provide you with real time hardware Application Specific Integrated Circuit ASIC chipset without even an operating system... Every thing hardcoded in VeriLOG/VHDL and I will try to run the test on some FPGA and you will have control, speed and reliability to operate spaceships....



It is simple a matter of money how reliable you want to go. And how many chips you guys need. if the chip sale runs in million than yeah they are worth my time of designing the whole system .

[MWP]

Give me a couple of thousand $$$ and I will provide you with real time hardware Application Specific Integrated Circuit ASIC chipset without even an operating system... Every thing hardcoded in VeriLOG/VHDL and I will try to run the test on some FPGA and you will have control, speed and reliability to operate spaceships.

Why do that when you can use a micro to do it at 1/4 of the price, with the same reliability and speed and also have it reprogramable?

[Squid]

I'm with MWP

[timbosaurus]

OK I thought an mpc555 wouldn't be able to handle and process enough inputs and outputs to be able to run an engine at several thousand rpm without some sort of intrerupt queue forming and it all going to the doghouse.

I suppose the single point injection would help reduce the number of outputs...

Congrats for getting it working, it is by no means what i would consider a simple task.

PS I have learnt everything on motorola as well, and I have a soft sport for the 68000's, in particular the 908, nice and multi purpose does almsot anything. I have been out of the scene for a while so I don't know if the 908s have been replaced or upgraded or anything.

Ah... that's the confusion... mine wasn't running on the MPC555, it was only running on an cute li'l Atmel The *next* one would be on a Motorola! and no, i couldn't imagine writing useful code on that without an OS

[timbosaurus]

Why do that when you can use a micro to do it at 1/4 of the price, with the same reliability and speed and also have it reprogramable?

I'd disagree a little... a properly designed ASIC (actually, more likely still an FPGA because i couldn't exactly see home made ECU designs ever exceeding 10000 units!) will clock a lot faster than *most* MCU's. Just a month or so ago I had to design a super-high-res timer module using a $0.90 CPLD running at 100MHz, try doing that with a cheap processor! Also the efficency of executing certain tasks in parallel in hardware will reduce an awful lot of the overhead too. And FPGA's are just that... Field Programmable!

But i do like micro's... they're so much easier

[chris_rg]

I would stick with micros for this application. In complex digital circuits you can reduce the chip count heaps and provide the ability to reconfigure using FPGAs. But ECUs pretty much have only one digital component, the controller itself. Which can already be reconfigured in the field. You still need all the signal conditioning, and high current drivers.

ECUs may seem like a fairly simple software task, and whilst it may be pretty easy to make a car run, its a whole other story making it run well. There is a fair bit of math behind the algorithms, of course this is well documented now, especially thanks to megasquirt and DIY-EFI. Also making it reliable is very difficult.

I wrote some software to run a COP system for a mates car, its was pretty easy to make it run. But the difficulty came when you considered transient events, such as change in engine speed. The dwell calculations got much more complex. I think i was looking at the second derivative to come up with an accurate prediction of when to enable the coil charge.

I think one or two people can come up with an ECU to run their cars ok, but it will never be as advanced, reliable or versatile as when the developers pool there knowledge in an open project such as Megasquirt.

I say why reinvent the wheel. The nature of projects like megasquirt lets you skip all the hard work of others and start working on your unique features.


Cheers
Chris

[Squid]

timbo - There is a right time and application for everything, but in this application an micro would be the logical choice, imho.

[Squid]

I wrote some software to run a COP system for a mates car, its was pretty easy to make it run. But the difficulty came when you considered transient events, such as change in engine speed. The dwell calculations got much more complex. I think i was looking at the second derivative to come up with an accurate prediction of when to enable the coil charge.

Perhaps an application for some sort of PID control? or perhaps a straight PD as im not sure where you would get your feedback loop from.

Without getting too far into it, I can't see how the 2nd deriv is useful, perhaps a quick explination you can let me know what you were trying to acheive? I could just be slow and missing the point!

[timbosaurus]

timbo - There is a right time and application for everything, but in this application an micro would be the logical choice, imho.

Mate, I couldn't agree more! I was just saying that micro's aren't necesarily the faster, cheaper, and only reprogramable option.

I often thought of using some logic array running at several hundred MHz to give a sub millisecond resolution on injector pulse width and ignition timing and interfaced with an micro for communications and calculations/algorithms... but then i lay down until that silly thought went away

micro's all the way for home made ECU's!!! oh... and i still think Megasquirt is a great idea!

[timbosaurus]

Perhaps an application for some sort of PID control? or perhaps a straight PD as im not sure where you would get your feedback loop from.

Without getting too far into it, I can't see how the 2nd deriv is useful, perhaps a quick explination you can let me know what you were trying to acheive? I could just be slow and missing the point!

ewww... control systems!!!!

I'll stick to my carbie