uint16_t Array im PROGMEM; erste Elemente stimmen nicht

[Alexander H. (ill_son)]

Hallo,

ich habe eine Frage zum Speichern von Arrays im Programmspeicher. Zu 
Testzwecken habe ich folgendes Array im Programmspeicher abgelegt.

const uint16_t c0 [8191] PROGMEM = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20, ... , 8190};

und greife wie folgt im Programm darauf zu:

for(uint16_t i = 0; i < 8191; i++)
{
   uart_writeln(ultoa(pgm_read_word(&(c0[i])), tmpstr, 10));
}

Ansonsten macht das Programm nichts weiter. Ich habe noch weitere Arrays 
derart angelegt, um den Programmspeicher zu füllen.

Ausgegeben werden die Werte wie folgt: 8187, 8188, 8189, 8190, 0, 1...
Auch bei den anderen Arrays stimmen die Elemente nicht. Woran kann das 
liegen?

Grüße, Alex

[M. K. (sylaina)]

Alexander H. schrieb:
> Ausgegeben werden die Werte wie folgt: 8187, 8188, 8189, 8190, 0, 1...
> Auch bei den anderen Arrays stimmen die Elemente nicht. Woran kann das
> liegen?

Welcher AVR ist denn in Gebrauch? Ist dir klar, dass dein Array alleine 
16382 Byte Flash brauchen würden?
Warum willst du den Flash-Speicher eigentlich füllen? Was ist Sinn und 
Zweck der Aktion?

[Werther (Gast)]

Poste das Programm so, wie du es kompiliert hast.

[Alexander H. (ill_son)]

Hallo,

danke für eure Antworten. Ich verwende einen ATxmega128A1. Sinn und 
Zweck der Aktion ist es, meinen Bootloader zu testen, im speziellen die 
Generierung der zu sendenden Daten aus dem Intel-HexFile, und dafür ein 
Programm zu haben, was etwas Sinnvolles macht und dabei möglichst den 
ganzen Flash belegt. Quellcode kann ich morgen früh posten.

Grüße, Alex

[Georg G. (df2au)]

Warum ultoa? 16 Bit ist ein normaler Integer, kein Long.

[M. K. (sylaina)]

Georg G. schrieb:
> Warum ultoa? 16 Bit ist ein normaler Integer, kein Long.

Ja, das könnte man fragen, ist aber gewiss nicht das Problem.

Alexander H. schrieb:
> Quellcode kann ich morgen früh posten.

Das ist sicher sinnvoll, hänge die Quellcode-Dateien einfach an den 
Beitrag an bzw. wenn du den Code in den Beitrag packst denke daran die 
entsprechenden Tags zu benutzen, sonst liest es sich recht schwer.

Der Fehler ist, dass zuerst die vier letzten Elemente kommen und dann 
beginnt die Aufzählung von vorne? Oder sind zwischen drin auch Fehler?

[Stefan E. (sternst)]

Alexander H. schrieb:
> Ich verwende einen ATxmega128A1. Sinn und
> Zweck der Aktion ist es, meinen Bootloader zu testen, im speziellen die
> Generierung der zu sendenden Daten aus dem Intel-HexFile, und dafür ein
> Programm zu haben, was etwas Sinnvolles macht und dabei möglichst den
> ganzen Flash belegt.

Dir ist klar, dass pgm_read_word nur auf die unteren 64k zugreifen kann?

Lass mich raten: zum Füllen des Speichers hast du mehrere dieser Arrays 
angelegt, die alle die selbe Zahlenfolge enthalten. Und bei manchen 
(nämlich jenen, die jenseits der 64k-Grenze liegen) hast du das 
beschriebene Problem.

[Joachim B. (jar)]

Stefan E. schrieb:
> Dir ist klar, dass pgm_read_word nur auf die unteren 64k zugreifen kann?

guter Einwand

pgm_read_word_far() sollte helfen?

aber dann konsequent für alles nicht das ein Mischmasch entsteht.

geklaut aus:
Beitrag "Frage: Atmega >64k, PROGMEM und Pointer, AVR Studio 6"

ich bin selbst beim 2560 mal reingefallen, habe den aber lange nicht 
mehr angesehen.

[Alexander H. (ill_son)]

Stefan E. schrieb:
> Dir ist klar, dass pgm_read_word nur auf die unteren 64k zugreifen kann?
>
> Lass mich raten: zum Füllen des Speichers hast du mehrere dieser Arrays
> angelegt, die alle die selbe Zahlenfolge enthalten. Und bei manchen
> (nämlich jenen, die jenseits der 64k-Grenze liegen) hast du das
> beschriebene Problem.

Du muss Hellseher sein. Also erstens, nein das war mir nicht klar und 
zweitens, ja. Ich habe mich mal an dem Link im letzten Post langehangelt 
und das hier fabriziert:

#define FAR(var)                     \
({ uint_farptr_t tmp;                \
  __asm__ (                         \
  "ldi    %A0, lo8(%1)"  "\n\t" \
  "ldi    %B0, hi8(%1)"  "\n\t" \
  "ldi    %C0, hh8(%1)"         \
  : "=d" (tmp)                  \
  : "i"  (&(var)));             \
  tmp;                              \
})

#define FAR_SECTION   __attribute__((__section__(".far_section")))

const uint16_t c0 [8192] PROGMEM = {0,1,2...
const uint16_t c1 [8192] PROGMEM = {0,1,2...
const uint16_t c2 [8192] PROGMEM = {0,1,2...
const uint16_t c3 [8192] FAR_SECTION = {0,1,2,...
const uint16_t c4 [8192] FAR_SECTION = {0,1,2,...
const uint16_t c5 [8192] FAR_SECTION = {0,1,2,...
const uint16_t c6 [8192] FAR_SECTION = {0,1,2,...

int main( void )
{
 for(uint16_t i = 0; i < 8192; i++)
 {
  uart_writeln(ultoa(pgm_read_word(c0 + i), tmpstr, 10));
  uart_writeln(ultoa(pgm_read_word(c1 + i), tmpstr, 10));
  uart_writeln(ultoa(pgm_read_word(c2 + i), tmpstr, 10));
  uart_writeln(ultoa(pgm_read_word_far(FAR(c3) + 2 * i), tmpstr, 10));
  uart_writeln(ultoa(pgm_read_word_far(FAR(c4) + 2 * i), tmpstr, 10));
  uart_writeln(ultoa(pgm_read_word_far(FAR(c5) + 2 * i), tmpstr, 10));
  uart_writeln(ultoa(pgm_read_word_far(FAR(c6) + 2 * i), tmpstr, 10));
 }

 while(1);
}

Das macht zumindest erst einmal das, was ich erwarte. Warum dazu bei 
FAR_SECTION ein 2*i notwendig ist, habe ich allerdings noch nicht ganz 
verstanden.

Grüße, Alex

[Stefan E. (sternst)]

Alexander H. schrieb:
> Warum dazu bei
> FAR_SECTION ein 2*i notwendig ist, habe ich allerdings noch nicht ganz
> verstanden.

Weil das Array 16-Bit-Elemente enthält. Das FAR() ist ja nicht wirklich 
ein Pointer, sondern nur die Adresse in Form einer Zahl. Es kommt also 
nicht die Pointer-Arithmetik zum tragen.

[Dirk B. (dirkb2)]

Also ist die 2 von sizeof(uint16_t) bzw. sizeof(*c3) ?

[Falk B. (falk)]

Ja.