Svenska ElektronikForumet

0024   1683           00034         BANKSEL IOC
0025   3008           00035         MOVLW   08      ; 0 0 0 0  1 0 0 0
0026   0096           00036         MOVWF   IOC     ; IOC @ 3
                      00037 ; / - - - - - - - - - /
0027   1283           00038         BANKSEL CCP1CON
0028   303C           00039         MOVLW   3C      ; 0 0 11  1100
0029   0095           00040         MOVWF   CCP1CON ; LSB 0X3 PWM act high
                      00041 ; / - - - - - - - - - /
002A   1683           00042         BANKSEL PR2
[b]Error[113]  : Symbol not previously defined (ff)[/b]
002B   3000           00043         MOVLW   ff
002C   0092           00044         MOVWF   PR2

Först fick jag detta med FF, sedan även med ff.
Som synes klaras andra HEX-tal, men inte just 15255d.

Det handlar iofs om bokstav som siffervärde, där F var först noterat.

Processor?
Fungerar MOVLW h'ff' ?
Vad är "15d"?

15 decimalt, d.v.s. 0xFF.

Nu har jag ingen koll alls på den aktuella assemblern, men min spontana tanke är ju att MOVLW inte är till för att användas med explicita adresser (d.v.s. assemblern förväntar sig inte ett tal där).

15 decimalt är 0f hex, 0FF hex är 255 decimalt

> men min spontana tanke är ju att MOVLW inte är till för att användas med explicita
> adresser (d.v.s. assemblern förväntar sig inte ett tal där).

MOVLW, "Move Literal to W". Parametern ska vara ett 8 bitars värde mellan h'00 och h'FF'.

Jag fattar inte ett smack av vad du skriver. Vad är en "explicit adress"?

> 15 decimalt,

Nej, det är d'15', inte 15d.

Som jag skrev, jag kan inget om den aktuella assemblern. Jag visste inte att instruktionen handlade om att flytta en literal. Och jag visste inte hur syntaxen i den aktuella assemblern är för att indikera att det är hexadecimala tal eller decimala tal.

Min tanke var att det kanske var en instruktion som var avsedd att läsa från en adress i minnet, men att assemblern då inte vill att man anger en adress i siffror utan anger en symbol.

När man höll på med Z80 för 100 år sen så fanns det ju en massa olika adresseringstyper, och alla instruktioner kunde inte använda alla adresstyper. Det fanns väl direct, indirect, immediate, relative, indexed och säkerligen ett par andra.

Men nu verkar det ju bara vara så enkelt som att TS missat att hexadecimala tal behöver prefixas? Fast å andra sidan verkade ju inte 3C behöva prefixas? Så varför funkar det med 3C men inte med FF?

Man kan sätta det "radix" som ska vara default om man inte prefixar.
Om man inte sätter radix så är default decimalt. Därför är det även
väldigt förvirrande med värden som "08" utan prefix (som ju kan vara
både decimalt och hex) och där det inte framgår att man har ändrat radix.

Generellt är det mycket bättre att använda de standardprefix som gäller:

Dec: d'100' (.'100' fungerar också)
Hex: h'D5' (0xD5 fungerar också)
Oct: o'73'
Bin: b'01101100'
ASCII: a'B' (enbart 'B' fungerar också)

> Så varför funkar det med 3C men inte med FF?

Ja, det är underligt...

> då inte vill att man anger en adress i siffror utan anger en symbol.

Generellt har det aldrig någon betydelse. Assemblern ser aldrig någon skillnad.

Nerre skrev:Fast å andra sidan verkade ju inte 3C behöva prefixas? Så varför funkar det med 3C men inte med FF?

För att 3C börjar på siffra och kan inte vara annat än ett tal (decimalt eller hex) men FF börjar bokstav och är därför en identifierare.

Ja, det låter ju väldigt rimligt. Jag har själv aldrig använt
värden utan korrekt prefix, men det är inte orimligt. Det
är ju dessutom exakt det som felmeddelandet säger...

0FF eller 0ff borde fundera. ( Alltså noll och inte 'o' )

XC8 använd.

Om radix används torde "korrekt prefix" vara att inte använda prefix.
Så om radix är HEX så borde varken h'nn' eller 0xnn behöva användas, utan endast nn.

Vilket är så, så länge första siffra är just en [tiobas] siffra.
Svårt avgöra vad som händer vid två "siffror" tillsammans.

Så summarum är det alltså meningslöst sätta radix. Trevligt.

Trist att binärt inte finns som alternativ för radix.

Ah, det borde fungera Jan!
Märkligt om så är fallet.

Det kan finnas fall då man t.ex. inkluderar maskingenererad kodbitar
som saknar radix prefix och då kan det vara praktiskt att sätta om default.

Man som sagt, det finns generellt ingen anledning att utesluta prefix
och med prefix så fungerar det ju alltid.

> Om radix används torde "korrekt prefix" vara att inte använda prefix.

Du menar om man har satt om det som är default med radix kommandot?
Man måste ju i alla fall använda prefix om man har värden med annat
radix än det som är default. Och HEX värden är ju lite struliga eftersom
de kan börja med en bokstav.

> Ah, det borde fungera Jan!
> Märkligt om så är fallet.

Det beror nog i så fall på att symboler inte får börja numeriskt...

Man som sagt, det finns generellt ingen anledning att utesluta prefix
och med prefix så fungerar det ju alltid.

Man måste ju i alla fall använda prefix om man har värden med annat
radix än det som är default.

Intressanta resonemang.

Det normala är ju att man använder fler olika radix beroende på vad det
handlar om. I just dina exempel skulle jag kanske inte använda hex alls.

Kod: Markera allt

  BANKSEL IOC
  MOVLW   b'00001000'        ; Ingen kommentar med binära värdet behövs...
  MOVWF   IOC
; / - - - - - - - - - /
  BANKSEL CCP1CON
  MOVLW   b'00111100'        ; LSB 0X3 PWM act high, lättare att matcha mot databladet.
  MOVWF   CCP1CON
; / - - - - - - - - - /
  BANKSEL PR2
  MOVLW   d'255'             ; Lättare att huvudräkna decimalt
  MOVWF   PR2

Erik M skrev: Intressanta resonemang.

Knappast, normalt att man gör så, kanske inte för dig, då du verkar göra allt tvärtom, och behöver ställa en massa onödiga frågor när det blir fel.

Sensmoralen är, gör rätt så blir det rätt.

Svenska ElektronikForumet

På tal om LST...

På tal om LST...

Re: På tal om LST...

Re: På tal om LST...

Re: På tal om LST...

Re: På tal om LST...

Re: På tal om LST...

Re: På tal om LST...

Re: På tal om LST...

Re: På tal om LST...

Re: På tal om LST...

Re: På tal om LST...

Re: På tal om LST...

Re: På tal om LST...

Re: På tal om LST...

Re: På tal om LST...