[vristang]

From another thread...

.....im suprised no one has come out publically with their own code to execute on one of these ecu's

Yeah, I think there is enough knowledge around to COMPLETELY replace the code, but I reckon testing would be a challenge, and companies probably want to stay away from liability issues.

First off, I would be willing to test this on my own car... I don't mind being the sacrificial lamb
Just throwing it out there...


As an open source deal, this would offer us all kinds of possibilities, wouldn't it?



There would still be limitations due to hardware in the ecu being used, like number of injector drivers, etc... but any hardware present could be retasked if desired?

MS was mentioned in the other thread, and it's limitations were mentioned as well (lacks trans control, etc)


Anyway, I thought this interesting enough to deserve it's own thread.
I've done some programming in a couple of languages (no hex), but nothing major... still, I wouldn't mind taking a stab at something like this... especially if open source in a community like this one.


Thoughts?

[decipha]

i gave this a bunch of thought way back when and it only seemed logical to rid the intel processor altogether at least for me

im pretty familiar with the atmels and i can make them do what i want thats why i never got too involved with the intel ecus just wasnt worth my time and effort

if your serious about doing all the footwork and coding i can give u some info on the 4 bank ecus that would probably be the most logical ecu to manipulate IMO as you have the fastest and most memory ecu at your leisure

oh btw i used your SAD to make a cjaq3 strategy file to tune a 96 ranger, worked great, any chance of supporting 4 bank?

this also leads me to another question, does anyone know of an intel 806x assembler that accepts c++?? if so i can copy the d.e.c. over and see how it runs on a single intel ic

[tvrfan]

does anyone know if there is a C or C++ complier for the 8096 ? That's probably the best place to start, and then opcode/binary to drive the HSI/HSO interface....

[vristang]

Honestly... I'm not at your guys level... My skills are only going to help when it gets to the C, C++, VB, or whatever language.
And at that point, the GUFB and others may provide examples of some of the logic.

I did a google for '8096 C++ compiler' and came up with a couple that may be what is needed?
http://www.softepic.com/windows/develop ... nt-System/

http://www.brothersoft.com/micro-c-8096 ... 12996.html

Again though, I'm not sure I fully understand what would be needed to get a Ford ecu to the point that it could be programmed with C++????????
A compiler is an intermediate step between Hex and C++, correct?

[decipha]

yep, the compiler compiles c into the ic specific binary

i actually had u 2 mixed up

[cgrey8]

Having a C/C++ compiler doesn't completely remove the need for assembly. It does substantially reduce it. There are some things that simply can't be done in C just because what you are needing to do to the hardware is very hardware-specific and only accessible via specific assembly instructions that likely aren't taught to a compiler how to invoke. Often the setup of initial configuration registers that handle pin/peripheral muxing and the setup of interrupts are always done in assembly. Once those things are done, most all code at that point can be successfully written in C/C++ since at that point, the code is mostly algorithmic. Depending on how "specialized" a controller's peripherals are dictates whether they must 1st have some initial assembly configuration or if they can be configured using C/C++.

As it relates to us, I'd think you could rip-off all the initial configuration assembly from an existing BIN file. While it is possible, I'm just not sure how practical it is without single-step debugging, stack tracing, watch windows, & breakpoint controls to go along with it. C does make writing the code easier, but without those tools, it also heavily removes you from what's actually going on at the processor level making "blind" debugging even more difficult. Debugging assembly blind is like reading braile. It's tedious and difficult, but not impossible. Debugging C blind is like trying to read braile with leather gloves on.

[vristang]

Wouldn't we only need to develop code to work with 1 Ford ecu though?

Say a 4 bank, v8, automatic, with fan control, etc (all the potential features one may want...)
Once the communication between the hardware and the C code is done, it would be a matter of programming the C code to change the ecu to a 4 cylinder, or change from TFI to EDIS, etc.

It just seems like we would only have to work with 1 Ford .bin in order to meet 99% of all potential needs?



So, given that I have basically no idea where to start... what should my fist step be if I want to explore this as a possibility?

[tvrfan]

Sorry to be a wet blanket here, but just trying to 'keep it real' as they say....

I think quite a few of the original Ford coded ECUs are already highly configurable for stuff like num of cyls, EDIS or TFI, bank or sequential, EGO or not.....

