RPN Scientific Calculator: Keypad

The next step of the hardware for my calculator is a keypad. I finished this several weeks ago but I haven't posted anything about it because I didn't have any pictures until now.

As you can see, the construction is pretty simple. My local shop had a new kind of perfboard that I wanted to try. It seems to be a little stronger than the kind I used before but still not really stiff like some of the high quality ones I have seen. It took some time to solder this together but it worked well in the end. Only one button connection had to be resoldered.

The circuit is a standard button matrix. A signal is sent through each of the green lines in turn and if any of the buttons are held down the signal will travel out of one of the yellow output lines and be recorded. Each button has a diode to ensure that the signal can only go one way. As you can see from the back side of the board, the columns are connected by solder and the rows by yellow jumpers. After I had soldered most of the columns, I realized that the two legs on each side of this kind of button are connected internally and don't have to be soldered together. The next time I make a button matrix I will leave them unsoldered so I will have room to make the rows out of solder as well. Avoiding jumper wires like I used here will make soldering simpler.

To read the matrix I am using a 74HC165 and a 74HC595 shift register. Output shift registers can easily be chained together but I also found out that an output and input shift register can be chained together as well sharing the same data, clock, and latch lines. Here I decided to use separate latches since the 165 is reading the output of the 595 but they do share data and clock lines which uses less microcontroller pins

Most of the time the shift registers will go unused since scanning the matrix only takes a fraction of a second. To save even more pins I decided to drive the LCD using the 595 shift register as well. This works out as long as communicating with the LCD and reading buttons never overlaps. I will have to take this into consideration if I decide to use an interrupt to read buttons. This also fixed a strange and unsolved issue that would occasionally cause the LCD not to receive commands when it was being driven directly by microcontroller pins.

RPN Scientific Calculator: Multiplication

The next step of the software for my calculator is multiplication. In Binary Coded Decimal (BCD) this is fairly straightforward. Every decimal place of the first number has to be multiplied by every decimal place of the second number. The tricky part is keeping the results lined up and then putting the decimal point in the right place at the end. Here is an example running on the MSP430:

One advantage of BCD is that it avoids the rounding errors that occur in floating point calculations. This quickly becomes apparent when you start multiplying decimal numbers. Even in this example using fairly small numbers there is a rounding error:

Floating Point:
835.2533 x 907.042 = 757609.823739

Binary Coded Decimal
835.2533 x 907.042 = 757609.8237386

For most uses floating point offers enough precision but a scientific calculator should be as accurate as possible, so BCD is a better choice.

While working on this I was able to find a bug in my code for addition and fix it. I also added a function to shift numbers one decimal place so they will be aligned properly for multiplication. This routine is sometimes necessary since each byte holds two decimal numbers. Routines like this take up space in Flash, which is limited to 16K on value-line MSP430s. One way to avoid having to shift numbers is to let each byte represent one number instead of two. Although this would use twice as much RAM, it would simplify programming and use less space in Flash. This is what I will do if I run out of room for the firmware. Right now I plan to use 128K parallel SRAM chips from Alliance, so running out of RAM wouldn't be a problem. (Of course 8k of SRAM would have been enough but I don't have any of those with me.) Another option would be to write all or part of the BCD routines in assembly. This would help a lot since the MSP430 has an op-code to add BCD numbers. It also handles carries natively which is more efficient than storing it in a variable and checking it explicitly like my code does now. Currently, the program is only 3.3K including the part that handles the LCD. How much I can fit in the remaining Flash will determine what changes I make.

New Project: RPN Scientific Calculator

My interest in electronics started because I would like to build calculators like the ones I used to collect. Now I plan to build a scientific RPN calculator. A three inch graphical LCD would work well for this but most cell phone screens I can easily find are a little bit too small. For the time being I will continue using the 16x2 LCD I found.

For this project I intend to use an MSP430. The challenge of this will be that the MSP430G2553s I have only have 512 bytes of RAM. To begin with I decided to start on the programming since this will probably be much more work than the hardware. Although I want this calculator to use RPN, it would also be good if it could evaluate algebraically as well like the HP-49G. It will hopefully also be useful to have a small parser that works on a microcontroller for some other projects I want to do. Here is the parser running on my LaunchPad and evaluating the equation 13*(4+25*13)/((67-33)*2^3):

 

 

At first I wanted to use recursion because this can really simplify parsing but that's not really an option since it would use a lot of stack space. Instead, it evaluates any expressions it can and stores the result in memory then writes a pointer to that memory in the place where the expression was. Doing it like this instead of tokenizing the whole string before evaluating saves memory. The results of operations are stored starting at the end of the string that holds the expression so that as the expression is evaluated and becomes smaller, memory is freed which can be used to store more results. So far this parser fits in about 2k of Flash.

The second part I worked on is a Binary Coded Decimal format. This will be more accurate than floating point since it will be able to store any number that will fit in available memory. Each byte of data contains two numbers from 0 to 9. Now numbers are limited to 512 digits in length but this can easily be increased, although it probably wouldn't be useful on such a small screen. I have code for adding and subtracting, so multiplication and division should be easy to implement using these. I was able to fit this into less than 2k of  Flash so with the parser I should still have about 12k of flash for other functions. Here is an example using numbers small enough to fit on the screen:

16x2 LCD and MSP430

Recently, I found a local electronics shop that carries 16x2 LCDs that are HD44780 compatible. This type of LCD is really common and it wasn't too hard to get it working with an MSP430.

