DIYEFI.org Forum

Exciting news (well, not very, but a small claim to fame)

FreeEMS now has a feature that MS does not :-)

http://www.youtube.com/watch?v=iCgvZvybzBc

Low voltage detection and recording.

i.e. if your power feed is bad or you have noise on your lines dragging the CPU low, but not low enough to reset, you will see it in the logs.

Admin.

I have the pit timers running and doing something, but nothing useful just yet...

I'm working on it.

Well, for the first time in 9 days, the code compiled and after another few minutes it looked like it might even do something :-)

Alas, it has a bug. I don't know quite what, but when you bang the reset button a tone proportional to input RPM comes out of the speaker for a split second and then it locks up and no other code runs. If you hammer the reset and a port H button at the same time, eventually you toggle the LED for port H interrupt code. This is happening in the short time before locking up. This narrows it down to injector code or ignition code. I'll check it out in the morning. Things should be up and running fairly soon. I'll have been caught out with pointer use somewhere... maybe some sort of array index issue. Not sure. Definitely resolvable though :-)

Admin.

After actually sleeping, I noticed this while commenting other stuff out to eliminate it.



Of course, I quickly uncommented everything and this, and we are back closer to where we were, but still not all the way.

When wheel inputs now function again, but fuel and ignition are still missing for some reason.

Hopefully I'll iron that out some time today.

Admin.

He went that-a-way!



I just proved that my pointers are pointing in random directions (and had breakfast).

PORTA being at 0x0000 has its advantages :-)

Hmmm, grep -rn PORTA . doesn't show me writing to it... yet its flashing proportionally to RPM... hmmmm.

Admin.

After trying all sorts of stuff to get it to behave, I moved the init of the array of pointers to the init.c file instead of global.c so that it was something run rather than something existing before runtime, and it works mostly.

It's a bit funny though, so more debug/understanding required.

Seems like its resetting constantly. Not sure why that might be, but I can test for it by displaying a clock variable on a port, and also some other counters that might tell me why it's resetting...

Target was 5pm release, I think I can manage that now, but we'll see. Only time truly ever tells if code will be good to go on time or not :-)

Admin.

Well, it was definitely hardware! Interesting. Caps on the RPM inputs are a BAD thing apparently. Not only do they combined with the input resistor severely limit RPM, they also severely shorten the pulses, but worse, they do it in an rpm dependent way. I snipped the returns on the two H1 input caps and put bigger caps straight onto the adapt card. that made it worse, not better, so i put smaller ones in, better, took them out, perfect. strange.

I'll repeat this info in the hardware thread so other testers don't make the same mistakes.

The good news is that the code is a lot shorter and cleaner and works exactly as it did before :-)

This arvos release will be a good one hopefully, even if it doesn't have ignition working just yet.

Admin.

http://www.diyefi.org/forum/viewtopic.php?f=8&t=93

0.0.9 released

get it here :

http://sourceforge.net/project/showfile ... _id=586108

0.0.9 (exponent) - 22/3/08
Refined injector control further
Implemented RTC in RTI for 1/8 milli, milli, tenths of, seconds, minutes each with 65535 max
Removed 6x duplication in injection_isrs.c by splitting to injector_isr.c and using defines and imports.
Added support for individual fuel pulse widths
Added latency adjustments and recording to minimum pulse width
Added code run time recording for each channel
Updated docs for injection algorithm
Added LVI interrupt logging to record low voltage conditions.
Added ADC sampling and flagging code
Heavily revised all fuel code to use arrays instead of defines.
Removed 6x duplication in the scheduler code
Tidied up MANY comments and code blocks a LOT

I should release a bug fix for the 0.0.9, but because no one is using it just yet, I'll just tell you that I have fixed it and it will be right in the next release.

If anyone needs the code for whatever, let me know.

I decided to try to verify the fix, and wrote the lost sync counter out to an IO port. Within a few seconds of operation I had a "lost sync". That could easily have caused the issues I was seeing. I'll changed that bugs status to fixed and get on with making ignition and injection timing a reality.

My initial simple attempt to fix injection timing failed. So, I need to try to understand what is going on there and resolve that.

Admin.

Admin wrote:My initial simple attempt to fix injection timing failed. So, I need to try to understand what is going on there and resolve that.

X = Y > 1;

is not equal to

X = Y >> 1;

woops :-)

It works now.

It needs prediction so that it can come closer to the maximum amount during dynamic situations, but, currently limiting to half of an engine cycle or 0xFFFF (whichever is smaller) works pretty well.

On with ignition/staging (which are more or less exactly the same) :-)

Admin.