Ha ez így segített a megoldásban, akkor inkább hagyd benne, nem sok helyet foglal az a néhány hívás.

Vagy még annyit megtehetsz, ha van rá lehetőséged, hogy addig, amíg nem történik meg az eszköz felkonfigurálása, addig nem csinálsz időhúzást a saját dolgaiddal. Olyanra gondolok, hogy csinálsz egy ciklust az USB bekapcsolása után, a fő ciklus előtt, ami hívogatja az USBTasks()-ot egészen addig, amíg a felismerés/konfigurálás tart. Eztán kezded el az i2c dolgokat. Van egy usb_device_state belső változó, abban jelzi, hol milyen fázisban tart az enumerációban. UserInit()-be meg szinte semmit nem tenni, hogy ne húzza az időt, mert azt meghívja az InitializeSystem(). Pl. így:


void main(void)
{
InitializeSystem();

while (usb_device_state != CONFIGURED_STATE)
USBTasks();

// ide jönnek az időt húzó iniciáló dolgok

while(1)
{
USBTasks(); // USB Tasks
ProcessIO(); // See user\user.c & .h
}//end while
}//end main

Ez jó ötlet lenne, de a későbbiekben szeretném elemről üzemeltetni az áramkört és csak a beállítások idejére kötni USB-re.
De ha beraknék 1 gombot amit nyomva kell tartani csatlakozáskor és attól függően figyelné a konfigurálást, az már jó lenne.
Köszi az ötletet!

A Delay szó hányszor szerepel a programodban?

Nem raktam bele, de az i2c-s függvényekben láttam.

Akkor jó eséllyel megvan a probléma forrása. Túl hosszú időre lefoglalja az I2C rutin a kontrollert, és nem hajtja végre elég gyakran az USBTasks processzt.

Sziasztok!

Az elmúlt percekben regisztráltam e helyen és máris elveszek az információ tengerben
Szeretnék egy áramkört építeni ami USB-n csatlakozik a géphez és 16 kimenetet tetszésszerint lehet programozni rajta. Olyan chip kellene, amelynek van belső eeprom memóriája is, kellőszámú IO portja a célhoz és egyszerűen vezérelhető USB-ről.
A chip kiválasztásához szeretném a segítségeteket kérni nomeg egy olcsó programozó is kellene. Ez a PICKit2 árban meg is felelne, de semmi közelebbit nem tudtam meg róla a chipcad.hu-n. Valamikor régen foglalkoztam már PIC-el (~10éve, 16C84), de azóta akkorát fordult a világ, hogy kezdhetem elölről
Nomeg kéne fejlesztőeszköz is (ASM vagy C).
Köszi előre is a türelmet...

Programozó: Pickit2 vagy utánépíted vagy megveszed.
USB: 18F*550 ld. Gory cikkei. Fejlesztőeszközt ad a Microchip butítottat ingyen . (MPlab + C18)

Én is beleszaladtam ebbe a dologba, ami a fő kérdésedben szerepelt. Úgy oldottam meg, hogy csináltam egy Timer0 megszakítást (kb. 6ms(152Hz)) és abba tetem az USBTask(); hívást. Így a fő programban azt csinálok amit akarok.

Persze ez a megoldás csak igen távolról mondható megszakításos USB kezelésnek, mert az USB szempotjából maradt pollingos. Ott még nem tartok, hogy valós USB megszakításos kezelést írjak, de szilva jóvoltából lassan kezd kialakulni a kép!
Tényleg szilva, nincs kedved egy cikket írni! Te lehetnél itt az USB Király! Ha ez nem mozgat, akkor az esetleg igen, hogy sokan szívükbe zárnának! Tudom nagy meló, de nem sürgetlek!

Sziasztok!

Ezzel a PIC-kel én is foglalkozom egy ideje, sikerült is látványos, működő programokat csinálnom. Még semmi komolyat nem csináltam, de a ledvillogtatás már nagyon profin megy... PC oldalon a mpusbapi.dll-t használom. Nekem az okozott nehézséget, hogy nem akartam a CDC firmware-t használni, a dll-hez meg nem találtam példaprogramot. Úgy gondoltam írok róla egy cikket, amit már el is kezdtem.

Az ADC nem akar működni, mindig nullát ad, bármit csinálok. Próbáltam már a Gory féle módszert, a C18-as adc.h-t, meg mindent de a mai napig csak 0-t hajlandó mérni. Beállítom tristate-nek a bemenetet, meg mindent, de nem működik. Mi lehet a baja?

A megszakításos módszernek mik a nehézségei? Így elsőre egyszerűnek tűnik.

Üdv. Muri

A cikk engem is érdekelne, csak rajta!

