Automatisk export av använda minnesceller till exel?

[nanopile]

Jag försöker läsa manualen men det verkar inte fungera riktigt.
Hittar ett exempel med "COUNT RES 1 ; in bank 1"

Hursomhelst, jag deklarerar såhär:
VariabelX RES 1
VariabelY RES 1
VariabelY RES 2
och när jag flyttar data till variablerna en efter en med
movff WREG, VariabelX
....osv så använder de samma cell allihop.
Har det betydelse att jag har sett cell="file register" som Microchip skriver överallt i dokument och MPLAB IDE?

Har jag fattat rätt att
VariabelX RES 5
Allokerar/definierar/reserverar 5 celler i rad varsomhelst i minnet?
Och i fallet PIC18F442 i det som är de 768 byte stora minnet.
Datablad: http://ww1.microchip.com/downloads/en/D ... 39564c.pdf
Produktlänk: http://www.microchip.com/wwwproducts/De ... e=en010289

[bearing]

sodjan har en sida som beskriver hur relocatable mode används
http://www.jescab.se/Relocmode.html

[sodjan]

Före RES måste du ha anget att det är ett data-segment med något av DATA direktiven
(d.v.s någon av de som är rellevanta för PIC18).

> movff WREG, VariabelX

MOVWF VariabelX, fungerar lika bra i just det där fallet. Och det blir väl både
kompaktare (1 word istället får 2) och lite snabbare, om jag inte har fel...

> Har det betydelse att jag har sett cell="file register"

sett eller satt ? Jag vet inte riktigt vad det där syftar på.

> VariabelX RES 5
> Allokerar/definierar/reserverar 5 celler i rad varsomhelst i minnet?

Inte riktigt var som helst, det styrs av vilket DATA direktiv du har för det aktuella data-segmentet.
Men som ett block "i rad" blir det i alla fall.

[AndersG]

Var en variabel hamnar är ju ointressant, däremot kan det vara intressant att veta när bank noll blir full...

[sodjan]

Och det märks väldigt tydligt, MPLINK hostar ur sig ett felmeddelande...

[nanopile]

Tackar hörni, detta med RES verkar väldigt lovande de gånger jag får det att fungera, sitter och experimenterar och får fram allsköns undeliga felmeddelanden men jag löser dem ett och ett
Har en fundering, går det att göra databuffers som sträcker sig över mer än 0xFF byte?
Verkar som om att reservera över de tre segmentsgränserna ger felmeddelande.
Har iofs bara en stor buffer och den är på exakt 256 byte men det vore kul att kunna göra större arrayer än så.

[AndersG]

Har iofs bara en stor buffer och den är på exakt 256 byte men det vore kul att kunna göra större arrayer än så.

Kan du koda så.. Du måste ta hänsyn till bankar bara..

[JockeE]

Det kan hända att man behöver ändra i linker-scriptet för att definera sammanhängande minnesbanker som är tillräckligt stora för att rymma exempelvis en buffer.

[sodjan]

> Har en fundering, går det att göra databuffers som sträcker sig över mer än 0xFF byte?

Per default är minnet i "linker script" uppdelat i banker eftersom det är så
som t.ex BANKSEL i alla fall måste hantera det. Se t.ex nedan för den processor
som du använder (om jag läste rätt). :

Kod: Markera allt

// File: 18f442.lkr
// Sample linker script for the PIC18F442 processor

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

LIBPATH .

CODEPAGE   NAME=page       START=0x0               END=0x3FFF
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=0xF000FF       PROTECTED

ACCESSBANK NAME=accessram  START=0x0            END=0x7F
DATABANK   NAME=gpr0       START=0x80           END=0xFF
DATABANK   NAME=gpr1       START=0x100          END=0x1FF
DATABANK   NAME=gpr2       START=0x200          END=0x2FF
ACCESSBANK NAME=accesssfr  START=0xF80          END=0xFFF          PROTECTED

Om man vet vad man gör kan man justera LKR filen så att man får ett tillräckligt område
för den buffert man vill hantera. Här är en justerad variant, notera att gpr1 har halverats
och övre halvan har slagits ihop med grp2:

Kod: Markera allt

// File: 18f442.lkr
// Sample linker script for the PIC18F442 processor

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

LIBPATH .

CODEPAGE   NAME=page       START=0x0               END=0x3FFF
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=0xF000FF       PROTECTED

ACCESSBANK NAME=accessram  START=0x0            END=0x7F
DATABANK   NAME=gpr0       START=0x80           END=0xFF
DATABANK   NAME=gpr1       START=0x100          END=0x17F  <<<=== !!!
DATABANK   NAME=gpr2       START=0x180          END=0x2FF  <<<=== !!!
ACCESSBANK NAME=accesssfr  START=0xF80          END=0xFFF          PROTECTED

Här är ett väldigt enkelt kod exempel som allokerar en buffert på h'180' bytes (alltså 256+128 bytes):

Kod: Markera allt

	list      p=18f442
	#include <p18f442.inc>

