Fred's firmware development diary

[Fred]

I had forgotten to add a particular variable in a particular place. The effect is that 0.0.11 has a potential instability on the border from pulsed to full on. 0.0.12 does not have that.

I have the code runtime set to 100us approximately as a conservative pessimistic estimate (reality is more like 1 - 4).

The following screen shots show the closest that I could get to full on without being full on with the JimStims artificially low RPM limit in Denso mode, and the artificially high code run time.





As you can see, in the shot that doesn't show the speed, the scale is 500us/division. You can also see that the gap between the pulses is exactly the 100us that is written in the code.

151Hz = 9060 RPM, so this is somewhat worst case. Given that the value used for code run time will most likely be between 5us and 20us. The total period is 6621us, so the pulsewidth can hit 99.78% worst case and around 99.92% best case both at 9k RPM. This will be undetectable due to jitter at lower RPMs.

I'm pretty happy with the fuel code at this stage.

Ignition and decent engine/rpm decoding need more work now. The glue math (after extensive discussions) and serial comms and flash burning. About then it will be car ready. When then is is hard to know.

The next week will prove to be very interesting for the future of this project and its overall direction. The only thing that could actually change where it's heading, or rather the rate at which this is heading, is the release of MS2Extra code under GPL. Because the chances of that are about as high as me waking up tomorrow morning to the sweet sound of the waves lapping on the hull of my boat in a quiet lonely bay somewhere in the far north of NZ, we are on track to get this thing out there and running in the medium term. If I do wake up tomorrow morning on a boat in NZ you probably won't see another release for a while, and if so, it will likely be a ported GPL MS2Extra code set rather than my own. However, that is all a pleasant dream.

It's time for a shower and brekky.

More code later today hopefully!

Admin.

[Fred]

Hi,

Things have been going pretty slowly over the last few days as I have been fairly busy doing Admin work here and there. That trend is likely to continue over the next couple of weeks unfortunately. Don't be put off, I have not forgotten and will not give up. Ever.

The influx of users in the next few days ought to keep me on my toes for sure, but I'll be working hard on the system constantly between doing Admin duties.

I'll keep up my current record of releasing code to the public as soon as I have a block complete-ish. Such releases can definitely be treated as experimental, and you can expect bug fixes for new features in subsequent releases (as you always would with a pre-alpha).

I'll also keep up my habit of posting here as I learn and discover the way the hardware works during development.

Thanks for all your continued support! :-)

Admin.

[Fred]

From 2.2.5.5 of S12XCPUV1.pdf :

While the I bit is set, maskable interrupts can become pending and are remembered, but operation continues uninterrupted until the I bit is cleared.

I had been thinking about the way interrupt setup was done inside the init sequence, and this somewhat confirms my thoughts. The interrupts should be done last, in an intelligent order, masks cleared sequentially and then interrupts globally enabled.

This made me think about the case when the cpu wakes up on a tooth and the end of tooth code runs before the start tooth code. I'm not sure it will matter at all as is, but I should keep this in mind and try to keep track of state to ensure that it doesn't matter.

Admin.

[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.

I believe I know why this was occurring now. Because of the semantics of above posted interrupt vector fetching, by clearing it at the end, I was infact clearing the next scheduled interrupts flag and stuffing everything up by doing it. It would appear to be a very bad idea to not clear any flags except inside the ISR, or while all interrupts are masked.

Admin.

[Fred]

Huston, we don't have ignition, but I'm making progress.



blue is broken-inverted-ignition-like-thing, green is stable-sweet-as-honey-fuel pulsewidth with sync for the scope

Bevaviour is strange to say the least. I'll keep working on it though.

Admin.

[Fred]

I inverted the code, and ended up with vaguely correct behaviour sometimes sort of.



What is happening is that it is that the ignition event is happening when I prod the PIT registers in the scheduler. Why this is happening I'm not sure, however it is apparent that I don't understand the PIT timer scheme well enough to use it just yet. I'll have to do some in depth reading and figure out why this is.

I just noticed that I wasn't clearing the Interrupt flags after setting the interrupt enable bits, but doing that didn't change the behaviour. Also, increasing the "dwell/retard" decreased retard which is backwards to what I would have expected.

Something is funny, just waiting for the "click" now I guess :-)

Admin.

[Fred]

Well, I was fiddling with the pots tonight testing some other changes and by chance ended up with one from six ign channels functioning correctly :



I'm still not certain why it's not functioning as desired, but I have a few ideas to try out tomorrow.

Admin.

[Fred]

'Bout bloody time I updated this thread don't ya think??



:-)

"Just" needs some scheduling etc to work in a useful way. I may be able to revert to how it was without the broken math too. We'll soon see.

Admin.

[Fred]

Good news, the increments of time in PIT land are exactly the same as in ECT land, so no funny math to make the values match up. That makes it easy!

Just verified that by adding variable dwell in terms of fuel pulse width on the scope. boundaries match up exactly as they should according to the math.

Admin.

[Fred]

James and Ken found an interesting quirk of the C language the hard way yesterday :

http://www.msextra.com/viewtopic.php?p=185447#185447

The thing is that literals get expanded to 16 bits by default as int = 16 bits.

http://supp.iar.com/Support/?note=12582 ... rch+result

See the confusing behaviour section.

I grepped Al's code and he has a bunch too. I'm guessing that code warrior (surprise surprise) doesn't adhere to the language spec in this regard and is more intuitive and therefore his code is bug free.

I grepped my code recursively and found that I had some too. I was using macros defined as 0x01 etc and ~ing them. The literals weren't in my code, but in the preprocessed stuff. It's worth remembering this and ensuring that :

A we use macros or variables instead of literals in all cases
B we ensure that our macros are correctly defined as 0x7F instead of ~0x80 etc.

~0x80 expand to ~0x0080 which works out to 0xFF7F instead or the expected 0x7F

In my code this didn't have any negative impact, but it could have so I'd like to put a makefile check in for this stuff at some stage and just be careful with it till then.

For general use the notted individual 8 bits are available from the header as NBIT0:7. Macros are there for a reason, consistency, lets use them :-)

Admin.