How to install real-time operating system RTOS

To get the most out of your Zynq All Programmable SoC, you need an operating system. This article describes how to install a real-time operating system - specifically referred to as μC/OS-III.

To maximize the benefits of the Xilinx Zynq®-7000 All Programmable SoC processing system, using an operating system is certainly more efficient than using a simple physical hardware solution. Developers of Zynq SoC designs have a variety of operating systems to choose from, and they can choose a real-time operating system based on the final application. If you are using Zynq SoC in a challenging environment where multiple application areas require fast response and reliability to avoid loss or achieve rigorous performance goals, then RTOS is the best choice for you.

We will use one of the most popular real-time operating systems, Micrium's μC/OS-III, to demonstrate how best to add RTOS to the Zynq SoC system. The RTOS or its earlier versions have been used in a variety of exciting systems including the Curiosity Mars Rover. The latest version of the RTOS is currently undergoing MISRA-C, DO178B Class A, SIL3/4 and IEC61508 standards, which means it will appeal to a wide range of Zynq SoC users. But before we introduce the specific implementation method, let's review the basic knowledge of the real-time operating system, which is very helpful.

What is a real-time operating system?
What is the difference between a real-time operating system and a standard operating system? The real-time operating system is deterministic, meaning that the system needs to respond within a clear deadline. This certainty is important for a variety of reasons. For example, if the final application is monitoring an industrial process, it must respond to the event within a specific time period, as is the case with industrial control systems.

The RTOS can be further classified into three different types of RTOSs according to the ability to meet the deadline, each of which meets the deadline in a different manner. In hard RTOS, missed deadlines are considered system errors. This is not the case for a solid RTOS, and occasionally missing deadlines is acceptable. In soft RTOS, missing a deadline will reduce the effectiveness of the results, but the system as a whole is acceptable.

The real-time operating system is centered on running tasks (sometimes called processes), each of which performs the specified functions. For example, a task might read data through an interface or perform some action on the data. A simple system might only run one task, but more often multiple tasks are running on the processor at the same time. The transition between these tasks is called "context switching," which requires that the processor state associated with each task be stored and added to the task stack.

With time-sharing, each task gets a dedicated time slot on the processor, while higher-priority tasks can also allocate multiple time slots.

Which task to run next will be controlled by the kernel. The core is the core of the RTOS and is used to manage software input and output requests and convert them into data processing instructions that the processor central processing unit and functional components can recognize. Task scheduling can be complex, especially when you need to avoid deadlocks (meaning two or more tasks are locked to each other). The two basic scheduling methods are time-sharing and event-driven. With time-sharing, each task gets a dedicated time slot on the processor, while higher-priority tasks can also allocate multiple time slots. Time segmentation is controlled by periodic interrupts or timers, a method commonly referred to as "polling scheduling." With an event-driven approach, task switching occurs only when a task with a higher priority needs to run. This method is often referred to as "preemptive scheduling."

Deadlock, resource sharing, and mutual exclusion wait When two or more processes (such as UART, ADC, or DAC) need to use the same resource, they can request the resource at the same time. In this case, access should be controlled to prevent contention. How to manage this is very important. If you do not use the correct management method, you will have problems such as "deadlock" or "mutual exclusion", which will lead to system errors.

When a process occupies a resource and cannot be released, a deadlock occurs because the task cannot be completed in this case. This process needs to use another resource that is currently occupied by another process. Since the system is in this state indefinitely, it can be said that the application has been locked. As you can imagine, deadlock is very bad for real-time operating systems.

Mutually exclusive wait occurs when a process cannot be run because the required resources are always allocated to other processes.

Over the years, there have been many articles and materials on these topics, and many solutions have been recommended, and you may not be surprised by this, such as the Dekker algorithm, which is a classic for mutual exclusion problems in parallel programs. Solution. The most common method of dealing with such situations is the semaphore method, which is usually divided into two types, binary semaphore and counting semaphore.

