• State
  • +1 person also asked this people also asked this
  • Replies 2 replies
  • Subscribers 102 subscribers
  • Views 82 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

AM625: Any way to use more than 20 GPIs on one PRU?

Cody Gray
Prodigy 60 points
Part Number: AM625

Tool/software:

Hi there,

I am evaluating processors in the AM62x family for use in two different upcoming system design projects.

My understanding is that each PRU core on the AM62x has access to 20 enhanced GPIs and 20 enhanced GPOs. The high-speed, low-latency access of the PRU cores to GPIOs is perfect for my needs. However, I actually need more than 20 GPIs.

Is there any way to increase the number from 20 to 30? For example, would it be possible to remap some of the GPOs to be GPIs in order to increase the number of GPIs? Or some other technique?

There are enough bits in the r31 register to accommodate more pins (see Figure 7-21, "PRU Module Interface", in the TRM, which shows 30 bits available in r31 for GPIs). I did see the section 7.4.2.2 "PRUSS Fast GPIO pins" in the TRM, but I didn't fully understand it. Is there something in the programming that can be used to increase the number of GPIs that are allocated to one of the PRU cores to more than 20?

Just to provide a bit more information on what I am trying to do, I have a dual-channel 14-bit ADC that provides parallel CMOS output. I want to read this output using the GPIs on the PRU cores. The catch is that the ADC is running at a ~48 MHz sampling rate, which is quite fast and gives very little margin for latency or error. I have this successfully implemented where each channel (14 bits/GPIs) is handled by one PRU core. But I need to free up one of the PRUs to handle interfacing with a different component (DAC), so I wanted to see if there was a way to increase the number of GPIs on one PRU so that I could handle both channels (a total of 28 bits/GPIs) on a single PRU, leaving the other one free.

Thanks,
Cody

  • 0
    TI__Guru* 89825 points

    Hello Cody,

    PRU GPI / PRU GPO signals are different from regular GPIO signals, because the signal is DIRECTLY wired to the R30/R31 registers inside the PRU core. For more information about why PRU GPO / PRU GPI signals are unique, please refer to 
    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1269989/faq-what-is-a-pru-core-why-are-pru-gpio-signals-different-from-regular-gpios

    That means that if we want the unique benefits of a PRU GPI / PRU GPO signal (instead of just a regular GPIO signal - keep in mind PRU cores can read GPIO signals as well, just like any other processor core), then we are limited to the hardwired signals within the processor.

    If we check out the AM62x datasheet > terminal configuration and functions > PRUSS, you'll see that PRU0 only has 20 GPI signals coming in, and 20 GPO signals coming out. Same for PRU1.

    Off the top of my head, I am not sure whether all 40 PRU GPI signals can be pinned out to PRU0 / PRU1 at the same time, or if there are pinmux conflicts. The PRU cores can very quickly pass data back and forth with scratchpads as demonstrated in PRU_Direct_ConnectX, so that is one potential option for load sharing (https://git.ti.com/cgit/pru-software-support-package/pru-software-support-package/tree/examples/am62x )

    I'm running out of time for today, but you could verify pinmuxing with the pinmux tool, like this:
    https://dev.ti.com/sysconfig

    EDIT: I missed your final paragraph, apologies. I am leaving the previous 2 paragraphs in in case they are helpful to a future reader. No time to give further thoughts, can chat more in a couple days.

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    Prodigy 60 points

    Nick,

    Thanks for your reply. I am aware of the advantages of the PRU GPI/GPO signals. In fact, I'd already read the thread that you linked, and that's a big part of why I'm pursuing this so doggedly, because using the Sitara family with the PRU cores is going to allow me to eliminate the FPGA from my design. The main issue I have is that I need more than 20 GPIs in order to do the job, so I'm just hoping to double-check with experts to see if I'm missing any options that might exist.

    So, yeah, I definitely saw that each PRU has only 20 GPI and 20 GPO signals coming in, and my team has already implemented this on an eval board (albeit with the AM64x, which has a bit more capable PRU subsystem). I am also aware of the pin-muxing issues, and I will definitely keep an eye on that as well. But I'm just trying to figure out if there is any way of increasing the number of GPIs available to one of the PRU cores on the AM62x, through any means possible, officially supported or not.

    One way I thought of was remapping some of the GPOs (which I don't need in this case) to be GPIs. In my reading of official documentation (such as the TRM) and the various e2e forum threads, I saw some references that made me think that might be possible. I also noticed that there are more bits available in the register, and some references in various material to up to 30 lines, so I was wondering if there was any possibilities there. As I had mentioned, I saw the section 7.4.2.2 "PRUSS Fast GPIO pins" in the AM6x TRM, but I wasn't really able to comprehend all of the information given there. It says there is a way to "switch between GPO and GPI operation in a fast (or at least a deterministic) manner", and "This allows each PRUSS GP pin to function as either a GPO or as a GPI when the I/O pin is configured for the GPO muxmode", which what made me wonder if it was possible to reassign/reallocate/reuse some of the GPOs that I don't need as GPIs (which I need more of). But because I am not confident in my understanding of what that section is saying, I wanted to confirm whether that was true.

    Absent any way of increasing the GPIs available to a single PRU core, I will have to look into external bank-switching (so that with 14+1 GPIs I could get two banks of 14 GPIs by toggling the 1 GPI), but I am concerned that this will take too long and thus not be able to keep up with the high sampling rate. Before I spend time investigating and prototyping that option, I want to make sure that I have exhausted all other options available on/to the SOC itself.

    I hope that makes sense. Hope you enjoy the New Year holidays, and I look forward to chatting when you are available! (You can also find my email in my non-public profile, if you want to discuss offline or share any sensitive materials.)

    Best,
    Cody