Fråga om GPR som pekar mellan banker

[Erik M]

Grejen med detta "överlapp" är att man t.ex. kan ha den lagring av status osv. som behövs vid interrupt att det alltid fungerar utan att man behöver växla bank eller liknande.

Hur menar du då icecap?

Vad skulle kräva multibanksstatus under ISR?

...underförstått vad gäller GPR då alltså.

[sodjan]

Jag är inte med riktigt, är det fortfarande något oklart kring det?

[Erik M]

Vad icecap menar på är synnerligen oklart.

[sodjan]

Icecap menar exakt samma sak som jag skrev två inlägg senare.

En del av GPR är "unbanked" för att underlätta "context-save" vid interrupt.

Jag förstår inte din fråga eller om något fortfarande är oklart.

[Erik M]

Det är bara det att context save bara innefattar två stycken GPR, exempelvis old_W och old_S. Båda inom det "normala" singelbanksspannet.
Och man är skiftar inte bank bara för att man är inne i en ISR.

Så på vilket vis har det med ISR att göra?

[sodjan]

> Så på vilket vis har det med ISR att göra?

Precis det du säger, att spara context utan att behöva skifta bank (vilket ju
alltså ändrar t.ex status registret). Det har ju allt att göra med ISR...

> Båda inom det "normala" singelbanksspannet.

Vad menar du med "singelbanksspannet"? Minne utanför "unbanked memory"?
I så fall har du fel. "Context save" *måste* ske till "unbanked" memory! Annars vet
du inte om det sparades till (t.ex.) 20h/21h (i bank0) eller till A0h/A1h (i bank1).

Så dina old_W och old_S *måste* ligga inom 70h till 7Fh (vilket alltså är samma
fysiska minne som F0h till FFh).

> Och man är skiftar inte bank bara för att man är inne i en ISR.

Inte "bara för", men det är ju inget som hindrar att man gör det.
Precis som vanligt alltså.

[Erik M]

Nu ser jag vad tanken är.

Om man är ute å valsar i vilken som helst slumpmässig bank då behöver de GPR som påverkas, i och med att ISR sker, vara av "multibankstyp".
Man bör oxå säkerställa att man är i rätt bank för vad som ska utföras inom ISR.

Så var det. Ju.

[sodjan]

Japp, just i det ögonblick to avbrottet inträffar så vet man ju
inte vilken bank man befinner sig i, helt korrekt. Och man kan
inte ändra i ISR'en, för då man kan inte återställa efteråt.

Så snart man har sparat det som behövs så kan ju ISR'en sedan
skifta banker som den vill. Allt kommer att återställas till "rätt" bank
(d.v.s. den bank som var aktiv då avbrottet skedde) i och med att STATUS
läggs tillbaka som den sista operationen före "return from interrupt", RETFI.

[Erik M]

Det är tråkigt att MicroChip inte använder "multibankadressering" på ett bättre vis - eller hoppar över det helt och hållet.
Varje SFR och varje del av varje SFR är redan unik - ergo möjlig att nå direkt, på samma vis som "multibanksadresserade" GPR. Om BSF STATUS, 0x5 / BSF TRISIO, TRISIO5 istället var BSF TRISIO5 så skulle mycket vara vunnet.

När man tittar på ex PIC16F1574 ser det dock ut att gå adressera, göra innehållet tillgängligt, direkt... på något vis.

Enklast vore väl att skriva en INC med macron, som löser detta, och låta bli använda större delen av "PICxx*x*.inc"...

Typ...
TRISIO5_0 MACRO
BANKSEL TRISIO
BCF TRISIO, TRISIO5
ENDM

Även om det egentligen borde räcka med BCF TRISIO5 - eftersom vi vet att detta egentligen ser ut som BCF 0x8C, 0x5...

Nackdelen med macrot ovan är den uppsjö med extra, och onödiga, BCF & BSF som BANKSEL skapar. Onödiga då varje SFR och GPR och varje del av dem redan är unikt adresserade, och tillgängliga.

Men så enkelt ska det inte vara...

[Erik M]

RETFIE, inte RETFI.
Att förkorta, stava, "General Purpose Registers" fel är en sak.
Att stava fel på instruktioner eller register fungerar inte.
Att, vid diskussioner, hoppa över bank och register och hålla sig till namnet (som är unikt, till skillnad från bank och register) på bitarna i registret underlättar och gör skrift klarare.

Tycker jag.

[sodjan]

Ja, adresserna till alla register är ju så klart i grunden unika. Problemet är
att de tillgängliga adress bitarna i instruktionerna inte räcker till förutom
på de allra minsta modellerna med endast en bank.

Macron fungerar inte, om man tänker till lite. Fundera på "skip" instruktionerna.

Och det är rätt, RETFIE ska det vara, det kändes att något var fel...

Sen finns det de som har byggt egna pre-processorer för MPASM där
det bl.a. ingår spårning av banker så att motsvarigheten till BANKSEL
kan kolla vilken bank som faktiskt är aktiv och ofta helt utesluta
BCF/BSF i de fall där det inte behövs.

Och som du säger, de nyare PIC16F1xxx modellerna har även ett linjärt
adress utrymme där hela GPR minnet adresseras som en kontinuerlig area.
Det beskriv i "3.6.2 LINEAR DATA MEMORY". Praktiskt för att t.ex. ha buffers
som är större än de 80 bytes som får plats i varje bank.

[TomasL]

Man skall alltid använda vedertagna namn på saker, då det underlättar för alla, speciellt för de nybörjare som eventuellt läser trådarna och försöker lära sig nånting.

Dessutom, om man använder korrekta och vedertagna namn så undanröjer man för det mesta risken för missförstånd (och man själv gör färre misstag)

[Erik M]

Macron fungerar inte, om man tänker till lite. Fundera på "skip" instruktionerna.

Jag har inte grävt mig ner i begränsningarna tillräckligt för att spontant komma på vad du menar. Utveckla gärna.


Linjärt för GPR, men inte för SFR?

Problemet är att de tillgängliga adress bitarna i instruktionerna inte räcker till förutom på de allra minsta modellerna med endast en bank.

Men varje bank har, PIC12F683, 127adresser - vilket räcker för både SFR och GPR. Visst, något färre GPR...

Men OK, jag förstår hur du menar.

Vad jag inte förstår är varför addera diverse externa MSB, dvs bankadresser, horisontellt, istället för vertikalt.
De är ju för i hela friden redan givna en vertikal adress! En unik vertikal adress.
För PIC12F683...
00h - 1Fh > SFR bank 0 (med lite onyttjade luckor)
20h - 7Fh > GPR bank 0
80h - 9Fh > SFR bank 1 (med lite onyttjade luckor)
A0h - BFh > GPR bank 1
C0h - EFh > minneslucka bank 1
F0h - FFh > GPR bank 0 70h - 7Fh

Var och en inom åtta bitar.
Att var och en sedan har åtta bitar är inte värre än de sexton bitar som redan hanteras, exempelvis CCPR1L och CCPR1H etc.


Problemet förefaller ligga i hur instruktionerna är byggda.

Dels destination - ha en OPCODE för vardera ADDWF f, d etc, de är inte så många, skulle frigöra den nödvändiga biten. Alltså ADDWFF respektive ADDWFW.

Sedan blir adresseringen av OPCODE i sig märklig när den ändrar antal bitar den består av.
Vad skiljer ex 100111001 från 100111001?
Alltså 100111 001 från 10011100 1...?
Ska de gå att skilja åt måste minst en bit avskiljas från "OPCODE" till "typ av OPCODE", alltså bit- eller byteorienterad.
Dvs 0 00111 001 respektive 1 0011100 1.

MicroChip har krånglat till det... för oss.

[Erik M]

Det blev lite tillägg ovan...

[lillahuset]

MicroChip har krånglat till det... för oss.

Nej Erik, Microchip är oskyldiga. Det är självförvållat så bara att bita ihop.