Чому логічно пов'язані бітові поля в регістрах MCU часто знаходяться в окремих місцях?

9

Пробачте, якщо на це питання вже відповіли, але я не зміг знайти відповідь ні на цій сторінці, ні в широкому Інтернеті.

Я досвідчений розробник з гідними знаннями щодо програмування низького рівня, але відносно новим для вбудованої розробки. Я вчив себе розробці вбудованих систем за допомогою плати ST-NUCLEO144, на якій є MCM 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, з новими реєстрами, доданими в інших місцях на карті реєстру.

— СамГібсон
джерело

1

Велике спасибі, що знайшли час, щоб вказати на це. Можливо, я мав би перевірити старий довідковий матеріал сімейства F, перш ніж запитати. Я подумав, що може бути більше до історії.

— ajxs

1

@ajxs - ласкаво просимо. Я можу говорити лише зі свого досвіду (ті старі УАРТИ були ще одним хорошим прикладом). Завжди можливо, що хтось інший матиме інший відповідний досвід, і вони можуть бути відкладені витрачати час на написання відповіді, якщо на питання вже є прийнята відповідь. Тож ви завжди можете "неприйняти" мою відповідь, зачекайте (скажіть) день, коли хтось ще відповість з різних точок зору, і побачите, чи відчуваєте ви, що вони відповідають на питання краще, ніж моє? Якщо ні, то ви завжди можете знову прийняти моє :-) Я просто не хочу, щоб ви втрачали інші перспективи відповіді.

— СамГібсон

2

Це здається розумним, я прийму вашу пораду! Дякую за те, що ви були настільки ввічливі, що зробили пропозицію. Якщо до завтра не знайдеться кращої відповіді, я прийму вашу. Знову дякую.

— ajxs

5

Ви маєте рацію

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

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

Однак, є деякі випадки, коли позиції бітів навмисно тримаються далеко один від одного. Зокрема, для бітів, які є критичними і НЕ повинні бути змінені ненавмисними записами (через неправильну позицію / маски, або скремтовані для безпеки), які можуть призвести до того, що система закінчиться в небажаному стані.

— rs747
джерело