Tiny Calculator: New Hardware

After figuring out how to build calculator keypads with my new laser cutter, one of the first things I worked on was new hardware with a new keypad for my Tiny Calculator project. The original keypad was made by printing color labels on overhead transparency plastic then cutting those out and gluing them to 3D printed keys. Since the labels were printed in reverse and glued with the ink side down to protect the ink, the glue caused the ink to smudge in some cases. The laser-cut keys, on the other hand, are very crisp and look much better. The only disadvantage is that they come in just one color. Each key is glued down individually to a 3D printed grid, so it would be possible to make some of the keys a third or fourth color as long as there is no more than two colors per key. One thing I want to experiment with in the future is making keys out of two different pieces to get up to four colors on one key.

The original hardware was two circuit boards stacked together with headers that made everything pretty thick. The new version is just one circuit board with everything mounted on top. One way to squeeze everything in such a small space was using magnet wires which take up even less room than the wire-wrap wires on the original. Both sides of the LCD are encased in a 3D printed housing that is glued directly to the battery holder and microcontroller. This makes it impossible to make any changes to the circuit but is worth it to make the body thin. A small header above the LCD allows for programming.

New Project: 6507 Graphing Calculator

Despite the decision in 2019 to finish up some lingering projects before beginning anything new, I did start working on a new calculator project. One of the members on the 6502 forum organized a contest about a year ago for projects using the 6507 processor, so I decided to make an exception and build this calculator as an entry. Most of my free time in 2020 was spent working on my Robot Game project before making a lot of progress on this project. Rather than a series of progress update posts like my other calculator projects have, this is one long post about the project so far. Some of this information is already available in the 6502 forum post on the project. 

Contest

The contest started in January 2020. The goal is to build something using a 6507 processor, 6532 RIOT, which stands for RAM, IO, and Timer, and a 2KB 2716 EPROM. After some discussion, a larger ROM of up to 8KB was allowed since it would be difficult for most people to program a 2716. The limit seems to apply to the total memory, so I may have accidentally disqualified myself by adding 2KB SRAM to the 8KB ROM. The 6507 and 6532 run at 1MHz and are both NMOS parts, so they consume a lot of current compared to the newer CMOS 65C02. The pair was used together in products like the Atari 2600. The 6507 is a reduced version of the 6502 and has 28 pins instead of 40, so it can only address 8KB of memory rather than the usual 64KB. It's also missing the IRQ and NMI interrupt pins. These limitations make it interesting to work with. The 6532 has 128 bytes of RAM, two IO ports, and a programmable timer, which is a lot of useful stuff to have in one package.

Hardware

The first 2KB of address space is occupied by RAM. Because the 6507 can only address 8KB, the last 4KB of address space is banked for the ROM. The 6532 takes 256 bytes of space leaving 1.75KB in the middle of the memory map that is assigned to ROM. Having a fixed amount of ROM there that isn't banked simplifies handling the banks and initializing the system. Here is the memory map:

• 0x0000 - 0x07FF: 2KB RAM
• 0x0800 - 0x08FF: RIOT
• 0x0900 - 0x0FFF: 1.75KB fixed ROM
• 0x1000 - 0x1FFF: 4KB banked ROM

The address decoding is done with a an ATF16V8C GAL, which is similar to a CPLD, though less capable. The WinCUPL software for programming these is atrocious and crashes frequently, but setting up the design for the GAL itself was pretty simple. The chips can be programmed just fine with the TL866II+ programmer that I use for EEPROMs. According to the datasheet, the ATF16V8C can draw over 100mA, so I also got some lower power variants to try to see if they save power.

The display is a 128x64 monochrome LCD compatible with the KS0108. This is the first time I've used a display like this and it works pretty well so far. The header pins are on the bottom edge of the screen, so it has to be turned upside down to fit the system I'm building. This means the font data has to be written upside down and backwards, which complicates things a little. It wasn't easy to find a completely free 5x8 font, so I made one myself. Later, I experimented with different styles to see what looks best:

The system would not start reliably on a breadboard, and I eventually tracked the problem down to sagging voltage on the breadboard. The problem was actually the jumper wires used to carry the supply current not the breadboard itself. Soldering everything onto protoboard fixed the startup problems and everything worked reliably after that:

