I came across an interesting rule by Rob Pike while reading the first chapter of The Art of Unix Programming. “Rule 5. Data dominates. If you’ve chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming”. While there can be numerous ways to solve a certain problem, I always felt solutions that use data structures that are well fit to the problem always have more simpler solutions and are easier to expand in functionality. It felt good to have something I thought was intuitive affirmed but the text went even further in the Rule of Representation by stating “where you see a choice between complexity in data structures and complexity in code, choose the former”. There was no intuitive affirmation or rejection of this statement on my part.
This post is much overdue.
As I worked on the original Arduino-Based Pasteurization Scanner (I will now refer to it as the 1.0), I began to realize that many of the components I was adding could possibly be integrated onto one PCB board. When I first began the 1.0, I really had no knowledge about PCB design, so I sort of pushed the thought off to the side for a good year or so. It just so happened that some of my father’s friends in the cider-brewing community got word of the work I had done, and were possibly interested in having one of their own.
For those of you with less technical knowledge about electrical design, a PCB stands for Printed Circuit Board, which are the “chips” that are inside pretty much of sort of electronic you use daily. They generally contain only the minimum amount of hardware necessary in order to cut down on cost. And since a PCB can be designed once, and printed as many times as the designer wants, it is a good way to mass-produce your design for an electronic.
I soon discovered that PCB design is sort of like carpentry where the mantra of “measure twice, and cut once” rules over everything. All the parts that you intend to use get laid out in software, but the designer has to double check that each part that is necessary in the design matches the physical dimensions in the software, or else the parts won’t fit and a new board will need to be fabricated.
At first, I wanted my PCB to be exactly the same size as the screen I was using, so that the screw holes on the LCD would match the screw holes on my PCB. Then the PCB could just rest directly behind the screen (and when looking straight on, you wouldn’t even know there was anything there). The pins on the right side of the screenshot above match up to the LCD screen inputs, so a vertical header could be used to directly plug in the screen to the PCB.
As I went on in my design, I tried to minimize the amount of traces (which are the electrical connections between parts on the board), and vias (which are when the traces switch from the top side of the PCB to the bottom, so that two different traces don’t intersect). I also added something extra, a WiFi module that prints out data when the user connects to it through a web browser (that’s the big rectangular thing in the upper left on the below screenshot). I also added a 4-axis joystick button, another thermometer port, and a speaker.
Eventually, I scrapped the idea of making the PCB have the same size footprint as the screen and made it even smaller, since I was being charged by the square inch of my design. I also tried to optimize the pins I was using on the microcontroller so that the traces needed could be simpler and require fewer vias.
Once the PCB came in, all I needed to do was solder all the parts on and hope they all fit!
They didn’t. In fact there were a couple errors in my design, which you can’t see since I fixed them on the backside. Also my barrel plug footprint did not match up with the ones I ordered, so I had to break it out with some wires.
I plan to have a complete final design done by the time I graduate.