Real-Prototyping World

There’s something to be said about the difference between designing your system on an evaluation board compared to designing it using the board on which your system is actually going to ship.
 
One of the problems with using an evaluation board is that it’s a really nice environment to work in. Too nice, in some respects. The processor company wants you to have a positive experience with their chip so the eval board has all the bells and whistles. You can get everything up and going super quick and see that yes, the chip can do what you want it to do.
 

 
What you don’t get is a realistic perspective of how well the processor is going to perform. Consider that power efficiency is a major concern for many applications. Eval boards usually have a lot more stuff on them than you’ll need in your final application. For example, there are peripherals that have been configured which you may not be using and which haven’t powered down. So yes, while you can get an idea of whether the processor will perform sufficiently (i.e., throughput, speed, power efficiency, etc.), you don’t really know how well it will perform.
 
This is especially true when you are going to use significantly different components (e.g. sensors, wireless connection, memory, etc.) than are supplied on the eval board. The challenge isn’t whether you’ll get the evaluation board to perform to spec. It’s whether the code you’ve written will give you anywhere near the same results on the board your customers are going to receive.
 
That’s where a prototype is much more useful. When you design on a board that is the same or relatively close to the final board you are going to use, you can see how quickly you’re consuming processing cycles, memory, and power. This can be quite helpful when you’ve cranked out the “first draft” of a system. That’s the proof-of-concept code, the code that gives you the confidence that you’re going to be able to do what you envision. The code has been thought-out but not perfectly crafted and optimized, yet. You’ll see how much of that you need to do once you bring the system up.
 
When you make this assessment with a board close to the one you’ll be going to market with, you get a much better idea of how much more work you’ve got left to do. A real-world board gives you real-world numbers. These can be extremely useful to have before you make critical design decisions. You also get this data early in the design process when it’s a lot easier to change processors if you need more (or less) than the one you’ve been prototyping with.
 
Getting hold of a production-level prototype is easier than you might think. For example, Upverter, a customized module design from Gumstix, enables you to drag-and-drop blocks of functionality into a project. You can start with a foundation built on a proven architecture such as Arduino or Raspberry Pi. Then you add the capabilities your system needs. The board comes with the OS, firmware, and drivers you need to immediately bring the board up.
 
With the initial design in place, you can then have a handful of boards built in a short time, enabling your software team to develop on the board that is likely very close to the board you will ship with. If you discover any issues during design, you can easily modify the board and get another set of boards.
 
The key here is that, from the beginning, the software team knows what they have to work with. You get all the surprises right away, not after you think you’ve completed the code. The result is faster design and faster time-to-market.
 
Take a look at some Gumstix customer success stories or contact Gumstix today to learn more about their products, design tools, and services. Or try out Upverter, their customized module design tool, for yourself.