It's all about communication

There's a lot of different comm protocols out there in the world. Proprietary, complex, simple, you can find one to fit your needs. However, there's a few that are standardized and common. I'm doing a little groundwork study on what I'd want/need in a "comm hub". A single microcontroller board that provides me with various comms from my PC, so I can program or view whatever my project is spitting out.

Dedicated Interfaces.

USB: Great, now universal, relatively fast (most MUCs are 12Mb/s), provides up to 500mA of power at 5V. Cons, gotta connect directly to a PC. Integrated or UART bridge

Ethernet: Really universal, no fanout issues, can plug in anywhere with the right software/config. Now can do Power over Ethernet (but rare and might not be worth the hassle for me!). 10Mb/s is common for an MCU. Integrated or parrallel bridge or SPI bridge.

CAN: Not really universal, but simple wiring, I can follow my own design tastes, more bulletproof in implementation. Slower at 1Mb/s max. Integrated or SPI bridge.

The Asynchronous Croud, the U(S)ART users.

Asynchronous communication, perhaps the oldest in the book. Not necessarily robust, but can be made that way. Comes out of the MCU at TTL levels, and can be programed to match many of the following theme variations.

RS232: The old time PC comm favorite. 115Kbaud max to most PCs, although modern variations can go up to something like 921Kbaud. More difficult to deal with due to the +/-12V signalling. UART + level shifter. Point to point.

RS422/485: Not the same scheme, but similar electrical interface. Requires a single ended to differential converter, but works at 5V. Can be faster than RS232 or go much farther. RS422 is otherwise very similar, but can have some limited multidrop capabilities (1 master, 10 slave?). RS485 is a full addressed network setup with an 8 bit network design (256 nodes, usually limited to less by electrical integrity issues).

IRdA: Another UART user, but this time using a pulse width technique to encode the data in light packets. Both ends need to be aimed at each other, but it's great due to the electrical isolation. Lower speeds, normally maxing at 115Kbaud for embedded hardware, but much higher speed (and shorter ranged) variations exist.

LIN: The slower brother of CAN. Uses an ordinary UART and a single wire transciever set, so it's cheaper to implemen than CAN.

Board Level Communications.

A few very common serial systems are not meant to leave the board level, but that doesn't mean they don't.

I2C: Two wire clocked serial bus. One line for data, bidirectional, one line for clock from the master. Simple, a few different names (mostly depends on voltages, SMBus is the 3.3V name, I2C is 5V, Two Wire Interface is the name for those not wanting to pay Phillips for the patent I guess).

SPI: Perhaps the oldest bus in the book. This is a simple clocked bus with a master clock line, a master data line, and a slave data line. A master interrupt line and a slave select line are optional. Simple, not direction changes. Full duplex. Clocked so you don't need to worry about baud rate error. Takes more pins, though. It's fast, however, Microchip products can move at 10MHz (equalling or outstripping the high speed PC busses in general), I've seen some DSP chips clock out at 20MHz to 50MHz.

I'm throwing together ideas for a "communications board" that will encompass many of the above parts. I originally thought USB for the PC interface, but I'm now thinking ethernet as it's simpler to port TCP controls from one OS to another rather than USB drivers. CAN will be on the unit, as will be one external header (possibly with a level shifter?) for I2C and SPI (4 wire). The thing I run into right now is deciding what UART protocols to support. Most chips only have 2 async busses, and I probably won't be able to make the baud rates match exactly due to different clocking requirements. RS422/485 is a given for my needs. I'm also considering IRdA. RS232 would be nice, as would LIN. Straight TTL to the UART may be useful too, but I think it'll not be used too much (maybe a jumper/header block?).