The Advanced Microcontroller Laboratory
Types of Laboratory Experiments
This paper describes how to set up a laboratory to provide convenient access to microcontroller hardware for doing exercises in hardware interfacing. Besides the traditional access given to the student via lab stations, hardware and software has been added to our set up to make much of the laboratory available on the Internet. With expanded campus networking being the rule rather than the exception, it makes sense to allow student access to laboratories by way of the network. Also, the increasing numbers of "older than average" students and students with disabilities lend further impetus for doing this.
Microcontroller hardware available to support a laboratory setting
typically consists of an evaluation board connected via a serial port to
a PC. Laboratory assignments typically address hardware issues such as parallel
and serial ports, interrupts, and timers. Some assignments deal with controlling
attached devices, such as stepper motors, LED displays, and DC motors. Described
in this paper are the developments necessary to make many of these features
available remotely over a network.
The advent of inexpensive personal computers running a free
UNIX and X-window has made possible a setting where a student accesses a
microcontroller in one window, an assembler and editor in another window,
a simulator with unique debugging facilities in a third window, and possibly
an editor for composing the laboratory write-up in a fourth window. With
network-wired residence halls students could very easily set up such a
workstation in their own rooms.
In our CS/EE course on assembly language and computer architecture,
several assignments use our micro-controller laboratory that is equipped
with Motorola 68332EVK boards. Two major assignments are a round-robin process
scheduler that uses real-time interrupts and a stepper motor control exercise.
In our EE course on microcomputer interfacing, students use a laboratory
equipped with Motorola 68HC11EVB boards. Exercises in this course focus on
hardware interfacing issues. For example, one assignment involves running
a 4-digit LED display using two output ports. One port contains the data
to be displayed while the other port controls latches that select which LED
displays that data.
Using an appropriate interface it is possible to put a microcontroller laboratory on the Internet using real processors (not simulators). Students are able to complete many assignments remotely without ever setting foot in a lab. This microcontroller programming laboratory "on the network" has received favorable reviews by the students. When given the choice, some students still go to the laboratory to get a "hands-on" feel of the equipment while others are content working from home. Regardless of how the student chooses to do the exercises, the quality of access to the laboratory has been improved at minimal cost to us.
In the future almost all electronic products will include
microprocessors in the design. Utilization of microprocessors / microcontrollers
in a hardware design augments the design's capabilities while simplifying
the design's implementation. Due to this it is important that students of
Electrical Engineering and Computer Science have undergraduate experience
with microcontrollers. It is sometimes difficult however, for a university
program to provide an adequate microcontroller lab due to limited lab space
and budget restrictions.
In an effort to overcome these difficulties a laboratory setup
has been developed utilizing existing net-works, campus hosts, and low cost
components that allow students superior access to lab equipment, at a price
that is reasonable. The enhanced configuration provides this improved access
without placing any additional restrictions on the types of laboratory exercises
that can be performed.
The defining characteristics differentiating microprocessors
and microcontrollers can be hazy. At the core, microprocessors and
microcontrollers are very similar. The primary operation of both is to process
a series of instructions that make up programs, and as such, they both do
this in much the same way. Their typical difference lies in that microprocessors
are oriented towards higher MIPS, MFLOPS, etc., while micro-controllers are
designed with interface circuitry embedded into the chip that provides things
like I/O ports, A/D converters, and RS-232. Note that this is the
typical distinction. Chip manufacturers sometimes blur this distinction
when making bigger and better chips.
At any rate, this paper is about an advanced
microcontroller lab, so the descriptions herein will focus on
microcontrollers. However since microprocessors and microcontrollers are
so similar, the setup is applicable to microprocessors as well. In fact,
on the NDSU campus microcontrollers are used to teach microprocessors.
Before detailing the setup of our advanced laboratory it is
helpful to consider some of the issues related to teaching a microcontroller
course and what sort of lab options are typically available to instructors.
There are two aspects to teaching a microcontroller course:
the programming side and the interfacing side. The programming aspect is
where teaching microcontrollers is similar to microprocessors. To insure
student understanding of microcontroller operation, microcontroller programming
must be taught at the machine language level. Because of this, additional
instruction in concepts such as memory fetches, cycles per instruction, stacks,
internal registers, and program counters is also required. These items are
avoided in most introductory programming courses and thus make teaching
microcontroller programming more difficult.
The other aspect to microcontrollers is the interfacing side, which itself has two facets. First, there is the physical / electrical connection between the microcontroller chip and external device being interfaced. This requires attention to issues of common grounds, voltage/current limitations, noise shielding, and firm physical connections. Even if a student has covered these concepts in other courses, because of limited prior experience, most students taking a microcontroller course need to be reminded of them.
Once the hardwired connection is made, the communications aspect
of the interfacing needs to be addressed. For this, students must learn about
memory mapped I/O (memory addresses whose value represents and/or manipulates
signals pins on the chip), timing considerations (many students put in-sufficient
delay in their programs so that the program talks to the device faster than
it can listen), and interrupts. Because of the number and complexity of these
concepts, a student requires lab experience to ensure understanding.
There are a number of different course counterparts that constitute
a lab, albeit some deviate greatly from the classic laboratory image. The
first style of lab is to offer computers with microcontroller simulation
software. Students can compose assembly language programs and then execute
them in a simulated environment. Typically the simulator restricts students
to programming that doesn't involve interfacing, with coding assignments
requiring only memory manipulation and simple text manipulation operations
via simulated monitor routines. More sophisticated simulators offer simulated
interfacing where students can observe or stimulate simulated ports. This
style of lab isn't great, but it at least allows students a place to write
and test their code. It is advantageous because the test equipment is software
which, could potentially be copied to all available computers, providing
a large number of lab stations for students. Access is further improved if
the software is available for a network accessible campus host. If a simulator
is placed on such a host, not only would it be available from the campus
computers but also potentially from a student's home if the campus offers
dial-up lines.
Some of the drawbacks of this lab style are that it doesn't
offer hands on experience and doesn't expose students to the interfacing
issues. For instance, students running code on sophisticated simulators may
assume the code is correct because the simulated output is properly sequenced.
However, students might overlook timing issues; even though the output is
properly sequenced, it is driving the I/O ports way too fast, and were the
code attempted with an actual microcontroller, the communication would fail
because the controller is talking faster than the device could listen. If
students had developed the code on an actual microcontroller this oversight
would have been caught rather quickly and at the same time, taught a valuable
lesson. Another drawback to a simulator-based lab is that simulator development
often lags chip development significantly. A microcontroller course using
a simulator-based lab would be restricted to teaching only microcontrollers
for which a simulator was available. This is a problem if a school is attempting
to teach the most current technology. Finally, simulators may contain programming
bugs, which could cause the simulator to deliver non-authentic responses
and hamper a student's understanding.
A second style of lab setup involves using evaluation boards.
Evaluation boards are printed circuit boards that contain an actual
microcontroller and a minimal set of memory chips and other supporting hardware
necessary to make the microcontroller function. Evaluation boards are offered
by chip manufacturers to promote their chips and provide customers an easy
way to evaluate a new product. Despite their commercial intent, evaluation
boards are very useful in education.
Evaluation boards typically run a monitor program that communicates
via a serial port. To use an evaluation board in a laboratory a computer
is required to communicate with this serial port. From the computer the user
can talk to the microcontroller and issue commands to upload code, execute
programs, and read and write memory locations. To perform an experiment using
this setup, students would enter their microcontroller program into the computer,
assemble it, upload the result from the assembly to the evaluation board,
and issue a command to begin execution. One advantage of this setup is that
the code is being run on an actual microcontroller so that the responses
are immune from programming bugs en-countered with the simulator. Also,
evaluation boards typically come with other connectors that directly route
to the various I/O ports, A/D ports, etc. that are featured on the
microprocessor. From these connectors students can very easily attach various
devices and perform interfacing experiments. Thus as a lab setup, the use
of evaluation boards remedies all the shortcomings of the simulator-based
laboratory.
Despite being an improvement, the use of evaluation boards does
have some disadvantages, the foremost being cost -- evaluation boards are
typically more expensive than a microcontroller simulation package. As such,
it is typically infeasible to have one lab station per student as was possible
with the simulator-based lab. In addition, evaluation boards typically require
one dedicated computer for each board. Though the simulators require computers,
the computers used can be located in a general purpose, general access computer
cluster. Since evaluation boards are expensive, it is usually desired that
the computers used to attach to their serial port be located where access
is restricted to only students taking the microcontroller course. Because
of these additional costs, an evaluation board-based microcontroller lab
typically supports only one lab station for every eight to ten students,
resulting in contention amongst students for access to the equipment.
A third laboratory setup is actually a hybrid of the other two
and stems from a recognition that all experiments need not be done on actual
hardware, especially for early assembly language programming experiments
that have nothing to do with interfacing and where speed is not an issue.
This laboratory orientation involves using a simulator for the initial part
of a course and then later using evaluation boards for the actual interfacing
and real time experiments. This setup maximizes the number of lab setups
at the start of the semester as stations are only limited by the number of
general purpose computers available (which is potentially unlimited if the
simulator is available on a campus host). This setup can also help alleviate
contention for the evaluation boards later on in the semester as students
can be encouraged to iron out the bugs in their code using the simulator,
and only after those bugs are ironed out, attempt work on the actual hardware.
One seeming drawback of this hybrid solution is that it is not
a cost-effective way of doing things since it involves obtaining both a simulator
and a set of evaluation boards. This isn't always the case though. One of
the expensive parts about using an all evaluation board setup is the cost
of the dedicated computers necessary to support restricted access. In an
educational environment, there are often multiple courses being offered using
specialized equipment needing computers with restricted access. If this is
the case, two courses can be orchestrated to use the same lab without interfering
with each other. So rather than just a microcontroller lab there is instead,
say, a microcontroller and PLD laboratory, helping to justify the computer's
cost and the dedicated lab space necessary to house them.
The Advanced Microcontroller Laboratory results from years of
observing what works best. It is a setup that is the current step in what
has been a series of small improvements to an existing laboratory arrangement.
It takes the best parts of the typical microcontroller laboratory
setups and puts them together in such a way that offers very convenient access
to equipment without restricting the types of exercises that can be assigned.
The design has additional merit in that it is both scalable and modular,
and it can be tailored to the needs and resources of any related course.
What is needed to set up an Advanced Microcontroller Laboratory
is a networkable terminal, a network, a host that allows multiple logins
(a PC running a free UNIX would do), a terminal server, and an evaluation
board with an appropriate assembler that can be ported to the host. These
are the minimal requirements to setup an Advanced Microcontroller Laboratory.
The listed items don't need to be purchased or obtained anew as existing
equipment will work. Most institutions already have a networkable terminal
(typically a PC with telnet capabilities), a campus network and a host, leaving
only the terminal server, evaluation board and assembler, all of which can
be obtained for less than $500.
The first step in putting together this lab is to obtain an
assembler for the microcontroller or microprocessor being featured in the
course. The assembler needs to be set up on the host. If the assembler isn't
written for the host it needs to be ported, or another assembler found. This
shouldn't be a problem as most popular microcontrollers / microprocessors
have many assemblers available; some vendors even supply the source code.
In the worst case, an arrangement might need to be made with the producers
of the assembler (com-panies are often helpful towards colleges and
universities).
Once the assembler is placed on the host that is accessible
via the network, students have the ability to compile their programs from
where ever they can log in. If working with the minimal requirements for
the Advanced Microcontroller Laboratory this would be the networkable
terminal. However more often there is a networked computer cluster that
students use to check their email, or alternatively a set of dialup modem
lines, anyone of which would allow students to log into the host and assemble
their programs.
The next setup item for the Advanced Microcontroller Laboratory
is the terminal server. A terminal server is a network device that attaches
to an ethernet, is assigned an IP, and has a number of serial port connections
for attaching serial communication devices. These serial ports might be used
to attach to some external modems. Incoming modem connections would be able
to operate via the IP number assigned to the terminal server, in essence
creating a modem bank. However for the proposed lab setup, the evaluation
board's serial connection is attached to one of the terminal server's serial
ports, and that port of the terminal server is configured as an output port
(in the modem example it would be configured as an input port). With this
in place, students can telnet from the host to the evaluation board (via
the terminal server), or in fact, students can telnet to the evaluation board
from anywhere (it need not be from the host) see [Fig.1].
Once the above is configured you have an Advanced Microcontroller
Laboratory [Fig 2]. The merits of this design will become evident in the
next section which describes how it is used.
The above description details the minimal configuration necessary
for an Advanced Microcontroller Laboratory. However, a more typical setup
would be to have several evaluation boards rather than just one, and at least
a computer cluster or two, plus dial-up lines, rather than just one networked
terminal. For purpose of the following description it is assumed that this
is the case.
For the first description of how to use the laboratory setup,
consider the example where a student has been assigned a problem that involves
writing a microcontroller assembly language program that doesn't involve
interfacing. In this case, the student would first telnet to the campus host
from a computer, be it from home or in a cluster. The student would compose
a program using one of the host's online editors and when completed, assemble
the program. Once the program is assembled, the student then telnets from
the host to an evaluation board via the terminal server. The student issues
commands to the evaluation board and host to upload the assembled code. Once
the code is uploaded, the student executes the program and sees if it delivers
the desired results. If the program doesn't deliver the desired results,
he or she can debug as necessary.
Some of the pluses of this arrangement should already be apparent.
First, evaluation boards are being used, which are actual microcontrollers
and thus are free of potential programming errors. Second, most of the time
spent working on program is in the composing and debugging stage. The previous
example showed that the editing being done used only the connection between
the student's terminal and the host, leaving the evaluation boards open for
use by other students. Were this a classical setup using evaluation boards,
each evaluation board would be attached to a computer, students working on
their program would tie up the computer connected to the evaluation board
(and consequently the evaluation board), even if they were merely typing
their program in.
For the second example the situation is altered such that students
have to complete an assignment that actually involves interfacing. In this
case some additional assumptions are made about the arrangement of the evaluation
boards. It is assumed that the evaluation boards attached to the terminal
server are in a lab station style arrangement in close proximity to some
computers or networked terminals. In this case the students go to one of
the computers or terminals and telnet from there to the campus host. They
then take their assembled code and upload it to the nearby evaluation board
that is hosting their interfacing experiment. Once all the connections to
the microcontroller are ready, students issue commands to the evaluation
board to start execution of the code. It is observed whether or not the
experiment works. If so, great; if not, then minor adjustments can be made
through the computer's connection to the host.
As with the last example, one advantage the Advanced Microcontroller
Laboratory has over classical arrangements is that students don't need to
tie up the evaluation boards during their initial program composition. With
this arrangement, students can do the bulk of their coding from home or from
one of the computer clusters and only when they think they have a working
product, go into the lab to test it.
Another advantage of the Advanced Microcontroller Laboratory
is the fact that all of the students' files remain on the campus host under
their own account. In conventional setups where evaluation boards are attached
directly to a computer, student files will collect on the computer's hard
drive, accumulating as junk and providing students a convenient means to
use another student's code.
In the previous section a number of details were skipped for
the benefit of understanding the gist of the operation. This section details
those and other items.
An important issue in the use of this laboratory is determining
which evaluation board students end up being connected to. In the case of
the non-interfacing example, it doesn't really matter, as students merely
need a microcontroller to test their code. In the interfacing case, however,
students will have presumably set up some additional hardware to a specific
evaluation board, so it is very important they get connected to that board
as they will be watching the interfaced devices for reactions.
This issue is handled by the capabilities of the terminal server.
As mentioned before, the terminal server has two sets of connections: one
is the ethernet connection that allows it to communicate with the host, and
the other is the collection of serial ports that allow it to connect to the
evaluation boards. Associated with each serial port is a number that maps
to an IP port that can be telneted to. The serial port number plus an offset
determine the IP port number. For example, if there was a lab station, numbered
station one, that possessed an evaluation board that was connected to serial
port number one, a student could connect to that specific evaluation board
by issuing a command from the campus host like, "telnet terminal.server.edu
2001". A virtual connection would then be established and the student could
then upload their assembled program and run their interfacing experiment.
The terminal server also provides a feature called a
rotary that facilitates connections when it doesn't matter which unit
is connected to. Without this feature a student wanting to connect to
any evaluation board would have to manually attempt to connect to
each known unit, a potentially frustrating activity if many of the boards
were in use. With the rotary that is not a problem; students merely attempt
a telnet connection to a special port (the port number of the rotary) and
the terminal server will automatically connect students to the first available
evaluation board. If none are available, the terminal server instead delivers
a connection refused error message, something that would still be frustrating,
but not nearly as much as they just attempted to connect to a dozen evaluation
boards only to find out that all of them were being used.
The second item that was skimmed over was how programs are uploaded
to the evaluation board once a connection is established. As mentioned, the
evaluation boards are intended for a serial port connection, and as such,
it is expected that programs will be uploaded via that serial channel. When
assemblers assemble a program the output generated is typically in a special
ASCII format. For the Motorola micro-controllers we are using this is the
"S-Record" format. The S-Record format was designed for uploading programs
to microprocessors on evaluation boards. S-Records encode both the opcode
data and the associated addresses in an ASCII printable format.
A program is uploaded by issuing a command to the evaluation
board's monitor telling it to expect S-Records on the serial line. The monitor
then waits indefinitely for S-Records to arrive and will not stop listening
for S-Records until it sees a special S-Record that denotes the end of
transmission. Once the monitor is placed in this wait state, the user then
issues commands to the telnet client to transmit the contents of a specified
file (which would be the resulting file from the assembler). Once the entire
file has been transmitted, the monitor returns to a command prompt. The user
is then free to issue a command to the evaluation board to start program
execution.
The final item that needs to be mentioned is a specially-designed
break detect circuit. It is possible for a microcontroller program to contain
an infinite loop; a set of instructions that will cycle over and over until
the processor is reset or until otherwise interrupted. This is not a problem
if a student is working in lab, where they can just hit the reset button
on the evaluation board. However with the Advanced Micro-controller Laboratory
it is likely that the student won't be in lab, but rather will be working
remotely, perhaps at home. If the evaluation board gets caught in an infinite
loop it will become unusable. Since it would be inconvenient to have to travel
to the lab to reset the microcontroller every time it locks up in an infinite
loop, a means to reset the evaluation board remotely is required.
The solution developed is to attach a tiny unit inline with
the serial connection that is wired directly to the evaluation board's reset
line. The inline unit is designed such that when it sees a break signal on
the serial line it pulls the reset line of the evaluation board low, causing
the unit to reset. The inline unit ignores any other signal or information,
responding only to the break signal.
There are a myriad of experiments that can be performed with
the advanced microcontroller laboratory. Some of our favorites follow.
Using a Motorola 68332EVK style evaluation board in our CS/EE
course on assembly language and computer architecture, one of the assignments
is to write code to implement a round robin process scheduler. This assignment
utilizes a Real Time Interrupt (RTI) generator (that is embedded in the
microcontroller) that sends periodic interrupt signals to the main processor
at intervals determined by the contents of a specific hardware address.
The objective of this assignment is for students to write code
that mimics an operating system's job scheduling duties by divvying CPU time
between two different processes running concurrently. To do this students
must write code that will suspend processing of one task and resume processing
by way of storing and retrieving register images. The round robin scheduler
switches processes every time it receives an interrupt from the RTI generator.
To provide validation that the scheduler is doing what it is
supposed to be, the final phase of the assignment requires students to develop
a print routine that uses the evaluation board's monitor routines for producing
output. These routines are accessed by way of TRAP instructions. A TRAP
instruction provides a con-venient way for an assembly language program to
make a system call.
Another favorite assignment in the CS/EE course on assembly
language and computer architecture is to write code to drive a stepper motor
setup. Stepper motors are special motors with multiple coils that represent
phases. The phases need to be strobed in a specific order to induce motion
in the motor. The ordering is typically to turn one phase on while turning
off the adjacent phase. Each transition between phases results in a
step of the motor. Stepper motors are often times used as actuators,
where small precise motor movements are required.
In the stepper motor setup used in this experiment, wires associated
with each phase of the stepper motor are attached to one of the 68332's output
ports. Since the 68332 uses memory mapped I/O, this allows a program running
on the 68332 to cause movement in the motor by adjusting the value stored
in a specific memory location. With this, the first part of this assignment
is for students to get the stepper motor to turn in both a clockwise and
counter clockwise direction.
The stepper motor setups also incorporate a photodetector mechanism
that is wired to an interrupt generator on the 68332s. This attachment is
setup such that when the stepper motor reaches a certain point in its rotation
a signal is sent back to the 68332 causing an interrupt. The second part
of this assignment requires the students to modify their code such that the
stepper motor turns in one direction until an interrupt occurs and then reverses
direction, resulting in an oscillation. This oscillation continues until
the motor completes some predetermined number of steps.
One of the challenges associated with this experiment is discovering
the sequence of numbers (corresponding to phase strobes) necessary to cause
movement in the stepper motor. Another challenge involves timing issues.
Since the stepper motor is a physical device it has inertia and requires
time to complete its steps. The student's code must allow sufficient delay
between steps to allow for this motion to occur. Fi-nally, it is possible
that when the stepper motor reaches the special spot in its rotation that
the photodetector will generate multiple interrupts when only one is desired.
The student's code needs to be smart enough to ignore interrupts that occur
in rapid succession. Students are asked to use the print routine developed
for the round robin scheduler to print out how many interrupts were ignored
as well as how many times the motor changed direction.
There are a number of different stepper motor setups, but one
of the more exciting ones appears below [Fig. 3]. It functions the same as
the setup described above but for added entertainment, a soda-pop can was
mounted to the stepper motor axle. It is rewarding to students when they
finally get their code working to see the can in action.
Figure 3: Soda-pop can version of stepper motor setup
Our EE course on Microcontroller Interfacing uses the MC68HC11EVB
evaluation board. One assignment in this course requires students to write
a program to control a four-digit LED display using two output ports of the
68HC11 microcontroller. The four-digit LED display attaches to the two ports
via ribbon cables. The data on one port is used to control which LED is to
be changed, while the data on the other port represents what gets displayed.
The ports are controlled via memory mapped I/O, so a program can adjust the
display by changing values stored in specific memory locations.
The challenging part of this assignment is much like that of
the stepper motor assignment. First, because of the way things are wired,
if the program running on the microcontroller placed a 7 on the port controlling
the display value, the result displayed would not be a 7. Consequently students
must figure out what values must be asserted on the ports to get the desired
value. Second, there are timing issues. Programs written to drive the display
must allow sufficient delay for the user to acknowledge a change. Without
sufficient delay, a program driving the display as, say, a counter, would
deliver a blurred display because the numbers were changing too fast.
Another interesting experiment uses DC motors and A/D converters.
The DC motor setup attaches to an output port of the 68HC11. It uses a D/A
converter that takes the digital value present on the output port and converts
it to a voltage that controls the speed of the motor. In this experiment
students are asked to apply a variable voltage source to the A/D converter
input of the 68HC11 and then via a program interpret that voltage to generate
a value that drives the motor. The variable voltage source that is inputted
into the A/D converters is initially the output of an adjustable power supply.
Once the setup is working, students move from using a power supply as input
to the A/D converter to using a voltage-outputting sensor.
This assignment allows students to experiment with control laws,
where the sensor is the input, the DC motor is the output, and the
microcontroller program is the control. The program that drives the motor
can be written to act as an amplifier, taking small changes in the sensor
output and converting them to large changes in the motor output; or as a
noise filter, ignoring rapid changes in input; or one of many other
possibilities.
Another possible experiment involves performing tests using
a Watchdog Timer. A Watchdog Timer is a safe guard available in many
microcontrollers. It is designed to prevent uncontrolled infinite loops or
suspended operation of the CPU. It is an interrupt mechanism that requires
the microcontroller program to periodically check-in with the "Watchdog".
If a program fails to check in after a certain amount of time the Watchdog
Timer generates a non-maskable interrupt that forces the CPU to start executing
a special recovery routine.
An experiment that can be performed to demonstrate the operation
of a Watchdog Timer is to write a microcontroller program that performs some
visible task, like driving a stepper motor, and then initiate the Watchdog
Timer and have the program purposely fail to check-in. The results of this
experiment would be that the stepper motor would turn for a while and then
suddenly stop when the Watchdog Timer sends the CPU to the recovery routine.
There are many things that can be done once an Advanced
Microcontroller Laboratory is setup. The following lists just a few.
To satisfy the needs of larger classes a number of evaluation
boards will typically be required. If many of the experiments in the course
are not going to involve interfacing, these evaluation boards can be grouped
together to minimize space. We refer to this arrangement as a bank.
The bank is nothing more than a bunch of evaluation boards mounted on some
surface with connections to power and the terminal server. Once constructed,
the bank can be mounted on a wall or tucked away in a corner to conserve
on facility space. An example of eight evaluation boards mounted in a bank
arrangement appears below [Fig. 4].
Figure 4: A bank of MC68HC11EVBs
A convenient variation used on the NDSU campus is to have a
bank of evaluation boards in addition to a set organized in a lab-station
arrangement. The bank is used for servicing the bulk of microcontroller needs
while the lab stationed evaluation boards exist for performing interfacing
experiments. For the part of the course where no interfacing experiments
are being done, the lab station evaluation boards can be included in the
rotary so that they act as part of the bank.
Perhaps the greatest advantage offered by the Advanced
Microcontroller Laboratory is the ability to interact with resources over
the network. This advantage can be further exploited by the uses of windowed
environments such as X-Window or MS Windows. With the advent of falling computer
prices and free UNIX (e.g. FreeBSD or Linux) running X-window, it becomes
very affordable to set up an X-station such that a student can have a connection
to the campus host in one window, a connection to an evaluation board in
another window, a debugger or simulator running in a third window, and a
text editor working on the lab report in a fourth window. With multiple windows
students have the ultimate lab station. And with network-wired resident halls
becoming more common, all this could be available from the student's room.
One of the biggest potentials that the Advanced Microcontroller
Laboratory offers is in the area of distance education. A state or educational
community will typically have multiple institutions that are spread out over
a large geographic area. It is often desirable to offer similar courses at
several institutions, and one means of doing this is through interactive
video links via satellite. With this arrangement an instructor may be at
one university teaching to a class with their lecture being simultaneously
broadcast to other institutions where their students are watching via video
monitors. This may work for the lectures, but it doesn't provide means for
the lab component. In an ideal situation each institution receiving the lecture
would have its own lab equipment for students to practice on. However, this
isn't always feasible. In such cases the Advanced Microcontroller Laboratory
would provide an excellent solution. Provided enough evaluation boards were
present, it would be possible for students to connect to laboratory equipment
hosted at another institution via the Internet.
The remote login ability of the Advanced Microcontroller Laboratory
can make laboratory work easier for the disabled, students older than average,
students with children, and anyone else with special needs that may have
difficult making it to campus to perform exercises in a lab. Also during
adverse conditions when travel is abnormally difficult this advanced lab
can be a great convenience.
After using the Advanced Microcontroller Laboratory for over
a year, the results at NDSU have been positive. The laboratory setup has
received favorable reviews from the students. In a survey of one of the classes,
students were asked to rate the laboratory as either, not very convenient,
satisfactory, or very convenient. Of 39 students responding, 28% said that
it was satisfactory, 72% said it was very convenient, and none said it was,
"not very convenient". In another class, 48 students responded to the survey
with 29% claiming the lab was satisfactory, 67% saying it was very convenient,
and only 4% saying it was, "not very convenient". One student commented,
"[It's] more convenient being able to have access to everything from anywhere."
The Advanced Microcontroller Laboratory is undergoing further
development. There is work being done on an interface that would allow students
to remotely perform microcontroller interfacing experiments by allowing them
to monitor and manipulate the states of the various ports on the microcontroller
via the network. When this work is finished, this would provide a complete
Microcontroller Laboratory on the Internet.
In conclusion, the Advanced Microcontroller Laboratory is a
low cost solution to many of the problems associated with supporting a
microcontroller lab. The simple, modular, and scalable design of the Advanced
Microcontroller Laboratory allows it to be tailored to the needs of any
microcontrollers or related course. It combines the best qualities of a
simulator-based lab and an evaluation board based lab to provide superior
access to equipment without hampering the types of experiments that are possible.
Using an Advanced Microcontroller Laboratory allows students
to face the challenges of writing a round robin process scheduler, driving
a pop-can mounted on a stepper motor, or controlling an LED display. And
because of the potential of this advanced lab, students may perform these
experiments using an inexpensive X-Window station that is housed in their
room while accessing evaluation boards that are hosted hundreds of miles
away.
Students who, in a survey, agreed that the lab was a very convenient
way to access laboratory equipment have substantiated our claims that the
Advanced Microcontroller Laboratory is a superior. Because of this, we feel
that the Advanced Microcontroller Laboratory would be a worthwhile investment
for any institution offering courses in microcontrollers.
[Greenfield 1992] Greenfield, J.D. (1992). The 68HC11
Microcontroller. USA: Saunders College Publishing
[Wakerly 1989] Wakerly, J.F. (1989) Microcomputer Architecture
and Programming. USA: John Wiley & Sons, Inc.
[Burcin and Bohus, 1996]. Burcin, A., & Bohus, C., et al.
(1996). Distance Learning Applied to Control Engineering Laboratories: IEEE
Transactions on Education, 39 (3), 320-326.
[Infanger 1998] Infanger, B.D. (1998). Masters Thesis: A
Microcontroller Laboratory on the Internet. Fargo, ND: North Dakota State
University (in preparation)