嵌入式系统的调试往往很复杂,可用的手段并不像PC编程那么多,开发成本较PC系统也要大很多。嵌入式系统调试主要手段只有JTAG为代表的单步追踪、printf夹杀大法等。 


这两种调试方法在嵌入式中也不尽然全部能解决问题。Jtag需要调试者有一个调试设备(有可能很昂贵),和目标系统相连。使用类似GDB Client等软件登录调试设备,跟踪运行程序。说实话,这个方法对嵌入式来讲是终极的调试办法,也是比较好的调试方法。但仍然有几个不足,当断点过多时,超出硬件的限制,某些低档的CPU不支持更多的断点,就需要JTAG利用软件模拟,或采用软件陷阱(软中断或异常)等办法实现断点。机理比较复杂,简单点说,1.不能进行长时间调试,不太稳定; 2.有可能影响程序的运行时刻的行为,通过时序影响。挂接JTAG系统后,利用硬件实现的断点不会影响系统运行的速度,但是软件实现的断点是必定牺牲一些性能的。可靠性也要打折扣的。当断点太多,而系统又进入临界区域,可能会造成断点不起作用。因为嵌入式实现全局临界区域往往需要关闭中断,有些CPU没有非屏蔽中断,当断点超过一定数量,使用软件断点,而软件断点又需要在中断工作的情况下使用……
特别调试时序问题和高速通信类的代码,JTAG帮助并不大。通信过程往往很快,通信包也是接二连三,才能完成一个完整的动作。如果是高速通讯,断点是无法让程序完成工作的。所以只能使用printf夹杀的办法,printf夹杀办法很好。但是也要注意几个问题:嵌入式系统往往没有屏幕,printf输出是通过串口输出。而串口工作模式有两种,一种是查询,另外一种是中断,或DMA。不管哪种,调试输出的printf只能使用查询的办法输出,千万不要使用中断或DMA的办法。不管是前后台程序也好,还是操作系统也好,都有不方便的时候,也许在全局临界内需要打印(关闭了中断),也许需要在中断里打印(不允许嵌套中断),也许要在一些驱动里打印(很多配合的设备没有初始化,内存分配和中断并不能很好的工作)。在这些情况下,利用Uart中断输出字符是不明智的。所以调试输出只能使用查询的办法。嵌入式物联网智能硬件等系统学习企鹅意义气呜呜吧久零就易,不要幻想着使用什么牛叉的办法,不必了。一句话,不可靠!既然做调试,那可靠的输出结果是第一要求。也就是因为如此,printf也会影响代码的工作效率,串口最高的波特率115200bps,越快速的CPU越是浪费时间,因为需要等待上一个字符输出完毕,这段时间完全是通过空转消耗这部分时间。所以使用printf要有一些技巧,在不影响一些关键时序的位置下再打印,而不是随意烂打……淹没了bug。
以上这两种办法并不能很好的解决全部的问题,在实际中如果嵌入式系统有一两个LED灯,尝试用IO口将其在特殊的情况下点亮熄灭的办法,也可表示程序的状态。这种办法适合调试中断、临界区域这些问题。点量LED灯需要的时间是非常短的,基本上是一条内存读写命令,如果IO口寄存器是CPU统一编址的话。基本上造成的影响微乎其微。在调试一些复杂的时序的时候,还可以使用空闲的IO口,将其在特殊的情况下拉低,拔高,然后利用数字示波器或者逻辑分析仪抓取再具体分析。特别是分析一段代码的执行频度,执行时间,优化效果等。对整体的性能提升等,有非常大的意义。对于简单的单片机,厂商开发软件都有个时序统计的功能。但对于有cache和MMU的单片机,时序统计并不准,往往不如用示波器测得的准。如果没有示波器利用CPU内部的时间计数器也可以实现时间的统计,需要结合printf使用。
我一个同事,调试飞利浦的ARM7,由于飞利浦ARM7外扩的RAM全部是静态RAM,即使在CPU死机情况下,只要不断电,SRAM里的数据也不会丢失,由于SRAM和内部的SRAM统一编址,所以,访问起来也就是一条读写指令,速度很快。利用这个特性,他把程序的模块和点全部标记上,当系统运行不正常,将ARM7复位以后,ARM7上电第一个工作就是取出复位前的数据打印出来。由此可调试ARM7的代码,非常巧妙的办法。如果只有SDRAM的朋友们是不能用这种办法的,因为只要系统复位,SDRAM没有刷新,数据即会丢失。
使用哪种办法,都有利有弊,在嵌入式系统里权衡的东西比PC平台多得多……