Az ADC-vel biztosan valami beállítási eltérés lesz, mert annak működnie kell. Nem sokat írtál róla, hogy érdemben lehessen mit mondani, de javaslom, hogy a részleteket a PIC Miértek... topicban tedd fel, hamar megoldódik, ha ilyen jellegű a probléma, csak adj valami támponot(programrészletet, vagy egész forrást)

A megszakításos módszernek nincsenek nehézségei, ha át tudod tekinteni a program működését.

Csak arról tudok írni, amit már kiszenvedtem és emiatt meg is tanultam. Ez nem igazán baj, elég, ha a tanár csak kicsit jár előbb az anyagban, mint a tanítványok Amit megírtam Neked levélben, ha nincs ellenedre, azokat a szövegeket kicsit kipofozva gondoltam cikkbe, vagy inkább cikksorozatba önteni.

A/D meg kell, hogy műkdjön. Nekem most egy lukacsos próbapanelen van egy igen érdekes szerzetem összerakva a tanuláshoz: Van rajta egy 18F2550 (most épp 18F2455, próbából), PICkit2 programozó tüskesor, RS232 illesztés egy DB9 mamával, meg az USB csatlakozó. Ezen kívül reset gomb, két "tact" nyomógomb, 1 hall-os nyomógomb, egy 4k7 poti bekötve az egyik analóg lábra, valamint 6 LED, ellenőrzésnek. A PICkit2 csatit most nem használom, inkább beletettem az RS232 bootloaderemet a PIC-be, így a terminálból le tudom küldeni az új hex-et neki, ha kell.

Az USB-vel most ott tartok, hogy ez a panel joypad-ként funkcionál PC-re kötve, az USB kommunikáció során a debug infókat RS232-n küldi egy terminálba. A "joypad"-em x eltérése a poti által szabályozható, az y a két "tact"-tal, a hall-os nyomógomb meg az első sorszámú tűzgomb. Reggel játszottunk vele Insane-t

Köszi a tippet!

Már hogy lenne ellenemre! Nagyon örülnék neki! Esetleg ha kicsit fetuningolnád néhány példával, tálázatokkal, az nagyon segítene a megértésben.
Közben sokat olvasok, kódot böngészek, és úgy érzem ragadt rám valami, főképp neked köszönhetően!

Az nem érdekes szerintem, hogy ha nem öleli át a teljes USB anyagot(gondolok itt a high speed-re meg néhány spéci módra), sokkal fontosabb, hogy egy részét jól meg lehessen érteni. a többi ebből kiindulva már sokkal egyszerűbb!

Kicsit irigyellek a jelenlegi USB pozíciód miatt!

Azt a levelet megkaphatom én is? Címem a profilomban található. Kösz

Úgy látom le vagyok maradva...

ADC-nek működni kell, de nem teszi... Az eredeti demót nézegetve sikerült kicsikarni belőle, hogy kiírjon valamit, csak összevissza ugrál 512 és 572 között.

Mint írtam, szeretnék egy cikket írni a dll használatáról, de csak most kezdtem, ezért nem tartok sehol. Megosztottam veletek a szerk. jogát, nézzétek meg azt a 10 sort, meg a programot töltsétek le.

Jó lenne belesűríteni mindent egy cikkbe. Egyébként a neten sok leírás van, sajnos csak angolul. Egyedül Gory leírása magyar.

Muri

Itt vannak a 18F2455 kódjában az A/D-kre vonatkozó részek. Az első valahol a main elején van, ahol a portokat is inicializálom:



A második részlet, ahol mérem az AN0-ra kötött potit:



Semmi más trükközés nincs az A/D-vel kapcsolatban.

A kód jónak néz ki, viszont a TABLE 21-1 alatti megjegyzéseknél azt írja, hogy ha az RC oszcillátort használod az ADC órajelének, akkor a konverzió idejére sleep-be kellene tenni a kontrollert. Szerintem használd inkább a főoszcillátorról származó jelet órajelnek, hátha ér valamit.

Valóban, igazad van, emlékeztem rá, hogy korábban olvastam ilyen furcsaságokat az A/D-jéről, de itt nem nagyon figyeltem rá. Egyébként mintának azért tettem be, mert ez így, ennyi beállítással nálam működik, felső 8 bitet használom csak.

Megjegyzem, azt a note-ot nem értem: az A/D RC időalapja elvileg pont azért van, hogy CPU órajeltől független időzítéssel dolgozzon az A/D. Hogy ennek mi köze a sleep-hez és a CPU egyébkénti működéséhez, az számomra rejtély. Lehet, hogy csupán a "digitális zaj" miatt írta oda a gyártó, hogy az ilyen "lassú" konverzióba már akár a CPU által keltett egyéb zajok is beleszólhatnak?

Ja, most nézem, hogy nemis nálad nem működik az ADC, hanem Muri-nál

