嵌入式的最大挑战在于硬件和软件同时成熟;出了个问题，不知道是软件问题还是硬件问题。当然，可以通过虚拟的方式解决大部分问题，但虚拟终归是虚拟。不是实际，上了实际的板子，还是有不少问题。嵌入式领域，特别是底层技术，由软件(驱动)和硬件两个部分组成。解决起来，需要两个部分的知识，对人员的素质要求更高。我曾经遇到很多棘手的问题，都是复杂的系统问题。

　　1、一个系统要求连续不断的24小时工作，即使断电，也要保存断电状态。在电源正常时，就必须恢复断电前的状态，继续工作。

　　实际中，我们也这样做了软件，但是实际效果并不是所想的那样。一万次断电，总有那么几十次不正常;又没办法重现，只能是猜来猜去。因为系统断电，这个也不好调试，挂着JTAG，系统现在断电了，目标板也就没电了。也就没办法调试跟踪单步了。本来的设计思路是，控制电路利用电容存储的一些些能量在断电后继续工作，保存状态，保存好后，进入待机状态。测试检测断电的信号后，也是没有问题的。后来，这个问题变成悬疑问题了……

　　这个系统分为两个模块，工作模块和控制模块。控制模块有电容继续供电，而工作模块没有电容工作;所以当发生断电时，全系统不是同一时间断电的。当控制模块检测到断电时，实际上工作模块早都没电了，所以工作模块不能正确的传递相关的数据回来，造成控制模块不能正确的工作。两个断电的时序非常的接近，无法判断其先后。解决的方法也很简单，就是把断电检测模块以工作模块为主进行同步，就没有问题了。

　　2、还是断电保护的问题，我们用继电器模拟断电的情况上万次正常后，终于上整机实验了，结果经常发现断电无法正常保护的现象。仔细查看电路也没有什么异常，都是一样的。结果工程部指责我们研发部没有仔细测试，发出来的东西都是有问题的东西。哎，伤心啊。后来经过仔细的分析，我们认为，软件异常的可能性很小。主要问题还是在硬件上，硬件上的超级电容可能在频繁的断电下，没有存储够足够的能量，使得系统完成保护过程。那么究竟是什么造成频繁的断电呢?按照设计要求，超级电容在3~5s内就会充满到80%的能量，理论上足够了。又有什么会不到3~5s钟频繁的断电呢?

　　说出来都匪夷所思，使用数字示波器不间断跟踪控制板的电源，才发现。原来是三相交流电需要接一个相位保护器，相位保护在系统工作时会频繁的开关(可能和系统的状态有关)。解决方法是，简单的把控制器的电源接在相位保护器前面就好了。

　　这些问题看似都是硬件问题，也是在产品的调试过程中经常碰到的问题。这些问题，需要软件工作人员确认软件中的Bug是否能造成这种情况，然后，还需要硬件工程师确认硬件。当然，硬件的确认过程漫长复杂，并且调试手段非常有限;嵌入式软件的调试相对于硬件来讲，成本和收效都会好一些。

　　所以往往需要嵌入式软件人员花很多时间确认软件问题，最后才怀疑硬件。作为嵌入式开发人员，能了解硬件的基本原理，结合软件的工作原理，和硬件工程师一起配合实验定位错误，是非常有效的办法。

　　网上有些朋友经常问我一些问题。有关于底层的知识，其中不乏一些多处理器的问题。关于多处理器的问题，我也才疏学浅，说来与大家讨论一下，关于嵌入式领域的 多CPU的应用。嵌入式说来说去是计算机科学的应用领域之一。既然是计算科学的应用领域之一，那么要做好这个领域，必须有过硬的计算机理论知识。

　　首先多处理器分为好几种，

　　处理器是同一型号，大家完全一样，通过一种通讯方式连接，如多口的RAM，rapidIO，千兆级以太网，或者PCI-E等;

　　处理器不同型号，甚至架构都完全不一样。之间通过一种通讯方式连接，同上，如多口RAM、RapidIO等;

　　同一个芯片中集成了多个CPU。这几个CPU什么都共享，属于比多口RAM还要紧耦合的系统。