Fórum témák
» Több friss téma |
Azt én is tudom, hogy melyik mire való. Ha azt meg tudnád tenni, ha Te jobban látod az adatlapban, hogy hol van az leírva, hogy a változókat hova kell rakni, illetve honnan indulhat maga a program, nagyon hálás lennék!
Adatlap
Én a CBLOCK-ot nem használom, inkább az udata, illetve udata_shr direktívákkal indítom az adatszegmenseket. Igaz, ilyenkor a a változók deklarálásakor meg kell adni ds direktívával a méretet, de ez (szémomra) még olvashatóbb is.
Szia!
A PIC 18-as széria legtöbb tagjánál ugyan ott van a magas és az alacsony prioritású megszakítás. org 0x0008 >>magas org 0x0018 >>alacsony Én álltalában org 0x0028-nál kezdem a programjaimat.
Van egy PIC24-em aminél a NYÁK egyszerűsítése miatt nem figyeltem, hogy az egyik láb csak bemenet, viszont én bi-directional módot szeretnék azon az áramkörön. Ugye nem követek el nagy hibát, ha a mellette levő lábat(amit most nem használok és ki-be menetet is tud) összeforrasztom vele, hiszen resetkor úgyis bemenetként indulnak. Nem akarok másik új NYÁK-ot gyártani.
Szia!
Nem néztem meg, de nagyon valószínű, hogy bootloadert használ ( ott szokot a program pl. 0x200-nál kezdődni!) és azért nem lehet 0x00-nál a program kezdete, mert akkor felülírnád a bootloader-t ![]() A hozzászólás módosítva: Júl 2, 2015
Nem használ. A programot én írtam, a PIC is teljesen új volt.
Honnan jött a 28? Illetve tudom te nem nagyon használsz változókat, de az encoder programban a pergésmentesítés számlálóját miért pont 0x0A- ra tetted?
Az icserny kolléga programjára írtam, szerintem ő használ bootloader-t !
A programmemória mindig a 0x00-ról kezdődik, legfeljebb már valaki rakott oda valamit és azért kell máshonnan kezdeni a programot, de ha Te írtad, akkor erről valószínűleg tudnál ![]()
Nem tudom a János miért 28-al kezdi, de ha nézed az általa linkelt táblázatot, az utolsó vektor 0x18. Ahhoz hozzáadod a 8 bitet (1 regiszter) akkor kijön a 0x20, azért szokták 20-nál kezdeni. Ez az ábra sem más mint a 628-é, csak itt több az SFR, nagyobb stack.
Onnan jött, hogy a PIC is 16 sor távolságra teszi a magas és alacsony prioritású megszakítást, Így egy rövidebb rutin odafér. Ezért én ugyanennyivel feljebb kezdem el a programot írni.
Azért raktam 0x0A-ra, mert nem adtam neki nevet. Csak odaírtam egy memoriacímet, ami épp megtetszett.
Valahogy csak nem értem. A program memória a 0x0000-nél kezdődik. Ezt, azt mondom még látom az adatlapból (mellékeltem egy képet).
A másik képen a 16F628A-nak a memória lapja látható, ott van, hogy 20h-tól kezdődik az általános regiszterek helye. Sőt még egy táblázatban is külön ki van emelve. De ilyet a 18F6622 adatlapjában nem látok. Tehát még mindig nem tudom, hogy a CBLOCK-ot honnan kezdjem és főleg miért onnan ahonnan. A hozzászólás módosítva: Júl 2, 2015
16F:
Elgondolkoztatok már azon, miért van a 16F -eken "lyuk" a user id terület és az eszközazonosító között? A memóriában a 0x2000 - 2003 területen van a felhasználói azonosító, a 0x2006 -on az eszközazonosító, az újabbakban 0x2005 -ön a revízió kód. De miért marad ki két rekesz? Az on chip debugger aktivizálásakor ide írják be a debugger rutin belépési pontjára ugró utasítást. Amikor a program a törésponton megáll, vagy külső jellel leállítjuk, a vezérlés a 0x2004 címre adódik át. (Jé, mintha hasonlítana a megszakítási belépési pontra ![]() 18F: Valami hasonló van itt is. Amikor a program a törésponton megáll, vagy külső jellel leállítjuk, a vezérlés a 0x200028 címre adódik át. Az itt elhelyezett goto utasítás irányítja a debugger rutinjaira. PICkit2 program Enable Test memory: A PICkit2.ini állományba be kell írni a következő sort:
A belinkelt két kép teljesen másról csól.
18F6622.jpg a Program memóriát ábrázolja, a 16F628a.jpg pedig az adatmemóriát. 16F62x -en az FSR terület egy része a 0x00 .. 0x1F címeken van. A 18F -eken az FSR terület általában a 0xF60 címen kezdődik, csak a modulokkal teletömött típusokon kezdődik alacsonyabb címen. Az ACCESS RAM pedig a 0. adatmamória lap 0x00 .. 0x5F tertományából és a 15. lap 0x60.. 0xFF tarományából áll össze. A hozzászólás módosítva: Júl 2, 2015
Röviden egy olyan memóriaterület ( mérete és SFR tartalma típusonként változhat) ami tartalmaz néhány SFR-t és a többi pedig szabad memória melyeket bármelyik lapról el lehet érni. Mi az értelme, haszna? Az, hogy bárhonnan elérhető bankváltás nélkül. Megspórolod a BSR-t, ráadásul a tartalma is megmarad.
Szerk: Amit innen akarsz elérni azt ide is kell elhelyezni. pl: udata helyett udata_acs. A hozzászólás módosítva: Júl 2, 2015
Az FSRxH, FSRxL regisztereket fel kell tölteni, azután lehet használni. Egy "véletlenszerű" hozzáférésnél ez a körítés terjengős lehet.
Nagyon kis alkalmazás: Csak az ACCESS bank -ot használja, mégis 96 adattárolót el tud érni az SFR -ek mellett. BSR = 0 állandóan. Nagyobb alkalmazás: BSR = 1 állandóan. Ekkor összesen 352 adattárolót és az SFR területet lehet elérni bankváltás nélkül. Az ACCESS bank -belieket ACCESS, a 1. lapon levőket BANKED eléréssel. Ennél nagyobb alkamazásnál ( pic -nél) már kell kezelni a BSR -t a programból. Pl.: 18F2x80, 18F4x80 esetén a CAN regiszterek a 13., 14., 15. Bank -ban vannak. (DS39637D-page 75) Célszerű az amúgyis indirekten kezelt változókat az ACCESS bank -on kívülre helyezni.
Akkor nem tudom, hogy nekem mitöl működik a programom hibátlanul, ha egyáltalán nem fordul elő benne BSR utasítás.
A RAM területet 101 től használom GLCD kijelző számára fantomképernyőként. FSR0H-t törlöm, FSR0L-be beírok decimális 101-et. Ezt követően INCFSZ- el növelem FSR0L-t. Ha túlcsordul ugyanígy növelem FSR0H-t. Így írok át a programmemóriából 1024 byte adatot. A RAM-ban végzem el a képernyőtartalom módosításait, és utána írom át a kijelzőre. Ezek szerint a 18-as széria magátol elvégzi a bankváltást.
Most már teljesen NEM világos!
![]() Kipróbáltam CBLOCK 0x000-val és 0x060-nal is, de sem így nem működik, sem úgy. A hozzászólás módosítva: Júl 2, 2015
De mi az ami nem működik?
A CBLOCK csak arra való hogy elnevezz egy ramot, hogy könnyebben tudj programozni. Ha te utánna FSR- el akarod megtalálni, egyáltalán nem bizos, hogy sikerül. A fene tudja, a fordító hogy rendezi át az elnevezéseidet. Lehet, hogy abc-be rakja. Ha ez a problémád, akkor ne a CBLOCK-al adj nevet a ramoknak.
Ebben az esetben Te egy vektort / buffert használsz, amit mindenképen indirekt címzéssel kezelsz. Jó úgy, ahogy megírtad. Más programokban nem ilyen szabályosan kell írni, olvasni az adatmemóriát...
Idézet: „Ezt követően INCFSZ- el növelem FSR0L-t. Ha túlcsordul ugyanígy növelem FSR0H-t.” Miért így csinálod? A movwf POSTINC0 avagy a movf POSTINC0,w stb. pontosan erre a feladatra van kitalálva! Egy utasítással elvégzi az adatmozgatást és az FSRx növelését 12 bitesen... Ugyanígy a POSTDEC0... Van még néhány variáció. A movff POSTINC1, POSTINC0 is működik... Idézet: „Ezek szerint a 18-as széria magátol elvégzi a bankváltást.” NEM. Az indirekt címzés az FSR -ből veszi a cím 12 bitjét, a movff utasítás kódja mind a két regiszter 12 bites címét tartalmazza. A többi utasításnál nekünk kell beállítani a BSR -t.
Nem tudom mit is próbálgatsz. Nekem minden cblock működik.
Hogy teljesen tiszta legyen minden: A cblock és org az abszolut módhoz tartoznak. A #pragma udata, stb a relokálható módhoz tartoznak.
Ez az ami nem működik. Vagyis működik csak nem úgy ahogy kéne.
Beírtam egy értéket a CBLOCK után ahogy írtad. Most a fordító nem is adja az a hibát amit korábban. Zenetom kolléga írta, hogy valószínűleg azért nem működik a fent linkelt utasítás rész, mert nincs érték a CBLOCK után.
Sziasztok!
Ha a PIC egy lábán érzékelni szeretném, hogy jelen van-e az 5V vagy nincs, akkor kell elé ellenállás, vagy szimplán ráköthetem a portra az 5V-ot? Idézet: „A fene tudja, a fordító hogy rendezi át az elnevezéseidet. Lehet, hogy abc-be rakja.” A fordító az abszolut módban pontosan abban a sorrendben és méretben számolja a címeket, ahogyan leírtad. Nem rendez át semmit sem.
a TEMP kezdőcíme 0x0000, hoszza 8 byte, a MODE pedig a 0x0008 címre kerül.
Ha a PIC lába bemenet és +5Vot akarsz vele érzékeltetni akkor a lábat GND-re kell húzni mondjuk 10k-val.
Mert ha csak az INDF0, POSTINC0, stb illetoleg a movff utasitast hasznalod, akkor nem foglalkozik vele a rendszer, mert vagy abszolut a cim, mint a movff-nel vagy eleve tartalmazza a 16 bites FSR valamelyike a pointert.
A tobbinel pedig meg kell adni, hogy az utasitasban szereplo memoriacimet minek ertelmezze a rendszer. A forditok tobbsegenel, ha nem jelzed kulon, akkor valamilyen alapbeallitast hasznal mindig, altalaban az access ramot. Magyaran, ha pl BSR =2, memoria mondjuk 0x10 es kiadsz egy movf memoria,w,A utasitast, akkor o az access ramban levo 0x10-est eri el a nulladik lapon. Ha siman a memoria,w-t, akkor a 0x210-es cimet latja. Altalaban a legtobb utasitast haromfelekeppen lehet kiadni (par ertelemszeru kiveteltol eltekintve): vagy az akkuban marad a vegeredmeny, vagy a memoriacim access ramban vagy a BSR+memoriacimben. Egy tisztesseges utasitas ket db szamot tartalmaz. pl. SUBWF memoriacim,0,0 az elso nulla utal a mem/akku valasztasra, a masodik az access ram/BSR ram kozott valt (vagy forditva, ezt fejbol nem tudom, de a PIC adatlapja tartalmazza). Csak ezt a legtobb fordito elrejti, mert jobbara felesleges es zavaro is.
Nincs hát!
![]() A kérdés az, hogy a MOVFF spi_adat,SSP1BUF utasítás miért nem működik??? Csak akkor működik, hogy ha először az spi_adat tartalmát W-be töltöm és onnan a bufferbe. DE MIÉRT? |
Bejelentkezés
Hirdetés |