Friday, June 4, 2010

Back to the bits'n'bytes

There's been an on-going battle between me and the ATMega chip recently. I wanted it to work as a rev-counter and spark timing reporter, and it didn't want to be reliable.

at first I had the idea that it was the fault of my detection process or algorithm. I had a 555 timer configured as a flip-flop triggered high by the incoming spark pulse and reset to low by the engine TDC detection. That way (I thought) I could measure the width of the pulse and the frequency of the full cycle, and calculate the RPM and spark advance. It failed quite spectacularly and very bizarrely, giving fractionally out of time results as well as full cycle multiples. I now realise that it was the way I was detecting the pulse that was causing a lot of the issues.

An ATMega processor can be set up to accept any pin as an interrupt, but unlike the 'real' interrupt lines, it can only detect a change of state on a standard pin. Consequently the programmer has to manage the state detection and pulse/cycle duration calculations. This was causing me headaches. My folly was that I believed the problem was all down to timing constraints, and tried several ways to improve the code.Nothing really worked.

Then I read some more and found timers ... with the pulseIn() function, measuring the spark pulse was a no-brainer ....

But there were still definitely timing issues with the reporting (I'm using Serial.print() to show the results on a terminal) and I found that when I upped the pulse rate to > 7000 rpm, the output routine was taking too long and the cycle was skipping a pulse. Consequently I had a rev counter running at 50% of the actual revs.

I eventually fixed that by sampling two pulses and the space between them ... A little extravagant, but now I can report up to 25000 rpm without a glitch and with accurate spark timing ... but I lose one pulse per sample.

A case of standing too close to the coal face ...

The reason for my obsession with sampling every pulse was caught up with the future need to manage every pulse when actually generating spark timing rather than reporting it. Consequently, I didn't recognise the evident fact that the timing generator would only be detecting a rotation pulse and flicking a pin about 2.5 to 48 milliseconds later ... so there would be no communication overhead in this case.

Happy bunny time ...

So now I have a working rev counter and timing reporter which can communicate the results faster than the eye can detect jitter on an instrument, and the plan is in place for the timing driver as well ....

... And finally I feel ready to start on some simple sensor interfacing and display drivers ...

No comments:

Post a Comment