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.

Kösz
Keresem

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 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:

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:

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.

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.

Hat igen. Ez a fordito hibaja, ez ketsegtelen.
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.
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.Igen, ezt en is lattam.

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!

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.

Ezt nem egeszen ertem.
Valoban. Ezen nem is gondolkodtam. Nem is tudna egy bitet maskepp beallitani. Ennek utanajarok, mert ez eleg erdekes.

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.

- 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 !!!