Perché i campi di bit logicamente correlati nei registri MCU sono spesso in posizioni separate?

9

Scusami se questa domanda è già stata risolta, ma non sono riuscito a trovare una risposta su questa pagina o su Internet.

Sono uno sviluppatore esperto con una discreta conoscenza della programmazione di basso livello, ma relativamente nuovo per lo sviluppo integrato. Mi sono insegnato lo sviluppo di sistemi embedded usando una scheda ST-NUCLEO144, che presenta un MCU STM32F746ZG. Una domanda che mi sembra non ovvia è che il motivo per cui i campi di bit logicamente correlati in un registro possano trovarsi in posizioni diverse.

Un esempio è il USART_CR1registro sull'STM32746ZG. I campi bit M0e M1insieme controllano la lunghezza della parola in USART TX / RX, un valore combinato a 2 bit 0b00specifica 8 bit, 0b01specifica 9 bit, ecc. Tutto ciò è abbastanza semplice, tranne che M0è al bit 12 ed M1è al bit 28 ... perché questo?

È per motivi di design legacy, come una nuova funzionalità inserita in spazi precedentemente riservati? È per motivi legati alla progettazione del chip, che non sto prendendo in considerazione, o c'è uno scopo maggiore in questo che non vedo?

Ovviamente questo è piuttosto banale da superare con il bit-masking, ma sono solo curioso.

microcontroller stm32 embedded

— ajxs
fonte

1

Nel caso specifico di UART, si tratta di una tecnologia molto vecchia, quindi il motivo è quasi sempre la retrocompatibilità. Lo stesso motivo per cui i campi bit di UART registrano spesso nomi scadenti che danno collisioni nello spazio dei nomi ovunque.

— Lundin,

13

È per motivi di design legacy, come una nuova funzionalità inserita in spazi precedentemente riservati?

In questo caso particolare (e in casi simili che ho visto) sì, è fatto per aiutare a mantenere la retrocompatibilità con i dispositivi più vecchi e minimizzare qualsiasi modifica richiesta al codice (forse ben collaudato e qualificato / certificato) già scritto per quei dispositivi più vecchi . Nuove caratteristiche e funzionalità (che richiedono nuovi bit di registro per controllo e configurazione) devono quindi utilizzare bit non contigui, se i bit adiacenti ai bit di registro originali sono già utilizzati.

Ad esempio, ecco il USART_CR1registro della vecchia famiglia STM32F1xx.

Figura 1. Utilizzo del registro STM32F10xxx USART_CR1

_{Fonte immagine: manuale di riferimento della famiglia STM32F10xxx RM0008, sezione 27.6.4}

Che la vecchia USART (con solo 2 opzioni di lunghezza della parola) abbia bisogno di un solo Mbit per configurare la lunghezza della parola USART tra le due opzioni, e che sia il bit 12. Notare come vengono utilizzati anche i bit 11 e 13, e quindi non disponibili per future "espansioni" .

Come hai detto, sul nuovo STM32F7 (e, ad esempio, anche sul STM32F4), USART ora ha 3 opzioni di lunghezza della parola (7, 8 e 9 bit) e quindi ha bisogno di un altro bit di configurazione - bit 12 è M0, con M1ora nel bit 28 (precedentemente riservato nella mappa dei registri STM32F1, come vedi sopra).

Figura 2. Utilizzo del registro STM32F74xxx USART_CR1

_{Fonte immagine: manuale di riferimento della famiglia STM32F75xxx e STM32F74xxx RM0385, sezione 31.8.1}

Non sono stati in grado di inserire il nuovo M1bit nei bit di registro 11 o 13, senza spostare i bit di registro già utilizzati per altre funzioni, rimuovendo così la retrocompatibilità con il codice esistente (ad es. Per STM32F1) che li utilizzava.

Quindi hanno cercato di mantenere un po 'di compatibilità all'indietro, il che porta ad aggiungere nuovi bit di registro in luoghi inaspettati.

Il mantenimento della mappatura dei registri per gli UART autonomi, dall'8250 al 16550, con nuovi registri aggiunti altrove nella mappa dei registri, è stato un altro esempio.

— SamGibson
fonte

1

Grazie mille per il tempo dedicato a segnalarlo. Forse avrei dovuto controllare il vecchio materiale di riferimento della famiglia F prima di chiedere. Ho pensato che potrebbe esserci di più nella storia però.

— Ajax

1

@ajxs - Prego. Posso solo parlare delle mie esperienze (quei vecchi UART erano un altro buon esempio). È sempre possibile che qualcun altro abbia altre esperienze rilevanti e che possano essere scoraggiati dal passare il tempo a scrivere una risposta, se la domanda ha già una risposta accettata. Quindi potresti sempre "non accettare" la mia risposta, aspettare (dire) un giorno che chiunque altro risponda da diverse prospettive e vedere se ritieni che rispondano alla domanda meglio della mia? Altrimenti, puoi sempre ri-accettare la mia :-) Non voglio che tu perda altre prospettive di risposta potenziale.

— SamGibson

2

Sembra ragionevole, prenderò il tuo consiglio! Grazie per essere così cortese da dare il suggerimento. Se domani non è arrivata una risposta migliore, accetterò la tua. Grazie ancora.

— Ajs

5

Hai ragione con

"..per motivi di design legacy, come una nuova funzionalità è stata inserita in spazi precedentemente riservati ..".

Per quanto ne so, le posizioni dei bit stessi non hanno quasi alcun impatto sulla progettazione (nella realizzazione del chip intendo) nella maggior parte dei casi. I designer di solito cercano di utilizzare tutto ciò che è disponibile. E in alcuni casi come quando stai cercando di estendere le larghezze ecc.

Detto questo, ci sono tuttavia alcuni casi in cui le posizioni dei bit sono intenzionalmente tenute distanti. Soprattutto per i bit critici che NON devono essere modificati da scritture involontarie (a causa di posizioni / maschere errate o criptate per motivi di sicurezza) che possono far finire il sistema in uno stato indesiderato.

— rs747
fonte