> różnice zegarów powyżej 2% rozwalają transmisję

Różnice stałe w czasie? Transmisję asynchroniczną? Przy przesyłaniu bajtów?
Nie sądzę. 5% to jeszcze bym powiedział - może się zdarzyć w systemach
sprzętowych sprzed 30 lat.
Wydaje mi się, że to wynika wprost z matematyki:
Przekłamanie może dotyczyć zmiany położenia próbki o 1/2 bitu.
Zwykle, z natury rzeczy, dotyczy to ostatniego bitu przesyłanego bajtu
danych (uwzględniając bit STARTu i STOPu.
Dla transmisji 8-bitowej, bez sprawdzania parzystości, bit STOP o długości
1,
mamy 10 transmitowanych bitów.
Przy nadawaniu 10 bitów mamy:
(1/2)/10*100%= 5%
Jeśli dodamy parzystość, to jeśli chodzi o wrażliwość na różnice prędkości,
wygląda, że jest jeszcze gorzej:
(1/2)/11*100%= ~ 4,5%
No, ale nie 2%

Już w samochodowych systemach OBD II, przy transmisji szeregowej, nadawany
był bajt synchronizacji 55h.
przy 5bps.
Dopiero potem system przełącza się na 8192bps
Odbiornik powinien się dostosować do prędkości nadajnika.
Co za różnica czy nadajemy z 115kbodów, czy 20% szybciej 138kbodów.
Ważne, aby urządzenia się zsynchronizowały.

W starych rozwiązaniach na 8051 @12MHz i Fclk/Finstr=12 to może i był
problem z rozdzielczością w ustawieniu prędkości transferu.
Teraz na mikrokontrolerach o rząd większym zegarze i mniejszym współczynniku
Fclk/Finstr to już nie jest problem.

Powiedziałbym, że teraz transmisja w RS232 czy RS485 daje nowe możliwości.
Wynikają one bezpośrednio ze zwiększenia prędkości zegara mikrokontrolerów i
doświadczenia.

W komputerach PC ciągle jeszcze widnieją standardy prędkości nadawania.
U mnie Windows daje takie możliwości wybrania prędkości COMa:
110,300,1200,2400,4800,9600,19200,38400,57600,115200
,230400,460800,921600.
Jakie to wydaje się głupie.
Dlaczego nie wpisać dowolnej prędkości, a tylko standardy?
No przynajmniej do tych 38400.


--
-- .
pozdrawiam
Sylwester Łazar
http://www.alpro.pl
http://www.rimu.pl -oprogramowanie do edycji schematów
i projektowania PCB