Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Szereztem egy PICKIT3-at de még mindíg nem ok.
Elindítottam PICKIT3 szoftvert, tápfesz programozóról kapja, bekapcsolva a PIC MPLAB: Debugger / Select tool / PICKit3 kiválasztva A következő jelenik meg: No PICkit 3 Connected. Másik verzió: PICKIT3 szoftvert nem indítottam el, eszköz nincs csatlakoztatva. MPLAB: Debugger / Select tool / PICKit3 kiválasztva A következő jelenik meg: No PICkit 3 Connected. Ekkor csatlakoztatom a programozót a PCB-vel, majd a következő fut tovább: PICkit 3 detected Connecting to PICkit 3... Running self test... Self test completed Firmware Suite Version...... 01.26.65 Firmware type......................dsPIC33F/24F/24H PICkit 3 Connected. PK3Err0045: You must connect to a target device to use PICkit 3.
Na most nem indítottam PICKIT2 szoftvert, hanem külső tápról jhajtom és ezt kaptam:
PICkit 3 detected Connecting to PICkit 3... Firmware Suite Version...... 01.26.65 Firmware type......................dsPIC33F/24F/24H PICkit 3 Connected. PK3Err0045: You must connect to a target device to use PICkit 3. Target Detected Device ID Revision = 0000300a Talán most kezdődhet a buli 
Valaki nem tud véletlen egy nagyon egyszerű, működő egységnyi erősítésű műveleti er. kapcsolást arra hogy a PIC A/D bemenetén lehessen egy nem közösmódú jelet érzékelni?
Köszi!
Ez itt elég erősen off.
Van műveleti erősítős topik is a fórumon, ott jobb helye lett volna. A nem közös módusú jel az differenciális módusú, remélem Te is erre gondolsz. Tipikus megoldás a különbségképző műveleti erősítős alapkapcsolás (differencia erősítő). Kivonó áramkör
Úgy néz ki, hogy összeállt a kapcsolat.
Most hogy tudnám kiolvasni az adatmemóriába írt adatokat? VieW/file regiszterben látom a változókat, de mindegyik után RRRR áll. Elvileg "írtam" az adatmemóriába de nem látom. Hogy tudnám kiolvasni az adatmemóriába írt adatokat?
Szia!
De a movwf CCP3CON,ACCESS vagy a movf CCPPR2L,w,ACCESS már nem fog menni a 18F26K80 -on, mert nem az ACCESS ram területen vannak... Ha valaki ezeket kezelte előbb, értele lehet a banksel -nek.
Az általad linkelt adatlap nem jó a PIC18F26K80-hoz! Ahhoz ez való: Bővebben: Link
Beállítottam a debug-oláshoz szükséges kommunikációs csatornát
Mivel PGEC1/PGED1 csatornán programozok ezért config __ICS_PGD1 ; communicate on PGC1/EMUC1 and PGD1/EMUD1 Még mindíg nem OK
Watch ablak? Igaz itt a változóidat látod, ami az adatmemóban van...
Nézz körül a microchip műveleti erősítőinek adatlapjaiban.
Igazad van, én voltam a hülye. A végén nem vettem észre, hogy 80 szerepel, nem 20
 Ez alapján a beállításaid jónak tűnnek. Én megpróbálnám esetleg egy másik verziójú MPLAB-ban szimulálni, vagy kiszámolni egy olyan "utóosztást" a megszakításra, hogy egyik lábat másodpercenként billentse át. Így megtudod, hogy a szimulátor jó vagy sem.
