> On May 21, 2018, at 6:20 AM, [email protected] wrote: > > Hi John, > Thanks for the answer, I did use u-boot overlays and setup the uEnv.txt to > load the right overlay. BTW, I am rebooting the BeagleBone every-time I want > to load a new overlay, can you confirm that it's the only way to do it ? Yes, you have to reboot every time you modify the overlay, but you should only modify the overlay once. > > I'll try to use the IIO Oscilloscope, however as I have access to a "real" > oscilloscope so I am not sure to understand how it can help me... > Finally, I think I've found my mistake this weekend. The input voltage was to > low (i've built a tension divider bridge between the generator and the input > of the ADC...)so basically I was measuring noises. However, do you know if > there is an auto-scale on the iio driver, indeed the "noises" where scaled to > the entire range of the ADC. The IIO Oscilloscope (OSC) is just an easy way to see that the IIO driver is working correctly. As you modify this input, you can see the waveform update on the OSC dynamically. So the way this works, the ADC driver reads the analog inputs and forwards them to the IIO buffer. The IIOD (iio deamon provided by the libiio repo [1]) makes the IIO sysfs and buffer available over TCP/IP. The OSC running on your host PC connects to the IIOD running on your BBB so that it can display all the info from the ADC driver. You can enable channels, display waveforms of one or more channels and also display FFT of these waveforms.
1 https://github.com/analogdevicesinc/libiio <https://github.com/analogdevicesinc/libiio> Regards, John > > TJF, > Thanks for the help,I tried to use libiio but i was not successful when it > came to read the data, i was read (nil) instead of my data (I am adding the > code I was using at the end of this message). That is why I change and used > the iio_generic_buffer.c example. BTW, is libpruio working with the latest > kernels, remoteproc and rpmsg? > > #define _GNU_SOURCE > #define _DEFAULT_SOURCE > > #include <cdk/cdk.h> > #include <locale.h> > #include <pthread.h> > #include <stdbool.h> > #include <unistd.h> > #include <stdint.h> > #include <stdio.h> > #include <string.h> > > #ifdef __APPLE__ > #include <iio/iio.h> > #else > #include <iio.h> > #endif > > struct iio_context *ctx; > struct iio_device *dev; > struct iio_channel *ch; > > int main() > { > ctx = iio_create_default_context(); > dev = iio_context_get_device(ctx, 0); > ch = iio_device_get_channel(dev, 3); > > > iio_device_attr_write_ > longlong(dev, "sample_rate", 100); > iio_channel_attr_write_double(ch, "scale", 1); > > iio_channel_enable(ch); > > char *a = iio_device_get_data(dev); > printf("%p\n", a); > > iio_channel_disable(ch); > > return 0; > } > > > > Le samedi 19 mai 2018 23:52:13 UTC-4, TJF a écrit : > Hi Pierrick! > > Have you tried libpruio <http://github.com/dtjf/libpruio> yet? It makes one > PRU fetching samples from the internal ADC. Parameters are controled from the > ARM side. Everything can get configured in user space (sampling rate, active > channels, avaraging, and more). Device tree action is only necessary once in > the install process. This make programming and testing much more easy. > > For the ADC, my future application is going to be time critical, by this I > mean that I want to sample data at around 5khz to 10khz. Is the IIO driver > able to execute real-time data acquisition while the ARM is processing the > data? > > In such a case I'll start with ADC input by libpruio and a controller loop on > the ARM. When real-time requirements cannot get fulfilled, the controller > loop can get shifted to the second PRU later in the development process. > > Regards > > -- > 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 [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/9f646186-6e07-4e64-a9cc-65b1704ae9a2%40googlegroups.com > > <https://groups.google.com/d/msgid/beagleboard/9f646186-6e07-4e64-a9cc-65b1704ae9a2%40googlegroups.com?utm_medium=email&utm_source=footer>. > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/588E6C1B-EA2F-48F6-9FA0-96954A6CDC9F%40gmail.com. For more options, visit https://groups.google.com/d/optout.
