root@beaglebone:/sys/bus/iio/devices/iio:device0# tree . ├── buffer │ ├── enable │ ├── length │ └── watermark ├── dev ├── in_voltage0_raw ├── in_voltage1_raw ├── in_voltage2_raw ├── in_voltage3_raw ├── in_voltage4_raw ├── in_voltage5_raw ├── in_voltage6_raw ├── name ├── of_node -> ../../../../../../firmware/devicetree/base/ocp/tscadc@44e0d000/adc ├── power │ ├── async │ ├── autosuspend_delay_ms │ ├── control │ ├── runtime_active_kids │ ├── runtime_active_time │ ├── runtime_enabled │ ├── runtime_status │ ├── runtime_suspended_time │ └── runtime_usage ├── scan_elements │ ├── in_voltage0_en │ ├── in_voltage0_index │ ├── in_voltage0_type │ ├── in_voltage1_en │ ├── in_voltage1_index │ ├── in_voltage1_type │ ├── in_voltage2_en │ ├── in_voltage2_index │ ├── in_voltage2_type │ ├── in_voltage3_en │ ├── in_voltage3_index │ ├── in_voltage3_type │ ├── in_voltage4_en │ ├── in_voltage4_index │ ├── in_voltage4_type │ ├── in_voltage5_en │ ├── in_voltage5_index │ ├── in_voltage5_type │ ├── in_voltage6_en │ ├── in_voltage6_index │ └── in_voltage6_type ├── subsystem -> ../../../../../../bus/iio └── uevent
Regards, John > On Mar 18, 2016, at 1:22 PM, Audrey <a...@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 >>> <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+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.
