RS-232 a ciągły strumień danych

W dniu 01.04.2011 19:51, Grzegorz Niemirowski pisze:

Dlatego wynaleziono 1.5 bita stopu - w ten sposób można jednoznacznie wykryć koniec bajtu. I zacząć prawidłowo dekodować kolejny.

RS-232 jest dwukierunkowy. Dane są wysyłane zwykle pakietami i potwierdzane. Nie ma sensu słać godzine danych na ślepo bez potwierdzenia - przynajmniej ja się z tym nie spotkałem. Jeśli jest coś wysyłane bez potwierdzania to są to zwykle powtarzające się pakiety rozdzielone czasem bezczynności.

Mirek.

Niekoniecznie. Osobiście pisałem oprogramowanie do urządzenia, które wysyłało "na ślepo" dane do komputera. Wysyłane co prawda pakietami po kilkadziesiąt bajtów, ale bez czasu bezczynności. Jak coś się straciło to nie było wielkiego problemu, byle nie za dużo i trzeba było wiedzieć ile i gdzie. Sprawa była załatwiona bardzo prosto, bo pierwszy bajt ramki miał ustawiony MSB na 1, pozostałe bajty miały 0. W ramce był przesyłany licznik. Tak więc komputer wiedział, po pierwszej synchronizacji, gdzie jest i "o sso chodzi". Tylko urządzenie musiało formatować dane tak, by się mieściły w 7- bitach bajtu.

Waldek

Jeśli ten strumień danych podzielisz logicznie na wysyłane jedna po drugiej "ramki" i co jakiś czas będziesz przesyłał jakiś magiczny bajt ("flagę") oznaczający początek/koniec ramki to prawidłowy odbiór jest możliwy. Oczywiście takie rozwiązanie powoduje, że wewnątrz ramki nie może pojawić się kod oznaczający flagę ale da się to obejść. Odsyłam do

RFC1661 i 1663 również będą przydatne. Oczywiście pomysł tam opisany można na własne potrzeby znacznie uprościć.

Podsumowując, jeśli włączysz odbiornik w losowym momencie to powinien on zignorować wszystkie bajty aż do napotkania "flagi" a po jej napotkaniu powinien się "zsynchronizować".

Chyba nie dlatego - po dluzszym kablu i tak sie znieksztalci, malo kto to stosuje, podejrzewam ze bylo im do spelnienia jakis zalozonych predkosci potrzebne.

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. Albo strumien nie bedzie jednak ciagly i sie trafi mala przerwa i wtedy zalapie.

Choc w specyficznych przypadkach moze byc problem. Wiekszy problem moze byc z trafieniem w strukture ramek.

Ot, nauczka na przyszlosc - konczyc ramke przez FF.

J.

Tylko to rozwiązanie nadal nie umożliwia synchronizacji pojedynczego bajtu. Musi być albo dłuższa przerwa w pewnym momencie, albo jak zaproponował J.F. bajt FF.

[...]

Dlaczego wymyślacie rozwiązania, które już dawno są wymyslone i działają? - w transmisji asynchronicznej uzywa się 1.5 lub 2 bitów stopu, - w transmisji synchronicznej używa się znaków SYNC nadawanych w czasie, gdy nie ma nic innego do nadania.

W dniu 2011-04-02 08:14, RoMan Mandziejewicz pisze:

A jak rozróżnisz dwa bity stopu od dwóch bitów 1,1 w połowie bajtu?

1.5 bitu stopu też na wiele się nie zda.

Ale mowa jest o asynchronicznej.

Zdaje się na bardzo wiele - czas trwania ułatwia odróżnienie stopu od innej kombinacji.

Transmisja asynchroniczna, jak sama nazwa wskazuje, nie wymaga synchronizacji. Jest stosowana wtedy, gdy strumień nie jest ciągły. Dla ciągłego przechodzi się na synchroniczną, żeby uniknąć problemów z synchronizacją właśnie.

W dniu 2011-04-02 09:08, RoMan Mandziejewicz pisze:

To pokaż mi uart, który to robi.

Teoretyzujesz. Nikt nie będzie wymieniał RS tylko dlatego, że ma ciągły strumień danych do wysłania do komputera. Prędzej doda parę sztuczek programowych.

Tylko że zamiast tej flagi można zrobić przerwę i problem fałszywej flagi znika. Z resztą wątkotwórce interesuje jak znaleźć w strumieniu początek bajtu a nie początek ramki. Jeżeli jest potrzeba wpinania się jakimś np. monitorem w już biegającą transmisję to tylko transmisja pakietami z przerwami - przynajmniej ja tak bym to zrobił. Jak mamy ciągły strumień np 9600 i nie ma czasu na przerwy to zwiększyć prędkość i nadawać z przerwami.

Mirek.

To chyba tak nie działa. 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. 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. 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. 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.

Mirek.

Tak mają niektóre wagi do kas fiskalnych. Mają tylko 3 piny - zasilanie, masę i wysyłanie danych. Po włączeniu zasilania i autokalibracji, waga w stałych odstępach wysyła aktualny odczyt.

Dokladnie tak dziala.

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

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,

bo wtedy "przeklamanie" masz caly czas.

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

J.

Użytkownik "Tomasz Wójtowicz" <SPAMMERS_GO snipped-for-privacy@SPAMMERS.COM napisał w wiadomości news:in795h$a0p$ snipped-for-privacy@news.onet.pl...

Zapominasz o jednym. Nie jest to strumień ciągły więc i kłopotów z synchronizacją nie ma.

Dziękuję wszystkim za odpowiedzi.