Questions and Problems with Snapshot2 Command

[Greg-R]

Hello, I need some help with a feature I am attempting to implement in an 800x480 BT817 display.
I am trying to implement a "waterfall". This could be described as a "time dependent temperature plot".
Temperature is shown by color, and time moves downward in a rectangular area of the display.
This is done by drawing a single line with the profile of temperature, meaning each pixel of the line can have a different color.
On a periodic basis, a new line is drawn and the lines below are shifted down. I have an idea of how to implement this using CMD_SNAPSHOT2. It may not be the most efficient, but maybe a workable prototype. I'm not getting past the basics yet.

Problems:

1. So I attempting to implement using the "CMD_SNAPSHOT2". I have this command somewhat working, yet not reliable.
   According to the programming guide, this command should not disturb the display. However it does! There is a very annoying glitch, as a drawn line jumps and flashes when the command is sent. My application can't tolerate glitches.
2. The snapshot of the line is retrieved from RAM_G using "CMD_SETBITMAP". This is somewhat working. I have the code below running in a loop, and the retrieved bitmap sometimes appears perfectly. And then sometimes nothing! I've decreased the SPI clock all the way to 1MHZ, and I see the same behavior.

Here is my code. This is using a Teensy 4.1 and PlatformIO. Hopefully there are enough comments to follow what I am trying to accomplish. The "waterfall line" in this test code is a simple line. In the actual application, it will be made pixel by pixel. The process: 1. draw a line. 2. Copy the line to RAM_G as a bitmap. 3. Re-draw the line including the bitmap.

`void loop()
{

// Command burst for waterfall line.
EVE_start_cmd_burst();
EVE_cmd_dl(CMD_DLSTART);
EVE_cmd_dl(DL_CLEAR_COLOR_RGB | 0x000000);
EVE_cmd_dl(DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG);
EVE_vertex_format_burst(0);
EVE_point_size_burst(32);

// Draw a line on the left edge, vertical middle of the display.
EVE_begin_burst(EVE_LINES);
EVE_color_rgb_burst(0xff0000);
EVE_vertex2f_burst(0, 239);
EVE_vertex2f_burst(255, 239);
EVE_end_burst();

EVE_display_burst();
EVE_cmd_swap_burst();
EVE_end_cmd_burst();
while (EVE_busy());
delayMicroseconds(20000);

// Wait 2 seconds to verify the above line is visible and stable.
delay(2000);

// Snapshot2 of the above line to middle of RAM_G.
// This command causes a very noticeable glitch in the display.
EVE_cmd_snapshot2(7, 500000, 0, 239, 256, 1);

// Wait 2 seconds to guarantee the snapshot operation is complete.
delay(2000);

// Now display the bitmap at a different location.
EVE_start_cmd_burst();
EVE_cmd_dl(CMD_DLSTART);
EVE_cmd_dl(DL_CLEAR_COLOR_RGB | 0x000000);
EVE_cmd_dl(DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG);
EVE_vertex_format_burst(0);
EVE_point_size_burst(32);

// First, the original line.
EVE_begin_burst(EVE_LINES);
EVE_color_rgb_burst(0xff0000);
EVE_vertex2f_burst(0, 239);
EVE_vertex2f_burst(255, 239);
EVE_end_burst();

// Now add the bitmap in a different location.
EVE_cmd_setbitmap(500000, 7, 256, 1);
EVE_begin(EVE_BITMAPS);
// Place the bitmap starting in the middle of the display.
EVE_vertex2f(400, 239);
EVE_end();

EVE_display_burst();
EVE_cmd_swap_burst();
EVE_end_cmd_burst();
while (EVE_busy());

// Delay to view the bitmap.
delay(2000);
}
`
Suggestions please!

Thank you,
Greg

[RudolphRrr]

Working...

I might have a different idea for you.
But while I can visualize this, I might not imagine what you are actually want to achieve, please provide an example image of how this is supposed to look like.

[Greg-R]

I was thinking of making a video, and indeed this is the best way to illustrate the problem:

https://drive.google.com/file/d/1YswJ7E6jwNPWnTkjq2CO7cMk1hGtEVLr/view?usp=sharing

