Time to redo the internal ReadTemp function. I will be tinkering with the old one to update the Dallas one-wire code for the ds18s20, ds18b20 and PAR (parasitic) devices. If anyone wants to add features, or test the example code, jump right in.
I will edit the header file while going thru the process.
O.K. here is an example using the DS18B20, I haven't tested the negative function in the freezer yet:
'=========ROM Commands for 1-Wire DS18S20 DS18B20======================================#define SearchRom 240 '0xF0IdentifySlaveRomcodes#defineReadRom51'0x33 Command for single slave#define MatchRom 85 '0x55Toidentifyaspecificslavecode#defineSkipRom204'0xCC Address all devices simultaneously#define AlarmSearch 236 '0xECSearchRomtoidentifyanyalarmflags'==========Function Commands for for 1-Wire DS18S20 DS18B20=============================#define ConvertT 68 '0x44SingleTempConversion#defineWriteScratch78'0x4E Write Scratchpad#define ReadScratch 190 '0xBEReadScratchpad#defineCopyScratch72'0x48 Copying Scratchpad TH and TL registers to EEPROM#define RecallE2 187 '0xB8RecallingalarmtriggervaluesfromEEPROMDimHighLowAsWordDimOWTempAsWordfunctionOWTempMasterRSTOWoutSkipRomOWoutConvertT#IfDEFPARasiticSetPullupOn#EndIfwait750ms'Need approx. 750 ms for 12 bit conversion#IfDEF PARasitic Set Pullup Off#EndIfMasterRSTOWout SkipRomOWout ReadScratchOwin#IfDEF ds18b20 'Assumesfactorydefault12bitresolutionHighLow=HighLow/16'Right shift temperature MSB into lower byte#EndifOWTemp = HighLowIf HighLow.8 1 Then 'TestforsignbitOWTempL=HighLow'Split word into bytes so byte size OWTempH = HighLow_H 'assembleroperationscanbeusedcomfOWTempL'Invert Low byte bits in the Register incf OWTempL 'AddOnetoLowbytetoturninto2's compliment comf OWTempH 'InvertHighbytebitsOWTemp=OWTempL'Reassemble bytes back into word OWTemp_H = OWTempHEnd ifend function'-----SUBS-----------------------------------------SubMasterRST'Master reset low for minimum 480 usDir DQ InDir DQ OutSet DQ Offwait 50 10usDir DQ In 'HiZthebuslineforreadingpresencepulsewait4810us'wait for presence pulse from one-wire device end subSub OWout (Command) #NRClocks = 0For Clocks = 1 to 8 Dir DQ Out Set DQ Off wait 3 us 'Needtoreleasebuswithin15usIfCommand.0OnthenDirDQInEndifwait60us'60 us per AN2420 Dir DQ In 'HiZthebusifstillpulledlowwait3usROTATECommandRight'The DS18s20 wants data LSB firstNextend subSub OWinHighLow = 0For bits = 1 to 16 Rotate HighLow Right 'TheonewiredevicesxmitdataLSBfirstDirDQOutSetDQOff'Start Read time slot wait 6 us Dir DQ In 'ReleasebusforonewireReceptionwait4usIfDQOnThenSetHighLow.151'Mustreadbuswithin15usslotIfDQOffThenSetHighLow.150wait50usNextendsub
Last edit: kent_twt4 2014-02-17
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, the existing function would be retained. The NewReadTemp is required till testing is complete; don't want to confuse myself or the compiler :). The new header saves several variables, and deletes an extra sub. More work required.
I thought I would use 9bit as default. We could have other resolutions with optional #defines.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
O.K. here is a revised header file with some #defines. Should be backward compatible with the DS18s20.
Will be working up an example on how to read the internal 8 byte of ROM (i.e. family code, 6 byte serial no., and CRC) from the ReadRom command. Getting the serial number allows a multidrop device scenario on a single data line.
2/18/14 Refactored waits in Read Time Slot because of sketchy first reads depending on OSC. Freezer tested for negative numbers.
'=========ROM Commands for 1-Wire DS18S20 DS18B20======================================#define SearchRom 240 '0xF0IdentifySlaveRomcodes#defineReadRom51'0x33 Command for single slave#define MatchRom 85 '0x55Toidentifyaspecificslavecode#defineSkipRom204'0xCC Address all devices simultaneously#define AlarmSearch 236 '0xECSearchRomtoidentifyanyalarmflags'==========Function Commands for for 1-Wire DS18S20 DS18B20=============================#define ConvertT 68 '0x44SingleTempConversion#defineWriteScratch78'0x4E Write Scratchpad#define ReadScratch 190 '0xBEReadScratchpad#defineCopyScratch72'0x48 Copying Scratchpad TH and TL registers to EEPROM#define RecallE2 187 '0xB8RecallingalarmtriggervaluesfromEEPROMDimHighLowAsWordDimOWTempAsWordfunctionOWTempMasterRSTOWoutSkipRomOWoutConvertT#IfDEFPARSetReadTemp_PullupOn#EndIf#IFNDEFPAR'start master read time slots until ds18x20 returns a "1"Do Until ConvertDone = True dir DQ out Set DQ Off wait 4 us Dir DQ In wait 7 us If DQ On Then ConvertDone = True Else ConvertDone = False End If wait 60 us 'minimum60ustimeslotsbetweenreadsLoop#ENDIF#IfDEFPARwait750ms'Need approx. 750 ms for full conversion Set ReadTemp_Pullup Off#EndIfMasterRSTOWout SkipRomOWout ReadScratchOwinIf HighLow.15 1 Then 'TestforsignbitCallNegNumberReadTemp_Neg=TrueElseReadTemp_Neg=FalseEndIf#IFDEFds18b20'Assumes factory default 12bit resolution #IFDEF ReadTemp_8Bits HighLow = HighLow / 16 'RightshifttemperatureMSBintolowerbyte#ENDIF#IFDEFReadTemp_9BitsHighLow=HighLow/8#ENDIF#IFDEFReadTemp_10BitsHighLow=HighLow/4#ENDIF#IFDEFReadTemp_11BitsHighLow=HighLow/2#ENDIF'#IFDEF ReadTemp_12Bits (DS18b20 default) leaves HighLow unchanged#ENDIF#IFNDEF ds18b20 #IFNDEF ReadTemp_9Bits HighLow = HighLow / 2 'RightshifttemperatureMSBintolowerbyte#ENDIF'IFDEF ReadTemp_9Bits (DS18s20 default) leaves HighLow unchanged#ENDIFOWTemp = HighLowend function'-----SUBS-----------------------------------------subNegNumberReadTemp_Neg=True#IFDEFPICcomfHighLow'Invert Low byte bits in the Register incf HighLow 'AddOnetoLowbytetoturninto2's compliment comf HighLow_H 'InvertHighbytebits#ENDIF#IFDEFAVRnegHighLow'Invert Low byte bits in the Register inc HighLow 'AddOnetoLowbytetoturninto2's compliment neg HighLow_H 'InvertHighbytebits#ENDIFendsubSubMasterRST'Master reset low for minimum 480 usDir DQ InDir DQ OutSet DQ Offwait 50 10usDir DQ In 'HiZthebuslineforreadingpresencepulsewait4810us'wait for presence pulse from one-wire device end subSub OWout (IN Command)Clocks = 0For Clocks = 1 to 8 Dir DQ Out Set DQ Off wait 3 us 'Needtoreleasebuswithin15usIfCommand.0OnthenDirDQInEndifwait60us'60 us per AN2420 Dir DQ In 'HiZthebusifstillpulledlowwait3usROTATECommandRight'The DS18s20 wants data LSB firstNextend subSub OWin (OUT HighLow as Word)HighLow = 0For bits = 1 to 16 Rotate HighLow Right 'TheonewiredevicesxmitdataLSBfirstDirDQOutSetDQOff'Start Read time slot wait 4 us Dir DQ In 'ReleasebusforonewireReceptionwait7usIfDQOnThenSetHighLow.151'Mustreadbuswithin15usslotIfDQOffThenSetHighLow.150wait50usNextendsub
Last edit: kent_twt4 2014-02-19
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Here is an example on how to read a bus powered single DS18b20 internal ROM code. Once individual ROM codes are learned, then a multi drop network can be effected on a single Data pin.
From my research of DS1820, DS18S20 and the DS18B20.
Device
Capability
DS1820
Temp returned as a fixed 9 Bit resolution
DS18S20
Temp returned as a 9 Bit resolution but 12 bit resolution can be calculated
DS18B20
Temp returned as 9 to 12 Bit resolution configured by designer
Will the new header support all three devices?
This is table of the capabilities per device.
See the attachment - gave up formatting the table!
Will we be able perform all the operations above in the new header? (I had to create this table as I could not find this consolidated information on the web....I am sure it exists somewhere!). Did I miss any capability?
The question always is how much functionality to bring to the table in a header, as opposed to showing the methods used to obtain a result? I am open to discussion.
Another question I have is; does the ReadTemp, and the much larger category of Dallas 1-Wire devices deserve a separate header file (say 1-Wire.h or OneWire.h?), as opposed to a System.h? (or wherever ReadTemp is currently stashed).
Supposedly the DS18S20 is meant to be a drop in replacement for the DS1820 per Maxim/Dallas DS18S20 DS18B20 comparison pdf. The exception being the increased resolution and the conversion time of the DS18S20 http://pdfserv.maximintegrated.com/en/an/AN4377.pdf I don't foresee any problems with the DS1820 device since the ReadTemp is polling the conversion time.
I have not planned to use the DS18S20 in the increased resolution mode. Bloated maths, and not matching the accuracy of +/- 0.5C of the device to it's resolution thing for me.
The Table looks good.
Setting and reading alarms is easy enough to incorporate.
I don't have any ready code for the SearchRom command. My thoughts are if you don't know what devices you have, or their location in the chain, you have got problems? Perhaps I could be persuaded though :).
Instead of doing software bit resolution for the DS18B20, we could make those as hardware EEProm R1, R0 bit configuration register settings. This would make for MUCH quicker ConvertT times for bus powered devices. Put a timer on ConvertT and get around 600+ ms 12 bit conversion, while a 9 bit conversion is "supposed" to be just under 100 ms.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Good point regarding header and method. Can we provide read temp for 9 bit and 12 bit, set / read alarm and read unique serial #/read unique device? The rest can be derived anyway from these. I think you are pretty close to this anyway.
I like the idea of a new OneWire.h as this will have non device specific methods and we should place all the DS18x20 methods in the old DS18S20.h file. So, to use you would need <onewire.h> and <ds18s20.h>
Re your list.
Agree re this point.
We should do a 12 bit – readtemp12 sounds like a good name for the method. I have some maths I can share.
I will update the table to show what is support and what people have to hand crank.
Good.
I think if you cracked the searchrom we would have something better than a few other compilers – please, please.
If it works – then any valid approach is good.
FYI: I just checked the current ds18s20.h it is your code dated Feb 12, 2007, Rev0.
:-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ughhh....Finally got the SearchRom code. Had to sneak a peek at the Dallas appnote 187 to get things going in the right direction. I was able to get three in a row on my own and then a total roadblock.
Anyway, how many devices should the header file be able to discover? 16 devices might fit in a smallish 4KByte flash, 256Byte Ram device, OR???
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No need for the NewReadTemp.h include. Perhaps the OWinRom routine would be of help though. I'm pretty sure I put up an example in the contributor section. The OWin bytes need to be printed out or saved to a buffer. Here's a recap:
cls
MasterRST 'start initialization process
OWout ReadRom
OWinRom
wait 2 s
goto Main
Sub OWinRom
For EightBytes = 1 to 8
For Clocks = 1 to 8
Rotate RxData Right 'The DS18s20 wants data LSB first
Dir DQ Out
Set DQ Off 'Read time slot
wait 4 us
Dir DQ In 'Release bus for one wire transmission
wait 7 us
If DQ On Then Set RxData.7 1
If DQ Off Then Set RxData.7 0
wait 50 us
Next
If EightBytes = 5 Then Locate 1,0
Print RxData: Print " "
wait 1 s
Next
end sub
Time to redo the internal ReadTemp function. I will be tinkering with the old one to update the Dallas one-wire code for the ds18s20, ds18b20 and PAR (parasitic) devices. If anyone wants to add features, or test the example code, jump right in.
I will edit the header file while going thru the process.
O.K. here is an example using the DS18B20, I haven't tested the negative function in the freezer yet:
Last edit: kent_twt4 2014-02-17
Header file named NewReadTemp:
Last edit: kent_twt4 2014-02-17
Can we retain the existing header file and add the new functionality to the existing file?
We should retain the existing function ReadTemp. You add a new function ReadTemp12 for the newer devices or add some parameters to control the method.
Cheers.
Yes, the existing function would be retained. The NewReadTemp is required till testing is complete; don't want to confuse myself or the compiler :). The new header saves several variables, and deletes an extra sub. More work required.
I thought I would use 9bit as default. We could have other resolutions with optional #defines.
O.K. here is a revised header file with some #defines. Should be backward compatible with the DS18s20.
Will be working up an example on how to read the internal 8 byte of ROM (i.e. family code, 6 byte serial no., and CRC) from the ReadRom command. Getting the serial number allows a multidrop device scenario on a single data line.
2/18/14 Refactored waits in Read Time Slot because of sketchy first reads depending on OSC. Freezer tested for negative numbers.
Last edit: kent_twt4 2014-02-19
HOW TO READ DSx1820 INTERNAL ROM CODE
Here is an example on how to read a bus powered single DS18b20 internal ROM code. Once individual ROM codes are learned, then a multi drop network can be effected on a single Data pin.
Cant wait to test at the weekend!
@kent_twt4: Questions.
From my research of DS1820, DS18S20 and the DS18B20.
Will the new header support all three devices?
This is table of the capabilities per device.
See the attachment - gave up formatting the table!
Will we be able perform all the operations above in the new header? (I had to create this table as I could not find this consolidated information on the web....I am sure it exists somewhere!). Did I miss any capability?
Last edit: Anobium 2014-02-19
The question always is how much functionality to bring to the table in a header, as opposed to showing the methods used to obtain a result? I am open to discussion.
Another question I have is; does the ReadTemp, and the much larger category of Dallas 1-Wire devices deserve a separate header file (say 1-Wire.h or OneWire.h?), as opposed to a System.h? (or wherever ReadTemp is currently stashed).
Supposedly the DS18S20 is meant to be a drop in replacement for the DS1820 per Maxim/Dallas DS18S20 DS18B20 comparison pdf. The exception being the increased resolution and the conversion time of the DS18S20 http://pdfserv.maximintegrated.com/en/an/AN4377.pdf I don't foresee any problems with the DS1820 device since the ReadTemp is polling the conversion time.
I have not planned to use the DS18S20 in the increased resolution mode. Bloated maths, and not matching the accuracy of +/- 0.5C of the device to it's resolution thing for me.
The Table looks good.
Setting and reading alarms is easy enough to incorporate.
I don't have any ready code for the SearchRom command. My thoughts are if you don't know what devices you have, or their location in the chain, you have got problems? Perhaps I could be persuaded though :).
Instead of doing software bit resolution for the DS18B20, we could make those as hardware EEProm R1, R0 bit configuration register settings. This would make for MUCH quicker ConvertT times for bus powered devices. Put a timer on ConvertT and get around 600+ ms 12 bit conversion, while a 9 bit conversion is "supposed" to be just under 100 ms.
Good point regarding header and method. Can we provide read temp for 9 bit and 12 bit, set / read alarm and read unique serial #/read unique device? The rest can be derived anyway from these. I think you are pretty close to this anyway.
I like the idea of a new OneWire.h as this will have non device specific methods and we should place all the DS18x20 methods in the old DS18S20.h file. So, to use you would need <onewire.h> and <ds18s20.h>
Re your list.
FYI: I just checked the current ds18s20.h it is your code dated Feb 12, 2007, Rev0.
:-)
Put up a Dallas 1-Wire temperature sensor network example in the Contributors section. The link: https://sourceforge.net/p/gcbasic/discussion/629990/thread/0d52cc35/#6609
Not much usable from the header file, so it is self contained so to speak. Also it uses the manual ROM discovery method as shown in previous post.
I really tried to use integer values, but having a heck of time with the syntax. I am not sure if a function can handle Integers?
Ughhh....Finally got the SearchRom code. Had to sneak a peek at the Dallas appnote 187 to get things going in the right direction. I was able to get three in a row on my own and then a total roadblock.
Anyway, how many devices should the header file be able to discover? 16 devices might fit in a smallish 4KByte flash, 256Byte Ram device, OR???
@kent. I have finally got to the DS18B20 testing.
Do I need the <NewReadtemp.h> file to make the READROM work correctly?
Anobium
Evan,
No need for the NewReadTemp.h include. Perhaps the OWinRom routine would be of help though. I'm pretty sure I put up an example in the contributor section. The OWin bytes need to be printed out or saved to a buffer. Here's a recap:
cls
MasterRST 'start initialization process
OWout ReadRom
OWinRom
wait 2 s
goto Main
Sub OWinRom
For EightBytes = 1 to 8
For Clocks = 1 to 8
Rotate RxData Right 'The DS18s20 wants data LSB first
Dir DQ Out
Set DQ Off 'Read time slot
wait 4 us
Dir DQ In 'Release bus for one wire transmission
wait 7 us
If DQ On Then Set RxData.7 1
If DQ Off Then Set RxData.7 0
wait 50 us
Next
If EightBytes = 5 Then Locate 1,0
Print RxData: Print " "
wait 1 s
Next
end sub
On Monday, August 11, 2014 8:30 AM, Anobium evanvennn@users.sf.net wrote:
@kent. I have finally got to the DS18B20 testing.
Do I need the <NewReadtemp.h> file to make the READROM work correctly?
Anobium
ReadTemp Header File Redo
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/gcbasic/discussion/579125/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/