 Hello, let's focus on CMC's OS version to API, which will be used within handsome parts during this session. CMC's OS API is a generic RTOS interface for Cortex and Pyste devices like STM32. It has been designed by ARM for all implementation of Cortex-M devices. Middleware components using the CMC's OS API are RTOS independent. This allows an easy linking of any third-party RTOS to your application. The CMC's OS API defines a minimum set feature, including the treat management, kernel control, semaphore management, message queue, and mail queue, memory management. STM32Cube libraries comes with an implementation of CMC's RTOS for free RTOS. And we've got two versions of an STM32Cube MX and CUBE IDE, CMC's OS V1 and CMC's OS V2. Here you can see the links to the Cale web page, which is describing more in details both API conventions. Within this training we will use CMC's OS V2, as it is much more advanced and it covers much more functionalities within free RTOS. Let's discuss the main data structures, main information while we are programming operations using CMC's OS API. So most of the functions from CMC's OS V1 or V2 is returning the status information. So in our implementation, in our examples, we will use OS status underscore T, as we will use version 2 of CMC's OS. OS status allows us to check whether the function is completed successfully or there were some issues. We will discuss further more in details the possible values of OS status underscore T and analyze the possible root causes of the issue. Then each OS component has its own ID, own handler, so in case of the tasks, it is OS3ID underscore T, in version 2, and it is mapped to task handle underscore T within free RTOS API. Similar stories with the Q's, semaphores and mutexes and the software timers. It is important that those handlers are valid for the components which needs some memory allocation, so the control block and its own stack. This is why we need the handler to store all of the information over there. The next important point is concerning the delays and timeouts. So like it is done when STM32 hardware abstraction layer, all the delays and timeouts are given in milliseconds. So zero means no delay, something above zero is always in milliseconds, and if you would like to wait continuously, so wait forever, we need to specify all the once within 32 bits, so it is defined as OS wait forever within CMC's underscore OS.h file. Most of the functions within CMC's OS API in version 2 is returning OS status underscore T type value. It is the fully defined within CMC's underscore OS.h file, and it's very important to understand what are the meaning of the values of this type. So once OS status underscore T is equal to zero, it means that the operation defunction completed successfully. Minus one means that there was some unspecified operating system error during runtime of execution of the function. Minus two means that it was not possible to fully execute the function within given timeout period. Minus three means that there was a problem with the resource availability. Minus four means that there was a parameter error. Minus five means that there was not enough memory, so system was out of memory, and it was not possible to allocate or book memory for this operation. Minus six, which is very important one, it is the option where the function was not allowed to be executed from the interrupt. So this is important to understand what is the meaning of the particular values of this type, and to check it during execution of the operating system functions, what is the return value to detect abnormal situation and debug the application. Task states are coded within OS thread state underscore T enumeration. Here in the table we can see the coding of each state of value. So we can see a thread inactive, ready, running, blocked, terminated, so mentioned, deleted. There is as well the thread error in case of an error with the task, and there is a reserved field as well. Let's focus a while on the three task attributes, which are defined within a structure of type os thread atr underscore T, within cmcs underscore os2.h file. So this is a typical for cmcs OS in version two, and it contains all of the information which are necessary to create a new task, and some of them we need to specify by our own during the task creation, and some of them are filled by the code after the task creation. So let's say the first one is a name of the task of the thread, as you can see, then the second one we need to specify is a stack size, which would be dedicated for the given task, and its priority. So those three arguments we need to specify within this structure before task creation, and then use an address of this structure to create a new task. Then during task creation the rest of the fields will be filled. So for example attribute bits, then pointer to the thread control block memory area, which would be known after task creation during allocation of two memory areas for the task, so the test control block needs stack. So this pointer would be filled a bit later on after creation of the task, then the size of the task control block would be filled here as well. It can be done after creation of the task, because it will be calculated based on the rest of the components, which has been selected within 3R2s, usually within 3R2s config.h file. As you remember, if we add for example mutex's, software timers, task notification, the task control block will be increased. This is why this size is added a bit later on. Then we've got the pointer to the thread or task stack memory area, so the dedicated stack for the task, and in case we are working with the microcontroller based on a core with a trust zone, there is as well the trust zone module identifier place. So those are the main components within this structure, which are defining the task we are just creating. Just to highlight, during the task creation, we are filling manually or specifying manually 3 components, name, stack size, and the priority of the task. Here is the list of the priorities which are available within CMC's OS V2. It is much extended list versus CMC's OS V1, and in terms of the naming, it is much more complex than native 3R2s API. So the priorities are stored within the enumeration called OS priority underscore t. We can find it within CMC's underscore OS.h file. And we are starting from OS priority none, which is not initialized, it is value 0. Then we've got OS priority idle, this is value 1, it is reserved for idle thread. Then we've got, let's say, the space between 2 and 7 not used. And number 8 of the priority is used for OS priority low. Then we've got OS priority low 1 to 7, and we've got the group OS priority below normal. Then there is OS priority normal, above normal, high, real time, and OS priority ISR, it is reserved for interrupt routines, and its level is 56. If there is an issue with the priority, we will have the value minus 1. So the system cannot determine what is the priority level, all the level used for the creation of the component is illegal one. So it is good to monitor the value, which is read, for example, from the task, whether the priority is on a correct level. When we are using the CMC's OS, it is converting, in fact, those naming conversion into the FreeR2S API once. So please monitor carefully which values are returned by the OS functions. The values which would be returned by CMC's OS would be, of course, within this OS priority enumeration list. But if you will go into the API functions of FreeR2S, please remember that in between we've got the conversion between those priority list and numbers and FreeR2S APIs. Thank you for watching this video.