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

[RudolphRiedel]

I am confident that it can be done.
However I do not have native code for the ESP32 yet, right out of the box it should work with Arduino.
It's not like this is utterly complicated, I only have not done it so far.

But, unfortunately I found the documentation from Riverdi to be rather incomplete.
There is no user-manual or datasheet available for download.
Only a sort-of online "datasheet" that has no schematic and does not specify which pins from the ESP32 are used for what function.
Well, okay, it sort of does, but only with Zerynths pin names and not with the GPIOxx designators from Espressif.
I found out that CS on pin D4 and PD is on pin D33.
But I could not find anywhere which GPIOs these are assigned to.
Oh yes, SCLK, MISO and MOSI are connected to SPI0.

If you can figure out the pins and set these in EVE_target.h for the Arduino target and also select EVE_RiTFT50 in EVE_config.h it should work already.

What framework are you planning to use?
Arduino or the "Espressif IoT Development Framework"?

[RudolphRiedel]

Anyways, I just ordered one of these:

Because why the heck not. :-)

[RudolphRiedel]

I got it running on the ESP32 and it really only was a matter of finding a Board definition in PlatformIO that matches this board and setting up the correct pins for CS and PD:

There is something wrong however.
Either it runs a lot slower than on an Arduino UNO, or micros() is returning bogus values.

The UNO shows Time1: 516µs Time2: 48µs
The ESP32 shows Time1: 1476µs Time2: 87µs

And that is after I sped up the SPI, without modification and running the SPI at 8MHz like the UNO it is 1576/92 µs.
At 8MHz the overhead for transferring the ~220 bytes necessary for the display list should be less than 250µs.

So the UNO needs 266µs for putting the list together while the ESP32 needs 1326µs?
That is a factor of five for exactly the same calculations.
But the ESP should be at least ten times faster, not a lot slower.

I updated the "EVE_Test_Arduino_PlatformIO" example with settings for Metro-M4 and ESP32.
And I switched the display to an EVE3-50G which is the closest I have to an IOT5.

[RudolphRiedel]

Just to make sure it is not PlatformIO I installed Arduino-ESP32 in the ArduinoIDE and it even runs a little slower with
Time1: 1580 Time2: 95

Unfortunately I left the Logic Analyzer in the office.

[RudolphRiedel]

Hmm, as it turned out, the SPI driver for arduino-esp32 is garbage, at least for a direct switch from an UNO to an ESP32.
As the ESP32 is running a RTOS underneath the SPI driver is thread-safe and this costs an awfull lot of time when transferring single bytes over SPI.
There are even Interrupts() involved.

In my opinion a SPI.transfer(data); should not use anything else but direct hardware access with polling and return in very little over 1µs at 8MHz, it should not involve anything like SPI_MUTEX_LOCK() / SPI_MUTEX_UNLOCK() calls, Interrupts or copying the data to anywhere else than the SPI data register.
It should be complete thread un-aware and un-safe as a default.

As it is, this is not really Arduino compatible when transferring a couple of single bytes is taking a lot longer than on the UNO.
Yes of course, for those needing it there should be a way to make it thread-safe as well.

Anyways, as the Arduino SPI for ESP32 is by default awfully slow, special measures are required to make it useable.

The first solution I came up with is quite simple:
`

static inline void spi_transmit_32(uint32_t data)
{
#if defined (ESP32)
uint8_t buffer[4];
buffer[0] = (uint8_t)(data);
buffer[1] = (uint8_t)(data >> 8);
buffer[2] = (uint8_t)(data >> 16);
buffer[3] = (uint8_t)(data >> 24);
SPI.transfer(buffer, 4);
#else
spi_transmit((uint8_t)(data));
spi_transmit((uint8_t)(data >> 8));
spi_transmit((uint8_t)(data >> 16));
spi_transmit((uint8_t)(data >> 24));
#endif
}

`

This brings down "time 1" from 1562µs to 662µs - which is better but still way slower than the 516µs an UNO needs.
Since that kicked out Arduino compatibility already we can go one step further and replace SPI.transfer() with SPI.writeBytes().
This brings down "time 1" to 613µs - still bad.

