 freeR2S native API. FreeR2S API conventions. Just to be aware about the main components, main conventions used within the naming at the FreeR2S API, let's spend a while here. The code of FreeR2S is written in very clear way and naming convention is very intuitive. So you can see within all of the variables names as a prefixes the information about the type of the variable itself. So for example C means char S short L long X port base type defined in port macro.h file. It is typical for each platform which is used within FreeR2S. So for example in STM32 it will be long. Then U is assigned and P is pointer. For the function name it is very nice naming convention implemented. So the beginning the prefix is telling us about the return value. So V is void X returns port base type and PRV is private. Then there is a file name where the function is defined. So for example the task means that the function would be defined within the task.c file. And the last part is a function name. So in this example it will be the priority set. So the complete function name would be V task priority set. It would mean that this function would return void so no return value in fact. Its name it will be priority set and it will be located within task.c file. A part of the functions within the FreeR2S API we've got a couple of macros which help us to perform some basic operations during the work of operating system. So all of the macros has as well the prefixes which are specifying where the macro is located. So for example port like port max delay is located within portable.h and it's typical for the port or for the architecture we are using now. Then the task prefix task like task enter critical is located in task.c.h file. Then pd it's a project that defines like pd true then config config use preemption as an example it will be located in FreeR2S config.h file. And err like errq full would be defined in project defines as well. Then we've got some common macro definitions like pd true pd false pd pass and pd fail which is more descriptive way on showing what is going on as a result of the function or macro. Mixing FreeR2S API and CMC's OS API. CMC's OS API and FreeR2S API coexistence. So CMC's OS API is a simple additional software layer over FreeR2S API code but not all of the features of FreeR2S API are available directly from CMC's OS API. So it is sometimes important to have the possibility to use those full features of FreeR2S API and this is why it is possible to use an additional FreeR2S API modules together with CMC's OS code like task notifications or event groups. There are let's say big differences in queues data structures task notification handling so it's much more simplified within CMC's OS and priority names. So please take care on those components while you're mixing the API CMC's and FreeR2S ones. Main operating system handlers are just a type def from the FreeR2S to CMC's. We can monitor it within CMC's underscore OS.h file like for example task handle underscore t which is from FreeR2S API it is mapped to OS Street ID. Then timer is the same story then semaphore, mutex and queue. So it is worth to check whether the handler is exactly the same structure and if it's the case it is much easier to mix the file the functions from FreeR2S and CMC's OS. Thank you for watching this video.