1 Problem Description

1.1 Overview

For the Fall 1995 semester, Ryan Wigley and Derek Creech proposed and built PAWS (Print quota Access With Speed), an Eos print quota access machine. The device would take $5.00 bills and the user's social security number with the intention of updating the user's print quota. This device was designed to interface with the Eos system, but the Eos interface was not completed. In the Spring 1996 semester, Sean Korb and Kent Voorhees refined the user interface and simulated an installation of the PAWS system into the Eos environment. It is now a trivial undertaking to install the machine in 100 Leazar as a 24 hour print quota access device.

1.2 Background

Currently, students desiring to increase their print quota must go to a WolfCopy center during business hours. Since many users run out of print quota during the evening or on weekends, it is desirable to have 24 hour print quota access. This is best accomplished with a vending machine type device that is capable of acknowledging the users ID and updating the users quota when money is inserted into the machine.

Ryan Wigley and Derek Creech built such a device , and Mr. Voorhees and Mr. Korb modified the prototype such that it effectively communicates with the Eos network. The device can now successfully update user's quota, and it can it access a database of user IDs. A picture of PAWS is shown in figure 1.2.1.

Figure 1.2.1
Courtesy of Ryan Wigley and Derek Creech

A development environment was procured to simulate the communications activity of PAWS and facilitate it's installation. The installation of the PAWS device onto an Eos server is designed to be a trivial undertaking.

2 Project Analysis

Many issues are raised with the development of the PAWS device, including security, maintainability, and usability.

2.1 Security

The PAWS device will be installed in 100 Leazar which currently maintains 24 hour security over the equipment in the lab. The PAWS bill acceptor is in a standard wall mounted strong box with "key in crank" access to received payment.

Access to the students login ID via student ID number will be on a secure privileged server. Only the student ID number will be available for the student to view. In this manner, a student has no useful access to the PAWS database of user ID strings and student ID numbers except to update print quota to a particular student ID.

A log of transactions is kept so that accounts may be balanced with money received by the PAWS device. See the software manual in Appendix C for details.

2.2 Maintainability

The micro-controller is a 68HC711 made by Motorola. This is a popular micro-controller with a great deal of support from Motorola and by developers all over the world. Code for PAWS will be stored in EPROM and EEPROM on the device itself, and cannot be erased except with intense ultra-violet radiation. However, should the code fail, or need adjustment, source code will be available with documentation on a World Wide Web site with access limited to authorized PAWS operators such as WolfCopy, the Computing Center and IT&ECS.

The majority of the code for the PAWS host server and it's slave programs will be written in PERL 4. This will insure cross platform compatibility across BSD Unix systems and close compatibility with System V Unix. Documentation of the code and a software manual will facilitate maintenance of the server program (see Appendix C).

The bill reader itself is of standard industrial design, but a more modern equivalent would be desirable. The same operating principals should be transferable to another bill reader.

2.3 Usability

24 hour print quota access makes adding print quota much more convenient. Since the PAWS device is located in the largest public Eos lab, most students will not need to walk very far in order to update their quota. Cumbersome paperwork need not be filled out, and the traditional wait for up to 1 hour for print quota to be updated will be eliminated.

The use of student ID numbers was considered a distinguishing way to verify a student's identity, and also a number that most students know. The interface to the students is a 16 by 2 character display so that feedback can be delivered to the student while using the device.

3 Design Considerations

3.1 Processing Platform

The micro-controller used is from the Motorola MC68HC11 microprocessor family, specifically, the MC68HC711E9 which has a built in 12k EPROM.

The MC68HC711E9 has 512 bytes of RAM and 512 bytes of EEPROM. Because we cannot ensure that the power will not be interrupted, the design requires that the program and data be stored in either EEPROM or EPROM. This design needs 3k of memory which is more than accommodated by the 12k internal EPROM the 711 chip provides.

Burning the BUFFALO monitor into the EPROM was considered because of the ease of using a monitor, but was abandoned when we found that it would take almost all of our volatile EPROM. A monitor emulator that runs on a MS-DOS platform was used.

