Non è la velocità dei dati che conta;usiamo CTS / RTS (o XON / XOFF per il controllo del flusso del software) dove esiste la possibilità di un overflow del ricevitore, anche se è vero che è più probabile a velocità di trasmissione dati più elevate.

Seun ricevitore non può svuotare i suoi buffer abbastanza velocemente, quindi dovrebbe disattivare CTS (in risposta al quale, il trasmettitore affermerà RTS se ci sono più dati da trasmettere).

Si noti che il trasmettitore potrebbe subire un buffer underrun, nel qual caso dovrebbe deasserire RTS (perché non ci sono dati validi da inviare).

Quindi dipende dalla velocità con cui i buffer possono essere spostati - è più probabile cheessere un problema a velocità di trasmissione dati più elevate, ma dipende completamente dall'implementazione;non esiste un'unica velocità.

È necessaria una qualche forma di controllo del flusso (che sia hardware o XON / XOFF) quando si trasferiscono dati a una velocità maggiore di quella che è possibile elaborare.È così semplice.

Il controllo del flusso viene utilizzato per un'estremità per dire all'altra estremità "aspetta un momento, sto ancora pensando".Di solito è legato al fatto che un buffer è quasi pieno (noto come "high water mark").

Il controllo del flusso hardware consente alle apparecchiature comunicanti di sincronizzarsi tra loro.Consente all'apparecchiatura ricevente di indicare che è pronta a ricevere i dati che vengono inviati.Se i dati vengono inviati quando il ricevitore non è in "ascolto", ciò causerà errori nei dati.

La velocità dei dati a cui si verifica dipenderà da una serie di altre cose, incluso il tipo di dispositivo e software suil dispositivo.Se stai collegando due PC a 115.2K, probabilmente saranno in grado di funzionare correttamente.Se si tratta di due microcontrollori con altro carico software, potrebbero non esserlo.

Se specifichi quale tipo di dispositivi stanno inviando e ricevendo, riceverai una consulenza migliore.

La necessità di un controllo di flusso su un'interfaccia seriale asincrona dipende completamente dalle esigenze dell'applicazione. A volte una velocità di trasmissione più lenta può abbassare la velocità dati effettiva per alleviare la necessità di controllo del flusso, ma anche questo dipende dall'applicazione.

Esistono alcune tecniche che possono consentire a un'applicazione di funzionare a velocità di trasmissione più elevate senza la necessità di utilizzare l'handshaking di controllo del flusso. Uno di questi consiste nell'utilizzare una tecnica di invio e ricezione UART guidata da interrupt e accodare il flusso di dati tra il codice della linea principale dell'applicazione e le routine di interrupt tramite buffer FIFO circolari.

L'uso dei buffer FIFO deve essere fatto in base al fatto che il processore dell'applicazione possa gestire gli interrupt UART alla velocità dei caratteri (cioè baud_rate / bits_per_transmission_unit). Se non è in grado di gestire quella velocità di interrupt più il piccolo overhead imposto dalla gestione del buffer FIFO, allora sarebbe necessario abbassare la velocità di trasmissione abbastanza da permettere il funzionamento della velocità di interrupt.

A volte il processore dell'applicazione avrà un UART che include un FIFO hardware integrato. Se questi vengono utilizzati insieme a uno schema di buffering FIFO gestito da interrupt, può essere vantaggioso per la progettazione della routine di servizio di interrupt svuotare i FIFO hardware di ricezione o riempire completamente i FIFO hardware di trasmissione al momento dell'interrupt da / per il il software gestiva buffer FIFO che normalmente sarebbero di dimensioni maggiori. Configurato e codificato correttamente, questo può abbassare la velocità di interruzione netta che un processore di applicazioni deve gestire a qualsiasi velocità di trasmissione particolare.

Ricordo quando usavamo terminali "stupidi" e digitavi Ctrl + S (XOFF) per mettere in pausa la trasmissione in modo da poter leggere lo schermo prima che i dati scorressero.Quindi dovremmo digitare Ctrl + Q (XON) per riprendere l'output.Lo schermo potrebbe essere messo in pausa per 10 minuti.Non aveva nulla a che fare con la velocità di trasmissione.

Allo stesso modo, una stampante seriale che aveva esaurito la carta poteva richiedere il controllo del flusso hardware per mettere in pausa l'output mentre la carta veniva sostituita.Anche in questo caso non avrebbe nulla a che fare con la velocità di trasmissione.

Si può ancora fare a meno di CTS / RTS a 115,2 kbps?

Invio di routine dati dail mio ATmega328P * a un monitor seriale a 115200 baud.Funziona bene.

_{* Arduino}

Ti interessa che i tuoi dati vengano trascinati nel secchio di bit?Se sì, allora usa il controllo di flusso.

Hai una parità secondaria / ECC / controllo di flusso come ha TCP?Se sì, allora sei coperto.Tuttavia, utilizzando TCP / OSI come modello, più livelli eseguono il controllo e il controllo degli errori per garantire la consegna dei dati e ridurre al minimo gli errori.Supponiamo che tu stia utilizzando TCP / IP, senza controllo del flusso hardware a 115,2 kbps, la tua velocità effettiva a causa di problemi di flusso hardware potrebbe essere terribile.

Ci sono molte considerazioni.

• Quanto è grande il tuo buffer di ricezione?
• Quanto velocemente il ricevitore può svuotare detto buffer?
• il ricevitore fa cose che lo fanno smettere di guardare il buffer per qualche tempo?in tal caso il buffer è abbastanza grande da consentire al ricevitore di superare quei casi?
• Se perdi parole a causa di un overflow del buffer di ricezione, quanto è grave?
• Se la fonte sperimenta "contropressione "dovuta al controllo del flusso quanto è grave?

Non esiste un numero magico per" quando ho bisogno del controllo del flusso hardware ", è una domanda che deve essere posta e risoltanel contesto di un sistema specifico.

Si può ancora fare a meno di CTS / RTS a 115,2 kbps?

Molti sistemi lo fanno, si veda ad esempio il serialeporte della console su quasi tutte le schede Linux integrate.

Se il dispositivo di destinazione ha un buffer di 16 byte ma l'interrupt veloce non è garantito, allora RTS / CTS è sempre preferito e include anche bit di parità dispari per l'affidabilità.Senza tutti i dettagli, è difficile conoscere la soglia di overflow del buffer di destinazione, quindi diventa tentativi ed errori.