Array aus Textdatei füllen?

Textdatei:

1

0x01, 0x02, 0x03

C-Code:

1

const uint8_t e2p_data[] PROGMEM = 

2

{ 

3

4

#include "textdatei"

5

6

};

Sollte so funktionieren.

Rufus t. Firefly schrieb:

> C-Code:
>

1

> 

2

> const uint8_t e2p_data[] PROGMEM =

3

> {

4

> 

5

> #include "textdatei"

6

> 

7

> };

8

> 

9

>

Beim Öffnen der Datei setzt er mir drei komische Zeichen vorne hin:

1

0x40,0x01,0xB1,0xC3,0x1C,0x35,

Meckert er dann so an:

1

../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

In der Textdatei hingegen gehts gleich mit den "richtigen" Daten los.

Wie könnte man das noch lösen?

Elias R. schrieb:

>

1

> ../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:

1

My.Computer.FileSystem.WriteAllText(OutPath, hexarray(i), True, System.Text.Encoding.ASCII)

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.

ich kann ja kein VB, aber du offenbar.
Du hast doch schon eine Zeile gezeigt wie:

1

...System.Text.Encoding.ASCII...

Wenn du alles so schreibst (ohne die Nullen vorweg) sollte
das Resultat doch ASCII sein.

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.

So VB bewandert bin ich leider auch nicht. Aber ich such mal nach einer 
anderen Möglichkeit das File zu speichern.

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?

Jetzt habe ich endlich einen Weg gefunden das Textfile richtig zu 
erstellen:

1

   Dim fso, MyFile

2

   Set fso = CreateObject("Scripting.FileSystemObject")

3

   Set MyFile = fso.CreateTextFile("c:\testfile.txt", True)

4

   MyFile.WriteLine("This is a test.")

5

   MyFile.Close

So funktionierts.
-closed-

sieht doch ganz einfach aus, warum nicht gleich so? :-)

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?

Fragst du das mich? Ich habe mit VB nix am Hut...
Dafür bin ich zu doof, ich kann nur C.