TIME variable question and a request

rq3

Senior Member
Does the TIME variable change with the "setfreq" setting? In other words, is "time=8" equal to "time=1" when setfreq m32 is invoked on an M20 Picaxe, vs when running at standard 4 MHz?
Playing around with "enabletime", "disabletime" and various scope trigger scenarios yields no clear answer.

The TIME variable is very useful, but very poorly documented. Personally, I believe it warrants its own heading in the manual(s).

Thanks,
Rip
 

geoff07

Senior Member
It isn't clear which chip you refer to, and they may behave differently. time is not listed as a special function on the 20M, though it is on the 20M2.

It would be simple enough to do a test to satisfy yourself:
Code:
oldtime = time
do
   if time > oldtime then
      toggle ledpin 
      oldtime = time
   endif
loop
This should flash an led on and then off at the interval of one time unit (not tested so may need some work)

You may find that the first time interval varies as setting time=0 does not reset the internal timer, though subsequent intervals should be correct. That is why I don't use the first interval.
 

rq3

Senior Member
It isn't clear which chip you refer to, and they may behave differently. time is not listed as a special function on the 20M, though it is on the 20M2.
My apologies for the typo. It's a 20M2. I've tried testing as you've suggested, but we're really into the realm of counting "one chimpanzee, two chimpanzee...". From what I can tell, at 32 MHz, the "time" function runs just twice as fast as at "standard" 4MHz for this particular device. To get a 5 second loop, I need to specify a 'loop until time>10' command. Close enough. The lack of documentation is frustrating, though, especially since this seems to go against the normal "double the clock, half the time" of other commands.
 

AllyCat

Senior Member
Hi,

Yes, I believe TIME is correct at 4 MHz and 16 Mhz and runs "twice as fast" on the 8 and 32 MHz settings. It shouldn't be difficult to check on a "real" chip, just write a little loop such as :
Code:
setfreq m8
#terminal 4800
do
  if time <> b0 then
    sertxd("tick ")
    b0 = time
  endif
loop
Cheers, Alan.
 

inglewoodpete

Senior Member
Hi,

Yes, I believe TIME is correct at 4 MHz and 16 Mhz and runs "twice as fast" on the 8 and 32 MHz settings. It shouldn't be difficult to check on a "real" chip, just write a little loop such as :
Code:
setfreq m8
#terminal 4800
do
  if time <> b0 then
    sertxd("tick ")
    b0 = time
  endif
loop
Cheers, Alan.
Correct. The M2-series chips 'tick' at 500mS intervals when the chip is running at 32MHz.
 

BESQUEUT

Senior Member
Hi,

Yes, I believe TIME is correct at 4 MHz and 16 Mhz and runs "twice as fast" on the 8 and 32 MHz settings. It shouldn't be difficult to check on a "real" chip, just write a little loop such as :
Code:
setfreq m8
#terminal 4800
do
  if time <> b0 then
    sertxd("tick ")
    b0 = time
  endif
loop
Cheers, Alan.
OK : this is a test code...
but be carefull : Time is a word variable. You can only use the "<>" or "=" tests.
With "<" or ">" tests result may be surprising...
 

AllyCat

Senior Member
Hi,

You can only use the "<>" or "=" tests.
With "<" or ">" tests result may be surprising...
Indeed, there are several "gotchas" with the time variable (at least with very short periods, or for over 18 hours). But sometimes < or > are "safer" than = . For example:
Code:
do
;   some other (slow) code
    if time > 59 then          ; is generally safer than = 60
       sertxd("another minute gone",cr,lf)
       time = 0
    endif
loop
I see that at 8 MHz, time actually runs "slow"; and some might argue with 2 MHz being included under the heading "... increased clock speed". :)

Cheers, Alan.
 
Last edited:

BESQUEUT

Senior Member
Code:
do
;   some other (slow) code
    if time > 59 then          ; is generally safer than = 60
       sertxd("another minute gone",cr,lf)
       [COLOR="#FF0000"]time = 0[/COLOR]
    endif
