snip
I think there would be a huge benefit to having a build of Angstrom,
Ubuntu, whatever that provided the same set of knives (to use your
swiss army analogy) that are present in Arduino. There are a lot of
Arduino users out there that will eventually be outgrowing that
platform. It seems like BeagleBone is a great place for them but right
now all of them have to slog through the same huge swamp of knowledge
to get to the same place. A path would be really appreciated by a lot
of folks and I think would help grow this community significantly.
I absolutely agree. Even for an experienced programmer, it's far easier
to get a quick hack up and running on an Arduino, even given the limited
libraries and horrid development environment, than on the Beagle. From
the look of it, this could change with the BeagleBone. With the
introduction of Cloud9, it seems that BeagleBone has a real chance at
becoming as easy to use as Arduino.
One obstacle, here, will be low-level hardware
configuration. While in the case of Aruduino, you have a simple
interface which interacts directly with the bare metal to give you, say
I2C acesss, on Linux things are more complicated. There are a lot of moving parts in low-level
configuration, between configuration of the SPI controller to the
pinmuxing to multiplexing the bus between multiple drivers, there are
lots of moving parts to get interacting before the ease of the Ardunio
will be realized on the BeagleBone.
This is something that really will need to be worked on. Currently, it
seems few people realize the importance of, say, being able to bring up
an SPI interface with spidev without rebooting. But this is necesary if
the BeagleBone is to reach the exposure of Arduino.
Anyways, it would be nice if we could start a discussion of what is
necessary to make this process more dynamic. Sure, dynamically binding
and unbinding drivers while fooling with pinmux after boot isn't trivial,
but it's not impossible. In fact, I believe that most of the kernel
interfaces already exist in some form or another (e.g. pinmuxing can be
done at runtime through debugfs; we'd probably want a better defined
interface though). Thoughts anyone?
In the meantime, does anyone know if Brian Hensley's instructions for
making SPI work on the BeagleBoard XM rev
C(http://www.brianhensley.net/2012/02/spi-working-on-beagleboard-xm-rev-c.html)
apply to the BeagleBone as well? In the worst case I'll give up some
room on my projects, get a BeagleBoard, and just shelve my BeagleBone
for now.
It looks like this should be fine. The one thing you will need to change
is the pins used. While the BeagleBoard exposes McSPI busses 3 and 4, the
BeagleBone exposes McSPI busses 0 and 1. I didn't look too carefully,
but I will say that his discussion seems quite long; it generally
shouldn't be too difficult to bring up SPI. Unfortunately, the current
state of things does require that you are able to compile a working
kernel. Depending upon what distribution you use, this can be a bit
tricky (e.g. an incompatible devicetree can drop you into a kernel which
silently crashes upon boot, unless you remembered to turn on
CONFIG_LL_DEBUG and earlyprintk; I killed a day yesterday working
through this on Linaro with a custom 3.3-rc kernel).
Cheers,
- Ben