Mikrokontroler na PC i nazad preko USB-a ?

Pozdrav... mozda nije bas pravi forum ali mi se ucinilio da je najbolje da ovo pitanje postavim ovde...

Elem, zanima me da li neko zna koji se hardveski driver (ili kako vec da ga nazovem) koristi za USB port...

Posto verovatno nisam bio najjasniji da pojasnim... odradio sam jedan poprilicno jednostavan projekat sa Atmelovim mikrokontrolerom AT89C2051 koji izmedju ostalog sluzi i za komunikaciju ovog kontrolera sa PC racunarom... e sada, ta konekcija se odvija preko RS-232 porta i to radi veoma lepo, medjutim ja bih sada hteo to malko da unapredim jer ce mi to trebati za neke druge projekte... dakle hteo bih Serijski port (odnosno MAX232 na plocici) da zamenim USB portom (odnosno nekim drugim elektricnim sklopom na plocici)... e sada... ono sto mene zanima je upravo ta elektronika (i naravno komponente) koje su potrebne da bi se ostvarila komunikacija ovog cipa sa PC racunarom preko USB-a... Ako postoji neka univerzalnta shema za USB sa odredjenim IC kolima/kolom nevezano za ostatak elektronike na plocici (kao sto npr. za serijski port postoji dobri stari MAX232) i to bi me naravno interesovalo...

Sto se tice softvera za PC to nije problem... to cu vec nekako odraditi u .NET-u, ali me najvise interesuje ova elektronika...
Ovo mi nisu prvi koraci u ovoj oblasti (naprotiv) tako da odredjeno iskustvo vec imam, a i veoma dobro poznajem asembler i programiranje ovih mikrokontrolera tako da verujem da mi ni sam softver za njega nece biti veliki problem (mada ne sumnjam da cu i u vezi toga traziti savet jer ipak nisam bas toliko iskusan i spretan sa tim stvarima, ali to je sada nebitno... otom-potom... :) )

Nadam se da ce neko umeti da mi pomogne u vezi elektronike...

Pozdrav i hvala unapred...

---

pozdrav kovach
lepo radi kyocera

ono sto tebi treba je ... FT232 (od FTDI-a)...USB-RS232 konvertor ... imaju predstavnisto u Sloveniji ...chip kosta oko 6Eura + 6E postarina ...

chip dozvoljava da se serijska komunikacija obavi preko usb porta u vidu virtuelnog com porta ... tako da ni software neces morati mnogo da menjas ... posto cisto programiranje usb-a nije ni blizu jednostasvnosti i lakoci serijskog porta.

ft232 je u lqfp32 kucistu ... i uglavnom ga koristimo za chiptuning programatore ...

tctctc... kovače, ti svrneš samo kad ti nešto treba..
ft232bm imaš u rajheltu a nabaviš ga preko recimo monsa.
znači 6,35€ x 1,3 x 1,18 = 9,75€ ovde. u dinarima naravno.

Pozdrav svima..

@guja... pp je poslat... :) ;)

@Codeus, hvala puno... ovo kolo je stvarno jedna interesantna stvarcica, za koju sam se nadao da postoji, ali nisam imao predstavu da je stvarno tako... :)

E sada, malko sam se raspitao na netu, skinuo neke datasheet-ove, drivere i slicne stvarcice i izmedju ostalog sam naisao na jedan poprilicno interesantan PDF sa, cini mi se, upravo stvarcicom koja meni treba... e sada problem je sto mi ova plocica koja je ovde prikazana ne ide bas u glavu... pogotovo ovo napajanje od 5V i 3V... dakle nije mi najjasnije gde ide jedan a gde drugi napon... pokusao sam u glavi da "okrenem" plocice i da ih spojim i neke stvari mi bas nisu jasne... druga stvar... ove komponente sa druge strane... da l' su one obavezne ili sta? Jer koliko ja kapiram ovaj regulator za 3.3V kao i eeprom su poprilicno bitne stvari i nisu neki otpornici i kondenzatori bez kojih se moze.... E da... i jos jedna malo konkretnija stvar... sta mu tu dodje Ferrite Bead, kako to izgelda, kako se montira i sl.... :) Bio bih vam zahvalan (svima naravno) ako biste samo malo mogli da mi pojasnite samu shemu u PDF-u ispod...

