How to read the 08M2 timer register for the "time" command

Flenser

Senior Member
How do I read the 08M2 timer register for the "time" command?

I was hoping to read the 08M2 PIC timer registers that are used for the "time" command, as described in this post by AlleyCat:
http://www.picaxeforum.co.uk/showthread.php?17782-PICAXE-program-Size-Optimisations-and-Speed&p=215463&viewfull=1#post215463

But when I do peeksfr for the TMR1H register at address $17 I get the constant value 182.
PE is reporting firmware PICAXE-08M2 v4.A

Can anyone point out what I'm missing?

This code:
Code:
#no_data

b0=$17

do
	peeksfr b0, b1
	sertxd(#b0,9,#b1,13,10)
loop
end
produces this output that does not increment:
Code:
23    182
23    182
23    182
23    182
23    182
23    182
23    182
23    182
 
Last edited:

eggdweather

Senior Member
I understand peeking at system variables is not allowed, stops folks copying the ROM, etc. You have the time variable so achieves what you want to do anyway.
 

hippy

Technical Support
Staff member
The only thing the PICAXE really strives to prevent is reading the firmware itself.

The firmware allows access to many of of the system SFR locations but usability and behaviour of those locations is not guaranteed. When accessing SFR locations the firmware uses all manner of strange and unexpected things can happen, and things can behave differently depending on PICAXE type.

My guess is the firmware is reading the timer and resetting it and the value you are reading is what it would be after such a reset and at the time the SFR is read. The timer only drives the 'time' accumulation and is not the 'time' variable itself.
 

bpowell

Senior Member
Remember, the timer is being reset / preloaded every 20ms or so...depending on delays in your program, you may not "catch" it doing anything.

Try this:

Code:
PeekSFR $17, b1
PeekSFR $17, b2
PeekSFR $17, b3
sertxd (#b1," ",#b2," ",#b3,13,10)
It is odd how now matter what changes you make to the delays, you will get a different number...but that number will then not change...I wonder if Timer1 is somehow used to synchronize the program execution?
 
Last edited:

Flenser

Senior Member
bpowell,

Thanks for your suggestion. This has solved it for me.

peeksfr $17, b1 - b16 in a loop gives:
183 185 187 190 192 194 197 199 201 203 206 208 210 213 215 217
183 185 187 190 192 194 197 199 201 203 206 208 210 213 215 217
183 185 187 190 192 194 197 199 201 203 206 208 210 213 215 217

peeksfr $17, b1 - b27 in a loop gives:
183 185 187 189 192 194 196 199 201 203 206 208 210 213 215 217 219 222 224 226 229 231 233 236 238 240 243 245
183 185 187 189 192 194 196 199 201 203 206 208 210 213 215 217 219 222 224 226 229 231 233 236 238 240 243 245
183 185 187 189 192 194 196 199 201 203 206 208 210 213 215 217 219 222 224 226 229 231 233 236 238 240 243 245

and "peeksfr $17, b1 - b27: peeksfr $17, b1 - b27" in a loop shows the TMR1H value being preloaded to a value near 178.
247 250 252 254 178 181 183 185 188 190 192 194 197 199 201 204 206 208 211 213 215 218 220 222 224 227 229 231
247 250 252 254 178 181 183 185 188 190 192 194 197 199 201 204 206 208 211 213 215 218 220 222 224 227 229 231
247 250 252 254 178 181 183 185 188 190 192 194 197 199 201 204 206 208 211 213 215 218 220 222 224 227 229 231

while TMR1L is wrapping around to 0:
peeksfr $16, b1 - b27
174 7 64 153 210 17 74 163 220 53 110 199 0 89 146 235 36 125 182 15 72 161 218 51 108 197 254
174 7 64 153 210 17 74 163 220 53 110 199 0 89 146 235 36 125 182 15 72 161 218 51 108 197 254
174 7 64 153 210 17 74 163 220 53 110 199 0 89 146 235 36 125 182 15 72 161 218 51 108 197 254
 

hippy

Technical Support
Staff member
What is probably happening is the timer is reset to 'zero minus N' so every N increments the timer overflows. When an overflow is detected the timer is again reset to 'zero minus N' and an internal tick counter increments. Every 'T' increments of the tick counter it overflows, resets to zero and 'time' is incremented.

The time taken for SERTXD is long enough that the timer will have overflowed during its execution so it will always be reset after SERTXD executes. The number of instructions and the time taken until your first PEEKSFR from that SERTXD induced reset is constant, and thus you always read the same value.

Add a command which takes a varying amount of time after the SERTXD or before PEEKSFR and the value read at the PEEKSFR will vary, for example -

b10 = b10+1 : Sound C.4, (b10,b10)

Note that in AlleyCat's timing code the timer is reset to zero rather than "zero minus N" so the timer has 65536 increments before it overflows rather than just N.
 

Flenser

Senior Member
Hippy,

I am seeing exactly what you describe.
When an overflow is detected the timer is again reset to 'zero minus N'
Using the approach suggested by bpowell, a sequence of several peeksfr's into different variables before doing a sertxd:
- It looks like I can sample the TMR1H register with a resolution of 2 -3. i.e. the TMR1L register is counting up to 256 and incrementing TMR1H about 2 - 3 times between each of my calls to peeksfr $17
- My reads return values that count up to 254 and then restart the count at about 177. i.e. it appears that the TMR1H register is being reset to 177 like you describe. This is what I see:
Code:
244 246 249 251 253 177 180 182 184 187 189 191 194 196 198 200 203 205 207 209 212 214 216 219 221 223 226
another thing you said prompted me to think of another test:
When accessing SFR locations the firmware uses all manner of strange and unexpected things can happen
It appears that the execution of the sertxd command is synchronized to the operation of TMR1. So my first peeksfr after calling sertxd is always at the same time relative to the TMR1H register getting it's normal reset and this means I always get the same value back from the TMR1H register. In hindisight, this behaviour of sertxd is not unreasonable as sertxd is software serial.

Using hserout instead gives me the sort of result I expected, peeksfr $17 returns different values. I'm sampling a fast moving timer register and the time it takes to send b1 out over hserout means that there is a big gap between each value I get back from each peeksfr.

This code:
Code:
hsersetup B9600_4, %10
b0=$17
do
	peeksfr b0, b1
	hserout 0,(#b0,9,#b1,13,10)
loop
Gives this output:
Code:
3	185
23	229
23	196
23	240
23	206
23	250
23	216
23	182
23	227
23	193
23	237
23	203
23	248
23	214
Thanks to you both for you help. I am now able to read the TMR1H:L registers. They are incremented too fast for me to use them for the idea I had, but I've answered that question which is what I was after.
 

hippy

Technical Support
Staff member
It appears that the execution of the sertxd command is synchronized to the operation of TMR1.
Not exactly but synchronisation does result due to the timer overflowing during SERTXD and then being reset after SERTXD.
 
Top