Поиск по массиву в compile time на С Опции

[amaora]

Есть массив регистров, ссылки на переменные с именами и некоторыми параметрами, для удобного доступа по разным интерфейсам и конфигурирования устройства. Допустим вот так объявленный,

Код

typedef struct {

    const char        *sym;

    const char        *fmt;
    int            mode;

    union {

        float        *f;
        int        *i;
    }
    link;

    void            (* proc) (const void *reg, void *lval, const void *rval);
}
reg_t;

#define REG_E(link, extra, unit, fmt, mode, proc)    { #link extra "\0" unit, fmt, mode, \
                            { (void *) &link }, (void *) proc }

#define REG(link, unit, fmt, mode, proc)    REG_E(link, "", unit, fmt, mode, proc)

const reg_t        regfile[] = {

    REG(hal.USART_baud_rate,        "",    "%i",    REG_CONFIG, NULL),
    REG(hal.PWM_freq_hz,            "Hz",    "%i",    REG_CONFIG, NULL),
    REG(hal.PWM_dead_time_ns,        "ns",    "%i",    REG_CONFIG, NULL),
    REG(hal.ADC_reference_voltage,        "V",    "%3f",    REG_CONFIG, NULL),
    REG(hal.ADC_current_shunt_resistance,    "Ohm",    "%4e",    REG_CONFIG, NULL),
...
    REG(pm.probe_speed_ramp,    "rad/s",    "%2f",    REG_CONFIG, NULL),
    REG_E(pm.probe_speed_ramp, "_rpm",    "rpm",    "%2f",    REG_NORMAL, &reg_proc_rpm),
...

Регистры адресуются по именам или по номерам. Имена достаточно постоянны, а номера могут изменяться в следующих версиях. В этом проблема, нельзя в коде просто взять ссылку на регистр по номеру regfile[n], номер может измениться. Искать по имени в compile time слишком сложно, средствами C и препроцессора не обойтись. По адресам переменных нельзя, они могут повторятся. Какие еще варианты?

Сейчас думаю, генерировать из объявления массив макросов вида #define REG_hal_USART_baud_rate 0, но здесь тоже много проблем, надо как-то "спасать" недопустимые символы (точка и др.).

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

Спасибо.

[DASM]

А наоборот как ?

Код

typedef enum {t1, t2, t3 = (char) 100} myE;
#pragma pack (1)
    struct  My
    {
        myE e1;
        myE e2;
        myE e3;
    };
#pragma pack ()
int main()
{
    cout << offsetof(My, e1) << endl;
    cout << offsetof(My, e2) << endl;

}
...... e1 e2 e3 как были int так и остались.
Компилятору по барабану все эти (char), он, как я понимаю, обязан уложиться в int и не более. Попросить его ограничиться char не могу, это compilator depended
Можно было бы как

Код

enum class myE : char {t1, t2, t3, eMAX};
#pragma pack (1)
    struct  My
    {
        myE e1;
        myE e2;
        myE e3;
    } my;
#pragma pack ()
int main()
{
    for (myE i = myE::t1; i < myE::eMAX; i++)

Только вот так не получится , да и понятно почему (второе изображение)
Выходит в С слишком опасно, в С++ слишком неудобно либо неэффективно. Решение есть, вот оно и ищется

Эскизы прикрепленных изображений

 

[Forger]

По-ходу я ошибся с явным указанием типа enum, у меня не работает
Нужно это делать ключами компилятора: http://www.keil.com/support/man/docs/armcl...11640303038.htm

Кстати, у меня pragma pack вот так используется:

Код

#pragma pack(push, 1)
....
#pragma pack(pop)

[DASM]

По-ходу я ошибся с явным указанием типа enum, у меня не работает
Нужно это делать ключами компилятора: http://www.keil.com/support/man/docs/armcl...11640303038.htm

Кстати, у меня pragma pack вот так используется:

Код

#pragma pack(push, 1)
....
#pragma pack(pop)

я думал, что могут быть такие ключи, но это еще меньше делать хочется. Если я делаю такие мерзости как явное приведение типов, то стараюсь писать static_cast <>, такая многословность в таких случаях в тему, при просмотре кода понимаю, что писав это понимал что делаю и чем чревато. А вот ключ компилятора ( если он есть) будем забыт сразу, в коде не видно. Признаюсь, особенно не мучался ранее стандартами, в голове засело, что enum это int, то ли книги так пишут, что непонятно. На самом деле enum это может и char и short и int быть, и , насколько помню, при сравнении такого enum с другим типом, имеющим неявное преобразование не будет даже warning.. А вот тут споткнулся

[Forger]

А вот тут споткнулся

В "протокольных" делах enum не использую, но очень активно использую union:

CODE

static const struct
{
// Device answers
uint8_t Ok;
uint8_t Unknown;
uint8_t WrongFirmware;
uint8_t WriteError;

// Common commands
uint8_t GetDeviceInfo;
uint8_t DeviceReset;
uint8_t BootloaderActivate;

// Bootloader commands
uint8_t GetFirmwareFitures;
uint8_t ChunkUpload;
uint8_t PageWrite;
uint8_t FirmwareVersionUpdate;

// Secret commands
.....
}
Command =
{
0x00, 0x01, 0x02, 0x03, // Device answers
0xA0, 0xA1, 0xA2, // Common commands
0xE0, 0xE1, 0xE2, 0xE3, // Bootloader commands
...... // Secret commands
};

.....

#if defined ( __CC_ARM ) // Arm Compiler v5
#pragma anon_unions
#endif

#pragma pack(push, 1)

struct DeviceInfo
{
Settings::Version bootloaderVersion;
Settings::Version firmwareVersion;
Settings::Version hardwareVersion;
Settings::SerialNumber serialNumber;
.......
};

struct FirmwareFitures
{
uint32_t baseAddr; // Firmware Base Address
uint32_t memorySize; // Flash memory size (including Bootloader and Firmware regions both)
uint8_t chunkSize;
uint16_t pageSize;
};

struct FirmwareCheckZone
{
uint16_t crc16;
uint16_t sizeKb;
};

......

struct Report // 64 bytes
{
uint8_t command;
union
{
uint8_t payLoad[REPORT_SIZE_BYTES - sizeof(command)];

struct DeviceInfo deviceInfo;

struct FirmwareFitures firmwareFitures;

struct
{
uint32_t addr;
uint8_t data[FIRMWARE_CHUNK_SIZE_BYTES];
} chunk;

struct
{
uint32_t addr;
} page;

...............
};
};

#pragma pack(pop)

Оба кода одинаково работают на Qt5 и под keil (v5 и v6), что очень удобно.
Доп. ключей компиляции не использую.

Использование const struct вместо define и enum (ну, не люблю их) позволяет мне делать код более читаемым.
Разбор пакетов, в которых идут разношерстные данные благодаря union делает его очень компактным и также хорошо читаемым:

CODE

// в rxReport - уже лежит полученный пакет (USB hid)

if (rxReport.command == Command.GetDeviceInfo)
{
txReport.deviceInfo.bootloaderVersion = settings.getBootloaderVersion();
txReport.deviceInfo.firmwareVersion = settings.getFirmwareVersion();
txReport.deviceInfo.hardwareVersion = settings.getHardwareVersion();
txReport.deviceInfo.serialNumber = settings.getSerialNumber();
......

txReport.command = Command.Ok;
sendReport(txReport);
return;
}

if (rxReport.command == Command.GetFirmwareFitures)
{
txReport.firmwareFitures.baseAddr = FIRMWARE_BASE_ADDRESS;
txReport.firmwareFitures.memorySize = FLASH_SIZE_KB * 1024UL;
....
txReport.command = Command.Ok;
sendReport(txReport);
return;
}

if (rxReport.command == Command.DeviceReset)
{
txReport.command = Command.Ok;
sendReport(txReport);
NVIC_SystemReset();
}

if (rxReport.command == Command.BootloaderActivate)
{
settings.killFirmware();
NVIC_SystemReset();
}

if (rxReport.command == Command.SerialNumberChange)
{
settings.setSerialNumber(rxReport.deviceInfo.serialNumber); // Other "deviceInfo" fields are ignored
txReport.command = Command.Ok;
sendReport(txReport);
return;
}

.....

Никаких адских массивов и массы магических чисел в качестве индесов для доступа к его содержимого.
Через полгода/год открою этот код и сразу пойму, что тут происходит.