Fórum témák
» Több friss téma |
Fórum » PIC - USB - PC projekt
Közbe megint bírtam egy kis időt szakítani a témára, hozzáraktam még egy pár LED-et, és mostmár zenére villognak, csakhogy USB-ről (VU meter tulajdonképp)
 Viszont egyszerre nem akar normálisan fogadni a PC-től két adatot, a ReceivedDataBuffer 0. és 1. bájtjai keverednek egymással, akárhol hajtom végre a "HIDRxPacket(HID_EP,(BYTE*)&ReceivedDataBuffer,64)" függvényt (vagyis USBOutHandle = HIDRxPacket(HID_EP,(BYTE*)&ReceivedDataBuffer,64) ). De majd hétvégén kiderítem. szerk.: a ReceivedDataBuffer tömb 0. eleme ugye a LED Toggle, azt meghagytam rajta és ugye az kavarodik be... 
Szia Watt!
Nézegettem a firmware mellé mellékelt leírást(igaz spanyol), de közben rájöttem, hogy Vendor ID és a Product ID nincs megadva a programban és gondolom ezért nem kommunikál a géppel. Le van írva hogy adjam meg, de mindig hibát ír ki és nem programozza fel a PIC-et. A komplett leírást megtalálod Bővebben: Link oldalon. Megépítettem és a régi firmware-val jól működött. Próbálkozom addig is hátha rájövök(egyszer úgy is meg kéne tanulni!). Köszi szépen.
Hello!
Tulajdonképpen az hogy VID-et és a PID-et miként kell megadni(bocs nem túl értelmes megfogalmazásért). Szabad fordításban így néz ki amit ők írtak: -------------------------------------------------- -------------------- Állítsa be a VID és PID a firmware -------------------------------------------------- -------------------- Abban az időben a berakodás a firmware, hajtsa végre a következő lépések: 1. Nyissuk meg az alkalmazást, és válassza ki a fájlt WinPIC800. HEX firmware. 2. A lapon az EEPROM (Data), írja az első 4 kódot byte a Vendor ID és a Product ID. 3. Írja be a firmware a PIC. -------------------------------------------------- -------------------- Állítsa be a VID és PID a firmware -------------------------------------------------- -------------------- Miután programozott a firmware a VID és PID be kell állítani a kódok alkalmazásához. 1. Nyissuk meg az alkalmazást, és válassza az Általános Beállítások fülre. 2. A "VID-PID", írja ugyanazt a 4 számok programozni a PIC. 3. Indítsd újra a kijelző XR, és alkalmazás. -------------------------------------------------- --------------------
A leírás szerint programozás előtt be kell írni az EEPROM-ba szánt adatsor elejére a VID/PID azonosítót.
Saját használatra javaslom valamelyik Microchip demóprogram azonosítóját. (Terjesztéshez venni/kérni kell saját azonosítót).
Az EEPROM elejére tehát ezt írd: D8 04 3F 00
Ez nem 'szabad forditas', hanem 'Google forditas' - de azert lehet erteni...
Szia!
Igazából az nem volt világos hogy a kiválasztott VIP/PID azonosítókat hogyan váltom át(biztos alap dolog, de már olyan rég tanultam és egyáltalán nem ebben dolgozom). Köszi szépen.
Jól sejtem hogy a PC oldali programban egy helyen kell megadni a tömb elemeit (mármint ha többet akarunk kiküldeni), és utána kiküldeni a WriteSomeData
Tehát ha mondjuk két elemet akarunk kiküldeni akkor:
PIC oldalon pedig:
Már 2 hete csak ezzel kínlódok hogy nem akar menni, valamiért összekeverednek a küldött adatok szerk.: vagyis a "Toggle LED" elég sebesen villog, vagy néhány*100Hz-el, és a PC felé küldött adat sebessége is kb ennyire gyorsul fel valamiért.
A HID mindig 64bájtot fog elküldeni, a kezdő címet kell megadni, ahol az adatok kezdődnek. A BufferOut(0) ebben a formában a saját címét adja át a HID függvénynek, így a következő 63 bájt is ki fog menni. Nem tudom, hogy pascal-ban szükséges-e a @ jel, mert a VB-ben nem...
Kell a @ jel, mert itt delphiben (meg pascalban is) ha csak simán a tömböt írom oda, akkor azt tömbként is veszi, oda pedig a tömb címe kell, vagyis valami pointer féleség, és ezért kell a @ jel.
De nem értem hogy ha több elemet adok meg, akkor miért gubancolódnak össze.
Nem értem, hogy mit értesz az alatt, hogy több elemet adsz meg? Nem lehet megadni az elemek számát, az mindig 64, ha akarod, ha nem. Bármi van a megadott címtől fogva, azt elküldi.
Persze, ez világos, viszont ha mondjuk a 3. elemnek is adok értéket:
 Most megnézem mi történik, ha a PIC-ben nem használom föl a "ReceivedDataBuffer[1]"-t.
