地球人都知道,嵌入式的最大挑战在于硬件和软件同时成熟;出了个问题,不知道是软件问题还是硬件问题。当然,可以通过虚拟的方式解决大部分问题,但虚拟终归是虚拟。不是实际,上了实际的板子,还是有不少问题。嵌入式领域,特别是底层技术,由软件(驱动)和硬件两个部分组成。解决起来,需要两个部分的知识,对人员的素质要求更高。我曾经遇到很多棘手的问题,都是复杂的系统问题。
1.一个系统要求连续不断的24小时工作,即使断电,也要保存断电状态。在电源正常时,就必须恢复断电前的状态,继续工作。
实际中,我们也这样做了软件,但是实际效果并不是所想得那样。一万次断电,总有那么几十次不正常;又没办法重现,只能是猜来猜去。因为系统断电,这个也不好调试,挂着JTAG,系统现在断电了,目标板也就没电了。也就没办法调试跟踪单步了。本来的设计思路是,控制电路利用电容存储的一些些能量在断电后继续工作,保存状态,保存好后,进入待机状态。测试检测断电的信号后,也是没有问题的。后来,这个问题变成悬疑问题了……
这个系统分为两个模块,工作模块和控制模块。控制模块有电容继续供电,而工作模块没有电容工作;所以当发生断电时,全系统不是同一时间断电的。当控制模块检测到断电时,实际上工作模块早都没电了,所以工作模块不能正确的传递相关的数据回来,造成控制模块不能正确的工作。两个断电的时序非常的接近,无法判断其先后。解决的方法也很简单,就是把断电检测模块以工作模块为主进行同步,就没有问题了。
2.还是断电保护的问题,我们用继电器模拟断电的情况上万次正常后,终于上整机实验了,结果经常发现断电无法正常保护的现象。仔细查看电路也没有什么异常,都是一样的。结果工程部指责我们研发部没有仔细测试,发出来的东西都是有问题的东西。哎,伤心啊。后来经过仔细的分析,我们认为,软件异常的可能性很小。主要问题还是在硬件上,硬件上的超级电容可能在频繁的断电下,没有存储够足够的能量,使得系统完成保护过程。那么究竟是什么造成频繁的断电呢?按照设计要求,超级电容在3~5s内就会充满到80%的能量,理论上足够了。又有什么会不到3~5s钟频繁的断电呢?
说出来都匪夷所思,使用数字示波器不间断跟踪控制板的电源,才发现。原来是三相交流电需要接一个相位保护器,相位保护在系统工作时会频繁的开关(可能和系统的状态有关)。解决方法是,简单的把控制器的电源接在相位保护器前面就好了。
这些问题看似都是硬件问题,也是在产品的调试过程中经常碰到的问题。这些问题,需要软件工作人员确认软件中的Bug是否能造成这种情况,然后,还需要硬件工程师确认硬件。当然,硬件的确认过程漫长复杂,并且调试手段非常有限;嵌入式软件的调试相对于硬件来讲,成本和收效都会好一些。所以往往需要嵌入式软件人员花很多时间确认软件问题,最后才怀疑硬件。作为嵌入式开发人员,能了解硬件的基本原理,结合软件的工作原理,和硬件工程师一起配合实验定位错误,是非常有效的办法。
1.一个系统要求连续不断的24小时工作,即使断电,也要保存断电状态。在电源正常时,就必须恢复断电前的状态,继续工作。
实际中,我们也这样做了软件,但是实际效果并不是所想得那样。一万次断电,总有那么几十次不正常;又没办法重现,只能是猜来猜去。因为系统断电,这个也不好调试,挂着JTAG,系统现在断电了,目标板也就没电了。也就没办法调试跟踪单步了。本来的设计思路是,控制电路利用电容存储的一些些能量在断电后继续工作,保存状态,保存好后,进入待机状态。测试检测断电的信号后,也是没有问题的。后来,这个问题变成悬疑问题了……
这个系统分为两个模块,工作模块和控制模块。控制模块有电容继续供电,而工作模块没有电容工作;所以当发生断电时,全系统不是同一时间断电的。当控制模块检测到断电时,实际上工作模块早都没电了,所以工作模块不能正确的传递相关的数据回来,造成控制模块不能正确的工作。两个断电的时序非常的接近,无法判断其先后。解决的方法也很简单,就是把断电检测模块以工作模块为主进行同步,就没有问题了。
2.还是断电保护的问题,我们用继电器模拟断电的情况上万次正常后,终于上整机实验了,结果经常发现断电无法正常保护的现象。仔细查看电路也没有什么异常,都是一样的。结果工程部指责我们研发部没有仔细测试,发出来的东西都是有问题的东西。哎,伤心啊。后来经过仔细的分析,我们认为,软件异常的可能性很小。主要问题还是在硬件上,硬件上的超级电容可能在频繁的断电下,没有存储够足够的能量,使得系统完成保护过程。那么究竟是什么造成频繁的断电呢?按照设计要求,超级电容在3~5s内就会充满到80%的能量,理论上足够了。又有什么会不到3~5s钟频繁的断电呢?
说出来都匪夷所思,使用数字示波器不间断跟踪控制板的电源,才发现。原来是三相交流电需要接一个相位保护器,相位保护在系统工作时会频繁的开关(可能和系统的状态有关)。解决方法是,简单的把控制器的电源接在相位保护器前面就好了。
这些问题看似都是硬件问题,也是在产品的调试过程中经常碰到的问题。这些问题,需要软件工作人员确认软件中的Bug是否能造成这种情况,然后,还需要硬件工程师确认硬件。当然,硬件的确认过程漫长复杂,并且调试手段非常有限;嵌入式软件的调试相对于硬件来讲,成本和收效都会好一些。所以往往需要嵌入式软件人员花很多时间确认软件问题,最后才怀疑硬件。作为嵌入式开发人员,能了解硬件的基本原理,结合软件的工作原理,和硬件工程师一起配合实验定位错误,是非常有效的办法。