STM32 DS18B20 Bitbanging vs UART connection

[anso-engineer]

Hello, I remember as half of year ago I had to make demo between STM32 and 18B20 sensor in Proteus. All this third party libaries didn't work so I decided to dig this topc up  and found bitbanging approach. Finally I did it, but it was too complicated to adhere to the sensor timings properly, I got responses but really it was to hard work with it.
When I took a read Nucleo board I have found that my board works really well in pair with it.
Probably the reason was in Proteus sensor model.
Now I concentrate on working with real hardware, and I plan to observe more UART approach instead of One Wire bitbanging.
I few some videos where explained that UART communication with the sensor works well. Could you explain some benefits UART over BitBanging?
I heard about few:

• UART is more respectful for timings
• UART it doesn't delay main loop, some kind of hardware level or etc.
• It works really as bus, you don't need to talk with each sensor separatelly

Could you somehow comment this things or add a real benefits of UART in this case?
[/list]

[peter-h]

Many years ago I did a multizone temperature controller which used the Dallas 1820 sensors, and I found getting reliable comms was extremely hard. IIRC, I used some Dallas interface unit, which just about worked.

Not sure this helps. I would not use these in anything than a hobby project.

[anso-engineer]

Ok, but in general is BitBanging an hardest approach to this type of communication?

[pcprogrammer]

I had my doubts about using a UART for the 1-wire protocol, but it looks like it is possible. https://www.analog.com/en/resources/technical-articles/using-a-uart-to-implement-a-1wire-bus-master.html

I have not fully read the document, but I don't think it is a straight forward write a byte to the UART register and it is send to the target and understood as is. They use combinations of bits to create the needed actual 1 wire bit times for sending the data.

It will be less demanding CPU time wise than bitbanging and maybe a bit more precise in timing, but it will still be a challenge to write your own code for it.

To get a full understanding of what is being done and how it works I would advice on reading the actual 1-wire protocol specification.
https://onlinedocs.microchip.com/oxy/GUID-1618003F-992B-4E48-9411-5E5D5D952C06-en-US-3/GUID-EE2B21FC-9AA9-4C04-88EF-1951F703A56C.html
https://en.wikipedia.org/wiki/1-Wire
https://docs.arduino.cc/learn/communication/one-wire/

Probably a simpler solution is to make use of the DS2482 https://www.analog.com/media/en/technical-documentation/data-sheets/ds2482-100.pdf I2C to 1-wire interface. Your STM32 can talk via an I2C peripheral to the DS2482 and that will take care of the 1-wire bus communication.

I have used that setup in combination with a Raspberry PI and OWFS. Worked without problems for many years with a lot of sensors on the bus.

[westfw]

Interesting.   I wouldn't have thought that was possible.

But I found this:

It looks pretty straightforward.  Basically, you set your UART to 115200bps, and then sending 0xFF sends a single low "start bit" that meets the timing requirements for the sending a "1" bit to the sensor, and sending 0x00 sends a long enough low period to match the timing for a zero bit.  The 0xFF 1bit start bit is also sufficient "frame pulse" to cause the 18b20 to send data bits when it is being read.
So basically, the code sends one byte for each bit it has to transmit, and then one byte for each byte it wants to read (after sending a command that will cause the sensor to generate data.)

The example in the video uses ST HAL DMA UART functions, which seems a little extreme to me, so it's not very "bare metal."  I'm not really convinced that it's simpler than bit-banging, unless you have other things going on (like an RTOS)  that might interfere with the timing...

[dietert1]

I think GPIO bit-banging is a waste of CPU resources. In order to guarantee timing one needs to block interrupts for an extended time interval.
Timing is guaranteed only when using the UART with DMA.
Combing a timer with DMA will let you do something similar. The idea is to prepare a liming table to generate kind of PWM with cycle by cycle different timings read from the table by DMA. I guess one can use input capture with DMA, too, in order to save the incoming data.

Regards, Dieter

[westfw]

Timing is guaranteed only when using the UART with DMA.

At moderate bitrates (~15us for OneWire, or 150us for the whole UART byte), I feel like you should be able to get by without DMA, if your UART has even the usual one byte of buffering (plus the shift register.)

It does seem like a particularly obnoxious timeslot for bit-banging.  Several bytes worth of 15us+ per bit is a long time to be doing nothing else...

Based on the video, a similar hack ought to be possible with an SPI peripheral.