Goto page 1, 2 Next
Grzegorz Niemirowski
Guest
Fri Apr 01, 2011 5:51 pm
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/
OE PowerTool i Outlook Express:
http://www.grzegorz.net/oe/
Uptime: 36 days, 21 hours, 45 minutes and 29 seconds
Michoo
Guest
Fri Apr 01, 2011 6:18 pm
W dniu 01.04.2011 19:51, Grzegorz Niemirowski pisze:
Quote:
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,
Dlatego wynaleziono 1.5 bita stopu - w ten sposób można jednoznacznie
wykryć koniec bajtu. I zacząć prawidłowo dekodować kolejny.
--
Pozdrawiam
Michoo
Mirek
Guest
Fri Apr 01, 2011 6:19 pm
On 01.04.2011 19:51, Grzegorz Niemirowski wrote:
Quote:
Zastanawiam się nad przypadkiem, gdy urządzenie nadawcze wysyła ciągle
jakie dane po RS-232.
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.
Waldemar Krzok
Guest
Fri Apr 01, 2011 6:47 pm
Mirek wrote:
Quote:
On 01.04.2011 19:51, Grzegorz Niemirowski wrote:
Zastanawiam się nad przypadkiem, gdy urządzenie nadawcze wysyła ciągle
jakie dane po RS-232.
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.
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ý.
JDX
Guest
Sat Apr 02, 2011 2:24 am
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ć".
J.F.
Guest
Sat Apr 02, 2011 4:11 am
On Fri, 01 Apr 2011 20:18:57 +0200, Michoo wrote:
Quote:
W dniu 01.04.2011 19:51, Grzegorz Niemirowski pisze:
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,
Dlatego wynaleziono 1.5 bita stopu - w ten sposób można jednoznacznie
wykryć koniec bajtu. I zacząć prawidłowo dekodować kolejny.
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.
Zbych
Guest
Sat Apr 02, 2011 6:03 am
W dniu 2011-04-01 20:47, Waldemar Krzok pisze:
Quote:
Mirek wrote:
On 01.04.2011 19:51, Grzegorz Niemirowski wrote:
Zastanawiam się nad przypadkiem, gdy urządzenie nadawcze wysyła ciągle
jakie dane po RS-232.
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.
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.
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.
RoMan Mandziejewicz
Guest
Sat Apr 02, 2011 6:14 am
Hello Zbych,
Saturday, April 2, 2011, 8:03:32 AM, you wrote:
[...]
Quote:
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.
--
Best regards,
RoMan mailto:roman@pik-net.pl
Nowa strona:
http://www.elektronika.squadack.com (w budowie!)
Zbych
Guest
Sat Apr 02, 2011 6:43 am
W dniu 2011-04-02 08:14, RoMan Mandziejewicz pisze:
Quote:
Hello Zbych,
Saturday, April 2, 2011, 8:03:32 AM, you wrote:
[...]
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,
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.
Quote:
- w transmisji synchronicznej używa się znaków SYNC nadawanych w
czasie, gdy nie ma nic innego do nadania.
Ale mowa jest o asynchronicznej.
RoMan Mandziejewicz
Guest
Sat Apr 02, 2011 7:08 am
Hello Zbych,
Saturday, April 2, 2011, 8:43:20 AM, you wrote:
Quote:
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,
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.
Zdaje się na bardzo wiele - czas trwania ułatwia odróżnienie stopu od
innej kombinacji.
Quote:
- w transmisji synchronicznej używa się znaków SYNC nadawanych w
czasie, gdy nie ma nic innego do nadania.
Ale mowa jest o asynchronicznej.
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
Nowa strona:
http://www.elektronika.squadack.com (w budowie!)
Zbych
Guest
Sat Apr 02, 2011 8:10 am
W dniu 2011-04-02 09:08, RoMan Mandziejewicz pisze:
Quote:
Hello Zbych,
Saturday, April 2, 2011, 8:43:20 AM, you wrote:
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,
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.
Zdaje się na bardzo wiele - czas trwania ułatwia odróżnienie stopu od
innej kombinacji.
To pokaż mi uart, który to robi.
Quote:
- w transmisji synchronicznej używa się znaków SYNC nadawanych w
czasie, gdy nie ma nic innego do nadania.
Ale mowa jest o asynchronicznej.
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.
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.
Mirek
Guest
Sat Apr 02, 2011 10:33 am
On 02.04.2011 04:24, JDX wrote:
Quote:
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.
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.
Mirek
Guest
Sat Apr 02, 2011 10:50 am
On 02.04.2011 06:11, J.F. wrote:
Quote:
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. 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.
Tomasz Wójtowicz
Guest
Sat Apr 02, 2011 1:43 pm
W dniu 2011-04-01 20:19, Mirek pisze:
Quote:
On 01.04.2011 19:51, Grzegorz Niemirowski wrote:
Zastanawiam się nad przypadkiem, gdy urządzenie nadawcze wysyła ciągle
jakie dane po RS-232.
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.
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.
J.F.
Guest
Sat Apr 02, 2011 2:16 pm
On Sat, 02 Apr 2011 12:50:12 +0200, Mirek wrote:
Quote:
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.
Quote:
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.
Quote:
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,
Quote:
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.
Quote:
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.
Goto page 1, 2 Next