Lehet sokat segítene, ha az egész state machine-t amit ez a case implementál újragondolnád, letisztázni a lehetséges állapotokat, tranziciókat , s utána újrakódolni az egészet.

Szerk: a verem túlcsordulásnak még egy oka lehet a túl sok függvényhívás is! És abból is van rendesen a programodban. De ezt inkább a case elágazás kijavítása után..

Nem írod milyen a PIC, ez a verem mélysége miatt érdekes(16F-eknél pl. 8).
Lényeg, hogy egy CALL-hoz egy RETURN-nak kell tartoznia, azaz nem szabad kilépni egy szubrutinból GOTO-val, vagy ha igen, ügyelni kell a RETURN-ra valahol.
A másik hiba lehet, hogy a megengedettnél többször történik szubrutinból szubrutin hívás. A PIC adatlapjában benne van verem mélysége, erre rá kell hagyni a megszakításhoz is legaláb egy réteget, de ha több prioritású megszakítás is van használva, akkor kettőt, illetve ha megszakításból is történik szubrutinhívás, akkor többet(amilyen mélységbe vannak ágyazva a hívások).

Goto utasítás nincs a programjában amit mellékelt.
A RETURN feladata beállítani a megfelelő program counter-t és a regiszterek állapotának visszaállítása. Egy helytelen visszatérés nem hiszem, hogy verem túlcsordulást okozna bár még nem próbáltam.
A második ötlettel kapcsolatban, én is erre gyanakodtam (lásd fennebb) de kétszeres hívásnál nincs több a programban. Plusz:

Tehát a hiba gyökere itt lesz valahol. A case újraírása szerintem elkerülhetetlen.

Szia! Sajnos nem volt időm a programot megnézni, csak általánosságban beszéltem a hibakódból kiindulva. Pascal amúgy sem túl ismerős...

A helytelen visszatérés, pontosabban ha nincs visszatérés és újabb Call van, túlcsordulást okoz. De lehet, hogy nem erre gondoltál, mikor helytelen visszatérést említetted...

Erre értettem de nem gondoltam tovább mi van ha egy újabb CALL jön. A gondolatmenetem szerint csak egy újabb adag érték lenne a veremre hányva, ha elférnek ezek, akkor szerintem ez önmagában nem okoz túlcsordulást. De ha ez 2x 3x előfordul szinte biztos megtelik a verem mivel a RETURN (annak hiánya miatt) nem takarítja ki a vermet a szubrutin után. Főleg ha paraméterekkel rendelkező szubrutinok..

De nem ugyanannak case-nek... Ugyanis kettő van.
Van egy, ami a mode értékét nézi, ez az aláhúzásos értékeket tartalmazza, meg egy másik, ami az svmode értékét nézi, ebben meg az aláhúzás nélküli cimkék vannak. Szóval ebből nem lesz keveredés.

Viszont: (ha már homár) ha már Pascal, akkor javasolnám az enum típus használatát ezek helyett a const definíciók helyett. Sokkal tisztább, és használjuk ki a Pascal egyetlen előnyét a C-vel szemben: a tiszta típusokat.

Igen.

Sziasztok!
16F887-es PIC-ről van szó, annak (ahogy watt is írta) 8 a verem mélysége, próbáltam erre ügyelni, hogy ne lépjem túl, mert eleinte valóban ez volt a probléma. Menürendszert nem igazán terveztem még, így nem tudom, hogy lehetne egyszerűbben megcsinálni. Magának a riasztónak alap esetben 4 módja van, ezek a következők:
- Monitorozás:
Ilyenkor csak a zónák állapotát jelzi ki illetve a keypad állapotát figyeli (van-e lenyomva valamilyen gomb), riasztás nincs. "#" lenyomására átvált az élesítés módra.

Élesítés:
Visszaszámol X másodperctől 0-ig, közben sípol, illetve figyeli a keypad állapotát, ha beírják a pin kódot, akkor alaphelyzetbe áll minden és a monitorozás mód lesz aktív. Ha letelt az X mp, beélesedik a rendszer.

Élesítve:
Zónák illetve keypad figyelése. Ha az 1-es vagy 8-as zónán állapotváltozás következik be, azonnal a riasztás mód lesz aktív, egyéb zónák esetén visszaszámol X másodperctől 0-ig majd a riasztás mód aktiválódik.

Riasztás:
Kimeneteket aktiválja (sziréna, reflektor, stb.) és másodpercenként növelget egy változót. Ha ez a változó eléri egy megadott értéket, a sziréna kikapcsol, de a behatolást jelzi a program a felhasználó felé. Mindeközben a keypadet ugyanúgy figyeli, bármikor beíródik a pin kód minden alaphelyzetbe áll és a monitorozás mód lesz aktív.

Ennyi nagyjából a logikája a programnak. A szerviz menü részben van két egymásba ágyazott case, mivel ott egy menüt kellett valahogy kialakítanom (pin kód váltás, késleltetések...) és nem találtam jobb megoldást rá.

Mikor olvastam a verem méretéről, ott írták (ahogy ti is megjegyeztétek) hogy ügyelni kell rá, hogy szubrutin ne nagyon hívjon magából mégegyet, mert ez könnyen vezethet verem túlcsorduláshoz. Viszont ha megnézem pl az InitDisp eljárást, ott alapból ott van az LCD_Init, LCD_Cmd, LCD_Chr_CP, és a ClearDisp amelyek mind külön szubrutinok. Ezek vajon mennyire pakolják tele a vermet?

Hát, ahhoz el kéne őket olvasni...

Amúgy pl. az XC8 fordító konkrétan végigelemzi, hogy hány szintű vermet igényel a program, és figyelmeztet, ha a limit közelébe ér az ember.

Mivel itt az interrupt rutinból nincs függvényhívás, így szerintem még egy 6-os szint is elfogadható kéne legyen a főprogramban. Elsőre ránézve 2 szintet használsz, plusz ami az LCD rutinokon belül van. Nehezen tudom elképzelni, hogy 4 szintnél több kelljen nekik...

Pl a ClearDisp ugye igy nez ki:egyszerubb lenne es nyernel 1 szint stacket ugy hogy a ClearDisp; helyere a LCD_Cmd(_LCD_Clear); kerulne. Nem neztem at az egeszet, ( a Pascalt nem is szeretem tulzottan) de lehet meg tobb ilyen benne.

_vl_ kollégának igaza van, én észre se vettem. Ez viszont igen komoly tervezési hiba szerintem. Case a case - ben, mi ennek az előnye?
Dave87 kipróbálta, s a beágyazott case két elágazásának törlése megoldotta a problémát. Nem látok semmi különöset a többi ággal szemben..
Még ha nem is ez a hiba tartom magam ahhoz, hogy azt a case t át kell tervezni, plusz beágyazott case-ek nélkül, így teljesen átláthatatlan.

Szia!
Indítsd el az MpLab -ot, állítsd be a kontrollert 16F887 -re. A lefordított hex -et importáld be, válaszd ki az MpLab SIM -et debuggernek. Helyezz töréspontot a megszakítási rutinra. Jelenítsd meg a Hardware Stack ablakot. Indítsd el a programot. Néha állítsd meg, a _mode és a svmode változóknak változtasd meg az értékét - a címüket a mikropascal watch ablakából ki lehet nézni. Figyeld a stack méretét...

Szia! Megcsináltam amit írtál, de nem igazán értek az MPLAB-hoz. Mindenesetre lekaptam a képet, gondolom te értesz belőle valamit. A képen látható címnél a program "megáll", pontosabban nem lép túl rajta.

Milyen Pascal fordítót használsz?

MikroPascal 5.61-et

Rá lehet venni valahogy, hogy generáljon a fordítás során assembly outputot? List file, vagy valami ilyesmi lesz a neve, általában .lst a kiterjesztés.

Igen, automatikusan generál lst és asm fájlt is. Mellékeltem őket.

Szia!

Ezen eggyszerűen továbbléptettem... Öt mélységű stack használatot láttam...

Nem értem, ha valóban 5 a mélysége, akkor mitől csordul mégis alul/túl? (Legalább is a szimuláció azt a hibaüzenetet dobja) Lehet megfogadom Programmer javaslatát és azt a case részt átírom. A gondom annyi mindössze, hogy nem tudom milyen más megoldás lehetne. Nekem ez tűnt a leglogikusabb megoldásnak, hogy van 5 mód, amit váltogatok a külső események függvényében. Az 5. mód a szerviz mód, abban szerepel a két case elágazás. Valamelyikőtök csinált már menürendszert? Mert szívesen vennék néhány tanácsot azzal kapcsolatban.

