4 ms·

I'd like to know why 1-wire isn't more common. It seems to me like a more elegant protocol than I2C. Not least because every device has a unique baked-in addr

by TOGoS 7y ago

I'd like to know why 1-wire isn't more common. It seems to me like a more elegant protocol than I2C. Not least because every device has a unique baked-in address so you don't need to worry about address collisions or dip switches to alter them. (Also: needs one fewer wire)

AWildC182 7y ago
If I had to guess, using clock-less (serial) protocols like 1 wire and UART requires some logic on each RX side to figure out what the clock of the incoming signal is, usually a PLL of some sort, and you'll need lots of crystal oscillators to ensure that clocks are sufficiently stable and accurate as to ensure reliable communication.
- andyjpb 7y ago
  1-wire is pretty slow (kbps max in normal mode) and very tolerant of devices with a wide range of timing skew.
  - agapon 7y ago
    I wouldn't call it very tolerant. Some timings are pretty tight, like 1 to 15 microseconds, and every microsecond can count. And I am not talking about the overdrive mode where the timings are much tighter.
    - andyjpb 7y ago
      One of the datasheets I have here says: ----- During the initialization sequence the bus master trans- mits (TX) the reset pulse by pulling the 1-Wire bus low for a minimum of 480µs. ----- There is no maximum time limit for the reset pulse. ----- The bus master then releases the bus and goes into receive mode (RX). When the bus is released, the 5kΩ pullup resistor pulls the 1-Wire bus high. When the DS18B20 detects this rising edge, it waits 15µs to 60µs and then transmits a presence pulse by pull- ing the 1-Wire bus low for 60µs to 240µs. ----- A tolerance of 15uS to 60uS on the device side and 60uS to 240uS on the driver side seems pretty wide to me. Now, it's hard to actually get a good figure for these specifications because different datasheets give different values, which further suggests the tolerances are large. Another datasheet that I have here says that the presence pulse should be sampled after 72uS. This leaves at least 12uS slack for rise times, long wires, etc. To give an idea of whether 10uS is very long or not, remember that the cycle time on, for example, an 8MHz AVR as you might find in an Arduino, is 125nS. That gives you 80 instructions every 10uS (at the AVR8's advertised 1MIPS/MHz). This is plenty of time to implement the 1-Wire driver in software.
      - agapon 7y ago
        It seems that you didn't reach the part of the spec that describes how to read and transmit data bits. Also, even for simplest slaves there is still a need to keep track of time which requires additional hardware (an oscillator or some such).
andyjpb 7y ago
I have wondered this too. Maxim have documentation about the fact you can get device IDs but I've never actually worked out how to get some. I guess people didn't want to be reliant on Maxim as the numbers authority? It's pretty popular for simple serial number / "Number In A Can" applications tho'.
londons_explore 7y ago
I was under the impression it used to be patent/licensing encumbered?
londons_explore 7y ago
Programming a globally unique ID per device is a large added cost for <$0.01 devices. The device needs fuses or equivalent so it can 'remember' it's 64 bit ID. it needs logic to both program as well as read the fuses. Think of applications like LED controllers - previously with I2C all they needed was an 8 bit shift register + comparator for their address, and an 8 bit shift register for their 'brightness', and an 8 bit comparator and +-50% RC oscilator for their actual operation. Probably ~400 transistors. With onewire, they need a 64 bit address shift register, an oscilator, a state machine for bus states, a counter to act as a timer for long/short bits, multiple comparators on the timer output. I don't think you could do it in less than 1000 transistors. Doesn't sound like much, but when every LED in a million pixel LED wall needs one of these circuits, it adds up!

by TOGoS 7y ago

AWildC182 7y ago

If I had to guess, using clock-less (serial) protocols like 1 wire and UART requires some logic on each RX side to figure out what the clock of the incoming signal is, usually a PLL of some sort, and you'll need lots of crystal oscillators to ensure that clocks are sufficiently stable and accurate as to ensure reliable communication.

andyjpb 7y ago
1-wire is pretty slow (kbps max in normal mode) and very tolerant of devices with a wide range of timing skew.
- agapon 7y ago
  I wouldn't call it very tolerant. Some timings are pretty tight, like 1 to 15 microseconds, and every microsecond can count. And I am not talking about the overdrive mode where the timings are much tighter.
  - andyjpb 7y ago
    One of the datasheets I have here says: ----- During the initialization sequence the bus master trans- mits (TX) the reset pulse by pulling the 1-Wire bus low for a minimum of 480µs. ----- There is no maximum time limit for the reset pulse. ----- The bus master then releases the bus and goes into receive mode (RX). When the bus is released, the 5kΩ pullup resistor pulls the 1-Wire bus high. When the DS18B20 detects this rising edge, it waits 15µs to 60µs and then transmits a presence pulse by pull- ing the 1-Wire bus low for 60µs to 240µs. ----- A tolerance of 15uS to 60uS on the device side and 60uS to 240uS on the driver side seems pretty wide to me. Now, it's hard to actually get a good figure for these specifications because different datasheets give different values, which further suggests the tolerances are large. Another datasheet that I have here says that the presence pulse should be sampled after 72uS. This leaves at least 12uS slack for rise times, long wires, etc. To give an idea of whether 10uS is very long or not, remember that the cycle time on, for example, an 8MHz AVR as you might find in an Arduino, is 125nS. That gives you 80 instructions every 10uS (at the AVR8's advertised 1MIPS/MHz). This is plenty of time to implement the 1-Wire driver in software.
    - agapon 7y ago
      It seems that you didn't reach the part of the spec that describes how to read and transmit data bits. Also, even for simplest slaves there is still a need to keep track of time which requires additional hardware (an oscillator or some such).

andyjpb 7y ago

I have wondered this too. Maxim have documentation about the fact you can get device IDs but I've never actually worked out how to get some. I guess people didn't want to be reliant on Maxim as the numbers authority? It's pretty popular for simple serial number / "Number In A Can" applications tho'.

londons_explore 7y ago

I was under the impression it used to be patent/licensing encumbered?

londons_explore 7y ago

Programming a globally unique ID per device is a large added cost for <$0.01 devices. The device needs fuses or equivalent so it can 'remember' it's 64 bit ID. it needs logic to both program as well as read the fuses. Think of applications like LED controllers - previously with I2C all they needed was an 8 bit shift register + comparator for their address, and an 8 bit shift register for their 'brightness', and an 8 bit comparator and +-50% RC oscilator for their actual operation. Probably ~400 transistors. With onewire, they need a 64 bit address shift register, an oscilator, a state machine for bus states, a counter to act as a timer for long/short bits, multiple comparators on the timer output. I don't think you could do it in less than 1000 transistors. Doesn't sound like much, but when every LED in a million pixel LED wall needs one of these circuits, it adds up!