AVR Assembler - Tabelle im Programmspeicher

[Peter (Gast)]

Hallo,

ich habe eine Tabelle im Programmspeicher abgelegt und greife über lpm 
darauf zu. Über R16 steuere ich den Offset. In R17 steht dann der Wert:

clr r0
ldi r16, 0
ldi ZL, lo8(table)
ldi ZH, hi8(table)
add ZL, r16
adc ZH, r0          
lpm r17, Z

...
...

.section .progmem.data
.type table, @object
.size table, 8
table:
.byte  0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07

Im Netz habe ich nun gelesen, dass man die Addresse der Tabelle um eins 
nach links schieben muss, und im Bit 0 dann das Low oder High Byte 
auswählt.

Wie man oben sieht, mache ich das ja nicht. Der Code funktioniert aber 
trotzdem.

Ist das nun Zufall (kann ich kaum glauben)? Oder woran liegt das?

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

Danke und Gruß, Peter

[Marc V. (Firma: Vescomp) (logarithmus)]

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.

[Timm T. (Gast)]

Peter schrieb:
> Der Code funktioniert aber
> trotzdem.

Das glaube ich nicht.

Das muss so heissen:

ldi ZL, lo8(2 * table)
ldi ZH, hi8(2 * table)

Der Code liest zwar irgendwelche Bytes, aber nicht an der Stelle table, 
sondern irgendwo anders.

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

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:

   ldi ZH, high(table << 1)           ;
   ldi ZL, low(table << 1)            ;
´

[Patrick J. (ho-bit-hun-ter)]

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

[Stefan E. (sternst)]

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.

[Markus M. (Firma: EleLa - www.elela.de) (mmvisual)]

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

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

uint8_t getVal(uint8_t index)
{
  return table[index];
}

grinz

[Peter (Gast)]

Timm T. schrieb:
> Peter schrieb:
>> Der Code funktioniert aber
>> trotzdem.
>
> Das glaube ich nicht.

Ich kann mich nur wiederholen: Das geht so.

Stefan E. schrieb:
> 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".

Und das wäre auch eine passende Erklärung dafür.

Gruß Peter