"USB Microchip Driver" problem PIC18F2550

I prawidlowo.... HOST probowal sie "dogadac po trzykroc :)" z Twoja koscia i zamiast odpowiadac na zadania czekales w petli.

Hmm, hardware'owy monitor portu USB ? Odpowiadal ze jest zajety, wiec HOST probowal ponowic probe a ty co.... - Czekales w petli !

Jak odbierzesz dane odpowiadasz ACK, NAK lub STALL i teraz albo ustawiasz to w rejestrze albo robione jest to automatycznie prze uP.

U¿ytkownik "Piotrek" <piotrd snipped-for-privacy@wp.pl napisa³ w wiadomo¶ci news:e2i8un$9h2$ snipped-for-privacy@nemesis.news.tpi.pl...

No wlasnie:) Gdy czekam w tej petli opozniajacej(to moze byc tez moje zadanie!) to mam bufor USB (UOWN bit ustawiony na uP). Jesli tak to uP powinien wysylac przez te 2ms NAK'i - i to robie. Ale przeciez po tych 2ms znow powinien odczytac transakcje od hosta bo przeciez ustawilem bit UOWN tak aby host mogl pisac do buforka:) . Czemu wiec PIC odpowiada caly czas NAK'iem??

U¿ytkownik "Piotrek" <piotrd snipped-for-privacy@wp.pl napisa³ w wiadomo¶ci news:e2i8un$9h2$ snipped-for-privacy@nemesis.news.tpi.pl...

Wlasnie przed chwila wyczytalem ze pakiety z kontrolnego endpointa (SETUP) powinny byc potwierdzane wylacznie ACK! Jesli wiec PIC bedzie zajety, to wg. specyfikacji wysle NAK, ciekawe tylko co wtedy robi host(?)...

Zeby to najlatwiej zrozumiec musisz sobie to debagowac, zrzucaj stan rejestrow UARTEM, zobaczyc jak odpowiada host. Z tym nakiem jest roznie otoz zaraz po podlaczeniu urzadzenia przy pierwszej probie pobrania deskryptora przez HOST na zapowiedz typu IN ladujesz pierwsze 8 bajtow do Hosta, powinienes dostac ACK lecz tak nie jest otrzymasz NAK pomimo tego ze odebral on te 8 bajtow. Zostaniesz zresetowany ponownie przez Host, w tych pierwszych 8 bajtach ktore mu przeslales byl zapisany rozmiar device descriptor, wiec zaraz po drugim resecie magistrali Host poprosi Cie jeszcze raz o deskryptor urzadzenia juz w celu jego pobrania , zna juz rozmiar i wie ile razy ma wyslac do Ciebie zapowiedz IN a potem zostaniesz poproszony o deskryptor konfiguracji i tu pomimo zwrocenia jego rozmiaru Host poprsi cie o 255B pomimo ze twoj deskryptor jest mniejszy, w celu zakonczenia procesu enumeracji musisz mu chyba wyslac pakiet zerowy

U¿ytkownik "Piotr" snipped-for-privacy@wp.pl napisa³ w wiadomo¶ci news:e2j8c7$2fiq$ snipped-for-privacy@news.enterpol.pl...

UART zajety - w picu to te same wyjscia co USB:(

Sek w tym ze enumeracja u mnie nastepuje pomyslnie, tak naprawde to ten delay_ms(2) wstawiam: if(USB_state_ => USB_CONFIGURED) // tego brakuje w kodzie na poczatku posta delay_ms(2); I host sie wiesza podczas GetReport(HID)... dostaje pozniej same NAKI:( Wszystko ogladam na hardwareowym monitorze USB.

Zauwazylem ze PIC18F2550 posiada 4 poziomowy stos transakcji (USTAT), no ale jesli sie przepelni to przeciez w petli predzej czy pozniej bede pojedyncze transakcje oblugiwal wiec chyba co ktorys ACK powinien wyjsc od pica ... a tu same NAKI kurde...

Sprobuj jeszcze zmienic wartosc pola (Polling interval) w deskryptorze dla kazdego endpointa.... Ponizej podaje przyklad

...................... /* HID Class-Specific Descriptor */ ..........

/* Endpoint Descriptor */ sizeof(USB_EP_DSC), // Size of this descriptor in bytes DSC_EP, // Endpoint descriptor type _EP01_IN, // Endpoint 1 IN _INT, // Interrupt transfers HID_INT_IN_EP_SIZE, // Maximum packet size 0x0A, // Polling interval (milliseconds) (tu jest ustawione na 10ms sprobuj zmienic na 0xFF) .............................