A legelső linken lévő anyagra sikerült rátalálnom PDF formátumban:

Bővebben: Link

A második linken található oldal már valószínűleg sajnos régóta nem létezhet, a Google archívumában sincs egyetlen oldal se belőle.

Mégiscsak rátaláltam, a második linken szereplő verzióra:

Bővebben: Link

Látod, mire nem jó a web archiválása?

Van szerencsére jó rég óta egy globális web-archiváló oldal, ezen találtam rá mindenestül, szövegestül, ábrástul a dokumentumra. A hasznossága láttán szerintem reklámozd te is ezt az oldalt, ahol tudod.

http://web.archive.org/

Üdv. t-dani!

Köszönöm szépen!

Már tanulmányozom is.

web.archive.org-t elrakom a könyvjelzők közé.

Köszi!
Böki

Üdv mindenkinek!

Az USB kezelő letiltja valahol az interruptot, vagy mi lehet az oka, hogy nem tudok pontos időzítést csinálni?

Alaphelyzet: Timer2-vel magas prioritású periodikus programmegszakítást keltettem (T=0,5 ms). Az USB kezelése is magas szintű interrupton történt. A Timer2 óraütéseit számlálva próbáltam adatgyűjtési időt mérni (természetesen szigorúan óraütéstől óraütésig). Ellenőrzésképpen a Timer1-re kötött 32 kHz órakvarc rezgéseit számoltam, de a számolt adatok nagyon szórtak.

Azt gondoltam, hogy az zavar be, hogy ugyanazon az interrupton van az USB kiszolgálás, mint ahol az óraütéseket számolom, és Timer1-et kapcsolom ki, meg be.

Kísérlet: átraktam az USB lezelését az alacsony prioritású interruptra (ehhez az usb_hal_pic18.h állományban kellett az IPR2bits.USBIP=1; utaítást átírni IPR2bits.USBIP=0;-re).

Tapasztalat: a helyzet változatlan.
Lehetséges, hogy az USB kezelése közben ideiglenesen a magas szintű interruptot is letiltja, vagy más hol keressem a problémát?

Pótkérdés: Ha T1CONbits.TMR1ON=1/0;-nal kapcsolgatom a Timer1-et, akkor ugye a Timer1 oszcillátora folyamatosan megy, s ez csak a számlálást kapcsolgatja?

Megvan a megoldás! Timer1-et szinkronizálni kell (T1CONbits.T1SYNC=0; ez negatív logikájú bit!). Így a másodlagos oszcillátor jeleit pontosan számolja. Nem értem, hogy aszinkron módban miért nem volt jó...

Most Timer1 inicializásása így néz ki:



A korábbi feltételezésem, miszerint az USB kezelés akadályozná az időalapot szolgáltató Timer2 interruptjainak lekezelését téves elképzelésnek bizonyult.

Köszi, hogy megosztottad a megoldást! Azt hiszem, mi nem nagyon tudtuk volna megtalálni az okot a hardver nélkül! Nem semmi meló egy ilyen, tudom!

A dologban az a csúnya, hogy nem tudom az okát. A PIC18F4550 Errata ugyan jelzi, hogy a 16 bites kiolvasás nem működik rendesen aszinkron módban, de az a magasabb helyiértékű bájtra vonatkozik, nekem meg jóval kisebb eltérések voltak (3-9 impulzus). A másik gyanús körülmény az, hogy PIC18F87J50-nél is jelentkezett ez a hiba, pedig annál az Errata nem jelez ilyen jellegű hibát.

Mindenesetre melléktermékként:
1. Kiderült, hogy az USB kezelést már nem kell Timer interrupttal ütemezni, önállóan is csinálja a magszakításokat.
2. Kiderült, hogy az USB kezelést viszonylag egyszerűen át lehet rakni az alacsony prioritású interruptra (ehhez az usb_hal_pic18.h állományban kellett az IPR2bits.USBIP=1; utaítást átírni IPR2bits.USBIP=0;-re).
3. Kiderült, hogy akkor sem sértődik meg az USB, ha ~100 ms időre letiltom az USB tamagocsit (igaz, nem is forgalmazok közben). Mindenesetre ilyet nem csinálok üzemszerűen, csak ki kellett próbálnom, hogy nem az USB zavar be az időzítésbe.

Üdv!
Kezd alakulni a CDC kommunikáció. Találtam egy egész jó PIC Libraryt mikroPascalhoz, most azt próbálgatom. A kérdésem az lenne, hogy a PC oldalon a Baud Rate állítás befolyásolja-e az adatátviteli sebességet? Pl. ha beállítom 9600-ra, akkor az ténylegesen csak annyi lesz, vagy a CDC állandóan kihasználja a sávszélességet?

A PC-n beállított érték nem számít a PC és az USB-s PIC között, de ha interfésznek használod a PIC-et, akkor a PIC-PIC USART sebességére kihatással lehet. Ilyet nem csináltam még, de volt erről szó korábban, keress rá, hátha megleled.
De ha csak a PC-PIC kapcsolatot akarod, akkor nem számít a baud.

Ez akkor jó hír, mert az eszközkezelőben csak 128k baud-ot engedélyezne. Már csak annyi a bajom vele, hogy nem engedi megnyitni a portot. Win7 van fent, COM43-ra rakta be a PIC-et, delphi7-ből pedig hibát ír ki: "unable to open com port (win error code: 2)". Utnánnanéztrm microsoft honlapján, ez elvileg egy fájl hiányára utal. Találkozott már valaki ilyen jellegű hibával?

Nincs a gépeden bluetoot eszköz, vagy valami hasonló, ami egy halom COM portot lefoglal? Csak akkor teszi annyira hátra! Próbáld meg kézzel kiosztani neki a portot!

A Com 1, 2 port szabad, és 43-tól felfelé. Fogalmam sincs, mi foglal le 40 portot, BT nincs. Com1-en próbáltam, ugyan ezt csinálta. Amint tudom, kipróbálom XP alatt is. (Sajna pár napig feküdnöm kell lábtörés miatt, a műhelyig pedig jó lenne eljutnom valahogy, ott XP van )

Nos, ennek a problémának kiderült az oka: én fordítottam a bootloadert, s nem vettem figyelembe, hogy az ingyenes fordító gyengébb optimalizálása miatt nem fért bele a számára kijelölt 0 - 0x7FF területre. Így még szép, hogy felülírta magát!!!

Tanulság: mindig meg kell nézni a generált kód méretét!

Elkezdtem játszani 18F4550-el.
Az USB-nél azt írja a windows, hogy ismeretlen USB eszköz.
Drivert nem kér, azt írja, hogy ismeretlen eszköz (nincs sárga felkiáltó jel sem).
A bootloader bele van már égetve, és gondolom, hogy működik is. A led világít az RD0 porton, amikor rádugom az USB-re és az RB4-es lábat leföldelem.
AZ USB HID bootloader program nem ismeri fel.
Ha scoppal nézem a D- és D+ lábakat, akkor ha belépek bootloader módba, akkor megy egy pár másodpercig a kommunikáció, aztán az egyik láb + tápon van a másik pedig GND-n.
Itt egy kicsit elakadtam és nem tudom, hogy hogyan tovább.