loop
Reseting Time to zero is NOT a good idea...
because you absolutely don't know when this will be done. And surely, it will not be done at an integer second, but few ms later...
So, each mn your watch go slower and slower...

Using a memory to test changed Time is far better :
Code:
do
  if time <> b0 then
    sertxd("tick ")
    b0 = time
  endif
loop
But : suppose you want to do something each 10 s :
Code:
b0 = time +10
do
  if time = b0 then
    sertxd("tick ")
    b0 = time +10
  endif
loop
Will work... or not...
Suppose Time is 255, then bo will be ... 9
and you have to wait 65535 s to get a "tick"...

Maybe, you can do something like :
Code:
w0 = time +10
do
  if time = w0 then
    sertxd("tick ")
    w0 = time +10
    if time>60000 then
        time=time-60000
        wo=wo-60000
    endif
  endif

loop
 
Last edited:

rq3

Senior Member
Indeed, there are several "gotchas" with the time variable (at least with very short periods, or for over 18 hours).
The "TIME" variable is certainly easy to use, and very useful for gross timing of things like whether or not a button has been pressed within a rough period of time, I still think it needs its own discussion in the manual.

It's a pretty unique variable, and the manuals discuss "enabletime" and "disabletime", neither of which is generally needed. So the user is left with the assumption he will stumble across these un-needed commands, when what he is after is a direct discussion of the "time" variable itself, with all its quirks and foibles.

In short, if "time" is a usable Picaxe BASIC command, it warrants its own listing in the manual. There is no such thing as too much information, IMHO.

Thanks all for valuable thoughts and input!

Rip
 

AllyCat

Senior Member
Hi,

Reseting Time to zero is NOT a good idea...
because you absolutely don't know when this will be done. And surely, it will not be done at an integer second, but few ms later...
So, each mn your watch go slower and slower...
One of the "gotchas" is that resetting time does NOT reset the prescaler, so time will not "slip". But, it's not an "accurate" clock anyway, calibfreq is only good to about 0.1% and some of the "blocking" commands can cause a major loss of time.

time is basically just another variable, IMHO it's perfectly valid to assign a new value, which can be an easy way to overcome the "rollover" issue and avoids using any more of PICaxe's valuable variable registers. But if the "other" code were really slow, then time = time - 60 might be preferable in my last example above.

@rq3: Yes, more documentation is always potentially helpful, but how many users are put off by the size of the manuals already? Also, one of the issues is that the body of Manual 2 is an alphabetical list of all the commands, and time is not a command but a variable. Personally, I would like to see a complete alphabetical "index", similar to the "Reserved Words" section (but combining Appendices 1, 2 and 3), with (hot) links to sections that explain the use of each corresponding "Word".

Cheers, Alan.
 

rq3

Senior Member
@rq3: Yes, more documentation is always potentially helpful, but how many users are put off by the size of the manuals already? Also, one of the issues is that the body of Manual 2 is an alphabetical list of all the commands, and time is not a command but a variable. Personally, I would like to see a complete alphabetical "index", similar to the "Reserved Words" section (but combining Appedices 1, 2 and 3), with (hot) links to sections that explain the use of the relevant "Word".

Cheers, Alan.
Alan, I agree, yet the time variable is a unique animal, used as if it were a command AND a variable simultaneously. I can think of no other PICAXE variable (or command) that is treated this way. I truly like your solution; there should indeed be a searchable list of all possible "things" that can be typed into the editor that will have an effect upon the chip, INCLUDING the special function registers. Who knows, perhaps Picaxe chip sales would increase exponentially as I probe SFR's? :)

Rip
 

AllyCat

Senior Member
Hi,

I'm not sure that "time" is particularly unique, but I do see that some "special" variables have been sneaked into the command list under the guise of "Let" (e.g. Let pins = ...). But would you look under "L" to find out about time ?

