New Project Time: A Programmer’s Calculator

Mmmm bitwise computation

A colleague of mine brought up a project idea to make a calculator specifically for hex calculations. We work in the embedded tools industry so we frequently come across calculations involving the bitwise operands as well as the need to change the base of a number. While Windows provides the programmer mode in its default calculator which is very capable and convenient, it has the difficulty of not having dedicated hardware. In particular the hex digits A-F and the bitwise operands are not well mapped to the input device (keyboard). Implementing a hardware calculator then seemed to be a reasonably complex and useful project for me to pursue while providing me with a number of exciting new topics to learn about.

I’m just about completing my initial research phase where I wrote down all my thoughts regarding the high level design. Things such as the various hardware modules and how they may be implemented. After that I took a more in depth look at each module to research bits that I wasn’t entirely sure about and eventually start selecting key components. In the end the project can be thought of as five individual modules for processing, power, display, input buttons, and form factor. I’ll outline my notes and design decisions regarding these below.


My primary concern was picking a processor that I could both work with and learn something from. This is because I subscribe to the belief that all these processors are more or less the same in terms of capabilities, and that other non-technical factors are the key differentiators. I chose to go with Microchip’s PIC24F08KL0302 for the CPU for a number reason. For one, I have no experience with PIC and thougt now is as good a time as any to familiarize myself with its architecture. Microchip’s PIC families have a sizable market share in industry so if ever I decide to pursue a career in embedded development outside Freescale it would be good to know. It’s popular with hobbyists because it has hobbyist friendly packages such as PDIP/SOP, a free toolchain+IDE MPLAB, and a cheap programmer the PICKIT 3. My technical specifications were governed primarily by the number of I/O pins which I needed at least 21 of. I had to choose a chip that had the bare minimum of hardware modules while  providing enough I/O’s to control my buttons and the display. The decision to go 16-bit was because I was worried about RAM limitations for an 8-bit and the cost savings were negligible.


Having taken a class in power electronics before I know how understated this aspect of embedded design can be, but I find it an interesting design problem with plenty of choices to make that effect overall efficiency. For most people, it’s also the only part of a system where they actually have to think about analog design. My goals were that the power system needed to be battery powered, high efficiency, low current, and low profile. For the battery I went with a Lithium CR2302 cell due to its ubiquity and the fact that lithium generates 3V over the 1.5V provided by Alkaline. Coin cells are nice because they’re low profile enough to fit the form factor of a flat calculator and standard enough that I can replace them cheaply. As for voltage regulation, the two rails I needed to provide were 3.3V and 5V with small loads. My preference is to not spend too much time searching for the ideal solution because there are simply too many choices available for a hobbyist without an FAE to mull through. What I did know was that I needed to go with either a boost converter or charge pump topology due to the 5V out with 3V in requirement. Charge pump then seemed logical from an efficiency standpoint for my extremely light loads. On Microchip’s website I found the MCP1252 which did both and after verifying it’s cost/availability I commited to it.


I didn’t know too much about my options with regards to displays as I’ve never worked on any other than a high resolution touch screen TFT oddly enough. Turns out there’s a standard developed by Hitachi for character LCDs. These displays come on a PCB with the LCD controller embedded as a COB. To control it you would use a 7/11-pin parallel protocol banged out by the MCU. The fonts for alphanumeric characters are embedded which is nice. Vendors such as Sparkfun/Adafruit make it even easier by embedding yet another MCU that translates commands from a serial port to the parallel interface. This seemed a bit unnecessary to me so I’m just going to implement the protocol myself using the 7-bit interface. There were really no other displays that looked like viable options for me without adding significant development overhead with little to gain as far as this project is concerned.


The tricky thing regarding inputs was the quantity of inputs I needed to be able to handle. I’ve never actually designed for a device that needed more inputs than I could justify the I/O pins for. In all, for a minimum viable product I worked out that I needed 46 buttons for the functions I wanted to handle. Looking for an IC to do it for me was my first thought. A lot of these I/O expanders work via I2C which is very attractive given
the 2 pin investment. The MAX7360 in particular was extremely attractive in that it featured 8 GPIO’s with PWM capabilities, interrupt signals, debouncing, multiple I2C addresses, and most importantly a 64 pin key matrix controller. If it wasn’t for the $6 price tag I would’ve loved to play with this chip, but I figured I could invest a little more on the MCU to swing for the bigger package with more GPIO. To handle these inputs, I need to implement what’s called a key matrix which reduced the number of pins required to 2*sqrt(n) making my grand total 14 GPIO pins for input. It works by laying the buttons out in a grid and using the MCU to work out the intersection of the two buttons. This is done by toggling power on all the columns and polling the rows for an intersection. For issues of debouncing, I figure I’ll just handle those in software with a delay so I won’t have to fiddle with RC time constants. Similarly ghosting won’t be an issue for this application as I don’t expect the user to do anything meaningful with a two button input. As for the actual part, I plan on using mechanical buttons since I don’t have the resources to make nice board printed contacts with custom buttons.

Form Factor

Finally we come down to what this thing should look like in the end. I didn’t have too much to consider here since I ruled out casing the device early on. This was because I’m trying more to showcase my ECE skills and not any kind of mechanical design. Given that I have no such experience, it would add a significant risk and a huge overhead from the learning curve. On top of that it completely abstracts the real work behind this device from the end user. This leaves the bare PCB + silk screen style for my calculator. I plan on laying out the buttons/screen similar to the Windows calculator so it becomes a landscape style device.

Leave a Reply

Your email address will not be published.