eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.misc.elektronikaRS-232 a ciągły strumień danych
Ilość wypowiedzi w tym wątku: 17

  • 11. Data: 2011-04-02 08:10:24
    Temat: Re: RS-232 a ciągły strumień danych
    Od: Zbych <a...@o...pl>

    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.


  • 12. Data: 2011-04-02 10:33:11
    Temat: Re: RS-232 a ciągły strumień danych
    Od: Mirek <i...@z...adres>

    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.


  • 13. Data: 2011-04-02 10:50:12
    Temat: Re: RS-232 a cišgły strumień danych
    Od: Mirek <i...@z...adres>

    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.


  • 14. Data: 2011-04-02 13:43:24
    Temat: Re: RS-232 a ciągły strumień danych
    Od: Tomasz Wójtowicz <S...@S...COM>

    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.


  • 15. Data: 2011-04-02 14:16:04
    Temat: Re: RS-232 a cišgły strumień danych
    Od: J.F. <j...@p...onet.pl>

    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.


  • 16. Data: 2011-04-02 15:54:47
    Temat: Re: RS-232 a ciągły strumień danych
    Od: "Marcin Wasilewski" <j...@a...pl>

    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.


  • 17. Data: 2011-04-03 00:34:51
    Temat: Re: RS-232 a ciągły strumień danych
    Od: "Grzegorz Niemirowski" <g...@p...onet.pl>

    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

strony : 1 . [ 2 ]


Szukaj w grupach

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: