Freemor wrote: > Again the problem here is not only the choice of free software > but free hardware. Wifi chip makers simply refuse to disclose how > their chips work. Thus the reason no non inclusion.
Particularly with the compact chips for small mobile devices like the NanoNote. The situation appears to be better with large chips, suitable for laptops, routers, and such, but that doesn't really help us. Even if the chip's programming interface is disclosed, this doesn't mean that it's really open. E.g., it may require a closed binary firmware. Even if you accept this on philosophical grounds, you still have the added inconvenience of dealing with it (e.g., you need to set up your system to load the firmware, you may not be allowed to include it as a package in your distribution, and so on). Worse, such firmware may have bugs that you can't fix. And the manufacturer may decide not to fix them, e.g., because they'd rather have you buy their new chips. Besides, you may be too small to matter to them. (I'm not making this up. I've lived through this situation at Openmoko, not so long ago.) Speaking of small, there's the next obstacle: if the chip is considered "hot", they may be selective to whom they sell and who gets access to the documentation you need to integrate the chip in your hardware design. Some chips may only be available to small customers in the form of modules, which impose a certain form factor on you. And you also have a more fragmented market and thus an increased risk that the maker of the module you're using goes out of business or just stops making the product. Some chips may be available even to small customers on the grey market. That happens with a lot of chips where the official channels only deal with big customers, but where these sell surplus stock to distributors. This creates yet another set of interesting issues on the sourcing side, including uncertain availability in the kind of volume we operate in, often ambiguous labeling (is that XYZ12345A3F97 they list really the same as the XYZ12345A you're using ? Or could it be perhaps some customer variant ?), uncertain handling conditions (e.g., some chips are sensitive to moisture and other things), and even the risk of getting fake chips. "Fake chips ?" you may ask. Surely this is something only the paranoid worry about. Well, there's a recent example right from Milkymist: http://en.qi-hardware.com/wiki/File:M1_rc3_0x37_u20s_mark_is_faked.png These are simple buffers (74LVC1G17), costing a few cents. Even with such trivial things there seems to be a margin for the crooks ... WLAN is becoming more and more a commodity also on small devices. Once the gold rush is over, we may well be able to find chips that suit our needs. But for now, this still isn't a technology that's compatible with what we need and what we are. > If I recall correctly Bluetooth is a more free option but a nightmare > to implement (unless tou do like everyone else and use the Bluez stack) Last time I checked, BT still had the issue that the chips you could get came with insufficient documentation to actually be able to make use of them. I'm also not so sure about the future of BT. It seems that most devices that have BT now also get WLAN, so BT as may disappear as a standalone technology, either because applications migrate to the less obscure WLAN or because BT simply gets merged with WLAN on the same chip. > I personally am very impressed with the work being done on the ATBEN/ATUSB Thanks ! :) - Werner _______________________________________________ Qi Hardware Discussion List Mail to list (members only): [email protected] Subscribe or Unsubscribe: http://lists.en.qi-hardware.com/mailman/listinfo/discussion
