Kluczowym aspektem transmisji synchronicznej jest preambuła – sekwencja bitów poprzedzająca właściwą ramkę, służąca do synchronizacji odbiornika przed odebraniem danych. W protokole HDLC ramka rozpoczyna się flagą 01111110, a aby uniknąć pojawienia się tej sekwencji w danych, stosuje się mechanizm bit stuffingu (wstawiania dodatkowego zera po pięciu kolejnych jedynkach). CRC (Cyclic Redundancy Check) umożliwia wykrywanie błędów transmisji poprzez obliczenie reszty z dzielenia wielomianowego całej ramki przez ustalony wielomian generatora.

Synchronizacja zegara w odbiorniku odbywa się za pomocą pętli DPLL (Digital Phase-Locked Loop), która na podstawie zboczy w odebranym sygnale odtwarza częstotliwość i fazę nadajnika. Kodowanie NRZ (Non-Return-to-Zero) jest najprostsze, ale nie gwarantuje wystarczającej liczby przejść do stabilnej pracy DPLL, dlatego częściej stosuje się NRZI (zmiana stanu przy zerze) lub Manchester (przejście w środku każdego bitu). Protokół PPP (Point-to-Point Protocol) stanowi rozwinięcie HDLC dla łączy punkt-punkt i oferuje negocjację parametrów połączenia poprzez protokół LCP.

Podstawowa różnica między transmisją synchroniczną a asynchroniczną sprowadza się do sposobu synchronizacji nadajnika i odbiornika. W transmisji synchronicznej oba urządzenia korzystają ze wspólnego sygnału taktującego, co pozwala na przesyłanie danych w dużych blokach bez dodatkowych znaczników między bajtami. Protokół HDLC definiuje ramkę o strukturze: flaga otwarcia, adres, pole sterujące, dane, suma kontrolna CRC i flaga zamknięcia.

W transmisji asynchronicznej każdy znak jest synchronizowany indywidualnie poprzez bit startu (przejście z 1 na 0) i bit stopu (powrót do 1), co pozwala na tolerowanie różnic częstotliwości zegarów do kilku procent. Natomiast w transmisji synchronicznej stosuje się zaawansowane techniki kodowania, takie jak Manchester, NRZI czy 8B/10B, które zapewniają odpowiednią gęstość zboczy do odtworzenia zegara przez pętlę DPLL. Kodowanie NRZI (Non-Return-to-Zero Inverted) reprezentuje logiczne zero jako zmianę stanu linii, a logiczną jedynkę jako brak zmiany, co przy odpowiednim zagęszczeniu zer w strumieniu umożliwia synchronizację.

Proces transmisji danych obejmuje trzy główne elementy: nadajnik przekształcający dane na sygnał, medium transmisyjne (np. skrętka, światłowód, fala radiowa) oraz odbiornik rekonstruujący pierwotną informację. Kluczowym wyzwaniem jest kodowanie liniowe – sposób reprezentacji bitów na medium – które musi zapewnić nie tylko poprawny odbiór, ale także możliwość odtworzenia sygnału zegara. NRZ (Non-Return-to-Zero) to najprostsze kodowanie, w którym wysoki poziom napięcia oznacza 1, a niski 0, jednak długie ciągi tych samych bitów prowadzą do utraty synchronizacji.

Rozwiązaniem tego problemu jest kodowanie Manchester, w którym każdej wartości bitu towarzyszy przejście w środku okresu bitowego (0→1 dla 0, 1→0 dla 1), co gwarantuje zbocze do odtworzenia zegara co każdy bit. DPLL (Digital Phase-Locked Loop) w odbiorniku analizuje te zbocza i dostraja wewnętrzny generator do częstotliwości nadajnika. W protokołach takich jak HDLC i PPP stosuje się dodatkowo mechanizm bit stuffingu, który wymusza pojawienie się zbocza po pięciu kolejnych bitach o tej samej wartości.

Problem synchronizacji sprowadza się do konieczności próbkowania linii danych w odpowiednim momencie – optymalnie w środku okresu bitowego, gdzie sygnał jest najbardziej stabilny. DPLL (Digital Phase-Locked Loop) to kluczowy układ odbiornika, który na podstawie zboczy w odebranym sygnale odtwarza sygnał zegara i wyznacza momenty próbkowania. Jeśli próbkowanie nastąpi zbyt blisko krawędzi bitu, nawet niewielkie zakłócenia mogą spowodować błędny odczyt wartości bitu.

W transmisji synchronicznej stosuje się preambułę – określoną sekwencję bitów na początku ramki (np. 101010... w Ethernet), która umożliwia DPLL osiągnięcie stabilnej synchronizacji przed odebraniem właściwych danych. Bit stuffing w HDLC zapobiega pojawieniu się sekwencji flagi (01111110) w danych poprzez wstawienie zera po każdych pięciu jedynkach. CRC (Cyclic Redundancy Check) stanowi ostatnią linię obrony przed błędami – 32-bitowa suma CRC-32 w Ethernet czy CRC-16 w HDLC wykrywa praktycznie wszystkie błędy wielobitowe.

Oba podejścia do synchronizacji różnią się fundamentalnie konstrukcją nadajnika i odbiornika. W transmisji synchronicznej nadajnik wysyła zarówno dane, jak i sygnał zegara (osobną linią lub zakodowany w strumieniu), a odbiornik używa pętli DPLL do wydzielenia tego zegara. Standard HDLC/SDLC (Synchronous Data Link Control) autorstwa IBM był jednym z pierwszych protokołów wykorzystujących transmisję synchroniczną z bit stuffingiem i CRC.

W transmisji asynchronicznej każdy bajt jest poprzedzony bitem startu (0) i zakończony bitem stopu (1), co pozwala na prostą implementację sprzętową w układzie UART. Kodowanie NRZ jest w tym przypadku naturalnym wyborem, ponieważ odbiornik resynchronizuje się przy każdym bicie startu. PPP (Point-to-Point Protocol) jest przykładem protokołu synchronicznego działającego w warstwie łącza danych, który potrafi negocjować parametry połączenia, w tym metodę uwierzytelniania i kompresję nagłówków.

Wybór metody transmisji jest zawsze wypadkową trzech czynników: efektywności widmowej, niezawodności oraz złożoności implementacji. Transmisja synchroniczna z protokołem HDLC osiąga efektywność bliską 100% przy dużych ramkach, ale wymaga zaawansowanych układów DPLL i kodowania liniowego, co zwiększa koszt. CRC jest standardowym mechanizmem kontroli błędów w obu podejściach – przykładowo CRC-32 stosowany w Ethernet zapewnia detekcję błędów z prawdopodobieństwem 99,99999998%.

