CS-384 Lab 3: Embedded System OS, Phase 1

Dr. Mark J. Sebern

Version 1.1 (12/18/1998)

Overview

The purpose of this lab is to increase understanding of operating system process management by implementing some components of a real-time operating system for the Motorola 68HC11 microprocessor.

Lab activity

Design and implement a simple dispatcher and round-robin scheduler for the 68HC11 microprocessor. You must also design and implement at least two "user" processes:

• The first user process should count an eight-bit value and display it on the breadboard alphanumeric display. Initially, the counting rate should be determined by a software delay loop. Put this delay function in a separate subroutine so it will be easy to modify its operation later. You may make use of the demo code in the AS6811/ASLINK package; see below.
• The second user process should produce a pattern (e.g., counting or rotation) on some (3-4) of the discrete LED's on the 68HC11 breadboard. You may wish to use the output bits of port A for this purpose. Again, use your "delay" subroutine to set the speed with which the pattern changes. (Note that later this code will be modified to use a different waiting method.)

The OS dispatcher should be designed to handle up to eight processes, though initially only the two above will be used. It should have a manually variable time quantum value (from tens of milliseconds to a few seconds); when the currently running process has exhausted its quantum, the dispatcher should context switch to the next "ready" process. Be sure to handle the possibility that there is no "ready" process.

Note that each process must have its own stack; the stack areas may be allocated statically (e.g., each of the process "slots" may have a fixed stack area associated with it).

Observe the behavior of the processes as you vary the quantum; by setting a large quantum value (e.g., 2-3 seconds), it should be possible to see the system "time slicing" from one process to the next.

Once the basic round-robin scheduling is working, add the following capabilities:

• [Required] An operating system call that puts a process to "sleep" for a specified duration. It is probably best to implement this call as a JSR to an operating system routine. (The "real-world" method would probably make use of the SWI instruction, but that is used for breakpoint handling by WinBug11.) Your process code should be written so that a software "switch" will select whether delays are done with a "busy waiting" loop or the "sleep" call. Note any differences in behavior between these two delay methods.
• [Extra credit, optional] Implement an OS-level binary semaphore (mutex) facility. You may limit the number of semaphores to eight, and you may require a fixed ID (e.g., 0 to 7) to specify a particular semaphore. Modify your "application" code to make use of at least one semaphore to protect some common data (perhaps "port C", if you use some bits for the alphanumeric display and others for a different purpose).

Note: Past experience has shown the importance of detailed analysis and good design. It is very easy to get lost in the assembly language coding if you have not carefully considered your data structures and function decomposition beforehand.

Two lab periods are allocated for this project. On the NT workstations in S-307 and the Windows 95 workstations in S-343 and S-366, you may use the WinBug11 program development environment, the AS6811 cross-assembler and ASLINK linker, and the Wookie simulator. If you are not familiar with this software, or with the 68HC11 "attaché case" systems, please ask the instructor for assistance. See the computer engineering download page if you want your own copies of these tools; note that they are updated from time to time.

You may use a ".s" file type for your assembly source files, to match the output of the GNU HC11 C compiler, or you can use some other file type (e.g., ".asm"). WinBug11 and Wookie have some features that are designed to work with the output files from AS11M, the older (non-relocating) assembler. We hope to update these tools to work with the newer AS6811 and ASLINK.

Acknowledgements

The WinBug11 debugger was developed as a senior design project by Jason Gaedtke, Matt Vandenbush, and Phil Van Helden.

The Wookie 68HC11 simulator was developed as a senior design project by Kalle Anderson, Jason Buttron, Paul Clarke, and Matt Enwald.

AS6811 and ASLINK were developed by Alan R. Baldwin, Kent State University, Kent, Ohio. They have been modified slightly at MSOE to support Microsoft Visual C++ version 5.0.

Report

Prepare a text file containing a brief report (one report per group) describing your design. Also detail any problems you encountered and any questions that remain about the lab material. Attach the report file and your program source file(s) (in a ZIP or tar archive) to a mail message, and send it to sebern@msoe.edu. Do not discard your original files, in case anything gets lost in the email system. Each section of the source code should list the author(s) and reviewer(s) of the code segment; each portion must be reviewed by a team member other than the author(s).

The report is due two hours before the following lab.

This page was last updated on January 19, 1999; send comments to Mark Sebern.