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

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From Polish to

Threaded View
Witam
Zastanawiam się nad przypadkiem, gdy urządzenie nadawcze wysyła ciągle jakie
dane po RS-232. Gdy tylko zakończy transmisję jednego bajtu, zaraz
rozpoczyna transmisję następnego. Czy w takiej sytuacji urządzenie odbiorcze
może odebrać dane prawidłowo, jeśli zostanie włączone w losowym momencie?
Wydaje mi się, że nie, i w ponad 90% przypadków będzie odbierać śmieciowe
dane. Rozwiązaniem problemu byłoby rozpoczęcie transmisji przez nadajnik
dopiero, gdy odbiornik jest już włączony i ma możliość poprawnego załapania
bitu startu. Dobrze kombinuję? Tak mi wyszło z rozważań i eksperymentów :)

--
Grzegorz Niemirowski
http://www.grzegorz.net /
We've slightly trimmed the long signature. Click to see the full one.
Re: RS-232 a ciągły strumień danych
W dniu 01.04.2011 19:51, Grzegorz Niemirowski pisze:
Quoted text here. Click to load it
Dlatego wynaleziono 1.5 bita stopu - w ten sposób można jednoznacznie
wykryć koniec bajtu. I zacząć prawidłowo dekodować kolejny.

--
Pozdrawiam
Michoo

Re: RS-232 a cišgły strumień danych
On Fri, 01 Apr 2011 20:18:57 +0200,  Michoo wrote:
Quoted text here. Click to load it

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.





Re: RS-232 a cišgły strumień danych

Quoted text here. Click to load it

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.


Re: RS-232 a cišgły strumień danych
On Sat, 02 Apr 2011 12:50:12 +0200,  Mirek wrote:
Quoted text here. Click to load it

Dokladnie tak dziala.

Quoted text here. Click to load it

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


Quoted text here. Click to load it

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,

Quoted text here. Click to load it

bo wtedy "przeklamanie" masz caly czas.

Quoted text here. Click to load it

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


J.


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

Quoted text here. Click to load it

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.

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

Quoted text here. Click to load it

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

--
My jsme Borgové. Sklopte štíty a vzdejte se. Odpor je marný.

Re: RS-232 a ciągły strumień danych
W dniu 2011-04-01 20:47, Waldemar Krzok pisze:
Quoted text here. Click to load it

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.

Re: RS-232 a ciągły strumień danych
Hello Zbych,


[...]

Quoted text here. Click to load it

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.

--
Best regards,
 RoMan                            mailto:roman@pik-net.pl
We've slightly trimmed the long signature. Click to see the full one.
Re: RS-232 a ciągły strumień danych
W dniu 2011-04-02 08:14, RoMan Mandziejewicz pisze:
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

Ale mowa jest o asynchronicznej.



Re: RS-232 a ciągły strumień danych
Hello Zbych,


Quoted text here. Click to load it

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

Quoted text here. Click to load it

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.


--
Best regards,
 RoMan                            mailto:roman@pik-net.pl
We've slightly trimmed the long signature. Click to see the full one.
Re: RS-232 a ciągły strumień danych
W dniu 2011-04-02 09:08, RoMan Mandziejewicz pisze:
Quoted text here. Click to load it

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

Quoted text here. Click to load it

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.

Re: RS-232 a ciągły strumień danych
W dniu 2011-04-01 20:19, Mirek pisze:
Quoted text here. Click to load it

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.

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

Quoted text here. Click to load it

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


Re: RS-232 a ciągły strumień danych
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
http://www.ietf.org/rfc/rfc1662.txt . 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ć".

Re: RS-232 a ciągły strumień danych
Quoted text here. Click to load it

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.

Re: RS-232 a ciągły strumień danych
Dziękuję wszystkim za odpowiedzi.

--
Grzegorz Niemirowski
http://www.grzegorz.net /
We've slightly trimmed the long signature. Click to see the full one.

Site Timeline