The spectrum problem using the "line strip" is working very well! Now if I can get past this waterfall problem, conversion of the project to EVE is very possible, with very significant performance improvement!

[Greg-R]

I should mention that the "first line" at the top of the waterfall, is manufactured from individual pixels using the "points" primitive and a for-loop, such that each pixel is a color depending on signal strength. So that part of the problem was successfully solved.
Apparently, that is the easy part!

[RudolphRrr]

Ok, yes, I was looking into waterfall views for signals and this is practically the only applications that I got examples for. :-)
That immediately changed how to approach this, the "line" is somewhat more complex, ok.

What I came up with is to use bitmaps with a height of 1 pixel, use like 64 of these or whatever the overall height is.
Generate the bitmap for a waveform in the controller, I would recommend RGB332 format to keep it 8 bit per pixel, transfer that bitmap to RAM_G, then generate the next bitmap later and transfer it and so on.

Now display the images like this (from EVE Screen Editor):
CLEAR(1, 1, 1)
COLOR_RGB(255, 255, 255)
CMD_SETBITMAP(0, RGB332, 256, 1)
BEGIN(BITMAPS)
CELL(0)
VERTEX2F(1600, 3200)
CELL(1)
VERTEX2F(1600, 3216)
CELL(2)
VERTEX2F(1600, 3232)

So the idea is that this looks like one big bitmap in memory that is displayed as 64 images with a height of 1 pixel.
To animate that, change the CELL values from one display update to the next.

Preferably use one line more than you display to not update a line that is displayed.
The limit with CELL would be 127 lines as the range is 0...127.

This is a ring-buffer for the lines.

On second thought, you could also change the way this is displayed.

First: 0...63
Second: 64, 0..62
Third: 63..64, 0..61

So two CMD_SETBITMAP and changing the height and start-address.

And looking at your code, you also had the idea of using bitmaps with one pixel height,
Just the idea of using CMD_SNAPSHOT2 is less than ideal as the BT817 is interrupted by it.

Generating the lines in the controller is a lot faster, that is a 256 bytes to transfer over SPI.
As primitives, color + point + coordinate are 12 bytes per pixel.
Using RGB565 would still be quicker, if RGB332 is not enough.

[Greg-R]

Step 1, I need to write the bitmap from the controller directly to RAM_G. EVE_cmd_memwrite is commented out in the library.
So I think I can do this, with the assumption of the controller building a bitmap into the array "bitmapArray[256]", as follows:

// First, upload bitmap data to RAM_G. EVE_start_cmd_burst(); // CMD_MEMWRITE 0xFFFF FF1A. Address = 0x00000000 EVE_memWrite32(CMD_MEMWRITE, 0); spi_transmit_32(256); // Number of bytes to be sent. // Transmit bitmap as array. for(uint32_t i = 0; i < 256; i = i + 1) { spi_transmit(bitmapArray[i]); } EVE_end_cmd_burst();

So will this do this basic job of sending data direct from controller to RAM_G?
Next, I am wondering if there extra formatting/size/meta data included in a bitmap. Or do I simply send a byte(s) for each pixel?
I should start with RGB332. The waterfall does not need high color depth.

[RudolphRrr]

Yes, EVE_cmd_memwrite() is commented out since that one would use the command-coprocessor to take bytes from the command-fifo and write them to RAM_G while you also can write to RAM_G directly.

Just use EVE_memWrite_sram_buffer() for your array.
Then you need to make sure that the last transfer is done, do not use the SPI if EVE_busy() does not return zero.

However, EVE_memWrite_sram_buffer() does not work with DMA and there is no function that would, yet, this just did not come up so far.
EVE_start_cmd_burst() is hardcoded to write to the command-fifo thru REG_CMDB_WRITE.

Ok, maybe this is something for which EVE_cmd_memwrite() would make sense.

[Greg-R]

So here is a short video showing progress this morning using your suggested code:

https://drive.google.com/file/d/1a7SO79XDgvJ4t914w0m2ltnm72v4nv5D/view?usp=drive_link

The controller is writing to RAM_G using EVE_memWrite_sram_buffer(). Three writes, and three addresses of RAM_G for red, green, and blue lines. And then the BEGIN(BITMAPS) process for each of the 3 bitmaps at their respective addresses.

I am still getting some problems with consistent re-displays. There is an occasional "miss". I am assuming this is some hardware glitch. The wiring from the Teensy goes to a "break out board" from Crystalfontz, and then through a ribbon cable to the display module. But it seemed to work very solidly with the actual application hardware and the spectral display, which seems to me to be very demanding, and running at a higher SPI clock rate. I have another display module that I need to try.

On to the next level experiment, so far, so good, now that snapshot2 is out of the picture!

[RudolphRiedel]

Well, yes, a chunk of 256 bytes can be a bitmap of 256x1 pixel. :-)

Teensy4, I just remembered something.
First of all, it has an LED with a resistor on either the MOSI or the SCK pin.
And then I had to use series resistors with the Teensy 4, but I just checked, at least the breakout boards I have from Crystalfontz already have series resistors in the lines, 91 Ohm.

Then I prompted this function to convert from the intensity values to bitmap:

uint8_t signalToRGB332(uint8_t signal)
{
    uint8_t r, g, b;

    if (signal < 128)
    {
        // From black to light green
        r = 0; // No red
        g = signal >> 5; // Green from 0 to 7
        b = signal >> 6; // Blue from 0 to 3
    }
    else
    {
        // From light green to red
        r = (signal - 128) >> 5; // Red from 0 to 7
        g = 7 - ((signal - 128) >> 5); // Green from 7 to 0
        b = 0; // No blue
    }

    // RGB332 format: RRR GGG BB
    return (r << 5) | (g << 2) | b;
}

I am a bit sceptic that this really does what I asked for, but it should do something. :-)

Now I kind of want to implement this myself, but I have no data source to use this with.

[Greg-R]

I did something very similar just now, as my application is using 16 bit colors in the signal-to-color array, and I need to convert to 8 bit color for RGB332. The Google AI seems almost miraculous, but the prompt is critical to get a good answer.
I got a completely different answer using "1 byte" versus "8 bits"!

I like your function better, as it will take less memory in the controller than the hard-coded array, and it appears that the function will not use a lot of CPU cycles.

Question: Is it possible to directly use an 8 bit color? For example for a primitive, in this case I want to use a point.
All of the examples use an 24 bit color, as in 0xFF00000 is red. Do I need a translation function, 8 bit color to 24 bit color?
I am failing to find a setting in the programming manual. This is for the initial waterfall line which should be the same color depth as the RGB332 bit maps.

I'm using 8 bit colors into EVE_color_rgb and getting very blue colors, which is not surprising. At least I know something is happening. This is in the application, and I'm ready for the next step which will be a cascade of single line bit maps.

[RudolphRiedel]

Well, yes, there is EVE_PALETTED8, but this uses 32 bits per pixel.

I implemented something, I am using an array of 32 values now and plot half a sine wave with 0...255.

And a new prompt with a couple of corrections resulted in this:

uint8_t signalToRGB332(uint8_t signal)
{
    uint8_t red = 0;
    uint8_t green = 0;
    uint8_t blue = 0;

    if (signal == 0) {
        // schwarz
        red = green = blue = 0;
    }
    else if (signal < 128) {
        // Blau -> Grün
        // signal = 1..127
        uint8_t t = signal;             // 0..127
        blue  = (127 - t) * 3 / 127;    // 3..0
        green = t * 7 / 127;            // 0..7
        red   = 0;
    }
    else {
        // Grün -> Rot
        // signal = 128..255
        uint8_t t = signal - 128;       // 0..127
        green = (127 - t) * 7 / 127;    // 7..0
        red   = t * 7 / 127;            // 0..7
        blue  = 0;
    }

    // rrrgggbb
    return (red << 5) | (green << 2) | blue;
}

The idea now was 0 = black, 255 = red and then blue to green to red.
I convert the array of "samples" to a bitmap and transfer that, takes around 50µs on the STM32F407 I am using right now.

Displaying just the one bitmap with a height of a single pixel proved to be an issue,
I am right now displaying the same image eleven times to really see something. :-)
I am using a 10" with 1280x800 and a BT820, this is just what I had ready-to-run.
And the pixels are to damn small for this.

Nope, that is also not what I asked for.
I am too lazy to actually solve this myself, that is not what I wanted to play this with for. :-)

[RudolphRiedel]

Har, fed the LLM the image and complained what the code did wrong and it delivered.

uint8_t signalToRGB332(uint8_t signal)
{
    uint8_t red = 0;
    uint8_t green = 0;
    uint8_t blue = 0;

    if (signal < 51) {
        // black -> blue
        blue = signal * 3 / 51;
    }
    else if (signal < 102) {
        // blue -> cyan
        uint8_t t = signal - 51;
        blue  = 3;
        green = t * 7 / 51;
    }
    else if (signal < 153) {
        // cyan -> green
        uint8_t t = signal - 102;
        blue  = (51 - t) * 3 / 51;
        green = 7;
    }
    else if (signal < 204) {
        // green -> yellow
        uint8_t t = signal - 153;
        green = 7;
        red   = t * 7 / 51;
    }
    else {
        // yellow -> red
        uint8_t t = signal - 204;
        green = (51 - t) * 7 / 51;
        red   = 7;
    }

    // rrrgggbb
    return (red << 5) | (green << 2) | blue;
}

definately good enough for me. :-)

[RudolphRiedel]

Time to call it a day.

This is running in TFT_display() now.

static uint8_t line_counter=0;

        for(uint8_t counter=0; counter<255; counter++)
        {
        	bitmap[counter] = signalToRGB332(spectrum[counter]);
        }

        EVE_memWrite_sram_buffer((1UL << 20UL) + (256 * line_counter), bitmap, 256);

So first the bitmap is calculated from the (static) data and copied to RAM_G at base-address + 256 * line_counter.

EVE_color_rgb(BLACK);
EVE_begin(EVE_LINE_STRIP);

for(uint8_t counter=0;counter<255;counter++)
{
    EVE_vertex2f(130+counter*1, 300 + (255 - spectrum[counter]));
}
EVE_end();

The current data is written out as curve using a line-strip.

EVE_color_rgb(WHITE);
EVE_begin(EVE_BITMAPS);

EVE_cmd_setbitmap((1UL << 20UL) + (256 * line_counter), EVE_RGB332, 256, 215 - line_counter);
EVE_vertex2f(130, 560);

if(line_counter > 0)
{
    EVE_cmd_setbitmap((1UL << 20UL), EVE_RGB332, 256, line_counter);
    EVE_vertex2f(130, 560 + (215 - line_counter));
}
EVE_end();

And this shows the all the generate bitmaps with a deliberate set of empty lines as two bitmaps.

The black bar wanders from bottom to top and right now I can not wrap around if that is correct.

Anyways, this is still without DMA using EVE_memWrite_sram_buffer() and my STM32F407 that I believe is running at 180MHz needs 333µs for the display-update, including sending 256 bytes over SPI.
The traffic for the display list itself is 1308 bytes and the resulting display list has 2348 bytes,
My update is once every 25ms, so 40/s.
But even at 60/s or every 16.7ms the display update is less than 2% of the runtime.

That is a lot of headroom in all directions and it is not even fully optimized. :-)

[Greg-R]

I have a working prototype!

https://drive.google.com/file/d/1T7JD1Vbks3ooMTX2j8h6LRQV-z5qc_l3/view?usp=sharing

1. Memcopy waterfall line 99 to waterfall line 100 in RAM_G. Copy waterfall line 98 to 99. Repeat up to zero using for-loop.
2. Copy new line from controller to RAM_G at location 0.
3. Use BEGIN(BITMAP) with for-loop to display bitmaps 0 to 100, stepping the vertical coordinate by 1 for each bitmap.

That is all! It's a few lines. I can hardly believe it!
The video looks a little washed out. It looks better viewing the display module with eyeballs.
I haven't added your 8 bit color function yet. It will look much better when that is added.
I'm out of time for today, so I will clean up the code and show it here tomorrow morning.

Thank you for the super-helpful suggestions! The waterfall seems like the biggest hurdle, and now that appears easy. Now to add the static stuff, which (I hope) is even easier.

Greg