Typically, a binary semaphore is assigned to each resource. The request process waits for resources to become available resources before the task executes. Once the task is completed, the requesting process will release the resource. These semaphores are often referred to as WAIT and SIGNAL operations. The process first waits for a semaphore. If the resource is idle, the process will be given control of the resource and run until completion, at which point the process will issue a completion signal. However, if the resource is already occupied while the process is waiting for a semaphore, the process will be suspended until the resource is released. Once the currently executing process is complete, the suspend state is immediately terminated, but if a higher priority process preempts the resource, then it will take longer. A special binary semaphore called mutexes is usually used to prevent the occurrence of priority inversion (the term mutexes is derived from "mutual exclusion").

Counting semaphores works the same way as binary semaphores, but the semaphore (such as data storage) is used only when there are more than one instance of a particular resource type. Since each resource is assigned to a process, the count value is reduced to show the amount of available resources remaining. When the value is reduced to zero, the available resources are gone, and the requesting process is suspended until a resource is released.

It is necessary to communicate frequently between different processes. There are several methods available, the easiest of which is to use data storage and semaphores as described above. More complex technologies include message queues. With message queues, when a process needs to send information to another process, it will POST a message to the queue. When a process needs to receive a message from the queue, it will queue the PEND. Therefore, message queues work just like FIFO (first in, first out) memories.

μC/OS-III operating system
Micrium's μC/OS-III is a prioritized RTOS, meaning that it always runs tasks that are ready to execute and have the highest priority. To add this operating system to your Zynq SoC system design, the first step is to download the μC/OS-III RTOS from the Micrium website. After the download, the installation is very simple. You only need to extract some ZIP files to the correct folder (path) in the Xilinx installer on your computer.

Be sure to extract the ZIP file named Zynq-7000-ucosiii-bsp.zip into the \ \ISE_DS\EDK\ sw\ lib\bsp\ folder. You will see some other operating systems under this folder, including standalone systems and xilkernel. Then, as shown in Figure 1, extract the ZIP file named Zynq-7000-ucosiii-demo.zip into the \\ISE_DS\EDK\sw\lib\sw_apps\ folder. You will see a demo of some other apps in this folder.

After installing these two sets of files, we can create a project in the Software Development Kit (SDK). We will use the same underlying hardware we created earlier, but because we want to add the operating system, we need a new application and board support package (BSP).

In the SDK, all open projects outside the underlying hardware design should be closed. Next select File > New > ApplicaTIon Project option, name the new project and select the operating system μC/OS-III (see Figure 2). Then select the demo program for μC/OS-III (see Figure 3).

When done, click the Finish button. Application and board support packages will be created in the SDK (if selected). If you choose the Auto Build option, you will find several error reports. This is because not all project references are correct. To set up these project references, you need to import the demo settings found in the Project > Src > SetTIngs option. Right click on the XML file and view the properties. This allows you to select and copy the file location, as shown in Figure 4.

After the location is copied, right click on the project and select Properties. Under Project C/C++ General, select the Paths and Symbol options. Then select Import SetTIngs and paste it into the location of the settings file.

Also make sure that the repository is correctly pointing to the library you added earlier. You can check it by setting up Xilinx Tools > Repositories; this option should show where the previous μC/OS-III BSP was installed.

Since we want to use the UART output to demonstrate the state (showing the completed initialization value and the running task), you may need to set stdin and stdout to the UART under the BSP settings.

After performing these tasks, you will find that you can create your project now. However, there are still some warnings. If you try to run the project on hardware, the project will not be executed as a demo. This is because there is an undeclared function warning. Adding the following statement to the bsp.c file corrects this problem.
#include "xil_cache.l

Once the "include" header file is added, the project can be built as expected and run on the ZedBoard (login?v=uRB4La5ijrA to watch YouTube videos).

After starting and running the startup and running the instance project, you can rest assured that the RTOS will be implemented correctly on your system. Now you can continue to implement software design correctly on the Zynq SoC. Once you've created the software application and the engineering team is ready to test on the hardware, you can create a programming file—created in exactly the same way as the physical hardware system (see Xilinx China Communications Magazine) In the 48th issue, "How to Configure the Zynq SoC Physical Hardware Solution" allows applications using the RTOS to be booted and executed from the configuration memory.