PIC24H Repeat Problem bei post increment

Ich habe meiner Meinung nach einen Chip Fehler im PIC24HJ256GP610
gefunden, den mir die Firma Microchip anscheinend nicht bestätigen will
oder kann, oder mein Problem nicht verstanden hat.

PROBLEM :
mov #0x1000,W0 ; W0 zeigt nun auf 0x1000
repeat #10 ; durchlauf die nächste Zeile 10+1 mal
com.w [W0],[W0++]
nop

dazu eine kurze Beschreibung was der code überhaupt soll:
complementiere die Speicherstelle (16 Bit) auf die das Register W0 zeigt.
schreibe das Ergebnis (16 Bit) an selbige Speicherstelle worauf W0 zeigt, dann erhöhe das W0 register um 1 Word, also um 2 Bytes.

wenn der Prozessor den "nop" Befehl erreicht, dann muss das "W0"
register 11 WORDS weiter gezählt haben (10+1), sollte also folglich wegen
dem Word Mode auf 0x1016 stehen. Dies funktioniert in der MPLAB IDE auch korrekt, jedoch im Prozessor selbst nicht. Das "RCOUNT" register steht dann zwar korrekterweise auf 0, das W0 register steht aber falsch. Das post increment scheint hier nicht richtig zu funktionieren, hier
gehen counts verloren.
Dazu tätigte ich einige Versuche mit verschiedenen Repeat Counts:
Repeat Count:
0 OK
1 OK
2 OK
3 hier fehlt 1 Word increment vom register W0
4 hier fehlt 1 Word increment vom register W0
5 hier fehlen 2 Word increments vom register W0
6 hier fehlen 2 Word increments vom register W0
7 hier fehlen 3 Word increments vom register W0
8 hier fehlen 3 Word increments vom register W0
9 hier fehlen 4 Word increments vom register W0
100 hier fehlen 49 Word increments vom register W0
1000 hier fehlen 499 Word increments vom register W0

dann testete ich selbigen Code mit dem W1 register
com.w [W1],[W1++]
ebenfalls falsche Ergebnisse im W1 register

dann testete ich selbigen code im Byte Mode
com.B [W1],[W1++]
ebenfalls falsche Ergebnisse im W1 register

dann ersetzte ich den "com" durch "neg"
NEG.w [W1],[W1++]
ebenfalls falsche Ergebnisse im W1 register

Nun testete ich anstelle des post increments das pre increment
com.w [W1++],[W1]
und zum Erstaunen, hier funktioniert alles richtig.

Kann eventuell jemand dieses Fehlerverhalten überprüfen bzw. bestätigen ?

Nun kann ich mir tatsächlich selbst antworten, mal was ganz neues.
Microchip hat meinen gefundenen Hardware Fehler im Chip
offizell bestätigt im Errata Sheet
vom 06.11.2007 PIC24HJXXXGPX06/X08/X10 Rev. A2 Silicon Errate
Fehler Nummer 43
Glauben wollte mir aber erstmal keiner.

Wie sind denn sonst deine Erfahrungen mit den 24xx Teilen?
Bisher habe ich nur die kleineren bis 18Fxx benutzt. Das ging ganz gut.
Aber ich hab mir mal den von dir erwähnten Errata Sheet angeschaut; das klingt ja grausig. Haarsträubende Fehler.
Was denkst du, trotzdem empfehlenswert, wenn man C machen möchte und Rechenpower braucht?

