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 <javascript:>> 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 <javascript:>.
> 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.
