AVR Assembler - Tabelle im Programmspeicher

Peter schrieb:
> Könnte es vlt. daran liegen, dass ich mit dem GCC arbeite, welcher mit
> der Libc mitkommt, und es sich da anders verhält?

 Ja.

 Adressen im Flash sind Wordadressen, im RAM sind es Byteadressen.
 In reinem Assembler würde dir das oben nicht durchgehen, bzw.
 die Flashadresse auf welche ZL:ZH zeigt, wäre um Faktor 2 kleiner.

Hängt von den Makros 'lo8' und hi8' ab. Die sind mir nicht bekannt, aber 
wenn man 'low' und 'high' benutzt, dann ist schieben angesagt:

1

   ldi ZH, high(table << 1)           ;

2

   ldi ZL, low(table << 1)            ;

3

´

Hi

Wir können wohl davon ausgehen, daß 'lo8' und 'hi8', wie bereits 
vermutet, Makros sind, Die sich um diese Anpassung 'Tabelle im 
Programmspeicher' kümmern.
Mit diesen Makros eine Tabelle im DSEG anzusprechen, dürfte dann 
fehlschlagen.

Wieder: nicht der komplette Code oder hi8/lo8 sind interne Makros dieses 
Assembler (gibt's ja nun auch die eine oder andere Variante von ...)

MfG

Patrick J. schrieb:
> Wir können wohl davon ausgehen, daß 'lo8' und 'hi8', wie bereits
> vermutet, Makros sind, Die sich um diese Anpassung 'Tabelle im
> Programmspeicher' kümmern.

Nicht wirklich.

Patrick J. schrieb:
> Mit diesen Makros eine Tabelle im DSEG anzusprechen, dürfte dann
> fehlschlagen.

Nein, auch das geht.

Der GCC, und damit auch der dazugehörige Assembler, arbeiten 
grundsätzlich Byte orientiert. Alle Label sind Byte-Adressen, egal ob 
Flash oder RAM. Datenzugriffe gehen daher "einfach so". Aber man braucht 
dann halt spezielle Vorkehrungen, wenn man die Wort-Adresse benötigt, 
z.B. für indirekte Sprünge oder Sprungtabellen.

Vielleicht sollte Peter doch ein wenig C-Code mit in sein Programm 
aufnehmen:

1

const uint8_t table[8] = {0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07};

2

3

uint8_t getVal(uint8_t index)

4

{

5

  return table[index];

6

}

grinz