Forum: Compiler & IDEs Separates Hex File. Geht das ?


von Rene B. (themason) Benutzerseite


Lesenswert?

Hallo Leute,

ich weiß nicht ob die Frage schonmal gestellt worden ist.
Ich möchte gerne in einem C-Projekt Daten definieren die in einem 
gesonderten Hex-File abgelegt werden.
Ich stelle mir das z.B. mit dem AVR-Studio so vor :

char TabelleFlash [] PROGMEM = { 1, 2, 4, 8, 16, 32, ... };

char TabelleEEPROM [] EEMEM = { 254, 253, 251, 247, ... };

char TabelleDF [] DATAFLASH = { 32, 64, 128, 192, 96, 48, 24, ... };

Hintergrund ist der das ich eben die ganzen Funktionen die mir der 
C-Compiler zur Verfügung stellt (Zeiger, Sizeof, Berechnungen mittels 
Konstanten usw) nutzen können möchte.

Wenn ich z.b. ein 2. EEProm oder ein DataFlash habe das ich dann z.b. 
sowas machen kann :

char Text1 [] DATAFLASH = { "Hallo ", };
char Text2 [] DATAFLASH = { "schöne ", };
char Text3 [] DATAFLASH = { "Daten ", };
char Text4 [] DATAFLASH = { "Welt ", };
char Text5 [] DATAFLASH = { "\n\r", };

char *ArrayText [] DATAFLASH = { Text1, Text2, Text3, Text4, Text5,  };

char EEPEntry [] EEMEM = { sizeof (ArrayText), sizeof (ArrayText) / 
sizeof (char *),  };

und in dem seprarat erzeugten Hex-File automatisch die richtigen 
Verweise von ArrayText auf die einzelnen Texte gesetzt werden.
Hintergrund ist der, dass ich größere Daten auslagern möchte aber 
trotzdem den Code (bzw. die Anbindung der Tabellen an mein eigentliches 
Programm) immer compilierbar und automatisch mit den entsprechenden 
erzeugten Verweisen nutzen können möchte.
Geht das ? Ich schätze ich muß im Make-File sowie im Linker-File 
Anpassungen machen wie der Speicher (in dem Falle ein Daten-Flash, 
könnte aber auch alles andere sein, z.b. ein EEPROM, oder ein FRAM oder 
oder oder) aufegbaut (Größe, Organisation, usw) machen. Das ich das 
resultierende Hex-File nicht per AVR-ISP gebrannt bekomme ist klar. Aber 
dafür kann man ja im Code eine Möglichkeit vorsehen das die Daten per 
serieller Schnittstelle via Applikation in das Datenflash bzw den 
jeweiligen Speicher geschrieben werden. Es geht sich halt erst nur um 
die Möglichkeit ein separates Hex-File zu erzeugen. Für das EEProm beim 
AVR wird das ja so gemacht, aber würde das auch für Erweiterungen 
funktionieren, und wenn ja wie ?

von Rolf Magnus (Gast)


Lesenswert?

Du kannst die Daten in eine eigene Sektion stecken. Dann kannst du mit 
objcopy aus dem elf-File diese Sektion in ein Hex-File kopieren und dann 
aus dem elf-File entfernen, damit der Linker sie nicht automatisch in 
.data steckt. So bräuchtest du am Linkerskript nicht mal was ändern.
1
#define DATAFLASH __attribute__((section("dataflash")))

und dann im Makefile vor der Konvertierung des elf-Files nach hex grob 
sowas wie:
1
avr-objcopy $(TARGET).elf $(TARGET)_dataflash.hex -j dataflash -O ihex
2
avr-objcopy $(TARGET).elf $(TARGET).elf -R dataflash

von Rene B. (themason) Benutzerseite


Angehängte Dateien:

Lesenswert?

@rolf

