Pourquoi les champs de bits logiquement liés dans les registres MCU sont-ils souvent dans des emplacements séparés?

Pardonnez-moi si cette question a déjà été répondue, mais je n'ai pas pu trouver de réponse sur cette page ou sur Internet plus large.

Je suis un développeur expérimenté avec une connaissance décente de la programmation de bas niveau, mais relativement nouveau pour le développement embarqué. Je me suis enseigné le développement de systèmes embarqués à l'aide d'une carte ST-NUCLEO144, qui dispose d'un microcontrôleur STM32F746ZG. Une question qui me semble non évidente est la raison pour laquelle les champs de bits logiquement liés dans un registre peuvent se trouver à différents emplacements.

Un exemple est le USART_CR1registre sur le STM32746ZG. Les champs M0et M1bits contrôlent ensemble la longueur de mot dans USART TX / RX, une valeur combinée de 2 bits de 0b00spécifie 8 bits, 0b01spécifie 9 bits, etc. Tout cela est assez simple, sauf que M0c'est au bit 12 et M1au bit 28 ... pourquoi est-ce?

Est-ce pour des raisons de conception héritées, telles qu'une nouvelle fonctionnalité a été insérée dans l'espace précédemment réservé? Est-ce pour des raisons liées à la conception de la puce, que je n'envisage pas, ou y a-t-il un objectif plus important que je ne vois pas?

Évidemment, c'est assez trivial à surmonter avec le masquage de bits, mais je suis juste curieux.

Est-ce pour des raisons de conception héritées, telles qu'une nouvelle fonctionnalité a été insérée dans l'espace précédemment réservé?

Dans ce cas particulier (et dans des cas similaires que j'ai vus) oui, cela est fait pour aider à maintenir la compatibilité descendante avec les appareils plus anciens et à minimiser les modifications requises au code (peut-être bien testé et qualifié / certifié) déjà écrit pour ces appareils plus anciens . Les nouvelles caractéristiques et fonctionnalités (nécessitant de nouveaux bits de registre pour le contrôle et la configuration) doivent donc utiliser des bits non contigus, si les bits adjacents aux bits de registre d'origine sont déjà utilisés.

Par exemple, voici le USART_CR1registre de l'ancienne famille STM32F1xx.

Figure 1. Utilisation du registre STM32F10xxx USART_CR1

_{Source de l'image: manuel de référence de la famille STM32F10xxx RM0008, section 27.6.4}

Cet ancien USART (avec seulement 2 options de longueur de mot) n'a besoin que d'un Mbit pour configurer la longueur de mot USART entre les deux options, et c'est le bit 12. Remarquez comment les bits 11 et 13 sont également utilisés, et donc indisponibles pour une future "expansion" .

Comme vous l'avez dit, sur le plus récent STM32F7 (et, par exemple, également le STM32F4), l'USART a maintenant 3 options de longueur de mot (7, 8 et 9 bits) et a donc besoin d'un autre bit de configuration - le bit 12 est M0, avec M1maintenant le bit 28 (précédemment réservé dans la carte du registre STM32F1, comme vous le voyez ci-dessus).

Figure 2. Utilisation du registre STM32F74xxx USART_CR1

_{Source d'image: Manuel de référence de la famille STM32F75xxx et STM32F74xxx RM0385, section 31.8.1}

Ils ne pouvaient pas mettre le nouveau M1bit dans les bits de registre 11 ou 13, sans déplacer les bits de registre déjà utilisés pour d'autres fonctions, et ainsi supprimer la rétrocompatibilité avec le code existant (par exemple pour le STM32F1) qui les utilisait.

Ils ont donc essayé de conserver une certaine compatibilité descendante, ce qui conduit à l'ajout de nouveaux bits de registre dans des endroits inattendus.

Le maintien de la cartographie des registres pour les UART autonomes, du 8250 au 16550, avec de nouveaux registres ajoutés ailleurs dans la carte des registres, en était un autre exemple.

Vous avez raison avec

msgstr "..pour des raisons de conception héritées, telles qu'une nouvelle fonctionnalité a été insérée dans un espace précédemment réservé ..".

Pour autant que je sache, les positions de bits elles-mêmes n'ont presque aucun impact sur la conception (dans la mise en œuvre des puces, je veux dire) dans la plupart des cas. Les concepteurs essaient généralement d'utiliser tout ce qui est disponible. Et dans certains cas, comme lorsque vous essayez d'étendre des largeurs, etc.

Cela dit, il existe cependant des cas où les positions des bits sont intentionnellement éloignées. Spécifiquement pour les bits qui sont critiques et ne doivent PAS être modifiés par des écritures involontaires (en raison d'une position / masques incorrects ou brouillés pour des raisons de sécurité) qui peuvent entraîner le système à se retrouver dans un état indésirable.