Velocità di clock del ricevitore UART


14

Stavo cercando di capire i fondamenti di UART. Resta inteso che

  • È un protocollo di comunicazione asincrono e quindi i clock TX e RX sono indipendenti l'uno dall'altro
  • La ricezione dei dati è garantita dall'uso del bit di avvio e di uno o più bit di arresto. Inoltre, il ricevitore deve essere consapevole della velocità dei dati in modo da generare un clock adeguato per pilotare il registro SIPO utilizzato per la ricezione.

Le domande qui sono

Si dice che normalmente un clock di 16X il bit rate è usato per recuperare i dati. Quindi, come è possibile la conversione di bps in frequenza di clock ? Forniscimi alcuni riferimenti per studiare il meccanismo di clock impiegato nel ricevitore UART.

Risposte:


18

Gli orologi del trasmettitore e del ricevitore sono indipendenti l'uno dall'altro, nel modo in cui sono generati indipendentemente, ma dovrebbero essere abbinati bene per garantire una trasmissione adeguata.

Il bit di avvio, che è basso, e il bit di arresto, che è alto, garantiscono che tra due byte ci sia sempre una transizione da alto a basso, il ricevitore può sincronizzarsi, ma dopo è da solo: non ci sono altri tempi segnali che può essere utilizzato per distinguere i bit successivi. Tutto ciò che ha è il suo orologio. Quindi la cosa più semplice da fare è partire dal campione del bit di avvio ogni bit nel mezzo del suo tempo. Ad esempio, a 9600 bps un tempo di bit è 104 µs, quindi campionerebbe il bit di avvio a + 52 µs, il primo bit di dati a + 52 µs + 104 µs, il secondo bit di dati a + 52 µs + 2 104 µs e così via. è il fronte di discesa del bit iniziale. Durante il campionamento il bit di avvio non è davvero necessario (tuT0T0T0×T0sapere che è basso) è utile accertare che il bordo iniziale non fosse un picco.

inserisci qui la descrizione dell'immagine

Per un tempo di 52 µs è necessario il doppio della frequenza di clock di 9600 bps o 19200 Hz. Ma questo è solo un metodo di rilevamento di base. Metodi più avanzati (leggi: più accurati) prenderanno diversi campioni di fila, per evitare di colpire solo un picco. Quindi potresti davvero aver bisogno di un clock a 16 9600 Hz per ottenere 16 tick per bit, di cui potresti usare, diciamo, circa 5 in quello che dovrebbe essere nel mezzo di un bit. E usa un sistema di voto per vedere se dovrebbe essere letto come alto o basso.×

Se ricordo bene il 68HC11 ha prelevato alcuni campioni all'inizio, a metà e alla fine di un po ', il primo e l'ultimo presumibilmente a risincronizzare se ci fosse un cambio di livello (che non è garantito).

Il clock di campionamento non deriva dal bit rate, è il contrario. Per 9600 bps dovrai impostare il clock di campionamento su 153 600 Hz, che deriverai attraverso un prescaler dalla frequenza di clock del microcontrollore. Quindi il bit clock è derivato da quello da un'altra divisione per 16.

orologi senza eguali
Questo è ciò che accadrà se l'orologio del ricevitore non è sincrono con quello del trasmettitore:

inserisci qui la descrizione dell'immagine

L'orologio del ricevitore è lento al 6,25% e si può vedere che il campionamento per ogni bit successivo sarà successivo e successivo. Una tipica trasmissione UART è composta da 10 bit: 1 bit di avvio, un payload di 8 bit di dati e 1 bit di stop. Quindi se campionate nel mezzo di un po ', potete permettervi di essere mezzo fuori dall'ultimo bit, il bit di stop. Mezzo bit su dieci bit è del 5%, quindi con la nostra deviazione del 6,25% ci imbatteremo in problemi. Ciò mostra chiaramente nella figura: già al terzo bit di dati stiamo campionando vicino al bordo.


Apprezzo l'aiuto. Grazie !! Il bit iniziale non dovrebbe essere campionato a T0 + 104us invece di T0 + 52us?
Vivek Maran,

1
@ Vivek27 - no, perché 104 us è la durata del bit di inizio, e quindi eseguiresti il ​​campionamento alla fine, anziché nel mezzo. Se mi dai un paio di minuti, aggiornerò le mie foto. :-)
stevenvh,

1
@Vivek: In realtà il bit di inizio non è affatto "campionato". Il suo scopo è quello di fornire quella transizione iniziale dalla linea inattiva a cui il resto del personaggio è cronometrato rispetto a. Il suo "valore" è sempre opposto alla riga inattiva e non contiene di per sé alcun dato.
Olin Lathrop,

7
@Olin - Vorrei campionare il bit di partenza, solo per verificare che il bordo iniziale non fosse un picco.
Stevenvh,

1
@downvoter - Se vuoi dirci cosa c'è che non va qui, potrei essere in grado di risolverlo. Ma poi devi dirci qualcosa . (Sei lo stesso che ha votato a favore della mia altra risposta oggi?)
stevenvh,

11

Facciamo un passo indietro e parliamo del protocollo di segnalazione di basso livello utilizzato dagli UART. TX e RX sono linee di dati, non orologi. Gli orologi sono solo all'interno di ogni UART, motivo per cui ci deve essere un accordo in anticipo su quale sia il baud rate.

