This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Epson s1d13781 graphics controller with LM4f230 - Slow screen draw issue

We have implemented a 4.3'' display with a Epson s1d13781 graphics controller. The epson chip is connected to the LM4F controller via SPI. We have built this board with the reference of Epson Booster pack for s1d13781.

When we use the GRLIb calls to change the screen contents ( ex: GrRectDraw, GrRectFill etc) we observe a re-paint of the screen. It looks like the grlib calls are writing to the graphics controller ram, slower that the rate at which the graphics controller refreshes the page.

We are already at max allowed SPI clocking at 25 MHz. Is there any way to avoid this painting of new screen and to have the screen change instantly?

Can the GRLIB calls be configured to do double buffering on the Graphics controller RAM so as to avoid this Paint situation?

It will be of great help if we can get more literature and sample code in using graphics library on LM4F.

  • Bharath Atreya said:
    looks like the grlib calls are writing to the graphics controller ram, slower that the rate at which the graphics controller refreshes the page

    And - this is totally normal/expected.

    That graphic controller is "task centric" - far better able (i.e. faster) to pull data from its memory than most any - general purpose MCU.  And - on the flip side - far less capable in any "non-memory" task - than most any MCU.

    As your SPI effort has not met expectations - have you "run the numbers" - and determined if a movement from SPI to parallel (8 or 16 bit) may warrant consideration? 

    Before surrendering SPI - insure that there are no unjustified transfer "hangs" - which impede the delivery of data.

    Be shocked to learn that Epson uses, "booster pack" in their board description...