Port LPT na karcie PCI i pytanie o

Ze starych czasow to ci powiem ze np karty ethernet "ne2000 compatible" na pci dawalo sie obsluzyc driverem z czasow ISA. O ile oczywiscie driver dal sobie wpisac odpowiednie adresy - niektore wiedzialy "lepiej" - sam podmienialem 0320 w pliku na EE00 i wybieralem trzecia onfiguracje z listy ..

Oczywiscie badz swiadom ze ten adres potrafi sie zmienic przy najmniejszej okazji. No i ze przydzielone przerwanie moze byc dzielone.

Przez ostatnie 5 lat raczej nic. Moze port juz spalony ? A moze windows jakies nowe i olewa ustawienia w biosie, ustawilo np port jednokierunkowy ?

A ten inpout32 to juz dostosowany do NT/XP ? Bo moze w tym problem ?

J.

Licze na to, że się da, teraz szybko doszywam do aplikacji możliwśc pobierania numerka prosto z pliku konfiguracyjnego ... niestety nie wiem, czy inpout32.dll pozwoli na podanie taiego adresu. Znasz moze alternatywę ? Coś co pozwala mi grzebać po portach LPT.

Bo ja wiem ... praktycznie wszędzie działa, a na tym jedeynm, na którym musi działać - nie chce. Port na sztywno pisze w win że dwukierunkowy - drukarka działa na nim.

Sprawdzany nawielu róznych windowsach, działa bez pudła.

Sebastian Bialy wrote: > Osoba która musi to urządzenie podąłczyć kupiła w końcu port drukarki > (dwukierunkowy) na złączu PCI. Niestety port ten po uruchomieniu > przydzielił sobie zasoby następujące (po niemiecku): > E/A - Bereich CC00 - CC07 > E/A - Bereich C800 - C807 > (i nazywa sie LPT1)

Zaryzykowałem i posłałem program, który zamiast po porcie 378 grzebie po porcie c800. Okazało się, że działa :) To tak dla wszystkich, którzy będą kiedyś googlować. Korzystam z biblioteki inpout32.dll która co prawda w dokumentacji stwierdza, że obsługuje wyłącznie 378/278 ale jak widać dziaął znakomicie na innych zakresach we/wy.

Tylko pamietaj ze w PCI adresy sa przydzielane dynamicznie a wrecz teoretycznie urzadzenia IO moga zostac zmapowane do pamieci.

Krzysiek Rudnik

Nie ma znaczenia - zawsze można przestawić adres IO na dowolny inny - dorobiłem proteze odczytującą z pliku ten adtres, więc user może łatwo zmienić. Coś mi się wydaje jednak, że bez zmian w hardware samo z siebie nie powinno się zmienić.

Dlatego w konfiguracji programu lepiej dac do wyboru numer portu LPT, a dopiero w czasie dzialania znajdowac jego adres bazowy. Tak dziala np. ISPProgrammer:

Polecam lekture dokumentacji funkcji Win32 API: SetupDiGetClassDevs, SetupDiEnumDeviceInfo, SetupDiGetDeviceRegistryProperty, CM_Get_First_Log_Conf, CM_Get_Next_Res_Des, CM_Get_Res_Des_Data i jeszcze kilka pomniejszych.

Nie ma czasu na eksperymenty, tym bardziej, że urządzenia nie mam i musze pisać w ciemno. To tylko proteza, żeby w ogóle zadziałało - docelowo wszystko będzie na rs232 może USB (ale też pewno w jakimś trybie strumieniowania jak rs232).

Na RS232 nie polecam żadnej nowej produkcji, bo już niedługo nie będzie tego gdzie podłączyć. Teraz już mało który laptop ma RS232, a widać tą tendencję też w dużych blaszakach. Odnośnie USB i wirtualnego COMa - dobry pomysł o ile nie zachcesz więcej portów (np. jeden kanał do transmisji danych a drugi do debugowania) albo całkiem innej funkcjonalności (fajnie wygląda upgrade firmware'u urządzenia przez wrzucenie pliku na wirtualną "dyskietkę" - klasa USB Mass Storage). Do obu zastosowań i jeszcze 100 innych nadają się za to bardzo dobrze uniwersalne układy USB takie jak np. Philips ISP1181 lub nowsze.

A to wiem, ale założenie jest bardzo proste - coma zawsze można podłaczyć przez USB - koszt około 40zł za "przelotkę" i masz port COM w kazdym laptopie. To że to stary system przesyłania danych - powiedz to producentom elementów do automatyki - tam cały czas RS232 jest podstawowym sposobem komunikacji i tego raczej nie przeskocze. Tak naprawdę to urządzenie które będzie sterowane przez komputer wymaga aż 4 lini RS232 do komunikacji, bo przerobić gotowych urządzeń nie mogę ... No i dodatkowo moja proteza na LPT ... Ale w następnej wersji będzie już tylko jeden RS232 / USB / IrDA / etc.

Zastanawia mnie wykorzystanie raczej gotowego mikrokontrolera z interfejsem USB. Jeśli tylko załatwi wszelkie hardware/synchronizacje/protokół i udostępni mi strumieniowane transmisje to więcej mi nie trzeba.

A w jaki sposob znajdujesz adres portu ?

No i ..

- co w przypadku jak port jest, ale windows go nie znajduje

- windows znajduje .. ale to port na USB ...

J.

Wymieniłem w tamtym poście nazwy kilku funkcji Windows API, z nich korzystam. RTF MSDN jakby co.

Jak nie widać portu w Windows to nawet inny program nic z nim nie zrobi. Nie daję w sofcie takich portów do wyboru.

Wtedy dla danego portu nie da się uzyskać adresu bazowego i nie daję w takim przypadku go do wyboru użytkownikowi. Taki port nie nadaje się do grzebania ręcznie "bitami" i AFAIK nie ma żadnej funkcji Win32 API pozwalającej w porcie LPT zmienić stan jednego bitu. A tego wymaga transmisja SPI.