I'm trying to write a program that reads the internal NanaosG20 ADC. I enabled the ADC in the kernel and with the test program on the http://www.armbedded.eu/node/339 page I can see that the ADC works. The test program uses the ADC in streaming mode by using the device file /dev/adc. I want to read a single value using the device file /sys/class/misc/adc/chn_value. When using the chn_value device file I see that the values from the device are decimal (as descript). However the low nibble of the ADC MSB and LSB that represent the ADC value only have a range between 0 and 9 (values from the ADC run more or less between 0 and 99). This means that the resolution is no longer 10 bit but far less.
Can someone confirm this?
ADC question
Submitted by rh on Sat, 10/29/2011 - 17:11
Re: ADC question
If you read from /sys/class/misc/adc/chn_value files you will indeed get the current values in ASCII format. However, these values are not limited to two byte values but are representing a whole string terminated by linefeed ("%d\n"). So a program should read one line (e.g. via getline) and convert it into a number (see: atoi). The resulting number is in selected range (8 or 10 bit).
Example:
/* ... */ FILE *ch0_fd; char *line; size_t n; int value; /* ... */ ch0_fd = fopen("/sys/class/misc/adc/ch0_value", "r"); line = NULL; n = 0; if(getline(&line, &n, ch0_fd) > 0) value = atoi(line); fclose(ch0_fd); if(line != NULL) free(line); /* ... */Re: ADC question
Works! Thanks for the info.
Re: ADC question
It works but there's still something nagging. If I want to read values from the ADC, using the above solution, I have to repeatedly open ch0_value, read the characters and close the device. Same procedure is needed when reading I/O pins. With other boards, similair to the NanosG20, I could open a device and use 'rewind(fs)' to update the status of the device. When using rewind on the NanosG20 the status of the device is not updated. Is this normal behavior or do I miss something?
Re: ADC question
Yes, this is normal behaviour since no fseek syscall is implemented inside the driver yet. I cannot promise that this will be implemented in the near future. However, this seems to be an useful feature.