孙龙泉优秀作者
原创内容 来源:小居数码网 时间:2024-08-13 18:39:01 阅读() 收藏:51 分享:67 爆
导读:您正在阅读的是关于【数码知识】的问题,本文由科普作家协会,生活小能手,著名生活达人等整理监督编写。本文有2429个文字,大小约为11KB,预计阅读时间7分钟。
本次分享一些嵌入式软件的调试经验及一些有用的工具。
需要说明的是:这不是一篇大神教你如何成为大神的文章,因为我还不是大神;而是一名普通嵌入式软件工程师从毫无经验到略有经验的一点调试总结,都很基础。
我们常常说,软件三分写七分调。实际开发中,确实也是这样子的。我工作这几年了,对这体会也越来越深。每当需求一下来,我代码很快就可以写完,但是,调试需要花很多时间。
这里需要明确的是, 调试的目的不仅仅是调通整个功能需求 。调通功能是最基本的要求,还需要进行优化、完善逻辑、完善异常处理。所以,需要非常长的时间。
记得毕业的时候参与的第一个项目,那个项目的硬件架构相对一般产品来说会复杂一些:
我负责的部分就是D芯片的软件。D芯片所做的事情就是跟产品功能比较相近的,当时通过A发数据,经过B、C之后,再到D,产品功能表现得不正常。我当时的 第一反应 就是我负责得D芯片的逻辑可能出问题了。
A、B、C都是比较有经验的工程师负责的,而且负责C的还是个组长级别的,大家也觉得应该是我负责的D芯片的代码出的问题,因为我是个刚毕业的新人,觉得问题出在我这里的概率比较大。
他们也没有去查是不是他们的问题,每天就是来看看我是否有找到问题。花了几天的时间,我最后才定位出来,是C芯片给我发的数据出问题了~
因为当时缺乏调试经验,所以没能很快就定位出问题所在。要是现在的话,这种问题很快就能查出来的。因为现在积累了一些经验:
平时开发调试时,可能会有这么两种情况:
一些小的项目,如果整个项目是我们自己开发的话,调试起来也比较方便,因为是我们自己开发的,所以会比较熟悉一些。
我的习惯是:分模块来进行开发,每开发完一个模块就先想办法测一下这个模块,没问题了再集成到工程里。模块初步开发、测试时,代码可以随意一些,调好了之后,再重新梳理、整理代码,集成到工程里。
自测的方式:有一些代码直接对应着功能,直接测试看功能正不正常;有一些代码可以通过log打印来看是否正常;有一些可能需要在线调试看看是否符合预期;有一些需要数据输入的,可以自己模拟一些数据等。
协同开发时,可能就比较麻烦一些。特别的,有时候甚至需要跨部门对接调试。
我的习惯是:先开发并自测自己的模块;然后模拟对方,简单地自测通信。
自测自己模块的方式如上面独立开发一样。我们模拟对方进行测试时,需要考虑是不是需要花比较多的时间,如果需要花太多的时间的花就算了,等到联调再一起调。
花时间较少的,可以自测通信的情况可能有如下三种:
当然,协作开发也可以不自测通信,看个人习惯。
我模拟自测通信是为了对我自己的模块的通信有一定的把控,联调时出问题时,就可以比较快地指出对方的问题。当然,这不是为了推锅,而是为了能更好地分析、解决联调问题。
比如,我最近的项目中,设备与手机APP对接。配网功能、设备于APP局域网内通信功能。我负责设备端,设备端作为服务器;对方作为客户端。
在与对方联调前,我已经写了一个客户端运行于PC或设备上,模拟对方的手机APP,对我的模块做了基本的自测,也测出了我的模块的一些问题。
然后在与对方正式联调时,出现的大多问题都在对方那边,所以这时候我就可以帮助对方分析问题,提高了联调效率。
上面分享了一些我的经验及思路,下面看看一些具体的调试方法与调试工具:
我在实际工作中,log打印调试解决了我大多数的问题,一般的问题,通过分析log都可以定位出问题所在。但是,打log也是有很多讲究的,需要我们打印出有助于我们调试的信息。
比如:
带时间戳、函数名、行号等有助于分析问题的信息。比如:
<xxx ms>[func:100]
当然,实际中可能不只包含如上信息,根据需要添加。
这样可以清楚地知道程序跑到分支判断时的执行流程。
可以清楚地知道某个操作开始的地方。
比如统一的log的格式中加上特定标签,比如BUSINESS。如:
<xxx ms>[BUSINESS][func:100]
因为业务逻辑一般是整个项目的最上层,其它模块都是为它服务的。
我们看log的时候,通过编辑器搜索关键字 BUSINESS 就可以只列出业务逻辑相关的log,我们只要看这些log,就可以大致知道程序的运行流程。
当然,其它模块也可以根据需要加上标签。
与数据打交道的模块可能需要打印一些数据来分析源数据是否正常。可以稍微的控制打印频率,尽可能在不影响数据分析的情况下打印尽可能少的log。
否则,一些log的文件动不动就几百MB,分析起来也很头疼。特别的,log需要保存在flash上时,为了防止log爆满flash,常常需要限制log文件的大小并做log滚动覆盖,这时候无效log太多了可能就会覆盖掉有效的log。
往期关于log调试相关的文章:
C语言、嵌入式中几个非常实用的宏技巧
bug解决不了?使用日志法
在线调试,可以看到程序运行的更多细节。基本的应该都会吧。
GDB往期相关推文:
GDB调试器原来那么简单
手把手教你使用VSCode + gdb + gdbserver调试ARM程序原创
我们之前也分享了很多有用的调试相关的工具:
这是一个实用的LCD模拟器,手头上暂时没有LCD或者开发初期,需要频繁下载程序,验证效果的时候,可以使用VirtLCD来提高我们的开发、调试效率。
VirtLCD的介绍及简单使用:
手头上无LCD却又急着开发UI?LCD模拟器了解一下
Wireshark 是一个网络封包分析软件。比如我们在调试socket通信的时候,可以使用Wireshark 监控看看我们有没有发送数据出去,或者有没有收到对方发送的数据。
wireshark的介绍及简单使用:
wireshark抓包工具的使用详解
Virtual Serial Port Driver(VSPD)是一个虚拟串口软件。虚拟串口软件是一种模拟物理串行接口的软件,它完全复制了硬件 COM 接口的功能,并且将被操作系统和串行应用程序识别为真实端口。
在编写串口上位机时,需要进行调试。一种方式是与下位机进行通信进行测试;另一种方式是借助虚拟串口软件来进行测试。
VSPD的介绍及简单使用:
工具 | 虚拟串口软件的使用分享
GUI Guider是恩智浦为LVGL开发了一个上位机GUI设计工具,可以通过拖放控件的方式设计LVGL GUI页面,加速GUI的设计。
相关文章:
LVGL | GUI-Guider上位机的使用分享
基于vs2019的lvgl模拟器使用
LittlevGL在STM32上的移植使用
基于framebuffer的LittlevGL的移植使用
J-Scope 是 SEGGER 推出的波形显示软件,傻瓜式,简单易上手。需要搭配 Jlink仿真器 (V9或V10)使用。
J-Scope的介绍及简单使用:
J-Scope的介绍及简单使用
RTT全称是Real Time Transmit(实时传输),是SEGGER 公司推出的,是搭配 Jlink仿真器 (V9或V10)使用的一种调试手段。
SEGGER_RTT的介绍及简单使用:
SEGGER_RTT的介绍及简单使用
CmBacktrace (Cortex Microcontroller Backtrace)是一款针对 ARM Cortex-M 系列 MCU 的错误代码自动追踪、定位,错误原因自动分析的开源库。
CmBacktrace 的介绍及简单使用:
ARM Cortex-M 系列 MCU错误代码自动追踪库的使用分享
VOFA+(伏特加)插件驱动的高自由度上位机。其是一款通用的数据调试工具,它让图形化调试变得像串口调试一样简单。通过打印字符串,或者发送十六进制数字的方式,就能完成数据的可视化操作。
官网:
https://www.vofa.plus/
VOFA+的介绍及简单使用:
分享一个很酷的上位机软件
QEMU是一款知名的而且开源的模拟器(官网:https://www.qemu.org/),它能在 X86 PC 上运行能够模拟 Arm、MIPS、RISC-V 等各种 CPU 和开发板,以及 网卡、声卡、键盘、sdcard、emmc、usb等各种外设。
QEMU我还未使用过,之前转载的一篇文章:
Linux利器:QEMU!用它模拟开发板能替代真开发板?
Valgrind是一套Linux下,开放源代码(GPL V2)的仿真调试工具的集合。
Valgrind的介绍及简单使用:
工具 | Valgrind仿真调试工具的使用
Bus hound是一款为了在pc电脑上进行总线数据包监控以及操控的开发工具。用来捕捉来自设备的协议包和输入输出操作,它是功能强大的总线协议分析器。
之前有与USB上位机联调,通过这个工具可以监控上位机发出的数据是否正确。关于Bus hound的文章我们还没有分享过,先占个坑,之后有机会再分享。
上面就是小居数码小编今天给大家介绍的关于(嵌入式软件调试方法有哪些)的全部内容,希望可以帮助到你,想了解更多关于数码知识的问题,欢迎关注我们,并收藏,转发,分享。
94%的朋友还想知道的:
(535)个朋友认为回复得到帮助。
部分文章信息来源于以及网友投稿,转载请说明出处。
本文标题:嵌入式调试工具有哪些盘点(嵌入式软件调试方法有哪些):http://sjzlt.cn/shuma/155352.html