Átállítottam, most pedig egymás után rengeteg

"Message[306] D:\PROJECT\FULLGSM SMS\FULLGSM SMS.ASM 2690 : Crossing page boundary -- ensure page bits are set."

üzenetet kapok, de lefordul a kód...

Köszönöm, erre nem gondoltam volna. Már csak azért sem mert kb 1 éve forult le ez a kód először, és akkor rontottam el egy klikkeléssel az egészet. Hol van az már...?

Lehet kéne nyitnom ennek egy új projectet.. jól?

Ez normális, miután előfordulhat, hogy a hívott rutin egy másik lapon van! Ha ez így van, akkor a CALL előtt ki kell választani a megfelelő lapot. Ezt megteheted a PAGESEL "rutin címe" sorral, illetve az RCALL ezt megteszi magától.
Az RCALL-al vigyazni kell, mert nem egy sorra fordul le! Ez akkor gond, ha pl. BTFSS után RCALL-t írsz. Ez így nem fog működni, miután a BTFSS és hasonló ugró elágazó utasítások csak egy sort ugranak át. Ilyen esetben csak a PAGESEL és a CALL jöhet számításba.

Nem kell új project, nincs ezzel szerintem semmi baj...

Ha a BTFSS után pl van egy bankváltás makro (esetemben BANK1 pl) akkor magát a bankváltást ugorja át? Mert az ugye nem utasítás elvileg hanem makro...

Elég kusza ez az egész kód, akkor lehet csak rendbe kell szednem. Ahogy jöttek az ötletek úgy állandóan csak hozzáíródott valami...optimalizálás meg sosem volt. Így jártam.

Köszönöm a segítséget!

A kérdésedre a válasz az, hogy a BANK1 makró annyi sorból áll, amennyit a makróba írtál, tehát a te esetedben 3 sor. Ez befordul minden alkalommal, amikor használod a makrót. Tehát a BTFSS után nem állhat több sorból álló makró(egysorost pedig csak indokolt esetben szoktunk írni).

A másik, hogy a BANK az nem LAP! Ha ezt érted, akkor nem szóltam...

Tehát a makro első sorát ugorja át...logikus.


Hűűha...Akkor ezeknek utána kell olvagatnom, mert eddig sosem volt ilyen jellegű problémám. "Hirtelen ránézésre" egy kalap alá vettem volna a BANKOT meg a PAGE et, de ezek szerint ez nem ugyanaz. Köszi hogy szóltál. Akkor hogy is van ez...?

A BANK a RAM, a PAGE a Flash programmemória.

Rendben, köszönöm a segítséget! Akkor ennek utána olvasgatok.

Ajánlom az adatlapot.

Na, most lehet hogy nagy hülyeséget kérdezek...attól hogy egyes rutinok más lapon vannak még működhet a kód? Vagy el sem éri azt a hívott rutin? Vagy csak arról van szó hogy figyelmeztet fordításkor ? Mert gyanús hogy azért lefordul a kód...

meg is van a válasz...kipróbáltam élesben a hardveren. NEM működik...!

Neked nem működik!
Pedig watt mindent szépen elmagyarázott...
Neked kell gondoskodni a váltásról. Az assembler fordító nem teszi meg helyetted. A C fordítók többnyire már kezelik a lapváltásokat (ha nem korlátos verzió)

Éppen azt mondom én is, hogy a kód nem működik a lapváltások nélkül. A lapváltás az biztos működik ha helyesen használják. De ezt át kell rágnom mert idáig még (valamiért) nem találkoztam ezzel a problémával.

Köszönöm mindkettőtöknek! A 7-8 rövidzár, a többi nincs rövidzárban. 8 eres a vezeték.

Azért nem találkoztál, mert eddig egy lapban elfért a kódod. Jól át kell gondolni, hogy melyik kódrészt teszed a 0-s lapra és melyiket másikra. Ha ezt kézben tudod tartani(akár org-okkal kijelölheted előre a laphatárokat és adott rutinokat szándékosan adott lapra tehetsz), akkor nem lesz kavarodás. Egyébként garantált! Javasolt a szimulátor használata, az rámutat egyből, hogy melyik hívás fut lapváltásra. Egyébként az egész egyszerű. Neked sem elég ha valaki megmondja, hogy a 6. fiókban van világ egyenletet megoldó képlet. Azt is meg kell mondani, melyik szekrényben van az a fiók!
Megjegyzem, ezért szoktam javasolni a 18F-ekkel való kezdést...

A 7-8 zárlata miatt van az, hogy a sárga LED világít. Ezt kösd szét, és ellenőrizd le, hogy a rajzon látható lábakat összeköti-e a kábel a dugókban. Ha nem, akkor forraszd be úgy, hogy ez teljesüljön.

