Parallel Port Interfacing Tutorial

"Bidirectional" bit (bit 5) in control register. This is done by writing 32 to control register. The command "partest1 write 890 32" will do this. After entering this command you can read the status of switches in the hardware using the command "partest1 read 888" Want to know more about parallel port..?, get this book NOTE: This sample program will not work on Windows NT/2000 or XP if you run the program on these machines , it will show an error. use new Inpout32.dll on NT/2000/XP machines

Inpout32.dll for WIN NT/2000/XP

The Problem Writing programs to talk with parallel port was pretty easy in old DOS days and in Win95/98 too. We can use Inporb and outportb or _inp() or _Outp functions in our program without any problem if we are running the program on Dos or WIN95/98. But entering to the new era of NT clone operating systems like WIN NT4, WIN2000, WINXP, all this simplicity goes away. Being interested in Parallel port interfacing and programming you might have experienced the problems in writing a program that can talk to parallel port successfully in NT based operating systems. When we are trying to run a program which is written using the the conventional software

functions like Inporb, outportb, _inp() or _Outp on a WINNT or WIN2000 system, it will show an error message that "The exception privileged instruction occurred in the application at location ....". The picture of such a messagebox is given below.

Staring to this messagebox, you might have been thinking that "did i make a mistake in my program ?" it is working fine on WIN98 ... Who is guilty here. 'Nobody' that is the answer. Then why it is happening like this ..? The answer is in the next paragraph Being a very secure operating system, Windows NT assigns some privileges and restrictions to different types of programs running on it.It classifies all the programs in to two categories , User mode and Kernel mode ie; running in ring3 and ring0 modes. user mode programs are running in ring3 mode and Kernel mode programs are running in ring0 mode. The programs you generally write falls in the user mode category. The user mode programs are restricted to use certain instructions like IN, OUT etc.. Whenever the operating system find that a user mode program is trying to execute such instructions , the operating system stops execution of those programs and will display an error message. Eventually our interfacing programs stops where they are executing IN or OUT instructions to read or write data to parallel port. But in the same time Kernel mode programs are in no way restricted in executing such instructions. Device drivers are capable of running in kernel mode. So the workaround for the above stated problem is to write a kernel mode driver capable of reading and writing data to parallel port and let the user mode program to communicate with it. Writing a driver is not an easy job for even experienced programmers. But writing a simple driver for communicating with parallel port is a simple task when drivers like USB, sound card etc.. are concerned. Even though you get a working driver from somewhere else, installing and configuring it can be very cumbersome task.

The Solution Introducing Inpout32.dll for WIN 98/NT/2000/XP. This dll have the following features 1) Works seamless with all versions of windows (WIN 98, NT, 200 and XP) 2) Using a kernel mode driver embedded in the dll 3) No special software or driver installation required 4) Driver will be automatically installed and configured automatically when the dll is loaded 5) No special APIs required only two functions Inp32 and Out32 6) Can be easily used with VC++ and VB 7) Functions are compatible with Jan Axelsons Inpout32.dll (available at www.lvr.com). So this dll can be used with the sample programs available with the book Parallel Port Complete, without

any modification.

How Inpout32.dll works If you don't know what is Inpout32.dll, please read it here and then continue. How it works The outstanding feature of Inpout32.dll is , it can work with all the windows versions without any modification in user code or the DLL itself. This tutorial describes how it is achieved, what programming methods used, what are the APIs used, etc.... The Dll will check the operating system version when functions are called, and if the operating system is WIN9X, the DLL will use _inp() and _outp functions for reading/writing the parallel port. On the other hand, if the operating system is WIN NT, 2000 or XP, it will install a kernel mode driver and talk to parallel port through that driver. The user code will not be aware of the OS version on which it is running. This DLL can be used in WIN NT clone operating systems as if it is WIN9X. The flow chart of the program is given below.

