PowerCell Device And

Device Driver Development For WAP Enable Devices.

http://powercell.cjb.net/

A Final Project Report For the Degree of MCS

(Master of Computer Science)

By Team Leader : Abdul Razaq

Hardware and App Interfaces: Irshad-ul-haq Quality and Documentation: Yahya Sadique

Degree Date: September, 2004 Revision Date : Nov. 2005

Preparid by : Abdul Razaq , arazaq@cityu.edu.hk , abdulrazaq@gmail.com This share ware version of documentation is with NO WARRANTY. Contact university

or me for complete documentation and other resources.

Master of Computer Science. University Of Management and Technology.

Project title: Cellular control of PowerCell Device And Device Driver Development for

WAP enable Browsers. Abstract

This document details the work to develop a PowerCell Device And Standard Parallel Port Kernel mode Device Driver Development. Power Cell Device consist on micro controller based PCB with DB-25 (Parallel Port) connecter, ADC and heat sensor. Other part is Power Cell Relay control board, control board is attached to PowerCell Device via 10 pin IDC connector.

Driver is designed and implemented in order to provide access to a sensor device from a simple user mode application and to provide access to read/write operations. In addition, we will discuss the parallel port specifications, driver development process (both in user and kernel mode), operating system internals, driver building environment, and Microsoft’s WDM , managing web server , server side scripting, client side scripting for WAP enable browsers and finally testing and debugging of whole system of applications.

Table of contents 1 Project overview 2 Driver development process 3 Hardware specifications 4 Overview of operating system internals

4.1 Differences Between Windows 9x and Windows NT 4.2 The Hardware Abstraction Layer (HAL) 4.3 Device driver 4.3.1 Monolithic driver 4.3.2 Layered driver 4.3.3 Miniport driver 4.4 Win32 Application Programming Interface (API) 4.5 I/O control operations 4.6 Application software

5. Implementation Of PowerCell Driver

5.1 DriverEntry 5.2 PowerCellDeviceControl 5.3 PowerCellCreateDispatch 5.4 PowerCellUnload

6 Parallel port

6.1 Basic Parallel Port Information 6.2 HardWare Specfications 6.3 Parallel port modes 6.4 Parallel port registers 6.4.1 Understanding Addresses Of Registers

6.5 Programming Concepts. 6.5.1 Basic Assembly to send data to parallel port

6.6 Configuration Parallel Port Mode In Bios For PowerCell Device 6.6.1 Pin Configuration Of PowerCell Device with Parallel Port. 6.6.2 How PowerCell Device communicate with Parallel Port. 6.6.3 Collecting data through a parallel port from installed ADC0804 chip on PowerCell device

7 PowerCell Driver Architecture 7.1 Driver software modules

8 Manual installation Of Driver And Quick Start 8.1 Batch installation.

9 Kernel mode driver development 9.1 Microsoft Windows Driver Development Kit (DDK) 9.2 Driver building environment in DDK 9.3 Build utility 9.4 Running the build utility

9.5 Driver code building example 9.6 Driver debugging

10 Conclusions 12 References 1 Project overview

The project aims in designing an embedded system ,in general implementing and

testing a customizable kernel mode driver for Microsoft family operating systems. Establishing, bi-directional communication channels with parallel port to eight bit bi-directional microcontroller ports.

This documentation emphasis on the software development part of the Power Cell device driver with graphical user interface(GUI) based on desktop application and web based interface for WAP clients, you will have short tutorial on parallel port of PC in same document.

Power Cell device driver is designed and implemented in order to access hardware from a simple local user mode application and from WAP enable browsers(supports general packet switching GPRS).

Driver supports bi-directional communication with standard parallel port. Centronics is an early standard for transferring data from a host to the printer. The majority of printers use this handshake. This handshake is normally implemented using a Standard Parallel Port under software control

Making PCB with onboard processing and Driver development is very time-consuming and requires a firm understanding of the basics of operating system internals , driver development and sufficient knowledge of electronics. Therefore, this document will briefly discuss the operating system internals, driver development in details with relevant information of electronics. In order to develop a parallel port driver, the developer has to have an understanding of parallel port specifications, understanding the IEE 1248 different port types which is subject to hardware understanding of registers connected to port. This document will also briefly discuss the parallel port specification. The Host Interface application supports port operations and with some monitoring capabilities. WAP interface provides User Authorization for web clients, allowing them to access PowerCell Device via their WAP enable browsers.

Both the driver and application is developed and executed successfully in Windows 2000 professional and Windows XP PC.

It is common that software development work is usually done in application level (user mode), where the programmer does not have the right to access directly to the hardware in protected operating systems such as Windows, Linux and Solaris. However, there is a solution. By utilizing software modules called device drivers that are located within the operating system (kernel mode), the application can “directly” access the hardware. The application is written and compiled using 32-bit compiler Microsoft

Visual Studio. The driver is built in DDK (Driver Development Kit from Microsoft). Driver code is written in C language and driver interfaces were written in C++ and VB 6. Both the development machine (for software development) and the test machine run on Windows 2000 and Windows XP respectively. 2 Driver Development Process

