Fred's firmware development diary

[Fred]

My car now starts great and revs great, win win. I've implemented a dwell limiting/spark duration reservation code block in a hacky way, but it works well so I'll add that to the main code base once I think of a nice way to configure it for general use.

Distributor style setups may have to have fairly specific physical timing in order to work nicely under all conditions, BUT, I'm OK with that because they are not a priority for this, and never were. My car isn't worst case, but it's not far off, so at some point soon I'll tidy up the "simple" decoder and try to run it on that too.

MTX works great for tuning timing, had a crack at that earlier today when setting up the engine.

Next steps are hw mods and getting my shit together or i'll miss the plane! :-/

I want to add mini usb like that dude that sent the photo to Marcos, and upgrade the ignitor drives to be much more powerful so we can run that 4age!

Then it's all refinements, again.

Fred.

[Fred]

A neat trick from Sean0's last commit:

viewtopic.php?f=8&t=1112

Worthy of a thread of its own.

Fred.

[Fred]

Yesterday I did a HUGE commit towards missing teeth generic builds with a lot of preproccessor trickery. Today I ripped out the eventMapping array and replaced it with an if == then = else = a % b; which works sweet on the car and is simpler in the code, especially for dynamically configured builds such as the missing tooth ones...

I'd also like to setup more verification of inputs to the decoder interface, such that decoder authors can't do anything dumb without being warned. Just "number of repetitions of pattern" is enough for that, I think. We'll see.

I was just thinking about scheduling and doing virtual scheduling. For that I need to stash pulsewidths and keep track of them. The I realised that I actually need to do that now, and I'm not! :-/ As it stands, I schedule off of input event 0 and with delay 9000 in the main loop, then in the decoder fire the event from the specified input event, 0, and go on my merry way, BUT, if the scheduler changes teeth between when I fire the output, and when the output event runs, the output event is having its delay swapped out from under it, to a potentially harmful value. I will have to remedy that shortly before anyone else tries to use it. Once I've implemented that, implementing virtual event scheduling is a piece of cake, that part is the hardest part.

The length of the virtual event scheduling arrays is an arbitrary decision, shorter = faster, longer = slower, however, I guess I should make it maximal and then let the loop know how many are actually being used to make it as efficient as possible for a given setup. This work will tie into the variable sync system somehow, as scheduling for a dizzy from a full cam sync wheel is just the same as scheduling wasted spark from a cam sync wheel, more or less. The difference is that in the latter case, the sync can change suddenly and whatever is scheduled needs to keep working with the new sync level. The solution to that is to only schedule on teeth that have a complimentary partner, and to schedule both. Another thing we could do, that just came to me right now, is to specify a sync level for each scheduled event, thus you could schedule BOTH the cam and crank sync events at first, and then only the cam sync ones later once cam sync arrives, and, from the decoder, only fire whatever is configured.

I'll have to think about this a little more, but the solution is close, that is for sure.

Perhaps I should refactor the precision stuff first, though, unsure. Both things need doing.

Fred.

[Fred]

I got some good work done over the weekend while out of cell reception and internet. Will push soon. Lots of good ideas springing up. I should post about some of them soon. Bench test decoder stuff was amongst my work.

[Fred]

And fixed a bug while out of inet in the last few days too. I've been super busy with real life stuff, but the hotel hyundai now starts smooth every time with the bug fix. I started looking over the changes for high res calcs the other night. That requires more work, but I want to get it done before I leave so that I can test it on my own car(s) and not risk anyone elses stuff.

[Fred]

I completed and tested the 0.02 degree resolution timing code changes on my hotel hyundai last night, worked same as before, which is good :-) The hardware timing isn't stable enough to judge the code at this stage, but today we'll get a good test in on a 4age and that should show us some smoooothness. Each decoder needs a retest due to this change, but it was necessary. I'll push the change once I am happy that the three decoders that are supposed to work actually do. Later today I may refactor the scheduling interface to allow multiple events on the same pin inside a cycle and remove the hack from the even teetth decoder.

[Fred]

Preston's 4age silver top ran tonight, on a stand, no exhaust, flames everywhere, wonderful! :-)

The new precision timing code worked beautifully, showing a rock solid timing light mark, and allowing precision adjustment of the base angle down to 0.02 degrees, wonderful! :-)

4 engines! All different! All running nicely! :-)

Fred.

[Fred]

http://www.facebook.com/FreeEMS/posts/215886318421472

:-)

[Fred]

http://stuff.fredcooke.com/Screen%20sho ... 5%20AM.png

1 coarse cas
2 fine cas
3 8 x ign@4ms per cycle
4 artificial pin twiddling to show a transition on each evenly spaced edge
5 - 8 two injections per cycle over 4 pins.

The glitches are:

one of the ignition pulses is consistently in the wrong place
the fuel channels can sometimes give two pulses, one late, after a correct one - the 5th line is doing just that consistently, on the first event in each cycle. It's perfectly consistent at a fixed rpm, which is nice. Easy to diagnose and fix if my yet-to-be-implemented fix doesn't solve both issues.

More progress soon! :-)

Fred.

[Fred]

The main point of the above post was to show the generic scheduling working.

We now have the ability to do :

1) Repeated cycles inside an engine cycle (for partial sync inputs)
2) 1:1 for full sync with sequential and/or cop/cnp
3) Repeated events on a single pin inside an engine cycle (for dizzy or wasted spark or semi sequential etc on a fully synced input)

Currently this is limited to 24 output events on 6 pins and is completely arbitrary. The 24 could be any number, however more than 24 should not be required on 12 or less cylinders without a staged injection setup or multi spark setup. Pretty awesome really, all generic code, nothing specific, odd fire V twin == inline 4 == v12 all the same to my code :-)

Fred.