The MC68HC711 micro-controller is a full featured processor easily capable of handling the tasks of controlling the user interface. The MC68HC711 has five built in ports labeled A thru E. These are used to access the LCD, keypad, bill reader, serial interface and a LED indicator. The interfacing to these components was already completed by Mr. Creech and Mr. Wigley. A block diagram of the micro-controller interface is shown in figure 3.1.1. and a schematic of the wiring harness is presented in Appendix B.

Figure 3.1.1

3.2 Host Server

The host server for PAWS must accomplish a variety of tasks. It must be able to communicate with the PAWS device via serial cable, and it must also be able to communicate with the Eos network in a privileged mode. Two privileged actions are required of the PAWS server. It must be able to access a database with both user ID strings and student ID numbers. Secondly, it must be able to increase a users print quota. Other actions, such as record keeping and user interface service will also be necessary.

4 Design Decisions and Implementation

Many of the project parameters were already fixed by Ryan Wigley and Derek Creech when they prototyped PAWS for their senior design project.

Few alterations were made to the original hardware prototype, though since there was more usable memory, the user interface was fleshed out somewhat.

4.1 The 68HC711 Micro-controller

More memory was needed to hold the final version of the assembly code for the MC68HC11. An MC68HC711 would provide 12k of EPROM which would be more than adequate for our project. Finding working MC68HC711 processors was a non-trivial task. This combined with the fact that those micro-controllers are back ordered six months caused dismay. We considered changing the operating mode of the MC68HC11 to expanded mode. In expanded mode the address, data, and control lines of the processor can be used to access a large variety of components. This would be advantageous since we could add arbitrary amounts of EPROM. RAM could also be installed for development work, bypassing the time consuming program and erase cycle of an EPROM. The cost was losing three of the built in ports of the MC68HC11. This would throw out all the interfacing work completed already. Fortunately, a working MC68HC711 was located. The integration of the MC68HC711 into the PAWS unit was nearly seamless, though as mentioned before, we were not able to use the BUFFALO monitor program and were compelled to use the free-ware PC Bug to perform down-loading and simulation.

4.2 Interface of PAWS to Eos

A DECstation 3100 was appropriated as a development platform for PAWS server construction. Programs were created in PERL 4 to simulate the action of the lpquota command in privileged mode, and access to a flat file of user IDs and student ID numbers. An SQL database was also procured to simulate the hes_db.dbo.userinfo SQL database that already exists on campus. To use the campus database, the account and password fields will need to be changed in the PAWS service program to access the privileged table. A data flow diagram of the PAWS system appears in Figure 4.2.1.

Figure 4.2.1

The PAWS device communicates with it's host through an RS-232 serial connection using 8 bit, 1 stop bit, no parity. Since the device transmits and receives a maximum of 15 bytes at a time, a complex protocol seemed unwarranted.

Since the majority of the host server program and assisting programs is written in PERL 4, it will not be difficult to move the server program from the DECstation development environment to a Sun Sparc or DEC Alpha based server in the Leazar server room.

4.3 Function of PAWS

The PAWS host server constantly monitors the serial port that the PAWS device is connected to. The PAWS device, in it's wait state, displays scrolling messages to the passers by. The messages are to attract attention and interest in using the PAWS device. These messages of propaganda continuously bombard the public in a variety of scrolling styles. When a user walks up and hits any key PAWS is set into action. It displays the input screen:

Enter ID Number

As the user hits the keys to enter their ID number PAWS displays the numbers on the screen. If the user makes a mistake they can correct the error with either the backspace key (B), or with the clear key (C). Both are clearly labeled on the PAWS device. Also they can quit the transaction at any time with the abort key (A). When all nine numbers of the student ID number have been entered PAWS automatically initiates the lookup process with the PAWS host. It sends the ID number along with the lookup command through the serial connection. The PAWS device then waits a standard amount of time for the host to respond with the lookup results. The host is logged into Eos in privileged mode, and searches an SQL database for a login ID that matches the student ID number inputted. The login is then returned to the host and used in the lpquota command to find out the user quota data. The PAWS host parses through this data to determine whether printing is off or on, and how much quota the person has. The host then returns the results of this lookup to the device through the serial connection with a tag to indicate a successful or unsuccessful transaction. If the lookup failed the PAWS device displays:

Failed lookup!!!

And returns to the scrolling messages after a short pause. If it passed the lookup the PAWS device displays:

account verified

After a short pause it displays the quota information returned by the host. If printing is turned off the display is the following

Quota=-XX.XX off
Insert $5 bills

If printing is on the display is the following:

Quota=+XX.XX on
Insert $5 bills

If the host is having network problems or is down and the PAWS device does not get a response within the allotted time the device displays messages that the communication is down and tries to synchronizes the connection.

At the "Insert $5.00" prompt, the user has 45 seconds to insert a $5.00 bill into the bill acceptor. This is to allow for those old wrinkled up bills that take a few attempts to satisfy the bill acceptor. When the 45 seconds are up and no bills have been entered the device will cut the bill machine off and ask if you would like more time.

Need more time ?
D/Yes / A/No

If there is no response in 15 seconds the device quits the transaction and goes back to scrolling the messages.

If the user does insert a bill in the 45 second window the device sends the ID number of the user with the increase command. The host performs an increase of the user's print quota by $5.00 on the Eos system and if $5.00 is greater than or equal to what was needed, printing is turned on for the user. The host also sends the newly updated information to PAWS The PAWS device then quickly displays:

Bill accepted
Quota up $5.00

Then after a short pause it shows the user the updated quota information:

Quota=(+/-)XX.XX (on/off)
Insert $5 bills

The PAWS device and host can indefinitely update a users quota like this. If the user wants to quit they can hit the (D) key for done or simply walk off. The device with wait for a bill 45 seconds then for 15 more seconds then return to the wait state of scrolling.

If the device does not get a response from the host when it is trying to increase quota it will display a warning screen for the user. This screen tells the user to check if their quota has been increased. If PAWS failed to increase their quota but took their money they are told to go to Wolf Copy for assistance.

A simplified flow chart is shown in figure 4.3.1.

Figure 4.3.1

4.4 Activity of the PAWS Host Server

The details of how the host communicates with PAWS are withheld for security reasons, but an overview is presented here. Appendix C is available with the source code for privileged readers. The host program was developed and tested on a DECstation 3100.

4.4.1 Simulation of lpquota command and SQL database

A program was written in PERL to simulate the actions of the lpquota command when used by a privileged user. Normally, a user can only check their own printer quota status, and is barred from increasing his/her printer quota on their own or anyone else's account. Privileged users may view all other user's quota status and manipulate other user's printer quota in a variety of ways, but an increase of $5.00 is all we are interested in. All lpquota commands return the current printer quota status for the user.

A PERL program was also written to parse a flat file of imaginary users and student ID numbers such that a user name would be returned if queried on a student ID number.

Recently, an SQL database table was procured from the Computer Science Department. SybPERL was used to perform the same function as the file parser, but using Sybase instead. User names were successfully retrieved in this way, and the experimental SQL table used is of the same form as the hes_db.dbo.userinfo table that would be used in the final installation of PAWS. This code is incorporated into the PAWS host program.

4.4.2 The PAWS Host Program

The PAWS host program incorporates many service routines to serve PAWS the information it requests via serial connection. The program maintains an infinite loop that waits for command directives from PAWS. A separate program conditions the serial line to match that of PAWS as 8 bits, one stop bit and no parity. This program reinitializes the serial line once every second to maintain the device configuration on a DEC 3100.

When the PAWS host receives a complete command string, it checks it for conformity to known commands, and executes a lookup or an increase on lpquota if the command is valid. If the command is invalid, the host returns a string indicating a failure in communication. The same failure string is transmitted if the user's ID number is invalid, or if there is no lpquota information regarding that user.

