search

STMicroelectronics / STM32CubeF4

STM32Cube MCU Full Package for the STM32F4 series - (HAL + LL Drivers, CMSIS Core, CMSIS Device, MW libraries plus a set of Projects running on all boards provided by ST (Nucleo, Evaluation and Discovery Kits))
Other
871 stars 418 forks source link

cmsis_os2.c -> osThreadDetach function missing #170

Closed zacilaci closed 4 months ago

zacilaci commented 6 months ago

Hi!

I am using the LVGL Library with the lvgl config LV_OS_CMSIS_RTOS2. I set up the middleware as cmsis_freertos2 also appropriately. When I build the project I receive an error as: lvgl/src/osal/lv_cmsis_rtos2.c:74: undefined reference to `osThreadDetach'

This generally means that the function prototype exists in the cmsis_os2.h but not in cmsis_os2.c.

It seems like the function definition is missing through other boards as well.

Please fix this issue.

Best regards, zacilaci

ALABSTM commented 4 months ago

Hi @zacilaci,

Please excuse this delayed reply. Looks like you're right. The same applies also for osThreadJoin(). I will get back to you after further investigation.

Please note however, that all FreeRTOS applications provided within the STM32CubeF4 firmware are CMSIS OS V1-based.

With regards,

ALABSTM commented 4 months ago

Hi @zacilaci,

Back to you with an answer. Actually, it is up to the user to implement osThreadDetach() in case they want to use it in their applications.

As you may know, the CMSIS-RTOS interface is provided by Arm for Cortex-M processor-based devices. It provides a set of APIs, the actual implementation of which is RTOS-specific.

Regarding osThreadExit(), it implements a common and typical operation that most RTOSes need, including FreeRTOS. This is why you can find a basic implementation in cmsis_os2.c as you can see below.

https://github.com/STMicroelectronics/STM32CubeF4/blob/db5ddbf1104882699129a6be85c8a30f4e7a10ad/Middlewares/Third_Party/FreeRTOS/Source/CMSIS_RTOS_V2/cmsis_os2.c#L650-L655

On the other hand, APs like osThreadDetach() or osThreadJoin() might not be needed by FreeRTOS. Hence, the choice not to implement them and to let the user do it in case they need them in their applications.

I hope this makes things clearer. Please allow me to close this issue. Thank you for your comprehension and thank you again for having reported this point.

With regards,