Curing GM EFI Vertigo?

[1project2many]

I was going to add this to a post in the 8D TBI thread but maybe it deserves its own thread.

My personal feeling regarding GM EFI hasn't changed in over 10 years. We EFI hotrodders put a bunch of work into playing with parts selection and software reconfiguring to get what we want. But we keep missing the big picture. Instead of mix and match software / ecm, the ideal situation would be to have a "master calibration" that we can put together as needed. Small changes that are ecm specific could be part of the calibration assembly so the calibration could be used in a variety of P4 family ecm's. Code written from scratch or assembled out of sections of GM code (the same way GM does much of it) would be fully documented, would require 1 tuner, 1 scanner, and could be made available to a bunch of different groups. Imagine hitting the syty forum, or the V660 forum, or thirdgen, or FSC, and being able to read and even use calibration changes and improvements that guys are coming up with in your vehicle, regardless of the different ecm's in play.

I have never understood the large amount of variation found in OBDI GM hardware and software but my gut tells me some of it's due to lack of communication between development groups. Often I've found software options that are never used, code that seems poorly implemented, and just plain dead sections of software indicating incomplete or improper development. Much of the GM code still has software included for the heads up displays used by GM engineering during initial development work for the particular calibration. And many of the cals have that software enabled, directing processor time away from the job of running the engine. The ecm can do so much more than we ask of it if only we bothered to ask.

I realize this forum has more hands on type guys than software and coding type guys and that's ok. But I at least wanted to throw this idea out there for others to think about. As you spend time trying to build definition files and find ALDL info, as you're bouncing from forum to forum trying to determine which ecm might be best for your application, and as you're trying to figure out which stock vehicle's wiring diagram to use with your EFI conversion, just think of the possibility of being able to pick up any one of a number of different ecm's and know it will work with the calibration, tuning, and scanning software you have without any dizzying list of requirements or "extra" knowledge.

[jim_in_dorris]

Wow, that is a concept. If I understand your thoughts, there would be a core piece of code that all the p4 would share, and the rest of the code would be added in based on a calibration setting. Then the ALDL stream would be setup to be essentially the same for all versions, thereby requiring only 1 xdf, adx (or whatever your scanner required). By doing that, a chip could be built for any P4 ecm, and the same tools could be used across many vehicles. Individual calibrations could be built as include files. You could have many different VE tables, SA tables, etc that you could just include in the build. HMMMM! What a project. If i wasn't about to start my Masters degree, I would definitely consider embarking on such a project.

[EagleMark]

Is that really possible? One bin, one adx and one xdf for all/most ECMs? Like code 59 for all?

Since there is an 8D super AUJP and a 32b extended, they changed the code in bin and xdf... hmmm? I should have spent some time in hex and understanding the bin, I am so far behind there.

I know for a fact there were to many different engineering departments working for GM at that time, Ford saw this in early days and different departments started communicating to stop duplicating work, then assembling pieces...

[Six_Shooter]

I've thought about a similar concept, only based on a single ECM, such as the '7730, bbut my coding skills are far less than mymechanical skills at the present. I am learningabout coding with another project and hope it will help with something like this in the (hopefully) not too distant future.I see a problem with having a single piece of code for all P4 ECMs since the addressing of some inputs and outputs seems to be quite different, especially when bringing the '7427 style PCMs into the equasion.

[gregs78cam]

I agree, I/O coding would probably be the kicker. You can make the code do anything you want, but the different PCMs have different I/O schematics. I think if the '7427, et al, could be easily modified to handle boost that would probably be the most versatile OBD1 PCM you find.

[jim_in_dorris]

By referencing I/O addressing with labels instead of absolute addresses, it might be possible to create include files for the different pcm's allowing the code to be generic, with I/O specific include files for each pcm.
for example instead of

L0016 EQU $0016 ; Error word #1
; b7=Error 13, O2 sensor
; b6=
; b5=
; b4=Err 16, VSS buffer error
; b3=
; b2=
; b1=
; b0=Err 21, high TPS

I would use
LErrorWD1 EQU $0016

then everywhere I need to reference this location in code I would say LErrorWD1 instead.. If another pcm has the Error word #1 at a different RAM location, it would mean changing just its address in the include file.

[1project2many]

Jim's right on top of this. Programs called compilers can take a more generic set of instructions and make them machine correct by inserting specific instructions in place of the generic ones. This is how a program written in a higher level language like C can run on both Apple and PC machines with completely different architectures.

My vision is a code library with a front end interface that allows user selectable ECM number, various options such as Peak and hold injectors, 2 BAR MAP, EGR, etc. Select a few options, choose ecm number, maybe enter engine size and some rough numbers for hp and torque curves, and out comes a starter calibration. All calibration data would be located in the same place in the cal so it's always readable, the ALDL data would always be the same, and improvements to the codebase could be applied to existing calibrations.

[dave w]

After reading the above posts, I immediately thought about the approach Dynamic EFI went with. From what I understand about Dynamic EFI, it's basically a multifunctional hardware system using one string of code? I also think MegaSquirt is similar in architecture with Dynamic EFI, basically a multifunctional hardware system using one string of code?

From what I understand about the GM ECM' to about 1995, they are primarily built on Motorola processing architecture?

dave w