The two important building blocks of this program are 1) A kernel mode device driver embedded in the DLL in binary form 2) The DLL itself Kernel mode driver Hwinterface.sys

The source code of Hwinterface.sys kernel mode driver is located in "kernel_mode_driver_source" directory. Where "hwinterfacedrv.c" is the main application source file. Three functions implemented in the driver are 1) 'DriverEntry' , Called when driver is loaded. Creates device object and symbolic links. 2) 'hwinterfaceUnload', Called when driver is unloaded, performs clean up 3) 'hwinterfaceDeviceControl', handles calls made through DeviceIOControl API. Performs reading writing to the parallel port according to the control code passed. The DLL Inpout32 The functions in the DLL are implemented in two source files, "inpout32drv.cpp" and "osversion.cpp". osversion.cpp checks the version of operating system. "inpout32drv.cpp" does installing the kernel mode driver, loading it , writing/ reading parallel port etc... The two functions exported from inpout32.dll are 1) 'Inp32', reads data from a specified parallel port register. 2) 'Out32', writes data to specified parallel port register. the other functions implemented in Inpout32.dll are 1) 'DllMain', called when dll is loaded or unloaded. When the dll is loaded , it checks the OS version and loads hwinterface.sys if needed. 2) 'Closedriver', close the opened driver handle. called before unloading the driver. 3) 'Opendriver', open a handle to hwinterface driver. 4) 'inst' , Extract 'hwinterface.sys' from binary resource to 'systemroot\drivers' directory and creates a service. This function is called when 'Opendriver' function fails to open a valid handle to 'hwinterface' service. 5) 'start' , starts the hwinterface service using Service Control Manager APIs. 6) 'SystemVersion' Checks the OS version and returns appropriate code. What is hwinterface.ocx ActiveX control It is an activex control with same features of Inpout32.dll. It can be used either with VC++ or VB. But it gives great convenience when used with VB. Data can be written to parallel port using Outport method and can be read using Inport method.

A Tutorial on creating DLLs with VC++ Visual basic is very fast and easy tool for developing applications with high degree of user friendliness , but it lacks some important functionalities like direct access to hardware, multythreading(Activex servers allows some type of multythreading !). The easy and effective solution for this problem is to write a DLL. But beginners experiance problems in understanding

how to write a dll. .Here is a simple tutorial on writing DLLs with Visual C++. I assume that you know a little bit Visual Basic and ?C? programming. What is Static linking and Dynamic linking ? The libraries can be linked to the executable in two ways . one is static linking and the other is dynamic linking. Static linking is the methode used to combine the library routines with the application. When bulding the program , the linker will search all the libraries for the unresolved functions called in the program and if found, it will copy the corresponding object code from the library and append it to the executable. The linker will keep searching until there are no more unresolved function references. This is the most common methode for linking libraries.This methode boasts of ease of implementation and speed but will generate bulky executables. In dynamic linking , the required functions are compliled and stored in a library with extension ?. DLL?. Unlike static linking, no object code is copied in to the executable from the libraries.Insted of that, the executable will keep the name of the DLL in which the required function resides. and when the executable is running , it will load the DLL and call the required functions from it. This methode yealds an executable with small footprint , but have to compromise on speed a little.

Example 1 Objetive Create a Dynamically linkable library which can calculate and return the sum of two numbers passed to it. Tools required visual C++ 6 , Visual basic 6 Writing The DLL Start VC++ IDE , select ?New? from File menu. Then select ?Win32 Dynamic - link library? from ? Projects? tab(picture-1). enter project name as ?example1? , then click OK button. Now you can see a dialog box with caption ?Win32 Dynamic - Link library - step 1 of 1? (picture-2).

Picture 1

Picture 2 Select ?a simple DLL project? and click Finish. Now open exaple1.cpp from ?fileview? (picture-3)

