**** BEGIN LOGGING AT Sun Sep 15 02:59:57 2019 **** BEGIN LOGGING AT Sun Sep 15 06:44:38 2019 Sep 15 10:11:10 hello, to transfer data between ARM and PRU, is map_prumem the recommended way? Sep 15 10:12:30 you can use either prumem (typically the shared dataram) or extmem, depending on requirements Sep 15 10:15:15 oh I didn't know about extmem Sep 15 10:17:35 (extmem is much larger, but reading it has high and non-deterministic latency. writing to it is usually fine since writes are "fire and forget" Sep 15 10:17:38 ) Sep 15 10:19:48 thank you Sep 15 15:43:37 can the pru directly read the ADC values? Sep 15 15:49:38 you can have pru manage the adc instead of the kernel Sep 15 15:51:36 in which case you should disable the kernel driver for the adc (uncomment disable_uboot_overlay_adc=1 in /boot/uEnv.txt) Sep 15 15:52:21 ok Sep 15 15:52:23 and to avoid having to deal with prcm, you can use a tiny overlay to force-enable the adc => https://pastebin.com/ieWYZANq Sep 15 15:53:52 I hoped to find a one line command that reads the ADC :-) Sep 15 15:54:11 sorry, doesn't work like that :) Sep 15 15:55:48 measurement samples from the adc are written to a fifo, from which they need to be consumed by cpu or dma... this means that you can't have two cpus both reading the data Sep 15 15:56:23 is there a reference document that explains how to deal with it? on the PruReference I don't see mentions on ADC Sep 15 15:56:35 (not to mention that the kernel driver would probably get confused as hell if you try to meddle directly with the adc behind its back) Sep 15 15:56:50 there's no reason to expect anything about the adc in the pru reference since it's not part of pru Sep 15 15:57:22 but pru can access everything on the SoC, including the adc Sep 15 15:59:10 I wouldn't be surprised if code examples for using the adc could be found if you search the web Sep 15 15:59:48 my idea is to create a test project that uses the PRU to read from the ADC and than send it to the ARM a bit like a digital oscilloscope, does it make sense? Sep 15 16:00:51 why not use the kernel driver? I've never really looked at how iio works exactly but I'm pretty sure it should be able to do that (with a bit of luck using dma) Sep 15 16:01:43 I thought the linux kernel was not suitable for that because can be interrupted Sep 15 16:02:12 does it not support dma? Sep 15 16:03:15 also, what sample rate were you hoping to use? Sep 15 16:03:40 I would be happy with 1MHz Sep 15 16:09:51 the adc is specified for 200 Ksps nominally... although it can be configured higher, in theory even as high as 1 MHz... not sure whether you'd get very useful data at such a high rate though Sep 15 16:13:17 anyway, if you're unhappy with the kernel driver you could of course bypass it and manage the adc yourself. if I wanted to do that I'd probably setup the adc from userspace (via uio_pdrv_genirq) and use either edma or pru to transfer the data into a ringbuffer Sep 15 16:14:41 having pru configure the adc is of course also an option **** BEGIN LOGGING AT Sun Sep 15 20:41:11 2019 **** ENDING LOGGING AT Mon Sep 16 03:00:52 2019