PIC 16F887 comf-Befehl sehr eigenartig

[Sven S. (stepp64)]

Hallo,

ich wollte gerade ausprobieren ob der COMF Befehl eines PIC 16F887 die 
Bits in einem Byte nur umdreht, oder ob er das Zweierkomplement bildet, 
also mit hinzuaddieren (oder Subtrahieren?) einer 1.

Folgender Code:

  movlw  b'01101001'
  movwf  tmp1
  comf  tmp1,w

ergibt in W: b'10010101' also Zweierkomplement.

dagegen ergibt der Code:

  movlw  b'01101001'
  movwf  tmp1
  comf  tmp1,f

in tmp1: b'10010110' also alle Bits vertauscht ohne eine 1 zu 
subtrahieren.

Kann mir einer sagen warum das so ist? Oder spinnt hier der Simulator? 
In der Doku steht nichts von dieser Eigenheit. Danach müsste bei beiden 
Bsp. das selbe herauskommen. Sehr eigenartig das ist...

Sven

[chris (Gast)]

comf ist nicht 2-er kompliment, sondern nur negieren.

[Sven S. (stepp64)]

Ja ok, aber warum dann das unterschiedliche Ergebnis, je nachdem ob man 
nach w oder nach f speichert? Das ist doch das Problem.

[chris (Gast)]

Im prozessor kommt bei beidem das identische heraus, es ist das
identische als der ~ operator in c, nur halt 8bit.

[Sven S. (stepp64)]

Anbei mal noch ein Bild woran der Fehler zu erkennen ist. Füge ich nach 
dem COMF noch ein NOP ein ist alles so, wie es sein sollte. Ohne dieses 
NOP landet aber in W ein falscher Wert, zumindest im Simulator. Wäre mal 
interessant warum das so ist. Da ich jetzt aber weiß, dass die Bits nur 
negiert werden, ist mein Problem erst mal gelöst. Obwohl... Würde mich 
schon interessieren warum er einen falschen Wert nach W schreibt ** 
grübel **.

Sven

[Master S. (snowman)]

ich assemblere leider nicht. aber vielleicht liegt's daran, dass er für 
w einen takt länger braucht als für f und so zwischenzeitlich ein 
falscher wert in w ist..?

[Sven S. (stepp64)]

So, ich habs gefunden. Manchmal ist man halt doch etwas voreilig....

Da ich nur zum Testen die 3 Befehle gleich ab Adresse 0 geschrieben habe 
belegen diese die Speicheradresse 0-2. Auf Adresse 3 steht im Quelltext 
nichts, aber im Speicher! Dort steht eine gelöschte Zelle 0x3FFF was 
einem ADDLW 0xFF entspricht. Der Assembler führt diesen Befehl aus auch 
wenn er nicht im Quelltext steht. Normalerweise hätte ja hier auch 
irgendein Sprungbefehl gestanden. Da es aber eine schneller Test sein 
sollte kam nun dieser "Fehler" zustande. Trotzdem danke für die Hilfe.

Gruß
Sven