Fråga om GPR som pekar mellan banker

[lillahuset]

Finns överhuvudtaget ingen anledning att fundera på varför man gör si eller så.

Nu blev jag faktiskt väldigt förvånad. Det finns väl all anledning att fundera på varför man gör si eller så.
Hur skulle man annars kunna välja en bättre väg om man har råkat göra ett misstag? Jag funderar alltid över det men inser att jag inte alltid är tillräckligt klarsynt. "It's hard to kill your darlings."

[lillahuset]

Erik M: Jag tror du ska välja en anständig C-kompilator istf assembler.
Byt upp dig till ARM så kommer du att få en helvetes inlärningskurva med periferi men sedan uppleva "Nirvana".

[sodjan]

Jag tror att Tomas syftar på varför teknikerna för 20 år sedan
valde den ena eller den andra kompromissen i designen.
Det kan ju vara lite kul som överkurs, men det viktiga måste
väl ändå vara att lära sig använda det så som det är.


> Så kunde det se ut såhär...
> BSF TRISIO5
> ...för all information finns redan.

Ja, för dig om mig finns all information där. Men inte för
processorn. I instruktionen för BSF finns det inte bitar nog
för att *unikt* peka ut TRISIO registret. Simple as that...

Naturligtsvis samma sak som Swech (och säkert jag själv tidigare)
redan har skrivit, men vad hjälper det...

[lillahuset]

Man bör inse PICarnas ursprung. Löjligt primitiva men kraftfulla I/O-processorer som skapades av GI, har jag för mig.

Vi började använda PIC16C52 tror jag det var. Snordyra EPROM-kretsar med fönster fanns efter ett par år. När vi började fanns bara fönsterlösa, så gjorde man ett misstag var det bara att rätta och bränna en ny. Vi var vana vid bipolöra PROM och PAL så vi upplevde det som "business as usual". Men cykeltiden var 1us och instruktionsuppsättningen intressant. Det var alltså en "Peripheral Interface Controller", och vi använde den så.

Sedan började Microchip fixa och dona med en "vacker?" arkitektur och det dök upp missfoster som PIC18xxxx och en massa annat konstigt. Ungefär vid millenieskiftet förklarade jag för mina kunder att om de ville använda PIC fanns det massor av konsulter som kunde hjälpa dem. Men jag var inte en av dem.

[Erik M]

Jag tänkte samma sak lillahuset, men vem orkar bry sig bemöta intet.

Vad jag nu egentligen frågade om, det övriga var frustration, var hur man kan flyttat bättre, som antyddes tidigare, med FSR istället för att använda BSR.

Alternativt om det går skriva koden rakt på, såsom den de facto används av processorn.

Det enda processorn möjligen gör, vilket inte förefaller troligt, är att den kommer ihåg vilken bank den står i alldeles själv. Det antyds av att man behöver tala om för den vilken bank den ska till härnäst - och om det är samma är det möjligen då så att det inte behövs 28 extra bitar, och en massa huvudbry.
Medans att behålla de fem MSB i adressen skulle eliminera alla dylika besvär...

Alternativt...

...om jag ska hoppa direkt till... MIPS?

Vad gäller Assembler kontra C (eller C++ eller VB eller ens Basic) är vad jag skriver för.
Det duger inte med de omvägar omvandlingen från C medför.

Vad gäller AVR så är det oxå, verkar det som, en kostnadsfråga.
De är ordentligt dyrare och med mindre och färre funktion. Typ.

[sodjan]

@lillahuset:

OK. Jag har kollat dina 6 inlägg så här långt, och jag kan faktiskt
inte se hur något av dom hjälper till att besvara frågeställningen.
Mest meningslöst dravel. Du har inte någon praktiskt erfarenhet
av PIC de senaste 16 åren men ändå anser du att du kan tycka
något om dagens kretsar. Hm...

[sodjan]

> Det enda processorn möjligen gör, vilket inte förefaller troligt, är att den kommer ihåg vilken bank den står i alldeles själv.

Självklart gör den det, bank-bitarna ändras inte av sig själva.

> Det antyds av att man behöver tala om för den vilken bank den ska till härnäst
> - och om det är samma är det möjligen då så att det inte behövs 28 extra bitar, och en massa huvudbry.

Om *du* som programmerade vet med säkerhet att du redan är i rätt bank
så behöver du självklart ingen extra BANKSEL. Men det är väl ganska klart?

> Medans att behålla de fem MSB i adressen skulle eliminera alla dylika besvär...

Och igen (får se om det "tar" denna gång), de får inte plats!

> Vad gäller Assembler kontra C (eller C++ eller VB eller ens Basic) är vad jag skriver för.

Den där meningen verkar "meningslös", jag fattar den inte i alla fall.

> Det duger inte med de omvägar omvandlingen från C medför.

Oklart vilka "omvägar" du syftar på.

[Erik M]

> Så kunde det se ut såhär...
> BSF TRISIO5
> ...för all information finns redan.

Ja, för dig om mig finns all information där. Men inte för
processorn. I instruktionen för BSF finns det inte bitar nog
för att *unikt* peka ut TRISIO registret. Simple as that...

Det var inte vad jag lade upp heller.

Vad jag lade upp var en princip - som möjligen fungerar tillsammans med FSR.
Vilket då oxå skapade grunden för den frågan - hur man egentligen och rent praktiskt nyttjar FSR, istället för omvägen om BSR.

