16F876 programminne

[Johan.o]

Någon som vet hur det funkar med programminnet i pic 16F876 ?
Det är uppdelat i fyra sidor (pages).
Eftersom mplab varnar för "Crossing page boundary -- ensure page bits are set." Nu när jag verkar ha fyllt den första sidan.. förstår inte, tycker det verkar märkligt att man ska behöva byta sida för programminnet, eftersom den ska ju
klara att adressera 8K.. Och det är precis 8K *14 programminne i den här rackaren..
Har inte skrivit ut databladet ännu så det är lite svårt att leta där, men
så länge har jag inte hittat så mycket hjälp där.

[bengt-re]

Fattar inte vad varningen varnar för egentligen... Funkar gör det ändå och den säger inte heller att det är något fel... Bara en varning. Fråga på deras support, de brukar svara, men jag har inte brytt mig eftersom det har fungerat ändå.

[Johan.o]

Ungefär som när den påpekar att man inte är i bank 1 då..
hmm.. jobbigt. Tur man kan stänga av varningar.
Tackar för det snabba svaret. Nu vågar jag fortsätta programmera..

[bengt-re]

SFR ligger i olika banker, men det kan knappast vara det man menar. Sak samma - funkar det så funkar det !!

[Icecap]

Programminnebankerna har med om man gör indexerade hopp, en uppslagstabell kan t.ex. lätt komma över en bounary och för att den då ska hoppa till rätt adress måste man se till att bank-bitten blir rätt samt att clear den vid behov.

Men den bankbit har inget med dataminnesbitten att göra!

[bengt-re]

Sant så sant... Där har vi nog förklaringen. Vi slipper det på 18F serien tack och lov ! De är snälla emot oss microship

[Johan.o]

Ahhhrgg...
nu efter 9 felmeddelanden av tidigare nämnd art,
så har min ICD2 slutat att debugga, mplab ballar ur..
Det måste ha något med programminnesbankerna att göra.
Vad ska man göra för att få ordning på det hela?
Hajar inte riktigt vad du menade Icecap.

[ClasseMan]

Det är väl så att program räknaren eller vad det brukar kallas bara kan adressera 256 steg sedan måste man ändra någon variabel för att byta sida. Om du hoppar mer än 256 steg i ditt programm så kommer inte progammräknaren att komma tillbaks till rättställe igen när den stöter på ett return om du inte själv talar om vilken page den skall till. kolla PCL i debuggern och om inte det är någon returnsats som ställer till det när du debuggarkoden. Tror minnet du skall hålla koll på heter pclatch eller något sådant

[cyr]

Det är (väl?) bara när man manuellt håller på och mixtrar med PCL som det kan skita sig. T.ex. om man har lookup-tabeller där man lägger till en offset till PCL, eller state machines implementerade på samma sätt. Då måste man se till att ha rätt värde i PCLATH.

[ClasseMan]

Jo det är nog sant. När du säger det så har jag nog aldrig haft det problemet annars.

[Johan.o]

Enligt databladet;
Program räknaren är 13 bitar, villket ger att den kan adressera 8192 adresser.
Men CALL och GOTO har bara 11 bitar för adressering, villket ger 2048 adresser.
Därimot har RETURN tillgång till 13 bitar adressering.
Det är ju helt otroligt! man måste fixa till PCLATH vid varje goto och call!

Ska studera exempel 2-1 på sida 30.. förhoppningsvis går det att lösa på något snyggt sätt (hoppas).
Annars kan jag ju alltid rycka loss tånaglarna, det är ju ungefär lika roligt

[cyr]

Aj, var det så illa.

Har nog aldrig använt mer än 2k words i en PIC16 så jag har väl sluppit tänka på det.

PIC18 är mycket trevligare vad gäller såna detaljer, de har lyckats bra med att fixa de mest irriterande "defekterna".

Men i vilket fall som helst, så är det nog bara när man hoppar *mellan* olika 2k-pages som man måste fixa PCLATH, och ett litet makro borde kunna fixa till de tre (?) instruktioner som behövs för att göra ett sådant call t.ex.

edit: Den här sidan från PIClist har ett makro "long_call" som automagiskt sätter upp PCLATH när det behövs.

http://www.piclist.com/techref/microchi ... /snipp.htm

[Johan.o]

Det där var intressant länk.

jag brukar göra så att jag lägger alla subrutiner högst upp i minnet,
har för mig att man ska det, så det gör att "huvudprogrammet"
hamnar i något 'högre' bank.
Det borde betyda att vid
org0
goto main

så måste jag ställa in bank efter vart 'main' ligger?
men call.. det är ju inte säkert att alla mina subrutiner får plats i bank 0.
Kommer long_call att funka ändå?
hur blir det med goto, behöver antagligen bara oroa mig för det om jag
gör ett goto mellan två banker, men det känns som det är lätt hänt.
Resonerar jag rätt?
Jag känner att jag inte riktigt fattar hur det fungerar.

[henkebenke]

Är glad att man använder AVR......

[Johan.o]

Vid tillfällen som dehär kan jag förstå varför.
jag menar hur svårt och dyrt kunde det igentligen vara att
göra adressbussen lite bredare?

Antar att det är kompabilitet bakåt som är räven?

Dessa jäv*ar banker är jobbigt.