Document Sample
paper-2 Powered By Docstoc
					                              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 [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
                                                                  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
                                                                   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
                                                                     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
and out was difficult to output to the LCD based on its          [2]    Texas instruments
conventions. In hindsight, the program could have been           [3]    PS/2         Keyboard          information
implemented differently with a separate parser and more       
features to compensate for the inability to change               [4]    Google
graphically.                                                     [5]    General Public license
                                                                 [6]     Spark          Fun           Nokia         128x128          Knockoff
    Overall, the functionality was aesthetically pleasing but 
took longer and cut into the number of total features that              products_id=569
could be added. In consideration of intellectual property,       [7]    Dell
we have to mention that the code that was written by             [8]    IBM
several people is all released with the protection of the        [9]    PS/2 Keyboard Scan Code Set 2
GNU General Public License. There are most likely no          
patent opportunities for this project because its similarity     [10]   Nokia
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      
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
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     
the user. The only possibilities for conflicts of interest       [14]   Cornell ECE 476 (Mega32 datasheet, STK-500 information)
were with reused code, which was verified to be for free
                                                                 [15]   RS232
use or under the GNU General Public License. There were
no temptations or need for reporting unrealistic estimates       [16]   Serial            communication              with          Hyperterm
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          
product that was useful for an appropriate high school           [18]    Example            construction         with          the       LCD
student that is interested in mathematics and engineering to  
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
help and constructive criticism of our peers to see what         [20]    ASPETE
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
   Cost details.

Shared By: