davidantliff / esp32-owb Goto Github PK

I'm currently writing a bit-banged 1-Wire slave for PIC16/18, which forces me to look pretty closely at some of the 1-Wire timing. With esp32-owb as the master, the LOW pulse for a "write 1" is a bit short, which makes my slave not recognize it. This is what the code says:

As far as I understand, 2us is actually too short. The Maxim guide recommends 6us (parameter A in the second table), and the worksheet below that table gives 5us as a minimum with default parameters.

While 2us seem to work with the official 1-Wire devices I have, I think it's better to use 6us (which is what the GPIO driver already does, btw) to comply with "the standard".

Hi David
do you have any idea why the lib isn't working with parasite power? I can detect the devices, but temperature reading just delivers 85.0 - and that's not true :)
Weird thing is: The ROM code is read and the device is detected. Just reading from scratchpad didn't get the right results.
Thanks for your insights (and of course for providing that lib in the first place! Nicely written!)
Klaus

typedef union
{
/// Provides access via field names
struct fields
{
uint8_t family[1]; ///< family identifier (1 byte, LSB - read/write first)
uint8_t serial_number[6]; ///< serial number (6 bytes)
uint8_t crc[1]; ///< CRC check byte (1 byte, MSB - read/write last)
} fields; ///< Provides access via field names

uint8_t bytes[8];              ///< Provides raw byte access

} OneWireBus_ROMCode;

Should probably be

typedef union
{
/// Provides access via field names
struct fields
{
uint8_t family[1]; ///< family identifier (1 byte, LSB - read/write first)
uint8_t serial_number[6]; ///< serial number (6 bytes)
uint8_t crc[1]; ///< CRC check byte (1 byte, MSB - read/write last)
} __PACKED fields; ///< Provides access via field names

uint8_t bytes[8];              ///< Provides raw byte access

} OneWireBus_ROMCode;

I don't think that there is a guarantee that compiler will align the family, seri... to bytes.

Currently the library disables interrupts during the timing-sensitive bus transactions, to prevent interruption. This is not very friendly behaviour, although it does work for simple programs.

A better solution is to use the RMT peripheral to generate the read and write timeslots. This would provide precise timing and also free up the CPU to do other tasks while the OWB transaction is taking place.

This is an approach taken by the NodeMCU firmware: https://github.com/nodemcu/nodemcu-firmware/blob/dev-esp32/components/platform/onewire.c

I have been using your library successfully several months - maybe over year in Espressif32 framework. Most I have been using Espressif32 version 3.5, but now I am going to 6.1. You could have mention that it works also on that framework.

Some succestions:

• Could ESP_LOGE be ESP_LOGD instead? I do not see why e.g., "rx_items == 0" would be an error. It is normal that 1-wire line can be empty.
• In library.json you could have "frameworks": ["espidf","arduino"],
• There is not much changed from version 3 -> 5 or 6. Could there be conditional compiling to keep same source still for older version? e.g.,

    #if ESP_IDF_VERSION_MAJOR>3
    rmt_set_gpio(info->rx_channel, RMT_MODE_RX, gpio_num,false);
    rmt_set_gpio(info->tx_channel, RMT_MODE_TX, gpio_num,false);
    #else
    rmt_set_pin(info->rx_channel, RMT_MODE_RX, gpio_num);
    rmt_set_pin(info->tx_channel, RMT_MODE_TX, gpio_num);
    #endif

I can also make PR, if you agree my improvements.

For the DS18B20 library + example, the RMT driver is unable to find any devices. Switching to the GPIO driver makes it work, but I would like to make use of RMT for the stability.

My environment:

Heltec ESP32 LoRa V2
1x DS18B20 on GPIO23
Code from the example repository with owb aee423c and ds18b20 4c76db4a34634aa1a2dc67a60345072590375012

Replacing:

owb_rmt_driver_info rmt_driver_info;
owb = owb_rmt_initialize(&rmt_driver_info, GPIO_DS18B20_0, RMT_CHANNEL_0, RMT_CHANNEL_1);

With

owb_gpio_driver_info gpio_driver_info;
owb = owb_gpio_initialize(&gpio_driver_info, GPIO_DS18B20_0);

Is all needed to make it work.

Not sure if it may be related, but I did also notice that the DS18B20 library in both cases thinks there is some parasitic sensor, while there is none. The attached sensor is supplied externally.

I also noticed recent commits, so could it be I should take a older/more stable version?

This is more of a question as I noticed that it works both ways.

Why in this function raw rom byte size is 8 instead of 9? Isn't last 9th byte the crc byte?

typedef union
{
    /// Provides access via field names
    struct fields
    {
        uint8_t family[1];         ///< family identifier (1 byte, LSB - read/write first)
        uint8_t serial_number[6];  ///< serial number (6 bytes)
        uint8_t crc[1];            ///< CRC check byte (1 byte, MSB - read/write last)
    } fields;                      ///< Provides access via field names

    uint8_t bytes[8];              ///< Provides raw byte access

} OneWireBus_ROMCode;

hello.. there I just need one example using your library. I tried a lot but unable to compile code in Arduino.
can u please give me one example that works with esp32 while connected to wifi for arduino
?

David & @chmorgan

Nice library thanks.

There is a comment in owb.h that says "Currently only externally powered devices are supported. Parasitic power is not supported." but the README.md says "Parasitic power mode." However, my viewing of your code make it look like it is there... so my question is: Is which is correct?

