[C++] Obsługa USB

0

Witam,
Mając trochę wiedzy z programowania C++ chciałem poszerzyć swoją wiedzę o C Sharpa, ktory jest bardzo podobny.

Chcialbym też wiedzieć czego szukać i czy ktos probowal/robi/robił podobna rzecz.

Chcialbym napisać program/programy, ktore obsluza dodany poprzez USB sterownik - bo mysle ze tak to musze nazwac (sterownik, ponieważ chcę np. nie wiem...zgasić światło przez program, czy poprzez włączenie programu podać 12V do urządzenia - teraz tak zmyślam na szybko. - to musi być sterownik? Jak w ogóle podejść do tematu...bo wiem, że przez COMa zrobić coś takiego nie jest wcale trudno i nie potrzeba układów specjalnych do tego.)

Jak wygląda obsługa portów USB pod językami programowania i czego mam szukać...

Z góry dzięki za informacje.
Nie śmiejcie się czasami, że amator szuka informacji "Jak napisać program". Chce troche poszerzyc mozliwosci, pokombinowac, poczytac...bo baze z języka Cpp mam dość dobrą, bo umiem pisać obiektowo, zapisywać do pliku, tworzyć bazy na tablicach itp.

0

Też kiedyś szukałem informacji na temat programowej obsługi USB, niestety nie jest to tak proste jak właśnie z COMem.. a co więcej nie znalazłem nic konkretnego dla Windowsa, lepiej było z Linuxem.. ale co do Windows`a to trzeba wziąć głęboki wdech i zajrzeć do obszernego źródła:

http://msdn2.microsoft.com/en-us/library/ms790518.aspx

osobiście się w to nie zagłębiałem, więc jeśli osiągniesz jakieś sukcesy, jak choćby sterowanie stanami napięć to pochwal się ;) życzę powodzenia...

0
Gals napisał(a)

Też kiedyś szukałem informacji na temat programowej obsługi USB, niestety nie jest to tak proste jak właśnie z COMem.. a co więcej nie znalazłem nic konkretnego dla Windowsa, lepiej było z Linuxem.. ale co do Windows`a to trzeba wziąć głęboki wdech i zajrzeć do obszernego źródła:

http://msdn2.microsoft.com/en-us/library/ms790518.aspx

osobiście się w to nie zagłębiałem, więc jeśli osiągniesz jakieś sukcesy, jak choćby sterowanie stanami napięć to pochwal się ;) życzę powodzenia...

Tam już zaglądałem.
No mało informacji jest, a nie wiem jak szukać. Musze kogos na uczelni popytać jak sie semestr zacznie.
Glownie to na poczatek chce regulowac stany ... zwarcie, bez zwarcia...czyli on/off, potem pobawie sie napieciami

0

Jako elektronik po trosze powiem, że USB nie jest takie proste i wiele informacji na ten temat nie ma (chyba że się mylę). Wiem że ludzie próbowali pisać sterowniki do własnych urządzeń na USB ale idzie to topornie, bo informacji jest tak mało, że w ogóle szkoda gadać. Wiem że był jakiś projekt kolesia który był naprawdę dobry i zawzięty żeby napisać jakiś sterownik, ale i on miał problemy z tym interfejsem. Jego praca jest gdzieś w necie, wraz z kodami źródłowymi. Dlatego zazwyczaj kończy się na tym, że budując urządzenia korzysta się ze scalonych przejściówek USB->RS232 które wmontowywali w uklad. Potem system miał dostęp do sprzętu przez wirtualnego com'a.

A tak poza tym to USB jest dość nie przyjemne jak na mój gust, wynika to z jego specyfikacji. Jak czytam i widzę, że jest podział pasma itd to strach się w to bawić. RS232 to najlepsze rozwiązanie jak dla mnie (lub LPT).

PS. osobiście tego nie robiłem i nie znam dokładnie historii, pochodzenia, problemów z tym zwiazanych, więc mogłem coś nie coś pomieszać za co przepraszam. Niech ktos poprawi mnie jeśli się mylę.