To communicate a hardware running on Windows, the application must call the standard Win32 APIs and the driver must call the system-specific APIs (Hardware Abstraction Layer, HAL). The developer also must conform to the operating system’s specific method of writing, linking, and loading of drivers. The development process of a driver is as follows by Microsoft:

1. Understand Driver and Operating System Basics. Understand the fundamentals of how drivers work in operating system.

2. Understand and follow the specific device class hardware and software requirements during development so that device/driver works correctly with other system components.

3. Make Driver Design Decisions. For example, driver developer should decide which operating systems and hardware platforms the driver will run on, whether the driver is user-mode or kernel-mode, and whether to modify existing sample driver code or start from scratch.

4. Learn how to write the driver code. The driver deals with the connections, signals, and protocols for communication between host and device.

5. Write, build, debug and test the driver. Understand the building environment for driver. Master the driver debugging tools and perform comprehensive driver testing.

6. Write the user application to access the hardware. 7. Provide a driver package. Determine the device installation components and what

operating system expects during device installation. 8. Distribute the driver package.

Note that these steps need to be repeated with every new operating system for the device.

3 Hardware Specifications

Hard Ware Consists on tow parts. 1) Power Cell Device (see figure 1) The hardware I’ve use in the project is AT89S52 microcontroller device from

8051 family produced by ATMEL. Figure 1 illustrates the board layout of Power Cell device PCB. The device board incorporates basic inputs (push-button, analog to digital converter ADC0804), output(LED) , LM35 heat sensor and an IDC connectors so that the user is able to easily connect his or her 8 bit interface for input or output. The AT89S52 device is FLASH device allowing 8 K memory. The device is powered by external power supply. The data transmitted from LM35 is sent to microcontroller then controller send it to PC for further data processing (reading current temperature from environment).

Figure 1. PowerCell Device PC Communicate with device through parallel port attached to port 1 of microcontoller for sending data back and forth.

2) Power Cell Relay Control board. (see figure 2)

The hardware we use in Power Cell Relay Control board is for connecting high voltage devices with computer. Figure 2 illustrates the board layout of Power Cell device PCB. The device board incorporates Relays, output(LED) ,OptoCoupler 4N25 and a 10 pins IDC connector. IDC is used to connect relay board with PowerCell device. The device is powered by external power supply of 12 V. Data sheets and cost analysis of HardWare can be located in References section.

Figure 2 : PowerCell Relay Control board. 4 Overview of operating system internals

The operating systems we have used for software development and testing is

Windows 2000 and XP respectively. Operating system provides a layer of communication for application software and hardware abstraction. The Windows Driver Model (WDM) provides a framework for drivers that operate in the operating system. Under Windows, software code runs either in user mode (restricted to authorized activities only) or in kernel mode (fully trusted and able to do anything). Each allows a different level of privilege in accessing memory and other system resources. Applications are limited to the user mode while drivers run in the kernel mode. Figure 3 shows the typical driver architecture in Windows.

User Mode Kernel Mode

Application API

Device

Device Driver

Figure 3. Typical driver architecture in Windows family.

In the user mode, an application has no access to an area of memory that the

operating system has designated as protected. This allows multiple applications to run at the same time without interfering with each other. The user mode corresponds to the so-called CPU’s Ring 3 mode. In the kernel mode, the code has unrestricted access to system resources, including the ability to execute memory-management instructions and control access to I/O ports. The kernel mode corresponds to the CPU’s Ring 0 mode.

As a result, applications are unable to access the hardware directly. In fact, this is only made available to code running in at Ring 0 or the kernel mode. This means that driver must be written in the kernel memory before accessing the hardware from the user mode.

Figure 3.1. The Windows operating system architecture. 4.1 Differences Between Windows 9x and Windows NT

MicroSoft system developers discovered that the unrestricted access provided by the VxD(win9X) architecture could be used to perform normally impossible tasks on behalf of user mode applications. Windows NT also provides such an interface via its

driver architecture. Much like VxDs, a Windows NT driver has unrestricted access to a computer's hardware.

Some of the major differences between the Windows 9x and Windows NT operating

systems.

• Windows NT is a true 32-bit operating system, whereas Windows 9x contains a considerable amount of 16-bit code that has been ported from Windows 3.1. As a result, under Windows 9x, portions of operating system memory are accessible from user mode.

• Under both operating systems, applications may share memory. However, under Windows NT, only those applications that specifically request a shared memory resource can see this memory, whereas under Windows 9x, all shared memory is visible by all running programs.

Windows Architecture

By Steven Roman published by O'Reilly and Associates, Inc.

4.2 The Hardware Abstraction Layer (HAL)

The hardware abstraction layer (or HAL) is a kernel mode library (HAL.DLL) that

provides a low-level interface with the hardware. Windows components and third-party

device drivers communicate with the hardware through the HAL

In order to perform an IRP, device driver needs to access its hardware by using facilities provided by the hardware abstraction layer (HAL). In the case of an IRP_MJ_READ, the access may be a read operation directed to an I/O port or a memory register implemented by the device. A read operation may involve calling READ_PORT_UCHAR (a HAL routine) to read a single data byte from an I/O port. The HAL routine uses a platform-dependent method to actually perform the operation to the hardware. On an Intel x86 computer, the HAL would use the IN instruction while on an Alpha, it would perform a memory fetch. 4.3 Device driver

Software that controls a device that is connected to or is part of a computer. In plain words a software routine that links a peripheral device to the operating

system is called device driver. It acts like a translator between a device and the applications that use it. Each device has its own set of specialized commands known only to its driver. In contrast, most applications access devices by using high-level, generic commands. The driver accepts these generic commands and translates them into the low-level specialized commands required by the device.

The driver allows the application code to access hardware when the application knows only the hardware’s name or function. The application need not have to know about the physical address of the port, or explicitly monitor and control handshaking

signals. This is achieved by translating between application-level and hardware-specific code. Many kinds of drivers form a complete operating system. Figure 4 shows several of them. In addition to device drivers, Windows also provide a device class called Human Interface Device (HID) . further details on HID can be enquired from MSDN.

Figure 4. Types of device driver in Windows.

Kernel-mode drivers include many sub drivers. A file system driver implements the standard PC file system on local hard disks or over network connections. Video drivers are kernel-mode drivers for displays and printers (legacy device) drivers are kernel-mode drivers that directly control hardware without help from other drivers. 4.3.1 Monolithic driver The simplest type is a monolithic driver. This type generally has no dependencies on other drivers loaded in the system. They supply an interface to user mode applications and talk directly to hardware without any intervention or support from anyone else. This is the type of driver we have implemented for our project.

A monolithic driver is illustrated in Figure 5. The driver communicates with the application through I/O control commands (IOCTs) and drives the hardware using calls to the DDK functions.

Figure 5. A monolithic driver Figure 6. A layered driver Figure 7. A miniport driver 4.3.2 Layered driver

Layered drivers are device drivers that are part of a stack of device drivers that

together process an I/O request. A layered driver is illustrated in Figure 6. An example of a layered driver is a driver that intercepts calls to the disk and encrypts/decrypts all data being transferred to/from the disk. In this example, a driver would be hooked on to the top of the existing driver and would only do the encryption/decryption. Layered drivers are sometimes also known as filter drivers. 4.3.3 Miniport driver

There are classes of device drivers in which much of the code has to do with the functionality of the device, and not with the device’s inner workings. A miniport driver is illustrated in Figure 7. Windows NT/2000/XP/Server 2003, for instance, provides several driver classes (called ports) that handle the common functionality of their class. It is then up to the user to add only the functionality that has to do with the inner workings of the specific hardware. 4.4 Win32 Application Programming Interface (API) Win32 API is the standard programming interface for Windows NT . Programmers use 32-bit addresses instead of the old 16-bit addresses used in earlier versions of Windows.

The application-level code (PowerCIO.dll) uses functions supported by the operating system to communicate with the device driver(PowerCell.sys) while the hardware specific code handles the protocols necessary to access the peripheral’s circuits, toggling control signals at appropriate times.

Windows environment subsystem is to act as an interface between user applications and

relevant portions of the Windows executive. Each subsystem exposes different

functionality from the Windows executive. Every executable file is bound to one of the

subsystems. Win32 subsystem houses the Win32 API, in the form of DLLs, such as

KERNEL32.DLL, GDI32.DLL, HALL.DLL and USER32.DLL. Microsoft moved part of

the Win32 subsystem from user mode to kernel mode in NT 4.

4.5 I/O control operations

Before the application can do any I/O operation, it has to obtain a HANDLE (an open handle open to the device) by calling the OpenDriver function of (PowerCIO.dll) Win32 API which in terms call (PowerCell.sys) standard Win32 API function CreateFile to grab the handle to device. While the handle is open, the application can make calls to NowRead, NowWrite, TotalRead , TotalWrite and TotalOpr. NowRead is called when the application wants to read data from physical device and calls NowWrite function to write data.

4.6 Application software

The application will need to call the many functions located in the Win32 API that are used to communicate with the operating system. The compiled code for the functions is found in dynamic linked library (DLL) file. In order to establish a communication path to a device, you use the Win32 API functions including (NowRead ,NowWrite ,TotalRead ,TotalWrite ,TotalOpr ) PowerCIO.DLL. The application software can be written as follows:

1. Exchange data reports with the device. i. Obtain a handle to device with Server.CreateObject in web based

interface or loading API in .exe modules.

ii. Sends an Output report to the device by calling the function NowWrite using the device handle

iii. Reads the Input report by calling the function NowRead by using the device handle.

iv. Multiple threads can be used in the data transfer process. By placing the

Read and Write commands in separate threads.

v. Destroy handle of device by setting it to nothing(Set handle = Nothing) to close handle at the end of the transaction.

5. Implementation Of PowerCell Driver:

A simple scenario is when host application or WAP interface wants to communicate with PowerCell device then (PowerCIO.dll) win32 API is loaded in memory with APIENTRY DllMain. Which in terms loads the driver module with DriverEntry point same as we have a main method for exe.

