Azure RTOS - Will there be full support (i.e. GUIX)?

[NTipp.1]

I notice that ST has announced it's roll out of licenses for Azure RTOS on specific STM32 devices during 2021:

https://www.st.com/content/ccc/resource/sales_and_marketing/presentation/product_presentation/group1/5b/4f/89/bf/8f/18/4e/83/Microcontrollers_STM32Cube_AzureRTOS/files/Microcontrollers_STM32Cube_AzureRTOS.pdf/jcr:content/translations/en.Microcontrollers_STM32Cube_AzureRTOS.pdf

The limited documentation so far makes reference to ThreadX, FileX, NetX/NetX Duo and USBX. The only component not mentioned is GUIX. So my question is:

Will there be graphics driver support from ST for GUIX?

I know there is TouchGFX, but it would be a pity not to support the entire Azure infrastructure.

[NTipp.1]

Well, I've just sat through the Azure RTOS presentation today and as I expected, the news is disappointing. GUIX is licensed, but there will be no support from ST on using it because of TouchGFX and how 'well' that is integrated. If you want to use it, you're essentially on your own. Having tried and persevered with TouchGFX and its 'integration' with CubeIDE, and quickly looked at GUIX and it's builder, I'm not sure that decision has been made in the best interests of the customer. It's a shame, and I think one that ST might come to regret. It's certainly making me think twice.

[Sami GUIZANI]

Dear NTipp.1, thank you for your comments. We are of course focusing on customer interests. We work on offering advanced STM32 graphic MCUs portfolio, as well as large software ecosystem around it. We are investing in our own graphic software solution TouchGFX but also on strategic partnerships to make sure customers have large graphic software options taking the full advantage of our STM32 hardware accelerations. Of course, support priority is given to our internal TouchGFX solution on which we have the needed full roadmap control to implement the features and upgrades our customers are requiring. We understand you are experiencing issues with cubeIDE integration; we are sorry for that. Our answer will be to work on solving these integration issues.

[NTipp.1]

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.

[NTipp.1]

Oh, and by the way, to put this into context, I think it's absolutely amazing that ALL of this is being made available absolutely free of charge. Any feedback like mine above is only made because I'd like to see it improve and become more and more successful. We all benefit from that!

[CIsel.1]

For what it's worth, I have gotten guix to work on the STM32 H747I discovery board and I put the code on github here : https://github.com/c4chris/H747-Test

The handling of the touch interface is not yet done.

Kind regards,

Christian

[SLimi.1]

@CIsel.1 I am trying to follow your example. How did you get GUIX and the app to fit into the internal flash memory?

[CIsel.1]

Hi @SLimi.1  ,

I defined the linker parameters in the files CM4\STM32H747XIHX_FLASH.ld and CM7\STM32H747XIHX_FLASH.ld

I do not remember having problems to fit the data and code in memory

Kind regards,

Christian

[NTipp.1]

Wow! That's impressive! Thanks for sharing, Cisel.1.

[CIsel.1]

Hello,

I now have also another example with H747 using HDMI interface and USB touchscreen (using usbx), also on github here https://github.com/c4chris/H747-WeighingStation - look at tag 0.3.1 (later modifications start using additional hardware linked to the board, but 0.3.1 is just the board + HDMI + touchscreen)

[SLimi.1]

@CIsel.1 I have had no success rebuilding your project.

[CIsel.1]

Any specific error message you could share ?

[SLimi.1]

something with the stm32h747i_discovery_lcd.h file. I am not going to worry about this too much.

[SLimi.1]

@CIsel.1 

I cannot figure out why the code is crashing at clearing the memory area in gx_canvas_create.c. The buffer is pointing to the correct SRAM address, but the code faults on the memory clear as if there it was the wrong memory address.

[CIsel.1]

I see your init code of the SDRAM (lines starting with + below) is quite different from mine (lines starting with -), are you convinced your parameters are ok ?

 

/* hsdram1.Init */
hsdram1.Init.SDBank = FMC_SDRAM_BANK2;
- hsdram1.Init.ColumnBitsNumber = FMC_SDRAM_COLUMN_BITS_NUM_9;
- hsdram1.Init.RowBitsNumber = FMC_SDRAM_ROW_BITS_NUM_12;
+ hsdram1.Init.ColumnBitsNumber = FMC_SDRAM_COLUMN_BITS_NUM_8;
+ hsdram1.Init.RowBitsNumber = FMC_SDRAM_ROW_BITS_NUM_13;
hsdram1.Init.MemoryDataWidth = FMC_SDRAM_MEM_BUS_WIDTH_32;
hsdram1.Init.InternalBankNumber = FMC_SDRAM_INTERN_BANKS_NUM_4;
- hsdram1.Init.CASLatency = FMC_SDRAM_CAS_LATENCY_3;
+ hsdram1.Init.CASLatency = FMC_SDRAM_CAS_LATENCY_1;
hsdram1.Init.WriteProtection = FMC_SDRAM_WRITE_PROTECTION_DISABLE;
- hsdram1.Init.SDClockPeriod = FMC_SDRAM_CLOCK_PERIOD_2;
- hsdram1.Init.ReadBurst = FMC_SDRAM_RBURST_ENABLE;
+ hsdram1.Init.SDClockPeriod = FMC_SDRAM_CLOCK_DISABLE;
+ hsdram1.Init.ReadBurst = FMC_SDRAM_RBURST_DISABLE;
hsdram1.Init.ReadPipeDelay = FMC_SDRAM_RPIPE_DELAY_0;
/* SdramTiming */
- SdramTiming.LoadToActiveDelay = 2;
- SdramTiming.ExitSelfRefreshDelay = 7;
- SdramTiming.SelfRefreshTime = 4;
- SdramTiming.RowCycleDelay = 7;
- SdramTiming.WriteRecoveryTime = 3;
- SdramTiming.RPDelay = 2;
- SdramTiming.RCDDelay = 2;
+ SdramTiming.LoadToActiveDelay = 16;
+ SdramTiming.ExitSelfRefreshDelay = 16;
+ SdramTiming.SelfRefreshTime = 16;
+ SdramTiming.RowCycleDelay = 16;
+ SdramTiming.WriteRecoveryTime = 16;
+ SdramTiming.RPDelay = 16;
+ SdramTiming.RCDDelay = 16;

[SLimi.1]

@CIsel.1 

I thought I made those changes, but the failure remains even after setting them correctly. TouchGFX is working so I am going to move on at this point. Thanks.