RPi use cases explained

Here is my take on this odd situation.  There are several needs and types of stakeholders in the Pi ecosystem:

• Conceptual need in EE.  Eben Upton has many times related the problems he experienced while doing student recruitment  at university, where each year's intake candidates were seemingly  less technically experienced than the last.  I can well believe that, because we saw exactly that same problem in my own engineering department, to the point where we had to provide catch-up courses to bring part of the student intake up to the level where they could  understand basic 1st-year EE lectures.  Making very cheap hardware available that encourages experimentation by inquisitive youngsters does seem to address part of the problem squarely by fostering interest and offering direct experience with hardware.  However, it doesn't address the gap in mathematics and foundational science skills.

• Improving IT education.  The UK has a specific problem in school-level IT education, in that over time it became nothing more than vocational training in office skills.  Clearly there is much room for improvement there, but this is almost entirely unrelated to the skills shortage observed in EE recruitment.  CompSci departments might benefit a little if programming were taught in schools, but not a lot because lack of programming skills is not the bottleneck,  Stronger maths skills would be vastly more useful than programming knowledge, and would help EE as much as every other branch of engineering and the physical sciences.  Also, programming is almost always vocational training with just a smidgeon of CompSci education acquired by osmosis on the side, and very rapidly becomes dated.  To compound matters further, a high-level language with a lot of abstraction would tend to be chosen for programming education, which means that pupils would tend to learn little about computer fundamentals unless they have an awesome teacher who explains the foundations along with the programming.

• Cheap media centre.  Don't laugh, this is a major stakeholder group for Pi.  What's more, RPF have always known this, because they have promoted the very strong media capability of the Broadcom SoC countless times in their blog.  They even went as far as to sell licensed codecs which are about as distant from educational as anything could be.  This area may well be getting the most development effort as well, which is reasonable since it plays to the Pi's biggest strength and makes a very large group of Pi users happy.

• Platform for expansions.  It always did seem odd that the Foundation so often stressed the difficulty of reaching their $25/$35 price point, and yet created a board bearing proprietary MIPI DSI and CSI-2 connectors which raised the board cost and complicated PCB routing.  Even more odd is that these MIPI interfaces would not contribute significantly to the board's educational capabilities since USB cameras and displays with open interfaces were readily available at good prices.  The subsequent high investment by RPF in developing camera and display modules suggests that this was a planned business strategy from the start, and it explains why the extra connector cost was considered justified.  One possible view is that there is business advantage in creating a platform for which expansion modules could be produced using a proprietary interface spec that narrows the competition.  Whether or not that was the thinking, it is the current actuality since RPF has invested time and money in expansions and delivered product.

• Enthusiasts/makers hacking platform.  Quite distinct from the needs of EE and UK IT education, a  large group of stakeholders is the worldwide and ever-growing community of makers and related enthusiasts, which may or may not be technical.  This group is heavily interested in creative projects which typically underpin some other area of interest that isn't itself computing.  The Foundation has from the start shown some interest in supporting this group, as evidenced by the board's P1 interfacing header and the near-miraculous provision of SoC peripheral interfacing information from a SoC manufacturer that has shown very little interest in supplying open documentation.  The enthusiast/maker community is strongly aligned with the open source software and open hardware communities since closed/proprietary devices impede rather than support building things.  Unfortunately RPF has been lukewarm in this area as the board is not open hardware, the SoC has very little open documentation, and not all of the software is open source either.  Undoubtedly most of the blame for this lies with Broadcom, but RPF spokespersons have defended the restriction of information themselves as well.

• Commercial for-profit product.  This stakeholder group is small but obvious.  RPF is a registered non-profit, but Premier Farnell and RS are not, and so the Pi has to justify its place on warehouse shelves.  The typically high profits on accessories probably make this quite easy though.

It's pretty clear from the above that the Pi ecosystem has multiple interested parties and drivers, and proceeds along many roads simultaneously with varying degrees of support from the Foundation.

In other words, the Raspberry Pi's concept, rationale, targets and user base are not correlated.

Getting a single view from anyone (especially RPF) is no more productive than all those blind men feeling different parts of the elephant.  To say that it was designed for IT education is completely wrong if intended literally --- Pi would not have been designed as it was nor targetted so strongly at non-educational stakeholders if that had been the primary intention.  This makes the question of "Why is there still no educational release?" a simple one to answer:  IT education was only one driving force, and clearly not a major one.

The only certain position is from objective engineering:  it's an ARM board with specific pros and cons, and it's those pros and cons that determine its effectiveness or otherwise for any given application.  I guess that's more boring than hype-laden official positioning statements by people with vested interests, but in contrast to them, it's accurate.

Morgaine.

Morgaine Dinova wrote:

 

• The subsequent high investment by RPF in developing camera and display modules suggests that this was a planned business strategy from the start, and it explains why the extra connector cost was considered justified.  One possible view is that there is business advantage in creating a platform for which expansion modules could be produced using a proprietary interface spec that narrows the competition. 

Actually the proprietary nature of the interface doesn't seem to be much of a problem. The actual camera sensors with the same interface and physical plug appear to be reasonable easily available off ebay and such like as spares for phones.

The roadblock is the bits that are buried inside the GPU.

I'd have to say that I originally thought the camera was a daft idea, but it's cheap enough that I bought one anyway.  If JamesH manages to sort out a couple of software niggles, I can see it having a reasonable future as a very cheap megapixel security camera amongst other things.

I see someone has already produced an aluminium case with a mount for the camera and externally a mount for additional standard lenses.

I think that's where the maker community shines.. by taking these cheap component parts and combining them into all sorts of interesting ideas.

The camera interface is in fact a standard not unlike the display the problem here is that you can talk to the device but you don't know what to say to it when you have got it. Each camera has it's own set up which is really where it becomes a true pain.

Other than that the closed source GPU is quite the pain more so than the camera really since it controlls so many other subsystems

The camera interface is in fact a standard not unlike the display the problem here is that you can talk to the device but you don't know what to say to it when you have got it. Each camera has it's own set up which is really where it becomes a true pain.

Other than that the closed source GPU is quite the pain more so than the camera really since it controlls so many other subsystems

John Alexander wrote:

 

Each camera has it's own set up which is really where it becomes a true pain.

 

Other than that the closed source GPU is quite the pain more so than the camera really since it controlls so many other subsystems

The problem here, of course, being that the driver for the camera is in the GPU. So even if you have all the info on the camera there's nothing you can do with it.

I've been following the section of the RPF forums on the camera and some people seem to have obtained most, if not all, of the relevant info on the camera and who are coming up with questions detailed enough to have stumped the broadcom employees working on the camera...

Combined with people who appear to have a lot more photographic knowledge than the software people it's made for some interesting reading.