Lab 11: Introduction to RTX Real-Time Operating System

Lab 11: Introduction to Keil RTX Real Time Operating System (RTOS) COEN-4720 Embedded Systems Cristinel Ababei Dept. of Electrical and Computer Engineering, Marquette University 1. Objective The objective of this lab is to learn how to write simple applications using Keil RTX (ARM Keil’s real time operating system, RTOS). 2. Real-Time Operating Systems (RTOS) Simple embedded systems typically use a Super-Loop concept (think of the “forever” while loop of main()) where the application executes each function in a fixed order. Interrupt Service Routines (ISR) are used for time-critical program portions. This approach is well suited for small systems but has limitations for more complex applications. These limitations include the following disadvantages: • Time-critical operations must be processed within interrupts (ISR) o ISR functions become complex and require long execution times o ISR nesting may create unpredictable execution time and stack requirements • Data exchange between Super-Loop and ISR is via global shared variables o Application programmer must ensure data consistency • A Super-Loop can be easily synchronized with the System timer, but: o If a system requires several different cycle times, it is hard to implement o Split of time-consuming functions that exceed Super-Loop cycle o Creates software overhead and application program is hard to understand • Super-Loop applications become complex and therefore hard to extend o A simple change may have unpredictable side effects; such side effects are time consuming to analyze. These disadvantages of the Super-Loop concept can be mitigated or solved by using a Real-Time Operating System (RTOS). An RTOS separates the program functions into self-contained tasks and implements an on-demand scheduling of their execution. An advanced RTOS, such as the Keil RTX, delivers many benefits including: • Task scheduling - tasks are called when needed ensuring better program flow and event response • Multitasking - task scheduling gives the illusion of executing a number of tasks simultaneously • Deterministic behavior - events and interrupts are handled within a defined time • Shorter ISRs - enables more deterministic interrupt behavior • Inter-task communication - manages the sharing of data, memory, and hardware resources among multiple tasks • Defined stack usage - each task is allocated a defined stack space, enabling predictable memory usage • System management - allows you to focus on application development rather than resource management (housekeeping) 1 3. Keil RTX Keil RTX is an open-source, deterministic real-time operating system. The latest version, RTX5, implements the CMSIS-RTOS v2 API (see Figure 1), a generic RTOS interface for Cortex-M processor- based devices. More information can be found here: https://www2.keil.com/mdk5/cmsis/rtx https://arm-software.github.io/CMSIS_5/RTOS2/html/index.html Figure 1: Illustration of the software stack for several different versions of Keil RTX RTOS. Some of its benefits include: • Open-source: Free-to-use commercial-grade RTOS. • Easy to Use - Reduced learning curve, faster product development. • Safe and Secure - Reliable and secure operation. • TUV-certified Arm Safety Run-Time System • Flexible Scheduling - Choose the best scheduling for your application. • Deterministic Behavior - Known behavior for time critical tasks. • Designed for Embedded Systems - Uses the minimum amount of system memory. • Source Code - Useful for certification. Keil RTX5 is publicly developed on GitHub. The source code is included in all MDK editions. Use it if your product requires certification. On the minus side of things: ARM Keil have been working on and changing their RTX continuously. This has made keeping up with their changes and updates rather an issue. A lot of things that were introduced a while back are not true/available anymore – this made backward compatibility challenging. In addition, documentation is not that great and examples are rather lacking. Another problem with the RTX5 is that it messes up projects created for LandTiger board. That is why in this lab, we will use the previous implementation RTX instead of RTX5. The main concepts about RTOS remain the same, generally. If you wanted to browse, in a default installation, RTX files reside in folders like these: C:\Users\Cristinel Ababei\AppData\Local\Arm\Packs\ARM\CMSIS\5.8.0\CMSIS\RTOS C:\Users\Cristinel Ababei\AppData\Local\Arm\Packs\ARM\CMSIS\5.8.0\CMSIS\RTOS2 A typical RTOS supports several different communication objects which can be used to link the threads together to form a meaningful program. The CMSIS-RTOS API supports inter-thread communication with signals, semaphores, mutexes, mailboxes and message queues. 2 At this time, please pause reading this lab and read about Signals, Semaphores and Mutexes in the supplementary PDF materials included in the archive of files for this lab! 4. Example #1: “Simulating” a stepper-motor driver This is a simple example that is adapted from the example that comes with the MDK installation. It is the RTX_Blinky example, which is included with the support/pack for the MCB1700 board from ARM. The example is modified so that it can be run on the LandTiger board. In this example, four LEDs are controlled to blink in a way that “simulates” the activation of the four output driver stages for a step-motor. The example illustrates the creation of Threads and inter-thread communications with Signals. The following are the steps to create an application that uses RTX: • Create a new project, let’s call it lab11_rtx_blinky, and use NXP LPC1768 as the target processor. • In the Manage Run-Time Environment window, select CMSIS::CORE and CMSIS::RTOS (API)::Keil RTX. If the Validation Output requires other components to be present, click the Resolve button. • Click OK. In the Project window, you will see the files that have been automatically added to you project, the library or the source code files, as well as the system and startup files. • Click to open RTX_Conf_CM.c file under CMSIS. Then, click on Configuration Wizard, selectable at the bottom of the editing window. Then, expand, RTX Kernel Timer Tick Configuration and change (if needed) RTOS Kernel Timer input clock frequency [Hz] to 100000000 and RTX Timer tick interval value [us] to 10000. Then save the file. • Place a copy of the source files for this example from lab11_rtx_blinky/ folder included with the zip for this lab in your new project folder. These files are RTX_Blinky.c, LED.c and LED.h. Then, add the .c files to your project. Compile the project, program the board, and observe the operation. Read the provided source files to understand what is happening. 5. Example #2: Four tasks Building on the code architecture from the previous example, let’s now create another simple example project called lab11_4tasks. All the necessary files are in the archive with the files for this lab. In this example, we create four threads that accomplish the following four tasks to: 1) count and display digits 0-9 in a round robin fashion, 2) toggle two messages on the LCD every one second, 3) keep incrementing a global counter between 0-59, and 4) keep decrementing another global counter between 59-0. Compile the project, program the board, and observe the operation. Read the provided source files to understand what is happening. 6. Example #3: “Simulating” a stepper-motor driver + use Mutex for shared GLCD resource 3 This is a modified version of Example 1. The change is that we use the GLCD to display the switching on/off of the four phases. The access to the GLCD – as a shared resource – is controlled via a MUTEX. The source files for this example are in folder lab11_rtx_blinky_mutex. Mutex stands for “Mutual Exclusion” and is a specialized version of a semaphore. Like a semaphore, a Mutex is a container for tokens. The difference is that a Mutex is initialized with one token. Additional Mutex tokens cannot be created by tasks. The main use of a Mutex is to control access to a chip resource such as a peripheral. For this reason, a Mutex token is binary and bounded. Apart from this, it really works in the same way as a semaphore. Please find more information about signals, semaphores, mutexes, mailboxes and message queues at: https://arm-software.github.io/CMSIS_5/RTOS/html/group__CMSIS__RTOS__MutexMgmt.html Compile the project, program the board, and observe the operation. Read the provided source files to understand what is happening. 7. Lab Assignment Part 1 (required): You must write a program that uses Semaphores. In your program, create two threads. Each thread’s task is to generate a random number between 0-9 and print on the GLCD that many times the letter “A” (by Thread 1 on row one of the GLCD display) or letter “B” (by Thread 2 on row two of the GLCD display). Each time a thread writes on its row, first it must clean the row (in this way letters are not displayed from previous iterations, if the new random number in current iteration is smaller). Use semaphores to synchronize the two threads: each of the threads must Wait with the writing to the GLCD until it hears from the other thread and must Signal the other thread once done with its own writing – so that the other thread can proceed with its own writing, and so on. Note: In addition to the supplemental materials provided with this lab, you should read info on Semaphores here: https://arm-software.github.io/CMSIS_5/RTOS/html/group__CMSIS__RTOS__SemaphoreMgmt.html Part 2 (optional): Create a new uVision project and write a program using the Super-Loop approach discussed in this lab to implement Example 2. You should not use RTX, but your program should achieve the same behavior as Example 2. Develop your program using only the programming techniques that we used earlier in this course.

Load more