[PIC] Per Code in den Flash schreiben - Grundlegende Verständnisfragen

OK, danke für die Info.
Heißt das dann, dass im Simulator definitiv etwas falsch läuft? Denn der 
erste Schreibvorgang funktioniert in der Simulation (dürfte eigentlich 
nicht funktionieren) und der zweite nach dem Löschen schlägt fehl 
(sollte eigentlich funktionieren).

Wo genau kann ich nachsehen? Den Quellcode der Flash-Routinen kann ich 
nicht einsehen. Die PDF zur Peripheral Library sagt dazu auch nichts.

Allerdings glaube ich, dass nach Aufruf der Funktion nicht gewartet 
werden muss. Sieht auch beim Durchsteppen durch den Code nicht so aus, 
da sich ja beim ersten Schreiben und beim Löschen direkt nach aufruf der 
Funktionen der Flash-Inhalt ändert. Nur eben beim zweiten Schreib-Aufruf 
nicht.

Stefan schrieb:
> Wo genau kann ich nachsehen? Den Quellcode der Flash-Routinen kann ich
> nicht einsehen. Die PDF zur Peripheral Library sagt dazu auch nichts.

Du benutzt doch sicherlich MPLABX?
Klicke bei gedrückter ControlTaste auf die Funktion, dann wird der 
Quelltext der Funktion geöffnet.

Stefan schrieb:
> (Etwas seltsam finde ich auch, dass der Funktion EraseFlash die
> Endadresse mitgegeben werden muss, anstelle der Anzahl Blocks, die
> gelöscht werden sollen. Es können doch sowieso nicht einzelne Bytes
> gelöscht werden..)

Ich habe mit diesen Lib-Funktionen noch nicht gearbeitet aber sieh es 
als Hilfestellung an, dass Du nicht selbst die boundaries errechnen 
musst.
Kann natürlich Probleme machen, wenn nicht zu überschreibende Stellen 
kurz danach kommen und du nicht merkst, dass diese im selben Block wie 
die letzten zu schreibenden Bytes sind. Aber das passiert nur, wenn du 
keinen Überblick über deine Adressaufteilung hast.

Stefan schrieb:
> Ist das ein Bug im Simulator, oder mache ich etwas falsch?
Mag sein, da Hardwarefunktionen nicht immer astrein abzubilden sind.

Kastanie schrieb:
> Du benutzt doch sicherlich MPLABX?
> Klicke bei gedrückter ControlTaste auf die Funktion, dann wird der
> Quelltext der Funktion geöffnet.

Das wusste ich noch gar nicht :-)
Allerdings bekomme ich auch damit nur den function header, nicht den 
kompletten source code. Die Lib wird wohl in compilierter Form vorliegen 
(object file? damit habe ich mich noch nicht befasst)

Kastanie schrieb:
> Kann natürlich Probleme machen, wenn nicht zu überschreibende Stellen
> kurz danach kommen und du nicht merkst, dass diese im selben Block wie
> die letzten zu schreibenden Bytes sind. Aber das passiert nur, wenn du
> keinen Überblick über deine Adressaufteilung hast.

Die Schreibblöcke bilde ich mir schon vorweg selber. Ich weiß also 
genau, welche Daten in welchen Block müssen.

Kastanie schrieb:
> Stefan schrieb:
>> Ist das ein Bug im Simulator, oder mache ich etwas falsch?
> Mag sein, da Hardwarefunktionen nicht immer astrein abzubilden sind.

ok, ich werde einfach weitermachen und am Ende schauen, ob es in 
Realität tut, was es soll.

Volker S. schrieb:
> Welcher PIC?
> Welcher Compiler?

PIC181F25K22 und MplabX mit XC8 Compiler

Zwei Frage habe ich doch noch:

In der Hex-Datei stehen folgende Infos:
 - Programmcode
 - Configuration Bits
 - EEPROM-Daten

1. Könnte noch etwas anderes enthalten sein, was ich aktuell nicht 
bedenke?
2. Schreibe ich die Configuration bits genau wie den Programmcode and 
die angegebene (in diesem Fall 4 Bytes lange) Adresse? Also auch wieder 
vorher Block löschen und dann Block schreiben? Das würde doch bedeuten, 
dass für einen kleinen Moment die Konfiguration in einem ungewünschten 
Zustand ist, was durchaus zu Problemen führen könnte, oder?

Stefan schrieb:
> PIC181F25K22 und MplabX mit XC8 Compiler

Ich meine natürlich PIC18F25K22

So, ich habe es jetzt alles umgesetzt und es funktioniert!
Also Also handelt es sich tatsächlich um einen Bug im Simulator.

Es hat ein wenig länger gedauert, da ich ein Problem mit einer 
berechneten Adresse für den goto Befehl hatte. Dafür mache ich aber ein 
neues Thema auf.

Danke für eure Hilfe!