A PIC18F4550 esetén annak is van esélye, hogy nem HID bootloader van beleégetve, hanem a MCHPUSB bootloadere, amelyikhez külön drivert kell telepíteni, és a Microchip PDFSUSB.EXE programmal lehet utána kezelni (a felbukkanó ablak BOOTLOAD Mode fülét kiválasztva.

Ennek a lapnak a legvégéről Microchip Application Libraries v2010-02-09 csomagot kell letölteni és telepíteni.

A PIC18F4550 mikrovezérlőt a PICDEM FSUSB kártya formájában támogatja.

----------------
A másik gond az lehet, ha nem jó az órajel frekvenciája. A fenti gyári csomagban 20 MHz-es kvarcot feltételeznek...

Közben megoldódott a gond.
Benéztem és először 12Mhz-es kvarcot raktam fel.
Utána láttam, hogy a 12Mhz az egy másik 3.3V-os változathoz van. Az én PIC-emhez 20Mhz kell. Ezt kicseréltem. Ezután sem működött.
Aztán a 4db 100nF-ot párhuzamosan (tegnap még csak ez volt itthon) a Vusb lábnál lecseréltem egy darab 380nF-ra. Innentől kezdve működik. Mondjuk nem értem, hogy miért, de megy.

Köszi.

Helló,

Felraktam a CDC BASIC DEMOT. Az ugye alapból annyit tesz, hogy BUTTON PRESSED üzenetet kiküldi.
Feltelepítettem a docklight programot, ahol látom az RX adatokat, amiket a PIC küld a PC-nek.
Módosítottam a programot, hogy számot küldjön ki.
EZ a része is működött a dolognak.
Azonban, ha beállítom az AD átalakítást az AD0-ás porton, akkor a windows nem ismeri fel az eszközt.
Ha az AD átalakítást kikommentezem, akkor megint működik minden.
AD átalakításnál nincs beállítva megszakítás.

Nézd meg a HID Custom demó programot! Abban az FSUSB kártyához így definiálják az inicializálást:



Én abból kopiztam át a CDC Basic demóba a megfelelő részeket, és működik.

Nálad a kiakadás annak lehet a jele, hogy valamiért nem fejeződik be a konverzió, tehátnem jó az ADC inicializálás. A részletekben nem merültem el, de az összehasonlítást és az adatlappal való összevetést te is meg tudod tenni.

Egyébként néhány napon belül közzéteszem a PICCOLO projekteb integrált USB CDC kapcsolat támogatói programkönyvtárát és az első USB-s demóprogramokat. Abban a while(1) ciklust akár így is írhatod:


Ebben is az USBDeviceTasks() és a ProcessIO() működnek a háttérben, de egy kicsit el lettek dugva a szem elől az usb_cdc_getc és usb_cdc-putc eljárásokba ...

Az AD átalakítás USB nélkül működik.
Az eredményét már írattam ki a PORTD-re.
Arra gondoltam, hogy az USB is használja azokat a portokat.
Inkább nem kínlódok vele tovább. Kivárom azt a kis időt, mire bele rakod a PICCOLO projeckbe.
Addig megtervezem hozzá a hardvert és utánna csak a szofverrel kell foglalkoznom.

Nekem elég lesz egy minimál USB, amivel AD értékeket viszek át a PC-nek.


Lesz majd benne alap delphi demó program is a PC oldalra?

PIC18F4550 esetén az RD0, RD1 kimeneteket rángatja az USB státusz kijelzésére. Erről le lehet beszélni, ha a BlinkUSBStatus(); hívást kikommentálod a ProcessIO eljárásban, s a UserInit() függvényből kihagyod mInitAllLEDs(); meghívását.

Nem lesz, nem foglalkozom Delphi-vel. A virtuális soros portnak pont az az előnye, hogy nem kell hozzá programot írni, a szokásos kommunikácós programokkal (Hyperterm, putty.exe) is el lehet boldogulni.

Hogy ne kelljen sokáig várni, a PICCOLO projekt PIC18 támogatói programkönyvtárának második (javított és bővített ) kiadását közzétettem. A mintaprogramok részletes leírása és magyarázata még várat magára...

A legfontosabb projektszintű konfigurációs paraméterek definiálása (HID_BOOTLOADER, USE_USB, USE_INTERRUPT) vagy a piccolo_config.h állományban vagy a Project/Build Options/Project menüben (a C18 fordító opcióinál) lehet megadni, ahogy némelyik mintaprojektben csináltam. (a "vagy" itt kizáró vagyként értendő!)

A főprogramba csak a piccolo_all.h állományt kell becsatolni (include-olni). Az USB mintaprogramok projektjeiből kiderül, hogy az USB használatánál milyen útvonalakat kell beállítani és mely fájlokat kell hozzáadni a projekthez.

Kipróbáltam!
Nagyon jól működik.

Azonban önálló dolgot még mindig nem sikerült létrehoznom.

A ProcessIO() függvényt csak egyszer kell meghívnom?

A "Hello-pool" mintaprogramot kezdtem el nézegetni.
for ciklussal csináltam 1s-os delayt. Azt szeretném, ha 1s-onként kiküldene a soros portra egy integert, ahogyan az AD átalakítónál is van.

Milyen függvényeket hívjak meg? Állandóan lefagy a programom, és a COM portot nem látja CDC terminal.

Az eredeti programokkal minden szépen működik.

Nézd el nekem, még csak 1 hete raktam fel a C18-as fordítót. C tapasztalatom annyi van, hogy 10 éve PHP-zek. A programjaimat eddig ASM-ben írtam, de az USB-hez ez már túl bonyolult lenne.

Lehet hülyeséget mondok.

Úgy tudom, hogy nem nagyon szabad delayt használni usb-s progiban, mert akkor megáll a kapcsolat, és a gép ledobja az eszközt.

Polling (lekérdezéses) módban állandóan hívogatni kell a ProcessIO() függvényt, s ez nem szabad, hogy hosszabb időre megszakadjon. Éppen ezért a blokkoló típusú függvényekbe (pl. usb_cdc_getc(), usb_cdc_putc()) bele kellett építeni, hogy várakozás közben hívogassák a ProcessIO() függvényt. A hello-poll.c programban a while(1) ciklusban azért nem szerepel explicit módon a ProcessIO hívása, mert a karakterre történő várakozásban már közvetett módon benne van.

Ha késleltetés kell, akkor próbálj olyan eljárást írni, amelyben legalább 1 ms-onként szerepel a ProcessIO hívása is! Ha ugyanis hosszabb ideig nem válaszol az eszköz a számítógép üzeneteire, akkor a PC úgy veszi, hogy az eszköz lekapcsolódott...

És a hello-int-4550-es programban a megszakítással van lekezelve az állandó hívogatás, hogy ne szakadjon meg a kapcsolat?

Polling üzemmódban a ProcessIO rendszeres hívogatása egyúttal az USBDeviceTasks() hívogatását is elintézi (ez a "kényesebb" időzítésű feladat, mivel ez tartja a kapcsolatot a PC-vel!).

Interrupt üzemmódban az USBDeviceTasks() kikerül a ProcessIO() eljárásból, és interrupton az USB forgalom függvényében kerül meghívásra, nem kell vele foglalkoznunk, életben tartja az USB kapcsolatot. Az adatforgalom lebonyolítása azonban továbbra is igényli a ProcessIO() rendszeres hívogatását, de az mostmár kevésbé kényes az időzítésre.

A korábbi késleltetős kérdésre visszatérve, mellékelek egy bugyuta adatgyűjtő programot. A beindításhoz kapnia kell egy karaktert (máshonnan nem tudom, hogy mikor csatlakozott a PC alkalmazáshoz!), s amíg le van nyomva a nyomógomb, addig küldözgeti a potméter állását (s a LED-eken is kijelzi a legfelső 4 bitet).

Az időzítés így nem pontos. Ha lényeges a pontos időzítés, akkor a hardveres időzítőket kell használni.

A demóprogram pollingos üzemmódhoz készült, de könnyen módosítható interruptos módhoz.

Köszi.
Nagyon hasznos kis programocska.
Alapnak nagyon jó.
Egy kicsit módosítottam és 2 potméter adatait egymás után 100ms küldözgetem.
Azt hiszem el leszek vele egy darabig.

Néhány apróságot megváltoztattam márc. 24-én a március 15-i kiadáshoz képest. Pl. észrevettem, hogy a korábban ajánlott késleltető eljárás használata esetén az USB státuszát kijelző LED-ek túl lassan villognak. Ez ugyan csak szépséghiba, a működést nem akadályozza, de módosítottam a delay_ms() eljárást, hogy még gyakrabban kerüljön sor ProcessIO() hívására. Ezzel ugyan pontatlanabbá válik a késleltetés, mert a belső ciklusban ProcessIO átlagosan 140 us-os ideje dominál, melynek időtartam nagymértékben függ a körülményektől, de ha a LED villogása fontosabb, mint a késleltetés pontos időtartama, akkor érdemes ezt használni. Én pl. csak arra használom a késleltetést, hogy "szemmel követhető" ütemű legyen a kiírogatás.

Pontosabb időzítést meg timer-rel csinál az, akinek szüksége van rá. (Nálam az egy későbbi fejezet lesz...)



Ja, az USB mintaprogramok leírása is megjelent, a "PIC miértek, hogyanok" topikban már hírt adtam róla.

Sziasztok!

Rutinos AVR-esként léptem át PIC-re, eddig tetszik a 18F4550, lenne egy olyan kérdésem, hogy C-ben hogy kell interruptot megadni (vagyis mi a makró - mint avr-ben a SIGNAL() vagy ISR(), amiről a fordító tudja, hogy ott IT jön), és hogy lehet áthelyezni az IT-ket, hogy a bootloader megmaradjon az USB-s programletöltéshez. Köszi!

Nézz meg néhány példaprogramot a gyári kódcsomagból, akkor világossá válik szerintem minden: Link