Почему логически связанные битовые поля в регистрах MCU часто находятся в разных местах?

9

Простите, если на этот вопрос уже был дан ответ, но я не смог найти ответ ни на этой странице, ни в более широком Интернете.

Я опытный разработчик с приличными знаниями в области низкоуровневого программирования, но относительно новым для встраиваемой разработки. Я учил себя разработке встраиваемых систем с использованием платы ST-NUCLEO144, которая оснащена микроконтроллером STM32F746ZG. Один вопрос, который кажется мне неочевидным, заключается в том, почему логически связанные битовые поля в регистре могут находиться в разных местах.

Одним из примеров является USART_CR1регистр на STM32746ZG. Эти M0и M1битовые поля вместе контролируют длину слова в USART TX / RX, комбинированный 2-битовое значение 0b00специфицирует 8-бит, 0b01указывает 9-бит и т.д. Это все довольно просто, за исключением того, что M0находится на 12 бита и M1находится на бит 28 ... почему это?

Это связано с устаревшим дизайном, например, новая функция была вставлена в ранее зарезервированное пространство? Я не рассматриваю это по причинам, связанным с дизайном чипа, или я не вижу в этом более важной цели?

Очевидно, что это довольно просто преодолеть с помощью маскировки битов, но мне просто любопытно.

microcontroller stm32 embedded

— ajxs
источник

1

В частности, для UART это очень старая технология, поэтому причина почти всегда в обратной совместимости. По той же причине, по которой битовые поля регистра UART часто имеют дрянные имена, которые приводят к конфликтам пространства имен повсюду.

— Лундин

13

Это связано с устаревшим дизайном, например, новая функция была вставлена в ранее зарезервированное пространство?

В данном конкретном случае (и в аналогичных случаях, которые я видел) да, это сделано для того, чтобы сохранить обратную совместимость со старыми устройствами и минимизировать любые изменения, необходимые для (возможно, хорошо протестированного и квалифицированного / сертифицированного) кода, уже написанного для этих старых устройств. , Поэтому новые функции и функциональные возможности (требующие новых битов регистров для управления и конфигурации) должны использовать несмежные биты, если смежные биты с исходными битами регистров уже используются.

Например, вот USART_CR1регистр старого семейства STM32F1xx.

Рисунок 1. Использование регистра STM32F10xxx USART_CR1

_{Источник изображения: справочное руководство по семейству STM32F10xxx RM0008, раздел 27.6.4}

Для более старого USART (только с двумя вариантами длины слова) требуется только один Mбит для настройки длины слова USART между этими двумя параметрами, и это бит 12. Обратите внимание на то, как также используются биты 11 и 13, и поэтому они недоступны для будущего «расширения» ,

Как вы сказали, в более новом STM32F7 (и, например, также в STM32F4) USART теперь имеет 3 варианта длины слова (7, 8 и 9 бит) и поэтому нуждается в другом бите конфигурации - бит 12 есть M0, а M1теперь в бите 28 (ранее зарезервировано в карте регистров STM32F1, как вы видите выше).

Рисунок 2. Использование регистра STM32F74xxx USART_CR1

_{Источник изображения: справочное руководство по семейству STM32F75xxx и STM32F74xxx RM0385, раздел 31.8.1}

Они не могли поместить новый M1бит в регистровые биты 11 или 13, не перемещая регистровые биты, уже используемые для других функций, и, таким образом, устраняя обратную совместимость с существующим кодом (например, для STM32F1), который их использовал.

Поэтому они попытались сохранить некоторую обратную совместимость, что приводит к добавлению новых битов регистра в неожиданных местах.

Поддержание отображения регистров для автономных UART, от 8250 до 16550, с новыми регистрами, добавленными в другом месте в карте регистров, было другим примером.

— SamGibson
источник

1

Большое спасибо, что нашли время, чтобы указать на это. Возможно, я должен был проверить старый справочный материал семейства F., прежде чем я спросил. Я подумал, что в этой истории может быть что-то еще.

— Ajxs

1

@ajxs - Пожалуйста. Я могу говорить только из своего опыта (эти старые UARTS были еще одним хорошим примером). Всегда возможно, что у кого-то еще будет другой соответствующий опыт, и он может быть отстранен от того, чтобы тратить время на написание ответа, если вопрос уже имеет принятый ответ. Таким образом, вы всегда можете «не принять» мой ответ, подождать (скажем) день, когда кто-нибудь другой ответит с разных точек зрения, и посмотреть, считаете ли вы, что они отвечают на вопрос лучше меня? Если нет, то вы всегда можете повторно принять мою :-) Я просто не хочу, чтобы вы потеряли другие потенциальные перспективы ответа.

— СамГибсон

2

Это кажется разумным, я приму ваш совет! Спасибо за то, что вы были так вежливы, что сделали предложение. Если завтра не придет лучшего ответа, я приму ваш. Еще раз спасибо.

— Ajxs

5

Вы правы с

msgstr "по устаревшим причинам дизайна, например, новая функция была вставлена в ранее зарезервированное пространство ...".

Насколько я знаю, сами позиции битов практически не влияют на дизайн (я имею в виду реализацию чипа) в большинстве случаев. Дизайнеры обычно стараются использовать все, что доступно. И в некоторых случаях, например, когда вы пытаетесь увеличить ширину и т. Д.

Тем не менее, есть некоторые случаи, когда позиции битов намеренно держатся далеко друг от друга. В частности, для битов, которые являются критическими и НЕ подлежат изменению непреднамеренными записями (из-за неправильного положения / масок или шифрования в целях безопасности), которые могут привести к тому, что система окажется в нежелательном состоянии.

— rs747
источник