Here is the law that applies:
Open source code is written for passion.
Company source code is written for profit.
It's silly for a company to assume the same motivations apply. In the end one can leverage all the benefits of open source but a company needs to realize that for useful and profitable products one has to invest the additional code development that work with the full product.
No sense of complaining, just be grateful for the open source and invest whatever additional is needed to make a useful product.
Just be glad the company doesn't have to pay for the development of the open source -- which would be very expensive -- if at all possible.
(Considering the narrow-mindedness of the only-profit approach.)
I agree with Russ T, example code or drivers is a must with chips getting ever more complex and manuals ever more useless. ARM chip suppliers are helping here with driver libraries, some even on chip, and have a driver interface standard between vendors even though their own driver are not allowed to be used on competitors chips :-). For some reason I still end up building systems where I use a really simple chip and write everything from scratch using my own code templates once I know how it works. I think open source has it's biggest benefit for complete OS's, ie. Android and Free RTOS etc.
I would add that often times the developer boards do not quite fit my (and maybe others' needs). Having free software and paying for hardware that is broadly targeted to a wide range of applications is nice but does not get the job done. Is robotics that much of a niche end product that no high speed, small form factor, software application rich platforms exist? I am talking about 1Ghz plus performance with SPI,CAN,Ethernet,USB, Analog IO, Digital IO etc. on a small board configuration. I continue to chase down the newer chip offerings but do not see the development boards to match.
I do look at the vendors software support before I spec in a new controller or peripheral device. Vendors who provide driver examples are much more likely to get my design win - with all other considerations being equal.
There is a lot of wasted efforts on the microcontroller vendors end when it comes to example code. Much of it is nearly worthless. they blink LEDs or poll UART RXBUFFULL register bits. Usually it is a faster to start from nothing as it is to use the example code. There are exceptions to this, but they are getting scarce. They should put out less volume, but make it more meaningful.
This si where the commercial RTOS companies provide value. They are paid for their code, so they have an incentive to make it meaningful.
The reality of the SoC business is that customers require system solutions -- hardware and software that work well together -- as a chip vendor, delivering a complete system solution is the only way you're going to sell those SoC's in volume.
You can look at it from the viewpoint that the software is free (a very hardware-centric bias) or you can recognize that you are selling a system solution, and both the chip and the software each bear part of the cost.
Either way, that software development cost is unavoidable. A chip vendor needs to have a fair amount of software available the day he has first samples of the SoC available, so customers can hit the ground running and meet their product launch schedules.
It's difficult to imagine how the IC vendors could rely on the open source community to develop device drivers for a new SoC before the chip even exists, and still meet their schedule commitments to customers to deliver working systems -- hardware & software -- with aggressive delivery dates.
To throw another view point to the mix, perhaps it is time the for-profit corporations to carve out a portion of their hardware markups (most do, to offset the cost of handing software free) and use that to actively support the open source development. I am sure a model can be worked out to strike a balance between hiring more vs. supporting OS tools. While some companies are doing this (like TI cited above), we need more to nurture OS tools.
Mark & Dave: good points... one option for early / beta version access to hardware for software developers, perhaps the hardware vendors could create a developer community that eventually releases the code to open source community?
I'd say that this is a good example of how open source can work well. It's a collaboration between Industry and individuals. A company like Ti needs the control over their own destiny that in-house programmers bring. Yet, they still turn the value created over to the open source community.
Having studied Ti's Beagleboard, this all seems to work quite well in practice. Even with the Ti software engineers, there are a large number of community developers writing software for peripherals and applications. At least in the case of the Beagleboard, Ti has found a very effective way of merging in-house and community efforts and does a very good job of supporting the open source community.
Ah....the Law of Unintended Consequences bites again! Or...No good deed goes unpunished!
Most likely it is just the cost of doing this type of business, so figure out if it can be somewhat automated if the code is that low level.
Mark makes an interesting point. Of course, they could go to a variant other than open source, but then that increases the base cost and doesn't give them the advantages of open source (which comes at it's own cost as seen here).
It's too bad that they can't somehow embrace the open source developer community to help maintain and enhance this low level code. Unfortunately they can't release the hardware itself into the open source community, but what about early versions of the interface specifications?
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.