Pin confusion from existing examples...

GoogleGroups
1

The frustration level is growing…

The Cloud9 IDE seems pretty powerful, but the examples shipped on the image, which is for different editions of BeagleBone does not have any indication is to which ones are meant to work on which board?

Thats really strange, and it takes quite some attempts to find an example that actually works.

Looking carefully at the https://github.com/beagleboard/beaglebone-blue/blob/master/BeagleBone_Blue_Pin_Table.csv

But realizing that most of the “Blue names” pins are not accessible from most high level languages.

Is there anywhere an indication of what libraries are complete and working, for what board, and with a list of IO-pins that might work…??

2

The frustration level is growing...

Sounds like you're experiencing the same thing I did when first starting.
One of the biggest hurdles here is going to be related to your knowledge of
Linux. After that, knowing the hardware well is a must for any serious use.

The Cloud9 IDE seems pretty powerful, but the examples shipped on the
image, which is for different editions of BeagleBone does not have any
indication is to which ones are meant to work on which board?

Myself, I do not use Cloud9, so I can not tell you how to deal with the
Cloud9 aspect. However, Cloud9 is basically just a web based text editor
with some functionality similar to an IDE, and a few features beyond. Most
of the functionality I've seen demonstrated using Cloud9 is Nodejs based.
As such you do not necessarily need Cloud9 to use Nodejs. I've written some
Nodejs examples, and have what some may consider a framework on github that
demonstrates several things one can do using Nodejs, and have even used it
to create a web based PMIC register viewer. However, it may not be exacly
what you're looking for. As you need knowledge of the hardware, and know a
good bit about using Nodejs, including setup, install, and all that.

Technically, all examples should work on all boards from the beaglebone
white, all the way to the latest Beaglebone blue. However, much of the
documentation on the web, was written with older kernels in mind. Where the
sysfs pathing for various hardware interfaces were different. Then, I
realize this does not do you any good now, but knowing how to deal with
these different paths in a modern kernel. Old, or new documentation then
becomes a moot point.

Thats really strange, and it takes quite some attempts to find an example
that actually works.

So here's the deal. No one knows specifically what you're talking about.
There are several differences between older, and current kernels that do
not directly translate because of sysfs pathing. So, If you could create a
different post, explaining a single( at a time ) problem in great detail.
There *IS* someone here who can help you. We need specifics, and we need
you to be verbose.

Looking carefully at the GitHub - beagleboard/beaglebone-blue: BeagleBoard.org BeagleBone Blue - BeagleBone optimized for mobile robotics
blob/master/BeagleBone_Blue_Pin_Table.csv

But realizing that most of the "Blue names" pins are not accessible from
most high level languages.

Is there anywhere an indication of what libraries are complete and
working, for what board, and with a list of IO-pins that might work...??

Here's the thing. Examples have already been written for the older
beaglebones. Everything on the web right now. Be it old, or new
documentation *will* work. Everything is still accessible from a file(in
relation to hardware ). Only the paths for various things have changed. The
only real difference between the beaglebone white, and the beaglebone blue.
Is that initially, the beaglebone white used a kernel that was not device
tree aware. With that said, the beaglebone white can use a current kernel
as well. As if, it were "just another beaglebone", which of course, it is.
To be sure, there are some low level hardware differences. But nothing that
you, or I( the user ) need to concern ourselves with immediately, or ever.
Mostly, this has to do with how the bootloaders treat the hardware when
it's first brought up.

3

In relation to " the only differences" . . . This is in the context of
software.. Obviously there are a few hardware differences. How one
physically connects to the outside world should be obvious. Header types,
and all that, and there is some different hardware on the board it's self.
But the processor core is exactly the same or so similar that accessing
hardware between one board and another will be the same.

4

Thanks for your feedback, very substantial stuff, I appreciate and confirms the fact that some of this is due to lack of experience with simple linux and device tree concepts.

As the amount of information is immense, I would like your pointer to the most updated information on the hardware access from ie. Python as of todays Beagleboard software.

Thanks again

5

I can't say about Python. I only use C, and sometimes shell scripts to call
custom written cmdline tool written by myself. I have dabbled with Nodejs
some, well more than dabbled, but I keep finding my way back onto a pure C
path . . .

6

I am thinking that its a shame, when there is a splendid opportunity to move into higher level languages and managed code. We have a full-blown computer here, with an operating system, and we are using the same programming approach as the dudes that are running with a PIC.

Argh!

The robotics cape c-library seems very mature and usable, and very tempting to start coding with that. But I want a much mature and abstract approach so I can focus on building prototypes.

7

The problem I have with most, if not all higher level languages is that the
overhead is too steep. Most of the project's I'm working on right now
involve a lot of processes running all at once, and many of these are as
close to real-time as possible. So, the smaller the executable, and the
faster it runs, the better our system performs. Where performance in our
own case can be perceived by our end users.

Now if you're on the moon, or mars where you already have hours worth of
latency, when remote controlling something. That may not be a big deal. But
lets envision an analogy where you have production line, with sever stop
buttons to stop that production line in case of an emergency. You do *NOT*
to be running code that can take seconds to respond to input. You need as
close to immediate of a response as possible. Otherwise someone's life
could be in danger.

Thankfully for our own case, our application is not quite so mission
critical. But how well the system performs in whole can be perceived by our
end users. Which for us, is very important.

8

And yeah, we could also be using bare metal hardware in tandem with a beaglebone for even better performance. But that would also require C / C++ at minimum, and honestly is not needed for our own purposes.