深入了解嵌入式编程

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

首先多处理器分为好几种，处理器是同一型号，大家完全一样，通过一种通讯方式连接，如多口的RAM，rapidIO，千兆级以太网，或者PCI-E等；处理器不同型号，甚至架构都完全不一样。之间通过一种通讯方式连接，同上，如多口RAM、RapidIO等；同一个芯片中集成了多个CPU。这几个CPU什么都共享，属于比多口RAM还要紧耦合的系统。为什么要用多处理器？大规模的并行运算；想利用多个CPU的特点，如DM642这样的方案，应用于复杂的视频方案。想利用DSP的浮点计算能力，同时也使用ARM的事务计算能力；单纯的提高系统的性能。对于普通的应用，提高系统性能是基本出发点。但嵌入式系统应用多处理器并不是一个简单的事情。多处理器的软件设计难度很大，调试也是很大的问题。如果不采用操作系统处理，采用前后台系统。那么自己还要设计一个通信算法，还要设计一个结果整合系统。这样的系统自己设计很多东西，其中总线的可靠和容错设计至关重要。 所以可能的话，利用成熟稳定的操作系统来支持多处理器可以减少不少的开发难度。然而，寻找这样的一个操作系统并非易事。首先要明确自己的应用，需要线程进程迁移吗？需要处理器平衡吗? 对于多处理器，如果不支持线程进程迁移，那也就谈不上处理器任务的动态平衡，不然只能事前指定好线程进程运行于哪个处理器。对于异构型多处理器，线程迁移和进程迁移并没有多大的实际意义。对于追求利益的公司来说，目前还谈不上实用价值。所以，迁移只限于对称处理器。然而，对称处理器也不是什么进程可迁移。对于对称处理器，操作系统封装好底层，让用户开发起来