An arduino library to communicate using the Dallas one-wire protocol, where the Arduino takes the role of a slave. Entirely implemented using interrupts, you can perform other tasks while communication is handled in background.
Have you ever tried to run this against a raspberrypi or anything else running Linux's w1 driver?
I tested your example sketch in a setup consisting of an 328P-based Arduino Nano, standard logic-level-shifter and a Pi as the master. No other sensors are present.
The Pi seems to be unable to enumerate devices (w1_gpio, w1_therm and wire kernel modules loaded).
While the Pi enumerates your driver catches bus reset correctly and calls back with error event immediately after, I am unsure where exactly. A bit of debugging shows that the state machine bounces back and forth between DS_WaitingCommand and DS_WaitingReset.
As a workaround I tried to disable enumeration on the Pi and to add client 28-0000000002 manually instead.
This gives me the device descriptors to read the scratchpad manually with the w1 driver assuming there is only the one registered client present on the bus.
Doing so, my logic analyzer tells me the bus actually carries
[reset+atr] [pause]
0x33 0x7D 0xFF (and many more 0xFF, did not count them)[reset+atr] [pause]
0x33 0x2D 0xFF [reset+atr] [pause]
0x33 0x22 [pause]
This is tried ten times before the driver throws in the towel returning
Have you ever tried to run this against a raspberrypi or anything else running Linux's w1 driver?
I tested your example sketch in a setup consisting of an 328P-based Arduino Nano, standard logic-level-shifter and a Pi as the master. No other sensors are present.
The Pi seems to be unable to enumerate devices (w1_gpio, w1_therm and wire kernel modules loaded). While the Pi enumerates your driver catches bus reset correctly and calls back with error event immediately after, I am unsure where exactly. A bit of debugging shows that the state machine bounces back and forth between
DS_WaitingCommandandDS_WaitingReset.As a workaround I tried to disable enumeration on the Pi and to add client 28-0000000002 manually instead. This gives me the device descriptors to read the scratchpad manually with the w1 driver assuming there is only the one registered client present on the bus.
Doing so, my logic analyzer tells me the bus actually carries
This is tried ten times before the driver throws in the towel returning
for the scratchpad contents and resigning with CRC failure.
Any ideas? It's possibly just me doing nonsense here but I'm starting to get the impression I might have kicked up a bug.