readtemp disables (delays) "time" count on M2s

lbenson

Senior Member
Perhaps this has been noted before, but I missed it. I've been scratching my head as to why the "time" count that I've been using in a program for rough timing is so far off. As it turns out, the counting of "time" is disabled during a READTEMP command (up to 750ms), so if you are doing READTEMP in a tight loop, the time spent in READTEMP far exceeds the remainder of the loop time during which the counter for "time" is incremented. This program illustrates the point.
Code:
#picaxe 08M2
#no_data

main:
  do
    if time <> w12 then
      sertxd(#time," ")
      w12 = time
    endif
    readtemp b.1,b1
  loop
If the READTEMP line is commented out, the SERTXD command give a pretty good 1,2,3, etc. count of seconds. With READTEMP in, over 30 seconds elapse between the printing of "1" and "2", and other counts.

In my real program, there is no good reason to read the temperature with every loop iteration.
 

hippy

Technical Support
Staff member
The internal ticks which drive the 'time' counter can get missed and dropped whenever the PICAXE is busy doing something else which is why there's a tendency for 'time' to run slow. This is particularly noticeable with READTEMP.

Given that READTEMP has an approximate time of 750ms, it is possible to count the number of executions and give an "INC Time" kick every now and again to keep long term elapsed time more accurate.

Code:
Do
  SerTxd( #time, " " )
  ReadTemp ...
  w1 = w1 + 750
  If w1 >= 1000 Then
    w1 = w1 - 1000
    Inc time
  End If
Loop
 

PhilHornby

Senior Member
I did some investigations into READTEMP a while ago, and found that it doesn't pause 750mS and then issue a 'read' command; it polls the DS18B20 in a fairly tight loop until it responds.

Also, I had one program with TIME issues that I tracked down to the SERTXD command. It was quickly solved, using inverted HSEROUTs (same pin, same data format on M2).
 

westaust55

Moderator
I did some investigations into READTEMP a while ago, and found that it doesn't pause 750mS and then issue a 'read' command; it polls the DS18B20 in a fairly tight loop until it responds.
Yes it has been known for at least 6 years that the M2 and X2 parts continuously poll the DS18B20 to ascertain when the temp data is ready. Only the older parts waited for 750 ms.
See post 17:http://www.picaxeforum.co.uk/showthread.php?17853/page2

The only way to perform some other tasks during the period while waiting is to use an X1 or X2 part and the 1-wire commands then you can poll within your code and perform other tasks while waiting for temp data.
The time until data is available is dependent upon the resolution that the Ds18B20 is set for and can vary from around 100 ms up to 750 ms.
 
Top