PS. stanami na wyjściach USB ręcznie nie da się sterować z tego co wiem, bo USB jest interfejsem zcentralizowanym (czy jak to się zwie), tzn. że obsługuje go jeden sterownik systemowy, a do USB ma się dostęp tylko przez ten sterownik. W przypadku LPT i COM był dostęp do wszystkiego, zaś USB jest ukryte przed człowiekiem. Jak napisałem wynika to chociażby z dzielenia pasma, są tam chyba 3 tryby transmisji i wiele wiele innych bajerów.

0
RR napisał(a)

PS. stanami na wyjściach USB ręcznie nie da się sterować z tego co wiem, bo USB jest interfejsem zcentralizowanym (czy jak to się zwie), tzn. że obsługuje go jeden sterownik systemowy, a do USB ma się dostęp tylko przez ten sterownik. W przypadku LPT i COM był dostęp do wszystkiego, zaś USB jest ukryte przed człowiekiem. Jak napisałem wynika to chociażby z dzielenia pasma, są tam chyba 3 tryby transmisji i wiele wiele innych bajerów.

To nie ma programowalnych sterownikow (sprzetowo) ze kupie sterownik pod usb i z niego sa wyprowadzane wyjscia? Cos musi byc co programuje USB...

A jak to wyglada w przypadku COM/LPT ??? Czego szukac?

0

To nie ma programowalnych sterownikow (sprzetowo) ze kupie sterownik pod usb i z niego sa wyprowadzane wyjscia? Cos musi byc co programuje USB...

Szczerze mówiąc nie zrozumiałem za bardzo... otóż wszelkiego rodzaju karty rozszerzeń poszerzających USB o kolejne gniazda nadal podlegają głównemu sterownikowi (choć nie wiem przypadkiem czy nie są traktowane jako nowe urządzenia, ale na pewno sterownik głowny nimi steruje i nadal jest to sterownik systemowy, chyba że konstruktorzy karty udostępnią swoje API ale to juz wtedy byłby cud, bo na pewno nie USB).

Jeśli chodzi o programowalne układy, które można zaprogramować i podpiąć pod USB to pewnie takie są, ale ma to jakieś znaczenie? Pewnie nie, bo napisanie sterownika w systemie obsługującego to urządzenie będzie trudne i z całą pewnością nie dla wszystkich.

Najłatwiej dostać układy scalone, które są tak skonstruowane, że działają jako wirtualne porty COM, które podpinasz pod USB. Taki port łatwiej sterować. Jak? Bardzo prosto. COM można otwierać z tego co pamietam prawie jak pliki, czyli ustawiasz transmisje i ślesz lub odbierasz podobnie do pliku. Dodatkowo można jeszcze posługiwać się pojedynczymi wyjściami/wejściami (choć nie wiem czy wszystkimi). Jeśli chodzi o LPT to z tego co pamiętam można posługiwać się nim dokładnie jak plikiem, czyli otworzyć plik o nazwie LPT (o ile dobrze pamiętam) lub (tak jak ja to robię) posłużyć się biblioteką inpout32, która daje możliwość bezpośredniego dostania się do portów tak jak to się robiło w asm przy pomocy instrukcji "in" oraz "out", choć nie wiem czy wszystkie porty działają. LPT chodzi na pewno.

Porty LPT i COM są portami do których dostęp jest możliwy bezpośrednio z naszego programu. Nie pośredniczy totaj nic. Praktycznie mamy dostęp bezpośrednio do sprzętu. USB ma zcentralozowany sterownik, który pośredniczy między programami. Ma to swoją zaletę - jeden sterownik radzi sobie lepiej z portem pod ktory może być podpięte mnóstwo urządzeń (do jednego portu USB można podpiąć równolegle wiele urządzeń) niż gdyby każde urządzenia miało swój sterownik.

Sorki jak coś poplątałem. Osobiście używam biblioteki inpout32 dostępne za free w necie lub z funkcji obsługujących COM. Częściej jest to LPT, bo to port równoległy, a zdarza mi się podłączać urządzenia z różnymi interfejsami, zazwyczaj zgodne ze standardem TTL i nie mające portu szeregowego.

0

