BeagleBone wireless communication with xBee

[bluehash 1,581]

Electric stitches has a wonderful tutorial on talking to your beaglebone via a xbee radio. He's using the python-xbee API.

 

[bluehash 1,581]

Website is down. Wayback machine to the rescue. pdf'ed it.

 

xbee_beaglebone_cape.pdf

[spirilis 1,265]

Man what's really driving me nuts is how the 3.8 kernel blasts most of the pinmux stuff out of the water so the old code & examples no longer work.  This tutorial being a great example, the "omap_mux" debug dir is no longer available.  All that stuff will have to be rewritten for the new devicetree-based convention (which I am still not 100% sure how you properly do it) for the BBBlack or any 3.8-kernel updates to the old beaglebone.

[bluehash 1,581]

Oof that plain sucks.

[spirilis 1,265]

Yeah once I get a handle on how that all works, I'll start spamming examples.

[yyrkoon 250]

Yeah once I get a handle on how that all works, I'll start spamming examples.

That would be great. From what I understand though Device tree is a semi PitA to learn. Fairly steep learning curve from what I understand. But what I did glean so far is that you *have* to use device tree, and then make a virtual cape ? Seems odd to me, but I do not have enough knowledge right now really to seriously comment.

 

Personally, and I really do not know enough about it ( again ), I think it would have been much better to just give us access to the  gpio / periphs through SYSFS or whatever. Maybe someday down the road if someone does not come out with a driver library that I like, I'll delve into writtign my own kernel module drivers. A bit over my head, but when I get some time to do some reading, who knows.

[spirilis 1,265]

I think the old "Give us freeform access to SYSFS" thing is the source of the issue; every ARM vendor has their own way to do it, Linus Torvalds got pissed off at this (or some rough facsimile of that sequence of events) and told everyone to figure out something uniform.  Devicetrees was born.  Instead of providing a sysfs layer to do it all, changes to pinmux et al are done by a descriptor file (devicetree) which is compiled into some binary format which is then tossed into /lib/firmware and kernel drivers must load those to carry out the changes.

 

The BeagleBone guys then have a "capemgr" kernel driver which enacts these, and the changes are done by loading "virtual capes" which are nothing more than devicetree files.  Likewise, instead of having the pinmux settings enacted by reading the contents of a cape's EEPROM and performing the requisite sysfs modifications, the "new order" of things is to have the capemgr driver simply read the board ID off the EEPROM and look for the matching devicetree file under /lib/firmware and then load that.

 

That's all I know for now, I know there are examples out there to mess with it but I haven't tried any yet.

 

The plan, in progress and hopefully released soon in earnest (I think Jason Kridner is heading this), is for the Bonescript/Node.JS stuff to natively support whatever the new order of things is supposed to be so you can dynamically change those settings from your bonescript application.  The old way was for bonescript/node.JS to simply twiddle the /sys/debug/omap_mux/blahblah files.