Reading analog in on the stretch (9.1) images

How do I read AIN on the latest images? I don’t know where to find it in /sys/

–Mark

Hi Mark,

This is with the Blue right?

James' got the ADC tied up in mmap for the Robotic's cape library..

https://github.com/StrawsonDesign/Robotics_Cape_Installer/blob/master/libraries/mmap/rc_mmap_gpio_adc.c

We need to convert his library to use libiio, then we can just enable
the ADC's as an iio device and share usage with the library..

https://analogdevicesinc.github.io/libiio/

Regards,

That's just swell, as Strawson didn't write that code either, and gave no
attribution to whom did.
https://github.com/wphermans/BeagleBone-GPIO/blob/master/src/gpio.c

Just for the record,I did not write that. Ethon Hayon did back in 2012, I'm
thinking probably for the white. Same hardware though . . . I know this,
because I have a duplicate of his repo on my git, but it was an excellent
learning tool. However, no one in their right mind, is going to map the
whole hardware address space into memory, UNLESS they were doing exactly
what Ethon was doing in his project. Which was making a general purpose
"library" to access any GPIO pin, and ADC's.

SO when you see something like this:

map[(ADCSTEPCONFIG1-MMAP_OFFSET)/4] = 0x00<<19 | ADC_AVG8 | ADC_SW_ONESHOT;
Versus
map[(ADCSTEPCONFIG1-MMAP_OFFSET)/4] = 0x00<<19 | ADC_AVG16;

Obvious copy paste ripoff.

Anyway I'm not saying no one can use Ethon's code, I'm saying if you're
obviously copy pasting code from his repo, you need to give him credit for
it. No matter how much you butcher / move stuff around.

Yup, this is the Blue.
In there short term is there an easy way to turn off the robotics stuff and get easy access to the analog in?

In the long term, what will it take to convert James’ robot stuff to libiio? I might take a shot at it if it isn’t too hard.

–Mark

I have lived on BBB + Robotics Cape in James’ world for some time. While I haven’t done this with a Blue, I suspect what I did can work there too. I did do his installation (for a Rev C BBB and a Rev D Robotics Cape). With Robert’s help I put the Capemgr back in the DTs and added the capemgr partno boot line for BB-ADC. This seems to be a workable combination of the two worlds. My premise is that I don’t try to do both at once. That is, I don’t run any of the rc_* apps or services while trying to read the ADCs from /sys/bus/iio. So far it seems to work for me.
Hugh

It sounds like I can either have a Blue that boots as a robot, or boots as an embedded processor, but not both at the same time.
I need to see what it would take to remove the ADC from the robots control.

–Mark

It looks like when the Blue comes out of the box, running a current image it’s all set up to run the Robotics stuff. You can access the ADCs, servos, etc. through the robot interface.

When I teach my Embedded Linux class I would also like my students to access the ADCs, PWM, etc in the Linux way.

How do I configure the Blue to boot up in “Embedded Linux” mode rather than “Robot Linux” mode?

–Mark

It looks like when the Blue comes out of the box, running a current image it’s all set up to run the Robotics stuff. You can access the ADCs, servos, etc. through the robot interface.

When I teach my Embedded Linux class I would also like my students to access the ADCs, PWM, etc in the Linux way.

How do I configure the Blue to boot up in “Embedded Linux” mode rather than “Robot Linux” mode?

If we get the integration right, IMO, we’ll boot up so that we can use the Linux userspace interfaces and the libroboticscape interfaces. The libroboticscape setup should do whatever is needed to disable Linux kernel drivers at runtime in order to enable its userspace accesses.

Turn on the ADC kernel drivers and look how libroboticscape fails. Then, report that as a bug.

Sounds like a good idea. How do I turn on the ADC drivers?

–Mark

Sounds like a good idea. How do I turn on the ADC drivers?

https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4-ti/src/arm/am335x-boneblack-custom.dts#L56

I found Jason’s hint to be a bit short on explanations, so here is what Robert Nelson led me through. It is was I reported that I did with a BBB + Robotic Cape but didn’t know if it would work with a Blue. I take Jason’s answer to be yes it will work with a Blue.
On July 11 Robert wrote in my earlier email stream titled “where is capemgr?”

It’s not a service file, it’s the device tree binary:

https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4-ti/src/arm/am335x-boneblack-roboticscape.dts#L19

Change:

#include “am335x-bone-common-no-capemgr.dtsi”

to:

#include “am335x-bone-common.dtsi”

He also led me through how to compile it and boot it, etc. I won’t try to repeat that here from memory.
Then do the usual capemgr boot line directive with partno=BB-ADC

I still believe that this configuration can live with the rc_* apps and services, as long as you only use one at a time.
Turns out we haven’t been hearing from James (the rc_* creator) on this because he is way way way out of the county for the summer.
Clark

I’m missing a “Big Picture” idea here. Let’s see if I can ask with right questions.

How can I tell with device tree file my Bone is booting with?
Where can I find it’s source?
How do I compile and install it?

Right now I’m trying to get a st7735 SPI-based LCD display working again on my Black. This[1] used to work, but the make no longer works.
What do I need to do so this:

config-pin -a P9_30 spi # Data out
config-pin -a P9_31 spi # Clock

will work? First I want it to work on the Black, then on the Blue.

–Mark

[1] BeagleBoard-exercises/install.sh at master · MarkAYoder/BeagleBoard-exercises · GitHub