Skip to content

Latest commit

 

History

History
90 lines (75 loc) · 3.96 KB

L10.md

File metadata and controls

90 lines (75 loc) · 3.96 KB
layout title license
default
Software execution time measurment and analysis

Introduction

This lab requires you to perform experiments to measure the worst-case execution times for code in a set of uC/OS-II tasks. The tasks have been allocated priorities in accordance with the rate monotonic principle. When you have measured the worst-case execution times for all tasks, you should use response time analysis to determine whether or not the task set is schedulable.

FRDM-K64F image

Preliminaries

  1. You need to have a terminal emulator that can connect to a serial port to allow the results of the measurement experiments to be reported conveniently to the user. Ensure that minicom is installed, using the following command:

    $ sudo apt-get install minicom

    Open a terminal window and run minicom as follows:

    $ minicom -s

    Configure the serial connection for /dev/ttyACM0 with the parameters 9600 8N1.

    From the minicom terminal, type Ctrl-A U to turn on the addition of carriage returns following end of line.

Exercises

  1. Make sure that you are up to date with the exercises so far. When you are ready to check your work, you can import the repositories and checkout the solution branches. Build, run, and observe the solution programs. Study the code carefully to make sure that you understand it. Ask your lab tutor for help with anything that you don’t understand.

  2. Now import https://github.com/davidkendall/measure-analysis-mbed. Build and load the program. Notice that it appears to run satisfactorily. Study the source code in src/app/main.cpp. You will see that the program comprises 5 tasks: checking if SW3 is pressed, sampling the accelerometer, updating the LCD, updating the speaker, and flashing the red LED.

  3. Take the main body of each task and copy it into the measurement program that you have already used so that it forms the 'Software under test'. Run the measurement program to obtain an estimate of the worst-case execution time of the code. For example, for the task sampleAccel you would use

     accelVal[0] = accel.x();
 accelVal[1] = accel.y();
 accelVal[2] = accel.z();

    as the 'Software under test'. You may need to add additional variables to your program in order to build it. Obtain the worst-case execution time. You can assume that the period of the task is given by the OSTimeDlyHMSM() call, in this case it is 100 ms. Why is it necessary to use a separate program to measure the worst-case execution time of each code fragment individually?

  4. When you have recorded the worst-case execution time and the period for each task, use response time analysis to determine whether or not the task set is schedulable. Note: If you need a refresher on response time analysis, have a look at the slides and the lab session for week 5.

Remember if there's anything you don't understand in the labs, please ask your tutor for help.

Working at home

You’ll need to spend about 5 or 6 hours per week, outside of scheduled classroom time, working on the exercises and doing further reading. The most important part of this will be the time that you spend programming. You can configure your own computer to enable you to do any of the work that you would normally do in the lab. If your own computer has a Linux OS installed, then you can simply follow the instructions for installing the GNU Arm Embedded Toolchain and pyOCD. If you have a Windows or Mac machine, then you should install Virtualbox and create an Ubuntu 16.04 Desktop guest OS to run on your machine. See [Using Virtualbox]({{ site.url }}/kf4005/L01.html#using-virtualbox) for guidance. You can then install the tools, as explained earlier.