There is still a good amount of work to do even though the hardware is pretty far along. The keyboard needs to be soldered and connected to one of the latches. There are a few possibilities for making the labels for the buttons that still need to be worked out. Another big part still missing is the power supply. The first plan was to run the system on four AA batteries, though this would waste a lot of power using a linear regulator or even a buck regulator since a lot of power would be left in the batteries by the time the voltage drops too low to use with a regulator. Instead, three AAs with a boost regulator will allow me to fully use more of the batteries' charge and also use rechargeables, which wouldn't be possible with the buck regulator. My plan is to use a MAX756 boost regulator, though I still need to set it up and test it. One cool thing about the chip is that it has a low battery indicator, which is something I was planning on trying to implement myself. The power supply also needs a way to be switched on and off by software control, so the keypad can have an on/off key rather than a separate power switch. This is really important so the system has a chance to save it's state before powering itself down. The last piece of the power supply system is a way to put the processor to sleep when it isn't needed. This can be done with the RDY pin. Hopefully, the timer and interrupt system of the RIOT can be combined with the GAL and software control to save energy while the calculator is between key presses.

Software

The interface is built around a Forth-style system with an 8 level stack of 8 byte objects. Unlike most Forths, there are three different types: floats, strings, and hex. The floats use 6 bytes for a 12 digit BCD significand and 2 bytes for the exponent and sign. Strings can take up all 8 bytes. Hex objects hold a 16-bit unsigned integer that can be used for memory addressing and come in two types: smart and raw. The raw hex type just stores a single 16-bit number. The smart hex type holds a base address, offset, and calculated sum of the two. The offset comes from any value added or subtracted to the object. This lets pointers be garbage collected since only the base needs to be updated then the existing offset can be applied to generate the sum. Garbage collection is also not a common feature in most Forths, but is definitely necessary for a Forth-based calculator with only 2KB of RAM to be viable. 

The Forth system is token based to conserve memory. The header of each word describes how many objects of which type the word expects on the stack. The dispatcher can check those objects and prevent stack underflow, which saves a lot of space compared to doing the checks in the word itself. Marking each word and piece of data with a token allows for garbage collection, since every piece of data that is a pointer which may change can be identified and updated when needed. 

So far, the basic Forth system including defining words, tick, and EXEC, and the four basic arithmetic functions for floats and hex objects have been defined. The main functions remaining to be implemented are loops, IF statements, and transcendental functions like sine and logarithms. The firmware is already 6.5KB, so there is very little room to squeeze in a lot of capability. My plan now is to continue writing everything in assembly, even if the firmware overflows the 8KB limit, then rewrite key parts of it in Forth to squeeze it into the available memory.

Floating point

The floating point numbers have a 12 decimal digit significand with guard, round, and sticky digits and rounding to even, which is the same format used by the HP-48 series of calculators. Implementing a floating point package is somewhat complicated and easy to make a mistake on, so a lot of testing is needed to verify the calculations. At first, I included tests in the firmware running in my JavaScript emulator, but this doesn't work well at all for a large file of test data. Next, I ported the emulator to node.js, so I can run the tests in a separate console window. This works by first generating a few million test calculations in Python using the Decimal package configured for the same number of decimal places and rounding style. The calculations are written to a file that comes to about 200MB then directed to the node.js emulator. The firmware running in the emulator reads the file generated by Python and performs calculations on the data there then compares the results to the results in the file and flags any that don't match. This system let me catch several errors in my code that would have been difficult to find otherwise.

Conclusion

Despite the months of work on this project, there is still a lot to do! In the coming months, I'll work on the keypad, power supply, and finishing the firmware, so I can finish the project and submit it to the contest.

Pocket Calculator: Hardware

In the last two weeks I have made a lot of progress on my Pocket Calculator. Normally, I like to breadboard everything and have it working 100% before I solder anything, but I had to speed things up since I was leaving home where all my electronics stuff is. So far, the project has turned out reasonably well with only a few hiccups.

Microcontroller: LPC1114
First of all, I had to get out my old LPC1114s and figure out how to program them again, since I haven't worked with them in over 2 years. Like before, it was really easy to do so with an FT232 cable. After frying an MSP430 Launchpad a few years ago by accidentally giving it 5v from the cable, I was really careful about hooking it up this time. One thing I do is leave the cable unconnected from USB until I recheck all the connections, which saved me this time since I had accidentally plugged into the 5v line again.

