While searching for a connector recently, I revisited an old project of mine called the Serial Squid. This was to have been my first open-source hardware design. After completing the entire design, PCB, BOM, and preparing for a crowd-funded campaign, I eventually gave up for reasons discussed below, I’ve always thought of this as a failure, but on further reflection I see it in a new light. There were some good lessons learned along the path to abandonment.
When do you let go? When should you push through?
An Idea Forms
The Serial Squid was to be essentially an Ethernet-connected Bus Pirate. The motivations for this project were many. Too many, in fact, and perhaps that should have been an early warning sign. At first, I just wanted a remote serial UART, and this out of laziness. It annoyed me to carry my laptop from my desk to the lab bench for debugging, or carrying the project to my desk. Surely there must be some way to physically extend my office computer’s I/O across the room or building to the lab bench over the network. So I focused only on serial UART solutions, and in fact had some modest success sharing a second compter’s serial port using
socat. But I gradually expanded the scope of my notional widget to include other serial interfaces of interest to the embedded developer.
Around this time, I had stumbled upon a small handheld flash programmer from China called Eagle Comm. It was designed for a variety of MCUs such as PIC, Cortex, AVR, etc., and was super easy to operate. It was perfect for small production runs at the factory or to send to customers to upgrade prototype boards. The more I used it, the more I liked the form-factor and wondered whether I could repurpose it. But the manufacturer wasn’t willing to share the code, and the hardware wasn’t that good a fit for my application to warrant reverse engineering it. But maybe my still-unnamed widget could learn a thing or two from the packaging and layout of the Eagle Comm unit.
Speaking of sending something to a client for flashing a chip, it would also be helpful to have something I could send some of my clients to use for data logging, especially when a system was installed on a remote location with no network access. Could my widget be battery powered and easily used as a logger?
And finally, I had been intrigued for years about packaging an electronics in a flat “enclosure”, made entirely of layers of PCBs. A suitably thin SMT board could be made into a flat package by adding a few fiberglass PCBs, some with cutouts for components. Connections and help could be silkscreened directly on the outer layers, and assembly would be as simple as screwing the layers together.
Gradually this product began to gel in my mind. Ideally, I wanted a small handheld device with a keyboard and display, and the provision for several I/O modules corresponding to each kind of interface. If you’ve ever held an old HP-41C calculator, imagine the plug-in modules being I/O blocks, for example. Alas, this approach eluded me for some time. There wasn’t a perfect intermediate bus for these modules. I wanted something that was not only technically suitable, but also low-cost, license-free, and that wouldn’t disappear next year. I was circling around Ethernet or SPI, when I hit upon the solution: defer a modular design until version 2, and go with a fixed set of ports for version 1.
I was having a tough time with the form factor. Making a half-decent keypad wasn’t going go be easy. And I was considering crowd sourcing, and if I was going to get any traction, a simple calculator-like layout was just plain boring. I wanted my widget to have a catchy look. I pursued several candidate designs with mockups and CAD, but none of them were quite right.
Then one day it hit me, something suggestive of a common food here in South Korea — my widget was going to be a squid. Each arm of the squid would be an interface port, and the head would naturally be the brain. Ten legs would be plenty. Now I could offer almost every serial protocol known. My newly-named Serial Squid would be really versatile.
After several explorations of squid-like shapes, I settled on the design below. I went through an exhaustive exercise to find the best connectors and pinouts for each interface.
Do Your Research
This part of the design took a really long time. Many serial protocols don’t have standard connectors. Sometimes we take for granted those everyday things we use like the TTL-level serial connector pinouts or what connector and pinout should an RS-485 interface have. (There’s no standard, but a fairly well adopted de-facto one.) Knowing the related specifications, history, and common usage can be quite helpful.
I researched as many different implementations as possible from other projects and products. Eventually I selected the most appropriate connector and pinout for each of the interfaces.
All the time I was trying my best to keep the “flat PCB” construction technique in mind. Because of the physical constraints of many of the connectors, some compromise was needed. This would not be a sleek, slim PCB sandwich, but I still feel the result would have been acceptable for the intended application. I was also leaning towards a 3D printed case instead of a PCB sandwich, because the stackup of PCBs needed were getting quite complicated, and I suspect more expensive than 3D printing.
The Death of a Squid
I abandoned the project after almost a year. I was so close. I had the Gerbers ready, the PCBs were quoted from China, parts were in my shopping cart ready to order. There were lots of reasons why, but three main ones come to mind.
Killer #1: Software
While I was cheerfully doing hardware design, the dark clouds of firmware development were looming. For this board to perform as I envisioned, I needed firmware that would present its various serial ports to a remote computer over Ethernet and possibly USB. While this didn’t seem too daunting when I thought about a UART, when you toss in a dozen other interfaces you have a problem. The biggest one being no standard xxxx-over-LAN protocol existed for these ports, nor did computers even have most of these ports natively. The enormity of the firmware task slowly sank in, not to mention possible desktop device driver development, and my enthusiasm began to fizzle out.
Killer #2: No Clear Purpose
Many people I discussed the project with admitted it was catchy and novel, but it was difficult to explain what it did. “It can do anything” was an unrealistic answer, and an honest evaluation led me to conclude it was trying to do too much.
Killer #3: Distracted by Rev 2
I was never quite happy with the the ten legs having fixed I/O ports. Ideally, I wanted the user to be able to mix and match the legs. This way I could make the body smaller, perhaps moving away from form factors based on 10-legged creatures. Four or five legs would be plenty. I kept debating with myself whether I should wrap up the squid first and then move on to Rev 2, or drop the squid and leapfrog directly to a new design. I did neither.
Lessons Learned: Feature Creep
Over the years as an engineer, I’ve experienced the mental letdown when a project ends or gets cancelled. But interestingly, I didn’t feel that way upon giving up this project. I had such a good time doing the design, learned or re-learned a lot of lessons, and gained some new skills along the way.
Beware of broad scopes and feature creep. This is well known by everyone in the community. But despite being a gray-beard, I was tripped up. Try to recognize the warning signs of a bloated specification. And if you see it happening, try to fix it or quit before you get in too deep. The fact that nobody could understand the purpose was a big red flag — I saw it, but ignored it anyway. Also, be flexible, know when to give up or abandon on a feature. Don’t be too rigid in the specifications, especially if it’s a hobby project.
I quickly abandoned my idea of the Squid appearing as port extensions on your desktop. Had I pressed on, I was going to either replace the micro with a Linux SBC, or run a scripting lanuage like Python or Forth on the Squid. If you find yourself having to re-invent or build new protocols from scratch, take a close look. There might be valid reasons to do so, but more often than not, you will be better off adopting existing interfaces and standards.
Don’t underestimate the value of mockups, either physical or simulated in CAD. I used this project as an opportunity to learn OpenSCAD, a skill that I’ve found quite useful. I also made a decision to get up-to-speed on KiCad for this project. Having used several professional PCB design tools over the years probably helped, but I could see that KiCad was going places and I needed to become proficient with it.
Be honest with yourself — brutally honest. As eye-catching as the Serial Squid is, I have to admit that I’m not sure how comfortable it would be to use in real life. Also really look closely at the problem you’re trying to solve. In hindsight, 99% of the use cases I was looking at solving could have been done with a Raspberry Pi and a custom shield or two.
Although strictly speaking the project was a failure, I had a lot of fun doing it. I met new people and companies, and learned new skills that I’m still using five years on. If you have a new project in mind, use some common sense. Bounce your ideas off of colleagues and fellow hackers. Then jump in and start. And don’t be afraid of a flop — even a failure can be valuable.