Okay, now, my library already has measures in place to support DMA, lets use that to just
build a bigger buffer and transfer this buffer without DMA:
`
static inline void spi_transmit_burst(uint32_t data)
{
#if defined (EVE_DMA)
EVE_dma_buffer[EVE_dma_buffer_index++] = data;
#else
spi_transmit_32(data);
#endif
}

#if defined (EVE_DMA)
static inline void EVE_init_dma(void)
{
}

static inline void EVE_start_dma_transfer(void)
{
uint8_t buffer[3];
buffer[0] = (uint8_t)(EVE_dma_buffer[0] >> 8) ;
buffer[1] = (uint8_t)(EVE_dma_buffer[0] >> 16);
buffer[2] = (uint8_t)(EVE_dma_buffer[0] >> 24);
EVE_cs_set();
SPI.writeBytes(buffer, 3);
SPI.writeBytes((uint8_t *) &EVE_dma_buffer[1], (EVE_dma_buffer_index-1)*4);
EVE_cs_clear();
}
#endif
`

This brings down "time 1" to 304µs - better than the UNO but a joke when considerung the 15 times higher clock.

To recap, we are transferring 220 bytes over SPI at 8MHz clock.
The Arduino UNO needs 516µs for this with the overhead for pure SPI transfer probably at <250µs.
The ESP32 needs 1576µs for executing exactly the same code as the Arduino UNO.
By just changing the way the data is transferred over SPI without changing anything else I was able to reduce this time
to 662µs, then 613µs and finally 304µs.
So at the very minimum there is an overhead of 1272µs for transferring 220 bytes over SPI - wow.

So far I am not impressed by the ESP32 and I really do have to wonder why the Arduino core is so bad at transferring bytes over SPI in an Arduino UNO compatible way.

[robouden]

Rudolph,

Really appreciate you fast responses.
Sorry for my late reply. Had to travel and setup on other place.

I updated my code, setup for EV3-50G in EVE_config.h. Setup environment on VSCodium and PlatformIO for ESP32. Complied the code. Flashed the IOT5, but nothing on the display.

What suggestion do you have?

regards,
rob

[robouden]

Rudolph,

I checked to code from Zerynth for the IOT5. The code with Zerynth runs fine, but very slow startup I think it has to load the Zerynth VM.
Some info from the code:

bt81x.init(SPI0, D4, D33, D34)
bt81x.touch_loop(((-1, widget_choice_cbk), )) # listen to touch events and make widget_choice_cbk process them

and :

from riverdi.displays.bt81x import ctp50
from bridgetek.bt81x import bt81x

I hope this helps.

regards,
rob

[robouden]

Rudolph,

More bt81x.init info at https://docs.zerynth.com/latest/reference/libs/bridgetek/bt81x/docs/bt81x/.

_init(spi,cs,pd,int,dc=None,spi_speed=3000000)

Parameters:

spi – spi driver (SPI0, SPI1, ...)
cs – chip select pin
pd – pd pin
int – interrupt pin
dc – display configuration as a DisplayConf() instance
spi_speed – spi speed in Hertz
Initializes the chip.

When dc parameter is not specified display_conf global variable is used._

regards,
rob

[RudolphRiedel]

I received the notifications from Github at work but I do not have my Github credentials at work...

As I wrote, first of all you need to identify to which pins CS and PD are wired and how these are used from PlatformIO.
The Zerynth software has CS on D4 and PD on D33.
There are GPIO4 and GPIO33 pins on the ESP32-WROOM module.
And it is possible that these are used as "4" and "33" from Arduino.
But this is just an idea with no documentation to back this up, you need to verify on your end that "4" does indeed control the CS line of the BT815 and "33" does control the "PD" line on the BT815.

When you have the correct pin numbers, open EVE_target.h, scroll down to line 856:
#if defined (ESP32)
#define EVE_CS 13
#define EVE_PDN 12

Now change that to the correct numbers, maybe it is like this:
#if defined (ESP32)
#define EVE_CS 4
#define EVE_PDN 33

Then you need to open EVE_config.h and change line 124:
#define EVE_EVE3_50G -> #define EVE_RiTFT50

I am using the EVE3_50G as I do not have a RiTFT50 to test with and the EVE3_50G is quite similar.

[RudolphRiedel]

To put some more facts on the table to show that I am not just ranting, here are a few shots with the logic-analyzer:

This is single-byte SPI transfers, there really is that much of a gap between bytes meaning that the driver spends more time on playing with itself than putting out bytes on the SPI.

This is with SPI.writeBytes(buffer, 4);
This is only faster as there are less gaps.

This is with 13MHz instead of 8MHz, it only is faster as the bits between the gaps take less time.

