PRU - ADC on BBAI

GoogleGroups
1

Hi All,

I am trying to implement deterministic data acquisition on the Beaglebone AI.

I was thinking of using the PRU with the ADC as it is done on one the TechLab example analogIn.pru0.c, however, as the BBAI is not based on the AM335x chip the STMPE811QTR ADC needs to be interfaced with the PRU through I2C and I am not quite sure how to achieve that. I have checked Mark Yoder’s PRU cookbook without luck and I do not find any PRU example specific to the ADC on the Beaglebone AI. I would like to know where I can find example of the use of I2C bus with the PRU and the configuration of the ADC of the Beaglebone AI.
Thanks,
Pierrick

2

I'm afraid I don't have an answer -- but I have to comment that your
query itself (and subject line) is somewhat misleading. Especially as you
state "configuration of the ADC of the Beaglebone AI" -- since the BBAI
(and BBB) have built-in on-board ADC capability which CAN be accessed from
the PRU (and lots of hits in Google on just that)

  However, your mention of an STMPE811 (the datasheet calls it an "8-bit
port expander with advanced touchscreen controller") indicates that
specifying ADC is a red-herring. Your REAL question becomes:

      PRU - I2C on BBAI

  Given the date, this
https://github.com/chanakya-vc/PRU-I2C_SPI_master/wiki is BBB related. It
also appears to be an attempt to use the PRU as an additional I2C (or SPI)
master -- the PRU implementing the communication protocol via
"bit-banging"; not having the PRU access the native I2C of the SoC.

  The closest I've found for having a PRU command the system I2C is
https://groups.google.com/forum/#!topic/beagleboard/QjjoNglpJ8s and a
school project at
<http://iis-projects.ee.ethz.ch/index.php/Control_an_external_ADC_using_Programmable_Real-Time_Unit_(PRU)_Subsystem_on_Beaglebone_Black_used_as_embedded_HPC-performance-monitoring_device>
which appears to still be looking for a student to do the implementation
"""
Status: Available
    Looking for 1 Master Students (Semester Project)
"""
(If it has been worked, the results appear to not be available openly)

  Remember, the full name for the PRU is PRU-ICSS, and the ICSS part is
"industrial communication sub-system" -- ie; one writes the communication
protocol to run /on/ the PRU.

3

Hi Denis,

Thanks for your answer, I agree with you that both boards have an ADC. I think my initial message was miss-leading.

The main difference is that the Beaglebone Bone Black is based on the ti-am335x which as a built-in ADC (tsc-adc module), for this configuration there is indeed many examples as the ones you mentioned. However, when it comes to the Beaglebone AI, it is based on the ti-am5729 which does not have an on chip ADC, so the ADC of the Beaglebone AI is on board (an STMPE811) and interfaced via I2C with the am5729 chip, at least this is what I understood from this diagram (page 18). This is why I am looking to interface the BeagleBone AI to the ADC via I2C because it is the way it is wired on the Beaglebone AI.

Pierrick

4

I'd somehow missed that the BBAI ADC was "external" -- turns out the
ADC mentions in the TRM are just for the internal temperature readings.

  In either case, I still believe the concern is not really with the ADC
chip, but with getting I2C communication from the PRU. And based on my
searches -- it just isn't done.

  There is no OS on the PRU, and I2C is handled by Linux kernel drivers.
I suspect you'd have to bit-bang the I2C protocol on whatever GPIO is
applicable (which may imply having to disable the OS I2C via device tree in
order to convert the pins to PRU-GPIO that the PRU can manipulate){That, or
disable Linux driver and perform low-level I/O to the I2C control registers
-- ie; write an I2C driver library on the PRU}

  Sorry I have nothing more encouraging.

5

I stumbled on this although it does reference the stmpe811 as a touch screen controller:
https://lore.kernel.org/linux-devicetree/20191119202850.18149-2-c-robey@ti.com/

Jon

6

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 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 /src/pru1.p codes?
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 ?

Thanks !

7

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&gt;\) 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

  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).

8

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?

9

No "insight". I suspect it depends upon how difficult it is to set the
BBAI pin-mux as needed by the driving code. Besides all pin-mux settings
having to be made in the device tree loaded by u-boot, do the BBAI PRU bits
map to the same chipset GPIOs.