08M2 - synchronising with the time variable

[afb]

I'm making a variable period timer from 10 seconds up to 10 minutes or so - required resolution of one second. Happy with the accuracy of using the time variable, but finding a problem with starting the the timing period. The command time=0 sets the time register to zero but the overall function seems to be free-running so the first increment of the time variable can occur (I find by experiment) anything from immediately up to one second later depending on just when the "time=0" command was executed. Not an issue at the 10 minute end of things but a large error in 10 seconds! I can improve the situation slightly by running at 32MHz to reduce the error to a maximum of half a second but would prefer this to be a tenth of a second or less.

Starting a PWM stream at 100Hz (possible at 4MHz) - presumably derived from the same internal timer - and counting/dividing its pulses by 100 from the moment of button press works ok, but robs me of an input and output on a project that already uses all the available 08M2 legs (incl a "disconnect" SERIN). I'd prefer not to do it this way with a 14M2 on the grounds of size.

ANY IDEAS ?

 

[hippy]

The command time=0 sets the time register to zero but the overall function seems to be free-running so the first increment of the time variable can occur (I find by experiment) anything from immediately up to one second later depending on just when the "time=0" command was executed.

That is correct. Setting 'time=0' is similar to moving the hour hand back to 12:00 on a clock but leaving the minutes hand where it is. It will then reach 01:00 some time between 1 and 60 minutes later depending where the minute hand was.

You could take control of the internal timer and read that or look for overflows to do your timing with PEEKSFR and POKESFR. There should be some discussion on doing that on the forum.

You can also hacksaw some legs and part of the body off a 14M2 to make it smaller. Not sure if that would help as I haven't checked a pinout diagram.

 

[afb]

Woo, that peeking and poking sounds dangerous, but I'll check it out - thanks for alerting me to this possibility. I'll pass on the bypass surgery idea though thanks!

 

[techElder]

If you do SETTIMER = t1s_4 and then timer = 0 doesn't that sync it?

 

[hippy]

If you do SETTIMER = t1s_4 and then timer = 0 doesn't that sync it?

Yes, on an X2

 

[techElder]

New 8X2

Ah heck! afb, get you a 40X2 and get to work with the hacksaw!

 

[afb]

great idea, and that way I'd get 5x 08M2 from every 40 pin package, right? . . . . any tips you have on reducing it from 0.6" pitch to 0.3" pitch would be most welcome

 

[techElder]

Do it the way us old-timers used to do it ...



... and a leetle glue.


EDIT: As long as you leave 20%, you'll still have an 08.

 

[AllyCat]

Hi,

Back to the original issue. I don't believe that any register to PEEKSFR or POKESFR is known (unless hippy does). The internal Timer1 (which can be peeked) "ticks" every 20 ms but that is then counted by an interrupt driven (?) software pre-scaler which increments the time variable once for every 50 counts. Sadly, I don't think that prescaler value is accessible in PICaxe Basic (which is a pity because it could be very useful).

However, you can start and stop "time" by using DISABLETIME and ENABLETIME, so a method which can be used is initially to test the time variable in a tight loop until it increments, then DISABLETIME. Now, you can start a time measurement with ENABLETIME and it will "tick" exactly 1 second later.

But beware that the time variable is only accurate if certain commands are avoided. Unfortunately those are not formally documented, but probably PULSIN, PULSOUT, SERIN and SEROUT, etc. if they exceed 20 ms, may need to be avoided (or worked around).

Cheers, Alan.

 

[afb]

Hi AllyCat

Thanks for your elegant solution using DISABLETIME and ENABLETIME - the logic is now obvious to me though I doubt I'd have reasoned my way to it without a prompt! I can report to other readers that my diagnostic program confirms a near consistent number of nominal 20mSec ticks in the first and each subsequent second of timing - given that my software 'ticker' is free-running. Most relieved I can stay behind the wheel rather than have to POKE about under the bonnet (or hood if Tex is listening). Thanks for the caution on conflicting commands - that was something I *had* previously read about - the only suspect command I'm using is PULSOUT, but that's to drive a servo and is thus limited to a maximum of 2mSec.

Thanks again, and keep taking the clever tablets . . . . .

(another) Alan