Sida 1 av 2

PIC assembler direktivet RES

Postat: 15 juli 2007, 14:04:34
av Johan.o
Har lite problem med att allokera RAM-minne i en pic18F1320.

Precis börjat att testa relocatable mode.

Kod: Markera allt

						udata_shr 
	cylinder_memory		RES	d'125'				
Fungerar, men som jag förstår läggs det i accessbank.
Och det vill jag inte i detta fallet..

Så ett rimligare alternativ borde vara:


Kod: Markera allt

					udata 
	cylinder_memory		RES	d'125'
ger Felmeddelande:

Kod: Markera allt

Error - section '.udata' can not fit the section. Section '.udata' length=0x0000007d
Errors    : 1


rimligen beroende av hur min lkr-fil ser ut.
Se nedan, desutom skulle jag villja placera det speciellt i bank noll
med början på adressen h'80', hur ska jag göra?

Kod: Markera allt

// $Id: 18f1230i.lkr,v 1.1.2.2 2006/03/03 23:33:13 curtiss Exp $
// File: 18f1230i.lkr
// Sample ICD2 linker script for the PIC18F1230 processor

// Not intended for use with MPLAB C18.  For C18 projects,
// use the linker scripts provided with that product.

LIBPATH .

CODEPAGE   NAME=vectors    START=0x0            END=0x29           PROTECTED
CODEPAGE   NAME=page       START=0x2A           END=0xE3F
CODEPAGE   NAME=debug      START=0xE40          END=0xFFF          PROTECTED
CODEPAGE   NAME=idlocs     START=0x200000       END=0x200007       PROTECTED
CODEPAGE   NAME=config     START=0x300000       END=0x30000D       PROTECTED
CODEPAGE   NAME=devid      START=0x3FFFFE       END=0x3FFFFF       PROTECTED
CODEPAGE   NAME=eedata     START=0xF00000       END=0xF0007F       PROTECTED

ACCESSBANK NAME=accessram  START=0x0            END=0x7F
DATABANK   NAME=gpr0       START=0x80           END=0xF3
DATABANK   NAME=dbgspr     START=0xF4           END=0xFF           PROTECTED
ACCESSBANK NAME=accesssfr  START=0xF80          END=0xFFF  
edit: relocatable

Postat: 15 juli 2007, 15:52:58
av v-g
Du vet att efter RES skriver du hur många bytes du vill allokera. 125 är kanske lite stort i en variabel :wink:

Jag är inte säker på vad du vill göra men ska du skapa en variabel med ett startvärde på X så är IDATA det direktiv jag TROR du ska använda. Är inte 100 på relocatable code själv :)

Postat: 15 juli 2007, 16:07:17
av Johan.o
Det finns definitivt 125 byte byte att allokera av gpr, så att det är stort håller jag inte med om, ok.. om tanken att varje RES är en variabel så då.. visst då är det lite stort :D

Men det funkar ju med udata_shr, men inte udata, vilket stör mig lite.
Så jag vill först veta varför det inte fungerar, sedan:

Hur ska man allokera exempelvis en buffert, eller stack som jag försöker göra här då?

Postat: 15 juli 2007, 16:38:35
av v-g
Stack finns redan ;) Antar att du vill ha en större dock.

Får säkert på näbben när de riktiga kunniga kommer men jag försöker ändå.

UDATA allokerar inte i shared data som UDATA_SHR dvs PICen kan behöva banka för att komma åt variablerna. Hur detta fungerar exakt vet jag inte bara att jag ibland måste slänga in en BANKSEL efter att ha "meckat" i de variablerna som inte ligger i shared memory.

Jag liksom du skulle önska att dessa definitioner gicks igenom helt och med exempel i tex hjälpen. Nu får man fanimej gissa och fråga sig till exakt hur de fungerar. Detta tycker jag är en punkt som microchip missat stort på.

Det finns mer att läsa idenna PDF Hoppas du finner svar där.

Edit:Förresten så _TROR_ jag UDATA_SHR inte hör till pic18. Jag kör med UDATA_ACS

Postat: 15 juli 2007, 18:46:31
av BoF
gpr0 har 115 byte enl. lkr filen, att då reservera mer än detta går ju inte!

Postat: 15 juli 2007, 18:48:00
av opatagio
Är också nyfiken på hur udata och banksel förhåller sig när man ska använda variabler i koden. Även direkt exempel av kod i stil med:

Kod: Markera allt

MY_VARS    udata
var1   res  1   ;//  Variabel 1 placeras i bank1
var2   res  1   ;//  Variabel 2 placeras i bank0

STARTUP  code  0x0000
...............

banksel TRISA    ;// Välj bank1
movlw  d'5'
movwf  var1
Notera att jag har ingen aning om ovanstående är rätt tänkt.

Som sagt, en mer utförlig guide i ren klartext (suttit och bläddrat genom 2-3 olika microchip-datablad för att inse vad CODE direktivet gör) skulle verkligen vara uppskattat.

Postat: 15 juli 2007, 18:58:52
av sodjan
> Stack finns redan...

Jag är övertygad om att det inte handlar en return-adress-stack !!

UDATA_SHR är inte rellevant till PIC18.
Den har ju inget "shared memory" eller "unbanked memory" !

Använd UDATA_ACS för att lägga variabler i "Access bank"
eller bara UDATA för att låta MPASM/MPLINK placera dom
någon annanstans...

När det gäller så pass stora allokeringar som 125 bytes på
"ett bräde", så brukar man kanske skapa en egen "data section"
i LKR filen, det är lite mycket på en gång att helt överlåta till
MPASM/MPLINK.

> desutom skulle jag villja placera det speciellt i bank noll
> med början på adressen h'80', hur ska jag göra?

Notera att h'80' ligger utanför access bank, men det vet du säkert...

Det finns tre sätt :
1. Sätt adressen direkt på UDATA direktivet.
2. Du skapar en egen "data section" i LKR filen.
3. Kalla din UDATA section för "grp0" så hamnar den rätt automatiskt.
("grp0 UDATA")

Sen kan man naturligtsvis inte skapa "variabler" som
är större en tillgängliga data-sektioner, men det talar MPASM/MPLINK om.

opatagio, din kod är inte rellevant för PIC18, så ta de frågorna någon annastans,
det blir alldeles för rörigt annars. Men helt kort så är det *inte* rätt tänkt...

> gpr0 har 115 byte enl. lkr filen, att då reservera mer än detta går ju inte!

Och det talar ju även MPASM om... :-)

> suttit och bläddrat genom 2-3 olika microchip-datablad för att inse vad CODE direktivet gör...

Du ska kolla i *manualen* till MPASM/MPLINKl, inte i några datablad...

Postat: 15 juli 2007, 19:56:54
av Kaggen
Håller med föregående talare. gpr0 börjar ju på 0x80 och slutar på 0xF3 vilket ger 115 bytes. Frågan är varför dom klämt in en bank som heter bdbgspr i de sista 11 byten (0xF4 - 0xFF), det är det som hindrar dig från att reservera 125 bytes. Om banken inte används till något viktigt kan du ju ta bort den raden i LKR filen och ändra gpr0 banken så den spänner över 0x80 - 0xFF, då borde dina 125 bytes få plats.

Sedan är det frågan om du menar PIC181230 eller 1320 eftersom du skriver PIC18F1320 i inlägget men i lkr-filen du klistrat in står det PIC18F1230, dock har båda 256 bytes RAM.

Postat: 15 juli 2007, 21:03:40
av sodjan
Om man inte tänker använda IDC2, så är det enklare att använda
18F1320.LKR istället för 18F1320I.LKR, än att börja ändra i LKR'en.

Det framgår inte om Johan.o medvetet har valt "i" filen p.g.a att han kör ICD2...

Eller, för att vara korrekt, "i" filen behövs bara om man faktiskt
tänker köra ICD2 som "debugger", så vitt jag förstår...

Postat: 15 juli 2007, 23:45:40
av sodjan
> Som sagt, en mer utförlig guide i ren klartext...

Klartext och klartext vet jag inte, men i alla fall ett försök :

http://www.jescab.se/Relocmode.html

Kommentera gärna ifall något blev otydligt (eller helt fel...) :-)

Postat: 16 juli 2007, 16:40:12
av Johan.o
Tack för alla svar!