Looking on the internet I was surprised to see that no one seems to sell the LPC1114 in DIP28 any more. That means the three that I have left might be the last ones I have to play with. There was some sort of announcement a few years ago that NXP would stop producing the chip then they changed their mind after someone pointed out that the company had promised to keep its chips in production. It looks like they might have decided to stop producing them after all, although they are listed as in production until at least 2022 on the NXP longevity page. One interesting thing I found was a listing for the chip in PLCC44 package with 8KB of RAM instead of the 4 the DIP version has. I'm not sure if those ever made it into production but it would be cool to have one to play with.

New Project: 6502 Graphing Calculator

One of the last things I want to make progress on before Makevention in a few weeks is a graphing calculator I have been planning for quite a while. It will use a 65C02 and is the main reason I started on my 6502 Virtual Trainer last year. Most models of Texas Instrument's graphing calculators use a Z80, which was a competitor to the 6502 in the past. Those models have a 6 or 15MHz clock. The Z80 needs roughly three times more cycles than a 6502 to accomplish the same task, so running this calculator at 5MHz should be as fast as one of those calculators at 15MHz. At the maximum speed of 14MHz, it should be nearly three times as fast. Interestingly, Hewlett Packard did produce several non-graphing calculators like the HP-35S, which used a 8502 chip based on the 6502. Later models of TI calculators used the Motorola 68000 and the latest use ARM processors. These will certainly outperform anything I could make with a 6502. My hope is to make something in power between the Z80 and 68000 series with a few added features.

So far I have finished most of the decoding logic in the ATF1508 CPLD I have been working on. It has 57

IO pins and I have managed to use them all without finishing all the functionality I need. My plan is to use a 512KB SRAM chip with the first 2KB of address space always mapped to the first 2KB of the SRAM. The next two 30KB chunks of address space will point to two windows in the SRAM controlled by the CPLD. This will let me copy large chunks of data between two parts of the SRAM without changing the window between copies. Hopefully 30KB is enough for any single program the calculator will need to run. The last 2KB will be the EEPROM. This is hopefully enough space for a small bootloader that will copy firmware from an SD card and into the SRAM banks. The peripherals like the keyboard and LCD are mapped into the last few bytes of the first 2KB of SRAM.

For the LCD I found a fairly cheap 3.2 inch 320x240 color LCD on eBay. It is the perfect size for a calculator like this. It was also easy to get working with an MSP430 and some shift registers. The only downside is that I did not get an SPI version and I do not have enough CPLD pins to drive the 16 bit data port. The good news is that the LCD seems to expect 3v signals, so I will need some shift registers for level shifting anyway, which frees up a lot of pins. I don't think I will be able to finish very much more of this project for Makevention but I would like to get it drawing to the LCD from a program stored on an EEPROM by then. If I do have extra time, I will work on getting it to read a keypad.

Summer Hackathon

Over the past year, I have not had as much time as I would have liked to devote to my electronics projects because I have been so busy with school. Hopefully I will be able to catch up this summer. My goal is to finish some projects I have already started on and start on some others I have been planning for a long time.

Here is a list of what I will be working on. Even though I probably won't have time to finish them all, these are my goals for the summer.

EEPROM Computer	Progress:	40%
As part of another project, I got interested in using an EEPROM lookup table to do four bit additions and ended up with this test setup. A 32KB EEPROM can hold 64 tables, which is enough to implement all the op codes for a full CPU. Hopefully this will greatly reduce the amount of logic involved. All that should be needed are some counters, buffers, and a multiplexer. So far I have finished most of a simulation in Atanua and started on a symbolic assembler. After I finish the assembler and have the simulation running, I will move everything to perfboard and program the op codes and source code into real EEPROMs.

8-bit Homebrew Computer	Progress:	0%
This project is something I have been thinking about for a long time. I won't say exactly how I plan to do it yet but looking on the internet I haven't found anything similar. It won't be possible to simulate this project in Atanua, so I plan to build it directly on a breadboard. The same assembler from the EEPROM Computer should be able to be changed to work for this also. I'm not sure yet whether it will be worth it to make a PC simulator for this project.

