i’m using cmsis_os2 (implemented by freeRtos) on an stm32f4
On cmsis mutex it says: osMutexNew, It can be safely called before the RTOS is started (call to osKernelStart), but not before it is initialized (call to osKernelInitialize)
On the FreeRtos documentation i don’t see any of these restrictions mentioned of when you are allowed to create the mutex. Are there any?
So can you confirm i’m allowed to create a mutex whenever i want and can use it if the returned value by xSemaphoreCreateMutex is not NULL?
First, I don’t think the FreeRTOS project makes a CMSIS implementation, but many processor vendors have built one.
Second, the Arm defined CMSIS is a lowest common denominator defintion, and has restriction that not all platforms that it targets have, and the need of a call to osKernelInitialize is one of them. I know if you look at the code for it, it won’t call any FreeRTOS initialize routine, as there isn’t one. (some port layers may have one?). Thus, you can cal xSemaphoreCreateMutex when ever you want.
It should be pointed out, that if you are actually using cmsis_os2, you probably shouldn’t be calling any FreeRTOS functions directly, as the various handles are not cross compatible, so a semaphore created with xSemaphoreCreateMutex can’t then be used with cmsis_os2 routines.
Personally, I don’t use the cmsis wrappers, as being a least common denominator adds restrictions that aren’t part of FreeRTOS, and a layer of overhead on operations. While it adds the option to change underlying RTOS being used, I don’t see much need to change that, but it does add a restriction that I cant port my project to a non-ARM based machine, as those won’t have a CMSIS defined (as it is ARM centric and defined).
i wanted to say: i use the cmsis_os2 implementation of ST which uses FreeRTOS as “backend” (and not threadx or anything else).
so yes, FreeRTOS does not implement cmsis. sorry for not being clear
i use osMutexNew for creation which then internally uses xSemaphoreCreateMutex.
In the project i’m working on there is additionally GitHub - ETLCPP/etl: Embedded Template Library being used which adds another layer of incompatibility and problems.
As when it is used with CMSISthe mutex is created with an osMutexRobust flag which FreeRTOS does not support so the whole mutex is not working as expected but this is not the fault of FreeRTOS
in the ST world it is kind of pushed if you use their tools. so at start it was just used because it was there, than someone came up with this ETL added on top, and now i’m here at the end of the food chain and try to fix bugs
Using freertos API directly is not a problem (which is something we will do in the future as all this added layers do distract and add sometimes subtle errors)
If using the wrapper, you should follow the limitations of the wrapper. The call to xSemaphoreCreateMutex won’t be an issue, but they may do some other work that would be.
Note, using their “Tools” (the IDE) doesn’t force you do use any of the other stuff. Using their libraries does force some things. Personally, we have found it better to not depend on their libraries, which just locks you into ST processors, and we built our own I/O libraries (that might use parts of the ST library internally) to make our project much more portable.
In particular CubeMX generates csmis_os2 code and their docu advises you to use it. By time you learn you don’t have to. For starters it is convenient to use. As for example you have the same functions in application and interrupt code and it is handled internally which freertos function to call. it looks like a big company has spent a lot of thoughts on how to implement that stuff to make it an easy use for you. and then by time you learn the harsh reality and how buggy it is in some parts
I would say that a big company spent a bit of effort to provide a glossy looking package to try to lock you into their product line (and their sloppy design practices).
Yes, you CAN use the same calls in an ISR or a task, but SHOULD you. Fundamentally ISR should be designed with different criteria than tasks, and thus few operations actually are well shared between them, and for those the duplication isn’t bad.
A key point is at the task level, many operations should block a bit to wait for the resource to be available. In the ISR, this shouldn’t be done (but some of their code does anyway, expecting that you will make sure the resource is being handled in a higher priority interrupt). Also, at the task level, FreeRTOS will automatically switch to a higher priority task that was unblocked, but an ISR needs to test at its end if it has unblocked a higher priority task to initiate the scheduler.
but this is not the fault of FreeRTOS