> On Mar 18, 2016, at 1:06 PM, Audrey <a...@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+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.

Reply via email to