Lab Dates:
Report and Demo Due Dates:
Objectives:
Equipment, Parts, and Provided Software:
Documentation:
Background:
68332-based microcomputer: All of the laboratory exercises will use the New Micros NMIX-0332-OEM 68332-based microcomputer. This system is a typical 32-bit single-board computer for embedded control applications. The Motorola 68332 microcontroller chip is a relatively old part, but its architecture and interface subsystems are still representative of more recent 32-bit controllers. The 68332 contains a CPU32 microprocessor (upwardly compatible in user mode with the original 68000), a time processing unit (TPU), a queued serial module (QSM), a system integration module (SIM), a 2048-byte random-access memory (RAM) with separate battery power pin, a connection to an external system bus, and various software-reconfigurable inputs and outputs. The CMPE 401 microcomputer is almost identical to the one used in EE 380, but the amount of random-access memory has been increased from 128 kbytes to 256 kbytes by changing the values in the corresponding chip select configuration registers in software. Also, some of the jumper connections are different and the silkscreened lettering on the printed circuit board (PCB) is slightly different. The memory map is identical for the two systems in every respect except that the user RAM in the CMPE 401 system extends from 0x03000 up to 0x03FFFF instead of up to only 0x01FFFF.
Kernels: In this laboratory you will be running a real-time multitasking kernel called MicroC/OS-II on the 68332-based microcomputer. A kernel is software infrastructure that provides basic services to user-written programs called tasks. The kernel takes care of the details of sharing the available CPU time among the ready-to-run tasks. A kernel also provides functions for creating, scheduling and terminating tasks. It also can provide semaphores to permit inter-task synchronization, and a message system for inter-task communication. A pre-emptive kernel is one that associates priorities with tasks, and then schedules higher priority ready-to-run tasks to execute on the CPU in preference over lower priority tasks. A real-time kernel is a kernel that has been designed to provide predictable execution time behavior and relatively fast real-time response to hardware interrupts. By using a kernel, a software designer can be much more productive by being able to leverage an existing infrastructure of (hopefully) well-written and thoroughly debugged software that provides much of the required application-independent functionality.
MicroC/OS-II: MicroC/OS-II, distributed by Micrium Inc., is a portable real-time kernel with strictly-prioritized preemptive scheduling. A maximum of 63 application tasks, organized in a fixed priority order (priority IDs 0 down to 62), can be active in the system at any one time. A special 64-th task, the idle task, executes on the CPU at the lowest priority (ID 63) when none of the application tasks is ready to run. As well as providing basic task management functions (create, delete, change priority, suspend/resume, etc.), MicroC/OS-II also provides semaphores, mutual exclusion semaphores, event flags, message mailboxes, and message queues. This kernel has been successfully ported to over 100 different microcomputer architectures, including the Intel IA-32 architecture (which includes the Pentium series microprocessors), the MIPS R4000, the ARM7, the Altera 32-bit NIOS, the Xilinx MicroBlaze, the IBM PowerPC 405, and the Microchip PIC-18xx. The kernel has been used in commercial products, and a validation suite is available to facilitate the certification of MicroC/OS-II-based systems in safety-critical applications. MicroC/OS-II software, written in ANSI C, is distributed royalty-free to educational institutions for teaching purposes; however, a licence is required from Micrium Inc. to include the kernel in commercial products. A TCP/IP stack (called Light-Weight IP or lwip) is available for use with MicroC/OS-II, but this extension is not required in the first laboratory exercise. MicroC/OS-II is very convenient for our purposes in CMPE 401, and should be portable for use in other project-based courses.
Most of the software that you will be required to design will be written in C. Interrupt service routines must be written in CPU32 supervisor mode assembly language. Your programs can access the various library functions provided by MicroC/OS-II. You will use the provided makefile, with some small modifications of your own, to compile and link together software loads for the microcomputer.
You will find that you will only need to use a small subset of the available MicroC/OS-II functions in your software designs. Some of the most useful functions are listed in the MicroC/OS-II Function Summary. The lab instructor will make her copy of the uC/OS-II reference available in the scheduled lab period for consultation.
Version management systems: Software development is rarely accomplished in isolation by single programmers. Collaboration is key to developing todays more complex applications. In order to collaborate in a consistent manner software management programs have been developed to manage this collaboration process. In CMPE401, Concurrent Version System (CVS) will be used to introduce the student to these software management systems. Other versioning systems include Visual SourceSafe, Revision Control System, and Subversion. The basic principle is the same for all of them. Programmers must be able to collaborate in developing software in a controlled way.
Pre-lab Work:
Purchase the CMPE401 kit from the EEClub. Only one kit is required per group.
All of the parts required for Lab 1, Lab 2, Lab 3, and Lab 4 are included in the kit.
If you already have the parts or you wish to purchase them elsewhere, feel free to
do so. Ultimately, you must have the parts listed on each lab handout to complete
the labs. The list of parts is provided above.
Sign out a breadboard, a DB9 cable and a 10 pin cable from the lab instructor prior to your first lab session. For all sections, the lab instructor will be in the lab on Friday September 21st and Monday, September 24th, between 2 and 4 PM to distribute the breadboards and cables.
Wire up the breadboard according to the schematic diagram. Your breadboard will be connected to the microcomputer over a ribbon cable via the 10 pin header connected to the marked lines on the J1 Header. You will need to use pliers to carefully bend the pins of the header outward (two bends per pin) so that the header can be inserted down into the breadboard across the middle divider of one of the three boards. The ribbon cable and header connection will allow you to easily make connections on the breadboard to all wires in the ribbon cable (and thus connect to all of the required microcomputer signals). Place the register and LEDs according to the suggested floorplan. Be sure to keep the wires relatively short and tidy so that they will not get in the way and will not be easily dislodged. You will be re-using the circuits from this first laboratory exercise in other labs, so it is wise to do a good wiring job in the first lab. The pre-lab work will be checked off by a TA or the lab instructor shortly after the start of the lab period.
Be sure to bring a set of pliers and wirecutters with you to the lab session as these will not be provided to you.
Exercise #1: Compile, download and verify an initial system load.
tar xvf cmpe401.tar.
NEVER repeat this step in this or any other lab or you may overwrite
and lose all of your work! If you overwrite your work but you have checked in your
recent changes to your CVS repository correctly, you can restore from the
CVS repository.
If you have to untar the main .tar file again, be sure to save copies
of the files that you want to keep in a completely different directory in
your account.
If the untar operation was successful, a particular directory structure
should have been created in your account.
This directory structure is documented here.
make.
This will compile the lab1.c source file and link it with the
uC/OS-II ROM image provided in the cmpe401/bin directory.
You should now have the files lab1.s19 and lab1.map.
minicom
lo and press enter
to get the monitor ready to load the .s19 file.
cat lab1.s19 >/dev/ttyS0
to transmit the .s19 file out through the COM1 serial port.
go 10000 in the minicom window to launch
the uC/OS-II system.
Exercise #2: Using tasks to control LEDs through a memory-mapped register.
Your goal in this exercise is to use the writing and reading I/O routines to display a message to the user, read the input, and display the result in binary form on the shift register. Do not be concerned in this exercise with the order in which things happen. We'll deal with syncronization in the next exercise.
Start with displaying a message to the user every few seconds. Anywhere in the three to five second range is fine. You'll be prompting the user to enter a single digit that will be displayed on the LEDs connected to the shift register. Enter your prompting code in the MessageTask. Any reasonable prompting message will do.
In the ReadTask, you'll be retrieving the character that was typed into the minicom window connected to the 68332 SBC (single board computer) from the RxQueue and dispatching it to LEDDriverTask for display.
Hitting a character generates an interrupt which deposits the character into the RxQueue. The interrupt code is given to you, and executes automatically. Pay special attention to the way in which the characters were inserted into the queue. You must retrieve them in the same form and convert them from ASCII for the LEDDriverTask to display them correctly. The LEDQueue and LEDDriverTask are provided to you for displaying data on the 8-bit shift register with the LEDS connected to it.
Exercise #3: Synchronization using semaphores and system deadlock.
In this exercise, order between two tasks will be enforced and we will suspend and resume tasks in our system and see what the result will be. You will accomplish this by using semaphores to make one task wait for the completion of another task. This is often required in safety critical systems to ensure that safety checks occur before operation. In this lab, this trivial example will allow you to gain experience in doing this without worrying about hurting anybody.
You will enforce order between the MessageTask and the ReadTask. Initially, the MessageTask should execute first and the ReadTask must wait for the completion of the MessageTask before executing. Use the two global semaphores to synchronize these two tasks. You must create and initialize your semaphores before you can use them. Each of the tasks signals to the other to proceed once it has finished its respective work, and loops back and waits for its own signal to proceed.
Next up is the suspension and resumption of tasks to introduce the dangers of system deadlock.
Modify your MessageTask to prompt the user for a character in addition to the number in exercise two. Case is not important and is left to your discretion. Each character will toggle the suspend/resume status of each of the four tasks:
l or L for LEDDriverTask
m or M for MessageTask
s or S for SuspendResumeTask
r or R for ReadTask
Modify your ReadTask to handle the new input. Numbers between 1-9 should be handled as they were before. Each time the user enters one of the 4 (or 8) characters above it will be sent to the SuspendResumeTask via the SusQueue. You can filter out the characters that don't match valid input in either the ReadTask or the SuspendResumeTask. Your choice. This will be tested during the demos so you must handle input that is not valid. You must also inform the user that a task has been suspended or resumed successfully. Print out an informative string from inside SuspendResumeTask after verifying the return code from the appropriate uC/OS-II functions.
Suspending or resuming the various tasks may result in system deadlock. DO NOT FIX THIS. This exercise is meant to demonstrate the deadlock issue to you. You will be asked about the results of suspending and resuming various tasks in the lab report requirements below. Demonstrate your working solutions to the lab instructor. You may choose to demonstrate exercise 2 and 3 separately or all at once; your choice.
Exercise #4: Version control using CVS.
This exercise requires no coding and is meant to introduce version control with CVS. This exercise is optional but is recommended for both collaboration and practice. Version control experience is often advantageous on your resume. If you have no exeperience to date with version control, you should complete the optional CVS exercises at the end of each of the 4 labs. The lab#1 CVS instructions are here. Demonstrate to the lab instructor that your complete cmpe401 directory has been imported to the CVS repository and that the CVS checkout command generates a correct and current source tree in an empty directory.
Report Requirements:
a2ps file.txt command from the command line to print your code is recommended. It saves paper and makes your code easier to read.
Marking Scheme:
Lab #1 is worth 25% of the final lab mark.Last modified September 17, 2007