 proprio myself assistant professor department of electronics engineering wouchern instof technology solapore in this session we will introduce one of the widely used RTOS which is called muCOS learning outcour at the end of this session पुजर्사�िया। उसर्ठष्पं Walker ,renched Light Sir तहीं नीन वो स्यastics ौ, बूर्स, Tribe . According to the ರವ Про GS symp diversified ಹ್ರ್ಟಟಟboro ಮ್ರುesususe ಸೆವಿ ಂಟಿದಾಕ್ಸಿಂಟಿ ಸಾಲ್ರಾ ಬ್ರಸುಡ númerಬಿಂ ಜಾ ಪಟೆ ಕೂವದಾ IDEಾರಮ, verbess only ದೆತ್ಣರಾ, ಮೋಕ್ಟಿರಕೊ್ ರ್ತೂತಿ ಕ್ಸ್ರಿಮು ಸ� instead of theಖ್ರರ Excellence and So, first feature is called the source code. All the source codes for mucos are easily available. Means the source code for mucos are openly available on the internet. So, we can get all these source codes and we can use as per our requirement. The mucos is called the portable because mucos is written in highly portable programming language and CC and that's why the code written for mucos are easily poured from one processor to another processor. Means if the processor is changed with a little bit modification, same code can be used for another processor. It is also called RAMable. Mucos was designed for embedded application and you can embed mucos as a part of a product. So, as mucos is designed for embedded application, the size of the mucos is small and that's why this mucos we can install on a ROM type memory and now this ROM may be the part of our final product. Mucos is called scalable. Means can use only the services that required in the application. So, what are the different application services defined for mucos? It is not mandatory to install all these services for all the times. But one can install only the required services in our application. Mucos is called preemptive. Mucos is fully preemptive real time kernel. This means that mucos always runs the highest priority task that is ready. Means whatever the scheduler defined in mucos that is of type preemptive scheduler. So, all the times the highest priority task will get serviced first. Mucos supports the multitasking and mucos is able to manage upto 64 tasks. And out of these 64 tasks, 8 tasks are used by the kernel system itself. That's why 64 minus 8, the 56 tasks can be defined by the user. Deterministic. Execution time of all mucos function and services are deterministic. Means one can always know how much time mucos will take to execute a function or a service. The next feature is called task stacks. Each task requires its own stack. However, mucos allows each task to have a different stack size. This allows to reduce the amount of RAM needed in your application. Means if the operating system assigns a specific size of the stack for all the tasks. So, in that case it may happen that the sum amount of memory can be wasted. Services. Mucos provides a number of system services such as mailbox, queues, semaphores, fixed memory partition, time related functions etc. Mailbox, semaphore can be used for inter-task communication. Interrupt management. Interrupts can suspend the execution of a task and if higher priority task is awakened as a result of the interrupt, the highest priority task will run as soon as all nested interrupts complete. Interrupts can be nested up to 255 levels deep. Next is the critical section of a code. How mucos handles the critical section of a code? Mucos like all real-time kernels need to disable interrupts in order to access critical section of a code and re-enable the interrupt when done. This allows mucos to protect the critical code from being entered simultaneously from either multiple tasks or ISRs. Mucos mainly defines two microbes to disable and enable the interrupts. The first function is defined as oas-enter-critical which we can use to disable the interrupt. While entering into the critical section code, one can call this function to disable the interrupts. To exit from the critical section of a code and to enable the interrupts, one can use oas-exit-critical function. See, these two functions are processor-specific. They are found in a file called os-cpu.h. So, each processor port will thus have its own os-cpu.h file. So, before to make the use of these two macros, it is required to add the os-cpu.h file. Now, the few kernel application services we will discuss. The os initialization, os-start, os-interrupt-enter, os-interrupt-exit, os-shaddle-lock, os-shaddle-unlock, and the operating system origin. So, first service is called os-init, means operating system initialization. Now, this function must be called prior to calling any other mucos functions. So, before going to use any mucos function, very first it is required to call os-init function. os-init function returns as soon as an error is detected. And the prototype of os-init function is wide os-init into bracket, the os error that is the variable and the pointer. So, p underscore err is a pointer to an error code. So, for example, if this function calls the function os underscore error underscore none, in that case it can display initialization was successful. No any error is found. os-start starts the multitasking under mucos. This function is typically called from start-up code after calling os-init. If os-init is not called and one is trying to call the os-start, it will not gets called. So, very first it is required to call the os-initialization function and then one can go for the os-start function. os-start will not return to the caller. Once mucos is running, calling os-start again will have no effect. The prototype of this is wide os-start into bracket, the variable and pointer variable. p-err is a pointer to variable used to hold an error code. Now one example is showed which can display mucos is not initialized. Means this message will be displayed when you have not called the os-initialization function. os-init enter notifies the mucos that an isr is being processed. This allows mucos to keep track of interrupt nesting. os-int enter is used in conjunction with os-int exit. This function is generally called at the beginning of isrs. Note that on some CPU architectures it must be written in assembly language. The one seedo code is shown below. So, the isr name first in the isr it is required to save the CPU context that means to save the CPU registers like the stack pointer, program counter and all other registers. Then it is required to call the os-int enter function. Then after that whatever the required isr interrupt subroutine program and at the end the os-int exit function. So, after exiting from the isr again it is required to restore the CPU registers and then the return from interrupt and the program control will transfer to the main task. Now next application services are os-schedule lock and os-schedule unlock. Now you recall the RTOS scheduler. Now the scheduler keeps the record of the state of each task and selects one which are ready to execute. Whether the task is invading, whether the task is idle, whether the task is running so all these state of task and its record the scheduler is keeping. Scheduler allocates the CPU to selected task. A scheduler helps to maximize CPU utilization among different tasks in a multi-tasking program and to minimize the waiting time. Now os-schedule lock and os-schedule unlock these two functions are used for this purpose. os-schedule lock prevents the task rescheduling until its counterpart. os-schedule unlock is called. The tasks that calls os-schedule lock retains control of the CPU even though other higher priority tasks are ready to run. So os-schedule lock and os-schedule unlock must be used in pairs because allows os-schedule lock to be nested up to 250 levels deep. Scheduling is enabled when an equal number of os-schedule unlock calls have been made. os-version obtains the current version of mucos and prototype eats the os-version underscore the variable and the pointer. p-error is a pointer to variable that contains an error code returned by this function. Currently os-version always returns the version of operating system. References used are a book mucos the real time kernel and the site mucrium.com Thank you.