Teensy 4 and Riverdi 70H not working

[julianfawkes]

Hello, I've had good luck with the GDSTx library on my setup here but wanted to switch to yours to eek out some more performance. However, the built-in example in this project doesn't work at all - the backlight powers up but nothing else happens. Any idea what's happening here? One thing that might be important to note is that my PDN pin is not connected, and the whole thing is already integrated in a PCB so I can't add it. This hasn't been a problem in the other library.

Any ideas as to what might be wrong would be much appreciated!

[RudolphRiedel]

Hi,

check EVE_init(), if you add EVE_SOFT_RESET to your build environment you can get away with not wiring the PD line properly.
I am thinking about removing the condition, but there are hardly any display modules with no PD line.

[RudolphRiedel]

Yes, the cmd FIFO is limited to 4kiB.
But then the display list is limited to 8kiB and the co-processor commands usually generate several display list commands.
It is less likely with a lot of points, but if you reach the limit of the cmd FIFO you usually have reached the limit of the display list as well.

So yes, using command-append can work, you generate a display-list, do not use DL_DISPLAY and CMD_SWAP in the end, read back REG_CMD_DL and use CMD_MEMCPY to copy the display list segment to some place in RAM_G.
Check out my initStaticBackground() function in tft.c of the examples.
I am not using DMA in this function but it only is supposed to be called once.

So you could do this to generate segments and then use CMD_APPEND to copy these all together to form the final display list.

However, you can skip the part with the command append.
Start the first segment with EVE_start_cmd_burst() and CMD_DLSTART as usual, stop the segment with EVE_end_cmd_burst().
Then after the transfer is finished, just EVE_start_cmd_burst() / commands / EVE_end_cmd_burst().
And the last segment ends with commands DL_DISPLAY and CMD_SWAP.
As you need at the very least 16.67ms between two display updates anyways, you could for example write a short segment ms with the final segment to trigger the swap after 20ms.

[julianfawkes]

I think I get it! I made a loop with the series of start burst and end bursts on a single display list, and I max-out at around 220 points on the screen. Anything more and I get crazy tearing and artifacting. Is this normal? This limit is consistent whether I use bursts or not. When using the Gameduino library, I can go up to >700 points.

[RudolphRiedel]

If you can go higher using the Gameduino library, then this is not normal as the same limitations apply.
What size is your display list at 200 points?
Please post some code, it does not need to be complete or compile, just to have a look at what exactly you are trying to do.

[Greg-R]

Hello, I am also using a Teensy 4.1 with an EVE4 display. I was able to get the Arduino display example to work almost immediately. I am new to the BT817 display driver, and I have been doing a lot of experiments. I can successfully draw simple graphic primitives. I am attempting something similar as the original poster, which is essentially an audio spectrum with 512 bins. And this needs to be completed as quickly as possible.

The question I have is in regards to the statement "As you need at the very least 16.67ms between two display updates".
The experiment I am working on is to draw short lines in a for loop. This seems to run slow compared to the technology I have been using (RA8875). But if there is 16.67ms delay between display updates, that would explain the slow response time.

I am monitoring the SPI bus using an oscilloscope. Drawing a single line requires approximately 50us. That's good!
But then when I attempt to draw another line immediately after, it takes much longer to complete the second line, on the order of milliseconds, which is perplexing as the first drawing of the line is a very small fraction of that time.
I've got the while(EVE_busy()) instruction at the conclusion of the line drawing code, so the Coprocessor should be done.

So what is the source of the 16.67ms delay? Is this a fundamental limitation of the technology?

[RudolphRiedel]

The 16.67ms is 60Hz, so the actual refresh rate of the panel itself.
And what is meant by this is that you can not update the display list faster than it is used to display things.
Yes, depending on the panel you could configure things to go faster or slower, but the target generally is 60Hz.
And the same limitation applies to a RA8875 as well, only not as apparent since you are writing in a display buffer that
the panel is fed from every 16.67ms. No idea how the RA8875 actually handles this, but there must be a latency involved as these panels are written to pixel by pixel, line by line and a different frontend does not change that.

Now this is not single lines, this is not between drawing one line and then another, this is for the whole display-list, everything between CMD_NEWLIST and CMD_SWAP, regardless of using only a handfull commands in the display list or fill the whole 8kiB of RAM_CMD.
When executing CMD_SWAP the new display-list gets activated and from that point the image displayed is from the commands in the new display list, the whole image.

If you try to update the display list faster than the panel refresh rate then the screen begins to flicker.
This could be considered a bug, but then it would be pointless to update the screen faster than it can be displayed anyways,
so I would take it more as an indicator in this case that something is not quite right.

[Greg-R]

