Fórum témák
» Több friss téma |
Fórum » PIC - USB - PC projekt
Fel raktam a "JVCL338CompleteJCL201-Build3449\jvcl\" mappában lévő cuccot az install-al, de nem tudom tovább hogy haladjak.
De a delphiben is jól kéne működnie, ennek a DLL-nek csak mégse.  Ez most kifogott rajtam. 
Szia!
Csatolom a módosított Delphi programot. Próbáld ki! Remélem nálad is működik!
Hali!
Igen, köszönöm szépen! Így már tökéletesen működik, tegnap este nézegettem a neten delphi forrásokat még, kezdtem kapirzsgálni a lényeget, de azt még mindig nem értem hogy ez mitől hívódik meg: Idézet: Vagyis mi hívja meg? „TForm1.HID_Event_Handle”
A Form üzenet kezelője adja át ennek a metódusnak, ha
a message utáni (procedure HID_Event_Handle(Var Uzenet : TMessage); Message WM_HID_EVENT  üzenetet kap.
Mármint ha a az USB-n kapja az üzenetet? És ezt az üzenetet meg a DLL-en keresztül látja a Form üzenet kezelője?
Valahogy így. Ezt úgy hívják, hogy eseményvezérelt objektum. A dll programja megszakítást okoz, amit a megfelelő szubrutin hívásával kezel le. Lehet, hogy nem pontosan fogalmaztam, de a lényeg ennyi. Az objektum orientált nyelveknél más módon nem is nagyon működne a dolog, mivel nem várakozhatsz egy ciklusban egy ritkán bekövetkező eseményre. Igaz van a DoEvent, de ez sem gyógyír mindenre. Szóval a kommunikációs és más eseményérzékeny rutinok(objektumok) szinte mind eseményvezéreltek. Nem kell velük külön foglalkozni, csak lekezelni az eseményt.
Értem, köszi a leírást! Mégis csak jó ez a Delphi.
Sziasztok!
Elsősorban olyanhoz intézném a kérdésem, akinek sikerült létrehoznia nagy-sebességű USB kommunikációt PC és PIC között. A helyzet a következő: PIC18F4550 - PC [Win7] fordító: CCS (kód lentebb) HID eszközként felkonfigurálva megy az adatküldés mindkét irányban DE: az adatátviteli sebesség lassú Konkrétan 16[ms]-enként tudunk küldeni valahány byteot(1-64) PICről PCre, ami még USB 1.1-hez is röhely, mert az elvileg 12Mbit/s-re képes. Egyrészt az lenne a kérésem, hogy ha valakinek sikerült ennél nagyobb sebességet elérni, akkor legyen kedves közzé tenni az általa használt kódot, másrészt ha valakinek bármilyen tapasztalata/ötlete van, akkor azt szívesen fogadom. A kódot kipróbáltuk egy Michrochip Explorer16 developement boardon is és ugyanezt tapasztaltuk. Ezen feltételezem a hardver jól van kiépítve, de ha valaki tud a bekötésre vontakozóan mondani valamit, az is hasznos lehet. Olyanokra gondolok, mint: sense pin használata (nekünk nincs bekötve) USB csati 5[V]os lábának összekötése valamivel esetleg (bár ez max a PIC meghajtására kellene hogy kelljen) az USB csati háza földelve van e a penelen? (mivel az árnyékolás földelve van PC oldalon az ottani csatlakonón keresztül, ezt külön nem kellene megtenni, illetve a csatinak van külön föld lába (amit bekötöttünk), ezért gondolom ez sem kell) A kódot pedig a CCS mintakódjából szedtük. tehát ami most fut: ///////////////////////////////////////////////////////////////////////////////////////////////// //ALAPVETO BEALLITASOK //kontroller: #zero_ram // RAM torles #include <18F4550.h> // PIC h-fileja #fuses HSPLL,NOWDT,NOPROTECT,NOLVP,BROWNOUT,NOPUT,NODEBUG,USBDIV,PLL5,CPUDIV3,VREGEN // HighSpeed kristaly PLL szorzoval, nincs WatchDogTimer, NoProtect, NoLowVoltageProgramming, // reset taphibara, inditasi idozito kikapcsolva, NoDebug, USB orajel osztoja, PLL 5 os oszto, // CPU orajel oszto, USB Voltage Regulator (VREGEN) #use delay(clock=24000000) // 24 MHz CPU orajel #include // 32 bites-re atallitva #TYPE LONG=32 #TYPE UNSIGNED //USB: #define __USB_PIC_PERIF__ 1 // belso USB periferiat hasznalunk #DEFINE USB_HID_DEVICE TRUE // USB HumanInterfaceDevice #define USB_EP1_TX_ENABLE USB_ENABLE_INTERRUPT // 1-es EndPoint (kuldo) engedelyezese #define USB_EP1_TX_SIZE 32 // Lefoglal 4 byte helyet a hardware-ben a szamara #define USB_EP1_RX_ENABLE USB_ENABLE_INTERRUPT // 1-es EndPoint (fogado) engedelyezese #define USB_EP1_RX_SIZE 5 // Lefoglal 5 byte helyet a hardware-ben a szamara #include #include // this UBS device #include // reports ///////////////////////////////////////////////////////////////////////////////////////////////// //VALTOZOK int adat=0; // ezt kuldjuk ki unsigned long usbido=0; // USB csatlakozas stabilitasa miatt int output_data[1]; // USB output adattomb (3 byte a belyegnek, 2 a pozicionak) int a=0; // futoindex tomb feltolteshez ///////////////////////////////////////////////////////////////////////////////////////////////// //INICIALIZALAS void init() //inicializalo resz { //portok set_tris_a(0xff); // A port: 11111111 set_tris_b(0xff); // B port: 11111111 set_tris_c(0xff); // C port: 11111111 set_tris_d(0xff); // D port: 11111111 //interruptok enable_interrupts(GLOBAL); // Interruptok engedelyezve enable_interrupts(INT_USB); // USB int engedelyezve (nem biztos hogy kell) } //USB init: void usb_inicializalo() // USB inicializalasa kulon meghivva referenciaba allitas utan { usb_init_cs(); // USB hardware-t inicalizalja usb_detach(); // levalasztas a BUSZrol while(!usb_enumerated()) // amig nem csatlakozott a PChez rendesen... { usb_task(); // USB kapcsolatot kezdemenyez usbido++; // novel 1-el if(usbido>500000) // ha 500000 ciklus alatt nem tudott csatlakozni... { usb_detach(); // valassza le a BUSZrol es kezdje elorol (whileba ujra belep) usbido=0; // nullazas, hogy elorol kezdje a szamlalast } } } ///////////////////////////////////////////////////////////////////////////////////////////////// //PROGRAM //foprogram void main() // foprogram (PIC innen indul) { init(); // inicializalo meghivasa usb_inicializalo(); // USB inicializalo meghivasa delay_ms(1000); while(1) { adat=4; // adatnak (most) fix ertek adas output_data[a]=adat; // kimeno tomb feltoltese ertekekkel a++; if(a==31) // ha minden byte-ba tettunk ereket { a=0; // futoindex nullaz if(usb_tbe(1)) // ha az output buffer keszen all { usb_put_packet(1,output_data,32,USB_DTS_TOGGLE); // kiirjuk az adatokat } } delay_ms(1); } } ///////////////////////////////////////////////////////////////////////////////////////////////// Ugyanakkora az adatkuldesi "frekvencia" ha 1 bytot küldok csak, illetve akkor sem gyorsabb, ha kihagyom az "if(usb_tbe(1))" feltételt. Még az usb_desc_hid.h-ban átírtam a report count-ot 32-re: const char USB_CLASS_SPECIFIC_DESC[] = { 6, 0, 255, // Usage Page = Vendor Defined 9, 1, // Usage = IO device 0xa1, 1, // Collection = Application 0x19, 1, // Usage minimum 0x29, 8, // Usage maximum 0x15, 0x80, // Logical minimum (-128) 0x25, 0x7F, // Logical maximum (127) 0x75, 8, // Report size = 8 (bits) 0x95, 32, // Report count = (32 bytes) 0x81, 2, // Input (Data, Var, Abs) 0x19, 1, // Usage minimum 0x29, 8, // Usage maximum 0x75, 8, // Report size = 8 (bits) 0x95, 5, // Report count = (5 bytes) 0x91, 2, // Output (Data, Var, Abs) 0xc0 // End Collection }; Bármilyne ötletet szivesen veszek. Köszönöm! Ádám
Nekem ez a 16ms nagyon gyanús, hogy a descriptorban ennyi idő van megadva a hostnak a polling intervallumra. Az endpoint descriptor utolsó bájtja adja meg elvileg ezt az intervallumot.
Azt vedd majd figyelembe, hogy a HID maximum 64kB/s sebességet fog tudni, mert egy csomag maximum 64 bájt lehet, és másodpercenként ugye 1000 csomag átvitelére van lehetőség. Tehát a 12Mb/s közelébe se lehet menni vele.
Köszönöm!
20 ms-re volt állítva a polling intervallum (ezzel már régebben próbálkoztam, csak remélem van valami megoldás, hogy ennél sűrűbb küldés is lehetővé váljon, illetve eddig sem 20-anként jött, hiába arra volt állítva, így nem igazán láttam, hogy lenne feltétlen összefüggés). Átállítottam most 10-re (ez a legkevesebb amit lehet) és így 32 ms-enként sikerült fogadnunk... egyébként amikor 20-ra volt állítva, akkor is előfordult a fogadások között jópár 32 ms-es különbség. tehát nem szabályosak az időközök (de többnyire 16 vagy 32 ms). Azt írod, hogy mp-enként 1000 küldés lehetséges. Ez hogyan? Több endpointot használva esetleg? Mert a legkisebb beállítható polling interval ezekszerint 10 ms, ami akkor 100 küldés jelent mp-enként. És mennyire bonyolítja a kérdést, ha nem HID eszközként konfiguráljuk felé a PIC-et? Próbáltál mást? Azzal van tapasztalod esetleg? Köszönöm! Ádám
Váltsd át, hogy Full Speed eszköz legyen, akkor mehet az 1ms-os polling. FSEN nevű bitet keress a PIC adatlapjában, azt kell átbillenteni hozzá.
Több Endpoint jó kérdés, én is gondolkoztam már rajta, hogy vajon úgy növelhető-e az átvitt adatmennyiség. Valószínűleg igen, ha kompozit eszközt csinálsz, csak azt meg akkor pc oldalról bonyolultabb lesz kezelni, mert két külön eszköznek látszik a rendszerben, ezért szerintem nem szoktak ilyesmit csinálni. Nézz szét a Microchip példaprogramjai között, ott van nagyobb sebességű átvitelre is példakód, pl. az USB Device - WinUSB - High Bandwidth Demo nevű.
Ahham, átállítottam és lementem 1 ms-ig és jó is lett. Stabilan megy 1ms-enként, ezzel sikerült is elérni a 64 kbyte/s-et.
Ez a jelenlegi projekthez épp elég, de majd probálkozom a High Brandwidt Demoval is. Köszönöm szépen a segítséget! Lenne egy másik kérdésem is, hátha van hozzá ötleted. Ez kevésbé kardinális, de azért jó lenne változtatni rajta: A saját panelemen egy 18F4550 van ugye. Feltolom rá a fentebb említett progit és kb 10-15 mp után tud csatlakozni (addig próbálkozik pár mp-enként). Ugyanazzal a programmal az Explorer board(18LF5440) azonnal csatlakozik. Sőt, ha az Exlporer boardot csatlakoztatom a PC-hez, a PC "felismeri" az usb_desc_hid.h-ben deklarált név (desc string) mindkét részét (mert ennek van egy 3 karakterből meg egy 12 karakterből álló része, amit külön van megadva). ha a saját panelt csatlakoztatom, akkor ezen két string közül csak az egyiket (a 3karaktereset) látja a a PC. erről a h-file részről van szó: char const USB_STRING_DESC[]={ //string 0 4, //length of string index USB_DESC_STRING_TYPE, //descriptor type 0x03 (STRING) 0x09,0x04, //Microsoft Defined for US-English //string 1 8, //length of string index USB_DESC_STRING_TYPE, //descriptor type 0x03 (STRING) 'B',0, 'M',0, 'E',0, //string 2 26, //length of string index USB_DESC_STRING_TYPE, //descriptor type 0x03 (STRING) 'P',0, 'O',0, 'Z',0, '.',0, ' ',0, ' ',0, 'A',0, 'S',0, 'Z',0, 'T',0, 'A',0, 'L',0 }; furcsa ez a név-beli különbség nekem. zavarni nem zavar, de tán összefüggésben van a lassú felismeréssel. Ha bármi ötleted van... És tényleg kösz! zsir Ádám
Ha nem az USB csatlakozóról veszi az áramköröd a tápfeszültséget, akkor figyelni kell a VBUS lábat (az USB csatlakozó +5 V-ja), különben nem tudja a PIC, hogy mikor van csatlakoztatva és mikor nem. Adatlap 17-11 ábrája és a demókártyák kapcsolási rajza segít.
A Microchip USB mintaprogramjainál az USE_USB_BUS_SENSE_IO szimbólumot is definiálni kell, hogy a firmware figyelje a hardver profilban megadott lábon (pl. #define USB_BUS_SENSE PORTAbits.RA1) a VBUS feszültség meglétét.
Jaja, ezt a sense pin dolgot én is nézegettem már, de elvileg (ha jól értelmezem a CCS fordító tutorialját) ez csak egy opció, és az Explorer16-os boardon se használják.
Ami viszont feltűnt több bekötési ajánlásnál is, hogy a Vusb lábat egy 470[nF]-os kondin lekötik földre. Ezt én még nem tettem meg, igazából ennyi eltérésem van alegtöbb ajánlott kapcs.-koz képest, úgyhogy ezt ki fogom ptóbálni. (annyi a gáz csak, amiért ezt nem tettem meg, hogy a penel már be lett építve a kész berendezésbe és nem szivesen patkolgatnám, csak ha feltétlen muszáj) De gondolom ez olyan beötési dolog, ami mindenképpen szükséges... Köszönöm az ötletet! Ádám Idézet: „De gondolom ez olyan beötési dolog, ami mindenképpen szükséges...” Mondjuk úgy, hogy ritka csodának számít, ha elindul egyáltalán az usb kapcsolat ezen kondenzátor nélkül.
Akkor velem csoda történt
 De akkor azt mindenképpen betolom! Köszönöm! Ádám
Na, újra itt vagyok. Kipróbáltam sulis gépen földelt konnektor ugyanaz, továbbra is reset (ráadásul laboros gépek, szigorúbb érintésvédelemmel tehát tuti hogy ott semmi zaj nem kerülhet USB-re)
Viszont azon gondolkodtam, hogy mivel csak ki be dugogatáskor resetel USB lehetne azt csinálni, hogy mikor elkezd villogni hibajelző led egy goto-val a programkód elejére ugrana a vezérlés. Szerintetek ez jó ötlet? (Ill. egyátalán kivitelezhető?)
Nem tudjátok véletlenül, hogy a CDC firmware képes magasabb COM portokon működni? Itt 26..200-ra gondolok. Nem tudom eldönteni, hogy a VB6 nem tudja kezelni, vagy a firware.
Esetleg azt nem tudjátok, hogy mi foglalhatja le a Win7-ben a 3...16 COM portokat? Én már minden leszedtem, úgy tűnik valami rendszer dolog lehet.
Elso kerdesre bevallom nem tudom a valaszt, de ugy gondolnam a drivertol fugg ez es nem a firmware-tol.
A masodik kerdesre: BIOS-ban nem kell valamit allitgatni? Pl. infras eszkoz meg akkor is ha nincs az infra bekotve, vagy bluetooth?
Szerintem a firmware-nek nincs köze ehhez. Azt tapasztaltam, hogy a Microchip USB demók esetén (ahol a virtuális soros portot a Windows usbser.sys drivere kezeli) mindig alacsony (COM3 - COM5) számokat kaptam. FTDI meghajtóval (PIC32-höz kaptam egyszer olyan szoftvert, amivel FTDI eszköznek látszott!), akkor viszont COM19 vagy COM21 volt az eszköz neve. A SUNIX átalakítóm (PL2303 van benne) COM6-ra került.
2-3 hét múlva lesz SiLab CP2102 meghajtóm, majd meglátjuk, hogy aztl hova pakolja a Windows.
Szerintem a firmware lehetséges, hogy nemis tud róla, hogy most melyik COM porton lakik, hiszen a firmware usb csomagokkal dolgozik, a pc oldali driver dolga a többit intézni. Persze most ugye jön a kérdés, hogy a driver vajon tud-e magasabb portokon működni?
Nincsenek régi beragadt cuccok, amik ezen a portokon voltak? CDC kisérletezések után elképzelhető, hogy bent marad a bejegyzés, és legközelebb azt csak ugyanannak osztaná ki, új kisérlet pedig új portot kap.
Sziasztok!
Tudna küldeni valaki egy linket Delphi 7 nyelvhez használható USB HID forrást(dll). PIC 4550-el már megcsináltam a programot működik is csak saját kezelő progit szeretnék irni. De eddig amit találtam az valami szemetet bele tett a küldendő adatba. Nem program hiba volt. Végig teszteltem. Tudom dobjam ki azt a bájtot amit tele szemetel, de nem vagyok ilyen egyszerű eset  Előre is köszi Peppe
Hali!
18F2550-re sikerült Sasmadár kolléga segítségével átírnom a Watt féle VB-s programot Delphi 7-re. Bővebben: Link. Ezzel kipróbáltam, hogy egy 4 gombos "joystick"-kal irányítani az egérkurzort, és tökéletesen működött! Most szórakozok én is a 18F4550-el, egy 4x4x4-es ledkockát akarok úgy megcsinálni, hogy USB-n kommunikáljon a PC-vel. Persze hogy nincs 20MHz-es kvarcom, a másik két kütyüből meg nem akarom kibontani (megfogadtam, hogy egy kész áramkörből nem berhelek már ki alkatrészeket ).De hétfőn veszek vagy 1 kiló 20 megás kavicsot, aztán kipróbálom ezt a bootloados dolgot 4550-re. Utána meg természetesen írom megfele a PC oldali programot Delphi 7-ben. Neked is bootloados a PIC-es program? szerk.: amit 2550-re csináltam, az nem bootloados, mivel Watt cikkébel lévő program ketyeg a PIC-ben (egy-két módosítással), abban pedig nincs bootload, illetve kivan kommentezve, meg még számomra nem teljesen világos ez a bootload dolog, illetve már csak a részleteket fedi homály.
4,8,12,16 vagy 24MHz-es kvarcod sincs? Mert csak a konfig biteknél kell az osztót átállítani, és használhatod ezek valamelyikével is.
Szia!
Nem bootloados! C ben irtam. Szépen működik a PIC program. Csak a PC oldal kell már hoyg tuti működjön..... Után jöhet a többi USB HID-es project. Peppe
Szóval elég azt beállítani hogy a PLL 96MHz legyen? Aminek 4MHz kell, tehát pl. 4MHz esetén nem kell osztó...
Valószínűleg akkor az eleján még a bootloados verzió nélküli PIC-PC kapcsolatot csinálom meg Delphivel, aztán ha teljesen megértem a bootloadot, megcsinálom azzal is.
Majd akkor írok hogy haladok. :yes: |
Bejelentkezés
Hirdetés |