Brainfuck Micrcontroller	Progress:	50%
After I finished the simulation for this project, I did not do much more work on it. The simulated version is four bits and will have to be expanded to eight in the final hardware. The software for the project is very simple, as all it does is convert Brainfuck commands into simple op codes.

Juggalo Robot	Progress:	70%
My brother and I started work on converting a remote control car into a robot. It will have a baby doll on top with moving arms and a rotating head. He decided to paint the doll's face and make the robot juggalo themed. He got motor drivers working with an Arduino for servos in the arms and a stepper for the head. My work so far has been to reroute motor control signals on the car from the motors to a microcontroller. That way another microcontroller in the remote control can send motor control signals over the radio, which the microcontroller in the car will intercept and interpret. Then it can activate the motors, servos, or stepper according to the signal sent by the remote. The hardware is mostly finished. All that's left is the software, which should be pretty simple.

ESP8266	Progress:	0%
Last year we had a fun night doing projects with some SparkCores at our hackerspace and I decided to get a hold of an ESP8266. At $4 it was much cheaper than a SparkCore, even if it is not as easy to program. Unfortunately, I have not had time to even hook it up and try anything with it. One of my plans is to install it in a calculator for an idea I have been thinking about for a long time. One of the challenges will be getting it to connect correctly to WiFi at my university or local cafes. Another idea is to use it to program MSP430s or EEPROMs from my Chromebook, since it can't program them directly over USB.

Wireless Breadboard	Progress:	0%
This is a project I put a lot of thought into before I found out that it has already been done. My plan is to use IO expanders to control every row of a breadboard with a microcontroller. For rows that should be connected wirelessly, the microcontroller will read and relay signals to the appropriate row. This will be comparatively slow because the microcontroller will be bitbanging both the input and output of the IO expanders. Another project I saw used an FPGA, which would be much faster, but using IO expanders will hopefully be an acceptable solution, even if it is much slower. All the connections between rows will be set on the PC, which is hopefully more convenient than plugging in wires. The main advantage will be monitoring the rows and displaying data in an easy to read way on the PC. This should really speed up debugging. Also, output signals can be controlled from the PC, so programming EEPROMs or other chips should be easy.

ATF1508 CPLD	Progress:	5%
For my next 6502 project I want to use a CPLD for the address decoding. The ATF1508 is one of the few ones left in production that runs at 5 volts. It can be programmed over JTAG, so I started soldering a programmer that will use an MPS430. The chip comes in PLCC. so soldering the adapter will be a little inconvenient. My plan is to add LEDs and dip switches so I can test my designs after programming.

BASIC Interpreter	Progress:	30%
A couple of projects I would like to do eventually will need to run a BASIC interpreter. One of them is the wireless breadboard mentioned above. It would be better for new functionality, like device programming, to be done with some kind of script. That way, new scripts can be transfered to the chip at run time, instead of having to reflash the chip every time.

LCD Programming	Progress:	0%
Some of the upcoming projects will need an output of some kind. A four inch LCD should work well for the ones that a 20x4 character LCD isn't enough for. Hopefully I can get one kind of LCD going that will work for several of the projects. Another option is a 5.5 inch LCD I got a few years ago. It is much larger but requires -27 volts for contrast. This is not easy to generate, but if I can get it going, I will hopefully be able to buy several more pretty cheaply. It would work well with homebrew projects if I can get it working without a microcontroller. The STM32F429 board I have been working with also has an LCD that I would like to get going.

Improved 6502 Trainer	Progress:	20%
The 6502 Virtual Trainer was nearly finished when I stopped working on it months ago. It works really well, except that the max speed is just under 0.02 MHz. Now that I have my STM32 board running, I hope to port the code for the project from the MSP430. It ran the BCD multiply routine from the microcontroller comparison about 15 times faster, although that's probably not a good indicator of how much faster it would be for this project. There are a few changes to how UART works that might speed things up also. Another speedup will come from driving the GPIOs directly, instead of through IO expanders. Hopefully all of this together will give me the 50x speedup I need to hit 1MHz. At first I intend to make a board that will plug into the STM32 board directly and possibly use a UART cable for communication. When I figure out how to design PCBs I will make a standalone board with an STM32F429 and an FT232.

