Поиск по массиву в 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, но здесь тоже много проблем, надо как-то "спасать" недопустимые символы (точка и др.).

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

Спасибо.

[Forger]

Масло-масляное.
Ваш некий реестр (я так понял по названию - константный, т.е compile-time), тогда все это можно сделать через некий h-файл, где через #define описать все параметры проекта.
Тогда нет никакого смысла создавать некий глобальный константный массив-реестр, ведь индексам этого массива все равно придется дать осмысленные имена, т.е. плодить те самые #define.

В своих проектах я использую такой файл и называю StaticSettings.h
Всем значениям даны понятные имена, чтобы в коде не фигурировали всякие "магические числа".
Править параметры проекта в одном файле проще, чем рыться по всему проекту в поисках нужного параметра.

Пример содержимого GlobalSettings.h (Keil), (все "лишнее" вырезал, чтобы не плодить новые вопросы)

Код

////////////////////////////////////////////////////////////////////////////////////////////////////////////////
// Project:        STM32L Bootloader
// Description:    Project settings
////////////////////////////////////////////////////////////////////////////////////////////////////////////////

#pragma once

////////////////////////////////////////////////////////////////////////////////////////////////////////////////
// Use Configuration Wizard in Context Menu
////////////////////////////////////////////////////////////////////////////////////////////////////////////////

// ================================================= SYSTEM ====================================================
//    <h>System

//     <o>Core Frequency [MHz]
//        <24=> 24 MHz
#define CORE_FREQUENCY_MHZ                        (24)
#define CORE_FREQUENCY_HZ                            (CORE_FREQUENCY_MHZ * 1000000UL)

//     <o>HSE Quartz Frequency [MHz]
//        <12=> 12 MHz <8=> 8 MHz
#define HSE_FREQUENCY_MHZ                            (12)

//    <o>Interrupts Stack size [bytes] <128-65536>
//    <i> Defines the stack size for all interrupts (incl. nested)
//    <i> Minimum: 128
#define INTERRUPTS_STACK_SIZE_BYTES                    (512)

//    </h>

// ============================================== APPLICATION ==================================================
//    <h>Application

//    <s.32>Application Name
#define APPLICATION_NAME                            "******"

//    <s.32>CPU Chip Name
#define CPU_CHIP_NAME                                "STM32L151RCT6A"

//    <h>Bootloader version:
//    <o>Major
#define BOOTLOADER_VERSION_MAJOR                    (1)

//    <o>Minor
#define BOOTLOADER_VERSION_MINOR                    (0)

//    <o>Build
#define BOOTLOADER_VERSION_BUILD                    (1)

//    </h>

//    <h>Hardware version:
//    <o>Major
#define HARDWARE_VERSION_MAJOR                        (1)

//    <o>Minor
#define HARDWARE_VERSION_MINOR                        (2)

//    </h>

//    </h>


.........

Вот так выглядит доступ к этим настройкам этого h-файла в Keil:






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

[jcxz]

В своих проектах я использую такой файл и называю StaticSettings.h
Править параметры проекта в одном файле проще, чем рыться по всему проекту в поисках нужного параметра.

.....и как только над проектом начинают одновременно работать >=2 программиста, начнутся проблемы с совместной модификацией этого мега-файла настроек.
А когда число программистов >=4 начинается вообще полная $опа.
Лучше разбивать настройки по отдельным файлам., принадлежащим разным программным модулям. Естественно - речь о локальных настройках. Глобальных много не должно быть и они должны быть в одном файле. Вобщем - настройки надо делить на группы, по функционалу и не класть всё в одну кучу. И сопровождение будет проще и модификации и использование в других проектах.

[Forger]

Лучше разбивать настройки по отдельным файлам., принадлежащим разным программным модулям. Естественно - речь о локальных настройках. Глобальных много не должно быть и они должны быть в одном файле. Вобщем - настройки надо делить на группы, по функционалу и не класть всё в одну кучу. И сопровождение будет проще и модификации и использование в других проектах.

Согласен, неднократно это обмозговывал, но я работаю в основном один, проекты небольшие, но много. Общая стилистика и подход в таком случае очень оправданы.
Общие константные настройки остались в одном файле, поскольку Keil умеет нормально отображать такие файлы (см. скриншот выше).
Так получает удобнее и нагляднее видеть все на одной странице экрана, все разбито по группам, "лишние" настройки пр нужде "сворачиваются".
К тому же приучил себя и многих коллег к SVN, это дисциплинирует и приучает к порядку

А вот привязку пинов в новых проектах уже разнес по соотв. модулям. Это выходит проще (пример):

Код

class PowerController : public Module
{
............

private:

............

    class Thread : public OS::Thread<PowerController, POWER_CONTROLLER_MODULE_STACK_SIZE>
    {
    public:

        inline void powerEnable() { pinPowerEnable.setToHigh(); }
        inline void powerDisable() { pinPowerEnable.setToLow(); }
............
        
    private:

        virtual void initialize();
        virtual void body();

    private:

        Hardware::DigitalOutputPin<PA15>     pinPowerEnable;
        Hardware::DigitalOutputPin<PC13>     pinEnable12V;
        Hardware::DigitalOutputPin<PC6>     pinSlaveEnable;
    
............
    
    } thread;

};