Ddrawing line with partial frame strategy on STM32F0 based on STM32G0 eval board

[PIRRI.1]

I'm using STM32f030cc MCU connected to an SD card and TFT Display 320x240 through SPI interface on a specific board. The SPi1 is used. it's the same configuration as the STM32G081 eval board and the partial frame buffer strategy is based on the STM32G0 software ( partialframebuffer_G0 project example)

The SPI DMA method is implemented on the sotware.

Touchgfx is used to draw on the TFT SPI display. Only 50 line can be drawn on the TFT.

if more are drawn, the software crashed and go into hardfault handler.

Does the touchgfx software contain a limitation to 50 lines ?

Can you explain to me why there is such limitation and how to do for drawing 240 lineson TFT display over touchgfx ?

Thanks for you quick answer

Best regards

Philippe IRRIEN

[MM..1]

Try ManyBlockAllocator<1280, 2, 2> same memory used but buff is rect of two 320 px lines

[PIRRI.1]

I tried with ManyBlockAllocator<1280, 2, 2> but it's the same result.

I also tried ManyBlockAllocator<6x640, 2, 2> but it's the same result.

so it's not the solution for me.

Another Idea ?

[PIRRI.1]

Dear Korry,

yes, change the display task size and ucHeap size has a effect.

I will tried larger task size to complete drawing.

And i hope this will be the solution.

Philippe

[MM..1]

Have you any canvas graphics on screen, when yes have you canvas buffer defined, too how you implement flushrect function?

[PIRRI.1]

What did you means with flushrect function ?

It is flushframebuffer function ?

Normaly, no canvas graphics are present on screen.

[MM..1]

Partial buffer strategy sends rectangles , then i name it , but yes i mean flushframebuffer , but as is explained in last spi part

here is named func ...

if (fba->hasBlockReadyForTransfer())

{

touchgfx::Rect r;

const uint8_t* pixels = fba->getBlockForTransfer(r);

LCDManager_SendFrameBufferBlockWithPosition((uint8_t*)pixels, r.x, r.y, r.width, r.height);

}

Read https://support.touchgfx.com/docs/development/ui-development/scenarios/lowering-memory-usage-with-partial-framebuffer/

[PIRRI.1]

This buffer strategy is implemented in the software.

This is made like this ( is part of 'Lowering Memory Usage with Partial Framebuffer' of touchgfx support ) :

void TouchGFXGeneratedHAL::flushFrameBuffer(const touchgfx::Rect& rect) {

 HAL::lockFrameBuffer(); //SYNC WITH FRAMEWORK. Get pointer to current framebuffer.

 touchgfx::FrameBufferAllocator* fba = HAL::getInstance()->getFrameBufferAllocator();

 HAL::flushFrameBuffer(rect);

 //Try to take a display semaphore - Always free at this point

 //touchgfx::OSWrappers::takeFrameBufferSemaphore(); // always inside HAL::lockFrameBuffer()

 // Once flushFrameBuffer() is called by the framework a block is already for transfer

 // Mark it ready for transfer and transmit it if user defined method isTransmittingData() does not return false

 // If data is not being transmitted, transfer the data with user defined method transmitFrameBufferBlock().

 fba->markBlockReadyForTransfer();

 if ( !TFT_ManagerIsTransmittingData() ) {

   touchgfx::Rect r;

   const uint8_t* pixels = frameBufferAllocator->getBlockForTransfer(r);

   TFT_ManagerTransmitFrameBufferBlock((uint8_t*)pixels, r.x, r.y, r.width, r.height);

 }

 //Unlock TouchGFX framebuffer and give semaphore back - Flushframebuffer() is now a part of RENDER_TIME.

 HAL::unlockFrameBuffer();

 touchgfx::OSWrappers::giveFrameBufferSemaphore();

}

I don't understand why only 150 lines can be drawing on screeen ?

The ucHeap size cannot be increase as big than 32K in RAM ( only 32K of RAM in STM32F0 ).

I also had another request :

1 ) Does relationship exists between caching bitmap and Frame buffer Allocator ?

2 ) If Bitmap are cahing, normally these bitmap must be copied to frame allocator ? in my case is not the case. Why ?

Thanks for you reply

Philippe

[MM..1]

I agree this info page and example code is little chaos. Why is marked block for transfer and then if manager transfer can be skipped.

Why is in if local touchgfx::Rect r; that isnt assigned ... CHAOS.

I mean this example need some modification to work properly. As first you need high speed

TFT_ManagerTransmitFrameBufferBlock((uint8_t*)pixels, r.x, r.y, r.width, r.height);

When this function isnt quick, your stack is overloaded with waited rect object to transmit...

Maybe anybody ST help you.

[PIRRI.1]

Dear Korry,

The ucHeap size cannot be increase as big than 32K in RAM ( only 32K of RAM in STM32F0 ) and a part of this RAM is used .

In fact, the ucHeap size is 17K.

I always cannot draw more than 150 lines on the screen.

Have you really tested the touchgfx on the STM32G0 eval board ? can you provide me the STM32G0 project example to adapt on my STM32F0 platform ?

I also had another request :

1 ) Does relationship exists between caching bitmap and Frame buffer Allocator ?

2 ) If Bitmap are caching, normally these bitmap must be copied to frame allocator ? in my case is not the case. Why ?

Thanks for you reply

Philippe

[Alexandre RENOUX]

There's no relationship between caching bitmap and framebuffer allocator except that both are related to RAM.

Framebuffer Allocator is dedicated to the framebuffer (as the name states) and more specifically corresponds to the partial framebuffer in itself (how many blocks ? What size per block?)

To cache bitmaps you need to allocate a different piece of RAM.

I reckon that having only a small internal RAM and trying to cache bitmaps as well as having a partial framebuffer could be too much.

/Alexandre