Improved RPN Calculator	Progress:	40%
For one of my friends I would like to remake my original RPN Scientific Calculator. This time I will use an LPC1114, which will allow me to copy numbers to the chip's memory before calculating. This should greatly increase calculation time because the external memory won't have to be accessed during any calculations. This will also make the firmware smaller. It should easily fit into the 32 KB the chip has, so two microcontrollers won't be necessary. Also, I would like to use a 23LC1024 SPI SRAM this time instead of parallel RAM. Altogether, the circuit should be very small.

Quiz Buzzer

About a month ago a friend of mine called and asked if I could make a buzzer system for a quiz game for students. Unfortunately, I only had two days until the competition and I did not get it working in time. Hopefully, I can fix it and send it to them to be used at the next competition in a few months.

The plan was that each of ten students would have a button connected to a buzzer by a few meters of wire and the first to press the button after a question was asked would cause a sound and light to go off. The connectors are RCA style and the buttons are from an automotive store.

These lead to an A42 enclosure I was able to sample from Serpac. The enclosure felt really sturdy but the plastic was surprisingly easy to cut and work with with just a knife. I will definitely use them again when I need an enclosure. The circuit itself was fairly simple with just an MSP430 microcontroller, buzzer, two 595 shift registers, and two 165 shift registers. I did not get around to adding the LEDs, although the firmware does use the shift registers to turn on the correct light when someone buzzes in.

To control things I made a separate detachable board with a 16x2 LCD. It will be easier to transport if the cable is detachable and it will also let me add a longer cable if the judges doing the scoring need to sit farther away from the enclosure. Other than the LCD, the board has a 555 to generate negative voltage for the LCD contrast and another 595 shift register to run the LCD. It also has buttons to change the time given to answer and to reset the counter.

For the cable I used Cat-5 again and this may be part of the reason it does not work correctly. For the connector I wanted to make something that would only plug in one way so that people other than me could use it without fear of plugging it in backwards and shorting something. Each side has a pin that can only be connected one way.

A project like this would take me a week at least but I tried to finish in two days because my friends needed it. The night before I stayed up soldering until 7am and when I finally switched it on, the LCD came on as expected and the buzzer sounded when I pressed one of the contestants buttons, but it made a high pitched screeching noise when it was finished buzzing. When I turned it off and tried again the LCD wouldn't display anything and only worked some of the time when I tried it again, so we weren't able to use it in the competition after all.

Why did it fail? In retrospect, I have had problems with this particular LCD in the past. When I was working on my calculator project I noticed that the LCD would often not work when being driven directly by a microcontroller but worked fine when being driven from a shift register like in this project. I'm not sure why it worked before and not now but the fact that it was flaky before might be a clue to my problem. Also, maybe my assumption that it will always work at voltages less than 5v is not correct or maybe supplying negative voltage to the display somehow has consequences. On the other hand, I observed the same faulty behavior with the contrast left unconnected. Another source of problems could be the Cat-5 Ethernet cable I am using for wiring. Each pair is twisted together and running a separate signal through each side of the pair instead of grounding one side might be leading to signal corruption. Finally, the loud screeching of the piezo buzzer is something I will have to figure out as well. Hopefully, when I understand more about this it will help me straighten things out with my clock project also.

Going from nothing to a nearly complete project in only two days was a lot of work, but in the end there was not enough time to troubleshoot problems. When I move into my new apartment next month I will have time to figure everything out and then I can send the working system back to Kyrgyzstan for my friends to use.

555 Entropy and Robotic Teddy Bears