This is what transferring a larger buffer looks like.
There is a short pause every 64 bytes.
The longer pause towards the start is there as I read somewhere that the transfers have to be word aligned.
And the first transfer is three bytes for the address, the rest is in 32 bits.

And for the last image, this is what it looks like using an Adafruit Metro M4 as Arduino with single byte writes.
The display update takes 302µs.
When I go bare-metal on the SAME51with my own SPI driver I get 284µs without using DMA.
All of course with the same 8MHz SPI clock.

[robouden]

Rudolph,

Hereby the part of the schematic that we can use from Riverdi.



Regards,
rob

[robouden]

Rudolph,

I tried what you suggested, but nothing on the display yet. I found more information from Zerynth at https://docs.zerynth.com/latest/reference/libs/bridgetek/bt81x/docs/bt81x/

I hope this can help you find out what is needed to get the display to work without using Zerynth (startup takes 5 seconds before anything is display). This is not acceptable for me.

Regards,
rob

[robouden]

Rudolph,

Attached is the bt81x library that Zerynth uses.

Regards,
rob
bt81x.zip

[dstulken]

It's a difficult architectural decision for sure. The ESP32 platform heavily promotes multi-core multi-threaded usage, so having thread-safe I/O by default is an understandable choice. One could argue that user code should handle locking and unlocking of resources on an as-needed basis, but then we invite priority inversion, blocked tasks, etc... the FreeRTOS scheduler becomes impacted, the watchdog fires (legitimately) causing the device to reset, etc, etc.

Making every single-byte transfer thread-safe clearly isn't elegant, but I can see why the developers would elect to have some guardrails in place for the default settings. Most people porting Arduino apps up to the multi-core ESP32 aren't going to have an extensive background in process/thread management or the associated pitfalls, and the "My ESP32 keeps rebooting! What a piece of junk!" type of forum posts are difficult for a (mostly) volunteer community to support, and it would cause unnecessary churn for hardware vendors exchanging the "faulty" modules for customers...

One thing I did see in a few search results - Have you tried testing with "CONFIG_DISABLE_HAL_LOCKS" enabled?
I also saw some reports that software SPI was faster than hardware SPI on an ESP32... although many of the posts were several years old, and things have changed very rapidly with the Arduino environment on these modules.

Please keep us posted if your ESP32-specific speedups described above make it into the mainline code - I have several ESP32/EVE projects in the works, so your efforts to diagnose things like this are certainly appreciated!

[davidjade]

Here is an example of how to drive an FT813 with an ESP32 using native (not Arduino) SPI DMA. This is a fork of this FT800-FT813 project that I did last spring to add better performing SPI DMA and to also improve and simplify the buffering of SPI data when using DMA. With this code I get these times on a EPS32 using an FT813 running the demo at a 30Mhz SPI clock rate.

Time1: 152us
Time2: 28us

Example code is here: https://github.com/davidjade/FT81x-ESP32

Note that the above example code does have one bottleneck and that is that it waits for all previous DMA requests to complete before issuing new ones. This bottle next is included in the above times. There is another way to handle that and that is by using queued DMA mode to maintain a bunch of simultaneous in-flight DMA requests. This requires managing multiple transmit buffers though and this example does not do that. However, unless you are sending very large bitmaps split over many chunks very quickly this is unlikely to be a serious bottleneck as most small DMA requests would likely complete before more where issued anyway.

However, I have another example of using DMA queued mode with the FT813 that also supports both Dual and Quad mode SPI with DMA that is stable at 30Mhz on an ESP32. It supports up to 50 (or more) in-flight DMA requests simultaneously. When using the DMA queuing mode I can easily saturate the SPI bus at 30Mhz in Single, Dual, or Quad SPI modes as long as I can feed it data fast enough. This queued DMA code is in the driver that I wrote to enable running the LVGL graphics library on the FT813, in the lvgl_esp32_drivers project. With that LVGL code I can do complete full screen bitmap updates at many frames per second on an FT813 (where each full frame is sending roughly 768k).

You may argue that this second example is not the intended purpose of using the FT813 because LVGL treats it like a big dumb bitmap display, but whatever - I wanted to use a more powerful graphics library on the displays I already had. I'm not interested in arguing about that. I am merely showing two examples of the proper way to use SPI on an ESP32 is by using native DMA and that it can be very fast.

The LVG project is here: https://github.com/lvgl/lv_port_esp32