Warum nur 8 MIPS bei 16 MHz Systemtakt?

[Vincent R. (vinc)]

Hallo zusammen!

Auf einem ATmega644P habe ich zu Testzwecken eine Dauerschleife laufen 
lassen, die nur PD6 umschaltet, sonst nichts.
Es ist ein 16 Mhz Quarz angeschlossen und die Fuses entsprechend 
programmiert:
LFUSE: 0x0F7 (0xFF ändert nichts)
HFUSE: 0xD9
EFUSE: 0xFF

#include <avr/io.h>

int main(void) {

  DDRA = 0x00;
  DDRB = 0xff;
  DDRC = 0xff;
  DDRD = (1 << DDD1) | (1 << DDD5) | (1 << DDD6) | (1 << DDD7);

  while(1) {

    PORTD |= (1 << PD6);
    PORTD &= ~(1 << PD6);

    PORTD |= (1 << PD6);
    PORTD &= ~(1 << PD6);

    PORTD |= (1 << PD6);
    PORTD &= ~(1 << PD6);

  }

  return 0;
}

Mit dem Oszi habe ich an PD6 gemessen (gelb) und gleichzeitig den 
Systemtakt an XTAL2 (blau).
Wie am Zeitcursor erkennbar, wird der Pin nach rund 125 ns umgeschaltet, 
was einer Freuquenz von 8 MHz entspricht.
Nun frage ich mich, warum der Controller für so eine leichte Aufgabe 
zwei Takte benötigt und nicht bloß einen.
Ist es möglich, dass er aus irgendwelchen Gründen nur mit 8 MHz taktet 
oder braucht er wirklich zwei Takte dafür?

Grüße,
Vinc

[Joachim .. (joachim_01)]

Haste mal den Asm-Code angekuckt? Vielleicht schiebt der Compiler ein 
NOP() ein.

[Assembler (Gast)]

Guck dir doch mal das Assembler-Listing an.

[(prx) A. K. (prx)]

Die Bit Set/Reset Befehle benötigen 2 Takte.

[Joachim .. (joachim_01)]

Moment mal. Du schreibst:
 PORTD &= ~(1 << PD6);
Ich vermute mal, daß das nicht einfach dem Komplementär-Befehl 
entspricht.

Bei den PICs gibts da ein:
PORTDbits.PD7 ^= 1;
Vieleicht bietet er gcc etwas ähnliches an.

[Joachim .. (joachim_01)]

prx war schneller ;-)

[RTFM (Gast)]

SBI und CBI brauchen auf dem ATMega 2 Takte (im Gegensatz zum ATTiny und 
XMega):
http://www.atmel.com/images/doc0856.pdf
Seite 14 und Fußnote 5 auf Seite 15

Die OUT instruction braucht dagegen auch auf dem ATMega nur 1 Takt, 
allerdings müssen vorher die Bits für den kompletten Port in einem 
Register liegen.

Folgender asm-code müsste also 4 MHz auf PD6 ausgeben (mit Verzögerungen 
für den rjmp nach jeweils 5 Perioden):

ldi r16, (1<<PD6)
ldi r17, 0
loop:
out PORTD, r16
out PORTD, r17
out PORTD, r16
out PORTD, r17
out PORTD, r16
out PORTD, r17
out PORTD, r16
out PORTD, r17
out PORTD, r16
out PORTD, r17
rjmp loop

Auf dem Mega644 müsste auch das Toggeln über schreiben ins PIN-Register 
funktionieren:

ldi r16, (1<<PD6)
loop:
out PIND, r16
out PIND, r16
out PIND, r16
out PIND, r16
out PIND, r16
out PIND, r16
out PIND, r16
out PIND, r16
out PIND, r16
out PIND, r16
rjmp loop

[Thomas E. (thomase)]

Joachim ... schrieb:
> Moment mal. Du schreibst:
>  PORTD &= ~(1 << PD6);
> Ich vermute mal, daß das nicht einfach dem Komplementär-Befehl
> entspricht.
>
> Bei den PICs gibts da ein:
> PORTDbits.PD7 ^= 1;
> Vieleicht bietet er gcc etwas ähnliches an.
Das ist nicht PIC. Das ist C.

PORTD ^= 1; führt beim AVR und beim PIC wahrscheinlch auch, aber zu 
einem Read-Modify-Write, was wesentlich länger dauert als der eine 
sbi/cbi.

