闲来没事，写了个测试STM32存储结构的程序，
如下：
void OSWriteUsart(u8 UsartNum,u8 *Buf,,u16 Len);
具体代码就不写了，就是将Buf里的字节通过串口发送Len个.
u32 tmp;
tmp=0x11223344;
OSWriteUsart(USART0,(u8 *)&tmp,sizeof(tmp));
用串口接收程序接收竟然收到44 11 22 33
改一下
u16 tmp;
tmp=0x1122;
OSWriteUsart(USART0,(u8 *)&tmp,sizeof(tmp));
串口接收程序收到11 22
再改改
typedef struct
{
u8 Hour;
u8 Minute;
u8 Second;
}TIME_TYPE_DEF;
TIME_TYPE_DEF Time_t;
Time_t.Hour=1;
Time_t.Minute=2;
Time_t.Second=3;
OSWriteUsart(USART0,(u8 *)&Time_t,sizeof(Time_t));
串口接收程序收到 03 01 02
晕，怎么可能是我的程序问题呢。
都搞了那么长时间了不可能犯这种错误的。
因为这样就对。
u8 tmp[5]={1,2,3,4,5};
OSWriteUsart(USART0,(u8 *)&tmp,sizeof(tmp));
接收到 01 02 03 04 05
再这样也对
typedef struct
{
u16 Hour;
u16 Minute;
u16 Second;
}TIME_TYPE_DEF;
TIME_TYPE_DEF Time_t;
Time_t.Hour=1;
Time_t.Minute=2;
Time_t.Second=3;
OSWriteUsart(USART0,(u8 *)&Time_t,sizeof(Time_t));
串口接收程序收到 00 01 00 02 00 03
看看你的函数OSWriteUsart()
估计是这个函数在搞鬼。
另外，试试把你程序中的tmp变量改为全局变量。
告诉你，ARM7也有类似问题。
嘿嘿！如果按你的这说法，ARM7也有类似问题。
那是因为STM32是LSB的
你写
u32 tmp = 0x11223344;
在内存里的存储顺序依次是 0x44 0x33 0x22 0x11
如果写u8 tmp[4] = {0x11, 0x22, 0x33, 0x44}
在内存里的存储顺序依次是 0x11 0x22 0x33 0x44
USART顺次8位8位发数据
就会有这种现象，写程序的时候要注意的。
LZ测试存储结构不用这么麻烦吧
定义一个变量，用watch窗口赋个值，看看地址，然后去memory窗口看实际每个地址的值就可以了，不可能存在你说的错误的。
比如u32 tmp=0x11223344，存储器中是44，33，22，11
u16 tmp = 0x1122，存储器中是22,11，符合little endian的定义。
不过
typedef struct
{
u8 Hour;
u8 Minute;
u8 Second;
}TIME_TYPE_DEF;
这个不好说，最好加个#pragma pack(1)
至于香主说的我的函数问题
晚上我回去直接调用ST的库试下就知道了
为什么输出u8 的数组就好使呢
我用的是DMA传输方式
回楼上
用的KEIL。
手头有板子的也可以测一测，到底是我个人问题还是都是这样的
还是我的错
不好意思，还是我的错。用的UCOS，通过DMA发送，当发送完毕的时候DMA发生中断通知任务已经发送完成，这时候任务把串口时钟关闭了，但发送是有一个过程的，DMA发生中断的时候最后那个字符并没发送完毕。导致最后一个字节总是没有发出来，总是在第二次发送前发出来了。这样本来应该发出44 33 22 11除了第一次发送少一个字节外，后面每次都发送11 44 33 22。一时粗心，没看出来。因为之前发送的字符串，后面有个结束符，所以初一看是正确的。
京公网安备 11010802033920号
