Bug Report - Designer code missing #include (4.10.0)

[brianshankland9]

When I added interactions to my container the compiler failed stating it did not know what an AbstractButton was.

When I manually added a #include for "touchgfx/widgets/buttons.hpp" using Visual Studio the fault was fixed.

It is a small project so I can zip it up and email if you tell me who to.

[brianshankland9]

I assume by the lack of reply from anyone at ST that they don't care their product can not even do the simplest of GUI tasks as have a button in a container of grouped widgets and allow it to be clicked!

Tried a new project just to be sure and yes as soon as you put a click interaction on a flexbutton that is in a container, the designer generated code that will not compile until you manually add

#include <touchgfx/widgets/Button.hpp> to the gui_generated base class for the container.

Since every time you amend the project this is rewritten you have to fix this every time you want to run your code.

Big fault to have let through to release so when is it going to be fixed?

[Martin KJELDSEN]

Hi @brianshankland9​,

I'm the only one monitoring this TouchGFX community and i've been traveling (Embedded World). Sorry you had to wait so long. Which version of TouchGFX are you using?

[Martin KJELDSEN]

I've verified that this is an issue in 4.10.0 and i'll pass it on to the Designer Team. Thanks for reporting it! There's a possibility that this has already been fixed in 4.11.0 which will be out soon (it's done - I will test this)

And yes, the files in gui_generated will get overwritten ever time the designer generates new code.

I apologize for the inconvenience!

Thanks!

Best regards,

Martin

[Martin KJELDSEN]

This is not a problem in version 4.11.0 so we've already fixed it - Release is pending CubeMX / Cube Firmware release dates. Will keep this community updated on the release of course.

(Other things in 4.11.0 - 8-bit, Thai support, Dynamic Fonts and Translations, ...)

[brianshankland9]

Hello Martin, Thanks for the feedback, I look forward to the V4.11 release. I apologise for my tone, I thought there would have been a larger team on this at ST since it will effectively let you corner the MCU display app market, but now understand your situation. I saw that there were trade shows on this recently (but too late to attend). We are heavily involved with Keil’s MDK for our product development which requires the use of their CMSIS-RTOS wrapper for their middleware. I saw that your projects provide an OSWrapper for cmsis but have struggled to get this to work with either their RTX or FreeRTOS library (the letter I think is a problem with their latest V10.0.1 since it crashes their own blinky examples). The RTX “works�? in that I see that framebuffers are being refreshed (disco leds) but the screen is corrupted (looks like its is zoomed in 4x and repeated) I don’t have this issue with the RTX threads is I use your NoRTOS OSWrapper example. Not sure if this is an timing issue with the semephores/queues in RTX or not. I was wondering if it is safe to use the NoRTOS OSSwappers if I’m not planning to access the frame buffer from any other thread than your GUI thread, and simply use the CMSIS-RTOS to create you a separate thread to run? Can start a new discussion thread if you think that best. regards _________________________________________________­_ Brian Shankland Icon Research Ltd 3 Raw Holdings | East Calder | West Lothian | EH53 0HY | UK T: +44 1506 885000 Ext 226 F: +44 1506 885501 www.iconresearch.co.uk<>

[Martin KJELDSEN]

Hi @brianshankland9​,

I appreciate that. TouchGFX is a relatively small team, so there's just me (for now!) to keep track of the community. I monitor it daily and this past week with no activity on my side is an exception, i promise you that.

I'd be interested in diving deeper into why the OSWrapper_cmsis.cpp doesn't work with RTX. I'll try to follow up on that and see if i can get a hold of RTX here.

Generally I don't advisertise using the NO RTOS Wrapper, even if you're just accessing the framebuffer from the gui task. There are multiple acessors of the framebuffer (CPU, LTDC, DMA) and as such it must be protected. You will have a lot of timing issues and not a lot of time to do real work if you don't use an RTOS. So i think we should just get the OSWrapper/RTX working properly.

Can you share your setup? Using CubeMX, etc?

Thanks!

[brianshankland9]

Certainly, It’s basically the same project I sent you, just altered the screen to something that did not use the spinner control. I’ll built it up using the RTX model and get a photo of the output that I’m seeing as its tricky to explain in words. I see that the oswrapper provided by the designer is V1 of the CMSIS RTOS so I had upgraded it to the V2 definitions. I also tried to replace the VSync Queue with a simpler semaphore (not suire why a dummy queue was needed) and the results are the same. Will do this today. regards _________________________________________________­_ Brian Shankland Icon Research Ltd 3 Raw Holdings | East Calder | West Lothian | EH53 0HY | UK T: +44 1506 885000 Ext 226 F: +44 1506 885501 www.iconresearch.co.uk<>