c - 嵌入式开发的 Pin Mask 约定

Question

对于嵌入式 C 应用程序，我一直使用以下约定来定义 GPIO 引脚掩码:

“传统”示例:具有 32 位 GPIO 端口的 32 位 CPU

置位 GPIO 输出寄存器中的 bit5 以打开 LED。

#define BIT5 (1u << 5)      //or maybe even just hardcode as 0x20
...
#define PIN_LED_CTRL (BIT5) //LED_CTRL is Pin #5
...
void gpio_set(uint16_t pin_mask) {
    GPIO_OUT |= pin_mask;
}
...
//turn the led on
gpio_set(PIN_LED_CTRL);

在最近的一个多开发人员嵌入式项目中，一位开发人员选择了以下语法

'替代示例:具有 32 位 GPIO 端口的 32 位 CPU

#define PIN(x) (1u << (x##_PIN_NUM))
...
#define LED_CTRL_PIN_NUM (5)
...
void gpio_set(uint16_t pin_mask) {
    GPIO_OUT |= pin_mask;
}
...
//turn the led on
gpio_set(PIN(LED_CTRL));

没有给出关于为什么选择它的真正明确的解释。与所有很少记录的代码一样，它似乎足够神秘，足以“清晰”地保证其实现。开发人员肯定知道我不知道的事情。在这种情况下，这个人是来自 CPU 驱动程序世界的聪明人。

异议

我根本不喜欢“alt”方法。它似乎太可爱了。但我能给出的唯一理由是:

• 'LED_CTRL' 不是编译时常量
  • 此外，您无法在 IDE 中下降/检查它
• 'LED_CTRL_PIN_NUM' 与 uri-naming-schema 完全相反
  • 例如PIN_NUM_abc 是首选
• 没有其他人这样做*
• 看起来很奇怪

但这在我看来就像是在提示；这些都不是真正的反对意见使用“alt”方法。

问题

为什么有人会使用“alt”方法？这可能是桌面驱动程序领域中注册使用的传世之作吗？

是否有任何常见的嵌入式 MCU 库、替代目标或编程语言使用这种“alt”方法？

谢谢!

*在一天结束时；我可能会坚持“它看起来很奇怪”:)。

Answer 1

两种方法几乎一样，只是风格不同，但问题是一样的。

通常情况下，pin 不是仅由位号定义的，您还需要知道端口。

所以在更改端口时，不仅需要修改定义，还需要修改代码。

#define PIN_LED_CTRL (BIT5) //LED_CTRL is Pin #5
...
void gpio_set_port2(uint16_t pin_mask) {
    GPIO2_OUT |= pin_mask;
}
...
//turn the led on
gpio_set_port2(PIN_LED_CTRL);

我更喜欢只定义一次引脚，所有不同的依赖项都是通过宏或函数构建的。

#define HW_SPI_CLOCK    2,5    // uses port2,bit5
#define HW_RESET_EXT    4,3    // uses port4,bit3

然后我用一些宏来定义获取端口方向，pushPull和其他寄存器。
这些宏几乎不依赖于平台和工具链。

/**
 * Generic GH-Macros
 */
#define PASTE2(a,b)       a##b
#define PASTE3(a,b,c)     a##b##c
#define __PASTE3(a,b,c)     PASTE3(a,b,c)
#define PASTE4(a,b,c,d)   a##b##c##d
#define PASTE6(a,b,c,d,e,f)     a##b##c##d##e##f
#define __PASTE6(a,b,c,d,e,f)     PASTE6(a,b,c,d,e,f)

#define GH_PORT(port,pin)       port
#define GH_PIN(port,pin)       pin
#define GPIO_PIN(gh)      __PASTE6(FIO,GH_PORT(gh),PIN_bit.P,GH_PORT(gh),_,GH_PIN(gh))
#define GPIO_DIR(gh)      __PASTE6(FIO,GH_PORT(gh),DIR_bit.P,GH_PORT(gh),_,GH_PIN(gh))