Be careful with DS18B20 and background serial receive

[Peter Fender]

I spent a few days banging my head on this problem until I finally figured it out.

I have a 28X2 with a DS18B20 temperature sensor that displays the temp on a 20x2 LCD display.
It also sends the temp via hserout to an XBee module and then to my PC.

I configured hsersetup for automatic background receive to the scratchpad, and periodically show the serial text received from the PC (via the XBee's) on the LCD display.

It mostly works, but occasionally garbled characters came in on the serial port.
I chased a few dead ends, mostly looking at the electrical interface between the PICAXE and the XBee (the 28X2 and LCD run at +5v, and the XBee needs 3.3v). This is the first time I've used XBee's, and I'm using this setup to learn how they work and how to convert the signal levels.

Turns out when the readtemp12 command executes, it temporarily changes the clock speed from the 28X2 default of 8MHz down to 4MHz.
So any characters received in the background during this command are decoded at the wrong baud rate.
I had to change the clock speed to 4MHz all the time to get the serial data to always be received correctly.


Does anyone know of a better way to work around this that can run the 28X2 at 8MHz or more?
(I'd like to speed up the display speed on the LCD eventually.)

I may try to connect the DS18B20 to a 08M2, trigger a reading with one pin from the 28X2, and read back the temp with a simple serin command on another pin.

 

[srnet]

Turns out when the readtemp12 command executes, it temporarily changes the clock speed from the 28X2 default of 8MHz down to 4MHz.

You appear to be correct, Manual 2 page 185;

Effect of increased clock speed:
This command only functions at 4MHz. M2, X1 and X2 parts automatically use
the internal 4MHz resonator for this command.

 

[MartinM57]

Have a look at owout/owin in Manual 2 - including code to roll-your-own READTEMP command. No mention of clock speed dependencies. You can replace the PAUSE 750 with some reasonably clever timer interrupt code to trigger the owin rather than PAUSEing you main program for 0.75 seconds.

 

[westaust55]

Have a look at owout/owin in Manual 2 - including code to roll-your-own READTEMP command. No mention of clock speed dependencies. You can replace the PAUSE 750 with some reasonably clever timer interrupt code to trigger the owin rather than PAUSEing you main program for 0.75 seconds.

The 1-Wire protocol is very time dependant.
While not mentioned in the manual 2 under the general 1-Wire commands, I believe that the PICAXE will drop to 4 MHz for the duration of the 1-Wire command just as for the READTEMP commands.

 

[MartinM57]

Might still be worth investigating - I'd guess that it is the inbuilt 750ms delay at 4Mhz in readtemp that is messing the background receive. Even with 4Mhz owin/owout commands, having the delay under your own control might work?

 

[g6ejd]

I would:

a. Run everthing at 4MHz as you've now done.
b. Use an external UART or another PICAXE configured to send/receive data for you with a Rx stack/buffer, so that you can take your time displaying the data when the Readtemp command has finished, safe in the knowledge that the external device has correctly Rx and stored the data. For TX, it would work out better too, as you could programme a Tx buffer, so that data can be queued for TX until complete, leaving the 28X2 to do all it needs. Inter-device comms can be via serial, but only when a Readtemp command had finished. Other thoughts are to only send data from the Picaxe on even minutes and send from the PC on odd minutes (time-slots) - the joys of near-real time programming...

Observation, as nothing your doing appears to be time critical and your only updating an LCD, isn't the 4MHz speed more than adequate?