Notebook i RS232

Mar 08, 2006 17 Replies

Wiatam! Jak radzicie sobie z programowaniem przeróżnego sprzętu (np centrale telefoniczne) po RS232? Bo laptop z RSem jest chole(nda)rnie drogi. Mowa o nowych laptopach. Używacie przejściówek USB lub RS232 na PCMCIA? Jest możliwość że przez taką przejściówkę będą problemy z komunikacją z jakimś urządzeniem?? Pozdrawiam


Z USB bywa różnie. Programy DOSowe mogą mieć problemy ale nie muszą. Zależy jak napisane. Najlepiej wypróbuj program na konkretnym konwerterze.

U¿ytkownik snipped-for-privacy@gazeta.pl napisa³ w wiadomo¶ci news:op.s53qvkyekkqzv3@a0913614fd6946d...

Niestety sa duze problemy z konwerterami na USB, za PCMCIA nie mam doswiadczen. Przynajmniej te najbardziej popularne usb->rs232 robia jeden za to cholernie uciazliwy numer -> przelaczaja tryb dzialania terminala (autodetekcja). W sterownikach nie ma opcji wylaczenia tej funkcjonalnosci. Wszystko jest ok dopoki piszemy sam tekst. Jezeli RSem chcemy przeslac dane binarne (np nowy plik firmware etc), w ktorych znajduja sie byc moze bajty o wartosciach kodow sterujacych dla terminali - konwerter zaczyna szalec. Konwertuje np ciag 0x31,0x32,0x10,0x31 (czyli '1','2',<CR>,'1') na

0x31,0x32,0x10,0x13,0x31 ('1','2',<CR>,,<LF>,'1').. Bagatela - dodatkowy bajt ktory zostal dolozony 'gratis' do transmisji. Normalnie port RS ma takie opcjonalne flagi, defualtowo chyba wylaczone, w kazdym badz razie zawsze jest mozliwosc ich ustawienia,.. w usb polegasz juz tylko na sterownikach dolaczonych do konwertera.

Jezeli ktos ma podobne doswiadczenia w tej kwestii to chetnie przeczytam.. Wydaje sie ze jedynym rozwiazaniem jest napisanie wlasnego sterownika ktorego wybranego konwertera, wtedy bedziemy na 100% ze nie zdarzy sie przykra niespodzianka ;/

pozdrawiam

Przemyslaw Augustyn

RS232 na PCMCIA funkcjonalnie jest w 100% zgodny z portem wbudowanym do ¶rodka komputera. W przypadku USB tak ju¿ nie jest.

Pawe³

U¿ytkownik "Pawe³" snipped-for-privacy@neostrada.pl napisa³ w wiadomo¶ci news:dun3du$l2h$ snipped-for-privacy@nemesis.news.tpi.pl...

Ake trzeba tez uwa¿aæ. Mam 2 PCMCIA z RS232, jedna 16 bitiwa 2xRS232 i jedna 1xRS232 ale 32 bitow±. W pierwszej dzia³a tylko jeden port, bo XP ma problemy (nowsza wersja tej karty podobno nie robi problemów) a druga... có¿, znów XP jest m±drzejsze ode mnie i nie potrafi sobie przypisaæ zasobów. Przy pierwszym uruchomieniu jakim¶ cudem zadzia³a³a, a teraz ju¿ notorycznie kod b³êdu 12... Niestety nie mam opcji w biosie do zmiany przerwañ i bez reinstalacji systemu siê nie obêdzie.

Polecam wiêc 16 bitówkê jednoportow±, przynajmniej jest du¿e prawdopodobieñstwo, ¿e zadzia³a bez problemów.

pozdro Dino

jeśli chodzi o usunięcie to zrobiłem to w najprostszy sposób, kupiłem kabelek do komórki a następnie przerobiłem go na typowego rs-a, sterownik mam oryginalny od kabelka i chodzi wszystko super nawet do

921k co jest Very dziwne jak na Taiwan za 20PLN

Andrzej

U¿ytkownik snipped-for-privacy@gazeta.pl napisa³ :

popróbuj na przej¶ciówce bazuj±cej na CP2102, ma do¶æ dobr± kompatybilno¶æ, choæ pod DOSem raczej bêd± problemy...

Jakiego terminala?

Nie spotkałem się z takimi problemami. FTDI i Prolific działają poprawnie z Modbus RTU. Prolifica używam też do połaczenia z programatorami MicroMade - Piccolo i Piccogal. Z Piccolo był problem, który wymagał poprawki autora w kodzie piccolo.exe. Piotr Gałka planował opisać ten przypadek na grupie ale widocznie nie miał jeszcze na to czasu. Przy okazji publicznie dziękuję mu za szybką reakcję w sprawie dość starego produktu.