Also das:
PORTD |= (1 << PD6);
PORTD &= ~(1 << PD6);
ist effektiver.

Beim AVR gibt es aber noch PINx |= 1; Da wird wieder der sbi eingesetzt.
Damit ist Toggle-Toggle zeitlich das gleiche wie Setzen-Löschen.

mfg.

[c-hater (Gast)]

RTFM schrieb:

> SBI und CBI brauchen auf dem ATMega 2 Takte (im Gegensatz zum ATTiny und
> XMega):

Das verstehst du falsch, jedenfalls was die ATtinys betrifft. Da steht: 
"reduced core tinyAVR". Das sind nur die ganz, ganz kleinen (4,5,9,10).

Ab Tiny11 aufwärts kostet SBI/CBI 2 Takte.

[(prx) A. K. (prx)]

Thomas Eckmann schrieb:
> PORTD ^= 1; führt beim AVR und beim PIC wahrscheinlch auch, aber zu
> einem Read-Modify-Write, was wesentlich länger dauert als der eine
> sbi/cbi.

PICs können XOR zum Port hin. Das ist also 1 Befehl, wenn die Maske 
schon im Akku ist.

[Thomas E. (thomase)]

A. K. schrieb:
> Thomas Eckmann schrieb:
>> PORTD ^= 1; führt beim AVR und beim PIC wahrscheinlch auch, aber zu
>> einem Read-Modify-Write, was wesentlich länger dauert als der eine
>> sbi/cbi.
>
> Nope. PICs können XOR zum Port hin.
Nicht schlecht.

mfg.

[Thomas E. (thomase)]

A. K. schrieb:
> Thomas Eckmann schrieb:
>> PORTD ^= 1; führt beim AVR und beim PIC wahrscheinlch auch, aber zu
>> einem Read-Modify-Write, was wesentlich länger dauert als der eine
>> sbi/cbi.
>
> PICs können XOR zum Port hin. Das ist also 1 Befehl, wenn die Maske
> schon im Akku ist.
Wieso im Akku?
XORLW ist doch mit immediate.

mfg.

[(prx) A. K. (prx)]

Thomas Eckmann schrieb:
> XORLW ist doch mit immediate.

Du willst nicht das Bit im Akku (W) toggeln, sondern im Port (f). Und 
dafür brauchst du XORWF, nicht XORLW: 
http://www.sprut.de/electronic/pic/assemble/befehle.html#xorwf

[Thomas E. (thomase)]

A. K. schrieb:
> Thomas Eckmann schrieb:
>> XORLW ist doch mit immediate.
>
> Du willst nicht das Bit im Akku (W) toggeln, sondern im Port (f). Und
> dafür brauchst du XORWF, nicht XORLW:
> http://www.sprut.de/electronic/pic/assemble/befehle.html#xorwf
Kann ja keiner ahnen, daß W der Akku ist.

> Daumenregel: In einen PIC Befehl fester Länge passt entweder eine
> Konstante oder eine Adresse. Aber i.d.R. nicht beides.
Ja. Ist logisch.

mfg.

[Markus W. (Firma: guloshop.de) (m-w)]

Thomas Eckmann schrieb:
> A. K. schrieb:
>> Nope. PICs können XOR zum Port hin.
> Nicht schlecht.

Das bringt mich auf die Frage, warum Vinc nicht einfach die 
Port-Toggle-Funktion verwendet:

PIND|= 1<<PD6

Hab jetzt nicht speziell im Datenblatt des ATmega644P geschaut, aber der 
sollte das eigentlich auch können.

[Thomas E. (thomase)]

Markus Weber schrieb:
> Thomas Eckmann schrieb:
>> A. K. schrieb:
>>> Nope. PICs können XOR zum Port hin.
>> Nicht schlecht.
>
> Das bringt mich auf die Frage, warum Vinc nicht einfach die
> Port-Toggle-Funktion verwendet:
>
>

PIND|= 1<<PD6

>
> Hab jetzt nicht speziell im Datenblatt des ATmega644P geschaut, aber der
> sollte das eigentlich auch können.

Kann er auch. Aber zeitlich bringt das nichts.
Um das gleiche zu erreichen, muss

PIND|= 1<<PD6

ja zweimal ausgeführt werden.

mfg.

