Any faster option than USART 115,200?

[Demon]

I have a main USB PIC that talks to several secondary PICs via hardware USART.

Is there a better/faster technique to transfer data than USART at 115,200?

[richard]

that's more than 11 thousand five hundred characters per second , how much data can a pic16 process at that rate before the wheels fall off and lost data spills all over the floor :D
seems to me to be a rather difficult prospect

[Demon]

...how much data can a pic16 process at that rate before the wheels fall off and lost data spills all over the floor :D ...

I was just keeping my options open; "hope for the best, be ready for the worst". :)

This will run alongside a flightsim, so data will be transfered often: altitude, speed, RPM, heading and much more, those values fluctuate constantly. 115K might be more than enough, but I won't know until I'm finished coding everything. Like I said elsewhere, right now I'm just researching and accumulating code to do very specific tasks.

I still have to design a communication protocol between PICs; what gets transfered, how often, all that stuff. Then it's the USB PIC-PC interface and comms with flightsim; I haven't touched that since early 2023 when I made sure I could do a rudimentary interface (turn on a switch, send that to PC, receive by flightsim, return status of some other control back to PIC).

So yeah, I'm just making sure I'm staying with the bestest options as I move forward, mainly cause I've never done this before. :)

EDIT: just did some math, 115,200/8 bits=14,400 char/second (right ? ), that should be more than plenty.

[richard]

just did some math, 115,200/8 bits=14,400 char/second (right ? )

no, divide by 10, 8 data + start + stop bits

[HenrikOlsson]

You can configure the UART for speeds way beyond 115200 if you want. I've done DMX512 which runs at 250kbaud for example.

But, as Richard mentions, thats only half of the equation.
At the receiving end you need to be able to both A) store the incoming bytes at that high pace and B) process the data.

Is the data a continous stream or short bursts with relatively long "silence" in between?

[Demon]

...Is the data a continous stream or short bursts with relatively long "silence" in between?

I haven't established that yet.

IOC and PPS is new to me, so I was wondering if there were other goodies hidden in the 16F18877 that I wasn't aware of (communication-wise).

The USB PIC will be a 16F1459 driving all the secondary PICs.

[tumbleweed]

There are faster hardware interfaces (ie SPI), but as has been pointed out your code needs to be able to keep up, and that gets difficult.
I've run a UART link up to 460K baud reliably, but that was with a PIC18 @ 64MHz

Here's how fast a byte gets transferred at different baud rates:
115.2K = 86us
230.4K = 43us
460.8K = 21us

If your ISR can't keep up with those rates then you'll loose bytes.
A UART is probably your best bet since it's double buffered in hardware, plus it's easy to use.

[Demon]

... UART is probably your best bet since it's double buffered in hardware, plus it's easy to use.

I agree. :)