Fórum témák
» Több friss téma |
Sziasztok!
Van-e a Microchip C18-ban direktíva arra, hogy adatokat helyezzek el az EEPROM-ban ( pl. asm-ben DE ) ? Steve
Gondolom a #pragma romdata, és a cím megadása megteszi. Bővebben: Link
Üdv.
Az lenne a kérdésem, hogy hogyan lehet (ha egyáltalán lehet) a C18 fordítóból kikényszeríteni, hogy egy egyetlen char paraméterrel redelkező függvény paraméterét WREG regiszterben adja át?
Ha jól értem a feladatot, akkor így:
Bővebben: Link Megjegyzés: A paraméter átadása a veremtárban történik,a fenti utasításokkal lehet elővenni a veremkeret-mutató felhasználásával.
Arra gondoltam, hogy a fordítót utasítani arra, hogy WREG regisztert használja paraméterátadásra, verem helyett, ha az eljárásban nincs szükség veremre. Static módosítóval nem veremben adja át a paramétert, és ezért nem is generál verem kezelő kódot, mivel lokális változója sincs az eljárásnak, de arra nem jön rá, hogy WREG-ben is átadhatná.
Ez az eljárás:
(Ami már nem a paraméterátadáshoz tartozik, hogy a 0200 címen található utasítás teljesen és egyértelműen fölösleges, de ezt a txb változó volatile módosítója hatására teszi oda.)
Van még egy kérdésem.
Az előzőre úgy sejtem, az a helyes válasz, hogy ennyire nem lehet beleszólni a compiler dolgába. Próbáltam keresni ebben a topic-ban a ment, visszaállít, megőriz szavakra, de nem sokat találtam arról, amit tudni szeretnék. Melyik regiszterek tartalmát kell megőrizni a C-ből hívott assembly rutinokban? Vegyesen írok programot C-ben és assemblyben (nem betétként, hanem külön fájlban, majd az object fájlokat linkerrel összeszerkesztve) Az világos, hogy a szoftveres adat vermet rendben kell tartani, de ezen kívül, ha használni szeretném FSR0, TBLPTR regisztereket, és az ezekhez tartozó egyéb regisztereket, akkor azokat kell-e menteni és helyreállítani? Elvárja-e ezek megőrzését a C fordító normál (nem megszakításkezelő) eljárásoktól és függvényektől? C18-at és MPASM-et használok. Köszönöm icserny előző válaszát, arra a tudásra is szükségem lesz (habár azt már elolvastam a "C18 user guide"-ban, de magyarul mégiscsak egyszerűbb)
Én nem ismerem annyira a fordítót, hogy belelássak, észre veszi-e, hogy az asm betétben milyen regisztereket használsz és annak megfelelően gondoskodik-e a kényes regiszterek mentéséről, de egy szimuláció ezt könnyen kiderítheti.
Írsz egy olyan C forrást, amiben az FSR, vagy a TBLPTR befordításra kerül, majd beleszúrsz egy asm betétet, amiben használod ezeket. Megnézed mit fordított. Ha lesz a fordított asm listában mentés a kérdéses regiszterekről, akkor nagyon okos a fordító! Ezen nagyon meglepődnék! 
Úgy tudom, hogy a visszaadott eredmény méretétől függően W, PRODL
RODH és FSR0 szolgálnak az eredmény visszaadására, tehát ebből következően nem tárolhatnak megőrzendő értéket, felülírhatók.
Azon én is meglepődnék, ha assembly betétbe belenézne, de jelen esetben ezt biztos nem teszi meg, mert külön object fájlba fordítódik külön asm fájlból az assembly függvény, ráadásul előbb fordítja a C fájlt, az után az ASM fájlt. Ettől függetlenül lehet, hogy az eljárások szabadon módosíthatják TBLPTR, TABLAT és FSR0 értékét, úgyhogy marad a próbakód+disassembly.
Illetve az a felvetés ellenőrzése, amit icserny 'nagymester' írt. Ha valóban nem tárolnak infókat bennük, akkor szabadon módosíthatóak. Ezt is le lehet ellenőrizni szimulációval.
Bocs, én PRODL : PRODH-t akartam írni az előző beírásomban, csak a fórummotor túlbuzgóságból vigyori pofát csinált belőle.
Sziasztok!
Próbálkozom icserny Bővebben: Link leírása alapján az LCD ( és a többi ) könyvtár újrafordításával, de valami nem jó: az LCD-re kiíráskor
Steve
Meg kellene nézni a függvény deklarációját, include-jat, már ha egyáltalán beincludolod. Nincs se hibaüzi se warning rá? ugye a string jöhet a ram-ból meg a flash-ból is, ezért lényeges a deklaráció a programod elején
Szerintem ilyen gond nem lehet: a fv. deklaráció is megvan. A fordításnál lehet valami opciós probléma ( ha a fv-t beépítem a projektbe, akkor lefordítja és azt használja --> így jól működik! ). Hibaüzenet, warning nincs!
A string egyébként ilyen parancsnál ( amit írtam ) a ROM-ban helyezkedik el tudtommal. Köszi a segítő szándékot, ha van bármi ötleted, akkor várom... Steve Idézet: Lehet, hogy pont ezt? A gyári könyvtárak ugyanis LARGE opciókkal vannak fordítva. De a fordító pampogásán kívül ez nálam nem szokott gondot okozni.„A projekt beállításnál SMALL van kiválasztva. Mit állítok be rosszul?!” Idézet: Ennek így is kell lennie, ügyanis a függvény deklarációjában szerepela "rom" módosító, ami 24 bites mutatót jelent:„putrsXLCD("ZORRO"); valami nagy mutatót ad át” void putrsXLCD(const rom char *); Idézet: Arra vigyázni kell a gyári könyvtár újrafordításánál, hogy a réhi és az új (módosított állományok) ne keveredjenek össze! Ha az alkalmazás fordításakor az új library és a régi header kerül becsatolásra, akkor nem fog működni. Legbölcsebb a régi változatot elmenteni, és minden módosított állomány lecserélni (.lib, .h). Ha csak az LCD-vel kapcsolatos állományok módosultak, akkor a c018.o állományt nem szükséges lecserélni. „Szerintem ilyen gond nem lehet: a fv. deklaráció is megvan.”
Szia!
Mellékelem, hogy mit látok... A Jó_LCD-nél a projekthez csatoltam a putrxLCD-t és így fordítottam ( ezért azt újrafordítja ! ), a rossznál az általad leírt módszerrel lefordítottam és beraktam a könyvtárba. Az xlcd.h biztosan jó, mert a 2 soros üzemmód és a villogó kurzor megjelenik, csak a szövegkiírás marad el a rossz mutató miatt! Látszik, hogy a jó mutató valóban jó helyre mutat, a másik meg nem is létező helyre ( a PIC-en belül! )! A LARGE opciót kipróbáltam, a hibajelenség megmaradt. Steve
Ha a szöveget a RAM-ba teszem és a
 !?Steve
