Potrzebujesz laptopa z portem COM , mam dla Ciebie tani sprzet.

NTG, mo¿e portal

Zreszt± mo¿na na rynku znale¼æ port COM na kabelku USB, koszt pewnie oko³o

Pawe³

Paweł Cern napisał(a):

Tyle, że są urządzenia, które z takimi przejściówkami nie podziałają, był nawet niedawno wątek na ten temat.

Pewnie badziewne jest oprogramowanie takich urz±dzeñ. Zamiast odwo³ywaæ siê kulturalnie do API próbuje grzebaæ po rejestrach sprzêtowych. Zreszt± i tak nie dzia³a³oby w Windows 2000 / XP.

Paweł Cern napisał(a):

Z tego, co wiem, to wina nie leży po stronie programu jako takiego lecz wymyślonego przez producenta protokołu komunikacyjnego - po prostu w pewnych warunkach przejściówki(szczególnie te na układach FTDI) nie dadzą na wyjściu tego co być dostał bezpośrednio na normalnym porcie szeregowym. Polecam lekutrę wątku "Notebook i RS232"

Dziêkujê za lekturê, jednak jej przeczytanie coraz bardziej utwierdza mnie w przekonaniu, ¿e problemy bior± siê z dziwnych "pomys³ów" (odbiegaj±cych od standardu) konstruktorów urz±dzeñ. Polecam uwadze kawa³ek o bitach startu/stopu. Zbadanie zachowania nietypowego rozwi±zania na jednym typie portu szeregowego nie oznacza ¿e sprzêt automatycznie bêdzie dzia³a³ poprawnie na wszystkich. A co do szybko¶ci transmisji, to zapewne oprogramowanie wysy³a bajt po bajcie, przy czym przed wpisaniem nastêpnego bajtu czeka na wys³anie poprzedniego. Gdyby autor programu poczyta³ dokumentacjê do UART 16550, dowiedzia³by siê ¿e jest tam co¶ takiego jak FIFO i mo¿naby wrzucaæ kolejne bajty do tej kolejki (je¶li nie jest pe³na) i ew. czekaæ na jej opró¿nienie kiedy naprawdê zajdzie taka potrzeba. Podejrzewam ¿e sterownk USB->RS232 mia³by tu szansê zoptymalizowaæ transmisjê i pakowaæ wiêcej ni¿ 1 bajt w jedn± ramkê.

Pawe³

U¿ytkownik "Pawe³ Cern" snipped-for-privacy@surname.pl napisa³ w wiadomo¶ci news:5c1fd$441cffd2$3eb34112$ snipped-for-privacy@news.chello.pl...

Je¶li rozwi±zanie, które jest chyba we wszystkich portach sprzêtowych RS232 wszystkich komputerów PC jest 'nietypowym rozwi±zaniem', to samochód na 4 ko³ach jest jeszcze bardziej 'nietypowym rozwi±zaniem'.

Poza tym, nie¶mia³o zauwa¿ê, ¿e obs³ugê RS232, o której by³a tam mowa, pisa³em w 1988r. Musieli¶my nadawaæ 8N2, bo 8748, który odbiera³ to programowo siê nie wyrabia³ z obróbk± odebranego bajtu w jednym bicie stopu. Dlaczego nie 8751 (z UARTem)? Bo 8751 kosztowa³ $20 - wtedy dwie ¶rednie pensje, a 8748 tylko $5, co decyduj±co wp³ywa³o na cenê urz±dzenia, którego

Co to ma do szybko¶ci ?

Nie na wys³anie, tylko na przeniesienie do rejestru szeregowego.

By³a wtedy 'trudno dostêpna'.

Program wymagaj±cy FIFO by³by równoznaczny z nieuzasadnionym zmuszeniem klientów do zmiany PC. Tak mo¿e dzia³a inna firma na Micro...., ale nie MicroMade. Wiêc nawet jakbym rozpoznawa³, ¿e jest FIFO to i tak procedury bajtowe by musia³y byæ. To po co komplikowaæ, skoro bajtowo dzia³a bez zarzutu ? FIFO jest w wielu UARTach, ale nie w IBM/XT (musi jaki¶ inny UART), a jeszcze w okolicy 2000 roku jak przekompilowa³em na 286 to mia³em kilka maili (serwisy RTV), ¿e nie chce chodziæ na XT.