So I do (continue to) wonder if it might be better to choose a common one, get really familiar with it, and then mod it, and that this might be easier in the long run ?

[Yes, I know I'm bound to say that with my disassembler view of the world, but still, I think it's a valid point to make - debugging something like this with C code will probably be VERY hard to do...although it probably would be fun for the serious geeks like me ! ]

[cgrey8]

Believe me, I'd love nothing more than to code up my own EEC using Linux as an OS and C-code for all the algorithms that calculate spark advance, injector PW, EGR, etc etc. But doing so with modern day processors, GNU compilers, debuggers, trace-steppers, and all the goodies of the modern day makes that feat quite a bit more doable than trying to write straight-C on an OS-less antiquated processor with no practical tools to do things like setup breakpoints, view internal register values, see the trace-stack, manipulate RAM variable values, etc etc. That's why I've always had it in my head that I'd develop up just that on an EEC via the J3 port. A big processor such an ARM Cortex A9 running Linux, wireless/bluetooth, EEC code, complete with HTTP interface with the PC for programming and datalogging. But all that would need to be in an FPGA which could also handle the back-n-forth with the 806x processor. But the code being fed to the 806x would be very hand-crafted, very simple, and very easy to diagnose assembly code that did nothing but read inputs, relay them to the J3 port while accepting commands to write the outputs. The 806x would be nothing more than a coprocessor of I/O.

In today's world of processors, they make dual processor ARM Cortex A9 and M3 controllers for jobs such as this. The Cortex A9 does all the heavy lifting and the Cortex M3 does all the real-timish stuff...all done within the same die.

[decipha]

i pray i dont offend anyone with this BUT...

using a higher level language than assembly isn't going to cut it on these ecu's Ford has tried it with Pascal F and their own custom language 'FACT' The Pascal F code took twice as much memory and ran some 60% slower. The FACT code took about 81% more rom and ran slower. The cost of the hardware meant that hand coding assembly code was cheaper to do!

i've concluded the same in my own endeavors, in the d.e.c. i have a prioritizing strategy based on a timer, the only way i was able to keep the calculations fast enough is to allow the loop to skip some sub-routines if it calculates that the alloted time exceeds the time required to complete that calculation, that routine then gets throw on the stack and when (and if) its number comes up in one of the next loops it then gets calculated, there is a bunch of failsafes and check variables for it though in the rest of the loop depending on its priority

so... for example, at WOT the egr routine is skipped and given a priority number, the problem is that the egr feedback sensor(s) are ONLY read and the egr position/flow is calculated in that routine, however, when the tps exceeds the WOT breakpoint, theres an interrupt that runs the WOT routine (only once), in that routine the egr flow is set to 0, if its value is anything other than 0, then in that same routine the egr valve pw is written to 0, in a later loop when (and if) the egr routine's priority number comes up, it then calculates the time required to make that calculation, if the time alloted doesn't excced the time required the egr routine will then be executed, the first command in that routine reads the feedback sensor(s), the next section of that routine is skipped where egr flow and what not is calculated since its criteria won't be met at WOT, after it skips down to the end of that routine it will then compare the egr feedback position to the maximum closed valve value to make sure that the valve is actually closed, if its not it'll set a fault code P0406 "egr circuit high" as well as a failed variable that gets passed on to the EGT routine to compare exhaust temps (if the sensor is present) to actual to see if it is indeed stuck open, if the EGT deviates from its typical value during those conditions then the "egr excessive flow" fault code gets set P0402


its a tad more involved since i have egr intertwined with variable cam timing for engines so equipped but you get the idea

[cgrey8]

I don't doubt that. And when you compare hand-crafted assembly to even C code, assembly will always run faster and take up less memory. In recent compilers, they've found ways to get C to pack tighter than it did in the 80s and early 90s. With a highly skilled C programmer, they can optimize the compiler for either memory or speed as well as use compiler options to put code inline. But as great as C compilers are, you'll never be able to get C code packed as tightly as assembly can be done by an experienced assembly programmer that knows all the assembly tricks. It's of no surprise that the same is true of Pascal.

[tvrfan]

