Jag står inför ett teknikskifte...

[Odur]

Du kan ju kolla med Microchip själva också. De är rätt aktiva i deras forumdel för MPLAB X: http://www.microchip.com/forums/f238.aspx

[BJ]

Okej. Tack för länken.

[sodjan]

Det är ju en "beta", det finns inga garantier att någonting alls
fungerar, igentligen...

[BJ]

Visst är det så.

[Batman]

Jag får felmeddelandet
Error[151]: Operand contains unresolvable labels or is too complex
för raden med IF ...

Jag provade med Mplab 8,63 i Windows, och den klarade det.

Kanske vi borde ha en egen tråd för Mplab x?

Felet har med hur man kör assemblern. MPLAB X kör nog med MPASM + MPLINK när den bygger. Då gäller detta för MPASM:
"When generating an object file, operands must be of the form [high|low]([relocatable address label]+[offset])."

Kör man bara MPASM och låter den generera hex direkt så klarar den av dina beräkningar.

[sodjan]

Ja, eller uttryckt på ett annat sätt...

Dina "IF" och "ENDIF" är ju kommandon/direktiv som är tänkta att
utföras av MPASM självt, lite som pre-compilern om man kör C, ungefär.

D.v.s att det som du testar på i IF satsen måste vara känt för MPASM.
Eftersom man i dag i princip alltid kör relokerbart så fungerar inte det du
gör varken i vanliga MPLAB eller i MPLAB X. *Om* man inte kör i "absolute
mode", men det vore lite dumt att tvingas kvar i absolute mode enbart p.g.a
av det !

Så poängen är att detta igentligen inte har något med MPLAB X att göra...

Två lösningar:

1. Skriv koden så att den blir oberoende av page-gränser (d.v.s hantera PCLATH)
2. Se till att allokera tabellen så att den inte går "över gränsen".

[BJ]

Tack för tipsen.
Jag fick faktiskt en fråga av programmet om mitt projekt skulle vara
absolut eller relokerbart. Jag tror att det var när jag skapade
projektet i Mplab x. Jag valde absolut. Men det gick inte ändå.

Precis som du skriver, sodjan, så använder jag absolut programmering.
Det blir en del jobb, men det har fungerat.
Jag brukar ställa in PCLATH före hopp till tabellerna,
men just i det här projektet hade jag inte med det.
Det är praktiskt att ha med den där kontrollen, för då
kan man fylla på sin tabell med olika textsträngar,
och så sköter assemblatorn kontrollen av om det blir fullt.

Men visst. Jag är inte tvungen att hålla mig fast vid det.
Det kanske är dags att läsa på lite om relokerbar programmering.
Det finns ju en del sidor att titta på. Du har ju också en, har jag sett.

[sodjan]

> Du har ju också en, har jag sett.

Två, faktiskt.
http://www.jescab.se/Relocmode.html
http://www.jescab.se/abs_reloc.html

Jag vill även bara göra en notering om att dagens modeller
av PIC's har snyggare metoder för att direkt läsa tabeller i
Flash utan CALL/RETLW metoden. Mer som att läsa EEPROM
ungefär.

[BJ]

Ja, det var det.

Jag har faktiskt läst om att man kan läsa från flashminnet
på dom nya processorerna, men jag tänkte inte på att man
kan använda det till tabeller.

Det jag hade tittat på var det här,
från databladet till 16F877A, sidan 36:

Kod: Markera allt

EXAMPLE 3-3: FLASH PROGRAM READ

BSF STATUS, RP1        ;
BCF STATUS, RP0        ; Bank 2
MOVLW MS_PROG_EE_ADDR  ;
MOVWF EEADRH           ; MS Byte of Program Address to read
MOVLW LS_PROG_EE_ADDR  ;
MOVWF EEADR            ; LS Byte of Program Address to read
BSF STATUS, RP0        ; Bank 3
BSF EECON1, EEPGD      ; Point to PROGRAM memory
BSF EECON1, RD         ; EE Read
                       ;
