【嵌入式编程】平台大小端存储差异解决办法
- 嵌入式开发
- -
- Linux平台
- 嵌入式开发
- -
- 单片机STM32
- 嵌入式开发
- -
- SoC芯片nRF51x22
- 嵌入式开发
- -
- SoC芯片ESP8266
- 嵌入式开发
- -
- RTOS-uCOS
- 嵌入式开发
- -
- RTOS-FreeRTOS
- 编程
- -
- C/C++
文章首发于同名微信公众号：DigCore
欢迎关注同名微信公众号：DigCore，及时获取最新技术博文。
原文链接：https://mp.weixin.qq.com/s/8UFQDv0D8E_C4TSk-bKskw
关于大小端存储的问题，在嵌入式开发里这个早已不是什么新鲜事儿了。作为开发者都有着很清晰的认识，在此就嵌入式开发中的大小端问题，做个简单的分享总结。
大端小端，是相对内存而言的。有关大小端的资料，互联网上一搜就一大堆的博文和百科知识点，这里就不再赘述。
在工程项目中，需要处理大小端差异的，主要出现在数据处理的过程中，常见的有：
1.数据包解析和组包
2.数据收发和参数传递
-
数据包解析和组包
数据包解析和组包的过程，可以参考《嵌入式硬件通信接口协议-UART（四）设计起止式的应用层协议》该文中的“设计协议帧结构”部分，该部分内容讲到把uint16_t字段的数据使用2个uint8_t类型的数据表示，旨在数据传输时没有差异。
但是，有些接口是别人设计好的，作为应用者你只能“顺从”地使用。
在C语言里可以利用强制转换来实现对数据类型的转换，但是强转的结果依赖于当前平台大、小端情况的。
如下的类型强制转换，将uint8_t类型buf中的数据流强制转为uint16_t类型后取出赋值给tmp_dat变量，根据观察发现buf中的数据流被每2个字节“组合”成一个uint16_t类型的数据，Debug过程截图如下：
代码中的p1是一个uint16_t类型指针，指向uint8_t类型数据流的tmp_stream，此处的指针赋值就需要使用强制转换。
在for循环内以p1指针为“起点”循环做偏移取出数据，并且每次偏移uint16_t类型的数据宽度，因为p1是uint16_t类型指针。
观察取出数据存放的tmp_dat变量，可见数据被从左到右（也就是从低地址到高地址）每2个字节“组合”成uint16_t类型，比如0x11和0x12组合成0x1122，0x33和0x44组合成0x3344......可见，低地址的那一个数据组合后成为了uint16_t的高字节部分！这就是大端模式！
同样的代码，拿到小端模式的ARM平台里运行，结果就完全不一样了：
不难发现，在小端平台里，数据被从左到右（也就是从低地址到高地址）每2个字节“组合”成uint16_t类型了，而此时0x11和0x12组合成0x2211，同时0x33和0x44组合成0x4433……可见，低地址的那一个数据组合后成为了uint16_t的低字节部分！这就是小端模式！
类似的问题，也会出现在强制转换为结构体的过程中，并且实际得到的结构体由于大小端问题，部分成员已经“变了样”！
使用同一数据流，利用一结构体指针p2指向该数据流进行解析，对比不同平台强制转换后的结构体部分成员的情况。
大端模式的51平台下：
小端模式的ARM平台下：
对比结构体成员的值，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产生。
-
常用处理差异办法
关于差异的处理，前文提到的全部采用uint8_t类型进行设计，比较保险稳妥，但数据量大、项目需求复杂的时候，未必就能满足，所以还是需要正面应对这些硬性问题。
这里整理出几个简单转换的过程。
-
1. 多个uint8_t转uint16_t/uint32_t
这个转换很容易可以实现，信手拈来：
val_u16 = (val_u8_tmp1<<8) |val_u8_tmp2;
这里的转基本都是把两个uint8_t类型“组合”成uint16_t或者uint32_t，而实际项目工程中，多是对uint8_t类型的数据流进行转换，并且是转换部分数据，因此这里直接写成宏定义，便于开发移植：
小端模式转成uint16_t/uint32_t
大端模式转成uint16_t/uint32_t
分析小端模式转成uint16_t类型的数据，首先将这一长串的宏拆分然后逐步去理解:
实际是((uint16_t)*(volatile uint8_t*)((ptr)+1)<<8)和(uint16_t)*(volatile uint8_t*)(ptr)两个数据进行位或的运算。
1.右半边 (volatileuint8_t*)(ptr)是将ptr所指地址强转为volatile uint8_t*类型；
2.然后是使用*(volatileuint8_t*)(ptr)根据地址从内存中取出该字节；
3.紧接着将取出的一字节数据使用(uint16_t)强制类型转换成uint16_t类型。
同样的原理，
1.左半边(volatileuint8_t*)((ptr)+1)是将prt所指地址的下一个内存单元强转为volatile uint8_t*类型；
2.然后是使用*(volatileuint8_t*)((ptr)+1) 根据地址从内存中取出该字节；
3.紧接着将取出的一字节数据使用(uint16_t)强制类型转换成uint16_t类型，再左移8位处理。
最后将两个结果做位或运算，即实现了“组合”，返回uint16_t类型结果。
以上过程分析的比较啰嗦，并且其中做的一些强转和volatile修饰也是很有必要的，因为设计的宏要想可靠，还考虑到在有中断、有事件处理的系统里，对数据操作还是需要谨慎些！
-
2.单个uint16_t/uint32_t转uint8_t
单个字/双字转成字节，使用场景比较少，最简单方式直接利用位与（&）和移位运算。
取低字节：
val_u8_tmp = val_u16&0xFF;
取高字节：
val_u8_tmp =(val_u16>>8)&0xFF;
-
3.对uint16_t/uint32_t类型进行字/双字内自转
其原理一样是操作内存地址的方式，写成宏定义，方便使用。
其转换的结果是将原数据翻转成相反的端模式。
总结，项目的开发细节问题弄清楚了，对后续的开发工作也是磨刀不误砍柴工，并且在有通信需求时，尤其有必要做好通信协议的沟通协调，设计一套双方通用的协议结构，对后续开发有着规范可循，对解决Bug也可以快速定位问题！
★★★★★推荐文章
《嵌入式硬件通信接口-使用RingBuffer处理数据(二)详细设计过程》
《嵌入式硬件通信接口-使用RingBuffer处理数据(一)》
《快速开发MQTT（一）电子工程师眼中的MQTT》
《快速开发MQTT（二）初识MQTT》
《MQTT客户端搭建-最清晰的MQTT协议架构》
《MQTT服务端搭建-最快方式验证自己开发的客户端》
★★★★★相似文章
《嵌入式硬件通信接口协议-UART（五）数据包设计与解析》
《嵌入式硬件通信接口协议-UART（四）设计起止式的应用层协议》
《嵌入式硬件通信接口协议-UART（三）快速使用串口及应用》
《嵌入式硬件通信接口协议-UART（二）不同电气规范下的标准》
《嵌入式硬件通信接口协议-UART（一）协议基础》
《嵌入式硬件通信接口协议-SPI（一）协议基础》
★★★★★扩展阅读
《【硬件电路】AltiumDesigner18规则检查含义》
《【硬件电路】N沟道、P沟道MOS管基本原理与应用案例》
长按二维码关注DigCore
关注公众号，发消息:
下载&BigLittleEndian
获取本文PDF原文或源代码下载链接