--
G
--
Pozdrawiam
MD
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ł
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
popróbuj na przejściówce bazującej na CP2102,
ma dość dobrą kompatybilność,
choć pod DOSem raczej będą problemy...
--
pozdrawiam
K.
Jakiego terminala?
> 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 ;/
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.
--
Pozdrawiam
MD
>możliwość że przez taką przejściówkę będą problemy z komunikacją z jakimś
>urządzeniem??
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
--
Tutaj sygnatura Grzegorza Domagały - jeśli chcesz wysłać do niego wiadomość
pisz pod adres grzegorz...@chello.at i nie zapomnij dodać
"kielbaska dla cerbera" w treści albo Cerber zeżre twój list...
Strona domowa: http://members.chello.at/grzegorz.domagata/
> 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.
Errata:
Problemy były z Piccogal konkretnie z obsługującym go programem piccogal
v1.27
--
Pozdrawiam
MD
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.
> To tyle, mam nadzieję, że te informacje przydadzą się używającym RS232
> bezpośrednio i przez przejściówki USB-RS232.
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).
--
Adam Dybkowski
http://www.amwaw.edu.pl/~adybkows/
Uwaga: przed wysłaniem do mnie maila usuń "123" z adresu.
oraz: programy DOSowe (i pisanie bezpośrednio po rejestrach) mają szanse
działać przez USB-RS232
> 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,
To chyba wynika pośrednio ze specyfikacji USB.
P.G.
>> 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,
>
> To chyba wynika pośrednio ze specyfikacji USB.
> P.G.
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).
--
Slawomir Sidor N 51 58.1385 E020 09.1966
>> 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.
>>
> Jeszcze fajniej przenieść taki protokół na przejściówkę Ethernet-RS232
> na drugim końcu świata.
Heh. Teraz wymyślając nowe protokoły już wiem, że należy ramkować
większe bloki danych i najlepiej CRC na końcu. :)