Picture 3 add these lines in to example1.cpp int _stdcall sum(int x , int y) { return x+y; } It is a simple function which returns the sum of numbers passed to it. Now our function is ready. The next step is to create a ?.def? file which informs the linker to export our function.Select ?New? from ?File? menu and then select ?text File? from ?Files? tab.Give it a name ?example1.def?. Now you can see an empty file . Add these lines in to ?example1.def? LIBRARY EXAMPLE1 EXPORTS sum @1 Select ?Build example1.dll? from ?build? menu. The build process should complete without any errors. If any error occures , correct it and rebuild again. Oce the build process is completed successfuly , you can see ?example1.dll? in ?debug? directory. Now we have successfuly built the Dll and it is the time to test it. For testing the DLL we have to write a small program in VB. Open a new project in Visual Basic. Place three text box and a command button like in picture 4.

Picture 4 Copy the code given bellow , to the code window Private Declare Function sum Lib "example1.dll" (ByVal x As Long, ByVal y As Long) As Long Private Sub Command1_Click() Text3.Text = Str(sum(CInt(Text1.Text), CInt(Text2.Text))) End Sub copy example 1.dll to ?windows? or ?system? directory . Then run VB ,enter some values to text1 and text2 and click ?Calculate? button. If you can see the sum in text3, you have completed example1 successfuly ! cangratulations !. Download the source code and project files for example1

Example 2 Objetive Create a Dynamically linkable library which can calculate and return the sum of two numbers passed to it. Tools required visual C++ 6 , Visual basic 6 Writing The DLL Create a new win32 DLL project in VC++ just like in the previous example. insert the statement given below before main #include ?string.h? Insert the following code after main char* _stdcall to_upper(char *lowerstring) { _strupr(lowerstring); return lowerstring; }

Create a def file and insert the following code LIBRARY example2 EXPORTS to_upper

@1

Now save the project, build it and copy example2.dll to ?windows? or ?system? directory. Create a new project in VB, place a text box and command button the form paste the following code to code window. Private Declare Function to_upper Lib "example2.dll" (ByVal text As String) As String Private Sub Command1_Click() If (Text1.text) = "" Then Exit Sub End If MsgBox to_upper(Text1.text) End Sub Run the program and enter some lower case characters in textbox.It should display a messagebox with same characters with case changed. Download the source code and project files for example2

Example 3 Objetive Create a DLL which can read/write data to parallel port This DLL is a very useful for interfacing parallel/serial ports. Since Visual Basic does not have any facility to communicate with parallel port directly , programmers will have to write code for accessing parallel port in a DLL and should be called from VB. In this DLL , in this dll , accessing the device registers is done using functions _Inp() and _Outp(), which is declared in ?conio.h? . More details about these functions can be found at MSDN online . We will export two functions from the DLL.One is for reading from a device register and the other is for writing to the device register. Let these functions be InPort() and OutPort(). InPort() will take one parameter ie; the address of the register to be read. and Outport will take two ie; the address of the register to which the data to be written and the data itself. Note: to do this project , You need to have some knowledge in Parallel port interfacing. Tools required visual C++ 6 , Visual basic 6 Writing The DLL

Create a new win32 DLL project in VC++ like in the previous examples. insert the statement given below before main #include ?conio.h? Insert the following code after main short _stdcall InPort(short portaddress) { return _inp(portaddress); } void _stdcall OutPort(short portaddress,short data) { _outp(portaddress,data); } create a .def file with name example3.def and insert the following code LIBRARY example3 EXPORTS InPort OutPort

@1 @2

now save the project and build example3.dll. for testing the dll , create a new project in visual basic.Create a form like in picture5.

Picture 5 Add the following code to code window Private Declare Function InPort Lib "example3.dll" (ByVal portaddress As Integer) As Integer Private Declare Function OutPort Lib "example3.dll" (ByVal portaddress As Integer, ByVal data As Integer) As Integer Private Sub Command1_Click() OutPort 888, 10 'Val("&h" + Text2.Text), Val(Text1.Text) End Sub Private Sub Command2_Click() Text3.Text = Str(InPort(Val("&h" + Text2.Text))

