Citat:
pp.peca: Zdravo,
...
Sve u svemu: ako neko dobro zna šta se dešava u kolu PIC18F4550 (ali znate, korak po korak) pa ili neka to objavi frajke ili neka napiše knjigu sa apsolutnim objašnjenjem šta se dešava i kako to uraditi u kodu a ne tekstove tipa: host pošalje reset, pa onda... a vi pojma nemate šta PIC u tom trenutku treba da ima naštelovano u sebi, koje registre da pratite i šta da uradi sledeće. Pa kad to završi, šta dalje...
Evo frajke:
Pre nego što se uključi USB periferija na PIC-u treba:
-odlučiti koja brzina će se koristiti (Full ili Low) i po tome konfiguriše bit FSEN.
-napraviti radni klok za USB periferiju i izabranu brzinu (sika 2-1 na strani 24). Primer, Full-speed i kristal 12MHz:
CONFIG PLLDIV = 3 ; 12/3 = 4MHz (96MHz PLL)
CONFIG FOSC = HSPLL_HS ; HSPLL
CONFIG CPUDIV = OSC1_PLL2 ; /2 = 48MHz Primary clock
CONFIG USBDIV = 2 ; USB clock source comes from the 96 MHz PLL divided by 2
-ako se želi eksterni transrisiver treba isključiti interni setovanjem bita UTRDIS.
-kada se koristi full-speed komunikacija potrebno je da se stavi 1.5K pull-up otporik za liniju D+ a kada se koristi low speed pull-up se stavlja na D- liniju. Kada je odabran interni transrisiver tada je mogće koristiti i interni pull-up otpornik setovanjem bita UPUEN.
-ako se želi monitoring nad internim transrisiverom potrebno je setovati bit UOEMON. Monitoring ide preko pina -UOE (active low) i aktivni signal na tom pinu predstavlja intervale u komunikaciji u kojima PIC upravlja linijama D+ i D-. Zgodno za analizu osciloskopom.
-ako se želi test mod u kom transrisiver generiše OKO potrebno je uključiti ga preko UTEYE. Inače, normalno je uvek isključeno. OKO je oblik koji se vidi na osciloskopu kada se stavi vremenska baza jednaka intervalu jednog bita u komunikaciji. Tada se prelazi (sa 0 na 1 i sa 1 na 0) isprepletu ostavljajući između zonu bez iscrtanih signala koja se zove oko. Što je oko čistije i veće to je bolje. Što je propagacija signala lošija i oscilovanje po dostizanju nivoa veće to je oko manje i lošije definisano.
-NAPAJANJE, za USB signale neophodan je napon od 3.3V. Postoji interni regulator za interni transrisiver ali ako se on koristi neophodno je staviti kvalitetan 220nF kondezator na pin VUSB radi stabilnosti. Interni regulator se može uključiti preko konfiguracionog bita VREGEN.
CONFIG VREGEN = ON ; USB voltage regulator enabled
-odlučiti da li se želi pinpong baferovanje (drugi treći ili četvrti slučaj kao na slici 17-7) i podesiti PPB1:PPB0.
-konfigurisati kontrolne registre za svaki endpoint (EP0 - EP15). Osnovno je da bar EP0 bude uključen za primanje.
-potrebno je odrediti bafere za komunikaciju. Drugi kilobajt RAM memorije je takozvana dual port memorija kojoj istovremeno može da pristupa jezgro mikrokontrolera i USB periferija pa je potrebno bafere za USB komunikaciju alocirati u tom delu adresnog prostora. Prvi bajtovi te memorije (počev od adrese 0x0400) se koriste kao bafer deskriptori. Svaki bafer deskriptor zauzima po 4 bajta i ako se endpoint-i kojih se ti deskriptori tiču ne koriste onda se ta memorija ne mora preskakati i može se pametnije upotrebiti za nešto drugo. Osnovno je da se pre uključivanja USB-a konfiguriše bafer i bafer deskriptor za EP0 u smeru od hosta ka uređaju (OUT) jer će prva komunikacija koja krene biti sa SETUP tokenima. Token je deo zaglavlja svake transakcije, ima četiri bita koji određuju vrstu tokena i većina njih se hardverski opsluži od strane USB periferije na PIC-u. Kada periferija izparsira SETUP token on se opsluži tako što se podaci preusmere u memorijski bafer EP0OUT. Podrazumevana veličina podataka sadržanih u kontrolnim transferima je 8 bajtova. Ostali transferi i veličine njihovih bafera se opisuju kroz handshake-ovanje.
Dakle, host (PC) ima potpunu kontrolu nad komunikacijom.
Kada se uključi USB periferni modul (registar UCON) on nalaže svom transrisiveru da simulira ubadanje konektora u port i kada host prepozna promenu na magistrali počinje handshake slanjem reset signala.
Reset signal je kada su obe linije (D+ i D-) nula. Hardver na mikrokontroleru prepoznaje reset i to prosleđuje jezgru kao interrapt (URSTIF). PIC firmware treba tada da obavi resetovanje svih parametara, adresnog registra, bafer deskriptora i sl. zatim uključi slušanje EP0OUT.
Nakon reseta, host šalje uređaj u mod sa suspenovanom potrošnjom i posmatra da li i koliko brzo menja stanje i koju struju tada troši. U slučaju da uređaj ne reaguje suspenzijom na vreme, host ponavlja probu ukupno tri puta. Sunspenzija potrošnje se na PIC transrisiveru kontroliše preko bita SUSPND a kao odgovor na IDLEIF interrapt. Izlazak iz suspenzije treba obaviti kao odgovor na interrapt ACTVIF.
Kada se ovo obavi host ponovo šalje RESET koji se javlja kao interrapt i uvek isto kao gore navedeno opslužuje.
Nakon ovog reseta host šalje kontrolni transfer na EP0. Hardver mikrokontrolera prihvata bajt po bajt i slaže ih u bafer. Kada se prijem završi periferija vraća hostu ACK signal o uspešnom prijemu i zatim prijavljuje jezgru mikrokontrolera obavljenu transakciju preko interapta TRNIF. Zatim firmver treba da u obradi ovog interapta obavi parsiranje sadržaja, te u zavisnosti od primljenog preduzme radnje.
Kada se desi TRNIF interrapt tada se prvo gleda u USTAT registar da bi se odredilo koja EP je generisala prekid i kog smera je bio taj obavljeni transfer (i eventualno koji polubafer pri pinpongovanju). Ako je EP0 imamo kontrolni transfer. Ako je DIR nula onda se radi o OUT ili o SETUP tokenu. Kada je slučaj EP0 i SETUP to se naziva komunikacijom kroz "Default Control Pipe" i svaki Setup paket je dug 8 bajtova i detaljno objašnjen u poglavlju 9.3 USB Device Requests unutar dokumenta "Universal Serial Bus Specification" v2.0.
U ovom trenutku imamo osam primljenih bajtova u kontrolnom EP0OUT baferu. Naš firmware počinje parsiranjem nad prvim bajtom koji je imenovan u ovoj osmobajtnoj strukturi kao bmRequestType. Bit najveće težine govori o smeru zahteva pristiglog od hosta. Zahtevi koje treba opslužiti slanjem dodatnih IN transakcija natrag hostu imaju vrednost ovog bita 1. Dalje sledeća dva bita određuju tip zahteva. Postoje standardni zahtevi zajednički svim USB uređajima. Zatim su tu zahtevi specifični za određenu klasu uređaja i na kraju zahteve koje je pridodao sam proizvođač i koji imaju najspecijalniji karakter. Najlakša pet bita prvog bajta određuju primaoca za zahtev (Device, Interface, Endpoint,...)
Drugi bajt zahteva, bRequest, predstavlja identifikaciju samog zahteva i svi standardni se nalaze u tabeli 9.3 USB specifikacije.
Treći i četvrti bajt su šesnaestobitna vrednost wValue čiji kontekst zavisi od predhodnih vrednosti.
Peti i šesti bajt su šesnaestobitna vrednost wIndex čiji kontekst zavisi od predhodnih vrednosti, obično indeks nečega.
Sedmi i osmi bajt su šesnaestobitna vrednost wLength koja predstavlja veličinu zahtevanog transfera u bajtovima.
U suštini, prvi TRNIF kada se isparsira znači Get Device Descriptor. Tada započinjemo seriju slanja DEVICE DESCRIPTOR-a ali host u ovom trenutku prihvata samo prvi IN paket i zatim prekida podešavajući svoje bafere i dijagram stanja prema onome što može da se vidi iz prve IN transakcije. Zatim ponovo šalje reset i nakon njega zahtev SET_ADDRESS dodeljujući uređaju adresu kojom će ga ubuduće prozivati. Ovde sam imao nešto problema pošto adresa ne sme istog trenutka da se upiše u UADDR registar već tek nakon sledeće IN transakcije koji je potvrda hostu da smo usvojili adresu. Zatim host šalje nov zahtev po prvi put koristeći novu adresu koju nam je upravo dodelio. To je ponovo zahtev GET_DEVICE_DESCRIPTOR samo što ovaj put host inicijalizuje seriju IN transakcija koje pokupe celokupan deskriptor. Zatim host gleda u to što je dobio i šalje seriju zahteva GET_CONFIGURATION_DESCRIPTOR za svaku konfiguraciju čiji ukupan broj se vidi iz device deskriptora i zahteve GET_STR_DESCRIPTOR za svaki string koji smo ideksirali u deskriptorima. Zatim slede zahtevi specifični za određenu klasu USB uređaja navedenu u deskriptorima, interfejsi i reporti. Za svaku klasu uređaja dalje postoji dokumentacija sa užom specijalizacijom.
Recimo tastatura opiše jedan izveštaj koji se sastoji od četiri bajta gde su prva dva skankod a druga dva stanja raznih flegova...
Zatim host odredi uređaju u kojoj od prijavljenih mogućih konfiguracija će raditi šaljući mu zahtev SET_CONFIGURATION.
Ovim je uređaj prošao kroz niz diskretnih stanja:
*Attached (utaknut)
*Powered (uključen)
*Default (spreman za rad)
*Address (dodeljene adrese)
*Configured (pokrenut da radi u jednoj od svojih konfiguracija)
Pozdrav
[Ovu poruku je menjao barum dana 28.01.2009. u 20:46 GMT+1]
[Ovu poruku je menjao barum dana 29.01.2009. u 20:21 GMT+1]