Hi, So I finally had the time to upgrade my beaglebone, and it now has this kernel: 4.1.18-ti-r53
However, now, a lot of the directories and stuff have changed. I can't even enable the adc (echo cape-bone-iio > /sys/devices/bone_capemgr.*/slots) because there is no longer any folder called bone_capemgr.9. root@beaglebone:/sys/devices# ls -l total 0 drwxr-xr-x 3 root root 0 Mar 20 17:12 armv7_cortex_a8 drwxr-xr-x 3 root root 0 Mar 20 17:12 breakpoint drwxr-xr-x 21 root root 0 Mar 20 17:12 platform drwxr-xr-x 3 root root 0 Mar 20 17:12 soc0 drwxr-xr-x 3 root root 0 Mar 20 17:12 software drwxr-xr-x 6 root root 0 Mar 20 17:12 system drwxr-xr-x 3 root root 0 Mar 20 17:12 tracepoint drwxr-xr-x 15 root root 0 Mar 20 17:12 virtual The folder armv7_cortex_a8 doesn't have slots and when I tried: echo cape-bone-iio > /sys/devices/armv7_cortex_a8/slots it said permission denied. There is also no longer any iio folder within /sys/bus: root@beaglebone:/sys/bus# ls -l total 0 drwxr-xr-x 4 root root 0 Mar 20 17:12 clockevents drwxr-xr-x 4 root root 0 Mar 20 17:12 clocksource drwxr-xr-x 4 root root 0 Mar 20 17:12 container drwxr-xr-x 4 root root 0 Mar 20 17:12 cpu drwxr-xr-x 4 root root 0 Mar 20 17:12 event_source drwxr-xr-x 4 root root 0 Mar 20 17:12 hid drwxr-xr-x 4 root root 0 Mar 20 17:12 i2c drwxr-xr-x 4 root root 0 Mar 20 17:12 mdio_bus drwxr-xr-x 4 root root 0 Mar 20 17:12 mmc drwxr-xr-x 4 root root 0 Mar 20 17:12 nvmem drwxr-xr-x 5 root root 0 Mar 20 17:12 pci drwxr-xr-x 4 root root 0 Mar 20 17:12 platform drwxr-xr-x 4 root root 0 Mar 20 17:12 scsi drwxr-xr-x 4 root root 0 Mar 20 17:12 sdio drwxr-xr-x 4 root root 0 Mar 20 17:12 serio drwxr-xr-x 4 root root 0 Mar 20 17:12 soc drwxr-xr-x 4 root root 0 Mar 20 17:12 spi drwxr-xr-x 4 root root 0 Mar 20 17:12 usb drwxr-xr-x 4 root root 0 Mar 20 17:12 virtio drwxr-xr-x 4 root root 0 Mar 20 17:12 w1 drwxr-xr-x 4 root root 0 Mar 20 17:12 workqueue On Saturday, March 19, 2016 at 4:15:04 PM UTC-4, john3909 wrote: > > Yeah, that is what I thought. IIO on the 3.8 kernel didn’t have a lot of > features and this is why you are having difficulty using it. I would > recommend upgrading to the 4.1 kernel or even the 4.4 kernel. I personally > use the 4.1 kernel, but I back ported IIO from the IIO-next kernel so that > I am using the latest IIO which includes DMA framework support. > > Regards, > John > > > > > On Mar 19, 2016, at 9:46 AM, Audrey <ao...@smith.edu <javascript:>> wrote: > > Hi William, I did read that article you sent me. I was unable to follow > the Driver Configuration bit, but as far as the continuous mode is > concerned, after careful re-reading of the article, I think I understand > that you are trying to tell me that I should be in the /dev/iio:device0 > directory to read the continuous mode. However, my problem is that buffer, > scan_elements, and mode, which the article says are used to set up the > continuous mode, should be in the /sys/bus/iio/devices/iio:device0 > directory. And that was where I was in, but I could not find them, which is > my current problem. > > John3909, my kernel version is 3.8.13-bone70. > > I think if this doesn't pan out, I will be looking into using the PRU, > although I would like to understand the current system better before moving > on to something more complicated. > > Thanks everyone for your help! > > On Friday, March 18, 2016 at 5:59:01 PM UTC-4, William Hermans wrote: >> >> Audrey, >> >> Please read the link I gave you a couple weeks ago . . . >> http://processors.wiki.ti.com/index.php/AM335x_ADC_Driver's_Guide#Continuous_Mode >> >> Everything you need to know to use the ADC is explained on this page. But >> from your last post, and the paths you've shown us. You're in the wrong >> directory. Essentially, you're still in the one-shot directories, which are >> completely separate from the continuous mode directory structure. >> >> On Fri, Mar 18, 2016 at 1:46 PM, John Syne <john...@gmail.com> wrote: >> >>> What is your kernel version? >>> >>> Regards, >>> John >>> >>> >>> >>> >>> On Mar 18, 2016, at 1:22 PM, Audrey <ao...@smith.edu> wrote: >>> >>> It says: >>> root@beaglebone:/# echo 1 > >>> /sys/bus/iio/devices/iio:device0/scan_element/in_voltage0_en >>> -bash: /sys/bus/iio/devices/iio:device0/scan_element/in_voltage0_en: No >>> such file or directory >>> >>> and I can't find scan_elements in sys/bus/iio/devices/iio:device0 >>> root@beaglebone:/sys/bus/iio/devices/iio:device0# ls -l >>> total 0 >>> -r--r--r-- 1 root root 4096 Mar 1 21:13 dev >>> -rw-r--r-- 1 root root 4096 Mar 1 21:13 in_voltage0_raw >>> -rw-r--r-- 1 root root 4096 Mar 1 21:13 in_voltage1_raw >>> -rw-r--r-- 1 root root 4096 Mar 1 21:13 in_voltage2_raw >>> -rw-r--r-- 1 root root 4096 Mar 1 21:13 in_voltage3_raw >>> -rw-r--r-- 1 root root 4096 Mar 1 21:13 in_voltage4_raw >>> -rw-r--r-- 1 root root 4096 Mar 1 21:13 in_voltage5_raw >>> -rw-r--r-- 1 root root 4096 Mar 1 21:13 in_voltage6_raw >>> -rw-r--r-- 1 root root 4096 Mar 1 21:13 in_voltage7_raw >>> -r--r--r-- 1 root root 4096 Mar 1 21:13 name >>> drwxr-xr-x 2 root root 0 Mar 1 21:13 power >>> lrwxrwxrwx 1 root root 0 Mar 1 20:47 subsystem -> >>> ../../../../../bus/iio >>> -rw-r--r-- 1 root root 4096 Mar 1 20:47 uevent >>> >>> >>> On Friday, March 18, 2016 at 4:15:00 PM UTC-4, john3909 wrote: >>>> >>>> >>>> On Mar 18, 2016, at 1:06 PM, Audrey <ao...@smith.edu> wrote: >>>> >>>> Hm. >>>> >>>> Sorry, but unfortunately I'm still quite a bit lost. What should I be >>>> doing to dev/iio:device0 (open?) in order to do the following: >>>> echo 1 > in_voltage0_en >>>> >>>> From memory, >>>> >>>> echo 1 > /sys/bus/iio/devices/iio:device0/scan_element/in_voltage0_en >>>> >>>> echo 1 > buffer/enable >>>> >>>> echo 1 > /sys/bus/iio/devices/iio:device0/buffer/enable >>>> >>>> Regards, >>>> John >>>> >>>> >>>> I'm assuming that I should be able to see in_voltage0_en and buffer in >>>> the folder /sys/bus/iio/devices/iio:device0 but I currently do not see >>>> those attributes/drivers/folders/buffers/whatever-you-want-to-call-them. >>>> >>>> Typing >>>> root@beaglebone:/dev# open iio:device0 >>>> doesn't seem to do anything. >>>> >>>> Do you think you could break your steps down even further? >>>> >>>> Thanks. >>>> >>>> On Friday, March 18, 2016 at 3:49:39 PM UTC-4, john3909 wrote: >>>>> >>>>> It is a driver, so you can open, poll and read from /dev/iio:device0 >>>>> >>>>> For a quick test, do the following: After you enable the various >>>>> scan_channels, start the buffer and then do the following: >>>>> >>>>> dd if=/dev/iio:device0 of=~/test.txt >>>>> >>>>> Press ctrl-C to stop capture. >>>>> >>>>> Use hexdump to view the file. >>>>> >>>>> Regards, >>>>> John >>>>> >>>>> >>>>> >>>>> >>>>> On Mar 18, 2016, at 12:37 PM, Audrey <ao...@smith.edu> wrote: >>>>> >>>>> It says: >>>>> root@beaglebone:/dev# cd iio:device0 >>>>> -bash: cd: iio:device0: Not a directory >>>>> root@beaglebone:/dev# cat iio:device0 >>>>> cat: iio:device0: Invalid argument >>>>> >>>>> >>>>> On Friday, March 18, 2016 at 3:25:13 PM UTC-4, john3909 wrote: >>>>>> >>>>>> The buffer is available here: >>>>>> >>>>>> /dev/iio:device0 >>>>>> >>>>>> Because the driver uses interrupts, you won’t get the speed you want. >>>>>> The driver has to be updated to use DMA if you want to use full speed. >>>>>> Reading from the buffer will reduce your CPU load compared to using >>>>>> LDR_PATH because this interface blocks until a sample is available, but >>>>>> not >>>>>> long enough for the thread to sleep. To use DMA, IIO have introduced a >>>>>> DMA >>>>>> framework and most of what you need is already available. However, IIO >>>>>> are >>>>>> going to be updating the IIO DMA framework to do zero copy between the >>>>>> kernel module and the socket interface, using MMU maps. >>>>>> >>>>>> Regards, >>>>>> John >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Mar 18, 2016, at 11:21 AM, Audrey <ao...@smith.edu> wrote: >>>>>> >>>>>> Hi everyone, >>>>>> >>>>>> First of all, thank you everyone for trying to help me. I appreciate >>>>>> everyone's input. >>>>>> >>>>>> I took everyone's advice, and have moved away from bash to C++. It's >>>>>> clocking at about 2 milliseconds, but I would really like it to go down >>>>>> into the microsecond range: >>>>>> >>>>>>> /** Simple LDR Reading Application >>>>>>> * Written by Derek Molloy for the book "Exploring BeagleBone: Tools >>>>>>> and >>>>>>> * Techniques for Building with Embedded Linux" by John Wiley & Sons, >>>>>>> 2014 >>>>>>> * ISBN 9781118935125. Please see the file README.md in the >>>>>>> repository root >>>>>>> * directory for copyright and GNU GPLv3 license information. >>>>>>> */ >>>>>>> >>>>>>> #include<iostream> >>>>>>> #include<fstream> >>>>>>> #include<string> >>>>>>> #include<sstream> >>>>>>> using namespace std; >>>>>>> >>>>>>> #define LDR_PATH "/sys/bus/iio/devices/iio:device0/in_voltage" >>>>>>> >>>>>>> int readAnalog(int number) >>>>>>> { >>>>>>> stringstream ss; >>>>>>> ss << LDR_PATH << number << "_raw"; >>>>>>> fstream fs; >>>>>>> fs.open(ss.str().c_str(), fstream::in); >>>>>>> fs >> number; >>>>>>> fs.close(); >>>>>>> return number; >>>>>>> } >>>>>>> >>>>>>> int main(int argc, char* argv[]) >>>>>>> { >>>>>>> cout << "Starting the readLDR program" << endl; >>>>>>> int value; >>>>>>> int i=1; >>>>>>> while (true) >>>>>>> { >>>>>>> float value = (float)readAnalog(0)/4095*1.8; >>>>>>> cout <<"V= " << value << endl; >>>>>>> cout << i << endl; >>>>>>> i++; >>>>>>> } >>>>>>> return 0; >>>>>>> } >>>>>>> >>>>>> >>>>>> Thank you TJF for pointing me to libpruio. I'll use it later if I >>>>>> need it, but for now I rather not use the PRU if I don't need to. >>>>>> >>>>>> So I noticed this thing where I can't see the buffer, or >>>>>> scan_elements, or mode in iio:device0, and I wonder if I'm not enabling >>>>>> the >>>>>> adc dto properly or something: >>>>>> >>>>>>> root@beaglebone:/sys/bus/iio/devices/iio:device0# ls -l >>>>>>> total 0 >>>>>>> -r--r--r-- 1 root root 4096 Mar 1 20:51 dev >>>>>>> -rw-r--r-- 1 root root 4096 Mar 1 22:03 in_voltage0_raw >>>>>>> -rw-r--r-- 1 root root 4096 Mar 1 22:03 in_voltage1_raw >>>>>>> -rw-r--r-- 1 root root 4096 Mar 1 22:03 in_voltage2_raw >>>>>>> -rw-r--r-- 1 root root 4096 Mar 1 22:03 in_voltage3_raw >>>>>>> -rw-r--r-- 1 root root 4096 Mar 1 22:03 in_voltage4_raw >>>>>>> -rw-r--r-- 1 root root 4096 Mar 1 22:03 in_voltage5_raw >>>>>>> -rw-r--r-- 1 root root 4096 Mar 1 22:03 in_voltage6_raw >>>>>>> -rw-r--r-- 1 root root 4096 Mar 1 22:03 in_voltage7_raw >>>>>>> -r--r--r-- 1 root root 4096 Mar 1 20:51 name >>>>>>> drwxr-xr-x 2 root root 0 Mar 1 20:51 power >>>>>>> lrwxrwxrwx 1 root root 0 Mar 1 20:50 subsystem -> >>>>>>> ../../../../../bus/iio >>>>>>> -rw-r--r-- 1 root root 4096 Mar 1 20:50 uevent >>>>>> >>>>>> >>>>>> This is what I've been doing to "enable" the adc (although I don't >>>>>> really know what it is doing. I can't find the file cape-bone-iio in >>>>>> bbb, >>>>>> and if I try echo cape-bone-iio > test.txt, it is just a regular >>>>>> string.): >>>>>> echo cape-bone-iio > /sys/devices/bone_capemgr.*/slots >>>>>> >>>>>> I tried searching for /driver/iio/adc/ti_am335x_adc.c, but I can't >>>>>> find it (there's nothing in root@beaglebone:/sys/bus/iio/drivers#). >>>>>> Could >>>>>> you perhaps specify the full filepath? >>>>>> >>>>>> Thanks. >>>>>> >>>>>> -- >>>>>> For more options, visit http://beagleboard.org/discuss >>>>>> --- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "BeagleBoard" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to beagleboard...@googlegroups.com. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>>> >>>>>> >>>>> -- >>>>> For more options, visit http://beagleboard.org/discuss >>>>> --- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "BeagleBoard" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to beagleboard...@googlegroups.com. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>>> >>>>> >>>> -- >>>> For more options, visit http://beagleboard.org/discuss >>>> --- >>>> You received this message because you are subscribed to the Google >>>> Groups "BeagleBoard" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to beagleboard...@googlegroups.com. >>>> <span style="font-family:He >>>> >>>> -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
