I am looking at the feasibility of using CMSIS threads in our C++ Cortex M4 application, compiled with armclang. Scheduling would be fairly simple – each thread would have a different priority and would wait on a semaphore set by an associated interrupt service routine.
I can see no requirement to have a system tick, which is just as well as it would not be supported in our hardware. Would CMSIS support the thread mechanism I have described without having a system tick? (I think it should be ok because I expect scheduling will happen on leaving the ISR and on semaphore operations).
I have written some simple test code based on the example here:
Thread Management
I haven’t linked in any CMSIS objects and so am getting a linker error: Error: L6218E: Undefined symbol osThreadCreate (referred from TestFunctions2.o).
Can you please either suggest which objects/libraries are required or point me to an Arm Dev Studio example that uses CMSIS threads?
Thanks for your help. I need a lightweight (fast) way for an ISR to wake a thread. Am I right in thinking that osThreadFlagsSet() is a convenient way of doing this?
Or might xTaskNotifyAndQueryFromISR() be better, or just a conventional semaphore?
Regarding the system tick, I need to check it but I note your point.
Yes, osThreadFlagsSet would work to rendezvous the waiting thread with the alerting ISR. i actually use the 'event flags' api for the same task, I'm not quite sure why as need as extra 'osEventFlagsNew' step. I think I liked the looser coupling it provides, it doesn't tie the ISR to ONE thread, ANY thread could be waiting for the alert.
The xTaskNotifyAndQueryFromISR is not in the RTOS2 spec, it maybe a call in FreeRTOS ??
Thanks, that's helpful. Yes, I got confused - xTaskNotifyAndQueryFromISR is from FreeRTOS.Alternatively, I could use osMessagePut(), but that may be overkill as I only need to signal an event.Do you think osThreadFlagsSet() has the lowest latency to wake a thread?
I haven't measured the latency with either thread flags or event flags, in RTX that is. My applications don't have millisecond requirements on interrupt handling, so I see RTX's implementation as 'good enough for me'.
One thing it's useful to know is that when a call like osThreadFlagsSet is called, it does NOT invoke the context switcher to immediately switch a readied thread to run. Rather, it sets some flag to denote the event/alert has occurred, then sets the PendSV bit. On exit from the ISR, the PendSV handler runs (it is pending until the ISR exits since always runs at LOWEST priority) and it is the PendSV handler that actually invokes the context switcher.
Thanks again for your help.