Hallo,

eine Frage... was ist schneller, I²C Kommunikation mit Interrupt zu
steuern, oder eine while() Schleife einbauen, die den Interrupt-Flag
testet?

Danke!

Meistens der Interrupt. Da entfällt nämlich das Rumgepolle und
rumgespringe.

Busy-Wait ist fast immer zumindest ein paar Takte schneller als
Interrupt-Bearbeitung. Mit welcher affenartigen Geschwindigkeit läuft
bei Dir denn die Übertragung, wenn es auf die paar Takte ankommt?

Sven Pauli wrote:
> Meistens der Interrupt. Da entfällt nämlich das Rumgepolle und
> rumgespringe.
Nö, gerade nicht. Ein Interrupt beim AVR (da kein konkreter
Controllertyp genannt wurde, gehe ich mal von AVR aus...) hat allein
hardwaremäßig für Ein- und Rücksprung schon einen Bedarf von 8
CPU-Takten (PC sichern, Flag löschen und in Vektor springen und am Ende
das ganze retour, je 4 Takte), dazu kommt bei
Hochsprachen-Programmierung generell noch der Sprung aus der
Vektortabelle in die ISR (2 oder 3 Takte, je nach Flash-Größe) plus
Sichern und Rückschreiben von SREG (je 3 Takte). Das ist die
Minimal-Latenz, wenn der Compiler nicht noch andere Register sichern
muss. Ein einfaches Pollen ist da deutlich schneller...

Eine kleine Rechnung: Bei einer Übertragungsgeschwindigkeit von 400
kBit/s benötigt das Übertragen eines Bytes ca. 250 Mikrosekunden. Bei
einem angenommenen Processor-Takt von 10 MHz - wenn wesentlich
langsamer, dann macht nämlich TWI nicht mehr mit - sind das 2500
Processor-Clocks pro übertragenem Byte. Was soll diese
"Mikrometerschrauben-Optimierung" denn bringen?

meint
Bernhard

Danke! Warum dauert denn meine Übertragung von 64 Bytes von einem
Mikrocontroller zum anderen Mikrocontroller über TWI 140ms ???

Warum solange?

TWI läuft mit 300kHz. Ich benutze Atmega644 mit 16MHz Quarz.

> Ein Interrupt beim AVR (da kein konkreter Controllertyp genannt wurde,
> gehe ich mal von AVR aus...) hat allein hardwaremäßig für Ein- und
> Rücksprung schon einen Bedarf von 8 CPU-Takten (PC sichern, Flag
> löschen und in Vektor springen

Außerdem wird noch der aktuell ausgeführte Befehl fertiggemacht, bevor
das alles passiert. Je nach Typ braucht z.B. ein ret 4 oder 5
Taktzyklen. Falls man noch einen Sleepmodus benutzt, kommt noch die
Aufwachzeit plus ein paar Takte dazu.

> und am Ende das ganze retour, je 4 Takte), dazu kommt bei
> Hochsprachen-Programmierung generell noch der Sprung aus
> der Vektortabelle in die ISR (2 oder 3 Takte, je nach Flash-Größe)

Nicht nur bei Hochsprachen-Programmierung.

> plus Sichern und Rückschreiben von SREG (je 3 Takte).

Es sind je 5.

> Das ist die Minimal-Latenz, wenn der Compiler nicht noch andere
> Register sichern muss.

Das muß er aber eigentlich fast immer. Macht dann pro Register weitere 2
Zyklen jeweils für das Sichern und das Zurückschreiben.

@Bernhard R.

> Eine kleine Rechnung: Bei einer Übertragungsgeschwindigkeit von 400
> kBit/s benötigt das Übertragen eines Bytes ca. 250 Mikrosekunden.

Wie kommst du auf diesen Wert? Ich käme eher so ca. auf ein Zehntel
(ohne Adressierung).

>  Was soll diese "Mikrometerschrauben-Optimierung" denn bringen?

Vielleicht dachten hier manche an SPI, das man mit bis zu halbem
Prozessortakt betreiben kann. In dem Fall sähe es dann nämlich anders
aus.

Rolf Magnus wrote:
>> und am Ende das ganze retour, je 4 Takte), dazu kommt bei
>> Hochsprachen-Programmierung generell noch der Sprung aus
>> der Vektortabelle in die ISR (2 oder 3 Takte, je nach Flash-Größe)
>
> Nicht nur bei Hochsprachen-Programmierung.
In Assembler kann man aber, wenn es wirklich zeitkritisch ist und man
nur den einen Interrupt nutzt, den Handler direkt in die Vektortabelle
schreiben, was zumindest den Sprung (jmp oder rjmp) eliminiert und damit
2-3 Takte einspart. Aber das geht eben wirklich nur in diesem
Spezialfall. Und in einer Hochsprache geht es gar nicht, weil der
Compiler grundsätzlich die komplette Vektortabelle anlegt mit allem was
dazugehört. Und das meinte ich mit "... bei
Hochsprachen-Programmierung..."...

Man kann einen Interrupt Handler zwar auch in C als naked anlegen und
damit die ganze Registerpusherei und -Popperei rauswerfen, aber eben
auch nur dann, wenn man sich zu 100 % sicher ist, dass im Handler das
SREG und andere Register (Pointer...) nicht beeinflusst werden.

Hsus wrote:
> Danke! Warum dauert denn meine Übertragung von 64 Bytes von einem
> Mikrocontroller zum anderen Mikrocontroller über TWI 140ms ???
>
> Warum solange?
>
> TWI läuft mit 300kHz. Ich benutze Atmega644 mit 16MHz Quarz.
Tja, das muss eigentlich am Programm liegen, das Du bisher nicht gezeigt
hast. Mit den Parametern sollte das schneller gehen, wenn während der
Übertragung tatsächlich nix anderes gemacht wird.

@ Rolf Magnus: Natürlich! 25 us / Byte, nicht 250. Da hat mein
"Rechenschieber geeiert". Es verbleiben ca. 250 Clocks/Byte.

Für die Entscheidung Polling vs. Interrupt spielt auch folgendes eine
Rolle: Was bringt Parallelisierung? Läßt sich zwischendrin etwas
Vernünftiges tun? Und last not least: Was ist einfacher zu
implementieren (insbesondere zu testen)?

Bernhard