Do Beaglebone Black PRUs offer extended UART capabilities ?

General Discussion
1

Hi, I am using a Beaglebone Black and already using the 4.5 Hardware UARTs using C/Python3. Now, I need to extend the number of UART ports and thought of using the 3 UARTs per PRUs to get more than 4 UARTs.

I fail to find any resource that can clarify this possibility. I mean, is it even possible ? If yes, how should I go about it ? Most PRU examples belabor on the FTDI/UART usage to replace printf.

2

@yoder Can you please shed some light on it ? Thanks

3

Check out
https://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/Foundational_Components/PRU-ICSS/Linux_Drivers/pru-sw-uart.html. They don’t make it easy to get to the individual example bits. I’m sure they are out there, but need to search for them.

4

Out of curiosity, what sort of baudrate do you need, and do you need both transmit and receive or just one of those directions?

5

38400 actually

6

That’s 5208.3 PRU cycles per bit-time… I feel like one PRU core should be able to emulate way more than 3 uarts at such a slow baudrate

7

That would mean 6 UARTs emulation via 2 PRUS… plus 4 Hardware UARTs … Am I right ?

Also, I can’t find any resources to emulate the uarts… I want to use the PRUs for this specific purpose. Please suggest.

8

I feel that the best way to get specific answers is to contact them via ti e2e.

9

But how are the different pins defined for each pru_uart in the code? I can’t find any help.

10

@pradan

Perhaps something like this would be a simpler solution

USB → 4 serial port adapter

11

Thanks but I don’t think it helps my case. I have a 1D lidars that I use to get data via UARTs. Using USB based serial interface will only make my solution more complicated and a little less robust.

12

At 38400 baud I would have thought USB2 would be plenty fast enough. As far as software goes, they would just appear as /dev/tty devices like the internal UARTS. No difference in code.
Writing soft UARTS on the PRU is going to me more complicated, and unless you do all the processing on the PRU, you are then going to have to interface that to something running under Linux. Overall it is probably going to be more complicated.
The simplest solution is usually the best, unless you have some real time constraints that you can’t get over USB

13

Thanks for this. Will surely give this a try now.