www.mikrocontroller.net

Forum: Compiler & IDEs eeprom_read_block Problem


Autor: Frank Link (franklink)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,
ich habe ein kleines Verständnisproblem::

Ich möchte einfach nur einen Bereich aus einem Array mit 
eeprom_read_block auslesen. Aber irgendwie schickt die Funktion mein 
Programm ins nirvana.

Strukturdefinition:
#define NUMBER_OF_RGB_LED  2
#define NUMBER_OF_RGB_TABLE 8

typedef struct _colorstruc 
{
  unsigned char H;
  unsigned char S;
  unsigned char V;
  unsigned char Speed;
  unsigned char red_pwm;
  unsigned char green_pwm;
  unsigned char blue_pwm;
  unsigned char Pin_R;
  unsigned char Pin_G;
  unsigned char Pin_B;
} colorstruc;

typedef struct _colorproc
{
  colorstruc colorstrucs[NUMBER_OF_RGB_LED];
} colorproc;


EEPROM Arraydefinition:
EEMEM colorproc colortable[8] =
{
    { 
      { 
        // White 
        { 0x00, 0x00, 0xFF, 200, 0, 0, 0, 1, 2, 3 },
        { 0x00, 0x00, 0xFF, 200, 0, 0, 0, 4, 5, 6 } 
      }
        }, 
    { 
      { 
        // Bright red
      { 0x00, 0xFF, 0xFF, 0xC8, 0, 0, 0, 0, 1, 2 },
        { 0x00, 0xFF, 0xFF, 0xC8, 0, 0, 0, 3, 4, 5 } 
      }
        }, 
    { 
      { 
        // Bright yellow
      { 0x2A, 0xFF, 0xFF, 0xC8, 0, 0, 0, 0, 1, 2 },
        { 0x2A, 0xFF, 0xFF, 0xC8, 0, 0, 0, 3, 4, 5 } 
      }
        }, 
    { 
      { 
        // Bright green
      { 0x55, 0xFF, 0xFF, 0xC8, 0, 0, 0, 0, 1, 2 },
        { 0x55, 0xFF, 0xFF, 0xC8, 0, 0, 0, 3, 4, 5 } 
      }
        }, 
    { 
      { 
        // Bright cyan
      { 0x80, 0xFF, 0xFF, 0xC8, 0, 0, 0, 0, 1, 2 },
        { 0x80, 0xFF, 0xFF, 0xC8, 0, 0, 0, 3, 4, 5 } 
      }
        }, 
    { 
      { 
        // Bright blue
      { 0xAA, 0xFF, 0xFF, 0xC8, 0, 0, 0, 0, 1, 2 },
        { 0xAA, 0xFF, 0xFF, 0xC8, 0, 0, 0, 3, 4, 5 } 
      }
        }, 
    { 
      { 
        // fast cycle
      { 0x00, 0xFF, 0xFF, 0x0A, 0, 0, 0, 0, 1, 2 },
        { 0x00, 0xFF, 0xFF, 0x0A, 0, 0, 0, 3, 4, 5 } 
      }
        }, 
    { 
      { 
        // fast cycle low sat
      { 0x00, 0x7F, 0xFF, 0x32, 0, 0, 0, 0, 1, 2 },
        { 0x00, 0x7F, 0xFF, 0x32, 0, 0, 0, 3, 4, 5 } 
      }
        }
};


Ziel-Array:
colorproc colors[1] =
{
  { 
    { 
      { 0x00, 0xFF, 0xFF, 0xC8, 0, 0, 0, 1, 2, 3 },
      { 0x00, 0xFF, 0xFF, 0xC8, 0, 0, 0, 4, 5, 6 } 
    }
  }
};


und so lese ich:
eeprom_read_block( (void*)&colors[0], (const void*)&colortable[0], sizeof( colorproc ) );


Wäre für den entscheidenden Tip dankbar.

Gruß
Frank

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist es denn für ein µC?

Neuere Versionen der avr-libc ignorieren einen Siliconbug einiger 
AVR-Derivate. Es wird eine ungültige Instruktion erzeugt, die im Manual 
verboten wurde.

Ob das das Poroblem ist, siehst du bei einer Sichtung des Disassemblies 
nebst Errata deines µC.

Autor: Frank Link (franklink)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Johann,
nee, glaub ich nicht, ich verwende die gleiche Struktur in einer anderen 
Anwendung um Daten aus einem zwei dimensionalen EEMEM-Array zu lesen. 
Der Unterschied hier ist lediglich die Struktur in die ich die Daten 
einlesen möchte.

Ich vermute einfach nur ein falscher Aufruf... D.h. falsche 
Parametrisierung.

Gruß
Frank

