蓝桥杯嵌入式备赛bug持续记录中~

_元_

已于 2025-01-25 10:02:47 修改

阅读量397

点赞数 7

文章标签：蓝桥杯 bug 职场和发展

于 2025-01-21 08:40:13 首次发布

本文链接：https://blog.youkuaiyun.com/GMSZ1348/article/details/145273932

版权

文章目的

用于记录笔者在备赛真题中遇到的种种问题，作为今后的自己和读者的参考。

1、15届嵌入式省赛真题

bug记录1 2025/1/20 变量大小没选对，天上馅饼也难接

问题：输入捕获的555定时器输出频率值过大，代码逻辑没有问题。

解决：输入捕获的输出的频率是计算出来的二手值。如果不是代码逻辑问题，那显然是参与计算频率的哪个值出现问题了。最后发现是一手的捕获值cal给的变量大小太小了，捕获值溢出导致计算出来的频率过大。

教训：故障输出值非一手值时，应该把参与输出值的逐个值用keil中的debug功能进行检查，尤其是变量大小。

bug记录2 2025/1/21 变量没设对，3w2变鸭蛋

问题：为了给输出频率设置溢出界限，使用了一个temp变量来存储计算后输出的频率（下面代码1），temp值不溢出时（下面代码2）才将temp值赋给fre，结果在原先频率最大的位置会出现fre=0的情况（即执行了代码3）。

        if(htim->Instance == TIM3) //频率输出1 R39 B PB4
	    {
	    	cap_val[1]= HAL_TIM_ReadCapturedValue(htim,TIM_CHANNEL_1);
	    	TIM3 -> CNT=0;
		
	1	    temp[1]=HCLK/((PSC_TIM2_TIM3+1)*cap_val[1])+PX;//此处80是（PSC+1）      
		    if(temp[1]>=0)
		    {
	2	    	fre[1]=temp[1];//此处80是（PSC+1）      //单位Hz
		    	cycle[1]=1000000/(fre[1]);                           //单位us
		    }
	3	    else {fre[1]=0;cycle[1]=0;}
		
		    HAL_TIM_IC_Start_IT(&htim3,TIM_CHANNEL_1);//PB4 TIM2-chan1
	    }

解决：因为频率计算存在负值的情况，选用的fre、temp分别为uint16_t、int16_t，temp的范围是-32768 到 32767，计算频率值赋值有会出现值溢出导致temp<0的情况。

将temp使用int32_t型进行定义

教训：定义变量a时，如果后续将变量a用于赋值不同类型的变量时，要考虑二者变量直接是否能够接收。

bug记录3 2025/1/22 初始值要警觉不要一给给默认

问题：为了进行捕获频率最大值最小值的获取，设置了另一个定时器中，将得到的最开始的捕获频率都赋给fre_max fre_min,最后却发现每次都是fre_max先赋到了值，但是fre_min最开始都为0.代码如下

	if(htim->Instance == TIM6)
	{
		//第一步：给出fre_max fre_min的初始值
		
		if(fre_D_Flag==0 && cap_flag==1)
		{
			fre_min[0]=fre[0];//明明这俩同时赋值的，怎么一个有值一个没有
			fre_max[0]=fre[0];//
			
			fre_min[1]=fre[1];			
			fre_max[1]=fre[1];
		
			fre_D_Flag=1;
			T0_count=1;
			
		}
		//第二步：在时间窗口3s内进行最大值最小值的捕获
		else if(T0_count < 300 && fre_D_Flag==1)
		{
			T0_count++;
			for(int i=0;i<2;i++)
			{
				if(fre_max[i]<fre[i])    {fre_max[i]=fre[i];}	
				if(fre_min[i]>fre[i])    {fre_min[i]=fre[i];}
			}
		}

解决：原来是最开始的时候，给到fre_min fre_max的初始fre是还没有输入捕获到的值fre=0，再接着第二步的代码，就只有fre_max能够先得到捕获后的值了。

获得的经验：给初始值的时候，一定要考虑到是否会直接给到上电时的默认值。