Forum: Compiler & IDEs Variable an fixer Flash-Adresse


von Tobi (Gast)


Lesenswert?

Hi!

Ich arbeite mit dem neuesten winavr mit dem ATmega32.

Ich würde gerne eine String Variable an eine fixe Adresse im Flash 
legen. Ziel soll sein, diese Variable aus dem dann erzeugtem *.hex file 
eindeutig auslesen zu können.(z.B. mit einem Windows Programm)
Dabei soll sich aber die .text section prinzipiell nicht ändern. Die 
.text section soll also um die Variable rumgebaut werden.
Bsp.: Der String "Testplatine V1.4" soll an der Flash-Adresse 0x0100 
landen.
Vorher und nacher soll wieder "normaler" Programmcode stehen.

Geht das überhaupt?

MfG Tobi

von Olaf (Gast)


Lesenswert?

> Geht das überhaupt?

Da WinAVR nur ein vornehmer Name fuer ein gcc Derviat ist und du dazu
den Source hast geht natuerlich alles. Die Frage ist nur ob du es
kannst. :-)

Ohne es jetzt schonmal gemacht zu haben wuerde ich vermutlich das
Linkescript ueberarbeiten und dort eine neue Section mit dem Namen
Tobi an deiner Wunschadresse einfuegen.

Eine andere Vorgehensweise waere natuerlich wenn du eine MagicNumber in 
deinen Source einfuegst und dafuer sorgst das deine Daten immer danach 
stehen. Dann brauchst du nur das Hex danach zu durchsuchen.

Olaf

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

,,um die Variable ... herum'' ist als Konzept im Linker nicht
vorgesehen.

von Tobi (Gast)


Lesenswert?

Hi!
Danke für die Antworten.
Das Problem mit den neuen Sections ist halt, dass die dann mit .text 
kollidieren. Und ans Ende des Flashes will ich die Variable nich legen, 
da das ja bei jedem Prozessor anders ist.

Kann man denn dann die section .text aufteilen? Es gibt ja wohl eine 
section.vectors, die sich in .text verbirgt. Man könnte ja zwischen 
.vectors und den restlichem Code in .text eine Variable plazieren. Man 
hätte dann erst die Interruptvektoren, dann z.B. ein kleine Lücke, dann 
die Variable und nach wieder einen kleinen Lücke den restlichen .text 
Teil.

von Stefan B. (stefan) Benutzerseite


Lesenswert?

Schon probiert die fragliche Variable mit PROGMEM zu definieren? Für 
mich sieht der folgende Ausschnitt in dem Linkercontrolscript avr5.x so 
aus, als ob PROGMEM Variablen zwischen den Vektoren und dem Hauptcode 
stehen. Und das wäre ja berechenbar
1
...
2
  .text :
3
  {
4
    *(.vectors)
5
    KEEP(*(.vectors))
6
    /* For data that needs to reside in the lower 64k of progmem.  */
7
    *(.progmem.gcc*)
8
    *(.progmem*)
9
    . = ALIGN(2);
10
     __trampolines_start = . ;
11
    /* The jump trampolines for the 16-bit limited relocs will reside here.  */
12
13
...

Anderer IMHO sauberer Ansatz: Wie wäre es mit Ablage der Daten im 
EEPROM?

von holger (Gast)


Lesenswert?

Warum solche Klimmzüge ?

Such im Hexfile einfach nach "Testplatine"
und lies die Version die dann folgt.
Ist doch völlig wurscht WO der String steht.
Dein Programm muss nur intelligent genug sein
das Hexfile zu durchsuchen. So schwer ist das nicht
zu programmieren.

von Tobi (Gast)


Lesenswert?

HI!

Danke!

Nur:
Das Ganze soll für verschiedene AVR Prozessoren funktionieren. Und das 
ist im *.hex File ja nicht abgelegt. Also gibts Probleme mit PROGMEM. 
Wie soll das Windows Programm dann die Adresse berechnen?

Der String soll eine ID darstellen. Die ist für jedes Projekt anders. 
Also kann ich nicht nach einem bestimmten string suchen. Außer ich würde 
ein Identifizierungszeichen ala "ID:" einstetzen.

von holger (Gast)


Lesenswert?

>Außer ich würde ein Identifizierungszeichen ala "ID:" einstetzen.

Genau das ist der richtige Weg. Ich würde statt "ID:" aber
was längeres nehmen: "Identifikation:" z.B.

von Stefan B. (stefan) Benutzerseite


Lesenswert?

Vielleicht erklärst du mal genauer, was du machen willst bevor die 
Werkzeuge zusammengesucht werden ;-)

Ich dachte es geht um einen

> Ich arbeite mit dem neuesten winavr mit dem ATmega32.

Wie passt das mit

> Das Ganze soll für verschiedene AVR Prozessoren funktionieren.

zusammen?

Wenn du unterschiedliche AVRs hast, solltest du auch für jeden Typ das 
Programm neu kompilieren. Es gibt nicht aus Jux und Dollerei viele 
verschiedene Includefiles und Linkerskripte... Und wenn du das machst, 
erhälst du zwangsläufig neue HEX-Files.

Das Auseinanderhalten vieler Hex-Files für viele unterschiedliche AVRs 
und viele unterschiedliche Projekte kann man durch eine Ordnerstuktur 
bei der Ablage/"Lagerhaltung" oder durch intelligente, automatisierte 
Namensgebung z.B. im Makefile erledigen. Du hast doch z.B. den µC Namen 
als Variable MCU. Nutze die doch.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Tobi wrote:

> Das Problem mit den neuen Sections ist halt, dass die dann mit .text
> kollidieren. Und ans Ende des Flashes will ich die Variable nich legen,
> da das ja bei jedem Prozessor anders ist.

Es wäre aber zumindest einheitlich auf den höchsten Adressen des
Hexfiles dann.  Das sollte nicht so schwer zu finden sein.

Die Größe der Interruptvektortabelle differiert zwischen den einzelnen
AVRs noch viel mehr und in viel diffizilerer Weise als die des Flash,
es zwischen Vektoren und Code zu legen, wird dir also auch kaum was
bringen.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

holger wrote:

>>Außer ich würde ein Identifizierungszeichen ala "ID:" einstetzen.
>
> Genau das ist der richtige Weg. Ich würde statt "ID:" aber
> was längeres nehmen: "Identifikation:" z.B.

Oder $Id: ... $, dann kann man das Tool "ident" auf die Binärversion
des ROM-Images loslassen...

von Tobi (Gast)


Lesenswert?

Hi nochmal!

Vielen Dank für die Hilfe!

Ich werde es mit einem Identifizierungsstring machen! Das scheint mir 
die sauberste Lösung zu sein!

MfG Tobi

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.