Fred's firmware development diary

[Fred]

Apparently what I posted above was not the issue, however it is worth doing things properly anyway.

I have most of the code in place for my queued PIT timer scheme (52ms limited), and in normal mode it works as it did before. When I put the rest of the code in place, hopefully it will work as anticipated. I'll be working on that today.

Admin.

[Fred]

It's still behaving strangely, but I know it needs more work in a number of ways. I'll keep working on it as it is getting closer. As soon as it even sort of works, I'll release 0.0.12 as it's been too long since the last release.

[Fred]

Progress :



This proves that my code is kinda sorta working which is very positive :-)

Now, the current issue is that it sticks on long dwell if you go any longer than what is shown in that image. If you then pull back the dwell, it stays long. This I find weird. I'll have to output some values to look at to diagnose it I guess. Though, ironically, I'm a bit short on IO for using the pins as binary number displays. I need to get some serial I/O happening, how are you going, Aaron and/or Cam?

Admin.

[Fred]

OK, the behaviour isn't consistent. Sometimes it will produce a full 52ms dwell (which I find surprising as I don't see how it's possible!, and other times, about 40ms is max. This makes a little sense, maybe. Because I have 5000x0.8us of retard on the signal fixed I imagine that one of those should be subtracted from the 52max, but the other half, not so sure. I'd have to think about the semantics more carefully.

This is very very positive though. It's pretty close to doing reliable ignition duty. Once that's done there are other interesting things I can move on to and we will start to see the thing taking shape for real :-)

Exciting times!

Admin.

[Fred]

If I bump up the rpm, I can clearly see the dwell creeping :-) cumulative error that can only be introduced by the queuing method. Further proof that the code I wrote does something :-) even if wrongly.

I snapped 3 more shots of it at different speeds to see what affect that hand on the maximum dwell period. A lot.

1.33ms max dwell at that rate



15ms max dwell at this rate (same as on previous page) :



And how it looks after it's been creeping for a while :



I'll have to have a think about that one. This explains the sporadic stability at higher speeds though. Which is good. Bugs are OK provided you know where they are so you can fix them :-)

Admin.

[Fred]

I added advance (instead of the fixed 5000) and magically it now does longer before dieing...





Moving advance definitely affects the way it works, and the cumulative thing is still occuring sometimes, but not other times.

I'll have to play with it tomorrow.

I may release it as 0.0.12 in the morning anyway as it has a bug fix for the fueling side of things and it's been a while.

Perhaps someone else can play with the ignition code too and show how brilliant they are with embedded C :-)

Admin.

[Fred]

0.0.12-bastard is released

http://www.youtube.com/watch?v=ti-Qe3Q9-ZM

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

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

Changes :

0.0.12 (bastard) 4/5/08
Fixed bug 5 : forgot to add code run time to test for injector hard on behaviour!
Added tooth counters for displaying tooth timing patterns in conjunction with last tooth time stamps at low RPM
Added configurable tooth polarity to rpm/engine position inputs
Fixed a mistake in the code that allowed a ~0x10 to occur (wasn't causing a problem in this instance)
Added PIT based queued ignition functionality which kinda sorta works

Bugs present :

6. PIT ignition code gathers a cumulative error in queued mode
7. PIT ignition code sticks at high dwells
8. PIT ignition code gets out of sequence when a spark event is missed
9. PIT ignition code can't dwell long enough at various speeds and advances

Admin.

[Fred]

I discovered tonight that any advance/retard of the beginning of dwell causes the large growing dwell issue. if you wind up the advance it grows so fast you can barely see it, but at some values you can watch it pulse up and down. I took a video of it. It's bed time though, I'll think about it and work on it more tomorrow. I think I had a loop wrong too, so that should be fixed now, but I haven't checked the scope results vs. the old ones to see if it helped or not.

Admin.

[Fred]

Well, tonight I made stuff get sent via serial :-)

The code is extremely basic and highly useless, but I can now work on improving it and making it useful for debugging :-)

Eventually we can work the protocol in when it is fully developed and matured.

Excellent.

I think a release is called for tonight :-) (IF I can get it to a more generically useful state!)

Admin.

[Fred]

I was sending the 16 bit value for seconds counted followed by a new line, but no carriage return, I was sending once per second, I got this :



Which is nice. I had to adjust the parity and bit count etc first, but it worked :-)

Admin.