2021-01-08 01:33 PM
Hello
First of all, thanks for developing such a powerful tool and delivering us such a content rich documentation.
I am playing with the partial framebuffer strategy, and I notice that, when the code is generated by the CubeMX, in the files TouchGFXHAL.cpp is a comment that user should implement some functions.
"A user must implement C-methods touchgfxDisplayDriverTransmitActive() and touchgfxDisplayDriverTransmitBlock() used by the Partial Framebuffer Strategy."
Later in the code, in the file TouchGFXGeneratedHAL.cpp, when these functions are supposed to be actually called, I see they re named without touchgfx part, just DisplayDriverTransmitBlock.
Then in the tutorial on partial framebuffer scenarios, these functions have completely different names: LCDManager_IsTransmittingData and LCDManager_SendFrameBufferBlockWithPosition.
So, having three names in tutorial, would bring quite confusion for someone who, like me, is trying to make the custom project work, imho.
2021-01-10 07:41 PM
Hello PKriv.1,
Just to be on the same page here is the explanation for touchgfxDisplayDriverTransmitActive() and touchgfxDisplayDriverTransmitBlock() taken from the comment in TouchGFXGeneratedHAL.cpp :
int touchgfxDisplayDriverTransmitActive() must return whether or not data is currently being transmitted, over e.g. SPI. void touchgfxDisplayDriverTransmitBlock(const uint8_t* pixels, uint16_t x, uint16_t y, uint16_t w, uint16_t h) will be called when the framework wants to send a block. The user must then transfer the data represented by the arguments.
Therefore from the above explanation, we understand relatively easily that :
LCDManager_IsTransmittingData = touchgfxDisplayDriverTransmitActive
LCDManager_SendFrameBufferBlockWithPosition = touchgfxDisplayDriverTransmitBlock
The touchgfx part is not added because the functions are implemented inside a namespace touchgfx {} encapsulation.
Sorry for the misunderstanding, I'll discuss with the team the possibility of modifying the article.
/Alexandre
2021-01-10 11:55 PM
yeah, I extrapolated that way, after all. It just took some extra time to unterstand the code. Thanks for explanation!
Another thing: at the beginning of TouchGFXGeneratedHAL.cpp two functions are defined as extern: touchgfxDisplayDriverTransmitActive and touchgfxDisplayDriverTransmitBlock. But, inside the functions flushFrameBuffer and startNewTransfer the function touchgfxDisplayDriverTransmitBlock is called as DisplayDriverTransmitBlock, without the "touchgfx" part. It needs to be edited by the user, otherwise the code won't build. And if the code is re-generated from the CubeMX, it's back to the initial version (DisplayDriverTransmitBlock). You might wanna fix that in CubeMX.
Best regards,
Pero
2021-01-11 12:24 AM
Hello PKriv.1,
It's normal that if you try to build it does not compile correctly. Because the user needs to implement these functions in his own user code (usually the driver) before.
It's not a bug, it is on purpose. Please have a look at the G0-Nucleo Application Template available in TouchGFX Designer for reference.
/Alexandre
2021-01-11 01:40 AM
Sorry, I might have explained it in not a clear way - it's not about implementation, it's about simple name generator. CubeMX writes one thing at the top of the file:
extern "C" void touchgfxDisplayDriverTransmitBlock(const uint8_t* pixels, uint16_t x, uint16_t y, uint16_t w, uint16_t h);
but calls other thing in the flushFrameBuffer (line 14):
void TouchGFXGeneratedHAL::flushFrameBuffer(const touchgfx::Rect& rect)
{
HAL::flushFrameBuffer(rect);
// 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().
frameBufferAllocator->markBlockReadyForTransfer();
if (!touchgfxDisplayDriverTransmitActive())
{
touchgfx::Rect r;
// Get pointer to block buffer and coordinates of the rect
const uint8_t* pixels = frameBufferAllocator->getBlockForTransfer(r);
// Start transmission of the block
DisplayDriverTransmitBlock((uint8_t*)pixels, r.x, r.y, r.width, r.height);
}
}
And it happens everytime the code is regenerated. And i need to go there and change the call every time.
2021-01-11 05:53 PM
What version of CubeMX and TouchGFX are you using ?
Because I tried on both CubeMX 6.0.1/TouchGFX 4.15 and CubeMX 6.1.1/TouchGFX 4.16 and the content of flushFramebuffer() is different from what you have.
void TouchGFXGeneratedHAL::flushFrameBuffer(const touchgfx::Rect& rect)
{
HAL::flushFrameBuffer(rect);
// Try transmitting a block
PartialFrameBufferManager::tryTransmitBlock();
}
Please try one of this two combinations and see if you still have the same content in the function. I recommend staying with TouchGFX 4.15 and CubeMX 6.0.1 since I'm confident that with this one you should not have any problem.
/Alexandre
2021-01-12 07:49 AM
Thanks for explanation. I've just check that my CubeMX Version is 6.1.1-RC2 and TouchGFX is 4.15, ugh.
Well this is funny, because on your documentation https://support.touchgfx.com/docs/development/scenarios/lowering-memory-usage-with-partial-framebuffer#transferring-frame-buffers-on-spi-display, the function flushFrameBuffer() has the same content like I do :)