On Feb 13, 2018, at 9:49 AM, pierric...@gadz.org wrote:Hi all,
I am trying to use the PRUs for real time data acquisition on the Beaglebone black (Linux debian 4.9.45-ti-r57). I have set up the PRU with remoteproc and RPMsg; everything is working fine.
The first time, I successfully captured data with the PRU using the SPI protocol and bit banging, and I have sent them to the ARM with RPMsg.
Now I want to do the same thing using the I2C protocol, which left me with some questions:
- Is it possible to use the on-board I2C bus with the PRUs?
- If not, I will enable the pull-up resistor on a GPIO pins using a custom device tree. But after that, I do not really understand how I can read and write the SDA line for I2C? (Contrary to the SPI protocol, I won't have Data In and Data out lines but only one SDA line).
My final goal will be to use the on-board ADC. There is already a very interesting project PRUADC that captures data using an external ADC. I would like to use the on-board ADC, is there any way to do it ? (I am not afraid of going into complex stuff).
Thanks,
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/ed0d2be5-9c7f-4fe1-8e79-1f494bde023b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
On Feb 13, 2018, at 1:55 PM, pierric...@gadz.org wrote:Thank you for your quick answerJohn!
So if I understand well, I can use the PRUs with the on-board SPI and I2C interface ? I have not found any similar project that can help me on this. Is it done using the L2 and L3 interconnect ? I am highly interested by using those on board interface with the PRUs, but it seems that I still need to learn a lot about this.
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?
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/8d0c8de1-659d-4b07-9d0a-4a284619992b%40googlegroups.com.
--
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.
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 :
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/3dc611e5-04e7-45bb-87d4-3c21a5665cec%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/18b69929-99ca-4e7e-8539-df962a17941d%40googlegroups.com.
On Apr 11, 2018, at 6:04 AM, pierric...@gadz.org wrote: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?
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/940610ad-a88c-4918-a3e2-15d7c88d77d1%40googlegroups.com.
On Apr 11, 2018, at 6:04 AM, pierric...@gadz.org wrote:
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?
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/940610ad-a88c-4918-a3e2-15d7c88d77d1%40googlegroups.com.
On Apr 16, 2018, at 3:40 PM, pierric...@gadz.org wrote:
Hi John,
Thanks a lot for this very complete answer ! I think I understand it now, the last point I am not sure about is:
ti,chan-step-avg = <1 1 1 1 1 1 1 1> /* 2 sample average */
I went through 12.3.3 of the AM3358 Technical Reference Manual and it seems that the setting the averaging value to 1 disable the averaging (instead of setting it to 2) am I right?
Thanks again for your help
If you look in the AM3358 TRM, it says 0 will disable averaging and 1 will average over two samples.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/ef59523c-02ab-4c58-992a-2b37c0744ff0%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/54c182f4-07cc-4d61-ac1a-6cfd077eec53%40googlegroups.com.
<8 average sin1hz 1000sample.png><8 average 20kHz.png><iio_generic_buffer_back.c>
On May 18, 2018, at 4:57 PM, pierric...@gadz.org wrote:
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/54c182f4-07cc-4d61-ac1a-6cfd077eec53%40googlegroups.com.
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?
On May 21, 2018, at 6:20 AM, pierric...@gadz.org 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 ?
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.
--
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/9f646186-6e07-4e64-a9cc-65b1704ae9a2%40googlegroups.com.
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?
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 ?
git:/opt/scripts/:[1aa73453b2c980b75e31e83dab7dd8b6696f10c7]
eeprom:[A335BNLT00C01018BBBK009B]
model:[TI_AM335x_BeagleBone_Black]
dogtag:[BeagleBoard.org Debian Image 2018-10-07]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 2018.09-00002-g0b54a51eee]:[location: dd MBR]
kernel:[4.14.71-ti-r80]
nodejs:[v6.16.0]
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[uboot_overlay_addr0=/lib/firmware/BB-W1-P9.12-00A0.dtbo]
uboot_overlay_options:[disable_uboot_overlay_video=1]
uboot_overlay_options:[disable_uboot_overlay_audio=1]
uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade <pkg>]
pkg:[bb-cape-overlays]:[4.4.20190215.0-0rcnee0~stretch+20190215]
pkg:[bb-wl18xx-firmware]:[1.20180517-0rcnee0~stretch+20180517]
pkg:[kmod]:[23-2rcnee1~stretch+20171005]
pkg:[librobotcontrol]:[1.0.4-git20190107.0-0rcnee0~stretch+20190108]
pkg:[firmware-ti-connectivity]:[20180825+dfsg-1rcnee1~stretch+20181217]
groups:[debian : debian adm kmem dialout cdrom floppy audio dip video plugdev users systemd-journal i2c bluetooth netdev cloud9ide gpio pwm eqep admin spi tisdk weston-launch xenomai iio]
cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 quiet]
dmesg | grep pinctrl-single
[ 1.131658] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568
dmesg | grep gpio-of-helper
[ 1.143650] gpio-of-helper ocp:cape-universal: ready
END