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 <a...@smith.edu> 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 > > <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 <javascript:>> > wrote: > What is your kernel version? > > Regards, > John > > > > >> On Mar 18, 2016, at 1:22 PM, Audrey <ao...@smith.edu <javascript:>> 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 >>>> <http://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 >>>>> <http://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 >>>>> <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 <http://googlegroups.com/>. >>>>> For more options, visit https://groups.google.com/d/optout >>>>> <https://groups.google.com/d/optout>. >>>> >>>> >>>> -- >>>> For more options, visit http://beagleboard.org/discuss >>>> <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 >>>> <https://groups.google.com/d/optout>. >>> >>> >>> -- >>> For more options, visit http://beagleboard.org/discuss >>> <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 >>> <https://groups.google.com/d/optout>. >> >> >> -- >> For more options, visit http://beagleboard.org/discuss >> <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 <javascript:>. >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. > > > -- > For more options, visit http://beagleboard.org/discuss > <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 <javascript:>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. > > > -- > For more options, visit http://beagleboard.org/discuss > <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 > <mailto:beagleboard+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout > <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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
