Los puntos que hagas son absolutamente válidos. Lo que te faltan son algunos detalles que puedes obtener al leer más sobre los protocolos de comunicación. Éstos son algunos de ellos.
- La velocidad de comunicación siempre debe elegirse entre la velocidad máxima requerida , no la que se puede lograr.
El motivo de esto es que, con algunas excepciones (transceptores, buffers, etc.), los datos transferidos deben obtenerse o procesarse de alguna manera. La entrada desde la interfaz humana ciertamente funciona en una dimensión de tiempo completamente diferente. Y si su controlador tarda varios segundos en procesar 1 MB de datos, sería inútil transferirlos a una velocidad de 16 Mbps.
- Debido a que la relación señal-ruido disminuye con la distancia, el ancho de banda máximo alcanzable también disminuye.
Hay un término "producto de distancia de ancho de banda" que se usa a menudo en la comunicación. Esta es otra razón por la que las conexiones directas de MCU a MCU rara vez utilizan esas altas velocidades de datos.
- En las MCU modernas, las velocidades de comunicación a menudo son independientes de los relojes de la CPU.
Por ejemplo, las MCU de Xmega tienen relojes periféricos que funcionan con 2 o incluso 4 veces la velocidad de la CPU. Además, los controladores con interfaces USB a menudo tienen sus propios osciladores.
- Ahora se admiten varios protocolos de comunicación en hardware .
Los protocolos síncronos como SPI (o I2C en el lado esclavo) tienen sus señales de reloj provenientes de las diferentes MCU. Por lo tanto, el hardware puede usar ese reloj para transferir datos a / desde el búfer y solo involucra al procesador al final de un mensaje. Las MCU más avanzadas con soporte DMA pueden incluso mover los datos entre diferentes periféricos o memoria sin involucrar a la CPU en absoluto.
Los protocolos asíncronos como UART o CAN requieren relojes sincronizados. Comienzan a cronometrar en el bit de inicio y luego muestrean las entradas una vez aproximadamente en el punto medio del reloj (UART) o hasta tres veces en aproximadamente el 75% del pulso de reloj (CAN). Obviamente, la integridad de los datos depende de la precisión del reloj. Mientras que los controladores CAN pueden ajustar sus relojes usando información de cambio de fase, los UART más simples no pueden.
Una práctica común para lograr una mejor sincronización de UART es usar cristales con frecuencias fácilmente divisibles a las velocidades en baudios en serie comunes. Por ejemplo, en lugar de ejecutar los controladores Xmega mencionados anteriormente en su máximo de 32 MHz, a menudo se pueden ver con 14.7456 cristales, que funcionan a 29.5 MHz.
Independientemente del protocolo, la combinación de almacenamiento en búfer de hardware y transferencias DMA hace que el ancho de banda de transferencia sea bastante independiente de los relojes de la CPU.
- Finalmente, cuando la velocidad de comunicación aumenta, es más común ver chips de controladores separados en lugar de una conexión directa a MCU.
No solo eso, sino que normalmente puede ver una conexión de bus paralelo entre MCU y transceptores de alta velocidad como la pantalla LAN o LVDS. Esto se debe a que el rendimiento del bus de comunicación es más rápido de lo que se puede pasar en un solo pin de MCU en serie.
Has mencionado Ethernet en uno de tus comentarios. Debería darse cuenta de que con velocidades de 1 Gbps Ethernet no MCU de 16 MHz tiene una posibilidad de procesar esa avalancha de tráfico. Para esas velocidades, deberías buscar hardware mucho más capaz, como el que se usa en RPi, por ejemplo.
Por cierto, este último punto es solo otra forma del punto # 1, es decir, si no puede reducir la velocidad de datos a algo que su MCU puede manejar, lógicamente se deduce que necesita un procesador más rápido para manejar el flujo de datos.