[egal² (Gast)]

Thomas Eckmann schrieb:
> Kann ja keiner ahnen, daß W der Akku ist.

Ähhh... doch!

[Thomas E. (thomase)]

egal² schrieb:
> Thomas Eckmann schrieb:
>> Kann ja keiner ahnen, daß W der Akku ist.
>
> Ähhh... doch!

Mir doch egal².

mfg.

[(prx) A. K. (prx)]

Markus Weber schrieb:
> Das bringt mich auf die Frage, warum Vinc nicht einfach die
> Port-Toggle-Funktion verwendet:

Soweit ich das verstanden habe, ging es ihm nicht darum, ein 8MHz Signal 
zu produzieren. Sondern um eine Erklärung für die 4MHz. Und die hat er. 
Fall abgeschlossen.

[Joachim .. (joachim_01)]

>>Das ist nicht PIC. Das ist C.
>PORTD ^= 1; führt beim AVR und beim PIC wahrscheinlch auch, aber zu
einem Read-Modify-Write, was wesentlich länger dauert als der eine
sbi/cbi.

Hmmmm...also ich bekomme auf einem 18F458 mit C18 das hier:

112:    LEDPin ^= 1;
28AC  7E8C     BTG LATD, 7, ACCESS

BTG ist:
BTG f, d, a Bit Toggle f 1 0111 bbba ffff ffff

Und er braucht dazu einen Takt.

[Markus W. (Firma: guloshop.de) (m-w)]

Thomas Eckmann schrieb:
> Markus Weber schrieb:
>> Das bringt mich auf die Frage, warum Vinc nicht einfach die
>> Port-Toggle-Funktion verwendet:
>>
>>

PIND|= 1<<PD6

>>
>> Hab jetzt nicht speziell im Datenblatt des ATmega644P geschaut, aber der
>> sollte das eigentlich auch können.
>
> Kann er auch. Aber zeitlich bringt das nichts.
> Um das gleiche zu erreichen, muss
>

PIND|= 1<<PD6

> ja zweimal ausgeführt werden.

Sorry, Tippfehler von mir, ich meinte:

PIND= 1<<PD6;

Das ist dann nur ein Takt.

[(prx) A. K. (prx)]

Joachim ... schrieb:
> Hmmmm...also ich bekomme auf einem 18F458 mit C18 das hier:

Oder so, gibts aber erst im PIC18.

> Und er braucht dazu einen Takt.

Sagen wir mal einen Befehlszyklus. Was 4 Takte sind.

[Thomas E. (thomase)]

Markus Weber schrieb:
>

PIND= 1<<PD6;

>
> Das ist dann nur ein Takt.
Ja. Das ist das gleiche wie die Assemblerversion weiter oben.
Das kann der C-Compiler natürlich auch.

mfg.

[Daniel F. (df311)]

.include "m8def.inc" ; durch passendes config-file ersetzen

ldi r16, 0x01
out DDRD, r16

loop: 
clr PORTD
ser PORTD

rjmp loop

eine taktmessung (einfach nur einen pin togglen) würde ich eher in ASM 
schreiben - und clr/ser brauchen laut meinem instructionset-ausdruck nur 
jeweils 1 takt. alternativ könnte man ein clr nach die initialisierung 
packen und in der schleife nur mehr com ausführen.

hier sinds 3 takte pro schleifendurchlauf, der overhead kann durch 
mehrfaches clr/ser einfach reduziert werden...

ok, ich habs auswendig geschrieben und mangels eines 644 auch nicht 
getestet, aber das prinzip sollte klar sein ;-)

[Markus W. (Firma: guloshop.de) (m-w)]

Daniel F. schrieb:
>

> loop:
> clr PORTD
> ser PORTD
>

Ich meine, clr geht nur für r0 bis r31, nicht aber für I/O-Register.

Thomas Eckmann:

Du hast natürlich Recht, ich hatte den Beitrag von RTFM nicht bis zum 
Ende gelesen.

[Vincent R. (vinc)]

Wow, das geht ja schnell hier :)

Wie es scheint, ist mit den zwei Takten pro Befehl in diesem Fall ja 
alles in Ordnung.
Ich wollte auch keinen Taktgenerator bauen, sondern einfach nur checken, 
ob der Controller mit dem richtigen Takt läuft.

Danke für die kompetenten Antworten!