Steps to Storing in Memory

Get started
1

Description

What MCU/Processor/Board and compiler are you using?

MicroBlaze on Xilinx Vitis

What do you want to achieve?

I would like to rather than have LVGL write directly to the screen, have a frame buffer be saved into memory to be accessed by hardware then displayed. In this case is the display driver necessary? Is there example code that does this?

2

I do not have any experience with the MicroBlaze.
As far as I understand it’s a controller (library) which can be run on a FPGA!?

You also didn’t write what your LCD would be (width, height, color), a ‘smart’ or a ‘dump’ display.

From your question it seems to me, you want to use a ‘dump’ display, which means directly connected to the controller.
For the the STM controllers (STM32F4/7 and -H7) this is possible as these controllers have special hardware build in. When using these controllers with direct LCD driving you need also appropriate memory as frame buffer. When using smaller resolutions and color depth (320 x 240 x 16-bit = 153600), this might fit into the controllers internal SRAM. For larger resolutions you need an external (mostly SDRAM) RAM.
Does the MicroBlaze allow direct driving of a dot matrix LCD? I did not find any information about this.

The most easy way is using a ‘smart’ display which has it’s own display driver and frame buffer.
These kind of displays can be either filled via SPI transfer or via 8-bit or 16-bit parallel IO/memory transfer.
Independent of what you use, you just have to write a flush_cb function which transfers the content of the lvgl’s working buffer to the real frame buffer (controller internal or extern on display)

3

Microblaze is the CPU for the FPGA.
The display I’m using is 1280 x 1024 using ARGB8888.
Is the flush_cb function necessary if I am just using hardware to copy the contents of the buffer to the display?

4

The flush_cb will always be necessary.
lvgl calls the flush_cb if lvgl has finished the drawing within the working buffer.
It’s a trigger for software (or hardware) to transfer the content of lvgl’s working buffer into the real frame buffer (whereever the framebuffer is located; internal or external).
Even though lvgl is setup for using full frame double buffering, which means you would need 1280 * 1024 * 4 * 2 = 10.485.760 Bytes internal RAM. In this case the display controller would need the flush_cb to know when to switch between the two frame buffers.

5

For my purpose, I don’t want to use flush_cb as it needs OLED drivers. I just want to take the drawing within the working buffer and copy it to memory. No need to display it yet. How can I go about that?

6

You will still need to use flush_cb even if you are copying to memory, as that is the callback where you normally interact with the working buffer. Here is an example:

void my_flush_cb(lv_disp_drv_t * disp_drv, const lv_area_t * area, lv_color_t * color_p)
{
    /*The most simple case (but also the slowest) to put all pixels to the screen one-by-one*/
    int32_t x, y;
    for(y = area->y1; y <= area->y2; y++) {
        for(x = area->x1; x <= area->x2; x++) {
            /* embeddedt: put the pixel where you want in memory */
            put_px(x, y, *color_p);
            color_p++;
        }
    }

    /* IMPORTANT!!!
     * Inform the graphics library that you are ready with the flushing*/
    lv_disp_flush_ready(disp_drv);
}
7

Does this mean display drivers are absolutely necessary to communicate with LVGL?

8

The implementation of flush_cb is left to the user; LVGL does not handle communication with the display itself.