Developing a FOSS / Linux friendly embedded hardware - component selection

Neng-Yu 'Tony' Tu

Hardware component selection seems like a easy job after people have google and digikey. But in real world, lots reason that make googled/digikey search result dose not mean it could be used in the mass production product. Mostly is not technical reason, but sourcing/SCM reason. Component sourcing/SCM (supply chain management) is one of the critical issue that will affect your design could go into real mass production or not.

Following are some aspect was considered during component selection process.

* Business relation:
Module vendor/chipset vendor always put business (either real money or just marketing) as first priority. Usually vendor or distributor will spent FAE/RD/support resource at confirmed customer, so it's not only about your money while you using their products into yours but also their money as well. Most hardware vendor need forecast required material quantities to
drive their upstream supply chain as well. We take LCM (LCD module) as example, if you buy module from vendor, they need to prepare:

* Flex print circuit cable
* LCM frame parts
* LCD Controller IC
* Touch panel controller chips and glass
* Many small components
* Negotiates with their factory in order assemble/delivery in time

Sometimes hardware providers will concern about of losing trading secrets/expose bugs with "open source" device. You have to clearly define about delivery target, what could release and what couldn't release to end customer, including:

* What is hardware delivery item/firmware version?
* Who should finish driver to specific firmware version?
* Documentation/source under what type license
* How to co-work on missing delivery? (Like GPL'ed version driver and re-distributable documentation).

All above will be continuous process during project period.

* Specification: Sometimes online chipset/module manuals/specifications are not updated one (or in-correct/non-function), especially those not release through official web site. There are some components I called: paper components, means not put into mass production yet or only vendor want to test the market response. Also, you have to understand specification very
well, because you also have setup acceptance standard/rules during whole process. Most embedded hardware won't fulfill every specification at design stage (durability/sensitivity/environmental tolerance/may others), you have to negotiate/track along the way.

Some vendor don't have linux friendly policy, you might not get source code of driver/testing tool. You may need to develop your own version, and find a way verify the specification before your linux driver ready.

* Unique/hard to source parts: If you using component that very unique in specification (like special cap value or fancy function). And this component could help RD simplify design or make life easier. For most developer, make mass production is not their responsibility, design good product is. Tricky part is: in many cases, using hard to source part will cause lots sourcing/logistic over head later (lead-time), and you might need to postpone whole production because of single component that seems harmless at design stage. You have to be very careful using unique/hard to source part if really want make a mass production-able device.

Some companies like using unique part as a lock (like own design function chip) to protect product, or using it as tool (like their own variation of PMU) to simplify later product design/verification cycle.

* EOL (end of life): Just like your cellar phone, electronics device chip life cycle is not long as you think. Most manufacture using the same part that "popular" device used, if "popular" device phase out (usually less than 1.5 years), sometimes component lead time will dramatically increase, because vendor will manufacture the part for you instead of moving stock around market. You your product design -> mass production period is too long (over 1 year), you must be very careful track your original deign-in part EOL date or specification change. Sometimes, you never get updated until you place next order. EOL is killer for hardware verification, for software need to have another round of test plan/driver parameter adjustment.

Some experienced people might ask: why so many industrial devices could grantee over 5 years or longer availability/replacement, answer is easy: they buy more as stock and sale product in higher price. So when manufacture stop fabricate component, they could still have on stock.

* Price: Including payment term/delivery method/tax. You could not get good price with reasonable quantities. This issue has nothing to do with software ;) but for PM, might need to keep an eye on it.

* Technical support: Most chipset/module will assign technical (FAE) and sales contact window after business cooperation. You may ask support from technical contact, usually including:

* Hardware testing/verification support
* Driver required document (may not release to public, but release to you as reference)
* Source code that under GPL license (or co-work develop one)
* Co-work on product development schedule (firmware
release/test/verification/bugfix/function add...etc)

Most of time component vendor only have driver to specific linux version (usually not updated one), and may use some strange rootfs combination. You have to double check what is "We have linux driver" means with FAE.

Component must have at least one of following charactics that makes it community/developer friendly component :)

* Full documentation, release in creative commons or re-distributable license, accessible from public Internet web site

* GPL'ed driver source, and driver already in upstream linux kernel tree is best

What is not acceptable is: binary driver and all documenation (user manual/datasheet/etc) under NDA, that developer could not easily track source and debug it. Sometimes vendor will only provide compilied/kernel specific driver, this is not acceptable format to FOSS developer.