Sign in to follow this  
Followers 0
Druzyek

RPN Scientific Calculator

8 posts in this topic

Overview

This is a scientific calculator I built that uses RPN notation. Features:

  • BCD number format with 1-255 places
  • Internal accuracy configurable from 6 to 32 decimal places
  • Two separate 200 level stacks
  • Optional scientific notation
  • Functions: (a)sin, (a)cos, (a)tan, y^x, x root y, e^x, ln, 10^x, log, mod
  • 20x4 character LCD
  • 42 buttons

The source code is available on https://github.com/druzyek/RPN_Calculator.

 

post-30999-0-82270600-1391028148_thumb.jpg

 

Software

The interface shows 4 levels of the stack, similar to some HP calculators. While I was writing the code for BCD calculations, I used a console program to test the routines. You can download it from GitHub if you want to test out the functionality: rpnmain_pc.c It will compile for Windows if #WINDOWS is defined or for Linux with the ncurses library if #LINUX is defined.

On Windows:
gcc -o rpncalc.exe rpnmain_pc.c

On Linux:
gcc -lncurses -o rpncalc rpnmain_pc.c

Numbers are stored in unpacked BCD format on an external SRAM chip. I wanted to access this memory using variables but there is no convenient way to do this since every variable requires a function to access it. A simple functions like:

X+=Y*Z-Q;

would become something like this (assuming we are passing pointers):

RAM_Write(X,RAM_Read(X)+(RAM_Read(Y)*RAM_Read(Z)-RAM_Read(Q));

To simplify things, I wrote a preprocessor program that looks for any variables that need to be stored in external RAM and converts access to them to function calls. External variables are all stored as pointers, so the PC version will work exactly the same with or without the preprocessor. To mark variables as external, #pragma directives are used. These are usually ignored by the compiler if they are not recognized, so they are a convenient way to communicate with the preprocessor. Here is an example:

//Before processing
void puts(unsigned char *msg)
{
     #pragma MM_VAR msg
     for (int i=0;msg[i];i++) putchar(msg[i]);
}

int main()
{     
     #pragma MM_OFFSET 200
     #pragma MM_DECLARE
     unsigned char text1[30];
     unsigned char text2[30];
     #pragma MM_END

     text1[0]='A';
     text1[1]=0;
     puts(text1);
}
//After processing
void puts(unsigned char *msg)
{
     #pragma MM_VAR msg
     for (int i=0;RAM_Read(msg+i);i++) putchar(RAM_Read(msg+i));
}

int main()
{     
     #pragma MM_OFFSET 200
     #pragma MM_DECLARE
     unsigned char *text1=(unsigned char*)200;
     unsigned char *text2=(unsigned char*)230;
     #pragma MM_END

     RAM_Write(text1+0,'A');
     RAM_Write(text1+1,0);
     puts(text1);
}

The trig and log functions are computed using CORDIC routines. This is a very efficient way to compute these functions for processors that cannot multiply or divide quickly. Instead, a lookup table is used with adds and shifts, which are much faster. I was able to speed the shifting up even more by using another lookup table that let me right shift 4 digits at a time. One way to measure the accuracy of calculations is with the calculator forensic found here: http://www.rskey.org/~mwsebastian/miscprj/forensics.htm. After setting accuracy to 24 places arcsin(arccos(arctan(tan(cos(sin(9)))))) evaluates to this:

post-30999-0-78120500-1391033219_thumb.jpg

 

The settings page allows the accuracy to be set from 6 to 32 decimal places. With the default of 12, trig functions calculate in about a second. With 32 decimal places calculations take 3-4 seconds. After setting the accuracy, the program finds the largest element in the CORDIC table that is still significant, so that no time is wasted on elements that have no effect on the answer. The settings page also shows the current battery charge.

post-30999-0-97522100-1391033646_thumb.jpg

 

When I began this project I wasn't sure how much I could fit into 16kB of firmware space. In the end it grew bigger than this and I had to use two MSP430s to hold everything. Part of this is due to all of the functions used to access external memory. The interface code also added a lot more to the size than I expected but I was able to add checks for most of the functions and add some meaningful error messages.

post-30999-0-37274300-1391034130_thumb.jpg

 

Hardware

My design uses two MSP430G2553s connected over UART. One of them (the master) reads the keyboard matrix, updates the LCD, and manages the interface. The other is connected to the data lines of 128k of parallel SRAM and does all of the calculating. The address lines of the SRAM are driven by two 74HC595 shift registers controlled by the second MSP430. The 17th address pin is controlled by the first MSP430 and allows the program to switch between two separate stacks. Here is the schematic: 

post-30999-0-47017900-1391035073_thumb.png

 

The keypad is formed from 42 tactile buttons arranged in a 6x7 matrix and read with a 74HC165 shift register by the master MSP430. The LCD and keyboard share the same pins since they are never used at the same time. Here is the layout of the keys.

post-30999-0-26935700-1391037871_thumb.jpg

 

The LCD is an HD44780 compatible 20x4 character LCD. It is rated for 5v but the logic works fine at 3.6v. The contrast needs to be close to 5v for anything to show up on the screen, so I used a 555 timer and some diodes to supply around -1.2v to the contrast pin. The result is very solid and clear.

 

The calculator runs on four AA batteries regulated by an LM1117 configured to supply around 3.5 volts. To run at 16MHz the MSP430s need at least 3.3 volts. The wiggle room between the two voltages will let me see when the batteries are starting to wear down. By the time the voltage gets down to 3.3v, the batteries will be down to 1.15v or so, which can be considered dead.

 

The PCB is made from perfboard. The top of the board contains female headers so that the keyboard and LCD can be unplugged. Part of the board had to be cut away so that it will fit in the case with the batteries. Although it is quite small, I ended up using over three meters of wire.

post-30999-0-60372200-1391036341_thumb.jpg

 

The case is soldered out of copper clad. I used a lot of solder on it and it feels very sturdy. I will give it a coat of paint tomorrow before assembling everything.

post-30999-0-92816100-1391036639_thumb.jpg

yosh, tripwire, PTB and 8 others like this

Share this post


Link to post
Share on other sites

Impressive.

this might be a stupid question, but why did you opt for the AS6C1008 + 2x74HC595 instead of a RAM module that can be accessed via a serial interface? are you getting data quicker with the shift registers as opposed to let's say 23A1024's SPI?

Share this post


Link to post
Share on other sites

@@petertux, good question. I had several AS6C1008s handy with nothing planned for them so I decided to use them. A 23A1024 would have worked well too and probably wouldn't have been much slower.

bluehash likes this

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0