IOT5 from Riverdi support?

[robouden]

Just wondering if the code supports also a IOT5 board with ESP32. I like to use it for client project with VSCodium and PlatformIO.

Regards, Rob Oudendijk

[robouden]

Rudolph,

Thanks for the progress. If we could get the INT on the ESP32 going, that would be great!!

Regards, rob

[robouden]

Maybe this link?

[RudolphRiedel]

This link is excellent. I only can not try this as I do not have access to the INT line.

"External Wake Up (ext0)" is what you are looking for. For the IOT5 INT is wired to GPIO_32.

As the IOT5 should be using a FT5x46 which is pulling INT low to signal touch events this should be the line for waking up the ESP32 from deep sleep: esp_sleep_enable_ext0_wakeup(GPIO_NUM_32,0); //1 = High, 0 = Low

[robouden]

Rudolph,

Did you check the MIKROBUS 10 pin ? Maybe we can route MIKROBUS pin 10 | INT | GPIO25 signal from ESP32-WROOM-32 (from this )

regards, rob

[RudolphRiedel]

I do not have an IOT5 but this would be a different INT. I thought the idea was to wake up from touch?

[RudolphRiedel]

I made it a little faster:

The first thing I did was to change the EVE_memReadx() functions to use spi_transmit_32() instead of 4 separat 8-bit transfers.

This gives the ESP32 a nice boost as it removes the gaps between the transfers and reading the touch-tag looks like this now:

This has no effect for ATSAMD51 / ATSAME51 but is a little slower on 8-Bit controllers like AVR.

As a reference this is what the same sequence looks like with the Adafruit Arduino SAMD on the Metro-M4:

And this is what it looks like on the ATSAME51 in bare-metal on my own board:

While this is not perfectly fair for the Metro-M4 since my board is running the SPI at almost twice the speed, the gaps between the transfers are shorter as well, 260ns in bare-metal down from 440ns with Arduino. However, this is a difference of only 20 clock-cycles which means the Adafruit Arduino SAMD is really fast.

The next thing I did was cheating a little, I moved this line: display_list_size = EVE_memRead16(REG_CMD_DL); from TFT_display() to TFT_touch(),

Well, this only adds a static delay anyways and now it is called more often than needed. And while this makes no difference for the display-update with native code on the ATSAME51 for example, it helps both the ESP32 and the AVR a little with the necessary time for the display-update.

I am still in the process of cross-plattform verification but I will also update the examples when I am done. I just did all the all the measurements while writing this. :-)

[RudolphRiedel]

This still requires some cleanup but the ESP32 on my desk is using DMA right now for the display-refresh using the ESP-IDF driver under Arduino.

[RudolphRiedel]

I just pushed a native ESP32 example as well. It somehow runs a little slower using ESP-IDF directly instead of the ESP-IDF that is supplied for Arduino-ESP32. But well, it does run the SPI with DMA and 40µs for the display refresh is not this bad either.

[chadpham75]

Hi Mr. Riedel, Great job with the ESP32 example, I am able to build and run your example code on my ESP32-SOLO-1 module environment and with Matrix Orbital LCD EVE3x-43G. But the Module didn't return the correct status for the MCU so it keeps looping here uint8_t EVE_busy(void) { uint16_t space;

#if defined (EVE_DMA)
if(EVE_dma_busy)
{
    return 1;
}
#endif

space = EVE_memRead16(REG_CMDB_SPACE);

if((space & 0x3) != 0) /* we have a co-processor fault, make EVE play with us again */
{
    #if EVE_GEN > 2
    uint16_t copro_patch_pointer;
    uint32_t ftAddress;

    copro_patch_pointer = EVE_memRead16(REG_COPRO_PATCH_DTR);
    #endif

    EVE_memWrite8(REG_CPURESET, 1);   /* hold co-processor engine in the reset condition */
    EVE_memWrite16(REG_CMD_READ, 0);  /* set REG_CMD_READ to 0 */
    EVE_memWrite16(REG_CMD_WRITE, 0); /* set REG_CMD_WRITE to 0 */
    EVE_memWrite32(REG_CMD_DL, 0);    /* reset REG_CMD_DL to 0 as required by the BT81x programming guide, should not hurt FT8xx */
    EVE_memWrite8(REG_CPURESET, 0);  /* set REG_CMD_WRITE to 0 to restart the co-processor engine*/

Is there anything related to the set up should I have to watch out for in order to make my LCD co-processor not enter fault mode?

[chadpham75]

Since the looping is keeping loop in the EVE_busy(), I got this error from ESP32 as well

E (755432) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time: E (755432) task_wdt: - IDLE0 (CPU 0) E (755432) task_wdt: Tasks currently running: E (755432) task_wdt: CPU 0: main E (755432) task_wdt: Print CPU 0 (current core) backtrace

Backtrace:0x400D25D9:0x3FFBE2A0 0x40082386:0x3FFBE2C0 0x4008929E:0x3FFAF5C0 0x400892D7:0x3FFAF5E0 0x400D301C:0x3FFAF600 0x400D1C23:0x3FFAF640 0x40085069:0x3FFAF670 0x400d25d9: task_wdt_isr at C:/Users/Admin/Desktop/esp-idf-2/components/esp_common/src/task_wdt.c:187

0x40082386: _xt_lowint1 at C:/Users/Admin/Desktop/esp-idf-2/components/freertos/xtensa/xtensa_vectors.S:1105

0x4008929e: rtc_wdt_get_protect_status at C:/Users/Admin/Desktop/esp-idf-2/components/soc/src/esp32/rtc_wdt.c:21

0x400892d7: rtc_wdt_feed at C:/Users/Admin/Desktop/esp-idf-2/components/soc/src/esp32/rtc_wdt.c:66

0x400d301c: app_main at c:\projects\esp\mo\build/../main/main.c:77

0x400d1c23: main_task at C:/Users/Admin/Desktop/esp-idf-2/components/esp32/cpu_start.c:600 (discriminator 2)

0x40085069: vPortTaskWrapper at C:/Users/Admin/Desktop/esp-idf-2/components/freertos/xtensa/port.c:143

[RudolphRrr]

I can't check this right now but looking at the image you modified the code in tft.c. Please post the modified version.

[RudolphRrr]

Oh, completely overlooked this, while this is not meant to be for support, this is what the forums are for. I am also watching the Matrix Orbital forums and I get notifications if someone is posting in this thread: https://www.mikrocontroller.net/topic/395608 If you would like to discuss this on Github, okay, but this is meant to be for issues, not support requests. But please open a new issue then since everyone here is getting email notifications for this issue.

[robouden]

Rudolf,

I restarted the IOT5 project and was wondering about a EVE fonts/layout etc.documentation. Any suggestions where to look?

Regards, Rob Oudendijk

[RudolphRiedel]

Well, first of all in the programming guide from the product page: https://brtchip.com/bt81x/ https://brtchip.com/wp-content/uploads/Support/Documentation/Programming_Guides/ICs/EVE/BRT_AN_033_BT81X_Series_Programming_Guide.pdf

[robouden]

Thanks for the fast reply. I will work with that. I noticed that the build in fonts work from 28~31. Is that correct?

[RudolphRiedel]

That is not correct, the build-in fonts are 16 to 34 with 32 to 34 needing to be assigned to a bitmap handle with CMD_ROMFONT before using them. Out of these 26 to 34 are the same font in different sizes.

[robouden]

Thanks for the information. You know where there are references/samples of the fonts?

[RudolphRiedel]

I have to look thru the programming guide myself every time as well. :-) Ok, I rarely need to look up specifics, I mostly use either font 26...29. Since the BT81x I am adding an UTF-8 font if I need anything else, like special characters or a monospace font of a specific size.