Curing GM EFI Vertigo?

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.

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.

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...

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.

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.

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.

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.

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

I can't speak much to the C3 ecm's that Dynamic EFI uses. The last time I looked Bob was using the 7747 with added and modified code as well as hardware changes to make it a more effective and more generic ecm. Bob spent a ton of time with that family of ecms and he knows them extremely well. I have one or two of his lockers kits here from eons ago but I was never fond enough of the C3 to stay with it. In stock form I've run up against it's limits several times. I don't know if Bob wrote his own code or (more likely) is using heavily modified GM code. Some of the tasks in the ecm can only be done a certain way no matter how you'd like to code it.

MS started as a simple fuel only system to remove complexity and the steep learning curves we face with GM systems. The code and hardware was made available to anyone, and it took off after a while. Why wouldn't it? When enough guys get together and say "It's ok but..." there are bound to be changes coming. And if all the tools and information is available to make those changes, well, watch out. I get lost trying to figure out where MS is now because of all the changes, but it's extremely popular and guys that get frustrated with the GM stuff can get MS to work in pretty short time.

GM used Motorola processors at least through the 0411 family of pcm's. I'm told those boxes use much faster Motorola 68000 hardware..

When you say "Locker Kit" are you referring to the WOT BLM Locker for the LT1 $EE? I found that years ago and saved it, then got an LT1 and used it, it is an amazing difference it WOT! If it is his I want to credit him for it in the $EE PCM thread. RBob has done a lot in early years that has brought me much enjoyment with todays technoligy... well OK OBDI is old tech now. But can you imagine not being able to tune a bin today?

I know he did the "Enable Highway Cruise" program used in the 1227747 and have him credited. I admire him and go out of my way to read his posts but sometimes do not have the knowledge to understand them...

As you know I honestly try to credit everyone with work they did. Another site I started 10-12 years ago was stolen and the guy took credit for everyones work. This site was originally started to preserve such work after I lost a lot I had been collecting over the years to a cup of coffee through my laptop keyboard incedent... and went back to DIY-EFI and found much of it missing, then some returned, then went msiing... rinse and repeat!

Back to topic! This sounds like a way to simplify GM ECM and all the work we do with them but would be a lot of work to get there... Gregscam has shown me some things he has done in the xdf side to make these changes simple with TunerPro by adding paremeters.

MegaSquirt is very popular at HotRodding sites because of it's simplicity of handleing so many differant engines.

GM ecm's are (were) designed to provide rapid access to bunches of data without going through the ALDL connection. If you take the cover off the 7747, the 7730, or a host of others you'll see an unused "connector" on one end of the circuit board. This connection was presumably for engineering departments and ecm repair centers to use, but was not intended to be access by technicians. Rbob designed an external hardware interface called "Lockers" Last time I looked he was supplying a different version called EBL or Embedded Lockers. Hmm.... just checked and it looks like he's doing more stuff with the P4 now. Will need to investigate.

Bob helped me out years ago by creating some code for a 7747 which contained a speed limiter. The shop flunkies were hauling loaded car trailers at 80+ mph on busy highways. Bad enough, but when one of them lost a car and didn't catch it for 15 miles!?!?!? that had to stop. Bob was also highly involved with Bruce Plecan's work with the GN code as those cars used a C3 as well. I'm glad to see his business growing.

Funny how things happen. I happened to find this tidbit from 2007 while scanning for memcal fuel mode stuff:

Quote:

---

An addon board by Bowling and Grippo disables the
"mask" ROM on the C3 CPU and substitutes an entirely
new program complete with variables for the ones that
GM engineers created and can be used to control 4
barrel TBI or TPI motors.

---

Another happening that I missed. The MS guys had independent code available for the GM C3. I wonder about the relationship between that board, Rbob, and Dynamic EFI.

Quote:

---

Originally Posted by 1project2many

GM ecm's are (were) designed to provide rapid access to bunches of data without going through the ALDL connection. If you take the cover off the 7747, the 7730, or a host of others you'll see an unused "connector" on one end of the circuit board. This connection was presumably for engineering departments and ecm repair centers to use, but was not intended to be access by technicians.

---

I presumed the acess your are talking about was to program the chip and limp home chip? then covered in goo and the top cover hides it! That's waht it looks like it's connected too...

The netres or backup fuel chip is just a network of resistors. It gets "made" rather than "programmed." You could make the same thing by measuring a stock chip then going to Radio Shack and buying a couple of packs of resistors. The edge card connection allows direct access to memory and AFAIK some of the input / output circuitry without the need to wait for data on the ALDL line.

Just a quick incomplete mockup of what the front end might look like:

http://i263.photobucket.com/albums/i...is/mockup1.gif

So if I am reading all this right, you are talking about a code mask that will work in most all popular ecm's/pcm's?
So instead of having diffrent ones for one pcm (such as $0D/$0E/$31) and others for another ecm (such as $42,etc..) you would have one code mask and one defination file that will work in all ecm's?

If that could be done I think it would be super. But it will take people way more smarter than me. I wish there was a way to help, but about the only thing I think I could do, would be a test mule, give me instructions such as "download this file and burn it to a chip and see if it works"...lol