move to new esp rmt device driver: resolves #28

[mjcross]

Proposed changes to integrate Espressif's new RMT driver

[mjcross]

As promised, a new from-scratch implementation of owb_rmt.c et al that talks to Espressif's new RMT driver.

• works with the existing unmodified esp32-ds18b20-example code
• passes all the testing I've done so far (8 sensors on a ~2 metre bus)
• not yet tested in the parasitic power configuration (but haven't touched any of that code)

The public API should be backward compatible but the tx_channel and rx_channel parameters don't do anything any more as the new driver removed these from user space.

There are also a couple of new public API functions: driver->read_bytes() and driver->write_bytes() added to owb.h because with the RMT it's slightly more efficient to handle multiple bytes at a time. They can handle up to 8 bytes at a time. I've left it up to you whether you want to hook them into your owb_read_bytes() and owb_write_bytes() (they are not at the moment); but the driver's 'bits' functions do automatically use them if called with nbits = 8.

[mjcross]

Just shout if you want any tweaks.

[DavidAntliff]

@mjcross awesome, thanks for this. I will take a closer look soon.

Please don't be disheartened if you don't hear from me for a little while, I will get to this.

Quick question - if someone uses this with the older ESP-IDF, prior to the RMT deprecation, does it fail (to compile, or run) in an informative way?

[mjcross]

@DavidAntliff no worries - I mainly did the updates because I use your lib in a couple of home projects but if others can benefit then that's a real bonus. FWIW I've already pushed something similar to my esp32_onewire repo that reproduces my API for the RPI Pico.

Good point about building with an an outdated IDF. At present it will just fail to compile but it would be far better to check IDF_VERSION_MAJOR in CMake. I'll take a look at that.

Could this also be a good time to strip out the old GPIO stuff? It would certainly simplify the project internally.

[CJCombrink]

@mjcross Nice work with the pr.

If I try to use it (drop in replacement) I get the following compiler error

C:/.../managed_components/esp32-owb/include/owb_rmt.h:77:32: error: unknown type name 'rmt_channel_t'
   77 |                                rmt_channel_t tx_channel, rmt_channel_t rx_channel);
      |                                ^~~~~~~~~~~~~
C:/.../managed_components/esp32-owb/include/owb_rmt.h:77:58: error: unknown type name 'rmt_channel_t'
   77 |                                rmt_channel_t tx_channel, rmt_channel_t rx_channel);

If I replace it with int (as in the source file) I get a new compiler error:

C:/.../managed_components/esp32-owb/include/owb_rmt.h:97:3: error: conflicting declaration 'typedef enum rmt_channel_t rmt_channel_t'        
   97 | } rmt_channel_t;
      |   ^~~~~~~~~~~~~
In file included from C:/Users/<>/esp/esp-idf/components/driver/include/driver/rmt_common.h:11,
                 from C:/Users/<>/esp/esp-idf/components/driver/include/driver/rmt_tx.h:12,
                 from C:/.../managed_components/esp32-owb/include/owb_rmt.h:41,
                 from C:/.../managed_components/esp32-owb/include/owb.h:324,
                 from C:/.../managed_components/esp32-ds18b20/include/ds18b20.h:37,
                 from C:/.../main/drivers/DS18B20Driver.cpp:10:
C:/Users/<>/esp/esp-idf/components/driver/include/driver/rmt_types.h:22:16: note: previous declaration as 'struct rmt_channel_t'
   22 | typedef struct rmt_channel_t *rmt_channel_handle_t;
      |                ^~~~~~~~~~~~~

I am using ESP-IDF 5.0.3.

Am I doing something wrong?

Update/Edit: The following steps allowed me to compile and test the code

1. Replace rmt_channel_t with int in the header (owb_rmt.h).
2. Comment out the typedef enum {...} rmt_channel_t from the header (owb_rmt.h)
3. Replace any reference to the enums in my code with 0

After the above changes my code works as before but with the new driver

[mjcross]

I get the following compiler error
C:/.../managed_components/esp32-owb/include/owb_rmt.h:77:32: error: unknown type name 'rmt_channel_t'

@CJCombrink Sounds like you're picking up the original version of include/owb_rmt.h rather than the one from the PR (link).

@DavidAntliff do you think you'll be likely to merge the PR at some point?

The PR version of include/owb_rmt.h has rmt_channel_t defined as follows, in lines 67-97:

/**
 * @brief Legacy RMT channel IDs.
 * 
 * These are no longer used for anything. They are defined here purely so
 * that legacy code can still compile.
 */
typedef enum {
    RMT_CHANNEL_0,  /*!< RMT channel number 0 */
    RMT_CHANNEL_1,  /*!< RMT channel number 1 */
    RMT_CHANNEL_2,  /*!< RMT channel number 2 */
    RMT_CHANNEL_3,  /*!< RMT channel number 3 */
#if SOC_RMT_CHANNELS_PER_GROUP > 4
    RMT_CHANNEL_4,  /*!< RMT channel number 4 */
    RMT_CHANNEL_5,  /*!< RMT channel number 5 */
    RMT_CHANNEL_6,  /*!< RMT channel number 6 */
    RMT_CHANNEL_7,  /*!< RMT channel number 7 */
#endif
    RMT_CHANNEL_MAX /*!< Number of RMT channels */
} rmt_channel_t;

[CJCombrink]

@mjcross
I will confirm, but a quick check showed that in the current release/v5.0/components/driver/include/driver/rmt_types.h#L22
there is this line that conflicts

typedef struct rmt_channel_t *rmt_channel_handle_t;

If you follow the includes in my original message you will see how it gets there.

The includes are:

1. owb_rmt.h#L41

   #include "driver/rmt_tx.h"
   

2. driver/rmt_tx.h#L12

   #include "driver/rmt_common.h"
   

3. driver/rmt_common.h#L11

   #include "driver/rmt_types.h"
   

4. driver/rmt_types.h#L22

   typedef struct rmt_channel_t *rmt_channel_handle_t;
   

[mjcross]

@CJCombrink
Just checking my build environment for that PR locally (but it's vanilla so it's probably the same as yours). Please could you check to see that your version of esp32-owb/include/owb_rmt.h has the typedef enum{...} rmt_channel_t in lines 67-85 ?

[mjcross]

@CJCombrink
OK I've checked my local build environment for the PR and I've got the same incudes as you listed (here) so that's not the issue.

[CJCombrink]

@mjcross Can you reproduce?
One thing to note perhaps is that I am compiling with a C++ compiler. I migrated my project from C to C++. Maybe the C++ compiler is a bit more strict in this regard.

[mjcross]

@CJCombrink wrote:

Can you reproduce?

Tried a full clean build, and no errors... as you say, perhaps it's the compiler.

I'm using:

gcc --version
Apple clang version 14.0.0 (clang-1400.0.29.202)
Target: x86_64-apple-darwin21.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

[CJCombrink]

This is what I have

C:/Users/<>/.espressif/tools/xtensa-esp32-elf/esp-2022r1-11.2.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-g++.exe --version                                            
xtensa-esp32-elf-g++.exe (crosstool-NG esp-2022r1) 11.2.0                                                                                                                    
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.