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 ?
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 |
@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) ?
> 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.
>> 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).
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.
@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 :-((
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.