Recently I have been keeping busy with a few electronics projects, although it doesn't look like either of them will turn into anything. The first would transmit text wirelessly from a PC to a microcontroller to be displayed on an LCD. For this I planned to hack toy walkie talkies. This is not an ideal way to transfer text but I thought it would be fun to try different ways of making them work to start understanding wireless communication. Unfortunately, in my whole town I could only find one set of walkie talkies and one of them turned out not to work. The data being sent would not be especially sensitive but I still did not want to send it as plain text. This got me wondering about encryption, which I also have no experience with. There are many algorithms but I would need one very easy to compute since the microcontrollers involved would not be very powerful but would have to decrypt and transfer quickly. One solution that intrigued me was using a one time pad. Each microcontroller would have the same list of random numbers that would simply be added or XOR'ed with the data to encrypt and decrypt it. One time pad schemes have the advantage of being truly unbreakable as long as the numbers used are random and never repeated. A bigger advantage for me is that the microcontrollers could simply fetch the numbers from an SD card without having to compute anything. To get truly random numbers, though, I would need a hardware random number generator. These are a common project for hobbysts but not always easy to build correctly. One method uses a transistor in reverse breakdown mode but I decided against this because it requires 15 volts or more. Apparently the transistor also changes with age (perhaps due to being continuously run in a way it was not designed to be) and the characteristics of the numbers generated change too. Another interesting way I found was to measure the output of a 555 timer with a microcontroller ADC as shown here. This made me wonder if I could just measure the length of 555 pulses compared to the oscillator in a microcontroller to use clock drift as an entropy source. I connected a 555 running at 480Hz to the hardware counter of an MSP430 running at 16MHz to measure how many clock cycles each 555 cycle took and dumped 1,000,000 samples out over UART.

RPN Scientific Calculator: Hardware

In the last two months I have made a lot of progress with my calculator. The software is now finished. As well as cleaning up a few bugs I also added a battery meter to the settings page. There was enough memory on the external RAM for two separate stacks with 200 levels each. All of the code is now on a GitHub page: https://github.com/druzyek/RPN_Calculator.

For the hardware I soldered everything on to perfboard. It didn't power up the first time I plugged it in but after fixing one power connection everything started up and worked fine. Here is a picture:

For the power supply I am using 4xAA batteries with an LM1117 adjustable regulator. My local shop didn't have the resistors I needed to get 3.6v from the regulator so it is running closer to 3.5v. On the left side you can see female headers for the keyboard outputs to be plugged into and on the lower left a repurposed DIP socket for the LCD and keyboard inputs to be plugged into. The red, white, and blue wires were the smallest single strand gauge one store had and worked fairly well. When I ran out of that I switched to an even smaller gauge (the brown wires) I got form another store and it was even more convenient. It works so much better than breadboard wire and I definitely plan to use it again. If you look closely you will see two pins for power so that the whole board can be powered from the LaunchPad if needed. Each MSP430 also has its own set of programming pins so that they can be programmed in circuit. One strange thing I noticed on this project is that solder will sometimes spill through the holes and onto the other side of the board. This may be because the smaller gauge wire lets the solder through more easily. One problem I had while testing the connections were two adjacent socket pins that seemed to be bridged, even after desoldering everything around them. After removing the socket itself, I saw that a drop of solder had flowed to the other side of the board and shorted the two legs in the space between the board and the socket.

Here is everything connected and running:

 Here is a circuit schematic of the whole system:

For the case I soldered together some clad which I was able to get really cheaply. It feels pretty solid. It needs a coat of paint and I need to adjust the holes in the faceplate for the keyboard and screen. Here is what it looks like so far:

As was my goal, I submitted the project to the Project of the Month Competition at 43oh.com. Thankfully it was extended an extra month so I had some time to finish most of what I wanted to finish. Voting starts tomorrow!

RPN Scientific Calculator: Update

As I mentioned in the last post about this project, I added a second MSP430 because the firmware was getting too large. In the end hardware UART turned out to be a good choice for communication between them. It works very fast and is reliable. The first MSP430 is responsible for reading the keyboard, controlling the LCD, handling the interface, and performing checks such as division by zero before passing on the addresses of the values  to be calculated to the second MSP430. The firmware for the first chip comes to a little over 13KB. The second MSP430 does all the actual calculating since it is connected to the SRAM. Its firmware is about 10KB.

The software part of this project is almost finished. One thing I added was a settings page. The accuracy of calculations can be set anywhere between 6 and 32 decimal places. There are also options to use scientific notation and switch between degrees and radians for trig functions. The only things left to add are a battery meter and support for two stacks. A second stack is not really necessary but as it is now, only one half of the 128KB SRAM is usable since the 17th address pin is not hooked up. I plan to add a button so that the second half of memory can be used as a separate stack.

