CUSTOM WINDOWS NT 4.0
PARALLEL PORT DEVICE DRIVER
A COMPONENT OF A NETWORK PERFORMANCE
MEASUREMENT TOOL
By
Angel Yu
Senior Project
Computer Engineering Program
California Polytechnic State University
San Luis Obispo
1998
Table of Contents
Acknowledgements ...................................................................................................i
Abstract....................................................................................................................ii
1. Introduction ......................................................................................................1
1.1. Senior Project Report Review.......................................................................1
2. Background .......................................................................................................2
2.1. Cal Poly–3Com Network Testbed for Network Performance Measurements.22.2. Problem of Measuring Network Latency in NT Environment .......................32.3. Use of Parallel Port Signal and PCI Instrumented with Logic Analyzer ........4
3. Requirements for a Parallel Port Driver..........................................................6
3.1. What is a Parallel Port?.................................................................................63.2. Interface with Windows NT..........................................................................83.3. Performance ............................................................................................... 10
4. Development Process....................................................................................... 10
4.1. Reference to Baker Driver .......................................................................... 104.2. Use of Microsoft DDK and SDK ................................................................ 114.3. Final Development Procedure Used............................................................ 11
5. Design of NT Parallel Port Driver .................................................................. 12
5.1. Software Design for Interface to NT Software ............................................ 125.2. Software Design for Interface to Parallel Port Hardware Signals................. 135.3. User Interface to Parallel Port Signal Function............................................ 14
6. Installation of Driver....................................................................................... 17
6.1. Installation Procedure ................................................................................. 176.2. Installation Configuration Considerations ................................................... 19
7. Testing of NT Parallel Port Driver and User Interface ................................. 20
7.1. Test Plan and Procedure ............................................................................. 207.2. Test Results ................................................................................................ 22
8. Alternate Approach ........................................................................................ 23
8.1. Existing Parallel Port Driver with Peek and Poke Functions........................ 238.2. User Interface to Peek and Poke ................................................................. 238.3. Testing ....................................................................................................... 23
9. Recommendations for Future Work .............................................................. 25
9.1. Parallel Port Driver..................................................................................... 25
10. Conclusions .................................................................................................. 26
10.1. Summary of Results of Senior Project ..................................................... 26
Biblography ........................................................................................................... 27
Appendices............................................................................................................. 28
A Alternate Approach Source Code
B Graphical User Interface using Borland C++ Builder
C Test Results from Alternate Approach
List of Tables
Table 1: Parallel Port Registers..................................................................................7
Table 2: Status Register .............................................................................................8
Table 3: Control Register...........................................................................................8
Table 4: Functions for Interface to NT Software...................................................... 12
Table 5: Test Procedure........................................................................................... 21
Table 6: Parallel Port Pin Assignments .................................................................... 24
Table C1: Parallel Port Output Values ..................................................................... 31
List of Figures
Figure 1: Configurations to measure network performance ........................................2
Figure 2: OSI Network Model ...................................................................................5
Figure 3: Interface Layers........................................................................................ 15
Figure 4: GUI for Parallel Port Signal Test .............................................................. 16
Figure 5: BUILD Directory Path.............................................................................. 18
Figure 6: Registry Directory .................................................................................... 19
Figure 7: Parallel Port Physical Pin Out ................................................................... 24
Figure 8: Parallel Port Bit Shifting........................................................................... 25
i
Acknowledgements
First of all, I would like to thank my advisor, Dr. James Harris. His encouragement,
support, and guidance throughout the project have been invaluable. His never-ending
passion to learn has inspired me and will keep me motivated throughout my career in
college and in industry. I would also like to thank Brian Hemme, a Cal Poly graduate
for his willingness to always help. His experience with Windows NT drivers was very
beneficial and he provided a multitude of resources.
This project is supported by 3Com, Inc.
ii
Abstract
Measuring network performance from a user’s perspective mainly involves response
time. To study the response time of the network, an investigation must be conducted
on the time it takes for each network layer to encapsulate the data. The investigation
will require a tool that will measure the network performance. As a step towards
developing a network performance measurement tool, this project proposes to
develop a parallel port driver that will send a signal level change to the parallel port.
A logic analyzer can be attached to the parallel port and can be configured to trigger
on the signal level change. By generating a signal to the parallel port immediately
before a write request to the server, the network latency can be determined from the
logic analyzer data.
1
1. Introduction
1.1. Senior Project Report Review
From the perspective of a network user, the most important performance criterion is
response time to the user’s request for data. Responses less than ten milliseconds will
not be perceived by a human, and responses as long as one hundred milliseconds may
even be acceptable. However, in the marketplace, the two measures of client adapter
performance are throughput and client computer central processing unit (CPU)
utilization. These measurements are fine for network design but do not address the
user’s performance criteria.
To study the response time performance of the network, the computer architecture
model for CPU/memory will be applied. The user of the client computer will take on
the role of the CPU. For non-real-time data requests, using cache memories should
improve the response time performance. The ultimate goal of this project is to
participate in the investigation of maximizing network performance through network
caching. A step toward this goal is to develop a driver for the Windows NT 4.0
operating system that will provide a parallel port signal for the measurement of the
network latency. This senior project consists of the development of this parallel port
driver.
2
2. Background
2.1. Cal Poly – 3Com Network Testbed for Network Performance Measurements
3Com has provided a testbed that consists of a five-computer Ethernet network with
100/10 Mbps hubs and adapter cards. With the assistance of 3Com and Intel, the
testbed will also contain an iq-sdk development system. This testbed will be used to
take network performance measurements. Comparisons of network performance will
be made on two configurations (Figure 1): 3Com driver installed on the NT operating
system (Network Driver Interface Specification, NDIS) and driver installed on the
i960 processor of the iq-sdk development system with the ported driver from the NT
operating system (Intelligent Input/Output, I20).
Figure 1: Configurations to measure network performance
3Com NIC
Windows NTOperating
System
3Com
PCI Bus
(a) NDIS configuration
3Com NIC
Windows NTOperating
System
LANOSM
PCI Bus
DDM
HDM
PCI Bus
(b) I20 configuration
3
2.2. Problem of Measuring Network Latency in NT Environment
Performance as defined by a user is not based upon how fast a system can respond to
a series of requests (i.e. throughput) but how fast it responds to an individual request.
It is suggested that the latency of the system handling user-initiated events, such as
keystrokes, is a better measurement for user-perceived performance [10].
As discussed in Endo and Seltzer [10], because a user can spawn multiple
applications, the only parties who know when event-handling begins and ends are the
user and the applications. Since users' perceptions vary from user to user, the reliable
source of data is the application. There are three different methods for obtaining data
from the application. First, it could measure its own latency. This probably provides
the most accurate data but it would require access to the application's source code.
Another technique is to use interposition to intercept every application call and
deduce the event latencies. This method is error-prone due to the interpretation of the
trace. The last technique requires the operating system to try to extrapolate the
beginning and ending times of events. All of these approaches are not feasible since
they require the Windows NT source code and it is not available.
Endo and Seltzer [10] also noticed another component of response time that is not
even included in the above techniques is the time that the system spends delivering a
hardware event (i.e. keystroke) to the application. Event-delivery time measurement
is based upon time-stamping every keyboard and mouse interrupt. This can be
4
accomplished by modifying the drivers. However, to associate a higher-level event
delivered to the application with a keystroke or mouse-click requires access to the
operating system source code. As input is processed, the path that is executed must be
traced with check points.
From the two cases above, it is clear that measuring the latency between a user
request and an application reply is difficult without operating system/application
source code. Applying this to the network protocol stack, there will not be a feasible
way to measure the latency at the application layer, let alone the whole protocol stack
itself. However, the tool that is proposed in this senior project avoids depending on
the source code.
Instead of measuring the network latency within the kernel or application, this tool
will seek measurements using signals from the parallel port and from data provided
by the PCI bus. The tool will consist of a logic analyzer that can monitor data across
the bus and a user interface to the parallel port.
2.3. Use of Parallel Port Signal and PCI Instrumented with Logic Analyzer
Open Systems Interconnect (OSI) Network Model
The OSI model consists of seven layers in its protocol stack: physical, data link,
network, transport, session, presentation, and application as shown in Figure 2. Each
machine has a protocol stack that conducts the transmission of data packets between
5
other machines. The packets travel through the layers. When a machine sends a data
packet, as it travels through a new layer, it is encapsulated with information specific
to that layer. Similarly when a machine receives a data packet, it also travels through
the protocol stack. As it passes a layer, the information specific to that layer is
stripped.
Figure 2: OSI Network Model
The first step is to understand the nature of network performance. For example, when
a client makes a request to a server through a network, the user experiences a delay.
This delay is the time it takes for the server to respond. The request travels from the
client working its way through the protocol stack (starting from the application layer
to the physical layer). At the server end, the request travels from the physical layer to
the application layer. The server's response must also travel back through its protocol
stack and back through the client's protocol stack. The response time depends on how
much time is spent in the layers of the network and how busy the machine is.
Network LayerApplicationPresentationSessionTransportNetworkData LinkPhysical
High Level Layer
Low Level Layer
6
A tool will be developed to measure the time spent in attaching each layer of the
network to each data packet. Using the logic analyzer, the packets can be monitored
from the PCI bus. At the application level, the client will send a signal (a signal level
change, such as a clock transition) to the parallel port just before initiating a request
to the server. The logic analyzer will be able to trigger on the signal. Using the logic
analyzer’s absolute timing mode, the time it takes for the request to travel through the
NT system is measured. In other words, this tool can measure the latency from the
parallel port signal (i.e., the application request to the network) to the very first data
packet of the user request as it appears on the PCI bus, i.e. response time.
3. Requirements for a Parallel Port Driver
3.1. What is a Parallel Port?
The parallel port was originally designed for the printer. The port was used to
communicate with printers. Today, however, many devices can be accessed through
the parallel port. Devices such as optical scanners and disks are attached to the
parallel port. Because the parallel port is traditionally used for the printer, the
following sections refer to the printer as the device that is attached to the port.
Physical Component
The DB-25 connector supports many signals. The most important ones are listed
below:
7
Initialize – The CPU requests the printer to be initialized.
Data – There are eight lines for data. The CPU sends a byte of data to theprinter using these eight lines.
Strobe# – The CPU informs the printer that valid data is ready on the datalines. This signal is active low.
Busy – The printer informs the CPU that it cannot accept any data at thisinstant.
Ack# – The printer informs the CPU that it is no longer busy. This signal isactive low.
Errors – The printer may use many lines to inform the CPU of any errors.
Software Interface
There are three eight-bit registers that provide the software interface to the parallel
port. One register is located at the base address and the other two registers are located
at consecutive addresses (See Table 1). In Windows NT, the addresses are 0378H-
037AH, with the data register at 0378H (the base address), the status register at
0379H, and the control register at 037AH. The details of the status and control
registers are described in Table 2 and Table 3, respectively.
Table 1: Parallel Port Registers
Offset from BaseAddress
Register Access Description
0 Data Read/Write Byte of data transferred1 Status Read Only Current status of parallel port2 Control Read/Write Commands sent to parallel port
8
Table 2: Status Register
Bits Description0-1 Reserved (normally contain 1)2 0 – Interrupt requested by port3 0 – error occurred4 1 – printer is selected5 1 – printer is out of paper6 0 – acknowledge7 0 – printer is busy
Table 3: Control Register
Bits Description0 1 – strobe data to/from parallel port1 1 – automatic line feed2 0 – initialize printer3 1 – select printer4 1 – enable interrupts5 0 – Reserved6-7 1 – Reserved
Parallel Port Driver
The main function of the parallel port driver is to manage data transfers and control
operations for printers. Writing to and reading from the three parallel port registers
have many effects such as, data transfers, printer requests, port and printer status, and
printer commands. However, for this senior project, the parallel port will not have any
device attached to it, except for the logic analyzer. The project will only require a
means to send a signal to the parallel port and also to read its status.
9
3.2. Interface with Windows NT
The parallel port driver alone does not access the parallel port. To “talk” to the
parallel port, the user must be able to communicate with the driver. A module must be
created to guide the user’s requests through the Windows NT operating system to the
driver. The application programming interface (API) is designed and implemented for
this purpose. With any Windows operating system, Microsoft Win32 API is used.
Microsoft Win32 Application Programming Interface
Win32 API is the standard programming interface for Windows NT [6]. Programmers
use 32-bit addresses, instead of the old 16-bit addresses used in earlier versions of
Windows.
Win32 basically consists of five categories [9]:
1. Windows Management
2. Graphics Device Interface (GDI)
3. System Services
4. Multimedia
5. Remote Procedure Calls (RPCs)
For this senior project, only one of these categories is used: Windows Management.
For details on the remaining components see the Win32 development web page [9].
10
The purpose of Windows Management is the development and management of a user
interface. An interface can be designed to prompt for input, display output, etc.
Applications must also be able to control the interface. In order to do this, the
application creates a window class with corresponding window functions. The class
and its functions comprise the user interface.
3.3. Performance
Due to the API, another layer is added to the many layers that are to be measured.
This may add more latency between initiating a request to the server and receiving a
response. However, for the time being this is not a problem; relative measurements
will be taken for each platform configuration. Ultimately, the API latency, if any, will
be stripped from the final measurements.
4. Development Process
4.1. Reference to Baker Driver
The Windows NT parallel port device driver runs in kernel mode. This kernel-mode
driver is a collection of subroutines that are called as needed by the input/output (I/O)
manager. Some of the subroutines include driver initialization and cleanup routines,
I/O system service dispatch routines, and data transfer routines. The Windows NT
Device Driver Book [1] provides a detailed example of a parallel port device driver.
11
To understand the development process, the parallel port driver code provided by
Baker was compiled. The final product was installed on one of the machines in the
testbed.
4.2. Use of Microsoft DDK and SDK
Because of the non-trivial nature of Windows NT device drivers in general, Microsoft
provides a Device Driver Kit (DDK) [4]. The DDK contains sample code for many
types of device drivers. It also contains many utilities for device driver development.
The general I/O port driver provided by the DDK can be applied to the parallel port
driver.
Microsoft also provides a Software Development Kit (SDK) [5], which provides
libraries and sample code to develop Win32 APIs.
4.3. Final Development Procedure Used
The parallel port used for this project is based on Baker’s parallel port driver. The
initial stages consist of using Baker’s driver, which includes additional functionality
that is not needed. However, as the code for the parallel port driver is understood
more, the functions that are not needed are to be excluded to make the driver more
efficient.
12
The API is created by using the SDK and the Microsoft’s web page on Win32 API
development [9].
5. Design of NT Parallel Port Driver
5.1. Software Design for Interface to NT Software
Proposed Routines
The interface to the NT software is basically a program that communicates with the
I/O control layer of NT. The functions in this layer control the I/O manager, allowing
interaction with the parallel port driver. The program is based upon four proposed
routines that call the I/O control layer functions: Init, GetByte, PutByte, and Kill.
Table 4 describes the functions in detail.
Table 4: Functions for Interface to NT Software
Function DescriptionInit Initializes connection to the parallel port driver, creating “handle” to the
driverGetByte Reads a byte from the parallel port*PutByte Writes a byte to the parallel portKill Terminates connection to the parallel port driver* Used for testing purposes only
13
Current Status
The parallel driver is installed on one of the machines in the testbed. However, all of
its functionality cannot be tested since a file handle could not be created for the
driver. See section 7.2 for details.
Proposed Direction
An existing driver for an input/output port modified from the DDK is up and running
on machines outside of the established testbed. A possible approach to determine the
file handle name is to compare the DDK driver to Baker’s driver. A detailed analysis
should be performed on the sections of code containing how the file handle is created.
Another possibility is to research Win32 API for function or procedure calls that can
provide an interface directly to the driver.
5.2. Software Design for Interface to Parallel Port Hardware Signals
The interface to the parallel port hardware is the driver itself. The routines in the
driver are called by the I/O Control functions as described in section 5.1.
As seen in Baker [1], there are many parts that comprise the driver. The “init.c” file
contains all hardware initialization and setup routines. It contains a routine called
“DriverEntry.” This code is executed when the driver is loaded onto the machine. The
routine initializes the driver, sets up the hardware resources needed by the driver, and
14
creates the objects needed to process I/O requests. DriverEntry calls another function
“XxCreateDevice” which is the module that actually carries out the hardware
initialization.
The “transfer.c” file contains three main routines that are relevant to this parallel port
application [1]. The first routine “XxStartIo” completes any processing needed before
the actual transfer of data. It also initiates the transfer. The routine
“XxTransmitBytes” actually transfers the bytes to the parallel port.
The “unload.c” file contains routines that make the driver unloadable. The main
routine “XxReleaseHardware” basically undoes the initialization, i.e. undoes the work
from “DriverEntry.” This procedure is also executed by parts of the driver
initialization since both routines need to perform the same cleanup. See Baker [1] for
more details on unloading the driver.
5.3. User Interface to Parallel Port Signal Function
Proposed Interface
A graphical user interface (GUI) is provided to initiate a signal to the parallel port. It
is basically a Win32 API (see Section 3.2). It contains two buttons. One button
generates a signal level change to the parallel port only.
15
The other button is used to initiate the signal level to the parallel port and initiate a
request (client writes a file to the server). The request generates a FTP socket using
Winftp and begins transferring a file to the server [3]. This provides an easy way for
the user to accomplish both tasks with one button click. Of course, there is still some
latency between generating the signal and issuing a request. However, with this
method, the latency would not include human reaction time, since a request would be
initiated automatically after the parallel port signal is initiated.
The user interface is essentially the interface to the NT software, as described in
section 5.1. The only difference is that it provides a graphical interface instead of a
console interface. Figure 3 shows the different interfacing layers.
Figure 3: Interface Layers
Current Status
Using Borland C++ Builder, a GUI was created. It has been altered many times for
the testing phase of the Parallel Port I/O for Windows NT [7] (see section 8).
Currently it contains a memo box, edit box, and a button (see Figure 4). The GUI
GUI
Interface to NT Software
Parallel Port Driver
16
allows the user to enter the value (signal) to send to the parallel port in the edit box.
When the button is pressed, the value (signal) in the edit box is transferred to the
parallel port. The memo box displays status messages for testing purposes only.
Figure 4: GUI for Parallel Port Signal Test
Proposed Direction
The next step is to develop buttons to generate signal level changes. One button will
be used to generate a low-to-high-to-low level change and the other will be used to
generate a high-to-low-to-high level change. The logic analyzer will then be able to
trigger on either one of these signal level changes.
After implementing the buttons for the signal level changes, the button to generate a
signal change and send a write request to the server may also be implemented.
17
6. Installation of Driver
6.1. Installation Procedure
Once the source code of the parallel port driver is developed, it must be “built”. The
BUILD utility provided by the DDK is basically a wrapper for NMAKE. BUILD
forms appropriate NMAKE commands from the source files. Then it runs NMAKE
which constructs one or more BUILD products (binary output files). There are
CHECKED and FREE versions of the binaries. CHECKED builds are basically used
for debugging; they contain extra debugging information. Binaries compiled with
optimization are called FREE builds. They are smaller, faster, and should be used for
final release of the driver.
To build the driver executable, the following steps should be taken:
1. In the same directory where the source code is, create a file called SOURCES,
which identifies the parts of the final driver. The SOURCES file consists of
keywords that specify the type of driver to be generated, the source files that
make up the BUILD product, and directories for files. See Baker's book for the
details on the keywords and the SOURCES file format.
2. Create another file called MAKEFILE in the same directory. MAKEFILE should
only contain the line: !INCLUDE $ (NTMAKEENV) \MAKEFILE.DEF This file
should not be modified in any other way. It invokes the standard makefile that is
needed by any driver created with BUILD.
18
3. A directory tree must be created. As shown in Figure 5, subdirectories
CHECKED and FREE are created under subdirectory i386.
4. Set the environment variables of the CHECKED and FREE directories for either
the debug or final release of the driver, respectively.
5. Move to the directory that contains the SOURCES file.
6. Run the BUILD utility. The driver (“.SYS” file) will be in either the CHECKED
or FREE subdirectory.
Figure 5: BUILD Directory Path
After building the utility, the executable driver must be copied to the device driver
directory. Using the Windows NT Explorer, change to the \SYSTEM32\DRIVERS
directory. Copy the .SYS file into the DRIVERS directory.
The driver must also be entered into the Registry. Specific Registry keys and values
must be set. Edit the Registry by opening the RUN command from the startup button
and type in "REGEDT32" to start the utility. After arriving at the subdirectory
CurrentControlSet by following the directory path as shown in Figure 6, the name of
(TARGETPATH)
i386
CHECKED
FREE..
19
the driver must be entered. This is done by selecting "ADD" and then "KEY." Values
should be added to the key also. This is done by again selecting "ADD" and then
"VALUES." The required values are shown in Figure 6 (ErrorControl, Start, and
Type). For details description of key values and optional key values, see Baker [1].
After entering the driver into the Registry, the machine must be rebooted. Then the
driver should now be recognized by the system.
Figure 6: Registry Directory [1]
6.2. Installation Configuration Considerations
After rebooting the system, this parallel port driver should be set up so that it is the
only driver started for the parallel port. This can be done by changing its startup
properties. From the Start menu, select Settings and then click on Control Panel.
From the Control Panel menu, click on Devices. A window is opened, which displays
HKEY_LOCAL_MACHINE
System
CurrentControlSet
(Device driver name)
ErrorControl: REG_DWORD: 0x1Start: REG_DWORD: 0x3Type: REG_DWORD: 0x1
20
a list of devices along with their status and startup configuration. If another parallel
port device has been started, its status will be listed as “Started”. Its status must be
changed. To stop any other device, select the device and click on the Stop button on
the right-hand side of the window.
This parallel port driver may also be setup to start automatically or manually. For this
driver, the startup configuration is set to automatic by clicking on the name of the
driver and then selecting the Startup button. A new window appears that displays a
list of different startup options. From the Devices window, a selected device may be
started or stopped using the associated buttons located on the right-hand side of the
window. All other devices that use the parallel port may have an automatic
configuration but they cannot all be started at the same time.
7. Testing of NT Parallel Port Driver and User Interface
7.1. Test Plan and Procedure
Without some kind of an interface between the NT software and the parallel port
driver, the driver is virtually unusable. Therefore, an interface is essential. Because it
is the link between the user and the actual parallel port driver functions, it will
provide a means to test the driver functions.
The first step is to test the routines (that are relevant to driving a signal to the parallel
port) provided by Baker [1]. The Table 5 below lists the various conditions to be
21
tested. In order to test some of these routines, the interface to NT software includes
additional features that are not needed for the measurement tool itself. These features
will be removed once testing is complete.
The next step is to test the graphical user interface with a "dummy" routine. This will
ensure that when a user does click on a button, the event (button click) will be
registered and call the specified routine.
Table 5: Test Procedure
Pass Fail Description CommentsDriver is loaded successfullyDriver is initialized successfullyDriver writes to the control registersuccessfullyDriver transmits a byte to the parallelport successfullyDriver reads the status registersuccessfullyWhen the driver is stopped, its isunloaded successfully
Finally, the graphical user interface will be integrated with the interface to NT
software. For example, when a user clicks the button to send a signal to the parallel
port, the button click will call the routine that will actually initiate the signal. After
obtaining successful results for this test, the other button can be tested. Clicking on
22
the second button should call the routine that sends the signal to the parallel port,
generates a socket to the server, and sends a file to the server.
7.2. Test Results
The parallel port driver was loaded and unloaded successfully. However, problems
arose when initializing the driver. When a driver is registered, the system references it
with a file name, i.e. file handle. In Baker's code, the name should be "xx1." But
when this name was used in the test program, no connection was established between
the test program and the parallel port driver.
Another test program was created to try to decipher the file name. It produced every
possible combination of printable characters, starting with one character up to sixteen
characters. After running this for two days, the program was still processing for 5
character words. Three file names were successful in connecting the driver and the
test program: "con" "nul" and "ndis." However these file names are irrelevant to the
parallel port driver. Due to these unsuccessful attempts at finding the file handle, the
driver initialization could not be tested.
This problem led to another strategy: there may be an existing utility that allows a
user to read and write to the parallel port addresses directly (see section 8). By using
this approach, the file handle problem can be avoided.
23
8. Alternate Approach
8.1. Existing Parallel Port Driver with Peek and Poke Functions
After searching the internet, a parallel and input/output port driver for NT that allows
direct access to the ports' addresses was found [7]. The utility only contains variations
of 1-byte, 2-byte, and 4-byte peek and poke functions. It can access the three registers
(data, status, and control) of the parallel port.
The utility is loaded and ready once it is installed (using the loader provided); the
system does not need to be rebooted. Also the included dynamic link library must be
placed into the "system32" directory. See [7] for more details on installation.
8.2. User Interface to Peek and Poke
The next step consisted of developing a user interface to the parallel port signal
function. Using Borland C++ Builder, a GUI was created. The GUI contains one
button that sends the data value to the parallel port and an edit box, which allows the
user to specify a value to send.
8.3. Testing
For test purposes, initially a button was created to send a value of 0xFF to the parallel
port. When the parallel port was connected to a logic analyzer, the data pins (see
Figure 7 and Table 6) had all high outputs. Therefore writing to the parallel port was
successful.
24
1 2 3 4 5 6 7 8 9 10 11 12 1314 15 16 17 18 19 20 21 22 23 24 25
Figure 7: Parallel Port Physical Pin Out [11]
Then the GUI was enhanced to accept a decimal value to send to the parallel port.
However, unexpected results occurred. For the value 0, the logic analyzer displayed
high outputs for the three most significant bits of the data register while the rest were
low.
Table 6: Parallel Port Pin Assignments (See [8] for more details on lines)
Pin Number Line Pin Number Line1 #Strobe 10 #Ack2 Data0 (LSb) 11 Busy3 Data1 12 Paper Empty4 Data2 13 Select5 Data3 14 #Auto Feed6 Data4 15 #Error7 Data5 16 #Initialize8 Data6 17 #Select In9 Data7 (MSb) 18-25 Ground
These unexpected results led to further testing. It turns out that for the range 0-7 the
data register contains the same value. Other numbers were also tested. The range 8-15
resulted in high outputs for the three most significant bits and the least significant bit,
25
while the others were low. A pattern had developed for other numbers that were
tested. The three least significant bits in a nibble of the value to be written to the
parallel port were being ignored. The ignored bits were reflected in the three most
significant bits on the parallel port itself. The value is shifted to the right three times
and then three most significant bits become high outputs on the parallel port (See
Figure 8).
Values greater than decimal 255 should not be used since the tool only needs to send
an 8-bit signal level change to the parallel port. The GUI is developed to read only
one byte of data from the edit box.
Bit Contents a7 a6 a5 a4 a3 a2 a1 a0
Bit Address 7 6 5 4 3 2 1 0a. Bits 0-2 are ignored. Each bit is shifted to the right three times.
Bit Contents 1 1 1 a7 a6 a5 a4 a3
Bit Address 7 6 5 4 3 2 1 0b. After the shift, “1” is shifted in on the left to replace the three bits that were
ignored.
Figure 8: Parallel Port Bit Shifting
9. Recommendations for Future Work
9.1. Parallel Port Driver
As stated earlier, the parallel port driver provided by Baker [1] is installed on one of
the machines in the testbed. However, Baker’s parallel port driver includes printer
26
functionality, which is not needed for this tool application. As a future goal, Baker’s
driver should be stripped, leaving the basic functions for a driver (initialization, clean
up, etc). Also a function should be implemented to generate a signal change to the
parallel port, i.e. a simple function that will transmit bits.
10. Conclusions
10.1. Summary of Results of Senior Project
The initial proposal to develop a parallel port driver for the instrumentation of a
measurement tool was not accomplished as planned. There were many complications
with Baker's driver. However, a basic understanding of the complex process involved
with device driver development was gained.
Although the reason why the new parallel port driver manipulates some bits is not
understood, it does perform the function that is required for this measurement tool. It
is capable of sending a recognized bit pattern to the parallel port. As shown in Section
8.3, the logic analyzer can recognize the parallel port signal.
27
Biblography
[1] Baker, Art, The Windows NT Device Driver Book, Upper Saddle River, NJ. Prentice-
Hall, Inc., 1997.
[2] Hsu, John, Computer Networks: Architecture, Protocols, and Software, Norwood,
MA. Artech House, Inc., 1996
[3] Liang, Yu, “Network Latency Measurement for I2O Architecture”, June 1998.
[4] Microsoft Corporation, DDK Platform, Microsoft Developer Network, Redmond,
Washington. January, 1996.
[5] Microsoft Corporation, Win 32 SDK, Microsoft Developer Network, Redmond,
Washington. January, 1996.
[6] Newcomer, Joseph M., and Rector, Brent E., Win32 Programming, Reading,
Massachusetts. Addison Wesley Longman, Inc., 1997.
[7] Parallel Port I/O for Windows NT
http://www.tmo.hp.com/tmo/pia/HPVEE/PIANews/software/English/HPVEE_Win3
2_NTPPIO.html
[8 ] Pinouts for Various Connectors in Real Life
http://margo.student.utwente.nl/stefan/el/componen/fpinout2.html#PINOUTS_006
[9] Win32
http://www.microsoft.com/win32dev
[10] Endo, Yasuhiro, and Seltzer, Margo, "Measuring Windows NT - Possibilities and
Limitations", USENIX Windows NT Workshop, August, 1997.
[11] Zip Parallel Port Cable Pin-out
http://www.iomega.com/support/techs/zip/2079.html
28
Appendices
A Alternate Approach Source Code
See [7].
B Graphical User Interface using Borland C++ Builder
File: “test2.cpp”//---------------------------------------------------------------------------#include <vcl\vcl.h>#pragma hdrstop//---------------------------------------------------------------------------USEFORM("ppsig.cpp", Form1);USERES("test2.res");//---------------------------------------------------------------------------WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int){
try{
Application->Initialize();Application->CreateForm(__classid(TForm1), &Form1);Application->Run();
}catch (Exception &exception){
Application->ShowException(&exception);}return 0;
}//---------------------------------------------------------------------------
File: “ppsig.h”
//---------------------------------------------------------------------------#ifndef ppsigH#define ppsigH//---------------------------------------------------------------------------#include <vcl\Classes.hpp>#include <vcl\Controls.hpp>#include <vcl\StdCtrls.hpp>
29
#include <vcl\Forms.hpp>//---------------------------------------------------------------------------class TForm1 : public TForm{__published: // IDE-managed Components
TMemo *Memo1;TButton *Button1;TEdit *Edit1;void __fastcall Button1Click(TObject *Sender);
private: // User declarationspublic: // User declarations
__fastcall TForm1(TComponent* Owner);};//---------------------------------------------------------------------------extern TForm1 *Form1;//---------------------------------------------------------------------------#endif
File: “ppsig.cpp”
//---------------------------------------------------------------------------#include <vcl\vcl.h>#pragma hdrstop
#include <stdio.h>#include "ppsig.h"#include "cppapi.h"//---------------------------------------------------------------------------#pragma resource "*.dfm"TForm1 *Form1;//---------------------------------------------------------------------------__fastcall TForm1::TForm1(TComponent* Owner)
: TForm(Owner){
HINSTANCE ppHandle;char pBuf[128];
ppHandle = LoadLibrary("ppppapi.dll");if (ppHandle == 0){
sprintf(pBuf,"Couldn't open ppppapi.dll\r\n");
30
Memo1->Lines->Add(pBuf);Button1->Enabled = false;return;
}Poke8 = (int (*)(USHORT, USHORT, UCHAR, int *))GetProcAddress(ppHandle,
"Poke8");
if (Poke8 == 0){
sprintf(pBuf,"Couldn't find Poke8");Memo1->Lines->Add(pBuf);
}
Peek8 = (unsigned short (*)(USHORT, USHORT, int*))GetProcAddress(ppHandle, "Peek8");
if (Peek8 == 0){
sprintf(pBuf,"Couldn't find Peek8");Memo1->Lines->Add(pBuf);
}}//---------------------------------------------------------------------------void __fastcall TForm1::Button1Click(TObject *Sender){
char pBuf[128];int iStatus, iretStatus;unsigned char val;unsigned short retval;
//get string from edit box & convert string to integerval = (unsigned char)(atoi(Edit1->Text.c_str()));
sprintf(pBuf,"The string value in hex is %x",val);Memo1->Lines->Add(pBuf);
//write data "val" to the data register of the parallel port (0x378)Poke8(0,0,val,&iStatus);sprintf(pBuf,"The status is %d",iStatus);Memo1->Lines->Add(pBuf);
//read status register (0x379) into "retval"retval = Peek8(0,1,&iretStatus);sprintf(pBuf,"The value in the status register is %x",retval);
31
Memo1->Lines->Add(pBuf);
//read control register (0x37A) into "retval"retval = Peek8(0,2,&iretStatus);sprintf(pBuf,"The value in the control register is %x",retval);Memo1->Lines->Add(pBuf);
}//---------------------------------------------------------------------------
C Test Results from Alternate Approach
Table C1: Parallel Port Output ValuesParallel Port Output (binary: MSb..LSb) Value Sent to Parallel Port (decimal)11100000 0 – 711100001 8 – 1511100010 16 - 2311100011 24 – 31. .. .11111110 240 - 24711111111 248 - 255