RMT calling a second time

[louisvangeldrop]

I want to use the RMT-functionality for retrieving DHT11/22 thermohygrometer data. The DHT11/DHT22 protocol needs to trigger the DHT to respond in the following way:

this.dht11Pin = new Digital({ pin: this.pin, mode: Digital.Output }); this.dht11Pin.write(0); // Send start signal this.dht11Pin.close() Timer.delay(20) this.dht11Pin = new Digital({ pin: this.pin, mode: Digital.InputPullUp }); this.inputRMT = new RMT({ pin: this.pin, channel: 0, divider: 80, direction: "rx", filter: 0, timeout: 1000, ringbufferSize: 512 });

let result = this.inputRMT.read(data.buffer); this.inputRMT.close() this.dht11Pin.close()

I do get the data with quite accurate timings - only missing the last 6 bytes. If I recall the same cycle, I get the following RMT-error:

"C:\Users\louis\OneDrive\Apps\IoT\moddable\modules\pins\rmt\esp32\rmt.c (146) # Break: RMT: install failed!"

It looks that it is not allowed to call RMT with the same parameters for the second time.

[phoddie]

I do get the data with quite accurate timing

Cool!

It looks like there's no call to rmt_driver_uninstall in the destructor. Try adding:

rmt_driver_uninstall(rmt->channel);

before the call to c_free here:

https://github.com/Moddable-OpenSource/moddable/blob/8c62c86e6bc7c3defe484c61e1f07d8b4e159241/modules/pins/rmt/esp32/rmt.c#L65-L69

Maybe that helps?

[louisvangeldrop]

It helps. The error does not appear anymore. Thanks for the prompt response.

[phoddie]

Great. Thanks for confirming. We'll include that in the next update.

(Please consider sharing a video demo of what you are doing sometime. I'm curious to see it.)

[louisvangeldrop]

I will do my best to finish this project. I am not sure: run it using a battery and deepsleep or using a usb-cable.

[louisvangeldrop]

I am still struggling with this project. I want to display the thermohygro-data on a TTGO LilyGo 1.14 inch LED device. As a test I used the Clock-example, but its doesn't work. I get the following error when using SPI-port values: null, 0 and 3.

With SPI is 1 or 2 , the mcu will not crash, but then the screen is not initialized.

Guru Meditation Error: Core 0 panic'ed (LoadProhibited). Exception was unhandled. Core 0 register dump: PC : 0x4008b3cc PS : 0x00060230 A0 : 0x800faf54 A1 : 0x3ffbdf80 A2 : 0x00000000 A3 : 0x00000000 A4 : 0xffffffff A5 : 0x00000000 A6 : 0x00000001 A7 : 0x00000065 A8 : 0x8008b3c9 A9 : 0x3ffbdef0 A10 : 0x00000000 A11 : 0x00000000 A12 : 0x000005a7 A13 : 0x3f424ccf A14 : 0x00000001 A15 : 0x3ffb9f74 SAR : 0x00000009 EXCCAUSE: 0x0000001c EXCVADDR: 0x00000040 LBEG : 0x400d35be LEND : 0x400d35d1 LCOUNT : 0x00000000 Backtrace:0x4008b3c9:0x3ffbdf80 0x400faf51:0x3ffbdfc0 0x400faf97:0x3ffbdfe0 0x400f9848:0x3ffbe000 0x400f9dd5:0x3ffbe030 0x400f9f0d:0x3ffbe060 0x400e1acf:0x3ffbe080 0x400d53cd:0x3ffbe0f0 0x400d3fcd:0x3ffbe110 0x400d2fd9:0x3ffbe2c0 0x400d2fe3:0x3ffbe310 ELF file SHA256: 108bb6d11c54b5f4 Entering gdb stub now.

Manifest.json:

{ "include": [ "$(MODDABLE)/examples/manifest_base.json", "$(MODDABLE)/examples/manifest_commodetto.json", "$(MODDABLE)/examples/manifest_net.json", "$(MODDABLE)/modules/drivers/st7789/manifest.json", "$(MODDABLE)/modules/pins/digital/manifest.json" ], "modules": { "": "./main" }, "resources": { "-alpha": "./digits" }, "config": { "screen": "st7789" }, "defines": { "ili9341": { "width": 135, "height": 240, "cs": { "port": null, "pin": 5 }, "dc": { "port": null, "pin": 16 }, "rst": { "port": null, "pin": 23 }, "spi": { "mosi": 19, "sck": 18, "port": null } } } }

[mkellner]

Hello, in the manifest, I see a few things wrong:

1) spi should be outside of the ili9341 definition. 2) mosi and sck need pins. 3) ports in pin definitions is not necessary if it is null. 4) You can shortcut the pin definition by using "mosi_pin":19 instead of "mosi": { "pin": 19 } 5) The SPI speed hay have to be modified.

