What's the current way to access the analog input ADC values? Everything I find online refers to capemanager, which apparently no longer exists. At least, there's no capemgr under /sys in my Debian/3.14.22 system.
TIA,
http://elinux.org/Beagleboard:Capes_3.8_to_3.14#Custom_dtb
See this example:
Location of the analog outpus are the same in userspace as in 3.8
Regards,
Hello Rick,
there’s also libpruio. It can sample at higher speed than the sysfs solution. And you can configure the ADC device and its steps.
Hi,
I tried the libpruio solution with kernel 3.14.xx but there is no capemanager. So I couldn’t install libpruio.
The only way getting the adc to work was to go back to kernel 3.8.xx with the help of Robert Nelson
sudo apt-get update
sudo apt-get install linux-image-3.8.13-bone67
sudo reboot
Now I am using kernel 3.8.13 and Blacklib (http://blacklib.yigityuce.com/index.html)
libpruio doesn’t depend on capemgr, there’s no need for capemgr at all! It’s just convenient to use it to load the overlay at boot time. You also can load the overlay manually. Or use the file /etc/rc.local, where you can execute commands like
`
echo libpruio > /sys/devices/bone_capemgr.*/slots
(/bin/sleep 1 && /bin/chgrp pruio /dev/uio5)
(/bin/sleep 1 && /bin/chmod g+rw /dev/uio5)
`
to load the overlay and configure write access to the interrupt /dev/uio5 for members of group pruio.
But there is no /sys/devices/bone_capemgr.*/slots because there’s no capemanager.
How to load it in this case?
I didn’t know that. What does the manual say? How to load any device tree overlay in that case? (uEnv.txt command?) The same way should work for libpruio-00A0.dtbo as well.
But there is no /sys/devices/bone_capemgr.*/slots because there’s no capemanager.
Ok, I can not give you exact steps, because I have not done this myself ( I still use 3.8.x too ) but you would load the device tree file from uEnv.txt.
Something like dtb=somedtbfilename.extension and in this case you would probably use Charles’ universal IO https://github.com/cdsteinkuehler/beaglebone-universal-io and once loaded you configure the pins ( on the fly ) from the command line.
Maybe I’ll do this on one of our elemental14 board, document it, and put up a new post on my blog which hasnt had attention in over a year . . .
You can use this overlay, but there’re some downsides. Ie. the overlay enables all devices (SPI, UART, …). And configuring the pins needs extra command line activity, some pin configurations don’t match the libpruio requirements. I recommend to use libpruio-00A0.dtbo instead, which works in the same principle but provides run-time pinmuxing capability.
Either would work fine. Just trying to put the “concept” out there so people know what to look for information wise. What device tree is loaded is up to the individual user. Also technically I think Charles’ universal IO overlay, is actually several overlays with 3-4 different options.
This is what I’ve read over the past several months, and since it is something of interest to me . . . somehow it was retained in my memory . . .
I would be eternally grateful if you did this.
I would be very interested in your post or some information how this all works for newer kernels.
Just so both of you know, I’ve seen Robert mention that cape universal, or Charles’ universal io “capes” come preinstalled on the latest images. So, they should just work already.
Now do keep in mind guys, I’m pretty sure there are soem things on kernel3.14.x that have not been fixed yet, and stuff liek ADC may not work. That i can not do anything about . . .
Thanks for this, Robert. I've been poking at it since yesterday, and I'm not at all sure I understand what I need to do. I built the dtbs from your repo. Is it enough to copy the am335x-boneblack.dtb (its .dts includes the proto cape example .dtsi), and update uEnv.txt to point to that?
Rick, i’m going through the whole process my self right now. For the first time. I’m confident I’ll be able to get all the info you need so you should be able to step by step copy paste setup.
However, what I am not sure of is exactly what all is enabled as this point in time cape wise. ADC, I2C, UARTs, PWM, etc. But I can experiment some, and show you how to experiment too in the process, As an aside, I have no circuitry or physical capes to test much, but I should be able to provide enough information for you to learn how to do this on your own ( beaglebone side ). Then if you have physical circuitry on hand, you should be golden.
Right now, im dding the console image to an sdcard, next step is booting it up, and upgrading to 3.14.x via APT. My notes thus far as very verbose, so should show others who are unfamiliar with the process of experimentation how it is done. At least how I do it.
Thanks! I don't intend to use any "real" capes, just a proto cape to make it easier to solder wires to it. I might add some voltage regulators, etc. But for testing the ADC, it's enough to stick the wires off a potentiometer into the pin sockets.
Someday, I want to make a proper cape with audio output and amplifier capable of driving small speakers, but for now I just need to get to where I can read the ADC. I've got a neat project idea that's stalled until then, and I need to finish it by the end of the year.
(The remaining issue I have has to do with audio glitces, no idea how to track that down, and I haven't found any helpful forum online.)
Do you think libpruio will be able to work with your changes?
Is it possible to test these things from bonescript? It seems like it's able to enable these things, but I don't really understand how it all fits together. I know of at least one reference online that uses the bonescript repo as the authoritative source for device descriptions.
Technically anything that is accessible from sysfs should be accessible via Nodejs. I dont know what all Jason does with bonescript, I shy away from it as its just another abstraction layer I personally do not need. I use “stock” Nodejs, and have not done much with it yet, but am able to execute a binary that queries a USB thermometer, and spit that information out to a local network webpage via socket.io.
Do you think libpruio will be able to work with your changes?
I am not really changing anything, just piecing together a bunch of information spread out all over the web, and adjusting things as needed to make it work for me( us ).
Mostly, I’m exploring / experimenting. Generally I’m pretty good at troubleshooting, so if there are any pitfalls along the way, I may / may not convey that in my notes / blog, but I will put the working stuff that i find out there for others to read.
As far as libpruio goes, it should just be a copy / paste replacement for whatever device tree files I use during my findings. But, I can not guarantee that of course, as I have no idea YET how much universal io is integrated into the boneblack images.
Everything I’ve read seems to indicate that dtb= in uEnv.txt should work. But since i’ve been posting about / talking on thiese point in the groups here, I figured I had better go see for myself. As technically I have been just been going by what I’ve been reading on these groups. Albiet form reliable people, but . . .You never know.
BTW, this may take me a few days as I have real life obligations over the next month or so, and I’ll be traveling next week so it could take some time. But if you’re in no hurry, I’ll have some information out soon-ish, I hope