PRUs realtime data acquisition, I2C bus and ADC

Hi Pierrick!

Have you tried 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

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 ?

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.

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;
}
`

Yes, you have to reboot every time you modify the overlay, but you should only modify the overlay once.

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

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?

OK, libiio doesn’t work for you. I suggested libpruio.

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 ?

With libpruio you install an universal overlay once in the install process. Afterwards everything gets controlled from userspace, like active channels, sampling rate or avaraging for ADC, but also pinmuxing for digital lines: GPIO, TIMERs, PWM, CAP, QEP. Hardware configuration gets done at a single place, your source code. That makes development much more effective. You need not reboot to change the sampling rate or the active channels, your programm can do that while running.

Regards

Did you figure out access to the i2c registers from within the PRU? I’m working on that at the moment and could use a header file or similar…

Hi all!

john3909: Sir! Your post in this topic halped me a lot and pointed me into right direction,
but I still cannot figure out how to properly load my own version of this BB-ADC-00A0 overlay .
Should I put my version under /lib/firmware with some different name, say /lib/firmware/BB-ADC-00A0.dtbo
and activate it via some key in the uEnv.txt file?
Or should I simply replace original BB-ADC-00A0.dtbo file?
My goal is to increase ADC sampling rate playing with chan-step-opendelay and chan-step-avg parameters.
Please, anybody, help!

My version.sh script returns the following: