Igen, már szerkesztettem közben, igazad van! Jónak tűnik, ötletes!
Igazat megvallva nem találkoztam még ezzel, ha most találtad ki, akkor elismerésem!

Kössz. Bár 1 goto-val lassítja a programot,de ha nem lényeg...

Igen, ezt a technikat hivjak ugro tablanak. Magyaran a tablaban vannak a szubrutinok cimei, es masok ezen a tablan keresztul "erintkeznek" a rutinokkal. Ez resze a loose coupling-nak, tehat, hogy a foprogram mit sem tud a rutinok elhelyezkeeserol. Ha bele gondolsz a dinamikus konyvtarak is ezt hasznaljak.

Namost ennek akkor van nagy elonye, ha szukseg van a rutinok lecserelesere anelkul, hogy a foprogramot lecserelned. Pl egy bootloaderes megoldasnal lehet ilyen. Vagy ha egyszerre tobb valtozatot szeretnel ugyanabbol a szoftverbol feltenni a chipre, es szukseg eseten konfiguralni, hogy epp melyik valtozat legyen ervenyben (csupan az ugro tabla cimet kell valtoztatni es maris mas rutinokat hivogatsz).

De egy egyszeru esetben ilyenekre nincs szukseg, csupan a PAGESEL makrot kell hasznalni es mindegy is hova fordul a rutin, annak mindig a helyes cimet fogja megkapni. Vagy linker scripttel kikenyszeriteni, hogy mi keruljon ugyanarra a lapra, amivel ugye meg lehet sporolni a lapozasokat a kesobbiekben (es eszre is lehet venni ha tul nyul a lapon a rutinunk, teht forditasi/linkelesi idoben mar eszre vehetjuk a hibat).

A pagesel makró ugyanolyan szószátyár, mint a banksel, pedig rendelkezésére áll az az információ, hogy melyik page-ről melyiket szeretnénk elérni:







Lalca ötlete a btfsc és btfss után levő eljárás híváson is segít, hiszen ide nem lehet elhelyezni a page-váltó utasításokat.

Más lehetőségek:
- A programok gyakran használnak táblázatokat: kiszámított ugrásokat, amiknél más a 256 -os határ miatt a PCLATH regisztert úgyis be kellett állítani. Ezeket a részeket nyugodtan át lehet tenni más page -ra, csak a visszatérés után ne feledjük el a PCLATH értékét a hívó lapra visszaállítani.

- Egy bonyolultabb programban a kezdeti beállítások elvégzése terjengős lehet - általában egy hosszú, ugrások nélküli programrészlet. Ezt is egyszerűen át lehet tenni más lapra....

- "Olcsó" page váltások:
Page0 <-> Page1, Page0 <-> Page2, Page1 <-> Page3, Page2 <-> Page3
-> Page0 --- clrf PCLATH

((A 18F szériában egy utasítás 2 byte, a programmemória címzése byte-os - így a kiszámított ugrások csak 128 utasítás hozzúak lehetnek az átvitel kezelése nélkül. Elég ügyesen kell a rutinokat elhelyezni, hogy ne legyen tele a program 4 byte-os goto / call utasításokkat. A bank váltás itt is megtalálható (ugyan ritkánbban kell használni), de ugyan azon az alapokon nyugszik. Pl. LIN illesztőt is tartalmazó kontroller FSR területe nem fér be az access bankban. ))

Igen, de maga a cél, hogy a lapozást segítse, más okozat. Az ugró tábla is ugyanez, de nem pont ez a szándéka.
Hp41C-nak is igaza van, még a BTFSS problémán is segít.

Az nyílvánvaló, hogy kellő rutinnal akár kézzel is lehet állítgatni a PCLATH bitjeit(főleg, ha csak 2 lap van és org-okkal kézben tartod a rutinok elhelyezkedését), és akkor makró sem kell, de az engem is bosszantott régen, hogy ezt miért nem tudta megcsinálni a gyártó az előfordítóban! A PAGESEL és a BANKSEL elég béna!
A 18F-nél én úgy szoktam, hogy 1-es bankra váltok, majd a fontos dolgokat az első 128Byte-ra teszem, és az 1-es bankban elérek 256-ot. A LIN illesztési feladat elég ritka, még nem használtam, te már igen?

Bocsi, már megint én. Hp41C azt irja lentebb:

"Ezeket a részeket nyugodtan át lehet tenni más page -ra, csak a visszatérés után ne feledjük el a PCLATH értékét a hívó lapra visszaállítani."

Viszont tegnap az írtad hogy a visszatérésnél return után már nem kell a foglalkozni a PCLATCH visszaállításával mert az értéke eltárolódik és a visszalépésnél újra betöltődik. Akkor most hogy van ez..? És a megszakításokkal kapcsolatos PCLATCH mentés..? Mert ezt is csak tőle hallottam, nem találok ezzel kapcsolatban infót.

Isten ments hogy akár őt akár mást én láma létemre megkérdőjelezzek, csak ellentmondásosak most ezek az infók és szeretnék tisztán látni...Pl erről a megszakítással kapcsolatos dologról semmit nem találok..

Köszi

icserny elég komoly honlapján vannak fontos dolgok említve a megszakításokkal kapcsolatban, érdemes elolvasni. Igaz, hogy az ott leírtak 18F szériára vonatkoznak, viszont nagy a hasonlóság az INT-kezelésben a 16F szériával, fő különbség a 2-szintű megszakítások lehetősége, ami 16F-eknél nincs.

Úgy értettem, hogy addig nem kell foglalkozni vele, amíg nem fut a program egy újabb ugró utasításra(Illetve a visszatérés előtt nem kell vele foglalkozni, mert visszatalál, holott egy másik lapon van a return).
Csatoltam egy projectet, próbáld leszimulálni, mi történik. Tömörítsd ki a C-be és indítsd el az mcp fájlt.

Szia!

(Bocsánat terjengős lesz...)
Különbséget kell tenni a goto / call és a return utasítások között.
- A return, retlw a belső stackről a program számláló összes bitjét visszatölti, de nem változtatja meg a PCLATH regiszeter értékét.
- Minden goto és call a PCLATH regiszterek pillanatnyi értékét használja fel a magasabb bitek beállítására.

Tételezzük fel, hogy a 0. page -ról kell meghívni egy rutint, ami a 3. page-n van, és a visszatérési STATUS,Z érték szerint kell ugrani a 0. page valamelyik címére. A programban megszakítás kezelés is van.



A Loop_0k első két utasítása beállítja a meghívandó rutin igénye szerint a PCLATH page kiválasztó bitjeit. A call már jó lapra történik. A Routine_6K végén a return a 0. page -re vonatkozó címet teszi a program számlálóba, azonban a PCLATH tartalma változatlan marad. A btfss utasítás után a 0. page-re szeretnénk ugrani. Ezért az ugrás előtt a PCLATH értékét a 0. page -nak megfelelően kell beállítani.

Tételezzük fel továbbá, hogy a megszakítás a Routine_6k futása alatt érkezik meg. Ekkor a kontroller a program számlálót a stackre menti, és a vezérlést a 0x0004 címre adja. A PCLATH a Routine_6k -nak megfelelően van beállítva. A Timer2 megszakítás kérés ellenőrzésénél levő ugrás a 3. page -re menne vissza, ha a PCLATH értékét nem állítanánk át.

A különböző lapokon levő eljárások belépési cimkéinek megnevezésénél érdemes a page információt valamilyen formában a cimkében is kódolni - lecsökkentve a page keveredés által okozott hibák számát. A rutinokon belül használhatunk egyszerübb neveket továbbra is.

A 0. Bankban illetve a közös területen helyet szabadíthatunk fel a gyakran használt változóink számára, ha a mentési regisztereket más lapra tesszük - ezeket a regisztereket csak a megszakítási rutin használja. A fenti példában a 2. bankba kerültek.

Hűű..mindenkinek köszönet a sok infóért..A bőség zavara.. Kicsit emésztgetnem kell a példákat.

A projectet sikerült elindítani, lefordítani, szimulálni?

Igen, a baj az, hogy egy normalis megoldashoz tudni kell honnan hova ugrik a kod. Magas szintu nyelveknel az optimalizacio soran dontik el, hogy mely bank ill page lapozasokat lehet kihagyni. Assemblynel akarmilyen okos makrot allitunk ossze nem lehet automatizalni ezt, kiveve, hogy ha kezzel optimalizaljuk ezt. Epp emiatt nem csinalta meg a Microchip, hogy a BANKSEL okosan es sporolosan lapozgasson -- hisz soha nem lehet tudni mikor hagyhatja ki a felsobb bitek beallitasat...

Szia!

Az Extended Instruction Set alkalmazása esetén az Access Bank első 96 címe (0x00 - 0x5F) új értelmezést kap...