To niestety prawda.. nawet popularne pisma elektroniczne ukazują projekty z zaimplementowanym konwerterem rs232->USB.. takie konwertery są oczywiście łatwo dostępne jak np. Ft232BM. Właściwie schodzimy już na temat mikrokontrolerów. Od ostatnich miesięcy popularne są nowe kontrolerki z rdzeniem ARM mające w swych strukturach (portach) już gotowe interfejsy USB a nawet LAN. Jest to jednak troche irytujące przynajmniej dla mnie, że chcąc stworzyć projekt jakiegoś urządzenia elektronicznego sprzężonego z kompem pozostaje stary (ale jary!) rs-232, którego są jednak pozbawiane laptopy.. i co tu zrobić.. zastosować konwerter? na razie tyle nam zostaje... ale czy to nie wkurzające? Cholera, zróbmy jakiś apel czy coś :P do polskich środowisk informatycznych, open sourceowych, forów, itd. niech ktoś to opracuje wreszcie, albo wspólnymi siłami! Brzmi to jak "Proletariusze wszystkich krajów...!" :P Wydaje mi się że "tajna wiedza" leży gdzieś głęboko w msdnie...

0

od strony PC tu masz info http://www.lvr.com/hidpage.htm , ogólnie szukaj o HID (Human Interface Devices) natomiast jeśli chcesz skonstrułować coś, co będziesz podłączał do USB do PC to kupujesz kość - kontroler usb i wtedy jak masz konkretną kość to jedziesz wg specyfikacji. Więcej też tu http://www.lvr.com/usbchips.htm

0

gals jak kupowałem w helionie kilka książek to w ramach promocji wybrałem jedną gratis o nazwie "Interfejsy sprzętowe komputerów PC". USB tam jest opisane dość dokładnie. Opis jest jednak fajny dopóki czyta się index :P ewentualnie specyfikację portu lub tryby :P. Dalej jest już tak nawalone że mi osobiście się nie chciało nawet tego czytać. RS232 jest lepszym standardem niż USB (niestety, choć ja uważam że na szczęście). Faktycznie są procki z konwerterem już w sobie, jednak większośc i tak wybiera poczciwy rs232, bo jest znany od lat i nie ma z nim problemu. BA! nawet jakiś czas temu pisałem programową obsługę RS232 w assemblerze na procku tak prostym, że nie miał go w sobie. Napisałem go dobrze. Do USB bym nawet nie stanął.

A teraz trochę o książce (przy czym nie jest to reklama!)

LPT opisano na 30 stronach wraz z opisem portów trybów EPP, ECP, rejestrów tego portu, jego podstawowej i ulepszonej wersji. Napisano trochę o konfiguracji.

COM opisano również na 30 stronach, opisując konwertery poziomów napięć, tryby np. asynchroniczny, podano konfigueację, jak rozwiązywać problemy z portem, jak testować port, opisano "Układy scalone asynchronicznych nadajniko-odbiorników (UART)". Czyli dużo pożytecznych informacji.

USB i FireWire opisane są na łącznie około 100 stronach! z czego USB to około 50 stron! Nie trudno się domyślić że nie jest to prosty interfejs, skoro aż tyle o nim napisano. Brak jest jakikolwiek konkretów w przeciwieństwie do LPT i COM, jest jedynie teoria przesyłania infrormacj np. "Przepustowość magistralii i urządzenia" czy też "Synchronizacja podczas transmisji izochronicznych".

O USB napisano między innymi:

tryby:
FS - full speed 12Mb/s
LS - low speed 1.5Mb/s
oraz w wersji 2.0 tryb HS - high speed 480Mb/s

Podstawowe 4 typy przepływu danych:

Transmisja izochroniczna - w czasie rzeczywistym przeprowadzana z wydzieleniem dedykowanej częśći pasma. W trybie FS takie pasmo to 1 kanał 1.023MB/s lub 2 kanały po 0.5MB/s. Dla HS to jeden kanał 24MB/s. Brak gwarancji na dostarczenie danych poprawnie, brak zaimplementowanych systemów poprawiania takich błędów np. poprzez ponowne wysłanie.

Przerwania - dane są wysyłane spontanicznie, kiedy akurat zajdzie potrzeba. Przy czym przerywania mają ustalone limity czasowe. Dane na pewno zostaną dostarczone.

Transmisja danych masowych - zajmują całe pasmo. Mają jednak najniższy priorytet i mogą być wstrzymane jeśli magistrala jest zbyt obciążona. Dane na pewno zostaną dostarczone.

