Szia!
Azt lenne jó tudni, hogy hogyan is zajlik a kommunikáció a host és az egység között. Milyen adatcsomagokat küldözgetnek egymásnak, azok hogyan épülnek fel, milyen állapotok vannak, stb...

Mindkét irány érdekel. A PIC24FJ vezérlők elvileg tudják a Host és Device módot is.

Host-al nem foglalkoztam még. Egyébként engem is érdekelne mi folyik ott, rengeteget keresgéltem, olvastam utána, de gyakorlatilag egy könyvet kéne megérteni(ez az USB_Comlete pdf is 593 oldalas!!!). Úgy döntöttem, hogy inkább használom, mint megértem a mély működését. Neked is inkább azt ajánlom, hogy keress a microchip oldalán példákat, demokat, és abból indulj ki. Ez sem könnyű feladat, mert a microchippék tudnak programot bonyolítani!

Az I2C és SPI buszokhoz van idődiagram, az USB-hez miért nem közölnek?

"Úgy döntöttem, hogy inkább használom, mint megértem a mély működését."

Na... ez az ami nekem nem megy.
Én csak akkor tudok valamit használni, ha előtte megértem a működés mikéntjét.

Nem az idődiagram a kérdéses, az benne van az adatlapokban. A probléma a protokolokkal, módokkal van. Letöltötted az USB-s doksit? Minden benne van elvileg, csak győzd megérteni!

A MAL (Microchip Application Library) tele van mintapéldákkal. Van USB host egér és billentyűzet, valamint USB Device egér, billentyűzet, joystick és digitalizáló. Ezek mind HID protokollal működnek.

Azért mert nem férne ki. Az I2C és SPI protokolhoz képest agyságrenddel több információ pattog ide-oda mire a legegyszerűbb enumeráció lezajlik. Ráadásul az üzenetcsomagokból lehet ezerféle. Ki győzné azt mind lerajzolni vagy végignézni?

watt:
Igen. Az usb.org oldaláról leszedtem egy kb. 650 oldalas szörnyűséget. Azt hiszem ez túl sok nekem így egyszerre.
Még össze kell vetnem az ott olvasott dolgokat a Microchipes adatlapokkal, hogy milyen szinten kell belemerülnöm a kommunikációba.

icserny:
A mintapéldákat már én is néztem, de az a gondom, hogy framework-öt használnak, nem pedig alacsony-szintű hozzáféréseket, így nem látszik a lényeg. Azért újra átnézem őket, hátha találok használható dolgot.
Én PIC24FJ-vel assembly nyelven szeretném megvalósítani a dolgot, saját rutinokkal, ha lehet.

A framework-nek is ott a forrása, nézz bele!

Mellesleg egy hardveres USB protokoll-analizátor nélkül ne nagyon ábrándozz arról, hogy belemászol az USB kommunikáció lelkivilágába. Ha nem működik a programod, honnan tudod majd, hogy mi a baj?

Rendben! Belekukkantok.

Azért az USB protokoll analizátorok fejlesztőinek sem állt a rendelkezésükre USB protokoll analizátor, legfejjebb az USB dokumentációk és logikai analizátor, ill. oszcilloszkóp.

Egyébként te hogy állsz ezzel a témával? Nem készülsz erről is cikket írni? Lenne rá igény.
(A részemről biztosan... )

Az USB előtt is voltak digitális oszcilloszkópok, mintavevők és logikai analizátorok. Nem a "protokoll analizátor" a lényeg, hanem az, hogy kellenek olyan hardvereszközök, amelyekkel ellenőrizhető, hogy mi folyik a buszon és mit csinál rosszul (vagy jól, de rosszkor!) a program.
Sehogy. Se eszközöm, se időm, se kedvem...

Azt már biztosan látom, hogy lebecsülöd ennek a témakörnek a bonyolultságát. Nem ijesztgetni akarlak, de majd rá fogsz jönni, hogy ez nem embernek való(nem 1 embernek...).

Dehogy becsülöm le.
Szerintem az USB-t nem is emberek csinálták, hanem valami földönkívüli szuperintelligens lények.

