Assembler, PIC16F88

Die erste Zeile ist so wies aussieht ein Makro. Poste mal dessen 
Programmcode.

Der Rest des Programmauschnitts schreibt 0x01 in WDTCON und geht in eine 
Endlosschleife, bis der Watchdog-Reset eintritt.

Könnte sein dass der Assembler mit den beiden TaskError durcheinander 
kommt, da es einmal als Label und einmal als Variable vorkommt.

0x01 in WDTCON bewirkt, dass der WDT einen Vorteiler von 1:32 hat und 
der WDT eingeschaltet ist (sofern der WDT per Software einschaltbar ist; 
das steht dann im Bit WDTEN im CONFIG1 Word, dort kann man einstellen, 
ob der WDT immer aus ist oder ob er per WDTCON einschaltbar ist).

Der Fill-Befehl füllt hier ab der aktuellen Stelle bis zum Flag 
Taskerror (0x0F9) den Speicher mit NOPs

Sascha schrieb:
> Könnte sein dass der Assembler mit den beiden TaskError durcheinander
> kommt, da es einmal als Label und einmal als Variable vorkommt.

Definitiv nicht, der Ausdruck TaskError-$ aus der ersten Zeile bedeutet 
nichts anderes als die Subtraktion des ProgramCounter-Wertes von der 
Adresse des Labels TaskError. Resultat ist eine Konstante, keine 
Variable.

M. B. schrieb:
> 333 : Operand contains unresolvable labels or is too complex

Welches ist denn die Zeile 333, aus deinem Posting geht das nicht 
hervor?

Gruß,
Edson

M. B. schrieb:
> Zeile 333:
>
>     fill  (nop),TaskError-$

So, und jetzt fehlt nur noch die Auflösung des Makros fill...

Falls das Makro in deinem Projekt gar nicht vorhanden ist, haben wir die 
Ursache der Fehlermeldung. "fill" wird dann als Label interpretiert und 
MPASM ärgert sich über das Komma nach dem (nop), da nach einem Befehl 
ein Operand erwartet wird.

Gruß,
Edson

Der Fehler hier ist, daß er die Adresse vom Label TaskError
nicht kennt. Ich würde tippen, du versucht das Programm mittels Linker
zu assemblieren und der Code braucht aber eine absoluten Assembler code.
Aber, lass einfach die betreffende Zeile weg, denn dann wird der Code 
mit
"addwf 0xff" gefüllt, in deinem Source ist es dasselbe, da danach eine
Endlosschleife kommt (goto $) und das W-Register sowie die Statusbits 
(Carry/Zero)egal sind.

Bei gelinktem Code trifft man die Codewörter "code" sowie "cblock" im
Sourcefile

fill ist eine Assemblerdirektive.
fill exp,count

Fill füllt den Bereich mit exp und zwar count mal.
und label-$ bedeutet, von hier bis zum Label.

Nein, fill füllt den Bereich. Es ist eine Assembler Direktive und kein 
Macro.
Anstelle des Labels könntest du auch folgendes schreiben:

  fill 0,0x0f9-$ ; nop=0, ev könnte auch das das problem sein

Trotzdem, ob ein NOP = 0 oder ein ADDLW 0xFF = 3FFF verwendet wird, ist
in diesem Code egal, einfach die Zeile fill weglöschen.
Der einzige Unterschied ist, daß man bei 3FFF nachträglich noch code
reinpatchen kann, aber wenn du die codeprotection verwendest, ist das 
auch
nicht mehr möglich.

Wenn du nichts schreibst, und einfach die org verwendest, dann wird 
steht da halt 3FFF drin was der Opcode für "addlw 0xff" also "addlw -1" 
ist.

Chris schrieb:
> Nein, fill füllt den Bereich. Es ist eine Assembler Direktive und kein
> Macro.

Oh, sorry für meine Fehlinterpretation. Ich arbeite seit geraumer Zeit 
nicht mit MPASM.

Gruß,
Edson

Hallo, pass auf, wenn du im EEprom Fill verwendest, dann ist das was
anderes als auf der von dir beschriebenen Codestelle.
Adressen ab 0x2100 sind EEprom. Ansonsten steht da FF drin und du 
erwartest
warscheinlich ein 0. Ob da ein "dt" = retlw zulässig ist, weiß ich auch
nicht recht, bzw was da dann effektiv in das EEprom landet.

ganz einfach, der Label kann nicht aufgelöst werden, warscheinlich da 
ein object File erstellt wird, welcher dann erst gelinkt wird, und 
deshalb
steht die Adresse für die Berechnung nicht fest, welche aber für die
Assemblerdirektive gebraucht wird. Der Label wird die Adresse 0x0f9 
haben.
Wenn du aber "fill 0,0x0f9-$" schreiben würdest, dann dürfte der 
Assembler kein problem damit haben.

fill  (nop),TaskError-$
    org    0x0F9
TaskError