bankad PIC

sodjan · Inlägg av **sodjan** » 27 oktober 2007, 18:24:00

BoF, inte många rätt där...

Om du byter ut "banker" mot "pages" så blir det lite bättre, men å
andra sidan så är det ju inte det som tråden handlar om i alla fall.

> det kanske inte alltid fungerar på en PIC,...

Och exakt vilket rellevans har det i en tråd om PIC i så fall ??

> så vilken är snabbast?

Omöjligt att svara på utan att veta hur t.ex push/pop till/från stacken
är implementerat. Är det något som sker "under the hood" eller är det
via PUSH/POP instruktioner ?

EDIT:
persika, posta gärna *kompletta* kodexempel som går att testköra
utan att behöva lägga till en massa...

BoF · Inlägg av **BoF** » 27 oktober 2007, 18:41:37

Nää Tur en använder banksel och pagesel rätt i PIC programmen i alla fall

Läste väl inte tillräckligt noga vad tråden egentligen handlade om!
Så jag smyger ut från tråden lika lätt som jag kom in i den

ucadv · Inlägg av **ucadv** » 27 oktober 2007, 20:25:10

>Omöjligt att svara på utan att veta hur t.ex push/pop till/från stacken
>är implementerat. Är det något som sker "under the hood" eller är det
>via PUSH/POP instruktioner ?

säg att vi byter bank med en enda instruktion: BSF STATUS, RP0

anta vidare att en push & pop är en enda instruktion (1 clk) i vår uC (nu är jag generös).

vi håller på att designa en uC på jobbet just nu (jag arbetar med FPGA och ASIC). Jag blev tvungen att lägga in (register) bank select för att...tja, ni som har följt tråden vet nog redan varför

edit: -

Marta · Inlägg av **Marta** » 27 oktober 2007, 23:11:37

Men då till frågan, VARFÖR pusha minnesregister till stack (som för övrigt inte finns i en PIC)? ISR kan ju använda helt andra adresser till det som den skall göra utan att behöva krångla, eller förutsätter Du t.ex. en flyttalsrutin som skall användas och där dess arbetsregister skall sparas?

För övrigt är det ofta att hela uppgiften i princip sköts i en eller flera ISR. Grundprogrammet gör bara konfigurering och drar igång det hela. Just den typ av program som man har microcontrollers till blir ofta bäst på det sättet.

sodjan · Inlägg av **sodjan** » 27 oktober 2007, 23:51:30

Skit samma, jag ser fortfarande inte hur detta är rellevant för PIC...

ucadv · Inlägg av **ucadv** » 27 oktober 2007, 23:59:49

hmmm... jag skrev först ett långt svar till marta, men sen insåg jag att hela den utdragna diskussionen och missförstånden kan bero på att vi har så olika bakgrund.

får jag fråga, vad har du för bakgrund marta? vilka processorer och språk brukar du använda?

jag vill också be om ursäkt för att ha snott persikas tråd

v-g · Inlägg av **v-g** » 28 oktober 2007, 00:12:33

Alla processorer har sina styrkor/svagheter/egenheter, detta ser jag bara som en som PIC har. Det lär säkert gå att lösa det både bättre och sämre hur snabbt det är tror jag inte någon av oss är att avgöra.

Gammalt skit finns i massor i både µc och stora datorer världen. Detta KAN bero på ett val som gjordes för 5-10-15 år sen och som de senare tvingats stå med. Kolla bara på MS och PC vilka gamla grejjor det sitter på dem och hur arkitekturen ser och har sett ut. Fortfarande fungerar win98 på en flångny dator(sjukt nog finns det också oftast drivrutiner).

Fördelen som JAG ser det är att genom att banka kan använda SFR som vanliga register dvs flytta/läsa/skriva dem precis som vilken annan adress som helst. De kunde säkert lagt längre instruktioner (dvs inkludera de två BITar som utgör bankningen) som gör allt detta. Nu är det inte så och det är bara att gilla läget som Ledin säger eller använda andra µc.

PIC18 är för övrigt mycket bättre i detta avseende.'

Kan ha fatalt fel och även fattat fel, reserverar mig för detta

Marta · Inlägg av **Marta** » 28 oktober 2007, 06:34:15

Svar till ucadv

Det hade varit intressant att få läst Ditt långa svar....

Min bakgrund är att jag är självlärd. Började då jag var 16, det var då mikroprocessorer började komma. Första maskinen var ett hembygge med RCA CDP1802 och det ovanligt stora minnet 1K i form av 8x2102. LED-displayer och knappar för att trycka in hextal binärt en nibble i taget. Processorn valdes för att den hade inbyggda faciliteter för att ladda in program utan att ha någon firmware. Det gällde att trycka rätt, för det gick inte att backa innan "systemprogramvaran" var inknappad och det gick att fortsätta med mjukvaruloader.

Efter denna blev det hembyggd Z80, köpt 6502 (AIM65) som därefter övergick i ett helt hembyggt system med floppydrives och riktig bildskärm. Högnivåspråket där var tyvärr BASIC i brist på annat. Fanns en Pascal-implementation, men den var förfärlig... Därefter köpt Z80 med CP/M och sedan PC/AT ett antal år senare.

Språket var ju givetvis assembler till att börja med, handkodad med papper och penna... AIM65 och framåt var riktig assembler. Sedan gjode jag Det Stora Misstaget och började på Pascal (Borland TP) istället för C. Har även kännt lite på uddaspråk när jag körde CP/M, där var det en salig röra.

Numera är det assembler och Pascal (Delphi eller TP beroende på miljö) som gäller. Tycker fortfarande om enkla hembyggda maskiner och har en NEC V20 med 512K RAM och 4x20 tecken LCD som ligger här på bordet. En V30 är på gång som nästa projekt. De processorerna har nog det mest väldisponerade instruktionssetet av alla.

Den enda microcontroller jag sysslat med "på riktigt" är bara PIC. Både 16 och 18. Den senare är ju klart starkare, men inte p.g.a. banking som jag ser det. Har funderat lite på andra och bl.a. kikat på Altera's FPGA en gång, men gillar det inte.

Det är alltså inget avancerat jag håller på med, utan mest en massa kladd och tidsfördriv som synes. Tycker om saker med detaljförståelse, alltså inte högnivåspråk och jätteavancerade saker som bara finns där. Jättebra till stora avancerade projekt, men till små hobbyprojekt finns det inget som slår assembler!

Sammanfattningsvis så har jag det här som en hobby, precis som säkert många av oss här om än inte just Du och då är det viktigaste att ha roligt och tycka det är intressant. Inte att vara maximalt produktiv. Trevligare med saker man förstår än att tillämpa andras färdiga lösningar. Tycker jag i varje fall...

ucadv · Inlägg av **ucadv** » 28 oktober 2007, 13:00:08

