Timing issue on 18m2

[satrapus]

This code is meant to pause for the amount set by a pot (from 1 to 60 seconds):

I tested with pollingInterval variable set at 10, 25 and 50ms.
An expected 60s pause took
10ms -2m 28s
25ms - 1m 35s
50ms - 1m 17s respectively.

There is not that much code executing but the poling interval has a big impact on accuracy.

IntervalTiming:
  symbol alarmTimer = w8
  alarmTimer = 0
  elapsedTime = 0
  do
    ...
  elapsedTime = 0
  do
    ; motor off while pause for potTime amount
    gosub DetermineSwitchPosition
    if switchPosition <> 3 then MainLoop
    Pause pollingInterval
    elapsedTime = elapsedTime + pollingInterval
    gosub DeterminePotTime
  loop until elapsedTime >= potTime
goto IntervalTiming

DeterminePotTime:
  ; Return potTime as 1000ms to 60000ms
  symbol MAX_SECONDS = 60
  symbol MIN_SECONDS = 1
  symbol POT_PIN = c.1
  ReadAdc POT_PIN, potTime
  potTime = MAX_SECONDS - MIN_SECONDS * potTime / 255 + MIN_SECONDS * 1000
  return

DetermineSwitchPosition:
  ; Sets global 'switchPosition' variable
  if swchPinTimed = 1 then 
    switchPosition = 3
  else if swchPinCont = 1 then
    switchPosition = 2
  else
    switchPosition = 1
  endif
  return

I guess the only solution is increasing the pollingInterval to the maximum tolerable value.
From what I read the m2 elapsed time counter is also effected by pause commands right?
Help please.

 

[techElder]

This doesn't really compile as you've listed it, does it?

There's no symbol definition for "elapsedTime". There's no label "MainLoop".

You need to post the complete code. And by the way, spruce it up a bit by adding "white space" with tabs and extra lines. Makes it easier to see what you are doing.

Also, add [code] at the beginning of your code and put [/code] at the end of your code. This also helps the rest of us to read your post.

 

[srnet]

There is not that much code executing but the poling interval has a big impact on accuracy.

Thats to be expected, due to the time it takes to process each loop\addition of the polling interval.

Which from the results you produced suggests that eack loop through the count is taking 14mS.

So the actual pause, but not the loop count calc, needs to be 36mS.

 

[satrapus]

Can you please explain how you worked that out and which pollingInterval value (10, 25 or 50ms) you used in the calculation.

 

[AllyCat]

Hi,

From your original post (which I agree would have been better added into your original thread), 6,000 polling loops take 88 seconds longer than the basic pause, 2400 loops take 35 seconds longer and 1200 loops take 17 seconds. They all produce roughly the same (excess) execution time of 14.5 ms per loop.

So 10 ms polling is impossible with that code, 25 ms needs a pause of about 10, and 50 ms needs a pause of about 35 ms. I haven't checked your code in detail, but suspect that code with a 10 ms polling loop is possible at the default 4 MHz clock frequency if required (and certainly with elevated clock frequencies).

Cheers, Alan.

 

[satrapus]

Thanks very much Alen.
I've set polling at 50ms.
With the pause at 36ms the pot timer is just over a second out when set at 60s which is brilliant as I don't require greater accuracy than that.

 

[hippy]

elapsedTime = elapsedTime + pollingInterval

The problem there is that the time of each loop is rather more than the pollingInterval; about 14.5ms longer as AllyCat calculates. So if you use -

elapsedTime = elapsedTime + pollingInterval + 14

That will make elapsed time more accurate. In fact you could simply take the "PAUSE pollingInterval" out of the program completely and just use -

elapsedTime = elapsedTime + 14

And, without the PAUSE, you will be polling as fast as possible, every 14ms, and still be accurately(ish) tracking elapsed time.

 

[satrapus]

Thanks Hippy! That makes the code cleaner.

I am now waiting for my proximity sensor ready solution to arrive.
Once tested I will decide if I'll use an interrupt or just leave the code as is.
I tested the scenario by using a polling time of 50ms and simulating a high on the ir sensor by quickly touching it's input pin.
No high signals were missed so even 50ms seems to be plenty fast enough.

A big thanks to all the kind folks on the forum for helping me get this far.
The end finally seems in sight