MPLAB foutmelding bij tabelwaarden in HEX

hoi,

ik ken geen PIC ASM, maar probeer eens 0x voor alle waarden te zetten?

Ja dat werkt wel, maar ik wil weten waar deze fout vandaan komt.

De compiler probeert de waarden in jouw tabel te als getal te interpreteren, 0F, 4D enz. is geen (decimaal)getal voor de compiler. De compiler probeert het dan als een label/variabele te interpreteren, maar dat bestaat niet (niet gedefinieerd).

0x0F daarentegen wordt correct geïnterpreteerd als 0F hex. (0x is de aanduiding: Nu volgt een Hex. waarde.)

Zelfs al zet je de radix op HEX, dan nog kan de assembler de hexwaarden niet interpreteren. Je moet nog altijd 0x voor het getal zetten of het in de vorm H'04ff' neerzetten.

De assembler kan hier niets mee beginnen, omdat 'ie niet weet wat bijvoorbeeld 'F6' is. Het kan een hex getal zijn, maar net zo goed een label uit een EQU of SET directive... (F6 EQU 123)
Daarvoor is 0x... nodig ter onderscheiding.

Ok.
Ik had dit in m'n achterhoofd zitten: (uit http://ww1.microchip.com/downloads/en/devicedoc/33014j.pdf )

radix hex ;Now default radix is in hex.
movlw .50 ;50 is declared in decimal.
movlw 50O ;50 is declared in octal
movlw 50 ;50 is not declared as hex or
        ;octal or decimal. So by default
       ;it is in hex as default radix
      ;is declared as hex.

Dat geldt dus voor constanten, maar niet als ze in een tabel staan
Jammer dat ik nu hele tabellen met de hand moet aanpassen.

Het wordt hoog tijd dat ik overstap naar Atmel

Op 19 september 2011 09:06:27 schreef Zonnepaneeltje:
Jammer dat ik nu hele tabellen met de hand moet aanpassen.

Kan je niet zoeken en vervangen en dan , vervangen door ,0x ?

Zp, ik ben het met je eens dat als er een "radix" commando is, dat "f6" dan als getal moet worden ge-interpreteerd. Ik begrijp dat het onderscheid op karakter-niveau dan lastig is, maar als je het radix commando introduceert moet je daar een oplossing voor bedenken.

Dit is het document van Microchip De relevante spullen staan op blz. 115. (zp had een typefout in de link)

Hmmm, dat hele radix directive blijkt niet te werken.

Bij wijze van proef heb ik het volgende ergens midden in het progje geplaatst;

  radix hex
   movlw E5

Geeft dezelfde foutmelding....pfffff

Op 19 september 2011 09:06:27 schreef Zonnepaneeltje:
Jammer dat ik nu hele tabellen met de hand moet aanpassen.

Het wordt hoog tijd dat ik overstap naar Atmel

Tsja, even werken, maar met copy/paste kan dat niet veel werk zijn...
En om nu om die reden over te stappen op Atmel...wat heeft de, door jou ervaren, beperking van de assembler in vredesnaam te maken met het kiezen van een andere architectuur.
Klinkt mij in de oren als 'omdat de rekenmachine van Windows mij niet bevalt stap ik over op een Apple'.

Maar om even dieper in te gaan op de onderliggende problematiek het volgende:

F3 EQU .21
...
movlw F3

of

    cblock
w_temp
F3
iTel
    endc

clrf F3

In het eerste geval zal de constante F3 bevat de decimale waarde 21, dus na de movlw zal W ook 21 bevatten.
In het tweede geval heeft de variabele F3 de waarde 0.
Dit zijn geldige instructies.
Hoe moet de assembler weten wat 'F3' betekent?
In beide gevallen zijn het geldige identifiers, maar volgens jou zou dit een foutmelding moeten opleveren omdat, wederom volgens jou, F3 een hexadecimale waarde is.
Ik ben blij dat MPAsm het zo doet, het zou alleen maar tot ongelooflijke misverstanden leiden.

[Bericht gewijzigd door hadv op maandag 19 september 2011 14:56:18 (38%)]

Labels en variabelen mogen niet met een digit beginnen.
De compiler gebruikt daarom het eerste karakter van een argument als leidraad.
Is het een numeriek digit, dat is het een directe waarde, anders is het een label.
Dus 0xE5 of 0E5 mag, E5 mag niet. Als dit bij een Atmel compiler anders is, is dat raar (en ongewenst)