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 ( tehát ez nem a PIC, hanem a már benne lévő progi miatt van így !) !!

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.

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 ) Az itt elhelyezett goto utasítás irányítja a debugger rutinjaira.
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.

Valaki magyarázza már el nekem, mit takar az hogy ACCES RAM.
Ugyanis ez a táblázat ugyanígy néz ki PIC18F14K22-esnél, amibe 256 byte a ram, és a PIC18F26K22-esnél, amiben közel 4 kbyte ram van.
Ráadásul egyszerű FSR0H és FSR0L címzéssel folyamatosan használok 1kbyte-ot gond nélkül.

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.

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.

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

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

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?

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.
fordítás eredményeként

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.

Ebben egy fia cblock sincs....

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! Szóval: az spi_adat egy általam deklarált változó amit SSP1BUF-ba akarok tölteni.
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?

Értem, köszönöm!