Fred's firmware development diary

Official FreeEMS vanilla firmware development, the heart and soul of the system!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Fred's firmware development diary

Post by Fred »

Another moment of enlightenment while removing the melted fan from the wall :

http://www.diyefi.org/forum/viewtopic.p ... p=609#p609

A, I think I've been over-complicating it, B, I MUST check the full interrupt flag register to see what is pending such that I can act accordingly...

Once I code to that, It should work beautifully *I think* :-)

Admin.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Fred's firmware development diary

Post by Fred »

I realised last night why I've been having some of my troubles.

Time comparisons are subject to overflow too... ie, 65000 < 0 should return true sometimes. That's what I'll be working on from now on. Once I have that sussed, Injection should be solid, and just a matter of syncing properly (also needs same math) and feeding those 8 functions the right numbers from the number crunching code elsewhere.

Onwards and upwards. It took me a while, but I understand the problem now.

Admin.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Fred's firmware development diary

Post by Fred »

I just had a pair of ideas both of which could work.

A
do more work in the OC interrupt and slam the port back on as soon as we come off if we should have started earlier. then subtract the difference after when we should have started from the pulsewidth and reschedule the end again.

B
When turning on, if period is greater than average cycle time set next compare at this time plus average cylce time and set to turn on instead of off.

I think B has more chance as A suffers from the same "is this less than or more than overflow issues".

Admin.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Fred's firmware development diary

Post by Fred »

OK, it's been a long battle, but I did it in the end. I tried a dozen different ways of making pulse widths overlap, and none of them worked properly until plan B

Lessons learned :
Stick to testing the difference between two figures that you know the order of, not < or >
There was another, but I can't think right now...

This release version 0.0.8 of FreeEMS is dedicated to my old boss Glen. Glen had a saying : "your best work yet" each time you gave him a run down on how totally @#$%ed the code was that you were working on. As I tested this tonight, his words crossed my mind, and inspired by epages releases of old, I have decided to start naming each release after something symbolic. Hence tonights is named freeems-v0.0.8-glen ;-)

notes :
0.0.8 - 9/3/08
Added code and constants to watch pulsewidth vs. min and max and act appropriately
Split constants out to separate files
Managed to make overlapping injection work with "Plan B"
Recording time between odd second triggers in 32 bits using timer overflow technique

3 channels without self schedule to cover the period after the trigger before the next start :
http://www.youtube.com/watch?v=6ujQN5SHKJQ

The working code (the glitches present are a result of time based timing instead of angle, and will disappear for the next release) :
http://www.youtube.com/watch?v=nhIT_ESQQSk

Files :
http://sourceforge.net/project/showfile ... _id=582848

In the vid you can see the treat I gave myself for getting it working : Ozzy chocolate milk. The English do not understand certain things. Among them are chocolate milk, peanut butter, coffee, and other things that they are used to receiving in low quality forms. I have to say, the Nippies iced choc was particularly nice this evening :-)

Over and out at 3am on the dot,

Your admin.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Fred's firmware development diary

Post by Fred »

I thought of another enhancement to this algorithm while I was in the shower just now (all the best ideas happen half asleep or in the shower). If I set a flag that says i scheduled to stay on (at a guessed start time) instead of go off, i can clear it, clear any pending interrupt requests for that channel and reset the new start time to the correct start time instead of a guess. This will make it more stable and predictable in dynamic conditions.

Also with regards synchronous ADC sampling, (another shower moment) if we sample in the wheel code, and set the "calculate it" flag, then we are open to ending up with stale values if the wheel breaks or whatever. So, a timer should be cleared when sampling, and a timeout checked in the RTI or main loop to resample asynchronously at that time and set the calc flag or just calc it.

If we don't do this, pulse width will always appear whatever the wheel code last saw, and the injector could hang open if that and period etc are not reset to sensible numbers.

I'll probably knock out some dummy code to do that stuff with the next release which should be advance retard capable for fuel injection, and I may even play with setting a PIT timer for staged injection. I can think of some simple clear ways to do that configurably with either parallel off or parallel on, or two PITs for independent on and off (but inside the window of primary injection. (I don't think limiting staged injection to happen while inside the main injection is a bad thing, do you? Flacid? Sean? Jean? Alex? I wonder if Alex is reading this at all?

Time to get shorn and go out for lunch.

Admin.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Fred's firmware development diary

Post by Fred »

I've made it even better again!

There are absolutely NO glitches of any kind under any circumstances now.

Instead of scheduling to stay on and setting a flag, i just schedule to go off as usual, and set a flag saying "too long, resched start when its our turn". Much better. 0.0.8 suffers from glitches when decelerating rapidly as the pulses ended up too short for the actual period. Now the only funniness is from excessive timing, once its degrees based instead of an arbitrary amount from a pot... those will not occur :-)

In the immortal words of Basil Fawlty, "Brilliant" :-)

Admin.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Fred's firmware development diary

Post by Fred »

This morning I added a set of RTCs in the RTI ISR that count in exactly 1/8 ms, ms, 1/10 second, second, and minutes.

As a result of that, I was able to see that the CPU was in fact not resetting at 4.3V

I'm guessing that certain aspects of the capture/timer etc fail to work correctly outside of spec voltages and that is what I was seeing, but it's definitely load/voltage related, not code as if i drag the voltage down manually it also occurs.

Admin.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Fred's firmware development diary

Post by Fred »

I have my first bugs to track down :-)

I did a LOT of rearranging etc today to great positive effect, but somewhere along the line I have broken it in two ways.

A. If the unit is reset with the wheel input happening, it never comes back up at all (no code runs). I find this very curious. Not sure why just yet.

B. If you start it without the wheel input, and introduce it, the wheel input code runs as normal, but there is no injection. Also curious. Also no idea why.

Best I get stuck in and find them :-)

This is more like the software dev I have done in the past, rather than not working at all, it just doesn't work right in some weird and hard to find way. Very me :-)

Admin.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Fred's firmware development diary

Post by Fred »

A is fixed, can anyone tell me why I can't clear the ISR flag at the end of the ISR routine? I thought because its in the interrupt until it comes out regardless, it wouldn't matter, but it does somehow at start up anyway. If it's allowed to start not under load, clearing at the end seems to work OK. Strange.

onto B

EDIT : The ISR flag must be cleared at the beginning because although no code runs while in an ISR (except the ISR code) the hardware instruction scheduler is still running and if the flag is not cleared quickly it will be rescheduled before you exit and just run again. So, always at the start!
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Fred's firmware development diary

Post by Fred »

B is fixed too, I had converted the injection channels to individual pulsewidths and forgotten to fill in the numbers from the ADC. It was actually working all the time, but on "min" pulse which is very difficult to see.

onto trying to make the "new features" work :-)
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
Locked