Bit stuffing w HDLC i PPP zwiększa niezawodność poprzez eliminację fałszywych flag, ale wprowadza niewielki narzut zmiennej długości (średnio 1 bit na 32 bity danych). Kodowanie Manchester, stosowane w 10BASE-T, podwaja wymagane pasmo, co jest ceną za prostotę synchronizacji. NRZI z bit stuffingiem, używane w USB, stanowi kompromis między efektywnością a możliwością odtworzenia zegara – każde zero powoduje zmianę stanu, a bit stuffing wymusza przejścia przy długich sekwencjach jedynek.

Transmisja synchroniczna opiera się na założeniu, że nadajnik i odbiornik działają z tym samym sygnałem taktującym, co eliminuje potrzebę dodawania bitów synchronizujących między poszczególnymi bajtami. Sygnał zegara może być przesyłany oddzielnym przewodem (jak w SPI) lub zakodowany w strumieniu danych przy użyciu odpowiedniego kodowania liniowego. W protokole HDLC ramka synchroniczna rozpoczyna się flagą 01111110, która służy zarówno do synchronizacji, jak i oznaczania granic ramki.

Aby uniknąć przypadkowego wystąpienia flagi w danych, HDLC stosuje bit stuffing – nadajnik wstawia dodatkowe zero po każdych pięciu kolejnych jedynkach, a odbiornik usuwa te zera po odebraniu. CRC (Cyclic Redundancy Check) umożliwia wykrycie błędów transmisji poprzez obliczenie reszty z dzielenia wielomianowego zawartości ramki. Kodowanie NRZI (Non-Return-to-Zero Inverted) jest powszechnie stosowane w synchronicznych interfejsach szeregowych, ponieważ zmiana stanu przy każdym logicznym zerze ułatwia odtworzenie zegara przez DPLL.

Ramka synchroniczna w protokole HDLC ma ściśle określoną strukturę: flaga otwarcia (01111110), 8-bitowy adres, 8-bitowe pole sterujące, pole danych o zmiennej długości, 16-bitową sumę kontrolną CRC-16 oraz flagę zamknięcia. PPP (Point-to-Point Protocol) rozszerza HDLC o pole protokołu (2 bajty) identyfikujące typ danych w ramce, co umożliwia multipleksowanie różnych protokołów sieciowych na jednym łączu. Preambuła w Ethernet (7 bajtów naprzemiennych 1 i 0) pełni funkcję synchronizacji DPLL przed rozpoczęciem właściwej ramki.

Flagę 01111110 można uznać za szczególny przypadek preambuły – jest to sekwencja unikalna, która nie może wystąpić w żadnym innym miejscu ramki. Bit stuffing w HDLC i PPP zapewnia przezroczystość danych (ang. transparency), czyli możliwość przesyłania dowolnych wartości binarnych bez ryzyka fałszywej detekcji flagi. CRC-16 stosowane w HDLC wyliczane jest z całej ramki pomiędzy flagami i pozwala wykryć wszystkie błędy pojedyncze, podwójne oraz wszystkie błędy o nieparzystej liczbie bitów.

Sygnał taktujący w transmisji synchronicznej może być przesyłany na dwa sposoby: jako osobny przewód (dedicated clock) lub zakodowany w strumieniu danych (embedded clock). W przypadku osobnej linii zegara, jak w interfejsie SPI, master generuje sygnał SCLK, a slave próbkuje dane na zboczu narastającym lub opadającym, co jest bardzo proste w implementacji. Wada tego rozwiązania to problem ze skosem czasowym (clock skew) przy wyższych częstotliwościach i dłuższych dystansach.

Kodowanie zegara w strumieniu danych eliminuje potrzebę dodatkowej linii, ale wymaga bardziej złożonego odbiornika z pętlą DPLL. Kodowanie Manchester gwarantuje przejście w środku każdego bitu, co daje DPLL stałą podstawę do odtworzenia zegara, ale podwaja wymagane pasmo. NRZI z bit stuffingiem (stosowane w USB) stanowi kompromis – przejścia występują przy zerach, a stuffing wymusza je przy długich ciągach jedynek, co zapewnia DPLL wystarczającą gęstość zboczy do utrzymania synchronizacji.

Efektywność transmisji synchronicznej jest znacznie wyższa niż asynchronicznej, ponieważ narzut ogranicza się do nagłówków ramek i kodowania liniowego. Dla ramki HDLC z 4096 bajtami danych narzut wynosi zaledwie 6 bajtów (flaga, adres, sterowanie, CRC, flaga), co daje efektywność 99,85%. PPP dodaje 2 bajty na pole protokołu, co w praktyce nie zmienia znacząco bilansu – efektywność pozostaje na poziomie powyżej 99% dla dużych ramek.

Transmisja asynchroniczna, z narzutem 2–3 bitów na każdy bajt (20–30%), traci tym więcej im mniejsze są przesyłane jednostki danych. Kodowanie liniowe dodatkowo wpływa na rzeczywistą przepustowość – 8B/10B stosowane w PCIe i SATA dodaje 20% narzutu, ale umożliwia odtworzenie zegara i zapewnia DC-balance. CRC w obu rodzajach transmisji dodaje zaledwie 2–4 bajty na ramkę, co przy dużych blokach danych jest pomijalne.

Ethernet jako najbardziej rozpowszechniony standard transmisji synchronicznej wykorzystuje ramki z preambułą synchronizującą i sumą kontrolną CRC-32 w polu FCS. SDH/SONET stanowi szkielet światłowodowych sieci telekomunikacyjnych, gdzie wszystkie węzły są zsynchronizowane do wspólnego zegara atomowego i przesyłają dane w ramkach STM-N o stałym okresie 125 mikrosekund. SPI i I²C to synchroniczne interfejsy wewnątrzsystemowe, w których master generuje zegar dla wszystkich urządzeń podłączonych do magistrali.

W SDH stosuje się skomplikowany mechanizm wskaźników (ang. pointers) umożliwiający niewielkie przesunięcia fazowe między węzłami bez utraty synchronizacji. Ethernet w wariancie 10BASE-T wykorzystuje kodowanie Manchester, podczas gdy szybsze wersje stosują 4B/5B (100BASE-TX) lub 64B/66B (10GBASE-T) z zaawansowanymi układami DPLL. PPP, choć często kojarzony z łączami asynchronicznymi, jest protokołem synchronicznym wykorzystującym ramki HDLC z bit stuffingiem i CRC.

Transmisja asynchroniczna charakteryzuje się tym, że każdy przesyłany znak jest synchronizowany indywidualnie za pomocą bitu startu i bitu stopu, co eliminuje potrzebę wspólnego sygnału zegara. Nadajnik i odbiornik mają własne, niezależne generatory zegara, a ich częstotliwości muszą być zgodne z tolerancją około ±2–5%. W przeciwieństwie do transmisji synchronicznej, gdzie stosuje się protokoły HDLC czy PPP, w asynchronicznej podstawą jest prosty interfejs UART.

