Context

去年我们接手了一个G3PLC的项目,这也算是首次正正规规的做一次嵌入式了,也是我第一次在自己的电脑上安装并使用keil,有点小兴奋。

一开始我们心里还是蛮害怕的,因为协议很多,我们嵌入式基础很弱,一直担心最后这个项目无法完成。不过,到了今年6月,我们竟然真的写完了!

俗话说得好,写程序花20%的时间,调试花80%的时间~ 当然这是他们嵌入式行业的俗话~

于是我们开始了紧张的调试,一开始还蛮顺利,遇到了问题基本上可以非常快的定位到问题点,然后也可以非常快的解决。

直到…

StackTrace

先来看两个结构体

adp.h:

typedef struct _ROUTINGTABLE_
{
    uSHORT    DestinationAddress; //16
    uSHORT    NextHopAddress; //16
    uSHORT    RouteCost; //16
    unsigned    HopCount:4;
    unsigned    WeakLinkCount:4;
    uSHORT    ValidTime;//16
}_ROUTINGTABLE,*_pROUTINGTABLE;

mmu.h:

typedef struct _ROUTINGTABLEITEM_
{
    uSHORT    destination; //2
    uSHORT nextHop; //2
    uSHORT cost; //2
    unsigned hopCount:4; //0.5
    unsigned weakLinkCount:4; //0.5
    uSHORT    ValidTime; //2
}_ROUTINGTABLEITEM, *_pROUTINGTABLEITEM;

这两个结构体除了名字不一样,别的都是一样的,每个变量的位置,变量的类型,所以我们觉得他们就是一样的

然后就出现了奇怪的现象~

我们设置了ValidTime之后,数据变了,变得我们不认识了!

我们上一行把ValidTime设置成300(0x012c)之后下一行用16进制打印强制转换另一个类型的ValidTime,却变成了0x2c00

我们上一行把ValidTime设置成30(0x001e)之后下一行用16进制打印强制转换另一个类型的ValidTime,却变成了0x1e00

是编译器欺负人?还是单片机欺负人?

按理说两个类型是完全一样的,那么我传入的指针,被强制转换之后,每个变量所对应的地址也是一样的,那内容应该也是一样的呀

Solve

折腾了很长时间,最后我就强行把类型统一了,使用同一个struct。竟然就好了!

于是我们发现在adp.h定义这一串struct之前有 #pragma pack(1)

他的功能是字节对齐,1就代表着1字节对齐。

在Keil官网上,对pack这个预编译函数有介绍
编译器默认是8字节对齐,所以只要不屑pack(1),那就是8字节对齐的。官网这里的demo我觉得有点问题,所以我就用另一个例子来说明。

以下内容夹杂猜想

adp.h:

#pragma pack(1)
......

typedef struct _ROUTINGTABLE_
{
    uSHORT    DestinationAddress; //16
    uSHORT    NextHopAddress; //16
    uSHORT    RouteCost; //16
    unsigned    HopCount:4;
    unsigned    WeakLinkCount:4;
    uSHORT    ValidTime;//16
}_ROUTINGTABLE,*_pROUTINGTABLE;

这里按照1个字节对齐,在内存里就是这样的

|-----------0-----------|
 -----------------------
|     Destination_H     |
|     Destination_L     |
|    NextHopAddress_H   |
|    NextHopAddress_L   |
|      RouteCost_H      |
|      RouteCost_L      |
|HopCount,WeakLinkCount |
|      ValidTime_H      |
|      ValidTime_L      |

sizeof(_ROUTINGTABLE)==9,这个应该是理想情况,但是如果没有pack(1)

mmu.h:

typedef struct _ROUTINGTABLEITEM_
{
    uSHORT    destination; //2
    uSHORT nextHop; //2
    uSHORT cost; //2
    unsigned hopCount:4; //0.5
    unsigned weakLinkCount:4; //0.5
    uSHORT    ValidTime; //2
}_ROUTINGTABLEITEM, *_pROUTINGTABLEITEM;

这里我觉得应该是按照2个字节对齐(虽然官网说的是8),在内存里就是这样的

|     0    |    1    |
 --------------------
|   dstH   |  dstL   |
|   NextH  |  NextL  |
|   cstH   |  cstL   |
|hopC\weakC|    *    |
|  ValTimH | ValTimL |

sizeof(_ROUTINGTABLEITEM)==10,于是字节错位了!

我们使用_ROUTINGTABLEITEM这个结构体对validTime赋值,会操作结构体内存的8、9位字节

使用错误案例validTime=300(0x012c),short在内存中存放为0x2c,0x01(倒着的~)

于是结构体为dstH,dstL,NxtH,NxtL,cstH,cstL,hop,weak,0x00,0x2c,0x01

但是使用_ROUTINGTABLE这个结构体去读取validTime的时候,会读取结构体内存的7、8位字节

也就是dst[7]=00,dst[8]=0x2c,于是validTime变成了0x2c00,超大的数字!

One more thing

这里bit field对齐夹杂了我的部分猜测,因为我查了很多很多很多资料,也没有找到比特操作的明确说明~

所以我就参考了这个牛逼的网页

假设bit是自动按序排列的,只要几个bit field大小总和小于等于一个字节,就使用一个字节空间,
而如果超过一个字节,那就需要把超的哪个bit field赶到下一个字节中去。

End

所以嵌入式是真的难啊!

我们这几天的调试还遇到了一些坑,过几天总结一下再来说说~