对比结构体成员的值，uint16＿t类型和uint32＿t类型的成员值都相反：
可见在强制转换的过程中，如果忽略了大小端问题，那么转换的结果将会和预期的不一致，要么导致程序处理异常而跑飞，要么导致内存溢出而系统崩了！
数据收发
数据收发，如果以嵌入式外设串行接口进行通信，收发大多是逐字节进行的，这里如果需要传输一个uint16＿t或者uint32＿t类型的数据，也都是被逐字节发出，此时就存在大小端的先后问题了。
这一点与上个问题的数据包解析和组包其实是个逆过程，也就是把特定结构的数据，强制转换为逐字节的数据流，从而在接口上逐字节被处理或者发出去。
构造一个结构体，对结构体各个成员进行赋值，然后将结构体对象传给接口发出去，看看大小端平台里的区别，Debug过程截图如下：
用一个uint8＿t类型的指针p3指向了结构体的首地址，也就是第一个成员的地址，p3 ＝ ＆tmp＿stru．val＿u8；该语句把结构体的地址赋给了p3，紧接着调用传输接口时，接口的参数要求是uint8＿t类型的指针，此时可以把p3作为参数传入处理接口trans＿port（）。
继续调试跟踪传输接口内部取到的数据流情况：
观察indata＿tmp数组，依次被填入的数据是0x10，0x20，0x30，0x40，0x50，…可见uint16＿t和uint32＿t类型的数据被“拆分”时，高字节先被处理，例如0x2030的数据先处理0x20再处理0x30，再比如0x40506070的数据先处理0x40，最后处理0x50！这就是大端模式！
同样的代码，拿到小端模式的ARM平台里运行，结果就完全不一样了：
在ARM的小端平台上，处理uint16＿t和uint32＿t类型的数据时，是反着来的！
综合以上验证，可以深刻理解和记忆嵌入式平台开发时的大小端差异问题。平台的大小端差异，不仅是数据存储需要考虑，而且在读取、使用和传递时，也需要多加留意，以免不必要的Bug产生。
