Error when compiling %moddable%\examples\rmt\write example

[louisvangeldrop]

Build environment: Windows Moddable SDK version: Target device: ESP324.3.8-17-g595da4b7a

Error

 fatal error: driver/rmt.h: No such file or directory
   25 | #include "driver/rmt.h"

Steps to Reproduce

1. cd %moddable\examples\pins\rmt\write
2. mcconfig -m -d -p esp32

[phoddie]

Yes, unfortunately the ESP-IDF v5 APIs changed completely. This module was broken as a result. It is a non-trivial project to rewrite for the revised APIs.

[louisvangeldrop]

Is there an alternative for RMT for writing pulses at different pulse-times?

[linfan68]

Em.... I hit this problem too. I'll try to put something together in the coming week. @louisvangeldrop you may want to checkout the neopixel implementation, it also uses RMT but a lot simpler since it only has TX code:

moddable/modules/drivers/neopixel/esp32/neopixel.c

[louisvangeldrop]

@linfan68 Thx for hinting to the neopixel implementation with RMT. Unfortunately, I am not a C-programmer. It is a pity that espressif decided to change the specs of RMT and maybe they will do that again in the furure.

[phoddie]

In Espressif's defense, when they introduce incompatible APIs, they are almost always an improvement over what was there before. However, the change can be very disruptive to the ecosystem because the APIs are often a complete redesign. ESP-IDF 5 migration was a big project for us because of a bunch of API changes.

[linfan68]

@linfan68 Thx for hinting to the neopixel implementation with RMT. Unfortunately, I am not a C-programmer. It is a pity that espressif decided to change the specs of RMT and maybe they will do that again in the furure.

I'm using RMT module quite extensively, andI could totally understand why they redesigned the API. The legacy one was pretty buggy and quite convoluted.

As a matter of fact, the new RMT api was one of the reasons we updated our system to IDF 5.

[linfan68]

In Espressif's defense, when they introduce incompatible APIs, they are almost always an improvement over what was there before. However, the change can be very disruptive to the ecosystem because the APIs are often a complete redesign. ESP-IDF 5 migration was a big project for us because of a bunch of API changes.

I will give it a try to update RMT module to IDF 5 API. @phoddie do you think I should try to keep the JS interface (mostly the configuration object) unchanged?

[phoddie]

@linfan68 – in a perfect world the JavaScript API would be stable. If that is impractical because of significant changes to the underlying APIs, then it would make sense to reshape the API around that.

[louisvangeldrop]

@linfan68. Maybe a Javascript api around RMT, that resembles the setWatch/diditalPulse functionality of Espruino? I keep trying...

[linfan68]

@linfan68. Maybe a Javascript api around RMT, that resembles the setWatch/diditalPulse functionality of Espruino? I keep trying...

emmm… this layer of api (under module/pins ) does not work in this way. They have very minimal and standard read/write methods. But with read/write you can wrap a higher level api easily.

[linfan68]

@louisvangeldrop I have a simple demo working (with the new RMT module an a test js app): RMT_IDF5_POC_TXOnly.zip

Only TX, and notice I changed the way JS sends sequence encoding to the C side to match the RMT protocol (also save some memory), for details check the .js code.:

You should see waveform like this:

LOTS of things missing:

• Rx function
• DMA support
• multiple RMT instances
• cleaning up
• ...

I'm still struggling about how to match the RMT design with the JS interface. For example, the RMT native module supposed to work with an "encoder" that transform byte data into RMT sequence on-the-fly, but that encoder needs to be implemented with the native code (because it's time critical, and needs to be placed in IRAM), which is not achievable by JS code. However considering MCUs that run JS normally has enough RAM, maybe it's a good idea to just encode whole sequence beforehand and send them to the native side, and use a simple "copy" encoder.

[phoddie]

However considering MCUs that run JS normally has enough RAM, maybe it's a good idea to just encode whole sequence beforehand and send them to the native side, and use a simple "copy" encoder.

That seems like a practical first step. If the sequence is not too long, it should be fine. It looks like that is what the IDF v4.x implementation does.

[louisvangeldrop]

@linfan68 . Thank you very much for the RMT-TX demo. I going to try it out with a RF433-switch as soon as possible.

[louisvangeldrop]

@linfan68 . I have tried your demo, but maybe I'm missing a library. In manifest.json there is a reference to "../../modules/rmt/manifest.json". However the folder "modules" is missing.

[linfan68]

There are two folders in the zip (rmt and rmt-test), you need to extract rmt folder somewhere in your tree and change the reference path to the manifest file in it. If you extract both folders in the same dir, try to change that line into: "../rmt/manifest.json"

Louis van Geldrop @.***>于2024年2月18日 周日下午11:09写道：

@linfan68 https://github.com/linfan68 . I have tried your demo, but maybe I'm missing a library. In manifest.json there is a reference to "../../modules/rmt/manifest.json". However the folder "modules" is missing.

— Reply to this email directly, view it on GitHub https://github.com/Moddable-OpenSource/moddable/issues/1296#issuecomment-1951353427, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABFQYSFRPU5642VGCI6YE5LYUIKRXAVCNFSM6AAAAABB7A2ONCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJRGM2TGNBSG4 . You are receiving this because you were mentioned.Message ID: @.***>

[louisvangeldrop]

I have changed the link into "../rmt/manifest.json". However it freezes after:

let rmt = new RMT({tx_config: {
    gpio_num: 25,
    resolution_hz: 1000000,
    mem_block_symbols: 48,
    trans_queue_depth: 4,
    invert_out: false,
    with_dma: false,
    io_loop_back: false,
    io_od_mode: false,
}});

[louisvangeldrop]

In the meantime I have tried to use the Digital-class to implement the digitalPulse function with success with respect to RF433.

It turns out that the following function works:

function digitalPulse(pin, value, width) {
    for (let time of width) {
        const currentTime = Time.microseconds
        pin.write(value);
        while (Time.delta(currentTime, Time.microseconds) < time) {
        }
        value ^= 1;
    }
}

[linfan68]

In the meantime I have tried to use the Digital-class to implement the digitalPulse function with success with respect to RF433.

It turns out that the following function works:

function digitalPulse(pin, value, width) {
    for (let time of width) {
        const currentTime = Time.microseconds
        pin.write(value);
        while (Time.delta(currentTime, Time.microseconds) < time) {
        }
        value ^= 1;
    }
}

Emmmm… if what you need is a simple square wave, checkout the PWM module.

This implementation is very inefficient, what is the frequency of the signal you need?

[louisvangeldrop]

The times do vary from 25 microseconds to 2000 microseconds.