ZFuel

[superlen]

Captain,

WARNING: A bunch of geeky programmer stuff to follow for Captain's piqued interest. Others may get bored.

You're buddy is right...you're out of touch..errr I mean today's compilers are way better/more predictable.

I think what really killed assembly programming is speed. Chips today just run so damn fast that speedy assembly code isn't that critical for most applications. Even if the compiler does silly things & bloats the code, it still runs 100 times faster than it has too. I've noticed myself migrating my code style from effeciency -> readability. I'll code up a function now and make sure it's readable and understandable to whoever looks at it later & I don't worry about efficiency. Sometimes I have to go back and tweak it for performance, but it's getting more and more rare.

On this project I find myself waffling between oldschool (optimizing variable sizes for sensor readings & upcoming math functions on them) vs newschool. (make 'em all floats and let the ALU do it's thing). For speed of development I probably should just make most floats, but so far I haven't. Many vars are integers with a resolution of tenths. Here's a copy of one of my structures.

//Engine

typedef struct {

//fixed vars

UINT16 Num_Cylinders;

UINT16 Num_Injectors;

float Bore; //in mm

float Stroke; //in mm

float Displacement; //in cc's

float Degrees_Per_Cycle;

//realtime vars

UINT16 BAT; //in tenths of volts

UINT16 RPM; //revs/min

UINT16 MAP; //in tenths of kPascal

UINT16 MAF; //mass airflow in g/s from aftermarket MAF

UINT16 AFM; //mass airflow from stock AFM

UINT16 IAT; //Intake Air Temp in tenths of deg F

UINT16 CLT; //Coolant Temp in tenths of deg F

UINT16 EGO; //EGO Narrow Band

UINT16 AFR; //Wideband AFR tenths

UINT16 BAR; //in tenths of kPascal - set at startup

UINT16 TPS; //throttle position %- true analog if aftermarket is used

//If stock system, 0=idle, 100.0 = WOT,

UINT16 Pulse_Width; //cur pulse_width in uS

UINT16 Status; //System Status - uses bit defines above

//b.0 - b.15

} ENGINE_struct;

It's a 32bit processor so it would be better if my UINT16's were 32, but I wanted to keep the size down so when I transfer to the PC, I can send it over the link faster. I want a nice snappy interface for feedback/tuning. I though about two different packets going back: One that has only a few vars that change the fastest: RPM, MAP, ICPW, TPS, AFM and then another that reports slow sensors such as CLT,IAT and such, but I think that's overkill. The link is 115200 & I can do all the above sensors (around 30bytes) in 2.5ms if I send in raw hex. If I send in ascii (which is more handy to debug/test) it's more like 10-12ms which is still plenty fast enough. The simulator I have updating at 100ms (10/sec) and it's still quite snappy and responsive on the graphs/gauges.

The A/Ds by the way are all 16bit as well. The pic line would also make a good starting point. I've done several smaller pic projects, but never anything with their larger parts. Coming from a Motorola background, I could never get past their 'Not Bit test skip if not clear | the moon phase is waning' method of branching. It always made my head hurt.

Lenny

[superlen]

RCB,

That's hilarious on the K&N filter. The Zfuel in plug n play mode could not be detected unless someone:

1) pulled the drivers side kickplate off

2) Disconnected/removed your ecu

3) Opened the case to look at the printed circuit board

4) & knew the difference between late 70's electronics and modern electronics.

The only thing that may make them curious is that your emissions should be lower than any Zcar they have every measured. I'm obviously not the one to condone tricking the 'man' in this manner, I'm just saying that it's possible.

Lenny

[LeonV]

This escalated above my programming experience very quickly! Great work Lenny, this is a fantastic project.

[Captain Obvious]

I think what really killed assembly programming is speed. Chips today just run so damn fast that speedy assembly code isn't that critical for most applications. Even if the compiler does silly things & bloats the code, it still runs 100 times faster than it has too.

Makes sense. Moore's Law historically has been as accurate as Murphy's Law, and if memory space and processor cycles are cheap enough to burn off, then why not, right? However, for this application my plan for all assy wasn't driven so much by cost or speed, but for reliability and predictability. I wanted to know exactly what was in all the registers at all times.

I'm out of touch and I'm comfortable with that. I always wrote the low level interface code for the stuff I designed, but I've never been a software jockey. I've done just enough to be dangerous.

You're clearly going a lot more complex than I had planned to do. I was thinking just model the transfer function of the original ECU and that's it. Let's see... Of your vars above, the only things I need to know are AFM, IAT, CLT, TPS, and Pulse_Width. Everything else was for phase II.

So I don't want to hear about it when your interrupts hiccup once every few days and you can't track it down. Are you sure you main loop will be able to keep up at 100ms worst case update at redline? You got a pulse width module timer in that beast so you don't have to babysit digital output pins to drive the injectors?

About the battery voltage... The original ECU tweaks the injector pulsewidth WRT battery voltage. Higher voltage opens injectors faster and all that. However, if I were doing this, I would probably switch to one of the pre-canned injector driver IC's that has the voltage correction built in. That would be one less thing to worry about and would be much more consistent than the stock system or trying to make that adjustment yourself. If you use something that has the fast opening peak/hold current control as well, then you can get rid of the injector resistors and run Vbatt right to the high side of the injectors.

