Newbie timing problem

PropNewbie · 2008-09-01 19:57

Using the code below to get a simple 1khz toggle on a pin. I am getting values significantly different than expected. For a delay of 40000·I get 963.3 hz output. For the following delays I get

Delay····Expected (Hz)···· Actual (Hz)
40000······· 1000·············· 963.3
20000········2000··············1881.0
10000······· 4000············· 3551.0

The board is a Propeller demo board with the supplied 5Mhz chip.·Measurements taken·on a Fluke 8060A multimeter. I don't think it is the meter playing games - I tested it against the 1khz calibration output on my scope and it was spot on. (I trust the meter more than my super cheapo scope).

Can anybody shed any light on why the values should be off by so much?

Code below
###########

CON
· _CLKMODE = XTAL1 + PLL16X
· _XINFREQ = 5_000_000
·
PUB Main
· Toggle·
·· return

PUB Toggle | delayCnt
· dira[noparse][[/noparse]3]:=1
· delayCnt := 40000
· repeat
··· waitcnt(delayCnt+cnt)
··· !outa[noparse][[/noparse]3]
·

hippy · 2008-09-01 20:42

This problem is described in the propeller manual ( not sure of the page ).

What you have is a fixed length pause in waitcnt() whereas what you want is something synchronised to a constant timing mark. What you're seeing is due to the effect of executing the internal code for 'repeat' and '!outa[noparse]/noparse'.

Philldapill · 2008-09-01 21:40

This is a classic problem with trying to have a sync'ed time interval. Try something like this:

PUB Maintime := cnt
interval := clkfreq/100     '100Hz
 
repeat
  DoSomethingHere
  time += interval
  waitcnt(time)

Mike Green · 2008-09-01 21:41

This sort of thing is described in the WAITCNT section of the Propeller manual.
It allows the WAITCNT to wait for time points a specific number of clock ticks
apart regardless of the execution time of the intervening Spin statements.

PUB Toggle | delayCnt, time
  dira[noparse][[/noparse] 3 ]:=1
  delayCnt := 40000
  time := cnt
  repeat
    waitcnt(time += delayCnt)
    !outa[noparse][[/noparse] 3 ]

PropNewbie · 2008-09-01 21:49

Really?

I did read about that - it is in the WAITCNT section under "synchronized delay timing". It just did not seem to be the likely source. How many cycles do a single REPEAT and OUTA statement take? My calculations work out that to generate the observed error of 37 Hz for the 1kHz wave, the loop overhead and OUTA would have to take 1480 clock cycles. Is this reasonable?

I sure appreciate the advice and assistance

Philldapill · 2008-09-01 21:59

I'd say it is. If each instruction takes at least 4 clock cycles, that is 370 intructions - which is fairly in line with what I've troubleshooted through before. I was doing something similiar, except mine was just an RTC with millisecond precision. Until I realized how to properly synchronize like this, I was getting about the same results in delay. Mike?

hippy · 2008-09-02 00:29

dedgar said...
My calculations work out that to generate the observed error of 37 Hz for the 1kHz wave, the loop overhead and OUTA would have to take 1480 clock cycles. Is this reasonable?

Sounds about right. The code is executing approximately 8 Spin bytecode instructions so that indicates around 185 cycles each, 46 PASM instructions per bytecode. That's in the right ballpark.

Newbie timing problem

Comments