Transmisje sterujące - wykorzystane do konfiguracji urządzeń. Dane zostaną dostarczone a urządzenie musi potwierdzić poprawność wykonania danego polecenia.

Dalej opisane są potoki:

Potoki:
strumieniowe - jednokierunkowe [...]. Żądania dla jednego potoku są wykonywane w ściśle okreslonej kolejności w której nadeszły. W przypadku wystąpienia poważnego błedu jest generowany sygnał <b>stall</b>.

do przesyłania komunikatów - dwukierunkowe. Są zsynchronizowane, mają określoną kolejność, wymagane potwierdzenie. Zazwyczaj następny komunikat nie zostaje wysłany bez potwierdzenia powszedniego

<b>Potoki różniące się przeznaczeniem:</b>
domyślny - czyli potok sterujący 0, którego właścicielem jest sterownik USB, jest wykorzystane do konfiguracji wszystkich urządzeń.

kliencki - należą do sterowników urządzeń. W potokach tych można przesyłać strumienie i transmisje w dowolnym typie (izochroniczne, masowe itd)

Potem opisano ramki i mikroramki a następnie transakcje magistrali wraz z formatem ramek i oznaczeniami kodów tzw. PID (np. kod IN, OUT, PING, STALL, ACK itd). Opisano mechanizmy obsługi błędów...

itd itd itd.
TO TYLKO 20 STRON! NAWET NIECAŁE 20!. Pozostałe 30 opisują dalej jak przesyłane są dane, jak wygląda zgłaszanie błędów itd.

Jak widać po tym "krótkim" opisie jest tego trochę. Mnie osobiście to przeraża i dlatego wolę COM jeśli to urządzenie ma być stosowane na różnych kompach lub LPT jeśli tylko testuje coś np. po szynie I2C.

0

