Fórum témák
» Több friss téma |
Mi a hiba IC-tipusa PIC16F84A
A forditó régi PICCLITE . Fordításkor (paransc: Picl -o Zg9 -16F84 -v lcdterm6.c) a hibaüzenet __CONFIG(WDTDIS & XT & UNPROTECT) Undefined symbol XT (error) undefined symbol WDTDIS #include <pic.h> //__CONFIG(WDTDIS & HS & UNPROTECT); //this is for HS (more than 4 megahertz) oscillator __CONFIG(WDTDIS & XT & UNPROTECT); //this is for XT (4 megahertz or less) oscillator // Watchdog timer would be | 0x04 but I'm not using it
Nincs definiálva WDTDIS szimbólum. Keresd meg a h fájlokban, hogy minek hívják pontosan a watchdog kikapcsolását beállító szimbólumot.
A hozzászólás módosítva: Okt 30, 2014
Ezt találtam
#if defined(_16F84) || defined(_16F84A) || defined(_16C84) #include <pic1684.h> #endif #define CLRWDT() asm(" clrwdt") #define ___mkstr1(x) #x #define ___mkstr(x) ___mkstr1(x) #define __CONFIG(x) asm("\tpsect config,class=CODE,delta=2");\ asm("\tglobal\tconfig_word"); \ asm("config_word"); \ asm("\tdw "___mkstr(x)) #define CONFIG_ADDR 0x2007 #define FOSC0 0x01 #define FOSC1 0x02 #define WDTE 0x04 #define PWRTE 0x08
Még ezt találtam
/*osc configurations*/ #define RC 0x3FFF // resistor/capacitor #define HS 0x3FFE // high speed crystal/resonator #define XT 0x3FFD // crystal/resonator #define LP 0x3FFC // low power crystal/resonator /*watchdog*/ #define WDTEN 0x3FFF // enable watchdog timer #define WDTDIS 0x3FFB // disable watchdog timer
Hát elvileg ott van a szimbólum. Akkor nem látja a fordító a h-t. ?
Az a baj, hogy nem ismerem a PICCLITE szintaktikáját, de a hibaüzenet az erre utal.
Üdv!
XC8 alatt van valami különbség a Nop(), és az asm("nop") utasítás között, vagy egyformán fordítja a fordító? Tudom, ki is próbálhatnám, de itt nincs fenn mplab, és nem akarok telepíteni. A hozzászólás módosítva: Nov 11, 2014
A C18 -ból kiindulva lesz különbség: Nem optimalizálja azokat a függvényeket, amelyben asm() (( C18 -ban _asm .. _endasm )) van.
Értem. köszönöm. Akkor a C-függvényt fogom használni.
Hello!
Következő kérdés merült fel. Szeretnék egy soros vonali meghajtót vezérelni. 2 kimenet: órajel, és adat. Az órajellel nincs semmi bajom, mert annak megadom, hogy 0 vagy 1. Adat kimenettel van gondom.
ez a soros kiíró függvényem. Ebből a seg_data=outputbit-et így fordítja az xc8:
Meg tudom adni olyan formában C-ben, hogy ne két vizsgálatra fordítsa csak egyre?
Nos .. Igen. Ezektől olyan terjengős és lassú a C -ből fordított kód...
vagy
Hiszen assemblyben csak 4 utasítás:
A hozzászólás módosítva: Nov 13, 2014
Köszönöm. Sajnos azt a sort mindenképpen úgy fordítja.
Na mindegy, remélem belefér az időzítésbe az a plusz néhány ciklus.
Miert van benne az outputbit valtozo? Nem jobb kodot fordit, ha ugy csinalod, ahogy Hp41C mondja? Mert ha belegondolsz, hogy gyors kodot akarsz irni, es a ciklusban allandoan shiftelgeted a seg_byte-ot, az eleve rettento pazarlas.
Persze ettol nem biztos, hogy jobb kodot fordit. Lehet, hogy tenyleg az if()-es megoldas a jobb:
Idézet: Mermint miktol? Adott egy valtozo (outputbit), aminek erteke 0 vagy 1 lehet. Ezt bemasolni egy bitfield-be (seg_data), nem kellene ilyen hosszu assembly legyen. Ez a fordito hibaja. Vagy te is erre gondoltal? Egy rendes fordito latja, hogy 0-ra 0, 1-re 1 kell menjen a seg_data-ba. Ehhez nem kellene ketszer a BitTest. „Nos .. Igen. Ezektől olyan terjengős és lassú a C -ből fordított kód...”
Főleg a teljesen felesleges bra utasításokra gondoltam.
Többféle megközelítés lehetséges a bitfield -be való másoláskor: - Kitörli és ha egyre kell állítani, akkor beállítja. Ha ez port a kimeneti regiszter, akkor létrejöhet egy rövid impulzus, ami hibás működéshez vezethet. (bcf / btfsc / bsf) - Csak akkor törli ki, ha eddig 1 volt és most 0 kell legyen és akkor állítja be, ha 0 volt és most 1 -re kell állítani. Ilyenkor nincs zavaró jelátmenet, de lassabb a beállítas. (btfss / bcf / btfsc / bsf) - Megnézzük miben tér el a már beállított a most beállítandótól és az eltérő biteket megnegáljuk. (xor / and / xor) stb. Továbbá a logikai érték beállítása, másolása sokkal hosszabb kódot állít elő, mint a feltételes utasítás. Ugyanis a feltételt (egy változó 1 bitjét) lelépteti a 0. bitre, majd vissza arra a helyiértékre, amit a rendeltetés bitpozíciója... Ez az assembly program írójának eszébe sem jut. Persze a C program írója is sokat tehet a kód rövidítésére. A fenti példában a ciklusban 8 -szor történik változó számú bittel való léptetés (seg_byte >> i). Sajnos a PIC nem képes ilyen műveletre, hanem ciklussal valósítja meg. Ez lassú, ráadásul változó idővel fut le. És teljesen felesleges, kiváltható ciklusonként 1 darab 1 bittel történő (1 utasítással megvalósítható) léptetéssel. Idézet: Hat igen. Ez a fordito hibaja, ez ketsegtelen.„Főleg a teljesen felesleges bra utasításokra gondoltam.” Idézet: A forditonak nincs sok lehetosege, ha az adott bitfield volatile tipusu, marpedig egy hardware regiszter az annak van deklaralva. Nem olvashatja ki, es csak egyszer irhat bele a muvelet soran, mert a C kodban is egy ertekadas szerepel.„Többféle megközelítés lehetséges a bitfield -be való másoláskor:” Idézet: Hat, ez a bemasolt kodban nem igy nezett ki. Nem shiftelt az semmit, csak volt benne ket felesleges BRA. De amugy vizsgalta a legalso bitet, es attol fuggoen beallitotta vagy torolte a 7-es bitet a port regiszterben.„Továbbá a logikai érték beállítása, másolása sokkal hosszabb kódot állít elő, mint a feltételes utasítás. Ugyanis a feltételt (egy változó 1 bitjét) lelépteti a 0. bitre, majd vissza arra a helyiértékre, amit a rendeltetés bitpozíciója... Ez az assembly program írójának eszébe sem jut.” Idézet: Igen, ezt en is lattam. „Persze a C program írója is sokat tehet a kód rövidítésére. A fenti példában a ciklusban 8 -szor történik változó számú bittel való léptetés (seg_byte >> i).”
Sziasztok!
A Microchip XC-8 fordítóprogramot használom az MPLABX IDE-vel. Hogy megbizonyosodjak róla, hogy a nyákon minden rendben van, írtam egy ledvillogtató programot, de nem működik. Hosszan hibakeresés után rájöttem, hogy a fordító egyszerűen nem azt csinálja, ami a C kódban szerepel. Összecseréli a PORT és TRIS regisztereket. (lásd a képet) Amikor megláttam, teljesen ledöbbentem. Kipróbáltam mindent: kikapcsoltam minden optimalizálást, megpróbáltam assembly kódot beszúrni a C kódba, de semmi sem segített. Régebben nem volt ilyen probléma. Hogyan tudom kiküszöbölni ezt a csúnya bug-ot? Emiatt képtelen vagyok haladni, határidőre dolgozok. Előre is köszi a segítséget! Idézet: „Hogyan tudom kiküszöbölni ezt a csúnya bug-ot?” Ha lehet, állj át "sima" MPLAB-ra.
Régebbi, vagy újabb verziókkal lehetne megpróbálni. Ha kezeli a PIC-et a régi, akkor egyértelmű azzal.
Szia!
Rég nem programoztam már 8 bites kontrollert, de van ott a bekeretezett rész előtt egy bankváltás. Nem ugyan ott van a Portx és a Trisx csak más bankban? Mert kétlem hogy a fordítóban ilyen hibák lennének.
De, pontosan ugyanazon a címen van a PORTx és a hozzá tartozó TRISx regiszter. És igen, a MOVLB 0 kiválasztja a nullás bankot, a MOVLB 1 viszont az egyes bankot. Tehát a lefordított kód nekem jónak tűnik, csak az ablakban mutatja a rosszul.
- Ha van az utasításkészteben BRA, akkor a FSR -ek között kell lennie visszaolvasható LATx -nek.
- Ha nem olvashatja vissza, akkor a BSF és a BCF sem használható - mindkettő RMW művelet. Idézet: Ezt nem egeszen ertem.„Ha van az utasításkészteben BRA, akkor a FSR -ek között kell lennie visszaolvasható LATx -nek.” Idézet: Valoban. Ezen nem is gondolkodtam. Nem is tudna egy bitet maskepp beallitani. Ennek utanajarok, mert ez eleg erdekes. „Ha nem olvashatja vissza, akkor a BSF és a BCF sem használható - mindkettő RMW művelet.”
A Baseline és a Midrange standard családban csak PORTx regiszter van és csak a goto utasítást ismerik. A Enchanced Midrange (12F1xxx, 16F1xxx) és a 18F -eken van LATx és ismerik a bra utasítást is. Mivel az idézett forrásban bra szerepel, az utóbbiakra kellett fordulnia.
Idézet: „Ezen nem is gondolkodtam. Nem is tudna egy bitet maskepp beallitani.” - A PORTx helyett a LATx használata megoldja a problémát. - A PORTx regiszter helyett egy RAM -beli másolaton végrehajtani a műveletet és az eredményt movwf PORTx utasítással írni a portra. Ekkor a másolatot már többször is lehet írni és olvasni a másolás előtt.
Igazatok van.
Egyébként azért volt az outputbit, mert később fel akartam használni ellenőrzésre, de az most tárgytalan lett. Módosítottam rajta. Köszönöm.
Most kezdtem a PIC-el foglalkozni ...
Látom jópár programnyelv létezik, el kéne döntenem melyikkel akarok komolyabban fogalkozni. Hajlok a C nyelv felé, de látom abból is többféle van. Ezek csak a fordítóban különböznek egymástól, vagy az utasításkészletben is van eltérés?
Lehet valahogy ellenőrizni fordítási időben, hogy egy struktúra adott eleme az a struktúra utolsó eleme-e? Pl. van egy config struktúrám:
És itt jó lenne, ha már a fordító szólna, ha a crc nem az utolsó a struktúrában (mert mondjuk hozzáírtam valamit, és elfelejtettem, hogy a crc kellene, hogy az utolsó maradjon). Futásidőben egyértelmű, hogy egy
vizsgálattal leellenőrizhető, de jobb lenne, ha már eleve a fordító szólna.
Esetleg az offsetof() hasznalataval. Az forditasi idoben adja meg egy mezo relativ cimet a strukturan belul.
Csak a padding miatt nem garantalt, hogy az utolso elem cime + az utolso elem hossza az megegyezik a struktura hosszaval. 8 bites architekturan igen, de 16-on 32-n nem feltetlenul.
Kozben rajottem, hogy nem is olyan egyszeru, mert forditasi idoben ilyesmit csak az elofeldolgozoval csinaltathatsz (#if ... #error), de az nem ertekeli ki a sizeof-of meg offsetof-ot, igy nem fog menni a dolog. En nem tudok erre megoldast. Talan ezert van az, hogy a struktura definiconal oda szoktam irni, hogy !!! Ennek kell az utolsonak lennie !!!
|
Bejelentkezés
Hirdetés |
