Jak napisać custom composite class handler dla STM32 USB host?

Jedyne co udało mi się znaleźć w necie na temat obsługi urządzenia composite za pomocą biblioteki USB host dla STM32, to wielce pocieszająca informacja z dokumentacji tejże biblioteki:

Cytat:

5.5 FAQs
Q: Does the USB host library support composite devices (for example Mass-storage + HID)?
A: Yes, providing the users write a custom composite class handler for the composite device.

Więc na razie wiem tyle, że się da (; Nie udało mi się namierzyć w necie żadnego przykładu jak tego dokonać, ale może zbyt słabo szukałem, więc może ktoś takowy przykład gdzieś widział albo ma u siebie? Wdzięczny będę również za wszelkie wskazówki jak to mniej-więcej powinno działać i co trzeba tam wyczarować.

Będę przy komputerze to spojrzę w swoje biblioteki. Wydaje mi się że coś takiego mi się przewinęło jak robiłem rozeznanie do USB hosta.

Mam kilka przykładów dla composit device tylko. Nic dla hosta. Ale z tego co udało mi się wyczytać to da się to zrobić poprzez połączenie dwóch klas urządzeń. Kolejna sprawa to czy to nie będzie wymagało dodatkowych zasobów od STMa.

Możesz spróbować przegryźć się przez USB Host Stack z pakietu Microchip Harmony for PIC32.

Cytat z dokumentacji:

Cytat:

The USB Host Layer in the MPLAB Harmony USB Host Stack performs the tasks of enumerating an attached device and interfacing the HCD. The following are the key features of the MPLAB Harmony USB Host Layer:

Supports multi-configuration and composite USB Devices
Supports VID PID and class, subclass, and protocol devices
Can manage multiple USB devices through the Root Hub
Concise API simplifies application development
Modular architecture allows support for multiple (and different) USB controller in one application. Can operate multiple USB segments.
Supports Low-Speed, Full-Speed, and Hi-Speed USB devices

Aktualnie pojawiła się wersja 3.0 która ma obsługiwać ARMy od Atmela/Microchip.
https://github.com/Microchip-MPLAB-Harmony

Działam na razie z kodem od ST. Po głębszej analizie (zbytnio na USB to ja się nie znam - jeszcze (; ) okazało się, że modemy GSM z CDC mają mało wspólnego, bo praktycznie wszystkie z góry na dół są klasy "vendor specific". Na szczęście używanie tego z poziomu hosta USB jest dosyć proste, podobne do CDC (które zresztą też jest proste). Napisałem więc swój driver i tu zaczynają się schody (; Kod USB hosta od ST to jest po prostu kwintesencja tego co sprawia, że zawsze wolę napisać swój kod zamiast używać takiego "crapware" od producentów. Generalnie jest tak lewy, że bardziej na lewo od niego jest tylko betonowa ściana.

Anyway...

Czy ktoś działał z tym kodem i udało mu się go zmusić do jakiegoś sensownego działania? Mam kilka pytań, które zapewne są dosyć głupie (bo mało się na tym USB znam), jednak wydaje mi się, że problem jest gdzieś w tym kodzie od ST, a nie w moim, bo ten mój jest wręcz banalny (otwieram kilka pipe'ów i wysyłam/odbieram z nich requesty typu BULK - zero filozofii, praktycznie jest to kalka kodu dla CDC). Na ten moment całość z modemem działa "w kratkę", tzn. czasem po resecie nie zadziała ani razu. Gdy całość po resecie jednak "odpali", to tak czy siak w ciągu max kilku minut finalny efekt będzie taki sam - device przestaje odpowiadać i nie odsyła żadnych ramek, choć rzekomo odbiera moje ramki. Cały test jest skrajnie prosty - włączam nasłuch na wszystkich 3 portach szeregowych modemu i na jeden z tych portów szeregowych co ~20 sekund wysyłam "ATI\r\n", na co modem przez pewien czas odpowiada prawidłowo, a potem milknie. Za bardzo nie wiem od której strony podejść do tego problemu i nawet nie mam już pomysłów gdzie szukać potencjalnej przyczyny...

Ja może trochę poza tematem.
Co Koledzy sądzą o tym projekcie?
https://github.com/dmitrystu/libusb_stm32

Gdzie wywołujesz obsługę USB? Ja miałem problem z wywoływaniem obsługi w przerwaniu i dopiero przeniesienie tego do pętli głównej pomogło. A co do kodu od ST to zrozumienie go jest już na innym poziomie.

-XantiO- napisał:

Gdzie wywołujesz obsługę USB? Ja miałem problem z wywoływaniem obsługi w przerwaniu i dopiero przeniesienie tego do pętli głównej pomogło.

Wszystko jest realizowane w innych miejscach niż przerwania.

Na ten moment mam taką oto ciekawą obserwację. Jeśli mój kod testowy odpalę tylko dla JEDNEGO portu szeregowego modemu, to wszystko działa jak trzeba przez dosyć długi czas. W takiej sytuacji używam tylko dwóch pipe'ów. Jeśli jednak dorzucę nasłuch na jeszcze jednym porcie szeregowym, na który akurat nic nigdy nie przychodzi (tak więc z mojej perspektywy nie zajmuje to czasu mikrokontrolera), to całość przytnie się nadzwyczaj szybko. Akurat w takiej sytuacji najpopularniejszy "tryb przycięcia się" jest taki, że pipe używany do wysyłania host->device nie wysyła transferu, a pipe'y które są od odbioru (przynajmniej jeden, bo na ten drugi nic nie przychodzi tak czy siak (; ) działają (jak wykręcę na moment anteny z modemu to dostaję kilka URC ze zmianą poziomu sygnału).

Nie pamiętasz może ilu pipe'ów używałeś w swoim zastosowaniu? Nawet nie chodzi o to ile jest otwartych (u mnie 6 z urządzenia + dwa CTRL), tylko ile jest "często" używanych.

-XantiO- napisał:

A co do kodu od ST to zrozumienie go jest już na innym poziomie.

Żeby go zrozumieć, to najpierw trzeba by dosyć dobrze zrozumieć USB, potem układ peryferyjny USB w STM32F7, a dopiero potem ten kod...

Pisałem to już 100 lat temu. Kod USB ST nie jest wielobieżny; sam peryferial "nie jest wielobieżny", bo wymaga operacji bitowych (realizowanych jako logiczne AND i OR) na rejestrach, w których każdemu endpoint odpowiada jeden bit (a jako pasjonat bitband zapewne zauważyłeś, że USB nie leży w obszarze bitband). Wszelkie procedury operujące na endpointach/kanałach host muszą być wołane na tym samym priorytecie sprzętowym procesora, co obsługa USB. Jeśli używasz przerwania USB, to procedury np. wysyłania czegoś po USB muszą być wołane z przerwań (np. wyzwalanych programowo) o tym samym priorytecie. Inaczej stos USB prędzej lub później zawiśnie.

Z tego co piszesz wynikało by, że w zasadzie tego kodu się po prostu nie da używać w sposób przewidziany przez autorów (; Rozumiem, że aby to ominąć to funkcję `USBH_Process(&hUSBHost);` musiałbym wywoływać np. z przerwania od timera, które miałoby taki sam priorytet jak przerwanie od USB?

Ad 1 - Właśnie tak - nie da się.
Ad 2 - Zapewne tak. Jak wiesz, ja nie RTOSowy, ale ogólnie kiedy mam coś wysłać do hosta w oprogramowaniu device - zgłaszam przerwanie o tym samym priorytecie, co przerwanie USB i wysyłam (wołam jakieś tam Send) w tym przerwaniu właśnie. Podobnie w przerwaniach wołam procedurę Receive, która, jak wiadomo, nic nie odbiera, tylko odblokowuje możliwość odbioru.

Tak na szybko spróbowałem pójść tym tropem i na czas wykonania funkcji USBH_Process() wyłączyłem przerwanie od USB - jeśli dobrze myślę, to powinno to dać podobny efekt jak obsługa tylko w przerwaniach (generalnie w kodzie hosta wszystko dzieje się w tej funkcji, dowolne funkcje klasy tak naprawdę tylko przestawiają odpowiednie flagi w odpowiednich miejscach, co znów powoduje że w funkcji USBH_Process() coś ciekawego się zdarzy). Niestety problemu zasadniczo to nie rozwiązało, choć zmieniło "tryb przycięcia się" - obecnie nie udaje mi się wywołać sytuacji w której wysyłanie pakietu się przycina, za to za każdym razem, po kilku poprawnych transmisjach, modem przestaje odpowiadać. Sprawdzanie stanu pipe'ów których używam do obioru pokazuje, że obydwa są "NAK" / "NOTREADY". Badam sprawę dalej.

BlueDraco napisał:

Ad 1 - Właśnie tak - nie da się.

(; czyli nie myliłem się w swoim osądzie, że ten "crapware" nie nadaje się do niczego. Są jakieś alternatywy? Bibliotek dla "device" jest całkiem sporo, ale dla hosta jest ich bardzo mało...

U mnie USB host to tylko HID dla skanera kodów kreskowych. Korzystałem z drivera od ST i jedynie dałem wpisy do usb_host.c

Co najśmieszniejsze USBH_Process() siedzi w głównej pętli a "reszta" programu leci z przerwań i wszystko jakimś cudem śmiga.

Co do pipów to chyba były "aż" 4 otwarte co mnie zastanawiało zawsze ale się zbytnio w to nie zagłębiałem (bałem się nawet cokolwiek zmieniać bo to USB było dodawane na ostatnią chwilę)