SPI Development, trying to avoid C

I am working on trying to read several sensor modules into the BeagleBone via the UART connections (mostly successful so far) and now it’s time to get SPI working for multiple sensors. However, after hours of research this is my list of notes:

  • C seams the be the preferred way to handle it. (Which I don’t want todo)
  • Python is how I am currently handling the UART stuff, but didn’t find any thing for python SPI libraries. (Not a great python guy)
  • Would prefer todo this all in java, but java lacks the support to access the hardware layer effectively (RxTx/ToyBox and others don’t have a port for the BeagleBone processor architecture. (Alot of other ARM processors though).
  • Still doesn’t handle the SPI problem even if I fixed it

Does anyone have any suggestions on a Python way to go for SPI. Or better yet know of a java way I have over looked? Do I have to bite the bullet and finally spend the time to learn C/C++?

I have read several of the posts on this group about the SPI dev stuff and it sounds like kernel patches and/or drivers are required and written in C. I could dive into the pool, but I am trying to avoid it.

Thanks in advance for your thoughts and considerations.

Gregg

not sure if you've seen this yet:

http://www.brianhensley.net/2012/02/python-controlling-spi-bus-on.html

it's for the beagleboard xM but might still be useful.

rday

This implementation needs spidev, but it is not available for the
BeagleBone:

opkg update # get the latest update
opkg upgrade # and kernel
mount /dev/mmcblk0p1 /mnt # mount fat32 boot partition
cp /boot/uImage-3.2.6+ /mnt/uImage # install new kernel
umount /mnt # umount
reboot # reboot

root@beaglebone:~# uname -a # show kernel running
Linux beaglebone 3.2.6+ #1 Wed Feb 22 10:52:27 CET 2012 armv7l GNU/Linux
depmod -a # configure new modules
modprobe spidev # load spidev driver
ls -l /dev/spi* # look for spidev generated devices
ls: cannot access /dev/spi*: No such file or directory

Everytime I ask here for spidev support on BeagleBone, nobody
answers. But there are people who show on Youtube several
displays running on beaglebone via SPI. So SPI is working
on BeagleBone, but nobody wants to explain, how you can make
it work. It seems to be a big secret.

Regards,

Frank

You're confusing the spidev driver with the kernel spi framework. The spi display in the videos is using a regular spi driver (st7735fb to be exact), not spidev.

You're confusing the spidev driver with the kernel spi framework.

Yes I know, this was my intent to get a clear statement from
you whether spidev is supported on beaglebone or not.

The spi display in the videos is using a regular spi driver
(st7735fb to be exact), not spidev.

Is spidev supported on leaglebone or not?

I can live with a "is not supported" answer, this would be
better than getting no reply at all.

Regards,

Frank

It depends on what you mean with 'supported'. That's not me trying to be a smart ass, it's a real and important question.

It shouldn't be much different than how it is done on the BeagleBoard.
The only different part would be you have to look in the SRM and find
the pins that have the spi bus you want to use and configure the pin
mux for that mode and then setup the spi platform driver and register
it so the spidev device shows up.

Search the archives for my name, I've tried to help several people in
the last month or so get spidev going on their BeagleBoard and gave
links to elinux pages etc.

Regards,

Brian

I want to write/port real existing applications to the
beaglebone. I don't want to write special drivers to
get an application work on beaglebone, which only needs
generic access to a SPI interface from userland. I only
want to use the beaglebone - as is.

The beagleboard supports access to GPIO via sysfs, everybody
from userland can use it - thats fine. Analogous I want to
get access to several SPI devices connected to the beaglebone
as a normal user - without need to write a special device
driver for that.

The only way I know to get generic access to SPI as a normal
user is to use the spidev interface. If this is not possible
on BeagleBone, I will make it via GPIO access. It's not very
difficult to simulate a SPI interface via GPIO. Surely it will
be not so fast, but better having a solution than having nothing.

Okay, I will express my question in another way:

Is it possible to get access to SPI on beaglebone from
userland? My applications are written in C.

Thanks,

Frank

Sorry for top posting, I’m thumb typing on a phone.

I hear what you are saying, but spi can be configured to be all kinds of places. On a lot of these TI processors, the pins can have up to 8 functions. So step one is to do the work required to make spidev show up THEN, any ole userspace app can use it.

I might be wrong but I don’t think the board file comes out of the box setup to do spi.

I think the new kernels support device trees and that would allow you to setup spidev too without having to modify the kernel.

So, just to be clear, you want spidev, then you have to turn it on in make menuconfig (usually already done by the default config) then you have to configure it (speed, bus, channel mode etc.) and you do that by:

1 modifying board file to setup the platform device and register it.
2 Use devtree.

You used the spi lcd as an example. Do you want to use the builtin driver in the kernel or write your own using spidev? With spidev turned on you can't use any of the available kernel drivers for spi hardware anymore. You say you don't want to write special drivers, but that's exactly what you need to do when using spidev.
I'm still not clear what you want to accomplish and why you think spidev is the one and only way to do it.

regards,

Koen

Thank you Brian, I will try it.

Regards,

Frak

You used the spi lcd as an example.

This was only an example to confirm that SPI works
on BeagleBone :wink: I don't want to use a display on
BeagleBone or something similar.

Do you want to use the builtin driver in the kernel or
write your own using spidev? With spidev turned on you
can't use any of the available kernel drivers for spi
hardware anymore.

I only want to drive up to 512 Output-Pins with the BeagleBone.
For that I use up to 64 cascaded 8-Bit-Shift-Registers (74HC595).
These ICs can be simply loaded via SPI.

According to http://www.kernel.org/doc/Documentation/spi/spidev
I only have to open /dev/spidevB.C and write up to 64 bytes
(512 bits) to that character device to load the shift-registers.
For this I don't need a display driver or something similar,
only generic SPI output.

Regards,

Frank

Yes, but you do need to instantiate a device as it states in
the referenced documentation. For that, you need to add kernel code
to define the spidev device with chipselect, polarity, timing, etc
specific to your part.

-Matt

It would be really nice if someone documented this on the elinux
BeagleBoard/SPI page (http://elinux.org/BeagleBoard/SPI). I've been
trying to keep the kernel patch up to date (which is generally quite
trivial), but it seems that a devicetree-based approach is ultimately
the right way to do this (someone correct me if I'm wrong).

Cheers,

- Ben

Thanks Brian. I’m in a similar boat to the original poster - I just want to start actually working with my 'bone, and for that I really just need SPI access from Python.

I’m comfortable in Linux from a user perspective, but I haven’t rolled my own kernel in many years, and unfortunately your directions, while I’m sure they’re super helpful for someone in the know, fly right over my head.

I’m happy to keep plodding forward, and I’m certainly learning a lot, but if anyone has any further instructions on how to get the point where I can bang some bits down SPI via python, I’d greatly appreciate it!

I’m fairly new to devices and all of my prior experience is with Arduino. The BeagleBone seems to solve all of my problems from a hardware perspective but so far it’s been very, very difficult to sort out the software side. I’ve read through this mailing list multiple times and have been reading everything I can about linux kernels, device drives, spidev, you name it - but as of right now I don’t feel any closer to a path forward.

I understand that SPI is a de-facto standard and as such there are certain things that need to be configured - but I guess what I’m wondering is what did Arduino do that’s so special that it just works? And is it possible to bring that “magic” to the BeagleBone? My friends who also play with Arduino are starting to need the kind of horsepower the 'bone provides, but right now the path for transitioning isn’t terribly clear.

Thanks so much.

  • Branden

BeagleBoard/Bone are Swiss Army Knives of Embedded Linux. They can do
anything. With that comes many combinations and permutations of
configs etc. Aurduino stuff is very specific. Yes SPI is a standard
but all devices don't run at the same speed nor are their polarity all
the same. You have to know enough about the device you are trying to
interface with to set the Beagle up to talk to it. Search the
archives ... I recently went through this showing how it is done with
Angstrom/bitbake. Don't have time to go through that again. The info
is all here ... it just takes a while to sink in.

Regards,

Brian

Thanks Brian - I really do appreciate the information, let me make that totally clear. There’s just a disconnect and it’s one I’ve seen a few times on this list and in general between experts and the very greenest of noobs - they just don’t speak the same language.

I’m new to all of this, and I really want to learn, I just have no idea how all of the pieces fit together. I’ve read through the archives many times over but I’m having to constantly look up things like u-boot, MLO, etc. I feel like I’m making progress, but it’s only my near mental illness level of optimism that keeps me going on at times!

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.

Now, not being one to just suggest other people do work, I’m more than happy to work with anyone here to help make that happen. Over the years I’ve written many, many tutorials and books about technology and would happily donate my time and sparking clean “beginners mind” to help make the BeagleBone more approachable.

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.

Thanks so much!

  • Branden

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(SPI working on the Beagleboard XM rev C - Brian Hensley)
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

There are a lot of Arduino users out
there that will eventually be outgrowing that platform. It seems like

I think it is great that there are more Arduino folks coming into the
fold and platforms like BeagleBone and Raspberri Pi making open
hardware & software available.

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.

The processors are more complex and the Linux kernel itself is
millions of lines of code itself and to add that to u-boot and all the
packages that make up the root filesystem and the build tools &
toolchains ... it is complex, no doubt. That is what the forums are
for. I've been using Linux from the start and I feel like a nube in a
lot of areas myself ... that is what draws me to it. You will never
exhaust or hit be bottom of all knowledge in this field ... nobody
can.

I think the influx will help drive usability issues but it will
probably take a while ... you can't turn a ship around on a dime (but
if you are Costa Crociere you can turn one over quick).

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.

In the meantime, does anyone know if Brian Hensley's instructions for making
SPI work on the BeagleBoard XM rev
C(SPI working on the Beagleboard XM rev C - Brian Hensley) apply
to the BeagleBone as well?

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
Beagles.

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

Regards,

Brian