Brak wspólnego zegara sprawia, że transmisja asynchroniczna jest znacznie prostsza w implementacji, ale kosztem większego narzutu – na każdy bajt danych przypadają 2–3 dodatkowe bity. Nie ma tu potrzeby stosowania bit stuffingu ani skomplikowanych metod kodowania liniowego, ponieważ odbiornik resynchronizuje się przy każdym nowym znaku. CRC nie jest standardowo stosowane w UART – zamiast tego używa się opcjonalnego bitu parzystości do wykrywania pojedynczych błędów.

Bit startu w transmisji asynchronicznej jest zawsze wartością logiczną 0 (spacja) i jego zadaniem jest poinformowanie odbiornika o rozpoczęciu transmisji znaku. Odbiornik wykrywa zbocze opadające sygnału (z 1 na 0) i uruchamia wewnętrzny licznik bitów, który określa momenty próbkowania kolejnych bitów danych. Bity stopu, zawsze równe 1 (mark), zapewniają minimalny odstęp między kolejnymi znakami i gwarantują, że linia powróci do stanu spoczynku przed rozpoczęciem następnej transmisji.

Dzięki oversamplingowi (najczęściej 16×) odbiornik próbkuje linię w środku każdego bitu, co minimalizuje ryzyko błędnego odczytu na krawędziach. W transmisji synchronicznej zamiast bitów start/stop stosuje się flagi HDLC (01111110) i bit stuffing, aby utrzymać synchronizację w długim strumieniu danych. Mechanizm CRC w synchronicznej jest znacznie skuteczniejszy niż bit parzystości w asynchronicznej – podczas gdy parzystość wykrywa tylko nieparzystą liczbę błędów, CRC-16 wykrywa praktycznie wszystkie błędy w ramce.

Brak wspólnego sygnału taktującego w transmisji asynchronicznej oznacza, że nadajnik i odbiornik muszą polegać na własnych generatorach zegara, których częstotliwości różnią się o pewną tolerancję. Zazwyczaj dopuszczalna różnica wynosi ±2% dla prędkości do 115200 baud, co przy 16× oversamplingu przekłada się na maksymalne przesunięcie fazy o około 3 próbki na koniec 10-bitowej ramki. Dla porównania, w transmisji synchronicznej z DPLL odchyłka fazy jest korygowana na bieżąco w każdym bicie.

W protokole HDLC i PPP synchronizacja na poziomie ramki odbywa się za pomocą flag 01111110, a preambuła w Ethernet zapewnia DPLL czas na ustabilizowanie się przed odebraniem danych. Bit stuffing stosowany w tych protokołach nie tylko zapobiega fałszywej detekcji flagi, ale także wymusza wystąpienie zboczy w strumieniu, co ułatwia pracę pętli DPLL. Kodowanie NRZI w USB dodatkowo zwiększa gęstość przejść poprzez zmianę stanu przy każdym logicznym zerze.

Transmisja asynchroniczna pozwala na przesyłanie znaków w dowolnych odstępach czasu, co jest naturalne dla interakcji człowiek-maszyna i aplikacji terminalowych. W przerwach między znakami linia pozostaje w stanie spoczynku (mark = 1), nie ma konieczności przesyłania żadnych znaków wypełnienia. W transmisji synchronicznej przerwy w transmisji muszą być wypełniane flagami HDLC (01111110) lub specjalnymi symbolami idle, aby DPLL nie stracił synchronizacji.

Protokół PPP na łączach synchronicznych wypełnia okresy bez danych flagami, co utrzymuje ciągłość strumienia bitów i stabilność pętli DPLL. W przypadku transmisji asynchronicznej, UART po wykryciu bitu startu po prostu odczytuje 8–9 kolejnych bitów i zwraca do stanu spoczynku. CRC w transmisji synchronicznej jest obliczany dla całej ramki w sposób ciągły, podczas gdy w asynchronicznej kontrola błędów ogranicza się do pojedynczego bitu parzystości na znak, co jest znacznie słabszym mechanizmem.

UART (Universal Asynchronous Receiver-Transmitter) jest podstawowym układem realizującym transmisję asynchroniczną i stanowi element niemal każdego mikrokontrolera. RS-232 definiuje poziomy napięć dla transmisji asynchronicznej (±3–15 V) oraz zestaw sygnałów sterujących (RTS, CTS, DTR, DSR) umożliwiających kontrolę przepływu. GPS NMEA 0183 wykorzystuje transmisję asynchroniczną 8N1 przy prędkości 4800 baud do przesyłania danych nawigacyjnych w formacie tekstowym ASCII.

MIDI (Musical Instrument Digital Interface) używa asynchronicznej transmisji szeregowej z prędkością 31,25 kbaud do komunikacji między instrumentami muzycznymi a komputerami. W porównaniu z transmisją synchroniczną, standardy asynchroniczne są znacznie prostsze w implementacji, ale nie osiągają prędkości rzędu Gb/s charakterystycznych dla Ethernet czy PCIe. Współczesne układy UART często integrują funkcje automatyzujące obsługę ramek asynchronicznych, w tym generowanie i weryfikację bitu parzystości oraz wykrywanie błędów ramki (framing error).

Bit startu w transmisji asynchronicznej jest wykrywany przez odbiornik poprzez obserwację zbocza opadającego na linii danych – przejście ze stanu spoczynku (1) do stanu 0. Aby odróżnić prawdziwy bit startu od szpilki zakłócenia, odbiornik z oversamplingiem 16× próbkuje linię po 8 okresach od pierwszego wykrytego zbocza i sprawdza, czy linia nadal jest w stanie 0. Jeśli tak, bit startu jest potwierdzany i rozpoczyna się odbiór danych.

W transmisji synchronicznej odpowiednikiem bitu startu jest preambuła – dłuższa sekwencja bitów (np. 101010... w Ethernet lub flaga 01111110 w HDLC), która synchronizuje DPLL przed właściwą transmisją. Bit stuffing w HDLC i PPP zapobiega przypadkowemu wystąpieniu flagi w danych, co dla bitu startu nie jest potrzebne, ponieważ ma on stałą wartość 0 i jest zawsze związany z początkiem znaku. CRC w synchronicznej jest obliczany na podstawie całej ramki i dodawany na jej końcu, podczas gdy w asynchronicznej kontrola błędów ogranicza się do bitu parzystości.

W transmisji asynchronicznej bity danych są przesyłane w kolejności LSB first (Least Significant Bit first), co oznacza, że najmniej znaczący bit bajtu jest transmitowany jako pierwszy zaraz po bicie startu. Na przykład dla znaku 'A' (ASCII 0x41 = 01000001) kolejność bitów na linii to: start (0), 1 (LSB), 0, 0, 0, 0, 0, 1, 0 (MSB), opcjonalna parzystość, stop (1). W transmisji synchronicznej kolejność bitów w ramce zależy od konkretnego protokołu – HDLC również stosuje LSB first dla adresu i sterowania.

W kodowaniu NRZ i NRZI używanych w transmisji synchronicznej kolejność bitów jest również istotna, ponieważ wpływa na liczbę przejść sygnału i tym samym na zdolność DPLL do odtworzenia zegara. CRC (Cyclic Redundancy Check) jest obliczany niezależnie od kolejności transmisji bitów i dodawany na końcu ramki w HDLC lub PPP. Bit stuffing w HDLC dotyczy całego strumienia bitów między flagami, niezależnie od kolejności bajtów – po każdych pięciu jedynkach wstawiane jest zero.

Bit parzystości w transmisji asynchronicznej jest najprostszym mechanizmem detekcji błędów, który polega na dodaniu do ramki jednego dodatkowego bitu tak, aby całkowita liczba jedynek była parzysta (even parity) lub nieparzysta (odd parity). W przypadku znaku 'A' (0x41 = 01000001) mamy dwie jedynki, więc przy parzystości even bit parzystości wynosi 0. Ograniczeniem tej metody jest brak możliwości wykrycia parzystej liczby błędów oraz braku korekcji.

W transmisji synchronicznej zamiast bitu parzystości stosuje się znacznie bardziej zaawansowany mechanizm CRC (Cyclic Redundancy Check), który potrafi wykryć błędy o dowolnej krotności w ramach całej ramki. CRC-16 stosowany w HDLC i PPP obliczany jest z całego pola danych między flagami i dodawany jako 16-bitowa suma kontrolna. Kodowanie 8B/10B używane w synchronicznych standardach jak SATA czy PCIe zapewnia dodatkową detekcję błędów poprzez sprawdzanie poprawności odebranych symboli – nie wszystkie kody 10-bitowe są dozwolone.

Bity stopu w transmisji asynchronicznej mają zawsze wartość logiczną 1 (mark) i zapewniają minimalny odstęp między kolejnymi znakami. Standardowo stosuje się 1 bit stopu (konfiguracja 8N1), ale w wolniejszych transmisjach lub przy dużych różnicach częstotliwości zegarów stosuje się 2 bity stopu (8N2). Dodatkowy bit stopu daje odbiornikowi więcej czasu na przetworzenie odebranego znaku i przygotowanie się do odbioru następnego.

W transmisji synchronicznej nie ma odpowiednika bitów stopu – ramki następują bezpośrednio po sobie, a przerwy wypełniane są flagami HDLC (01111110) lub symbolami idle. PPP na łączach synchronicznych również wykorzystuje flagi jako wypełnienie między ramkami. Sprawdzanie poprawności bitu stopu (framing error detection) w UART polega na weryfikacji, czy po odebraniu danych linia ma wartość 1 – jeśli nie, odbiornik sygnalizuje błąd ramki, co jest analogiczne do wykrycia nieprawidłowej flagi w HDLC.

Pełna ramka asynchroniczna składa się z bitu startu (0), 5–8 bitów danych (LSB first), opcjonalnego bitu parzystości oraz 1–2 bitów stopu (1), co daje łącznie 7–12 bitów na każdy przesłany znak. Dla najpopularniejszej konfiguracji 8N1 (8 bitów danych, brak parzystości, 1 bit stopu) narzut wynosi 2 bity na 10, czyli 20%. Dla porównania, w transmisji synchronicznej z HDLC narzut na flagi, adres, sterowanie i CRC to zaledwie 6 bajtów niezależnie od rozmiaru danych.

W transmisji synchronicznej każda ramka HDLC zawiera flagę otwarcia (01111110), pole adresu, sterowania, dane, CRC-16 i flagę zamknięcia. PPP rozszerza ten format o pole protokołu (2 bajty) identyfikujące rodzaj danych w ramce. Bit stuffing w HDLC i PPP zapewnia przezroczystość danych poprzez wstawianie zera po każdych pięciu jedynkach, co jest usuwane przez odbiornik. CRC w tych protokołach jest obliczany z pól między flagami i dodawany przed flagą zamknięcia.

Oversampling to technika polegająca na próbkowaniu linii danych z częstotliwością wielokrotnie wyższą niż nominalna prędkość transmisji, co pozwala na precyzyjne określenie środka każdego bitu. W odbiornikach UART standardowy oversampling 16× oznacza, że wewnętrzny zegar próbkuje linię 16 razy w czasie trwania jednego bitu, co przy 9600 baud daje częstotliwość próbkowania 153,6 kHz. Na podstawie tych próbek odbiornik wybiera optymalny moment do odczytu wartości bitu.

W transmisji synchronicznej odpowiednikiem oversamplingu jest DPLL (Digital Phase-Locked Loop), która na podstawie zboczy w odebranym sygnale odtwarza sygnał zegara. Kodowanie Manchester dostarcza zbocze w środku każdego bitu, co daje DPLL stały sygnał do synchronizacji. NRZI z bit stuffingiem (stosowane w USB) wymusza przejścia przy zerach, a stuffing zapobiega zbyt długim sekwencjom bez przejść, co jest kluczowe dla utrzymania synchronizacji DPLL w transmisji synchronicznej.

Wybór mnożnika oversamplingu w UART jest kompromisem między dokładnością synchronizacji a maksymalną osiągalną prędkością transmisji. Przy oversamplingu 4× wymagany zegar odbiornika jest tylko 4 razy szybszy od prędkości transmisji, co pozwala na wyższe prędkości, ale daje mniejszą precyzję próbkowania. Oversampling 16× jest najczęściej stosowany, ponieważ zapewnia dobrą odporność na zakłócenia i wystarczającą precyzję przy umiarkowanych wymaganiach co do częstotliwości zegara.

W transmisji synchronicznej rola oversamplingu jest nieco inna – DPLL analizuje zbocza sygnału i na ich podstawie odtwarza zegar, bez konieczności wielokrotnego próbkowania każdego bitu. Kodowanie NRZ nie zmienia stanu przy długich sekwencjach tych samych bitów, co utrudnia pracę DPLL, podczas gdy kodowanie Manchester gwarantuje przejście co każdy bit. CRC w transmisji synchronicznej jest obliczany niezależnie od metody oversamplingu – stanowi dodatkową warstwę zabezpieczenia przed błędami wynikającymi z niedokładnej synchronizacji.

W odbiorniku UART z oversamplingiem 16× proces odbioru bitu startu rozpoczyna się od wykrycia zbocza opadającego na linii danych. Po upływie 8 okresów zegara próbkującego (połowa czasu trwania bitu) odbiornik ponownie sprawdza stan linii – jeśli nadal jest 0, bit startu jest potwierdzany, co eliminuje fałszywe detekcje spowodowane zakłóceniami. Następnie odbiornik próbkuje każdy kolejny bit w jego środku, odliczając 16 okresów między próbkami.

