16Bit-(IO)Register - ja wie denn nun??

LotadaC

Sehr aktives Mitglied
22. Jan. 2009
3.547
70
48
Marwitz
Sprachen
  1. BascomAVR
  2. Assembler
Gerade im Datenblatt (42505D Seite 127) des Tiny102/104 drüber gestolpert:
Accessing the low byte triggers the 16-bit read or write operation: When the low byte of a 16-bit register is written by the CPU, the high byte that is currently stored in TEMP and the low byte being written are both copied into the 16-bit register in the same clock cycle. When the low byte of a 16-bit register is read by the CPU, the high byte of the 16-bit register is copied into the TEMP register in the same clock cycle as the low byte is read, and must be read subsequently.
Note: To perform a 16-bit write operation, the low byte must be written before the high byte. For a 16-bit
read, the low byte must be read before the high byte.
Das widerspricht sich doch, oder?

Im ersten Teil steht doch quasi, daß das jeweilige High-Register an ein temporäres Register gekoppelt ist, und der Zugriff auf das entsprechende Low-Register denselben Zugriff auf das High-Register auslöst.
Beim Beschreiben des Low-Registers wird zeitgleich der bestehende (vorher dahin geschriebene) Inhalt des temp-Registers ins High-Register geschrieben.
Beim Lesendes Low-Registers wird zeitgleich der Inhalt des High-Registers ins temp-Register übertragen, und kann folglich danach gelesen werden.

Warum soll dann (in der Note) das Low vor dem High beschrieben werden???
C&P-Fehler von X-Core-Datenblättern?
(Bei den X-Cores scheint immer(!) zuerst auf das Low-Register zugegriffen werden zu müssen beim schreiben und beim lesen)

(Beim Tiny4/5/9/10 und beim Tiny20 paßt die Note zur vorhergehenden Erläuterung)

Anmerkung: Dieser Schreib-/Lesemechanismus verhindert inkohärente 16Bit-Register die entstehen könnten, wenn das Modul selbst (also der Timer) sie während des Zugriffes (zwischen den beiden Zugriffen) ändert (also zB inkrementiert - insbesondere mit Überlauf zwischen Low- und Highbyte).
Er verhindert nicht, daß ein eventueller IRQ seinerseits Änderungen an irgendeinem 16bit-Register unter Verwendung des temp-Registers vornimmt, und dieses verändert.
Zur Unterdrückung solcher Fehler müßte in der ISR entweder der Inhalt des temp-Registers gesichert und wiederhergestellt werden, oder besser (und allgemein üblich) jeder 16bit-Zugriff vor IRQs geschützt werden (indem währenddessen IRQs global unterdrückt werden)
 
Das wird ein Fehler im Datenblatt sein.

So wäre es richtig ...

To perform a 16-bit write operation, the low byte must be written after high byte.
For a 16-bit read, the low byte must be read before the high byte.
 
Hatte ich auch spekuliert. Das Datenblatt ist von 2016, also recht aktuell. Insbesondere moderner als einige andere TPI-Tinies, bei denen es ja stimmt.

Bei den X-Cores scheint es hingegen so zu sein, daß immer zuerst auf das lowest Byte zuzugreifen ist. Beim schreiben und beim lesen.
 
Das Datenblatt ist von 2016, also recht aktuell.
So, mal'n bisschen in meinem Archiv gewühlt:
  • 42505A von 2/16 ist korrekt
  • 42505C von 7/16 ebenso (die B-Revision scheine ich nicht zu haben)
  • 42505D von 10/16 weist den genannten Fehler auf
Im Datasheet Revision History der D-Version:
• AVR CPU Core:
– New section added, Accessing 16-bit Registers.
Da haben sie wohl den Fehler eingebaut.
Was ist da eigentlich unter "New Section" zu verstehen? Vorher hieß es:
17.6. Accessing 16-bit Registers
(in der C-Version noch auf Seite 129)

:stupid:
 
Vermutlich ein Fehler, wie Dirk schon sagte. Aber kein C&P-Fehler.
Bei den Xmegas (und vermutlich auch bei allen anderen Xcores (hab nur bei einem nachgesehen)) sieht es so aus:
Accessing16bitRegisters.png
Die Note gibt es nur bei den älteren tinies und megas:
Note: To perform a 16-bit write operation, the high byte must be written before the low byte. For a 16-bit read, the low byte must be read before the high byte.
 
