Pytanie:
Skąd UART rozpoznaje różnicę między bitami danych a bitami start / stop?
Ben Hershey
2016-08-09 00:41:03 UTC
view on stackexchange narkive permalink

Rozumiem, że schemat UART często używa 8N1, co oznacza 1 bit startu, 8 bitów danych i 1 bit stopu. Coś takiego:

0 xxxxxxxx 1

Gdzie 0 to bit początkowy, x to dane, a 1 jest bitem zatrzymania. W przypadku ciągłego przesyłania wielu ramek z powrotem do tyłu byłoby coś takiego:

0 xxxxxxxx 10 xxxxxxxx 10 xxxxxxxx

Moje pytanie brzmi: w jaki sposób odbiornik może odróżnić bity start / stop od bitów danych? Aby zilustrować ten punkt, załóżmy, że bajt danych 0xAA jest ciągły. Wyglądałoby to następująco:

0 10101010 10 10101010 10 10101010 10 10101010 10 10101010 1

Pogrubiłem bity start / stop dla podkreślenia, ale wydaje mi się, że naprawdę nie ma sposobu, aby odróżnić je od bitów danych .

Oczywiście, jeśli odbiornik miał solidne, wolne od błędów połączenie z nadajnikiem od wieczności, to widzę, że nie byłoby to problemem. Lub jeśli bajty nie zostaną odesłane z powrotem, nie byłoby problemu. Ale pracowałem z obwodami 8N1, które w sposób ciągły transmitowały bajty jeden po drugim i mogłem rozłączyć / ponownie podłączyć przewody w trakcie transmisji, a odbiornik zawsze wskakiwał z powrotem do prawidłowego odbioru. Jak to możliwe?

Nie może i w takim ciągłym strumieniu będziesz miał problem.Konieczne jest albo opóźnienie między bajtami, albo inna metoda „ramkowania” bajtów.
bardzo łatwo jest źle zsynchronizować uart i pozostać w błędzie przez jakiś czas, istnieją wzorce, które możesz wysyłać w sposób ciągły, że jeśli zablokuje się źle, pozostanie zły.W idealnej sytuacji dane się zmieniają, a czasami występują okresy bezczynności, w takiej sytuacji układ UART ostatecznie przejdzie przez błędy kadrowania blokowania danych zamiast synchronizacji, a następnie w końcu wsunie się we właściwy wzór.Nie jest to protokół doskonały, ale działa wystarczająco dobrze.Istnieje wiele innych, które nie są tak podatne na błędy.
Działa zgodnie z oczekiwaniami - i jak sugeruje ogólne podsumowanie większości odpowiedzi.Załóżmy, że nie ma kontroli parzystości, 1 początek, 1 początek, 8-bitowe dane.RX bezczynny i gotowy do odbioru, linia = high = idle.|RX rozpocznie się pierwszego dnia 0. |1,5 bitu raza po zmianie 1/0 będzie samplował pierwszy bit i zrobi to 8 razy.|Następnie, miejmy nadzieję, sampluje bit zatrzymania 1 bit później.-> TERAZ, jeśli bit stopu = 1 = prawidłowy, będzie czekał na następne przejście 1/0 (poprawnie> = 1 bit czasu po rozpoczęciu prawidłowego bitu stopu ORAZ jeśli otrzymane w ten sposób dane są śmieciami, to nie wie.wygląda tak realistycznie, jak ...
... prawdziwe dane.Więc powtórzy powyższe.|Ale / i jeśli bit stopu jest nieprawidłowy (niski), będzie WIEDZIEĆ, że nie jest zsynchronizowany i odrzuca be i szuka prawidłowego bitu początkowego.można podjąć decyzje o tym, KIEDY może wystąpić ważny bit początkowy.|Na kolejnym bicie pozornego początku powtarza się jak powyżej.Jeśli wynikiem jest ciąg danych z 10 sekwencjami oddalonymi od siebie o 10 bitów (jak na powyższym diagramie), to JEST on zsynchronizowany, a dane JEST sprawdzone - tak jak można powiedzieć.MOGĄ to być śmieci, ale są to śmieci przypominające prawdziwe dane....
|Za każdym razem, gdy niezsynchronizowany system widzi niski (= nieprawidłowy) stop, ale przesuwa jeden lub więcej bitów wzdłuż silnego i JEŚLI dane są w rzeczywistości prawidłowe i wolne od błędów, wcześniej czy później zostaną zablokowane, chyba że w danych są wzorcespełniające warunek synchronizacji 10xxxxxxxx.|Proste, wysokopoziomowe przerwy między postaciami znacznie pomogą przywrócić synchronizację systemów.Wszystko na haju za 9?czasy znaków gwarantują synchronizację w systemie bez błędów.
Pięć odpowiedzi:
Eugene Sh.
2016-08-09 00:47:03 UTC
view on stackexchange narkive permalink

To wykrywanie bitu początkowego. Dokładnie taki jest tego cel. Linia bezczynności będzie wyglądać następująco:

  ... 11111111111111111111111111111 ...  

Gdy odbiornik zobaczy 0 po długi czas jedynek (lub po bicie stopu, jak zobaczymy wkrótce), wie, że transmisja została rozpoczęta i zaczyna liczyć bity. Wie, że 8 bitów (lub zgodnie z konfiguracją) po bicie startu to dane. Dziewiąty to bit stopu i powinien wynosić 1 . Jeśli tak nie jest - wystąpił błąd ramkowania i wymagana jest ponowna synchronizacja.

Po odebraniu bitu stopu, zaczyna ponownie czekać na bit startu. I tak dalej.

Teoretycznie może wystąpić problem z synchronizacją, jeśli linia wygląda następująco:

  ..1010101010101010101 ....  

lub podobnie, więc w tym przypadku odbiorca nie zobaczy, od czego zacząć, ale w tym przypadku nie ma to większego znaczenia, ponieważ pozycja początkowa nie ma znaczenia. Aby jednak uniknąć takich problemów, niektóre protokoły definiują 1,5 (półtora) długości bitu dla bitu stopu, aby uczynić go unikalnym. Lub, w praktyce, między dwoma pakietami danych zawsze występują pewne opóźnienia, więc linia jest bezczynna wystarczająco długo, aby umożliwić odbiornikowi synchronizację.

_ "ale w tym przypadku nie będzie to miało znaczenia, ponieważ pozycja początkowa nie zrobi różnicy" _ - zrobi różnicę, gdy linia zatrzyma serię `AA` i zacznie przesyłać różne dane.Wtedy odbiorca może otrzymać nie tylko błędy ramek, ale także śmieciowe dane.
jonk
2016-08-09 05:30:11 UTC
view on stackexchange narkive permalink

To brzmi jak pytanie zadane przez kogoś, kto próbuje emulować odbiornik UART w oprogramowaniu lub FPGA. W przypadku RS-232 używają terminu znak i spacja . Ale te zwykle odpowiadają, po zdigitalizowaniu, odpowiednio '1' i '0'.

Odbiornik UART często dzieli każdy bit czasu (musi być znany, a priori) na co najmniej 4, ale często 16 lub więcej podokresów. Zaczyna się (po włączeniu zasilania / zresetowaniu) w stanie, w którym oczekuje się, że linia odbiornika szeregowego będzie w stanie znacznika . Jeśli linia NIE znajduje się w tym momencie w znaku , to wie , że znajduje się w środku ramki transmisyjnej i musi czekać, aż będzie mogła się zsynchronizować. Jeśli linia jest w stanie znaku , to może lub nie znajdować się w środku czegoś i będzie musiała poczekać i zobaczyć. Jest to problem z RS-232, jeśli po prostu podłączasz inne urządzenie podczas komunikacji szeregowej lub jeśli jest częścią dotknięcia, aby monitorować asynchroniczną komunikację szeregową między dwoma innymi graczami i właśnie zostały zresetowane. Aby być absolutnie pewnym, wychodząc i tak z resetowania, UART musiałby obserwować co najmniej N bitów razy (gdzie N to liczba bitów na słowo, a często 7 lub 8 i zakładając tutaj brak opcji parzystości) o wartości znaczek , po którym następuje jeden bit czasu spacji w celu ponownej synchronizacji (lub N + 1 bitowy czas spacji ). Wiele z nich nie przenosi tak dużo dookoła, aby mogły się nieprawidłowo zsynchronizować, jeśli zostały uruchomione w środku strumienia. Często pojawiają się błędy ramek i sporadyczne bajty danych, dopóki nie zdarzy się, że przypadkowo ponownie zsynchronizuje się poprawnie. To też często była akceptowalna cena. Zwykle kable są podłączone, a urządzenia są włączane w określonej kolejności, więc rzadko pojawiają się problemy.

Jednak po synchronizacji UART wie, czego się spodziewać.Zawsze zaczyna się od linii odbiorczej przechodzącej od znaku do spacji , potrzebnego bitu początkowego, który trwa przez cały czas bitowy, po którym następują bity danych, a następnieco najmniej jeden bit o wartości czasu oznacz (lub dłużej) jako bit stopu.Jeśli pozostanie zsynchronizowany, zobaczy ten wzorzec powtarzany w kółko.

Jednym z powodów podzielenia czasów bitów na coś w rodzaju 4x lub 16x jest to, że zegary używane przez nadajnika odbiornik niekoniecznie jest idealnie dokładny, a poza tym są po prostu asynchroniczne względem siebie.Tak więc część synchronizacji, która zachodzi w odbiorniku, polega na dopasowaniu jej pokrojonych w kostkę okresów do taktowania nadajnika.Im drobniejsze jest to zrobione, tym lepiej ustawiony może być odbiornik.

Gregory Kornblum
2016-08-09 00:45:28 UTC
view on stackexchange narkive permalink

UART potrzebuje ciszy na początku, aby złapać pierwszy bit startowy.Następnie liczy tylko zgodnie z predefiniowaną liczbą bitów, osiąga bit stopu i ponownie czeka na bit startu.Jeśli UART zacznie odbierać w środku długiej wiadomości - łatwo może dostać po prostu śmieci.

pgvoorhees
2016-08-09 00:46:13 UTC
view on stackexchange narkive permalink

Może dostrzec różnicę, ponieważ wie, gdzie powinny znajdować się w strumieniu bitów (ponieważ to powiedziałeś).

Pamiętaj tylko, że każdy symbol jest bez znaczenia, dopóki nie zostanie uzgodnione znaczenie.

Tony Stewart Sunnyskyguy EE75
2016-08-09 00:51:46 UTC
view on stackexchange narkive permalink

Jeśli bezczynność istnieje wcześniej, nie pojawiają się żadne błędy, nie ma problemu, ale każdy błąd, taki jak przepełnienie bufora, wymaga jakiejś metody uzgadniania, po którym następuje stan bezczynności i powinien zostać ponownie zsynchronizowany od pierwszego bitu startowego.

Uzgadnianie jest niezbędne do komunikowania wykrycia pełnego bufora, przepełnienia, błędu parzystości lub błędu bitu stopu.

Nieparzysta parzystość jest tutaj przydatna do wykrywania błędu danych i / lub błędu ramkowania, aby wznowić poprawny startsynchronizacja bitowa i bezbłędna komunikacja.



To pytanie i odpowiedź zostało automatycznie przetłumaczone z języka angielskiego.Oryginalna treść jest dostępna na stackexchange, za co dziękujemy za licencję cc by-sa 3.0, w ramach której jest rozpowszechniana.
Loading...