Svenska ElektronikForumet

Korp's förslag om banksel/pagesel är helt korrekta.
Så fort man har en device med > 2KW programminne, så
bör man tänka på det. Sen kan man alltid lägga närliggande
moduler som anropar varandra i samma CODE block (så att
de alltid hamnar i samma page) o.s.v.

Sen, *om* detta var ett problem i det aktuella fallet är en
annan sak, lite studium av MAP filen borde visa det. D.v.s
var i program minnet som de olika CODE blocken hamnade.

Pages var (är) en ny bekantskap för mig, så det är bra att ni tar upp det.
Men ni får en del frågor på köpet.

Jag börjar med att visa map-filen: Här kommer frågorna jag varnade för:
Jag kan se vilka minnesadresser som de olika blocken "hamnar" på,
men jag får inte ihop det med page. Vilka adresser börjar de olika ..pages(?) på?
Eller gör man på något annat sätt för att veta vilka block som ligger i samma page?
Vad är skillnaden mellan page och bank?

Jag hittar inget om page i databladet. Provade att söka, men hittade bara en väldig massa sidfötter. t.ex "page 7" osv.
Det enda jag hittade om pagesel i MPLAB-manualen var "Assembler help contains assembler directive
information (e.g., udata, pagesel, banksel.)", men det var inte riktigt vad jag var ute efter.

Så jag behöver nog mer info.

> Vilka adresser börjar de olika ..pages(?) på?

Framgår av "memory organisation" i databladet.

> Vad är skillnaden mellan page och bank?

Bank : dataminne (SFR/GPR)
Page : Programminne ("flash") (varje "page" är 2K-ord)

> Jag hittar inget om page i databladet.

Vilket datablad ?
Vilken processor ?

Framgår av "memory organisation" i databladet.

Precis det kapitlet som jag har uppe på andra skärmen.
Jag har lusläst det många gånger gånger utan hitta något om pages.

"2.1 Program Memory Organization
The PIC16F688 has a 13-bit program counter capable
of addressing a 4k x 14 program memory space. Only
the first 4k x 14 (0000h-01FFF) for the PIC16F688 is
physically implemented. Accessing a location above
these boundaries will cause a wrap around within the
first 4k x 14 space. The Reset vector is at 0000h and
the interrupt vector is at 0004h (see Figure 2-1)."

.."4k x 14 program memory space". Betyder det 14st pages?


Figur 2-1 visar "block" med olika adresser. Såhär:
______________
PC<12:0>
|
Stack Level 1
Stack Level 2
.
.
Stack Level 8

Reset Vector: 000h

Interrupt Vector: 0004
On-chip Program Memory: 0005 - 0FFFh
Wraps to 0000h-07FFh: 0800h - 1FFFh
______________

Det framgår säkert jättetydligt vilka adresser som de olika pages börjar på, men jag ser det iallafall inte.


Processor: PIC16F688.
Länk till databladet.
(Ser nu att det inte är samma version som jag hade, så jag laddade hem detta.)