Bei den X-Cores steht das als Unterpunkt der AVR-CPU (genauer AVR-CPU -> Functional Description -> Accessing 16bit-Registers) - also eher global im Datenblatt.
Bei den non-X-Cores findet sich der Punkt bei jeder 16bit-Hardware (also bei jedem 16bit-Timer).
Bei den non-X-Cores ist ...
das jeweilige High-Register an ein temporäres Register gekoppelt ist, und der Zugriff auf das entsprechende Low-Register denselben Zugriff auf das High-Register auslöst.
Bei den X-Cores hingegen ist die Kopplung davon abhängig ob gelesen oder geschrieben wird. Deswegen ist hier immer zuerst auf das low-Byte zuzugreifen.
Und genau das sagt auch die (falsche) Note im D-Datenblatt des Tiny102/104 (ein non-X-Tiny):
Note: To perform a 16-bit write operation, the low byte must be written before the high byte. For a 16-bit read, the low byte must be read before the high Byte.
Bis zum C-Datenblatt des Tiny102/104 war es ja noch korrekt, irgendwer hat aus irgendeinem Grund zwischen Juli und Oktober 2016 genau zwei Sachen im entsprechenden Abschnitt geändert:
  • aus
    Note: To perform a 16-bit write operation, the high byte must be written before the low byte. For a 16-bit read, the low byte must be read before the high Byte
    wurde:
    Note: To perform a 16-bit write operation, the low byte must be written before the high byte. For a 16-bit read, the low byte must be read before the high Byte
    (Also einmal low und high getauscht)
  • Bei den Code-Examples wurde zweimal folgende Fußnote angefügt:
    Note:
    1. The example code assumes that the part specific header file is included. For I/O Registers located in extended I/O map, “IN”, “OUT”, “SBIS”, “SBIC”, “CBI”, and “SBI” instructions must be replaced with instructions that allow access to extended I/O. Typically “LDS” and “STS” combined with “SBRS”, “SBRC”, “SBR”, and “CBR”.
Der gesamte Rest von Abschnitt 17.6. ist Wort für Wort identisch geblieben.
In den Code-Examples wird übrigens die korrekte Reihenfolge eingehalten.

Die Note gibt es nur bei den älteren tinies und megas:
Damit meinst Du alle non-X-Cores?
2016 ist ja noch nicht so lange her
 
Zuletzt bearbeitet:
Damit meinst Du alle non-X-Cores?
Ja, aber natürlich nur die knapp ein Dutzend, deren Datenblätter ich mir vor 2016 genauer angesehen hatte.
Hatte mich mal interessiert, was die so können, habe mich aber vorwiegend mit Xmegas beschäftigt.
Bis zum C-Datenblatt des Tiny102/104 war es ja noch korrekt, irgendwer hat aus irgendeinem Grund zwischen Juli und Oktober 2016 genau zwei Sachen im entsprechenden Abschnitt geändert:
Da hat wohl jemand 'n Praktikanten rangesetzt, der noch keine Ahnung hatte... ;)
 
Ich häng mal noch was dran, betrifft allerdings den Analog Comperator…
Bei den Features findet man:
• Flexible Input Selection:
– Internal Voltage Reference
Two Pins Selectable for Positive or Negative Inputs
Bei der Erklärung des Blockdiagrammes ferner:
The Power Reduction ADC bit in the Power Reduction Register (PRR.PRADC) must be written to '0' in order to be able to use the ADC input MUX.
Sinngemäß steht beim Power Reduction Register (PRR) dasselbe:
Bit 1 – PRADC: Power Reduction ADC
Writing a logic one to this bit shuts down the ADC. The ADC must be disabled before shut down. The analog comparator cannot use the ADC input MUX when the ADC is shut down.
Ok, soweit sogut. Man kann ja bei diversen Controllern statt eines festen Ain-Pins den Ausgang des ADC-Muliplexers auf den negativen AC-Eingang schalten. Aber da findet sich dann üblicherweise auch irgendwas zum Auswählen dieses Einganges - ein Analog Comperator Multiplexer Enable - bit (ACME) zB (da muß(!) dann übrigens der ADC abgeschaltet sein (ADEN)).

Beim Tiny102/104 finde ich weder ein ACME, noch irgendeinen Analog Comperator Negative Input Multiplexer (bereits im Blockdiagramm ist nur der positive "Multiplexer" mit der Bandgap vorhanden) - nur eben die genannten Andeutungen WANN ADMUX als AC-Eingang genutzt werden könnte oder nicht... aber eben nicht WIE...

P.S. @Mikro23 : bevor Du jetzt nochmal mit dem "Stift" kommst - das ist bereits in den älteren Versionen so

Edit: Bei der Conversion Time des ADC (Seite 172) gibt's auch noch diese Fußnote:
Note:
1. When gain amplifier is active, also includes the first conversion after a change in channel, reference or gain Setting.
Öhm... der hat doch gar keinen...
 
Zuletzt bearbeitet:

Über uns

  • Makerconnect ist ein Forum, welches wir ausschließlich für einen Gedankenaustausch und als Diskussionsplattform für Interessierte bereitstellen, welche sich privat, durch das Studium oder beruflich mit Mikrocontroller- und Kleinstrechnersystemen beschäftigen wollen oder müssen ;-)
  • Dirk
  • Du bist noch kein Mitglied in unserer freundlichen Community? Werde Teil von uns und registriere dich in unserem Forum.
  •  Registriere dich

User Menu

 Kaffeezeit

  • Wir arbeiten hart daran sicherzustellen, dass unser Forum permanent online und schnell erreichbar ist, unsere Forensoftware auf dem aktuellsten Stand ist und der Server regelmäßig gewartet wird. Auch die Themen Datensicherheit und Datenschutz sind uns wichtig und hier sind wir auch ständig aktiv. Alles in allem, sorgen wir uns darum, dass alles Drumherum stimmt :-)

    Dir gefällt das Forum und unsere Arbeit und du möchtest uns unterstützen? Unterstütze uns durch deine Premium-Mitgliedschaft!
    Wir freuen uns auch über eine Spende für unsere Kaffeekasse :-)
    Vielen Dank! :ciao:


     Spende uns! (Paypal)