The Raspberry Pi is not open source hardware. OSHW offers schematics, software, everything that is printable is free to use as you like. But the RPi has a copyright notice on it's schematics. RPi is accessible via a low price. And it's popular with educators. But it's not near to being OSHW like Arduino, Launchpad, Beagleboard, and even the Intel Galileos & Edison products.
Yes, open source started with Linux in the user space, then migrated to embedded because it was royalty free and maintained by an army of altruistic engineers and computer scientists. (Even with out a college degree, I would call ANYONE that is trusted to contribute as having earned the title.)
Open source hardware is another realm from SW, but only because you can't sustain a free HW model...but you can minimize the cost as much as possible and at least make the HW accessible. As for open source in general, there is an open source beehives movement, open source text books, and open source customer relationship management packages. (Just to name a few.) These are products that are free to use, but true open source offers the user the ability to improve the product, sell it for profit, and contribute back to the source via community. Open source taps the original scientific concept of sharing intelligence via publishing without patent. The Henrietta Lacks story. The HeLa cells were groundbreaking, and like sour dough starter, given away freely and without patents on the cells. This is what open source is opening: a veritable reinassance in the sharing of ideas without fear of reprisal via courts and capitalism. - LR
It seems this article is somewhat confused about Open Source. Stallman defined the GNU license in the way that he did to ensure that there was a contribution by users and his definition was that Open Source should be analagous to freedom of speach not free beer. To take this and say that now open source means free but you should contribute is certainly far different.
Second, with all the inexpensive hardware and sensors avabilable and freely available operating systems with abundant communications protocol and sensor support, it seems that users don't really have to have a degree in engineering. They can plug things together and simply run an OS and focus on applications programming. Although somewhat more difficult than programming on Windows, if you choose something based on open standards the challenges are more in assembly and OS configuration. Developing product prototypes should be easy already for those that have done their homework.
The real issues come up as product developers try and transition from their crude prototype to a commercial product. Here all the cheap and chearful approaches disinigrate. Here a real product development environment and real engineering skills are required. You can reuse some of the hardware design but BOM optimization is required as is real commerical quality software with things like: security, good performance, testing of protocols in many situations, broad hardware support to ensure choices and extensive testing among other things. Here the educated and business wise seek commercial solutions to reduce time to market and maximize the probability of success.
By way of full disclosure, we offer the Unison RTOS, an MCU focused operating system that is completely free for development and has commercial licenses availble for production. And by Stallman's definition, Unison is open source.
Ah yes the Papilio looked quite awesome! Also if you already have a Raspberry Pi there is the LOGI Pi that was on Kickstarter.
About the IP issue, yes more IP needs to be available for free (at least for non-commercial use). There is already OpenCores and similar sites, which work fine, but as @alex_m1 points out it is much easier to reuse IP that is described at a higher level. Think about easy it is to reuse a module in Node.js versus integrating a library in C on several supported platforms and different toolsets. This is what we're aiming at.
Yes chip design companies are generally big companies, but it doesn't mean that it has to be this way. Smaller companies are generally much more agile and innovative, and small companies do in fact manage to produce their own chips, just ask Andreas Olofsson of Adapteva :-) But yes taping out your own chip is far from frictionless though, I'm pretty sure this can be improved.
Just a precision that I think is relevant, especially in the context of libraries (as you say peripherals etc), it's important to have something that can be used by the community. Commercial HLS tools support their own proprietary, mutually incompatible versions of C/C++ and SystemC :-( That pretty much guarantees fragmentation of the community.
On Kickstarter/Indiegogo: I think it's important to look at ALL projects in a field, not just a couple. Sure, a couple do real well, but many have a tough time reaching even modest goals (for example, Max could relate the story about his Magnificient Galactic Arduino break out shield). In many cases, I think backers like to see a history of success before investing.
For example, one sucessful Kickstarter FPGA project is the Papilio Duo (yes, I am looking forward to getting mine). Note that the Duo comes from an established designer, with an existing community -- and has a lot of tools to make working with FPGA's easier (such as Arduino compatibility, Jack's DesignLab IDE, and a variety of Wings).
Another issue with FPGAs (or ASICs) is IP. When you buy a MCU, IP like CAN, Ethernet, and USB is already paid for. But if I add these to my own FPGA, it's my responsibility (in the case of CAN, I believe Bosch wants $2000, which is pretty reasonable, but still a significant chunk of change for a small project).
And given the power of small, affordable boards such as the RPi (now starting at $20), BeagleBone Black ($55, but with 1GHz CPU + dual 200MHz PRU's), I think most people will take the path of least resistance, and stick to regular programming (especially with the wealth of resources already available for Linux on ARM). (Another interesting approach: take a RPi and add-on a $15 XMOS starterKit).
First let me say i like the psoc, it's a nice family.
But for those who want a mcu+fpga based solution, using mcu+ cheap fpga could offer much better performance(200mhz cortex-m4 vs 67 mhz cortex-m3 in psoc, options for m4 fpu), better software support(more rtos's ,mbed/arduino support,vendor firmware support), and far cheaper price(maybe even 1/4 of a psoc based solution in some cases), portabiliy, versatility(combine whatever mcu with whatever fpga), and like you say, more FPGA cells.
BTW if there's a community that shares hls code for peripherials and such, you reduce the barriers for using your platform considerably - just copy some code, maybe change some minor detials and use the tool to compile. this is is always good for adoption.
As for chip design, i would imagine Chip design companies prefer to buy tools from big companies, even if they cost a lot. But for xilinx/altera , low price high level tools sure do sound attractive.
And in general - even with things like hls and easic, i get the notion that chip design is mostly a big company playfield.
Good point about projects and fast development, I agree.
Actually what you describe reminds me of what Cypress does with their PSoC, a microcontroller that includes programmable analog and programmable logic (although they're very careful not calling that FPGA but UDB - Universal Digital Block, I'm not sure why). From what their documentation states the amount of logic available seems a bit limited, but regardless you could very well design it with Cx.
I think that this kind of chip is very interesting, like a miniature version of the Intel Xeon + Altera FPGA or ARM Cortex + Xilinx FPGA. Another thing that I think has a lot of potential is eASIC-like technology, between FPGA and ASIC. The thing is, once you remove the obstacles and make IC design easy, who knows what can happen?
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.