ESP32S3 DMA - EVE Text Issue

[Ed-Tronics]

Hi Rudolph,

Hope you're well and enjoying life. I have got a great UI set up for my project now, thanks to your excellent library! However, I've found a weird bug with the text command in my context.

Environment
Platform-IO (VS-Code extension)
ESP32-S3
ESP-IDF / Arduino framework
Riverdi EVE3 5" (EVE_RiTFT50)

Problem
When EVE_cmd_text_burst is the last command in a burst list, it can exhibit the following:

• Not appearing at all (this can be resolved by a no op or other basic command before and after)
• Affecting the previous command (in my case, gauge background major divisions only partially shown
• String is sometimes truncated by 1 character

My Code
Although I use switches and macros to do various things, my code is essentially:

  EVE_start_cmd_burst();
  EVE_cmd_dl_burst(CMD_DLSTART);
  EVE_color_rgb_burst(BLACK);

  // Some other static gauge backgrounds, text etc

   EVE_cmd_gauge_burst(
   370,                                    // X position
   ROW_7of9,                                // Y position
   GAUGE_RADIUS_MED,                        // Radius size
   EVE_OPT_NOBACK | EVE_OPT_NOPOINTER,      // Options for background
   AuxDevice_OnBd.getConfig().Gauge.MajorDivisions, // Major divisions from device config
   GAUGE_MIN,                               // Minor divisions
   0,                                       // Value (0 for background)
   GAUGE_STEPS                              // Number of steps
   );
   EVE_cmd_text_burst(370, (ROW_7of9 + 30), TNR_FONT, EVE_OPT_CENTERX, "Axx");

  // Dynamic text, needles etc

  EVE_cmd_dl_burst(DL_DISPLAY);
  EVE_cmd_dl_burst(CMD_SWAP);
  EVE_end_cmd_burst();

.. and what I see is lots of minor divisions and one major division at the end. I have confirmed a display list size of <2.5kB.
I can get around it for now with no ops, but it would be nice to find out what the problem is!

[RudolphRiedel]

Hello,

so that is BT815, the next best thing I had lying around was an EVE3-50G.
I seriously need to clean my desk. :-)
And what I had readily available was an Arduino UNO clone.

With that setup I am currently running this from my basic demo:

EVE_cmd_number_burst(104, EVE_VSIZE - 20, 26, EVE_OPT_RIGHTX|6U, num_profile_b);

EVE_cmd_gauge_burst(370, 200, 100, EVE_OPT_NOBACK, 5, 4, 6, 20);
EVE_cmd_text_burst(370, 230, 28, EVE_OPT_CENTERX, "Axx");

EVE_display_burst(); /* mark the end of the display list */
EVE_cmd_swap_burst(); /* make this list active */

EVE_end_cmd_burst();

And there is no difference in the display, I can change the length of the text, just displays fine.
With the logic-analyzer I can see that the padding is also working as expected, the text is followed by 1 to 4 zero bytes.

So, unfortunately, I can not reproduce your issue so far.

// Dynamic text, needles etc

What is this though, is EVE_cmd_text_burst() the last command in the list, or is it not?
Please provide a somewhat complete and simple example that triggers the issue.

[Ed-Tronics]

Thanks for testing that for me, it is a fairly standard set of commands so I should know better... however I have found the issue now!

As I was deconstructing my setup, based on your example, I noticed that when building my static background list I was calling the burst start and end commands whereas your example doesn't. I was also using the associated burst commands. I think these things combined was leading to an unexpected packet structure, since I had essentially nested two packets.

So the solution was to copy your example, removing the burst commands and adding EVE_execute_cmd(); once the display list is finished and after using EVE_cmd_memcpy();

Would you mind explaining the purpose of the execute command vs DL_DISPLAY & CMD_SWAP?

Thanks again for your help,

Connor

[RudolphRrr]