A rossz változatnál nekem úgy tűnik, hogy csak két bájtos címet kap, és hozzáolvas egy harmadik bájtot, aminek semmi köze a címzéshez.
A könyvtár és az alkalmazás tehát láthatóan különböző memória modell beállítással volt fordítva. A projekt opcióknál a C18 code model: Large (> 64K) beállítással próbálkoztál? Annak jónak kellene lennie! Ha a könyvtárak forrását becsatolod a projektbe, akkor nyilvánvalóan konzisztens lesz a fordítás, akármilyen memória modellt választasz.
A rossz változatnál engem semmi nem emlékeztet a jó címre, Te hol látod az 1 hibás byte-ot?!
A LARGE-ot az előbb próbáltam ( írtam! ), most újra, de nem jó! Steve
Most néztem meg, hogy végül is kell-e vigyázni FSR0 értékére, ha C-ből assembly függvényt hívok. Egy egyszerű ciklust írtam C-ben, ami csupán egy tömböt nulláz, ha semmi függvényhívás nincs benne, akkor is mindig újratölti FSR0-t a mutató értékével, hiába van bekapcsolva minden optimalizálás. Ez alapján arra következtetek, hogy a függvényeknek csak arra kell vigyázniuk hogy maguk után rendben hagyják a vermet.
Ha a próbaidő letelte csak a kiterjesztett utasításkészletet és a procedurális absztrakciót tiltja le akkor ez a C18 fordító még nagyon gyerekcipőben jár (legalábbis a 3.36-os verzió, amit használok), hiszen egy unsigned short változó növelését sem a legrövidebb úton oldja meg. Idézet: A szöveged a 03FA címen van, ha jól látom, s a pointered átvett értéke is tartalmazza ezt a két bájtot, csak van utána egy fölösleges 0x01 bájt.„A rossz változatnál engem semmi nem emlékeztet a jó címre” A szubrutin meghívásának (putrsXLCD("ZORRO"); hogy néz ki a disassembly listája LARGE modell esetén?
Nálam ez a különbség: SMALL modell esetén kétbájtos, LARGE modell estén hárombájtos cím kerül átadásra.
Aha, igazad lehet, én előtte néztem a roszat...
Megcsináltam amit kértél, hátha Te észreveszed a problémát! Steve
Most látom, hogy mire gondoltál, mindjárt megnézem...
Itt van akkor a megfelelő részlet... Itt úgy látom, csak 2 byte-ot ad át!?
De nem értem, hogy miért adnak át adott esetben 3 byte-ot, ha az adott PIC-nél max. 2 byte a ROM címe ?! Steve Idézet: Ez elég érdekes! Tudniillik így nem fog működni...„Itt úgy látom, csak 2 byte-ot ad át!?” Idézet: A fordítót nem izgatja az adott PIC memória-mérete, az majd a linkelésnél derül ki.„De nem értem, hogy miért adnak át adott esetben 3 byte-ot, ha az adott PIC-nél max. 2 byte a ROM címe ?!” Mellesleg a konfigurációs bitek, az EEPROM, az eszközazonosító és a felhasználói azonosító akkor is 24 bites címzést igényel, ha a memória kisebb, vagy egyenlő mint 64 kbyte. A könyvtárakat pedig azért fordítják gyárilag LARGE modellel, mert nincs külön batch fájl a 128 kbites típusokhoz.
HI-TECH-ben hogyan tudom megadni a fordítónak, hogy programozáskor töltse fel az eepromot bizonyos adattal? Gondolok itt arra, hogy pl. az eeprom első byte-jában legyen 1, a másodikban 5, harmadikban 7, stb., és ezt csak programozáskor írja bele. Tudom, hogy programozás előtt direktbe át tudom írni az eeprom regisztereit, és azt tölti be, de nekem a programba kellene ezt megmondanom.
|
Bejelentkezés
Hirdetés |