Upon a successful lookup of the user name using a SybPERL query of it's database, the host executes an lpquota command for that user, and parses the information on the user's quota limit and usage. The command would look like this from a shell on the Eos system:

eos%lpquota -Plez100 userid
Username        : userid
Service         : eos
Usage: $60.97           Limit: $65.00
Last bill: $0.00        Ytd billed: $0.00
Printing is allowed

Only the third line is examined, and the limit amount is subtracted from the usage amount. This number is rounded into a string conforming to dollars and cents conventions, and appended to a return string for PAWS. This string is sent down the serial port for PAWS and the program waits for more input.

An increase command from PAWS initiates a similar course of action, except that the lpquota command is altered to affect an increase on the user's quota, and if their usage is less than or equal to their limit, printing is turned on by using the -f1 switch in the lpquota command. The command would look like this from a shell on the Eos system:

eos%lpquota -f1 -Plez100 -i 500 userid
Username        : userid
Service         : eos
Usage: $60.97           Limit: $70.00
Last bill: $0.00        Ytd billed: $0.00
Printing is allowed

Again, the third line is examined, and the information is returned to PAWS.

4.5 Maintenance and Service to the PAWS System

The PAWS host keeps a continuous log of each transaction, including a time stamp, the message received from PAWS, the user name of the customer, and the acknowledgment string sent back to PAWS. This log may be viewed by a text editor available on the Eos system.

A program is provided to show how much money is in the box for accounting purposes. One simply enters the date and time the money was last removed from the box, and the program parses the log file after that time stamp to collect data on the transactions, displaying the received total on the screen.

This document and complete appendices will be stored in


which has access limited to only IT&ECS employees who will support the hardware and software of the PAWS system.

5 Observations and Conclusions

Getting a micro-controller to talk to a computer is a non-trivial endeavor. Unix has many approaches to serial line conditioning, and none of these are uniform across platforms. We thought it interesting that a DEC 3100 will "forget" it's line conditioning commands unless you remind it on occasion. It was also interesting that different Linux machines respond differently to serial communication, though they all claim to be "IBM compatible".

Programming a MC68HC11 can be a long and arduous task when most of it's function is I/O. Much of what our device was doing was sending instructions to the LCD display, taking input from the keyboard, and maintaining serial communication with the host. Debugging was made much more difficult because of these facts, but we endeavored to make the assembly code modular to assist in tracking down problems. We also tried to put the questionable routines into EEPROM rather than EPROM to try to save time and memory space for multiple test down-loads.

We are grateful to Ryan Wigley and Derek Creech for outlining the design beforehand, allowing us to get right to work on implementation. We only needed to request materials from our sponsor, and proceed along design specifications that were already in place.

Many people consulted on this task suggested using C to program the service routines, but PERL has been shown to be as powerful as C, and as evidenced by this project, it is rather easy to port PERL programs over different platforms. Serial communication in PERL is predictable and practical, and development was quite speedy using this scripting language. The SybPERL extensions make database queries a simple task, and the code embedded in the service program is small and clear.

6 Installation of PAWS on the Eos/Unity Network

The PAWS system can be used when permission is granted to use a database of user names and student ID numbers. A privileged user can log onto a dedicated machine, such as paws.eos.ncsu.edu, and initialize the PAWS service program. The program will continue to work without assistance until the privileged user logs out or his/her tickets die.

It is desirable to have the service program initialized by a privileged daemon that can authenticate itself as a privileged user, and then all the manual service that PAWS will need is for the money to be occasionally removed from the machine. There are several security issues raised with this method, not the least of which is the necessity to store the privileged user's password in plain text. We are currently working to solve this problem.

It is also desirable to have a vending machine that could take various denominations. The PAWS system is flexible enough to allow for new commands to be associated with different denominations, and WolfCopy has expressed some interest in procuring a new vending machine that could read the different denominations. This may be a reasonable design project for next semester if it turns out that the interface is much more complicated. Otherwise, it may be simpler to reprogram the 68HC11 a bit and interface it to the new machine.

7 Credits

We'd like to thank the following for their gracious support for this project: