Forum: Compiler & IDEs array volatile, elemente nicht?


von Jörg M. (Gast)


Lesenswert?

Hallo zusammen,

Ich habe folgendes (Compiler optimiert zuviel) Problem.

Ich hab ein globales array deklariert:
  volatile uint32_t  FREQUENCY[4];

Das fülle ich mit Daten (aus dem EEPROM). Alles so fein so weit, dann
hab ich ein paar Funktionen, denen ich z.B. &FREQUENCY[3] übergebe und
die dann sachen machen wie
  *freq = *freq + 10 ;

Das Problem ist, dass der Wert im Array nicht sofort up-to-date ist,
weil das alles in Registern stattfindet. In einer anderen Datei greife
ich auf ein array-element zu (später), und merke, das ist veraltet.

kann ich irgendwie den compiler zwingen, die werte auszulesen und
zurückzuschreiben, also im Prinzip sowas wie:

  volatile uint32_t tmp = FREQUENCY_CHANNEL[channel];
  FREQUENCY_CHANNEL[channel] = tmp;

ich hätte also gerne ein array mit volatile elementen, wenn man das so
sagen kann.

Gibts eine Lösung für mein Problem?

Gruss

Jörg M.

von Werner B. (Gast)


Lesenswert?

Versuche es mal mit einem typedef.

typedef volatile unsingned long vuint32_t;

vuint32_t  FREQUENCY[4];

...

Ist aber nur so eine Idee.

von SuperUser (Gast)


Lesenswert?

wie ist den *freq deklariert?

von Jörg M. (Gast)


Lesenswert?

Hallo,

Was passiert ist folgendes:

   decrease_value(cursor_position, &(FREQUENCY_CHANNEL[channel]) );

mit definition von decrease_value():
   void decrease_value(uint8_t cursor_position, volatile uint32_t
*frequency);

und in dieser Funktion passiert z.B.:
   *frequency -=10000;

Jetzt starte ich mal den Versuch mit dem typedef

Jörg

von SuperUser (Gast)


Lesenswert?

Aha!

Ein gutes Beispiel dafür, dass

uint32_t a[]

nicht das gleiche ist wie ein

uint32_t *a

von Jörg M. (Gast)


Lesenswert?

und was sagt mir das?



es grüsst
der_auf_dem_schlauch_steht

Jörg

von SuperUser (Gast)


Lesenswert?

Ich muss gestehen, ich habe etwas oberflächlich gelesen, du übergibst ja
nur einen einzigen Wert und nicht das array...

Dann versuch doch mal

uint32_t * volatile a

von SuperUser (Gast)


Lesenswert?

ähm ohne garantie, ohne C-Buch schwimme ich hier auch ein wenig...

von Karl H. (kbuchegg)


Lesenswert?

> uint32_t * volatile a

Das ist garantiert keine Abhilfe.
Hier waere der Pointer selbst volatile und nicht
das worauf er zeigt.

Allerdings: ich weiss auch keine Abhilfe für Jörg

von hans dieter (Gast)


Lesenswert?

in einem standard-c array gibt es nur die elemente! D.h. ein Array ist
im Prinzip "nur" ein Zeiger auf das erste Element im Array. Damit der
Compiler weiß, wie viel Platz der für die Elemente reservieren soll ist
auch noch eine Größen-angabe nötig.
Schau mal in den Code, wo dein Array liegt.
volatile uint32_t frequency[4];
solle eigentlich schon im RAM liegen.
Zugriffe mit
uint32_t *ptr = &(frequency[3]);
und
*ptr = 23423424;
sollten eigentlich direkt erfolgen, da ptr nur die adresse des wertes
enthält. (Welche auf den RAM zeigt.)
Stell mal deinen Code rein und welchen Compiler du verwendest.

von Jörg M. (Gast)


Lesenswert?

Das ist ziemlich viel Code, ich dachte, ich hätte es schon auf das
wesentliche reduziert.

Ich lass den Compiler (avr-gcc (GCC) 3.4.3) mit -Os laufen, weil ich
sonst insgesamt an die Grenzen des Speichers bei mir laufe.

Ich überlege gerade, ob ich mir das array spare, und statt dessen 4
volatile variablen anlege, dann bin ich auf der sicheren Seite.

Jörg

von Jörg M. (Gast)


Lesenswert?

Hallo

Asche auf mein Haupt, ich hab mich an einer andren Stelle meines
Programmes um eins verzählt, und hab immer das falsche array-Element
wieder gelesen, und da alle mit dem selben wert initialisiert waren,
war das natürlich das alte, obwohl das richtige sich geändert hatte...


Runde Bier ausgeb

Jörg

von Karl H. (kbuchegg)


Lesenswert?

Prost

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.