www.compsys1.com/support/docs/usbp3.pdf

Sto se tice nabavke ovog kola, tu cu pokusati nekako da se snadjem, ali ako ne uspem, eto mene ponovo sa pitanjima... :)

Hvala puno i pozdrav...

_{[Ovu poruku je menjao kovach dana 15.10.2005. u 15:33 GMT+1]}

---

Microchip proizvodi seriju 18F kontrolera koji nisu skupi i imaju u sebi vec ugradjen UCB modul, ne bi trebalo da su skuplji od desetak E u maloprodaji.
Na sajtu postoje sorsovi u C za njihov kompajler, uradjeni kompletni primeri komunikacije(studentska verzija kompajlera je besplatna ali nema optimizaciju), isto tamo mozes da skines sve drajvere za XP i njihove sors filove.
Pretpostavljam da isto takve mikrokontrolere ima i Atmel jer mikrokontroler + chip koji radi USB komunikaciju kosta vise od samog mikrokontrolera sa ugradjenim USB -om.

Ovde imas sve primere i drajvere
http://www.microchip.com/stell...Full%20Speed%20USB%20Solutions

Ja sam se pre 2-3 godine interesovao za USB protokol pa smo nabavili Cypres-ov razvojni sistem. Onda me posao odvukao na drugu stranu, pa sam pauzirao s'tim, ali sada ponovo imam vremena za projektovanje... Nego, interesuje me nesto. Znam da pri USB komunikaciji kljucnu ulogu igra hand-shaking, odnosno detekcija P&P drajvera i onaj kod kako se vec zvase. Kako sada to funkcionise sa integrisanim usb modulom u samom pic-u?
Pozdrav

---

Nazalost isto sam samo nabavio nekoliko pic18f4550 i za sada nisam isprobao kako to funkcionise.
Pre sam vrlo povrsno pogledao sta microchip nudi i to se koliko sam ja shvatio svodi na:

Human Interface Device (HID) class firmware

gde postoje funkcije u za njihov C kompajler netreba "hand-shaking" obradjuje se komunikacija tipa tastature i miseva koristi se postojeci protocol, radi se o brzinama do 64kb/s

Communication Device Class (CDC) firmware

Emulacija RS-232 preko USB porta koja mene interesuje, postoji njihov drajver koji se instalira i C funkcije napisane za njihov kompajler koje podsecaju na klasicnu komunikaciju preko serijskog porta,radi do brzine do 1 Mb/s

Mass Storage Class Firmware
Radi se o komunikaciji izmedu pc - pic - SD card/ multimedia card MMC


Microchip Custom Driver
Microchip daje gotove dll biblioteke,primer za borland builder C++ i C sorsovi za njihov kompajler.Radi se o "pravoj" USB komunikaciji, znaci ne samo pisanje programa za pic vec i pisanje windows aplikacije("hand-shaking").

Zdravo,

pratim ovu diskusiju pa evo mog malog doprinosa.

Ja pokušavam da oživim USB pomoću PIC18f4550 koga sam montirao na Mikroelektronikin razvojni komplet EasyPIC3 i do sada nisam uspeo da bilo šta dobijem sem gomile grešaka kada Microchip-ov MCHPFSUSB firmware pokušam da prevedem u njihovom C18 kompajleru. Problem je u tome što je sam MCHPFSUSB vrlo složen, iseckan na gomilicu fajlova sa još većom gomilom funkcija tako da, recimo ja nisam još u stanju da sklopim celu sliku šta se dešava i u stvari kako cela stvar funkcioniše. Što je još gore, ceo MCHPFSUSB je, ustvari, pisan za Microchipovu USB razvojnu pločicu (kao i u JUNGO-ov paket za firmware) sa PIC18F4550 ili PIC18F87J50 pa je potrebno promeniti delove koda za svoju pločicu (što ja i dalje ne uspevam - ali ja nisam uopšte reper za upoređivanje; pitanje je koliko je moje znanje iz ove oblasti, zar ne?).
Lično bih voleo da neko ko to zna (recimo drugari iz Mikroelektronike) napišu jedan tekst ili jednu brošuru kako to sve radi jer oni imaju HID primer koji sam ja uspeo da učitam u EasyPIC3 i to radi (ali je neupotrebljivo za praktičnu upotrebu: raspoloživ je samo *hex fajl) ali dalje od toga nisam mrdnuo: gomila ne komentarisanog koda ne može da vas daleko odvede pogotovu ako vam npr. jedna od glavnih funkcija (čini mi se) HID_Enable(...) ne postoji a imate samo gotov *.hex fajl koji možete da uprogramirate u PIC i učitate aplikaciju za PC i onda srećno zurite u ekran kako vam PIC šalje neprekidnu petlju slova A,B,C,D...
Knjiga od Jan Axelson "USB Complete" je od male pomoći jer je (po mom mišljenju) više opisna a kod je uglavnom za običan PIC (bez USB-a) na koji se zakači eksterno USB kolo pa ko hoće može da se zeza sa tim.
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...
Izvinjavam se što je tekst duži nego što je uobičajeno ali, valjda je ovo i moj vapaj za pomoć...
Pozdrav od Pece.

