Audrey, Also, if you need your samples to be taken precisely at <some time frame> apart. You'll have to use a PRU - Period. Linux is good for determinism at around 200ms, which often times Linux *is* faster, but it's not guaranteed, The PRU's on the other hand run outside of Linux( bare metal essentially ), and can be very precise timing wise.
SO with using the PRUs, sometimes it's not about how fast you need something, but how deterministic you need something. On Fri, Mar 18, 2016 at 2:56 PM, William Hermans <yyrk...@gmail.com> 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 <john3...@gmail.com> wrote: > >> What is your kernel version? >> >> 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> 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. >>> 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+unsubscr...@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+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
