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, an extra DB9 cable and a 10 pin cable from the lab instructor prior to your first lab session. For sections D1 and D3, the lab instructor will be in the lab on Friday, September 15th, between 2 and 4 PM, and Monday, September 18th, between 2 and 4 PM to distribute the breadboards and cables. For students in D2 and D4 sign out your breadboard and cables at the times specified above or during the scheduled lab periods for D1 and D3 prior to your first session.
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 and display statistics about uC/OS-II .
For this exercise you will be using tasks to control the state of eight LEDs
through a memory-mapped register connected to the Queued Serial Module (QSM)
of the 68332.
You must modify the given source file lab1.c, which is provided to
you containing two dummy tasks called StatsDisplayTask()
and ContextCountTask().
Your new code will be inserted primarily into these two tasks.
Your StatsDisplayTask code will have to display data into the minicom
terminal window on the Linux host using the functions in the I/O library.
Read through cmpe401/src/io/io.c to familiarize yourself
with the available I/O functions.
Specifically, you will be using outstr(),
and outchr() among others
to display strings and characters, and intstr() to convert
integers into the corresponding character strings.
Note: The standard C library stdio.h/stdio.c is not available in the
MicroC/OS-II environment so do not attempt to use functions such
as printf() or putc().
The kernel has been set up to produce two oscilloscope test signals using
the scope libraries found in cmpe401/lib/scope.s.
You should read and understand the functions in scope.s.
The kernel will toggle PCS0 on a clock tick and toggle PCS1 on a
context switch.
Therefore if a 32-Hz square wave is present on the PCS0 (Peripheral Chip
Select 0) pin of the 68332, then MicroC/OS-II is running.
PSC1 can be used to verify that tasks are being scheduled.
Using the scope() function you might, in future labs,
find it useful to send signals to the remaining PCS channels(/PCS2 and /PCS3)
for debugging purposes.
StatsDisplayTask()OSTaskQuery(). Display the header information and the task
information in a table.
The table should list each task's name, priority and task status. Display the
tasks from lowest to highest priority. Assign task names to known system tasks
like the idle and statistics tasks. In addition, your StatsDisplayTask should
display queue information for LEDQueue and ContextQueue. Each entry
in the table for queues should include the name of the queue, the size of
the queue and the number of elements in it.
Display the header, task and queue information so that it looks something like
this.
An updated table is to be redisplayed every 5 seconds initially.
The screen should be cleared before displaying a new table by sending
the ASCII code 0x0C (ASCII for Clear Screen).
ContextCountTask()
StatsDisplayTask:
Send a CONT_SW element from StatsDisplayTask to ContextCountTask via ContextQueue
Do StatsDisplayTask Stuff
Cede control to scheduler so another task can run
LEDDisplayTask() already exists in your code and does not
need to be modified. This task communicates directly with the QSM to turn the
LEDs on and off and can be viewed as a primitive hardware driver in the form
of a task.
Save and make the modified code and download it to the 68332 target. Run the code and verify that both of your tasks are running properly. Also note any changes to the scope signal on channel 2 (pin PCS1).
Modify the value passed to OSTimeDly in various tasks to determine the effect this has on system performance. Choose other time values for your completed tasks so that they generate as many context switches as possible and include the results in a table in the lab report. Your goal in choosing these values is to force the number of context switches up to 50% of max and the max that can be displayed on the shift register and observe the responsiveness of the system. Include these observations in your report.
Exercise #3: Input from the keyboard and synchronization using semaphores.
In this exercise input from the keyboard will control the suspension and resumption of any of the five running tasks. SciInit initializes the vector table to ensure that input from the keyboard works correctly with uC/OS-II. The characters typed at the keyboard generate interrupts that execute the associated interrupt service routines automatically. The interrupt service routine calls RxPost to place the character into the RxQueue. To retrieve the characters typed in, retrieve the character from the RxQueue using the appropriate uC function.
The StatsDisplayTask should continue to display the statistics that it displayed in exercise 2. Some modifications to StatsDisplayTask will be required for synchronization with SuspendResumeTask and GetTickTask as discussed below, otherwise the same stats displayed in exercise 2 should be displayed in exercise 3 with the addition of the stats for the new tasks and queues. LEDDisplayTask does not require any modifications, and should be created as in exercise 2. ContextCount task does not require any further modifications beyond your solution to exercise 2 , and should be created as in exercise 2. Add the necessary CONT_SW items to the ContextQueue for the new tasks so that their context switches are counted as well.
Sychronization is an important concept that you will implement in exercise 3. Enforcing order in real-time systems is a common problem. To accomplish this synchronization, three semaphores have been created for you to signal to StatsDisplayTask, SuspendResumeTask and GetTickTask that their respective turns have arrived. Each routine signals another to proceed once it has finished its respective work, and loops back and waits for its own signal to proceed. In this way, the three tasks execute in an orderly fashion. In this exercise you goal is to have the GetTickTask run first, SuspendResumeTask run second and StatsDisplayTask run third. The ContextCountTask and LEDDisplayTask will run freely as they would in exercise 2.
Suspending and resuming each of the tasks may result in system deadlock. Do not fix this. This is intentional and meant to demonstrate the dependencies that may exist between tasks in our system. Discuss this in your report as mentioned below in the report requirements.
GetTickTask
SuspendResumeTaskExercise #4: Version control using CVS.
This exercise requires no coding and is meant to introduce version control with CVS. Demo points are available for this exercise. 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.
Further details on this exercise are provided here and will be explained in the lab.
Demonstrate your working solutions to the lab instructor. You may choose to demonstrate exercise 2 and 3 seperately or all at once; your choice. Demo exercise 4 any time after you have imported and checked out your project.
Report Requirements:
Marking Scheme:
Lab #1 is worth 25% of the final lab mark.Last modified September 19, 2006