---

Pravno mesto za tvoje probleme:
http://www.mikroe.com/sr/forum/

Info : FT232 ima comet

---

http://www.mikroe.com/forum/

Our users have posted a total of 72883 articles
We have 5681 registered users.

Probaj ovaj link. :)

Pozdrav kolege. Ja sam uspeo da upravljam sa pic18f4550 preko USB porta. Kao drajver koristim HID. PC aplikaciju razvijam u C# a za pic koristim ccs c. U sustini vam nisu potrebne nikakve posebne knjige ako koristite HID drajver. Sve primere mozete naci u example folderu ccs c komapjlera naravno kada ga instalirate. Takodje je moguce pomocu easy HID programcica izgenerisati okvir aplikacija tako da samo dodate kod koji ce da se izvrsava kada posaljete odnosno primite podatke sa USB porta. Ja sam ranije koristio easy hid ali sam prestao zato sto moze da generise okvirne aplikacije samo za vc++6, VB6 i delphi sa strane pc - ja, odnosno pic basic pro sa strane pica. Posto mi vise lezi c sintaksa preso sam na ccs c i za sada sam zadovoljan. Pozdrav

Zdravo svima,

okupiran drugim stvarima zezanje sa pic-om 4550 je stajalo i skupljalo prašinu. Sada imam vremena, pa da se opet vratim temi.
U međuvremenu, uspeo sam da pomoću Jungo-vog paketa napravim HID firmware za pic i da dobijem enumeraciju tj. PC ga lepo vidi i sa njihovim dijagnostičkim programom (izgleda) pošaljem i primim bajtove. Ali, pošto nemam hardverski dibager, ne mogu da pratim šta se dešava u pic-u tako da nisam siguran šta sam dobio.
Drugi problem je što stvarno nisam u stanju da ukapiram gde u pic-ovom firmware-u ja mogu da pišem svoje funkcije, odn. kako da koristim Jungo-ve funkcije koje su oni "dokumentovali" u svom uputstvu (normalno, bez i jedne jedine linije koda kako da to i upotrebite). Ako neko može da pomogne - hvala unapred.
Drugo, postoji jedan interesantan program - "HIDmaker FS". Može se videti na http://www.tracesystemsinc.com/usb_tools.ivnu. Toliko je nahvaljen da je jednostavan da sam skinuo demo verziju da vidim šta je. I izgleda da i jeste jednostavan, samo ima caka: kad dođeš do gerisanja firmware-a za pic i koda za PC, taj deo odradi prazne stranice tj. ne generiše nikakav kod. Jasno, da bi dobio kod i sve ostalo, treba da se učipiš $600!
Jel` neko "koristio" ovaj program? Ako jeste, mogao bi da kaže kako ga koristi i kakve je rezultate dobio.

Pozdrav!

---

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








<sub>[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]</sub>

Hvala Bojane.

Ovo je do sada jedno od najboljih objašnjenja i vrlo cenim tvoj napor, a nadam se i naši drugari sa foruma.
Da li je ovo greška:
Piše: CONFIG PLLDIV = 2 ; 12/3 = 4MHz (96MHz PLL)
Mislim da bi trebalo da stoji: CONFIG PLLDIV = 3 ; 12/3 = 4MHz (96MHz PLL).
Doduše, ceo ovaj proces sam u zadnjih jedno godinu i više dana (sa manjkom slobodnog vremena) dobro proučio tako da sam lako razumeo celu priču. Svejedno, odlično je za one naše drugare koji žele da saznaju proces "enumeracije" (nazovimo ga i "prijavljivanje") USB uređaja.
Pa gde je problem?
Paaaa, ceo taj proces treba napisati u kodu koji treba učitati u PIC i kada se on uključi na USB onda... :-(
Dakle, bez namere da umanjim značaj tvog truda i rada, samo opisivanje nije dovoljno. Ja sam predložio da se jedan primer koji radi (recimo HID) napisan u C-u i Basic-u na strani PIC-a objavi ili frajke ili kao skripta (koja bih ja, recimo, odmah kupio od autora) u kome je do detalja iskomentarisana svaka linija koda, ali na sledeći način:

1. Na početku bloka široko i detaljno objašnjenje šta taj blok treba da uradi, koje promenjljive, funkcije, registre itd. će da koristi, zašto i kako će da budu korišćeni, početna postavljanja, međustanja (ako ih ima i kako utiču) i krajnji rezultat.
2. Pored svake linije koda dati što širi komentar tako da čitalac može da prati proces i da tačno zna šta ta instrukcija radi.
3. Dati sve el. šeme sa komponentama i detaljnim objašnjenjima da bi amateri lako mogli da ih realizuju.
4. Softverski deo na hostu (recimo PC-ju) dati u C++/C# i Basic-u, takođe sa detaljnim objašnjenjima (kao i za PIC stranu).

Jedino tako nešto može da bude od koristi!
Znate, bilo koji kod koji ima jedno dve tri reči pored jedne instrukcije pa onda posle 100 linija koda još jedno dve reči nije ništa. To vam je Jungo-v kod ili Microchip-ov USB stack. To znači nešto autoru ili visokim profesionalcima, ali amaterima tj. nekome ko treba da uči ne vredi ništa. Pogotovu ako želite da to menjate i prilagodite svojim potrebama.

Ali, da nastavim dalje.
Ja sam pokušao nešto da pišem, otprilike ovo:

- aktivirao sam internu USB jedinicu u full-speed modu sa internim pull-up otpornicima. Ovo znam jer PC reaguje na uključenje i isključenje USB kabla,
- (mislim) da sam u odgovarajuće registre upisao koje endpointe da koristim (samo endp0OUT, endp0IN, endp1OUT i endp1IN),
- (valjda) sam postavio i adrese u bafer-descriptoru pripadajućim endpointima.

Interesantno je to što nigde nisam pročitao da posle prvog reseta (ako sam dobro razumeo) host jednom (a najviše) tri puta ispituje stanje SUSPEND... itd. Ovo moram da proučim detaljno. Jer do sada (iz razne literature) sam shvatio da host posle prvog reseta traži DEVICE_DESRIPTOR ali uzima samo prvih osam bajtova i kada ih dobije ponovo pošalje reset a posle njega šalje adresu pa opet traži DEVICE_DESRIPTOR ali ceo itd.
Uz ovu poruku sam zakačio par lepih *.pdf tekstova iz kojih sam dosta naučio. Čak sam i kupio knjigu od Jan Axelson koja mi nije baš nešto pomogla.
Dalje, sem interapta kada dobijem RESET ništa drugo nisam mogao da uhvatim. Da budem iskren, pošto nemam hardverskih mogućnosti da pratim šta se dešava, a i pošto sam pročitao ovaj tvoj tekst, nisam siguran koji RESET sam uhvatio.
Dakle, jasno je da u mom "slučaju" do sada, sem teorije, od prakse nema takoreći ništa. Ali ja ću uporno da nastavim dalje dok ne dobijem ono što hoću .

Pozdrav od Pece.

P.S. A šta je parsiranje? I niko ne reče ništa o HIDmaker-u...

<sub>[Ovu poruku je menjao pp.peca dana 29.01.2009. u 13:26 GMT+1]

[Ovu poruku je menjao pp.peca dana 29.01.2009. u 13:29 GMT+1]

[Ovu poruku je menjao pp.peca dana 29.01.2009. u 13:42 GMT+1]</sub>

---

Da, greška je, treba PLLDIV = 3.
Ispraviću i u postu.




Svoj firmver sam pisao u assembleru. Kod je ooogroman i uobičajeno slabo dokumentovan. Za assembler i C znam da postoje mnogi primeri, recimo oni koje je objavio Leon Heller ili, meni od najveće pomoći, Bradley A. Minch (konkretno http://ece.olin.edu/pe/ece/projects/lab2_18F2455.zip ). Priličnu pomoć sam dobio i na Microchip-ovom forumu.





Nemam ni ja ali mi to nije bio problem jer imam serijsku vezu i u asm kodu imam gomilu PRINTF makroa koji detaljno loguju u Realterm sve što se dešava u programu.




Parsiranje je semantička analiza, tj. proces razlaganja izraza radi utvrđivanja njegovog smisla.





P.S. I ima još jedna greška. Spomenuo sam trostruko pokušavanje suspend moda pre enumeracije ali je to pogrešno. Zapravo to se dešava mnogo kasnije za uređaje koji sebe deklarišu sposobnima za smanjenu potrošnju. Zapravo ja uopšte nisam ni koristio napajanje iz USB-a. Greška je otud što sam posmatrao stare log fajlove koje su generisale redom verzije mog firmvera. Ono što sam video je u stvari bio odgovor na interapte IDLEIF i ACTVIF. Ove interapte generiše USB modul na PIC-u kada protekne 3 milisekundi bez aktivnosti na magistrali i kada se aktivnost ponovo pojavi i nemaju nikakve veze sa namerom hosta da suspenduje uređaj. Izvinjavam se.



_{[Ovu poruku je menjao barum dana 29.01.2009. u 23:15 GMT+1]}

O.K.

Možda malo objašnjenje oko drfinisanja (pokušao sam sa "anonimous" strukturom ali mi nešto "ne ide"), čitanja i postavljanja UOWN bita - tu sam malo konfuzan.

Nastavljamo dalje. Seme, dobrodošla bi pomoć ...

---

Poštovani, poruka primljena ali je malo nejasna. D*finisanje čega?

Što se tiče UOWN, to je semafor bit. Vrednost određuje da li naš program može bezbedno da menja vrednosti u bafer deskriptoru i samom baferu.


Kada je vrednost UOWN bita 1 tada SIE (USB Serial Interface Engine) aktivno koristi bafer deskriptor i njime pointovani bafer. Vrednosti koje se tada mogu pročitati niti su određenog značenja niti konačne a pisanje po zauzetom baferu ili njegovom deskriptoru može potpuno da zbuni periferiju.

Kada je vrednost UOWN bita 0 tada jezgro aktivno koristi bafer deskriptor i njime pokazani bafer. Tada periferija ne pristupa baferu niti zbog čitanja niti zbog pisanja i vrednosti su konačne i imaju značenje. Značenje zavisi od konteksta u kom trenutno upotrebljavamo bafer:
- Prvi kontekst je da postavljamo vrednosti bafer deskriptora (i bafera ako šaljemo podatke) da bi smo ih prosledili periferiji da može da obavi transakciju. Ako šaljemo podatke hostu (IN transakcija) treba i napuniti bafer podacima i na kraju upaliti bit UOWN. Značenje za ovaj kontekst predstavljeno je u REGISTER 17-5
- Drugi kontekst je da smo obavešteni o obavljenoj transakciji (TRNIF i USTAT) i želimo da vidimo šta je bilo. Značenje karakteristično za ovaj kontekst navedeno je u REGISTER 17-6. Kada završimo opsluživane transakcije ponovo menjamo kontekst u kom gledamo na ove lokacije i podešavamo za sledeću transakciju i palimo UOWN bit kada smo sve namestili.

Dakle firmware koji izvršava jezgro treba jedino da pristupa kada je nula i da na kraju promeni u jedinicu.
Periferija (SIE) pristupa samo kada je jedinica i kada uspešno završi transakciju sama promeni u nulu.

Prvo, hvala na nesebičnoj pomoći.
Drugo, štamparska greška. Izvinjavam se, koristim radio-tastaturu pa i ne primetim kad preskoči slovo (ili ja napravim grešku ).
Hteo sam da kažem da sam pokušao da napravim "bit-addressable anonymous structure" u unijama da bih lakše kontrolisao UOWN-bit i ostale bitove u deskriptorima. Sad` dal` bi to pomoglo ili ne, drugo je pitanje.
Objašnjenje oko UOWN-bita: kratko i jasno.
Pošto uporno čitam sve do čega dođem na internetu, verovatno polako počinjem da slažem mozaik šta se dešava. Pa iz toga kratko pitanje: da li treba da pravim interapt funkcije i da im prilazim preko `interrupt low/high` vektora da bih proverio koji interapt je izvršen (posle javljanja USBIF interapta).
Ustvari, nije mi jasno da li USB interapti uopšte idu preko lokacija 0x08 i 0x18 jer sam pisao nešto za hvatanje tog interapta i ništa nisam dobio (recimo, kad se javi USB interapt program skoči na 0x08 (ili na 0x18 kad se ništa nije desilo na 0x08 ), proveri da li je USBIF==1 pa ako jeste, upali LED recimo na PORTBbits.RB0)?
Pretpostavljam da sam u pravu kada mislim i sledeće: USBIF ja moram da obrišem a da posle proveravanja flegova ko je okinuo interapt isti odmah obrišem i uđem u funkciju za obrađivanje tog interapta koju ja treba da napišem.
Ispravite me ako grešim.
I za sad dosta. Korak po korak.
Pozdrav.



_{[Ovu poruku je menjao pp.peca dana 02.02.2009. u 13:37 GMT+1]}

---

Unije mogu mnogo da pomognu, na primer za ovaj bafer deskriptor http://eris.liralab.it/iCub/do.../usbmmap_8h-source.html#l00080

Da, bolje preko interapta ali nije moranje ako mikrokontroler ne treba radi ništa osim toga. Da bi se pojavio USBIF potrebno je da bar neki ulaz bude omogućen, vidi FIGURE 17-8. Dakle ako hoćeš da se USBIF desi kada imaš URSTIF potrebno je da go omogućiš uključivanjem bita URSTIE. Da bi i ostali događaji menjali USBIF treba uključiti njihove Enable parnjake.

A da bi se dobio interrupt pored URSTIE potrebno je još uključiti USBIE, PEIE i GIE. Mislim da je bolje za početak isključiti prioritete (IPEN=0) i dobijati interapte samo na adresi 0x008. Vidi FIGURE 9-1.

Kada se obradi događaj potrebno je resetovati Flag bit za taj događaj i USBIF.

Primer za pisanje interrupt-a u C18 trebalo bi da se nalazi gde je MCC18 instaliran, npr.
C:\MCC18\example\Interrupt\main.c

_{[Ovu poruku je menjao barum dana 02.02.2009. u 16:14 GMT+1]}

Da... kao i do sada: kratko i jasno.

Anonimne strukture u unijama su "kilavo" objašnjene u C18 help-u a onaj MCHPUSB... ili već kako se zove (koji je neko na nekom forumu nazvao "Mikročipove špagete") nisam ni čitao mnogo: dig`o sam ruke jer sa onoliko mnogo #def... i preturanja po fajlovima gde je šta definisano i šta bi trebalo da znači ... na kraju se pogubiš. Doduše, ja ih razumem: taj galimatijas bi trebalo da bude neko opšte rešenje pa ti "samo uzmeš" šta ti treba i ono radi... (verovatno).
Sada sam malo pažljivije posmatrao njihovu strukturu (hvala na datom linku!) pa predpostavljam da moje strukture nisu radile jer nisam definisao tipove podataka koji će u njima da se nalaze (byte, word...).
O.K. sada je vreme za malo teškog posla: probaću da do sada stečeno znanje iskoristim da vidim šta ću da dobijem.
Javiću se na ovoj istoj niti kada dobijem nešto (verovatno sledeći problem ). Baci(te) pogled s`vremena na vreme!
Pozdrav od Pece.

---