-
关于任务调度获取锁，而不释放锁
0f06818fdfd9312863df35ac53b4c20.png
67e6d85c6ddc39f9ce48ed247ed4377.png
影响：
f625884b1a1e9b3e5b9e31457a5abbe.png
注意：
同步机制仅仅就保护临界区 不要扩大作用范围
-
关于预防向一块内存区域拷贝数据发生缓冲溢出
1c3034910c445c8a75a6c2b523d8e49.png
影响：
拷贝前没对文件长度和buf长度进行比较判断... 万一文件长度超过buf长度
注意：
增加判断： sizeof(buf)/sizeof(buf[0]) > file_size ;
备注：
数据究竟是怎样的一种结构 也就是如何格式化数据 是由数据的使用者解释；
以字符串这种格式处理数据的时候 就要用字符串的操作函数；
禁止一方面把数据作为字符串使用，一方面又使用内存操作函数，因为内存操作函数是没有对数据做格式化解释；
-
malloc之后对返回指针不做是否成功判断
5737be48d916fa5279d3608cc3dc851.png
影响：
有可能申请堆空间失败，有可能申请堆空间成功；如果申请失败的情况下，恰好指针又是处于一种失管状态（ptr != null），可能修改任何一处内存地址；
注意：
每次malloc之后对返回指针进行是否申请成功判断；另外，对使用完之后的指针进行指向NULL操作；
-
if嵌套最好不超过3层
ed543ca4a24e66c77546cd4827628de.png
影响：
代码可读性太差
注意：
建议作空值判断修改
if (ptr == NULL)
{
goto ....；
}
-
可用表达失完成的处理 却使用函数
a69023516a5084339166b0aa883e96c.png
影响：
增加系统开销，对于当下的处理频率来说不算问题，但这是个不好的行为
注意：
if （a == b == c）
-
向数组中拷贝满数组大小的数据时 禁止使用常量进行指定数组大小
int buf[50];memcpy( buf, src, 50 );
修改为：
memcpy( buf, src, sizeof(buf)/sizeof(buf[0]) );
影响：
避免数组大小经修改后，对应的数组操作处忘记做修改，导致缓冲溢出后果；
备注：
此项目代理中有一处错误如下：
image.png
image.png
-
关于优化性能 防止cpu空耗时间
image.png
影响：
此项目中应用RTX，划分时间片大小为5ms ， 上图当进入延时等待过程没有让出cpu，而是选择空耗时间片。且这种空耗时间片的等待消息到达的模式大量应用在 mcu 与 4G模组 基于 uart 的通信模式中；
注意：
可以采用异步消息通知机制，当线程需要延时等待时主动挂起；保证其他线程可以更好的利用cpu
-
关于EEPROM保存数据可靠性与代码框架清晰的思考
image.png
我的设想主要是用一个线程管理eeprom的写入。当系统启动时，从eeprom中读出数据后，在内存中维护一份映射（其实就是静态栈空间的一份数据结构）。当其他线程需要获取数据时，直接从内存中获取； 当其他线程需要更新数据时，直接更新内存中的数据结构，同时向eeprom_manage_threads发送一个消息，接下来当前线程继续处理业务逻辑。 当eeprom_manmage_threads占有cpu时，写入待更新数据。
网友评论