Azt hiszem meg van hol a baj. A főciklusban (mármint a PIC-en) akkor is kell nézni hogy használatban van-e az USB (IDRxHandleBusy), amikor a lekért tömb egy elemét nézzük.
Hopp, meg PC oldalon is volt egy kis hiba, de sikerült rájönni.
Sziasztok!
A helyzet a következő: PIC32MX795F512L-el próbálkozunk USB kapcsolatot belőni. Az alapokkal nincs is gond, bekötés stimmel (Explorer16 board-ról koppintva), sima Device-ként, bulk transfer-el sikerült is belőni, driver a Michrochip honlapról. Namost a gond csak az, hogy nekünk legalább 1MByte/sec sebesség kellene. Ezt elvileg meg lehet valósítani "isochronous transfer" adatküldési mechanizmussal, ehhez azonban nincs driver. Tehát a kérdés az, hogy: - bulkosan be lehet-e lőni a kívánt sebességet? VAGY - hogy lehet isochronous transfer-t lekezelő drivert szerezni/csinálni? hátha valaki próbálkozott már... köszönök bármilyen ötletet! Adam
Az USB Device - WinUSB - High Bandwidth Demo-t nézd meg. Úgy látom, hogy ehhez van PIC32 mintaprojekt is.
Szia!
Köszi szépen, ezek szerint lehetséges a dolog.  Annyi kérdés merült fel bennem, hogy ezt ellenkező irányba kéne reprodukálni (tehát a PIC küld 64000 byte-t), viszont az ottani parancsok ezt nem engedik nekem. A demo amit ajánlottál csak úgy van megirva hogy egyedül a gép küld. Néztem a gép oldali programot, ott egy paranccsal kiküldi a 64000byte-t, viszont a PIC-nek maximum 64 byte-s a buffere. Emiatt eléggé érdekesen is fogadja az adatot. Adam
Pont itt akadtam el én is. Hiába tudna gyorsabb sebességet, a buffer behatárolja az egy csomagban elküldött bájtokat, azaz 1000x64/sec, az 64KByte/sec. Nekem lenne 512bájt pufferem is, de nem látom át, hogyan lehetne rávenni a stack-et, hogy ezzel dolgozzon. A PC oldali driverről nem is beszélve... Most tesztelek egy alkalmazást, amiből ki fog derülni, hogy tud-e 64K-nál többet a CDC, miután ott 255 adatot lehet kivinni egy paranccsal. Persze nem fűzök sok reményt a 64bájtos puffer miatt, pedig a CDC-re is 1MByte sebességet írnak az adatlapjában.
Hello!
Hát elvileg a bulk transfernél bár 64 byte-s a buffer egy ms alatt (ha a bus teljesen szabad) 19 ilyet tud elküldeni full speed-ben, úgy jön össze az 1MB/s. Már csak az kérdés, hogy pic oldalról ezt hogyan kell kezelni, de valahogy biztos meg lehet oldani. Valószínűleg a CDC is valami hasonló módon oldja meg, de arról még nem sokat tudok.
Azt kéne tudni, hogy a puffert hogyan kezeli a program. Lehet, hogy dinamikus puffer, nem várja meg míg tele lesz, hanem küldi, és csak akkor töltődik, ha torlódás van. Elég kevés az infó, már ami érthető is...
A másik Winusb-s demóprogramból (USB Device - WinUSB - Generic Driver Demo) kiderül, hogy hogyan lehet PIC-ből a PC-be küldeni:
The endpoint was not "busy", therefore it is safe to write to the buffer and arm the endpoint. The USBGenWrite() function call "arms" the endpoint (and makes the handle indicate the endpoint is busy). Once armed, the data will be automatically sent to the host (in hardware by the SIE) the next time the host polls the endpoint. Once the data is successfully sent, the handle (in this case USBGenericInHandle will indicate the the endpoint is no longer busy.
Tehát a fentiek értelmében minden USBGenWrite() hívás adatátvitelt generál, s rajtad áll, hogy teleírod a 64 bájtos buffert, vagy sem.
Én még ott ragadtam le, hogy az USB Host pollingja 1ms-es. A GenericDriver képes ettől függetlenül átvitelt generálni? Azaz kisebb mint 1ms-es ütemben adatátvitelt bonyolítani?
Én nem értek hozzá, de úgy sejtem, hogy bulk módban ha a host adatot akar kapni, akkor IN tranzakciót indít, s ha iparkodik, akkor egy keretben akár többször is megteheti.
Az 1 ms-onkénti lekérdezés a HID módnál van.
Az a baj, hogy én sem értek hozzá eléggé, én is csak gondolkodom.
Ha jól tudom itt is, mint más master-slave szervezésnél, a host indíthat kommunikációt, a slave csak a kérésre válaszolhat. Ezért valamilyen pollingra szükség van. Én úgy tudom, hogy a CDC az 1MByte/sec-et úgy tudja, hogy 1024 bájtos lehet a csomag mérete. De lehet, hogy ez téves infó. Ha 64bájtos egy csomag, akkor sokkal gyorsabban kell pollingolnia a host-nak, amit nem nagyon tudok elképzelni, de ki nem zárható. Az egy, amit el tudok képzelni 1ms-en belül az, hogy a forgalom nem egy 64bájtos csomagban merül ki, hanem tolja kifelé a bájtokat folyamatosan, amíg ideje van egy kereten belül. Ehhez viszont pufferre sem lenne szükség, elég lenne egyenesen a memóriáról kitenni az adatot egy "USB Tx" regiszterbe, mint az UASART-nál. Nemrég beszéltünk róla, hogy milyen gáz, ha valaki csak használ valamit, miközben nem érti a működését. No most pont ebben a cipőben járok és eléggé sajog a lábam! Jó lenne valami emészthető irodalom, legjobb lenne magyar, de bármi is legyen, csak áttekinthető lenne!
Igen, minden tranzakciót a host indít. De bulk üzemmódban nem fix idejű, periodikus pollingban kell gondolkodni, hanem "rendszertelelen" tranzakciókban, melyeket akkor indít a host, amikor igénye van rá, és talál szabad sávszélességet az adott eszköz számára.
Itt találtam egy jónak tűnő előadásvázlatot.
Ez jó anyag, köszi! Világosodik a sok mód közötti eltérés...
Hello!
Sikerült a PIC-től PC felé is elérni az 1Mbyte/s-es sebességet bulkos transferrel, felhasználva a high bandwidth demo-t. Ezen a linken: Bővebben: Link nagyjából le van irva miket kell változtatni. Ezután a fordítók még adnak ki hibaüzenet, ezek főleg abból adódnak hogy nem mindenhol irta át a buffer illetve paracsneveket. Emellett ha vkinek szüksége van rá fel tudom tölteni a nekem működő programokat vagy emailben elküldeni, jelezzétek ha szükséges. Adam
Szia!
Én szívesen megnézném tanulás céljából ( a címem publikus )! Steve
Hello!
Apró PC gondjaim vannak most,de holnap elküldöm őket. Adam |
Bejelentkezés
Hirdetés |
