1-wire Driver

[Melchior Dow]

Iam trying to understand how to use the Zephyr 1-wire driver on nrf52840. I see from the "scanner" sample of the w1-serial driver that it supports the nrf52840DK, however, the sample readme does not provide a description of the hardware connections required. As I understand, this driver uses the UART module, and I understand the Tx and Rx pins have to be shorted by a 470k resistor or a Schottky diode, before it can be connected to a 1-wire device such as Dallas DS28E05 EEPROM.

Could you please confirm that this is required to be done? Also, would it be possible to have a simple workaround by assigning the Tx and Rx to the same pin in a DTS overlay? This would avoid the need for hardware modifications.

My ultimate aim is to get the w1-serial driver working on a custom board that a customer has provided, on which the DS28E05 is already wired to a GPIO pin (P0.5) of nrf52840. Previously, on the old bare-metal application software, there was a bit-banging driver that was used for this communication. My job is to port the old software to Zephyr, and I would like to use the proper Zephyr driver for this. Changing the hardware is not an option for me, as this board is already in production. If the only way to use the w1-serial driver is to wire up the Tx and Rx as above, I guess I would be forced to write a new Zephyr-compatibe version of the old bit-banging driver.

thanks for your answer! Actually, my main question was (I guess I should have highlighted it), was if I could avoid physically shorting Tx and Rx, and simply assign them to the same pin in a DTS overlay. This would avoid hardware changes. As I mentioned in my original post, I am creating a software update for a production board which is already in use at various client sites, and am not in a position to modify the hardware in any way. From your answer, I feel this should be possible, but would just like to verify.

However, as you have indicated, and as I have seen in various other places too, a direct shorting also seems to work. That being so, assigning the same physical pin to both Tx and Rx in the DTS should have the same effect, unless it causes some internal problem in nrf52 UART module that you might be aware of.

Could you please verify if my approach is feasible, or if what I am trying to do is simply impossible? In that case, I guess I have no option but to go back to bit bashing and forget the serial_w1 driver, since, as I said, I am not in a position to change the board wiring. Would it be possible for you to try it out with the nrf52840DK? I do not have access that board, and perhaps it is just an issue with my custom board.

It's not been designed or intended to share pins the way you are trying no. So you should not expect this to work unfortunately. So unless you can update the board to use two pins, it looks like you need to use some kind of bit bashing yes.

1-Wire is a low speed half-duplex serial bus using only a single wire plusground for both data transmission and device power supply.Similarly to I2C, 1-Wire uses a bidirectional open-collector data line,and is a single master multidrop bus. This means one master initiates all dataexchanges with the slave devices.The 1-Wire bus supports longer bus lines than I2C, while it reaches speeds of upto 15.4 kbps in standard mode and up to 125 kbps in overdrive mode.Reliable communication in standard speed configuration is possible with 10 nodesover a bus length of 100 meters. Using overdrive speed, 3 nodes on a bus of10 meters length are expected to work solid. Optimized timing parameters andfewer nodes on the bus may allow to reach larger bus extents.

The link layer handles basic communication functions such as bus reset,presence detect and bit transfer operations.It is the only hardware-dependent layer in Zephyr.This layer is supported by a driver using the Zephyr Universal Asynchronous Receiver-Transmitter (UART) interface,which should work on most Zephyr platforms.In the future, a GPIO/Timer based driver and hardware specific drivers mightbe added.

In case the driver supports both standard speed and overdrive speed, the reset routine takes care of sendig either a short or a long reset pulse depending on the current state. The speed can be changed using w1_configure().

This command is only necessary in multidrop environments, otherwise the Skip ROM command can be issued. Once a slave has been selected, to reduce the communication overhead, the resume command can be used instead of this command to communicate with the selected slave.

This routine sets up the bus slaves to receive a command. It is usually used when there is only one peripheral on the bus to avoid the overhead of the Match ROM command. But it can also be used to concurrently write to all slave devices.

This function searches slaves on the 1-wire bus, with the possibility to search either all slaves or only slaves that have an active alarm state. If a callback is passed, the callback is called for each found slave.

This routine locks the bus to prevent simultaneous access from different threads. The calling thread waits until the bus becomes available. A thread is permitted to lock a mutex it has already locked.