Although I planned on adding programming features at the beginning, I may not have time. The 43oh forum is having a project of the month competition I would like to enter this project in and I will need to hurry to finish putting together the hardware and making a case for it. If there is time left at the end of the month I may add a simple key stroke programming mode. It is a little disappointing that I did not get to this but on the other hand, it is convenient to have a firm end to this project. It would be easy to keep adding features but even now I feel like I have stretched the project beyond what the hardware can reasonably handle. I have plans for other calculators that will be programmable but they will use a more powerful chip than the MSP430G2553 and they won't use SRAM controlled by shift registers.

One change I made to the hardware was to use a different LCD. The new LCD is also 20x4 but it was much cheaper. The old LCD was quite expensive and I would like to keep using it rather than commit it to this project. The new LCD is 10cm wide instead of 8cm like the old one so I decided to turn the keypad long ways to save room. Here is the layout I plan to use:

RPN Scientific Calculator: Second MSP430

The next step for the calculator is the interface. The code for handling input ended up being fairly long but now entering numbers works as well as the basic math functions. A lot of flash space was taken up by the mathematical checks that must be done with trig functions to convert them to useable forms and ensure that they are within a valid range.
 
At this point the firmware took up about 14KB, which is close to the 16KB I have to work with. There probably isn't enough space left to add all of the functions and accompanying checks so I decided to add another MSP430. This will give me more more space but also make things more difficult since I will have to coordinate communication between the two. Moving to another chip with more Flash would be an option but I have plenty of MSP430s on hand and I don't want to move chips now that I have everything working well together.

Since I only have one LaunchPad I had to program the second MSP430 on a breadboard. This is pretty easy to do. The LaunchPad has jumpers on the RST and TEST lines where the programming signals can be diverted and used elsewhere. In this case they go to the breadboard, and a dip switch is used to select whether the programming signals go back to the LaunchPad or to the breadboarded chip.

With two chips I have a lot of left over pins. This let me eliminate the read and write shift registers used with the SRAM. The data port is now connected to one whole port of the second MSP430 instead and should work a little faster. The next step was to establish communication between the two chips. Using one pin for data and another as a clock signal, I was able to do some simple data transfers. Unfortunately this caused an error, usually after several thousand successful transfers. It's not clear whether the error was caused by hardware problems like breadboard crosstalk or if there was a timing error of some kind in my code. My plan now is to use hardware UART between the chips instead. Hopefully this will be more reliable.

There are now also enough pins to drive the LCD directly instead of using a shift register. When I tried doing this before with a 16x2 LCD it worked well but at some point in the project it began to randomly stop working. In retrospect I think it may have started after adding some of the other components to the project. In any case, sending signals to the 20x4 LCD from the LaunchPad does not work at all. This problem will have to wait until I can replace my broken multimeter and test all the voltages involved.

RPN Scientific Calculator: Tweaks

Recently I was able to get some new components and took the chance to make a few tweaks to the calculator. First of all, I hooked up a new 20x4 character LCD to replace the 16x2 version I was using before. It is gray with black letters and I like how it looks. With this I will be able to make the bottom row of the screen a menu like the kind some of the later HP calculators use. The LCD itself came with male headers so it can be plugged into a breadboard, but there was no convenient place to put it so I decided to run wires from the headers to the breadboard instead. The LCD worked fine at first but quickly became corrupted after I wound the wires into a loop to make them neater. This was causing crosstalk and the problem disappeared when I separated the wires.

I also added a CMOS 555 timer to generate the negative voltage for the LCD. This frees up a microcontroller pin that I am now using to independently drive the input shift register of the RAM. Now I can read the external RAM and the keyboard at the same time without worrying about coordinating interrupts. In order to save energy I decided to use the smallest capacitor and the largest value resistors I could for the timer. Unfortunately, none of the resistor values I had on hand would give me the 30 Hz or so the microcontroller was generating. 48 Hz was the closest I could get using a 0.1 uF capacitor and 100k ohm resistors for R1 and R2. Adding a 470 ohm resistor to the output of the 555 gave a good contrast and should also keep the contrast constant if I try to run everything from a battery later.

The last thing I did was to expand the CORDIC tables to 32 bits wide instead of 16. Using a 16 bit wide table gives around 14 decimal places of accuracy which is sufficient for calculating logarithms. A problem arises, however, when that logarithm is used to calculate things like exponents because those 14 places of accuracy also include the whole part of the answer. A simple calculation like 8^9 only offers 5 decimal places of accuracy after the decimal since the whole part is 9 digits long. The new version takes about 6 seconds to calculate "atan(tan(37))" This is very slow so I will let the user set the precision in settings.

RPN Scientific Calculator: Software Update

Work continues on my calculator. Each byte of a BCD number now holds only one digit instead of two. This eliminates the functions that were needed to align and pad numbers when every byte held two numbers. It also makes calculations a little simpler and reduces the amount of space the functions take up in the Flash.

Another improvement is that arrays can be stored in the external SRAM and accessed similarly to how internal memory is accessed. To read or write anything to the external memory a function has to be used. That means a simple equation like this:

X+=Y*Z-Q;

would become this if those variables were stored externally:

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

This is difficult to decipher and inconvenient to use when writing code. My solution was to make a small program that preprocesses the source code and replaces any variables that should be stored externally with their corresponding read and write commands. These variables are marked off with #pragma directives. #pragma is a note to the compiler to do something special that may be specific to that compiler. If the compiler doesn't recognize the directive, it is ignored. Here is an example of what the preprocessor would do.

This is unprocessed code:

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);
}

 This is preprocessed code:

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);
}

Arrays are converted to pointers that store offsets to the external memory. This way none of the function prototypes have to be changed. The code should work the same way whether the variables are stored in internal or external RAM. External memory can be turned off if needed to make tracking down bugs easier. One disadvantage to this is that function arguments must be either internally or externally stored but a function can't accept both types for one argument. For things that need both I will need a wrapper function. The preprocessor doesn't support all of the C standard since I only spent about a day on it. Adding support for all of the possible ways there are to access a variable would take a lot more work and I wouldn't be likely to use that functionality anyway. Things like variable names that span multiple lines or variable assignments inside of other statements aren't supported but I didn't end up using any of those features in my code.

The new code for adding and subtracting BCD numbers fits in about 2K, including LCD driving code. Using the preprocessor to store all the values externally adds another 500 bytes. The code for multiplication is also much smaller than the last version.

RPN Scientific Calculator: External RAM

The last part of the hardware needed to complete the calculator is external RAM. Even if it does not have any programming capabilities, it will still need more RAM for the stack than the 512 bytes an MSP430G2553 has. Microchip makes 128K SRAM chips that are small and accessible over SPI that would work well for this project. However, I had this parallel SRAM chip from Alliance left over with nothing in mind for it and I decided to use it instead. It needs 8 pins for data so I am using one 74HC595 for output and one 74HC165 for input. The 17 address pins are driven by two more 74HC595s. This only gives 16 outputs so the 17th address pin is tied directly to a microcontroller pin. This will allow me to have two banks of memory, although I don't have any use for that at the moment. Putting this together took a lot of wiring but it wasn't too difficult.

Accessing large amounts of memory like this over serial can be a speed bottleneck, so I decided to use the USCI module of the MSP430 to do hardware SPI and speed up transfers. After learning how it works I saw that it is really easy to set up and convenient to use. As with the shift registers that read the button matrix, I decided to share the clock but to use different latches. The USCI has separate data in and data out pins so those aren't shared. This is handy for reading the 165 shift register because after it is latched you can just push a dummy value out then read the USCI receive buffer. There is a flag to control whether the USCI stores data in MSB (Most Signicant Bit) or LSB format but it can't be set separately for the input and output buffers. This means data goes out with the right orientation but comes in backwards. To remedy this I hooked up the data inputs of the 165 in reverse order to the data bus of the SRAM.

To test the speed of this setup I made a test program to write a pattern to every byte of the RAM then read it back and make sure the values are as expected. This worked fine at 1MHz but the LCD glitched when I tried running at 16MHz. After I fixed that I was able to finish the whole test in about two seconds. That is pretty good throughput for a calculator!

Now that the RAM is working, the hardware part is finished. It is good that I don't have anything else to add since all of the microcontroller pins are taken up. In fact the input shift registers for the SRAM and keypad share the same latch since it is unlikely that they will ever be used at the same time. If I need anything else I will have to use the two remaining bits in the keypad shift register (the keypad only has 6 rows and the LCD only needs 5 bits) or add another shift register. Now I can focus on the programming and worry about hardware again when it is time to make a circuit board. Here is what the hardware looks like now:

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.

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.