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

do góry

W dniu 01.04.2011 19:51, Grzegorz Niemirowski pisze:
> 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

do góry

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.

Mirek.

do góry

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.

Waldek

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

do góry

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ć".

do góry

On Fri, 01 Apr 2011 20:18:57 +0200, Michoo wrote:
>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.

do góry

W dniu 2011-04-01 20:47, Waldemar Krzok pisze:
> 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.

do góry

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,
- w transmisji synchronicznej używa się znaków SYNC nadawanych w
czasie, gdy nie ma nic innego do nadania.

--
Best regards,
RoMan mailto:r...@p...pl
Nowa strona: http://www.elektronika.squadack.com (w budowie!)

do góry

W dniu 2011-04-02 08:14, RoMan Mandziejewicz pisze:
> 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.

> - w transmisji synchronicznej używa się znaków SYNC nadawanych w
> czasie, gdy nie ma nic innego do nadania.

Ale mowa jest o asynchronicznej.

do góry

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.

>> - 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:r...@p...pl
Nowa strona: http://www.elektronika.squadack.com (w budowie!)

do góry