Lab 3b: Scheduling Multithreaded Applications with RTX & uvision

Transcription

1 COE718: Embedded System Design Lab 3b: Scheduling Multithreaded Applications with RTX & uvision 1. Objectives The purpose of this lab is to introduce students to RTX based multithreaded applications using uvision and the ARM Cortex-M3. This lab is the complement to lab3a which implemented task based RTX applications. In this lab, students will learn how to schedule round-robin, priority preemptive, and non-preemptive multithreaded applications with uvision and its supporting RTX and CMSIS libraries. 2. Setup the RTX Project Launch the uvision application. Create a new project "RTX_ThreadDemo" in your "S:\\" folder. Select the LPC1768 chip. Copy the files provided to you in the course directory "U:\\coe718\labs\lab3b-threads" to your project directory. Configure your project workspace to resemble that of Fig. 1. Do not use the LED, LCD etc files provided for this section. 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. To manage the structure of your project, use the project manager - 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, specify the RTX target options in uvision, either select the icon or Project >> Options for Target "LPC1700". Select the RTX Kernel operating system option and Use MicroLib. Click Ok to close the window. Select File >> Save All. Now RTX must be configured for specifications such as the time slice frequency of the CPU's systick timer and the arbitration techniques desired for our multi-threaded applications, similar to how tasks were implemented in the previous lab. Open the file RTX_Conf_CM.c. Ensure that the option Use Cortex-M SysTick timer as RTX Kernel Timer is selected, that the Timer clock value [Hz] option is set to (10 MHz), and that the Timer tick value[us] option is set to (10ms). Double check that the "User Timers" option is also checked off. Your configuration file should now resemble that of Fig. 2.

2 2 Fig. 2: RTX_Conf_CM.c Configuration Wizard 3. Programming Multithreaded Application with uvision and RTX 3.1 Understanding the RTX Program Open the Demo.c file and examine the code. This program presents an example of a multithreaded RTX application consisting of two simple threads, each executing their own task. The osthreadcreate() and osthreaddef() functions will create the threads and set their priorities respectively. Task1 and Task2 will infinitely loop using a round-robin scheduling technique. This timing specification was included in the config file (RTX_Conf_CM.c). oskernelinitialize() and oskernelstart() will setup the round-robin scheduling definition for the threads and execute the kernel respectively. Compile the application and enter Debug mode. We will now use the uvision tools to analyze the RTX program. 3.2 Analyzing the RTX Project As in the previous section, use the Watch Window, Watchpoints, Performance Analyzer, Event Viewer and RTX Tasks and System Window to analyze the application. Are there any similarities or differences between the task based implementation of the previous lab to this? How about the coding techniques? 3.3 Revisiting Demo.c Now that we have analyzed a simplistic multi-threaded application and its various performance features using uvision, let's go back to the Demo.c file. You might have noticed that when we evaluated the code using the various uvision tools that we may have over looked some technicalities. For instance, both the the RTL.h and cmsis_os.h headers must be included to define and access all RTX features. Let's take a look at the code once more step-by-step using uvision's analysis tools: 1. Re-execute the code and take a look at the Event Viewer. What task executes first? ostimerthread() thread initializes and executes - this thread is responsible for executing time management functions specified by ARM's RTOS configuration 2. The program starts executing from main(), where main() ensures that: a. The Cortex-M3 system and timers are initialized - SystemInit() b. the os kernel is initialized for interfacing software to hardware - oskernelinitialize() c. Creates the threads to execute task1 and task2 - osthreadcreate() d. Starts the kernel to begin thread switching - oskernelstart() 3. The Task1 thread executes for its round-robin time slice since it is created first. After 10msec the timer thread forces control to the Task2 thread.

