There are way too many choices available out there. There are a number of conventional benchmarking factors that we all use in sorting through the alternatives. These include: the capabilities of the target controller (speed, power consumption, on-chip peripherals), available features (with memory being the major consideration, supported communication protocols), on-board peripherals and technical support (compiler toolchain, sample applications) from the vendor.
But in addition, I feel there are a number of other considerations that should really drive us while looking at development boards. Here are a few of them:
Open designs matter
List any popular development boards which have been registering an active user community, timely enhancements, hundreds of developers working towards porting new applications to the board.
One common feature that binds all such products, be it the Beagleboard or the CMUcam or the artistic arduino, is that their designs are open and available. Basically if its a development board it cannot be closed source. If it is, its like defeating the purpose in the first place.
Vendors employing such closed source policies cite plagiarism as their primary fear. However the truth is that this openness is seldom used to replicate a board.
In most cases these open designs are used as reference designs which have a more value-added entity built on top of it. After all, why would users of such boards want to rebuild them? When a large group of users do realize this need, it's time for the board itself to undergo a revision.
I believe open-ness in a design has got more to do with the mental satisfaction of the buyer. Whether you plan to build your own board post using an open source hardware is secondary, who would want to buy from an insecure source, insecure of designs being aped, insecure of facing critical peer reviews / comments on their designs, insecure of Chinese manufacturers coming up with dirt cheap alternatives.
One such path breaking philosophy surrounds Arduino's business model.
The Arduino team has created a company based on giving everything away. On its Web site, it posts all its trade secrets for anyone to take — all the schematics, design files, and software for the Arduino board. Download them and you can manufacture an Arduino yourself; there are no patents. You can send the plans off to a Chinese factory, mass-produce the circuit boards, and sell them yourself — pocketing the profit without paying the team a penny in royalties.
They won't sue you. Actually, they are sort of hoping you'll do it. That's because the Arduino board is a piece of open source hardware, free for anyone to use, modify, or sell. Banzi and his team have spent precious billable hours making the thing, and they sell it themselves for a small profit — while allowing anyone else to do the same.
They're not alone in this experiment. In a loosely coordinated movement, dozens of hardware inventors around the world have begun to freely publish their specs. Banzi admits that the concept does sound insane.
After all, Arduino assumes a lot of risk; the group spends thousands of dollars to make a batch of boards. "If you publish all your files, in one sense, you're inviting the competition to come and kill you," he says, shrugging. (Courtesy:Wired Magazine ).
An answer to this is, "It doesn't matter anymore whether your product is open source. Someone in another country (did I say China??) is going to open it up and reverse-engineer it anyway." So, how does one sustain in this volatility? How was the Arduino team still able to sell over 50,000 units in two years?
"Basically, what we have is the brand," says Tom Igoe, an associate professor at the Interactive Telecommunications Program at New York University, who joined Arduino in 2005. "And brand matters." Last year, Arduino noticed that copycat versions of its board made in China and Taiwan were being sold online. Yet sales through the main Arduino store were still increasing dramatically. Why? Partly because many chinese knockoffs were poor quality, rife with soldering errors and flimsy pin connections. The competition created a larger market but also ensured that the original makers stayed a generation ahead of the cheap imitations. Merely having the specs for a product doesn't mean a copycat will make a quality item. That takes skill, and the Arduino team understood its device better than just about anyone else. "So the copycats can actually turn out to be good for our business," Igoe says.(Courtesy:Wired Magazine).
Looks matter
Steve Jobs once said, "I don't need engineers. I need artists." What's a product that's low on looks, usability and visual appeal? Art has often been an ignored entity while designing evaluation boards. The other day while I was working with the beagleboard at home, its aesthetics suddenly attracted my siblings (non-tech people), who started enquiring what this new gizmo was.
I strongly believe that sophisticated looks and smart finishing do contribute to mass appeal even for a product meant for a technical audience. After all, if the board is going to be your companion, you would rather keep scary-looking things away.
Clarity on user segment/intended apps matter
Very often than not, I have also noticed people stuffing development boards with anything and everything since its not too clear what the hardware is meant to do and what sort of audience does it cater to.
This is a direct contributor to the fact that most companies are unable to come-up with cost effective hardware.
Moreover, I recently also came across a platform which was being publicised by the vendor as a development board for Image/video processing. Unfortunately, we also bought this board unaware of the real computational capabilities of the board.
On further benchmarking, we found that it took more than a minute to execute a simple blurring operation which is one of the most preliminary operation in image processing.
The vendor when asked for justification on how he could categorise this as a image/video processing platform, justified saying, "Sir, the controller has an image sensor interface".
Sales guys are going to be dumb (no offence intended), so make sure you interact with some technical member on the vendor side and make him responsible for recommending you the development board for your intended purpose.
Support matters
Come what may, a bunch of highly paid talented intellectuals hired by a firm to provide support for products can rarely compete an exponentially increasing highly passionate user community sharing information and ideas, day and night on forums, IRCs and mailing lists.
Avoid premature optimization
Surprisingly, this rule applies not just to programming but even out here. I would strongly recommend that optimization is something that you should keep back for the end product. Avoiding premature optimisation doesn't mean that you buy a multi-core platform for requirements that can be fulfilled by 8-bit platforms.
It is very common for the project scope to be refined or redefined at every stage of your project. Although we study waterfall model for project development, iterative model is what prevails in the real world.
In the same project discussed above, we started off with a very simple scope of capturing an image, processing it and saving it to an SD/MMC card. With this at hand we decided not to opt for an OS/RTOS.
Over a period of time, the client decided to give more flexibility in the product by allowing images to be saved onto a USB stick as well as a remote server.
More features like audio acquisition were added which compelled us to have an OS/RTOS running which fortunately was supported by the procured development board. The board, thankfully, was also able to accommodate a change in the camera sensor interface (from I2C + Parallel to a USB full speed interface). All this can be directly attributed to the fact that we kept a lot of related options open while freezing the development board instead of trying to optimize prematurely.
Consideration of the above factors, I think, should make your efforts in choosing a development board a pleasant one-time process instead of an iterative (read frustrating) one.
Saurabh Gandhi works as a Senior Member of Technical Staff in the Embedded Division of ThinkLABS (TRI Technosolutions Pvt. Ltd.). His scope of work includes working on embedded technologies mostly on the application side requiring domain expertise in image processing and machine vision based algorithms. In his leisure time he is also involved in administration and maintenance of project uNiBoard v1.1, an open source development platform for Embedded and Real Time Systems Programming.