Danke für den Tipp. Ich habs mal ausprobiert und einen kleinen 
Teilerfolg erzielt. Also wenn ich per define eine eigene Section 
definiere und eine Tabelle damit versehe kann ich nach dem Build mir die 
Daten per objcopy rausholen. Allerdings passen die Adressen nicht. Ich 
habe mal obiges Beispiel in ein bestehendes kleines Projekt reinkopiert 
und die Hex-Datei erzeugen lassen. Das Hex-File fängt bei 0x2dd2 an, und 
die Verweise (Zeiger) in der ArrayText-Tabelle fangen bei 0x00ae an, 
obwohl beide Bereiche ja ab 0x0000 anfangen müssen.
Ein weiteres Problem sehe ich darin wenn das Hex-File größer als die 
dahinter versteckte Ur-Section (da meine Section dataflash ja auf .data, 
.sram bzw .progmem basiert).
Außerdem würde mir in dem Moment der Speicher ja irgendwo "fehlen".
Wie sieht das denn mit den Linker-Scripten aus ? Ich habe beim Win-AVR 
mal die ldscripts angeschaut, aber so wirklich schlau daraus werde ich 
nicht. Gibt es da irgendwo eine Zuordnung welcher AVR-Typ mit welchem 
Linker-Script (ich habe die Ordner avr25, avr3, avr6, avr1, xmega1-5 und 
die .x .xbn .x Linker-Scripte mit jeweils den Ordnernamen gefunden) 
verknüpft ist ?
Würde es reichen eine bestehende Section (z.b. .eeeprom) zu kopieren und 
umzubenennen, sodass sich die Speicherbereiche nicht ins Gehege kommen ?
Hätte das weiteren Einfluß auf Projekte die diese Section nicht nutzen 
(sprich, das der Linker dann meckert wenn meine selbstdefinierte Section 
in anderen Projekten nicht vorhanden bzw genutzt wird) ?

von Rolf Magnus (Gast)


Lesenswert?

> Allerdings passen die Adressen nicht.

Hmm, stimmt. Das hatte ich nicht bedacht.
Man könnte die Adresse auf 0 setzen, indem man dem objcopy noch anfügt:
1
--change-section-address dataflash=0

aber das wird auch noch nicht deinem Wunsch entsprechen. Das Problem 
ist, daß die Adressen für dein Programm trotzdem nicht stimmen. Ob man 
das hinbiegen kann, ohne am Linkerskript zu drehen, weiß ich nicht.

> Ein weiteres Problem sehe ich darin wenn das Hex-File größer als die
> dahinter versteckte Ur-Section (da meine Section dataflash ja
> auf .data, .sram bzw .progmem basiert).

Da weiß ich jetzt nicht, was du da genau meinst.

> Gibt es da irgendwo eine Zuordnung welcher AVR-Typ mit welchem
> Linker-Script (ich habe die Ordner avr25, avr3, avr6, avr1, xmega1-5
> und die .x .xbn .x Linker-Scripte mit jeweils den Ordnernamen gefunden)
> verknüpft ist ?

Da gibt's eine Liste: 
http://www.nongnu.org/avr-libc/user-manual/using_tools.html

> Würde es reichen eine bestehende Section (z.b. .eeeprom) zu kopieren
> und umzubenennen, sodass sich die Speicherbereiche nicht ins Gehege
> kommen ?

Das wäre jetzt mein nächster Vorschlag gewesen. Da die Sektion .eeprom 
ja im Prinzip schon genau das gleiche macht, kann man sich da abgucken, 
wie's funktioniert und das genauso machen.

> Hätte das weiteren Einfluß auf Projekte die diese Section nicht nutzen
> (sprich, das der Linker dann meckert wenn meine selbstdefinierte
> Section in anderen Projekten nicht vorhanden bzw genutzt wird) ?

Du mußt ja nicht die Files der Installation verändern. Du kannst auch 
das geänderte Linker-Skript zu deinen Sourcen packen.

von Rene B. (themason) Benutzerseite


Lesenswert?

>> Ein weiteres Problem sehe ich darin wenn das Hex-File größer als die
>> dahinter versteckte Ur-Section (da meine Section dataflash ja
>> auf .data, .sram bzw .progmem basiert).

