Perché il codice AVR utilizza lo spostamento dei bit [chiuso]

Nella programmazione AVR, i bit di registro sono invariabilmente impostati spostando a sinistra 1nella posizione dei bit appropriata - e vengono cancellati da un complemento di uno degli stessi.

Esempio: per un ATtiny85, potrei impostare PORTB, b _{4 in} questo modo:

PORTB |= (1<<PB4);

o cancellalo in questo modo:

PORTB &= ~(1<<PB4);

La mia domanda è: perché è fatto in questo modo? Il codice più semplice finisce per essere un casino di bit-shift. Perché i bit sono definiti come posizioni dei bit anziché come maschere.

Ad esempio, l'intestazione IO per ATtiny85 include questo:

#define PORTB   _SFR_IO8(0x18)
#define PB5     5
#define PB4     4
#define PB3     3
#define PB2     2
#define PB1     1
#define PB0     0

Per me, sarebbe molto più logico definire i bit come maschere (in questo modo):

#define PORTB   _SFR_IO8(0x18)
#define PB5     0x20
#define PB4     0x10
#define PB3     0x08
#define PB2     0x04
#define PB1     0x02
#define PB0     0x01

Quindi potremmo fare qualcosa del genere:

// as bitmasks
PORTB |=  PB5 |  PB3 |  PB0;
PORTB &= ~PB5 & ~PB3 & ~PB0;

per attivare e disattivare i bit b ₅ , b ₃ e b ₀ , rispettivamente. Al contrario di:

// as bit-fields
PORTB |=  (1<<PB5) |  (1<<PB3) |  (1<<PB0);
PORTB &= ~(1<<PB5) & ~(1<<PB3) & ~(1<<PB0);

Il codice maschera di bit legge molto più chiaramente: imposta bit PB5,PB3 e PB0. Inoltre, sembrerebbe salvare le operazioni poiché i bit non devono più essere spostati.

Ho pensato che forse è stato fatto in questo modo per preservare la generalità al fine di consentire il porting del codice da un AVR n -bit a un m -bit (esempio da 8 bit a 32 bit). Ma questo non sembra essere il caso, poiché si #include <avr/io.h>risolve in file di definizione specifici per il microcontrollore di destinazione. Anche cambiando gli obiettivi da un 8-bit ATtiny a un 8-bit Atmega (dove definizioni dei bit cambiano sintatticamente da PBxa PORTBx, per esempio), richiede modifiche al codice.

Il codice più semplice finisce per essere un casino di bit-shift. Perché i bit sono definiti come posizioni dei bit anziché come maschere.

No. Niente affatto. I turni sono solo nel codice sorgente C, non nel codice macchina compilato. Tutti gli esempi che hai mostrato possono e saranno risolti dal compilatore in fase di compilazione perché sono semplici espressioni costanti.

(1<<PB4) è solo un modo per dire "bit PB4".

• Quindi non funziona solo, non crea più dimensioni del codice.

• Ha anche senso per il programmatore umano nominare i bit in base al loro indice (ad es. 5) e non in base alla loro maschera di bit (ad es. 32) perché in questo modo è possibile utilizzare numeri consecutivi 0..7 per identificare i bit invece del potere imbarazzante di due (1, 2, 4, 8, .. 128).

• E c'è un altro motivo (forse il motivo principale):
  i file di intestazione C non possono essere utilizzati solo per il codice C ma anche per il codice sorgente dell'assemblatore (o il codice dell'assemblatore incorporato nel codice sorgente C). Nel codice dell'assemblatore AVR sicuramente non si desidera solo utilizzare le maschere di bit (che possono essere create dagli indici mediante lo spostamento dei bit). Per alcune istruzioni dell'assemblatore di manipolazione dei bit AVR (ad es. SBI, CBI, BST, BLD) è necessario utilizzare gli indici di bit come operatore immediato nel loro codice operativo dell'istruzione.
  Solo se identifichi bit di SFR per indici(non tramite la maschera di bit) è possibile utilizzare tali identificatori direttamente come l'operando immediato delle istruzioni dell'assemblatore. Altrimenti dovevi avere due definizioni per ciascun bit SFR: uno che definiva il suo indice di bit (che può essere usato ad esempio come operando nelle istruzioni assembler di manipolazione di bit di cui sopra) e uno che definisce la sua maschera di bit (che può essere usata solo per istruzioni in cui l'intero byte viene manipolato).

Forse lo spostamento dei bit non è l'unico caso d'uso per le PB*definizioni. Forse ci sono altri casi d'uso in cui le PB*definizioni sono usate direttamente piuttosto che come importi di spostamento. In tal caso, credo che il principio DRY ti porterebbe ad implementare una serie di definizioni che possono essere utilizzate per entrambi i casi d'uso (come questi PB*definiti) anziché due diverse serie di definizioni che hanno informazioni ripetitive.

Ad esempio, ho scritto un'applicazione che può eseguire misurazioni da un massimo di 8 canali ADC. Ha un'interfaccia per avviare una nuova misurazione in cui è possibile specificare più canali tramite un campo a 8 bit, un bit per ciascun canale. (Le misurazioni vengono eseguite in parallelo quando vengono specificati più canali.) Quindi ha un'altra interfaccia che restituisce i risultati della misurazione per un singolo canale. Quindi un'interfaccia utilizza il numero del canale come spostamento in un campo bit e l'altra interfaccia utilizza direttamente il numero del canale. Ho definito una singola enumerazione per coprire entrambi i casi d'uso.

typedef enum
{
    CHANNEL_XL_X = 0,
    CHANNEL_XL_Y = 1,
    CHANNEL_XL_Z = 2,
    CHANNEL_G_X = 3,
    CHANNEL_G_Y = 4,
    CHANNEL_G_Z = 5,
    CHANNEL_AUX1 = 6,
    CHANNEL_AUX2 = 7
} ChannelNum;

struct MeasurementResult;

void StartMeasurement(uint8_t channel_mask);
MeasurementResult ReadMeasurementResult(ChannelNum channel_num);

main
{
    ...

    StartMeasurement( (1 << CHANNEL_XL_X) | (1 << CHANNEL_XL_Y) | (1 << CHANNEL_XL_Z) );

    meas_result_x = ReadMeasurementResult(CHANNEL_XL_X);
    meas_result_y = ReadMeasurementResult(CHANNEL_XL_Y);
    meas_result_z = ReadMeasurementResult(CHANNEL_XL_Z);
}