Problem ATMEGA32 & IJMP

Stefan Gast #2231900
Lesenswert?
• ▲
▼ 
Hi,

ich hhabeein Problem in einem Projekt mit einem MEGA32 und AVRStudio 
4.18, das mich etwas stutzig erscheinen lässt. Ich fahre per IJMP 
indiziert eine Tabelle mit 255 Einträgen an, was seither klaglos 
funktioniert hat, ach der Standardmethode

1
ldi zl,low(sprungtabelle)

2
ldi zh,high(sprungtabelle)

3
add zl,index

4
ldi temp,0

5
adc zh,temp

6
ijmp


Der Code ist dann inzwischen reichlich angewachsen (>14k); indem ich 
etliche rcall-Sprünge innerhalb der aschlußendlich ngesprungenen 
Subroutinen durch Makros ersetzt habe.

Nun konnten die Einträge in der Sprungtabelle per rjmp irgendwann nicht 
mehr erreicht werden; somit wollte ich stattdesen "jmp" in der 
Sprungtabelle verwenden. Seither wird grundsätzlich der falsche 
Tabelleneintrag angesprungen, quasi um Dezimal 81 nach hinten 
verschoben. Vor Erweiterung des Codes habe ich alle 255 Tabelleneinträge 
einwandfrei anfahren können.

Kann das dadurch bedingt sein, das der Compiler die Makros nicht richtig 
berücksichtigt? Oder liegt es an den JMPs? Auch die andere Lösung des 
Anfahrens der Sprungtabelle per lpm un einer Sprungtabelle mit 
".dw"-Einträgen arbeitet nicht korrekt; auch die Position der 
Sprungtabelle im Code ist irrelevant

Viele Grüsse
Stefan
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Stefan Gast #2231916
Lesenswert?
• ▲
▼ 
...was dann aber zur Folge hat, das auch der Index selbst mit zwei 
aufmultipliziert werden muß und somit pro Tabelle auf 127 Einträge 
beschrönkt ist. Was sich zwar regeln lässt, aber was mich verwundert 
ist, das man sagt, das der Flash auf die Art und Weise immer 
wordadressiert werden -muß-, es aber bis zu einer bestimmten Codegröße 
scheinbar byteadressiert funktioniert hat.

Seltsam. Muß ich halt zwei Sprungtabellen machen.

Danke & Gruß
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Stefan Gast #2231926
Lesenswert?
• ▲
▼ 
Hm, komischerweise doch nicht. Das zerhacken in zwei Sprungtabellen 
hilft, aber sprungtabelle*2 nehmen führt wieder ins Nirwana. Alte 
Methode und prüfen des Index > 127,  und bei erfüllter Bedingung Abzug 
von $7F vom Index und danach anspringen der zweiten Sprungtabelle 
funktioniert, dabei jeweils den Index per lsl aufmultiplizeren.

Vielleicht trifft die Regel "*2" nicht auf jeden Compiler zu.

Gruß
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Stefan Gast #2231948
Lesenswert?
• ▲
▼ 
Ja, die Sache ist, das ich mittlerweile -komforthalber- eigentlich mehr 
unter BasCom programmiere und nur noch bei zeitkritischen Aufgaben 
Assembler heranziehe; da bekommt man viele Dinge einfach tatsächlich 
nicht mehr mit oder schaltet Assembler im Kopf "halb ab".

Gruß
Stefan
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren