Taktowanie UART dla danych asynchronicznych zależy od znajomości szybkości transmisji danych i posiadania zegara, który jest zwykle 16 razy szybszy. Górna połowa obrazu przedstawia sposób ponownej synchronizacji danych, a dolna połowa źle zsynchronizowany system (taktowanie 13x), tak jak na przykładzie: -

Przy braku jakichkolwiek krawędzi danych, prawidłowo zsynchronizowany zegar może próbkować dane mniej więcej w środku symbolu. Na dolnym obrazku, bez krawędzi danych, które mogłyby zmienić czas, zegar 13x w końcu popełni błąd.

Aby uzyskać większy "obraz radiowy", musisz wysłać preambułę, aby rozpocząć, tj. nie możesz po prostu mieć nadziei na natychmiastowe zablokowanie, ponieważ jest zaangażowanych wiele czynników. Oto zdjęcie, które narysowałem jakiś czas temu, które wyjaśnia, jak preambuła działałaby na prostym nadajniku i odbiorniku radiowym FM: -

A here to poprzednia odpowiedź zawierająca ten diagram. Zawiera więcej przydatnych informacji.

Układy UART (rs232) mają bit startu (0) i bit stopu (1). patrz diagram Andysa. Ale używają drutu, a szum jest bardzo niski - w zasadzie żaden.

W przypadku hałaśliwego łącza działa to bardzo źle. Jeśli bit początkowy jest zły, wszystko po nim jest błędne i tak pozostaje.

Radia na ogół tego nie robią, bardziej prawdopodobne jest, że mają preambułę, która zawiera serię rozgrzewającą 1/0, aby tx i rx ustabilizowały się i uzyskały synchronizację bitową, a następnie magiczny blok synchronizacji, np. 32-bitowy unikalny wzorzec początkowej synchronizacji bloków, a następnie bloków danych z korekcją błędów. Należy pamiętać, że bloki danych z poprawionymi błędami mogą być samosynchronizowane - są one ważne tylko wtedy, gdy synchronizacja jest prawidłowa.

Kody są tak dobrane, aby zawsze miały wystarczającą liczbę przejść 1/0, aby zachować synchronizację bitową. to znaczy. nie można uzyskać przebiegu 32 1s, zawsze będzie przejście co N bitów, w najgorszym przypadku.

Jeśli używasz UART przez radio, preambuła powinna być znakami, które mają pojedyncze przejście 0/1, aby UART mógł wrócić do synchronizacji. Jak powinno być oczywiste, jeśli dane były 1/0/1/0, to uart nigdy nie wiedziałby, która krawędź była bitem początkowym. Jak widać na diagramie Andysa, chce mieć mniej więcej równe saldo 1/0. Więc 0xF0 jest idealne, sekwencja będzie zaczynać się = 0 0000 1111 stop = 1

W komunikacji asynchronicznej masz określoną prędkość, prędkość transmisji.

Odbiornik wie, jak długi jest bit czasu. Oczekuje na krawędź, a następnie zaczyna odliczać, aż znajdzie się w połowie czasu bitowego. Następnie próbkuje dane wejściowe.

Oczekiwanie na koniec odbywa się za pomocą „oversamplingu”. Odczytujesz stan wejścia znacznie szybciej niż szybkość transmisji. Powszechne jest użycie nadpróbkowania 16x, ale działa też 8x.

Istnieje darmowe oprogramowanie, które implementuje UART.
Jeśli chcesz zobaczyć, jak to się robi w sprzęcie, znajdź kod źródłowy Verilog. Jeśli znasz C, możesz prawie ^* czytać kod Verilog.

^* _{Oprócz kilku bardzo ważnych szczegółów :-)!}

Przepraszamy, że przegapiłem część „początek i koniec ich bajtów”.

UART zaczyna się od bitu początkowego, który jest zawsze niski. Kończy się bitem stopu, który jest zawsze wysoki. W ten sposób czekasz na 0 w linii i wiesz, że jest to bit początkowy. Liczysz wtedy np. 10 bitów (start, 8 danych, stop), a dziesiąty bit powinien być wysoki. Jest bardzo prawdopodobne, że ciągły strumień bitów jest próbkowany w niewłaściwym miejscu i nadal jest zgodny z protokołem „początek jest niski, stop jest wysoki”. Dlatego próbuję złapać oddech między bajtami, aby temu zapobiec.

Pouczające może być przyjrzenie się prostszemu algorytmowi znajdowania bitów stopu i startu. Najpierw próbkuj wejście z czterokrotną szybkością transmisji.

Jeśli szybkość transmisji danych wynosi 9600 bitów na sekundę, będziesz chciał próbkować z częstotliwością 38 400 Hz.

Gdy nie ma transmisji, otrzymasz dużo szumu, a na wejściu próbki mogą pojawić się losowe wzloty i upadki.

Po wysłaniu bitu początkowego można go wyczuć na co najmniej 3 kolejnych próbkach. Następnie będziesz próbkować co czwartą próbkę jako rzeczywisty otrzymany bit, przesuniętą o jedną próbkę, aby była blisko środka każdego bitu.

W końcu otrzymasz bit stopu - jeśli nie jest poprawny, możesz odrzucić wszystkie dane i spróbować ponownie, czekając na bit startowy.

To prosty przypadek. Gdy już to uruchomisz, zauważysz, że nadal otrzymujesz złe dane i właśnie tam wykorzystujesz więcej technik odzyskiwania danych:

• Zamiast używać tylko jednej próbki w pobliżu środka każdego bitu, spójrz na wszystkie trzy próbki, które powinny wystąpić w czasie bitowym, i użyj głosowania większości, aby określić rzeczywistą wartość bitu.
• Zwiększ częstotliwość próbkowania do 8x lub 16x, co da znacznie większą liczbę próbek na bit do wykorzystania i przybliży Cię do zbierania informacji przez cały bit, a nie tylko 3/4 w środku.
• Przechowuj strumień danych podczas odbierania i używaj korelatora, który porusza się wzdłuż strumienia, aby znaleźć bity początkowe i końcowe. W ten sposób nie wyrzucisz możliwego bajtu, ponieważ masz zły bit startowy tuż przed prawdziwymi danymi.
• Zamiast próbkować w środku bajtów, szukaj przejść - RF wysyła przejścia lepiej niż poziomy statyczne. Znajdź początek bitu początkowego, a następnie używając małego okienka wokół każdego przejścia bitowego, sprawdź, czy jest przejście, a wtedy uzyskasz informacje o poprzednim i następnym fragmencie.

Jednak proste sygnały USART nie są odpowiednie dla RF.Rozważ przyjrzenie się kodowaniu w Manchesterze.Zamiast wysyłać dane jako wysokie / niskie, wysyłasz je jako przejścia od wysokiego do niskiego lub niskiego do wysokiego.To znacznie ułatwia odzyskiwanie zegara, ponieważ koduje zegar na każdy bit i działa na przejściach, które są naturalnym przyjacielem RF.Nie możesz wysłać go tak szybko, ale będzie znacznie bardziej niezawodny.

Weź również pod uwagę wykrywanie błędów i, jeśli to możliwe, korekcję błędów.Dzięki prostemu wykrywaniu błędów będziesz w stanie zweryfikować, czy modyfikacje algorytmu poprawiają sygnał, czy nie obiektywnie.