ok, då har vi ungefär samma bakgrund. jag började dock arbeta med inbyggda system (det vill säga, jag fick betalt för att ha kul) och då blev jag tvungen att följa utvecklingen i branschen (68k -> x86 -> ... -> PIC ->... -> ARM och på mjukvarusidan: pascal -> C -> C++ -> Java/C#??) och tog under tiden universitetexamen inom inbyggda system, men jobbar numera mest med FPGA och ASIC.

Jag använder ARM, FPGA & AVR i mina hobbyprojekt, mest för att jag har fått ett stort antal utvecklingskort via jobbet. Jag försöker ocskå lära mig lite mer om analog elektronik men det verkar som jag helt saknar talang för det

Nu till ditt svar, visst kan man koda en uC på det sätt vi gör här på forumet, men så fort projektet blir större, eller om man använder kod som någon annan skrivit, om man är flera som kodar på samma projekt eller om man använder C i delar av projektet så blir det svårt att hålla koll på vem använder vilka register. Då finns det oftast en "standard" för hur man ska använda registrarna så att alla kan komma överens med varandra och med C kompilatorn. Här finns till exempel en för ARM, om nån orkar läsa:
http://www.arm.com/pdfs/aapcs.pdf
Hittade ingen motsvarande för PIC eller för interrupt, men en sådan brukar följa med C kompilatorn.

Det finns alltså standardsätt att göra detta, men sånt gäller större projekt eller små projekt man hoppas ska bli stora nån dag. Det gäller knappast våra små hobby projekt, men jag försöker ändå följa dessa regler eftersom jag har funnit de mycket användbara.

ok, skit samma. tillbaka till bankerna: när jag hör ordet banker tänker jag
1. hur används banker inom industrin
2. varför införde vi banker i vårt senaste hårdvaru projekt på jobbet.
3. hur brukar jag använda banker i mina mjukvaru projekt.
och detta är kanske inte alltid vad ni tycker är det rätta svaret

... men vi är alla olika och något som funkar för mig kan mycket väl vara helt j-a pucko för resten av världen

--
nu gäller inte allt detta jag har skrivit här och i tidigare inlägg alltid en PIC , men jag tror jag har redan påpekat detta högre upp i tråden.

persika · Inlägg av **persika** » 28 oktober 2007, 13:29:45

Intressant disskussion här är.

Jag har försökt komma underfund med
hur det funkar med bankarna, men inte
fått det funka på det sätt jag tänkt.

Har gjort några exempel, som adderar två variabler
som ligger på "samma ställe", men i olika bankar.

Får inte rätt resultat, *båda* variablerna ändrar sig samtidigt.
Det blir inte rätt i MPSIM, har inte kört det i en riktig pic'krets.

Ett exempel med att addera variablerna direkt,
och ett annat med pekare och som switchar mellan bankarna för att välja variabel.

Är det någon som förstår varför det blir så här?

Här är ett komplett körbart exempel, som Sodjan bad om:

;++++++++++++++++++++++++++++++++++++++++++++++++++++

list p=12f675 ; list directive to define processor
#include <p12f675.inc> ; processor specific variable definitions

errorlevel -302 ; suppress message 302 from list file

__CONFIG _CP_OFF & _CPD_OFF & _BODEN_OFF & _MCLRE_ON & _WDT_OFF & _PWRTE_ON & _INTRC_OSC_NOCLKOUT

ORG 0x000 ; processor reset vector
goto main ; go to beginning of program

main

; remaining code goes here

; Exempel, addera två tal på olika sätt

TAL equ 020h
TAL2 equ 0A0h

;------------------
; Exempel 1

; lägg värden i TAL och TAL2
banksel TAL
movlw 011h
movwf TAL ; TAL := 011h

banksel TAL2
movlw 022h
movwf TAL2 ; TAL2 := 022h

; addera de två talen
banksel TAL
movf TAL, w
banksel TAL2
addwf TAL2, w

; efter detta exempel får w = 044h, skulle varit 033h

;------------------
; Exempel 2

; ställ in pekare
movlw TAL
movwf FSR ; pekar på TAL

; lägg värden i TAL i båda bankarna
bcf status, RP0 ; bank 0
movlw 011h
movwf INDF ; (TAL,bank0) := 011h

bsf status, RP0 ; bank 1
movlw 022h
movwf INDF ; (TAL,bank1) := 022h

; addera de två talen
bcf status, RP0 ; bank 0
movf INDF, w
bsf status, RP0 ; bank 1
addwf INDF, w

; efter detta exempel får w = 044h, skulle varit 033h

;------------------
nop

END ; directive 'end of program'

;++++++++++++++++++++++++++++++++++++++++++++++++++++

sodjan · Inlägg av **sodjan** » 28 oktober 2007, 13:36:39

> och detta är kanske inte alltid vad ni tycker är det rätta svaret..

Svaret på vadå ? Inte på frågan som uttrycktes i början av tråden i alla fall.
Notera att jag inte alls anser att du har *fel* i princip, det är bara inte
rätt svar i just denna tråd...

> men vi är alla olika och något som funkar för mig kan mycket väl vara helt j-a pucko för resten av världen

Det tror jag inte alls.
Du har säkert studerat t.ex hur register arkiteikturen i en Sparc ser ut, där
swppar man banker (eller windows är kanske ett bättre uttryck) hej vilt. Och
det ger bra interrupt prestande i *det* fallet. Alpha arkitekturen är ett
annat exempel på en high-end arkitektur med avancerad interrupthantering.
Men inte det heller är speciellt rellevant...

> Då finns det oftast en "standard" för hur man ska använda registrarna så att alla
> kan komma överens med varandra och med C kompilatorn. Här finns till exempel
> en för ARM, om nån orkar läsa:

Är väl ganska normalt att man försöker definiera en "call-standard" i high-end miljöer.
Skummade igenom lite snabbt, och till stora delar innhåller det samma saker som
t.ex den call-standard som finns i OpenVMS, men i ARM fallet har man gjort det
enkelt för sig och begränsat sig till C/C++, i OpenVMS har man en gemensam
call-standard för *alla* supportade språk. Det betyder att man inte behöver
veta eller bry sig om i vilket språk den sub man anropar (eller LIB man
länkar till) var skriven i. Det är helt transaparant över MACRO (d.v.s asm),
Fortran, COBOL, BASIC, ADA, Pascal, C, C++ och några till som jag inte
minns på rak arm (!

). Det finns alltså motsvarande manual som heter
"HP OpenVMS Calling Standard". Länk nedan för den intresserade...

http://h71000.www7.hp.com/doc/82final/5 ... bbe-te.pdf

Från introduction sidan :

"Applies to all intermodule callable interfaces in the native software system.
Specifically, the standard considers the requirements of important compiled
languages including Ada, BASIC, Bliss, C, C++, COBOL, Fortran, Pascal,
LISP, PL/I, and calls to the operating system and library procedures."

sodjan · Inlägg av **sodjan** » 28 oktober 2007, 13:38:10

persika, bra att du får ner oss på PIC-jorden igen...

Koller lite mer på din kod senare i dag, just nu är vädret för vackert...

BoF · Inlägg av **BoF** » 28 oktober 2007, 14:11:01

12F675 har bara 64bytes
Bank 1 är enbart en spegling av bank 0, du har 22h både i TAL och TAL2 när du adderar
Vilket helt riktigt ger 44h.

Du kommer åt din variable oberoende i vilken bank som är aktiv.
När du lägger in talet 22h i position A0(TAL2) så får också 20h(TAL) samma värde.

Sodjan får rätta mig om jag har fel eller förklara på ett bättre sätt.

Marta · Inlägg av **Marta** » 28 oktober 2007, 15:01:56

Du har helt rätt, vi har varit så "duktiga" att vi underlåtit att läsa datablad....

Angående minneshantering i stora projekt så är väl svaret i dagens läge: Objektorienterad programmering! Perfekt när det är massor av folk som skriver på ett projekt av mastodontkaraktär. Åtminstone i teorin, men det är väl antagligen ändå en hel del arbete med systemintegrationen innan allt samsas som det skall...

persika · Inlägg av **persika** » 28 oktober 2007, 16:04:48

"Jag får nog skaffa glasögon..."

Det står mycket riktigt "accesses 20h-55h"
på området A0h-DFh i "Data memory map of the PIC12F629/675"
i manualen DS41190C

Då är det ju inte så konstigt att mina exempel-program inte funkar som tänkt.

Så jag provade med en "fuling", satt i stället:

TAL equ 01Eh
TAL2 equ 09Eh

samma som ADRESH o ADRESL använder.

Då funkar "Exempel 1" som tänkt,
men inte "Exempel 2", exemplet med att bara switcha bankar.

Hur kan det komma sig ?