Hallo,
ich habe mir für meinen Mega164 ein Programm geschrieben, dass ein
externes EEPROM per I2C programmiert. Die Daten dafür liegen im FLASH
und werden so von mir definiert:
#include <avr/pgmspace.h>
const uint8_t e2p_data[] PROGMEM = { ...1024byte... }
Zum brennen auf den Chip verwende ich das Programm "jtagice.exe" von
AVR. Damit kann ich per .bat den Chip mit einem klick brennen.
Kann ich irgendwie dieses Monsterarray in eine externe Datei auslagern?
Am besten so, dass ich einfach nur den Inhalt des Arrays, also 0x00,
0x01, 0x02.....in einer Textdatei speichere und dann beim kompilieren er
die Daten dort rausholt.
Textdatei an vorgegebene Stelle kopieren -> AVR Studio aufmachen und
kompilieren -> Brennen -> fertig
Dann könnte ich die Textdatei - die Daten des Arrays, die dann später
ins EEPROM sollen - einfach tauschen wenn was anderes reingeschrieben
werden soll.
Danke
> ../out_hex.txt:1: error: stray '\357' in program
2
> ../out_hex.txt:1: error: stray '\373' in program
3
> ../out_hex.txt:1: error: stray '\377' in program
4
>
>
Wo hast du die Textdatei her?
Wird die mit einem Programm erzeugt?
> In der Textdatei hingegen gehts gleich mit den "richtigen" Daten los.
Zumindest zeigt ein anderer Texteditor diese Zeichen nicht an. Das
heisst aber nicht notwendigerweise, dass sie nicht drinn sind. Am besten
organisierst du dir einen Hex-Editor und siehst dir byteweise an, wie
die Datei losgeht.
> Wie könnte man das noch lösen?
Der Lösungsweg ist schon richtig.
Nur muss die Textdatei dafür auch richtig aufgebaut sein. Kein
Sonderzeichen, keine Codierungsinfo. Plain vanilla ASCII und sonst
nichts. Dein Punkt zum Ansetzen ist die Erzeugung dieser Textdatei und
nicht die Verwendung.
Die Textdatei erzeuge ich mir selber aus einer binären Datei.
Die Hex Werte werden dann mit Komma getrennt in ein .txt geschrieben.
Ist also keine richtige Hex Datei, sondern nur die Hex Werte in einer
Textdatei.
Was könnte man da falsch machen beim Umwandeln, bzw. beim Erstellen der
Textdatei?
genau genommen die Byte order mark (BOM), siehe
http://de.wikipedia.org/wiki/Byte_Order_Mark
Wahrscheinlich ist das Ding als UTF-8 gespeichert, deshalb geht es
mit okt 357 los, das ist 0xEF.
Klaus Wachtler schrieb:
> genau genommen die Byte order mark (BOM), siehe> http://de.wikipedia.org/wiki/Byte_Order_Mark> Wahrscheinlich ist das Ding als UTF-8 gespeichert, deshalb geht es> mit okt 357 los, das ist 0xEF.
Richtig es war UTF8. Jetzt habe ich mal folgendes versucht:
VB-Code:
Mit ASCII werden dann beim includen die ersten 5 bytes als 0x00 gelesen.
Also auch noch nicht das Wahre.
Karl heinz Buchegger schrieb:
> Der Lösungsweg ist schon richtig.> Nur muss die Textdatei dafür auch richtig aufgebaut sein. Kein> Sonderzeichen, keine Codierungsinfo. Plain vanilla ASCII und sonst> nichts. Dein Punkt zum Ansetzen ist die Erzeugung dieser Textdatei und> nicht die Verwendung.
Was ist dann "plain vanilla" ASCII?
ASCII ohne Schnickschnack, also auch ohne die drei einleitenden Bytes.
Nimm einen einfachen schlichten Editor, der nur oder zumindest
auf Anforderung nackte ASCII-Dateien speichern kann.
Oder du öffnest die Datei, wie du es oben gezeigt hast, lässt die
ersten Zeichen weg (deine fünf Nullen) und schreibst den Rest wieder.
Dann sollte das Resultat auch nacktes ASCII sein.
Klaus Wachtler schrieb:
> Oder du öffnest die Datei, wie du es oben gezeigt hast, lässt die> ersten Zeichen weg (deine fünf Nullen) und schreibst den Rest wieder.> Dann sollte das Resultat auch nacktes ASCII sein.
Die Frage ist doch eher wie ich die Daten gleich "plain vanilla" ASCII
speichern kann? Oder besser gesagt: So speichern, dass beim includen
alles reibungslos funktioniert.
PS: Ich hatte mir mal ein kleines Programm gebaut, das aus beliebigen
Binärdateien eine passende Folge von Initialisierungen für C macht,
die man mit #include einfügen kann.
Bei Bedarf kannst du das ja auch nehmen, und die Datei einfach neu
erzeugen aus deinem Original.
Klaus Wachtler schrieb:
> Wenn du alles so schreibst (ohne die Nullen vorweg) sollte> das Resultat doch ASCII sein.
Das dachte ich auch. Aber wie gesagt er überschreibt mir die ersten
Werte. Ich könnte also beim Erstellen des Files erstmal Platzhalter
schreiben und dann mit den wirklichen Daten loslegen. Aber so richtig
gefällt mir die Lösung noch nicht.
Muss doch möglich sein, dass sauber hinzubekommen?
Wie hast du denn das in deinem Programm gelöst?
Elias R. schrieb:
> schreiben und dann mit den wirklichen Daten loslegen. Aber so richtig> gefällt mir die Lösung noch nicht.
Schau mal ob du irgenwie die Möglichkeit hast eine Datei im RAW/Binary
Modus zu schreiben, ich vermute mal das die 'FileSystem.WriteAllText'
Funktion standardmäßig ein paar Bytes hinzufügt um später beim einlesen
das Encoding erkenne zu können.
Elias R. schrieb:
> ...> Wie hast du denn das in deinem Programm gelöst?
In C++ ganz einfach und schlicht.
Quelltext: http://mfgkw.dyndns.org/bin2c.cpp
Für Windows übersetzt als Anlage.
Wenn ich meine konvertierten Daten aus dem Textfile rauskopiere, ein
neues Textfile per rechte Maustaste -> Neu erstelle und die Daten dann
wieder einfüge funktioniert alles.
Das heißt ich muss jetz einen Weg finden wie ich in VB ein "richtiges"
Textfile erstelle so wie Windows es tut. (oder ich erstelle vorher ein
Textfile und lass die Daten dann reinschreiben was aber nicht seh
praktisch ist.)
Kann mir da jemand behilflich sein?
Jaja.... ;-)
Es gibt in VB irgendwie so viele Arten gewisse Dinge zu bewirken. Ich
hab allerdings absolut keine Ahnung wie man was wo wie verwendet...
Was unterscheidet denn den Code jetzt von dem oben in der Wirkung?