# paper-2

Document Sample

```					                              Design a graphing calculator

Tigas O , Zogopoulos A , Panetsos S , Pagiatakis G
Department of electronics engineering educators
School of Pedagogical and Technological Education ASPETE
Athens , Greece

Abstract— A perfect tool for high school students that will        distinct advantages: it was moderately priced at 30Euros, it
pursue a career in engineering, the graphing and statistics        supported color which allowed us to distinguish separate
calculator combines the functionality of a scientific calculator   equations, and there was sample Mega32 code written by
with graphing capabilities as well as being able to compute        other people that could be used rather than having to write
simple statistics. The purpose of this calculator is to compete    from scratch. After getting it soldered and operational, we
in the graphing calculator market with the common Texas            were able to focus on putting together the calculator itself.
Instruments [2] standard, specifically the TI-83 and TI-89.        The first major part of this project was coding for the PS/2
Our calculator is more simplistic and has no outer case due to     keyboard [3]. After researching with Google [4] , a table of
the limited budget provided. Comparatively, the finished
scan codes and a pin-out diagram were found. The output
product is budgeted at a price (~65 Euros) that is competitive
was relatively simple to verify because the bits were
with other graphing calculators on the market today. Lastly,
the implementation of a PS/2 keyboard allows the user to
checked using an oscilloscope against the scan code table.
have more ease in typing rather than having to use the             Though it was a crude process, it proved to be effective in
"alpha" key to write text.                                         verifying its functionality. The second integral portion
involves building the scientific calculator, which includes
basic math such as addition, subtraction, multiplication, and
I. INTRODUCTION                              division.
Our concern was to create something useful and not
from the scratch due to our low budget. The central idea
was to take hardware and software from other electronic
devices such as : cellar phones and personal computers.
After a long discussion the graphing calculator was chosen.
We used the Mega32 microcontroller from atmel [1] on the
STK programming board also from atmel, which was the
main board of our project. We tried to adapt several
hardware units (small keyboards of common calculators,
cellar phone keyboards) in order to insert the data to our
device. However the personal computer keyboard was the
best choice because of the known scan codes and the user
ability to insert data. As a displaying unit we took a
coloured LCD from an old cellar phone. The formatter will
need to create these components, incorporating the
applicable criteria that follow.

II. HIGHER LEVEL DESIGN
The concept for this project came as a result of
determining what was realistic within the limitations of our
budget. The calculator was perfect for this because we
could implement the software in an incremental fashion
with three major parts. Prior to dealing with the software, it
was essential to have the hardware functioning first. We                    Figure 1. The schematic of the construction
decided to use a Nokia LCD because the LCD had many
A crucial consideration had to be taken here because of     speeds of what the driver was written in (4MHz) and what
the order of operations, which required special attention to    our Mega32 ran at (16MHz). Initially, we attempted to
ensure that the equation string received from the keyboard      compensate for this problem by quadrupling all the delays
to be evaluated is computed properly.                           in the driver, but that did not seem to help and the default
display did not appear. To solve the issue, the Epson [12]
The functions written here (doMath and doCalculation)       command set and color set were added to fix the issue. The
were also used to calculate points to be plotted on the         keyboard presented a bigger challenge then we would have
graphing side. The last important piece of software was the     expected. By doing a little research, we knew how the
graphing calculator. It allows the user to input equations      PS/2 keyboard worked. With 6 output pins in the device,
with a range for xmin, xmax, ymin, and ymax. However,           only four of them were used: Vcc, ground, clock, and data.
due to the complicated LCD scheme explained later, the          The PS/2 keyboard works by supplying power and ground
features of zoom and scaling were not able to be                to the keyboard (the recommended values are 5V at
implemented. The statistics portion was also written to add     300mA, but we supplied 7.5V at approximately 500mA).
unique features to the product. In terms of hardware to
software tradeoffs, the most challenging aspect was the             Once a key is pressed, the keyboard generates is own
LCD’s interaction with the hardware. There were definite        clock signal and a data signal that it passes through the
temptation to push the LCD to refresh at a faster pace;         respective lines. In order to decode which key was pressed,
however, it had limitations with fading effects. The display    the host must read the data line on the falling edge of the
could also support more colors than we had utilized, but it     clock. In all, 11 bits of data are collected per key stroke.
was not worth the overall tradeoff in terms of speed. In the    The scan code syntax is 1 start bit, 8 data bits, 1 parity bit,
scope of the project, no standards were followed other than     and 1 stop bit. The 8 data bits are passed in with least
the ANSI C because we coded in the C language.                  significant bit first, which means essentially that the scan
code is "backwards" from what a normal human was
Regarding patents, trademarks, and copyrights, there        expect. In addition, both lines float high when idle (so the
was no violation because all the code was either written by     start bit is always logic 0 to signal the start of a data
us or protected under the GNU General Public License [5].       stream). The keyboard clock is not an accurate crystal. The
published data shows that a keyboard clock cycles
III. HARDWARE DESIGN                          approximately 10-16 KHz. This translates to roughly 60-
The main pieces of hardware involved in our calculator      100us periods or an average of 80us. If a key stroke is
are an LCD display for showing the user inputs and              pressed from for a designated amount of time, the key
graphing the output, a keyboard of dynamic entry (text,         starts to send repeat patterns to the host (so the key will
numbers, and math symbols), and the STK-500 for the             start to replicated very quickly to the host machine).
Mega32 microcontroller. The LCD was an LCD ordered                  If the key is released, the keyboard sends a known
off Sparkfun.com [6]. The keyboard was a standard PS/2          "break" command to the host (0xF0) followed by the key
keyboard. When testing, we used both Dell [7] and IBM           that was just released. This creates at least 22 bits for the
[8] keyboards, but since both followed the more common          ending sequence of the keyboard. Because we are using
industry standard of scan code set 2 [9], there was never       our keyboard in a very limited function (all 26 alphabetical
any problem using the keyboards. The STK-500 was the            keys, both the top-row and keypad numbers, and
standard classroom board that we have been using all            miscellaneous buttons such as enter, asterisk, divide,
semester. Even though we did not use most of the                period, etc.) we did not deal with any of the "strange" scan
functions on the STK-500, we opted not to use our own           code keys (such as break/pause, which has a 64-bit scan
printed circuit board because it was extremely convenient       code).
to have some of the indicators on the board for
development. The LCD screen was a Nokia [10] mobile                 In addition, we were not too concerned with the fidelity
phone display (7210 model). In addition, we ordered two         of the scan codes, so we do not worry about the start,
other parts: a connector piece for the LCD and a carrier        parity, and stop bits. Also, since the user should not be
board. The connector piece was 1 Euro and allowed the           pressing more than one button down at a time, we also
LCD to be soldered to other components. The carrier board       ignored the break code and its corresponding bits at the
was 15 Euros and served the same function as the                end. This essentially leaves us with 8 bits of real data, of
connector piece, but all the ports were already pre-printed.    which our only task is to flip the bits (to put MSB on the
At first, we were afraid that the LCD was very delicate and     left end of the array and LSB on the right end) and then
we handled it very carefully when putting it into the carrier   compared to an array look-up table. The keyboard input
board. There was no distinct "snap" as the LCD fit into the     was read using a 10us interrupt on the Mega32. The
carrier board. Rather, we felt a "crunching" sensation as       interrupt would poll the keyboard input line (A2 for clock,
the pieces interlocked. We became worried that LCD              A3 for data) to check and see if the clock line was low. If
connectors were broken, but upon prying the piece away          the clock line was low, then it would accept the data value
from the carrier board, we found everything was intact and      on the data line into an array. We polled the line every
proceeded with the project. The next step was to try and        10us to over-sample the keyboard on purpose. Because of
load up the Mega32 driver code for the LCD [11].We              the variability in the keyboard clock, we would not count
realized early on that there was timing issues with the         on an 80us interrupt to achieve enough accuracy. Because
refresh rate because of the difference between the clock        the PS/2 keyboard is a male connector, we used a female-
to-female PS/2 gender changer adaptor [13] that changed           Another piece of software that was borrowed from
the PS/2 keyboard connector into a female connector; the      another person was the LCD font set. All of the
adaptor allowed us to easily connect wires to the PS/2        alphanumeric characters are in a 6x6 grid and the
keyboard and to integrate with the STK-500 board. The         characters were quite clear and legible. We chose not to
STK-500 board [14] has a number of built-in handy             alter their font set, but added our own characters because
devices that our calculator ended up not using. One           of the math symbols that we were using.There is also a
extremely useful component was the LED array, which we        comprehensive set of functions for the LCD. The original
used to detect which state our software state machine was     graphing calculator design was based on default functions,
in, in addition to debugging initializing problems. The       but in the final product, we rewrote our own functions for
STK-500 also had an interface with the computer               better functionality and efficiency. The functions that we
(Hypertrm) via an RS-232 [15] cable. We also used             had were better optimized for graphical use, not text
Hypertrm extensively in our initial development, but in the   display. Creating our own functions allowed us to create
final product, we opted to move everything onto the LCD       several optimizations, such as backspace. Backspace
display to decrease on the number of peripherals and          (deleting characters) was achieved by drawing a 6x6 white
dependencies that the graphing calculator would have.         square to block out any possible letter in that character
Lastly, another convenience that the STK-500 afforded us      space. The spacing on the LCD was done by "padding"
was readily available "ports" that we could plug our          the left (Lmargin) and top (Tmargin) by 5px. The text was
external devices such as the LCD and keyboard into. Aside     written to the screen and the characters were spaced by
from that, the decision not to use a smaller Mega32-only      2px between each character (Cshift). Each new line was
board was that the difference in price (1 Euro) was not a     also 2px between lines measured from the bottom of the
suitable tradeoff. Otherwise, the only real component we      first line to the top character of the second line (Vshift).
used on the STK-500 board was the Mega32 chip.
The text is a little bit small with a 6 pixel font, but it
allows our LCD to hold a lot of lines of data. Next, we
IV. SOFTWARE DESIGN                           moved on to the keyboard driver. Initially, the interrupt
The software for the graphing calculator was developed    sampling was set too long (roughly 80us) and there were
mostly from scratch. Aside from the LCD driver and the        times when the scan codes were being sampled
LCD font set, everything else was developed as the project    inconsistently. For instance, the letter "A" would have
progressed. The first thing that we attempted to tackle was   multiple scan codes showing up on the Hypertrm display
the LCD driver. After getting the default multi-color box     [16]. Finally, the interrupt speed was tuned down to 10us
to appear, we tried to change the colors and size of the      and we were able to get reliable scan code sampling. Once
box. With several tests, we immediately noticed that the      the sampling was figured out, we developed a scan code
coordinate (0,0) was located in the top left corner of the    table for all the keys we wished to map. If the user presses
screen. This coordinate system would cause us many            a key that is not within our requested scan code table,
problems because the math needed to scale and zoom            nothing would happen and the bits were discarded. We
became extremely tedious to code, which we realized after     mapped the special keys Enter to E, Backspace to B, and
several failed attempts.                                      the break code to X. Everything else was definable by its
respective ASCII character. After the scan codes were
developed, another problem we ran into while testing was
the break code and the subsequent scan code that followed
it. This was producing an "echo" effect when the user
pressed a key. For example, when the user pressed "A",
the letter "A" would show up, but when the user let go of
the key, another "A" would appear again because of the
break code.(The scan code sequence was 0x1C 0xF0
0x1C representing "A" (break) "A".) To remedy this, a
special flag (kybd_flush_bits) flag was created. Whenever
a break code was detected, the kybd_flush_bits was set
high.
This signaled to the microcontroller to discard the next
11 bits that it received (the repeat of the scan code of the
key that was just released). This solves the break code
problem for most keys except special keys with more than
11-bits of scan code (such as break/pause), but since we
are not using any of the special keys, the slight patch up
job was good enough to cover up the break bits. In order
to capture all of the keystrokes being entered by the user,
an array (keyboard_in) was created to hold all the
characters being individually entered (key_pressed).
Figure 2. A string output on the LCD display
Every time a character was entered, the array index            took in the equation to be graphed in similar format that
(kybd_in_index) would advance by one so as to not              the scientific calculator accepted equation inputs.
Next, it asked for the x and y scaling indexes and
finally, it went into a state titled "GraphReady". In this
state, the state machine parsed the input y= equation and
replaced "x" with an array filled with x values to be
computed.
Once the simple string replacements were made, the
equation was dropped into doCalculation() which
evaluated it as a regular scientific equation. The answer
was placed into an array of points to be plotted. The array
was 1-dimensional because the actually array index was
the x-axis value and the array value was the y-axis value.
In this way, we saved ourselves one array and cut down
a little on memory usage. Certain limits were imposed on
the graphing. For example, if the ymax and ymin values
were backwards (if ymax was smaller than ymin), then the
state machine would automatically switch the two values.
The same applied for xmin and xmax. In addition, if the
Figure 3. The graph function of the calculator         calculated value for a given x point was greater or smaller
than the allowed y tolerance, the value was automatically
set to the border value (ymax or ymin). Additional support
overwrite the already entered characters. Backspace        functions include fixInt() and fixChar(). These functions
took advantage of this index to erase previous letters         were to help force typecasting between (int) and (unsigned
entered.If the user hit enter on the keyboard input, the       char). There were frequently compatibility problems
calculator would try to process whatever was just passed       switching between the input string (unsigned char) and the
to it. If it was any of the crucial keywords, it would go      output variable (int). The two functions used for loops and
into a special state machine to take care of the functions.    just flat-out compared the characters and numbers and
For example, the keyword "graph" would cause the               outputted the corresponding typecast of the same value.
graphing state machine to trigger. If the keyword was          Two additional notes should be made about the calculator.
"clear", the entire screen would be wiped white,               The first is order of operations. Because there is no real
essentially erasing all the data on the screen. The "cursor"   parsing built into the calculator, only simple parsing could
would be placed back at the top of the row (5px from the       be performed. In other words, the equations in our
top and 5px from the left). If the user entered a regular      calculator are evaluated in a linear, straight-forward basis.
equation, the software would pass the equation to a            The equation 1+1*3 will evaluate to 6 instead of 4 because
function called doCalculation(). doCalculation() parsed        1+1 is evalued to 2 first, and then 2*3 evaluates to 6.
the input string into numbers (int) and mathematical           There were several options to get around this, many of
symbols (func). It would evaluate the function and return      which we attempted but eventually gave up on. The first
an answer (int). A sub-function doMath() acted as support      option was to create a C-syntax parser that would detect
for     the    doCalculation()     function.    While    the   for the operand and attempt the mathematical caluclation
doCalculation() function parsed the string, doMath()           that way. This proved to be too challenging of a recursive
would perform the actual math crunching. More in-depth,        function to write reliably. A second option was to change
the doCalculation() function took in a 20-element string       the calculator into a reverse polish notation calculator [17].
array. It parsed the first number into a temporary int         A reverse polish notation calculator has unambiguous
variable and put the operator into an unsigned char            syntax (1+1*3 would be inputted as 13*1+) and would
variable titled func. It would then "walk" through the rest    automatically take care of order of operations for us.
of the equation putting numbers that it parsed into a          However, it was too difficult to write a reverse polish
second temporary variable (int). When the second               notation parser for more complex functions because we did
temporary variable was filled, it would doMath() temp1         not fully understand reverse polish notation ourselves. (For
and temp2 with the gathered function. The answer from          example, we were not sure how to represent 2*5+3*6 in
doMath() would go into temp1 and the parser would try to       reverse polish notation). Lastly, another option we tried
find another math symbol and number to put into func and       was to create a reverse polish notation parser that
temp2. If it would not find another math symbol,               automatically converted a regular string (1+1*3) into a
doCalculation() would break and return the final answer        reverse polish notation string (13*1+) and then evaluated it
from the string calculation. To implement graphing, the        that way. The problem with such a parser was that it was
user would first have to enter the key word "graph". We        essentially performing the same function as a regular C-
created a state machine that collected a number of             syntax parser in regards to order of operation and the effort
variables before the graphing would be conducted. First, it    put into writing such a parser/converter would essentially
be the same as writing a regular C math parser and
skipping the reverse polish notation step altogether. The            The keyboard is clocked in on 10us intervals, so the
final conclusion for order of operations was a sort of "last     total time to gather 11bits of data is about 100us. The
entry" memory function. If the user typed 1*3 and returned       keyboard will not accept another input until the main()
3, the user could then immediately type "+1" to achieve 4,       function outputs the gathered key first, which then comes
the correct answer. In this way, we did not ask the user to      with a break code and a discarded scan code, for a total of 3
understand or convert to polish notation. Rather, we are         11-bit sets that needs to be collected before another key in
merely asking the user to think wisely about the order of        inputted. The collection time alone is 330us (11 bits * 3
operations because using the calculator to evaluate              sets * 10us/bit), but the time to output it to the screen is
numbers. It is not too unreasonable a conversion for a           undefined because it is software dependent on the while(1)
human to make, as opposed to converting into reverse             loop. However, despite all of the scan codes that are hidden
polish notation.                                                 from the user (25 bits out of 33 bits are never used; only 8
bits of scan code are used per key), there does not seem to
The second special note on our calculator was the            be any lag or "skipping" of keyboard input, no matter how
statistical analysis function using vectors. If the user typed   fast the user types. If the codes get any longer or slower,
in the keyword "stats", it would call up the statistical         there might be timing issues with how fast the user can type
function. It would first prompt the user to enter up to a 5-     on the keyboard, but at its current size, there are no
element vector of numbers, and then it would be able to          noticeable problems. Because the keyboard is sampling at
perform a number of functions depending on what the user         about 8 times the actual keyboard output speed, there is
asked for. The stats function of our calculator is able to       never any problem with sampling accuracy for the
figure out the min, max, mean, median, and mode of a set         keyboard input. There are, however, accuracy issues with
of numbers. Even if the user entered less than 5 numbers         the mathematical and graphing calculations. Because the
into the array, the calculator would automatically adjust its    Mega32 does not support float (whenever we attempted to
index boundary and figure out the correct answer. One last       output float, it would mutilate the number), there was no
function wraps up all of the special functional keywords         good way to implement finer values. A division value was
for our calculator. The keyword "clear" erased the entire        reported as its quotient and its remainder. We couldn’t
screen and returned the cursor to the top of the page.           convert a divide number into its decimal form. In the
graphing scenario, all of the x-axis values were rounded to
V. RESULTS                                the nearest whole number, which caused some slight
The speed of execution of the design was very straight-      resolution problems. Overall, there are no unique safety
forward. Despite being a calculator, the majority of the         issues with our product. The graphing calculator takes
calculations that the microcontroller had to perform were        advantage of a full-sized keyboard, which has been shown
not mathematical. Rather, the majority of the processing         to cause Carpal Tunnel Syndrome from extended repetitive
power went into parsing strings, gathering keyboard              use, but we do not foresee any serious long-term, extended,
inputs, and outputting to the LCD pixel by pixel. The            constant use for a graphing calculator. In addition, all
relatively concurrency of the system seems instant because       power supplies were 3-7V and low current. None of the
of how compact the code is.                                      exposed leads posed any serious threat to the user, even if
the user were to complete a circuit and get "electrocuted".
(Three volts is not dangerous enough to cause problems.)
Our project is completely self-contained and issues no
signals or commands that could interfere with other
projects.
There is no sound involved in our project and thus will
not cause a nuisance to anyone around us. Lastly, we tried
to design the calculator to be similar for usability to the TI-
calculator series. However, we made some modifications
due to some restrictions, mostly from the small size of the
LCD [18] because of the budget. In order to compensate for
this, we ensured that the contrast was set at a high level and
that the font size was increased for easy reading on the
eyes. We were not able to find a proper enclosure for the
product though, which would be an obvious necessity when
marketing the calculator as user friendly.

VI. CONCLUSIONS
In retrospect after completing the project, the results
did not quite meet all of the expectations that we set forth.
Figure 4 Basic calculations with the calculator               After implementing the LCD and keyboard, we did not
anticipate the complications that arose when programming
both portions of the calculator. On the scientific side, the
order of operations proved to be a problem because we                                         REFERENCES
were not able to parse the string properly to verify which
computations would need to be done first. Conversely, for
the graphing side, the math involved to scale and zoom in        [1]    Atmel http://www.atmel.com/
and out was difficult to output to the LCD based on its          [2]    Texas instruments http://www.ti.com/
conventions. In hindsight, the program could have been           [3]    PS/2         Keyboard          information      http://www.computer-
implemented differently with a separate parser and more                 engineering.org/ps2keyboard/
graphically.                                                     [5]    General Public license www.gnu.org
[6]     Spark          Fun           Nokia         128x128          Knockoff
Overall, the functionality was aesthetically pleasing but           http://www.sparkfun.com/commerce/product_info.php?
took longer and cut into the number of total features that              products_id=569
could be added. In consideration of intellectual property,       [7]    Dell www.dell.com
we have to mention that the code that was written by             [8]    IBM www.ibm.com
several people is all released with the protection of the        [9]    PS/2 Keyboard Scan Code Set 2 http://www.computer-
GNU General Public License. There are most likely no                    engineering.org/ps2keyboard/scancodes2.html
patent opportunities for this project because its similarity     [10]   Nokia www.nokia.com
to the TI models. After reviewing the IEEE [19] Code of          [11]   Mega32 driver for Nokia Color LCD http://www.e-
Ethics, it was clear that no violations were made in the                dsp.com/controlling-a-color-graphic-lcd-epson-s1d15g10-
making of this project. As responsible students of                      controller-with-an-atmel-avr-atmega32l/
electronics engineering department of ASPETE [20], we            [12]    Epson LCD driver www.handtronix.com
provided a product that is completely safe with low              [13]   PS/2        Female         to       Female       Gender       Changer
voltages and currents that have no possibility of hurting               http://www.trianglecables.com/200844.html
the user. The only possibilities for conflicts of interest       [14]   Cornell ECE 476 (Mega32 datasheet, STK-500 information)
http://instruct1.cit.cornell.edu/courses/ee476/
[15]   RS232 http://en.wikipedia.org/wiki/RS232
use or under the GNU General Public License. There were
no temptations or need for reporting unrealistic estimates       [16]   Serial            communication              with          Hyperterm
http://www.dnatechindia.com/index.php/Tutorials/8051-
or accepting bribery; at no point did we manipulate our                 Tutorial/HYPERTERMINAL.html
costs or falsely advertise the abilities of the calculator. As   [17]   Reverse                           polish                      notation
our primary goal, we seriously attempted to create a                    http://en.wikipedia.org/wiki/Reverse_polish_notation
product that was useful for an appropriate high school           [18]    Example            construction         with          the       LCD
student that is interested in mathematics and engineering to            http://instruct1.cit.cornell.edu/courses/ee476/FinalProjects/s2007/c
further their pursuit of higher education. Throughout the               mm98_jl478/cmm98_jl478/index.html
process of the project, we also constantly requested the         [19]    IEEE code of ethics http://www.ieee.org/portal/site
help and constructive criticism of our peers to see what         [20]    ASPETE www.aspete.gr
features would be most beneficial for our audience. In
recognition of their criticism, we set out to make changes
to improve our product such as the addition of the
keyboard. We also provided advice to other groups to
support them in maintaining the code of ethics. Lastly, the
calculator was created to be completely fair to our
audience of users with careful consideration taken for their
safety.
Cost details.

```
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
 views: 6 posted: 8/29/2011 language: pages: 6