[RudolphRiedel]

I went with a different approach and just refined that.
It seems to be working, but I only have one set of data that is plotted.

First, I am now counting down on my line_counter, starting from the top value.
So the first bitmap written is the last one and so on.
The display is done in three steps now.
First: display the current line from address (base + (256 * line_counter)) at the desired position with a height of 1.
Second: if the line_counter is smaller than the max value, display a bitmap from address (base + (256 * (line_counter + 1))) at the desired position + 1 with a height of max - line_counter
Third: if the line_counter is bigger than 0, display a bitmap from address base at the desired position + 1 + step2_count with a height of line_counter

So this only has three EVE_cmd_setbitmap() / EVE_vertex2f() for the whole waterfall display which works as the lines are in one continous block.

When the programm starts, the waterfall starts at the top with the rest black and moves down.
Im displaying 215 lines and reset the counter at 210 to deliberately not fill some lines, this results in a small black bar wandering down.

Ok. go nuts, I just expanded the waterfall to 415 lines.
And the only difference is how much RAM_G is used, the time for a display update remains unchanged.

Here is the tfc.c I am using, it should not be using BT82x specific code, I also just changed the RAM_G address for the bitmaps to use a macro:
tft.zip

[RudolphRiedel]

New version: tft.zip

I prompted a new function spectrum_update() to animate things, calling that in TFT_touch().
I also added two macros for the amount of lines and the top, I am running with 450 lines right now.

No idea what I could use this for, but this was a fun challenge.

And yes, I did not forget about CMD_MEMWRITE. so there will be another boost.

[Greg-R]

My code is less efficient. I am manipulating 100 individual bitmaps, and also moving 100 individual bitmaps using memcopy.

I have replaced the colors array with your LLM generated function and it is working! I do have some concerns that the LLM did not get the integer divisions done correctly. This always causes me confusion, as there are "implicit conversions" in both C and C++. It is working well enough now, and I will come back to it and verify it is assigning the "in between" colors correctly.
I am definitely getting red/green/blue colors, as I can vary the strength of the signal and see the color change:

https://drive.google.com/file/d/10TTnyyPRsuJHtZBqC9ZYtqORiTKkswrx/view?usp=sharing

I have implemented in multiple functions. This is the function which the controller uses to write the waterfall array to RAM_G.
The function EVE_memWrite_sram_buffer() will not use DMA? Note my application's actual width is 512. So 512 bytes to transfer via SPI.

void EVE_Display::writeWaterFalltoRAM_G(uint8_t* waterfall) { // void EVE_memWrite_sram_buffer(const uint32_t ft_address, const uint8_t *const p_data, const uint32_t len) EVE_memWrite_sram_buffer(500000, waterfall, 512); while (EVE_busy()); }

Next, using memcopy to shift the height = 1 bitmaps down by one. This has to be done "bottom up" in order to not overwrite the bitmaps. Based on your comments, I should be able to do this in a single memcopy, without the loop.
Note the variable "waterfallLines" is the number of lines.

`void EVE_Display::moveBitmapCells() {
uint32_t source{0};

for(int32_t i = waterfallLines; i > -1; i = i - 1) { // "Bottom up"
source = 500000 + (512 * i);
EVE_cmd_memcpy((source + 512), source, 512); // Overwrite next bitmap.
while (EVE_busy());
}
}`

Next, adding the individual 1-line bitmaps to the display list:

`void EVE_Display::drawWaterfallLines(uint8_t* waterfall) {

EVE_start_cmd_burst();
EVE_cmd_dl(CMD_DLSTART);
EVE_cmd_dl(DL_CLEAR_COLOR_RGB | 0x000000);
EVE_cmd_dl(DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG);
EVE_vertex_format_burst(0);
EVE_point_size_burst(32);

// Now add all of the waterfall line bitmaps.
for(uint32_t i = 0; i < waterfallLines; i = i + 1) {
EVE_color_rgb_burst(0xffffff);
EVE_cmd_setbitmap(500000 + (i * 512), 4, 512, 1);
EVE_begin(EVE_BITMAPS);
EVE_cell(0);
EVE_vertex2f(0, 290 + i);
EVE_end();
}

EVE_display_burst();
EVE_cmd_swap_burst();
EVE_end_cmd_burst();
while (EVE_busy());
}`

So that is working prototype 1. I will attempt to optimize per your suggestions, and see if I can improve efficiency.

[RudolphRiedel]

Yes, EVE_memWrite_sram_buffer() can not use DMA.
I am working on EVE_cmd_memwrite(), somehow botched something on the first try,

And yes, I also thought of going wider, did not try to though. :-)

