经济学家说过，路边是不会有100元的；但如果有，你还是要捡起来。
同理，在貌似万物免费的网络时代，你是很难找到有针对性的好资料；但是如果有，希望你能认真学习吸收。
比如笔者今天写的这一篇
今天这篇文章要分享两个案例，第一个案例关于枚举，第二个案例也是关于枚举。
照旧例，先来几句简单的照本宣科。C语言枚举类型用于针对某一类对象定义一个集合，根据该类对象的实际意义将集合中的元素逐一列举出来，然后用实际取值为整数(枚举值)的文本式变量描述这些元素。
这些枚举值相当于一种助记符，可以提供对某一类对象更加贴近实际的描述，所以不仅能够增加程序的可读性，还能帮助码农们分别并记忆它们。当然，在具体的编程活动中，枚举类型也会暂时把码农从枯燥的计算机世界解脱出来，找回一点人间烟火的感觉。
科普完毕，大家可能开始纳闷了。既然从数学概念上来理解，枚举定义了一个“集合”，用整型取值来表示集合中的“元素”，逻辑上如此清晰而且简单，这还可能出什么问题？
你想，平地里可以起惊雷，阴沟里也会翻了船，编程写出个bug来，难道不是意料之外、情理之中的事情吗？
只不过，我始终搞不清楚，编程时，到底一帆风顺无惊无喜是幸福的，还是遇到问题百转千回更幸福？
说到幸福，我不禁想起范伟的一段经典台词，脑袋大脖子粗的范伟端着个大脸盘子，无神的眼睛里透露着看破红尘的沧桑，慢条斯理地回答：“什么是幸福？幸福就是我饿了，看别人拿个肉包子，那他就比我幸福；我冷了，看别人穿了一件厚棉袄，他就比我幸福；我想上茅房，就一个坑，你蹲那了，你就比我幸福。”
同样是简单的枚举，你用时没碰到问题，而我碰上了，你说咱俩到底谁比谁幸福？
二道家有一句很玄妙的话：天下本无事，庸人自扰之！
坚定地秉持唯物主义的四有青年们对这句话当然是嗤之以鼻孔兼鼻毛的。
你见或者不见，事儿就在那里，不来不去，但是按照老庄的思想，合着是我们自己没事找事了？
对此等断语，笔者只能微微一笑很倾城，接着苦笑很悲情了。因为我遇到的枚举问题就是自己瞎搞出来的。
本来，同事小周给我的代码里有这么两段代码：
void SendI2cAck(void)
{
SetSdaDir(IO_DIR_OUTPUT);
SetSdaLow();
ToogleScl();
}
void SendI2cNak(void)
{
SetSdaDir(IO_DIR_OUTPUT);
SetSdaHigh();
ToogleScl();
}
明眼人一眼就看出来了，尽管每段代码都很简单，完全没有必要改写，但是由于这两段代码的重复度很高，它们完全可以改写成一个带参量的函数。
尤其对我们这种对代码清理和重构有着偏执型冲动的人来说，让我们不重构简直比杀了我们还难受，此时不改，更待可时？
于是我三下五除二，把代码改成了下面的样子：
voidi2c_ack(e_I2cAck ack)
{
SetSdaDir(IO_DIR_OUTPUT);
if(I2C_ACK == ack){
SetSdaLow();
}else{
SetSdaHigh(); }
ToogleScl();
}
在这里，笔者定义了一个枚举类型：
typedefenum{
I2C_ACK = 0,
I2C_NAK = 1
}e_I2cAck;
然后，因为鬼才知道的原因，笔者给出了如下函数声明，也在不经意间埋下了一颗炸弹：
void i2c_ack(uint8_t ack);
看到这里，大咖们可能在捏着下巴上唏嘘的胡茬子会心一笑了，但是小白们也许还是不知所以。
尽管函数的声明误写成了i2c_ack(uint8_tack)，但是它的定义i2c_ack(e_I2cAckack)还是对的；在调用函数传递函数参量的过程中，传进去的I2C_ACK难道不还是0，I2C_NAK不还是1吧？
笔者也是这么想的，当然，刚开始的时候，我根本没有发现把声明写错的“笔误”。
不过，埋下的炸弹终会暴雷。由于重构后的程序运行不正常，我很快发现了声明和定义不一致，但是，so what？我依然不得要领，于是只好架上仿真器单步调试，看看到底会发生什么。
我追踪调试到调用i2c_ack的地方，眼见着把I2C_ACK=0传了进去，到了函数里面后，竟然没有执行if(I2C_ACK == ack)这个分支。于是我试着添加了一个uint16_t型的临时变量，将函数参量赋值给它。
不看不知道，一看吓一跳，传递进来的参量竟然成了0x5A00。
追踪到这里，又查阅了相关资料后，我似乎有些开窍了。
尽管8位整型便可以涵盖这次枚举定义中的最大值，但是枚举类型的尺寸是16位，而非所想象的8位。
这样一来，如果函数声明中的参量是16位，那么，在参量传递时，传递进来的枚举类型的I2C_ACK会被处理成16位整型的‘0’，函数会按照‘0’分支进行正确的处理。但是，由于函数声明中的参量是8位，所以，实际上传递进来的枚举类型的I2C_ACK只取了1个8位整型的‘0’；进入函数内部后，它又会被扩展成16位整型；而函数内部的变量是局部变量，地址空间都在stack里面，它扩展时会采用相邻的高位地址来填充该16位整型的高8位。这样，在传递0时，数据低八位依然是0，但是高八位就不一定了。
本来不改程序，还不会遇到这些问题，看看，是不是天下本无事，庸人自扰之？
千百年来，多少人苦苦思索，到底是什么力量，掌握着我们的命运，让我们经历痛苦和欢乐？
现在我明白了，生命不息，折腾不止，正是这种没事找事瞎折腾的力量主宰了我们的喜怒哀乐呀！
三笔者分享的第二个关于枚举类型的案例，是更加便利地使用枚举类型进行数组索引的一种新用法，不敢藏私，与诸君共享之。
如前所述，枚举的一个重要作用是增加程序的可读性，以助记符的形式帮助程序员记忆和理解代码。比如，笔者在实现软件定时器时(见文章《如何用单个定时器统一地实现多种定时应用》)就曾经以枚举类型定义了软件定时器的ID或者说软件定时器的名称。
为了让读者更加便于理解，还是要花开两朵各表一枝，叨咕叨咕软件定时器。
一个嵌入式产品中会有很多定时逻辑，最好也是最通用的处理方式便是设计一种结构体形式的软件定时器，令一个软件定时器对应一种定时逻辑，所有软件定时器构成一个结构体数组，各种定时逻辑的实现时便是在结构体数组中的成员变量上进行处理。
在这里，以可读性较强的枚举类型定义软件定时器的ID，枚举值根据各个定时应用的具体逻辑命名。比如说：
检测输入信号的周期性定时器INPUT_DETECT_PTMR；
喂看门狗的周期性定时器FEED_WATCHDOG_PTMR；
监测系统状态的周期性定时器SYS_MONITOR_PTMR；
蜂鸣器报警的多次定时器BEEPTWEET_TTMR；
总线busoff后恢复通信的单次定时器BUSOFF_TTMR等。
高智商的程序猿们打眼一看，就能从枚举值的命名上看出定时器背后的逻辑来，枚举增强程序可读性的功能可见一斑。但是，问题是，您老人家看明白了，单片机呢？
这么说吧，我们在用Timer[INPUT_DETECT_PTMR]处理定时逻辑时，怎么保证这个定时器节点就能具体对应到检测输入信号的周期性定时器？
智商在线的你肯定不会因为INPUT_DETECT_PTMR这个文本化的枚举写得如此得昭彰，就想当然地认为单片机也能“心同此心”的。实际上，如果你不做一些特殊的处理，单片机肯定不知道Timer[INPUT_DETECT_PTMR]就可以表征检测输入信号的周期性定时器的。
愿你三冬暖，愿你春不寒，愿你天黑有灯，下雨有伞。程序猿想和单片机结下此等心心相映的缘，需要做点编程工作，主动手拉手线牵线。
四显然，INPUT_DETECT_PTMR此类软件定时器节点ID想在数组中充当下标使用，下标和枚举之间要具有天然的一致性。
所幸，数组Timer[N]的下标范围是[0,N-1]间的正整数，而整型取值正是枚举类型的天然属性。所以，第一步是要保证定时器枚举也从0开始取值，然后取值依次加一，在[0,N-1]间一一占位。
第二步，在定时器数组的初始化阶段，要用整数型下标进行一次for循环，将各个软件定时器节点的ID初始化为对应的数组成员的下标，即Timer[i].timer_id = i。这里的i有三个作用，一是for循环体中的循环变量，二是数组成员下标，三是赋值给定时器ID。
在系统运行阶段，引用某个软件定时器时，以该软件定时器对应的枚举类型常量做为数组下标，引用以该ID标识的软件定时器节点，即用Timer[timer_id]直接寻址具体的软件定时器。这里有一个好处是，避免了以整型变量为下标引用定时器时，需要查找该定时器节点在软件定时器数组中对应的下标的繁琐，而且提高了程序的可读性。
其中妙处，你品，你仔细品！
扫码入群扫码添加管理员微信加入“电子产品世界”粉丝交流群
↓↓↓↓点击，查看更多新闻
)
...)