Доступные только для чтения регистры, отображаемые в памяти, определенные с помощью volatile const в C, но только volatile в C++

Поскольку ни один объект RoReg никогда не создается, нет веской причины опускать квалификатор const в typedef.

Каждое использование RoReg находится либо в макросе, который определяет указатель на тип...

#define REG_WDT_SR (*(RoReg*)0x400E1A58U) /**< \brief (WDT) Status Register */

...или объявление struct, доступ к которому осуществляется с помощью аналогичного макроса.

typedef struct {
  WoReg WDT_CR; /**< \brief (Wdt Offset: 0x00) Control Register */
  RwReg WDT_MR; /**< \brief (Wdt Offset: 0x04) Mode Register */
  RoReg WDT_SR; /**< \brief (Wdt Offset: 0x08) Status Register */
} Wdt;

#define WDT        ((Wdt    *)0x400E1A50U) /**< \brief (WDT) Base Address */

Даже с квалификатором const код должен вести себя одинаково как на C, так и на C++.

Возможно, автор неверно истолковал стандарт. Чтобы гарантировать, что структура C++ имеет тот же макет, что и в C, требуется, чтобы класс «имел такой же контроль доступа (пункт 11) для всех нестатических элементов данных». Автор мог ошибочно принять const и volatile за спецификаторы управления доступом. Если бы это было так, то вы бы хотели, чтобы все члены структуры имели одинаковые квалификаторы cv, чтобы обеспечить совместимость макетов C и C++ (и аппаратных средств). Но именно public, protected и private определяют контроль доступа.

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

Как упоминалось @fanl, const действительно изменяет связь глобальных переменных по умолчанию в C++ и не позволяет определять переменную без инициализации.

Но есть лучшие способы получить внешнюю связь, чем удаление const. Использование зарезервированных массивов в заголовочном файле, на который ссылается Крис, также очень хрупко. Я бы сказал, что этот код оставляет много возможностей для улучшения — не подражайте ему.

Более того, эти переменные не определяются (что привело бы к выбору адреса компилятором и компоновщиком), доступ к ним всегда осуществляется через указатели, причем адрес фиксируется в соответствии с картой памяти.

Для заголовков, предназначенных исключительно для использования C++, я делаю это так (карта памяти, соответствующая чипу TI Stellaris).

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

template<uintptr_t extent>
struct memory_mapped_peripheral
{
    char data[extent];
    volatile       uint32_t* offset( uintptr_t off )       { return reinterpret_cast<volatile       uint32_t*>(data+off); }
    volatile const uint32_t* offset( uintptr_t off ) const { return reinterpret_cast<volatile const uint32_t*>(data+off); }
};

struct LM3S_SYSTICK : private memory_mapped_peripheral<0x1000>
{
    volatile       uint32_t& CTRL   (void)             { return offset(0x010)[0]; }
    volatile       uint32_t& RELOAD (void)             { return offset(0x014)[0]; }
    volatile       uint32_t& CURRENT(void)             { return offset(0x018)[0]; }
}* const SYSTICK = reinterpret_cast<LM3S_SYSTICK*>(0xE000E000);

struct LM3S_NVIC : private memory_mapped_peripheral<0x1000>
{
    volatile       uint32_t& EN    (uintptr_t i)       { return offset(0x100)[i]; }
    volatile       uint32_t& DIS   (uintptr_t i)       { return offset(0x180)[i]; }
    volatile       uint32_t& PEND  (uintptr_t i)       { return offset(0x200)[i]; }
    volatile       uint32_t& UNPEND(uintptr_t i)       { return offset(0x280)[i]; }
    volatile const uint32_t& ACTIVE(uintptr_t i) const { return offset(0x300)[i]; }
    volatile       uint32_t& PRI   (uintptr_t i)       { return offset(0x400)[i]; }
    volatile       uint32_t& SWTRIG(void)              { return offset(0xF00)[0]; }
}* const NVIC = reinterpret_cast<LM3S_NVIC*>(0xE000E000);