[Greg-R]

I made simple changes, combining a couple of functions so there is a single swap (double swap == big mistake),
and now have a single setbitmap instead of the for-loop. I also increased the height to 150, which is just about right.

The main loop() dropped from about 32ms to about 19ms. An excellent improvement, even with the increased number of lines!
The very best I could achieve with the RA8875 was 120ms. So the BT817 is a massive improvement.
This performance is well beyond my expectations. I'm looking at the refresh rate of the spectrum and I just can't believe it.
The great thing is that I can now choose to drop the refresh rate. That is a parameter which was beyond control with the RA8875, because it was never fast enough. I am thinking about the software and it may be greatly simplified and easier to maintain.

There is another smaller spectrum of the audio. A second line strip can be added. The audio spectrum is smaller, about 250 wide. This should work easily based on what I have learned.

Next I am going to have to debug a rotary encoder problem. I suspect a software issue caused by the changes to the display code. Everything was woven together with the RA8875. Now various tasks and functions can be "decoupled". I suspect the encoder problem is tangled up in this and now the delicate balance is broken. I have to make sure this is not a serious problem before proceeding.

[RudolphRiedel]

I am running with a width of 750 right now and a height of 450 for the waterfall.

Without DMA I am getting 924µs for converting one set of values to a bitmap, transferring that to RAM_G and build a display list.
The transfer of the display list takes 2.6ms, 3304 bytes.

With DMA I am getting 387µs, the tranfer after that takes 3.3ms, 4068 bytes.

Oh, right, I could not go beyond 750, the DMA buffer was set to "only" 4100 bytes.
The BT820 has 16kiB of RAM_CMD though.
I am running now with a width of 950, 463µs and 5048 bytes, a display-list of 5152 bytes, this is not possible with the BT817, at least not directly.
With the BT817 this would need two separate transfers to stay within the 4kiB of RAM_CMD.

With 512 x 150 I am at 272µs, 2876 bytes SPI, 3400 bytes display-list.
Edit: 512 x 150 without DMA for the bitmap is 642µs.

Your 19ms seem to be excessive. :-)
And I am not running a 600MHz Teensy 4.

Now that I attached the logic-analyzer, the SPI clock is 10MHz.

tft.zip

Tomorrow I will update the lib with EVE_cmd_memwrite().

[Greg-R]

Those time numbers are for the entire loop(), including the signal processing. The loop() time is a metric I use, as it is easy to compute and make comparisons as I change the code. I get periodic numbers via the serial bus.
I use a 200MHz 4-channel oscilloscope with 14MB deep memory which can decode SPI. I will have a look and see if everything makes sense. I may need to add additional granularity to my timing instrumentation as well.

When you say "The transfer of the display list takes 2.6ms, 3304 bytes", is that a number you are reading back from the EVE device?

[RudolphRiedel]

Ah ok, so not just the display.

I am printing the bytes on the screen, also the size of the resulting display list.
The 2.6ms is from the logic-anaylyzer, just the CS low period.
The "Time1" and "Time" on screen are the runtimes measured with a timer.

[RudolphRiedel]

I just pushed the updated EVE_commands.c / EVE_commands.h both here and for https://github.com/RudolphRiedel/EmbeddedVideoEngine.

[Greg-R]

Repository updated and now using EVE_cmd_memwrite_burst() instead of EVE_memWrite_sram_buffer().
My crude timing comparison shows about 400us less total loop time. This is not a large change, but every processor cycle counts in this application. A good update, thank you!

The rotary encoder problem is fixed, and now on to adding the rest of the prototype display. At first I thought the very different style of programming the BT817 would be more difficult than the RA8875. However, I am starting to think it will be the other way.
I'm going to find out now!