Timer speeds

[FFMan]

Previously i used a zx24a to capture engine rpm using inputcapture and in testing i found i needed the following statement to get the scaling correct.

register.timerspeed1= 2

I am not trying to do the same on a zx24x,= and i note the clock speed is double the zx24a

the documentation lists TimerC0 as relating to inputcaputre on this device, but i can't get the syntax of the statement right. None of these will compile:-

register.timerC0speed

register.timerspeedC0

where am i going wrong ?

[dkinzer]

There are two "timer speed" registers: Register.TimerSpeed1 and Register.TimerSpeed2. The 1 and 2 have nothing to do with the timer that may be being used. Rather, Register.TimerSpeed1 is used with some I/O routines and Register.TimerSpeed2 is used for other I/O routines.

For InputCapture() and InputCaptureEx(), Register.TimerSpeed1 is used as noted in the Discussion section of the descriptions of both routines.

There is a table that lists which "timer speed" register value is used for each of the various timer-related I/O routines:

http://www.zbasic.net/doc/ZBasicSysLib.php?page=25

[FFMan]

As usual Don you saw my problem before I did. This from your rmail seems spot on:-

For the ATmega devices Register.TimerSpeed1=2 yields a timer frequncy of
F_CPU/8 so the timer frequency is 1.8432MHz. This frequency isn't available on the ATxmega (which runs at 29.4912MHz) because F_CPU/16 would be needed and only F_CPU/8 and F_CPU/64 are available. Which would would better depends on the frequency range of the signal being measured.

Depending on what you're trying to implement, it may work better to use the external signal to clock the timer and then let the timer run for a set period of time. Knowing that period of time and the ultimate timer count would give you an average time between timer clocks.

i.e. there isn't a good timerspeed that covers the range of value i need.

Your suggestion to clock the timer etc. How would I start on this. Can I use Pulsein or am i likely to hit a similar issue.

the pulse width would seem to range from say 100ms between pulses to 4ms although as yet i haven't determined on this engine whether it runs wasted spark or not, plus I have 2 coil, so these numbers could be required multiplying or dividing by 2.

Ideally this measurement needs to be as little blocking as possible as there is also an attached gps runnign at 15,200 into a h/ware uart and an sd card logger accepting output.

Any pointers much appreciated. I have a scope and signal generator to hand for test purposes.

[dkinzer]

How would I start on [counting using an external clock]

For starters, you'll need to get the xmega A manual and read up on the timers, the event system and interrupt handlers.

http://ww1.microchip.com/downloads/en/D ... oc8077.pdf

The high level overview would be something like this:
- configure the event system to supply a clock to a chosen timer via one of the I/O pins
- configure the timer to be clocked by the event and generate an interrupt on overflow
- write the timer overflow interrupt handler to increment a variable on each overflow occurrence.

To compute the frequency of the external signal:
- clear the overflow counter, clear the timer and note the current value of Register.RTCTick
- at some later time, note the current value of Register.RTCTick, the current timer value and the overflow count

Knowing the elapsed time (diffenerence between current Register.RTCTick and the starting value divided by Register.RTCTickFrequency) and the total number of external clocks (overflow count times 65536 plus the timer value) you can compute the average frequency of the input signal.

The above is the simplified description. There are some details that need to be observed. Firstly, you must take into account possible rollover from one day to the next. You could handle this by noting if it is a different day than when the Register.RTCTick was originally read and either discarding the reading or doing the math to handle the RTCTick rollover.

Secondly, you may determine that the accumulated external signal count is too low to be meaningful. If so, you could come back later and try again. An analysis of the expected range of frequency of the input signal will doubtless give you a minimum sample accumulation time.

Thirdly, you'll want to disable interrupts while you collect the data from the several places. Even then, though you will have to handle the situation where there is a timer overflow interrupt pending and adjust the numbers accordingly. As usual, you'll want to have interrupts disabled for the shortest amount of time possible.

There may be other "gotchas" that I didn't think of.