SPI Development, trying to avoid C

... Oh, I got carried away on my soap box and forgot to address the
specific issues of SPI BeagleBoard vs BeagleBone on that page you
mention but it looks like Ben did an excellent job covering it.

The builds for BeagleBoard & BeagleBone are the same as far as kernel.
When you are trying to figure out SPI, pinmuxing etc. you need to put
your "BeagleBone" glasses on so when you read about posts or
directions that are written for the BeagleBoard ... be asking yourself
what would be different on the BeagleBone as far as pinmux etc.




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.

Just what we needed, a use case! You see, once DT conversion is complete
and it becomes that standard way to boot Beagle*, it doesn't solve this
"bring up an SPI interface with spidev _without rebooting_ problem. A
complete DT solution does allow you to edit your dts, define your SPI
slave devices, and reboot an unmodified kernel to have those slaves bind
to the spidev protocol driver then you're off and running. As an
incremental step, this is vastly simpler for many things since modifying
the kernel scares people to no end.

So, let's talk no reboot...

Today you have the kernel interface spi_new_device() such that one can
load a device specific module, register an additional spi_device with
the appropriate parameters, and then use the userspace bind/unbind
interface to bind it with the spidev protocol driver.

But you're going to tell me that's icky and sure, it is icky to the
Arduino crowd. It does hint at a short-term way to manage this for the
Beagle community though in that you *do* have all raw kernel interfaces
exported in order to instantiate things at runtime.

That said, the proper solution is to add a SPI subsystem feature in the
kernel that exposes a new userspace API in the SPI sysfs hierarchy that
allows one to hotplug a spi_device instance via a sysfs entry. IMHO,
that's the only thing missing from the kernel POV and I guess I'll add
it to my TODO list.

The rest is up to the userspace javascript folks. :slight_smile:

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?

The pinctl subsystem with the optional pinmux driver backend will deprecate
the omap-specific pinmux interface, so you can check off the "better
defined interface part". The rest is an exercise in userspace code.


I like the i2c way of doing it:

root@beaglebone:~# echo bmp085 0x77 > /sys/class/i2c-adapter/i2c-3/new_device

root@beaglebone:~# dmesg | grep bmp
[ 45.409667] i2c i2c-3: new_device: Instantiated device bmp085 at 0x77
[ 45.434717] bmp085 3-0077: BMP085 ver. 2.0 found.
[ 45.434756] bmp085 3-0077: Successfully initialized bmp085!



Don't get frustrated and give up. As my Dad always told me ... Rome
wasn't built in a day. Comparing Arduino to BeagleBoard is like
trying to compare a Cessna 170 to a Boeing 777.

Oh, no worries there, I'm just about as pig headed as they come! The biggest problem I'm running into is that I often don't have a good conceptual skeleton to hang all of these tools and technologies on. I'm very much a blind man feeling up an elephant right now!

If anyone knows of any documentation that just shows who all the players are (u-boot, the kernel, drivers, etc), what roles they play and how they fit together that would probably be an excellent beginner resource (and I would love to read it!)

I don't mean any disrespect to the OP but the whole subject of this
thread reminds me of a thread a colleague was telling me about the
other day. Not using C to do some of this stuff is like asking on a
FPGA forum how to do VHDL with .Net.

I fully understand that sentiment, there's some code that always needs to be close to the metal. That being said, I tend to find that the most interesting things happen in technology when you make programming more accessible to the masses.

IMHO truely incredible things happen when you expose creative people to new technology and make it easy for them to play and explore.

I skimmed that sight and thought it looked excellent. It is from the
perspective of running Ubuntu though. I think the bulk of folks here
are running distros custom build with Angstrom as that is what is
shipped with the boards. I don't have any experience running Debian
or Ubuntu on the Beagle's as I mostly need them to do embedded
oriented things than full blown desktop things but I am a huge Debian
fan and love the fact folks are running Debian flavor OS's on the

Keep digging .. you'll pick stuff up ... it takes a while.

Thanks for the info and encouragement. It's really appreciated.

- Branden