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

[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);
непрокатит.

[singlskv]

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

а почему не прокатит-то ?
почему макрос "Kernel_SetCb" не сможет укладывать countdown значение 2000 в соответствующую ячейку массива ?

[defunct]

а почему не прокатит-то ?
почему макрос "Kernel_SetCb" не сможет укладывать countdown значение 2000 в соответствующую ячейку массива ?

Потому что Kernel_SetCb делает то что написано в названии - одноразово вызывает заданную функцию по таймауту или по событию в зависимости от того, что произойдет раньше.
Если вместо функции первым параметром дадите макрос (CLR/SET_PIN_X), думаю очевидно, что программа даже нескомпилится, т.к. у макроса не может быть адреса.

[singlskv]

Потому что Kernel_SetCb делает то что написано в названии - одноразово вызывает заданную функцию по таймауту или по событию в зависимости от того, что произойдет раньше.
Если вместо функции первым параметром дадите макрос (CLR/SET_PIN_X), думаю очевидно, что программа даже нескомпилится, т.к. у макроса не может быть адреса.

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

[defunct]

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

Вы читали о чем я пишу? Я пишу что, я считаю, надо забыть о портах, номерах пинов, и т.п. чтобы спалось спокойно.

Kernel у меня работает с функциями и с задачами а не с идентификаторами пинов.
Любое __действие__ в общем виде всегда можно описать функцией. Номером пина либо еще какой-то фигней, любое действие не опишешь.

Точно также как в примере с реле я работаю и с более сложными процессами:

modem_Dial();
Kernel_SetCb( modem_Dial, 60000, SEMA_NULL); // повторный дозвон через минуту если не удалось дозвониться.

Ровным счетом никаких отличий

Ну как же никаких...
Вы можете поставить макрос в очередь задачь?
А инлайн функцию - запросто, компилер поймет что от него хотят. Там где можно заинлайнит, там где нужно вызовет по адресу.

[Dog Pawlowa]

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

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

Если предусматривается какая-то более сложная логика, то это не совсем порт, а, скажем объект какой-то типа звукового сигнала со своими параметрами, или моргающего светодиода, как в примере zltigo. Для обслуживания такого "объекта" прописывается свой сервис в каком-нить бэкграунде. Его параметры устанавливаются типа так:
void Beep (unsigned int ms, char beeps_qty), после чего "приложение" забывает о существовании этого объекта. Типичная организация системы без ОС.

В Вашем варианте смешаны в кучу и быстрые действия и медленные, в результате быстрые могут оказаться не такими быстрыми, как иногда требуется.