Time variable on goslow?

I'm getting back into PicAxe programming having been away from it for over a year (so having to relearn much stuff again).

Working now on a throttle controller for our boat, I want to occasionally (every two or three seconds) send a variable representing the percentage of maximum throttle setting via SEROUT to an RF transmitter (NKM2401) without slowing down the main program loop to ensure that a change in the joystick position, which controls the motor speed, is rapidly monitored and passed through to the DAC to control the motor speed.

I found some very useful code which will undoubtedly do what I want in an existing thread from 2015 ('Time' Command question) but in experimenting with the 'time' variable myself, I found a strange anomaly which it would be nice to have an explanation for please?

Using the simple code below, everything works as I would expect, monitoring the time variable itself and the other variables, 'time' increments once a second. But if I comment out the PULSOUT line, 'time' only increments once every 5.5 seconds approximately.

Why?

Thanks, Charles Lyne

Code:
	; 
	#picaxe 20M2
	; 
init:
	symbol time_ex2 = w2    	; word variable for monitoring the time
	symbol time_ex3 = w3    	; word variable for monitoring the time
	symbol Stp_LED    = B.6 ; Use a logical name for the o/p pin.
	setfreq m4
	;
main:
	debug
	time_ex2 = time   		; allow the time to be seen by the debugger
	LET time_ex3 = time_ex2 / 5   ; 
	PULSOUT Stp_LED,500 : PAUSE 1000
	GOTO main
end
 

hippy

Technical Support
Staff member
If you saw my earlier answer you may have noticed I misread your question ! Here's the actual answer -

With the PULSOUT you have a PAUSE 1000, and that means the program is spending most of its time in the PAUSE command. The 'time' is running a little slower than real life and that's because it's missing some ticks while it is dedicating itself to handling DEBUG and PULSOUT. Most of the time it's in the PAUSE 1000 and seeing ticks there.

When you comment out the PULSOUT you are probably also commenting out the PAUSE. As a result the program is spending most of its time in the DEBUG where it is missing more ticks than it sees in the rest of the program.

If you add a PAUSE in before the 'GOTO main' it will get back closer to incrementing at the one second rate.
 
Hi hippy, thanks for your quick reply but I don't think it does answer my query.

If the code is simplified even more, to :

Code:
	; 
	#picaxe 20M2
	; 
init:
	symbol time_ex2 = w2    	; word variable for monitoring the time
	setfreq m4
	;
main:
	debug
	time_ex2 = time   		; allow the time to be seen by the debugger
	GOTO main
end
the problem is very evident in the debug window on my PC.

Both symbol "time_ex2" and "time" in the system variables pane, increment only every 5.5 seconds.

Putting the PULSOUT line back in, irrespective of how long the PAUSE command is (250 for instance, doesn't change anything), does get "time" working properly.
 
Last edited:

hippy

Technical Support
Staff member
Without PULSOUT but adding a PAUSE works for me when I test it. The longer the PAUSE the closer 'time' will be to real time.

PAUSE 250 has 'time' increment 10 in around 14 seconds, PAUSE 500 incrementing 10 in 12 seconds, PAUSE 1000 incrementing 10 in 11 seconds.
 

hippy

Technical Support
Staff member
Yes but why should "time" run 5½ times slower than normal if there's no PAUSE command at all?
That's back to post #2. During DEBUG ticks for the timer are not counted, and that's where your program is spending most of its time.

Imagine you have a friend shouting "tick" and you are both counting those. If you stick your fingers in you ears for a while ( the DEBUG ) only pull them out briefly ( the rest of the program ) your count will lag behind how many ticks there were.

If this were simulating accurately what the PICAXE is doing you'd be counting one fifth of actual ticks, your count would be five times slower than it should be.

It's all about the ratio of hearing ticks against not hearing ticks.
 

hippy

Technical Support
Staff member
Code:
Ticks    _|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_
            ___________________     ___________________
Debug    --|___________________|---|___________________|--
         __                     ___                     __
Rest     __|-------------------|___|-------------------|__

Counted  _|_____________________|_|_____________________|_
Code:
Ticks    _|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_
            ___________________                         __
Debug    --|___________________|-----------------------|__
                                ___                    
Rest     ----------------------|___|----------------------
         __                         ___________________
Pause    __|-----------------------|___________________|--

Counted  _|_____________________|_|_|_|_|_|_|_|_|_|_|_|___
 
Many thanks hippy, have got all the basic controller working very nicely now and am pleased with the results so far. A bit more hardware (and software) to do before testing in the boat but confident it should work as expected.
 

hippy

Technical Support
Staff member
Excellent news. In most programs 'time' will keep reasonably good time, it's just that your tight test program highlighted one of the gotchas with the PICAXE's ability to keep time.
 

inglewoodpete

Senior Member
IIRC, the debug command takes around 35mS to download the register data from the PICAXE. Unsuited to time-critical applications.
 

bpowell

Senior Member
IIRC, the debug command takes around 35mS to download the register data from the PICAXE. Unsuited to time-critical applications.
But, it's just outputting serial data, right? That shouldn't get in the way of a timer interrupt. I don't see why Debug causes the timer to stop (or the PICAXE to stop *noticing* the timer) unless interrupts are disabled during Debug.
 

inglewoodpete

Senior Member
But, it's just outputting serial data, right? That shouldn't get in the way of a timer interrupt. I don't see why Debug causes the timer to stop (or the PICAXE to stop *noticing* the timer) unless interrupts are disabled during Debug.
I'm pretty sure that the debug output is bit-banged, so all internal interrupts are disabled for the duration.
 

hippy

Technical Support
Staff member
Yes, DEBUG is bit-banged serial and there is a fair amount of data which gets sent in a DEBUG packet.

The firmware ignores the timing ticks while it is concentrating on getting the serial bit timing right so not all ticks get seen, the timing counter will be ticked along less frequently and 'time' will increment slower than it otherwise would.

DEBUG use does not usually account for an excessive amount of time when used in most programs but it will be where a program will be spending most of its time if used in a tight program loop.

Even then it won't usually have much of an adverse effect on a program. Except when also using 'time'.
 

bpowell

Senior Member
Thanks for the replies Hippy and Inglewoodpete.

I have to say, I haven't played with debug much...but when I have, it was VERY useful! I'm also big on slapping LEDs around and using them as milestone indicators ... I then remove them once the project is working as expected. It's helpful to see where a program gets hung up.

All good stuff!
 

hippy

Technical Support
Staff member
I find DEBUG most useful when one wants a snapshot of everything - which is of course what it's designed to provide - but tend towards SERTXD and outputting specific variables with that.

The main advantage with SERTXD is that it can include text information, so one can more easily see how something is and where it is that, for example how 'w0' is set on entry to a subroutine and on exit.
 

inglewoodpete

Senior Member
I find DEBUG most useful when one wants a snapshot of everything - which is of course what it's designed to provide - but tend towards SERTXD and outputting specific variables with that.
I'm also big on slapping LEDs around and using them as milestone indicators ... I then remove them once the project is working as expected. It's helpful to see where a program gets hung up.
I use both of the methods above. SerTxd, also bit-banged, is handy for occasionally logging register contents. To minimise the impact of logging during time-critical periods, I use SerTxd with single characters like '@', '|', '^' or '*' to indicate where execution is (or is not!) occurring. These characters are not likely to get confused with register contents or most text.

For X2 chips running at their default speed (8MHz), a single character only takes around 1mS to be sent. However, you need to be aware that any bit-banged logging risks losing time-critical system interrupts like background serial reception or running as an i2c slave.
 
Top