Ez tanulságos számomra, bár az allokálható kódoknál nem igazán értem, hogy a $-os hivatkozás hol kerül kiértékelésre. Úgy gondolom, hogy a linker-nek kell behelyettesítenie a megfelelő kódod, amikor az egyes kóddarabokat összeilleszti, de ha változik a kód mérete azáltal, hogy a makró beszúr egy PCLATH módosítást vagy sem, hogyan lesz abból működőképes program. Szóval nem igazán értem még a fordítókat, hogyan bírkóznak meg a PAGESEL illetve BANKSEL makrókkal.

Szia Igen, köszi. Illetve elindítani elindul csak éppen lefordulni nem fordul le, így szimulálni sem tudom. De éppen nyomozok hogy miért nem fordul le...2 x 306 os üzenet van az out ablakban, meg:

Debug build of project `D:\PROJECT\Lapozas\Lapozas.mcp' failed.


Próbáltam a C ről is ahogy írtad, de onnét sem volt jó. Ezért beraktam a saját projectjeim közé hátha onnét megy.... de nem akar.

Hmm...

"Couldn't locate build tool. Check tool locations."

a saját projectjeim viszont rendben lefordulnak.

A C gyökerébe kell kitöröríteni. Egy mpl könyvtár lesz. Ha nem megy, csatold egy txt-ben a hibaüzenetet!

Nézd meg a fordítási beállításoknál, neked biztosan máshol van az MPLAB Suite! (A Project/ Select Language Toolsuite alatt nézd meg milyen elérési út van az én projectemben, és módosítsd a tiédre!)

----------------------------------------------------------------------
Debug build of project `C:\mpl\mpl\Lapozas\Lapozas.mcp' started.
Language tool versions: MPASMWIN.exe v5.35
Preprocessor symbol `__DEBUG' is defined.
Wed Dec 29 19:45:22 2010
----------------------------------------------------------------------
Clean: Deleting intermediary and output files.
Clean: Deleted file "C:\mpl\mpl\Lapozas\Lapozas.o".
Clean: Deleted file "C:\mpl\mpl\Lapozas\Lapozas.err".
Clean: Deleted file "C:\mpl\mpl\Lapozas\Lapozas.hex".
Clean: Deleted file "C:\mpl\mpl\Lapozas\Lapozas.lst".
Clean: Deleted file "C:\mpl\mpl\Lapozas\Lapozas.mcs".
Clean: Done.
Executing: "C:\Program Files\Microchip\MPASM Suite\MPASMWIN.exe" /q /p16F648A "Lapozas.asm" /l"Lapozas.lst" /e"Lapozas.err" /d__DEBUG=1
Message[306] C:\MPL\MPL\LAPOZAS\LAPOZAS.ASM 34 : Crossing page boundary -- ensure page bits are set.
Message[306] C:\MPL\MPL\LAPOZAS\LAPOZAS.ASM 53 : Crossing page boundary -- ensure page bits are set.
Couldn't locate build tool. Check tool locations.
----------------------------------------------------------------------
Debug build of project `C:\mpl\mpl\Lapozas\Lapozas.mcp' failed.
Language tool versions: MPASMWIN.exe v5.35
Preprocessor symbol `__DEBUG' is defined.
Wed Dec 29 19:45:24 2010
----------------------------------------------------------------------
BUILD FAILED

Na, megoldódott. Újra indítottam a gépet és végül a projected felépítése előtt az MPLAB felkínálta a te elérési utadat meg az enyémet. Csak ki kellett választani. Most már lefordult a kód, köszi.

Szuperul lehet látni mit csinál valójában, a szimulátorral lépésről lépésre tudom chekkolni.

Köszönöm, ennél szemléletesebb már nem is lehetne...

Szuper! Akkor elértem amit szerettem volna a sok beszéd helyett!

Linkeles soran, es *nem* a fordtias soran dol el a vegleges cim. Addig az object kodban un. feloldatlan cimkent szerepelnek ezek. Nem hiszem, hogy erdemes lenne itt kitargyalni a forditas es linkeles rejtelmeit, hogy pontosan hogyan tarolja el a koztes kodban a fordito ezeket es utana a linker mikent oldja fel a cim hivatkozasokat, de azert azt el tudod kepzelni, hogy egyenlore oda bepakolnak csupa nullat, es valahol mashol emlekeznek ra, hogy ezeket a helyeket meg fel kell tolteni, melyeket a linker meg is csinal. Nem raketa tudomany ez amugy, mert ezek a dolgok mind 60-as 70-es evek technologiai...

Nahát pont ez az! Feloldatlan címek. De én a makrókról írok, amik a kódban elvileg fordításkor kerülnek kiértékelésre.
Például 16f sorozatú pikeknél a:

a kódba betesz két utasítást, a bankváltástól függően BSF, vagy BCF a négy variációnak megfelelően. De az, hogy oda ténylegesen BSF vagy BCF kerül, már csak a linkernél derül ki, mert a konkrét címeket az adja. Emiatt arra gondolok, hogy hiába írok én okos bankváltás makrót, amelyik figyeli, hogy korábban melyik bankot használtam és elspórol egy-egy bitállítást, mert a kódban ott két utasítással lehet csak biztosra menni. Vagy talán ezt rosszul gondolom?
Rengeteg memória elmegy ezekkel a bankváltásokkal, meg pageváltásokkal. Nem beszélve a futásidőről! Jó lenne valahogy spórolni rajta.

Hát nekiálltam....Közben az jutott eszembe hogy mivel a PAGE 0 ról hívok meg PAGE 1 -n lévő rutinokat, mi lenne ha a rutinok végére a RETURN elé beraknám a PAGE 0 ra váltást. Igy már rögtön a PAGE 0 ra tér vissza a rutinból és nem kell állandóan visszalépkedni. Tehát a programot úgy szervezem hogy azokba a rutinoknak a végére beillesztem a Page 0 ra váltást amelyek a PAGE 1 en vannak.

Mintha tegnap valaki valami ilyesmi megoldást dobott volna fel, csak ő a rutinok elejére is berakta volna a lapváltást....(lehet spanyolviasz a részemről...?)

Elvben működhetne ez a dolog..?

Absolut módban nem sokat számol a linker. Ott a befordított kódból azonnal kiderül a lap. A cím pedig az ugró utasításban benne van ami őt követi. Tehát az okos makró ki tudja szamolni az előfordítás alatt a makróból, hogy egy, vagy két sort tesz be, attól függően, hogy melyik lapon van most, és melyikre kell ugrania. Ez azonnal megvan, itt csak a lapot választja ki a két utasítás, itt nem címet számol(mint írtam az adott a következő utasításban), hanem azt, hogy hány sort helyettesítsen be. Optimalizálás sincsen, ez kézimunka.
A direktívák kiértkelésénél, gyakorlatilag kiegészül a kézzel írt asm forrás az utasítások szerint, az igazi fordítás csak utána jön, tehát olyan lesz a kód addigra, mint ha mi írtuk volna kézzel.

Igen, működhet, mert a visszatérési címben benne van a lap, tehát tök mindegy, hogy hová állítod a szubrutinban, az vissza tud térni a hívás utáni sorra.

De egyébként ezeket próbáld leszimulálni, látni fogod, hogy működik-e , a példát csak ki kell egészítened!

Sziasztok. Nemrég kezdtem PIC-kel foglalkozni. Van egy pickit3 égetőm Mplab ide 8.63 programmal. Eddíg sikeresen égettem 12f629-et, 16f628a-t. Viszont az egyik 16f628a égetésénél az mplab kiírt egy figyelmeztető ablakot. Ha OK-t választottam elindult az égetés, de memoria hibával sikertelen lett. Az mplab configuration --configuration bits menüben az oscillator selection menüben próbálkoztam állítgatásokkal, de vagy nem került be a program a pic-be, vagy bekerült, de volt hogy egyik kimenet állandóan megvolt. Aztán visszaállítottam az eredeti beállítást, ami a képen is látható és így már átment a program és működik is, de a figyelmeztető ablak megmaradt. A kérdésem az lenne, hogy hol állítódott el a konfig. Az Mplab-ban, vagy a pickit3-ban?

Szia!

A rutinok elejére tett page váltás nem jó ötlet, hiszen a rutinok tartalmazhatnak ugrásokat / további eljáráhívásokat. A visszatéréshez szükséges page beállítást az utolsó ugrás / eljárás hívás utánra tehető be.

((Persze ezt is ki lehet használni : Egy lapról, ugrások nélküli részből hivogatni más page -eken elhelyezkedő eljárásokat. Az első hívás előtt átállítjuk a PCLATH bitjeit, az utolsó után visszaállítjuk arra a page-ra, ahonnan az eljárásokat hivogattuk....))