NOP
NOP                    ; Any instructions here are ignored as program
                       ; memory is read in second cycle after BSF EECON1,RD
                       ;
BCF STATUS, RP0        ; Bank 2
MOVF EEDATA, W         ; W = LS Byte of Program EEDATA
MOVWF DATAL            ;
MOVF EEDATH, W         ; W = MS Byte of Program EEDATA
MOVWF DATAH            ;

Nu såg jag att Pic 18 t.ex., har ett annat sätt att läsa.
Pic 18Fxx8, sidan 69:

Kod: Markera allt

EXAMPLE 6-1: READING A FLASH PROGRAM MEMORY WORD

MOVLW CODE_ADDR_UPPER  ; Load TBLPTR with the base
MOVWF TBLPTRU          ; address of the word
MOVLW CODE_ADDR_HIGH
MOVWF TBLPTRH
MOVLW CODE_ADDR_LOW
MOVWF TBLPTRL
READ_WORD
TBLRD*+                ; read into TABLAT and increment
MOVF TABLAT, W         ; get data
MOVWF WORD_LSB
TBLRD*+                ; read into TABLAT and increment
MOVF TABLAT, W         ; get data
MOVWF WORD_MSB

Där används tydligen 22-bitars adress, så då skulle man kunna
läsa 4k (eller 2k ord).

Tjänar man nånting på att använda dom sätten i stället för retlw?
Mer än att man kan läsa ett större område.
Är det nån som har tittat på vilket som är snabbast, och vilket som
drar minst minne?
Eller det kanske man får prova själv.
(Jag har inte grejer nu så att jag kan göra det.)

[sodjan]

På PIC18 (som ju har ett 16-bitars program-ord) så kan man lagra
två bytes i varje programadress. På en PIC16 så blir det alltid 1 byte
per adress (eftersom 14-bitar inte räcker till 2 bytes). En RETLW
tabell har alltid en byte per adress på både PIC16 och PIC18.

[BJ]

Ok. Då skulle tabellerna ta hälften av minnet om man använder
18-serien. Dags att titta på det då.

[BJ]

Hur är rätt sätt att skriva om man vill lägga variabler
i en viss bank? Om jag skriver

Kod: Markera allt

; Bank 0.

section
gpr0           udata

LCD_data       res 1

så får jag
Error[150] : Labels must be defined in a code or data section
when making an object file

för section-raden.
Det är alltså fel. Nån som vet hur man gör?
Om den vill ha en etikett på mina variabler så kan jag kalla den
för variabler_i_bank_0. Var ska det stå?

[sodjan]

Om jag inte har helt fel (och svaret finns så klart i MPASM/MPLINK manualen !)
så måste du definiera en SECTION som du sedan använder i UDATA direktivet.

T.ex SECTION NAME=myvar_1 RAM=gpr2 och sedan använder du
myvar_1 udata i koden. Ungefär. Bara att experimentera lite.

"labeln" i UDATA direktivet måste alltså peka på en SECTION i LKR filen.

Du kan alltså flytta runt variablerna mellan bankerna genom att enbart
ändra LKR filen. Det blir även enklare att skriva portabel kod eftersom
kopplingen till bankerna sker i LKR filen.

[BJ]

Jaha, det var i lkr-filen det skulle in.
Har man sett... Det fungerade.
(Jag kör med vanliga Mplab just nu.)

Variablerna hamnade där dom skulle.
Kan man lita på att dom alltid kommer i den ordningen
som man skriver dom med res?
T.ex. om jag börjar bank 1 med en buffert, kommer den
alltid att hamna i början på bank 1 då?
Så inte programmet får för sig att stoppa in några variabler
i början där.

[sodjan]

Det spelar ingen som helst roll, och det är inget du behöver veta...
Huvudsaken är att det hamnar i den bank du vill (vilket igentligen inte
heller spelar så stor roll, varför vill du speca bank ?).