The hard part was that the LCD expects 5 volts, although the LaunchPad supplies only 3.6 volts. I did some reading and it turns out that the logic part of the LCD can run on as little as 2.7 volts. The contrast, on the other hand, expects 5 volts. Even with the pin that controls contrast connected to ground, nothing can be seen on the LCD. One solution is to feed this pin some negative voltage.

Negative voltage can be generated with a charge pump made of only two capacitors and two diodes. In the picture above you can see them behind the LCD. They need a pulse to work which I generated with my MSP430. This worked well but I began to think that it might be a bad idea to charge capacitors through a microcontroller pin. My first try was to switch the voltage with a transistor. This didn't work because I could only source current. Then I found out about push-pull stages. This is a handy way to sink and source current with only two transistors.

My next plan was to create the pulses for the charge pump externally so the MSP430 wouldn't have to worry about doing it. The 555 timer I bought for the job turned out to be 5 volts also so that didn't help. I tried modifying a circuit I found to flash LEDs using capacitors and transistors but it wasn't very reliable. For now I will stick with doing it with the MSP430.

Reusing LEDs

Before I got a hold of the red LEDs I used in the 3x3 LED matrix, I was having a hard time finding a local source for LEDs of any kind. When the holidays rolled around I had a look at some of the Christmas tree lights that were for sale and for a few dollars I bought a string of 100 white lights that look like this:

As you can see from the picture, the head is concave. This type is easy to see from a distance but doesn't look very good on a breadboard. The string of lights this LED came from consists of four seperate strands. The first few LEDs on each strand have resistors soldered to their legs as you can see here. This makes them convenient to plug into a breadboard, even though concave LEDs don't look very good up close.

Later on I found a similar string with frosted convex LEDs. Each of the four strands of 25 LEDs was a different color. I bought several boxes and in the end I paid less than 3 cents per LED! The first few lights on each strand also have resistors soldered to the legs:



One thing I found very interesting about these LEDs is that they grow very brightly. The resistors soldered to the legs are Orange-Black-Red-Gold. This should mean that they are 3000 ohm resistors. In order to get 20mA out of these LEDs I would need around 60 volts. However, when hooked to the 3.6v of my LaunchPad they glow very brightly. By my calculations, if the forward voltage of the LEDs is around 2 volts, the LEDs should be using less than 1mA when the supply voltage is 3.6v. Clearly something isn't as it seems!

Hopefully, I can repurpose some of these LEDs to make a matrix. This should be convenient since they already have wires soldered to their leads. Since each string has four different colors, I don't have enough LEDs to make a large matrix of only one color. My plan now is to combine a red, a green, and a blue LED together to make one RGB pixel. Like other matrixes I saw on the internet, I tried ping pong balls as diffusers. Here is the result using four of the colored LEDs and one of the white ones:



They seem to diffuse very well but ping pong balls here are too expensive to be used for a whole matrix. Once I find a better way of diffusing light, I can move on to soldering the matrix.

3x3 LED Matrix

A friend of mine recently asked about making a small LED sign for his business that can scroll text. It seems that buying such signs is pretty expensive. To give him a little demonstration of how it would work I made a small 3x3 matrix of LEDs using a 74HC595 shift register. Using multiplexing it is possible to run a 4x4 matrix with only one shift register but I didn't have that many matching loose LEDs on hand. I was able to draw some simple patterns using an MSP430 and even do some PWM to dim the LEDs.

One thing that surprised me was that the cheap red LEDs I used burned out almost instantly when hooked up to the supply rail without a resistor. Running an LED without any kind of current limiting is of course a bad idea but it was a surprise that these failed so quickly. Others I have experimented with worked without any noticeable damage for a few seconds when hooked up to the few 100mA that the MSP430 LaunchPad can source.

Also, although these LEDs appear to be identical and were bought at the same time from the same store, one of them seems to glow at least twice as bright as the others. Some LEDs I have used seem to glow a little dimmer than others from the same batch but I've never seen one like this that glows so much brighter. I'm not sure what causes this.

MSP430 and C115 LCD

Recently I visited a local cell phone repair shop in search of LCDs with pads large enough to solder. What I came out with was a color display from a Motorolla E370 and a two-inch Motorolla C115 monochrome display. There don't seem to be any datasheets or code examples for the E370 on the internet but I was able to get the C115 running with an MSP430.

The first thing I did was solder wires to the ribbon cable. The pads were wide enough to attach normal breadboard wires to. Soldering them individually turned out to be pretty difficult so I first covered all of the pads in solder then placed the wires on the pads and melted the solder by putting the soldering iron on top of the wires.

To run the display I looked at some AVR code I found on a Russian site and tried to adapt it. The LCD uses the I2C protocol so I looked up how to use the UART module in the MSP430G2553 I was using. The AVR code sends the address of the LCD as a 7-bit address shifted left one bit. When I used this address with the MSP430 the LCD didn't respond and I started to suspect that it was broken. Then I decided to use some code I found from TI that checks to see if there are any devices connected at a particular address and used that to scan all the possible I2C addresses. The LCD responded at an address I wasn't expecting. It turns out that the address was wrong because the UART of the MSP430 expects an unshifted address, whereas the AVR code was sending an address that had already been shifted.

After I had the display running, I wrote a few lines of Visual Basic code to convert a bitmap into a C array. Here is a picture I made to test the display:

Then I worked on a font for the display. There are a lot of 5x7 fonts and not much room for creativity at such a small size but I went ahead and made my own character set anyway. My goal was to make the characters slim so that I could fit as many as possible on one line. As you can see in the picture, the font is variable width since any unused spaces aren't drawn. I also made sure that characters like g and j are drawn one pixel lower.

This LCD wasn't too hard to get running and hopefully I can use it in a future project.