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

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

do góry

On 02.04.2011 04:24, JDX wrote:
> 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.

do góry

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

do góry

W dniu 2011-04-01 20:19, Mirek pisze:
> 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.

do góry

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.

do góry

Użytkownik "Tomasz Wójtowicz" <S...@S...COM> napisał w
wiadomości news:in795h$a0p$1@news.onet.pl...

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

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

do góry

Dziękuję wszystkim za odpowiedzi.

--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 38 days, 4 hours, 37 minutes and 17 seconds

do góry