On Sat, 02 Apr 2011 12:50:12 +0200, Mirek wrote:
>On 02.04.2011 06:11, J.F. wrote:
>> A synchronizacja - jesli strumien sie zmienia, to kiedys nie trafi w
>> sekwencje 1-0 stop-start, przeskoczy o kilka bitow, znow nie trafi,
>> przeskoczy, az w koncu trafi wlasciwie.
>
>To chyba tak nie działa.

Dokladnie tak dziala.

>Często się wpinałem jakimś komputerem z
>terminalem do jakiegoś urządzenia (wysyłającego dane paczkami) i
>zdarzało się że pierwsza linijka po podłączeniu to były śmiecie, a
>następne przychodziły już poprawnie.

byc moze byl odstep miedzy paczkami i to juz wystarcza do odzyskania
synchronizacji.


>Jak parametry transmisji były źle
>ustawione czyli liczba bitów danych i stopu to cały czas szły śmiecie -
>czyli UART jak złapie coś, co wygląda na początek to dekoduje i reszte
>ma w d.

Owszem, ale jednak poczeka na bit startu, czyli 0 po 1.
i to czesto wystarcza zeby w strumieniu bitow trafil w koncu
prawidlowo.
W wiekszosci uartow chyba nawet ilosc bitow stopu nie ma wplywu na
odbiornik - jesli nie znajdzie pierwszego to zglasza Framing Error,
drugiego nawet nie sprawdza, tylko czeka na bit startu. Smieci
bedziesz mial jesli odbiornik jest 8 bitow danych a nadajnik nadaje 7,
albo 7 plus parzystosc,

>Raz pamiętam, że non stop miałem krzaki na ekranie i
>kombinowałem z tymi bitami a się okazało, że szybkość transmisji była
>inna - i tak dekodowało coś mimo to.

bo wtedy "przeklamanie" masz caly czas.

>Swoją drogą te UART-y w modemach
>(zewnętrznych) były sprytnie zrobione, bo odpowiadały niezależnie z jaką
>prędkością się do nich gadało - tutaj zdajesie kluczem do sukcesu są
>literki AT lub at - na ich podstawie są określane parametry transmisji.

tak pisza, ale one jakby sprytniej dzialaly. To wymaga albo
nietypowego UART, albo bardzo sprytnie oprogramowanego.


J.