¿Por qué los campos de bits relacionados lógicamente en los registros de MCU a menudo se encuentran en ubicaciones separadas?

Perdóneme si esta pregunta ya ha sido respondida, pero no pude encontrar una respuesta ni en esta página ni en Internet.

Soy un desarrollador experimentado con un conocimiento decente sobre la programación de bajo nivel, pero relativamente nuevo en el desarrollo integrado. Me he estado enseñando el desarrollo de sistemas integrados utilizando una placa ST-NUCLEO144, que cuenta con una MCU STM32F746ZG. Una pregunta que no me parece obvia es por qué los campos de bits relacionados lógicamente en un registro pueden estar en diferentes ubicaciones.

Un ejemplo es el USART_CR1registro en el STM32746ZG. Los campos M0y M1bit controlan juntos la longitud de la palabra en USART TX / RX, un valor combinado de 2 bits que 0b00especifica 8 bits, 0b01especifica 9 bits, etc. Todo esto es bastante sencillo, excepto que M0está en el bit 12 y M1está en el bit 28 ... ¿por qué es esto?

¿Es esto por razones de diseño heredadas, como una nueva característica insertada en un espacio previamente reservado? ¿Es por razones relacionadas con el diseño del chip que no estoy considerando, o hay un propósito mayor para esto que no estoy viendo?

Obviamente, esto es bastante trivial de superar con el enmascaramiento de bits, pero tengo curiosidad.

¿Es esto por razones de diseño heredadas, como una nueva característica insertada en un espacio previamente reservado?

En este caso particular (y en casos similares que he visto) sí, se hace para ayudar a mantener la compatibilidad con dispositivos antiguos y minimizar cualquier cambio requerido al código (quizás bien probado y calificado / certificado) ya escrito para esos dispositivos más antiguos. . Por lo tanto, las nuevas características y funcionalidades (que requieren nuevos bits de registro para control y configuración) tienen que usar bits no contiguos, si los bits adyacentes a los bits de registro originales ya están en uso.

Por ejemplo, aquí está el USART_CR1registro de la antigua familia STM32F1xx.

Figura 1. Uso del registro STM32F10xxx USART_CR1

_{Fuente de la imagen: manual de referencia de la familia STM32F10xxx RM0008, sección 27.6.4}

Ese USART anterior (con solo opciones de longitud de 2 palabras) necesita solo un Mbit para configurar la longitud de palabra USART entre las dos opciones, y ese es el bit 12. Observe cómo los bits 11 y 13 también se usan y, por lo tanto, no están disponibles para futuras "expansiones". .

Como dijiste, en el STM32F7 más nuevo (y, por ejemplo, también el STM32F4), el USART ahora tiene 3 opciones de longitud de palabra (7, 8 y 9 bits) y, por lo tanto, necesita otro bit de configuración: el bit 12 es M0, M1ahora con el bit 28 (previamente reservado en el mapa de registro STM32F1, como puede ver arriba).

Figura 2. Uso del registro STM32F74xxx USART_CR1

_{Fuente de la imagen: manual de referencia de la familia STM32F75xxx y STM32F74xxx RM0385, sección 31.8.1}

No podían poner el nuevo M1bit en los bits de registro 11 o 13, sin mover los bits de registro ya utilizados para otras funciones, y así eliminar la compatibilidad con el código existente (por ejemplo, para el STM32F1) que los usaba.

Por lo tanto, han tratado de mantener cierta compatibilidad con versiones anteriores, lo que lleva a que se agreguen nuevos bits de registro en lugares inesperados.

Mantener el mapeo de registros para UART independientes, desde el 8250 hasta el 16550, con nuevos registros agregados en otras partes del mapa de registro, fue otro ejemplo.

Tienes razon con

"... por motivos de diseño heredados, como que se haya insertado una nueva función en un espacio previamente reservado ...".

Hasta donde yo sé, las posiciones de bits en sí mismas casi no tienen impacto en el diseño (en la implementación del chip, quiero decir) en la mayoría de los casos. Los diseñadores generalmente intentan utilizar lo que está disponible. Y en algunos casos, como cuando intentas extender anchos, etc.

Dicho esto, sin embargo, hay algunos casos en los que las posiciones de bits se mantienen intencionalmente separadas. Específicamente para bits que son críticos y que NO deben ser modificados por escrituras involuntarias (debido a posiciones / máscaras incorrectas o codificadas por seguridad) que pueden hacer que el sistema termine en un estado no deseado.