Arduino: now a Single Board Computer!

I think with Intel and T.I. as players in the Arduino market place this will move from the hobby level into the professional level and we will see more of these in the work place than we have before.  To Beaglebone was a great board and I liked it a lot, but the black was a tad disappointing. I own the pcDuino, UDOO, several Arduinos, and Due and look forward to receiving the Galileo too. I posted several benchmarks and gpio tests on http://www.marchdvd.com so this is exciting news for me. 

ed march wrote:

 

Beaglebone was a great board and I liked it a lot, but the black was a tad disappointing.

Could you elaborate why BBB disappointed you?  It seems to me that it's virtually all progress compared to its predecessor (I have both boards here), since the only losses are JTAG + serial port on the mini-USB and no PMIC header.  Those are rarely used facilities, and in exchange for their loss the gains are truly huge and important to almost all BBB users.

I've never heard anyone suggest that BBB was a disappointment before, so I'd like to hear your PoV.

Morgaine.

ed march wrote:

 

Beaglebone was a great board and I liked it a lot, but the black was a tad disappointing.

Could you elaborate why BBB disappointed you?  It seems to me that it's virtually all progress compared to its predecessor (I have both boards here), since the only losses are JTAG + serial port on the mini-USB and no PMIC header.  Those are rarely used facilities, and in exchange for their loss the gains are truly huge and important to almost all BBB users.

I've never heard anyone suggest that BBB was a disappointment before, so I'd like to hear your PoV.

Morgaine.

Morgaine Dinova wrote:

 

ed march wrote:

 

Beaglebone was a great board and I liked it a lot, but the black was a tad disappointing.

 

Could you elaborate why BBB disappointed you?  It seems to me that it's virtually all progress compared to its predecessor (I have both boards here), since the only losses are JTAG + serial port on the mini-USB and no PMIC header.  Those are rarely used facilities, and in exchange for their loss the gains are truly huge and important to almost all BBB users.

I thought having USB serial and JTAG was a great BB White feature since it provided a nice interface for bare-metal programming.  However, the reality is that very few people do bare-metal programming on a chip as complex as the Am3359, so the capability added a lot of expense for something few people would use.  I think adding HDMI output and dropping the price to US$45 was the opposite of disappointing.

Indeed, and every other comparison I've read has said the same.  Yet apparently one person thinks otherwise, so I'd like to understand his rationale in case we missed something important.

Morgaine.

Last year a friend and I bought bought a BBBK and his kept loosing the network, my worked fine, I ran lighttpd  as a web server. He brought his board to TI since he lived near then in Texas, they didn't low what to do and gave him a new board, he show him my board and said make them work the same, and TI couldn't - he kept my board for the project and I switched to pcDuino. The other main problem was the device tree was not working in any of the linux distribution SD card images. We had a hard time getting the GPIO and several harts working, we ended up using the debug uart.  I have a UDOO board and all the IO in /sys/class for the device tree works 100%, also the PcDuino works 100%, TI dropped the ball on the software, they let the open source community  do the sw, while they just did hardware, rather poor. Other companies write the necessary drivers for the arm processors and provided a 100% working package. The white BB did not suffer from this mess. I also worked with Bruce Lightner on his pico web many years ago and respected him, he gave its a low star review on amazon due to networking issues.  

amaon reviews

http://www.amazon.com/Beagleboard-BeagleBone-Black-Beaglebone-A6/product-reviews/B00CHYOLHK/ref=cm_cr_pr_hist_1?ie=UTF8&filterBy=addOneStar&showViewpoints=0&sortBy=bySubmissionDateDescending

http://www.amazon.com/Beagleboard-BeagleBone-Black-Beaglebone-A6/product-reviews/B00CHYOLHK/ref=cm_cr_pr_hist_2?ie=UTF8&filterBy=addTwoStar&showViewpoints=0&sortBy=bySubmissionDateDescending

Thanks for your reply, ed.  A rough summary of your experiences plus those described in the two Amazon reviews you linked seems to be "Great hardware, but the software is badly broken."

I think a lot of people would agree with that.  Certainly the networking under Angstrom was an unmaintained mess, an unholy combination of connman, systemd, and SysV init scripts that managed to support the Javascript-based IDE through USB out of the box quite well, but fell apart if you tried to configure it for other common scenarios.  Nobody seemed to know if there was a solution either --- lack of docs and lack of maintenance is a bad combination --- which is why there was a mass exodus of users to Debian.  That provided a working network config at last.

The device tree problems are a more complex matter.  I do agree with you that it's the manufacturer's job to get the drivers working for all the interfaces provided on the board.  My reason for this is simply pragmatic --- the manufacturer's engineers know their devices inside out, whereas it could take years for community developers to reach the same level of knowledge and finally get the drivers working.  If a board is to succeed without delay, it needs the manufacturer to not only provide the open source drivers, but also to ensure that they work out of the box.  Just throwing the whole bundle over the wall for the community to sort out will (probably) work eventually, but it's not the strategic way forward, and it will create disappointment.

Morgaine.

PS. I don't personally know the state of the drivers you mentioned, so the last paragraph is just a general comment.

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.

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.