As I can see you have very interesting idea to develop free ECU. I found this site searching info that can help me to make decision about my project. Telling the long story short, I have an idea to create all terrain expedition vehicle. Now I am on a stage of information collection. One of the problem I want to make the vehicle powered by diesel engine (presumably CR) and that would be great to have open source ECU to control the engine. May be I will not make the car but that would be interesting to participate the project to estimate difficulties with mine.

I have some questions about the project because I did not get some project concepts.
- I did not make any calculations but I expected it is possible to build ECU based on 8-bit microcontroller (for example something from Atmel mega family at 20MHz). Has anybody tried something like that for ECU?
- Your project prototype use 16-bit microcontroller MC9S12XDP512. What uC limitations do you expect for final version?
- Which types of engine could be controlled by FreeECU?
I meant these options:
- otto (carb, ignition + drive-by-wire option)
- otto (k-jetronic)
- otto (injectors)
- diesel (distributed injection)
- diesel (common rail)
- diesel (pump-injector)
- 2-stroke engines (like motorbikes)

Thank you in advance for your answers.

VEMS uses an 8 bit core of similar speed to that, however VEMS would appear to have some limitations in its firmware abillity. Because it is distinctly closed source it is not possible to discern exactly what limitations are present, but I do know that up until quite recently it's COP code could not do overlapping dwell! This is a severe limitation. Apparently that is no longer the case, but it gives you an idea of how it might be.
I don't understand what you mean. The intent is to use the xdp512 for the foreseeable future and perhaps switch (easily) to the xep100 core at a later date to gain more IO and more performance.

• otto (carb, ignition + drive-by-wire option) - This is certainly possible, however I probably won't be developing drive by wire code myself as I don't believe it is a good idea for home build use anyway.
• otto (k-jetronic) - With retro fit of normal EFI equiptment yes, but otherwise no.
• otto (injectors) - Yes
• diesel (distributed injection) - I don't know what this is.
• diesel (common rail) - Maybe with appropriate injector driver hardware.
• diesel (pump-injector) - Do you mean a normal old style reliable diesel with mechanical injector pump? If so, only via some sort of stepper "throttle" control. You would likely need to code this your self.
• 2-stroke engines (like motorbikes) - Yes

You are most welcome, thanks for signing up :-)

Fred.

Thanx for the info. I will investigate this later.


I thought you gonna make portable solution for any kind of uC. Theoretically, I think it is possible using uC abstraction layer. Just for example to make this clear.

otto (k-jetronic) - Hm. If it is possible for carbs why is it not possible for k-jetronic and TBI so on? It is the same ignition control loop, but the fuel is not distributed between cylinders (just one of two injectors).

diesel (distributed injection) - That is the classic one. High pressure pump distributes fuel between injectors (timing + amount of fuel). But there are to options fully mechanical pump (like Bosch VE) and electronically controlled pump (like Bosch VP). There is nothing to control in mechanically controlled pump, but electronically controlled pump uses many external sensors (like inlet air pressure and temperature and injector's valve motion sensor). As I know some of the values go through ECU, and it is definitely drive-by-wire because ECU reads pedal position and sends the value to pump control unit. OK, it is not so much to control but like any in diesel engine there are glow plugs, and they are have to be controlled during the engine starts.

diesel (common rail) - Diesel engine has completely different cycle, so the fuel amount has to be calculated by different way; that's what I meant. Another tricky thing, modern common rail solution use a multi-injection method. The multi-injection significantly reduces diesel noise, but I suppose it is not possible to do with otto engines.

diesel (pump-injector) - That is the most modern diesel injection fuel equipment where high pressure pump and injector are the same device. For example, look at this page What is Pumpe Düse?

Theoretically you could, but in practice it's extremely unlikely that such code would be efficient enough to do the job well. It would also be overly complex for it. Many parts of it will be non processor specific, but all the register fiddling would be totally different and other cores don't have equivalent devices inside to perform the same functions.



Each interrupt call uses at least about 10 instructions (>10 clock cycles) without doing anything inside. If this is something that is being called with a high frequency and is run from within an ISR it will negatively impact all aspects of operation. It's just not practical really.

The idea was to develop a good working system that in future could be ported to a different core (with varying degrees of work) once this one gets out dated. The XEP100 is likely to be the next core targeted by us IF Freescale ever release it :-) (which they may not)

What I meant was the ECU could potentially control a carb of throttle plate of a kjet, but it could not control the injection itself. Similarly for a std injector pump setup you could stepper motor control the fuel control arm and thereby control fuel flow in a coarse manner.

All of that would seem to be a gross waste of time though.

The multi squirt business in those modern diesels apparently heavily impacts economy... You could probably achieve it, but would you want to?

Basically : Anything is possible if A someone is willing to write the code for it B the core used is up to the task.

Without knowing much more about how those systems work, I can't really comment on ability or potential performance of such a system.

The goal (which I failed to state) was to make automotive petrol engines run in a performance manner for performance enthusiasts. Some diesel stuff might be possible, but it certainly isn't one of the goals.

With the XDP512 I would say max 6 cylinders of common rail control assuming you can construct the hardware to do the job.

Fred.

In case it is a C project (may be except low level and a start up code) that might be a set of headers like I wrote. Implementation of all the functions makes possible to connect ECU specific logic with uC specific implementation. If you need a timer and an interrupt when one overflows there are almost the same in any uC. For example two completely different uC I know, 16bit Fujitsu MB90540/545 and 8bit Atmel ATmega8 both have 16-bit similar free running timers (not compatible by registers, of course) and both could have the same basic C API headers (init, interrupt, and something project specific). If I understand correctly, in/out pins also could be configured so some intermidiate layer has been designed anyway.
I am not trying to convince you to do like this, but you will do something alike anyway just why not to keep uC porting in mind.


I did not get it. If you really need one how are you planning to escape the interrupts?
I am not telling about calls an API functions inside ISR; I am telling ISR are uC specific like other uC utility functions but they are described and organized like API.


It depends. I want to buy an used diesel engine with CR fuel equipment, recondition it, and equip it with with a simple and reliable ECU (muli-injection is not a rocket technology but could take time).


That's true, but the question was about this project. If the system design allows to select control loops from the whole project library the task is simple, otherwise that could be easier to write it from scratch.


Thanks for the explanation.

Certainly, however the low stuff is hard to avoid and fairly integral to many parts of the code. The many parts might be separated out nicely, but most of them (so far) have some low level code in them. Once we get to the stage of writing code to do generic things like port management and specific functions, it should all be of sufficiently isolated nature to just drop onto any core with appropriate lower level support. I think some people may underestimate how much of the code is low level by necessity though.


This is a good idea for sure and something that needs designing. Feel free to grab that task and post up a proposed software architecture design for discussion as Stu has done with the serial spec.


Portability should come naturally with a well designed system. If it is more difficult than possible in some places it will be that way for simplicity and efficiency reasons. IE I am keeping it in mind :-)


OK, clearly we are suffering from some language barrier :-)


OK, see below :-)

"Select control loops" ? It is already modular in that if you want the "fuel" channels to run ignition it would be trivial to implement that in code. The functionality to produce clean wave forms is in place. You just feed it with duration and angle effectively. I'll be improving that even further soon based on an idea that I had a little while ago.

Fred.