undefined symbol ossemaphorecreate

[Zaher]

Why the API for FreeRTOS middleware keeps changing every now and then? You barely start to wrap your head around an API, a new one gets released.

I had to generate the initialization code from CubeMX, as it makes life much easier especially if you want to add new components or modify a lot of GPIOs for a given project.

Many of my projects were built with CMSIS_V1, but I don't know why that option is greyed out in CubeMX for STM32L552. I spent hours trying to build the project until I realized most of the API calls to create semaphore were invalid.

Now, in the new API, the way to create a binary semaphore is like this:

osSemaphoreId_t osSemaphoreHandle;
const osSemaphoreAttr_t osSemaphore_attributes = 
{
 .name = "osSemaphore"
};
 
osSemaphoreHandle = osSemaphoreNew(1, 1, &osSemaphore_attributes);

To release semaphore from ISR:

osSemaphoreRelease(osSemaphoreHandle);

You may refer to the example project at the Cube repository at:

\STM32Cube_FW_L5_V1.4.0\Projects\NUCLEO-L552ZE-Q\Applications\FreeRTOS\FreeRTOS_SemaphoreFromISR

Anyways, I noticed that the following are no longer needed in this port:

xHigherPriorityTaskWoken = pdFALSE;
xSemaphoreGiveFromISR(xSemaphore, &xHigherPriorityTaskWoken);
portYIELD_FROM_ISR(xHigherPriorityTaskWoken);

I was wondering if that's the correct way to do it with ISR in the new API.

By the way, is there any new documentation that outlines all of the new API features, changes, and a guide on how to use them with examples like this one: UM1722?

Zaher

[Zaher]

OK. I just tested it. The new API makes things less complicated. The above functions are no longer needed. The "initial count" and "max count" parameters are also very useful for semaphores.

[Pavel A.]

> Anyways, I noticed that the following are no longer needed in this port:

This is not a port and not a new API. This is so called CMSIS-RTOS, a kind of universal façade API over several RTOSes, including the original Keil RTX, FreeRTOS and few more.

Its goal is make life easier for these who make drivers, examples and libraries portable across these RTOSes.

For a real product you usually select one specific RTOS, so the CMSIS-RTOS wrapping adds memory and time overhead.

[Zaher]

Thank you. That makes sense. So, the CMSIS-RTOS v2/v1 are just wrappers for a variety of RTOSes. I would probably re-generate the project without the FreeRTOS middleware component if that proves necessary to free some resources. However, I'm ok with performance and footprint at the moment.