There are many amazing open source hardware (OSHW) printed circuit assembly (PCA) projects available today. Arduino®, BeagleBone®, Rasperry Pi®, OpenPilot®, and RepRap® are a few of the bigger names, but there are many, many more. These projects have spurred a whole generation of makers, hackers and students to get involved with electronics and firmware.
With low cost hardware and large developer communities, many people have been exposed to one or more OSHW PCA’s. Given that experience, it makes sense to consider these boards when developing your own product. At Simplexity, we’ve used different flavors of Arduino, BeagleBone and RepRap in various product development activities. They’ve been great for cheap, rapid prototyping, but they’re not without their drawbacks. Before jumping in with OSHW, there are some points you should consider about when and how to use this technology:
IS COST THE ONLY DRIVER FOR USING OSHW?
One of the great things about OSHW projects like Arduino is that they’ve driven down the cost of microcontroller PCA’s. In fact, these community driven projects have forced the major silicon vendors to respond with their own OSHW development boards. Before Arduino, development boards for microcontrollers started at several hundred dollars. Because of the competitive pressure from Arduino (and the project’s use of Atmel processors), there are now low cost development board lines from most major silicon vendors. While they may not be OSHW, Boards like the ST Discovery,NXP Freedom and TI LaunchPad start at under $10 (less than Arduino!). If you don’t like the processor the community based OSHW project, find the processor you do like, and get the low-cost dev board that goes with it. Another great thing about these boards? Their designs tend to be open source because the vendor is trying to get their chips into your design. If board price is the only thing driving your board selection criteria, be sure you consider the new low cost development boards.
DOES THE BOARD HAVE AN ASSURANCE OF SUPPLY (AOS)?
Anyone serious about manufacturing a product knows that component assurance of supply is a significant design consideration. One great thing about OSHW is that you have access to the design files and can get the boards built yourself. The catch? The community based OSHW tend to move fast.
If you base a production design on a community OSHW board, you may find that your supply of cheap parts has disappeared in a year or two. The low board price for large projects like Arduino and BeagleBone depends on high production volume. When the community moves on to the latest and greatest, your supply of cheap board may dry up. Sure, you can produce your own boards with the OSHW designs, but at what price? Simplexity investigated the cost of producing a BeagleBoneBlack board in total volume of 500 units, and found the cost went up approximately 3X.
It’s reasonable to expect that vendor supplied boards will stay in production as long as the part on which they are based has not gone end-of-life. Your silicon vendor’s sales representative should be able to provide you with the production lifetime for a given part. Note however, that the vendor license may preclude you from shipping a development kit board in your product.
Another option is to use a commercially designed embedded controller board from a third party. Any reputable supplier of a PCA should be able to provide you a minimum production lifetime. For additional assurance, some third parties will escrow their designs so that you can get design files if the company ceases operation. This has the same cost risk as the community projects, but does make sure you have a product if your supplier goes out of business.
DOES THE BOARD HAVE ALL OF THE HARDWARE YOU NEED ON A SINGLE PCA?
To hit the lowest possible price point, designers remove all but the most critical functionality. For OSHW projects, most small use a system of daughter boards or “capes” to provide additional hardware. While capes can be great for prototyping, be careful about what you put into the field. BergStik headers are not as mechanically robust as a single PCA design. Intermittent connection issues between boards may lead to field issues that are very difficult to diagnose.
Along the same lines, your microcontroller should have all of the hardware peripherals that you need in your application. Simplexity specializes in mechatronic product development. As such, we build a lot of motion control systems. For our systems, it’s critical that our microcontrollers have hardware to handle quadrature encoder inputs. Polling or interrupting on encoder pins is simply not acceptable for a professionally developed product because missing encoder counts lead to serious motion system problems. Make sure the microcontroller on your board has the hardware resources for your design needs.
DOES THE BOARD HAVE REGULATORY CERTIFICATION?
In order to ship a product to consumers, your PCA is going to have to have regulatory agency certifications. It’s very rare for community based OSHW designs to be certified. It’s also rare for silicon vendor dev boards to offer certification. If you make changes to an OSHW design to get certified, you will likely lose the cost structure that made an OSHW design so attractive in the first place (see above). In addition, because you’ve leveraged an OSHW design, you are required to provide your changes back to the community.
If your goal is only to prototype or do basic concept validation, this may not be an issue. However, you should think about how far down the road you want to get before switching to custom hardware.
WHAT IS THE IP SITUATION?
As noted above, if you make changes to OSHW, you’re required by the open source licensing agreement to provide those changes back to the community. If you have valuable proprietary hardware designs, that may be an issue.
A more significant issue is the firmware that is used to run the board. OSHW typically comes with open source firmware, and that firmware typically requires any changes to be published. You don’t have to use the open source firmware, but it’s often the most expedient path to getting something working. If you intend to deliver a product that does not provide its source to the public, you should tread very carefully. Consider whether you should start with open source code, or start with clean IP by using commercially purchased or internally developed firmware.
Given those points, how should today’s product development engineering community use open source hardware when developing a commercial product offering? At Simplexity Product Development, we do the following:
- We use community based OSHW products for prototyping and early feasibility investigations when needed. When we do use OSHW, we do it “bare iron”. That is, we do not use open source community firmware on anything that might ship so that we avoid any IP encumbrances for our clients. We tend to use the silicon vendor hardware interface libraries, GCC and a some of our own internally developed firmware to run the hardware. Note that the silicon vendor libraries are typically usable in closed source projects as long as you run on the vendor’s chips.
- We use silicon vendor development kit hardware when we have new parts, both for microcontrollers and other parts (sensors, memories, etc.). Again, utilizing silicon vendor libraries as appropriate.
- By far the most common approach we use is to use our internally developed motion control board. As a product development company, Simplexity builds a lot of hardware for electro-mechanical products. We’ve developed our own mechatronics board that has a much larger set of hardware needed for motion control than the standard OSHW board. In addition, we have a flexible, fully featured set of internally developed firmware to run the board. This allows us to get hardware running quickly, without the introduction of IP issues. Many product companies can do something similar by leveraging modified hardware from previous products.
The OSHW community has done great things for the product development community. For professional product development engineers, the OSHW offerings are best utilized for early prototyping. Even then, it’s best to use avoid open source firmware when designing closed source product. By building your own firmware toolkit, you can leverage the best of the OSHW world without introduction IP and licensing headaches into your design.