>Da weiß ich jetzt nicht, was du da genau meinst.

Ich meine das so : Wenn ich mir eine Section erstelle bezieht sich diese 
ja immer auf entweder das SRAM, das EEProm oder den Flash-Speicher. Eine 
Section ist ja nichts weiter als ein reservierter Bereich in meinen 
vorhandenen Speicherbereichen, quasi Shared. Und demnach würde mir der 
Platz den ich bei der Reservierung meiner Tabellen brauche irgendwo 
fehlen (SRAM, EEProm oder eben Flash), richtig ?.

>Da gibt's eine Liste:

Jau dank dir. Sowas hab ich gesucht.

>Das wäre jetzt mein nächster Vorschlag gewesen.

Ich werds mal so ausprobieren.

>Du mußt ja nicht die Files der Installation verändern. Du kannst auch
>das geänderte Linker-Skript zu deinen Sourcen packen.

Dazu dann mal ne Frage. Wenn ich das geänderte Linker-Script mit zu den 
Sourcen packe muß das Make-File ja auch entsprechend auf dieses 
Linker-Script zugreifen, richtig ?
Ich frage deshalb weil ich mich mit den Make-Files noch nicht so 
auskenne (schäm).

von Rolf Magnus (Gast)


Lesenswert?

Der Linker muß drauf zugreifen, d.h. du mußt den Linker-Optionen den 
Parameter zum Verwenden deines Linkerskripts anfügen. Ich hab das selbst 
noch nicht direkt gemacht, sondern nur über ein spec-File, wo das drin 
steht. Aber es müßte auch direkt mit der Option -T <deinlinkerskript> 
gehen.

von Rene B. (themason) Benutzerseite


Angehängte Dateien:

Lesenswert?

@rolf

Also ich habe das Linker-Script und das Make-File entsprechend 
angepasst, aber es will leider noch nicht. Ich hab alles was nach eeprom 
oder .epprom stinkt mal 1:1 kopiert und "eeprom" durch "dataflash" 
ersetzt. Es gibt nun im Makefile auch einen eigenen Abschnitt für das 
Datenflash (HEX_DATAFLASH_FLAGS).
Es wird auch ein hex-file für mein Datenflash erzeugt. Allerdings ist 
das leer. Die Daten landen immer noch in den Flash Bereich. Hex-File für 
EEProm funktioniert aber dennoch.
Mich wundert auch das im Map-File der Dataflash bereich den ich angelegt 
habe aufgeführt wird, ich aber nicht per DATAFLASH (bzw dem Makro mit 
dem Section-Attribut) meine Daten in den dafür vorgesehenen (virtuellen) 
Bereich reinkopieren kann.

Ich habe mal ein kleines Projekt erstellt mit angepasstem Linkerskript 
und Makefile.
Vllt hat ja jemand ne Idee was es sein kann. Ich denke es ist 
(hoffentlich) nur ne Kleinigkeit, aber ich komm nicht drauf :-((

von Rene B. (themason) Benutzerseite


Angehängte Dateien:

Lesenswert?

So. Ich glaube ich habs hinbekommen. Und zwar schien es (unerklärlicher 
weise) daran zu liegen, dass der Linker ein Problem hat mit .dataflash 
und "dataflash" und "data" nicht auseinander halten kann. Nehme ich für 
die Benamung statt dataflash ein dflash funktioniert es problemlos. Ich 
habe mir mal den "Spaß" erlaubt und einen weiteren Speicherbereich 
(exteep für Externes EEProm) zu definieren, und hier funktioniert es 
auch auf anhieb.
Wahrscheinlich dürfte es bei Speicherbereichen die den Namen textmem 
oder dataextended oder irgendwas wo der Name schon "drin" steckt 
Probleme geben.
Kann jemand dieses Verhalten bestätigen ?! Also das der Linker bei der 
Benamung da etwas "einfach" gestrickt ist ?!

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.