Van egy kis gond, de lehet, hogy csak én látom így. Szétszettem a csatlakozó mind két felét és a vezetékek nem ugyan ahhoz a lábhoz mennek. Pl.:az egyiknél 1-es lábon barna a másikon pedig piros a vezeték. A 7-es és 8-as mindkét végén össze van forrasztva.
Én úgy gondolom, hogy leforrasztok minden lábról mindent és újból forrasztom Így jó lenne? (Pl,: mind két végén az 1-es lábon piros lesz.)

A kép lemaradt!

Igen, én is azt írtam, hogy be kell kötni jól! A rajz szerinti lábakat kell szám szerint összekötni a dugókban, a többi nem számít! Ezt a kábelt másra nem fogod tudni használni, és más kábel nem lesz jó ide.

Nagyon köszönöm! Megyek is és forrasztok.

Üdv, mindenkinek.

Én mondhatni, hogy semmit nem értek a pic-hez, de haveromnak már van égetője, és ő is más programmal dolgozik. Mert van nekem egy fájl ami asm és azt keleln nekem átteni hex.-be nemtudná nekem valaki megtenni?
Mert a haver a hex-et már tudja a pic-be éget.
A segitéget előre is köszönöm.

Szia!

Töltsd le a Microchip oldaláról az MpLab programot és telepítsd fel. És már Te is fordíthatod a programokat...

Igen, kicsit utána olvasva a dolognak kezd tisztulni a kép. Szóval a 2K feletti program memóriájú PIC eket érinti a dolog, ezért nem találkoztam még idáig ezzel. A 628A val idáig sikerült megoldanom amit akartam. A 648A már 4 K s, és elértem a "határra", így elő is jött a galiba. A PCLATH regiszter 3; 4; biteket kell állítgatni a lapváltásokhoz. Ez a + 2 bit hiányzik a 2k feletti címzéshez. Jelenleg a sűrűn hívogatott rutinokat előrébb helyeztem, a ritkán használtakat hátra. A gonosz az a dologban hogy hiába váltok lapot, RETURN után a váltás előtti lapcímmel (vagy a 0 -s al..?) tér vissza. Tehát ha egy rutint egymás után többször is meg akarok hívni..(pl késleltető hurok..) akkor minden CALL előtt lapot kell váltanom. És akkor ott vannak még a GOTO k is amik szintén a 2k feletti részre ugranak. A szubrutinok átszervezésével máris kevesebb a lapváltás, de megúszni nem tudom...
Köszi, olvasgatok tovább

Valahogy fel kell osztani két jobban elkülönülő részre a programot és akkor megoldható. Pl. inicializálás, megszakítási rutin, ilyesmi marad a nullás lapon, főprogram meg kerül az egyes lapra. Vagy ha vannak táblázatok, akkor azokat is a nullás lapra tenni (mondjuk ahogy emlékszem, a 16F648A-nál ez nem kivitelezhető, mert csak RETLW-vel oldható meg a táblázatkezelés, nem tudja úgy olvasni a flash memóriát, mint az eepromot).

Bekötöttem, de semmi változás. Ha össze van kötve ha nincs akkor is világít a sárga led is.

Csak indokolt esetben ugorj át lapot GOTO-val, mert az mindig összekutyulja a dolgokat, ha ide oda ugrálsz. Szervezd úgy a programot, hogy inkább szubrutinhívások legyenek benne, és csak azokon belül használj GOTO-t.
A CALL előtt be kell állítani a lapot, visszatéréskor már nem(szerencsére) mert a stack-re tett visszatérési cím tartalmazza a lapot is, ahonnan a hívás jött. Úgy kell szervezni, hogy ne legyen túl sok laphívás.
Az org-os javaslatomat értetted? Fontos, hogy kézben tartsd, hogy a rutinok melyik lapra kerüljenek, és ne tolódjanak el, ha hozzáírsz a programhoz. Ha ilyenkor még is átcsúszik valami a következő lapra, akkor a fordító hibával jelzi ezt, tudsz tenni ellene(átteszel még rutinokat).
A PAGESEL és az LCALL és az LGOTO-t ismered? (Bocs az előbb RCALL-t írtam!)

A LED csak akkor világíthat, ha a Q3 nyitva van. Ez lehet több okból. (Q2 zárlatos, Q3 zárlatos, vagy nem jól vannak beültetve(B,C,E))
Az R8 ellenálláson nem szabad feszültségnek lennie, ha nincs rádugva a PC-re az áramkör. Először PC nélkül mérd végig. Írd meg, hogy az említett alkatrészek lábainál miket mérsz és hogy nincs-e zárlat valahol, vagy egyéb alkatrész hiba!