Hi Sami. Thank you for your response. I can understand why ST is taking this approach. I suspected it before I knew. I can see the effort that has been put into TouchGFX and understand why you would not want to demote it. I have (only) played with GUIX and can see at this stage it has issues, so it isn't perfect. However, given your adoption of Azure RTOS (and the marketing literature talks about its complete integration, which is a little misleading) it seems a shame not to offer support for using it in its entirety. Its functionality and integration with the other Azure components will only improve. Its basic 'code in C' approach and integration into a project seems, on the face of it, somewhat simpler. Will ST be doing the same with TouchGFX? I'm not an expert with TouchGFX and STMCube by any stretch of the imagination, so maybe I'm not representative of the users out there, but I find the lack of integration of TouchGFX, CubeMX, the IDE, and the need to rebuild this after changing that and the copying of files from here to there and the cutting and pasting all a bit tortuous. Maybe some of this is down to a lack of understanding by me, but while I have tried to follow the tutorials and videos to get a better understanding, you have to do a lot of digging if you weren't on board at the beginning to find out that this processor isn't supported yet or that something used to be done the way in the video you're watching, but that's actually changed now in the release you've just downloaded. Maybe it's just me, but it seems, at least at the moment, to be harder than it should be. I guess if it wasn't changing and improving rapidly, I'd be moaning about that instead 😉. I'm sure Azure RTOS is also not an answer to everything, but if there was a graphics driver layer available from ST it would at least be a choice for STM32 users to embrace it in its entirety if they wanted to.
