You are reading a single comment by @DaveNI and its replies. Click here to read the full conversation.
  • @DaveNI - I wasn't aware there was an issue with parasitic power either. I'll have to try it and figure out what's taking the time. As far as I remember, OneWire itself doesn't really have any 'blocking' behaviour built into the protocol, so I'd imagine that any delay would be something to do with the DS18B20 module.

  • @Gordon - Some details I found regarding the 750ms delay:

    Parasite power mode:
    When operating in parasite power mode, only two wires are required: one data wire, and ground. At the master, a 4.7k pull-up resistor must be connected to the 1-wire bus. When the line is in a "high" state, the device pulls current to charge an internal capacitor.

    This current is usually very small, but may go as high as 1.5 mA when doing a temperature conversion or writing EEPROM. When a slave device is performing one these operations, the bus master must keep the bus pulled high to provide power until the operation completes; a delay of 750ms is required for a DS18S20 temperature conversion. The master can't do anything during this time, like issuing commands to other devices, or polling for the slave's operation to be completed. To support this, the OneWire library makes it possible to have the bus held high after the data is written.

    Normal (external supply) mode
    With an external supply, three wires are required: the bus wire, ground, and power. The 4.7k pull-up resistor is still required on the bus wire. As the bus is free for data transfer, the microcontroller can continually poll the state of a device doing a conversion. This way, a conversion request can finish as soon as the device reports being done, as opposed to having to wait 750ms in "parasite" power mode.


Avatar for DaveNI @DaveNI started