5.1 DriverEntry:

DriverEntry, which is the kernel-mode equivalent to DllMain in a user mode Win32 DLL. The DriverEntry function is called by the I/O Manager when our driver is started. The function is passed a pointer to a PDRIVER_OBJECT as well as a pointer to the registry string for our driver.

Below line of code creates a logical entities for our device (attached to parallel port) and kernel object(device object)

WCHAR NameBuffer[] = L"\\Device\\PowerCell";

WCHAR DOSNameBuffer[] = L"\\DosDevices\\PowerCell";

IoCreateDevice(DriverObject, 0, &uniNameString, FILE_DEVICE_UNKNOWN, 0, FALSE, &deviceObject);

The IoCreateDevice routine creates a device object for use by a driver.A driver specify name for a device object when it calls IoCreateDevice to create the device object.Then we create a symbolic link in Dosdevice and PowerCell device with following code.

IoCreateSymbolicLink (&uniDOSString, &uniNameString);

After linking objects symbolically we now point our driver object to functions that will be used in driver life in memory(before closeDriver).The Microsoft Windows family of operating systems communicates with drivers by sending input/output (I/O) request packets (IRPs). The data structure that encapsulates the IRP not only describes an I/O request, but also maintains information about the status of the request as it passes through the drivers that handle it. An IRP has a header area followed by several stack locations. Each stack location holds a function code and various parameters, e.g. for the read, write and device I/O control functions.

IRP_MJ_CREATE Request for a handle

IRP_MJ_DEVICE_CONTROL Control operation

DriverObject->MajorFunction[IRP_MJ_CREATE] = PowerCellCreateDispatch;

DriverObject>MajorFunction[IRP_MJ_DEVICE_CONTROL]=PowerCellDeviceControl

DriverObject->DriverUnload = PowerCellUnload;

At this point our driver if fully loaded and it can serve for any numbers of NowRead , NowWrite , TotalRead , TotalWrite and TotalOpr calls to interact with PowerCell Device.

5.2 PowerCellDeviceControl :

This function also belongs to kernel module PowerCelldrv.cpp , this functions requires tow parameters. First parameter is handle to device object and second is pointer to Input Output Request Packet (IRP). Each user mode application call to DeviceIoControl causes the I/O Manager to create an IRP with the major function code IOCTL_WRITE_PORT_UCHAR Or IOCTL_READ_PORT_UCHAR and to send that IRP to the driver dispatch routine

DeviceIoControl(handleTOdrive,IOCTL_READ_PORT_UCHAR,&Buffer, 2 ,&Buffer ,1,&bytesreturn ,NULL);

Now we grab the associated current system buffer from IoGetCurrentIrpStackLocation, this macro obtains the current stack pointer in the IRP (which is managed by the I/O Manager).

CtrlSystemBuff = pIrp->AssociatedIrp.SystemBuffer when we have captured the current system buffer for IRP ,its time to extract value for register which is suppose to be target port by address = (PUSHORT) CtrlSystemBuff And we can get data,in NowWrite case by doing the same thing for port data. data = (PUCHAR) CtrlSystemBuff Now we check our control codes so far passed in Device Object by checking the stkloc->Parameters.DeviceIoControl.IoControlCode in switch structure we do appropriate actions against the IO control codes. Before calling the IoCompleteRequest function we set the IOStatus.Information to the number of bytes that are required in user space. In our Driver case we require only One byte in user area.

5.3 PowerCellCreateDispatch

The first parameter is the device object that we have created for your driver within DriverEntry call. The I/O Manager will always pass this pointer to our control functions, so we don't have to keep a pointer to it for global scope within our driver. The second parameter is a pointer to an IRP structure. This structure completely contains the information required to perform operation and process the request.

5.4 PowerCellUnload

This function is called when driver is no longer required by the user mode application Or user mode application delete its handle by calling the CloseDriver function of PowerCIO.dll. Though it is atomatically called when APIENTRY finds process detach reason for cal

We delete first symbolic link created in Dos devices and PowerCell device. IoDeleteSymbolicLink (&uniDOSString);

Finally we delete our kernel object.

IoDeleteDevice(DriverObject->DeviceObject);

6 Parallel port

6.1 Basic Parallel Port Information

