I wish we had standard hardware-software interfaces -- mandatory by law for consumer electronics -- for all significant components (what is understood by "devices") of computing platforms used for general public, as we have today (to varying extents) for USB host controllers, Ethernet PHYs etc.
The typical counter-argument here is that standardizing would stifle innovation (and possibly hit performance), but is that still as impacting as it sounds? For once, innovation seems to have moved to "rear ends" of the devices, and secondly, given the amount of firmware that goes into all sorts of devices these days, any reasonably complex translation doesn't look so penalizing anymore?
One reason that GSM took over the world was because the initial standard defined not just the over the air interface, but the interfaces between all the individual components in the ground network. The point being so you could mix Ericsson base stations with a Nokia controller, and in that way it increased competition between the equipment manufacturers since they had no lock-in.
Just look at printers: They all speak PostScript/PCL or GDI, and haven't seen a single innovation in at least 15 years. Yet somehow, printer drivers are still the single worst piece of software you're likely going to see.
Hmm... guess I was downvoted for "mandatory by law".
I am not in favor of using law here either, that was more a cry of the heart -- I've been spending what seems like entire life on driver development, which is no rocket science in itself but made complex by hardware vendors concealing unimportant information (often for not good reasons, like corporate culture), for so long time that product makers have learned to not even look for it anymore.
I'm not sure. The datasheets contain pin-out and hardware interfacing information.
But apparently missing is information on how to program the internal registers, how to Tx and Rx data and wireless management information, which is probably what the Broadcom drivers require to manage the chips.
Basically, the internals of the chips still look like a 'black-box' to the drivers.
It's not actually that uncommon to see minimal datasheets on some types of consumer type IC's. Getting the full documentation and software needed then requires signing an NDA and spending anywhere from a few hundred to to a few thousand for a development kit.
Some of this is because the manufacturer considers the information to be proprietary and also because they not setup to support large numbers design teams. Some IC's especially early revisions are buggy and poorly documented so a lot of hand holding is needed[1].
[1] Think of a buggy piece of silicon where you need to implement a number of work around's in firmware. And where each customer invariably runs into an errata you didn't know about.
>requires signing an NDA and spending anywhere from a few hundred to to a few thousand for a development kit.
>Some of this is because the manufacturer considers the information to be proprietary and also because they not setup to support large numbers design teams
No, it is what is called a pain sales tactic. You make a person to go through big pain, spend lots of resources just to get a devkit, so they would not be inclined to throw it out midproject because it sucks
That is true. But for WiFi chips, some of that initial development cost can be bypassed as they usually operate over a SDIO interface, which is a generic interface and compatible with most microcontrollers with a SDIO controller.
So you can usually just get the WiFi chip (for example, Broadcom or Marvell) on a SDCard form-factor extender, plug it into your standard SD Card slot and work on it with the SDIO controller on your development board.
Note: the SD interface controller must support SDIO and not just the memory SD-Card portion of the spec.
But, of course, you still need the development documentation and internal chip information. That, unfortunately, must still be paid for.
Every time I do a fresh install of Debian on my laptop, I whip out the Ethernet cable and do the strange, hour-long dance of installing and uninstalling broadcom-sta-common while modprobing various kernel modules until my wifi works.
Because well ... Broadcom drivers suck.