05508 – ee plasmon multimedia kiosk -...
Post on 14-Mar-2020
3 Views
Preview:
TRANSCRIPT
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
Rank Pro’s Con’s Pro’s Con’s
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
Rank Pro’s Con’s Pro’s Con’s
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
Wake-up Presentation from Screen Saver.
Disable further Presence Sense Interrupts
0 0 0 0 0 0 0 1 1
Wake-up Presentation from Screen Saver.
Disable further Presence Sense Interrupts
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
0 1 0 0 0 0 1 x xNavigate to Menu Choice
#2
0 0 1 0 0 0 0 x xWake up. Go to Main
Menu
0 0 1 0 0 0 1 x xNavigate to Menu Choice
#3
0 0 0 1 0 0 0 x xWake up. Go to Main
Menu
0 0 0 1 0 0 1 x xNavigate to Menu Choice
#4
0 0 0 0 1 0 0 Wake up. Go to Main
Menu
0 0 0 0 1 0 1 x xNavigate to Menu Choice
#5
0 0 0 0 0 1 0 Wake up. Go to Main
Menu
0 0 0 0 0 1 1 x xNavigate to Menu Choice
#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:
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.
top related