Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Csak a csatolmány maradt le...
Szia!
Ha a programozó adapterben nem futtatsz programot, akkor érdemesebb a Vpp -t és a Vdd -t a földre (Vss) húzni. Az indokot már régebben megírtam részletesen: Belső oszcillátoros, letiltott MCLR -es konfiguráció, ami a PGC vagy PGD vonalat kimenetnek, T1 oszcillátornak, stb használja, csak a "Vpp first programing enrty" módszerrel programozható át. Mivel semilyen más eszköz nincs az adapteren, a Vpp bekapcsolára a Vpp és Vdd közé tett ellenállással meg nem engedett szintre húzhatja a Vdd -t, de minden esetre feszültség alá kerül a Vdd is, ami a Vpp first módszert lehetetlenné teszi... Ha már úgy döntött a készítő, hogy nem futtat (nyomkövetés) programot, akkor a MCLR láb alacsony szintre húzása nem akadályozza semmiben...
Nah az történt hogy a beépített pwm előállítót kihagytam és az anselt átírtam
ANSEL=0b01111111; (ezt elnéztem az előbb) így az oszlopok mind érzékelnek de az RA1 -em még mindig nem ad ki impulzust. Ha visszakapcsolom a pwm-et akkor megint csak 1 oszlopom érzékel, mintha visszaraállítódna kimenetté , csak nem tudom miért..
A pwm_init -et módosítgattam kicsit, regiszter átírási sorrendet változtattam, és így í 4 oszlop jó , de az RA1en még mindig nem jön jel
Sziasztok,
Kis segítség kellene, most kezdek megismerkedni a pic-ekkel és olvasom ezt a nullától a robotokig irást és ez említ egy pic égetőtBővebben: Link Ahogy látom ehhez kell külső táplálás. De annak mennyinek kellene lenni? max dc 35V? és akkor ez müködhet egy ilyen kábellel laptopról is? Bővebben: Link
Hali
Ez az egeto nem all a helyzet magaslatan. Inkabb valami paralel portost kellene csinalni. Az USB-RS232 atalkito meg ront a helyzeten. Viszont ha nincs a gepeden LPT, RS232 port, akkor csak az USB-s egeto johet szamitasba. PK2, PK2 klon. Ezek az egetok altalaban megelegszenek 15-16 voltos tappal. A 35 volt nagyon magas.
Sziasztok , segítsetek légyszives.
Neten bogarásztam a pic18f14k22 hibái körül, és találtam olyan írásokat miszerint a 18f14k50 -es IC nél az RA0 és RA1 láb CSAK bemenetként használható. Ilyen kikötést a 14k22 -esnél nem találtam. Meglestem a fordító program header fájljait, és a 14k50esben tényleg nem is létezik LATA0 és LATA1 regiszter, viszont a 14k22-nek pedig létezik. mplab X -et használok, mcc18 as forditóval. Valaki segítsen megoldást találnom arra hogy RA0 és RA1es lábakat kimenetnek tudjam használni... nincs más szabad lábam már ezen a pic-en, szóval nem tudom már áthelyezni.
Szia!
Az ANSEL regiszter 0. és 1. bitjét tötölted?
ANSEL regiszternél ha 1et irunk bele akkor digital input buffer disable , ha 0át akkor enable van. Ebből én arra következtetek hogy ha azon a lábon digitális kimenetet akarok akkor a digitális bemenetet tiltani kell . Szóval így néz ki :
ANSEL=0b01111111; ANSELH=0b00000110; Kipróbáltam ezzel is : ANSEL=0b01111100; de nem jó Init : PORTA=0; LATA=0; TRISA = 0x08; definiciók: #define LED LATAbits.LATA0 #define sor1 LATAbits.LATA1 mainba ha csak ennyi van : init(); while(1) { LED=1; sor1=1; delay_ms(1); LED=0; sor1=0; delay_ms(1); } ezzel nem csinál semmit az a 2 kimenetem. Minden frankón működik csak ez a 2 láb problémás...
Szia!
Félreértetted: ANSEL regiszter bitjei a hozzá tartozó kivezetést analóg módba állítja 1 értékre és digitálisra 0 értékre. A digitális módban az irányt a TRISA regiszter bitjei állítják: 1 - bemenet, 0 - kimenet.
Ez így oké , TRISA regiszter be van lőve kimenetként, de az anselt akármire állítom nem akarja váltogatni a kimenetet. Sőt az ansel 3. bitja az RA2 és annak a beállításai is TRIS bit kimenet, ansel bit 1-es hogy disable, és az mégis úgy működik kimenetként ahogy én akarom, és annál is a LATAbits.LATA2 őt rakosgatom 0ba vagy 1be.
Szia!
Nyomkövetéssel ellenőrizd a regiszterek beállítását: ANSEL<1..0>00, TRISA<10>00. Az is lehet, hogy külső áramkör nem engedi a magas szint kialakulását a kivezetéseken. Ha lehet, kösd le a RA0 és RA1 kivezetéseit, és magukon a lábakon ellenőrizd le a működést. Végső soron a pic is lehet hibás...
RA0 és RA1 csak 1-1 nyomogombra kapcsolódik, a nyomogomb másik fele pedig egy ellenállásra amin keresztül gnd-re megy, illetve egy másik bemenetre. magyarán az RA0 és RA1 lábak ha 1est adnak és a gomb le van nyomva akkor egy másik láb is 1est érzékel(amugy nullát) és ezzel lehet dolgozni. Nyomogomb nem zárlatos, és ez a 2. pic szoval nem hiszem hogy mindkettő rosz lenne. Valami apró program hiba de már nem tudom mi lehet. Már biztonság kedvéért a VREFCON regisztereket is nulláztam mert láttam hogy ez a 2 láb a VREF+ és VREF- , de az se segített.
A RA0 a PGD, a RA1 a PGC kivezetés is. A konfigurációs regiszterekben a BKBUG ki van kapcsolva?
Idézet: „magyarán az RA0 és RA1 lábak ha 1est adnak és a gomb le van nyomva akkor egy másik láb is 1est érzékel(amugy nullát) és ezzel lehet dolgozni.” Amig ezt leirtad le is rajzolhatta volna es akkor egyertelmubb lenne -- mert nekem nem vilagos miert adnal aktiv kimenetet a nyomogombra? Vagy ki ad 1-est kinek? Ha valahogy ugy van bekotve ahogy a mellekelt kepen is, akkor az csak es kizarolag akkor mukodhet ha a porton a belso felhuzo ellenallas be van kapcsolva. Es kozben ha veletlen aktiv magas kimenetnek kapcsolod a portot es ekozben lenyomod a gombot akkor a gombon keresztul a kimenetet rovidre zarod a folddel... Ez a veszelye a dolognak, ezert tesz bele sok ember soros ellenallast, ami az ilyenkor folyo aramot bekorlatozza. Lehet eg kesz panelen ez nem annyira leyeges, de pl egy demo panelen mar igen.
Jogos erre én is gondoltam , ugyanis a configom így van beállítva :
... #pragma config LVP = OFF #pragma config XINST = OFF // #pragma config DEBUG = OFF #pragma config CP0 = ON #pragma config CP1 = ON ... A debug sor azért van kikommentezve mert valamiért oda hibát ír fordításnál. pedig a HELP-ből írogattam ki ezeket a beállításokat és ott ezt írja a C18 configuration settingsben : Background Debugger Enable bit: DEBUG = ON Background debugger enabled, RA0 and RA1 are dedicated to In-Circuit Debug DEBUG = OFF Background debugger disabled, RA0 and RA1 configured as general purpose I/O pins nahde ha a kommentezést kihagyom akkor ez a hibakód jön vissza : Error: [1224] configuration setting 'DEBUG' not recognized TIPP?
Bocsánat...
Csatolva van az áramkör ide vonatkozó része, nyomogomb mátrix 4 vezérlő láb, 4 érzékelő láb... Vezérlő lábak közül CSAK egyikre kirakom az 5V-ot, és ha megvan nyomva valamelyik gomb akkor valamelyik érzékelő lábon nem nullát hanem 5V-ot fog észlelni(logikai 1et) . Ha nem érzékel semmit, akkor a vezérlő lábak közül egy másikat rakok 1esbe. RA2 , RC0, RC1 teljesen jól működik akkor megy fel 5V-ra amikor program szerint kell.. RA1 viszont SOHA. RA0 láb pedig egy ledet vezérelne értelemszerűen megintcsak akkor ad 5V-ot amikor én akarom de az se megy. Remélem így már érthetőbb vagyok akkor, és bízom benne hogy találunk megoldást.
Ez az áramkör elég problémás... Ha egyszerre több gomb is le van nyomva, akkor két különböző kimenő szintre állítaoot kimenetet egymásnak kapcsolhat...
Maradjunk annyiban hogy ne foglalkozzunk az áramkörrel, nagyon rövid ideig aktívak a kimenetek, és ha több gomb is le van nyomva nagy bumm,semmi baj nem lesz, szoftveresen meg van oldva ezek észlelése.Viszont azt a 2 lábat kellene aktívvá varázsolni , és ebben kérem a segítségeteket. PL úgy hogy a hiba lehet ez a debug-os config bit, de a fordító hibát ír ha azt a sort aktívvá teszem...
Pontosan a debug beállítás szabadítaná fel a PGC és PGD lábakat... Milyen azonosító szerepel erre a funkcióra a header állományban?
Nem is akartam, csak a keresésemre azt is kidobta, és megijjedtem hogy a 14k22 nél is csak bemenetek azok a lábak, pedig a header fájlban ír LATA1et és LATA0 át.
Abban az állományban nem igazán találok hasonlót.
Viszont az MPLABX help menüjében ott a config beállítás menete, az alapján írtam , egyedül erre a DEBUG = OFF -ra nyögdécsel fordításkor. Inkább kihagytam hogy legalább probálgassam a progit, de úgyfest most nagyon kéne, de nincs rá ötletem hogy lehetne.
Mit mond az alábbi parancs? (Pontosabban mit ír a config.txt állományba?)
Idézet: „Ez az áramkör elég problémás... Ha egyszerre több gomb is le van nyomva, akkor két különböző kimenő szintre állítaoot kimenetet egymásnak kapcsolhat...” Na jo, de ha ugy csinalja, hogy vagy aktiv magas vagy lebego (tristate / input) allapot van a vezerlo vonalakon akkor azert nincs ilyen jellegu problema ezzel. Nyilvan ha a firmware-t az ember elrontja akkor lehet vele gond azert, es egy soros ellenallas nem artana, hogy megvedjuk az aramkort.
Remélem jól csináltam, cmd-ben beirtam amit írtál és kimentettem egy txt-be , csatoltam.. Viszont én nem látok benne utalást se DEBUG -ra se BKBUG-ra. Mi tévő legyek?
Az MpLab 8.xx -ben az ablak közepén lehet a Release / Debug módot kiválasztani...
Tudom, hogy ez az észrevétel nem oldja meg a fő problémát, azért is tettem külön hozzászólásba. Sokféle megoldás is szóba jöhet, 4 ellenállás, 16 dióda, stb - kinek mi tetszik. Itt az a probláma, hogy jó programmal is előáll a szembekapcsolódás...
Ezt tudom, de már írtam korábban h MPLAB X a környezet. Ott nincs ez a fül , illetve a project beállításai között se nagyon találom. Van egy supported debug header : AC244033 és pipa hely mellette de nem pipáltam be. Következő ötlet?
|
Bejelentkezés
Hirdetés |