ECE 487/587 Embedded Systems
Laboratory Manual
1.
Background and Related Material
The laboratory exercises are based on equipment designed to interface to the
Versa Module Eurobus (VMEbus). The VMEbus is a standard asynchronous bus
protocol designed for I/O intensive applications. The use of this hardware is not to teach
the exact particulars associated with the VMEbus standard or the cards being used on the
bus. We will not become VMEbus experts, nor will we memorize the VMEbus transfer
protocols. Instead, this equipment will allow us to study a bus-based system architecture
which makes up a large percentage of the embedded systems in use today. Many of these
systems will use different bus protocols and different peripherals on the bus. However,
the fundamentals of communication within this architecture are the same.
The VMEbus provides a flexible educational environment. Using this equipment,
we will be able to study analog-to-digital conversion, polling input/output (I/O),
interrupt-driven I/O, multiprocessor concepts such as shared memory, task
synchronization, mutual exclusion, and real-time concepts such as deadlines, timing
evaluation, and task scheduling.
The VMEbus has a 32-bit address space and a 32-bit data path. Transfers across
the bus are initiated by a bus master. These transfers can be either read or write transfers.
VMEbus slaves reside on the bus and respond to the transfers initiated by the masters.
VMEbus slaves can respond to addresses in short address space (using only the low 16
bits of addressing), standard address space (using 24 bits of addressing), or extended
address space (using all 32 bits of VMEbus addressing). In order to distinguish a 16-bit
slave from a 24-bit slave or a 32-bit slave, the VMEbus uses address modifier lines, AM0
– AM5. These lines in conjunction with the address lines will be decoded by slaves to
determine the EXACT address in the VMEbus address space at which the slave resides.
Bus slaves decode the address and address modifiers being broadcasted by the master and
respond to the transfer only if they contain the destination address.
2.
The University of Alabama (UA) VMEbus Configuration
2.1
General Hardware Description
The VMEbus physically exists on a PC card mounted into the back of a desktop
chassis. There are two (2) chassis available for use in the Embedded Systems Laboratory
in 220 and 221 Houser Hall. In each chassis, there are nine (9) slots available to insert
cards to connect directly to the VMEbus. The card in slot one of the is a VMIVME-7750
CPU card. This card is basically a PC on a single VME card and is referred to as a single
board computer (SBC). Windows 2000 is the operating system on this CPU. All the
specifics associated with this card can be found in the VMIVME-7750 Product Manual
posted on the course web site. In slot two, resides the VMIVME-7459 card which
contains a hard drive and a CD-RW drive. This card is interfaced directly to the CPU
card in slot one of the chassis via a ribbon cable connecting the P2 connectors and
provides the hard disk storage and media drive for that particular CPU card. Slots three
and four contain another VMIVME-7750 and its associated hard drive and CD-RW drive.
This second CPU card executes the RedHat LINUX operating system kernel 2.4.20-6.
2
The last card in the chassis is the VMIVME-3113A. This is an analog-to-digital
conversion board having 64 single-ended or differential input channels with 12-bit
encoding per channel. All the details of this card are available in the VMIVME-3113A
Product Manual posted on the course web site. All boards in the VME systems are
configured using the factory default settings.
2.2
Access to the Hardware
The VMEbus equipment is physically located in the Embedded Systems Lab in
rooms 220 and 221 of Houser Hall. In order to conserve space in the lab, the CPU cards
within each VMEbus chassis share a keyboard, mouse, and monitor with a generalpurpose lab PC sitting adjacent to it through a 4-port KVM switch. The KVM switch is
configured so that the CPU 1 setting corresponds to the general-purpose lab PC, CPU 2
corresponds to the Windows VME SBC, CPU 3 corresponds to the VME Linux SBC, and
CPU 4 is not connected. Also, the VME SBCs connect to the monitor using an external
analog connection while the general-purpose lab PC uses a digital interface. So, one
must use the center button on the monitor to select the alternative analog input when
using either VMEbus SBC.
To demonstrate this setup, consider this example. Suppose a student wants to go
into the lab and access the Linux VMEbus SBC. First, the student should go to the lab
PC sitting adjacent to the desired VMEbus chassis. After selecting CPU #3 on the KVM
switch, the student should toggle the center button on the monitor to select the alternate
analog input to the monitor. After a few seconds, the monitor should display the Linux
login screen. The student might need to move the mouse if the system is idle. At this
point, switching to the Windows VMEbus SBC requires only changing the KVM
selection to that of CPU #2.
In addition to direct access from the Embedded Systems Lab, remote access is
available to the Linux VMEbus SBC from any networked PC. To gain access, students
can go to the website http://www.unix.eng.ua.edu/. On the left side of the page, students
should select to run the RealVNC Client software from the “Quick Downloads” section.
When prompted for the VNC server, the student can use either 130.160.67.31:22 for
VME01 or 130.160.67.33:22 for VME03. Students must provide the internet address and
port number associated with the VME chassis upon which they are given an account.
Once entered, students should get a window on the desktop that looks exactly like the
terminal window used by directly accessing the system from within the lab. Login to the
Linux login screen as usual using the username and password assigned to you.
2.3
Software
In addition to the standard RedHat Linux kernel distribution, the Linux VMEbus
SBC also has specific software targeted to the 7750 CPU SBC. This software is called
the board support package and includes a driver for the Tundra Universe II Chipset that
interfaces the VMIVME-7750 SBC to the VMEbus. A high-level description of the
software on the Linux VMEbus SBC necessary to interface to the VMEbus is given in
Figure 1.
3
USER CODE
API INTERFACE TO THE
DRIVER
VME UNIVERSE DRIVER
CPU CARD (VMIVME-7750)
TUNDRA
UNIVERSE II
CHIP SET
PCI-TO-VME
BRIDGE
PCI BUS
VMEBUS
ANALOG-TODIGITAL BOARD
(VMIVME-3113A)
API = Application Program Interface (Library of user functions)
Figure 1. High-level description of the Linux VMEbus SBC software.
In order for the user application to have access to the API library, it must include
<vme/vme_api.h> and <vme/vme.h>. Also, user code must link with the libvme.so
library using the –lvme switch on the compile command line.
The details associated with the API library functions are located in the online
documentation at
https://ladd00.triumf.ca/~daqweb/doc/vmic/latest/vme_universe/doc/index.html. There is
also sample code in the documentation students should review.
In order to use the driver library correctly, the user application will have to
initialize the VMEbus. This actually creates an interface between the application user
4
code and the driver software. The function responsible for this is called vme_init. Each
piece of user code trying to access the VMEbus must call this function because each user
program has its own scope and interfaces can’t be shared from the scope of a single user
application.
Other library functions that are required include:
vme_master_window_create
vme_master_window_map
vme_master_window_unmap
vme_master_window_release
vme_term.
The general template for a user application is shown in Figure 2.
#include files
int
main function {
/* variable declarations go here */
vme_init
vme_master_window_create
vme_master_window_map
/* main functionality of the routine goes here */
vme_master_window_unmap
vme_master_window_release
vme_term
return(0);
}
Figure 2. General template for a user application interfacing with the VME Universe
driver software on the Linux VMEbus SBC.
In addition to the API library functions, there are VMEbus utilities that the
students can initiate from the command line to perform some VMEbus transfers. The
documentation provides specific details about each of these utilities. These are just
command line utilities that are convenient for use. They are not the same as the API
library functions that students will use as part of their C programs. The utilities do
provide convenient debugging capabilities.
5