在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
数据包格式如下图
以太网数据包格式
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下。
各位给提示下啊!
一周热门 更多>