Arduino: now a Single Board Computer!

Morgaine Dinova wrote:

 

Angstrom was an unmaintained mess, [...] Nobody seemed to know if there was a solution either

Of course there's a solution...  It involves

a mass exodus of users to Debian. 

On the BBB, the driver situation is very much complicated by capemgr and device tree overlays.  If they were to do what everyone else is and making it a case of "edit the dts, recompile it and reboot" I suspect most of the drivers work just fine.  The problem is that changing direction like that requires abandoning the capes concept and I believe that pushes it into a political decision rather than a simple engineering one.

ed march wrote:

 

It will only take a few great battery changes to kill off the arm, and some day no one will care about low power any more

That's based on a misconception that the only problem with using a lot of power is the limited amount of it we can get from today's batteries.  Quite clearly this is nowhere close to being true, since there are issues of heat to consider, as well as issues of increased component cost and operating cost and reduced lifetime, not to mention the impact on already stressed public utilities.

Low power consumption and high energy efficiency are very important figures of merit in their own right, and they won't cease to be important when battery power and capacity increase into the stratosphere.

Morgaine.

selsinork wrote:

 

On the BBB, the driver situation is very much complicated by capemgr and device tree overlays.  If they were to do what everyone else is and making it a case of "edit the dts, recompile it and reboot" I suspect most of the drivers work just fine.  The problem is that changing direction like that requires abandoning the capes concept and I believe that pushes it into a political decision rather than a simple engineering one.

So how do you see the official adoption of Debian as changing this situation?  Platform-specific hacks are unlikely to be accepted by upstream Debian nor by mainline kernel, so any BeagleBone-only concept like capes is going to have to dovetail cleanly into a multi-platform Debian + kernel world.

It seems to me that Beagleboard.org needs to head in the direction of allowing full device tree configuration to be performed in the same plain vanilla ARM Debian that works on other boards, and cape management to be only an optional extra to make life easier and to provide a measure of protection against hardware mishaps.  That approach would ensure that cape management is strictly a superset feature, requiring nothing at all of upstream distro and kernel communities that don't use capes.

Morgaine.

This is undoubtably where things get tricky.  The obvious first step is something similar to the RPi situation where you have one repo for the main part of the distro, and a second one for the platform specific kernel and utils. apt-get makes this configuration relatively simple to accomplish.

Looking at the device tree overlay loader proposed by Pantelis in early November 2013, all of the beaglebone specific stuff had been removed. There was no capemgr or anything similar included. My first thought was that the much more generic structure was ideally suited to a capemgr in userspace. If that were the case, the generic overlay loader can be in the mainline kernel as there are other users (fpga folks seem to like the idea too), capemgr goes in the platform specific apt repo as an add-on package.

Reading Robert Nelsons posts to the beagleboard google group, it seems that while they're heading towards 3.12/3.13 kernels, they don't have working cape support there and may be going for some default config that enables a fixed set of functions on the expansion headers. That's unlikely to play well with random capes, especially multiple capes, but is a way forward and matches what everyone else is doing when moving to devicetree.

selsinork wrote:

 

My first thought was that the much more generic structure was ideally suited to a capemgr in userspace. If that were the case, the generic overlay loader can be in the mainline kernel as there are other users (fpga folks seem to like the idea too), capemgr goes in the platform specific apt repo as an add-on package.

Agree 100%.  And that would compartmentalize the jigsaw into kernel, generic ARM Debian and platform-specific parts, with great relief to everyone concerned.  And perhaps even more important, it would allow the fastest rate of progress because all of the inter-team negotiation (and politics) is avoided.

Morgaine.

Galileo seems to have landed in the UK http://www.coolcomponents.co.uk/intel-galileo.html

Pricing doesn't work for me 66 GBP for Galileo vs 62 for a Cubie A20 http://www.coolcomponents.co.uk/cubieboard-a20.html not a favourable comparison from where I'm sitting.

selsinork wrote:

 

Pricing doesn't work for me 66 GBP for Galileo vs 62 for a Cubie A20

I think you're right in a strict comparison of prices and capability, although it might be justifiable purely on "check out the x86 contender" grounds for comparison die-hards.

It's a pity it doesn't have at least one salient spec item going for it though, such as more than the usual 512MB memory (instead of less, namely 256MB) or a gigabit NIC.  I guess the PCIe mini-card slot is one such, if one is trying to be generous, but there are additional expenditures involved there (converter plate and leads), and additional expenditures put the board even further out in the fields.

I welcome Intel joining in the fun though.

Morgaine.

Morgaine Dinova wrote:

 

I think you're right in a strict comparison of prices and capability, although it might be justifiable purely on "check out the x86 contender" grounds for comparison die-hards.

and there will be people who believe x86 is an advantage..

I did a quick table with basic features vs cost here Where does RIoT fit ? while trying to work out which boards have an obvious advantage or special niche.  I'd missed that Galileo has a mini pcie.....  I'll go add that now..

selsinork wrote:

 

...and there will be people who believe x86 is an advantage..

Actually, I've got to admit I'm pretty impressed with the latest Intel NUC US$141 mini-PC: http://linuxgizmos.com/intel-releases-low-cost-low-power-mini-pc/

In fact, I'm tempted to get three and name them Larry, Curly, and Moe (NUC, NUC, NUC).