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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.