I’m trying to figure out how to relate the various GPI and GPO bits in the PRU_ICSSGs to the pins on the Cape Headers. There’s a few different layers to doing this and here’s what I think I need to be doing. And I just need a sanity check to make sure I’m on the right track and determine if perhaps there’s a better strategy that someone with more experience can suggest.
I started with the BBAI-64 hardware documentation where the various connections are documented.
The chip-to-cape header I believe I found in the hardware documentation for the BBAI-64 here (p25):
BeagleBone_AI-64_Rev_B1_SCH_220602.pdf
(p25)
However the pin-names for each pin position seem to be logical names assuming a specific mix-combination. But their prefix does look like a pin-position ID. But just for curiosity, I search the document for the label name just to see where else they show up. I started with AH21_MCAN6_TX, which is labeled as Pin 3 on Header P8. Searching AH21_MCAN6_TX, it appears to be associated with something called PRG1 and wires to that as PRG1_PRU0_GPO19 / AH21.
This looks promising, but I’m still not sure I fully understand what I’m looking at. What is PRG1 (and PRG0)?
Assuming that AH21 is a pin-descriptor, I go to Sysconfig to see what it looks like, and sure enough AH21 correlates to a pin.
This is both confirming that the things I’m seeing are aligning. But I’m still not sure I fully know what PRG1 and PRG0 or if I need to care yet.
I do see the various Modes this pin can be put in and I see that putting it in Mode 0 makes it a PRG1_PRU0_GPO19 pin which sounds like what I would want. But I don’t know which PRU_ICSSGx peripheral this goes to. Is there a correlation between PRU_ICSSG1 and PRG1? If so, then this is a clue that I need to take care in picking pins that are all on the same PRG to keep all my pin selections within the same PRU_ICSSG subsystem.
Finally, I need to find the documentation that correlates each PRU’s GPO and GPI Register-bits to these pins. I remember reading this a while back for PRU_ICSS on the BBB, but I’d assume the mappings are all different for this platform. Given TI doesn’t claim support for the PRUs in the TVA4VM, how do I find documentation to complete this final step?
All that said, once I get some of these mysteries cleared up, I think I can move forward picking pins with a bit more confidence.
Background on the project I’m trying to prototype:
For the project I’m trying to prototype using the BBAI-64’s PRUs, to interface on an old 16-bit processor’s memory bus as a slave device (emulating PROM). The bus has 8 data/address lines, and 5 control lines. I need at least 8 bi-directional (high speed) pins for the data I/O. When the BBAI-64 is a slave, the 5 control pins will be monitor-only. However there is a scenario where the BBAI-64 will need to disable the processor and become the bus-master, and thus it will be controlling those lines. However in this scenario, timing is not nearly as critical since the BBAI-64 gets to set the pace (as the master). So handling this scenario outside of the PRUs is a completely viable option. Latency and timings are not nearly as critical and in this mode since all that’s being done is getting a memory-dump of the existing PROM.
I say all this in hopes that maybe there’s a similar BBAI-64 project already started that might have some similar pin-muxings already setup and some documentation of what cape-pins map to what Input and Output bits in which PRUs.
Also any documentation that details how to incorporate SysConfig information into a project (e.g. what are the muxing registers in the TVA4VM)? I’m sure a lot of this depends on when and where the muxing is being performed. For instance performing muxing as part of uboot launch will have different details than performing muxing at runtime as part of a fundamental application mode-switch. But any details that can be shared of helpful hints and things to be aware of might prove useful. For instance, I suspect accessing raw memory when your code is separated by the MMU where RAT is performed might have challenges and thus some helpful details as to how to defer/relay your need to read/write raw memory from those perspectives.
