Reading DS1620 (SPI Temperature) from 18F46k22 Micro at 16MHz

[JimAvanti]

In the past I built a device that read the temperature from two DS1620 (SPI) using an 18F4620 at 8MHz and it has been working good for years. Recently I had some boards made for this design, however I used an 18F46k22 running at 16MHz instead. I am using shiftin/shiftout commands to read the temp. The speed difference in micros seems to be affecting the temp reading. I tried adding DEFINE SHIFT_PAUSEUS 100 to the code. I also added a small pause between the reading of Temp1 and Temp2. I played around with different SHIFT_PAUSEUS (1000, 2000, & 3000). Nothing seems to help. I am not sure if the timing is the problem, however I am just guessing at the values I am trying. Does anyone know what setting I should be using on the 18F46k22 running at 16MHz to make it as close to a 18F4620 running at 8MHz? Or any other suggestions?
Thanks,
Jim

[Dave]

Jim, I have converted much of my code from old projects using the 18F4620 to 18F46K22's. I have a few questions. What are you doing with the RESET line to the part? Are you looking at the DONE bit for the conversion to complete? If I could see the section of code you are using for configuring the part and reading it I can probably help.

[JimAvanti]

Jim, I have converted much of my code from old projects using the 18F4620 to 18F46K22's. I have a few questions. What are you doing with the RESET line to the part? Are you looking at the DONE bit for the conversion to complete? If I could see the section of code you are using for configuring the part and reading it I can probably help.


'DS1620 Constants:
RdTmp CON $AA 'read temperature
WrHi CON $01 'write TH (high temp)
WrLo CON $02 'write TL (low temp)
RdHi CON $A1 'read TH
RdLo CON $A2 'read TL
RdCntr CON $A0 'read counter
RdSlope CON $A9 'read slope
StartC CON $EE 'start conversion
StopC CON $22 'stop conversion
WrCfg CON $0C 'write config register
RdCfg CON $AC 'read config register
THi CON 85 'high temp alarm
TLo CON 40 'low temp alarm

'DS1620 Variables:
tempIn VAR Word ' Raw temperature + Temporary conversion var
tsign VAR tempIn.BIT8 ' 1 = negative temperature
tC VAR Word ' Celsius Temp
tF VAR Word ' Fahrenheit Temp
tF2 VAR Word ' Fahrenheit Temp


HIGH TRS1 ' Initialize DS1620 Temp Sensors (Once at program start)
SHIFTOUT TDAT, TCLK, LSBFIRST, [WrCfg, %10] 'Use with CPU; free-run
LOW TRS1
PAUSE 10
HIGH TRS1
SHIFTOUT TDAT, TCLK, LSBFIRST, [StartC] 'Start conversions
LOW TRS1
HIGH TRS2 'Alert the DS1620 #2
SHIFTOUT TDAT, TCLK, LSBFIRST, [WrCfg, %10] 'Use with CPU; free-run
LOW TRS2
PAUSE 10
HIGH TRS2
SHIFTOUT TDAT, TCLK, LSBFIRST, [StartC] 'Start conversions
LOW TRS2



Read_DS1620:
HIGH TRS1 ' Alert the DS1620
Pause 5
SHIFTOUT TDAT, TCLK, LSBFIRST, [RdTmp] ' Command to read temp
SHIFTIN TDAT, TCLK, LSBPRE, [tempIn\9] ' Read it in as 9 bit word
LOW TRS1 ' Release the DS1620
tempIn.BYTE1 = -tsign ' Extend sign bit
tC = tempIn * 5 ' Convert to tenths
IF (tC.BIT15 = 0) THEN ' Temp C is positive
tF = tC */ $01CC + 320 ' Convert to F
ELSE ' Temp C is negative
tF = 320 - ((ABS tC) */ $01CC) ' Convert to F
ENDIF
Pause 10
HIGH TRS2 ' Alert the DS1620-2
Pause 5
SHIFTOUT TDAT, TCLK, LSBFIRST, [RdTmp] ' Command to read temp
SHIFTIN TDAT, TCLK, LSBPRE, [tempIn\9] ' Read it in as 9 bit word
LOW TRS2 ' Release the DS1620-2
tempIn.BYTE1 = -tsign ' Extend sign bit
tC = tempIn * 5 ' Convert to tenths
IF (tC.BIT15 = 0) THEN ' Temp C is positive
tF2 = tC */ $01CC + 320 ' Convert to F
ELSE ' Temp C is negative
tF2 = 320 - ((ABS tC) */ $01CC) ' Convert to F
ENDIF
RETURN