Nem lehetetlen a dolog. Szilvanak és nekem kb 2 hónap ejszakazasok árán sikerült ezt megtanulnunk (de valóban szinte minden nap hajnal 3-ig nyomtuk és közben folyamatosan kommunikaltunk msn-én hogy ki mit fedezett fel. A Micrichip nagyon alul dokumentálta a SIE működését.

USB protokoll analizator van szoftveres is, azt mindenképp kell használni. Icserny szerintem inkább arra gondolhatott, hogy ha te szeretnél host controllert fejleszteni, vagy ha SIE-t, akkor kell a hardveres.

"ha te szeretnél host controllert fejleszteni, vagy ha SIE-t"

Isten ments!
Nekem tökéletesen megfelel a PIC24FJ sajátja is.
Mint azt korábban írtam; kizárólag HID eszközöket (billentyűzet, egér, játékvezérlő) akarok kötni a mikrovezérlőhöz, majd pedig HID eszközt készíteni mikrovezérlővel, amit PC-hez kötök.
A kérdés az, hogy mi az amit a SIE elvégez autómatikusan, és mi az amit nekem kell szoftveresen.
A fő problémák:
- Hogyan érzékeljük az egység csatlakoztatását?
- Hogyan állapítjuk meg hogy mit dugtunk rá?
- Milyen tulajdonságai vannak az egységnek?
- Mik azok a leíróállományok, és mire használjuk?
- Hogyan konfiguráljuk?
- Hogyan történik az adatátvitel, ki kezdeményez?
- Hogyan érzékeljük az egység eltávolítását?
Sorolhatnám még a felmerült kérdéseket.
(Ugyan már kezd egyik-másik körvonalazódni, de még igencsak messze vagyok a megértéstől.)

Ha van konkrét kérdésed Host ügyben szívesen segítek. Így hogy időzítés meg hasonblók kicsit bővebb témakör egypár fórum hozzászólásnál. Foglalkoztam már a PIC-es framework-el is, bár mostanában másik processzorokat hasznáok USB célra. Nem kell feltétlenül USB analizátor egy HID-es fejlesztéshez, de mindenképpen jó sok olvasnivalón kell átrágni magad, ha tényleg szeretnéd tudni mit csinálsz. Amiket én javaslok kezdésnek.

USB in a nutshell (neten megtalálod)
USB made it simple (asszem ez a neve)
USB complete 3rd edition
USB design by example
USB 2.0 Specification
HID Specification

Ezen kívül először érdemes egy device-ot írnod, és utána a Host oldalba belefogni. Itt a hobbielektronikán is találsz cikkeket (tőlem is), amin el lehet indulni, bár azóta sokat változott a framework a PIC-ecben.

Ha a kérdéseid a host-ra vonatkoznak általanosságban a válasz:

1) Amikor a host-ra rádugod az usb kábelt akkor az eszközben lévő felhúzó ellenállás miatt áram fog folyni, így érzékeli a host a csatlakozást.
2)Enumerációnak hívják ami során a host címet oszt ki az eszköznek, kiolvassa a descriptorokat és ebből tudja mivel áll szemben
3)Ezt nem igazán értem
4)A descriptorok azok, és ezzel szerez a host tudomást az eszköz tulajdonságairól
5)Adatlap biztos tárgyalja
6)A host a buszon a master 1ms (vagy 0,125)ms intervallumos frame-kben folyik a kommunikáció, transferekből és tranzakciókból és azon belül packetekből felépítve, az adott eszköznek és átvitelnek megfelelő formában. Mindig a Host kezdeményez.
7) Az egység eltávolítását az 1-ből már magad is megfejted.

Szia!
Az általad felsorolt irományokból négyet már megnéztem ill. letöltöttem. Kell egy "kevés" idő mire átrágom magam rajtuk.

A Frameworkkel kapcsolatbam:
A C-nyelvhez nem értek és nem is akarok. Másrészt nem szeretek mások által megírt rutinokat használni, amik tudja fene hogy működnek.

Élek a felajánlással, úgyhogy meg is ragadom az alkalmat és kérdezek:
Nézzünk egy konkrét példát! Van egy USB-s egerünk.
- Milyen leíróállományokat kell tartalmaznia?
- Azok mire szolgálnak pontosan?
- Hogyan kapok információt a gombok állapotáról és az elmozdulásról?

Köszi a választ előre is!

Az a helyzet hogy C nyelv nélkül elég lehetetlen küldetés. Bár assemblyben elvileg mindent meg lehet írni amit C-ben, de egy ilyen bonyolultságú dolgot százszor nehezebb. Ráadásul már a processzorokat is kb úgy tervezik hogy C-ben íródnak rá a programok. Assemblyben létezik egynéhány usb stack megvalósítás, de többnyire régi procikra, és nem túl megbízhatóak. Ha ilyesmivel szeretnél foglalkozni, elkerülhetetlen a C.

Egy egérnek is a szokásos descriptorok kellenek, device, configuration, interface, endpoint. Mivel HID classba tartozik, ezért van neki HID class descriptora is, ezen kívül hid report descriptora. Az hogy ezek mire szolgálnak elég hosszú téma, szintén nem elég keret neki egy fórum hozzászólás. Ezekben a host és az oprendszer számára vannak infók, minden lényeges tulajdonságról (gyártó, fogyasztás, működés stb...)

