PROGMEM -- liest ab bestimmten Array nicht mehr aus

[Jens (Gast)]

Habe mehrere Dateien mit mit

uint8_t    Tab0[]   PROGMEM = Daten0,
 Tab1[]   PROGMEM = Daten1,
bis ...
Tab12[]   PROGMEM = Daten12;

in den Programmspeicher geladen

Dabei ist Datenx relativ groß, und so definiert

#define Daten0 {2,3,4,1, usw...}

nun gibt es 12 solcher Dateien und ab der 7. wird dann nicht mehr 
ausgelesen bzw. wieder vorn angefangen.

ich denke ja, dass der Pointer nicht weiterzählt, weil er zu klein ist.

benutze folgende Auslesezeile:

aTemp = pgm_read_byte(&Tab0[CounterBytes]);

dabei ist der CounterBytes 16Bit groß, die ersten 6 Dateien werden gut 
ausgelesen.

Was kann man tun?

[Rene Z. (rzimmermann)]

Hallo,

wie gross ist das Array den? Welcher Controller wird verwendet?

#define  pgm_read_byte_far(address_long)   __ELPM((uint32_t)(address_long)) 
#define  pgm_read_word_far(address_long)   __ELPM_word((uint32_t)(address_long)) 
#define  pgm_read_dword_far(address_long)   __ELPM_dword((uint32_t)(address_long)) 
#define  pgm_read_float_far(address_long)   __ELPM_float((uint32_t)(address_long))

http://www.nongnu.org/avr-libc/user-manual/group__avr__pgmspace.html

Gruß

[Jens (Gast)]

Ich stell den Beitrag mal unter uC ein.

ich verwende ein Board mit dem ATMega 1280.


(Mod.: der Beitrag passt in dieses Unterforum, Doppelpost unbegründet)

[Johann L. (gjlayde)]

Wieviel Daten sollen dann nach PROGMEM gelegt werden? Mehr als 64k?

[Jens (Gast)]

ja,

es ist ja auch so, dass mitten in der 7. Datei dann wieder die erste 
ausgelesen wird.
Also so, als würde der Adressspeicher überlaufen. Ich weiß nur nicht ob 
es beim Einspeichern, also bei Progmem oder beim Auslesen passiert.
Ich denke, der Adressspointer müsste größer sein.

Es sind sehr viele 8Byte Konstanten - Messreihen.

[g457 (Gast)]

> Also so, als würde der Adressspeicher überlaufen.

Nicht ganz, die Adresse (bzw. das Ergebnis der Adressberechnung) läuft 
über.

> Ich denke, der Adressspointer müsste größer sein.

Ja, und zwar sizeof(uint32_t), nicht sizeof(void*) wie aus der Signatur 
von pgm_read_byte_far() (siehe Doppelpost) eindeutig hervorgeht -> 
Adresse selber ausrechnen.

Alternativ wäre noch zu klären, ob der Compiler mit __flash richtig(tm) 
rechnen würde.

[Falk B. (falk)]

@ Jens (Gast)

>Es sind sehr viele 8Byte Konstanten - Messreihen.

Jaja, und mein Bruder hat ein gaaaanz grooooßes Auto.

Mensch, nenn man ein paar ZAHLEN!!!

Siehe

http://www.mikrocontroller.net/articles/Netiquette#Klare_Beschreibung_des_Problems

[Johann L. (gjlayde)]

g457 schrieb:

> Alternativ wäre noch zu klären, ob der Compiler mit __flash richtig(tm)
> rechnen würde.

Ja, tut er: Er rechnet genauso wie in der Dokumentation beschrieben :-)

[Jens (Gast)]

Danke erst mal, also es ist der ATM1280. Der ist zu 97% voll mit den 
über PROGMEM eingelesenen Daten, das hat also funktioniert.

Die Größe schätze ich jetzt mal, da es Bytes von Dateien sind, die ich 
vorher mit Delphi in eine h Datei umgewandelt habe.

Hier der Code-Auszug:

   uint8_t  Tab0[]   PROGMEM = TabDaten0,
  Tab1[]   PROGMEM = TabDaten1,
  ...
  Tab11[]   PROGMEM = TabDaten11;

dann die TabDaten – sie sehen etwa so aus.
Header File

 #define TabDaten0 {156,4,57,32,... 45,68\
      23,34,113, ... 78,54 \
      24,200}

jetzt die Größen

ein File ist etwa 7KB groß
alle 12 Files sind ca. 110KB groß

ausgelesen habe ich bisher mit

 x = pgm_read_byte(&TabDaten0[i]);

was bis zur 7. Tabelle wunderbar geht.

[Falk B. (falk)]

Beitrag "Re: PROGMEM -- liest ab bestimmten Array nicht mehr aus"

Deine Daten ab der 7. Tabelle liegen oberhalb von 64kB, dort muss man 
per _far Zugriffen arbeiten.

[Jens (Gast)]

Also mit

pgm_read_byte_far(&TabDaten10[i])

Das habe ich probiert, geht aber nicht, folgende Warnung erscheint;

warning: cast from pointer to integer of different size

[Falk B. (falk)]

Was wohl daran liegt, dass deine Variablentypen nicht stimmen. Ich habe 
auch noch nie mit den _far Funktionen gearbeitet. Vielleicht so.

uint_farptr_t my_far_pt = &TabDaten10;
pgm_read_byte_far(&my_far_pt[i])

[hal9000 (Gast)]

Jens schrieb:
> aTemp = pgm_read_byte(&Tab0[CounterBytes]);

wusel wusel. Mein Tipp für wenig Geld gibt es professionelle Compiler
die diesen Mist nicht brauchen.

[Stefan E. (sternst)]

Falk Brunner schrieb:
> Vielleicht so.

Nein. Das grundlegende Problem hier ist, dass ein Pointer halt nur 
16-Bit hat. Der "direkte" Weg geht also in keinem Fall.

Wieso gibt es hierzu eigentlich 2 Threads?
Beitrag "pgm_read_byte_far"

[Jens (Gast)]

ja danke erst mal,

habe gerade hier gefunden, dass der AVR-GCC tatsächlich Zeiger nur bis 
16bit akzeptiert. Na prima.

[g457 (Gast)]

> habe gerade hier gefunden, dass der AVR-GCC tatsächlich Zeiger nur bis
> 16bit akzeptiert. Na prima.

Schön dass mein Hinweis und meine Lösung von gestern Abend 2335 doch 
noch gelesen wurden. Hatte schon befürchtet, dass die durchgeflutscht 
seien.

Und wie schon gesagt: selber berechnen, das ist nur wirklich kein 
Beinbruch.

Nix für ungut

[Johann L. (gjlayde)]

Nimm __memx, dann sind Zeiger 24 Bit groß.

[Falk B. (falk)]

@ Johann L. (gjlayde) Benutzerseite

>Nimm __memx, dann sind Zeiger 24 Bit groß.

Kann man das auch mal als gescheites Beispiel darstellen, damit es auch 
normale Leute ohne ultimatives Insiderwissen verstehen?

[Johann L. (gjlayde)]

Welcher Teil der GCG-Doku ist denn unklar?

http://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html

Oder gehört die Doku jetzt schon zum Insiderwissen ?