You mean from void initStaticBackground(void)?
That one only generates a display-list snippet that is stored for re-use and not directly displayed.
And since that is only done once there is close to no runtime to be saved from using EVE_start_cmd_burst() / EVE_end_cmd_burst() around that.
Edit, oh yes, and practically all EVE_execute_cmd() does is to wait for the command co-processor to be finished which is not really necessary for display-list updates and actually a bad idea when using DMA.

[Ed-Tronics]

You mean from void initStaticBackground(void)?

That's right, I can see there is little benefit to the bursts at this stage but I'm a sucker for efficiency! However, the bigger point is that (I now realise) I am not seeing my whole display list copied. Having spoken to Claude (lol), I realise that I need to leave time between ending the burst and copying the display list since it takes time for the DMA transfer and then the coprocessor to build the display list!

Here's my code:

   EVE_start_cmd_burst();
   EVE_cmd_dl_burst(CMD_DLSTART);                    /* Start the display list */
   EVE_cmd_dl_burst(DL_TAG);                         /* no tag = 0 - do not use the following objects for touch-detection */
   EVE_cmd_dl_burst(DL_VERTEX_FORMAT);               /* set to 0 - reduce precision for VERTEX2F to 1 pixel instead of 1/16 pixel default */
   EVE_cmd_dl_burst(CLEAR_COLOR_RGB(255, 255, 255)); // Set screen fill colour
   EVE_cmd_dl_burst(CLEAR(1, 0, 0));                 // Clear (fill) screen with colour above
   EVE_cmd_dl_burst(COLOR_RGB(0, 0, 0));             // Anything drawn after this will be black

   productStaticDL(); // Macro to function to pull in product specific static display list items (text, separators, gauge backgrounds)

   EVE_end_cmd_burst();

   static_dl_length = EVE_memRead16(REG_CMD_DL);                // Acquire the length of the current display list from REG_CMD_DL
   EVE_cmd_memcpy(MEM_DL_STATIC, EVE_RAM_DL, static_dl_length); // Copy the first (static_dl_length) Bytes of the display list on RAM_DL to the last 4kB, for use with append

Edit, oh yes, and practically all EVE_execute_cmd() does is to wait for the command co-processor to be finished which is not really necessary for display-list updates and actually a bad idea when using DMA.

Good to know. So this is perhaps only necessary after sending a co-processor cmd like EVE_cmd_memcpy? Won't this solve my problem above?

Cheers.

[RudolphRiedel]

Yes, what you need when you generate a snippet is for the co-processor to finish and in this case using DMA does not save any time.

productStaticDL();

What does this do?
I hope that it is not like initStaticBackground().

The whole idea with dividing the display list into a dynamic and a static part is that
the static part is only generated once.
And that happens outside of building the normal display list.

This helps with SPI traffic, EVE_cmd_append() to attach the pre-generated snippet needs 12 bytes on the SPI,
what I have in initStaticBackground() is way beyond that.

Of course this is only meant as a simple example, you could have a bunch of pre-generated snippets to attach
to the display list when needed.

Even something simple as doing two snippets for a single button to display it either as pressed or not pressed could save time with the SPI as CMD_BUTTON needs to transfer at least 20 bytes and potentially more depending on the text on the button.
On the other side, RAM_G is limited.

Doing a gauge for example in two steps, one for the divisions in the static part and one for only the pointer in the dynamic part - I would not do that as the part with only the pointer needs to send the same amount of bytes.
Providing a static image for a gauge with the divisions and then draw the pointer over it dynamically, that makes sense.

[Ed-Tronics]

productStaticDL(); is just a list of eve_cmd_xxx, nothing else. A different set of commands is called depending on which product is enabled via pre-processor macro, I'm using it exactly as you describe it's just that my project builds many different product firmwares.

An interesting thought regarding the gauge, I hadn't considered that it would be the same amount of display-list entries for static and dynamic parts. Wont the display lists generated by the co-processor be different depending on what is displayed? (e.g. EVE_OPT_NOPOINTER for the dynamic part)

[RudolphRiedel]

Yes, you are correct, the display-list generated from the co-processor commands can be different, but I was only talking about the transfer from the host-mcu to the EVE chip.