Tak zle to z ta wiedza nie jest, dostepne sa

  • przyklady jak libusb z kodem
  • ksiazki http://helion.pl/ksiazki/komusb.htm,
  • gdzies sie wala po internecie specyfikacja USB 1.1 (chyba z 400 stron),
  • zreszta specyfikacja 2.0 tez jest http://www.lammertbies.nl/comm/info/usb-specification.html.
  • przyklady wraz ze sprzetem (jak zaimplementowac stos USB w swoim mikrokontrolerze (IgorPlugUSB)
  • wraz z kodem (PowerSwitch).
  • Przyklady z DDK
  • najszybsze do zaimplementowania przyklady z HID (na tym forum)
  • jak ktos ma pieniadze to WinDriver (kiedys chyba byla demowka)
  • do mikrokontrolerow z USB sa sterowniki/przyklady

i pewnie duzo wiecej, jednak nie jest to tak jak z comem czy lpetem: 5 sekund i diody migaja.

Najprostsze rozwiazania to:

  • PowerSwitch+libusb (z 10-20 minut uruchomienie)
  • FTDI, jak juz sie przylutuje to tez z 10-20 minut
  • ewentualnie jakis PIC albo atmel albo ??? z USB (czy mozna w ogole tu mowic o uruchomieniu ...)
0

reichel napisał:

jednak nie jest to tak jak z comem czy lpetem: 5 sekund i diody migaja

Właśnie i dlatego zazwyczaj zabawa z USB leży poza rozsądkiem. Zwłaszcza, że kupić można jeszcze konwertery między standardami RS232 -> RS485 i mamy przemysłówkę. Z USB daleko się nie zajdzie jeśli sprzęt ma chodzić na dalszą odległość. Zeby cokolwiek zrobić na USB to trzeba się nieźle napracować i poczytać, a COM i LPT? Zrozumienie dokumentacji i przykładów dla początkującego to poniżej pół godziny.

Jeśli chodzi o ilość informacji to może masz rację (nie wiem, aż tak w USB nie siedzę) ale prawda jest taka, że dopóki USB nie będzie w użyciu przy tworzeniu własnych amatorskich urządzeń, tak jak obecnie króluje COM i LPT to nie powstanie nigdy dobra dokumentacja, taka dla każdego. Ludzie którzy tworzą jakieś swoje urządzenie i mają wybór miedzy prosty i sprawdzony COM/LPT a USB wolą COM/LPT, bo nie widzą potrzeby zabawy. Tylko nie liczni mają chęć poznawać USB. I tutaj myślę jest największy problem. USB jest zbyt skomplikowane jak na większość prostych urządzeń. Poza tym sama historia USB świadczy trochę o tym jak złożony jest to problem. Pierwsze wydania były obarczone błędami, wiele różnych firm wprowadzało swoje jakieś dodatki, więc urządzenia nie działały poprawnie itd. Potem pojawił się dopiero standard... a historia COM czy LPT? Już komputery takie jak Amiga, C-64 były wyposażone w jeden i drugi interfejs (co prawda C-64 miał RS232C z tego co pamiętam).

Podsumowując... osobiście jestem zwolennikiem RS232 i LPT ze względu na ich ogromną popularność i dostępność informacji o obu. Poza tym RS232 pasuje mi lepiej w miejscach gdzie sprzęt będzie leżał w nieznanej odległości od komputera, bo można uzyć konwertera.

Aha zapomniałem porównać jeszcze koszty w postaci czasu i pieniędzy. COM/LTP to "5 sekund" + Kabel. USB to konieczność zapoznania się z układami, ich konfiguracja pewnie, koszt dodatkowego układu... a wszystko tak na pawdę dla szpanu :(.

0

Moim zdaniem dokumentacja jest dobra, a ze dla amatorskiego uzytku jest to trudne no coż mozna zbudowac radio na kawalku preta ferytowego z jedna dioda i kondensatorem albo odbiornik z tysiacem cewek, dlawikow, filtrow etc. To mniej(mniej) wiecej taka roznica.

Do malych projektow istotnie warto stosowac COM/LPT (przejsciowki). Ale jak budujesz cos wiekszego to nie jest tak zle. Cos za cos, IDE, PCMIA, PCI, USB, ... nie sa proste ale maja sporo zalet ktore czasami sa niezbedne w projekcie.

a co do kosztow niezgodze sie

http://www.obdev.at/products/avrusb/powerswitch.html

tyle samo czasu i wysilku co w przypadku COM

0

Cos za cos, IDE, PCMIA, PCI, USB, ... nie sa proste ale maja sporo zalet ktore czasami sa niezbedne w projekcie.

Oczywiście, ale realnie popatrz... ile jest sprzętu który tego wymaga? USB ma tylko sens dla wielkich projektów, dla komercyjnego sprzętu. W praktyce jednak nie jest niczym wielce szczególnym, za to skomplikowanym o wiele wiele wiele razy mocniej niż wszystko inne. Dla przykładu, widziałem drukarkę canona nowiuśki sprzęt i drukarkę laserówkę pod LPT. Jak zechcę coś wydrukować do ta pod LPT idzie szybciej :).

PS. nie bawiłem się z PCMIA i PCI, ale powiem ci szczerze, że IDE do współpracy z dyskiem twardym implementowałem w C i działało. IDE w podstawowej wersji wbrew pozorom jest strasznie proste (chyba, ja przynajmniej nie miałem z nim problemu), oczywiścnie nie korzystalem z DMA, bo nie było takiem potrzeby. Implementowałem również RS232 programowo, też poszło łatwo. No o LPT to nie wspomnę, bo szkoda w ogóle go komentować :P. Do USB wolałbym się nie zbliżać :), bo bym takiego molocha nie napisał. Konstrukcja USB jest mocno przesadzona, za mocno. W zasadzie to Ci powiem że widziałem na necie prosty układzik do sieci LAN, który można skonfigurować i pracować przez LAN. Chyba wolałbym taki sprzęcik zrobić :). Coś takiego wydaje mi się fajniejsze.

Ach, nie odniosłem się jeszcze do innej kwestii.

Wiele amatorskich urządzeń z COM jest o tyle lepsze niz z USB, że można je potem podpiąć pod inne urządzenia -> jedno urządzenie steruje drugim. To jest plus, bo przez USB pewnie tak łatwo by nie poszło.

Druga sprawa, to zobacz ile to pisania w uP żeby działało. Dla COM raczej mniej.

