Lab 8: Parallel Port Interface
In Lab 8, we will write (modify) C programs to interact with our
digital-to-analog converter (DAC) we built in Lab 7. First we will rig a
solder-cup DB-25 male connector to
fan out the digital outputs to the
FET inputs of the DAC. Then we'll test the C-programming interface in
stages, ultimately creating our own wacky waveforms.
The reason we used FETs in the DAC circuit is that the output voltages
of the parallel port are unreliable/unknown, and could even vary from
pin-to-pin. The FETs let the parallel port output simply switch in a
well-defined 5 V. The parallel port also drives the LEDs directly, so
don't be surprised if some light up even before the power supply is turned
on.
The Actual Lab
Some of the instructions below are less than fully descriptive. You are
left to figure some things out on your own.
Editing and compiling the code
- Make a folder/directory somewhere within your "My Documents"
tree with some relevant name to today's task.
- Start the Bloodshed Dev-C++ application from the start menu.
- Open a new source code in Bloodshed Dev-C++.
- Type in the code you want to try.
- Save As (pick *.c extension from droplist), etc. If you pick
the .c extension, this will be put on automatically. Save into the
the folder/directory you made earlier.
- Compile the program.
- Note that running the program from Bloodshed Dev-C++ may appear not to work,
especially if you're looking for printed output. If you're vigilant, you
might see a DOS window pop up for a millisecond with the output, then
disappear. But let's make the output more permanent:
- Open an MS-DOS command prompt (under Accessories).
- You should be in H:\, which is your My Documents directory.
- Type dir to see the contents.
- cd parportor equivalent command to switch into your
directory. Use dir to make sure the correct contents are there.
You should see the programs (with .c extensions), and the executables
(.exe extensions, if compiled).
- To run, type something like: try_prog.exe, including any
command-line arguments the program wants.
Lab Procedure
- On a male DB25 solder-cup connector, solder 6-to-8-inch leads (stripped
at both ends: keep stripped portion short (1/8-inch) on solder-cup end) to
pins 29 for the data bits. Also solder a similar-length wire to an
unused ground pin (e.g., 25).
- Connect the assembly to your DAC breadboard. Pin 2 is the least
significant bit (LSB). Connect each lead to the appropriate FET input, and
the ground lead to the board ground. We have a bunch of 10-foot DB-25
cables to hook to the computers' parallel ports.
- Try a test program to send a fixed value between 0 and 255 (expressed
in decimal or hex in the C-program) to the parallel port. See that the
LEDs on the inputs light up in the correct pattern. Once you accomplish
this feat, you are home-free. It may take you some time to get this right.
You can use the template in the lecture notes (lean and mean version:
typing in yourself gives you more of a sense that you made it all
happen), or you can use this more fleshed-out prototype and edit to taste.
- Now create a new program that will accept an integer command-line argument
(between 0 and 255) and present this single value to the parallel port.
Once this is running, send a variety of values and verify that the patterns
are correct. You can enter values in hex if the sscanf command
has a "%x" instead of the usual decimal "%d" format code.
- Use your new program to verify the DAC operation using a DVM. Sending
255 should yield the full-scale voltage. Take this opportunity to adjust
the pot to give you the desired full-scale voltage. See that you get
appropriate output voltages depending on the integer value you request.
- Now make a third program that takes a floating point argument, checks
that it is within range (exiting if not), converts to the appropriate
integer value, and sends this to the DAC. The goal is to get the DAC to
put out the voltage you ask for. It may not be exact, as the
output is confined to a discrete number of possibilities. But you can
check that you are within the step-size.
- Make a fourth program to cycle through a set of integers in such a way
as to make a ramp (like the example from class). Watch the output on the
oscilloscope. Note the period, and calculate the time per step/update.
If you zoom in, you should be able to see individual steps. If triggering
of the scope is jumpy, you may have some spikes in your waveform. See the
tip below to fix this condition. Check the amplitude and make sure it's
full-scale. If the slow-rising side is not perfectly uniform/straight,
then you may have a DAC problem (resistor values, bad/mis-placed FET,
etc.). Fix it up if this is the case. It could also be a mis-routing of
the 8 parallel bits to your FET inputs. In fact, it may be instructive to
switch two inputs to see what shape results in the waveform. Could get
funky.
- With the ramp waveform running, move the mouse and see what happens.
Drag a window around. Start a web browser. What happens? Why?
- When the ramp is running, trigger on the negative-going (fast) side,
and expand the time scale until you can measure the slew rate of the
op-amp. Express in volts per microsecond, and compare to the specification
for the op-amp. If you've rigged the low-pass filter according to the tip
below, temporarily remove it for this measurement.
- Now be creative. Make a new program that puts out an
"interesting" waveform of your
choosing/designsomething a function generator cannot do.
But think it out well enough in advance that you can successfully program
the wave function in C. Math is good. Sure, you could draw a row houses,
but this is hard to describe in a C-program (though the more ambitious may
trycan even try a chimney!). Anyway, come up with something you're
happy with.
Tips
- Keep your programs separate rather than continually modifying the same
one. This way you can include listings of each in your write-up, and also
re-use them if necessary.
- A multiple of 2.55 V for the full scale makes the
stepsize a convenient multiple of 10 mV.
- To eliminate spikes (which are likely due to a momentarily
indeterminate state on the parallel port as it switches from one value to
another), first look at the step size. Figuring you want to keep this feature,
but eliminate spikes, pick a resistor/capacitor combination whose RC time
constant is about ten times shorter than the step size. Use a resistor in
the 1kΩ100kΩ range and the associated capacitor in a
low-pass arrangement (R between output and scope and C from scope and
ground). This should eliminate spikes and keep the steps, allowing for
more robust triggering. Do not try to characterize slew rate with the
capacitor hooked up, however.
Lab 8 Write-up
The write-up for Lab 8 is to be combined with a writeup of Lab 7. For this segment, include program listings,
sketches of waveforms, and all numbers/calculations and descriptions
requested in the sections above. Include example inputs/outputs of your
programs. For example, if you put in the floating point request for 1.357
volts, what voltage do you read on the DVM. Give enough examples to be
convincing.
Alternative (LPT) approach to the parallel port interface:
If you want to run the parallel port without using the inpout32
bridge over the hardware abstraction layer (HAL), you can try the LPT
method mentioned in the lectures. This results in a simpler-looking
program, but is actually slower because each write must open, write, then
close the file handle.
To get this technique to work, you'll need to fool the windows machine
into thinking it's connected to a printer, ready and waiting. To do this,
tie pins 11 and 12 to ground (pins 1825). Solder little loops to go
from the appropriate solder cups to the ones just below (8 in a row are
ground).
Back to Physics 121 page