You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
I have searched the issue tracker for a similar issue and not found a similar issue.
General issue report
I'm using esp-idf 5.1.2 with ESP32-S3-DevkitC in a Windows/VS Code environment. I have 2 onewire devices (DS2408 and MAX31820) on my bus, which is just a breadboard. Using the Onewire example, it can detect either of the devices, but not both. Plugging the same "network" into a Linux SBC, both devices are detected, so I believe the wiring is correct. The ID of the DS2408 (470000003FB84629) supersedes the 31820 (0100000ED5745128), so only it is detected if both are attached.
Looking at onewire_device_iter_get_next() with the JTAG debugger, I can tell that search_direction is never 0 -- last_zero = rom_bit_index is never executed even though a discrepancy is detected. I think the issue is different device families. The problem may be that last_dispepancy is initialized as 0 and rom_bit_index is initialized as 0, so a discrepancy of the first bit will be detected as the 2nd occurrance of this discrepancy? A different implementation (esp32 bitbang onewire) initializes last_discrepancy as 64. The Analog Devices App Note initializes last discrepancy as 0, but the first bit is 1 and not 0.
The text was updated successfully, but these errors were encountered:
github-actionsbot
changed the title
OneWire Search not working for mixed devices
OneWire Search not working for mixed devices (IDFGH-11938)
Jan 19, 2024
@rpaulbeam Thanks for reporting! I don't have a MAX31820 before my hand, It would be very appreciated if you could submit a PR in this repo for the fix.
The MAX3180 is a compatible temperature sensor and it works just like the ds18b20. The problem with the search routine is a discrepancy on bit 0, which can happen with different kinds of devices. I'm not experienced with esp-idf so it took me a while to move the component from a managed component to one I can modify. I will fix over the weekend and post as suggested.
Get Outlook for iOS<https://aka.ms/o0ukef>
Answers checklist.
General issue report
I'm using esp-idf 5.1.2 with ESP32-S3-DevkitC in a Windows/VS Code environment. I have 2 onewire devices (DS2408 and MAX31820) on my bus, which is just a breadboard. Using the Onewire example, it can detect either of the devices, but not both. Plugging the same "network" into a Linux SBC, both devices are detected, so I believe the wiring is correct. The ID of the DS2408 (470000003FB84629) supersedes the 31820 (0100000ED5745128), so only it is detected if both are attached.
Looking at onewire_device_iter_get_next() with the JTAG debugger, I can tell that search_direction is never 0 -- last_zero = rom_bit_index is never executed even though a discrepancy is detected. I think the issue is different device families. The problem may be that last_dispepancy is initialized as 0 and rom_bit_index is initialized as 0, so a discrepancy of the first bit will be detected as the 2nd occurrance of this discrepancy? A different implementation (esp32 bitbang onewire) initializes last_discrepancy as 64. The Analog Devices App Note initializes last discrepancy as 0, but the first bit is 1 and not 0.
The text was updated successfully, but these errors were encountered: