嵌入式系统调试时相对比较麻烦一些，特别是在定位一些疑难问题时，调试手段就显得非常重要。废话不多说，直接上方法。
方法一：利用特殊文件名字的文件存在与否来触发调试代码是否运行。比如有些特殊状况下，我们需要保存一帧数据图像，那保存数据图图像的代码不能时时刻刻都运行，那样不光flash受不了，系统怕也受不了，那就需要严格控制他的数量和频率。示例如下：
需要执行调试代码的时候，在SD卡创建一个临时文件，系统access判定文件是否存在，存在了就进去执行，为了减少次数，在执行完调试动作后就直接删除了这个临时文件，防止重入，减少系统负担。
/*****************************************************************************************************/
声明：本博内容均由http://blog.csdn.net/edsam49原创，转载请注明出处，谢谢！
/*****************************************************************************************************/
————————————————
版权声明：本文为CSDN博主「coding码场」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/edsam49/article/details/64439643
这个方法还是很好用的，在实际项目中可以灵活运用，达到调试的目的。
方法二：取系统时间，打印到毫秒级，在判断一些程序模块函数执行时间、效率上很有用。
int get_time_ms(char *buff, int len)
{
struct timeval tv;
struct tm* ptm;
char time_string[40];
long milliseconds;if(buff == NULL)
{
printf("%s buff is NULL.\n", __func__);
return -1;
}gettimeofday(&tv, NULL);ptm = localtime (&(tv.tv_sec));strftime (time_string, sizeof(time_string), "%Y-%m-%d %H:%M:%S", ptm); //输出格式为: 2022-03-30 20:38:37
milliseconds = tv.tv_usec / 1000;
snprintf (buff, len, "%s.%03ld", time_string, milliseconds); //输出格式为: 2022-03-30 20:38:37.182
return 0;
}这样就可以在需要的地方前后调用一下，再分析打印就可以比较准确的判断出执行的效率、耗时，统计出来还可以采用一些统计手段取一些平均值。
方法三：保存文件。比如需要把中间过程的某些重要数据保存下来，我们可以采用保存文件后，再分析文件。
static void save2file_render(void * buf, int len, char *fileName){
int fd = -1;
unsigned long bytes;if (-1 == fd){
fd = open(fileName, O_WRONLY | O_CREAT | O_TRUNC,
S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
if (fd < 0){
APP_PRT("unable to create debug file.");
fd = -2;
}
}if (fd > 0){
bytes = write(fd, buf, len);
// APP_PRT(" file %s write bytes %ld image file closed .",fileName, bytes);
close(fd);
fd = -2;
}}以上几个方法可以同时上，都是比较常用惯用的手段，调试手段越丰富，调试效率也就会越高。特别是遇到一些不容易出现的现象，又不能临时把自己调试想法运行出来，就可以采用前面说的办法，先把想法埋到流程中去，有需要的时候打开一下就行了，这样既能保障系统平时的执行效率不受影响，也能在关键时刻挺身而出，为你披荆斩刺！
