#define的常见用法

 

先来讲一讲#define的优点与缺点: 
[优点] 
当在程序中想要修改某一个值得时候,而且这个值又在很多地方引用。这时候就能体现出宏定义的强大优点了。 
例如:

#define LINK LED0   //定义LINK的灯为LED0

因为在程序中我们可能很多地方要对LINK灯进行操作,当我们想换LINK灯的时候,直接将:

#define LINK LED1

这样就很方便了,不用一处处去找,而且不用担心有漏掉的可能。 
[缺点] 
宏定义有一些缺点: 
(1) 无法对宏定义中的变量进行类型检查 
此缺点,是相对于const变量来说的 
[define与const的区别的简单总结]

define定义的变量,是Compile-Time时期的变量,系统在编译时候,就将其全部替换,而不会对其变量进行类型等属性检查,相对不是很安全,可能存在潜在的问题,而没有发现. 
正因为其仅仅是编译时期替换,所以其定义的变量,是不会在运行时候分配内存的,不占用内存空间. 
const定义的变量,是 Run-Time时期的变量,如果类型不匹配,系统在运行时候,就会发现并提示或报错,对应的,const变量在运行时期,也是一种变量,系统会为其分配内存. 
(2) 边界效应 
A. 未加括号带来的边界效应 
由于宏定义的时候,其各个分量未加括号,而在使用宏定义的时候,传递的参数是变量的表达式,然后经过系统展开后,由于优先级的原因,导致其结果不是你所希望的. 
[例子]

#define MUL(A,B) A*B

而在使用的时候,这样的调用: 
int a=1,b=2,c=3,d=0; 
d=MUL(a+b,c) 
经过编译时候展开,就变成了 
d=a+b*c 
而不是我们所希望的 
d=(a+b)*c 
[解决办法] 
其解决办法也很简单,就是给每个分量,都加上括号,就可以避免此类问题 
即,在宏定义的时候,如此定义:

#define MUL(A,B) ((A)*(B))
  1. define的变体,即#ifndef,可以防止头头文件的重复引用 
    [释] 
    #ifdef和 #define组合,一般用于头文件中,用以实现防止多个文件对此同一个头文件的重复引用.实际使用中,即使你的头文件暂时没有被多个文件所引用,为了增加程序可读性,移植性,健壮性等,还是最好都加上。其用法一般为:
#ifndef <标识>
#define <标识>
………   // include or define sth.
#endif

<标识>在理论上来说可以是自由命名的,但每个头文件的这个“标识”都应该是唯一的;标识的命名规则一般是头文件名全大写,前后加下划线,并把文件名中的“.”也变成下划线, 
如:stdio.h对应的就是:

#ifndef _STDIO_H_
#define _STDIO_H_
………   // include or define sth.
#endif

举个例子

#ifndef CHARDEV_H
#define CHARDEV_H

#include


#define MAJOR_NUM 100

#endif

例子中的chardev.h中,就用到了

#ifndef CHARDEV_H
#define CHARDEV_H#endif

这样做之后,以后某个文件引用此头文件,就包含了chardev.h文件,而其他文件如果再引用此头文件的话,编译器那么就会判断出来,已经define了CHARDEV_H,已经有其他文件引用了此文件,so,the complier will not include this header file. 就可以发现解决重复引用头文件的问题了.

2. #define的变体,即#ifdef,可以实现加入自己需要的模块(源文件) 
[例子] 
在源文件中加入

#ifdef MYSELF_H
#include "myself.c"
#endif

可以实现在源文件中加入myself.c的代码,将其实现的功能加进来, 即加入了myself模块 
3. 简单的define定义

#define MAXTIME 1000

一个简单的MAXTIME就定义好了,它代表1000,如果在程序里面写

if(i<MAXTIME){.........}

编译器在处理这个代码之前会对MAXTIME进行处理替换为1000。

这样的定义看起来类似于普通的常量定义CONST,但也有着不同,因为define的定义更像是简单的文本替换,而不是作为一个量来使用,这个问题在下面反映的尤为突出。 
4. define的“函数定义” 
define可以像函数那样接受一些参数,如下

#define max(x,y) (x)>(y)?(x):(y);

这个定义就将返回两个数中较大的那个,看到了吗?因为这个“函数”没有类型检查,就好像一个函数模板似的,当然,它绝对没有模板那么安全就是了。可以作为一个简单的模板来使用而已。

但是这样做的话存在隐患,例子如下:

#define Add(a,b) a+b;

在一般使用的时候是没有问题的,但是如果遇到如:c * Add(a,b) * d的时候就会出现问题,代数式的本意是a+b然后去和c,d相乘,但是因为使用了define(它只是一个简单的替换),所以式子实际上变成了

c*a + b*d

另外举一个例子:

#define pin (int*);
pin a,b;

本意是a和b都是int型指针,但是实际上变成int* a,b; 
a是int型指针,而b是int型变量。 
这是应该使用typedef来代替define,这样a和b就都是int型指针了。 
即:

typedef pin (int *)

pin a,b;

此时:a和b都是 int*型的。 
所以我们在定义的时候,养成一个良好的习惯,建议所有的层次都要加括号。 
5. 宏的单行定义

#define A(x) T_##x
#define B(x) #@x
#define C(x) #x

我们假设:x=1,则有:

A(1)------〉T_1
B(1)------〉'1'
C(1)------〉"1"

6. define的多行定义

define可以替代多行的代码,例如MFC中的宏定义(非常的经典,虽然让人看了恶心)

#define MACRO(arg1, arg2) do { /
/* declarations */ /
stmt1; /
stmt2; /
/* ... */ /
} while(0) /* (no trailing ; ) */

