cancel
Showing results for 
Search instead for 
Did you mean: 

How to use cubeMX created semaphores inside another source file? CubeMX creates semaphores inside app_freertos.c but they are not accessible from custom source files??

aotuz
Associate

I am using STM32CubeMX with FreeRTOS/ CMSIS_RTOS_V2. However I think I have not understood the logic behind the creation of the files.

  • CubeMX created a file "app_freertos.c" without a header file and the semaphore created is inside this file.
  • I have two other files "busA.h" and "busA.c" where I use a couple of Timer ISRs with STM Low Layer APIs. "busA.h" is included inside "stm32g0xx_it.c".

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)?

5 REPLIES 5
KnarfB
Principal III

I would add a header file and simply declare the semaphores like

extern osSemaphoreId_t semaphoreId;

Piranha
Chief II

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.

cubeMX will probably create a new semaphore at the same place each time I generate code, and won't that extern limit encapsulation?

The real limiting factor is CubeMX - it limits sanity and stability of firmware to a level of non-working bloatware.

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.