stm32 f103 芯片里的陷阱

  最近闲来无事，买了一块f103c8t6，就是随便玩玩，想复习下hal库的开发，结果没想到一脚踩进了坑里。

不多说，上代码：

u8 Get_temputure(float *temp1)
{
  unsigned char H=0,L=0;
    u16 temp=0;
    ds_rst();
    if(ds_ack())
    {
        return 0;
    }
    ow_write(0xcc);
    ow_write(0x44);
    delay_ms(750);

    ds_rst();
    if(ds_ack())
    {
        return 0;
    }
    ow_write(0xcc);
    ow_write(0xbe);
    L=ow_read();
    H=ow_read();
    
    OLED_ShowNum(56,6,H,9,16);
    
    if(H>7)
    {
        temp=(H<<8)|L;
        *temp1=(~temp)+1;
        *temp1=(*temp1)*0.0625*(-1);
    }
    else
    {
        temp=(H<<8)|L;
        *temp1=temp*0.0625;
    }
    return 1;
    
}

u8 ow_read(void)
{
    u8 dat;
    int i=0;
    for(i=0;i<8;i++)
    {
      ds_out();
      ow(1);
      delay_us(1);
      ow(0);
      delay_us(2);
      ow(1);
      ds_ipt();
      delay_us(12);
        if(P5)
        {
            dat=dat>>1;
            dat|=0x80;
        }
        else
        {
            dat=dat>>1;
            dat|=0x00;
        }
        delay_us(3);
    }
    return dat;
} 

这是自己写的DS18B20的驱动函数，调用ow_read()得到一个U8类型的返回值。但在实际使用的时候，返回值一直是非常大的一个量，远远超出了u8的范围。刚开始我以为是驱动写错了，又是一番检查。随后在第一个函数下面加入OLED显示H的值，结果竟然奇迹般的好了。但随后添加了一些东西，又是一团乱码。

随后显示H的值，竟然是2097161。。。换成二进制肯定远超八位。

无疑，肯定是程序才芯片上跑的时候数据泄露了。仔细检查，想来想去只有ow_read()里的dat问题，虽然定义了u8类型，但程序在多次调动时极有可能没有重新定义变量，才导致每次移位都会增加位数。

 给dat赋初始值：u8 dat=0 问题解决。

这不是我在stm32 上遇到的第一次这样的问题，之前遇到过CACHE的问题，与这个差不多。