Fórum témák
» Több friss téma |
Az asm programot a c fordító generálta, csak azért fordítottam le külön, hogy lépésenként legyen nyomonkövethető.
A 900-as ROM címet az 1,2,3 RAM címekre teszi és onnan tölti fel a tábla regisztereit.
A TBLRD-vel olvassa ki a 0x900 tartalmát.
Ha még nem váltottál bankot PIC18-nál, mi a célod ezzel a kérdéssel?
Idézet: „Mik ezek a bankváltások? ”
Szerintem arra gondolt, hogy mi szükséged van rá, hogy bankot válts? Alapból 18F-nél majdnem minden megoldható enélkül is.
Hogy kinek és mikor van szüksége bankváltásra 18F -eken, azt a konkrét típus és a felhasznált adat memória mérete valamint a programnyelv és a fordító határozza meg. Sok típusban a 14. bankban is van FSR.
a movlb 0x5 a BANKED opcióval megadott utasításokat a 0x500 - 0x5FF címek közötti tartományokra végzi el. Lehet indirekten is elérni LFSR fsr0, 0x500 után pl. movwf POSTINC0,ACCESS utasítással. A movff utasítás mindkét operandus teljes 12 bites címét tartalmazza - nem kell hozzá bankváltás. Hogy tovább fárasszam a tisztelt Nagyérdeműt, a 18F -ek közés tartozik pl. a 18F57K42 is, amiben már 64 RAM bank van, a 62. és 63. a SFR terület, a GPS pedig a 0..31 bankokban található. Egy új, 3 szavas utasítás is használható movffl ami a két operandus teljes 14 bites címét tartalmazza. Ezekben nehéz lesz bankváltás nélkül programozni.
Nem, a 0x900-on 00 van, a 0x901-en van az 5. Az 1 2 3-as címen a pointer van, a táblázat értékeit a fordító közvetlenül beírja, hiszen konstans.
A hozzászólás módosítva: Nov 26, 2017
Tényeken nem érdemes vitatkozni.
Az 1,2,3 RAM címen az a pointer van, ami a 0x900 ROM cím.
Talán olvass vissza és megérted miről van szó.
Pontosan, ha ez még a 18F25K40, az 8 bites, az asm-ben a MOVFF TABLAT, LATA a csak a 900 címen levő bájtot mozgatja, ami 0x00.
Sziasztok!
Valaki tudna segíteni PIC assembly programozásban? Nagyon sürgős lenne. Előre is köszönöm!
Mi a kérdés?
Bell problémájára én a globális változókat a RAM ban képzeltem el.
Nem néztem, hogy az általa használt PIC nek a címzése, hogy van. Ha a változónak, mikor mi lenne az értéke, minek lenne máshol a helye, mint RAM vagy esetleg EEPROM, ha tényleg ott a helye ? Deha a RAMban, akkor jók a MOV utasítások. A hozzászólás módosítva: Nov 26, 2017
A globális változó csak annyit takar, hogy bármelyik függvényből hozzáférhetünk a változóhoz, és a program futása alatt mindvégig létezik. A PIC-ek a const változókat a memória ROM területén helyezik el (régen a C18 fordítóban még a változó minősítése is 'rom' volt erre a célra), mert teljesen felesleges az igencsak szűkös RAM-ba másolni ezeket, hiszen úgy sem akarjuk az értéküket megváltoztatni. Az egy másik kérdés, hogy a 8bites PIC-eken teljesen más módon lehet hozzáférni az így létrehozott konstansokhoz, mint a sima RAM-ban tárolt globális változókhoz.
A ROM 16 bites, a TABLAT csak 8.
A 0x900 címre így 2 byte-os adat is kerülhet. A ROM alsó byte kiolvasása a 0x900 értékű pointerrel, a felső byte a 0x901 értékű pointerrel lehetséges. Az alsó byte itt 5.
Igazad van, én kavarodtam bele bele az int/char letárolásba.
Ha nagyon sürgős valami, azt úgy szokás megfogalmazni, hogy jutalom díjat kínálsz előre kifizetve. Akkor elhisszük, hogy nagyon sürgős. Egyébként meg nem
Úgy igaz, ahogyan az előbb írtad.
A felső byte a páros, az alsó a páratlan pointerrel olvasható. (Az ábrán ez van, a c fordító viszont fordítva csinálja, így nem tudom melyik a jó.) A hozzászólás módosítva: Nov 26, 2017
Írj be 0x900 nak 0x0905 öt és értékátadva villogtasd le Leddel és szimulátorral lehet különbözik. 5öt vagy 9et ?
Amikor szimulátorban jó akkor 18F26K22 re vagy 46K22 re is le bírod fordítani ? És az növeli a program méretét, hogy a kezdő értékeket is lefordítja vagy sem ?
Bell mester !
Namost hogy van ez a szimulátor szerint jó villogás dolog... Ekkor a szimulátor mi szerint dolgozik ? a C ből külön fordított magának másik állományt vagy tökugyanaz a lefordított állomány, amit PIC re írva a globális változok nulla értéken vannak ? Ha utóbbi akkor az értékadásoknak a fájlban kellene lenni mégis. Ha nem akkor a szimulátoros fordítás fájl rendelkezésre áll e ? Esetleg az felhasználható lehetne a végterméknek?
Futási időben bármilyen típusú, méretű, globálisan definiált változó mindig nulla értéket ad vissza.
Szimulátorban minden a helyén van. Pedig a konstansok bekerülnek a kijelölt ROM területre, a változók a megfelelő RAM címre, sőt az eszközbe kerülő tárgykód is jónak tűnik. De a valóságban nem működik. A 0x900 címre írt 0x0905-el sem. (x[]={0x0905,...}) A globálisan definiált változók mindig 0 értékkel, a lokálisak viszont gond nélkül kerülnek a LATA-ba. A program fut, az időzítések jól működnek, a ROM terület olvasása engedélyezve van, ezek szerint a konfigok is rendben vannak.
Akkor a különböző cégek? hogy programozzák ezt fel? A szimulátor külön project ugyanezekkel a c fájlokkal vagy ugyanebből kérhető ? XC8 nekem a végén hibával hagyja abba a telepítést.
Más típusú (esetleg másik példány) mikrovezérlővel is ugyanezt csinálja?
Amúgy nálam az ilyen __at(cím) típusú direk címhozzárendelést nem is hajlandó az fordító (XC8 v1.33) megenni, csak ha bekapcsolom a CCI vagy IAR szintaktika engedélyezését.
Ez a típus kb egy éves, a free verzió talán majd 4-5 év múlva fogja ezt valamennyire jól kezelni.
Azt is el tudom képzelni, hogy keringenek kéz alatt javítások, amikben pár hiba már ki van javítva, vagy akár linuxra egyszerű parancssori kompájlerek, de akár más nyelveken is kiválóan működők. Ezt a hibát egy nagyon egyszerű, rövidke asm programmal szemléltetve pár sorral lentebb közzétettem. Azon viszont csodálkozom, hogy egyesek, akik itt lenézik a C nyelv lehetőségeit és azt is, aki használja, de a nagy assembly tudásukkal rendszeresen kérkednek, hozzá se tudnak szagolni. 
Nincs most kéznél más típus, ilyenből van 3, kettővel ugyanaz a helyzet.
A tok működik. A legfrissebb fordítókat tettem fel, ami nem feltétlenül a legjobb. Igen, azt bekapcsoltam, de ha kikapcsolom, azt is elfogadja. Az asm-et lefordítva is ugyanaz a helyzet, így a fordító kiesik. Vagy az asm-ben, vagy a konfigban kellene felfedezni a hibát.
Errata-t néztél már? A flash rom olvasása és az NVMREG regiszter értéke között van némi összefüggés: "TBLRD Requires NVMREG Value to Point to
Appropriate Memory", induláskor kell egy BSF NVMCON1, 7 utasítás. Amúgy meg szerintem senkinek nincs itt rajtad kívül ilyen chipje otthon, így legfeljebb a szimulátorban tudják kipróbálni, de ugye ott meg jól működik. A hozzászólás módosítva: Nov 27, 2017
Idézet: „.Azon viszont csodálkozom, hogy egyesek, akik itt lenézik a C nyelv lehetőségeit és azt is, aki használja, de a nagy assembly tudásukkal rendszeresen kérkednek, hozzá se tudnak szagolni.” Én meg azon csodálkozom, hogy ilyeneket írkálsz, miután többen is kértük, hogy írd le, mit is kellene ennek a programnak szerinted csinálnia. Mi az elképzelésed? Mi oka van annak, hogy egy egylépcsős adatkezelést táblázatból akarsz megoldani? Azt is kérdezték már tőled, miért 0x800-nál kezdődik a programod. Majd ha ezekre a kérdésekre válaszolsz, valószínűleg rájövünk, hol a hiba.
Pillanatnyilag betettem a C fájl elejére, így rendben van.
Köszönöm a segítséget!
Az errata szerint így kellene:
De ezt a power-up.as fájlt nem tudom összekötni a C fordítóval. A hozzászólás módosítva: Nov 27, 2017
Több alkalommal leírtam, hogy a globális változókat nem lehet definiálni, az értékük mindenütt nulla.
A programnak nincs jelentősége, mert az csak a szemléltetéshez kellett. De leírtam a programot és azt is, amit valóban végrehajt. Legutóbb itt
Pedig a fordító könyvtárában létezik a sources/pic18/powerup.as a következő tartalommal:
A goto előtti sorban még oda is van írva, hogy ha az errata javasol valami induláskori hibajavítást, akkor azt ide lehet a nop helyére beszúrni. Így már működne a globális és statikus változóid kezdőértékének megadása is, mert a startup program ezután futna le és így már képes lenne a flash programtárból bemásolni a kezdőértékeket. |
Bejelentkezés
Hirdetés |