Trzecia sprawa zobacz ile pisania pod systemem np. funkcja (i tutaj dla COM prościej):

static int usbOpenDevice(usb_dev_handle **device, int vendor, char *vendorName, int product, char *productName)

Każdy interfejs ma swoje + i -. COM zazwyczaj sprawdza się wystarczająco dobrze, jest prosty, pozwala na sterowanie urządzeń przy pomocy innych urządzeń itd. USB jest o wiele bardziej skomplikowany (nawet jeśli jest na pokładzie uP) po obu stronach - urządzenia i komputera. Oczywiście wszystko pozostaje kwestią dyskusji i zależy od zastosowania, jednak ja USB wybrałbym na samym końcu interfejsów.

0

Jest w tym troche racji a na pewno to ze USB jest tylko dla komputerow (PC,maki etc.). USB raczej jest dla wygody programisty niz dla wygody tworcy (podobnie jak program konsolowy i program z GUI nastawionym bardzo na uzytkownika klasy 0 - nic nie wiedzacego).

reasumujac USB jest dla urzadzeni ktore beda stosowane przez ludzi o malym pojeciu o konfiguracji (chociaz widzialem takie urzadzenia komercyjne, ktorych USB trzeba bylo konfigurowac - pewnie tworcy pisali w stylu COM'a).

IDE owszem proste w wersji najprostszej.

Ale oddalamy sie od pytania/odpowiedzi. Skoro po tym stwierdziles, ze dla twojego projektu starczy COM/LPT to temat wyczerpany.

A wracjac do modulowych konstrukcji to sa jescze inne polaczenia bardziej pewne. Jak dla mnie COM dzisiaj jest dobry do zabawy i jakiegos prostego sterowania.

0

Skoro po tym stwierdziles, ze dla twojego projektu starczy COM/LPT to temat wyczerpany.

reichel na wszelki wypadek przypomnę że nie jestem auterem wątku, bo takie odniosłem wrażenie że zostałem potraktowany jak on.

IDE skomplikowane nie jest aż tak bardzo. Sprzęt zdolny do przetwarzania danych w trybie DMA to już dobry sprzęt. AVR nie dadzą rady, więc zostaje zwykły tryb. Poza tym IDE w ogóle jest dość zrozumiałym interfejsem. Są adresy, błedy, możliwość poznania sprzętu. Dość łatwo napisać program dla AVR który by bawił się dyskiem w trybie PIO (o ile nie przekręciłem określenia). Poza tym myślę że powinienem wspomnieć o tym, że są urządzenia IDE a interfejs właściwie to ATA, ale to tak na marginesie.

A wracjac do modulowych konstrukcji to sa jescze inne polaczenia bardziej pewne. Jak dla mnie COM dzisiaj jest dobry do zabawy i jakiegos prostego sterowania.

Oczywiście że tak. Najczęściej moduły pracują po I2C, choć z tą pewnością połączenia w tym przypadku nie jest idealnie :). RS232 bierze jednak górę nad wszystkim kiedy pojawia się odległość. Wtedy konwersja RS232->RS485->RS232. Właściwie to pewność połączenia i dostarczenia informacji nie do końca jest uzależniona od interfejsu sprzętowego. Przecież w głównej mierze za wykrywanie błędów odpowiada oprogramowanie, a to nie podlega ocenie, bo to się po prostu pisze.

reasumujac USB jest dla urzadzeni ktore beda stosowane przez ludzi o malym pojeciu o konfiguracji

Zgadzam się w 100%, choć przyznam, że urządzenia z USB nie raz pokazywały że do idealnych nienależą.

0

Chcialbym napisać program/programy, ktore obsluza dodany poprzez USB sterownik[...]

Chce troche poszerzyc mozliwosci, pokombinowac, poczytac...bo baze z języka Cpp mam dość dobrą, bo umiem pisać obiektowo, zapisywać do pliku, tworzyć bazy na tablicach itp

Czesc

Zamiast dyskutować czy warto lepiej skupmy się na problemie [glowa]

Ja tez ostatnio zająłem się tym tematem i dotarłem do biblioteki usblib-win32 tu ją można ściągnąć:
http://www.systomath.com/etc/scripts/unicounter.pl?name=../counters/LibUsbWin32_0_1Setup_dl&trackip=0&deliver=../../packages/w32/LibUsbWin32-0.1Setup-10.01.exe
Zainteresuj się może tą biblioteką to coś wspólnie wydumamy [browar]

