Komunikacja po rs232

Krzysiek S napisał:

Do kontroli przepływu (z urządzenia) potrzebna Ci tylko linia

pc urządzenie CTS <---- RTS

Wystawisz na RTS 0 -- komp może wysyłać, na RTS 1 -- komp nie może wysyłać.

Licz się z tym, że po wystawieniu 1 na RTS, komp będzie jeszcze wysyłał przez jakiś czas. Gdzieś kiedyś widziałem, jak ktoś robił takie testy... wyszło, że transmisja trwała jeszcze przez ok. 18 ms.

Pozdrawiam, voice

Wydawało mi się że linie sterujące ( w odróżnieniu od lini danych ) opisane sa za pomoca logiki dodatniej więc myślałem że gdt RTS=1 komp może wysyłać a gdy RTS=0 jest zablokowany. Pozdrawiam i dziękuje za odpowiedz Krzysiek

A jaka byla predkosc ? Software o zmianie RTS powinien dowiedziec sie szybko i szybko zareagowac .. ale w dzisiejszym pececie FIFO ma 16 bajtow, co na 19600 faktycznie moze ~18ms potrwac

J.

J.F napisał:

Znalazłem... to był projekt BTnode (więcej info w sieci).

Kawałek avr128_uart1.c:

#v+ // experiments w/ linux and minicom @ 57.6 showed that after RTS, the // PC uart still sends for another ~18 ms, that is 112 bytes #v-

Pozdrawiam, voice

No to troszke duzo. Ciekawe co to .. jakis lepszy pecet, windows pokazuje co potrafi, czy kiepskie oprogramowanie transmisji ..

J.

Tylko ¿e to bez sensu .... Po wstrzymaniu RTS UART powinien nie nadaæ ju¿ tego co ma w FIFO i wypu¶ciæ to dopiero po wznowieniu RTS. Gdyby by³o odwrotnie, maksuymalna wielko¶c bufora (a co za tym idzie porcji która mo¿e jeszcze nadejsc) musia³a by byæ zestandaryzowana a tak nie jest.

Prędkośc transmisji nie będzie duża - 9600 lub co bardziej prawdopodobne

o ile mnie panmiec niemyli ( w zaleznosci o sposobie sterowania przeplywem) RTS wystawia sie gdy bufor odbiornika zapelniony jest w 2/3. Wiec dopuszcza sie jeszcze ze jeszcze niwielka porcja moze poleciec.

Zalezy jaki duzy jest ten bufor odbiornika. Jesli to nie jest PC a jakis mikrokontroler z malym buforem to moze byc problem.

Krzysiek Rudnik

Sun, 03 Oct 2004 23:51:24 +0200, na pl.misc.elektronika, Krzysiek S napisał(a):

To moize zrób zupełnie inaczej - transmisja na żądanie czyli np. zmiana stanu RTS jest dla PC poleceniem wysłania określonej ramki, którą na pewno odbiornik pomieści.

Ale jesli nadajnik ma bufor X to bufor odbiornika i tak musi byc > 3*X bajtów. z ciekawosci chyba wypróbuje, czy w pececie faktycznie tak jest, ze RTS nie wstrymuje wyslania bajtów z bufora ....

Raczej X+N. N wynikle z czasu reakcji.

UART 8250 na bank nie wstrzymuje. Reszta to sprawa softu .. i byc moze jakis nowych opcji uarta, ktory juz dawno jest w innych kosciach.

J.

On Behalf Of william

Zalezy od programu wysylajacego dane z peceta. Pecet zawsze wysyla dane do opróznienia bufora nadawczego. Jesli program ignoruje RTS, to ...

pzdr Artur

Uzytkownik "ziel" snipped-for-privacy@poczta.onet.pl> napisal w wiadomosci news: snipped-for-privacy@poczta.onet.pl...

I od tego kiedy sie dowie, ze jest zmiana na RTS. Ktos kiedys mi klarowal, ze jak sie wlozy dyskietke, to wszystkie inne programy sa zamrozone na 3s.

Wydaje mi sie, ze przerwania z RTS nie trafiaja prosto do tego kto ich potrzebuje, tylko jakis driver zamienia je na Windows Messages i do normalnej kolejki zadan (ale sie nie znam).

P.G.

Ten kto¶ chyba mia³ windows 3.11 :)

To ju¿ ca³kiem mo¿liwe. Ale z drugiej strony po to w windowskie jest ustawienie wielko¶ci bufora FIFO dla uartu, by producent urz±dzenia móg³ napisaæ - mam w odbiorniku bufor 8 znaków, ustaw fifo na 4 znaki ....

Nie pomoze jesli programowa obsluge przerwania spozni :-) Chyba ze na zasadzie - masz 8 znakow, ustaw 2, moze nie wysle wiecej niz 4 :-)

J.

Ustawiłem bufor na 120 bajtówm a wysyła blokuje Rts po 100 więc może da rade :) Jak nie to AVR pozwoli mi jeszcze dwukrotnie zwiększyć bufor :) Pora na testy dopiero nadejdzie :|

On Behalf Of Krzysiek S

Za mało! daj bufor nadawczy na 40 bajtów, a w procku bufor odbiorczy na 120 bajtów. Lekko licząc. To jest windows, więc może spokojnie skierować kilka paczek, zanim załapie, że ma wstrzymać nadawanie.

pzdr Artur

U¿ytkownik "Krzysiek S" snipped-for-privacy@interia.pl napisa³ w wiadomo¶ci news:ck1j3n$i5j$ snipped-for-privacy@inews.gazeta.pl...

Stosujemy RS232 na trasie PC-mikrokontroler od 1988 roku. Zawsze u¿ywali¶my tylko linii TXD i RXD. Inne linie ewentualnie do zasilania i innych ciekawych celów jak prze³±czanie pêtli pr±dowych (do 256 prze³±czanych pêtli, do 1km ka¿da, 4800 Baud, a wszystko zasilane z linii DTR portu). Dwie linie (TXD i RXD) to zawsze mniej hardware'u (szczególnie jak siê izoluje). Zawsze protokó³ by³ taki, ¿e ka¿dy wie ile najwiêcej mo¿e za jednym razem dostaæ. Dopóki nie potwierdzi nie dostanie nastêpnej paczki. Jak co¶ ginie to za³atwiaj± to time-outy. W PC/XT by³ problem z odbiorem 57600 bo wstawienie w pêtli odczytu zegara (aby zrobiæ time-out) powodowa³o gubienie bajtów (PC by³ za wolny). Rozwi±za³em to inaczej i zosta³o gdzie¶ w kodzie (DOS-owym). Jak wesz³o XT przesta³o chodziæ. Przez kilka lat by³em pewien, ¿e XT nie daje dostêpu do COM programom DOSowym. Dopiero miesi±c temu odkry³em przyczynê i poprawi³em programy (DOS-owe) do naszych programatorów Piccolo i Picco-GAL. Programy teraz za to nie chodz± na XT (mo¿e te¿ AT).

P.G.