On Tue, 20 Oct 2020 05:33:26 -0700 (PDT), in
>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
>have provided. Do you think that the PRUDAQ project (here
>) can also be a good
>starting point it seems that he is doing bit-banging on the /src/pru0.p and
Not quite... The PRUDAQ AD9201 is a parallel I/O module. See
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