Jag har en känsla av att jag får dissekera hex för att få ordning på detta - vad som egentligen händer.

[lillahuset]

sodjan: Nja, jag tror det var 2005 jag befriades från SISTA PIC-projektet. Men du har helt rätt, min kunskap är rätt begränsad. Även om jag emellanåt har läst på när det gäller PIC-arkitekturer.
Alla mina kunder som använde PIC och har fortsatt med nyutveckling har antingen gått över till AVR eller ARM Cortex-M.

Därmed inte sagt att PIC inte har en funktion att fylla. Men visst är dessa nya arkitekturer med start i PIC18 lite märkliga. Eller?

[Erik M]

> Medans att behålla de fem MSB i adressen skulle eliminera alla dylika besvär...

Och igen (får se om det "tar" denna gång), de får inte plats!

Eh... Va?
Det borde framgått rätt tydligt att jag förstått.
Om du tittar på mitt exempel ovan så... Är det väldigt tydligt att jag förstår det.
Det är ju till och med just detta problem jag belyser.

Dvs problemet är att genom att inte ha blivit givna plats för hela registrets adress så får vi som användare en massa fullständigt onödigt huvudbry.

[lillahuset]

Med tanke på att vi lever i det 21milleniet och kisel är nästan gratis förstår jag inte varför man inte använder ARM CortexMx (med x=0 till x=7).
Enda skälet jag kan tänka mig, förutom konservatism, är att processorerna är mer komplicerade. Speciellt I/O.
Prismässigt, över en riktigt låg nivå, är det ingen prisskillnad att tala om.

Nästan allt utom det allra enklaste är enklare att implementera i en "bättre" processor.

Ber om ursäkt om det här betraktas som OT.

[sodjan]

> Vad jag lade upp var en princip - som möjligen fungerar tillsammans med FSR.
> Vilket då oxå skapade grunden för den frågan - hur man egentligen och rent
> praktiskt nyttjar FSR, istället för omvägen om BSR.

Jag fattar inget av det där. Det verkar som att du har kört helt in i någon som
bygger på nått missförstånd. FSR är register för "indirekt adressering", det har
inget med banker att göra. FSR registren är stora nog för att hålla en komplett
adress till hela minnet, inklusive programminnet i flash.

Handlar frågan egentligen om hur man använder indexerad adressering?
I databladet för den senaste processorn du har nämnt (PIC12F1572) ligger
det i kapitlet "3.6 Indirect Addressing".

> Jag har en känsla av att jag får dissekera hex för att få ordning på detta - vad som egentligen händer.

Vad som "egentligen händer"? Jag fattar alltså fortfarande inte vad som är oklart.
Händer närdå? Igen så verkar det som att du har snöat in på något stort missförstånd...

> Om du tittar på mitt exempel ovan så... Är det väldigt tydligt att jag förstår det.

I så fall fattar jag *ändå* mindre! Är det så att du talar om något helt hypotetiskt
exempel på en processor som inte ens existerar? Och inte en diskussion om hur de
verkliga processorerna faktiskt fungerar? Ja, då kan du ju hitta på vad som helst och
"vad som egentligen händer" blir ju helt ointressant...

Ser att lillahuset igen försöker förklara hur det fungerar, men verkar
tyvärr ha misslyckats (igen). På't igen!

[TomasL]

> Så kunde det se ut såhär...
> BSF TRISIO5
> ...för all information finns redan.

Ja, för dig om mig finns all information där. Men inte för
processorn. I instruktionen för BSF finns det inte bitar nog
för att *unikt* peka ut TRISIO registret. Simple as that...

Det var inte vad jag lade upp heller.

Vad jag lade upp var en princip - som möjligen fungerar tillsammans med FSR.
Vilket då oxå skapade grunden för den frågan - hur man egentligen och rent praktiskt nyttjar FSR, istället för omvägen om BSR.

Jag har en känsla av att jag får dissekera hex för att få ordning på detta - vad som egentligen händer.

FSR är en omväg för att kunna läsa och skriva, i vissa lägen kan det förenkla, eftersom FSR är tänkt att fungera som stackpekare.

BSR är en mycket snabbare och bättre metod.

Din assemblator ser till att BSR alltid pekar på rätt bank när du använder Assembler makrot BANKSEL Register.
Vilket gör att du kan använda registeroperationerna på ett enkelt sätt.
Skall du använda FSR måste du först skriva till FSRH vilken bank du skall använda, därefter skriver du registeradressen till FSRL.
Först därefter kan du använda INDF registret i din registeroperation.

BANKSEL tar antingen 0 eller 1 instruktion, beroende på vad BSR pekar på.

Skall du använda FSR så är det alltid minst 1 instruktion extra dvs ladda FSRL med register adressen.
Om FSRH pekar fel så blir det ytterligare en instruktion.

Så för att Läsa/skriva en IO-Port med BANKSEL tar det 1 eller 2 instruktioner.
För att läsa/Skriva en IO-Port med FSR tar det alltid 2 eller 3 instruktioner.

Kort och gott, använd BANKSEL och glöm FSR/INDF i dessa fall.

[lillahuset]

Om man inte är "expert" på en "modern PIC-arkitektur" tror jag man har mycket att vinna på att programmera i C.

[TomasL]

C är nästa alltid bättre än ASM.