#define 与用于寻址外设的枚举

发布于 2024-09-28 07:56:55 字数 833 浏览 3 评论 0原文

我必须在基于 ARM9 的微控制器中对外围寄存器进行编程。

例如，对于USART，我将相关的内存地址存储在enum中：

enum USART
{
    US_BASE = (int) 0xFFFC4000,
    US_BRGR = US_BASE + 0x16,
    //...
};

然后，我在函数中使用指针来初始化寄存器：

void init_usart (void)
{
    vuint* pBRGR = (vuint*) US_BRGR;
    *pBRGR = 0x030C;
    //...
}

但是我的老师说我最好使用#定义，例如：

#define US_BASE (0xFFFC4000)
#define US_BRGR (US_BASE + 0x16)
#define pBRGR   ((vuint*) US_BRGR)

void init_usart (void)
{
    *pBRGR = 0x030C;
}

像这样，他说，你没有在堆栈中分配指针的开销。

就我个人而言，我不太喜欢#define，也不喜欢其他预处理器指令。所以问题是，在这种特殊情况下，#define 真的值得使用而不是 enum 和堆栈分配指针吗？

相关问题：想要在基于 ARM9 的芯片中配置特定的外设寄存器< /a>

原文

I have to program peripheral registers in an ARM9-based microcontroller.

For instance, for the USART, I store the relevant memory addresses in an enum:

enum USART
{
    US_BASE = (int) 0xFFFC4000,
    US_BRGR = US_BASE + 0x16,
    //...
};

Then, I use pointers in a function to initialize the registers:

void init_usart (void)
{
    vuint* pBRGR = (vuint*) US_BRGR;
    *pBRGR = 0x030C;
    //...
}

But my teacher says I'd better use #defines, such as:

#define US_BASE (0xFFFC4000)
#define US_BRGR (US_BASE + 0x16)
#define pBRGR   ((vuint*) US_BRGR)

void init_usart (void)
{
    *pBRGR = 0x030C;
}

Like so, he says, you don't have the overhead of allocating pointers in the stack.

Personally, I don't like #defines much, nor other preprocessor directives.
So the question is, in this particular case, are #defines really worth using instead of enums and stack-allocated pointers?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

翻身的咸鱼 2024-10-05 07:56:55

我一直喜欢的方法是首先定义一个反映外设寄存器布局的结构

typedef volatile unsigned int reg32; // or other appropriate 32-bit integer type
typedef struct USART
{
    reg32 pad1;
    reg32 pad2;
    reg32 pad3;
    reg32 pad4;
    reg32 brgr;
    // any other registers
} USART;

USART *p_usart0 = (USART * const) 0xFFFC4000;

，然后在代码中我可以使用

p_usart0->brgr = 0x030C;

当您有相同类型外设的多个实例时，这种方法更加清晰：

USART *p_usart1 = (USART * const) 0xFFFC5000;
USART *p_usart2 = (USART * const) 0xFFFC6000;

用户 sbass 提供了指向一个优秀的专栏 Dan Saks 提供了有关该技术的更多详细信息，并指出了它相对于其他方法的优势。

如果您足够幸运能够使用 C++，那么您可以为外围设备上的所有常见操作添加方法，并很好地封装设备的特性。

The approach I've always preferred is to first define a struct reflecting the peripherals register layout

typedef volatile unsigned int reg32; // or other appropriate 32-bit integer type
typedef struct USART
{
    reg32 pad1;
    reg32 pad2;
    reg32 pad3;
    reg32 pad4;
    reg32 brgr;
    // any other registers
} USART;

USART *p_usart0 = (USART * const) 0xFFFC4000;

Then in code I can just use

p_usart0->brgr = 0x030C;

This approach is much cleaner when you have multiple instances of the same sort of peripheral:

USART *p_usart1 = (USART * const) 0xFFFC5000;
USART *p_usart2 = (USART * const) 0xFFFC6000;

User sbass provided a link to an excellent column by Dan Saks that gives much more detail on this technique, and points out its advantages over other approaches.

If you're lucky enough to be using C++, then you can add methods for all the common operations on the peripheral and nicely encapsulate the devices peculiarities.

回复收藏 0 原文

空名 2024-10-05 07:56:55

我担心 enum 对于这样的任务来说是一个死胡同。该标准将enum常量定义为int类型，因此通常它们不与指针兼容。

有一天，在具有 32 位 int 和 64 位指针的架构上，您可能会遇到一个不适合 int 的常量。目前尚不清楚会发生什么。

另一方面，enum 将在堆栈上分配某些内容的论点是无效的。它们是编译时常量，与函数堆栈无关，也与您通过宏指定的任何常量无关。

回复收藏 0 原文

木有鱼丸 2024-10-05 07:56:55

Dan Saks 就此嵌入式系统编程撰写了许多专栏。这是他的最新文章之一。他讨论了 C、C++、枚举、定义、结构、类等，以及为什么您可能会一一讨论。绝对值得一读，并且总是好的建议。

回复收藏 0 原文

相对绾红妆 2024-10-05 07:56:55

根据我的经验，使用 #define 来处理此类事情的一个重要原因是它更像是嵌入式社区中使用的标准习惯用法。

使用枚举而不是#define 会产生来自教师（以及将来的同事）的问题/评论，即使使用其他技术可能有其他优点（例如不破坏全局标识符命名空间）。

我个人喜欢使用枚举来表示数字常量，但有时您需要按照您正在工作的内容和地点执行惯常的操作。

然而，性能不应该成为问题。

回复收藏 0 原文

辞旧 2024-10-05 07:56:55

答案总是按照老师的要求去做，通过课程，然后根据你自己的问题，找出他们的理由是否有效，并形成你自己的意见。你赢不了学校，不值得。

在这种情况下，很容易编译为汇编程序或反汇编以查看枚举和定义之间的差异（如果有）。

我建议使用定义而不是枚举，因为编译器对枚举感到不舒服。我非常不鼓励像使用指针那样使用指针，我见过每个编译器都无法准确生成所需的指令，这种情况很少见，但当它发生时，你会想知道你过去几十年的编码是如何工作的。指向结构或其他任何东西要糟糕得多。我经常因此而受到批评，并且希望这一次也能如此。街区周围有太多英里，修复了太多带有这些问题的损坏代码，以至于忽略了根本原因。

回复收藏 0 原文