This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

tiadc: cat: read error: Device or resource busy

I've two apps,

1. while usleep 10; do cat /sys/bus/iio/devices/iio:device0/in_voltage0_raw; done;

2. while usleep 10; do cat /sys/bus/iio/devices/iio:device0/in_voltage1_raw; done;

I get "cat: read error: Device or resource busy"

The above error arises when "found" variable in drivers/iio/adc/ti_am335x_adc.c - tiadc_read_raw() function is not updated to "true" state from "false" state". This function returns -EBUSY.

 

"If only one of  the Apps is run , it works fine."

I searched online and found the same issue reported by others but there is no solution. Is anybody aware of what causes this error and solution?

Regards,

Gangadhar

  • Hi,

    What processor and Linux version is that?

  • Hi,
    Processor - AM335x, linux-3.12, tisdk - 7.0

    Regards,
    Gangadhar
  • Hi Gangadhar,

    The problem your going to run into is that the ADC IP when taking a sample is completely busy until it is done taking the sample. This means if you try to read the value from another ADC channel  while the ADC IP is still processing your previous request then the second read will fail. Using your current approach the only way to avoid the issue is to insure that your only reading from one channel at a time.

    Using something like a mutex would be one way to insure that only one channel is being read at a time which will avoid that error. Since you say you have two separate applications then it makes things alot harder. A bit more involved approach would be to using a library like DBUS which is made for interprocessor communication. Some sort of handshaking can then be used between the two programs. Another approach is to simply try to do a read and if it fails go to sleep for x amount of microseconds and try again. Microseconds are a relatively short time so the length of your usleep may need to be played around with.

    A third less complicated solution would be to have a shell script/program handle sampling both channels and maybe write it to two separate files. Your other programs can then just read those files to get the latest value but you avoid the synchronization issues.

    The issue your facing is more of a limitation of the IP when trying to take a single sample using the one shot mode (manually taking a sample at a time).

  • Hi Franklin,

    Thanks. Please also find solution to other ADC post - resource temporarily unavailable.

    Regards,

    Gangadhar