If it doesn't work, I thought that I would fix it... but any insights into how you knew it wasn't working would be helpful as a starting place.

Thanks,
Alan

The documentation for owb_rmt_initialize does not indicate that the owb_rmt_driver_info structure needs to be kept around, since the OneWireBus is actually a member of the info structure.

If the info structure goes out of scope, then things break down, and it's not apparent why. (I just spent a few hours tracking down an issue caused by this.)

When I tried searching for this library through the PlatformIO, it showed that the version is still 0.1 and last updated 3 years ago. Any chance for you to upload your latest version to that platform?

I have a DS18B20 that is malfunctioning. When it is plugged in to the bus, the call to ds18b20_check_for_parasite_power() hangs forever. I believe it is hanging in its call to _read_bits() hence why I have opened the issue here.

Obviously my malfunctioning device is the root cause here. However I think even a misbehaving bus should not cause this call to hang indefinitely.

The debug output is:

D (3428) ds18b20: ds18b20_check_for_parasite_power
E (3528) owb_rmt: rx_items == 0
D (3528) owb_rmt: _is_present 0
D (3528) ds18b20: owb_reset OK
D (3528) ds18b20: owb_write_byte(ROM_SKIP) OK
D (3528) ds18b20: owb_write_byte(POWER_SUPPLY_READ) OK
[hangs]

Edit: I am using RMT, not GPIO.

I am intermittently encountering this error when writing data to flash. I have done a bit of poking around in the config to see which settings will influence whether this error occurs, but so far I am unable to stop this from happening unless I remove the ESP_INTR_FLAG_IRAM flag from rmt_driver_install.

Steps required to produce error

• Active communication over owb rmt (DS18B20 in this case)
• Mounts SPIFFS file system (using esp_vfs_spiffs_register)
• Write data to filesystem

This error will occur perhaps 1/10 writes. Presumably this is related to whether an RMT interrupt is firing when the flash is accessed. I have not been able to produce this error when reading from flash, but reads are happening less frequently in my application.

Any ideas on what might be causing this?

Although the installation of the library is successful, the .h headers are not found during the compilation phase.

Hello,
this is very interesting !
Do you have an example using a Dallas/Maxim component with RMT please ?
Regards,
F.

CC build/esp_http_client/esp_http_client.o
/components/esp32-owb/owb_gpio.c: In function '_reset':
/components/esp32-owb/owb_gpio.c:100:13: warning: 'taskENTER_CRITICAL(mux)' is deprecated in ESP-IDF, consider using 'portENTER_CRITICAL(mux)'
taskENTER_CRITICAL(&timeCriticalMutex);
^
/components/esp32-owb/owb_gpio.c:134:13: warning: 'taskEXIT_CRITICAL(mux)' is deprecated in ESP-IDF, consider using 'portEXIT_CRITICAL(mux)'
taskEXIT_CRITICAL(&timeCriticalMutex);
^
/components/esp32-owb/owb_gpio.c: In function '_write_bit':
/components/esp32-owb/owb_gpio.c:156:13: warning: 'taskENTER_CRITICAL(mux)' is deprecated in ESP-IDF, consider using 'portENTER_CRITICAL(mux)'
taskENTER_CRITICAL(&timeCriticalMutex);
^
/components/esp32-owb/owb_gpio.c:164:13: warning: 'taskEXIT_CRITICAL(mux)' is deprecated in ESP-IDF, consider using 'portEXIT_CRITICAL(mux)'
taskEXIT_CRITICAL(&timeCriticalMutex);
^
/components/esp32-owb/owb_gpio.c: In function '_read_bit':
/components/esp32-owb/owb_gpio.c:177:13: warning: 'taskENTER_CRITICAL(mux)' is deprecated in ESP-IDF, consider using 'portENTER_CRITICAL(mux)'
taskENTER_CRITICAL(&timeCriticalMutex);
^
/components/esp32-owb/owb_gpio.c:198:13: warning: 'taskEXIT_CRITICAL(mux)' is deprecated in ESP-IDF, consider using 'portEXIT_CRITICAL(mux)'
taskEXIT_CRITICAL(&timeCriticalMutex);
^

Hi there, how should I wire my circuit to use the RMT? It seems like the library uses different GPIOs for TX and RX so I'm a bit confused. Could you provide an example?

Before finding this library I was trying to write my own version but I was having some funny issues using the same pin for TX and RX (switching it back and forward).

Thank you!

Hi David,

when compiling with idf5.0 (master branch), I get a depreciation message for rmt.h:

esp-idf/components/driver/deprecated/driver/rmt.h:18:2: warning: #warning "The legacy RMT driver is deprecated, please use driver/rmt_tx.h and/or driver/rmt_rx.h" [-Wcpp]

Regards,

Klaus

The while loop within the function owb_verify_rom blocks, if no one wire device is connected to the bus.

https://github.com/DavidAntliff/esp32-owb/blob/master/owb.c#L357

./components/esp32-owb/owb_rmt.c
../components/esp32-owb/owb_rmt.c: In function '_init':
../components/esp32-owb/owb_rmt.c:432:26: error: incompatible types when assigning to type 'volatile union ' from type 'int'
GPIO.enable_w1ts = (0x1 << gpio_num);
^
../components/esp32-owb/owb_rmt.c:436:14: error: 'gpio_dev_t' {aka 'volatile struct gpio_dev_s'} has no member named 'enable1_w1ts'; did you mean 'enable_w1ts'?
GPIO.enable1_w1ts.data = (0x1 << (gpio_num - 32));