28x1 Internal Timer timing & READTEMP command

Hi, Can anyone explain a problem I am seeing with the 28x1 internal timer, set for 4Mhz operation and using the 1sec interval variable. This works fine until I include a "readtemp" or "readtemp12" command to read a DS18B20 temperature sensor.....the timer appears to slow down. I am using 4 sensors in my application and find that the impact on the timer gets worse the more "readtemp" commands I execute. See the following code:

symbol x = b1
symbol hwc_hi_temperature = w11
symbol hwc_hi_sensor_pin = 5
x= 44
hwc_hi_temperature=0
settimer t1s_4 'settimer to 1 second ticks at 4MHz

go_again:
high 7
pause 700
if timer > 60 then gosub fast_flash
low 7
readtemp hwc_hi_sensor_pin,hwc_hi_temperature
pause 400
goto go_again

fast_flash:
for x = 0 to 20
high 7
pause 100
low 7
pause 80
next x
timer = 0
return

I look forward to hearing from you

As I recall, READTEMP12 can take upto 750ms to execute, therefore the overall code slows down, until the READTEMP12 command has been processed.

You should take a look at manual 2 page 175. (under "function")

Personally, I haven't had any trouble and I make sure to pause for a minimum of 750ms. So, if I were you, I'd try changing from pause 400 to pause 750 (at least)...

Dave Carroll said:

Hi, Can anyone explain a problem I am seeing with the 28x1 internal timer, set for 4Mhz operation and using the 1sec interval variable. This works fine until I include a "readtemp" or "readtemp12" command to read a DS18B20 temperature sensor.....the timer appears to slow down. I am using 4 sensors in my application and find that the impact on the timer gets worse the more "readtemp" commands I execute. See the following code:
(code omitted)

Click to expand...

It should be possible to read all four DS18B20s within a second but you need to approach it with a different method.

Have a look at the command descriptions for OWIn and OWOut. There is some sample code that frees up the time that the DS18B20 needs to perform the temperature conversion.

I think others have issued several commands to start the conversion on several DS18B20s. Then, after a short delay, complete the request and read cycle on each temp sensor. You may even find some code for a multisensor system posted somewhere on the forum.

Problem is related to the timer count value

My software snippet shows the timer counting for 60 counts before running the fast flash routine, this should take 60sec (+/- 1sec for temp read and the pause), however the software shown takes about 1m30s ...... the counter Timer variable should reach 60 after 60sec and I should see that at 60 +/- 1sec or so, not 30s later. If I do 2 READTEMPs, the delay is approx 1m53s ...... in my view, the 1sec increment of the Timer variable is being affected by the REATEMP command???

I see the others are missing the point that TIMER is counting independently from the code speed of the loop so it should always trigger the flash subroutine within a second or so of one minute - not half a minute off. It's an independent timer - not a timing loop.

I'm far from a competent programmer - but shouldn't you zero the counter before you ever start your "go_again" routine?

Can you run the code in the emulator to see what happens?

Also - you provide no schematic of your hookup. Is the 28X1 actually reading the sensor? Perhaps it's spending all that time trying to read the sensor. I'd suggest you verify the functionality of the sensor reading before you work on the timing of other functions.

Thanks John, I think you have said it clearer than I had made it.

I do reset the timer initially and again after every time it reaches a count of 60 (in the fast_flash loop).

I understood, as you mentioned, that the timer proceeds to count time, irrespective of what the software was doing (except NAP and SLEEP which suspend all counters). I found this to be true with many of the commands that I have used, except the READTEMP and READTEMP12, which appear to suspend the timer while carrying out the transaction. It is possible that the READTEMP uses a form of SLEEP of NAP when waiting for the chip to respond with the temperature reading (750ms later), but I do not have access to the "micro code" that makes up the READTEMP commands.

(I understand that the SERVO commands also use that timer)

Thanks again to everyone for help on this, Dave.

Yes - the servo will take up the timer's time so you can't run them both together.

It sounds like you actually have more code running than you are showing us. Perhaps the problem is in there somewhere.

Hi John,
The code I am using is what you see in my first post. My larger application has much more code. When I could not put my finger on the problem, I rebuilt the code as shown in order to give me a tight loop.

My actual application ia part of a heating controller. It reads several sensors many times and displays the values on a LCD. However after every 3 hours (which is why I want the timer) I have my system doing a special routine, resets the timer and resumes temperature reading and displaying. The problem I have is that 3 hours is 3*60*60 seconds, but if I can't measure the second, then I have a problem (I know I could use an external timer, but why if the 28X1 can do the job?). This led me to stripping the code and using a simple LED to display the loops as the code goes through them. The code shown in my original posting behaves exactly as I have described it, with the timer "slowing" down.

And there in lies my problem....thanks again for the help, I know there is an explanation....dave

Do you have the temperature sensor attached and actually being read in your "stripped down" version? Sometimes stripping things down introduces as many problems as it removes. Those temperature sensors are a communications device with back and forth data transmission as I recall.

Hi John,
Yes temp sensor is in situ and fully operational. Only other device attached is the LED. Temp sensor is reading correctly. This has been confirmed using the DEBUG command, added after the READTEMP command. I removed the DEBUG when doing the timing measurement, as the interface to/from the PC slows down true operation speed of the chip.

Will send on the circuit diagram, but it is the same as the PICAXE manual 2, P155.

Besides, based on my understanding of the timer, if there was a delay when reading due to a bad, or incorrectly set-up sensor, I would only get fewer reads in the 60sec, the software loop would take longer. The actual timer clicks of the "timer" variable should not be affected.

Thanks again for sticking with me on this, Dave

It sounds like you've covered all the possibilities. I don't have any of those chips in stock to give a try from here, and my grasp of code quirks is slim. In short, my troubleshooting bag of tricks is used up. Perhaps someone else can do more. Good luck with it.

I'll continue to follow this thread with interest as there seems something distinctly odd afoot re the chip's internal counter and its reads that I don't understand.

Dave Carroll said:

the timer appears to slow down. I am using 4 sensors in my application and find that the impact on the timer gets worse the more "readtemp" commands I execute.

Click to expand...

The issue is described in Appendix 2 of PICAXE Manual 2. While executing each READTEMP there is a delay of around 750ms whilst the software waits for a response from the chip. During this time internal interrupts are disabled and the internal timer, which is driven by internal interrupts, won't see the time elapsing. It loses time against a real world clock.

The solution is, as suggested, to use OWOUT and OWIN commands.

OK. Finally got it. The internal timer is NOT a free running counter. Tnx, hippy.

That's right. There is an internal free-running hardware timer whose overflows generate interrupts which cause the software timer to increment. It's like manually moving the hands forward on a broken clock when someone shouts "tick"; when you pop off to do something else you won't hear those ticks so the clock won't get updated.

Hi Guys,
That sounds exactly like what I am seeing. I will remove the readtemp commands and change to one-wire as suggested.
Thanks to all for the help,
Keep up the great work,
Dave.

That was what was confusing me. I kept reading that the timer was free-running, but didn't catch the rest. Again, thanks. That info will save me from going through all that Dave has. I hate to learn things through the frustrations of others, but I'm glad I have the info nonetheless.