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
echo 1 > buffer/enable
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 <javascript:>>
> 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 <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.
