Hex Calculator Part 2 – Printed Circuit Board

As of this week the hardware design phase for this project is complete (mostly). Specifically, I have completed schematic capture, bill of materials, and procurement for my first revision. The PCB design is as complete as I can get it at this point with routes/placement defined for all components other than the battery holder. Trouble is I’m blocked on just the battery holder that I ordered from China that I don’t have a datasheet for and need to measure my own footprints when they come in. Everything else on the PCB is done down to the silk screen and final layout. I can very well send off the gerbers today if it weren’t for these two pesky pads to land the battery holder onto.

As previous experience dictates hardware design is a lengthy process with numerous steps and knowledge required. However, the development time pales in comparison to the making the entire system work. It’s easy to make something “work” on paper but to make it work in practice is something else entirely and the only thing one can do to help that along is to design the hardware properly on the first try. I managed to work out the entire schematic over 4th of July weekend pretty quickly thanks to my previous due diligence selecting the major components and researching the supporting circuitry. From other projects I’ve learned a number of habits to be efficient during hardware design.

  • Save all datasheets and app notes as you’re doing research. Archive important web pages because you never know when they’ll go down. Prune as necessary but never rely on the internet to archive for you.
  • Keep track of the bill of material(BOM) as you place parts on the schematic. When I place a part on the schematic I want to be sure of what I’m placing. I select the exact package, source a vendor, cost the part, and update the BOM accordingly whenever I place a part. Do this for every single part down to the lowly ceramic capacitor and you’ll catch most show stoppers and save you time down the road.
  • Always be conscious of the likelihood you will make mistakes. Plan for a revision and include as many test fixtures as possible too make hardware debug easier. Order at least twice as many components as necessary and as soon as you complete the schematic (no sooner).
  • Be wary of your resources and only choose components you know you can work with. In my case this means things like no 0402 packages, nothing super high frequency, or prohibitively expensive toolchains.
  • Never stop double checking your schematic. Again, mistakes are likely and in hardware they tend to be costly/frustrating. Double checking minimizes this.

For this project I decided to do all my design using EAGLE instead of Altium designer which I’m used to. This was mostly to pull me out of my comfort zone and be more of a generalist when it comes to PCB software. I went with EAGLE because of its popularity particularly among hobbyists which undoubtedly has to do with the free LITE version. Long story short, I didn’t like EAGLE too much at first because it wasn’t what I’m used to (hence leaving my comfort zone). It lacked a lot of nice features of Altium most notably DRC based routing(!!!), footprint wizards, and all the great hotkeys. In EAGLE’s defense, the core functionality is there and if I wanted to design a sophisticated PCB using EAGLE I probably could at a fraction of the cost. One thing I did really like about EAGLE’s status in the hobbyist community was the availability of accurate footprints for nearly every part I had. As I stand now though, I’m fairly comfortable with using EAGLE for hobbyist projects like this and there’s nothing horrible about the software if you know your way around.

As you can see from the image of the PCB above I finalized the button layout and mapped each of the 49 buttons in my grid to some function. It was probably at that moment where I realized how much development effort there will be in the firmware alone. I naively assumed that it would be relatively straightforward, but the functionality I’ve laid out in the buttons is going to be a whole lot more than I anticipated. Everytime I think about it and how my Casio FX calculator behaves there’s a whole lot to keep track of in a calculator and I have rather constrained memory running off the PIC. It’ll be interesting to see if I can get all the functionality implemented in the calculator eventually.

Anyway, I can’t wait to get the PCB back from fabrication since this will actually be the first time I designed a PCB for a personal project completely on my own.  I have to note,  am thoroughly impressed by the options available to the hobbyist designer in terms of PCB manufacturers. Since last I checked the going price for PCB’s now is ~$30 for 10x 10cmx10cm boards and it’s even cheaper if you go with 5cm boards. Not only that but we have a number of shops offering the same deal as evidenced by PCB Shopper. I decided to go with Itead Studio because they were cheap and offered colored solder mask for only $5. Honestly though, they all seem to be on the same level of price/quality/turnover. Anyway, there’s just something so satisfying about seeing the finished product of a hardware design and I just want to have it in my hands now.


SEO and Taking Control of My Google Results

About 63,500 results (0.38 seconds)

A few weeks ago I went through the exercise of Googling my own name “Gerardo Ravago” to discover that this web page doesn’t even appear on the front page. In fact, it would appear that my father has a much greater web presence then I do. I then set out on a project to improve my page rank on Google and take some kind of control over the results that people get from my name on the off chance I may actually be interesting to somebody.

The idea behind the web search problem is that if you have good relevant content your web page should  served up first. For obvious reasons, Google doesn’t publish the exact specifications of their page rank algorithm to thwart hackers looking to commandeer search traffic. What I do know though is that the billion dollar secret behind Google’s success was revealed to me in an undergraduate probability course as nothing more than clever use Markov Chains. When you think about it the internet is just a bunch of web pages that link to each other in a graph. Intuitively, pages that tend to be linked to frequently in regards to a particular subject tend to also be very relevant to that subject. You can then solve for a stationary probability matrix for the probability of landing in any given node (web page) in a graph generated by a certain query on the entirety of Google’s index of web pages. All this of course happens in a fraction of a second as shown above. It’s probably one of the most understated statements we all encounter on a daily basis and it amazes me every time I think about it.

Without reading into any other material other than what I know I formulated a simple strategy to improve my page rank. This was mostly just because I wanted to experiment and see if it would work as I expected. My strategy was simple. First,  enable my Facebook page to be indexed by Google since Google seems to rank these pages very highly. Then I would go through all the pages on Google under my control and add a link to my blog. On my blog I’ll mention my name a few more times in the meta data to ensure that it gets indexed as a page relevant to “Gerardo Ravago”. Finally, wait it out and let the Google bots do their work. It’s been a week now and my blog has gone from the second page of my results up to the 4th result. I still need to dethrone that damn White Pages page and the Facebook links for myself and my father. Hopefully if I drop enough links here and there I can make it happen. In the mean time…

Hello web crawling robots, my name is Gerardo Ravago please click that link to find out more 🙂

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.