Natomiast pod linuksem z jądrem poniżej 2.6 były chyba skopane sterowniki do FTDI. W sumie to loteria - zależy od aplikacji - zwłaszcza w przypadku dosowych i zapewne od sterowników.

" snipped-for-privacy@gazeta.pl" napisal:

Raz mi sie zdazylo ze program wywalal sie ze wzgledu na zbyt dlugi czas oczekiwania na odpowiedz urzadzenia - usb przesyla dane w paczkach, w regularanych odstepach (z tego co pamietam USB1 co 5ms, USB2 co 1ms albo 500us). I nawet jesli srednia predkosc transmisji jest duza czas odpowiedzi nie moze byc krotszy od tego okresu. Konwerter byl przypiety przez USB1 a program "tracil cierpliwosc" po jednej ms :)

usb1. GRG

Errata: Problemy były z Piccogal konkretnie z obsługującym go programem piccogal v1.27

Czujê siê wywo³any do odpowiedzi. Chcia³em najpierw doprowadziæ do tego, aby poprawione wersje by³y na naszej stronie, a potem opisaæ problem. Poprawki s± proste, ale trochê czasu wymagaj± zawsze do³±czone do programu pliki (opis kolejnej wersji programu). Programy s± 3 wiêc ³adnych kilka godzin zawsze mi na to zejdzie. Niestety, na razie brak³o czasu - s± pewne rzeczy (wymagane przez dyrektywy), które powinienem ju¿ z miesi±c temu zrobiæ, a jeszcze jestem w polu i w lesie.

No to opiszê problem, bo wydaje mi siê, ¿e mo¿e byæ to ciekawa informacja.

Gdyby Mariusz Dybiec zg³osi³ mi, ¿e piccogal nie dzia³a przez przej¶ciówkê USB-RS232 odpowiedzia³bym, ¿e on obs³uguje RS232 pisz±c bezpo¶rednio po adresach rejestrów (typowe rozwi±zanie w DOS) i ma prawo przez przej¶ciówkê nie dzia³aæ. Ale jednocze¶nie otrzyma³em informacjê, ¿e piccolo dzia³a, a ten (jeszcze starszy) program obs³uguje RS232 tak samo.

Dotar³em wiêc do takiej samej przej¶ciówki (driver Prolific) i okaza³o siê, ¿e u mnie jest tak samo - to ju¿ po³owa sukcesu. Zauwa¿y³em, ¿e na zwyk³ym COM na pierwsze pytanie komputera odpowied¼ picco-GALa jest: ACK P, a przez przej¶ciówkê ACK ø (tak to dociera do mojego programu na PC). Ustali³em prawdopodobny kod znaczka ø - nigdy nie jestem pewien jak co¶ jest w oknie DOSo podobnym pod Windows czy nie jest 10x przekodowane.

P=0x50=01010000 ø=0xFD=11111101

Uzupe³nione o bit startu i bity stopu (du¿o bitów stopu, bo to jest koniec transmisji) i od najm³odszego - tak jak jest nadawane przez RS232 wychodzi:

ACK P = ACK 000001010111111111 ACK ø = ACK 010111111111111111

Od razu widaæ, ¿e odbiornik w przej¶ciówce USB-RS232 nie za³apa³ siê na bit startu od P i za bit startu uzna³ dopiero pierwsze 0 po najbli¿szej jedynce. Takie co¶ sugeruje, ¿e nadajnik nadaje 8N1 a odbiornik uparcie oczekuje 8N2. Sprawdzi³em - faktycznie w programie piccogal mia³em ustawione 8N2. Przestawienie na 8N1 rozwi±za³o problem.

Normalne scalaki w PC (sprawdzali¶my kiedy¶ dawno) ustawione na 8N2 nadaj±

8N2, a odbieraj± zarówno 8N1 i 8N2. Faktycznie zg³aszaj±, ¿e przyszed³ bajt gdzie¶ tak w 3/4 pierwszego bitu stopu (zarówno w trybie 8N1 jak i 8N2). Uznali¶my, ¿e w zwi±zku z tym najbezpieczniejsze jest ustawienie 8N2 - daje wiêksz± gwarancjê synchronizacji. Picco-GAL te¿ mia³ w zamy¶le nadawaæ 8N2, a odbieraæ 8N1. Dlaczego nadaje 8N1 to nie wiem (nie pamiêtam) - mo¿e okaza³o siê, ¿e jego UART jak nadaje 8N2 to te¿ odbiera tylko 8N2 wiêc wysz³o na to, ¿e jest wszystko jedno, a 8N1 jednak dzia³a szybciej.

