Fórum témák
» Több friss téma |
Fórum » CCS PIC Compiler
Én csináltam CCS-ben is Fullspeed-es HID cuccot, nem raktam rá külső felhúzót, viszont nem vagyok biztos benne, hogy alapból nem low-speed-re van-e állítva az FSEN bit a CCS kódban. Ezt is ajánlatos megnézni.
Most nézem a CCS ex_usb_hid.c mintaprogramot. Ebben alaphelyzetben feltételezik, hogy az RB2 bemeneten figyeli a PIC, hogy csatlakoztatva van-e az USB-re. Ha nincs csatlakoztatva az RB2-re semmi, akkor a program azt hiheti, hogy nincs rádugva az USB-re, s nem kommunikál megfelelően.
Azt mondják, hogy ezt ki kell kommentezni, ha nem akarjuk használni ezt a lehetőséget.
Így igaz. Amiket találtam kapcsolásokat legtöbb a belső felhúzót használhatta, mivel külső nem volt rajta, de...
Ha lowspeed-en a D- t kell felhúzni, highspeeden a D+ t, és a külső ellenállás beforrasztása jelentős javulást okoz, arra enged következtetni - bár lehet hogy tévesen - hogy a PIC alapértelmezése a lowspeed, azaz a D- belső felhúzóját állítja be, vagyis ha a D+ t egy külsővel felhúzom mindkettőn lesz, ami akár okozhatja is a jelenséget, bár továbbra sem értem miért kezeli másképp a win7 és az XP. A kérdés továbbra is az, hogy mi a trükkje az UCFG elérésének CCS-ből.
Ilyen USB sens-es áramkört építetten én is, mivel az készülék éli a maga életét, az USB-t csak a beállításra és a külső eprom adatainak lekérdezésére használom. Ugyan nem az RB2-n figyelem, de ez mindegy, átírtam a programban másik pinre, az kiválóan működik is, ha egyszer felismerte bedugom - kihúzom gond nélkül csatlakozik és bontja a kapcsolatot a PC-oldalon is és a PIC-is (tettem egy ledet hogy lássam az usbÜenumerated() állapotát), az hibátlan.
Okos ötletnek találtam, mert a digidugi panelen amíg ez nem volt benne amíg az USB nem volt csatlakoztatva a program el nem indult mert vár a csatlakozásra. De ha az XP megeszi, ugyan azon a gépen a win7-nek mi oka lehet rá hogy ne ismerje fel? A dolog azért aggasztó, mert ahová a cucc végleg kerülne, ott már csak 7-es windows van. Idézet: „Ugyan nem az RB2-n figyelem, de ez mindegy” Nem tudom, hogy számít-e, de az RB2 TTL szintű bemenet.
Igen, az adatlap szerint is az FSEN és a UPUEN alapban 0-ra van állítva. A D+ on és a D- on is van egy pull up ellenállás, amit az FSEN kapcsol be, alapban lowspeedre, vagyis a D- t húzza fel, az UPUEN húzza a D+ t és kapcsolja le a D- t.
Azaz ennek szellemében a beforrasztott 1,5k-s ellenállásommal jól kellett volna hogy működjön, de nem volt 100-as. "Kis" keresgélés és adatlaptúrás után erre jutottam:
Így már teljesen korrekten ismeri fel minden XP a készüléket valami Semifluid.com vagy mifenének, de a neten azt írják ez jó jel . Eddig simán vagy felismerte vagy nem függetlenül az ellenállástól, azaz vélhetően a 20% os ellenállás már nem alkalmas erre (bár írják hogy 5%-osnak kéne hogy legyen, de olyanom nem volt a fiókban. Ezek szerint érzékeny rá. Ezzel a kis kiegészítéssel minden rendben volna, 3-ból 3 XP gond nélkül azonnal felismeri de a windows 7 nem hajlandó. Hiába túrom a netet nem találok semmi épkézláb dolgot ami előrébb vinne.
Lehet, hogy valami nem szabványos a descriptorokban, XP meg megengedte, de Win7 már nem engedi meg a szabványtól eltérést.
Win7 mit mond? Nem tudja felismerni, vagyi hibásan ismeri fel?
Erre (mármint az előző hozzászólásodban mutatott beállításokra) mi szükség van, amikor CCS-nél az usb_attach() hivatalból megcsinálja? (pic18_usb.h)
Ayt mondja nem lehet felismerni. Eddig egzetlen egyszer véletlen felismerte, da akkor sem tudta használni.
Tudsz valami jó decriptor leírást?
Az a gyanúm hogy nem csinálta meg, hiába kellett volna neki. Hogy miért azt ne kérdezd, fogalmam nincs.
Talán már megy az USB. Az adatlap azt írja hogy ezeket a biteket az USB modul indítása előtt kell piszkálni. Talán az initusb már elindítja így hiába próbálkozik. Nem tudom, de mióta beleírtam az XP-k gond nélkül felismerik, és működnek vele.
Sziasztok,
Ismét a segítségeteket kérem. Írtam egy programot egy PIC12F629-re, amiben egy RA portváltozás megszakítást használok arra, hogy átírjak két változót. Hogyan tudnám elérni azt, hogy ez a két változó ezután már ne változzon meg, azaz a főprogramba való visszatérés után az már ne legyen képes ezeket átírni? A főprogramnak a normális működés során írnia kell ezeket a változókat, csak azután nem szabad, ha ez a fajta interrupt egyszer is lefutott. Szerintetek van erre valami megoldás? Kössz előre is. Üdv: Buddha
Csinalj egy flaget (nevezheted mutexnek vagy semaphornak vagy aminek akarod). A flaget inicializaldd fel pl. 0-ra bekapcsolaskor. Foprogramban addig csinalhat X muveletet ameddig Fx flag 0. Interruptban pedig ezt az Fx flaget beallitod 1-esre...
Kössz, ez jó ötlet.
Még egy kérdés: lehet-e olyat csinálni, hogy az interruptból ne az eredeti helyre ugorjon vissza, hanem egy megadott címre a programban? Kössz. Üdv: Buddha Idézet: Tudtommal PIC12F mikrovezérlővel nem lehet, mert ugyanabba a hardveres verembe kerülnek a visszatérési címek szubrutinhíváskor és programmegszakításkor is. Ha máshová ugrasz, akkor nem tudod kitakarítani a fölösleges visszatérési címet a veremből. „lehet-e olyat csinálni, hogy az interruptból ne az eredeti helyre ugorjon vissza, hanem egy megadott címre a programban?” Legfeljebb akkor lehet megcsinálni, amit akarsz, ha az egész veremtartalmat eldobod. Ez esetben azonban - mivel nem tudni, mit szakítottál félbe - egy inicializálás jellegű programrészre kell ugranod (GOTO-val)., s gondoskodni kell a programmegszakítás újraengedélyezéséről.
Technikailag kivitelezheto -- pl. egy eleg neves amcsi ficko is alkalmazza ezt a modszert, de az nagyon speci dolog, es Te olyat nem akarsz csinalni... mondom nem
Ahogy icserny mar irta a stack-el problema lesz... Kis trukkel pl at lehet ezt hagni, amit szinten emlegetett icserny, hogy resetet kell csinalni, amit pl a WDT-vel meg lehetne eppenseggel csinalni, vagy egy kulso reset aramkor segitsegevel. De mint emlitettem, Te nem akarsz ilyet csinalni... mondom nem Szoval marad a flag, amit bizonyos pontonkent a programodban figyelsz, es ha az beallt 1-be akkor ugras ahova tetszik... Idézet: Erre tudsz linket adni? „Technikailag kivitelezheto -- pl. egy eleg neves amcsi ficko is alkalmazza ezt a modszert”
Meg probalom megkeresni -- vegulis a piclist-en ir rola Olin Lathrop, de forrast nem hiszem talalsz hozza. Megprobalom megkeresni, de mar 1-2 eve irta, csak beugortt. Pill.
Köszönöm, hogy utánanéztél!
Ha jól értem, az úriember ötlete szerint a PIC egy külső esemény (interrupt) hatására feltétel nélkül az interrupt vektortól folytatja a programot, s csapot-papot otthagyva, innen folytatódik a program. Egyfajta lágy újraindítás... Mindezt az teszi lehetővé, hogy PIC12 és 16 esetén a hardveres verem túlcsordulás és kiakadás helyett egyszerűen körbefordul.
Igen, igy van. Nyilvan feltetel, hogy az ember masra nem hasznalja a hardware-es call stack-et -- avagy ha igen akkor meg ugy van a program felepitve, hogy az ne zavarhasson be semmilyen korulmenyek kozott.
Amugy epp az ellenkezojet mar csinaltam en is: WDT-t tulajdonkepp timer interruptnak hasznaltam egy 10F202-ben, ahol ugye nincsenek interruptok. Nem egy kellemes dolog ez sem, csak a kenyszer hajtott. Azon gondolkodom epp, hogy van olyan PIC, aminel lehet konfiguralni, hogy a call stack tulcsordulasa eseten csinaljon-e resetet vagy sem. De ha jol emlekszem nem mindegyiknel van ez igy? Idézet: „Azon gondolkodom epp, hogy van olyan PIC, aminel lehet konfiguralni, hogy a call stack tulcsordulasa eseten csinaljon-e resetet vagy sem.” Azoknál a fejlettebb mikrovezérlőknél van ilyen (pl. PIC18), ahol a veremhez hozzá lehet férni valamilyen módon (tehát szükség esetén el lehet dobni egy visszatérési címet). Lehet, hogy az új generációs "öszvér" PIC16F1xxx mikrovezérlők is idetartoznak, azokat nem néztem még meg.
Fiúk!
Tudna valaki valami letöltőhelyet, ahonnan a CCS TCP/IP stack-jét és USB stack-jét le lehetne tölteni, hogy kipróbálhassam? Nem szeretnék látatlanban kiadni több száz dolcsit... Utoljára azt a CCS TCP/IP stack-et láttam, ami a MicroChip 3.7 verziójú TCP/IP stackjére épült, a MicroChip most az 5.6-os TCP/IP stacknél tart. Nagyon örülnék, ha valaki tudna segíteni ebben. Üdv: Jossz
Whalaky, csatolom a 3,3V-os CCS Ethernet fejlesztő panel kapcsolási rajzát és a CCS TCP/IP 3.75 stack-et. Meg persze mindenkinek ajánlom, akit érdekel...
Üdv:Jossz
Kösz, de én azt hiszem itt adom fel. Ez a TQFP tokozás nekem nagyon nem jön be. Nem tudom beforrasztani
Marad az hogy keresek valami enc-s verziót, ki tudja... A másik igaz nagyon költséges, de atom stabil megoldás a TIBBO. Lehet hogy nem úszom meg.
Amikor az UART kapcsolat SPEN, TXEN, TRMT, SPEN regisztereit használni akarom, meg kell előtte adnom valahol, hogy hol vannak ők? Vagy a #use rs232-ben kell valami?
Közli velem, hogy azok ismeretlen változók. 16f887-et használok, az adatlapban ott van, hogy pl trmt az 98h helyen bit1. Hogy mondom meg neki, hogy erre gondolok? Az >itteni< küldő és fogadó kódokkal harcolok.
Idézet: „meg kell előtte adnom valahol, hogy hol vannak ők?” Igen. Idézet: „Vagy a #use rs232-ben kell valami?” Nem. Idézet: „Hogy mondom meg neki, hogy erre gondolok?” 16F-nél #byte, 18F-nél #word preprocessor...
Tehát pl #byte 98.1 jelen esetben? (a fordítónak tetszik)
A #bit-et el is felejtettem.Pl 16F:
Igy "érthetőbb". Nincs "Reference Manual" a közeledben?
Na csak összejött, köszi!
Nehéz szülés volt, de lett egy működő rádiókapcsolatom
A "double" változótípusról ezt állítja a ccsc (V4.093) súgója: "double is a reserved word but is not a supported data type." Mivel helyettesítsem? Lefordítja a double változókkal is, de igazából azt sem tudom így, hogy hány bites változóról van szó...
|
Bejelentkezés
Hirdetés |