возможно ли на Си, объединить биты регистров портов микроконтроллера Опции

[another_one]

Здравствуйте.

Прошу подсказки.

С целью удобства и лучшей читабельности необходимо объединить биты портов микроконтроллера в один структурный тип или объединение.

Биты находятся в разных портах и не последовательно.

Не пойму как назначить адрес бита порта к "битовому типу" структуры.

Заранее благодарен

[defunct]

Меня как-то никогда не смущало написать пару десятков inline функций с осмысленными названиями, чтобы абстрагироваться от портов полностью.

Код

static inline void hal_SetRTS0(void)
{
    PORTG |= (1 << RTS0);
}

static inline void hal_ClrRTS0(void)
{
    PORTG &= ~(1 << RTS0);
}

static inline void hal_SetDTR0(void)
{
    PORTG |= (1 << DTR0);
}

static inline void hal_ClrDTR0(void)
{
    PORTG &= ~(1 << DTR0);
}


static inline void hal_PutRTS0(U8 val)
{
    if (val)
        hal_SetRTS();
    else
        hal_ClrRTS();
}

static inline void hal_PutDTR0(U8 val)
{
    if (val)
        hal_SetDTR();
    else
        hal_ClrDTR();
}


static inline U8 hal_GetCTS0(void)
{
    return (PINE & (1 << CTS0)) != 0;
}

static inline U8 hal_GetDCD0(void)
{
    return (PINB & (1 << DCD0)) != 0;
}

static inline U8 hal_GetDSR0(void)
{
    return (PINB & (1 << DSR0)) != 0;
}

static inline U8 hal_GetRI0(void)
{
    return (PINB & (1 << RI0)) != 0;
}
....

А уже потом где надо, эти функции с осмысленными названиями назначать структурам:

Код

typedef struct tagFLOW_CONTROL
{
    U8 enabled;   // flow control enabled (check CTS before transmitting)

    // acquiring signals cbs
    void (*On_DCD_Up)(struct tagFLOW_CONTROL *pCtrl);
    void (*On_CTS_Up)(struct tagFLOW_CONTROL *pCtrl);
    void (*On_DSR_Up)(struct tagFLOW_CONTROL *pCtrl);
    void (*On_RI_Up)(struct tagFLOW_CONTROL *pCtrl);

    // losing signals cbs
    void (*On_DCD_Down)(struct tagFLOW_CONTROL *pCtrl);
    void (*On_CTS_Down)(struct tagFLOW_CONTROL *pCtrl);
    void (*On_DSR_Down)(struct tagFLOW_CONTROL *pCtrl);
    void (*On_RI_Down)(struct tagFLOW_CONTROL *pCtrl);
    
    void (*set_rts_cb)(U8 val);
    void (*set_dtr_cb)(U8 val);
    
    U8   (*get_cts_cb)(void);
    U8   (*get_dsr_cb)(void);
    U8   (*get_dcd_cb)(void);
    U8   (*get_ri_cb)(void);
} TFLOW_CONTROL, *PFLOW_CONTROL;

...

#if (UART1_FULL_RS232)
    uart_con.u1_rs232_control.set_dtr_cb = hal_PutDTR0;
    uart_con.u1_rs232_control.set_rts_cb = hal_PutRTS0;
    uart_con.u1_rs232_control.get_cts_cb = hal_GetCTS0;
    uart_con.u1_rs232_control.get_dsr_cb = hal_GetDSR0;
    uart_con.u1_rs232_control.get_dcd_cb = hal_GetDCD0;
    uart_con.u1_rs232_control.get_ri_cb  = hal_GetRI0;

    uart_con.u1.pCtrl = &uart_con.u1_rs232_control;
    Kernel_SetTask( u1_DispatchRemoteFlowCtrlEvents, 5, TASK_PERIODIC);
#endif

Зачем нужны всякие макросы и прочая фигня для работы с портами то?

[zltigo]

Зачем нужны всякие макросы и прочая фигня для работы с портами то?

Зачем нужна вся эта фигня для работы с портами то?

[defunct]

Зачем нужна вся эта фигня для работы с портами то?

