Single-board computers are a game-changer. Here's why.

The realization was in college. I built a perfect 555 timer circuit on a university lab breadboard – the square wave was perfect. A geometric perfection that would make Mies van der Rohe proud. Begrudgingly, I had to transfer it to a portable board, the sharp edges were gone; the project became a mess. My project wasn’t building a 555 timer square pulse generator, but there I was trying to create a perfect one again. After many builds, I was close, but never achieved that original sharp edge. I considered cutting the breadboard in the lab, removing the section. But you know how watchful those TAs can be.

A near perfect 555 timer square wave generator. This one is from instructables. Mine… was the square of legend! (via Instructables  http://www.instructables.com/id/Audio-modulated-flyback-transformer-driver/all/?lang=de)

Since then, I’ve avoided “building projects before building my project.” It’s become somewhat of a mantra I share whenever the situation arises. Is your goal building a CNC machine, or do you want to use a CNC machine to make part? Honestly, this applies to almost every task. For me, it has never been more apparent than in the world of electronic development. Development (dev) boards and single board computers (SBCs) are a catalyst to the ultimate goal.

Starting at the end of the design chain, test-rigs are perfect candidates for off the shelf dev-boards. Typically, the dev-board is a “one-of” device, only seen behind closed doors. It can be crude, as long as it does the job. Size is rarely a concern. The rig can be the size of those envy inducing Smart Cars - it hardly matters. This is where a SBC like Raspberry Pi (R-Pi) really shines. With all the plug-n-play accessories for the R-Pi it can handle any data input/output situation. Just take all my recent R-Pi projects; it could handle flipping relays at a certain time (Scary Door), sense temperature (Project Goldie), actuate other products (Drinkmotizer), and even set off an event at a certain time (Fireworks Launcher). With it, I did not have to build and sort of circuit since it is ARM based system, figure out a way to see the reading with its built in HDMI port, worry about IO with its GPIO bank, video and microphone input, and the list goes on from there.

Project Goldie block diagram. This could almost be seen as a fish tank test-rig, monitoring all aspects of the tank. (via Project Goldie)

I remember having to build a test setup using a PIC and come relays. At first it was a breadboard nightmare of broken wires and tracks, then it was a soldering mess plagued with similar issues. Like the Three Stooges stuck in a door, I did manage to get it working; one false movement and it could fall apart.

A step back leads us to what drives a project. Like the test-rig, if a system can be any size and shape, going with anything other than a dev-board or SBC seems silly. All the heavy lifting is done for you. Case in point, all the R-Pi projects again. Not only do they perform repetitive tasks, but they are complete systems. The Drinkmotizer is the perfect example. I could get away with just using an Arduino and some input buttons. But, I wanted a LCD touchscreen, mouse and keyboard input, and a full-fledged operating system for future additions/changes.

The Drinkmotizer complete system sketch. The R-Pi is the nexus of activity. If I had to build everything there myself, I would still be working on it. (via Drinkmotizer)

(For the record, with Drinkmo, I could get away with some discrete components and touch buttons. But, where is the flash in that?)

Moving backward, we come to the most important aspect, the development environment. These devices in focus offer the “Ideal” platform. The boards come to us with the guarantee to work. Many boards, like the R-Pi and Arduino, have huge communities where almost every challenge has been tackled. Example code abounds, if you need it. On top of that, many boards come with a software development kit (SDK) not only from the manufacturer but also third parties. These are designed to make your job even easier. Not to mention manufacturer help in getting up and running is only a phone call or email away.

This reminds me of a story from my early work history. I worked at a company that made a lot of warning systems for government agencies factories, pretty much everywhere in the world. They had this audio tone module product that operated like an Atari cartridge. Slap it into a “command center” and it stored a warning sound or voice message. If it was an Atari cartridge it would be more modern. This device was far older, designed in the 60s or 70s. No one knew, since it was so old! Believe me, I asked.

The Atari game “Combat” stripped of its plastic shell showing off that edge connector. Probably one of the worst style of connectors every made. Faulty contacts were always plagued the setup. To play devils advocate, if you never remove it from the first time it is installed, you should be good forever. (via Atariage.com)

There was an analog IC on board that handled both storing the sound clip and playing it. Life was good for many decades. Then the chip was discontinued. This company bought every last one they could find on the planet Earth. Life was still good for another decade. Then the party ended. Right at the point where they only had 1000 or so left, they bring me in. I was tasked to make a whole new system. No pressure, it just had deadlines that involve the life’s blood of a company…

I went about making it digital. My solution was modern, at the time. Same form factor and cartridge connection. But, I used a microprocessor (uC) and a SD card for storing sound clips, and lots of them. I found a uC that had native sound playback features, various flash storage options and a robust SDK. What did I do? I bought the development board.

I demonstrated how it would work with the dev-board. Then I just copied all the elements I needed from the schematic, chip and SD card interface. I laid out a PCB from there with the same cartridge interface. Consulted the manufacturer and wrote some simple code to handle the task. The first batch of prototype boards worked perfectly. I dropped the engineer microphone on stage and walk off.

It doesn’t get any more clear than this… why build a project before you build your project?