Microcontroller with fast UART

[luky315]

I am looking for a microcontroller with at least one fast UART for a 20MBd RS485 Network. A Hardware direction control would be really useful at this speed.
I found a few STM32F4 controller which are capable of 10.5MBit on some UARTS (the ones connected to the 84MHz APB2 Bus), but nothing with more speed. Does anyone know other microcontrollers which are able to communicate (and handle the data) with even higher baudrates?

[AndyC_772]

That's a bit of an unusual requirement; I've designed a lot of serial interfaces over the years, but they've all been synchronous above 115,200 baud.

My first reaction would probably be to look into using a small FPGA.

[westfw]

Ethernet...

[nctnico]

I agree. With this requirement ethernet is the way to go. Note that you don't need to implement TCP/IP or so. An ethernet MAC will send away anything you feed it so you can implement your own protocol.

[dannyf]

Sufficiently high master clock + sufficient low bit rate register values -> sufficiently high bps.

[digsys]

Highest RS485 rates I've run is 5Mb, using 16c750s etc external UART ICs. They have 128/256 byte FiFos, so you don't need to pull/push
every single byte. With trigger levels tied to IRQs, flow control is quite easy. One advantage is, the CPU can be quite "slow".
It's rare that you HAVE to process EVERY byte as it appears / sent.
Higher than that, you'll need to go to FPGA / EPLDs etc and roll your own.

[embeddedbob]

If it has to be RS485 (?), another option is to use the external parallel bus on the ST Cortex hooked up to a OTS transceiver or CPLD (small FPGA) to roll your own. Although Ethernet seems to fit better (as others have suggested).

[free_electron]

afaik the only uarts that can do that are the 16C890 , M681 and family. those go up to 40megabaud
Problem is that they use the VLIO interface , not commonly found on your garden variety cpu... (Intel Xscale beast ...)

you can bitbang VLIO but then you lose the speed ...

your problem is that at 20 megabaud a character arrives every 500ns (1 startbit,8 data, stopbit = 10 bits) ...even with a buffer you will need a very fast cycletime cpu to keep up with that. so you need uarts with deep fifo's and/or dma capability.

microcontroller with dma capability will be 32 bit monsters. maybe some 16 bitters.

[hans]

PIC32MX has 20Mbps USARTS with 80MHz clock, and has 8-level FIFO + DMA support. No RS485 driver support, so you need to roll your own software driver

USARTS usually oversample by 16, but on most 16- and 32-bit PIC's you can oversample with 4 (probably at the cost of more framing errors etc).

Otherwise you need a 16x20M = 320MHz clock, which is too high for todays MCU's.
Even 8x20M=160MHz is very high, only some ARM chips get that but can only run at divide by 16 on the top of my head.

What free_electron said is true; on a high bus load (e.g. 50%) you're receiving 1MB/s. You could use DMA on the USART on PIC32, but still you need to software-process 1MB/s of data.
At 1MB/s a 8-level FIFO would still generate 125000 interrupts per second. If you're spending 2 us per interrupt (only 160 ticks), the CPU is 25% busy with RS485.

Not sure if the Ethernet suggestion is of any help if the TS is hooking in to an existing bus. If there is freedom, I would definitely use a 10/100Mbps ethernet phy on a ARM/PIC32 chip and enjoy the full benefits of DMA + interrupt on frame basis + unicast/multicast/broadcast support + CRC.

[westfw]

Is "asynchronous" serial communications even likely to work at that sort of speed?  Traditionally, "serial ports" (rs232) top out at 115200bps or so, with "synchronous" (V.35) external clocking going up to 2Mbps, and above that you start using various forms of embedded clocking (Manchester, etc.) (10Mbps ethernet is Manchester, 100Mbps is MLT-3, 1000Mbps is multiple parallel links...  Above 10Mbps, you no longer have multidrop, except as implemented by smart intermediate switches...)

[Jeroen3]

You should move focus from looking for a microcontroller to a microprocessor. You know, those +500Mhz ones.
Or, get some programmable logic. So you can apply hardware filters, something CAN and MAC (layer of ethernet) already have.

At what speeds does RS485 lose signal integrity? The distance should be reduced significantly with 20 MBaud, or not?

[mikeselectricstuff]

RS485 at 20Mbaud is going to be rather limited in terms of range, especially if you have stubs etc.
As mentioned, UART is rather sensitive to things like asymmetric rise/fall times - Manchester would be better. 
You will certainly need DMA, double buffered etc. This could get interesting once you add in RS485 driver control, address filtering, packet framing and error handling.

[stevech]

wire capacitance and slew rate of line drivers are a key limitation.
And you'd need to run the UART in DMA mode on an STM32F4xx - which the HAL library supports.
Hard to do for receiving, unless you know in advance the data block sizes

[T3sl4co1l]

You should move focus from looking for a microcontroller to a microprocessor. You know, those +500Mhz ones.
Or, get some programmable logic. So you can apply hardware filters, something CAN and MAC (layer of ethernet) already have.

At what speeds does RS485 lose signal integrity? The distance should be reduced significantly with 20 MBaud, or not?

It needn't lose signal integrity, if it's planned right.  Usually a bus is a double-end-terminated transmission line (remember coax thinnet?) with low impedance capable bus drivers distributed about (for a multi-master configuration).  Aside from DC coupling and isolation, it's not really very different from 10BASE-T (20Mbaud Manchester encoding = 10Mbps), which is also doubly terminated (50 + 50 ohm to GND, 100 ohm differential), and reasonably strong (~1V?).  You'll ultimately be limited due to HF and DC loss in the cable (unless you add boosters or repeaters).

wire capacitance and slew rate of line drivers are a key limitation.

Both edges and bits propagate just fine, when using compatible drivers (RS-422/485 outputs are not weedy CD4000 gates, or current-limited RS-232!) and suitable termination.  The line can be much longer than the risetime, and for that matter, much longer than the bit time.

Speaking of 10BASE-T, the nice thing is it's self clocking.  Most high speed protocols are synchronous, as mentioned.  You aren't going to get away with that for two channels of RS-485 and a synchronous (e.g., SDO + SCK) protocol because no two cables will be well enough matched over a long distance that you can count on the clock and data remaining in sync.  (If you're cheap and use unshielded CAT-5, you're even worse off, because the cable specifically has different velocity factors on the different pairs!)

Tim