# 1-Wire Interfaces

I am wondering about the experience of users in this site with the 1-Wire interface as far as reliability in communications and ease of use.

From my perspective, the main issue I see is the lack of native 1-Wire modules in microcontrollers, which means it has to be done in software with some timers. I've even used it a little bit with FPGAs using Maxim's own 1-Wire FPGA syntesizable module, but the results were pretty horrendous since it didn't work and I ended up using a software solution (which requires careful timing). Perhaps using an actual timer with capture/compare would have made a few things easier.

1) Has it been reliable and useful in your projects?

2) How did you implement the communications interface?

Any tips/tricks that make it easy to use would be greatly appreciated.

• A bit more context would help. What kind of instrument are you designing? What kind of 1-wire peripheral(s) are you considering? – Nick Alexeev Dec 30 '12 at 21:06
• I was planning on adding a few temp sensors to a board. I2C is easy, but some interesting devices come in 1-Wire and I've had bad experiences with it before. – Gustavo Litovsky Dec 30 '12 at 21:14
• 1-Wire is easy to implement, and doesn't hog a lot of pins if that is a concern. It has it's limitations, just like anything else. I don't agree that you should avoid it if possible. It simply depends on the application. – capcom Jan 1 '13 at 12:57

I've had bad experience with 1-wire too. 1-wire performs poorly in presence of EMI**.

IMHO, the only reasonable niche for 1-wire are applications where every wire and connector pin is very precious, and slow communication rate is acceptable. These are usually low cost and high volume products, for example: disposable medical applicators, printer ink cartridges, meshes of wired peripherals in non-trivial numbers.

Generally, I don't see a point for choosing 1-wire over I2C, when peripherals are on the same PCB as the master. Wiring is affordable within PCB.

There are I2C to 1-wire bridge ICs, which can take low-level burden from the main controller.

** I2C is not the most EMI-resilient bus either. Still, I2C works better than 1-wire in presence of EMI.

• I think your post sums it up as "Avoid it if possible" which was my feeling as well. Thanks. – Gustavo Litovsky Dec 31 '12 at 6:35

I've only once did anything with a 1-wire bus, and that was to build a test jig that connected to existing equipment that contained a 1-wire EEPROM. This jig had to, among other things, read and write the EEPROM.

Everything just worked as I remember it. Of course before writing any code I carefully read the Dallas 1-wire spec and the datasheet for the particular part. After understanding the 1-wire bus, the firmware layers to implement the protocol become apparent. Again, there were no surprises, and everything worked as expected. I even ended up with host code that could enumerate all the devices on the 1-wire bus.

I wouldn't go long distances with 1-wire, but it seems to work well for what it is intended for. As with most things, read the datasheet, and the rest is just implementation.

In response to a comment below, I went back and checked how exactly the timing was implemented in this one case. The processor was a PIC 18 and timing was done by turning off interrupts temporarily and executing a controlled number of instructions. In this particular system, there was plenty of processing power and interrupts being off occasionally for a few 10s of microseconds was acceptable. That may not be the case with other implementations. Each case should be thought about separately.

Here are the critical routines for reading and writing individual bits. Only these two routines and the bus reset routine turned off interrupts and did critical timing. Everything was else firmware above this low level layer, like reading and writing whole bytes and enumerating the bus devices.

;*******************************************************************************
;
;   Subroutine WIRE1_WRBIT
;
;   Write a single bit to the 1-wire bus.  The bit value is taken from the low
;   bit of REG0.  All FSRs are preserved.
;
glbsub  wire1_wrbit, noregs

intr_off            ;temp disable interrupts for accurate timing
bus_low             ;start the write slot
btfsc   reg0, 0     ;bit value is 0 ?
jump    write1      ;bit value is 1
;
;   The bit value is 0.
;
wait_us 62, 3       ;hold bus low for 62 us
bus_high
intr_on             ;re-enable interrupts
wait_us 2, 6        ;leave high for at least 2 us
jump    write_leave
;
;   The bit value is 1.
;
write1   unbank
wait_us 2, 4        ;hold low for 2 us
bus_high
intr_on             ;re-enable interrupts
wait_us 60, 4       ;leave high rest of bit time

write_leave unbank           ;common exit point
leaverest

;*******************************************************************************
;
;   Subroutine WIRE1_RDBIT
;
;   Read a single bit from the 1-wire bus.  The bit value is returned in the
;   high bit of REG0.  The remaining bits of REG0 are not altered.  All FSRs are
;   preserved.
;
glbsub  wire1_rdbit, noregs

intr_off            ;temp disable interrupts for accurate timing

wait_us 2, 1        ;hold bus low for 2 us to indicate read slot
bus_high            ;let the device drive the bus

wait_us 10, 2       ;wait for reply from device to be stable
bcf     reg0, 7     ;init returned data bit to 0
dbankif wire1_reg
btfsc   wire1_reg, wire1_bit ;data bit is 0 ?
bsf     reg0, 7     ;no, set returned bit to 1

intr_on             ;re-enable interrupts
wait_us 50, 4       ;guarantee minimum bit time of 62 us

leaverest

• I agree that it's down to the implementation. Do you remember how you implemented it? Was is all software toggling, timers? – Gustavo Litovsky Dec 30 '12 at 21:51
• @Gustavo: See addition to answer. – Olin Lathrop Dec 30 '12 at 22:48
• @NickAlexeev - That was exactly my reaction too. – Connor Wolf Jan 1 '13 at 4:33