Mo¿e z t± szybko¶ci± to chodzi³o o FIFO ? FIFO nic nie przyspieszy jak program siê wyrabia z wpisaniem kolejnego bajtu w czasie nadawania poprzedniego. A nawet poczciwy XT wyrabia³ siê w tych

Dla sterownika (jak obs³uguje DOS-owe dzia³anie po rejestrach) jest bez znaczenia, czy FIFO jest 1 bajtowe, czy wiêksze. Czytaj uwa¿niej. W tamtym i w tym w±tku by³o ju¿ powiedziane, ¿e to chodzi o protokó³. Jak program wysy³a 1 bajt i czeka na odpowied¼, to sterownik nic nie mo¿e zoptymalizowaæ. P.G.

Nie port szeregowy jest nietypowy, ale rozwi±zanie problemu komunikacji. Wysy³anie danych w formacie 8N1 do portu skonfigurowanego 8N2 nieco wykracza poza standard. Odbiornik móg³by rozpoznaæ bit stopu jako 0 i zg³osiæ jaki¶ b³±d (mo¿e ramkowania, nie pamiêtam).

OK, w tamtych czasach by³o to uzasadnione. Jednak przygl±daj±c siê wspó³czesnym komputerom warto by³oby o tym pomy¶leæ. Kiedy¶ byæmo¿e czêstotliwo¶æ zg³aszania przerwañ przez kontroler RS232 nie mia³a specjalnego znaczenia, jednak obecnie ma. W procesorach s± pamiêci cache, przerwanie wymaga zapewne dokonania inwalidacji jakiego¶ obszaru cache i za³adowanie w to miejsce kodu obs³ugi przerwania. Mam wra¿enie ¿e mo¿e to byæ czasoch³onne. Mo¿e warto by³oby dodaæ w programie choæby opcjê pozwalaj±c± na u¿ycie mechanizmu FIFO?

Gdyby to by³ protokó³, to programy windowsowe te¿ paskudnie wolno dzia³a³yby z przej¶ciówkami USB<->RS232. Swoj± przej¶ciówkê (zreszt± na uk³adzie FTDI) pod³±cza³em do modemu analogowego i jako¶ problemów szybko¶ci nie zauwa¿y³em.

Pawe³

Paweł Cern napisał(a):

To jeszcze pomyśl, że powyżej tego modemu i przejściówki USB->RS232 istnieją jeszcze jakieś aplikacje i protokoły. Otworzyłeś terminal, wpisałeś AT, pojawiła się odpowiedź OK. I o czym to świadczy? Na oko nie zauważysz, czy odpowiedź przyszła po 100 ns czy po 10 ms. Przesłałeś plik na drugą stronę ZModemem? Protokół ZModem jest tak skonstruowany, że wysyła w ramkach duży kawał danych nie czekając na odpowiedź (timeout jest rzędu 1 minuty) tak że tu przejściówka USB->RS232 nie wprowadziła zamieszania. Jeżeli na tym modemie potem ustawiłeś dial-up'a to śmigał pewnie m.in. protokół TCP/IP, który wysyła duże paczki w ciemno, podobnie jak ZModem. I tak dalej. Obecnie już chyba bardzo mało jest protokołów skonstruowanych na zasadzie "bajt wysyłam, potwierdzenie odbieram". Nawet bardzo prosty XModem wysyła paczkę danych (nagłówek,

Faktycznie, je¶li oczekujemy odpowiedzi po ka¿dym bajcie (lub nawet kilku), ciê¿ko bêdzie to zoptymalizowaæ. Ciekawe czemu konstruktor nie zaplanowa³ umieszczenia w pamiêci ma³ego bufora 32 czy 64 bajtowego. Gdyby odpowiedzi nie by³y przesy³ane po ka¿dym bajcie, z pewno¶ci± programator dzia³a³by szybciej, nawet na starszych komputerach. Naturalnie nie zawsze czytamy/programujemy 32/64 bajty, ale napewno w wiêkszo¶ci przypadków.

U¿ytkownik "Pawe³ Cern" snipped-for-privacy@surname.pl napisa³ w wiadomo¶ci news:89471$441ee247$3eb34112$ snipped-for-privacy@news.chello.pl...

Czytaj uwa¿nie - nie pisa³em o obecno¶ci portu, tylko o rozwi±zaniu, o którym by³a mowa. Czyli w³a¶nie o tym, ¿e tak zrobiona komunikacja (8N2->, 8N1<-) dzia³a. Jest co najmniej 2000 u¿ytkowników, ka¿dy prawdopodobnie w ci±gu lat kilka razy zmieni³ komputer. Jak co¶ by by³o nie tak od razu mia³bym seriê maili.

Mo¿e zg³asza, mo¿e nie sprawdzam - jedyn± dokumentacj± obs³ugi RS232 jak± mia³em by³ opis z jakiego¶ czasopisma.

Nie u¿ywa³em przerwañ - by³ chyba jaki¶ problem gdy 4 porty by³y na 2 przerwaniach (taki by³ hardware PC-tów). Programy komunikuj±ce siê przez Windows API te¿ mia³y problem, gdy pu¶ci³o siê jeden dzia³aj±cy z COM1, a drugi z COM3. Na niektórych kombinacjach sprzêt+wersja Windows prowadzi³o to nawet do definitywnego zawieszenia siê systemu. Wed³ug mnie taki program DOS puszczony pod Windows nie zale¿y od przerwañ z portu, a jedynie od przydzielanego mu czasu maszynowego. Poniewa¿ nie przegapia bajtów wiêc s±dzê, ¿e Windows za³atwia dla niego FIFO.

Programy te nie s± rozwijane, bo Unia spowodowa³a wycofanie tych urz±dzeñ z produkcji (przestarza³e konstrukcje, ma³a sprzeda¿ - przeprojektowanie aby spe³niæ normy na CE i badania na CE by³yby nieop³acalne).

My¶lê, ¿e protokó³ komunikacji z modemem przewiduje wystarczaj±co du¿e paczki danych, wiêc nie ma powodu, aby dzia³a³ wolno. W tych moich programach, (paczki s± 16 bajtowe) te¿ nie zauwa¿am spowolnienia przez przej¶ciówkê. P.G.

U¿ytkownik "Pawe³ Cern" snipped-for-privacy@surname.pl napisa³ w wiadomo¶ci news:e778f$441f9fb4$3eb34112$ snipped-for-privacy@news.chello.pl...

Je¶li chcesz s³u¿ê pe³nym opisem protoko³u komunikacji picco-GALa. (Mogê daæ ka¿demu).

- stos procesora

- procedura programowania GALa, czy EEPROMu

- dwa stosy danych dla procedury.

Praktycznie wszystkie nogi 8751 s± wykorzystane do sterowania PINów programatora - nie tylko dwukierunkowo, dla wektorów testowych GALi jest te¿ potrzebne sprawdzanie czy pin jest 0, 1 czy hiZ. Jakby¶my do 8751 do³o¿yli zewnêtrzny RAM to zabra³o by to nam ponad 16 nóg (dwukierunkowych !), wiêc trzeba by do³o¿yæ co¶ zamiast. Programator zamiast

Procedury s± pisane w jêzyku FORTHo - podobnym (opis zawiera wszystko na ten temat). W³a¶nie fakt, ¿e procedur obs³ugi poszczególnych elementów nie umie¶cili¶my w programie tylko w RAMie pozwoli³ na to, ¿e urz±dzenie wyprodukowane w 1993 mog³o obs³ugiwaæ ró¿ne EEPROMy, o których istnieniu nie mieli¶my pojêcia (lub jeszcze nie zosta³y wymy¶lone) robi±c programator. Wtedy to by³a nasza tajemnica, bo konkurencja wymaga³a przesy³ania do nich programatora w celu upgrade oprogramowania, aby móc robiæ nowe elementy. P.G.