Tu jest przykładowy programik pisany pod biblioteke w Liniksie, ale wystarcz wprowadzić pare zmian i będzie sie kompilowało i linkowało:
http://www.opcode.eu.org/c_cpp/test_libusb.c/#c_cpptest_libusb.c

Jedna ważna uwaga, zamiast globalnej struktury usb_busses należy użyć funkcji: usb_get_busses()

Jak na razie udało mi się zainicjować obsługę USB i odczytać ilość magistrali USB w moim PC. Jest jednak problem z funkcją usb_find_devices() Bez względu na to czy podepnę jakieś urządzenie do portu USB czy nie to zawsze zwraca mi 0, czyli zero zmian w podłączonych urządzeniach USB. Co za tym idzie programik nie wykrywa urządzeń USB, zmienna devices w strukturze każdej magistrali jest pusta.

Jak ktoś miał ten problem to niech napisze co wykombinował.

Pozdro!

0

Ściągasz Device Driver:
http://libusb-win32.sourceforge.net/#downloads
W katalogu bin albo podobnie jest tool służący do generowania sterowników.
I teraz:
podpinasz swoje urządzenie
uruchamiasz generatora sterowników, wybierasz z listy swój device na podst. vendor i product id.
generujesz sterownik (plik inf + jakieś dodatkowe flaki).
Jeśli windows do tej pory sam nie prosił o sterowniki, to we właściwościach urządzenia swego klikasz "aktualizuj sterownik" albo jakoś tak.
Wskazujesz plik sterownika zrobiony przed chwilą.
Instaluje się.

Od teraz urządzenie jest "osterownikowane" i libusb z nim będzie pracować.

Albo miast robić sterownik do jednego konkretnego urządzenia, możesz zainstalować "Filter Driver" i wtedy libusb powinien wykrywać wszystko, co jest.

0

Zrobiłem jak poradziłeś: ściągnąłem i uruchomiłem inf-wizard.exe i wygenerowałem plik inf do zwykłego pendrajwa. Potem zainstalowałem go w menadżerze urządzeń. Zainstalował się ok, ale przestał być widoczny jako dysk w eksplorerze i co najważniejsze funkcja dalej zwraca zero.
Sprawdziłem programem testującym dostarczonym przez libusb-win32 i widzi urządzenie i pokazuje te same numery product i vendor.

Niby ok a funkcja ślepa [???]

0

hmm, tak, jak zainstalowales inf-wizardem nowy sterownik, to pendrive juz nie jest pendrivem tylko "twoim" urzadzeniem, ktore jest widoczne w menadżerze urządzeń jako libusb-device albo tak jakos. Czyli jak chcesz, żeby jednocześnie windows do tego standardowe sterowniki dawał, a ty libem obsługiwał, no to filter zostaje.

Funkcja zwracająca zero...

  1. a niech zwraca zero, przecież ten wynik de facto nie jest potrzebny do niczego ;]
  2. ona nie ma zwracać ilości urządzeń podpiętych, ale ilość zmian, jakie nastąpiły od poprzedniego wywołania funkcji. Różnica jest, szczególnie, jak wywołujesz funkcję tylko jeden raz ;]

A tak na nawiasem mówiąc, te instrukcje free(bus) wywal. Skąd w ogóle taki pomysł, żeby zwalniać to? usb_busses, (bo na to bus został ustawiony) jest zmienną globalną.

Na moje oko powinno chodzić, bo mi coś podobnego (wszak to trochę przerobiony exampl) chodzi.

0

Funkcja zwracająca zero...

  1. a niech zwraca zero, przecież ten wynik de facto nie jest potrzebny do niczego ;]
    </quote>

Ok niech zwraca, ale jak już pisałem potem w pętli przeszukującej każda magistrala jako device zwraca zero => czyli nie ma urządzeń
Poza tym właśnie ta funkcja przy 1 uruchaniu powinna zwrócić liczbę urządzeń na USBkach...

1 użytkowników online, w tym zalogowanych: 0, gości: 1