2.8'' ILI9341 SPI LCD and XPT2046 Touch Controller

[ALomb]

I'm trying to integrate the display in question with TGX 4.13. This is the LCD module.

I developed the drivers for both display and touch, configured the project and trying to follow what is reported in the documentation at this link (spi scenarios for ST7789H2).

I have an error during compilation which is as follows:

../TouchGFX/target/TouchGFXHAL.cpp:91:8: error: 'class TouchGFXHAL' has no member named 'copyFrameBufferBlockToLCD'; did you mean 'setFrameBufferAllocator'?

How to solve?

[PKriv.1]

Hello @Community member​ , nice work you've done! I've studied your project long and wide, and tried to implement it on my custom board.

Since I want to learn, I decided to use your example and go with your libraries.

I am using an STM32F411RE, that has significantly less RAM - 128KB and is not able to carry a full framebuffer. For that reason, I decided to make my screen only half the size, that is 160x240 framebuffer. I only needed to modify GUI_WIDTH to 160 in ili9341.h I made the sample in the TouchGFX Designer, it worked just fine, and the program builds.

However, the image I get is for some reasone offset, and the items on it (a simple circle button) is duplicated. Do you see a reason why that might happen? I.e. is there something in your code that might not work with modified screen resolution?

Best regards,

Pero

[PKriv.1]

>>if I don't, the flushFrameBuffer is never called!

@Martin KJELDSEN​ could you please address this issue? I have the same problem, the flushFrameBuffer is not called if the lockDMAToFrontPorch(true); is called in initializaiton. Only when it's set to false, I do get an image, like the @Community member​ .

[Martin KJELDSEN]

Refresh me on your setup. When you "lockDMAToFrontPorch(true)" you're basically telling the DMA2D to wait until the front porch has been reached. But front porch does not make sense in an scenario where your display has GRAM.

lockDMAToFrontPorch() is used with something like a TFT controller where you can get a line interrupt when the front porch is hit.

[Martin KJELDSEN]

So, keep it false for setups that have no TFT controller.

[PKriv.1]

Thanks for the answer, Martin.

My setup is a simple STM32F411RE Nucleo board with SPI interface to ILI9341 based TFTLCD.

I am not sure what DMA2D is, but I am using DMA to transfer the framebuffer into the GRAM on ILI9341. I also must admit that I dont understand concept of "front porch". I havent found it in the Getting Started part of documentation. So, what I can conclude from your answer is that, since my LCD has the GRAM, the front porch is irrelevant, and I should keep the lockDMAToFrontPorch(false) during the initialization. Right?

[Martin KJELDSEN]

Okay, if you're using DMA to transfer to the display you MUST wait on a semaphore inside flushFrameBuffer() so that the function does not return before you've transferred the data to the display. Release the semaphore in your DMA completed interrupt. Otherwise TouchGFX will continue with next frame and call flush() again immediately.

/Martin

[PKriv.1]

Hello Martin, thanks for the explanation! I need to let you know that I don't use any RTOS in this project, therefore, no semaphores either. However, I make sure that no program is executed before the DMA transfer is done simply by invoking an endless loop after the DMA transfer starts. Then, the in the callback upon the DMA transfer completion, the loop is broken and the program continues. It's not perfect, but it somewhat resembles the semaphore, in a way that it doesn't flush() immediately.

But in any case, I should keep the lockDMAToFrontPorch(false), right?

[Martin KJELDSEN]

keep it false. You don't have DMA2D on your micro, so the lock does not make any sense - Having it true may be interfering because you cannot signal to TouchGFX that you've reached the front porch.

/Martin

[LVers.1]

Hi Martin,

I'm at the same stage as @PKriv.1​ meaning i succesfully have touchgfx working with an spi lcd. For the moment i'm using a single frame buffer, but i may switch to partial frame buffer later to reduce the ram consumption.

I'm now in the process to move to using DMA for the transfer, but i'm wondering if there will be any real gain of doing so if, in the end, we have to wait for (ie loop until) the transfer is complete.

Of course using a RTOS would probably improve the performance as other tasks could be activated while waiting for the dma transfer to finish.

Is it not possible to immediately return to touchgfx main loop and only block when touchgfx would attempt a next frame transfer ? By doing so i expect that touchgfx could already do proceed some things before needing to actually proceed with a new transfer to the lcd.

Thanks for any advice on this,

Laurent

[Martin KJELDSEN]

Hi Laurent,

If the transfer is small, then maybe there is no gain. You could create some guard that only uses DMA to transfer IF the amount of data is substantial (e.g. half a screen or full screen).

What i usually do is to introduce an additional semaphore that is taken by flushFrameBuffer() which is released by the DMA completed interrupt (In the case of DMA being used to transfer).

Hope this helps

/Martin