05508 – EE PLASMON Multimedia Kiosk -...

05508 – EE PLASMON Multimedia Kiosk

Team:

Tracie Johnson

Chris Brazener

Sponsor/Mentor:

Dr. Robert Bowman

Coordinators:

Paul Garsin

Dr. Daniel Phillips

Introduction:

The PLASMON system (Project #05508) is a multi-media kiosk for the Electrical

Engineering Department. The kiosk will serve as a center for up-to-date information as

well as a form of entertainment. The intended target audience consists of both current

and prospective students.

Needs Assessment:

The PLASMON Multimedia Kiosk resides outside of the department of Electrical

Engineering in the Kate Gleason College of Engineering at RIT. Prior to its inception as

a senior design project, the kiosk allowed the user to view a PowerPoint presentation,

which was played repeatedly by a personal computer (PC). The subject matter of the

slide show consisted of information relative to the department of Electrical Engineering,

its staff, faculty, and students.

The existing kiosk is comprised of a widescreen flat-panel monitor, a Pentium III

PC, an audio amplifier, a pair of loudspeakers, an interface board, and a capacitance-

sensing touch plate.. The initial setup of the PLASMON was intended to facilitate

additional hardware for interactivity. The department purchased a capacitive touch panel

for use with the system, as well as interface circuitry and harnessing for connection of the

panel to the parallel port of the computer.

The PLASMON project entailed the creation of design modifications in an effort

to make the kiosk presentation more interactive and informative. Instead of repeatedly

playing a slide show, the new kiosk facilitates interaction with the user, allowing the user

to extract information efficiently. The PLASMON also provides a degree of

entertainment while supplying information about the department.

The end realization of the PLASMON system is a completely interactive and

informative kiosk that incorporates documents, calendars, photos, audio, and video

streams that can be controlled by the user. Since the majority of the users of the kiosk

will be people with an interest in the EE field or the department, the quality of the overall

presentation will be of utmost importance. A strong presentation will allow the kiosk to

attract users and encourage them to learn about the department.

Specifications:

The PLASMON multimedia presentation shall be able to provide the user with the

following content:

Academic Flowcharts for each EE Degree Program

Event Calendars and Department Information

Photo Albums of Faculty/Staff /Students

Information about the PLASMON itself

A Virtual Tour of the Electrical Engineering Department

Provide an entertaining, interactive experience

The PLASMON System shall offer the following to the Operator/Administrator:

Simple and Efficient Updating of Presentation via common Microsoft

Applications

The PLASMON hardware shall consist of the following:

A Pentium 4, PC-Compatible personal computer with the following requirements:

o 2GHz or better CPU

o Minimum 1GB of free Hard drive space

o 128M video card or better

o Minimum 256 MB of RAM

o PS2-configurable Parallel Port

A Quantum Research E-160 six-button charge-transfer touch panel

A 50” High-resolution color plasma display

An audio amplifier and speaker system Part Number: 31-1982B

A presence-sensing device that will begin the presentation when a potential user

approaches the kiosk within five feet

An Interface board to facilitate communications between the touch panel and the

Software.

Deliverables

Below is the list of deliverables to meet customer satisfaction:

1. Complete/functional Software application, which complies to all

required specifications.

2. A Functional interface board with all required harnessing

3. One unpopulated Interface PCB board along with all required parts

for assembly of one additional Interface PCB

4. One Technical Manual Detailing Software and Hardware

Installation and configuration

5. One Users Manual Detailing Presentation Updating.

6. CD containing all software, hardware schematics and layout files,

pictures, videos, manuals, etc.

Concept Development:

The conceptualization for the PLASMON kiosk had been underway prior to

becoming a senior design project. The kiosk booth had been constructed. The monitor, a

Pentium III PC, a touch panel, an interface box, and complete set of harnesses were also

acquired prior to the inception of the 05508 PLASMON senior design project. The

concept development phase was therefore bounded by pre-existing hardware

requirements. Issues addressed in the concept development phase included:

Type of executive programming language

Incorporation of photo albums and video streams

Polling I/O scheme versus interrupt-driven I/O

Hardware and software interaction in response to stimuli from the user

Design of both hardware and software for testability

File structure for easy maintainability

Perhaps the most important concept to be considered is the type of programming

language to be used for the presentation. Prior to Senior Design involvement in the

PLASMON project, the kiosk software was constructed entirely with the Flash MX web

graphics/animation package available from Macromedia. Although this software

facilitates high-quality graphics images and effects, it provides little control over I/O

peripherals such as the parallel port. The files created by Macromedia are very large, and

as a result require a significant amount of time to load before execution can take place.

For these reasons, a brainstorming session was held to determine the best method for

creating the structure of the kiosk software. One result of the session was the idea of

implementing an executive program that could call much smaller files when prompted by

the user. The executive program could run the hidden functions necessary for I/O

handling and menu navigation, while the “slave” program would run the applications

visible to the user, such as photos and video animation.

The executive program idea brought about other issues to be looked at further--

one being which software would be the best for this executive code. Visual Basic and C+

+ were both considered during brainstorming to serve as the executive programming

language. The characteristics determined to be most important in choosing an executive

language include:

Compiling time

Execution Speed

Graphics Capabilities

Easy import/ export of different file types to the presentation

Using these characteristics, a rating system was established. The rating system was

implemented, and results were tabulated in the Feasibility Assessment section of this

report.

A second consideration that required some analysis was the method of

communication between the executive language and the parallel port. Recent Microsoft

Windows operating systems (Windows ’98 and later) require the use of a Kernel-mode

device driver in order to gain access to hardware peripherals. On-line research was

conducted, and four drivers were weighed according to the following characteristics:

Compatibility with executive programming language and operating system

Possible conflicts with existing parallel port drivers

Ease of incorporation of parallel port driver with executive software

Simplicity of Syntax

Ability to read or write to port registers

Ability to respond to hardware interrupts

Price

The results of the rating procedure are documented in the Feasibility Assessment section

of this report.

Visual basic has the ability to read the contents of a folder and point to files.

Because the photo albums were required to be easily modifiable, the concept of file and

folder access was examined closely. It was determined that a photo album folder could

be created to hold all pictures. Within this folder, the administrator could add and

remove files without having to modify code if pointers to files are used in the executive

skeleton. The same is true of faculty interviews. This could allow the users to “page”

through selections simply by moving a pointer.

Design for testability was considered in the early stages of the project. Only one

set of hardware existed, which made testing and development challenging at times. Over

the course of software design, provisions were made that would enable the software

developer to test code on a laptop without requiring the use of the touch panel. Likewise,

during the design of a new interface board, provisions were made that would enable a

system test with only the interface box and a PC. Consideration of design for testability

proved very useful and will benefit future developers of the system.

While the project was in the design stage certain concerns about the polling

structure were expressed. This consideration of interrupt-driven I/O led to

conceptualization of a hardware-software communication scheme that will provide an

interface that is as error-free as possible. Hardware interrupts can be caused by a button

press at the touch panel, or by detection of a user by the presence sensor. The interface

PCB could provide hardware that can allow the software to disable certain events, or

being able to monitor signals without causing an interrupt. This is discussed more in

depth during the feasibility section.

Presence/motion sensors were researched concurrently to conceptualization of the

Interface PCB. Both infrared and ultrasonic sensors were being considered. See the

Feasibility section of this report for a synopsis of sensor selection.

Feasibility:

After assessing the needs and creating software concepts as stated above, the

choices were summarized and then a brief analysis was preformed. Due to previous

decisions determined by the first Engineering Team, the project already had a definitive

direction, which in turn created less of a need for an elaborate feasibility assessment.

One of the focal points in the beginning of the project centered on how the execution of

the menu navigation was going to be preformed. Below, in Table 1, shows a summation

of the decision process. . The two options considered were:

Create an executive skeleton that could call smaller portions of the

presentation upon each input from the user.

Keep the presentation entirely within Macromedia and try to use

Macromedia’s ‘Action Script’ for interfacing.

Executive Program Macromedia

Rank Pro’s Con’s Pro’s Con’s

4

Apparent Parallel Port

communication

capability

(4)

No Apparent Parallel

Port communication

capability

(-4)

3 Faster execution time.

(3)

Approximately 2+

additional weeks of

implementation time

(-3)

Approximately 2+

fewer weeks

implementation

time

(3)

Slower execution time

(-1)

2Past Experience with

Software

(2)

Would require 30+

(small) graphics Swf

files

(-2)

Ability to have one

(large)

graphics .exe file

(2)

No Prior Experience

(-2)

1

Approximately a

fourth of the File

Size. (~112Mb)

(1)

Large files size and

processor usage.

(~ 400Mb)

(-1)

Total: +5 Total: -3

Table 1: Concept Decision 1 - Executive Vs. Macromedia

The above table made it apparent that the Macromedia option wasn’t a feasible

choice. This was confirmed with the shortcomings the previous Engineering team

encountered using this approach. With this evaluation complete, another obstacle

presented its self. The executive program could have been developed using various

software packages. At the time of the concept development the two obvious choices

were to use either C++ or Visual Basic 6.0 due to the software package capabilities.

Refer to Table 2 below for the results.

Visual Basic was ultimately chosen as the executive language for the kiosk.

Visual Basic (VB) has the ability to call other applications such as Macromedia Flash,

Windows Media Player, or Microsoft Office applications within the GUI. This provides

a degree of modularity with respect to modification and upkeep of the presentation. If a

video or spreadsheet needs to be changed, the administrator can simply replace the source

file. This modularity gives rise to the overall file and directory structure of the kiosk

software.

C++ Visual Basic 6.0


4

Software created for

data and register

manipulations.

Important for the

Parallel Port

(4)

Software package not

created for additional

“plug and play”

graphics

(-4)

Microsoft package allows

easy compatibility with

other Microsoft products

using OLE containers

(Word, excel etc.)

(4)

3

Approximately 2

additional weeks added

to implement time

(-3)

Software package designed

specifically for GUI

applications

(3)

Software package

not used for in depth

register

manipulation

needed for the PP

(-3)

2

Compiled language

(2)

Current .swf integration

available

(2)

Interpreted

Language

(-2)

1

Prior VB team experience,

leading to approximately 2

fewer weeks for

implementation time

(1)

Total: -1 Total: +5

Table 2: Concept Decision 2 - C++ Vs Visual Basic

Using both of these assessments the project went underway using a Visual Basic

executive program that utilizes different Macromedia .swf movie files depending on user

input.

The project initially adopted a polling structure in order to detect a user key press.

However there were a few concerns expressed pertaining to the CPU processing power

being consumed consistently while the program was running. Although the presentation

seemed to be operating within the real time specification, future additions may have an

impact and create a time lag or a discontinuous appearance. At this time, a proposal to

transfer to an interrupt driven structure was considered. Although this would involve a

complete redesign of the current I/O scheme, the system would be a more robust and

practical application. Below in Table 3, is the layout of the decision process.

Alter to an Interrupt Structure Pursue Current Polling Structure


4

Frees up to 10 times the CPU

Processing time

(4)

Loose up to 3 weeks

of project design

(-4)

Will have up to 3

additional weeks to

create additions

(4)

May limit future

additions, and

usage of the kiosk

(-4)

3Creates a smoother real-time

presentation

(3)

Design/build/purchase

new Interface board

capable of interrupts

(3)

2

Would satisfy customer

specifications to a greater extent

(2)

1Provides valuable team experience

(1)

Total: +3 Total: 0

Table 3: Concept Decision 3 - Interrupt Vs. Polling

After evaluating the different aspects and possible consequences of this change

during the design stage, the team came to the conclusion to peruse the hardware interrupt

structure. In order to make the transition as smooth as possible, most of the existing code

was utilized.

Using a similar process as the previous concept feasibility, the team created a

rating system for the multiple drivers available to implement communication to the

parallel port. Below is a table format of this decision method.

PortTalk TinyPort Inpout32 TVicLPT

Executive Compatibility 1 1 3 5

PC HW Compatibility 3 3 3 5

Syntax 0 3 3 5

Port Manipulation 3 3 3 4

Interrupt Capability 0 0 0 5

Price 5 5 5 3

Total 12 15 17 27

Table 4: Concept Decision 4 – Communications Driver

The TVicLPT driver was determined to be the best choice given the above results.

The main features this particular driver offered was the hardware interrupt capability.

This driver provided extensive technical documentation that proved to be useful during

the initial implementation stage.

During the hardware brainstorming session various motion/presence sensors were

considered, the two primary types being infrared and ultrasonic. The ultrasonic was

determined to be more suitable for this application due to the directionality as well as the

dual adjustable ranges. Although the infrared sensor is more cost effective, the

previously mentioned characteristics are not available within this option. The

functionality of the presence sensor is addressed in more detail within the Hardware

section.

Project Plan:

During the preliminary stage of the project, a schedule was fashioned using

Microsoft Project as shown in Appendix A, Figure 1. The milestones during the

primary phase centered on obtaining communication from the hardware to the software,

along with preparing the prototype version for beta testing on the EE floor of RIT. These

milestones were met with a few exceptions. Obstacles were encountered that impeded

the implementation slightly. However, problems were anticipated and extra time was

built into the project schedule.

During the succeeding stage of the Plasmon Project, a revised schedule was

produced to account for pursuing the replacement of the polling I/O scheme with the

interrupt-driven scheme. The main milestone then became the completion of the

Hardware and Software interrupt driven Interface. Other software milestones included

the implementation of Photo Album software, which also allows the user to view pictures

and interviews of the Electrical Engineering Professors. The proposed project schedule

was subjected to some delays when introduced to additional features that were requested

by the customer. However, the milestones were met with the addition of approximately

20 work hours. For further details on obstacles and solutions that were encountered

during the complete project process, see the section “Compatibility/Debug Issues” of this

report.

A flexible budget of $500 was originally allotted to the Plasmon project. The

final project was completed below budget by approximately $200. In the initial design

phase of the PLASMON, software was the focus and no major purchases were necessary.

The budget was split into four broad categories, additional parts, replacement parts,

resources, and miscellaneous. During Sr. Design II the budget became more pertinent

due to the design of a new interrupt capable interface board as well as the integration of a

presence sensor. For a detailed purchase tracker refer to Appendix A, Figure 2.

Hardware:

The user interface consists of a charge-transfer touch panel. The part chosen for

this design is an E160 evaluation board offered by Quantum Research Group, and is

depicted in Appendix B, Figure 1. See Appendix B, Figure 2 for a schematic diagram

taken from documentation supplied by Quantum.

The touch panel consists of six buttons, which detect body capacitance upon the

presence of the user’s finger. The user’s body capacitance adds to the button capacitance

to actuate the logic level that is sent through the interface box to the parallel port. The

E160 is covered with a clear plexiglass face that fits over the top of the buttons. Upon

installation of the touch panel onto the kiosk structure, this cover is removed such that it

can be fastened to the underside of the plexiglass panel in front of the PLASMON

monitor. Each button on the touch panel is assigned a number. Button #1 is located

adjacent to the pin header, and the numbers increment in a clockwise direction.

The output of the touch panel can be configured via on-board switches to provide

either pulsing actuation or toggling. When set to pulse, the output goes high and then

returns to a low logic level when the user removes his/her finger. When set to toggle

mode, the button must be activated a second time to return the logic level to a low state.

For the PLASMON application, the pulse mode was chosen.

The presence sensor chosen for the kiosk was a SonaSwitch Mini-S. This sensor

has two adjustable sense ranges (“long” and “short”). The sensor emanates periodic

bursts of high-frequency sound waves, which bounce off of anything in front of the

sensor (up to ten feet in range, with a fifteen-degree dispersion angle). For the sensor to

detect a body, three successive reflections must be received. This feature is useful in

minimizing interrupts to the kiosk from rapidly-moving objects or people. See Figure 1

for a visualization of how the sensor responds to objects at varying distances. The Mini-

S is powered by the +12V supply from the PC. It has two open-collector outputs (one

corresponding to each range), which are pulled up to +Vcc on the Interface Board. Upon

detection of an obstruction within a range, the output transistor pulls the corresponding

output low. The sensor is connected to the interface board via a four-conductor Presence

Sensor Harness.

Figure 1: Sensor Reaction to Various Distances

The original interface PCB was designed by Dr. Robert Bowman. It consisted of

a series of buffer amplifiers that convert the +5V logic levels to +3.3V, one for each of

the six buttons. There were also seven through-hole LEDs. One LED indicates when

power is applied to the circuit. The other six each illuminate when their respective

buttons have been pressed. The original interface PCB was used in system development

for the first half of the project. Upon completion of Senior Design II, the decision was

made to change the interface scheme to respond to hardware interrupts at the parallel

port. Dr. Bowman’s design served as a starting point for the new design. As the new

interrupt capable interface PCB was deigned, all possible I/O stimuli were considered.

The embodiment was to consist of circuitry that would accept six logic levels from the

touch panel as well as a logic level from the presence sensor, which had yet to be defined

in the initial design phase of the interrupt-driven interface PCB. Figure 2 shows a

conceptualization of the interface PCB.

The interface PCB is connected to the touch panel through a 10-conductor ribbon

cable that shall be referred to as the touch panel harness. The touch panel harness is

terminated to a DB-9 connector in order to mate with the interface PCB. The other end

of the cable is terminated with an insulation-displacement ribbon connector that mates to

the ten-pin header on the E160. For construction and pinout diagrams of the touch panel

harness, see Appendix B, Figure 9.

Figure 2: Conceptualization of Interface PCB in the PLASMON System

The hardware design of the Interface PCB was dependent on the methods in

which the parallel port would accept and respond to hardware interrupts. The hardware

design of the interface board and the design of the interrupt-handling scheme were thus

developed concurrently. See the Software Implementation section of this report for

information on the Interrupt Service Routine used in the kiosk software.

Possible inputs from the environment would include button presses, presence

sensor signals, and the current state of the presentation. In design of the interface, all

possible combinations of stimuli were considered and desired system responses were

chosen. Hardware was designed accordingly. See Table 7 for a visualization of possible

situations and responses.

It was determined that three control signals were needed for dependable

operation. These three signals could guarantee that only one interrupt would be serviced

at a time. The software could receive the stimulus, take proper actions to service it, and

then send a control signal to hardware indicating the interrupt has been processed. The

hardware can then be reset by software to send another interrupt upon the next user input.

See Appendix B, Figure 3 for a schematic of the Interface PCB.

Button logic levels are fed into a hex buffer chip. On-board tactile switches SW1-

SW6 provide the ability to activate a touch panel input when one is not available, and

also feed the buffers in a wired-OR configuration with the button signals from J1. Quad

NOR-gate U2 is used to invert the open-collector outputs of the presence sensor and to

hold the lines low when the PRES_SENSE_DISABLE line from the parallel port is high.

Jumper JP1 is added in a wired-OR configuration to hold PRES_SENSE_DISABLE high

in hardware. While the interrupts due to the sensor lines are disabled, their respective

logic levels still propagate to the 8-bit latch U5. The open-collector outputs of the sensor

are inverted and fed into an octal-input OR/NOR gate U3 along with each of the button

signals. When any of these signals go high, U3 clocks a D flip-flop U4. The non-

inverting output of U4 goes high. This signal is used to latch the button and sensor logic

levels into U5. The slope of the interrupt line needed to generate a hardware interrupt

can be either a negative-going transition or a positive-going transition, depending on the

PC the system is operating on. Pin header J6 allows the user to select either transition

type. Once a hardware interrupt is generated, subsequent interrupt transitions are

prevented to occur by hardware until the /INT_CLEAR line resets U4 from software, and

all inputs to U3 go low again (ie. the user releases the button). The LATCH_CLEAR line

enables software to make the latch outputs all low. Pin header J5 allows the technician to

select either 5V logic or 3.3V logic. This is, again, dependent on the type of parallel port.

A Bill of Materials is shown in Appendix A, Figure 3 and a Layout diagram for the

Interface PCB can be seen in Appendix B, Figure 4.

The output of the interface PCB consists of eight logic levels (corresponding to

each of the buttons and two sensor lines) and a ground line. The interface PCB is

connected to the parallel port via the parallel port harness. The parallel port harness

(PPH) mates to the interface PCB via a DB15 solder-cup connector. The cable consists

of thirteen conductors- a ground line, six button lines, two presence sensor lines, a

hardware interrupt line, and the three control lines used by software to facilitate I/O

protocol. The PPH mates to the 25-pin parallel port on the back of the PC. An assembly

diagram for the parallel port harness can be found in Appendix B, Figure 5.

The interface PCB requires a +12V supply, +5V supply, and a ground wire for

power. This is supplied by the PC’s power supply via a standard 4-conductor disk drive

power cable. This harness is shown in Appendix B, Figure 6. Once all harnesses have

been constructed, the PLASMON system assembly becomes a simple procedure. Figure

3 depicts the connections required to construct the PLASMON interface system.

Figure 3: System Interconnection

The Parallel Port:

The parallel port connector on the PC is of the DB-25 (IEEE-1284-A) ilk. A

pinout diagram of the PC parallel port connector is shown in Figure 4 below.

Figure 4: PC Parallel Port Connector

The six button lines from the interface PCB connect to the data pins on the

parallel port. Button #1 connects to D0, #2 connects to D1, and so on. There are two

unused data lines (D6 and D7), these are left unimplemented for future revisions of the

design. The use of the parallel port interface requires software to be able to access the

logic levels present on the port pins in order to discern what buttons have been pressed.

There is a bank of registers that resides in the PC’s memory that governs the operation of

the parallel port. For a standard PS/2 port, the bank consists of the data register, the

status register, and the control register. In order to control the parallel port, the locations

and functions of each of these registers must be understood. Figure 5 shows the three

parallel port registers for a standard bidirectional PS/2 port. There are multiple types of

parallel port interfaces. Table 5 shows a comparison of each type. For the PLASMON

system, a bidirectional port is necessary. Regarding the operation and configuration of

the parallel port, the assumption will be made that the port is either of the PS/2 type, or is

emulating the PS/2 type.

Figure 5: Parallel Port Registers

Table 5: Parallel Port Types

The memory locations of the parallel port registers are somewhat standardized.

Typically, the data register for LPT1 resides at memory address 0x378. Its status and

control registers are usually found at 0x379 and 0x37A, respectively. Since these

addresses may not apply to all machines, they must be ascertained before parallel port

interface is possible. This can be accomplished by running WINMSD.EXE from the

RUN selection of the START menu in Windows NT/XP. Figure 6 shows the menu

selections necessary to locate the parallel port (LPT1) addresses.

Figure 6: WINMSD.EXE

Since the parallel port will be used entirely as an input, the bidirectional port must

be configured accordingly. By setting bit 5 of the control register, the output buffers of

the port are placed into a high-impedance mode. The driver will then read high logic

levels from the pins until an external device (the touch panel) pulls the level low. If the

data pins are not configured as inputs, the touch panel could sink enough current through

the port output buffers to damage the port circuitry. A simplified schematic of the

parallel port can be seen in Figure 7.

Figure 7: Simplified Schematic of the Data Register

Parallel Port Interface Implementation:

The TVicLPT parallel port driver was used in the kiosk software to provide

hardware/software interfacing. It is available for download at:

www.entechtaiwain.com/dev/lpt/index.shtm. Benefits of TVicLPT over previous port

drivers include simple syntax and integration into Visual Basic. The TVicLPT driver has

the ability to locate LPT1 in memory automatically, which requires less low-level

hardware knowledge from the programmer.

As discussed earlier, the parallel port must be able to accept eight inputs from the

buttons and sensor (PP data lines), and one input to generate hardware interrupts (ACK).

Three parallel port pins must be used as outputs to control interface hardware. There are

three bits available in the control register that can be used as outputs. The following table

shows choices of parallel port bits to be used as interface control signals:

Parallel Port Signal

Control Register Bit Inverting

Interface ControlSignal

nAutoLF 1 Y LATCH_CLEARnInit 2 N PRES_INT_DISABLE

nSelectIn 3 Y /INT_CLEAR

Table 6: Parallel Port Bit Options

The interrupt service routine needed be designed such that upon the occurrence of

an interrupt, software will disable further interrupts until it has completed servicing the

current interrupt. Further detail pertaining to the software Interrupt Serious Routine refer

to the Software Implementation section.

A synopsis of possible combinations of stimuli and appropriate actions are given

in Table 7. A similar table was used in the creation of the software ISR.

Button 1

Button 2

Button 3

Button 4

Button 5

Button 6

Awake

LongRangeSenso

r

ShortRangeSenso

r Action Taken

0 0 0 0 0 0 0 1 0

Wake-up Presentation from Screen Saver.

Disable further Presence Sense Interrupts

0 0 0 0 0 0 0 0 1



0 0 0 0 0 0 0 1 1



1 0 0 0 0 0 0 x xWake up. Go to Main

Menu

1 0 0 0 0 0 1 x xNavigate to Menu Choice

#1

0 1 0 0 0 0 0 Wake up. Go to Main

Menu


#2


Menu


#3


Menu


#4


Menu


#5


Menu


#6

Table 7: Combinations of User Input and System Reaction

Parallel Port Interface Development/Test:

Visual Basic was used to create a test application to verify proper port operation.

This application was also used in the development of the interrupt service routine

intended to handle hardware interrupts. A screenshot of the test application can be seen

in Figure 19. The interface provides three text boxes displaying a hexadecimal

representation of the data, status, and control ports. Another text box displays an

“INTERRUPT!!” message when a hardware interrupt occurs. The “CLEAR” button

changes the text box back to read “Zzzzz…” Six buttons at the bottom of the window

offer bitwise manipulation of the three control lines used as control signals for the

interface PCB. Once the prototype interface board was constructed, it was connected to

the PC and the test application program was used to verify proper operation of the

hardware. The test application also served as a development tool for the proper

handshaking steps required of the interrupt service routine. The test application was

eventually modified to automatically handshake with the hardware. These modifications

became the basis for I/O interfacing in the kiosk software. The source code can be seen

in Appendix C, Figure 1.

Software Concept:

After evaluating the objectives of the project it was necessary to understand what

had already been completed. The majority of the project still needed to be created but

initial graphics structure and menu navigation had been developed. However much of the

previous work was recreated and elaborated in order to better meet customer satisfaction.

The animation was created using a software package called Macromedia Flash MX. This

software uses a timeline frame-by-frame animation process for which the user defines the

frame rate. An animated scene is created by compiling multiple frames and layers, which

typically include motion ‘tween’. The motion ‘tween’ capability of Flash is a major

defining application for the software, which allows an automatic transition of motion,

color manipulation, etc of an object in two separate frames. This automatic ‘tween’ can

be created over any length of time and distance giving the user control over various

speeds and positioning. A screen capture with component labeling is shown below in

Figure 8.

Figure 8: Macromedia Flash MX

Timeline / FramesLayers

Motion ‘tween’

Added Audio

Current Scene’s graphic screen

The initial conceptualization included some brief code written in Macromedia’s

‘Action Script’, which used the PC’s keypad numbers 1-6 as user input. This input

allowed for navigation through the different menus and animations. However, there were

many drawbacks found in using such a high level script- the most critical being the

inability of ‘Action Script’ to manipulate port registers. The only user input that was

supported by Macromedia was the PC’s keyboard and mouse; the touch pad couldn’t be

incorporated.

Another major issue was the cumbersome maintenance process for the

presentations information. The Macromedia Presentation text can be changed in two

ways, one by using the editing process found in the .fla file. However, the presentation

would have to be exported to a new executable. Macromedia also has the capability to

point to text files (.txt), however, in order for the text to be displayed correctly, the text

file needs to have a code-like syntax instead of plain text. This process also limits how

the text is formatted, (size, color, font, etc). Both of these processes were too time

consuming and technical to be acceptable to meet the customer requirements.

The team decided to use an executive program that would be constructed using

the Visual Basic software package 6.0 as discussed in the Feasibility section. Visual

Basic is an interpreted language, which has the capability to program low-level functions

along with creating and programming high-level GUI’s. This was an important feature

due to the fact the software entailed high-level User Interfaces such as the calendars and

photo albums, but still required low level communication to the PC’s parallel port. In

addition, VB is a Microsoft software package, which facilitates compatibility with many

other Microsoft applications. This provided a solution to the problem of information

maintenance and upkeep. The software now entails standalone Microsoft word

documents and bitmap pictures that can be easily integrated into the presentation.

Software Implementation:

During the actual implementation of the Software design, a top-level menu map

was created and presented to the customer for approval. This can be seen in Appendix B,

Figure 7. After this was done the original Macromedia presentation was broken apart

into many separate Shock Wave Flash (.swf) movies instead of one large executable. The

executive program calls to these 28 short animations to be transition movies between the

menu navigation. The main purpose of these animations are to provide an entertaining

way of presenting different department information as well as display menu options to

the Kiosk user. In addition to the top-level menu map, a lower level software flowchart

was made to represent the Interrupt Service Routine (ISR) as seen in Appendix B, Figure

8. The next step was the actual development of the software. Figure 9 displays part of

the main code executed at the Visual Basic form1 start up in the VB application window.

The function of this code is to set the appropriate parallel port configurations need to set

the touch pad as a user input. This also serves as the initial visual setup by importing a

word document into the richtextbox1, which is a component object of form1. This is

depicted in Figure 10 below. For the complete Visual Basic source code see Appendix

C, Figure 2

Figure 9: Main Menu Startup Code

To prevent idle images from causing “burn-in” on Plasma Screen, a screen saver

appears if the program remains idle for five minutes while in the main menu or ten

minutes while in any sub menu. The screen saver displays random pictures from the

“My Pictures” folder on the PC. If a user walks within a five-foot radius of the kiosk, an

Ultra Sonic Presence Sensor is activated and starts the Plasmon Presentation in the Main

Menu regardless of what menu selection was active when the screen saver was called.

The main menu screen appears as shown below in Figure 10.

Figure 10: Kiosk Main Menu

Richtextbox1

Form1 (Main Menu)

When the program is in its active mode, the object TVic standby until a hardware

interrupt is detected. When an interrupt occurs it is then processed by the ISR which first

masks further interrupts and determines whether it was a key press or a sensor triggered

interrupt. Note that in the active mode all sensor interrupts are masked until the

presentation becomes idle again. When the activated button is determined a variable

intrpval is set to an integer 1-7 depending on a HEX value given by the parallel port

using the Hex(ParPort.DataPort) command. Throughout the code execution a variable

runmain is set and stored to act as a placeholder of where the user currently is in the

menu navigation. These variables are sent to a service routine which determines which

SWF movie to play and what key mapping to creating depending on both the variable

intrpval and runmain. This service routine is depicted in flow chart format seen in

Appendix B, Figure 8.

For an example if button 1 is pressed the parallel port sends either Hex C1 or 1

(depending on if the presence sensor is enabled or not) to the TVic object. The variable

intrvpal is set to 2. If the user was currently in the main menu (runmain = 1) when the

button was pressed the variable runmain is set to 2. The movie,

PLASMONPresentaion_about.swf, is played using the VB container shockwaveflash1

for the “About” sub menu and form2 is displayed while form1 is hidden. The user now

has different options and can press 1-6 to perform selections pertaining to “About the

PLASMON”. Below is a screen shot of the ‘About’ menu as seen in Figure 11.

Figure 11: Kiosk About Menu

In the About mode the user can find out how to use the kiosk, who created the

kiosk, how it works and how to become involved. The About menu offers and option for

the user to view informational help and how to become involved in similar project. This

information is imported into the Visual Basic form2 using another richtextbox object

which calls to Word documents. If the user wants to return to the previous menu at any

time, button 6 has been dedicated to a return command.

The main function of the kiosk is to provide up to date information about the

Electrical Engineering department at RIT. One menu (See Figure 12) that provides

information about the different programs available in the EE department is the Academic

menu. Here, the user can call up seven different flow charts and information nine

Form2, shockwaveflash1

User options while in the “About” menu

Animated Graphics created in Macromedia Flash

academic programs offered at RIT. These flow charts are easily updated by adding pdfs

to Microsoft Word documents located in a EE flow Charts folder.

Figure 12: Kiosk Academic Menu

Another option in the kiosk presentation is the Calendar menu. In this menu, four

months of the department calendar of events are available for viewing along with a list of

upcoming important events. The calendars were created using a Microsoft Word VBS

(Visual Basic Script) program while the “Important dates” file is a standard Word

document. Both were made easy to update by incorporating these often-used Microsoft

applications. This menu can be seen in Figure 13 below.

During the execution of the Calendar code, the program must create six different

user options that are determined by the current month. First the PC’s internal clock is

accessed to obtain a numerical representation of the current month. Next, four variables

are set monthname1, monthname2, monthname3, and monthname4 to the string which

holds the month’s name. These variables are then used to set four Visual Basic objects

called lable1 – 4. These objects are embedded into form2 and are made visible only

while in the Calendar Menu and represent the users six options while in this menu. If

option 1-4 is chosen, a calendar is called and embedded into an OLE container located in

form3. These calendars are Microsoft word documents, which contain VB macros.

The maintenance of the calendars was simplified by creating an automatic

calendar creator. The administrator would have to simply click on a button, which would

open a GUI, then select the appropriate month and year and chose “Apply Changes”.

The program would automatically renumber the days for that month/year, and create a

heading as shown in Figure 15.

Figure 13: Kiosk Calendar Menu

Labels 1-6 displays the user options in the Calendar Submenu

Figure 14: Kiosk Calendar View

Figure 15: Calendar Program

Days are automatically renumbered

A clipart Heading is automatically creating to display Month and year Selected

Easy to Use GUI

The fourth option available to the Kiosk users is the Department Information

menu. In this menu the user can find information pertaining to student and faculty

awards, different clubs and organizations available, Current Sr. Design Projects, Research

Areas, as well as 8 different Photo Albums. Below in Figure 16 is a screen capture of the

Department Information Menu.

The code execution for this menu consists of calling different SWF movies as

well as informational word documents. The concept is similar to the one described for

the previous menus.

Figure 16: Department Information Kiosk Menu

While in the Department Menu the user can access eight different photo albums,

which contain pictures of students, faculty and staff. This album software was written to

be compatible with a Visual Basic Object ImageBox that displays bitmap pictures. A

sample of the Photo Albums is shown in Figure 17.

The execution of the Album software begins by employing a VB object called a

filelistbox. This object is a visible pointer, which calls to a certain folder path and

compiles all of the files with in the specified path. These files names are then displayed

in the filelistbox and used as an available picture list. The Visual Basic form4 consists

of the filelistbox as mentioned, four small image objects used to display picture preview

thumbnails, one large image to display the currently selected picture, five textbox objects

containing the user options and Album title, along with one richtextbox to display any

informational text. During the execution of the Album software a variable index is used

to determine which picture to display while two other variables are used to determine the

next and previous picture.

If the user is the EE Faculty Photo Album only, they have an option to view an

interview of the displayed Professor. When this option is employed form5 displays an

embedded windowsmediaplayer object capable of playing different video and audio

files.

Figure 17: Kiosk Photo Album

Title textbox

User options textboxes

Four thumbnail imageboxes

filelistbox

Large imagebox

richtexbox

One of the last menu options available is the virtual tour as seen in Figure 18.

This option allows the user to go on a guided tour of the EE department directed by

department head Dr. Robert Bowman. This menu also consists of different tours of the

research, teaching and studio labs located on the Electrical Engineering floor at RIT.

These videos are viewed in the same fashion as the professor interviews.

Figure 18: Kiosk Virtual Tour Menu

The option labeled “Who Am I” is to be implemented by other Engineering

Teams in years to come. This option will enable a face/voice recognition system that will

allow students to “register” their faces and voices into the kiosk so that the kiosk will

“remember” them in future encounters. For the current version of the project, there is a

page holder prompting the user to visit this option in the future. In the software an empty

menu slot was made available for easy additions.

Along with the actual PLASMON Presentation software, a test application was

created for easy configuration of the PC’s Parallel Port. In Figure 19, a screen capture of

the GUI application software is shown. Depending on the computer architecture, parallel

ports are either positive or negative edge triggered. Using this application can give the

administrator an easy one-shot way to determine the PC’s structure, register address and

LPT number. This GUI is also used to place the parallel port in either read or write

mode, however for the PLASMON software the parallel port must always remain in the

Read Mode. This program may also be used for an easy debug process to determine if

the parallel port is functioning in the appropriate fashion and reading the correct button

HEX values. The complete Visual Basic source code may be found in Appendix C,

Figure 1.

Figure 19, PLASMON Test Application

Compatibility/Debug Issues:

An initial prototype of the PLASMON system was constructed in the laboratory

while still employing the polling structure. Upon integration of the parallel port driver

code in the presentation software, menu navigation via the touch panel was successful.

However, when trying to port the application to the PLASMON PC, Visual Basic

indicated a “Privileged Instruction” error message. This is an error typically shown when

Windows refuses port access to user-mode applications. It was later discovered that two

versions of the INPOUT32 driver were available online. The version initially evaluated

and eliminated from consideration was available from http://www.lvr.com.

The second version, downloaded from http://www.logix4u.net/inpout32.htm and

based upon the initial version, does perform under Windows XP and uses the same

syntax. The DLL file was copied into the Drivers folder of the PLASMON machine.

The PLASMON application was started up, and no errors resulted. Upon execution, the

parallel port read functions did not return the correct values. When the computer is cold-

booted, the BIOS indicated that the user can select one of many types of ports that LPT1

can emulate. PS/2 mode was chosen, but after configuring the port data lines as inputs, a

data byte of 0x00 was returned. With further investigation it was found that the parallel

port was in fact not configured to the PS/2 mode as stated in the BIOS. INPOUT32 was

used for bit-manipulation of the control ports to force the parallel port into PS/2 mode.

Proper operation was verified by reading port values and validating the proper bit

configurations for PS/2 mode.

Upon implementation of the TVicLPT driver, these problems were eliminated as a

result of the driver’s ability to automatically detect both the memory location and type of

parallel port, as well as improved syntax that eliminates much of the need for individual

bit manipulations.

Design Projections:

The PLASMON Multimedia Kiosk currently has multiple software additions that

will need to be implemented outside of this project. One that was previously mentioned

is the face and voice recognition software. Along with this anticipated addition, the kiosk

software and hardware was designed for flexibility to allow upgrades and feature

improvements for future endeavors.

Conclusion:

http://www.logix4u.net/inpout32.htm

http://www.lvr.com/

In conclusion the project completion was a success. The completed software and

hardware is currently a functioning part of the Electrical Engineering Department. The

project presented many challenges in both the software and hardware realms, as well as

an introduction to hardware/software interfacing. The design team needed to consider all

I/O situations in order to create a robust product. Concurrent hardware and software

redesign required constant communication between team members, as well as a solid

concept for how the interface would work.

05508 – EE PLASMON Multimedia Kiosk -...

Documents

Transcript of 05508 – EE PLASMON Multimedia Kiosk -...