The Parallel port has come a long way since its original implementation on the IBM PC in the early eighties. It was originally designed to allow faster output to printers than the serial port. It did this by transferring 8 bits of data at a time instead of one. Although this is still the most common use for the parallel port, it is also put to many more uses, and provides vastly superior methods for data transfer to those who wish to spend a little time and effort. This document is intended to give the reader a good grounding in the way the parallel port appears to a systems programmer. Starting with the original IBM PC, IBM defined a standard parallel printer port which has become very widespread. This port uses a female DB-25S connector on the computer, and a special male DB-25P.Centronics male 36 pin "IBM Printer cable" is used to connect to standard Centronics parallel printers. (about half of the Centronics pins carry just electrical ground.). The original definition was embodied in the "IBM Printer Adaptor", and the "IBM Monochrome Display and Printer Adaptor" cards the connection between data (eg: a register bit) and pins is direct if a data 1 is associated with an electrical TTL high, and inverted if data 1 is associated with TTL low. An overall connection (data to TTL to data)is considered direct if outputing a 1 produces a 1 on input at the other end, or inverted if outputting a 1 produces a 0 on the other end. 6.2 HardWare Specifications The D-Type 25 pin connector is the most common connector found on the Parallel Port of the computer, while the Centronics Connector is commonly found on printers. The IEEE 1284 standard however specifies 3 different connectors for use with the Parallel Port. 1284 Type A is the D-Type 25 connector found on the back of most computers. The 2nd is the1284 Type B which is the 36 pin Centronics Connector found on most printers. IEEE 1284 Type C however, is a 36 conductor connector like the Centronics, but with some extras.

Figure 8 "Pin Outs" of the D-Type 25 Pin connector

6.3 Parallel port modes Newer Parallel Port’s are standardized under the IEEE 1284 standard first released in 1994. This standard defines 5 modes of operation which are as follows, 1. Compatibility Mode. 2. Nibble Mode. 3. Byte Mode. 4. EPP Mode. 5. ECP Mode.

6.4 Parallel Port Registers

The programs, circuit and other information found in this document are compatible to almost all types of parallel ports and can be used without any problems. The lines in DB25 connector is divided in to four groups, see Figure 9 1) Data lines 2) Control lines 3) Status lines 4) Ground lines

Figure 9 As the name refers , data is transferred over data lines , Control lines are used to

D-Type 25 Female D-Type 25 Male

control the peripheral and of course , the peripheral returns status signals back computer through Status lines. These lines are connected to Data, Control And Status registers internally . The details of parallel port signal lines are given below

Pin No (DB25)

Signal name

Direction Register - bit

Inverted

1 NStrobe Out Control-0 Yes

2 Data0 In/Out Data-0 No

3 Data1 In/Out Data-1 No

4 Data2 In/Out Data-2 No

5 Data3 In/Out Data-3 No

6 Data4 In/Out Data-4 No

7 Data5 In/Out Data-5 No

8 Data6 In/Out Data-6 No

9 Data7 In/Out Data-7 No

10 nAck In Status-6 No

11 Busy In Status-7 Yes

12 Paper-Out In Status-5 No

13 Select In Status-4 No

14 Linefeed Out Control-1 Yes

15 nError In Status-3 No

16 nInitialize Out Control-

2 No

17 nSelect-Printer Out Control-

3 Yes

18-25 Ground - - -

6.4.1 Understanding Addresses Of Registers IBM defined three standard port base addresses (in 80x86 IO address space). The Printer Adaptor could use base address 0x378, or later 0x278, while the Monochrome Display and Printer Adaptor used base address 0x3BC. The IBM BIOS defines RAM space for 4 parallel printer port base addresses,

DOS (MSDOS and IBM DOS) maps these as LPTn devices. Unlike COMn devices and com ports, the name mapping varies depending on whether or not there is a Monochrome Display and Printer Adaptor card or not. The first entry in the BIOS table at 0x408 becomes LPT1, the second entry LPT2, and the third entry LPT3 (if there are that many). The DOS device "PRN" is really software alias for another port, by default LPT1; use the MODE command to change this aliasing. The following table has "typical" assignments. Note that by swapping the entries in the BIOS table at 0x408, one can change

which physical ports are assigned to LPT1, LPT2, etc. Several "printer swap" programs do just that.

Typical Assignments Address MDPA no MDPA 0x3BC LPT1 n/a Monochrome Display and Printer Adapter (MDPA) 0x378 LPT2 LPT1 Primary Printer Adapter 0x278 LPT3 LPT2 Secondary Printer Adapter Name MDPA no MDPA LPT1 0x3BC 0x378 LPT2 0x378 0x278 LPT3 0x278 n/a

6.5 Programming Concepts. Below information is aimed to prior Windows NT 4.0, Microsoft moved part of the Win32 subsystem from user mode to kernel mode, kernel mode driver will be discussed later in this document. Almost all programming languages allow programmers to access parallel port using some library functions. For example , Borland C is providing "Inportb" and "Outportb" functions to read or write IO mapped peripherals on windows 98. But again you need access of ring 0 (kernel ring) to communicate with your parallel port .

6.5.1 Dos Address of parallel port

0040:0000 BC 03 78 03 78 02 C0 9F LPT1 Address in little endian form: BC03, which is actually 03BC. Also note that the first eight offset are not shown as this is the dump of memory location 0040:0800. The above dump can be obtained in DEBUG by entering the following command -d 0040:008

6.5.1 Basic Assembly to send data to parallel port

Debug can execute assembly language instruction. 0. For windows 98 release. 1. Start Debug by Start > Run >type DEBUG 2 Type A (to Assemble) and press enter. mov dx,03bc ;Port Address mov ax,255 ;Port Data out dx,al ;Perform Writer Operation

The number on the left (Segment & offsets) can be different on your machine, don't worry about them. After you type the last instruction i.e. out dx,al press enter twice. You

will then return to the hypen prompt . Now enter G and press enter. You will see that all LEDs have turned on, Change the value in AL to achieve desired effect. 6.6 Configuration Parallel Port Mode In Bios For PowerCell Device

PowerCell Device will work perfect under these Bios setting for parallel port.

1) Printer Mode (Sometimes called Default or Normal Mode)

2) Standard & Bi-directional (SPP) Mode is the bi-directional mode. Using this mode, bit 5 of the Control Port will reverse the direction of the port, so you can read back a value on the data lines.

3) enable Bidirectional mode for selected printer port. 4) OnBoard Parallel Port = Auto(windows will assign 378 as base address) You can change this setting from windows also selecting Device Manager. Note: These settings are from Ami Bios setup version 1.20E , But it will work on

all other systems with same configuration. 6.6.1 Pin Configuration Of PowerCell Device with Parallel Port. 'DB-25(P1) C^0 = mC P 3.2 P12(INT0) 'DB-25(P14) C^1 = mC P 3.3 P13(INT1) ' DB-25 Pin DB-25 Port &H378 MICROCONTORLLER PINS ' C^0_C^1_________D0................D7___________P12___P13 ' ' '195 '3' 0 0 PERFORM BOTH OPERATION 0 0 '194 '2' 1 0 READmC 1 0 IN '193 '1' 0 1 WRITEmC 0 1 OUT '192 '0' 1 1 CLEARmC 1 1

6.6.2 How PowerCell Device communicate with Parallel Port.

At the moment PowerCell device don’t support any PnP options, it provides a GUI host interface and WAP based interface.

As mentioned above the data port of D25 is attached with port 1 of microcontroller for bidirectional communication. Provided interface let user to perform either activity, I/O read or write.

When host interface wants to perform write operation then.

1) It throws data on Data register (Base Address + 0)of parallel port which is connected with port 1 of microcontroller

NowWrite Val("&H378"), Val(xxx) ' send data to mC Port 1

2)It sends a high signal to microcontroller P3.3 (INT1) via parallel port Control register (Base Address + 2), by raising the interrupt pin high on microcontroller.

NowWrite Val("&H37A"), Val(WRITEmC)

3) microcontroller fetch data from its port 1 and then moves it to port 2 which is connected with PowerCell Relay Board via 10 Pin IDC. Controller assembly :

MOV A, P1 MOV P2,A 4) clear the INT1 NowWrite Val("&H37A"), Val(CLEARmC) ' clear C0 , C1

When the host sends data to the device, the device must respond by sending a code that indicates whether it accepted the data or was too busy to handle it. On the other hand, when data is sent from the host to device, the device must respond turning the relay board LED’s ON.

6.6.3 Collecting data through a parallel port from installed ADC0804 chip on PowerCell device When host interface wants to perform read operation then.

1) Prepare Data Register (Base Address + 0) for Input for avoiding any raw values. NowWrite Val("&H378"), Val(CLEARuC) 2) It sends a high signal to microcontroller P3.2 (INT0) via parallel port Control register (Base Address + 2), by raising the interrupt pin high on microcontroller NowWrite Val("&H37A"), Val(READuC) ' signal ADC to start conversion 3) Let the ADC finish conversion using sleep from win32 kernel32.dll Sleep (9)

4) Prepare Data Register (Base Address + 0) for bi-directional use while setting high pin 5 of (Base Address + 2). NowWrite Val("&H37A"), Val(BIDIRECTECTION) 'Prepare the Port for ADC data 5) Let the microcontroller transfer it data using sleep from win32 kernel32.dll Sleep (1) Controller assembly : Mov A , P0 Mov P1 , A 6) Get data from Data Port (Base Address + 0) temp = Inp(Val("&H378")) 7) clear the INT1

NowWrite Val("&H37A"), Val(CLEARuC) ' clear C0 , C1

7 PowerCell Driver Architecture

All the software development uses development tools and compliers from (Microsoft Visual Studio) and debugger was used from systeminternals. The programming language for kernel mode driver (PowerCell.sys) is C language And win32 API is developed in C++. VB dynamic link library is responsible for web interface of device. The driver is a monolithic type driver. It enables the access to the hardware directly from within Win32 application (in user mode). The driver architecture GUI application (PCVBDemo.exe), user-mode library win32 API (PowerCIO.dll), and kernel-mode driver (PowerCell.sys). Figure 10 illustrates the architecture of PowerCell driver .

Figure 10. Flow from PCVBDemo.exe to PowerCell Device

In order to access the hardware from WAP interface application makes calls to

one of the functions from the user-mode library PCIOCLASS.dll, which then calls the

PowerCIO.dll in terms to call kernel-mode driver located in the operating system. The kernel-mode driver accesses the PowerCell device resources through the native system-dependent calls. Figure 11 illustrates the driver architecture for WAP interface that has been developed for this project.

7.1 Driver software modules

Table summarizes the core driver software modules and their descriptions. Driver Software Modules Module Description MicroController Code Pcell.asm Assembly Code For Micro Controller Pcell.hex Hex Code for microcontroller Kernel Mode Driver Code(Ring 0) PowerCelldrv.h Kernel mode driver header file to declare WDM read , write constants PowerCelldrv.c Kernel mode driver source PowerCelldrv.rc Static library resources of kernel mode driver Sources DDK Use this file to compile driver ntddk.h For WDM constants MAKEFILE To build kernel mode driver source FOR COMPILING THE PowerCIO.dll (Ring 1 , 2) resource.h Header file of PowerCIOdrv.rc osversion.cpp To initiate the kernel mode driver If OS is not allowing the direct access

to parallel port. PowerCelldrv.h user mode API implementations and declarations PowerCIO.cpp definitions of the parallel port user-mode logic interface PowerCIOdrv.rc Resource file for PowerCIO.dll PowerCell.sys The kernel-mode library includes loading and unloading the driver PowerCIO.dll Compiled PE For Compiling PCIOprj.dll (Ring 2) PCIOprj04.vbp VB project file PCIOcls.cls Class file providing handle from ring 3 to Ring 0 PCIOprj.dll Compiled PE Host Interface Of PowerCell Device Project (Ring 3) PCVBDemo.vbp VB project file frmmain.frm Start up form of project, Provide user friendly interface for device. frmnew.frm Administrator view to add or delete clients for WAP site modmain.bas Utility module PCVBDemo.exe Compiled PE PowerCell Application (WAP + Host Interface) PowerCell.vbp FrmMain.frm FrmLogin Frmsetting.frm Frmcontrol.frm Frmhost.frm Frmnew.frm FrmBrowser.frm FrmAbout.frm Module1. PowerCell.exe Compiled PE WAP interface Project Files (Ring 3) default.asp Start up page for WAP clients reg_user.asp Options available for authorized users PCerror.asp Error page in case of Non authorized users save_settings.asp Operational page for interacting with deveice Global.asa Used to handle user session and Application level variables. DataStore.inc Connection to data base

Timer.asp Setting timer for device Back End DataBase UMTDB SQL server 2000 Desktop edition.

8 Manual installation Of Driver And Quick Start

You can manually install the driver on Windows by copying both driver and dll files to the corresponding system directories.You don’t need to reboot your system after installation.

1. Make sure your BIOS settings are according to requirements described in Configuration Parallel Port Mode In Bios For PowerCell Device section.

2. Copy the kernel mode driver file PowerCell.sys to Windows’ drivers directory on the target PC - %windir%\system32\drivers

3. Copy the driver win32 interface file PowerCIO.dll in %windir%\system32 folder.

4. Copy the WAP driver win32 interface file PCIOCLASS.dll in %windir%\system32 folder.

5. Plug in PowerCell Device properly. 6. Now power up both DC out put adapters (12 V and 5 V). make sure that 12

Vcc is applied to PowerCell Relay board and 5 V are supplied to PowerCell Device(microcontroller PCB).

7. To interact with device from host machine open PCVBDemo.exe or PowerCell.exe

8. To interact with device from over the network type YOUR_DNS\default.asp in your WAP enable browser.

9. You have to provide keyCode and appropriate campus name for logging in WAP site.

CATUIONS: Software and as well as both boards are tested again and again on XP and 2000 and I should work perfect on 98 , Me , Long Horn systems. If PowerCell Device returns 255 as a temperature value then please follow these steps. 1) Disconnecting power supplies from both PCBs. 2) Power them again. 3) And start application. Host interface provides some debugging and testing options. You can write to specific bit of required port for testing and debugging purpose. 8.1 Batch installation.

Tow batch files are available for quick installation of driver. 1) XPPCell.bat for NT 4 pro systems. 2) Win98PCell.bat for Win98

9 Kernel mode driver development

Building a driver is not the same as building a user-mode application. In order to build a working driver, you have to use the "free" and "checked" operating system builds and configure the build environments for the driver. You also need to perform the iterative testing and debugging on as many hardware configurations as possible. The driver development process could be summarized as below and explained in more detail after the summary. 1. Writing the driver code in standard complier in C. 2. Building checked version of the driver in WINXP DDK. Test and debug the checked driver. 3. Building free version of the driver in WINXP DDK. Test and debug the free driver. 4. Tuning the performance of the driver on the free build. 5. Final testing and verification using the free build. 9.1 Microsoft Windows Driver Development Kit (DDK)

Microsoft provides Driver Development Kits for all of it's operating systems which includes example device drivers. The Windows 98 and Windows 2000 DDK's is available for download from www.microsoft.com/ddk. The Windows XP DDK is only available through MSDN registration or by ordering a copy on CDROM. All the DDKs except XP require Visual C to be installed. The windows XP DDK includes build tools alleviating the need to have a compiler installed. 9.2 Driver building environment in DDK

The WINXP DDK provides two environments (free build and checked build) for building drivers. You should use both environments to build, test and debug your driver. In the early stages of driver development you should use the checked build to debug the driver. It contains extra error checking, argument verification, and additional debugging code that is not available in the free build. It helps protect against many driver errors. Performance tuning, final testing, and verification of the driver should be done on the free build. The drivers are built with full optimization, and debugging asserts are

