Part Number: AM623
Hi PRU team,
An old friend at a customer reached out asking if we could do a 1.5mbps UART and how many we could do with the 2 PRU IP's in an AM62x architecture. He needs more than the hardware UARTs on the AM62 and is trying to replace an FPGA that is expensive but gave a huge # of UARTs. I had an email exchange with Nick. I'll copy it here and then we can loop in the customer for this great discussion:
Initial thoughts:
Need more details about usecase:
-
- Half duplex or full duplex
- If half duplex, is this TX or RX
- Where is the data coming from and where is it going
- Whether the data needs any pre-processing before passing to another core
There is not an existing project that does this that a customer would be able to copy/paste, so the customer would need to do some development work.
Design overview
There are 4 options I am aware of for PRU UART on AM62x:
-
- Hardware UART in the rest of the processor (8 on AM62x)
- Hardware UART in the PRU subsystem (1)
- SW UART implemented through 3 channel peripheral interface (up to 3 half-duplex instances per PRU core, or 3 full-duplex instances across both PRU cores)
- SW UART implemented by bitbanging (cannot say exact limits right now)
For HW UART in the rest of the processor, read / write latencies may be a limiting factor at higher speeds. Interrupt driven would be better than polling if an option (I haven’t checked interrupt mapping).
For SW UART implementations, the time between when we need to read/write data to the interface is the limiting factor. 3 channel peripheral interface is a bit more forgiving since you load the bits you want to send or read into a FIFO, so you have either 8 or 16 bits on the UART line before you need the code to circle back and service that particular UART instance. Bitbanging data by directly reading/writing the GPI/GPO pins can theoretically go much faster than 3 channel peripheral interface (3 channel peripheral interface maxes at 16MHz), but your code also has much less time to execute since you need to do that GPI/GPO read/write for every single bit on the UART line. AM64x is a lot more flexible than AM62x in implementing bitbanging code, since you have 3x the PRU cores to do processing within the same amount of time, and 2x the PRU subsystems.
If the customer’s request was 12-15 UARTs running at 115200 Baud, then my answer would be: yes, this is very easy. We just port the AM335x SoftUART Linux driver & PRU firmware to AM62x, which gives up to 6 additional UARTs. This code was written for a 200MHz PRU core, not a 333MHz PRU core, so if the customer needed even more UARTs, we could pretty easily sneak in another 2 UARTs, maybe more: https://software-dl.ti.com/processor-sdk-linux/esd/docs/07_03_00_005/linux/Foundational_Components/PRU-ICSS/Linux_Drivers/pru-sw-uart.html
Another question to ask is whether PRU even needs to be in the loop. If software development is needed anyway, does it make sense to do that software development on Linux drivers than in PRU firmware? For example, DMA might be able to help offload frequent reads & writes even if PRU isn’t used. In the UART case, I think the Linux UART driver doesn’t have DMA support upstreamed at this point in time though. Bin would know more about that thought process.