Átírhatod, de nem ott lesz a hiba... Inkább valahogy próbáld meg fülöncsípni a hibát. Melyik utasításnál írja ki a szimulátorod a hibát? Használd a MikroPascal debuggerét, az MpLab szimulátorát. Hátha a baj nem is a programmal van, hanem a szimlátorban vagy a beállításában...
Mivel programozod? PICKit2 -vel? Az egyben egy emulátor is. Bele lehet látni a kontrollerbe a segítségével... Az MpLab -bal kellene lefordítani a pascal által gyártott asm -et debug módban. Debugger legyen a PICKit2...

Sajna nem PicKit2-m van, hanem egy ILYEN

ISIS-ben mikor elindítom a szimulációt, össze-vissza villog az LCD-n 1-2 másodpercig a kurzor, majd elkezdi dobálni a hibaüzeneteket, a képen látható. Még egy sejtésem van mi lehet a gond, csak nem tudom megfogalmazni, butaságot meg nem akarok írni

Ezt a menü rendszert nagyon egyszerűen le lehet írni egy Finite State Machine használatával(véges állapotú gép). A lényege, hogy minden menüpont egy állapot, függetlenül attól, hogy almenü vagy főmenü. Egy állapotból a másikba csak egy meghatározott esemény megtörténtekor lehet/szabad átlépni.
Egy példa: 3 menüpont
- Idő beállítása
- Kijelző beőllítása
- Kilépés a főképernyőre
Ekkor négy állopotot kapsz: a főképernyő, plusz a 3 menü. Ezek lesznek a case elágazásai, itt fogod leírni melyik állapotban mit kell csináljon a program. Az esemény pedig lehet egy gomb, egy időzítő lejárta stb. Ha GOMB1 megnyomva és épp a 3ik menüponton vagy, az beállítja a főképernyő állapotot. A főképernyő állapot utasításai lesznek a képernyő letörlése, megfelelő szövegek kiírása.
Elég rövid és suta leírás ez így, de neten találsz róla rengeteg infót.

AD modullal kapcsolatban van egy érdekes észrevételem.
Több PIC-en (16F, 18F sorozat) használtam már AD-t, de ilyet még nem láttam:
18F86k22-es PIC alacsony analóg bementi fesznél (Ube<~3mV) az ADRESH reg. értéke FF, míg a ADRESL olyan F0 és FE között változik. A bementi feszültség természetesen pozitív a Vref- -hoz képest (ami GND-re van kötve).

Tapasztalt már vki hasonlót? Azt tudom, hogy az AD alacsony értékeknél nem pontos, de ez azért meglepett, nem kicsit.>

Szia!

Én még nem ... Milyen referenciát használsz ?!

Steve

Még én sem, egyszer volt hogy hülyeséget írt, de az analóg részt kötöttem el tesztpadon...
Illetve nekem akkor szokott pontatlan lenni, ha a fehér dugaszolós panelt használom! Azt nem pontos mérésekre találták ki.

A legjobbat, amit találtam és meg tudtam fizetni.
REF198.

Akkor is csinálja, ha a Vref- -t a Vcc-re konfigurálom, ill. ha a külső Vref- lábra. A Vref- láb a Vcc-re van kötve.

Ez egy végleges nyák. Gyártattam. Az egyik oldala majdnem teljesen teliföld. A Vref és bementi vezetékek pedig körbe vannak véve földdel. A lehető legjobban el van árnyékolva a digitális résztől.

Atom stabilan mér, gyakotlatilag 1LSB-n belül van bőven a pontosság, csak ez a hülyesége van.

Szia!

El kell keserítselek: A fordítót, amit használsz nem ismerjük, ha van lehetőség valahogy lefordítani, az valami régebbi verzió... Nem arra a hex állományra fordít, amit használsz. A szimulátoroddal ugyan ez a helyzet. Ezután nekünk nem sok lehetőségünk van arra, hogy megállapítsuk mi a hiba...

ok, ok! Csak egy ötlet volt!