It has been six months since my curiosity soared towards Real-Time Operating System (RTOS). By this timeframe, I had the opportunity to work on two most popular RTOSes for the sole purpose of learning. One is which from open source domain, FreeRTOS and another is from the commercial domain, ThreadX. As the creative mind and effort behind the RTOSes are different, so do the provided services (aka objects). It seems to me that it is very easy for current to flow in a particular path by following KCL, but services provided by RTOSes, are so perplexing to choose during application development. However, one can easily download the basics into head by studying the materials, already available on earth or in cloud. Hence my preference goes to something else to choose a path to go by.
The number of devices has been scheduled by the scheduler of ThreadX, surely indicates its popularity. ThreadX supplied its RTOS with sources that maintained well naming convention to define data structures such as control block (CB) of objects. This is particularly helpful to understand the soul of RTOS. It is needless to say that playing is much more enjoyable when inner working of system is known. However, ThreadX comes with a cost of probably not less than five figures in USD. Don’t be alarmed now. Renesas Synergy will bring you full flesh of ThreadX for free but agreeing terms and conditions.
FreeRTOS, the de facto RTOS to get started with. For my case, there was no exception. I dereferenced my RTOS learning pointer to FreeRTOS. As ThreadX stimulated the wondering sight to dig deeper, so it didn’t take me much time to investigate the data structure offered by FreeRTOS. Though owner of FreeRTOS clearly stated, “FreeRTOS implements a strict data hiding policy“, the shipped version of FreeRTOS declared all required attributes in CB as dummy1, dummy2, … dummyn. Cores, those accommodate FreeRTOS in its real estate, surely don’t have any trouble to understand those dummies. But for a human core, it is no mere feat. There lies a big overhead in time domain for a human core to know which dummy is responsible to store defined priority for a task or status of task—running or suspended or completed. Anyway, nowadays IDE are smart enough to provide the option to get such meaningful information through RTOS-aware debugging.
In order to speed up my learning curve of FreeRTOS, once I started using STM32CubeMX to sync RTOS practice with preferred controller from STMicroelctronics. If I choose FreeRTOS in CubeMX, it automatically enables the CMSIS RTOS wrapper, where things get changed in order to make application portable for different RTOSes. CMSIS RTOS usage unique priorities than FreeRTOS. In order to convert to the original priority supported by FreeRTOS, CMSIS RTOS called a function, makeFreeRtosPriority to convert the desired priority to the priority suitable for FreeRTOS during creation of task. Overhead associates with calling this function is negligible since it occurred during task creation. So, no way it is going to harm real-time behavior of application. Anyway, I wanted to see the working principle of priority inheritance through my own eyes during my encounter with Mutex. So, I decided to use the marvel tool, Tracealyzer to record the trace data and my head was struct seeing the trace data produced by Tracealyzer where that particular task swinging back and forth between priorities 3 (default priority for FreeRTOS) and 4 (inherited priority for FreeRTOS) while I expected 0 (default priority for CMSIS RTOS) and 1 (inherited priority for CMSIS RTOS) with respect to task definition. What I tried is to speed up my learning curve, but I chose something that cost me more time to learn something else than intended. As the new day dawns, hope to see Tracealyzer to support CMSIS RTOS.