Arduino as a rapid prototyping system
I’ve become a bit obsessed with the Arduino as a rapid prototyping system. In fact, I spoke on the subject at ESC Silicon Valley, back in July, and I’m speaking on the subject at the upcoming ESC Minneapolis. Prototyping is a natural subject for me, as I spend my days in the rapid prototyping assembly house, Screaming Circuits, but my obsession with the Arduino for prototyping goes way beyond the manufacturing angle.
At ESC Silicon Valley, I talked about, and wore, an Arduino-compatible electronic show badge (below) that I had thrown together, largely using sections of a couple of older designs. It used the core of an Arduino Leonardo, a LiPoly charging circuit from one of my robot boards, an accelerometer from my electronic business card holder, a real-time clock from my NeoPixel clock, and a TFT display that I’d never used before.
It was a last minute idea, and I spent about an hour putting the schematic sections together, and another hour and a half on the layout. It’s not my best work - a total hack job, in fact - but ended up working, with just one mod wire and one other small issue.
One of the challenges with the Arduino is that the base units are built around 8-bit microcontrollers. They are pretty handy and a lot more useful than a lot of people give them credit for, but it is easy to run out of memory or processing capability. Thus, for my next Arduino-compatible project, I looked to the ChipKIT Arduino from Digilent and Microchip. The ChipKIT uc32 Arduino-compatible is based on an 80 MHz, 32-bit MIPs architecture MCU from Microchip, with 512K FLASH and 32K SRAM. That’s a big step up from the 8-bit, 16MHz, 32K FLASH, 2.5K SRAM microcontroller in the Arduino Leonardo.
The PIC32MX340F512H in the ChipKIT has ample capability over and above the standard Arduino. It also runs at 3.3 volts, which would have helped with the “other small issue” I had with the badge: The accelerometer I used was a 3.3 volt part, and the battery charger/management chip can output up to 4.5 volts. Pop went the accelerometer.
The new board took a little longer than the 2.5 hours that I spent on the first badge. I don’t have a lot of 32-bit design experience, so I spent more time reading datasheets and self-educating myself on the ChipKIT design. In total, it was about two weekends worth of design, layout, and parts finding time, with one of those days being used mostly for design review.
For the most part, the problems I found in my design review matched pretty closely to the manufacturability issues that pop up most often back at the shop with customer boards. I had a number of parts with the wrong footprint, and a few with the right footprint on the board but the wrong part package variant in the bill-of-materials (BOM). I also found an unconnected pull-up resistor on one of the switches. Ironically, that’s the same problem that led to the mod wire on my original electronic badge.
One of the downsides of basing a design on open source is that you don’t have the tribal knowledge that went into the design decisions. There are a few places where the design deviates from the chip datasheet recommendations. That’s not uncommon, but without the water-cooler discussions and o-scope time that went into the original board, I don’t know why those changes were made. I’d rather understand what I’m building than just run on blind faith.
This won’t be a home-built project. Since I’m having my company build it, I can use QFN (quad flatpack, no leads) packaged chips when possible. If you aren’t familiar with the package, a QFN is usually a square part, with pads underneath on all four (Q-quad), or two (D-Dual) sides. With a QFP (quad flatpack), you can see the leads sticking out on four side. With the QFN, you can’t because the “leads” are just pads under the part. It’s the same for an SSOP package vs a DFN package.
The chips in the image below are all identical Atmega32u4 MCUs. The two on the top are in QFP packages, and the two on the bottom, QFN. On the left side, the top is showing, and the underside on the right.
The MCU and the FDTI USB to UART chip both have QFN packages available. The Microchip MCP73833 LiPoly battery chip comes in a tiny DFN, but that variant seems to be out of stock a lot, so I used the slightly bigger MSOP packaged part. Most of the passives are in 0402 packages. 0201s would be fine too, but they tend to cost a bit more and real estate isn’t that tight.
While I did download the open source Eagle CAD schematic and board files from Digilent, I didn’t start with those files. I started with my old badge design as a point of departure, ripping out what I didn’t need. The original ChipKIT Arduino uses a QFP packaged MCU, and I wanted to use the smaller QFN. To do so, I went to SnapEDA.com, a repository of footprints, symbols, and such, and found the footprint and symbol for Eagle. I could have made my own component, but 64 pin chips are a pain. Doing so would have added several additional hours, and introduced a lot more opportunity for error. As it was, it took about a minute to search, find, and download the part.
The next step is to get some prototypes built up and hope that I didn’t cross any wires or leave any unconnected. This is where it comes in quite handy to work where I do. I ordered up PC boards from Sunstone Circuits with a one-day turn and assembly from my shop on a 48 hour turn. I added parts to the order as well to keep it all together.
Once I’ve proven my design, I’m going to look at a bit of cost reduction. The FTDI chip used in the ChipKIT costs a little over $4.00 in small quantities. FTDI has one that’s smaller and costs half that, which I want to try. The board has 12 MOSFETs used for controlling LEDs. They aren’t too expensive, but with that many, I could save a few dollars with a less expensive part. I already use as many resistor networks as I can. That reduces part count, which reduces manufacturing cost (which isn’t actually relevant to me in this case). I also kept all of the surface mount parts on one side -- again, a way to save a bit on manufacturing cost.
As soon as I get the boards back, I’ll get to take advantage of one of the biggest Arduino-based time savers. I can upload the ChipKIT Arduino bootloader and get to programming right away. I don’t have to learn any of the intricacies and idiosyncrasies of the PIC32 micrcontroller. I will get to that later, but I can prove the hardware first and isolate hardware from software problems.