W transmisji synchronicznej podobną funkcję pełni preambuła – na przykład w Ethernet 7 bajtów naprzemiennych 1 i 0 umożliwia DPLL osiągnięcie stabilnej synchronizacji przed odebraniem SFD (Start Frame Delimiter) i właściwych danych. HDLC używa flagi 01111110 do synchronizacji, a bit stuffing zapobiega pojawieniu się tej flagi w danych. W obu przypadkach DPLL musi być zablokowana na fazę sygnału przed rozpoczęciem odbioru danych, co jest kluczowe dla poprawności transmisji.

Oversampling znacząco zwiększa odporność transmisji asynchronicznej na zakłócenia impulsowe (szpilki), ponieważ krótkie zakłócenia są odrzucane na etapie potwierdzania bitu startu. Dodatkowo próbkowanie w środku bitu, a nie na jego krawędziach, minimalizuje wpływ oscylacji i przesłuchów występujących przy zmianach stanu linii. W przypadku transmisji synchronicznej, DPLL z pętlą sprzężenia fazowego filtruje zakłócenia, a kodowanie Manchester dodatkowo redukuje błędy poprzez podwajanie częstotliwości przejść.

CRC w transmisji synchronicznej stanowi dodatkową linię obrony przed zakłóceniami – nawet jeśli pojedyncze bity zostaną odebrane błędnie, suma kontrolna wykryje uszkodzenie ramki. W HDLC i PPP bit stuffing, choć stosowany głównie do przezroczystości danych, również pomaga w utrzymaniu synchronizacji DPLL podczas długich transmisji. W transmisji asynchronicznej z UART błąd ramki (framing error) jest wykrywany, gdy bit stopu ma wartość 0 zamiast 1, co może być spowodowane zarówno zakłóceniem, jak i niedopasowaniem prędkości.

Interfejs SPI z dedykowaną linią zegara SCLK jest najprostszym przykładem transmisji synchronicznej, gdzie master generuje sygnał taktujący dla wszystkich urządzeń na magistrali. Ponieważ SCLK jest przesyłany osobnym przewodem, odbiornik nie potrzebuje DPLL do odtworzenia zegara – próbkuje dane bezpośrednio na zboczu narastającym lub opadającym SCLK. SPI umożliwia transmisję full-duplex (jednoczesne nadawanie i odbiór) z prędkościami do kilkudziesięciu MHz.

W przeciwieństwie do SPI, protokół HDLC i PPP nie używają osobnej linii zegara – zegar jest odtwarzany ze strumienia danych za pomocą DPLL i odpowiedniego kodowania. Kodowanie NRZI w USB zapewnia przejścia przy zerach, co ułatwia synchronizację, a bit stuffing wymusza przejścia przy długich sekwencjach jedynek. CRC w HDLC i PPP chroni integralność danych, podczas gdy SPI często nie stosuje żadnej sumy kontrolnej, pozostawiając detekcję błędów wyższym warstwom protokołu.

Kodowanie Manchester jest metodą kodowania liniowego, w której każdy bit danych zawiera przejście w środku okresu bitowego: bit 0 jest reprezentowany jako przejście od niskiego do wysokiego (0→1), a bit 1 jako przejście od wysokiego do niskiego (1→0). Gwarantuje to zbocze w każdym bicie, co umożliwia odbiornikowi precyzyjne odtworzenie sygnału zegara za pomocą DPLL bez potrzeby przesyłania osobnej linii zegara. Wadą Manchester jest podwojenie wymaganego pasma w porównaniu z NRZ.

W porównaniu z NRZI, które zmienia stan tylko przy zerach, Manchester jest znacznie prostszy do zsynchronizowania, ale mniej efektywny widmowo. W Ethernet 10BASE-T kodowanie Manchester umożliwiło osiągnięcie 10 Mb/s przy użyciu taniej skrętki i prostych układów DPLL. Dla wyższych prędkości zastąpiono je bardziej efektywnymi kodowaniami, takimi jak 4B/5B (100 Mb/s) czy 64B/66B (10 Gb/s), które oferują mniejszy narzut przy zachowaniu możliwości odtworzenia zegara.

Kodowanie 4B/5B przekształca każde 4 bity danych w 5-bitowy symbol, wybierając spośród 32 możliwych kodów tylko 16 oznaczających dane oraz kilka kodów kontrolnych (np. JK do oznaczania granic ramek). Głównym celem jest zapewnienie, że w strumieniu nigdy nie wystąpi więcej niż 3 kolejne identyczne bity, co umożliwia DPLL utrzymanie synchronizacji. Dodatkowo część kodów kontrolnych służy do sygnalizacji stanów specjalnych, takich jak idle czy error.

Efektywność kodowania 4B/5B wynosi 4/5 = 80%, co oznacza 20-procentowy narzut w stosunku do surowej przepływności bitowej. Fast Ethernet 100BASE-TX wykorzystuje 4B/5B w połączeniu z kodowaniem MLT-3, które redukuje pasmo sygnału. W porównaniu z Manchester (100% narzutu), 4B/5B jest dwukrotnie bardziej efektywne, a w porównaniu z 8B/10B oferuje nieco większą prostotę implementacji kosztem gorszego DC-balance.

Kodowanie 8B/10B, opracowane przez IBM w latach 80., jest zaawansowaną metodą kodowania stosowaną w standardach synchronicznych wymagających DC-balance i niezawodnej synchronizacji. Każdy bajt (8 bitów) jest dzielony na 3 i 5 bitów, które są kodowane odpowiednio na 4 i 6 bitów, dając łącznie 10-bitowy symbol. DC-balance oznacza, że liczba zer i jedynek w strumieniu jest zrównoważona, co eliminuje składową stałą i umożliwia stosowanie transformatorów lub sprzężenia pojemnościowego.

Dodatkową zaletą 8B/10B jest możliwość wykrywania błędów transmisji – nie wszystkie kody 10-bitowe są dozwolone, więc odebranie nieprawidłowego symbolu natychmiast sygnalizuje błąd. Specjalne kody kontrolne (K-codes) umożliwiają oznaczanie granic ramek, co jest wykorzystywane w PCIe, SATA i USB 3.0 zamiast flag HDLC. W przeciwieństwie do prostego NRZ, 8B/10B zapewnia wystarczającą gęstość przejść do stabilnej pracy DPLL nawet przy transmisji długich ciągów tych samych danych.

Porównanie metod synchronizacji ujawnia wyraźny kompromis między narzutem a złożonością implementacji. Dedykowana linia zegara (jak w SPI) ma zerowy narzut, ale wymaga dodatkowego przewodu i cierpi na problem skosu czasowego przy wysokich częstotliwościach. Manchester ma 100% narzutu, ale jest niezwykle prosty w synchronizacji. Kodowanie 4B/5B i 8B/10B oferują 20% narzutu przy umiarkowanej złożoności, a 64B/66B redukuje narzut do około 3% kosztem znacznie bardziej złożonego skramblera.

W kontekście protokołów takich jak HDLC, SDLC i PPP, synchronizacja opiera się na flagach i bit stuffingu, co nie wymaga skomplikowanego kodowania liniowego, ale wprowadza zmienny narzut. DPLL w tych protokołach może działać z prostym kodowaniem NRZI, gdzie przejścia występują przy zerach, a bit stuffing wymusza przejścia przy długich sekwencjach jedynek. CRC stanowi uniwersalną metodę detekcji błędów niezależną od wybranej metody synchronizacji i kodowania.

Transmisja synchroniczna dominuje w aplikacjach wymagających wysokiej przepustowości, takich jak sieci szkieletowe, pamięci masowe i szybkie interfejsy peryferyjne. Jej największą zaletą jest minimalny narzut – brak bitów start/stop między bajtami pozwala osiągnąć efektywność przekraczającą 99% dla dużych ramek. Protokoły takie jak HDLC z CRC i bit stuffingiem zapewniają niezawodność przy zachowaniu wysokiej wydajności.

Główną wadą transmisji synchronicznej jest złożoność implementacji – potrzebne są układy DPLL do odtworzenia zegara, SERDES do serializacji danych oraz zaawansowane kodowanie liniowe (8B/10B, 64B/66B) dla wyższych prędkości. W porównaniu z prostym UART, koszt układów synchronicznych jest znacząco wyższy. Dodatkowo utrzymanie synchronizacji w przerwach transmisji wymaga wysyłania flag lub znaków wypełnienia, co w aplikacjach o niskim współczynniku wykorzystania łącza może być nieefektywne.

Transmisja asynchroniczna jest niezastąpiona w systemach wbudowanych i aplikacjach, gdzie priorytetem jest prostota i niski koszt implementacji. Układ UART jest integralną częścią praktycznie każdego mikrokontrolera, a do komunikacji wystarczą dwa przewody (sygnał danych i masa). Tolerancja na różnice częstotliwości zegarów do ±2–5% sprawia, że urządzenia mogą pracować z niedrogimi generatorami kwarcowymi bez potrzeby precyzyjnej synchronizacji.

Głównym ograniczeniem transmisji asynchronicznej jest niska efektywność przy dużych wolumenach danych – narzut 20–30% oznacza, że przy prędkości 115200 baud rzeczywista przepustowość danych wynosi około 92 kb/s dla 8N1. W przeciwieństwie do synchronicznych protokołów takich jak HDLC czy PPP, UART nie oferuje zaawansowanej detekcji błędów – bit parzystości jest słabym zamiennikiem CRC. Ponadto maksymalna prędkość transmisji asynchronicznej jest ograniczona do około 1–2 Mb/s ze względu na narastające problemy z synchronizacją.

Tabela porównawcza obu metod transmisji pokazuje fundamentalne różnice w podejściu do synchronizacji. Transmisja synchroniczna z protokołem HDLC wymaga wspólnego zegara (przesyłanego lub odtwarzanego) i osiąga efektywność bliską 100% przy przepływnościach rzędu Gb/s. Asynchroniczna z UART działa z niezależnymi zegarami, ale jej maksymalna prędkość jest praktycznie ograniczona do kilku Mb/s ze względu na narzut bitów start/stop i ograniczoną tolerancję zegarów.

W kontekście CRC i detekcji błędów, transmisja synchroniczna ma znaczącą przewagę – CRC-16 w HDLC lub CRC-32 w Ethernet wykrywają praktycznie wszystkie błędy w ramce. W transmisji asynchronicznej bit parzystości wykrywa tylko nieparzystą liczbę błędów w pojedynczym znaku. Metody kodowania takie jak Manchester, NRZI czy 8B/10B są stosowane wyłącznie w transmisji synchronicznej, ponieważ asynchroniczna nie wymaga odtwarzania zegara ze strumienia danych – synchronizacja odbywa się od nowa przy każdym bicie startu.

SDH/SONET to przykład sieci synchronicznej, gdzie precyzyjna synchronizacja zegarów we wszystkich węzłach jest kluczowa dla poprawnego działania. Wszystkie węzły sieci SDH są zsynchronizowane do wspólnego zegara referencyjnego (np. atomowego lub GPS), co pozwala na bezkonfliktowe łączenie strumieni danych z różnych źródeł. Ramka STM-1 o okresie 125 µs zawiera wskaźniki (AU pointers), które umożliwiają niewielkie przesunięcia fazowe między węzłami bez utraty synchronizacji.

SDH stosuje kodowanie NRZ ze skramblerem, który zapewnia odpowiednią gęstość zboczy do odtworzenia zegara przez DPLL w odbiorniku. W przeciwieństwie do HDLC, SDH nie używa flag ani bit stuffingu – granice ramek są wyznaczane przez precyzyjny zegar i wskaźniki. BIP (Bit Interleaved Parity) w SDH (BIP-8, BIP-24) służy do monitorowania jakości transmisji na poszczególnych odcinkach łącza, co umożliwia szybkie wykrywanie degradacji i przełączanie na ścieżki zapasowe. PPP jest często używany do enkapsulacji pakietów IP w ramach SDH.

Ethernet jest najszerzej stosowanym standardem transmisji synchronicznej w sieciach lokalnych, wykorzystującym preambułę (7 bajtów 10101010) do synchronizacji DPLL przed odebraniem ramki. Po preambule następuje SFD (Start Frame Delimiter – 10101011), który oznacza początek właściwej ramki, a całość kończy pole FCS (Frame Check Sequence) z 32-bitowym CRC. W przeciwieństwie do HDLC, Ethernet nie używa flag ani bit stuffingu – granice ramek są wyznaczane przez odstępy międzyramkowe i preambułę.

W zależności od prędkości, Ethernet stosuje różne metody kodowania: Manchester dla 10BASE-T, 4B/5B z MLT-3 dla 100BASE-TX, 4D-PAM5 dla 1000BASE-T oraz 64B/66B dla 10GBASE-T. We wszystkich przypadkach DPLL w odbiorniku odtwarza zegar z sygnału danych, co wymaga odpowiedniej gęstości zboczy. W przeciwieństwie do PPP, Ethernet nie negocjuje parametrów połączenia na poziomie fizycznym – autonegocjacja dotyczy tylko prędkości i dupleksu, a nie protokołów warstwy wyższej.

SPI i I²C to synchroniczne interfejsy wewnątrzsystemowe, które różnią się znacząco pod względem złożoności, szybkości i liczby wymaganych linii sygnałowych. SPI (Serial Peripheral Interface) jest szybszy (do 80 MHz) i prostszy w implementacji, ale wymaga oddzielnej linii SS (Slave Select) dla każdego urządzenia. I²C (Inter-Integrated Circuit) jest wolniejszy (do 5 MHz), ale potrzebuje tylko dwóch linii (SCL i SDA) dla całej magistrali obsługującej wiele urządzeń z adresowaniem 7- lub 10-bitowym.

W przeciwieństwie do HDLC czy PPP, SPI i I²C nie stosują CRC, flag ani bit stuffingu – detekcja błędów jest minimalna lub nie występuje w ogóle. NRZ jest naturalnym wyborem dla tych interfejsów, ponieważ DPLL nie jest potrzebna – zegar jest przesyłany osobną linią. I²C wykorzystuje arbitraż na poziomie bitów do rozstrzygania kolizji między nadajnikami, co jest unikalną cechą wśród synchronicznych interfejsów. W porównaniu z UART (asynchronicznym), oba interfejsy wymagają większej liczby linii, ale oferują wyższe prędkości i pełną synchronizację.

USB (Universal Serial Bus) jest przykładem synchronicznej magistrali szeregowej wykorzystującej kodowanie NRZI (Non-Return-to-Zero Inverted), w którym logiczne zero powoduje zmianę stanu linii, a logiczna jedynka pozostawia stan bez zmian. Aby zapewnić wystarczającą liczbę przejść do odtworzenia zegara przez DPLL, USB stosuje bit stuffing – po sześciu kolejnych jedynkach nadajnik wstawia zero, co wymusza zmianę stanu. Każdy pakiet USB rozpoczyna się sekwencją SOP (Start of Packet) synchronizującą DPLL.

W przeciwieństwie do HDLC, gdzie flagi i bit stuffing dotyczą całej ramki, w USB stuffing jest stosowany na poziomie strumienia bitów między SOP a EOP (End of Packet). CRC w USB jest obliczany dla pól pakietów – tokeny używają CRC-5, a dane CRC-16. W porównaniu z asynchronicznym UART, USB oferuje znacznie wyższe prędkości (do 20 Gb/s w USB 3.2), ale wymaga bardziej złożonych układów nadawczo-odbiorczych z DPLL i kodowaniem NRZI.

UART (Universal Asynchronous Receiver-Transmitter) jest najpowszechniej stosowanym układem transmisji asynchronicznej, wbudowanym w większość mikrokontrolerów i procesorów. Jego działanie opiera się na rejestrze przesuwnym, który szeregowo wysyła lub odbiera bity z ustaloną prędkością (baud rate). W przeciwieństwie do synchronicznych układów z DPLL, UART używa prostego dzielnika częstotliwości do generowania zegara próbkującego z oversamplingiem (najczęściej 16×).

Konfiguracja UART (baud rate, liczba bitów danych, parzystość, bity stopu) musi być identyczna po obu stronach łącza – w przeciwieństwie do PPP, który negocjuje parametry połączenia automatycznie. UART nie ma mechanizmu CRC – jedyną ochroną jest opcjonalny bit parzystości, który wykrywa tylko nieparzystą liczbę błędów. W porównaniu z HDLC czy PPP, UART jest znacznie prostszy, ale nie nadaje się do transmisji o wysokich wymaganiach co do niezawodności i przepustowości.

RS-232 jest standardem transmisji szeregowej asynchronicznej, który definiuje nie tylko format ramki, ale także poziomy napięć (±3–15 V), sygnały sterujące oraz złącze. W odróżnieniu od TTL UART (0–5 V), RS-232 stosuje wyższe napięcia dla zwiększenia odporności na zakłócenia na dłuższych dystansach (do 15 m przy 9600 baud). Sygnały sterujące RTS/CTS umożliwiają kontrolę przepływu sprzętowego, co zapobiega przepełnieniu buforów odbiornika.

W przeciwieństwie do synchronicznych standardów jak Ethernet czy HDLC, RS-232 nie ma mechanizmu CRC ani potwierdzeń na poziomie fizycznym – kontrola błędów musi być realizowana w wyższych warstwach protokołu. RS-232 używa kodowania NRZ z poziomami napięć, gdzie mark (1) to napięcie ujemne, a spacja (0) to napięcie dodatnie. Mimo że nowsze interfejsy (USB, Ethernet) wyparły RS-232 z komputerów osobistych, standard ten jest nadal powszechnie stosowany w przemyśle, sterownikach PLC i systemach laboratoryjnych.

Protokół NMEA 0183 wykorzystuje asynchroniczną transmisję UART do przesyłania danych nawigacyjnych z odbiorników GPS do procesorów i wyświetlaczy. Dane są przesyłane w formacie tekstowym ASCII z prędkością 4800 baud i konfiguracją 8N1, co zapewnia kompatybilność z szeroką gamą urządzeń. Każde zdanie NMEA zaczyna się od znaku $ i zawiera sumę kontrolną XOR (opcjonalną) obliczaną ze znaków między $ a *, co jest znacznie prostsze niż CRC w HDLC.

W porównaniu z synchronicznymi protokołami takimi jak PPP czy HDLC, NMEA jest niezwykle prosty i nie wymaga negocjacji parametrów połączenia. Nie stosuje się tu bit stuffingu, flag ani zaawansowanego kodowania – surowe NRZ z UART w zupełności wystarcza. CRC-16 stosowany w HDLC i PPP jest znacznie skuteczniejszy niż suma kontrolna XOR w NMEA, ale dla aplikacji nawigacyjnych prostota i niski narzut są ważniejsze niż absolutna niezawodność transmisji.

MIDI (Musical Instrument Digital Interface) wykorzystuje asynchroniczną transmisję szeregową z unikalną prędkością 31,25 kbaud wynikającą z dzielnika zegara 1 MHz / 32. Każdy komunikat MIDI składa się z 1–3 bajtów w konfiguracji 8N1, gdzie pierwszy bajt (status) określa typ zdarzenia (Note On, Note Off, Control Change) i kanał MIDI, a kolejne bajty niosą parametry. W przeciwieństwie do HDLC, MIDI nie ma flag, bit stuffingu ani CRC – kontrola przepływu odbywa się na poziomie protokołu.

W porównaniu z synchronicznymi standardami, MIDI jest wyjątkowo prosty i niezawodny w swoim zastosowaniu. Nie stosuje się tu kodowania Manchester ani NRZI – UART z NRZ w zupełności wystarcza dla tej prędkości. DPLL nie jest potrzebna, ponieważ UART z oversamplingiem 16× przy 31,25 kbaud wymaga zegara zaledwie 500 kHz. W przeciwieństwie do PPP czy HDLC, które mogą przenosić dowolne dane binarne, MIDI przesyła tylko małe komunikaty sterujące i nie wymaga zaawansowanego CRC.

