MSP430 - Info-Speicher und Optimierung

[rangi jones (Gast)]

Ich möchte den Informationsspeicher meines MSP340F2132 nutzen um 
Parameter dauerhaft zu seichern. Dazu benutze ich eine Struktur, mit der 
die einzelnen Werte leicht zugänglich sind. Mit einem #pragma wird diese 
Struktur an eine feste Adresse gelegt, hier Segment C - 0x1040. 
Unoptimiert funktioniert das prima.
Wenn ich die Optimierung auf "High" stelle werden die Lese-Zugriffe 
weg-optimiert. (IAR EW 4.x) Die Defaultwerte, welche der Struktur 
zugewiesen werden, werden gleich in den Quellcode eingebettet.
Welche Qualifier oder #pragmas muss ich verwenden damit korrekt auf den 
Inforamtionsspeicher zugegriffen wird?

Aktuell verwende ich folgenden Code:

typedef struct _EED_tstSegC_Data { ... u8 bParameterXYZ; ... } EED_tstSegC_Data

#pragma location = 0x1040
__root const EED_tstSegC_Data EED_stSegC_Data= { $Defaultwerte meiner Applikation$ }

Die Lesezugriffe erfolgen dann auf die Elemete der Struktur. Beispiel:

#define EED_bGET_ParameterXYZ()   EED_stSegC_Data.bParameterXYZ

Wie kann ich verhindern, dass die Code-Optimierung die Lese-Zugriffe 
weg-optimiert? Ich habe bereits einige varianten mit volatile und 
__no_init ohne erfolg ausprobiert


Vielen Dank

[Karl-heinz S. (cletus)]

Das Information Memory ist eigentlich Read-Only.

Wenn du es neu beschreiben willst, musst du den kompletten Block 
löschen.

Kann es sein, dass der Compiler das erkennt?

[rangi jones (Gast)]

Nochmal, es geht nicht nicht ums Schreiben - das mache ich in einer 
eigenen Funktion. Das funktioniert auch super.
Es geth ums lesen aus dem Info-Bereich. Die Daten werden mit 
Optimierung nicht mehr aus dem Info-Block entnommen. Die Werte stehen 
dann im Quellcode.
zb: "mov.b   #0x14,R12" dabei ist 0x14 mein Defaultwert, der eigentlich 
aus dem Info-Block entnommen werden sollte.
richtig waere "mov.b 0x1040,R12" - hier steht die 0x14 auf adresse 
0x1040

[Stefan (Gast)]

Frag mich jetzt nicht warum... klingt komisch, ist aber so... keine 
Ahnung warum!

Das produziert Dein beschriebenes Verhalten:
[c]
#include <msp430x20x2.h>
//#include "global_vars.h"

#pragma location = 0x1040
__root const int  test = 0x1234;

void main(void)
{
  int value = test;
  P1OUT |= (value & 0x00AA);

  while(1);
}
[c]

[Stefan (Gast)]

Ähh... nochmal:

Das produziert Dein beschriebenes Verhalten:

#include <msp430x20x2.h>

#pragma location = 0x1040
__root const int  test = 0x1234;

void main(void)
{
  int value = test;
  P1OUT |= (value & 0x00AA);
  
  while(1);
}

Während das hier (zumindest in IAR V3.42A) funktioniert:

<global_vars.h>:
extern const int  test;


<global_vars.c>:
#include "global_vars.h" 

#pragma location = 0x1040
__root const int  test = 0x1234;


<main.c>:
#include <msp430x20x2.h>
#include "global_vars.h"

void main(void)
{
  int value = test;
  P1OUT |= (value & 0x00AA);
  
  while(1);
}

[Stefan (Gast)]

Hier noch das List-File, max. Optimierungsstufe "speed"

1. Fall:

     11            int value = test;
     12            P1OUT |= (value & 0x00AA);
   \   000000   F2D020002100 BIS.B   #0x20, &0x21

2. Fall:

      9            int value = test;
     10            P1OUT |= (value & 0x00AA);
   \   000000   5E42....     MOV.B   &test, R14
   \   000004   7EF0AA00     AND.B   #0xaa, R14
   \   000008   C2DE2100     BIS.B   R14, &0x21

[rangi jones (Gast)]

schrei JAAAA, das Funktioniert !!!
vielen Dank.

und ich ich weiss auch warum. Man haette fast selber drauf kommen 
muessen.
Die einzelnen Module duerfen nichts vom Inhalt der Daten wissen. Sie 
muessen wissen wie die Struktur aussieht. Dazu muss das Ding mit extern 
rausgegeben werden. Dadurch dass der Inhalt aber in einem anderen c-File 
steht, kann der Compiler es nicht rausoptimieren sondern muss zugreifen. 
Das Optimieren erfolgt ja vor dem Linken.

Theoretisch sollte es im eigenen Modul optimiert werden. Da das aber 
nicht passiert, denke ich steckt da eine Logik im Compiler dahinter.

Da ich das nicht genau weiss, werde ich jetzt ein reines Daten-Modul 
anlegen, mit eigenem Header. Darin wird nicht zugegriffen.

vielen Dank nochmal.

[Johnny (Gast)]

Also wenn Du "test" explizit als const deklarierst, dann würde ich es 
als Compiler auch gleich wegoptimieren ;-)
Deine ursprüngliche Variante würde evtl. auch funktionieren, wenn Du bei 
"test" noch volatile voranstellst, damit es nicht wegoptimiert wird.

[Stefan (Gast)]

>Deine ursprüngliche Variante würde evtl. auch funktionieren, wenn Du bei
>"test" noch volatile voranstellst, damit es nicht wegoptimiert wird.

Das wäre eine logische Schlußfolgerung, die sogar im IAR-Compiler 
User-Guide als Beispiel vorgeschlagen wird. Jedoch funktioniert das in 
der Praxis nicht, da der Compiler die Kombination aus:

#pragma location = 0x1040,
volatile + const und
Wertzusweisung (test = 0x1234)
mit Fehlermeldung quittiert.