Ez a "digitális zajok beleszólnak" jó gondolat! Az okokról nem sokat beszél az adatlap, ezt lassan meg kell szokni az MC-nél.
Én is a fő oszcit szoktam AD-re használni. De ha működött a fenti kód nálad, akkor lehet, hogy csak az alsó bájton lehetett volna bizonytalanságot tapasztalni.
Egyébként a kódodban várakozás van, amit nyugodtan le lehet cserélni sleepre. Persze van olyan program, amiben ezt a luxust nem nagyon lehet megengedni...
(ugye mondtam, hogy a témát szétoffoljuk, ha nem kerül át a PIC Miértekbe!! )

Köszönöm a gyors válaszokat! Én is valahogy így próbáltam, és kiderült hogy a PIC rész jó, csak a PC szoftver nem jó bájtot figyelt. Most sem működik teljesen, majd rászánok pár órát.
Szilva, ha jól értem az egészet megírtad assemblyben???

Hát, gyakorlatilag igen. Az USB kommunikáció váza megvan, HID eszközt csináltam vele próbából. Persze még foglalkozni kellene vele, de úgy gondolom, fogok írni az USB-nek erről az alacsonyabb szintű megközelítéséről egy cikket vagy inkább cikksorozatot.

Hát igen, az USB az nem egy cikk. Az sok cikk

Megszakításból kezeled az usb kéréseket, vagy polling módszerrel?

Még polling, de a kód elvileg elő van készítve a teljesen interruptos módszerre is.

Gyakorlatilag a GIE-t kellene bebillenteni és az interrupt-kezelőből azt a rutint meghívni, amit most a pollozás hív meg rendszeresen.

Jelenleg egy próbapanelen rakom össze a kísérleti környezetet, amiben lesz 3x4 Hall-os nyomógomb, vízszintes és függőleges tolópotik, 4 tekerős poti és 3 LED. Ezen mindenféle joy- és klaviatúrás dolgot ki lehet majd próbálni. Épp most készült el a nyomógombok mátrixba kötése és a tesztprogival lekérdezése, de ez még csak a LED-eken jelez vissza, nincs kész az RS232 csatlakozás (debug) és még az USB csati környéke sincs kialakítva.

A gyári CDC firmware-nél is ezt hittem, aztán valahogy nem ment. Ezért tettem a fő hívást aztán egy Timer hurokba. Ez ettől még polling maradt, de végül is megszakítsában van kezelve, mert nem maradhat el a rendelkezésre állás.

A cikkhez sok sikert, alig várom!

Az a baj a C-ben írt gyári firmware megszakításból történő kezelésével, hogy további függvényeket hívogat az USB_DriverService() rutinból, ami miatt a fordító a megszakításnál szinte az összes regisztert elmenti, majd a megszakítás végén visszatölti ezeket. Ez jelentős mennyiségű processzoridőt emészt fel. Az egészet át kell írni úgy, hogy ne hívogasson további függvényeket a megszakítási rutinból, hanem az összes elvégezni való munka egy függvényben legyen. Természetesen első körben mehet a dolog függvényekkel is, de hamár úgyis azért csináljuk a megszakításból, mert a főprogramunk lassú, akkor ezzel sokat lehet nyerni a főprogram számára.

Ez egyébként nem csak az usb-re érvényes, hanem az összes C programra. Van is erről egy webinar anyag a microchip honlapján: Link

Köszi az infót, meglesem!

Szerintetek milyen időközönként kell lepollingozni az USB portot, hogy a bedetektálás és a folyamatos készenlét meglegyen?

Hogy a bedetektálás meglegyen, azt jobb megcsinálni egy kis ciklusban. De azután hogy mennyi időnként kell, az már jó kérdés. Pl. a ps2-usb átalakítóm a felismerés befejezése után nem igényli, hogy folyamatosan hívogassa a rutinokat. Csak akkor hív meg egy-egy rutint, ha a gép új adatot küld neki (konkrétan a ledek állapotát), vagy az emulált billentyűzet küld a gép felé valamit. Ezt onnan tudom, hogy amikor meghívódik a rutin, akkor - ha az UIR regiszter nem nulla - akkor az UIR tartalmát kiíratom egy LCD-re. Felcsatlakozáskor teleírja az LCD-t, de utána ha csak úgy áll a gép, akkor az lcd tartalma nem változik fél nap után sem.

De a Host pollingolására kell valamit válaszolni, nem?
Egyébént leszakadna a PC-ről egyből! ??

Most, hogy jól menjen a detektálás kb. 5KHz-es megszakítás kell. Holott valami 6-10ms-re emlékszem, ami a host felőli lekéréseket illeti. Ezek szerint a detektálás nem tartja be a host polling közöket?

Kipróbálom, hogy a detektálás után kevesebbszer pollingolok. Köszi!