ATmega644: warum +1 Takt bei einigen Sprungbefehlen ?

[Frank (Gast)]

Hallo,

im Datenblatt zum ATmega644 wird für die Befehle RCALL, ICALL, CALL, RET 
und IRET jeweils ein Taktzyklus mehr als z.B. beim ATmega88 angegeben. 
Bei einem Programmspeicher von mehr als 64k wäre das nachvollziehbar, 
aber der 644 hat nicht mehr als 64k. Hat jemand eine Idee, warum das 
trotzdem so ist?

Frank

[spess53 (Gast)]

Hi

Das hat nicht direkt mit dem Flash sondern mit dem Program-Counter 
(16/22Bit) zu tun. Steht alles im Instuction Set oder AVR-Studio Hilfe 
nachzulesen.

MfG Spess

[Frank (Gast)]

Hi Spess,

sorry, dann war meine Frage nicht klar genug formuliert: Das mit den 
unterschiedlichen Zeiten bei 16/22 Bit PC hatte ich gelesen, aber wozu 
benötigt man einen 22 Bit Program Counter in einem Controller, der nur 
64k Flash zur Verfügung hat?

Frank

[Benedikt K. (benedikt)]

Laut Datenblatt hat er nur 16bit:

The ATmega644 Program Counter (PC) is 15/16 bits wide, thus addressing 
the 32/64K program memory locations.

[Andreas K. (a-k)]

Braucht er diese +1 wirklich oder behauptet das nur die Doku ?

[sascha (Gast)]

Hallo,

probiers doch mal mit dem Simulator im AVRStudio aus.

Sascha

[Kachel-Heinz (Gast)]

Naja, der Sim ist auch nur in Software, seine Aussagekraft in dieser 
Frage dürfte gegen 0 gehen. Wenn schon ausprobieren, dann in der 
Hardware, z.B. mit Testprogramm und externem langsamen Takt (zum 
Mitzählen). Aber wen interessiert das nun wirklich?

KH

[ikorb (Gast)]

Sowas interessiert die Leute die Code schreiben der so timingkritisch 
ist, dass er durch diese zusätzlichen Taktzyklen das benötigte Timing 
nicht einhält.

Ich tippe auf einen Fehler im Datenblatt, da ich einen Codeschnipsel 
habe der auf ATmega32 und ATmega644 ohne Änderungen funktioniert und in 
der innersten Schleife einen rcall macht. Würde der auf dem 644 wirklich 
einen Takt länger brauchen als auf dem 32 dann wäre die Abweichung so 
gross, dass die Empfängerseite am Ende eines Blocks die falschen Bits 
samplen würde.

[Kachel-Heinz (Gast)]

> Sowas interessiert die Leute die Code schreiben der so timingkritisch
> ist, dass er durch diese zusätzlichen Taktzyklen das benötigte Timing
> nicht einhält.

Ich weiß, mich brauchst Du davon nicht überzeugen, ich mag auch 
effiziente Routinen. Ich habe mich auch etwas geärgert, dass man beim 
Mega48 (und Co) einige oft benutzte I/Os in den Extendet-I/O-Bereich 
verbannt hat und die Zugriffe darauf länger dauern. Meine Aussage sollte 
eigentlich eine Provokation sein, mit dem Ziel, dass mir widersprochen 
wird.

Ich halte das übrigens auch für einen Datenblatt-Fehler, wobei es mich 
momentan nicht soooo sehr interessiert, da ich mehr mit den kleineren 
AVRs werkele.

KH

[Rudolph R. (rudolph)]

MirdochegalderCompilerweissschonweissermachensoll. :-)

[nixversteh (Gast)]

??
WasmachtderCompilergleichnochmalweisser? grins

[Frank (Gast)]

Danke für Eure Antworten. Deutet also im Moment alles auf ein 
copy-n-paste Problem beim Erstellen des Datenblatts hin. Wäre ja auch 
nicht das erste Mal bei Atmel.

Frank