Widaæ, ¿e w tej przej¶ciówce USB-RS232 kto¶ postanowi³ byæ lepszy od typowych scalaków w PC - jak 8N2 to odbieraj±c wymaga ca³ych 2 bitów stopu.

Gdy to ju¿ ustali³em to sprawdzi³em jeszcze jak to jest w programie piccolo, który dzia³a - okaza³o siê, ¿e tam jest te¿ 8N2. Skoro dzia³a to znaczy, ¿e piccolo nadaje 8N2. Programator piccolo (8748 z kwarcem 6MHz) nie ma UARTA - nadaje i odbiera programowo z prêdko¶ci± 57600 (niez³y wyczyn). Jakby nawet chcia³ to nie nada 8N1 bo siê nie wyrobi z przygotowaniem nastêpnego bajtu do nadawania.

To tyle, mam nadziejê, ¿e te informacje przydadz± siê u¿ywaj±cym RS232 bezpo¶rednio i przez przej¶ciówki USB-RS232. P.G.

Piotr Gałka napisał(a):

Czyli podsumowując: jeżeli urządzenie nadaje UARTem ustawionym na 8N1 to nie należy zakładać, że ustawienie w porcie pecetowym 8N2 też będzie poprawnie działać (bo właściwie nawet nie powinno).

Ja w swoim urządzeniu przeszedłem kiedyś ze zwykłego UARTu na FT232BM i się bardzo zdziwiłem, gdy transmisja zwolniła gdzieś tak dziesięciokrotnie. Protokół był bardzo prosty: nadajemy bajt danych, odbieramy ACK (lub timeout). Po zwykłym COMie wszystko śmigało, a przez ten konwerter RS232-USB odstępy między kolejnymi transferowanymi bajtami wynosiły co najmniej 1ms, co dawało faktycznego transferu tylko 0,5 KB/s w jedną stronę. Pomogła dopiero rewolucja z protokołem i przesyłanie większych paczek danych (przy okazji doszło CRC).

U¿ytkownik "Adam Dybkowski" snipped-for-privacy@amwaw.edu.pl> napisa³ w wiadomo¶ci news:duq66n$7$ snipped-for-privacy@atlantis.news.tpi.pl...

oraz: programy DOSowe (i pisanie bezpo¶rednio po rejestrach) maj± szanse dzia³aæ przez USB-RS232

To chyba wynika po¶rednio ze specyfikacji USB. P.G.

Piotr Gałka napisał(a):

Jasne. Tylko kto to brał pod uwagę wymyślając kilka lat temu prosty protokół śmigający po RS232. A potem trzeba to było przenieść na USB (FT232BM) i klops.

Zależy jakiej firmy. Za niecałe 3k zł nowy model to chyba nie jest tak źle? A jak się chce mieć HP to trzeba płacić za wszystko.

Niefirmowe prawie wszystkie mają (Acery itp).

U¿ytkownik "Adam Dybkowski" snipped-for-privacy@amwaw.edu.pl> napisa³ w wiadomo¶ci news:duvhjq$kpo$ snipped-for-privacy@atlantis.news.tpi.pl...

Jeszcze fajniej przenie¶æ taki protokó³ na przej¶ciówkê Ethernet-RS232 na drugim koñcu ¶wiata. P.G.

Piotr Gałka napisał(a):

Heh. Teraz wymyślając nowe protokoły już wiem, że należy ramkować większe bloki danych i najlepiej CRC na końcu. :)

U¿ytkownik "Adam Dybkowski" snipped-for-privacy@amwaw.edu.pl> napisa³ w wiadomo¶ci news:dv4p45$a4m$ snipped-for-privacy@nemesis.news.tpi.pl...

Osta³y siê jeszcze miejsca, gdzie mo¿na po staremu (krótkie ramki). Zrobili¶my kiedy¶ prze³±cznik pêtli pr±dowych (zasilanie z RS232, 10 izolowanych pêtli, 115200 do 100m). Mia³y byæ produkty rynkowe, ale pojawi³ siê USB i wysz³o, ¿e nie ma sensu. Na tym prze³±czniku wieszamy teraz ró¿ne testery produkowanego urz±dzenia i programator AVR-ów w³±czony w to urz±dzenie (³adowanie programu testowego, testowanie i pomiary, ³adowanie programu docelowego). Jak robiê nowy tester to protokó³ mogê sobie u³o¿yæ bez grupowania wielu poleceñ w d³uga¶ne ramki. P.G.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required