Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Sziasztok, segítséget szeretnék kérni. Biztosan már többen találkoztatok a problémával...Íme:
Általában 16F876A-t használok. A megírt program hossz még nem lépi túl a bankhatárt, sőt meg sem közelíti. A programban van kb. 25 szubrutin, rövidebbek, hosszabbak. Egy karakteres kijelzőt kezelgetne sok egyéb mellett. Van hogy a tökéletesen működik, de van hogy nem. Ilyenkor simán a szubrutinok sorrendjének a megváltoztatása megoldja a problémát. Ha nem az első átrendezés, akkor a második. Nem a végrehajtás sorrendjét változtatom, hanem egyszerűen a szerkesztőben elfoglalt helyét. A hibás működés úgy jelentkezik, hogy a kijelzőn mindenféle karakter kezd el rohangálni. Eddig megoldottam az átrendezéssel, de most már kezd idegesíteni, hogy nem tudom, hogy mi történik...Előre is köszi a hozzászólásokat! Üdv! The_Saint Idézet: „NSTDIS: Interrupt Nesting Disable bit” Itt érdemes nézelődni: Angol-magyar informatikai szótár A nesting interrupt hasonló, mint a nesting loop (egymásba ágyazott ciklusok), mivel a magasabb prioritású megszakítás kiszolgálása "beleágyazódik" az alacsonyabb prioritású megszakítás kiszolgálásába. Ez a beágyazódás azonban letiltható az INTCON regiszter NSTDIS bitjének '1'-be állításával. Az interruptok egymásba ágyazásának letiltásakor minden felhasználói interrupt 7-es prioritásszinten fut, ami megakadályozza, hogy bármilyen további felhasználói interrupt érvényesülhessen, mielőtt az aktuális megszakítás kiszolgálása befejeződik. Ezen kívül IPL<2:0> csak olvasható válik (nem módosítható a futási prioritásszint), s az interrupt prioritások csak arra szolgálnak, hogy az egyidejű kérelmek érvényesülési sorrendjét megszabják.
A regiszterbankok kezelését és a lapváltásokat érdemes átnézned és sűrűn használgatni a banksel makrót. Ha kísérletezős kedvű vagy, akkor az egyes szubrutinok elé szúrd be az org xxxxh sort, természetesen az xxxx helyére egy-egy önálló memóriacím kerüljön. Érdemes még megnézni a fordítás végén kapott .map fájlt, mert abból kiderülhet, hogy esetleg a programoddal átlépted az első memórialapot a programtárban. Ilyenkor már illene használni a pagesel makrót is. Ha van a programodban indirekt regiszterhasználat, akkor még a bankisel makrót is előveheted.
Kb. ennyit láttatlanban. Az biztos, hogy a hiba ki fog derülni, ha foglalkozol a problémával.
Szia!
A programodban szerepel a "movf PCL" vagy az "addwf PCL,f" , azaz a programszámlálót módosító kiszámított ugrás. Az ugrás egy táblázat (lista) elemeire ugrik, ennek a listának az elhelyezkedésével van a gond. Az egész táblázatnak egy 256 utasítás blokkban kell lennie, azaz a kezdőcím és a végcím felső byte-jának meg kell egyeznie - Ha nem egyezne meg, akkor a PCLATH regiszteri is kezelni kellene az ugrás címének kiszámításakor...
Idézet: „A programodban szerepel a "movf PCL" vagy az "addwf PCL,f" , azaz a programszámlálót módosító kiszámított ugrás.” Ezt honnan tudtad? Így könnyű!  Idézet: „A megírt program hossz még nem lépi túl a bankhatárt” Csak szeretnélek kigazítani, mert nem a bankhatárról beszélsz, illetve a válaszokban sem arról esik szó, mert a bankok a RAM memóriához tartoznak, a programod a laphatárokat nem lépi át! (PAGESEL) Ha netán tényleg van a programodban táblázat, akkor a laphatárokkal van gondod. A megoldást Hp41C segítsége jelzi.
Sziasztok! Köszönöm a válaszokat mindenkinek!
Igen, szerepel az "addwf PCL,f", de elég rövid táblázatokról van szó. Egyszerre max 16 karakter. Ja és igen elírtam  laphatárra gondoltam Ime egy részlet, a teljesség igénye nélkül:
általában így néz ki egy táblázat, de max. 16 értékkel. Sajnos még mindig nem értem, hogy az átrendezés miért oldja meg a problémát. A PicKIT ben a beírásra szánt hex vége (remélem jól jelenik meg ):
A leírásból azt olvastam ki, hogy 0800H-nál kezdődik a második lap... vagy nem jól értelmezek valamit? Hp41C, köszi a kis részletet, de a C nem az erősségem...többnyire asm-ben írogatok. Bár értem, hogy mit írtál... Üdv The_Saint
Huuu... ez elég összevissza lett, de mind1, alán érthető....
Szia!
A félreértések elkerülése érdekében megemlíteném, hogy az idézett részlet assembly környezethez illeszkedik. Azok a furcsa (if, endif, error) kulcsszavak az MPASM direktívái. Ha a részt beleteszed a programodba (minden táblázathoz - természetesen átírva), és a változtatások miatt a táblázataid (akármilyen rövidek is) a 256 utasítás blokk határt átlépnék, a fordítás hibára futna. A hibajelzére kattintva, a hiba helyére lehet ugrani a forrásban... Az error sorba nem kellenek a zárójelek - Elnézést elírtam..
Nem ismertem a kérdéses programot...
Mi másért lenne jó az egyik sorrendben és hibásan lefutó egy másik sorrendben a program? A különböző lapokon definiált címkék keveréséből származó hibát a kérdés kizárta. Idézet: Bizony nem, mert a PCL csak 8 bites, tehát annak minden túlcsordulása PCLATH módosítását igényelné (ennek hiányában rossz helyre ugrik a program). „A leírásból azt olvastam ki, hogy 0800H-nál kezdődik a második lap... vagy nem jól értelmezek valamit?”
Huu...köszi, ezt eddig nem tudtam. De tényleg! Így mindjárt más! Tényleg köszi!
 Utoljára a TurboPascal-ban találkoztam a "furcsa" kulcsszavakkal, meg talán pár éve php-ben Annyira mélységeiben nem ismerem az MPASM lehetőségeit.... gondolom meglepődnék, mi mindent tud még...
