Hi,
Wie Euch allen klar sein sollte, benötigen die 16bit-Timer für den Zähler, die Output Compare Register und das etwaige Input Capture Register je 2 Bytes. Um inkohärente Ergebnisse beim auslesen bzw falsche Compare Events beim schreiben (oder falsche Überläufe beim schreiben des Zählers) zu vermeiden besitzen diese 16bit-Register einen Synchronisationsmechanismus. Es existiert (je 16bit-Timer?) ein(!) Pufferregister, in welches beim auslesen eines low-Registers gleichzeitig der Inhalt des dazugehörenden high-Registers kopiert wird, bzw dessen Inhalt beim beschreiben eines low-Registers in das dazugehörende high-Register kopiert wird.
Daraus leitet sich die "Faustregel" ab, beim schreiben erst das high-Register zu beschreiben (genauer: den Wert im Puffer zu parken), und danach das low-Register (und damit beide synchron) zu beschreiben. Und beim lesen eben erst das low-Register zu lesen (wodurch das high-Register automatisch im Puffer landet), und danach den Wert des high-Registers aus dem Puffer zu lesen.
Soweit ist das nichts neues.
Beim Tiny10 sind das dann folgende Adressen:
Warum nun eigentlich diese 4 Adressen? Nach der obigen Erklärung ist es schlichtweg egal, in welches der 4 high-Register man den Wert schreiben läßt. Er landet so oder so oder so oder so im selben Puffer, und wird dann durch schreiben des low-Register zu dessen(!) high-Register geschrieben. Und beim auslesen dieser 4 Adressen liest man denselben Puffer aus, darin steht halt immer die Kopie des high-Bytes, dessen korrespondierendes low-Byte zuletzt ausgelesen wurde.
Ich habe versucht, das im Simulator des Studios (6.1.2730) nachzuvollziehen, beim schreiben paßt das, aber beim lesen ist das nach dem Simulator nicht so (konkret habe ich TCNT0L auslesen lassen, und danach OCR0AH, was auch genau so erscheint - ich hätte aber die Werte von TCNT0L/H erwartet)
Liege ich jetzt irgendwo falsch, oder ist das ein (weiterer) Simulatorbug?
Hmm... vielleicht mal real die Veränderungen über die serielle ausgeben lassen, mit echter Hardware...?
Und wie ist das bei ICs mit mehreren 16bit-Timern? Haben die dann einen gemeinsamen Buffer, oder jeder Timer einen eigenen?
Wie Euch allen klar sein sollte, benötigen die 16bit-Timer für den Zähler, die Output Compare Register und das etwaige Input Capture Register je 2 Bytes. Um inkohärente Ergebnisse beim auslesen bzw falsche Compare Events beim schreiben (oder falsche Überläufe beim schreiben des Zählers) zu vermeiden besitzen diese 16bit-Register einen Synchronisationsmechanismus. Es existiert (je 16bit-Timer?) ein(!) Pufferregister, in welches beim auslesen eines low-Registers gleichzeitig der Inhalt des dazugehörenden high-Registers kopiert wird, bzw dessen Inhalt beim beschreiben eines low-Registers in das dazugehörende high-Register kopiert wird.
Daraus leitet sich die "Faustregel" ab, beim schreiben erst das high-Register zu beschreiben (genauer: den Wert im Puffer zu parken), und danach das low-Register (und damit beide synchron) zu beschreiben. Und beim lesen eben erst das low-Register zu lesen (wodurch das high-Register automatisch im Puffer landet), und danach den Wert des high-Registers aus dem Puffer zu lesen.
Soweit ist das nichts neues.
Beim Tiny10 sind das dann folgende Adressen:
- TCNT0H = 0x29
- OCR0AH = 0x27
- OCR0BH = 0x25
- ICR0H = 0x23
Warum nun eigentlich diese 4 Adressen? Nach der obigen Erklärung ist es schlichtweg egal, in welches der 4 high-Register man den Wert schreiben läßt. Er landet so oder so oder so oder so im selben Puffer, und wird dann durch schreiben des low-Register zu dessen(!) high-Register geschrieben. Und beim auslesen dieser 4 Adressen liest man denselben Puffer aus, darin steht halt immer die Kopie des high-Bytes, dessen korrespondierendes low-Byte zuletzt ausgelesen wurde.
Ich habe versucht, das im Simulator des Studios (6.1.2730) nachzuvollziehen, beim schreiben paßt das, aber beim lesen ist das nach dem Simulator nicht so (konkret habe ich TCNT0L auslesen lassen, und danach OCR0AH, was auch genau so erscheint - ich hätte aber die Werte von TCNT0L/H erwartet)
Liege ich jetzt irgendwo falsch, oder ist das ein (weiterer) Simulatorbug?
Hmm... vielleicht mal real die Veränderungen über die serielle ausgeben lassen, mit echter Hardware...?
Und wie ist das bei ICs mit mehreren 16bit-Timern? Haben die dann einen gemeinsamen Buffer, oder jeder Timer einen eigenen?