Habe selbst schon fast die ganze Familie von Microchip programmiert.
Vom 12F,16F, extrem viel mit 18F und neuerdings erst mit den 24er.
Es gibt eigentlich keinen PIC der nicht einen zugehörigen Errata Sheet
besitzt. Trotzdem bin ich eigentlich sehr zufrieden mit den Controllern.
Eingesetzt werden sie von mir für medizintechnische Anwendungen
und privat für diverse Kleinigkeiten unter anderem für Fernsteuerungen
für Mini Autos, Drehzahlregler, Servosteuerunge usw.
Der 24er ist für mich auch noch recht neu, man sollte sich jedoch nicht abschrecken lassen von den Errata Sheets, klingt viel " grausamer"
als es ist. Der Fehler z.B, den ich hier im Forum beschrieben habe,
wird mit einem C-Compiler wahrscheinlich niemals auftauchen.
Ich programmiere aber seit jeher alle PICs in Assembler und bin immer
wieder dabei durch gezielte Programmierung hier und da einen
Ausführungszyklus einzusparen. Gibt zwar meist nicht den wirklichen
Sinn, aber so bin ich nunmal. Wenn es um mathematische Funktionen
geht, ist die 24er Serie den 18F Typen weit überlegen. Weit muss hier aber
extra betont werden, denn ich habe Wochen verbracht um dem 18er
das Rechnen beizubringen. Alleine die Vorzeichen gerechte Abfrage von
kleiner, größer, gleich im 16 oder 24 Bit Format hat einiges an Nerven
gekostet, das hat der 24er alles schon von Hause aus.
Vorzeichen gerechtes Multiplizieren Dividieren, Vergleichen mit dem 24er in Assembler absolut kein Problem mehr. Der gesamte Code generell wird sehr kompakt. Wenn man also etwas mehr an Permomance braucht, kann
ich Dir dir 24er oder dsPICs wirklich empfehlen.
Sieht man sich im Errata Sheet z.B. die Fehler des UARTs an, sollte man
denken, der kann wohl niemals richtig funktionieren. Aber ich habe ohne
Umwege die RS232 programmiert und diese läuft absolut einwandfrei.
Mit einem C-Compiler habe ich noch nie gearbeitet, liegt wohl am Preis
aber evtl. kannst Du mir ja deine Erfahrung damit mal kurz erläutern.
Ich scheue mich davor, da ich der Meinung bin, ich kann dann den Code nicht mehr 100 Prozentig nachvollziehen. Ich möchte möglichst immer genau aufs Bit wissen was der Prozessor macht. Wie sieht es eigentlich mit
Bibliotheken aus, bekommt man da auch die Quellcodes ?

mit freundlichen Bits
Bernd Sirozynski

Zitat:

---

Mit einem C-Compiler habe ich noch nie gearbeitet, liegt wohl am Preis
aber evtl. kannst Du mir ja deine Erfahrung damit mal kurz erläutern.

---

Erfahrungen: keine!
Ich mache auf den PICs auch nur Assembler. (Auf dem Desktop sonst sehr gerne C), aus den gleichen Gründen wie bei dir. Jeder Takt zählt!

Zitat:

---

Sieht man sich im Errata Sheet z.B. die Fehler des UARTs an, sollte man denken, der kann wohl niemals richtig funktionieren.

---

Ja, genau das war der Eindruck. Ich kenne auch die Errata Sheets der kleineren PICs und da betrafen die Fehler oft nur einzelne, sehr spezielle Befehle. Konnte man mit entsprechenden Workarounds ganz gut mit leben.

Ich war bis jetzt immer sehr zufrieden mit den PICs (habe mit 16Cxx angefangen, bis hin zu 18Fxx), aber in letzter Zeit bemerke ich einen Trend bei den neueren Produkten, der mir nicht so gefällt:

Sicherheit wird zugunsten von Flexibilität aufgegeben. Viele Beschränkungen bei den alten PICs, (die ich übrigens erst sehr unsinnig fand), dienten dazu, dass das Device softwaremäßig schwer "abzuschießen" war. Z.B. Watchdog nicht per Software abschaltbar, strikte Trennung von Code und Daten, Hardware-Stack usw. Wenn man das richtig einsetzte, konnte man recht sicher sein, dass eine Amok laufende kleine Subroutine nicht das Programm ins Verderben zog.
Bei den neueren PICs wurde das schon aufgeweicht und nach einem ersten Blick in die Data Sheets der 24xx dort wohl noch mehr.

Also ich habe nicht vor, die Seiten zu wechseln (Atmel), aber die Richtung gefällt mir nicht, zu wenig "embedded".

Gruß
Phaidros