I punti che fai sono assolutamente validi. Quello che ti manca sono alcuni dettagli che potresti ottenere leggendo di più sui protocolli di comunicazione. Eccone alcuni.
- La velocità di comunicazione deve essere sempre scelta dalla velocità massima required, non quella che può essere raggiunta.
La ragione di ciò è che con alcune eccezioni (ricetrasmettitori, buffer ecc.) i dati trasferiti devono essere ottenuti o elaborati in qualche modo. L'input dall'interfaccia umana funziona certamente in una dimensione temporale completamente diversa. E se il controller impiega diversi secondi per elaborare 1 MB di dati, sarebbe inutile trasferirlo a una velocità di 16 Mbps.
- Poiché il rapporto segnale / rumore diminuisce con la distanza, anche la larghezza di banda massima achievable diminuisce.
Esiste il termine "prodotto larghezza di banda-distanza" spesso utilizzato nella comunicazione. Questo è un altro motivo per cui le connessioni dirette da MCU a MCU raramente utilizzano velocità di dati così elevate.
- Nelle moderne MCU le velocità di comunicazione sono spesso indipendenti dagli orologi della CPU.
Ad esempio, gli MCU Xmega hanno clock delle periferiche che funzionano a 2 o anche 4 volte la velocità della CPU. Inoltre, i controller con interfacce USB spesso hanno i propri oscillatori.
- Vari protocolli di comunicazione sono ora supportati in hardware.
I protocolli sincroni come SPI (o I2C sul lato slave) hanno i loro segnali di clock provenienti dai diversi MCU. Quindi, l'hardware può utilizzare quell'orologio per spostare i dati da / verso il buffer e coinvolgere il processore solo alla fine di un messaggio. Gli MCU più avanzati con supporto DMA possono persino spostare i dati tra diverse periferiche o memorie senza coinvolgere affatto la CPU.
I protocolli asincroni come UART o CAN richiedono orologi sincronizzati. Iniziano a temporizzare al bit di inizio e quindi campionano gli ingressi una volta approssimativamente al punto di metà clock (UART) o fino a tre volte a circa il 75% dell'impulso di clock (CAN). Ovviamente l'integrità dei dati dipende dalla precisione del clock. Mentre i controller CAN possono regolare i loro clock utilizzando le informazioni sullo spostamento di fase, gli UART più semplici non possono farlo.
Una pratica comune per ottenere una migliore sincronizzazione UART consiste nell'usare cristalli con frequenze facilmente divisibili per comuni velocità di trasmissione seriale. Ad esempio, invece di eseguire i suddetti controller Xmega al loro massimo 32 MHz, è spesso possibile vederli con 14,7456 cristalli, in esecuzione a 29,5 MHz.
Indipendentemente dal protocollo, la combinazione di buffering hardware e trasferimenti DMA rende la larghezza di banda di trasferimento abbastanza indipendente dai clock della CPU.
- Infine, quando la velocità di comunicazione aumenta, è più comune vedere chip controller separati piuttosto che connessione diretta all'MCU.
Non solo, ma di solito è possibile vedere la connessione del bus parallelo tra MCU e ricetrasmettitori ad alta velocità come il display LAN o LVDS. Questo perché il throughput del bus di comunicazione diventa più veloce di quanto possa essere passato in seriale tramite un singolo pin MCU.
Hai menzionato Ethernet in uno dei tuoi commenti. Dovresti renderti conto che con velocità Ethernet di 1 Gbps nessun MCU a 16 MHz ha la possibilità di elaborare quella valanga di traffico. Per quelle velocità dovresti guardare a un hardware molto più capace, come quello usato in RPi, per esempio.
A proposito, questo ultimo punto è solo un'altra forma del punto n. 1, cioè se non puoi ridurre la velocità dei dati a qualcosa che il tuo MCU può gestire, ne consegue logicamente che hai bisogno di un processore più veloce per gestire il flusso di dati.