Dlaczego logicznie powiązane pola bitów w rejestrach MCU często znajdują się w oddzielnych lokalizacjach?

9

Wybacz mi, jeśli na to pytanie już udzielono odpowiedzi, ale nie mogłem znaleźć odpowiedzi ani na tej stronie, ani w szerszym Internecie.

Jestem doświadczonym programistą z przyzwoitą wiedzą na temat programowania niskopoziomowego, ale stosunkowo nowy w programowaniu wbudowanym. Uczę się projektowania systemów wbudowanych za pomocą płytki ST-NUCLEO144, która zawiera MCU STM32F746ZG. Jedno pytanie, które wydaje mi się nieoczywiste, dotyczy tego, dlaczego logicznie powiązane pola bitów w rejestrze mogą znajdować się w różnych lokalizacjach.

Jednym z przykładów jest USART_CR1rejestr na STM32746ZG. Te M0i M1Pola bitów wraz kontrolować długość słowa w USART TX / RX, łączna suma 2-bitową 0b00Określa 8-bitów, 0b01określa 9 bitów itd Wszystko to jest proste, z tym, że M0jest w bit 12, M1jest trochę 28 ... dlaczego to jest?

Czy dzieje się tak z powodów projektowania, takich jak nowa funkcja została wstawiona do wcześniej zarezerwowanego miejsca? Czy to z powodów związanych z konstrukcją układu, których nie rozważam, czy jest to ważniejszy cel, którego nie widzę?

Oczywiście jest to dość trywialne do pokonania za pomocą maskowania bitów, ale jestem po prostu ciekawy.

microcontroller stm32 embedded

— ajxs
źródło

1

W przypadku UART jest to bardzo stara technologia, dlatego prawie zawsze przyczyną jest zgodność wsteczna. Ten sam powód, dla którego pola bitów rejestru UART często mają gówniane nazwy, które powodują kolizje przestrzeni nazw.

— Lundin,

13

Czy dzieje się tak z powodów projektowania, takich jak nowa funkcja została wstawiona do wcześniej zarezerwowanego miejsca?

W tym konkretnym przypadku (i w podobnych przypadkach, które widziałem) tak, zrobiono to, aby pomóc zachować wsteczną kompatybilność ze starszymi urządzeniami i zminimalizować wszelkie zmiany wymagane w (być może dobrze przetestowanym i kwalifikowanym / certyfikowanym) kodzie już napisanym dla tych starszych urządzeń . Nowe funkcje i funkcje (wymagające nowych bitów rejestru do sterowania i konfiguracji) muszą zatem wykorzystywać niesąsiadujące bity, jeśli bity sąsiadujące z oryginalnymi bitami rejestru są już używane.

Na przykład tutaj jest USART_CR1rejestr starej rodziny STM32F1xx.

Rysunek 1. Wykorzystanie rejestru STM32F10xxx USART_CR1

_{Źródło obrazu: Instrukcja obsługi rodziny STM32F10xxx RM0008, sekcja 27.6.4}

Ten starszy USART (z tylko 2 opcjami długości słowa) potrzebuje tylko jednego Mbitu, aby skonfigurować długość słowa USART między dwiema opcjami, a to jest bit 12. Zwróć uwagę, w jaki sposób używane są również bity 11 i 13, a zatem niedostępne dla przyszłego „rozszerzenia” .

Jak już powiedziałeś, w nowszym STM32F7 (i na przykład także STM32F4) USART ma teraz 3 opcje długości słów (7, 8 i 9 bitów) i dlatego potrzebuje innego bitu konfiguracji - bit 12 jest M0, a M1teraz w bicie 28 (poprzednio zarezerwowane w mapie rejestrów STM32F1, jak widać powyżej).

Rysunek 2. Wykorzystanie rejestru STM32F74xxx USART_CR1

_{Źródło obrazu: STM32F75xxx i STM32F74xxx podręcznik referencyjny rodziny RM0385, sekcja 31.8.1}

Nie mogli wstawić nowego M1bitu do bitów rejestru 11 lub 13, bez przenoszenia bitów rejestru używanych już dla innych funkcji, a zatem usuwając wsteczną zgodność z istniejącym kodem (np. Dla STM32F1), który ich używał.

Próbowali więc zachować pewną zgodność wsteczną, co prowadzi do dodawania nowych bitów rejestru w nieoczekiwanych miejscach.

Innym przykładem było utrzymanie mapowania rejestrów dla autonomicznych UART, od 8250 do 16550, z nowymi rejestrami dodanymi w innym miejscu na mapie rejestrów.

— SamGibson
źródło

1

Bardzo dziękuję za poświęcenie czasu na zwrócenie na to uwagi. Być może powinienem był sprawdzić stary materiał referencyjny z rodziny F. Pomyślałem, że może być więcej w tej historii.

— ajxs

1

@ajxs - Nie ma za co. Mogę mówić tylko na podstawie moich doświadczeń (te stare UARTS były kolejnym dobrym przykładem). Zawsze jest możliwe, że ktoś inny będzie miał inne istotne doświadczenia i może być zniechęcony spędzaniem czasu na pisaniu odpowiedzi, jeśli pytanie ma już zaakceptowaną odpowiedź. Więc zawsze możesz „nie zaakceptować” mojej odpowiedzi, poczekać (powiedzmy) dzień, aż ktokolwiek odpowie z innej perspektywy, i zobacz, czy uważasz, że odpowiedziałaby na to pytanie lepiej niż moja? Jeśli nie, zawsze możesz ponownie zaakceptować moje :-) Po prostu nie chcę, abyś stracił inne potencjalne perspektywy odpowiedzi.

— SamGibson,

2

To wydaje się rozsądne, posłucham twojej rady! Dziękuję, że jesteś tak uprzejmy, aby coś zasugerować. Jeśli jutro nie otrzyma lepszej odpowiedzi, zaakceptuję twoją. Dzięki jeszcze raz.

— ajxs

5

Masz rację

„.. ze starszych powodów projektowych, takich jak nowa funkcja została wstawiona do wcześniej zarezerwowanego miejsca ..”

O ile mi wiadomo, same pozycje bitów w większości przypadków nie mają prawie żadnego wpływu na projekt (w implementacji chipa). Projektanci zwykle starają się wykorzystać to, co jest dostępne. A w niektórych przypadkach, na przykład gdy próbujesz zwiększyć szerokość itp.

To powiedziawszy, istnieją jednak przypadki, w których pozycje bitów są celowo utrzymywane daleko od siebie. Szczególnie dla bitów, które są krytyczne i NIE mogą być modyfikowane przez niezamierzone zapisy (z powodu niewłaściwej pozycji / masek lub zakodowane dla bezpieczeństwa), które mogą spowodować, że system skończy się w niepożądanym stanie.

— rs747
źródło