The PIC stuff was intriguing. I did maybe three projects with them, and it sure was a paradigm shift from the Motorola stuff. It took a little sideways thinking to figure out that branching stuff, but once I got a handle on it, I really liked it. It's like Whaaaat? Skip the next instruction? What the crap is that? You have to use goto's? I was always taught that goto's were evil.

You need to embrace the goto.

But guess what... The newer bigger PIC stuff has conditional branches just like Mot. Feels like home.

[Captain Obvious]

Fortunately, both the 260s have triple Webers.

Fortunately???

Wuss.

[rcb280z]

Lenny,

I say we trick the "man" and make this work. Sounds like the ball is in my court so to speak. I'll bet I can make it work.

Bob

[LeonV]

Fortunately???

Wuss.

Ha!

The original flat-tops are sitting in storage, just in case.

[Captain Obvious]

Haha! If you weren't so far away, I'd put em back on for ya.

I bet I could convert you to the dark side...

[superlen]

Captain,

I too though the exact same.. just model the transfer function and knock it out....then damn feature creep. And, when I have the interrupts flaking out, I'll do more than tell you about, I'll put a scope in your hand and have you babysit/trigger on the event while I drink beer. haha.

Loop time is no problem. All timing inputs/outputs are input capture & output compare timers accordingly. The only thing main does is check the serial, read the sensors, calculate the pulse start/stop times, set the timer registers. Plus, it's running at 100mhz & has a floating point unit so the "calculate the pulse start/stop" step should also be blazingly fast. That's why I thought about just using floats. I ended up NOT doing that; most are all integers. It makes the code a little less readable as units are sometimes 10x or 100x larger than displayed on screen.

As for the injector drivers..I hate 'em. They work great, not too expensive, have lots of handy features for short circuit test/reporting ect, and are packaged well. However, the supply side of the equations sucks. Since they are primarily sold to the large OEMs, you are at the mercy of what the OEMs want. If they change to a newer style, your supply then drys up. Back in the 90s I had an industrial chicken skinner that I used one on to drive some external solenoids, and every 6 months they would go obsolete and be replaced by a newer/better part. Granted, that was early on in FI driver IC development, so designs and supply are more likely stabilized now, but it left a sour taste in my mouth.

My plan was to use some discreet FETs so that there were multiple manufacturers to ensure a good supply & not be sole-sourced to one specific part. It would be easier to use a driver though (less design time, less testing, more features). I should look back into them again and see what the supply chain looks like now. It's possible that more than one manufacturer has adopted a common package/function. I didn't know that they were available with battery correction built in. I wonder how they accomodate different characteristics of injectors? Thanks for asking about these.

I'll be able to support both low & high impedance injectors, but for now to get the plug and play going, I'll just use stock high impedance. You'll still need your resistor pack.

Len

[Captain Obvious]

I don't know anything about the supply side as I'm jut datasheet shopping. Never actually tried to buy any of the injector drivers.

From fuel injection to industrial chicken skinner... You'll have to walk me through that one over drinks sometime.

FYI, the original ECU used a pair of NPN Darlington BJT's to drive the injectors. Three injectors per driver pulled to ground. They segregated the ground for these drivers from the rest of the circuitry so the switching currents didn't mess with the analog front end. Separate analog and digital grounds inside the ECU.

[superlen]

You can't be an engineer in Arkansas unless you do some project related to chickens. It may be a state law?? I've worked on poultry skinners, evisceration equipment, turkey baggers, popup timer inserters, automatic weighing systems, chicken house dimmers, curtain controllers....it's a good think I like chicken.

If we can ever connect in the same city sometime, I'll buy beer...and or course chicken.

I haven't reverse-engineering the analog ecu mutch, but it doesn't surprise me that they did some careful layout. I'm still constantly amazed at how well they made that system work with the technology they had. Of course, I was always in awe of my father rebuilding a carb & actually understanding them as well. He was an old school mechanic and owned a garage/body shop in the small town I grew up in. When the electronics began showing up in the late 70s, early 80's. He was in his early 50s and was quite annoyed with anything electronic controlling an engine. His theory on engine tuning was if you can't turn it, bend it, or drill it, it should just be set on fire and rolled into the creek.

I was in my early teens at that time, loved electronics, & so naturally ended up debugging most electronic issues. That's what made me decide to become an EE.

I have to fix a massive injector rail leak on the Z today, but once fixed I'm hoping to start characterizing the pulse widths at some know conditions and then compare them to some of my calculated values. I have several sets of wiring harnesses and extra sensors so I'll make a bench test setup as well...assuming I can find my bench. It's currently completely covered with parts, tools, the cat, ect.

Lenny

[Captain Obvious]

Yeah, the original ECU is a highly trimmed black box full magic and voodoo. I didn't do a lot of reverse engineering either, but I did get through the output stage and the "After Start" enrichment section. Tough part is there are three IC's in there and I have no visibility into what's inside the cans. They predate DIP packages, and there's no discernible standard like "opposite corners are power and ground". So for the sensor inputs, I've traced the circuits up to the IC's, but once they connect to one of the IC's, I hit a wall.

I hooked the ECU up on the bench with a scope and a sig-gen and tried to get it to speak, but no luck. I just stuck in fixed resistors for the sensors, but I must have missed something because I couldn't get any injector pulses. Then I ran out of time on that project and moved on to something more pressing. My car runs well so it was an academic investigation only.

But think about this... All analog. Instantaneous continuous response. Smooth transfer function. And has been bulletproof reliable since 1977.