3 4. The Task2 thread executes during its time slice for 10msec and is forced to stop again and execute task1. This occurs infinitely. 3.4 Processor Idling Time As an exercise, let us determine the idling time of the code we have been currently working with by using the idle demon once again, i.e. 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; and setup: void os_idle_demon (void) { for (;;) { countidle++; 1. Save the file and compile the project. Re-enter Debug mode. Open the Watch window. Add counta, countb, and countidle to the expression list of variables to watch during execution. Click reset, and RUN. 2. Observe the Watch 1 window, and as counta and countb increment, but the countidle variable does not. What does this mean? This The CPU is currently under 100% utilization by the task threads. Note that Idle Demon is set with the lowest priority in the task list. You can verify this by using the RTX Tasks and System tool. 3. Implementing Different Scheduling Algorithms Exercise 1- Setting Priority: Exit the Debug mode to access the Demo.c file. Change the line: osthreaddef(task2, osprioritynormal, 1, 0); TO osthreaddef(task2, ospriorityabovenormal, 1, 0); Compile the program and return to Debug mode. Run the program and open the Event Viewer window. What do you notice? By setting the priority of the task2 thread to that of a higher priority in comparison to task1, a pre-emptive (interruptible) scheduling technique was created where the higher priority thread will execute to completion first. Since task1 was created first, it was also expected to run first. Task1 however will never be executed due to its "Normal" priority setting (in comparison to task2's "AboveNormal") and the fact that task2 executes infinitely. Conversely, if the code was programmed such that the task2 thread terminates after a finite time (when its workload completes), task1 would thereafter be able to execute. It is recommended that the CMSIS-RTOS API Thread Management and ospriority enumerations be consulted to familiarize yourself with the available thread-based priority options during coding. Note that it is also possible to create a non-preemptive scheduling algorithm by assigning appropriate priority levels to the tasks. Exercise 2 - Pre-emptive Scheduling: Exit Debug mode to access the Demo.c file again. Change the task1 and task2 function code to the following: task void task1 (void const *arg) { // task is an RTX keyword for (;;){ // Infinite loop runs while task1 runs. counta++; // Increment global variable counta indefinitely os_tsk_pass(); task void task2 (void const *arg) { 3

4 4 for (;;){ countb++; os_tsk_pass(); Also make sure to change: osthreaddef(task2, ospriorityabovenormal, 1, 0); back to osthreaddef(task2, osprioritynormal, 1, 0); Recompile the files. Enter Debug mode. Open a Watch window to track the counta and countb variables, along with the Event Viewer. Reset the program and click RUN. How does the execution of the code using os_tsk_pass() differ from round-robin? If you were successful, you will observe short execution time slices per task in the Event Viewer, where it almost appears as if the tasks were running as round-robin (after several msec). With the changes made to the program, each task should simply increment their counter by one and pass control to the next task of equal or greater priority using os_tsk_pass(). Specifically, you should observe that on average a single task runs for 2.52us before passing control to the next task (which is the equivalent time spent entering the task, incrementing the counter, and passing control). What is the utilization time of the processor? Check the Idle Demon variable and task using the performance based tools. Try replacing the os_tsk_pass() with osthreadyield(); What do you notice? Exercise 3: Stop the previous program and exit Debug mode to gain access to the Demo.c file. Remove the os_tsk_pass() functions you implemented in the last exercise. Update task1 and task2 with the following code: task void task1 (void const *arg) { // task is an RTX keyword for (;;){ // Infinite loop runs while task1 runs. os_dly_wait(2); counta++; // Increment global variable counta indefinitely task void task2 (void const *arg) { for (;;){ os_dly_wait(1); countb++; Recompile the files and enter Debug mode. Setup the Watch 1 window with the variables counta, countb, and countidle. RUN the program Assess the Watch window, and note the difference between the execution of this code and the previous code. Use the Performance Analyzer and Event Viewer to verify your findings. What is the utilization time of the CPU?

5 5. Lab Assignment This lab is due week 7 at the beginning of your lab session. The following outlines the specifications for 3 different scheduling applications (Questions 1, 2, and 3). You must create TWO versions for each application: 1) an analysis version and 2) a demo version. The analysis will be used for debug mode to analyze performance of your applications for your report, and must not include any LED or LCD code. The demo version will include LCD and LED functions for your demo 1. You will be marked on both versions of the code, but are only required to submit the analysis version for grading. 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. 5 TABLE I: LIST OF PRE-EMPTIVE TASKS Task Functionality Thread Priority A A = [ + 2 ] B 2 3! 1 B = C C = D D = 1 +!!!!! E E = Table I provides a list of pre-emptive tasks, with their function and priority listed. Note: The lower the number in the Priority column, the higher the priority. Write the pre-emptive code for a scheduling algorithm which invokes the tasks and functionalities in Table I based on their priority level (i.e. Task C should finish computing first etc). Each task should print their final result to stdout (using printf or the watch window). For the demo version only, use the LEDs and the LCD to indicate the threads that are currently executing in your program. 2 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. 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. 1 Note, you may need to increase the stack size to accommodate the LED/LCD code in RTX_Conf_CM.h