Hi John, Thanks for the help, I looked into the iio_generic_buffer.c example and i patched it to disable the hardware triggers thanks to the patch presented on this page : https://www.teachmemicro.com/beaglebone-black-adc/ I am now able to reader a buffer from the different channel. However I have 2 majors questions that remains:
1) I only want to use on channel, then I do not want the ADC to sample the other one so that i'll have the maximum sampling rate. What is the best way to disable the channel? If I do not enable them in iio_generic_buffer.c I am not sure that the ADC is not going to sample this channel or not (well, I think it wont sample but I prefer to be sure). Is it preferable to not mention them on the devicetree so that Linux wont know that there are multiple channels on the ADC? This part is not very clear for me. 2) To change the sample frequency of the ADC you mentioned that it is done using the device tree however I did not find any argument on the ADC devicetree to change the sampling frequency. I read the discussion you had on this post (https://patchwork.kernel.org/patch/9391487/ ) but it is not clear if the frequency setting is done using the kernel module or devicetrees. Could you explain me this please? Thanks a lot Pierrick Le mercredi 28 mars 2018 00:45:01 UTC-4, john3909 a écrit : > > Look at the kernel source under tools/iio for examples on how to use IIO. > > Regards, > John > > > > > > On Mar 27, 2018, at 12:10 PM, pierric...@gadz.org <javascript:> wrote: > > Hi John, > > Sorry for the late answer, I had hard time using the PRUs and I am now > going to use the IIO ADC driver, I am able to read the sample with the cat > command in /sys/bus/iio/devices/iio:device0/in_voltage3_raw > However I am not able to use Libiio in order to read data from a user > space application, I am reading (nil) instead of my data. Do you have any > idea of where does the problem comes from ? > > Here is the code I am using in the user space : > > > #define _BSD_SOURCE > #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; > } > > Thanks > > Pierrick > > > Le lundi 26 février 2018 16:46:11 UTC-5, john3909 a écrit : >> >> The IIO ADC driver can run at 800K samples per second. Here is the patch >> that made that possible. >> >> https://patchwork.kernel.org/patch/9391487/ >> >> I can confirm that I have tested the driver at 800Ksps and it works fine >> as long as you have a proper low impedance source for each ADC channel. CPU >> utilization was about 5% if I recall and that was probably used by the iiod >> daemon, which I used to display the waveform on a remote Linux app. >> >> There is example code in the original Starterware for McSPI, which should >> work fine if you are using the PRU low level drivers. >> >> Regards, >> John >> >> >> >> >> On Feb 26, 2018, at 12:56 PM, pierric...@gadz.org wrote: >> >> Thanks John, >> >> I am now working with the starterware_PRU but i did not find examples for >> using the McSPI with the PRU, do you think it will be hard to adapt the >> initial code to the PRU ? >> By the way, looking to the IIO driver documentation, it seems that for >> the AM335x chip the max sampling rate is only 200k samples per second which >> may not be enough : >> http://processors.wiki.ti.com/index.php/Linux_Core_ADC_Users_Guide ; am >> I right ? >> >> >> Thanks >> >> Pierrick >> >> Le lundi 19 février 2018 23:15:50 UTC-5, john3909 a écrit : >>> >>> Like I said, it was based on Starterware, so search Github for >>> starterware and you will see a project starterware_PRU. It does use the >>> mcspi, so it is not a bitbang implementation. >>> >>> Regards, >>> John >>> >>> >>> >>> >>> On Feb 19, 2018, at 7:33 PM, pierric...@gadz.org wrote: >>> >>> Thanks John for you answer, I was quit busy last week so I worked on >>> this during the Weekend. >>> >>> Unfortunately, I was not able to find a project that is using the SPI >>> and I2C interface with the PRU, I only found this one : >>> >>> https://github.com/chanakya-vc/PRU-I2C_SPI_master/wiki/SPI-Master-Controller >>> >>> But it is using bit banging for the SPI part and not using the on-board >>> pull-up resistors for the I2C part. >>> >>> Concerning the ADC, I'll have a loook at the UIIO drivers in the coming >>> days it seems that it meets my need in term of real-time acquisition. >>> >>> Regards, >>> >>> Pierrick >>> >>> -- >>> 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...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/beagleboard/74949832-b67c-430f-811e-f3b2fff83852%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/beagleboard/74949832-b67c-430f-811e-f3b2fff83852%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit 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...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/beagleboard/3dc611e5-04e7-45bb-87d4-3c21a5665cec%40googlegroups.com >> >> <https://groups.google.com/d/msgid/beagleboard/3dc611e5-04e7-45bb-87d4-3c21a5665cec%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit 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...@googlegroups.com <javascript:>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/18b69929-99ca-4e7e-8539-df962a17941d%40googlegroups.com > > <https://groups.google.com/d/msgid/beagleboard/18b69929-99ca-4e7e-8539-df962a17941d%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit 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. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/940610ad-a88c-4918-a3e2-15d7c88d77d1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
