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, 7-

segment 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 mid-

range 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 multi-

digit 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