End Sub Run the program and enter some value in text1. the n click ?Write it? button. Again click the ? Read it? button , now if text2 displays the number which you entered in text1 , your dll is working successfuly. Download the source code and project files for example3

IEEE 1284.3 and 1284.4 Advances in High-Speed Parallel Port Performance and Port Sharing From it's humble beginnings as a Printer Port on the original IBM PC, the Parallel Port has become one of the most common connectors on the Personal Computer today. Virtually every PC shipped over the past 18 years has had a parallel port interface on it. Originally this port was used just for driving 'fast' dot matrix printers. Today the parallel port is used to interface to almost every PC peripheral in use. Printers, scanners, data acquisition, CD ROM, tape drives, high speed modems and digital cameras are some of the peripherals that can be purchased and used today. From 1981 until 1994 there was tremendous growth in the power, performance and capabilities of the PC. Unfortunately there was very little change in the performance of the parallel port. In 1994 this all changed with the release of IEEE Std. 1284-1994. This standard defined new protocols and new interface models that would enable a 50 to 100x performance increase in the capabilities of the parallel port. With the efforts of the IEEE 1284.3 and 1284.4 committees these enhancements are continuing today. This presentation will provide an introduction to the state and future of the parallel port interface and the associated protocol stack. Prior to the 1284 standard the PC parallel port model was a simple register set that the host driver could access. In order to transfer data the host driver was required to access the register and manage all the handshaking and data transfer. Since the parallel port was mapped into the ISA bus I/O space the fastest the driver could access the port was 1Mbyte per second. With an overhead of 4 port accesses per data transfer this put a limit of 250Kbytes per second as the fastest the PC could transfer data using the Centronics printer protocol. It would require nearly 100% of the PC utilization in order to achieve this rate. In order to keep the PC responsive actual data rates were on the order of 50KB/S to 150KB/S. The 1284 standard provided new data transfer protocols that could be implemented in an enhanced register model. One of the key advantages of this was that the register model could remain backward compatible with the existing model but add enhanced features for better data transfer. This was achieved by implementing hardware state machines that would offload the data transfer handshaking form the host driver. The Enhanced Parallel Port (EPP) and Extended Capabilities Port (ECP) are these advanced modes. These modes enable data transfer rates of over 1MB/S with reduced host utilization on today's ISA ports, and 3-5MB/S on future PCI implementations. Printing, reading or writing from tape, and other peripheral communication can consume a significant percentage of the parallel port bandwidth when active. In reality though, these activities do not occur very often and use very little of the overall available bandwidth. This means that a significant PC resource is being wasted. To use this additional potential the IEEE 1284.3 committee developed a protocol to allow sharing of the parallel port by multiple peripherals. The Daisy Chain protocol is the result of this effort. Devices that adhere to this protocol (DC devices) have two connectors on them. One connector connects to the host port of the PC or the Pass Through port of another DC device. The other connector is the pass through port. This port replicates, or passes through the signals from the host port when the peripheral is not communicating with the host. The Daisy Chain protocol allows four peripherals to share a single parallel port and still attach an older 'legacy' peripheral. In this way, like the 1284 standard, backwards compatibility with the existing installed base is preserved. The wire protocol that is used for 1284.3 is "out of band" to the 1284 defined protocols. This allows all DC devices to utilize the full capabilities of the 1284 standard. The 1284.3 protocol provides the means to address individual devices on the parallel port chain and to select a particular device for use by the host. When a DC device is selected the 'downstream' devices and the legacy device do not see any activity on the parallel port. To these devices the parallel port is idle.

One advantage of standardizing on the switching protocol is to enable the use of a common software driver on the host PC. The host driver, possibly provided by the Operating System, can then provide the switching services for the host application. The 1284.3 Service Provider Interface defines the types of services that are required by client applications. These services will be provided by the host. This 1284.3 SPI is responsible for determining how many devices are attached to the parallel port and discovering what they are. This information is obtained by the 1284 device ID method for LPT plug and play. To the client application it appears that the DC device is the only device attached to the parallel port. The 1284.3 SPI driver manages the switching and selection of the peripheral. Once you have a software layer to provide the basic port enumeration services it is a natural extension to include the data transfer functions. The 1284.3 Data Link interface defines these services. With a full software interface to the parallel port we are able to achieve independence from the actual hardware interface. This makes it easier to migrate to newer and faster hardware without effecting the client applications. The 1284.3 Data Link defines a packet protocol that enables the delivery of packets of data to other side of the interface. This creates a connection-less, peer to peer relationship between the host and the peripheral. The header provides information on the data length and the transport protocol being used. This ensures that the data is only delivered to the appropriate client. The data length is used to enable DMA for the reception of data. At this point the 1284/1284.3 protocol stack provides a software interface that is independent of the actual hardware implementation. With the appropriate implementation of the data link the parallel port could be used with many different transport protocols. Although this is true, there was no transport layer that could take advantage of the features of the 1284 interface. In particular the channel capabilities of the EPP and ECP modes. The IEEE 1284.1 committee had defined a printer management standard that could operate over networks or direct attached interfaces. They requested that the IEEE develop a transport protocol that would take advantage of the 1284 standard parallel port capabilities but also be suitable for other physical interfaces. One of the main requirements was that the transport layer be able to maintain multiple conversations, or sessions, between the PC and the peripheral. In addition to this the protocol should ensure that one conversation cannot block another. An example of blocking is what you see in older Centronics interfaces. If the paper should run out of the printer or you open the tray to add more paper you can no longer communicate with the printer. With 1284.4 these functions should be independent and not effect one another. The IEEE 1284.4 committee was established to develop and define this transport protocol. After analysis of various existing protocols, such as PPP and the MFP IS16550, it was determined that the Multiple Logical Channels (MLC) protocol developed by Hewlett-Packard and Genoa Technology met the general requirements for this standard. QualityLogic™ (formerly Genoa Technology) and HP offered this protocol as the basis for the 1284.4 standard. While MLC was the basis for 1284.4, the final standard is not backward compatible with MLC. The 1284.4 protocol allows a device to carry on multiple, concurrent exchanges of data and/or control information with another device across a single point-to-point link. Blocking of one data exchange has no effect on the others. While the protocol was required to operate over the 1284 interface it may also operate over other interfaces such as USB and IEEE 1394. 1284.4 defines a packet protocol that enables this communication. Within the packet is the identity of the source and destination endpoints, client data, as well as control and credit information. Credit is the flow control method that is used to ensure that channel blocking does not occur. With credit the target of a data transfer gives the source of the data an indication of how much data it is guaranteed to accept. In this way the source can never send more data than the target can accept. Upon initialization both sides negotiate for how much data needs to be transferred and in what packet sizes. The source and target identities define a connection between the sides. A source may communicate with multiple target endpoints. In this way one client can communicate with multiple services on the target. A scanner is one example of how this may operate. The scanner application on the host may need to communicate with two functions on the scanner peripheral. The first function may be the scanner control and status monitor. The application will then establish a conversation between itself and this function on the scanner. At some point a page to be scanned may be inserted. Now the scanner can request the establishment of a connection between the scan engine and the host application. Now we have two independent conversations established between the PC and the peripheral. This model can be extended to many different conversations. Conversations may occur between devices on different physical interfaces. The advantage of 1284.4 is that it can port to other PC related interfaces by the implementation of the appropriate software interface. This means that a client application on the PC can communicate with devices on multiple physical interfaces without any changes. In conclusion, the parallel port is being enhanced by new hardware and software support. With backward compatibility and a huge installed base this interface will provide a convenient and powerful port for future peripherals. This presentation will provide an introduction to the protocol stack and issues involved in developing parallel port peripherals.