EE 331 DESIGN PROJECT - BASIC CALCULATOR
Submitted by: Alex MacKay & Alex Meng
Department of Electrical Engineering, University of Saskatchewan
December 1, 2009
Design Description
The design project chosen is a basic calculator capable of performing addition,
subtraction and multiplication operations with robust handling. The calculator takes
input from a user in real-time via a keypad and displays output on a 4-digit, 7segment LED display module. The control and arithmetic algorithm is performed
using a Microchip PIC16F887 microcontroller. A high level block diagram of the
hardware implementation is shown below.
Fig. 1: Block Diagram of the Calculator Hardware
We chose a 4×4 keypad made by Grayhill Inc. for our input source[1]. Using a
keypad, we were able to achieve real-time data input using much fewer MCU input
pins than that required using individual switching methods for each 'key'. As indicated
in Fig. 1, the 16 keys represent: the ten decimal digits from 0 to 9, three arithmetic
operators, evaluation ('='), clear data ('C'), and a project message key ('M').
The PIC16F887 was chosen as the MCU for our project for a number of reasons.
Most prominently, it meets the design constraint which requires that we use a midrange PIC16F MCU. It also has many I/O pins which makes it suitable for our project
as we need quite a few pins to interface with a seven segment display and keypad.
The MCU chosen also has a wide operating voltage range (2V - 5.5V) which allowed
flexibility for powering the circuit in testing and implementation. Lastly, the MCU
has an ALU so that we can implement basic binary addition and subtraction (which
are of course required to implement any larger addition, subtraction or multiplication
2
operations) and a sufficient amount of registers for setting up and storing values.
We used a 4-digit 7-segment LED module made by Lite-On Inc. to display our
input values as well as results [2]. We chose a 4-digit display as it seemed enough to
showcase basic mathematical operators extending to numbers beyond 255 (8-bit
which our MCU is capable of).
Basic High-level Hardware Operation:
Through the input bus, the information from the keypad is sent to the
microcontroller where it is decoded. Once the information has been processed, the
microcontroller will send the relevant data through output data bus to the display.
Conceptual Design - Hardware
1. Keypad
The keypad is implemented by a scanning matrix in which each pin of each row of
the keypad is connected to an output pin on the MCU which is changing
(dynamic) very quickly. Each column pin of the keypad is connected to an input
pin on the MCU which uses pull-up resistors to keep the value as HIGH until
changed by a keypad input. Since the input pins (MCU) require pull-up resistors
to avoid floating values, we chose PORTB [3:0] to implement these connections
since it has internal pull-up resistors. We chose PORTA[3:0] as our output pins
(MCU) to go to the rows on the keypad. Although the choice of scanning pins
(PORTA pins) is not necessarily significant, we did purposely choose pins that
were all in the same nibble so that we could easily implement a rotate function on
the register to create 'scanning' (ie: 11111110 or 11101110 rotating)
2. Common Anode 7-segment LED Display Module
We chose PORTD[6:0] as output pins to control which segments of each digit
were on at any given time; these are connected to the common anodes of the
LED's. We connected PORTC[7:4] to each 'digit control cathodes' and configured
them as output. Using these digit control cathodes, we were able to display multidigit values by having only one digit on at a time and switching them very
quickly.
3. MCU and Power Supply
The microcontroller was programmed by a Microchip PICkit 3 programmer using
the standard programming pin connections provided by Microchip [3]. Since the
calculator is simply a prototype, we decided to just use the programmer as a
power supply since adding an external battery supply to a prototype bread-board
seemed unnecessary. The detailed schematic of the designed calculator is shown
on the following page in Fig. 2.
3
Fig. 2: Designed/Implemented Calculator Schematic
Major Challenges
Before delving into explanations of some of the main software implementations and
some challenges faced, it is important to point out a couple of major barriers faced
during the project (due to the project itself).
Since we decided to implement all of our operations using BCD rather than
binary (explained further on the following page), we were unable to utilize all the
features of the binary operations and had to write all exception handling (ex. setting
flags) for decimal operations ourselves. By doing this, we ended up writing all of our
operations in original code (no external references with the exception of the keypad).
As well, due to the nature of our project (arithmetic logic which depends on
user input), we had to consider a lot of different error cases which needed to be dealt
with individually that would not impede on the ability to do calculations. For these
reasons, our project could not be implemented as a simple procedural device such as
something which does a predicted event upon input (example: control output pins to
external devices with delays - LED's etc.) but rather has to consider many different
variables as well as [the basic level of] interfacing arithmetic logic internally with
real-time user input and display externally.
4
Conceptual Design - Software
1. Keypad Scanning
Using a similar approach to the 4×3 keypad scanning process shown in our course
textbook, we were able to obtain correct key identification from our input [4].
However, when the scanning algorithm was actually implemented, we
encountered two major problems. The first occurred when a key was accidently
lightly touched (for example as one key is pressed, one's finger grazes an adjacent
key); the MCU may unintentionally read the value. The reason this occurs is
because we did not originally have a method of debouncing. In order to fix this
problem, we added a debounce routine, which makes it so that values can only be
read if the key is pressed for a certain amount of time. The second problem is
caused by the scanning speed. The program can scan the keypad many times
while the button is pressed which sometimes causes the key-press (by user) to be
read multiple times. To solve this problem we added a 0.5 second delay after each
scan cycle to slow down the scanning speed.
2. Data Storage
We found that our PIC16F887 had far more memory than required for the design.
With this in mind, we decided to take advantage of some of this memory and store
our individual BCD digits into registers as we needed them (with one digit per
register in the lower nibble and bits 7-4 cleared). From this we decided that we
would implement our arithmetic operations using BCD operations rather than
binary. By doing this, we were able to think about all calculations and storage as
single decimal digit operations. In hind-sight, it seems that it may have been
easier to use a combination of BCD and binary operations since the multiplication
operation becomes particularly complicated when using only BCD values.
Our main calculation storage registers are for two numbers N1_X and N2_Y
which are the operands, and a result register, RESULT_Z where values are stored
after operations. The variables X, Y and Z indicate which digit is being looked at
(3 = MSB/thousands', 2 = hundreds', 1 = tens', 0 = LSB/ones'). In order to
implement all the arithmetic operations in a robust manner, we also used a fair
number of temporary storage locations as well as flag and indicator registers.
One design challenge faced in this project was the implementation of a
multiplication algorithm in which we called both the addition and subtraction
subroutines. After any arithmetic operation is called, it stores the final results in
our RESULT_Z registers. We were therefore forced to use several temporary
storage registers when implementing the multiplication algorithm so that we
would not have overwrites of our original number inputs or our results when we
used the addition and subtraction algorithms embedded in the multiplication
subroutine.
Another design challenge occurred when we had to implement digit shifting
upon multi-digit input. For example, if a user wishes to enter the number '7682', it
is expected that the digits would be entered in sequence from MSB to LSB. To do
5
this we had to develop an algorithm which puts the first number inputted into the
LSB and will shift digits towards the MSB as more digits are entered. The
algorithm also stores the number of digits currently inputted.
One important challenge met which has yet to be discussed was overflowing
the stack which is only eight levels deep. After the design was near completion,
we encountered several stack overflow situations which meant we had to reduce
the number of embedded subroutine calls so that we would not overflow the stack.
3. Dynamic Display
1) Project Message Display
When the calculator is turned on for the first time or if the project message
button (M) is pressed, the following strings will be shown on the display to
advertise the course and the creators of the designed project: "EE 331 ALEX."
2) Error Message Display
If a numerical calculation/entered value leads to digit overflow (i.e. a value
greater than '9999') or a negative value is encountered (i.e. subtraction of a
larger number from a smaller number) an error message string: "Err," appears
on the display for about two seconds before resetting the calculator.
3) Numeric Display
The values which are desired to have displayed are converted into required
HEX numbers corresponding to each digit via a 7-segment LUT. These values
are stored in single-digit BCD registers labeled SEV_SEG_NUM_X (following
same conventions as other BCD registers with X). As mentioned previously,
we are able to display multi-digit values by only displaying a single character
at any instant in time (on one digit) and then turning it off and turning on
another digit. We displayed each value for about 2ms so that the minimum
frequency of display was around 125Hz which is far beyond the human eyes
capability to track (making the displayed string appear smooth).
4. Exception Handling
1) Digit Overflow
As mentioned previously, there are two types of overflow which both occur
when the number required for display exceeds 4 digits. One of which happens
if the user tries to enter a number more than 4 digits long and the other occurs
if the calculated value is more than 4 digits long. In both cases, the calculator
detects the problem and displays the error message: "Err" and resets all values.
2) Multi-Operation Calculation
The calculator has been designed for basic mathematical operation such that it
can compute multi-operation calculations as long as an overflow or negative
numbers do not occur (in which case error message is displayed as per usual).
It should be mentioned that this calculator has basic order of operations rather
than scientific order of operations, meaning that if the user enters "1+5*2", it
will compute "1+5"; store this value in N1, then compute "6*2" and display a
result of 12.
6
3) Negative values
As mentioned previously, the calculator is not designed to handle negative
numbers and will produce and error message if the result is negative. The
reason we did not design this calculator to handle negative numbers is because
we thought it would be unnecessary for such small values since we only have
four digits, although it should be relatively easy to implement for future work.
5. Clear Button
If the clear button (C) is pushed, the calculator will be reset to default. All register
values are cleared and it will display zero as if it were in the initial status.
6. Arithmetic Operations
As mentioned earlier, all arithmetic operations were implemented using BCD
arithmetic rather than binary operations. The logic of each task is therefore quite
intuitive since most people are able to think of doing this basic math with decimal
numbers.
Although using BCD operations may make the logic more intuitive, it does
however, make the implementation much more complicated than simply using
binary operations. When using BCD operations, it was required that all event
handling (i.e. digit carry/borrows/overflows) were implemented without the help
of binary operations, since these would only occur on carry/borrow/overflows of
values of ten (not two, and not at 255). Therefore a number of helper subroutines
were required to handle all exceptions. All operations required extensive error
checking since there are many different ways in which overflows can occur. It
should be mentioned that tracking all possible errors (mainly by overflow) was
the most difficult and time consuming part of the operations to implement. Since
they are so vast and unique, they will not be discussed in detail but can be viewed
in the code or understood at a [very] basic logic level (code will give a better
appreciation) from the flow charts in Appendix A (starting at page 13). Besides
error handling, there were other major difficulties encountered when
implementing the arithmetic operations as discussed below.
In the subtraction subroutine, we needed to implement event handling that
could not only do single borrows, but cascade borrows if the digit above
(attempting to be borrowed from) was zero. This was implemented by checking
for zeroes in a simple binary subtraction initially, but then we needed to perform
a 10's compliment routine and a series of flag checks to monitor and ensure
proper functionality of cascading borrows. To understand how this works, refer to
"Subtraction correction subroutines" in the full source code.
In the multiplication subroutine we faced several major challenges. We needed
to implement an operator to do multiplication of two single digits and store the
result. This was done by storing one of the operands in a decrementing counter
while adding the other number to itself the amount of times that was equal to the
counter operand (also this had to call addition since it could obviously become a
two digit number; a flag was set so that we wouldn't waste time doing a full
7
add;). Once this was complete, we had to adjust values based on previous carry's
(from previous multiplication/additions). A basic flow chart of how the remaining
components of multiplication (and all other operations) were carried out can be
found in Appendix A. As mentioned before, the error handling should be viewed
in the code since this was the most intensive task but the cases are too different to
warrant listing them in these paragraphs.
Conclusion/Recommendations
When designing our calculator, we did not consider a few things which may
be considered for later work. We realized it to be extremely unlikely for any realistic
design of a commercial calculator to use a PIC16FXXX MCU (especially in
assembly) or a 7-segment LED display similar to the module we chose and therefore
looked at the project as a method of practice more than implementing a "product" so
to speak. With this in mind, we focused our efforts on successful algorithm
implementation and robustness so that it could properly handle all the cases we
thought of. For this reason, we did not put a lot of effort into power reduction (since
the 7-segment display alone draws an unnecessary amount of current) and so if
someone were to continue on the project, that may be an area which should be
considered. Particularly using an interrupt routine waiting for input so the device does
not scan in an infinite loop waiting for input (could be in power saving mode) would
help the overall power efficiency. Another area which we did consider but could have
more work put into is calculation and memory efficiency. The device was fairly
efficient considering we used BCD operations, but could become more efficient (and
use less temporary space) if the operations were implemented as more basic binary
operations using the binary operation instructions which are given.
Our design was also lacking in a number of areas which are more easily
implementable that should be considered for possible future work. Before anything
else is done, it is recommended that the code would be broken down into separate
assembly files in relevant blocks which could be linked together so that the code does
not seem convoluted. As a basic calculator, it is recommended that a division
operation be implemented. This should be a relatively simple operation to do since it
could use the subtraction subroutine already available; the only large problem faced
would occur with truncation since our display only has 4-digits and may not provide
adequate accuracy; for this reason, decimal values less than one should also be
implemented (that is X.X). This leads to the next recommendation, which is to replace
the LED-display with an LCD module so that more digits could be displayed and
require less I/O ports (per displayable digit) on the MCU. Also, as mentioned
previously, we should be able to implement negative number handling quite easily
which should be done if there is a sufficient number of space for display (as on an
LCD). Lastly it may be desirable to change the functionality of the calculator from
"basic" to "scientific" so that it follows the common precedence order of operations
sequence.
8
Task Breakdown
Throughout the design process, both partners performed different tasks on the project
in separated blocks so that the overall load on each group member would be lessened.
Due to many design challenges faced well as hours debugging code and finding new
exceptions, each group member worked on the project for around 48 hours.
The basic tasks (simplified to exclude debugging which was the majority of
time spent) performed by each member are outlined below:
Alex Meng
 Assembly implementation of hardware control (keypad, display module)
 Interfacing arithmetic operations with hardware (bringing code together)
 Draft of design report
