如何解决STM32 gcc优化产生不同的结果
我正在尝试使用STM32F4(SW4STM32 IDE中的gcc)将RGB缓冲区解码为适合LED RGB矩阵的行。 设置编译器优化-O0时,以下代码可以完美工作。
使用-O1优化进行编译时,代码会产生不同的结果。 (还有-O2,-O3)。 将( attribute ((packed)))添加到带有-O1的struct color_t定义时,代码还会产生不同的结果。
仅将优化设置为此.c文件,其他文件仍为-O0。
有人可以找出优化为何更改了代码逻辑/行为吗?
uint8_t badr[24576] = { 0xff,0x2a,.... };
struct s_color_t
{
uint8_t r;
uint8_t g;
uint8_t b;
} ;
//__attribute__((packed))
typedef struct s_color_t color_t;
#define WIDTH 128
#define HEIGHT 64
#define COLOR_SIZE sizeof(color_t)
#define R0_POS 0x01
#define G0_POS 0x02
#define B0_POS 0x04
#define R1_POS 0x08
#define G1_POS 0x10
#define B1_POS 0x20
#define enc_color(c,s,r) (c & s)? r : 0
color_t dispBuf[ WIDTH * HEIGHT];
uint8_t dispLine[WIDTH];
void fillBuf()
{
uint8_t *dbuf = (uint8_t *) dispBuf;
memcpy(dbuf,badr,WIDTH * HEIGHT * COLOR_SIZE);
}
void enc_row(uint8_t slice,uint16_t row,uint8_t *rBuf)
{
uint8_t reg;
color_t *upPtr = dispBuf + row * WIDTH * COLOR_SIZE;
color_t *dnPtr = dispBuf + (row + (HEIGHT / 2)) * WIDTH * COLOR_SIZE;
uint8_t *destPtr = rBuf;
uint8_t sn = (1 << slice);
for (int i=0; i < WIDTH; i++) {
reg = 0;
reg |= enc_color((*upPtr).r,sn,R0_POS);
reg |= enc_color((*upPtr).g,G0_POS);
reg |= enc_color((*upPtr).b,B0_POS);
reg |= enc_color((*dnPtr).r,R1_POS);
reg |= enc_color((*dnPtr).g,G1_POS);
reg |= enc_color((*dnPtr).b,B1_POS);
*destPtr = reg;
upPtr ++;
dnPtr ++;
destPtr ++;
}
}
void do_func()
{
uint8_t *ptrLine = dispLine;
fillBuf();
for (int s=0; s < 8; s++) {
for (int i=0; i< (HEIGHT/2); i++) {
enc_row(s,i,ptrLine);
printf("line %3i ",i);
for(int c=0; c<WIDTH; c++) {
printf("%02X,",ptrLine[c] & 0xFF);
}
printf("\r\n");
}
}
}
解决方法
感谢Zan Lynx。 确实,如果一个人打算以后使用优化,他应该放置检查点以验证代码在优化后是否能产生相同的结果。
上面的错误结果是由指针计算引起的。我将上面的两个语句替换为:
upPtr = &dispBuf[row * WIDTH];
dnPtr = &dispBuf[(row + (HEIGHT / 2)) * WIDTH];
在调试过程中(启用优化功能),删除了一些功能(即,操作由编译器完成)
对其他设备来说,嵌入式接口的信号也会改变速度。您可能会超频或更短的脉冲。
使用-O1,代码执行时间减少了60%。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。