[Dave]

Jim, Looking at the data sheet, I would change the "SHIFTIN TDAT, TCLK, LSBPRE, [tempIn\9]" statement to "SHIFTIN TDAT, TCLK, LSBPOST, [tempIn\9]" According to the data sheet, the data is valid until the next rising edge of the clock. Also, it takes 750 Milliseconds for each new conversion to complete. I am assuming that your TRS1 and TRS2 port bits are connected to the respective NOT RESET lines on the DS1620's?

[JimAvanti]

Dave,
I will make that change to the Shiftin statement tonight and let you know if it helps. The TRS1 and TRS2 bits are connected to the respective NOT RESET lines on the DS1620s. This same code worked well on the slower Micro years ago. Maybe reading on the wrong edge didn't have enough of an affect on the slower clock speed, but made the difference at 16MHz. Hopefully that fixes the issue I am seeing. If not, it is always more fun when you have to figure things out.

Thanks,
Jim


Jim, Looking at the data sheet, I would change the "SHIFTIN TDAT, TCLK, LSBPRE, [tempIn\9]" statement to "SHIFTIN TDAT, TCLK, LSBPOST, [tempIn\9]" According to the data sheet, the data is valid until the next rising edge of the clock. Also, it takes 750 Milliseconds for each new conversion to complete. I am assuming that your TRS1 and TRS2 port bits are connected to the respective NOT RESET lines on the DS1620's?

[JimAvanti]

Dave,
I tried changing the LSBPRE to LSBPOST as you suggested, but it seemed to make things worse. I changed DEFINE SHIFT_PAUSEUS to 1 and it seemed to make things the closest to the 8MHz Micro as possible (Looking at the timing on a logic analyzer). I can get temp readings, but they are not always reliable. I should also note that the DS1620s are on the end of a cable about 15' from where the micro is. The temp readings seem to be a little low (reading 58F where it should be closer to 69F, however when I try LSBPOST the reading drops in the 40's (Must be dropping a bit or something). Maybe the 18F46k22 can't handle the cable length as the 18F4620 did so well for all these years.
I will keep it running for a while and monitor the results.

Thanks for your help
Jim



Jim, Looking at the data sheet, I would change the "SHIFTIN TDAT, TCLK, LSBPRE, [tempIn\9]" statement to "SHIFTIN TDAT, TCLK, LSBPOST, [tempIn\9]" According to the data sheet, the data is valid until the next rising edge of the clock. Also, it takes 750 Milliseconds for each new conversion to complete. I am assuming that your TRS1 and TRS2 port bits are connected to the respective NOT RESET lines on the DS1620's?

[Dave]

Jim, When you have the logic analyzer connected to the PIC pins, are you seeing consistent data between transfers meaning reading to reading? 15 feet is quite a ways for an un-buffered SPI bus. The DS1620 device shouldn't be changing temperature that drastically.

[JimAvanti]

Dave,
from one reading to the next, the data does look consistent, but the temp is off which seems weird. I have been logging the results and they are smooth changes in temp. I think it will be a bit easier to follow what is going on with the logic analyzer if I remove the fahrenheit conversion and compare the data read to the bits on the analyzer, but that will be for another day since I don't have the analyzer set up next to where the device is mounted. Maybe then I will be able to see if I am dropping a bit someplace. I may try a different type of Temp IC also (Maybe one that also does humidity)



Jim, When you have the logic analyzer connected to the PIC pins, are you seeing consistent data between transfers meaning reading to reading? 15 feet is quite a ways for an un-buffered SPI bus. The DS1620 device shouldn't be changing temperature that drastically.