Autor: Stefan Ernst (sternst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schau nochmal genau hin, ob es nicht noch einen weiteren Unterschied 
gibt, nämlich die Optimierungsstufe. Die fehlerhafte Instruktion wird 
nur erzeugt, wenn die Optimierung abgeschaltet ist.

Autor: Frank Link (franklink)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vergessen:

Prozessor: ATMega8
Board: MyAvrUsb
Umgebung: AVR Studio 4.13.557

Gruß
Frank

Autor: Werner B. (werner-b)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
1. Und das Wichtigste, die Compilerversion?

2. Workaround für das Compilerproblem = leere ISR für den EEProm 
Interrupt definieren.

3. EEMEM Daten werden vom Compiler "im Prizip" genauso behandelt wie 
Daten im Progmem. Es gelten also im wesentlichen auch die gleiche 
Beschränkungen.
Du kannt insbesondere den Abschnitt 
AVR-GCC-Tutorial: Array aus Zeichenketten im Flash-Speicher aus dem 
Tutorial auf dein Problem mit dem EEProm übertragen.
Ich fürchte so wird das nicht funktionieren. :-(

Werner

Autor: Frank Link (franklink)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Werner,
ich denke, das Problem liegt an sizeof( colorproc ). Ich hatte mir den 
Wert mal per UART ausgeben lassen und erhalte hier den Wert 0x20 an 
Stelle von 0x14.

In der Simulation läuft die Anwendung einwandfrei. Also liegt die 
Vermutung nahe, dass ich mir irgendwo Speicher überschreibe.

Ich werde heute Abend nochmals in Ruhe und mit dem notwendigen Abstand 
forschen.

Danke schon mal für die Ratschläge.

Gruß
Frank

Autor: Werner B. (werner-b)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> ...erhalte hier den Wert 0x20 an Stelle von 0x14.

Könnte das nicht nur ein Darstellungsproblem sein?  Denn 0x14 = 20Dez ?

Autor: Frank Link (franklink)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Werner,
eigentlich nicht, ich verwende eine Funktion für den Uart die mir einen 
Hex-Wert liefert. Da ich diese Funktion an anderer Stelle auch verwende 
und sie dort korrekte Werte liefert...

Aber wie so oft, der Teufel liegt im Detail, werde ich also heute Abend 
nochmals prüfen.

Ich werde heute Abend mal das ganze Teil posten. Mal sehen ob sich 
jemand erbarmt und mal rein schaut. Sitze schon zu lang an dem Problem 
und sehe wahrscheinlich mal wieder den Wald vor lauter Bäumen nicht 
mehr.

Gruß
Frank

P.S. eigentlich sollte das doch so richtig sein, oder?

Autor: Stefan Ernst (sternst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank Link wrote:

> ich denke, das Problem liegt an sizeof( colorproc ). Ich hatte mir den
> Wert mal per UART ausgeben lassen und erhalte hier den Wert 0x20 an
> Stelle von 0x14.

Sehr unwahrscheinlich. Die bereits angesprochene mögliche Hex<->Dez 
Verwechselung ist hier deutlich wahrscheinlicher.

Und mal so nebenbei: Bist du meinem Hinweis bezüglich der 
Optimierungsstufe mal nachgegangen?

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Werner B. wrote:
> 1. Und das Wichtigste, die Compilerversion?

Falls es der EERE-Bug ist, ist die Version der avr-libc interessanter. 
Neuere Versionen machen da nen ziemlich umständlichen indirekten call 
und wenn nicht alles komplett wegoptimiert wird, crasht es.

Zudem würd ich meine Hand nicht ins Feuer dafür legen, daß das Problem 
je nach C-Kontext nicht auch bei höheren Optimierungsstufen zum Tragen 
kommt.

Ergo: Nur ein Disassembly liefert Sicherheit.

Der Bug ist für ATmega8 aktiv.


Probleme kann es auch geben, wenn ein Modul mit -fpack-struct übersetzt 
ist und eines ohne.

Und in den Initializern kann ich eine {}-Ebene nicht zuordnen, scheint 
eine zu viel zu sein?

Autor: Frank Link (franklink)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Stefan,
nein, dem Optimierungproblem bin ich noch nicht nachgegangen, da ich 
erst heute Abend wieder daran arbeite.

Ist kein Problem, dass ich im Bürö habe.

Die Anwendung ist eine kleine Spielerei von mir für ein Moodlight.

Wie geschrieben, ich stelle heute Abend mal den Sourcecode und alle 
anderen Infos ein.

Gruß
Frank

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank Link wrote:
> Hallo Stefan,
> nein, dem Optimierungproblem bin ich noch nicht nachgegangen, da ich
> erst heute Abend wieder daran arbeite.

hmmm, soweit ich sehe, benutzt die neueste Version der avr-libc (1.6.4) 
explitit ein IN, so daß der Silicon-Bug nicht getriggert werden dürfte.

Da weiß Jörg bestimmt mehr drüber zu sagen, für welchen lib-Versionen 
überhaupt problematischer Code erzeugt werden könnte.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.