Próbáld azt a debug módot törölni a config-ban, ha netán be van állítva most, majd az MPLAB beállítja ha kell neki! Nekem bajt okozott a működésben, mikor engedélyeztem, igaz az egy 18F-en volt!
Megvan! A szimulátor volt a hibás. Debuggolva pörög a számláló a Watch ablakban rendesen. Mondjuk így nem engedi átírni manuálisan a TMR1 értékét, de a CCPR3-ét igen. Ha megállítom a program futását és a CCPR3-ba azt a számot írom ami épp a TMR1-ben van, majd léptetek egyet akkor a TMR1 nullázódik. Szóval idáig rendben van, viszont megszakítás nem történik!
Ezeket állítottam be:
Próbálj egyel nagyobb értéket írni a CCPR3-ba.
Megtettem, 1-el nagyobb számot írtam a CCPR3-ba mint ami a TMR1-ben volt, majd tovább léptettem. A TMR1 a léptetés után nulla lett majd 2, 4 stb... (A goto$ ciklusban ugye.)
De megszakítás nem történt.
Viszont egyszer történik megszakítás! Lefordítom a programot, beégetem, majd elindítom és egyszer belép a megszakításba CCP3IF miatt, majd lekezeli a megszakítást és kilép. Utána viszont soha többé nem lép bele a megszakításba.
Megvan! Ez aztán az érdekes! A megszakítás így néz ki:
A hiba pedig a következő volt; hogy töröltem a PIE4 regiszter CCP3IF bitjét. Ugyanis ilyen nem létezik! A CCP3IF bit nem a PIE4-ben, hanem a PIR4-ben van (rosszul írtam). A fordító bezzeg nem sírt hogy nincs ilyen, hanem helyette amikor és ezt írtam:
Akkor valójában ő ezt csinálta:
Tehát nem a flagbitet hanem az engedélyezés bitet törölte a bolond. 
Ez ilyen sajnos, nekünk kell figyelni erre!
Érdemes deffiniálni saját neveket, mert akkor csak egy helyen kell odafigyelni!
Kedves fórum társak! Az alábbiakban kérnék srgítséget: A mellékelt forráskód PIC16F88-ra lett írva. A kérdésem az lenne, hogy változtatás nélkül PIC16F628-ba betöltve működne-e? Ha nem, mit kellene átírni benne? Hogy mit is szeretnék megépíteni a következő linken látható. Bővebben: Link
Idézet: „A hiba pedig a következő volt; hogy töröltem a PIE4 regiszter CCP3IF bitjét. Ugyanis ilyen nem létezik! A CCP3IF bit nem a PIE4-ben, hanem a PIR4-ben van (rosszul írtam). A fordító bezzeg nem sírt hogy nincs ilyen” A fordito errol nem tehet! A fordito nem lat neveket, csak szamokat, ugyanis ezek #define ill EQU -kent vannak letarolva es ezeket az elofordito (preprocessor) atalakitja szamokka. A forditonak tehat nincs lehetosege ilyen tipusu hibak felderitesere, igy ne azt okold. Nem tudom PIC ASM-hez letezik-e mar ilyen megoldas, de lint vagy plint -tel elmeletileg ki lehetne derinteni ilyen jellegu hibakat. Korul kellene nezni hatha a gnupic-esek csinaltak mar ilyet. Idézet: Termeszetesen nem. Mivel a ket PIC kozott igen sok kulonbseg van, ezert az inicializalo reszeket ertelem szerint at kell irni a F628 periferiaihoz. „A kérdésem az lenne, hogy változtatás nélkül PIC16F628-ba betöltve működne-e?”
Ez nézőpont kérdése. Én tudnék olyan fordítót írni, ami felismeri ezeket az összefüggéseket. Persze eszembe se jutna nekiállni!
Persze, hogy lehet ilyet irni -- es vannak is ilyenek, C-ben pl ha bitfieldet hasznalsz, azt sem tudod mas portra vagy regiszterre emelni
A programozas elso szamu torvenye:
A program UTASITASAID es nem kivansagaid szerint mukodik. Ha nem jot irtal, ne a forditot okold. Ha harom felest kertel, de kettot akartal mondani, nem a csapos a hulye, ha harmat ad.  Idézet: „Ha harom felest kertel, de kettot akartal mondani, nem a csapos a hulye, ha harmat ad.” Ez pontosan igy van! Ambar ha kettot kersz es harmat akartal mondani akkor a csapos nagyon hulye tud lenni -- foleg ugy hajnal 3 korul 
Nem, most az történt hogy kértem három felest és a pultos meg nem szólt hogy igazából ez egy virágbolt. Inkább adott három szál rózsát.
Én is hibáztam, de a fordító is szólhatott volna hogy valami nem stimmel, de ne csinálja már azt hogy ha olyan nincs akkor helyette random megváltoztat valami más bitet.
De nem random es nem is valtoztatott meg semmit sem. Ha mar analogianal tartunk, ahogy a fordito mukodik:
Bemegy a Tescoba, es mirelit hasab burgonyat akarsz venni. Annyit tudsz, hogy MIRELIT, HASAB; Namost, ezt a fordito nem tudja ertelmezni, ezert az elofordito szepen lecsereli a neveket szamokra: MIRELIT EQU 15; HASAB EQU 6; Tehat a fordito azt latja, hogy neked a 15-os folyosorol kell a 6-os polc. Namost, ha te azt irod, hogy MIRELIT, HAJFESTEK; akkor az elofordito azt mondja, hogy 15, es a HAJFESTEK EQU 8 miatt azt, hogy 8... A fordito meg boldog, hogy te a 15-os folyosobol a 8-adik pocra vagy kivancsi. Az ot nem edekli, hogy ott sem nem a hajfestek, sem pedig a hasab burgonya nincsen, az majd neked lesz a bajod
Igazából a fordító számára CCP3IF is egy szám, meg a CCP3IE is egy szám. Sőt a PIR4, és a PIE4 is csak egy szám.
Abban a .h fileban van meghatározva hogy melyik névhez milyen szám tartozik, aminek a neve egyezik a pic típusával. Próbáld ki BCF PIR4, CCP3IF helyett: BCF 0x0FB7, 0 Elvileg mennie kell, ha nem néztem el a címeket
Ja... én azt gondoltam hogy a regiszter nevét és a bit nevét egyként kezeli.
|
Bejelentkezés
Hirdetés |
