Warum befinden sich logisch verwandte Bitfelder in MCU-Registern häufig an verschiedenen Orten?

9

Verzeihen Sie mir, wenn diese Frage bereits beantwortet wurde, ich jedoch weder auf dieser Seite noch im Internet eine Antwort finden konnte.

Ich bin ein erfahrener Entwickler mit anständigen Kenntnissen in Bezug auf Low-Level-Programmierung, aber relativ neu in der Embedded-Entwicklung. Ich habe mir selbst die Entwicklung eingebetteter Systeme mit einer ST-NUCLEO144-Karte beigebracht, die über eine STM32F746ZG-MCU verfügt. Eine Frage, die mir nicht offensichtlich erscheint, ist, warum sich logisch verwandte Bitfelder in einem Register an verschiedenen Stellen befinden können.

Ein Beispiel ist das USART_CR1Register am STM32746ZG. Die Felder M0und M1bit steuern zusammen die Wortlänge in USART TX / RX, ein kombinierter 2-Bit-Wert von 0b00spezifiziert 8-Bit, 0b01spezifiziert 9-Bit usw. Dies ist alles ziemlich einfach, außer dass M0es sich um Bit 12 und M1Bit handelt 28 ... warum ist das so?

Ist dies aus Gründen des Legacy-Designs der Fall, z. B. wurde eine neue Funktion in einen zuvor reservierten Bereich eingefügt? Ist es aus Gründen im Zusammenhang mit dem Chipdesign, die ich nicht in Betracht ziehe, oder gibt es einen größeren Zweck, den ich nicht sehe?

Natürlich ist dies mit Bitmaskierung ziemlich trivial zu überwinden, aber ich bin nur neugierig.

microcontroller stm32 embedded

— ajxs
quelle

1

Bei UART handelt es sich speziell um eine sehr alte Technologie, weshalb der Grund fast immer die Abwärtskompatibilität ist. Der gleiche Grund, warum UART-Register-Bitfelder oft beschissene Namen haben, die überall zu Namespace-Kollisionen führen.

— Lundin

13

Ist dies aus Gründen des Legacy-Designs der Fall, z. B. wurde eine neue Funktion in einen zuvor reservierten Bereich eingefügt?

In diesem speziellen Fall (und in ähnlichen Fällen, die ich gesehen habe) ist dies der Fall, um die Abwärtskompatibilität mit älteren Geräten zu gewährleisten und Änderungen am (möglicherweise gut getesteten und qualifizierten / zertifizierten) Code zu minimieren, der bereits für diese älteren Geräte geschrieben wurde . Neue Merkmale und Funktionen (für die Steuerung und Konfiguration sind neue Registerbits erforderlich) müssen daher nicht zusammenhängende Bits verwenden, wenn die zu den ursprünglichen Registerbits benachbarten Bits bereits verwendet werden.

Hier ist zum Beispiel das USART_CR1Register der alten STM32F1xx-Familie.

Abbildung 1. Verwendung des Registers STM32F10xxx USART_CR1

_{Bildquelle: Referenzhandbuch zur STM32F10xxx-Familie RM0008, Abschnitt 27.6.4}

Dieser ältere USART (mit nur 2 Wortlängenoptionen) benötigt nur ein MBit, um die USART-Wortlänge zwischen den beiden Optionen zu konfigurieren, und das ist Bit 12. Beachten Sie, wie die Bits 11 und 13 ebenfalls verwendet werden und daher für zukünftige "Erweiterungen" nicht verfügbar sind. .

Wie Sie sagten, auf der neuere STM32F7 (und beispielsweise auch die STM32F4) nun die USART hat 3 Wortlänge Optionen (7, 8 und 9 Bits) und so eine andere Konfiguration Bit benötigt - Bit 12 ist M0, mit der M1jetzt in Bit 28 (zuvor in der STM32F1-Registerkarte reserviert, wie Sie oben sehen).

Abbildung 2. Verwendung des Registers STM32F74xxx USART_CR1

_{Bildquelle: Referenzhandbuch für die Familien STM32F75xxx und STM32F74xxx RM0385, Abschnitt 31.8.1}

Sie konnten das neue M1Bit nicht in die Registerbits 11 oder 13 einfügen, ohne die bereits für andere Funktionen verwendeten Registerbits zu verschieben und so die Abwärtskompatibilität mit dem vorhandenen Code (z. B. für den STM32F1) zu beseitigen, der sie verwendet hat.

Deshalb haben sie versucht, eine gewisse Abwärtskompatibilität beizubehalten, was dazu führt, dass an unerwarteten Stellen neue Registerbits hinzugefügt werden.

Ein weiteres Beispiel war die Aufrechterhaltung der Registerzuordnung für eigenständige UARTs von 8250 bis 16550, wobei an anderer Stelle in der Registerzuordnung neue Register hinzugefügt wurden.

— SamGibson
quelle

1

Vielen Dank, dass Sie sich die Zeit genommen haben, darauf hinzuweisen. Vielleicht hätte ich das alte Referenzmaterial der F-Familie überprüfen sollen, bevor ich gefragt habe. Ich dachte, die Geschichte könnte mehr beinhalten.

— Ajxs

1

@ajxs - Gern geschehen. Ich kann nur aus meinen Erfahrungen sprechen (diese alten UARTS waren ein weiteres gutes Beispiel). Es ist immer möglich, dass jemand anderes andere relevante Erfahrungen hat, und es kann sein, dass er nicht die Zeit damit verbringt, eine Antwort zu schreiben, wenn die Frage bereits eine akzeptierte Antwort hat. Sie könnten also meine Antwort immer "inakzeptieren", einen Tag warten (sagen), bis jemand anderes aus verschiedenen Perspektiven antwortet, und sehen, ob Sie das Gefühl haben, dass er die Frage besser beantwortet als meine? Wenn nicht, können Sie meine jederzeit wieder akzeptieren :-) Ich möchte nur nicht, dass Sie andere potenzielle Antwortperspektiven verlieren.

— SamGibson

2

Das scheint vernünftig, ich nehme Ihren Rat an! Vielen Dank, dass Sie so höflich sind, den Vorschlag zu machen. Wenn morgen keine bessere Antwort eingeht, werde ich Ihre akzeptieren. Danke noch einmal.

— Ajxs

5

Sie haben Recht mit

"..aus alten Designgründen wurde beispielsweise eine neue Funktion in einen zuvor reservierten Bereich eingefügt ..".

Soweit ich weiß, haben Bitpositionen selbst in den meisten Fällen fast keine Auswirkungen auf das Design (meine ich bei der Chip-Implementierung). Designer versuchen normalerweise, alles zu nutzen, was verfügbar ist. Und in einigen Fällen, wenn Sie versuchen, Breiten usw. zu erweitern.

Es gibt jedoch einige Fälle, in denen die Bitpositionen absichtlich weit voneinander entfernt sind. Speziell für Bits, die kritisch sind und NICHT durch unbeabsichtigte Schreibvorgänge (aufgrund falscher Positionen / Masken oder aus Sicherheitsgründen verschlüsselt) geändert werden dürfen, die dazu führen können, dass das System in einem unerwünschten Zustand endet.

— rs747
quelle