2020-02-02 08:09 AM
I am using STM32CubeMX with FreeRTOS/ CMSIS_RTOS_V2. However I think I have not understood the logic behind the creation of the files.
I need to call osSemaphoreRelease(semaphoreId) inside one of those ISR callbacks but because CubeMX created the semaphore inside "app_freertos.c", I just can't access it. It seems the semaphore scope is limited to "app_freertos.c". The problem is I have a lot going on inside my files (busA.c), bunch of variables etc. I am %90 sure if I try to move everything inside "app_freertos.c", it will be a mess.
Shall I create a header file manually for "app_freertos.c", namely "app_freertos.h" and return semaphore address into my "busA.c" file (with a function)?
2020-02-02 10:39 AM
I would add a header file and simply declare the semaphores like
extern osSemaphoreId_t semaphoreId;
2020-02-02 10:40 AM
Either export higher level ISR to a global scope and call it from "***_it.c" file or put "IRQHandler" in a file with the semaphore.
2020-02-02 10:58 AM
cubeMX will probably create a new semaphore at the same place each time I generate code, and won't that extern limit encapsulation?
2020-02-02 11:08 AM
The real limiting factor is CubeMX - it limits sanity and stability of firmware to a level of non-working bloatware.
2020-02-02 12:17 PM
If you don't change the name or config of that semaphore, CubeMX will re-generate exactly the same definition text again, no problem.
> limit encapsulation.
In an embedded project, ressources like semaphores are often all created in the beginning to avoid memory issues. The generated code will setup semaphores before tasks are created and started, so there is little room for abusing the external declaration. And, a semaphore is a shared ressource by definition, so I would not worry about limited encapsulation. The osSemaphoreId_t is a void*. Even if you implement a "getter" function for it, that function would return ... that very same pointer.