Alex MacKay
 Algorithm and assembly implementation of BCD arithmetic operations
 Schematic design
 Draft report editing and final design report
9
REFERENCES
[1]
Data sheet for Grayhill 4×4 keypad:
http://lgrws01.grayhill.com/web/images/ProductImages/Series%2096%20Stan
dard%20Keypads.pdf
[2]
Data sheet for Lite-on 4-digit, 7-segment display module:
http://optodatabook.liteon.com/DataBookFiles/11678/C4627JS.pdf
[3]
Data sheet for Microchip PIC16F887:
http://ww1.microchip.com/downloads/en/DeviceDoc/41291F.pdf
[4]
Katzen, S. (2005). The Quintessential PIC Microcontroller (2nd ed.).
New York: Springer.
10
Appendix A - Program Flow Charts Cont'd
A.1: Main Logic
11
Appendix A - Program Flow Charts Cont'd
A.2 - Operator Storage Logic
12
Appendix A - Program Flow Charts Cont'd
A.3 - Data storage Logic
13
Appendix A - Program Flow Charts
A.4: Addition logic (High Level)
14
Appendix A - Program Flow Charts Cont'd
A.5: Subtraction logic (High Level)
15
Appendix A - Program Flow Charts Cont'd
*NOTE: A single multiplication (two single digits) is performed by adding one digit to itself the
amount of times of the value of the other digit being multiplied.
A.6:Multiplication logic (High Level)
16
Appendix A - Program Flow Charts Cont'd
A.7 - Calculation Logic