Only a spoilsport would say so, but contrary to widespread belief devkits and single-boards, while useful, are not the Holy Grail that the time-strapped design engineer is searching for. And while it is true that they have become an important part of the design process for electronic systems, they come with some potential baggage that we will talk about shortly. The problem (in most cases) isn’t conceptual. Like reference designs, devkits and single-boards can make it much easier for designers to solve some of their challenges and evaluate parts they need; the key benefit being that the engineer won't have to do everything from scratch.
My esteemed colleague Cabe Atwell, discussing the good side of these tools in his blog “Single-board computers are a game changer” argues that he tries to avoid “building projects before building my project.” He notes that “development boards and single board computers are (just) a catalyst to the ultimate goal “and he would rather use a Raspberry Pi or similar SBC with lots of plug-n-play accessories than build what he calls a “one-of” single purpose prototyping device.
He’ right, of course, and I could not agree more, but here’s why I inserted the qualifier “in most cases” two paragraphs above: Cabe’s correct if we are talking about single-board computers aimed at the hobbyist or educational market, such as the Raspberry Pi, BeagleBoard or Arduino. But if you are a practicing engineer, with circuits or systems to design with the intent of manufacturing a product to be sold in the commercial world in large numbers, these SBCs were never intended for such use.
Don’t get me wrong. I love the Raspberry Pi, that a wonderful little computer that measures just 3 inches by 2 inches by less than an inch high, created initially to replace the expensive computers in school science labs and one which packs enough power to, for instance, run a home media center using its graphics chip to stream video and photos to a big-screen TV.
But these are hobbyist boards and they shouldn’t be expected to adhere to the same high standards as a kit suppliers offer to help you design a fully commercialized product. That being part of a commercial design chain was never intended for these SBCs is very clear. Let me quote from the BeagleBone Black System Reference Manual (the underscore is mine):
“The BeagleBone Black is designed to address the Open Source Community, early adopters, and anyone interested in a low cost ARM Cortex-A8 based processor. It has been equipped with a minimum set of features to allow the user to experience the power of the processor and is not intended as a full development platform as many of the features and interfaces supplied by the processor are not accessible from the BeagleBoneBlack via onboard support of some interfaces. It is not a complete product designed to do any particular function. It is a foundation for experimentation and learning how to program the processor and to access the peripherals by the creation of your own software and hardware “
- Fig. 1 Ti offers both (top) the CC2530DK development kit supporting its second generation 2.4GHz IEEE 802.15.4 compliant System-on-Chip, containing all hardware, software, and tools necessary to build a 802.15.4-compliant product and (bottom) the marvelous little BeagleBone Black SBC. While both are great at what they do engineers are more likely to use the former from 9 to 5 and the latter from 5 to 9.
Even devkits and SBCs with aspiration to be concept-testers in a commercial product design chain have issues, although here the problem is often one of execution, or rather one of a less than desirable execution. As one-time give-away items for chip companies to show off their latest components, dev kits have matured into test beds for software development and prototype or proof-of-concept designs. But in the doing a concern has emerged that the evaluation kit either has flaws or cannot meet the exact needs of the design engineer. I’ m reminded of something Tampa Bay Buccaneer head football coach John McKay once said. Following a loss coach McKay was asked what he thought of his team's "execution." He is reported to have replied, "I'm all for it."
There is definitely a down side for the engineer who relies too heavily on devkits and SBCs. Here’s why:
Engineers require sufficient information about how best to use a part. To do so, they need to determine to the point of exhaustion what is actually going on with a part so as to properly use it in a design project. Manufacturers and/or third parties make things easier by providing a wide variety of dev kit options. Some packages are executable demos, which cannot be modified; some are trial versions, which come with software (or links to a library) as well as perhaps a sample project for the IDE that has been used. Most kits enable engineers to evaluate code, do software development or even develop and debug a small design with much less cost and complexity than a full-fledged development board would require.
In this effort the semiconductor vendor’s task should be to completely describe the functionality and behavior of the device, and also provide the settings of peripherals used (if applicable) and the electrical and packaging specifications of the device. But raw details on functionality and setup cannot by itself inform a designer how to best use a feature in an actual application, which is important since most designs continue to be application-driven.
To be valuable to an engineer a devkit or SBC should be accompanied by detailed support material containing a schematic, a bill of materials including supplier and part numbers for all components and a thorough, functional description as well as all of the formulas and design procedures used to determine the component values used in the circuit--all to help enable the engineer to adapt the design to his/her own needs. Kits also should include a CD or flash drive with self-running tutorials and application examples that highlight the features and capabilities of the part or family of parts and its supporting tools.
Documentation is critical. And so is the manner in which that documentation is presented. Too often if a user’s guide is provided at all, it is either too simplistic or contains errors.
Ask yourself: how often are sufficient support materials included with a devkit/SBC, especially if it has been designed to carry either a very low cost price tag or in fact is free? In many cases the supplier clearly wants to make certain cost will not be an obstacle to anyone (students and hobbyists included) who wants to evaluate or develop its parts. Low cost is also important so that if an engineer has to throw away non-functional prototypes it doesn’t cause his or her company financial grief. But to drive the cost down often the first thing that goes is support materials.
Moreover, there are other shortcomings to watch out for, any of which could result in a frustrated engineer. In some cases, the experience can be so bad that the low cost kit will be discarded before the evaluation is finished.
Among common problems:
- Setup and startup instructions are unclear or incomplete. Installation procedures are clumsy and heavily laden with mouse clicks and incorrect or questionable user inputs. Software tools failed to install correctly.
- The hardware didn’t operate correctly or required additional components (such as a power supply and cables).
- Hardware and software components failed to play well with one another.
- Hardware was overly simple, or unnecessarily complex, for assessing the target part. In the case of Raspberry Pi since the board does not come with an included micro-USB cable to supply power, you must obtain one. Additionally, the Raspberry Pi does not come with a pre-installed operating system or on-board storage.
- There was no explanation of the IDE and/or toolchain, despite the fact that their operation wasn’t nearly as intuitive as might be expected , creating delays.
- Example code and projects (when supplied) were remedial and provided little insight into device and tool performance and capabilities. Development kits need to provide easy-to-follow, non-trivial examples to show engineers how to quickly accomplish the ordinary details of what they need to do, such as establishing USB and Ethernet communication, setting up timers and interrupts, etc.
- It was necessary to call the device manufacturer for help before getting the kit’s system board to work
- SDKs may have licenses that make them unsuitable for creating software intended to be developed under another, incompatible license. A proprietary SDK, for instance, may be incompatible with free software development, while a licensed SDK could be incompatible with proprietary software development.
So, in conclusion, we’re not saying don’t use devkits or SBCs. But we are suggesting that you keep in mind that they should not be viewed as easy, breezy substitutes for a good, old-fashioned design effort.
Top Comments