Przykład transmisji znaku 'A' (ASCII 0x41) w trybie asynchronicznym 8E1 ilustruje pełną strukturę ramki: bit startu (0), 8 bitów danych LSB first (10000010), bit parzystości even (0) i bit stopu (1). Łącznie 11 bitów na linii, z czego tylko 8 to dane użyteczne – efektywność wynosi 8/11 ≈ 72,7%. W transmisji synchronicznej ten sam znak byłby przesłany jako część większej ramki HDLC lub PPP, gdzie narzut na flagi i CRC jest rozłożony na wiele bajtów.

Gdyby przesyłać pojedyncze znaki 'A' w trybie synchronicznym z HDLC, każda ramka zawierałaby flagę otwarcia (8 bitów), adres (8), sterowanie (8), dane (8), CRC-16 (16) i flagę zamknięcia (8) – łącznie 56 bitów na 8 bitów danych, czyli efektywność zaledwie 14,3%. Dlatego transmisja synchroniczna opłaca się tylko dla większych bloków danych. Bit stuffing w HDLC mógłby dodatkowo zwiększyć rozmiar ramki, gdyby w danych wystąpiła sekwencja pięciu jedynek.

Porównanie efektywności dla 1 MB danych pokazuje dramatyczną różnicę między obiema metodami. Przy transmisji asynchronicznej 8N1 potrzeba 10 485 760 bitów (1MB × 10 bitów/bajt), podczas gdy synchroniczna z ramkami 1500 bajtów wymaga około 8 388 808 bitów (dane + narzut ~200 bitów na ramkę). Oznacza to, że transmisja synchroniczna jest o około 20% szybsza przy tej samej przepływności bitowej – różnica ta rośnie z rozmiarem przesyłanych danych.

CRC w transmisji synchronicznej (CRC-32 w Ethernet lub CRC-16 w HDLC) dodaje znikomy narzut w porównaniu z bitami start/stop w asynchronicznej. Dla ramki 1500 bajtów narzut CRC-32 to tylko 32 bity na 12 000 bitów danych (0,27%). Bit stuffing w HDLC i PPP może dodać średnio 1 bit na każde 32 bity danych (około 3,1%), co przy 1 MB danych daje około 260 000 dodatkowych bitów, ale nadal pozostawia transmisję synchroniczną znacznie bardziej efektywną niż asynchroniczną.

Arduino Uno z mikrokontrolerem ATmega328P jest klasycznym przykładem zastosowania transmisji asynchronicznej UART w systemach wbudowanych. Komunikacja z komputerem odbywa się przez wbudowany UART na pinach TX (1) i RX (0) z domyślną konfiguracją 9600 8N1. W przeciwieństwie do synchronicznych interfejsów takich jak SPI czy I²C, UART wymaga tylko dwóch przewodów (dane + masa), co jest wygodne w prototypowaniu.

Różne prędkości transmisji UART (9600, 19200, 115200 baud) są realizowane przez dzielniki częstotliwości zegara mikrokontrolera, co może prowadzić do błędów kwantyzacji. W porównaniu z HDLC czy PPP, Arduino UART nie oferuje CRC ani potwierdzeń – jeśli potrzebna jest niezawodna transmisja, implementuje się ją programowo w wyższej warstwie. Bit stuffing i flagi typowe dla transmisji synchronicznej nie są tu stosowane, a synchronizacja opiera się wyłącznie na oversamplingu i detekcji bitu startu.

Podsumowując, wybór między transmisją synchroniczną a asynchroniczną zależy od konkretnych wymagań aplikacji. Transmisja synchroniczna z protokołami HDLC, SDLC, PPP i Ethernet oferuje wysoką efektywność i duże prędkości kosztem złożoności implementacji wymagającej DPLL, odpowiedniego kodowania (Manchester, NRZI, 8B/10B) i CRC. Asynchroniczna transmisja UART jest prosta i tania, ale jej efektywność spada do 70–80%, a maksymalna prędkość jest ograniczona.

CRC (Cyclic Redundancy Check) jest kluczowym mechanizmem detekcji błędów w transmisji synchronicznej, znacznie skuteczniejszym niż bit parzystości w asynchronicznej. Bit stuffing w HDLC i PPP zapewnia przezroczystość danych i pomaga w synchronizacji DPLL, zapobiegając pojawieniu się flagi w strumieniu. Kodowanie Manchester i NRZI z bit stuffingiem umożliwiają odtworzenie zegara bez dodatkowej linii, co jest fundamentalne dla nowoczesnych sieci synchronicznych.

Przedstawiony materiał stanowi wprowadzenie do tematyki transmisji synchronicznej i asynchronicznej, która jest fundamentem współczesnej telekomunikacji. Zrozumienie różnic między tymi metodami, roli sygnału zegara, DPLL oraz kodowania liniowego (NRZ, NRZI, Manchester) jest niezbędne dla każdego inżyniera sieci i systemów wbudowanych. Protokoły HDLC, SDLC i PPP wykorzystujące transmisję synchroniczną z bit stuffingiem i CRC stanowią podstawę wielu rozwiniętych standardów komunikacyjnych.

Szczególnie istotne jest zrozumienie mechanizmu CRC, który mimo niewielkiego narzutu (2–4 bajty na ramkę) zapewnia praktycznie całkowitą detekcję błędów transmisji. W porównaniu z prostym bitem parzystości transmisji asynchronicznej, CRC oferuje znacznie wyższy poziom ochrony danych. Preambuła i flagi w ramkach synchronicznych pełnią kluczową rolę w synchronizacji DPLL, a bit stuffing gwarantuje, że sekwencje specjalne nie pojawią się w przesyłanych danych, co zapewnia integralność transmisji.

Pytania do dyskusji mają na celu sprawdzenie zrozumienia kluczowych koncepcji związanych z transmisją synchroniczną i asynchroniczną. Warto zastanowić się, dlaczego transmisja synchroniczna z protokołem HDLC jest bardziej efektywna od asynchronicznej z UART przy przesyłaniu dużych plików, ale traci tę przewagę przy pojedynczych znakach. Rola CRC jako mechanizmu detekcji błędów jest często niedoceniana – bez niego nowoczesne sieci o wysokich prędkościach nie mogłyby funkcjonować niezawodnie.

Analizując kodowanie Manchester, NRZ i NRZI, warto zrozumieć, dlaczego to pierwsze jest stosowane tylko w wolniejszych standardach (10BASE-T), podczas gdy szybsze sieci wybierają 4B/5B czy 8B/10B. Bit stuffing w HDLC i PPP jest eleganckim rozwiązaniem problemu przezroczystości danych, ale wprowadza zmienny narzut, co w aplikacjach czasu rzeczywistego może być wyzwaniem. DPLL w transmisji synchronicznej jest kluczowym układem umożliwiającym odtworzenie zegara – bez niego niemożliwe byłoby osiągnięcie prędkości rzędu Gb/s charakterystycznych dla dzisiejszych sieci.