Jag gjorde en liten tankemiss, trodde jag skulle få in 125 bytes på GPR i bank 0, med början på adress h'80' men ni har ju rätt, det går ju inte,
ändrade till ett lägre värde. Och då fungerade det såklart, trodde det var
något annat fel.
anledningen till att jag använder 18F1320I.LKR är för att jag kör med en ICD2
under utvecklingsarbetet, så det var ingen tankemiss.

Nu börjar jag förstå lite bättre hur lkr filen fungerar.

Kör med det såhär istället och det blir som tur precis som jag vill.
Tänker ändå bara till sörst del göra åtkomst via indirekt adressering, så det blir bra precis där. Medans direkt adressering sparar jag Access bank för.

Kod: Markera allt

	gpr0				udata 
	cylinder_memory		RES	d'100'	
Sodjan: Har haft stor nytta av dina exempel på din hemsida.
Tycker dom är bra, bara att ibland behöver man en knuff på vägen som i
detta fallet ändå.

edit: La till sista stycket.

Postat: 18 juli 2007, 17:08:46
av opatagio
Tackar Sodjan, guider är alltid användbara (inte minst i mitt fall!) och den du postade ovanför är riktigt bra. Nu har jag dock fortfarande inte fått igång reloc-mode. Assemblering och länking fungerar som det ska, utan problemet uppstår med "banksel MyVar". Det fungerar helt enkelt inte med banksel. Tar jag bort banksel fungerar det som det ska. 16F887 ifråga och testkoden nedan

Kod: Markera allt

	list        p=16f887

	#include <P16F887.INC>

	errorlevel -207, -302		; -207 = Label not in column
								; -302 = Ensure bank bits
		__CONFIG _CONFIG1, _XT_OSC & _PWRTE_ON & _WDT_OFF & _CPD_OFF & _LVP_ON ; Used for 8MHz Ext.XT

#define	ONELED		PORTD,2			; OUTPUT
#define	TWOLED		PORTD,3			; OUTPUT


VARS	UDATA_SHR
d1		RES	1
d2		RES	1
d3		RES	1

MYVARS	UDATA
Count	RES	1

STARTUP CODE			; Starts reading instructions from here.
	goto	INIT
	nop
	nop
	nop
	goto	INIT



INITIAL	CODE
INIT
		banksel	OSCCON
		movlw	b'01111000'        ; Setup clock with external xtal
		movwf	OSCCON             ; *** SETUP ONLY VALID WITH 8.MHz
		movlw	b'00001111'
		movwf	OSCTUNE				;     USING AN EXTERNAL CRYSTAL

	
	banksel	PORTD
	clrf	PORTE
	clrf	PORTD
	clrf	PORTC
	clrf	PORTB
	clrf	PORTA
	
	banksel	ANSEL
	clrf	ANSEL
	clrf	ANSELH
	banksel	TRISD
	clrf	TRISD
	movwf	TRISD

	bsf	ONELED
	bsf	TWOLED

	banksel	Count
	clrf	Count
	movlw	d'3'
	movwf	Count


main
		bcf		ONELED
		call	DELAY
		banksel	Count
		decfsz	Count,f
		goto	$+2
		goto	$+3
		bsf		ONELED
		call	DELAY
		goto	main

	
DELAY	
		clrf	d1	
		clrf	d2
		clrf	d3

	movlw	h'08'		
	movwf	d1
	movlw	h'2F'
	movwf	d2
	movlw	h'03'
	movwf	d3

Delay_0
	decfsz	d1,f
	goto	$+2
	decfsz	d2,f
	goto	$+2
	decfsz	d3,f
	goto	Delay_0
	goto	$+1
	nop
	return

	END

Edit: MyVar bytt till Count. Men det spelar ingen roll då ingen definierad variabel fungerar med banksel före som i exemplet ovan. MPLinker rapporterar inga fel, inte heller MPAsm vid assemblering.

Postat: 18 juli 2007, 17:32:18
av sodjan
Var har du "banksel MyVar" ??

Postat: 18 juli 2007, 18:06:44
av sodjan
Hela koden behövs...

Postat: 18 juli 2007, 22:04:20
av opatagio
Som jag förstått det så ska 'banksel count' fungera även om denna ligger i samma bank som jag är i sedan tidigare?