www.elektronik.si

[Umnik]

Zanima me kdaj pride do teh dveh pojavov in kaj se zgodi ko do tega pride.

Pa tudi: PIC ima 8 nivojski stack in me zanima ali se je možno vanj nekako "nezavedno" pogrezat?
Recimo, je možno da se iz glavnega programa v stack pogrezneš do 4 nivoja, potem pa ne prideš nazaj, a vseeno izvajaš glavni program, kot da ni nobene napake?
Nekako ne znam prav zastavit vprašanja, upam da je dovolj razumljivo kaj bi rad...

[Silvo]

Sklad praktično nič drugega kot nek 13 bitni "register" kamor se shranjuje PC (programski števec) Pri pic-u je 8 nivojski. (kar je po moje zelo veliko ) to pomeni, da lahko uporabimo CALL 8 x v "globino" deveti klic bo pa prepisal 1 vnos v sklad. (Prevajalnik mislim, da nima kontrole "globine" torej moramo na to sami paziti pri programiranju.) Vsak RETURN ali RETLW vrne nivo za eno stopnjo nazaj, ob enem se sprosti en nivo. Če prav razumem, te zanima kaj bi se zgodilo, če bi šel v globino recimo 4x potem bi v zadnji proceduri poklical spret prvo (program bi nekako zazankal ?) Tega nisem probal, dvomim, da bi to zaznal prevajalnik Bi pa lahko prišlo do zalo čudnega obnašanja kontrolerja

[Djurodrljaca]

V sklad se pri PIC-ih 16F (in podobnih) ne da vpisovati ali brati sklada, to lahko delaš s PIC-i 18F (in verjetno tudi s dsPIC).

[Umnik]

Prevajalnik kakršnihkoli čudnih in napačnih manipulacij, ki privedejo do napake sklada ne zazna. Če bi program zazankal bi se začel "utapljati" v skladu; program sicer nekaj časa deluje normalno potem pa se mikrokontroler obesi...

Vprašanje se je pravzaprav porodilo pri primeru preklapljanju strani (Page) pri 16F877A. Listing v okolici preklopa je tak:

[Silvo]

Tega končka kode ne razumem. Pojasnim pa lahko glede PCLATHA. Programski števec je dolg 13 bitov. Instrukcije, ki naslavlajo PC so call ter goto. Cela instrukcija je dolga 14 bitov Trije MSb biti so "ime" instrukcije z ostalimi 11-stimi biti pa naslavljamo PC. Istočasno se iz PCLATH-a prebereta še dva zgornja bita. Torej če so skoki daljši kot 11 bitov je potrebno pred skokom postavit ali zbrisat PCLATH, sicer bo skok šel na napačno lokacijo.

[Silvo]

Umnik,

Tole te zanima zaradi tistega Iztokovega programa? Prejle sva z Iztokom debatirala po telefonu. Vzrok za nastalo težavo po moje ni to, da koda presega 2k. Tam je sicer bilo nekaj napak glede PCLATHA, ki sva jih analizitrala a stvar še vedno ne deluje. Mislim, da je vzrok to, da procedura "print1" povozi sklad. Gre v globino več kot 8x. To je možno ker so makroji "vgrzneni" en v drugega. Kode je toliko, da sem se pri analizi enostavno zgubil. Če bom imel jutri čas bom tisto analiziral do podrobnosti. Če imaš kak pameten simulator, poskusi odmaknit rutino "print1" boš videl, če ti bo še "težil" po prekoračitvi sklada.

[Umnik]

Ne vem, mislim, da gre print1 "samo" 5x ali 6x v globino...
Problem je, ker simulator nič ne zateži, a stvar vseeno ne dela.
Če (Ko) boš odkril napako, bi prosil če sporočiš kaj je bilo, ker se mi zdi da sem pri tem bolja ali manj mrzel...

[Silvo]

Procedura je tolikokrat vgreznjena, da je včeraj zvečer enostavno nisem uspel analizirati. Bojim se namreč, da manjka kar "return" Bom poskusil danes zvečer narediti eno testno vezje. Po telefonskem pogovoru z Iztokom sem izvedel, da preinitvena rutina ko stvar deluje normalo teče, tukaj pa glede kode, ki mi jo je poslal ni ene logike, kajti v sami prekinitveni rutini ima vrstico, ki izklaplja vse prekinitve. (Sicer nisem prepričan, če CPU pusti prekinitev izključiti v prekinitveni rutini - tega nisem nikoli poskusil) V koliko je prekinitev res izključena, progam namreč v nadaljevanju teče v zanki v kateri prekinitve ne vključi ponovno je edina razlaga, da program skoči nekako na reset vektor 0x0 ter ponovno "pobaše" inicalizacijsko kodo. Sicer se v nadaljevanju prekinitev ne bi smela več izvesti.

[Silvo]

Še tole sem pozabil . V sami rutini "print1" se večkrat ponavlja makro, ki generira tabelo. Seveda tukaj postane problem v koliko se tabela lomi na dosegu PCL (8 bitenga nizkega števca) ter se za branje uporablja naslavljanje le tega.