Как правило __работать__ с портами не нужно.
Нужно работать с какими-то внешними объектами, так уж получается что через порты. Порты - промежуточное звено, о котором лучше всего забыть вообще.
Упоминания о портах у меня заканчиваются в hal и нигде более в программе не вспоминаются.

[zltigo]

Нужно работать с какими-то внешними объектами, так уж получается что через порты. Порты - промежуточное звено, о котором лучше всего забыть вообще.

А вместо декларируемого HAL для "объекта" получена просто заумная работа с отдельными битам . Вы не одиноки , а заумные HAL пишут с неменьшим "успехом" и на макросах. Уму не растяжимой "красоты" пример HAL можно глянуть в SimpliciTI от TI. Ну их еще можно понять - а нефиг читать и портировать - берите и пользуйте только с нашими продуктами, как есть.

[defunct]

А вместо декларируемого HAL для "объекта" получена просто заумная работа с отдельными битам .

HAL у меня не декларирует непосредственно объекты (объекты описываются уже в соответствующих им файлах).
HAL у меня отделяет программу от МК. (Двухступенчатый HAL получается). В примере выше, TFLOW_CONTROL описан не в HAL, а в uart.h, т.к. это объект связанный с UART'ом.

Если мне нужно включить реле1 то я предпочту написать

hal_RelayOn();

если зажечь зеленый светодиод, а не красный и не желтый.

hal_GreenLedOn();

вместо

SET_BIT( PORT_HZx, PIN_HZx);
CLR_BIT( PORT_HZy, PIN_HZy);

или других извратов.


В свою очередь, это дает возможность, легко управлять временем.
Например отключить реле __через 2 секунды__ после включения, я могу сразу же при включении реле:

hal_RelayOn();
Kernel_SetCb( hal_RelayOff, 2000, SEMA_NULL);

Ну и полностью забыть о GPIO портах как о классе, вне HAL.

Вы не одиноки , а заумные HAL пишут с неменьшим "успехом" и на макросах.

на макросах такая конструкция
hal_RelayOn();
Kernel_SetCb( hal_RelayOff, 2000, SEMA_NULL);
непрокатит.

[zltigo]

если зажечь зеленый светодиод, а не красный и не желтый.

hal_GreenLedOn();

вместо

SET_BIT( PORT_HZx, PIN_HZx);
CLR_BIT( PORT_HZy, PIN_HZy);

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

Код

#define P0B_SPI0_FSEL0    BIT22
#define P0B_SPI0_FSEL1    BIT31
#define IOSET_SPI0 IO0SET
#define SPI0_SEL_MASK    (P0B_SPI0_FSEL1|P0B_SPI0_FSEL0)
....
IOSET_SPI0 = SPI0_SEL_MASK;

И даже для тех-же светодиодов уровень абстакции может, и я считаю- должен, быть заметно выше, нежели ON/OFF
void led_mode( Led_e led, Led_mode_e mode );
led_mode( LED_RED, LM_FLASH_1 );
Задается какой светодиод и десяток режимов миганий. Несклько десятков строк в отдельном файле посященном светодиодам. В файле без всяких слишком многоэтажных наворотов пишется, все , что нужно. Такой HAL, я понимаю.

[defunct]

Зачастую меня более всего устраивает и такое самое простое и незатейливое:

Код

#define P0B_SPI0_FSEL0    BIT22
#define P0B_SPI0_FSEL1    BIT31
#define IOSET_SPI0 IO0SET
#define SPI0_SEL_MASK    (P0B_SPI0_FSEL1|P0B_SPI0_FSEL0)
....
IOSET_SPI0 = SPI0_SEL_MASK;

А если проц поменялся? У меня это просто:
hal_SPI0_Prepare();

А может Вашему кернелу уже работать с объектами а не с отдельными сущностями ?

Вы о чем? Какие отдельные сущности?
Kernel работает с ___функциями____ которые описывают ___любые___ действия любых объектов.

совсем не уловил почему countdown счетчик для пина должен принципиально отличаться от таково же для модема ?

Блин... дак ничем он и не отличается.