As a follow-on to releasing the HA7Net - Ethernet 1-Wire Host Adapter Drivers for Hubitat, I'm releasing a similar set of drivers of beta quality for the newer Embedded Data Systems (EDS) OW-Server 1-Wire to Ethernet Server product.

The OW-Server product is positioned as a replacement for the much older HA7Net product. It's significantly less expensive than the HA7Net, is still supported, and provides a streamlined programming interface.

I have both an HA7Net and an OW-Server running in my house supporting two different 1-Wire networks of sensors. Since the same basic RJ11 plug layout is shared across these devices, you can simply unplug a 1-Wire network from an HA7Net and plug it into an OW-Server.

In the initial beta release I've included support for several 1-wire sensor types that I have on hand and can test. Additional sensor types can be easily added by people that have other sensors supported by OW-Server.

Thanks for contributing. I like the idea but not sure if it's an advantage, at least for me, when I can get 2 or 3 zigbee sensors for the price of a single one-wire sensor.

Is this something you already have setup or do you like the presumed reliability of having a wire?

One wire sensors have been around for a long time. They are now often added to things like Raspberry Pi and Arduino. As generic devices, they can be quite inexpensive. I have been using one wire temperature sensors for several years and connected to an ESP8266 they can connect to HE through Hubduino.

For a large array of temperature sensors, particularly in a tough environment, it's hard to beat a 5-pack of waterproof probes for $13. And that's buying them retail on Amazon. Individual sensors without whips are I was drawn to 1-Wire sensors for home use 10 or so years ago when faced with the challenge of monitoring the temperature of the ground loop and domestic hot water superheater loop of our geothermal ground sourced heat pump system in addition to the tank temperatures of our preheat and main domestic hot water heaters.

Gluing inexpensive 1-Wire DS18S20 sensors to the actual pipes and tanks using thermal adhesives and connecting them to the HA7Net via Cat5 cabling was pretty easy and resulted in a maintenance free set of sensors.

Since I had done all of that, I included the same type of temperature sensors in our main and garage attics and outside all without needing to deal with batteries. Which in an attic would be rough both in terms of heat and access. I added a few humidity sensors near the three HVAC thermostats as well.

The attic was the spot where the DS18S20's became the only way to get temperature for me. I also like them for the outdoors where heat and cold are hard on batteries. With an ESP8266 costing roughly $4 and being able to connect up the 5 pack posted by @rcjordan it is a pretty inexpensive way to get temperature readings from difficult locations.

Do you use any of the other 1 wire sensors? I haven't searched for a long time. There was a real appeal to having a string of sensors on the single wire network.

Just picked up a OW-Server to test, seems to be working great. Also bought a OW-ENV-TH Temp/hud combination unit. OW-ENV - Environmental Sensors. Any possibility of supporting it? I've attached the log when trying to create the child device. They also have version with other features such as light.

It could also help to try another overlay to troubleshoot if loading the overlay is the issue, or if the issue is specific to the 1-wire overlay. If you use the ADC overlay BB-ADC-00A0.dtbo, it should show up at /sys/bus/iio/devices/iio:device0.

The other thing I noticed is that Nerves.Artifact.BuildRunners.Docker is incompatible with alias docker=podman because of a version check mismatch. I know this is a little picky, but it would be nice if nerves could support podman, because then the nix-shell would only have to provide the podman executable to provide the full environment. Docker proper requires also enabling the docker daemon, which is a system level change. Is podman support something nerves would be open to? I could try to work on a PR.

I am trying to read a DS18B20 temperature sensor on my orange pi pc, but I can't get it to work. I hooked up ground and 3.3v to the sensor, the data line I placed it on gpio 20/ physical pin 37 as other posts suggest but it is not reading it.

So it's a software issue and I wonder why you didn't follow the advice to show us the output of 'armbianmonitor -u' (we invented this for the only reason to be able to diagnose problems properly and being able to help)

I have the same Wiring Orange Pi you referenced on my DS18b20 application and have no compatibility issues. I did however, have a lot of difficulty when migrating my application from the Raspberry Pi, but in the end it was the result of stupid mistakes on my part. My pin out is as follows:

3a8082e126