IMHO, the "command" list has got unmanageably large. I often view the .PDF version via "bookmarks" on a small tablet and am often frustrated when the command proves to be "irrelevant" when I get to the full description. I suspect that many users are only interested in a subset of perhaps 30% of all the commands (at any particular stage of their project or abilities). The subdivision would not even be particularly contentious, because the descriptions often use phrases such as "for younger students", "deprecated", "pseudo command", etc..

Therefore, I would propose about 6 subsections with classifications such as: "For novices", "Obsolete/Historical", "Core Commands" (M2), "Extended Commands" (X2 family), "Special Variables" (Let....) and "Pseudo Commands" (created by the PE). Only the last of these might cause some consternation, because there are a surprisingly large number of them!

But "Technical Writing" is not a popular occupation and can too easily become a full-time job. :(

Cheers, Alan.
 

inglewoodpete

Senior Member
One of the "gotchas" is that resetting time does NOT reset the prescaler, so time will not "slip". But, it's not an "accurate" clock anyway, calibfreq is only good to about 0.1% and some of the "blocking" commands can cause a major loss of time.
To add to Alan's information above the system Time variable, within its chip's constraints, can be surprisingly accurate.

I am using an 08M2 chip to control the lighting of an exterior wall of a 4-storey building. Via an LDR and daylight, I am using the Time variable to control a 24-hour timer. The clock is reset at dusk each day by monitoring light levels. I logged the data for several weeks. I have taken care to ensure that there are no blocking commands in the code.

The Timer variable is reset to 0 every 5 seconds (10 ticks @ 32MHz) - my most frequent task is performed every 5 seconds. A second counter counts to 12 (Ie. 1 minute), while the third (word) counter counts to 1440 minutes or one day.

To date the 08M's timer has been accurate to within +/- 4 minutes per day or less than +/- 0.3%
 
Last edited:

bpowell

Senior Member
I love the TIME variable...I use it to jump out of a clock-setting routine if there is no input in 2 minutes...I assume the SET button was hit by mistake, or the user walked away...so if time > 120, the SET-TIME subroutine is ended and the clock returns to normal operation....works a treat!
 

lbenson

Senior Member
And for multiple events which need to happen at intervals of a different number of seconds, you can let the time variable run for, say, twelve hours (60*60*12=43,200) and use modulo calculations to determine when to execute a certain routine:
Code:
remainder = time // 60
if remainder = 0 then gosub everyMinute
interval = time // 3600
if remainder = 0 then gosub everyHour
interval = time // 4
if remainder = 0 then gosub every4Seconds
if time => 43200 then : time = 0 : endif ' reset every 12 hours
(Note that you would need to set flags to make sure you didn't execute subroutines multiple times per interval.)
 

matchbox

Senior Member
I wrote up this quick reference for a friend sometime ago, who was new to picaxe's.
Code:
Setfreq command (Time changes) on M2 parts  (m8 m16 m32 internal resonator) 4MHZ default


 Time = 1:1   @ 4MHZ and 16MHZ    -  1000mS = 1000mS(1sec)
 Time = 0.5:1 @ 8MHZ              -   500mS = 1000mS  required value /2
 Time = 1:0.5 @ 32MHZ             -  2000mS = 1000mS  required value x2
 

rq3

Senior Member
I wrote up this quick reference for a friend sometime ago, who was new to picaxe's.
Code:
Setfreq command (Time changes) on M2 parts  (m8 m16 m32 internal resonator) 4MHZ default


 Time = 1:1   @ 4MHZ and 16MHZ    -  1000mS = 1000mS(1sec)
 Time = 0.5:1 @ 8MHZ              -   500mS = 1000mS  required value /2
 Time = 1:0.5 @ 32MHZ             -  2000mS = 1000mS  required value x2
Neat, but at this point all are agreed that the "time" variable is gross enough that figuring out its relation to the chip clock is pretty trivial. The remaining issue is that the manual mentions "disabletime", and "enabletime", but not "time", which is bloody aggravating. Does this require a 30 man-year effort to update the manual?

Rip
 
Top