关键是要在每一个换行的时候加上一个”/”

7 .在大规模的开发过程中,特别是跨平台和系统的软件里,define最重要的功能是条件编译。

即:

#ifdef WINDOWS
......
......
#endif
#ifdef LINUX
......
......
#endif

可以在编译的时候通过#define设置编译环境

8. 如何定义宏、取消宏

//定义宏
#define [MacroName] [MacroValue]
//取消宏
#undef [MacroName]
//普通宏
#define PI (3.1415926)

带参数的宏
#define max(a,b) ((a)>(b)? (a),(b))

关键是十分容易产生错误,包括机器和人理解上的差异等等。

9. 条件编译

#ifdef XXX…(#else) … #endif
例如
#ifdef DV22_AUX_INPUT
#define AUX_MODE 3 
#else
#define AUY_MODE 3
#endif
#ifndef XXX … (#else) … #endif

<think>好的,用户问的是这两个宏定义:#define LED_RED_GPIO GPIOB 和 #define LED_RED_PIN GPIO_Pin_5。首先,我需要确定用户的使用场景。可能是在嵌入式开发,特别是使用STM32的情况,因为这些宏常见于STM32的库中。用户可能是刚开始学习,或者在做硬件相关的项目,需要控制LED。 接下来,用户的身份可能是一个嵌入式系统的新手,或者有单片机基础但刚接触STM32的开发者。他们可能对如何配置GPIO引脚还不熟悉,所以需要解释这两个宏的作用以及它们如何配合使用。 用户的真实需求是理解这两个宏定义的意义以及它们在代码中的用途。深层需求可能包括如何在实际项目中应用这些宏来控制LED,比如初始化GPIO,设置引脚模式,以及如何通过这两个宏来操作特定的引脚。 然后,我需要拆解这两个宏。第一个宏LED_RED_GPIO指向GPIOB,表示LED连接到GPIOB端口。第二个宏LED_RED_PIN是GPIO_Pin_5,对应引脚5。在STM32中,每个GPIO端口有多个引脚,这两个宏一起指定了具体的端口和引脚号。 接下来,要说明这两个宏在代码中的典型应用场景。例如,在初始化函数中,配置该引脚为推挽输出,然后在主循环中控制引脚的电平来点亮或熄灭LED。同时,需要提到外设基地址的映射,比如GPIOB的地址在头文件中定义,用户不需要手动计算。 可能还需要指出为什么使用宏定义,主要是为了提高代码的可读性和可维护性,方便后续修改硬件连接时只需调整宏而不用改动所有代码。此外,可能需要提醒用户检查硬件连接是否确实将LED连接到PB5,并确认是否正确配置了时钟等步骤。 最后,确保解释清晰,结构合理,分点说明,让用户能够逐步理解每个部分的作用,并能够应用到实际项目中。</think>在嵌入式开发中,`#define LED_RED_GPIO GPIOB` 和 `#define LED_RED_PIN GPIO_Pin_5` 这两个宏定义是用于硬件抽象的典型做法。它们的核心作用是为**红色LED的硬件连接**提供可读性强的标识符。以下是分层解析: --- ### 一、代码解析 1. **硬件端口定义** `#define LED_RED_GPIO GPIOB` - 表示红色LED连接的**GPIO端口**是`GPIOB`(即STM32的B组GPIO) - 在STM32中,GPIO分为A、B、C等组,每组有16个引脚 2. **硬件引脚定义** `#define LED_RED_PIN GPIO_Pin_5` - 表示红色LED连接在`GPIOB`的**第5号引脚**(即PB5) - `GPIO_Pin_5`是STM32标准库中预定义的宏,对应二进制值`0x0020`(即第5位为1) --- ### 二、实际应用场景 1. **GPIO初始化配置** 在代码中通常会通过这两个宏配置引脚模式: ```c GPIO_InitTypeDef GPIO_InitStruct; GPIO_InitStruct.GPIO_Pin = LED_RED_PIN; // 指定引脚 GPIO_InitStruct.GPIO_Mode = GPIO_Mode_Out_PP; // 推挽输出模式 GPIO_Init(LED_RED_GPIO, &GPIO_InitStruct); // 应用配置到GPIOB ``` 2. **控制LED状态** 操作LED时直接使用宏提高可读性: ```c GPIO_SetBits(LED_RED_GPIO, LED_RED_PIN); // 点亮LED(高电平) GPIO_ResetBits(LED_RED_GPIO, LED_RED_PIN); // 熄灭LED(低电平) ``` --- ### 三、硬件层关联 1. **外设基地址映射** - `GPIOB`在STM32头文件(如`stm32f10x.h`)中已定义: ```c #define GPIOB ((GPIO_TypeDef *) GPIOB_BASE) ``` - `GPIOB_BASE`对应芯片内存中GPIOB外设的物理地址 2. **引脚位掩码** - `GPIO_Pin_5`的二进制形式为`0010 0000`,用于在寄存器中定位特定引脚 --- ### 四、设计优势 1. **可维护性** 若硬件修改(如LED改接到PC7),只需修改宏定义: ```c #define LED_RED_GPIO GPIOC #define LED_RED_PIN GPIO_Pin_7 ``` 2. **代码可读性** 直接通过`LED_RED_GPIO`和`LED_RED_PIN`理解硬件连接关系 --- ### 五、验证建议 1. **检查硬件连接** 确认开发板LED实际连接的物理引脚是否为PB5 2. **时钟使能** 确保已启用GPIOB的时钟: ```c RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOB, ENABLE); ``` 通过这种硬件抽象方式,开发者能更专注于功能实现,而无需频繁查阅硬件手册。
评论 7
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值