RESET_VECTOR	CODE	0x0000

		 goto	main

mybuff   UDATA       ; allokera buffert
buffer   RES h'180'  ; 256+128 bytes decimalt

myvars1  UDATA       ; allokera övr variabler
var1a    RES 1
var1b    RES 1
array1a  RES 8
array1b  RES 8

myvars2  UDATA_ACS   ; Allokera några variabler i "access bank".
var2a    RES 1
var2b    RES 1

MAIN	 CODE

main     goto    main
         end

Detta get en MAP fil som ser ut så här (delar av filen) :

Kod: Markera allt

MPLINK 4.20, Linker
Linker Map File - Created Fri Jan 16 00:04:44 2009

                                 Section Info
                  Section       Type    Address   Location Size(Bytes)
                ---------  ---------  ---------  ---------  ---------
             RESET_VECTOR       code   0x000000    program   0x000004
                   .cinit    romdata   0x000004    program   0x000002
                     MAIN       code   0x000006    program   0x000004
                  MYVARS2      udata   0x000000       data   0x000002
                  MYVARS1      udata   0x000080       data   0x000012
                   MYBUFF      udata   0x000180       data   0x000180

                              Symbols - Sorted by Address
                     Name    Address   Location    Storage File                     
                ---------  ---------  ---------  --------- ---------                
                     MAIN   0x000006    program     static C:\DATA\proj...
                    VAR2A   0x000000       data     static C:\DATA\proj...
                    VAR2B   0x000001       data     static C:\DATA\proj...
                    VAR1A   0x000080       data     static C:\DATA\proj...
                    VAR1B   0x000081       data     static C:\DATA\proj...
                  ARRAY1A   0x000082       data     static C:\DATA\proj...
                  ARRAY1B   0x00008a       data     static C:\DATA\proj...
                   BUFFER   0x000180       data     static C:\DATA\proj...

Notera hur de olika RES direktiven allokerar ur olika delar av minnet.
Dels beroende på storleken på "buffer", dels beroende på om UDATA eller UDATA_ACS används.
"Buffer" kommer med stor sannolikhet att hanteras via indexregistren och de har ju alla adressbitar
och störs inte av att "buffer" ligger över två banker.

[nanopile]

Lärt mig en hel del genom att experimentera idag och insett att jag kommer att spara mycket tid i framtiden jämfört med hur jag gjort tidigare tack vare god hjälp
All bufferhantering körs med hjälp av INDF, PREINC mfl registren.

Har hittils inte sett någon anledning att dela upp första banken i två bitar.
Någon som vet orsaken att udata_acs sträcker sig från 0x00 till 0x80 och inte 0xFF?
Efter att ha mixtrat med linker scriptet så noterade jag att det går fint att flytta start och slut på bankerna och hur det påverkar placeringen av variablerna.
Därför undrar jag om man inte kunde slå ihop allt utom första banken till en minnesarea i linker scriptet om man inte använder bsr i programmet?.

[persika]

Att på något vis hålla reda på vilka "minnesceller" som är använda är ju bra.
Själv håller jag dessutom reda på om minneceller som är upptagna i en subrutin är lediga att använda i en annan rutin, om dom inte används samtidigt.
På det viset kan man spara minnesutrymme.

[JockeE]

Någon som vet orsaken att udata_acs sträcker sig från 0x00 till 0x80 och inte 0xFF?

Access-banken är ju inte större än så. 0x00 till 0x7F pekar på första delen av RAM bank 0 och 0x80 till 0xFF används för åtkomst till alla SFR.

[sodjan]

> Därför undrar jag om man inte kunde slå ihop allt utom första banken till en minnesarea i linker
> scriptet om man inte använder bsr i programmet?.

Sannolikt ja. Om du inte tänker accessa den arean med MOVF, MOVWF eller liknande.

> Någon som vet orsaken att udata_acs sträcker sig från 0x00 till 0x80...

Därför att det är just så stor som "access bank" är på just den modellen !
Andra PIC18 har andra gränser (oftast lägre på de med väldigt många SFR's...)

> Att på något vis hålla reda på vilka "minnesceller" som är använda är ju bra.

Nej, det behövs väldigt sällan.

> Själv håller jag dessutom reda på om minneceller som är upptagna i en subrutin är lediga
> att använda i en annan rutin, om dom inte används samtidigt.

Läs på lite om UDATA_OVR !

[Icecap]

persika: men ... det gör man ju redan! Om man har "slaskvariabler" som bara används för olika uträkningar i olika rutiner i t.ex. mainloopen har man ju namngett dom till t.ex. Work1, Work2 osv.

När jag programmerar ger jag bara unika namn till de variabler som inte får användas av andra rutiner för att värdet ska "återanvändas" senare, på det vis är det enkelt att spara minne.

[AndersG]

När jag programmerar ger jag bara unika namn till de variabler som inte får användas av andra rutiner för att värdet ska "återanvändas" senare, på det vis är det enkelt att spara minne.

Samma här.