I can see both sides of this argument - Yes modern processors probably ARE fast enough to run an OS and algorithms and easily keep up, after all some of the early EEC-IV code ran at only 8 Mhz, whereas today CPUs run at Ghz speeds. (even later complex ones ran at only 24 MHz ??)

BUT many of the OSes don't have true real time (as far as I know) so some care would be needed, and my knowledge of newer embedded systems is zero, so I don't feel qualified to say more.

The Ford code on some boxes does exactly the trick described above (again as far as I can tell) - interrupts get dealt with immediately (sparks, injectors, EGO, etc) but a lot of the other stuff runs on a background list which has a kind of 'use previous value if timeout' logic.....

ALL high level code has a penalty for redundant instructions, and some (as said) are very high indeed. I can't say I've studied any newer ones or seen stats - the modern way seems to be to throw more CPU power at the problem....it's cheaper than programming time. 'C' can be simple or complex, I like it, but admit it can be pretty horrible to read (and compile I imagine) ...

[cgrey8]

Foreground/Background vs RTOS vs nonRTOS in embedded is always a lovely debate because there are right and wrong answers. And the real answer is both have their place. RTOSs are generally very small in codebase, have very little overhead and thus have minimal latency when it comes to when an interrupt triggers and when your interrupt service routine is actually executing your interrupt code. And for non-interrupt code, the switching/scheduling algorithms in most RTOSs are also much leaner so switching between tasks is very fast and deterministic. And when your processor and/or memory store isn't big enough to even hold an RTOS, you write the simplist possible embedded application there is via foreground/background technique which is what Ford used to program our EECs. Most processors and memories today are sufficiently large enough to work with an RTOS, but there are still some ultra-small/ultra-cheap applications where everything is still written 100% in assembly.

Non-RTOSs like Linux on the other hand are behemoths. Some very small RTOSs like uCOS can be packed in to memory as small as just a few kb. The Linux kernel alone is typically around 3-4MB packed and uncompressed in memory is closer to 8MB. But like any OS, Linux can be stripped down bare and in those cases can fit in impressively small memory spaces, but as small as Linux can get, it's still about an order of magnitude greater in size than super-lean RTOS code (i.e. few hundred kb).

But for all that code, how well does Linux really perform? It depends. If you are writing straight-up applications in Linux that make use of the canned peripheral drivers like the standard serial driver to communicate over a serial (e.g. RS232 or RS485 connection), then what you'll find is you either need to always be the master on that network OR the protocol being spoke needs to have gracious token timeouts upwards of 60ms or better. Most do not. So to get say 1ms response times from interrupts, you pretty much have to be writing your own code driver. I haven't had much experience with this myself, but I've read articles that the new Real Time Threads in Linux do actually get normal Linux applications running at Real Time priority to very near driver speeds in response time. Obviously it can't be just as fast, but it is absolutely impressive they got it compatible. Normal tasks are not even close. That simply means the better Linux gets at doing real time tasks on these fast processors, the easier and easier it'll be to develop, program, and debug, real time and near-real time applications as compared to traditional RTOS experiences.

[decipha]

problem is a lot of those processors arent automotive friendly due to the harsh environment

afaik the fastest processors atmel makes for automotive use is only 86mhz

[MartyMcSly]

I think quite a few of the original Ford coded ECUs are already highly configurable for stuff like num of cyls, EDIS or TFI, bank or sequential, EGO or not.....

So I do (continue to) wonder if it might be better to choose a common one, get really familiar with it, and then mod it, and that this might be easier in the long run ?

That then comes down to hardware variations across EEC's... as an example, the Australian 1998-2002 Falcon (AU model code) uses 2 different hardware modules for V8's (ETV-722 and -723) but 8 different modules for the 6 cylinder engines (ETV-711 through -715 and ETV-733 through -735).

Some of the variations arise because of the change in security from Smartlock to Smartshield during the life of the AU. Other variations are due to factory fuel options - dual-fuel and dedicated LPG.

I don't know how generic the hardware is. I wouldn't be surprised to find that on a dedicated LPG PCM, the injector pins are unconnected for example, or that the pins used for injectors 7 & 8 on a V8 are "dead" on a 6-cylinder PCM.

But yes, as long as hardware isn't an issue, I believe the EEC is highly configurable.