- Sat Jun 04, 2016 11:32 pm
#48601
I'm pretty sure I know how it works based on experience with a different one-wire protocol. When devices are queried for their presence, ALL of them begin to respond bit by bit but watching the data line too. If two transmit a "1" at the same time, no harm done. If two send opposite bits, the "1" prevails and the one sending a "0" defers and stops sending, waiting for the packet to finish, ready to resend. After the prevailing response finishes, the "inferior" devices resend under the same rules until all have replied successfully. Maybe I have it backwards and the "0" prevails, but the idea is the same.
So what I think the temp command is doing is to begin with a device query and build the device lookup table (0-n cross referencing the ROM codes) first before then addressing the target device by its ROM code. I think this is a bad way to do it for two reasons: 1. As before, if a device is rendered inoperative, the software may not know, much less adjust. 2. The temp command/function would be faster if you could specify a ROM code and preclude the the initial device query altogether.
I propose that the temp function be modified to (optionally) accept a ROM code instead of a device number. I'd suggest that the ROM code be given as a string value and the device number would just be numeric. This way the function could distinguish between the two. In the instance of a ROM code being passed, the temp function would skip the device query and the lookup of device number to ROM code. The result is higher speed and a positive identification of the correct device. Since we are not adding arguments, the original temp command in Branch 2 could be modified too.
forlotto wrote:hrmmm yes interesting indeed how does the address get set 0-n I almost wonder if the rom code may not have something to do with it if not then I estimate it is set on which sensor responds to reset the quickest possibly?
I'm pretty sure I know how it works based on experience with a different one-wire protocol. When devices are queried for their presence, ALL of them begin to respond bit by bit but watching the data line too. If two transmit a "1" at the same time, no harm done. If two send opposite bits, the "1" prevails and the one sending a "0" defers and stops sending, waiting for the packet to finish, ready to resend. After the prevailing response finishes, the "inferior" devices resend under the same rules until all have replied successfully. Maybe I have it backwards and the "0" prevails, but the idea is the same.
So what I think the temp command is doing is to begin with a device query and build the device lookup table (0-n cross referencing the ROM codes) first before then addressing the target device by its ROM code. I think this is a bad way to do it for two reasons: 1. As before, if a device is rendered inoperative, the software may not know, much less adjust. 2. The temp command/function would be faster if you could specify a ROM code and preclude the the initial device query altogether.
I propose that the temp function be modified to (optionally) accept a ROM code instead of a device number. I'd suggest that the ROM code be given as a string value and the device number would just be numeric. This way the function could distinguish between the two. In the instance of a ROM code being passed, the temp function would skip the device query and the lookup of device number to ROM code. The result is higher speed and a positive identification of the correct device. Since we are not adding arguments, the original temp command in Branch 2 could be modified too.
