05:47 <ds2> set_: I don't care about all the support...just trying to figure out availability. Figure they are cheap breakout boards for the MSP430

09:46 <fuser> Miydoc

13:37 <Siegurd> I’ll answer my own question, you can use pins pru1_pru_r3x_0 and pru1_pru_r31_1 (GPIO_70,

13:37 <Siegurd> GPIO_71

13:37 <Siegurd> ) thanks to the pin multiplexing system.

13:37 <Siegurd> ) simultaneously with PRU1 (GPIO_70) and the C/C++ user space application (GPIO_71

13:39 <Siegurd> oh, something with the program...

13:39 <Siegurd> I’ll answer my own question, you can use pins pru1_pru_r3x_0 and pru1_pru_r31_1 (GPIO_70,

13:39 <Siegurd> <Siegurd> GPIO_71

13:39 <Siegurd> <Siegurd> ) thanks to the pin multiplexing system.

13:39 <Siegurd> <Siegurd> ) simultaneously with PRU1 (GPIO_70) and the C/C++ user space application (GPIO_71

13:40 <Siegurd> sorry

18:30 <zmatt> Siegurd: your question is quite unclear anyway

18:31 <zmatt> a pin can only be muxed to one of its functions at any time, so using a pin in direct pru input (via r31) or output (via r30) is mutually exclusive with using it in gpio mode

18:33 <zmatt> and if muxed to direct pru input/output then that pin is exclusively accessible to that pru. using a pin in gpio mode allows it to be used by linux as well as both pru cores (albeit with higher latency and less timing accuracy than using direct pru i/o)

18:35 <Siegurd> zmatt: does AD7771 uses PRU0 pins or Linux system pins?

18:35 <zmatt> just be careful to not write to any gpio register from PRU other than the SETDATAOUT and CLEARDATAOUT registers

18:37 <zmatt> how would I know what pins you're using to interface to the AD7771 ? and there's no such thing as "Linux system pins"

18:37 <zmatt> nor PRU0 pins for that matter

18:38 <zmatt> some pins have pru0/1 direct input/output modes available as mux modes

18:39 <Siegurd> I'm about ad7771-mcasp0.dtsi from https://github.com/mvduin/overlay-utils

18:39 <zmatt> that uses mcasp0 and has nothing to do with pru

18:43 <zmatt> of course it is definitely a possibility to use pru to receive the signals instead of using mcasp0, or you could use mcasp0 but with pru reading the data directly from mcasp instead of using linux

18:44 <zmatt> (all of these would use completely different DT overlays and software)

18:45 <Siegurd> I thought there is some kind of freeRTOS on PRU which is some kind of interface between Linux and pins and all protocols (SPI, PWM, UART and so on) are made in PRUs. So when overlay is loaded = firmware for PRU is loaded. Glad I was wrong.

18:52 <Siegurd> Another question: why then overlay's exists on BBB if it has PRUs? 1 universal firmware on PRU can solve all communication protocols...

20:11 <zmatt> uhh no.. while pru may be able to emulate certain peripherals, it definitely can't emulate all of them, let alone at their designed performance specs, and most definitely not all at the same time

20:14 <zmatt> also I'm not sure why you imagine you'd want to run something like freertos on pru... I'm not sure it's even possible and it would definitely be incompatible with implementing a software-emulated peripheral since these will generally require very precise timing

20:20 <zmatt> and overlays are just a way to modularize a device tree blob, which is the data strucvture that informs linux about the hardware it's running on and thus which drivers to load and what configuration needs to be done

20:22 <zmatt> if you did have a soft-peripheral implemented by pru (and there are indeed examples of these) then you'd still need an overlay for it as well since otherwise linux has no way of knowing about it

20:36 <Siegurd> zmatt: thanks for clarifying that!

21:24 <ds2> Overlays exists because there are too any idiots who do not understand anything.

21:24 <ds2> Overlays needs to go away =)