Quando non si trasmette la linea viene lasciata nello stato inattivo. Per trasmettere un byte (ad esempio, sono possibili altre larghezze di dati), il trasmettitore invia prima il bit di avvio . Il ricevitore utilizza il tempo del bordo anteriore del bit iniziale e la velocità di trasmissione nota per decodificare il resto del carattere. Diciamo per semplicità che vengono usati 100 kBaud. Ciò significa che ogni tempo di bit è lungo 10 µs. Ciò include il bit di avvio, i bit di dati e i bit di arresto. Pertanto, la metà del primo bit di dati sarà a 15 µs dopo il bordo anteriore del bit di avvio, la seconda a 25 µs, ecc.

Finché gli orologi del ricevitore e del trasmettitore sono gli stessi, ciò potrebbe continuare all'infinito. Tuttavia, non saranno mai esattamente gli stessi, quindi non può andare avanti per sempre. Per consentire la risincronizzazione dell'orologio del ricevitore con l'orologio del trasmettitore, il carattere dei dati termina, la linea viene lasciata inattiva per un po ', quindi il processo viene ripetuto. Gli errori di temporizzazione si accumulano a partire dal bordo anteriore del bit di avvio, quindi la deriva massima è all'ultimo bit. Una volta terminato quel carattere, il ricevitore si reimposta in attesa del prossimo bit di avvio e il processo si ripete.

Con 8 bit di dati, il caso peggiore per il timing è il campionamento dell'ultimo bit. Questo corrisponde a 8,5 bit dal riferimento di temporizzazione, che è il bordo iniziale del bit di avvio. Se il ricevitore è spento di 1/2 bit o più, campionerà l'ultimo bit durante un altro bit. Chiaramente questo è male. Ciò accade in caso di mancata corrispondenza della frequenza di clock di 1/2 bit in 8 1/2 bit, ovvero del 5,9%. Questa è la mancata corrispondenza garantita. Per affidabilità, di solito si desidera assicurarsi che il ricevitore corrisponda al trasmettitore entro la metà di esso, o al 2,9%. Ciò rappresenta un errore di tempo di 1/4 bit all'ultimo bit.

Tuttavia, non è così semplice. Nello scenario sopra descritto, il ricevitore avvia essenzialmente un cronometro sul bordo anteriore del bit di avvio. In teoria ciò potrebbe essere fatto nell'elettronica analogica, ma sarebbe complicato e costoso e non facilmente integrabile nei chip digitali. Invece, la maggior parte delle implementazioni UART digitali ha un clock interno che funziona a 16 volte la velocità di bit prevista. Il "cronometro" conta quindi questi cicli 16x. Ciò significa che è possibile aggiungere un ulteriore errore di 1/16 bit a tutti i tempi di campionamento dei bit, che è come un altro non corrispondente del clock del 7% all'ultimo bit.

Spero che questo chiarisca qual è il bit di stop, come funziona il timing dei bit e di cosa si occupa l'orologio 16x. Per lo più ho saltato bit di stop, ma forse ora puoi capire da solo perché è richiesto almeno un bit di stop. Fondamentalmente i bit di stop sono il minimo tempo di inattività della linea forzata tra i caratteri. Questo è il tempo durante il quale il ricevitore ha terminato di ricevere un personaggio ed è pronto per il successivo bordo iniziale di un bit di inizio. Se non fosse presente alcun bit di stop, l'ultimo bit di dati potrebbe avere la stessa polarità del bit di avvio e il ricevitore non avrebbe alcun bordo su cui avviare il cronometro.

Molto tempo fa questo protocollo è stato decodificato da camme, leve e ruote girevoli. Due bit di arresto venivano spesso utilizzati per consentire il ripristino del meccanismo. Al giorno d'oggi, tutto è fatto nella logica digitale e 1 bit di stop è usato praticamente universalmente. Spesso vedi il protocollo di basso livello scritto come 8-N-1, che significa 8 bit di dati, nessun bit di parità (dimenticati di questi, oggi sono usati raramente) e 1 bit di stop. Il bit di avvio è implicito poiché non esiste alcuna opzione.

Utilizzando 8-N-1, un byte di dati a 8 bit richiede effettivamente 10 bit per l'invio. Questo è uno dei motivi per cui esiste una distinzione tra "bit rate" e "baud rate". La velocità di trasmissione si riferisce ai tempi di segnalazione dei singoli bit, inclusi i bit di avvio e di arresto. A 100 kBaud, ogni bit trasmesso richiede 10 µs, inclusi i bit di avvio e di arresto. Pertanto, l'intero carattere richiede 100 µs, ma vengono trasferiti solo 8 bit di dati reali. La velocità di trasmissione è di 100 k, ma la velocità di trasferimento dei dati dal punto di vista dei livelli più alti è solo 80 kBit / s.


5

La velocità in bit per la trasmissione è la frequenza di clock divisa per (come dici tu, in genere) 16. Hai anche alcuni bit non di dati per i bit di framing (inizio, parità, arresto). Quindi per un orologio a 16000Hz si ottengono 1000 bit al secondo, ma dopo che vengono inseriti bit di inquadratura minimi solo 800 bit di dati o 100 byte al secondo.

Per la ricezione, il ricevitore conta dalla metà del bit di avvio 16 orologi e campiona la linea chiama ciò che vede "primo bit di dati". ripete questo conteggio e campiona abbastanza volte per leggere l'intero simbolo, quindi conferma la presenza del bit di stop e inizia ad attendere il prossimo bit di start.

Finché l'orologio del ricevitore è vicino alla frequenza dell'orologio del trasmettitore, il campionamento colpirà le parti corrette del segnale trasmesso.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.