Lo scenario di cui sembri parlare (con bit di inizio e fine), è probabilmente UART (di cui RS232 è un tipo di). UART sta per Universal Asynchronous Receive Transmit, la cui parte fondamentale è Asynchronous . Non ci sono linee di clock, solo dati.

In questo tipo di sistema hai due dispositivi (TX e RX) che non condividono necessariamente un orologio comune. Entrambi i sistemi potrebbero ad esempio concordare su 9600 Baud, ma senza un orologio comune, uno potrebbe produrre 9601 Baud mentre l'altro ottiene 9599 Baud. Gli orologi non sono perfettamente precisi, il che significa che nel tempo i due si discosteranno dall'allineamento.

Inoltre, poiché la comunicazione è asincrona, può iniziare ogni volta che il trasmettitore ne ha voglia (ignorando il controllo del flusso). Il trasmettitore e il ricevitore potrebbero accendersi in momenti diversi e il ricevitore non ha modo di sapere quando inizia a trasmettere.

Il requisito fondamentale è quindi noto come sincronizzazione. Il protocollo deve includere un modo in cui il trasmettitore segnali al ricevitore che ha appena iniziato a trasmettere. Inoltre ci deve essere un modo per sincronizzare gli orologi ad entrambe le estremità.

Nel caso dell'UART, questa sincronizzazione viene eseguita sotto forma di una transizione da alto a basso sulla linea dati. La linea resterà inattiva in alto, quindi si abbasserà quando la trasmissione inizia. Questa transizione agisce per sincronizzare i tempi tra entrambi i dispositivi. Il ricevitore quindi sa di sincronizzare in cicli sufficienti di dati in base al suo baud clock. Esistono tuttavia due problemi con questo schema:

1. La singola transizione da alto a basso non è sufficiente per sincronizzare i tempi su un lungo periodo di tempo. Ricorda che i due dispositivi avranno frequenze di clock interne leggermente diverse. Finché questi due clock si trovano entro una certa% l'uno dall'altro, la transizione fornirà informazioni sufficienti per sincronizzare i dispositivi per al massimo alcuni cicli di clock. Ciò significa che è necessaria una risincronizzazione periodica.

2. Se la tua linea è inattiva e il primo bit di dati che vuoi inviare è anche rappresentato da un livello alto, allora non hai una transizione. Se la tua linea è inattiva e il primo bit che vuoi inviare è basso, hai lo stesso problema. Ciò significa che hai bisogno di un modo per distinguere il primo bit.

Entrambi questi problemi vengono risolti nel caso dell'UART utilizzando i bit di avvio e di arresto. I dati inviati vengono suddivisi in pacchetti di pochi bit (es. 8 bit). Ogni pacchetto è preceduto da un bit di inizio "basso" e seguito da un bit di arresto "alto". Ciò significa che tra ogni pochi bit c'è una transizione nota da alto a basso: il bit di stop dell'ultimo pacchetto e il bit di inizio del pacchetto corrente. Ora puoi risincronizzare ogni pacchetto.

Questo non è affatto l'unico modo per risolvere il problema. Esistono molti altri schemi: la codifica Manchester è un esempio. In questo schema una transizione da basso ad alto indica un 1 logico mentre una transizione da alto a basso segnala una logica 0. Ciò significa che ogni bit che invii codifica le informazioni di clock al suo interno, il che significa che puoi risincronizzare ogni bit che invii.

Potresti avere altri metodi di segnalazione come l'uso ternario - tre livelli di tensione. Ad esempio potresti usare + 5V per 2, 0V per 1 e -5V per 0. Potresti inviare binario tramite questo sistema usando uno di questi stati per indicare inattivo. Tuttavia in quell'esempio hai semplicemente sostituito un bit di avvio e arresto con un periodo di tempo a una terza tensione. Non cambierai la necessità di una risincronizzazione periodica, quindi non ti fa risparmiare davvero nulla e aggiunge solo complicazioni ai circuiti.

Dici -15V + 15V + 15V -15V. che è 0110, hai ragione un ricevitore potrebbe riceverlo correttamente.

Ma cosa succede se invii 15 V 15 V 15 V -15 V come faresti a sapere di cosa si tratta. Poiché l'ascoltatore, la prima cosa che sentiresti è il primo -15V, non avresti idea di quanti segnali da 15V sono arrivati ​​prima.

L'ascoltatore sentirebbe la stessa cosa indipendentemente dal fatto che il mittente abbia inviato 1110, 1101, 1011 o 0111.

Senza alcun riferimento temporale, sembrano tutti uguali come segnali di tensione.

Poiché il tempo è importante con segnali asincroni, devi inviare un segnale "ASCOLTA". In RS232 il segnale di ascolto è una transizione da alto a basso sulla linea. Dice al ricevitore "Sto per inviare N bit di dati alla mia velocità di trasmissione, a partire da ORA!"

Nota, in questo esempio di UART a 4 bit, ogni modello ora ha una firma univoca.

Il bit di stop assicura che la linea torni allo stato inattivo alla fine della trasmissione e fornisce anche al ricevitore una finestra temporale per gestire i byte appena ricevuti, ripristinati e prepararsi ad ascoltare il bit di avvio successivo.

Nell'immagine sotto la prima traccia non ha bit di stop. Si noti che poiché l'ultimo bit del primo dato è zero, la linea è già bassa quando arriva il bit di avvio successivo e non c'è transizione per avviare l'UART. Nella seconda traccia che ha un bit di stop, ti viene garantito il massimo prima del minimo.

In effetti la maggior parte degli UART ti dà la possibilità di inviare più di un bit di stop per aprire ulteriormente quella finestra per il ricevitore. Questo era più importante nei primi giorni della trasmissione seriale in cui il segnale RS232 in realtà azionava direttamente motori e relè meccanici, ma può ancora avere i suoi usi oggi.

Inoltre, la maggior parte degli UART controlla effettivamente che il bit di stop sia alto al momento del bit appropriato. In caso contrario, al destinatario viene segnalato un errore di frame.

Startbit è un risveglio alla fine dello stato di inattività.Stopbit assicura che ci sia una transizione nota all'inizio del nuovo byte.Il sistema è stato sviluppato in un'epoca in cui non era possibile essere sicuri che i motori nei dispositivi di trasmissione dati meccanici (= telescriventi) funzionassero in sincronia su entrambe le estremità.Start e stopbits erano il metodo di risincronizzazione.

Oggi sequenze di bit molto più lunghe di un byte possono essere trasmesse senza bisogno di risincronizzazione.Ma alla fine tutti gli orologi si allontanano e la sincronizzazione è necessaria.Sono stati sviluppati numerosi sistemi di codifica che trasportano i dati di sincronizzazione necessari in modo molto più efficace di start&stopbits che necessitava di una capacità aggiuntiva del 25%.

Per un payload sicuro ... forse ... forse.Ma cosa succede se stai inviando un flusso di dati.Come può il ricevitore essere sicuro quando l'ultimo carico utile è terminato e il nuovo carico utile inizia?

Lo stato di inattività di un bus RS232 è -12V.Come farà il ricevente a sapere che sta per ricevere un flusso di 0 o quando la trasmissione deve iniziare?

Anche questa comunicazione seriale è asincrona.Il ricevitore deve vedere un limite per determinare gli aspetti della trasmissione

Stai confondendo i livelli di tensione (RS-232 presumiamo) e il protocollo seriale (diciamo solo uart come proveniva da un tempo prima che tutti fossero ossessionati dal dare un nome alle cose).

Usando il tuo esempio non puoi distinguere 0110 da 001100 per esempio. Con il protocollo uart devi campionare idealmente il centro della cella di bit, in modo che il ricevitore sappia dove si trova il centro, essendo su sorgenti di tempo diverse e non esattamente la stessa, il primo fronte da inattivo ti dà un riferimento per poterlo per raggiungere la metà dei successivi N bit quanto è grande N dipende dalla precisione di ciascun lato, 8 o giù di lì bit di dati puoi essere piuttosto sciatto e, se vuoi, puoi risincronizzarlo su tutti i bordi che trovi (nel tuo esempio come riceveresti 00000000? o 11111111?)

Il bit di inizio ci dà un vantaggio da distinguere da inattivo, per indicare quando inizia il messaggio e un riferimento per campionare i bit. Il bit di stop assicura che torniamo inattivi almeno per una cella di bit o due. Quando sei saturo di dati, senza spazi vuoti, nessun inattivo tranne il bit di stop, allora hai un altro problema che il protocollo uart non risolve necessariamente (beh, la parità aiuta) se entri nel mezzo (qualcuno collega poi cosa mentre i dati si muovono , o qualsiasi altro motivo) i bit di inizio e fine aiutano a inquadrare i dati senza parità potresti ancora essere in grado di capire dove ti trovi, con la parità hai una possibilità ancora migliore ma non perfetta.

Ora ci sono altri protocolli. Molti altri protocolli. vai a cercare irig-106, invece di un bit di inizio hai un modello di sincronizzazione che può essere seguito da centinaia di bit prima di un altro modello, senza periodi morti. Il documento irig ha un bel grafico di varie codifiche dove NRZ-L è quello a cui siamo abituati con un semplice uart (non ritorno a livello zero) un interessante è bi-phase-l Dove c'è un cambio di stato a metà cella di bit quindi il tuo 0110 verrebbe trasmesso a 2x la frequenza dei dati e sarebbe 01101001, nel peggiore dei casi non puoi mai avere più di due celle di mezzo bit di fila allo stesso livello, molti bordi con cui sincronizzare bit.

Un altro interessante è mil-std-1553, dove usano bi-phase-L (che è una codifica popolare con molti nomi diversi solo bifase o manchester, ecc.) ma non sono dati continui, è un'esplosione di una a molte parole. usano un errore bifase-l intenzionale di tre celle a mezzo bit e tre celle a mezzo bit come modello di sincronizzazione, quindi entrano nel messaggio codificato in bifase-l.

Non c'è motivo per cui non sia possibile utilizzare livelli di tensione RS-232, RS-422, ecc. con un protocollo diverso da quello uart. Ma hai ancora bisogno di bordi ogni tanto nei dati per sincronizzare gli orologi (se porti con te l'orologio allora questa è un'altra storia) e hai bisogno di un modo per sapere dove si trovano i gruppi di bit che formano byte o parole quindi devi avere uno schema di sincronizzazione o un bit di avvio o altro. o fare qualcosa come spi o i2c per segnare l'inizio. la classica ethernet utilizzava una lunga onda quadra con alcuni bit per indicare la fine di quella e l'inizio del pacchetto. MDIO ha qualcosa di simile.

Alla fine della giornata non si può avere un protocollo seriale affidabile a segnale singolo senza un modo per sapere dove si trovano i confini di parola / messaggio nel bitstream, allo stesso modo non si può farlo senza sapere dove / quando campionare per ogni bit.Anche se un bitstream continuo e forse pensi di sapere quando era il tempo zero e puoi semplicemente contare fino a 8 e contrassegnare un altro byte, potresti essere fortunato ma devi comunque sincronizzarti con l'orologio di invio poiché il tuo orologio è basato su un diversoriferimento e deriverà rispetto all'orologio dei mittenti.Quindi puoi provare a farcela fintanto che guardi periodicamente i bordi che trovi e assicurati che ci sia un bordo ogni N bit in base alla matematica relativa alla precisione degli orologi.