Hey Dennis, Do you have any insight into whether that PRUDAQ module referenced by Pierrick will work with the Ai without much (if any) modification?
On Tuesday, October 20, 2020 at 9:18:42 AM UTC-6, Dennis Bieber wrote: > > On Tue, 20 Oct 2020 05:33:26 -0700 (PDT), in > gmane.comp.hardware.beagleboard.user > "[email protected]" > <[email protected] <javascript:>> wrote: > > >Hi Denis, > >Thanks for the help and sorry that I only answer now. > >I understand what you mean with the I2C, I tried to change the topic of > the > >post without luck yet. I am starting to work on that with the examples > you > > Well, hopefully you find this post then, as it should have new > subject > line. > > >have provided. Do you think that the PRUDAQ project (here > ><https://github.com/google/prudaq/tree/master/src>) can also be a good > >starting point it seems that he is doing bit-banging on the /src/pru0.p > and > >/src/pru1.p codes? > > Not quite... The PRUDAQ AD9201 is a parallel I/O module. See > https://github.com/google/prudaq/wiki/InputOutput > > PRU0 is bit-banged to generate the sampling rate clock and that is > all > it does, while PRU1 is used to read 10 data (GPIO lines) in parallel for > each sample, and then transfers that sample via shared RAM to the ARM > processor. ALL 10 bits of the sample value are available on each clock > cycle (it appears the first channel on clock HIGH, and second channel on > clock LOW). The chip you are using transfers samples in I2C serial format > so you have to combine the bits into bytes/words before making them > available to whatever processor is going to use them, AND you have to > provide the overhead control data too (the I2C address/command bytes). > > >Finally, I will have a beginner's question about bit-banging: I have read > >that bit-banging is much slower that using an i2c library, but as far as > I > >understand an i2c library is doing the same as bit-banging or am I > missing > >something huge here ? > > There is I2C hardware in the chip itself (block diagram, page > three of > TI SPRS953F; specifications page 269)[page 5716/section 24.1 of the TRM, > SPRUHZ6L]. Just as with UARTs, the kernel passes full bytes (or even more) > to the I2C hardware, and the hardware (essentially a shift register) > handles the serial I/O, only signaling the kernel when it is ready for > more > data (or has received data to give to the kernel). The > kernel/ARM-processor > is not tied up monitoring status pins and looping over the bits in the > data > manipulating I/O pins. > > To have the PRU control the I2C modules would likely require > disabling > them in the ARM kernel (device tree) and, as I recall implying months ago, > writing a "driver" that runs on the PRU which would write to the specific > I2C module control registers (section 24.1.6 of the TRM lists those). > > > -- > Dennis L Bieber > > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/d38a453b-1666-4f1b-9369-9a966b9702e8o%40googlegroups.com.
