COE718: Embedded Systems Design Lab 3a: Scheduling Tasks with uvision and RTX 1. Objectives The purpose of this lab is to lab is to introduce students to uvision and ARM Cortex-M3's various RTX based Real-Time Operating System (RTOS) capabilities. Specifically, students will learn how to schedule round-robin, preemptive, and non-preemptive tasks using uvision and its supporting libraries. 2. Working with uvision and RTX 2.1. Setting up an RTX Project Launch the uvision application. Create a new project "RTX_Demo" in your "S:\\" folder. Select the LPC1768 chip. Copy the files provided to you in the course directory "U:\\coe718\labs\lab3a-task/lab3a_1" to your project directory. Configure your project workspace to resemble that of Fig. 1. To configure the "RTX_Library" folder in the project tree, navigate to the directory C:\\Keil\ARM\CMSIS\uVision\LIB\ARM\ and find the file RTX_CM3.lib. When searching for the.lib file, ensure that the field "Files of type:" in the file window is set to "All files (".")" to see files of type.lib. To manage the structure of your project workspace, use the project manager. To access this click on Project >> Manage >> Components, Environment, Books. Try manipulating the Project components so that they are exact to Fig. 1. Fig. 1. Project Workspace for Demo Once the workspace is setup, follow the following steps to setup the RTX kernel: 1. To specify the RTX target options in uvision, either select the icon or Project >> Options for Target "LPC1700". 2. Click on the Target tab. In the Operating System dropdown box, select RTX Kernel. 3. In the Code Generation box, check Use MicroLib. This will help the compiler generate a smaller code size which is ideal for embedded applications. All other configuration options should be left as their default values. 4. Click Ok to close the window. Select File >> Save All. RTX must now be configured for the scheduling algorithms desired for our task-based applications.
2.2 Configuring RTX 1. Open the file RTX_Conf_CM.c either by selecting File >> Open or by double clicking the file in the "Configuration" sub-tree of the Project workspace. 2. Once the file has opened, select the Configuration Wizard tab found at the bottom of the coding window. Click Expand All to see all the options that the RTX kernel provides. 3. a) We will investigate these properties further when dealing with multi-threaded applications in lab3b. For now, let us look at what pertains to round-robin scheduling. First, observe the fields under the heading RTX Kernel Timer Tick Configuration. b) Under this option, there should also be a subheading entitled Timer Clock value[hz]. Ensure that this option is set to 10000000 (10 MHz), and that the subsequent Timer tick value[us] option is set to 10000 (10ms). What exactly do these numbers mean? If we set the frequency to 10MHz, an RTX kernel timer will cycle every 0.1us. Setting the timer's tick value to 10000 then allows the "RTX's clock" to tick and generate an event every 10000*0.1us = 1000us = 1ms. Why do we need an RTX clock? Real-time system's are not usually designed for applications that deal with nanosecond time scales that are typical of conventional processors. They revolve around more practical applications and human-like response times. Systems designed for such an environment will more than likely require higher magnitudes of time, such as milliseconds. By adding an RTX timer, the application can be coded easily for variety of possible scheduling algorithms, without the need to explicitly poll for timer flags and/or use interrupts to schedule the tasks. 2 Fig. 2: RTX_Conf_CM.c Configuration Wizard 4. Round-Robin Scheduling: The RTX_Conf_CM.c file is especially useful for programming applications with round-robin scheduling algorithms. Under System Configuration there is a heading entitled Round-Robin Thread Switching. We will be programming a round-robin application for this demo. Therefore ensure that the Round- Robin Thread switching and User Timers boxes are checked. Under this subheading there should also be a field entitled Round-Robin Timeout[ticks]. We will use a time slice of 10ms for each task. Therefore since every "tick" is equivalent to 1ms, set the timeout field to 10. Your configuration file should now resemble that of Fig. 2. Note: When a change is made in the Configuration Wizard file, the code in the "Text Editor" tab will also change automatically according to the options you selected. Ensure that you Save All to save these changes and include them during compilation.
3. Programming with uvision and RTX 3.1 Understanding the RTX Program Open the Demo.c file in the project workspace and examine the code. This is an example of an RTX application consisting of two tasks which appear to be executing concurrently, employing a round-robin scheduling algorithm. The "LPC17xx.h" and <RTL.h> headers must be included when creating an RTX application for the MCB1700 board. In the main() function, the SystemInit() function is used by the internal NXP microcontroller to setup the system and configure the clock. The os_tsk_create() functions will create the tasks and set priority levels. It is recommended that the priorities set to each task upon initialization are of equal value in a round-robin scheduled algorithm (Note: if os_tsk_create(task1, 0); is coded, the '0' will automatically be transformed to a '1' by the compiler). Note that 255 is the highest priority task, whereas 1 is the lowest. Thereafter, once the tasks have been created, main() is instructed to delete itself using os_tsk_delete_self() so that only the three tasks execute. os_sys_init(task1) instructs the program to start executing using task1. Using the RTX timer, task1 and task2 will infinitely loop using round-robin arbitration with 10ms time slices, set according to the specifications in RTX_Conf_CM.c. Tasks are implemented each in their own unique function above main(). Notice that data exchanged between tasks should be done globally, else local data will be overwritten when the task's time slice has expired. If you are implementing loops within tasks, it is also wise to consider a global while loop over a local for loop implementation, since for loops use local data to keep track of information. Compile the application and enter Debug mode. We will now use the uvision tools to analyze this RTX based program. The following exercises will require re-running the program for each subsection. Therefore click stop and RST (reset) when commencing a new subsection. 3.2 Analyzing the RTX Project a) Watch Windows Watch windows allow the programmer to keep track of the variables global_c1 and global_c2: 1. Open the watch window by selecting View > Watch Window > Watch 1. 2. Find the column entitled "Name" in the Watch 1 window. The subsequent rows under this column should read <Enter expression>. Highlight the field and press backspace. Enter "global_c1" in the first row, and "global_c2" in the second. Alternatively, you may also hover the mouse over the variable name in the code window, right-click and select Add 'global_c1' to... >> Watch 1. Same for global_c2. 3. When you click the RUN icon to execute the program, the values of global_c1 and global_c2 should alternatively increment depending on the task that's currently executing. 4. It is also possible to change global_c1 or global_c2's value as its incrementing during execution. If you enter a '0' in the value field, you may modify the variable's value without affecting the CPU cycles during executing. This technique can work both in simulation and while executing on the CPU. b) Watchpoints (Access Breaks) Similar to the Watch window, watchpoints allow a program to stop executing when a variable has reached a specific value. This can also be very useful for debugging purposes. To use a watchpoint: 3
1. Select Debug >> Breakpoints. 2. In this window we can select a variable's value for which we would like the program to terminate. Enter the expression field as: global_c1 == 0xFFFF. Check off the "Write" box in the "Access" field. Click on "Define" to set this as a watchpoint under Current Breakpoints. Click Close. 3. Go back to the Watch window and set global_c1 as 0x0 (zero) if it is not already set. Click RUN. The processor (and simulator) will then stop when global_c1 is equal to the value 0xFFFF. To remove the watchpoint, open the Breakpoint window once again and select "Kill All". Select Close. c) Performance Analyzer 1. Select View >> Analysis Windows >> Performance Analyzer (PA). 2. Expand the "Demo" function in the PA window by pressing the "+" sign located next to the heading. There should be a list of functions present under this heading tree. There should also be another subheading entitled "Demo.c". Press the "+" sign again to collapse the demo tree further. There you can see task1 and task2 execution, along with the main function. 3. Reset the program (ensure that the program has been stopped first). Click RUN. 4. Watch the program execute and how the functions are called. Exercise: Try setting a watchpoint for the variable global_c1 again to 0xFFFF. Reset the program and click RUN. At what time does the overall program halt? How long was the TASK running for? Set a watchpoint for global_c2 to 0xFFFF. What do you notice? Why does this happen? d) RTX Event Viewer The Event Viewer is a graphical representation of a program's task based execution timeline. An example is given in Fig. 3. The Event Viewer runs on the Keil simulator but must be configured properly for CPU execution using a Serial Wire Viewer (SWV). To use this feature: 4 Fig. 3: Event Viewer 1. In the main menu select Debug >> OS Support >> Event Viewer. A window should appear. 2. Ensure that you have killed all the breakpoints from the previous steps by selecting Debug >> Kill All Breakpoints. 3. Click RUN. Click the "All" button under the zoom menu in the Event Viewer window. You may also select "In" or "Out" to adjust the view of the timeline which dynamically updates as the program continues to execute. Note the other tasks other than task1 and task2 that are also present in the execution timeline. 4. Let the program execute for approximately 50 msec. Click STOP. Your window should now look similar to that of Fig. 3. 5. Check off "Task Info" in the Event Viewer menu. Hover the mouse over one of the task time slices (blue blocks indicating execution of the task). You will see stats of the task appear. The stats should concur with the round-robin scheduling we set up in RTX_Conf_CM.c (i.e. 10ms time slices).
6. Try going back to the RTX_Conf_CM.c file and changing the time stats of the round-robin scheduler. Rebuild the project and run it again in Debug mode. See if the Event Viewer reflects the changes you made to the file. e) RTX Tasks and System Window This window provides an RTX kernel summary with detailed specifications of RTX_Conf_CM.c, along with the execution profiling information of executing tasks. An example window is provided in Fig. 4. The information obtained in this window comes from the Cortex-M3 DAP (Debug Access Port). The DAP acquires such information by reading and writing to memory locations continuously using the JTAG port. To use this feature: 5 Fig. 4: RTX Tasks and System Window 1. Select Debug >> OS Support >> RTX Tasks and System. 2. As you run the program (or Reset and RUN), the state of the "Tasks" heading will change dynamically. The "System" information however will remain the same since these values were specified prior to runtime in RTX_Conf_CM.c. Fig. 5: Project Workspace for Second Demo 4. Implementing Different Scheduling Algorithms 4.1 Pre-emptive Scheduling with Tasks Leave debug mode and close the round-robin project. Create a new project "RTX_Preemp" in your "S:\\" folder. Select the LPC1768 chip. Copy the files in the course directory "U:\\coe718\labs\lab3atask/lab3a_2" to your project directory. Configure your project workspace to resemble that of Fig. 5. Remember to include the RTX_CM3.lib, and to change the "Target Options" accordingly with the RTX Kernel operating system and use MicroLIB options. Refer to Section 2.1 if uncertain. Since we are coding a pre-emptive application, we must open the RTX_Conf_CM.c file. Uncheck the Round-Robin Thread switching option under System Configuration. This eliminates the timer from interrupting each task after a certain time slice is complete.
6 Open the Demo2.c file and analyze the code and comments provided. The description for this pre-emptive algorithm code is as follows: The tasks and global variables are declared globally at the beginning of the code, along with the libraries and headers needed to implement the scheduling algorithm. The OS_TID variables are used as "Task Identifier" values to keep track of each task's ID. main() creates a task entitled "job1", initializes the timers and deletes itself so that only the tasks will run. job1 retrieves it's ID and creates a new task, job3. Note that both job1 and job3 have the same priority level. Note that since this is a pre-emptive algorithm, job1 and 3 may be interrupted and/or pass control to one another at any time. The task's main goal is to enter an infinite loop and increment its global counter until the value 200 is reached. The task increments its variable once however before passing control to the next task of equal or higher priority using os_tsk_pass(). Similar to job1, job3 also obtains it's ID the first time it executes its function. It then goes into the same loop as job1, incrementing its counter one at a time and passing control to the next task. This continues until job1 has reached its limit, where it then sets a flag to be read by job3. Job3 also continues execution until it's counter has reached its limit. It raises it's priority level using os_tsk_prio_self() so that it may retrieve the job1's signal without interruption when it arrives. Once the evt signal has been obtained, job3 creates a new task, job2, and deletes itself along with job1. job2 continues executing and passes control with os_tsk_pass(). Since there are no other tasks with equal or higher priority, job2 continues executing until its limit is reached. Thereafter the task deletes itself. Compile the program and return to Debug mode. Open the Event Viewer window and let the program run for about 5ms. Zoom in on job1 and job3 in particular. Verify and ensure that you understand how the program corresponds to this graphic representation and the pre-emptive nature of the running tasks. 4.2 Processor Idling Time When there are no tasks to run, a processor will typically transition to an idle state and wait until a new task is ready for execution. In RTX mode, the Cortex ARM core and the RTX kernel automatically create an "Idle Demon" task for the idle state. The actual task definition for Idle Demon is located in the RTX_Conf_CM.c file in the function os_idle_demon(void). The task may be altered to do useful work when idling, or even count the idle cycles to determine the utilization time of the processor. As an exercise, let us determine the idling time of the code we have been currently working with: 1. Exit Debug mode and open the RTX_Conf_CM.c file. Under the line #include <cmsis_os.h> insert the definition for the global variable unsigned int countidle = 0; 2. In the same.c code find the task entitled os_idle_demon(void) and adjust the function's code so that it resembles the following: /*--------------------------- os_idle_demon ---------------------------------*/ void os_idle_demon (void) { for (;;) { countidle++; } } 3. Save the file and compile the project. Re-enter Debug mode. 4. Open the Watch window. Add cnt1, cnt2, cnt3 and countidle to the expression list of variables to watch during execution. Click reset, and then RUN.
5. Observe the Watch 1 window as the variables increment. Notice the final values of the count variables, the countidle values and when the variable obtains these values. 7 4.3 Non-Preemptive Scheduling with Tasks Non-preemptive scheduling may be implemented in the same way that the pre-emptive scheduling was invoked. Non-preemptive scheduling however can be most effectively implemented by using priority levels to indicate priority levels and allow for non interruptible execution. Exercise: Using the previous example, add an additional task for a total of four tasks (i.e. job4). Job1 and job3 should have the same priority as in the pre-emptive example and be allowed to switch between tasks during execution. Job2 should have a lower priority in comparison to job1 and 3, whereas job4 should have the highest priority. Thus execution should output as finishing job4, job1 and 3, and finally job2. Experiment with the functions os_tsk_create(), os_tsk_prio_self() and os_tsk_prio() to set task priority levels. Note on Pre-emptive/Non Pre-emptive Scheduling Versus Round-Robin Scheduling To implement pre-emptive/ non pre-emptive scheduling techniques, make note that the RTX_Conf_CM.c file must be adjusted. Specifically in the Configuration Wizard, the option System Configuration >> Round- Robin Thread switching must be disabled. Ensure however that the systick timers are enabled. 5. Lab Assignment This lab is due week 6 at the beginning of your lab session. The following outlines specifications for 3 different scheduling applications. You must create TWO versions (analysis and demo) for each application in questions 1, 2, and 3. The analysis code will be used for debug mode and to analyze performance of your applications. Therefore, it must not include any LED or LCD code. The demo version will include the LCD and LED functions and supporting files. Note, you may need to increase the stack size to accommodate the LED/LCD code in RTX_Conf_CM.h. You will be marked on both versions of the code, but are only required to submit the analysis version for grading. The demo version will be presented during the lab. 1. Write a round-robin scheduling example using 3 different tasks. Each task should be allotted a time slice of 15msec. Note: Your code must perform a different functionality than the one provided in this demo. Marks will be awarded for creativity. Ensure that the tasks do not run infinitely, and they have a finite workload with respect to time. For the demo version only, use the LEDs and the LCD to indicate the threads that are currently executing in your program. 2. Create a preemptive scheduling algorithm for the following Operating System (OS) based problem: Priority OS Task Function Functionality 4 Memory Management -Increments its memory access counter. -Implements a bit band computation to a volatile memory location.
8 -Passes control to CPU management. -After obtaining a signal back from CPU management, delays the OS for 1 tick and deletes itself. 4 CPU Management -Increments its CPU management access counter. -Creates a conditional execution and barrel shifting scenario (to check its internal hardware). -Signals back to the memory management task and deletes itself. 2 Application Interface -Ensure that Application executes before Device Management. -Accesses the global variable logger using a mutex. -Writes a partial message to logger. Waits for Device Management to finish writing to logger. -Increases its global counter. Delays the OS for 1 tick and deletes itself. 2 Device Management -Writes the ending to logger variable started by the Application Interface. -Signals back to the App Interface. -Increases its global counter. Delays for 1 tick to ensure the file is closed, and deletes itself. 1 User Interface Increments the number of users (its variable), delays the OS for 1 tick then deletes itself. Commence task execution in main() with the memory management task. Implement each task's functionality as specified in the table, noting that each function has its own global variable and may be dependent on another task. The tasks presented here are of a finite workload, with the highest priority task being priority one. For the demo version only, use the LEDs and the LCD to indicate the threads that are currently executing in your program. (Note you may need to add delays in your demo version). For all solutions: Hand in the printout of the analysis version of your.c code, RTX_Conf_CM.c Configuration Wizard file, and snapshots of your Event Viewer and Performance Analyzer windows for each application. Question 2 may require several snapshots of your Event Viewer, and a well thought out choice regarding where you should halt your program for the Performance Analyzer window. Your TA will ask you to demonstrate the demo version for each application during your lab session. You may also be required to answer questions regarding the implementation and simulations of your applications.