Noch mal zum Thema pollen oder Interrupt:
Ich habe mal einen kurzen Test gemacht, aus Bequemlichkeit auf einem Nano mit ATmega@16kHz. Ich gehe davon aus, dass ein ATtiny85@8kHz halb so schnell ist, solange keine besonderen Features des ATmega verwendet werden (Hardwaremultiplikation z.b.).
Für eine einzelne loop(), die nichts anderes macht als pollen per encoder.tick() aus der RotaryEncoder library, bräuchte der tiny85 demnach 0,004365 ms (gemessen Nano@16kHz: 873 ms für 100.000 loops). Dabei vernachlässige ich, dass es im Test zu gar keinen pin changes kommt, beim
Blick auf den Source code sieht man aber, dass da nichts Weltbewegendes passiert, aber nehmen wir mal an, ein pin change dauert 5 mal so lange in der Bearbeitung und nehmen im weiteren den worst case an, dass es jedes Mal zum pin change kommt, dann sind wir bei 0,021825 ms pro loop().
Nehmen wir für den Encoder mal eine max. Geschwindigkeit von 10 Runden pro Sekunde(!) an, kommt es bei 32 Segmenten mit je 4 Signalwechseln, also 128 pin changes pro Runde, alle 0,78125 ms zu einem pin change. Das ist ca. um den Faktor 36 langsamer, wird also noch ohne Probleme in der loop() sicher erkannt. Erst ab ca. 358 Runden pro Sekunde gäbe es Probleme bei den obigen pessimistischen Annahmen.
Natürlich kommen in beiden Fällen die I2C-Interrupts dazu. Aber die sollten in beiden Fällen zwischen zwei Pegelwechseln abgehandelt werden, was bei 100kHz I2C speed und einem Paket von 4 bytes bei großzügig kalkuliertem Overhead weniger als 0,0001 ms dauern sollte [Edit: s. Korrektur unten(*)]. Gefühlt würde ich sogar sagen, dass es besser ist, wenn hier eine klare Priorität vorherrscht, denn soweit ich das verstehe, ist die bei AVRs nicht ohne Weiteres gegeben, d.h. ohne besondere Maßnahmen könnten sich Zähl- und I2C-IR gegenseitig unterbrechen, was gefühlt eher ungut ist.
Wenn ich da nicht irgendwo grundfalsch liege (was gut sein kann), sollte es bei diesen Geschwindigkeiten praktisch egal sein, ob Interrupts oder polling genutzt werden, außer in Spezialfällen wie z.B. wenn es bei Batteriebetrieb auf den Verbrauch ankommt.
vg
Jan
(*) da bin ich gleich um 4 Stellen verrutscht, denn hier hatte ich von den kHz ausgehend in s gerechnet und dann noch falsch gerundet, richtig sind weniger als 1,0ms, was mich ehrlich gesagt überrascht, denn das würde dann den eigentlich limitierenden Faktor darstellen, also die Obergrenze für die Pulsfrequenz. Hmm.
