Binary Semaphore problem with conversion

Kernel
1

Hello community,
i hope somebody can help me.

I try to update a ScreenView from TouchGFX.
There is incoming data from RX and passed to ScreenView with RTOS binary semaphore checking for “message-ready-flag”.

Thats the error:
error: invalid conversion from ‘osSemaphoreId_t’ {aka ‘void*’} to ‘QueueHandle_t’ {aka ‘QueueDefinition*’} [-fpermissive]

I get this error in the line where
if( xSemaphoreTake( binarySemUartMsgHandle, ( TickType_t ) 10 ) == pdTRUE ), is called.

Here is my code where the “TAKE” is called:

#include <gui/model/Model.hpp>
#include <gui/model/ModelListener.hpp>
#include "cmsis_os.h"
#include "semphr.h"

extern osSemaphoreId binarySemUartMsgHandle;




Model::Model() : modelListener(0)
{

}

void Model::tick()
{
	if (binarySemUartMsgHandle != NULL)
	{
		 if( xSemaphoreTake( binarySemUartMsgHandle, ( TickType_t ) 10 ) == pdTRUE )
		{
			uartMsgRdy();
		}
	}
}

void Model::uartMsgRdy()
{
	modelListener->uartMsgRdy();
}

Here is my code where the “GIVE” is called:

#include "main.h"
#include "PollingRoutines.h"
#include "string.h"
#include "cmsis_os.h"
#include "semphr.h"

extern osSemaphoreId binarySemUartMsgHandle;

void PollingInit()
{
	// Interrupt einschalten, Speichert 1 Byte ins Array
	HAL_UART_Receive_IT(&huart1, uartMsgData, 1);
}

void PollingRoutine()
{
	if(msgRdyFlag)
	{
		xSemaphoreGive(binarySemUartMsgHandle);
		msgRdyFlag = 0;
	}
}
2

You should either stick to the CMSIS wrapper API or use native FreeRTOS API.
So either find the CMSIS function to handle (binary) semaphores or use FeeRTOS
SemaphoreHandle_t xSemaphoreCreateBinary( void );

1 Like
3

Thank you!
For the moment i found a solution by myself, i hope this is not too wrong, but it is working so far:

if( xSemaphoreTake( (QueueHandle_t)binarySemUartMsgHandle, ( TickType_t ) 10 ) == pdTRUE )

i casted like this.

I will try to understand your answer, you mean i should use either the custom CMSIS warpper or i should use the raw FreeRTOS wrappers not both mixed?
(I should probably prefer the CMSIS one?)

4

Exactly. Don’t mix.

Which one to use is up to you. There are pros and cons to both approaches. Just make sure, again, to stick to one API.

1 Like
5

The key point is that if you want the generality of the wrapper, you shouldn’t assume that the wrapper handle and the FreeRTOS primitive handle are actually the same thing. Some wrappers may actually create a new object that the handle points to that contains the FreeRTOS handle in it.

A Second point is that the “purpose” of using something like the CMSIS wrappers is to allow the easy chaining of what RTOS you are going to use. This means you code shouldn’t directly call ANY FreeRTOS functions, or you have just negated that advantage.

I find it rarely makes sense to change the OS for an application, so I find little use for something like CMSIS

The one exception to this would be for writing ‘library’ code. It might make sense when writing a general purpose library to want it to be usable for multiple RTOSes, and so the library might use CMSIS or some other wrapper. Such a Library would use CMSIS, and thus application parts that need to share with that library would end up needing to use the CMSIS api.

The one limitation I will add about CMSIS, is it basically locks you into the ‘ARM’ ecosystem, as it is an ARM based wrapper. I program based on directly using FreeRTOS is portable to other processor families.

1 Like
6

Thanks a lot for post, very informative and thankful for me.