{
    "include": [
        "$(MODDABLE)/examples/manifest_base.json",
        "$(MODDABLE)/examples/manifest_commodetto.json",
        "$(MODDABLE)/examples/manifest_net.json",
        "$(MODDABLE)/modules/drivers/st7789/manifest.json",
        "$(MODDABLE)/modules/pins/digital/manifest.json"
    ],
    "modules": {
        "": "./main"
    },
    "resources": {
        "-alpha": "./digits"
    },
    "config": {
        "screen": "st7789"
    },
    "defines": {
        "spi": {
            "mosi_pin": 19,
            "sck_pin": 18
        },
        "ili9341": {
            "spi_port": "VSPI_HOST",
            "width": 135,
            "height": 240,
            "cs_pin": 5,
            "dc_pin": 16
            "rst_pin": 23
        }
    }
}

I note that you may need some different initialization registers for the st7789. I just did a similar display and had to add some initialization registers after the rst_pin like this:

"ili9341": {
    "hz": 27000000,
    "spi_port": "VSPI_HOST",
    "width": 135,
    "height": 240,
    "cs_pin": 5,
    "dc_pin": 16
    "rst_pin": 23,
            "column_offset": 40,
            "row_offset": 53,
            "registers": [
                "0x01, 0,",
                "0xff, 150,",
                "0x36, 1, 0x70,",
                "0x3A, 1, 0x05,",
                "0x21, 0,",
                "0x11, 0,",
                "0x29, 0,",
                "0xff, 100,",
                "0x2B, 4, 0x00, 0x35, 0x00, 0xbb,",
                "0x2A, 4, 0x00, 0x28, 0x01, 0x17,",
                "0xff, 100,"
            ]
}

[louisvangeldrop]

Thx for the corrections in manifest. I have adapted the manifest and the good thing is, the exception is gone. In the Clock example the software stops at the first "render.end()". Pressing "Stop" or "Pause" in the debugger doesn't work anymore.

render.begin(); render.fillRectangle(backgroundColor, 0, 0, render.width, render.height); render.end();

[phoddie]

FWIW - the end call is when the pixels are sent out over SPI. The display driver doesn't wait for a response from the display - it just outputs pixels to SPI. So, it isn't blocking on the display. Perhaps there's something wrong with the parts of your configuration related to the ESP32 SPI configuration that causes a conflict on this board.

[louisvangeldrop]

The pin-definitions are correct. I have used the specs of the board and tried these parameters with this example: http://www.espruino.com/modules/ST7789.js

This example works. So I am puzzling what is going wrong.

See pin-diagram. BTW the BL-pin should be number 4

[mkellner]

Displays can be challenging. The initialization of the particular screen may be hanging you up. The "registers" I have suggested above worked for my particular case. I got the registers by looking at sample code that the display vendor pointed to and adapting its initialization setup to the Moddable SDK style.

With a google search for device you mentioned, I found some documentation which pointed to an arduino driver. Digging into the github sources for that driver, I found the initialization specification for the ST7789 device. If that code works on your device (ie. first always try with the vendors example to ensure that the hardware works), then you can adapt the initialization writecommand and writedata to the "registers" specification.

As an example: in https://github.com/Bodmer/TFT_eSPI/blob/master/TFT_Drivers/ST7789_Init.h

  writecommand(ST7789_SLPOUT);   // Sleep out
  delay(120);
  writecommand(ST7789_NORON);    // Normal display mode on
  writecommand(ST7789_MADCTL);
  writedata(TFT_MAD_COLOR_ORDER);
  ....

would translate to

    "registers": [
        "0x11, 0,",
        "0xff, 120,",
        "0x13, 0,",
        "0x36, 1, 0x08,",
...

For the registers array, the first value is the register (ie. ST7789_SLPOUT equates to 0x11). The second value is the number of data values to follow, then the data values. A register of 0xff indicates a delay of the following number of milliseconds.

---

I notice while writing this that you've pointed to a different file. That has a ST7789_INIT_CODE that you can adapt.

[mkellner]

This should be moved to the discussions area of the github repository or opened as a new issue as this no longer is about RMT.

[louisvangeldrop]

I fully agree.