I was thinking about it for a while, and then decided to take the inverse of 16.67ms. 60Hz. Aha, video refresh rate!
Then I found the data sheet for the module which I had purchased, and there is no mention of that specification!
Oh well, I understand it now. And 60Hz is well beyond "persistence of vision", so I should be able to make this work.

I will perform some more experiments now, and gate the CMD_SWAP to greater than every 16.67ms. Maybe the "line strip" is the way to go. I am also interested in DMA, as I want to reduce the CPU load as much as possible in the application.

Thank you very much for the fast response, and also thank you for the library!

Best regards,
Greg

[RudolphRiedel]

Well, yes, this is just abstraction, the bare-panel datasheets describe things a bit different than the module datasheets.
The framerate is pixelclock divided by the sum of VCYLE and HCYCLE.

A linestrip is a pretty efficient way to plot a graph from a set of samples like an oscilloscope.

[Greg-R]

My experiment was successful. Using the line strip, I was able to plot a contrived 512 bin spectrum (random numbers) at a rate much faster than required by the application. I'm going for 20 spectrum updates per second in the application, and this was ~3X faster. Excellent!

So next is working on other elements of the display. The controller is the BT817, which has the "command list" to RAM_G feature.
Is my assumption that this is the optimal way to work with the BT817? I have had no success sending a display list to RAM_G and later appending it, however, I was able to store and retrieve a command list very easily.

I am starting to really like the BT817!

[RudolphRiedel]

There are two mechanisms to use commands from RAM_G, the older one is to use CMD_DLSTART, write a number of commands into the display list, then copy that display list to RAM_G and use CMD_APPEND.
The newer is using CMD_NEWLIST, CMD_ENDLIST and CMD_CALLLIST to write co-processor commands directly to RAM_G without interpreting them and then call it during execution of RAM_CMD to build the display list.

Both variants are used here: https://github.com/RudolphRiedel/EmbeddedVideoEngine/blob/main/examples/EVE_Test_SAME51_RVT50H/tft.c
Check initStaticBackground() and TFT_display().
The reason to use CMD_NEWLIST etc. for BT820 was that the BT820 generates display-list commands that use fixed addresses to jump within the display list, so using CMD_APPEND to add a snippet somewhere in the display list fails with strange effects.

What both of these methods provide is a way to reduce the SPI traffic from the host controller to the EVE chip,
And my example code only uses the simplest form of this by splitting the display-list into a static part that remains unchanged and a part that is is generated for every update.

I am still using that scheme, but it became somewhat obsolete when I moved to faster controllers with DMA.
The images in the example_pics folder show this, "Time1" is for executing TFT_display.
Arduino UNO, 16MHz AVR, no DMA: 516µs
ATSAMC21, 48MHz Cortex-M0 with DMA: 51µs
ATSAME51, 120MHz Cortex-M4 with DMA: 14µs
For the 600MHz Teensy that value was of course even lower, can't find a screenshot now.

[Greg-R]

Reducing the SPI traffic and load on the CPU is precisely why I am attempting to change to the BT817.
The application is a "software defined radio" and the CPU must perform signal processing operations on a hard schedule.
Currently the signal processing and the display updates are interleaved at an almost atomic level, which results in very hard to manage software. It is the spectral displays which must be sent to the RA8875 display one bin at a time. Painful!

So I believe the BT817, and in particular the "line strip" which appears to be extremely efficient, plus DMA will greatly reduce the processor load caused by display updates. Not only that, the raw SPI speed is much higher than the RA8875. And if I can get the Teensy's "Flex-IO" working as a quad SPI, there is potential for massive improvement!

I hope to be back soon for advice on using the DMA. I completed a DMA project (audio streaming) project a few months ago, so I will have a good base to start from.

Thank you again for your very helpful replies!
Greg

[RudolphRiedel]

Well, first of all, going from a famebuffer-chip to an EVE chip already reduces the SPI traffic by a lot.
My perspective was completely different, I started from using EVE and what I optimized for was to do display updates
in less than 1ms every 20ms in order to reserve the remaining 19ms for processing.
At 8MHz SPI clock this is around 1000 bytes, which already is nothing when you throw raw pixel at the display.
With higher core clocks and DMA this gets reduced to very little.
The 516µs for Arduino UNO was 224 bytes on the SPI and at 8MHz SPI clock probably more than half of the time was non-DMA SPI transfers.
Well, with AVR, DMA was not an option.
Then, back in 2019, I started to use ATSAM controllers. And with DMA, reaching <1ms was never an issue anymore.

Which is also the reason why I never explored to go beyond single SPI, there is not really a point to do this for updates
and I never had an issue with loading assets.

Now with the Teensy 4, DMA support is already baked in.
The code is in EVE_cpp_target.cpp, less than 10 lines effectively.
And all you need to do is to put EVE_start_cmd_burst(); and EVE_end_cmd_burst(); around the display-list code, like in TFT_display() of tft.c from my examples.