Szia,
ezt kifejtenéd bővebben? Tehát az ugrás nem lehet messzebb mint 8 bit? Tehát ha a call pl. 0x100H on van és ha a cél 0x0208 on akkor ez hibát okoz? Vagy még mindig nagyon messze járok? Üdv The_Saint
Én az alábbi struktúrákról beszéltem:
A CALL/GOTO utasításnál egészen más a helyzet, ott van a 2K-s laphatár.
Szia
átnéztem a programod és a meglévő programohoz sok helyen kéne belenyulnom, énmeg ugye lusta vagyok . Annyit sikerült elérnem hogy közvetlenül olvasás előtt és után állítgatom a CREN bitet és egy tömbbe olvasom a bejövő adatokat. Viszont ami nem megy (illetve megy csak nem ugy ahogy szeretném .. ) az a putch , és putst fv-ek. Elvileg az egy alapfüggvény nem? Michrochip honlapon található samplek között találtam egy progit amivel a soros portos kommunikációt nyomon követem, Terminal v1.9b a neve ha valakinek ismerős. Namost a transmit és recive ablakban szépen ugyanazt látom, tehát amit elküldök a PICnek az vissza is jön, és a pic fogadja is mert szépen eltárolja és dolgozik vele, de pl válaszüzenetet nem látok egyik ablakban sem. Még a sima putch() fv-t se nemhogy valami karaktersorozatból álló szöveget (putst...). Elvileg a serial jol van inicializálva. A program rosz vagy a PIC nem kezeli tul jol ezeket a fv-eket?
Ok, kezd összeállni a kép
Tehát ha PCL éppen mondjuk 253, én meg pont a 10. karaktert akarnám beolvasni, akkor túlcsordul, mert ugye 253+10...az sok. Idézet: „minden túlcsordulása PCLATH módosítását igényelné (ennek hiányában rossz helyre ugrik a program).” ebben segíts még kérlek, ezt hogy kell csinálni? Előre is köszi! .... hm... és mi lesz a visszatérésnél? Hhhh....  lettem volna inkább a halászok detektívje!!
Ebben a hozzászólásban már megkaptad a segítséget. Ha használod azokat a direktívákat minden táblázatnál, akkor a fordító visítani fog, ha rossz helyre került a táblázatod.
Idézet: Én legaláb annyira lusta vagyok, tehát ha a saját fejed után mégy, akkor magadra leszel utalva. „a meglévő programohoz sok helyen kéne belenyulnom, énmeg ugye lusta vagyok.”  Idézet: „Viszont ami nem megy ... az a putch , és putst fv-ek. Elvileg az egy alapfüggvény nem?” Nem. Bizonyos könyvtári függvényeid lesznek stdio.h és a p18f2420.lib becsatolása után, de abban nem tudok ilyen nevűeket. Van viszont putc() és puts() nevű. Ezek csak akkor fognak értelmes dolgot csinálni, ha vagy fölüldefiniálod az _usart_putc() függvényt (én ezt teszem...), vagy a nem interruptos gyári Open1USART() függvénnyel kell megnyitni a soros portot. A "gyári" függvények között nincsen getc() függvény, helyette Read1USART()-tal és gets1USART()-tal lehet próbálkozni.
Szia!
A tálbázat címének felső byte-ját töltsd be a PCLATH regiszterbe, eztán az alsó byte és a index összeadásának eredményét a W -be képezd, ha túlcsordulás keletkezik, növeld a PCLATH értékét. Ezután a W -t beírhatod a PCL-be. Ha az index is hosszabb 8 bitnél, akkor az index felső byte-ját és a táblázat címének felső byte-jának összegét töltsd be a PCLATH regiszterbe. A többi lépés nem változik. A visszatérés nem gond, a belső stack mind a 13 bitre emlékszik, onnan az egész cím kerül át a programszámlálóba.
Jó annyira nem vagyok lusta
Nagyon szivesen veszem a segitséget és nem várom el h megcsinálják helyettem.Lehet könyebb lesz ha leirok pár sort a programbol Tehát : void init_comms(void) { INTCONbits.INT0IE = 0; INTCONbits.RBIE = 0; INTCONbits.GIEH=1; INTCONbits.GIEL=1; INTCON2bits.RBPU = 0; RCONbits.IPEN = 0; SPBRG = 31; TXSTA = 0x26; RCSTA = 0x90; DDRCbits.RC6=0; DDRCbits.RC7=1; } Putch és getch fv-ek is elővadászva: void putch(unsigned char byte) { /* output one byte */ while(!TXSTAbits.TRMT) /* set whilst TX in progress */ continue; TXREG = byte; } unsigned char getch() { /* retrieve one byte */ while(!PIR1bits.RCIF) /* set when register is not empty */ continue; return RCREG; } void putst(register const char *str) { while((*str)!=0) { putch(*str); if (*str==13) putch(10); if (*str==10) putch(13); str++; } } Ez a putst pedig elvileg szöveg kiirásra van . Namost ha én ezekbe a kis rutinokba egy ledvisszajelzést is rakok akkor látni hogy valami történt szoval meghivja a főprogram őket, és az adatvétellel nincs is gondja a PICnek , szépen sikerül letárolni és feldolgozni , de ha már valamit küldenék akkor a használt progi nem nagyon jelzi ezt nekem, se hyperterminal se más. Lehet nem a TRMT bitre kéne figyelni a TXREG feltöltés előtt?
Küldés engedélyezéséhez az alábbi beállításokra van szükség (a baudrate beállításán kívül):
• bit SPEN (RCSTA<7>) must be set (= 1) • bit TXEN (TXSTA<5>) must be set (= 1) • bit TRISC<7> must be set (= 1) • bit TRISC<6> must be set (= 1) Ha a program túljut a while(!TXSTAbits.TRMT); feltételen (nem kell oda continue, csak pontosvessző!), akkor a PICkit2 logikai analizátor módjában megnézheted, hogy a TXREG = byte; hatására kimegy-e az impulzussorozat.
Ezek is megvannak az IO_init-ben , mármint a port beállitás.
A pickites analizálást reggelt tudom meglesni de köszönöm a tippet. Addig elméleti gondolkodás megy tovább
Hp41C-t kiegeszitve: Ugy kell tekinteni mint egy 16 bites aritmetikat, ahol a felso 8 bit a PCLATH-ba kerul, mig az also a PCL-be. Csupan arra kell figyelned, hogy mikor a PCL-be toltod az erteket akkor a program szamlalo azonnal frissul a PCLATH es PCL ertekekkel, igy annak kell a leges-legutolso muveletnek lennie! (Magyaran, hogy elkeruld az ido elotti, rossz cimre torteno ugrast...)
Sziasztok!
Csinálok egy külső-belső hőmérsékletet mérő ketyerét. A problémám a következő lenne, hogy az LM35-ös hőmérő IC kimenete feszültség, ezt kötöttem az PIC18F45K20 A/D bemenetére. Pozitív hőmérsékletnél csodálatosan működik, viszont negatív hőmérsékletnél, negatív feszültség a kimenet. Próbálkoztam, hogy -5V-ot adok a -Vref lábnak, de azzal nem működött, így arra gondoltam, hogy 0,5V-al megemelném a jeladó kimeneti jelét és akkor a PIC nem kap soha negatív feszt, csak pozitívat azt meg tudja mérni gond nélkül. A tanácsotokat kérném, hogy milyen konkrét áramköri megoldással oldanátok meg a +500mV-al való emelést? Köszi! LAC
Köszönöm mindenkinek a segítséget...megküzdök vele
Üdv The_Saint
Szia!
Az adatlapon a figure 7. szerint... P_Istvánnak: Egyszerre írtuk, majd egzszerre töröltük... |
Bejelentkezés
Hirdetés |