OK.
De har gjort en tabbe i just 688 databladet.
Jämtför t.ex med motsvarande kapitel i 886 databladet :
(http://ww1.microchip.com/downloads/en/D ... 41291F.pdf).

Där framgår det tydligt vad "pages" är via de två extra bilderna som saknas i
688 databladet

Kapitel "2.3 PCL and PCLATH" ger lite ytterligare ledtrådar (ja, det står faktiskt
där om man tolkar texten korrekt, "The Program Counter (PC) is 13 bits wide.").

Generellt så är programminnet i en PIC16 *ALLTID* uppdelat i 2K-ord pages så
så snart man har en processor med > 2 K-ord programminne så blir "pages" något
man bör ta hänsyn till.

Jimmy, pagingproblemet tycker jag är ett typiskt problem för denna hobby som man upptäcker när man själv stöter på det. Det ges lite indikeringar här och var i datablad som man förstår när man väl känner till det.

Vår PIC-guru Sodjan brukar rekommendera PICmicro Mid-Range MCU Family Reference Manual som kvällslektyr, och där står det en hel del bra saker förklarat på lite bredare front än för just en specifik modell. Sen måste jag erkänna att jag inte läst den så noga som jag skulle önska. Jag har mest använt den som referens vid några tillfällen när jag tyckt att databladet beskrivit något lite väl kortfattat.

För paging-problemet känns kap 6 (6.2.6) relevant.

Det kanske är tydligt i alla fall, men jag vill bara notera att exemplet
som finns i Ref manualen : har det lilla "poblemet" att man måste *veta* att SUB_P1 ligger just i Page1 !

Bättre : På så sätt så kommer MPLINK alltid att sätta korrekt page oavsett om
SUB_P1 kanske flyttar mellan pages från en build till en annan. PAGESEL
genererar rätt BCF/BSF instruktioner beroende på var saker och ting ligger.

Ovanstående hänger väl ihop med att större delen av Ref Manualen
skrev innan relocateble code var "på modet", så att säga.

Köp en MAX6818, eller läs i dess datablad hur de avstudsar ingången och gör en tillståndsmaskin i mjukvara som fungerar på liknande sätt. Kretsen ger även ESD-skydd.

Det mesta i det här inlägget skrev jag igår precis innan Korp's inlägg.
Tryckte "Förhandsgranska" och såg då länken i Korp's inlägg som jag klickade på.
Då låste sig datorn. Eftersom jag hade en del osparade grejer igång så lät jag den vara på
och åkte till sommarhuset och jobbade. Nu när jag tittade till datorn nu så hade den vaknat
och några nya inlägg hade skrivits i tråden.



Sodjan:
Där framgår det tydligt vad "pages" är via de två extra bilderna som saknas i 688 databladet

Det var viss skillnad ja. Ok, då är jag med.

I PIC16F688 är alltså de olika bankerna fördelade mellan 0005h - 01FFh.
Eftersom databladet inte avslöjar startadressen för varje bank så måste
jag isåfall veta antalet banker för att kunna räkna ut startadresserna.

Men samtidigt nämner ni pagesel... Så då behöver man väl inte hålla koll på adresserna i map-filen?
Det är kanske lika bra att förutsätta att olika CODE-block kommer att
hamna i olika pages i en PIC16 och därför alltid använda pagesel.


Mr M:
Tack för tipset, men nästan 40kr för en krets som gör i princip samma sak som gratislösningarna
som kommit i tråden och som jag kan använda hur många gånger som helst?
Tydligen så ska en mjukvarulösning fungera. Det är bara jag som har något trassel i min kod..

Jag fortsätter gärna klura på det här, för det vore väldigt kul att se vad som är felet.



Någon som har en länk direkt till *PDF*-filen PICmicro Mid-Range MCU Family Reference Manual
så att jag kan ladda hem den utan att först visa den med webläsarens PDF-plugin?

> Någon som har en länk direkt till *PDF*-filen PICmicro Mid-Range MCU Family Reference Manual

http://ww1.microchip.com/downloads/en/d ... 33023a.pdf
Dessutom har väl pluginen an "save" funktion !?

> I PIC16F688 är alltså de olika bankerna fördelade mellan 0005h - 01FFh.

Det här är lite märkligt, databladet verkar helt fel på flera punkter.
LKR (16F688.LKR) filen har dock rätt : Du kan alltid kolla LKR filen, om inte den är rätt så skulle inte
någon "build" kunna fungera alls...

> så måste jag isåfall veta antalet banker för att kunna räkna ut startadresserna.

två saker...
1. Du behöver aldrig räkna ut det, det är *ALLTID* samma adresser (i PIC16 arkitekturen).
2. Du behöver inte veta adresserna, MPASM/MPLINK och PAGESEL tar hand om det (och det finns i LKR filen).

> Det är kanske lika bra att förutsätta att olika CODE-block kommer att
> hamna i olika pages i en PIC16 och därför alltid använda pagesel.

Normalt gör det inte det om du inte har mer än 2K-word kod totalt (inkl tabeller o.s.v.).
Jag tror inte att det är det som är ditt problem just nu. Och det är lätt att verifiera
via MAP filen genom att kolla var koden faktiskt hamnade.

Vad jag skulle ha gjort i detta läge är att köra MPLAB SIM och simulera en knapptryckning. Dels en som gör en knapptryckning som bara varar ett ISR och även en som vara 2 ISR. Jag skulle singlesteppa igenom debounce-delen och se att allt reagerar korrekt innan jag ens tänkte på extern hårdvara.

Min erfarenhet är att "mitt sätt" fungerar med MÅNGA olika brytare i MÅNGA olika scenario helt utan problem så jag fasthåller att det är ett logisk fel i debounce-rutinen i nuläget men då reaktionerna inte är säkerställda är det omöjligt att veta vad som går fel och varför de gör det.

Och är man lat kan man (i SIM) ställa knapp-porten till utgång köra till en interrupt kommer, ställa porten till '1', stega igenom och när porten är läst ställer man den till '0' igen, sedan stoppar man exekveringen igen vid nästa interrupt och ser hur det blir, detta simulerar att knappen bara är aktiverat under 1 ISR.

När man simulerar att den är aktiverat under 2 eller fler låter man portpinnen vara '1'.

På detta sätt kan man testa programmets funktion realistisk utan att skriva en stimuleringsfil.

Sodjan:
Tack för länken.

Jodå, pluginen har en save-funktion, men av någon anledning "frös" hela webläsaren när jag klickade på Korp's länk.
(Tror det beror på att webläsaren har tuggat i sig så pass mycket minne att Windows swap-"minne" får jobba på högtryck..)
Jag ville därför ladda ner en "rent" pdf-fil utan att först visa den i webläsarens pdf-plugin.

Hade inte en tanke på att man kunde kolla det (bankernas adresser) i LKR-filen.


"Jag tror inte att det är det som är ditt problem just nu."

Men det var intressant och lärorikt ändå.


Icecap:
Jag har kört koden väldigt många gånger med MPLAB SIM och bara fått 0 på current och key. (Jag går efter detta inlägg.)
Resten har fungerat precis som det skulle.

Men efter många dagars analyserande så trillade polletten äntligen ner! Ja, det fungerar! Det fungerar bra dessutom.

Svaret låg i:

6: "Key" = ("Work" XOR "Current") AND "Current"

Nu är det så att i "Current" sätts motsvarande bit eftersom knapparna avkänns stabilt, när en knapp är läst ska man sätta motsvarande bit i "Current", då försvinner den knapp fram till man släpper och trycker igen.

Jag hade missförstått hur det var tänkt att man skulle använda current.
Nu när jag väl löst det så är texten hur glasklar som helst:
när en knapp är läst ska man sätta motsvarande bit i "Current"

Jag kan inte förklara det tydligare än den raden, nu när jag väl fattar.


"Min erfarenhet är att "mitt sätt" fungerar med MÅNGA olika brytare i MÅNGA olika scenario helt utan problem så jag fasthåller att det är ett logisk fel i debounce-rutinen i nuläget men då reaktionerna inte är säkerställda är det omöjligt att veta vad som går fel och varför de gör det."

Jag misstänkte starkt det. Det är därför som jag ville få det att fungera, vilket det nu alltså gör.
Det var en kul födelsedagspresent!