A gombok és az elmozdulás úgynevezett report-okban jön a host felé. Azt hogy ez a report hogy néz ki, hány van belőle, hogyan jön, melyik bitje és bájtja pontosan mit jelent, ezt a HID report descriptor mondja meg. Egy egér esetén egy elméleti példában mondjuk a gomb lenyomások lehetnek egy bájtban és az egyes bitjei mondják meg hogy mi van lenyomva vagy felengedve. A következő bájt lehet az x koordináta, aztán az y. Amint írtam ez a felépítés a report descriptorból derül ki. Vannak olyan esetek amikor ez némileg egységes (boot protocol), de nem feltétlen az mert rengeteg féle HID eszköz képzelhető el, billentyűk, touch vezérlők, pozicionáló eszközök stb...

Köszi a választ!
Lehetetlen küldetés??? Akkor vállalom!
A C nyelvre úgysem tud engem senki rábeszélni, még ha kést szorítanak a torkomhoz, akkor sem.
Azt hiszem egy kicsit félreteszem az USB témát, amíg befejezem a jelenlegi munkáimat, s majd azután teljes gőzzel belevetem magam. (Ha addigra nem megy el tőle a kedvem... )
(Találtam assembly nyelvű példát is, - igaz csak egységre - úgyhogy majd nekilátok megfejteni.)

Hy all! Szeretnék egy égetőt építeni pic16f84 hez, lehetőleg usb porthoz. Ha nincs olyan azon gondolkoztam hogy lpt is jó lenne de akkor vennék vagy építenék hozzá egy usb átalakítót. Tudna valaki segíteni?

LPT-s és USB-s égetőkre (az utóbbihoz is kell az előbbi...) is találsz példákat a Kapcsolások/PIC szekcióban.

USB átalakítóhoz nincs kapcsolás. Olyan működő megoldás van (PICkit2), amiben mikrovezérlő is van, és az direktben az USB-re kapcsolódik. Csak így korrekt az időzítés és így elfogadható sebességű a programozás.

Javaslom, hogy az alábbi témaköröket nézegesd, további kérdéseideat azokban tedd fel:
- WPB égetőszoftver fejlesztése/tesztelése
- PICKit2 klón építése

A "Hi" pontos i-vel van!

Sziasztok!

Annak van valami különösebb oka, hogy MMC/SD kártyát és USB portot PICen ugyanazokra a lábakra szokták bekötni? Mi van, ha én mindkettőt szeretnék csatolni egy PIChez? Sebességbeli követelmények nincsenek, 1024 byte/másodperc írási sebesség már OK, mind az olvasás, mind pedig az usb küldés sebessége legyen valamivel több, emellett szükségem lesz egy interrupt lábra, opcionálisan egy LCD ha még belefér (ha így belefér, az is jó)

Az SD kártyát az MSSP portra,az USB-t pedig az USB portra célszerű bekötni, mert ott van hozzá hardver támogatás. Ezek természetesen nem azonos lábak.

Az SPI és I2C eszközöket kell azonos lábakra kötni (lehet, hogy ezzel kevered?), mivel ugyanaz az MSSP portkezeli a kétféle szinkron soros perifériát. Ha mégis egyszerre kell mindkettő, akkor olyan mikrovezérlőt kell választani, amiben két MSSP port is van (PIC18F45J10), vagy külön eszközként kezeli az SPI és I2C illesztőt (PIC24, dsPIC33).

Szia! Köszi a választ tényleg elsiklottam bizonyos részletek felett, azonban ha jól látom akkor ezzel a lábkiosztással megoldható a dolog (PIC18F4550):
USB: VUSB(18) RC4/D- (23) RC5/D+
MMC/SD: RB0/SDI/SDA (33) RC7/SDO (26) RA5/SS (7) RB1/SCK/SCL (34)
interrupt: INT2 (35)
lcd: meglátjuk
Ha jól látom ebben 2kb memória van, abszolút vállalható. Nincs amúgy valahol összegzőtáblázat az egyes típusok adatairól (gyártják-e még, órajel, portok, tokozás, memória méret, csere lehetőség (más típusú PICre), stb)?

Sziasztok!

PIC32MX460-al (mint Device) szeretnék nagyobb mennyiségű adatot (kb 8kB) átküldeni PC-re a lehető legrövidebb idő alatt.
Korább már használtam USB-t 18F4550-el custom device class-os bulk módban, de csak pár bájtos csomagokra. Elsősorban azt szeretném megkérdezni, hogy polling-olást meg lehet-e állítani valahogy az adott eszköznél? Mert ugye átküldök mondjuk 64 bájtot, de utána relatíve elég sokat kell várni, hogy az eszköz újabb csomagot küldhessen, és ezzel megy el a legtöbb idő (ha jól vettem észre). Vagy van-e valamilyen mód az átvitel gyorsítására?

Köszönöm.

Bulk üzemmódban a gyors küldés titka az, hogy több végpontot kell használni, hogy egy időszeleten belül több csomagot is lehessen küldeni. A Microchip fórumán lehet olvasni ilyesmiről, én nem foglalkoztam vele.

Hali!
CDC-nél mekkora volt a sebesség?
HID-nél 64kByte/sec is lehet a sebesség, és szerintem egyszerűbb mint a CDC.