cancel
Showing results for 
Search instead for 
Did you mean: 

About the Tx_CMSIS_Wrapper example

SMacl.1
Associate II

I am new to STM32, been looking at it just a week, have an L4R9 Disco board. I am familiar with the CMSIS RTOS2 api, and have used RTX previously. Was interested to see the Tx_CMSIS_Wrapper example, as it shows how an RTOS2 facade is added to Azure RTOS ThreadX.

What I don't get is the apparent need for a Mutex/Semaphore in the example. The two threads are toggling separate LEDs, and share no data (ram nor peripheral registers). Yes, they do both call printf, 3 times, but ironically 2 of the 3 calls aren't in the critical region anyway.

Am I missing something here, or is there a fundamental misunderstanding of concurrent programming on the part of that code's author? The README within the project states that (paraphrasing) "because both threads call Led_Toggle, this is considered a critical region... ". Shared DATA needs sequential access, but two threads that happen to be sharing CODE does not.

2 REPLIES 2
Piranha
Chief II

https://github.com/STMicroelectronics/x-cube-azrtos-l4/blob/main/Projects/STM32L4R9I-Discovery/Applications/ThreadX/Tx_CMSIS_Wrapper/Src/app_tx_cmsisrtos.c

That is an example of how to use the API, not how to blink LEDs. Ironically the printf() calls should be mutually exclusive, but are not... And at least for Newlib runtime library most likely it's broken anyway:

https://community.st.com/s/question/0D53W00001KRfkeSAD/is-stm32cubeide-newlib-with-freertos-now-really-thread-safe

SMacl.1
Associate II

Yes, but doesn't the code as written lead an RTOS newbie into believing "I have two threads that syntactically call the same function, I must therefore need a mutex" ? Maybe I am overthinking it.