请教DSP下lwip的字节对齐问题。

2019-07-24 17:30发布

在TMS320F2812上移植lwip,网卡为ENC28J60。在收到数据包后lwip定义的struct eth_hdr与数据包对不起。
ENC28J60字节长8 bit,DSP字节长为16 bit,dsp按字节读取ENC28J60接收缓冲区,相当于把8位字节扩展成16位字节。
下面是lwip定义的报头struct eth_hdr,其字节长度应该是是8bit。
而dsp的字节是16 bit。报头前两项是MAC地址,即6字节的dest和6字节的src还能对应上,第13和14字节表示数据包类型(type),而dsp下u16_t type只对应第13字节,第14字节的数据存不到type中。在其他用到这个报头结构的地方都会有问题。
数据包从第14个字节开始对不齐,后面内容就全乱了。

我的理解问题原因是:
lwip中            sizeof(eth_hdr) = 14
TMS320F2812中  sizeof(eth_hdr) = 13

因为lwip定义类型:
typedef unsigned    char    u8_t;
typedef unsigned    short   u16_t;
所以
sizeof(unsigned char)=1
sizeof(unsigned short)=2

而F2812中类型定义 sizeof(unsigned char)=size(unsigned short)=1

不知道我表达清楚没有。
这个问题该怎么解决?
CCS中有没有PACK_这类的编译指示符解决这个问题?我找了,没找到,请各位给指点一下啊,谢谢啦!

#define ETHARP_HWADDR_LEN 6
PACK_STRUCT_BEGIN
struct eth_addr {
  PACK_STRUCT_FIELD(u8_t addr[ETHARP_HWADDR_LEN]);
} PACK_STRUCT_STRUCT;
PACK_STRUCT_END

PACK_STRUCT_BEGIN
struct eth_hdr {      //数据包包头
#if ETH_PAD_SIZE
  PACK_STRUCT_FIELD(u8_t padding[ETH_PAD_SIZE]);   //本程序不使用填充字节
#endif
  PACK_STRUCT_FIELD(struct eth_addr dest);    //1-6字节,目标MAC地址
  PACK_STRUCT_FIELD(struct eth_addr src);       //7-12字节,源MAC地址
  PACK_STRUCT_FIELD(u16_t type);                    //13、14字节,数据包类型,0x0800 : IP包,  0x0806: ARP包
} PACK_STRUCT_STRUCT;                                   // 在CCS的watch里可以看到,type值是0x0080, 后面的00或06在下个字节位置
PACK_STRUCT_END

数据包格式如下图
以太网数据包格式 以太网数据包格式
友情提示: 此问题已得到解决,问题已经关闭,关闭后问题禁止继续编辑,回答。
8条回答
warcraftiii
2019-07-24 22:42
我理解根本问题出在这句: typedef unsigned short   u16_t;
lwip本意的unsigned short应该是2 byte,所以eth_hdr中的 u16_t type 正好对应数据包中的第13、14字节,存储数据包类型。
而TMS320F2812下 unsigned short 是1 byte,所以eth_hdr中的u16_t type 只对应第13字节。

按照这种理解,ARP、IP数据包结构体的定义都存在这个问题。改哪里好呢?
改lwip的源文件?好像有好多地方都要改。

要是上面理解正确的话,lwip应该不适合移植到TMS320F2812这种字节长度是16bit的dsp下。
各位给提示下啊!

一周热门 更多>