disabled. The faster speed of the free build makes it possible to detect race conditions and other synchronization problems. 9.3 Build utility

The build utility is used to build the samples, drivers, and associated software components that are supplied in the WINXP DDK. The build utility helps you maintain target-dependent information, such as source file names and paths to header files and output directories, in a single file. The utility automatically sets the compiler and linker switches that are required to create output files for specific platforms that you specify. 9.4 Running the build utility

When you open a build environment window, the directory in the window is set to the default directory for the WINXP DDK. Before running the build utility, you must first create a number of data files. The build utility requires the files, as illustrated in Table 3, to build a driver. Table 3. Required files for the build utility to build a driver. File Location

source files (.c) Typically reside in a subdirectory of the DDK install directory, but can be anywhere.

Sources File (sources) Required in each directory that contains source files. The sources file lists the source files to be compiled and linked, and specifies values for certain macros.

makefile File (makefile) Required in each directory that contains a sources file. The makefile file specifies dependency relationships, compiler and linker options, and various other build-related settings.

dirs File (dirs) Optional file used to compile source code in multiple subdirectories automatically. This contains macros called DIRS and OPTIONAL_DIRS that specify the directories to open recursively and the order in which they should be opened.

The build utility (build.exe) is invoked from the command line of the build

environment window. On the command line, you type: build

9.5 Driver code building example 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

2. A directory tree must be created in subdirectories of target path. \\i386\CHECKED

\\i386\FREE . . 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. 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. Steps reqired to compile the *.lib fle(Static library project) 1) Choose static project 2) Load the interface of your sys file in xxx.cpp 3) After compiling lib ready to call in Win32 console C++ project, lib file will be the same as the project name. //More or less same steps are required to compile the dynamic lib, dynamic library project produces *.dll file Steps required to compile the win32 exe using static lib funtions 1) get the std call for funtions 2) copy your required lib in same exe folder 9.6 Driver debugging

The WINXP DDK includes the Debugging Tools for Windows package. This package contains extremely powerful user-mode and kernel-mode debuggers that can debug applications, drivers, and services running on any NT-based operating system. We have used Debugger from systeminternals DBGVIEW.EXE for our project. 10 Conclusions

With the help of tutorial and free source code for Input32 Project from logix4u.net, we developed a driver and application for our PowerCell microcontroller device. It really provided us strong understanding of kernel mode driver. We are greatly thankful to Our advisors and Mr. Amir(E-LAB) who provide us step by step guidance for building PowerCell Device. Other references can been seen under Reference headings.

Compiling the kernel mode driver do require certain tools and environment. Though XP DDK provides all the necessary tools and utilities but it is still requires good knowledge of operating system and hardware know how of PCs.

12 References Electronics section :

http://www.eleinmec.com/article.asp?29 http://boondog.com/ http://8052.com/ http://www.du.edu/~etuttle/electron/elect51.htm http://polcad.w.interia.pl/links.htm http://www.voti.nl/blink/index.html

Driver section : http://www.logix4u.net/inpout32.htm For understanding the basic of parallel port driver. http://crisp.ece.cornell.edu/mengproj/alan_report.doc. http://www.driverforum.com/index.htm http://msdn.microsoft.com/library/default.asp?url=/library/en-us/parallel/hh/parallel/vspd_c292ce44-8328-4b86-85fe-c5a2375c500f.xml.asp http://www.microsoft.com/technet/prodtechnol/ntwrkstn/evaluate/featfunc/kernelwp.mspx http://www.osronline.com/article.cfm?article=224 http://www.phdcc.com/WDMarticle.html http://hollistech.com/Resources/ddkbuild/ddkbuild.htm http://www.wd-3.com/archive/HowBuild.htm

“Introduction to Windows NT Drivers “ Author: Art Baker Publisher: Prentice Hall

“Introducing Windows Driver Framework” by Walter Oney

Parallel Port Concept and HW specification standards: http://standards.ieee.org/reading/ieee/std_public/description/busarch/1284-1994_desc.html Please consult IEEE 1284 for parallel port tyes and modes. http://www.lvr.com/files/ibmlpt.txt A comprehensive link of FAQ’s. http://www.ctips.com/para.html http://b.domaindlx.com/obaid/pport/parallel_port_led.asp http://www.epanorama.net/circuits/parallel_output.html http://www.beyondlogic.org/spp/parallel.htm http://www.mpc-data.co.uk/articles/guide_parallel_ports.htm http://webster.cs.ucr.edu/AoA/DOS/pdf/ch21.pdf http://members.surfeu.at/org2/hardware/parallel.htm

WAP section :

Operating system concepts and fundamentals section :

Windows Architecture By Steven Roman

http://www.gelon.net/ http://www.bsu.edu/classes/nasseh/cs276/module4.html http://silverstr.ufies.org/lotr0/terminology.html http://www.cwdixon.com/support/win98_support/apps_ring_architecture.htm