Передовой опыт битовых манипуляций

Проблема с битовыми полями заключается в том, что стандарт C не предписывает, чтобы порядок их определения был таким же, как и порядок их реализации. Таким образом, вы, возможно, не устанавливаете биты, которые вы думаете.

Раздел 6.7.2.1p11 стандарта C состояния:

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

В качестве примера посмотрите на определение struct iphdr, представляющего заголовок IP, из файла /usr/include/netinet/ip.h в Linux:

struct iphdr
  {
#if __BYTE_ORDER == __LITTLE_ENDIAN
    unsigned int ihl:4;
    unsigned int version:4;
#elif __BYTE_ORDER == __BIG_ENDIAN
    unsigned int version:4;
    unsigned int ihl:4;
#else
# error "Please fix <bits/endian.h>"
#endif
    u_int8_t tos;
    ...

Здесь вы можете видеть, что битовые поля расположены в другом порядке в зависимости от реализации. Вы также не должны использовать эту конкретную проверку, потому что это поведение зависит от системы. Это приемлемо для этого файла, поскольку он является частью системы. Другие системы могут реализовать это по-разному.

Так что не используйте битовое поле.

Лучший способ сделать это — установить необходимые биты. Однако имеет смысл определить именованные константы для каждого бита и выполнить побитовое ИЛИ над константами, которые вы хотите установить. Например:

const uint8_t BIT_BYTE =     0x1;
const uint8_t BIT_HW   =     0x2;
const uint8_t BIT_WORD =     0x4;
const uint8_t BIT_GO   =     0x8;
const uint8_t BIT_I_EN =     0x10;
const uint8_t BIT_REEN =     0x20;
const uint8_t BIT_WEEN =     0x40;
const uint8_t BIT_LEEN =     0x80;

DMA_base_ptr[DMA_CONTROL_OFFS] = BIT_LEEN | BIT_GO | BIT_WORD;

Другие ответы уже охватили большую часть материала, но, возможно, стоит упомянуть, что даже если вы не можете использовать нестандартный синтаксис 0b, вы можете использовать сдвиги для перемещения бита 1 в позицию по номеру бита, т.е.:

#define DMA_BYTE  (1U << 0)
#define DMA_HW    (1U << 1)
#define DMA_WORD  (1U << 2)
#define DMA_GO    (1U << 3)
// …

Обратите внимание, что последнее число соответствует столбцу «номер бита» в документации.

Использование для установки и очистки битов не меняется:

#define DMA_CONTROL_REG DMA_base_ptr[DMA_CONTROL_OFFS]

DMA_CONTROL_REG |= DMA_HW | DMA_WORD;    // set HW and WORD
DMA_CONTROL_REG &= ~(DMA_BYTE | DMA_GO); // clear BYTE and GO

Старый способ C состоит в том, чтобы определить кучу битов:

#define WORD  0x04
#define GO    0x08
#define I_EN  0x10
#define LEEN  0x80

Тогда ваша инициализация становится

DMA_base_ptr[DMA_CONTROL_OFFS] = WORD | GO | LEEN;

Вы можете установить отдельные биты, используя |:

DMA_base_ptr[DMA_CONTROL_OFFS] |= I_EN;

Вы можете очистить отдельные биты, используя & и ~:

DMA_base_ptr[DMA_CONTROL_OFFS] &= ~GO;

Вы можете протестировать отдельные биты, используя &:

if(DMA_base_ptr[DMA_CONTROL_OFFS] & WORD) ...

Однако определенно не используйте битовые поля. У них есть свое применение, но не тогда, когда внешняя спецификация определяет, что биты находятся в определенных местах, как я предполагаю здесь.

См. также вопросы 20.7 и 2.26 в списке часто задаваемых вопросов по C.

Стандарта для битовых полей не существует. В этом случае отображение и битовая операция зависят от компилятора. Двоичные значения, такие как 0b0000, также не стандартизированы. Обычный способ сделать это определить шестнадцатеричные значения для каждого бита. Например:

#define BYTE (0x01)
#define HW   (0x02)
/*etc*/

Если вы хотите установить биты, вы можете использовать:

DMA_base_ptr[DMA_CONTROL_OFFS] |= HW;

Или вы можете очистить биты с помощью:

DMA_base_ptr[DMA_CONTROL_OFFS] &= ~HW;

Современные компиляторы C отлично справляются с тривиальными встроенными функциями — без лишних затрат. Я бы сделал все абстракции функциями, чтобы пользователю не нужно было манипулировать какими-либо битами или целыми числами, и вряд ли он злоупотреблял деталями реализации.

Конечно, вы можете использовать константы, а не функции для деталей реализации, но API должен быть функциями. Это также позволяет использовать макросы вместо функций, если вы используете древний компилятор.

Например:

#include <stdbool.h>
#include <stdint.h>

typedef union DmaBase {
  volatile uint8_t u8[32];
} DmaBase;
static inline DmaBase *const dma1__base(void) { return (void*)0x12340000; }

// instead of DMA_CONTROL_OFFS
static inline volatile uint8_t *dma_CONTROL(DmaBase *base) { return &(base->u8[12]); }
// instead of constants etc
static inline uint8_t dma__BYTE(void) { return 0x01; }

inline bool dma_BYTE(DmaBase *base) { return *dma_CONTROL(base) & dma__BYTE(); }
inline void dma_set_BYTE(DmaBase *base, bool val) {
  if (val) *dma_CONTROL(base) |= dma__BYTE();
  else *dma_CONTROL(base) &= ~dma__BYTE();
}
inline bool dma1_BYTE(void) { return dma_BYTE(dma1__base()); }
inline void dma1_set_BYTE(bool val) { dma_set_BYTE(dma1__base(), val); }

Такой код должен быть сгенерирован машиной: я использую gsl (известный 0mq) для создания кодов на основе шаблона и некоторого ввода XML, в котором перечислены детали регистров.

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

Однако то, что другие, похоже, до сих пор упускали из виду, — это различные аспекты поведения аппаратных устройств с отображением памяти, которые могут быть нелогичными при работе с языком более высокого уровня, таким как C, и функциями оптимизации, предлагаемыми такими языками. Например, каждое чтение или запись аппаратного регистра иногда может иметь побочные эффекты, даже если биты не изменяются при записи. Между тем оптимизатор может затруднить определение того, когда сгенерированный код действительно читает или записывает адрес регистра, и даже когда объект C, описывающий регистр, тщательно квалифицирован как volatile, требуется большая осторожность, чтобы контролировать, когда ввод-вывод имеет место.

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

Таблица описания битов, которую вы цитируете, относится к регистру управления ядра контроллера Intel Avalon DMA. Столбец «чтение/запись/очистка» дает подсказку о том, как ведет себя конкретный бит при чтении или записи. В регистре состояния для этого устройства есть пример бита, в котором запись нуля очищает значение бита, но он может не считывать обратно то же значение, которое было записано, т. е. запись в регистр может иметь побочный эффект в устройстве, в зависимости от значения бита DONE. Интересно, что они документируют бит SOFTWARERESET как «RW», но затем описывают процедуру как двойную запись в него 1 для запуска сброса, а затем они также предупреждают: Выполнение программного сброса DMA при активной передаче DMA может привести к постоянная блокировка шины (до следующего сброса системы). Поэтому бит SOFTWARERESET не следует записывать, кроме как в крайнем случае. Управление сбросом в C потребует некоторого тщательного кодирования, независимо от того, как вы описываете регистр.

Что касается стандартов, ISO/IEC выпустила «технический отчет», известный как «ISO/IEC TR 18037», с подзаголовком «Расширения для поддержки встроенных процессоров». В нем обсуждается ряд вопросов, связанных с использованием C для управления аппаратной адресацией и вводом-выводом устройства, и, в частности, для типов битовых регистров, которые вы упоминаете в своем вопросе, он документирует ряд макросов и методов, доступных через включаемый файл, который они позвоните <iohw.h>. Если ваш компилятор предоставляет такой заголовочный файл, вы можете использовать эти макросы.

Доступны черновики TR 18037, последний из которых TR 18037(2007), хотя и предполагает довольно сухое прочтение. Однако он содержит пример реализации <iohw.h>.

Возможно, хорошим примером реальной реализации <iohw.h> является QNX. Документация QNX предлагает достойный обзор (и пример, хотя я бы настоятельно рекомендовал использовать enums для целых значений, а не для макросов): QNX <iohw.h>

Вы должны убедиться, что биты инициализированы известным значением по умолчанию, когда вы объявляете переменную для хранения их значений. В C, когда вы объявляете переменную, вы просто резервируете блок памяти по адресу, а размер блока зависит от его типа. Если вы не инициализируете переменную, вы можете столкнуться с неопределенным/неожиданным поведением, поскольку значение переменной будет зависеть от того, какое значение/состояние памяти в этом блоке было до того, как вы его объявили. Инициализируя переменную значением по умолчанию, вы очищаете этот блок памяти от его существующего состояния и переводите его в известное состояние.

Что касается удобочитаемости, вы должны использовать битовое поле для хранения значения бит. Битовое поле позволяет хранить значения битов в структуре. Это упрощает организацию, поскольку вы можете использовать запись через точку. Кроме того, вы должны обязательно прокомментировать объявление битового поля, чтобы объяснить, для чего используются различные поля. Надеюсь, это ответит на ваш вопрос. Удачи вам в C программировании!