谈一谈嵌入式处理器问题
这里不讨论实时系统，那是一块很大的专业话题。对一般的嵌入式系统而言，由于处理器能力有限，要特别注意性能的问题。一些很好的架构设计由于不能满足性能要求，最终导致整个项目的失败。下面来谈一谈嵌入式处理器的一些问题。
一、处理器能力有限，性能要求高
即使这不是绝对的，由于嵌入式系统硬件性能所限，弹性较低。一旦发现新技术有和当初设想不同之处，就更难通过修改来适应。比如GWT技术。这是Google推出的Ajax开发工具，它可以让程序员像开发一个桌面应用程序一样开发Web的Ajax程序。这使得在嵌入式系统上用一套代码实现远程和本地操作界面成为了很容易的一件事。但是在嵌入式设备上运行B-S结构的应用，性能上是一个很大的挑战。
同时，浏览器兼容方面的问题也很严重，GWT目前的版本还不够完善。事实证明，嵌入式的远程控制方案还是要采用Activex,VNC或者其他的方案。
2、不要有太多的层次分层结构有利于清晰的划分系统职责，实现系统的解耦，但是每多一个层次，就意味着性能的一次损失。尤其是当层和层之间需要传递大量数据的时候。对嵌入式系统而言，在采用分层结构时要控制层次数量，并且尽量不要传递大量数据，尤其是在不同进程的层次之间。如果一定要传递数据，要避免大量的数据格式转换，如XML到二进制，C++结构到Python结构。
嵌入式系统能力有限，一定要将有限的能力用在系统的核心功能上。
二、存储设备易损坏，速度较慢
比如有一个应用式每天向CF卡上写一个16M的文件，文件系统是FAT16,每簇大小是2K，那么写完这个16M的文件，分区表需要写8192次，于是一个100万次寿命的CF实际能够*的时间是1000000/8192=122天。而损坏的时候，CF卡的其他绝大部分地方的使用次数不过万分之一。
除了因为静态的文件分区表等区块被频繁的读写而提前损坏，一些嵌入式设备还要面对直接断电的挑战，这会在存储设备上产生不完整的数据。
1、损耗均衡损耗均衡的基本思路是平均地使用存储器上的各个区块。需要维护一张存储器区块使用情况的表，这个表*括区块的偏移位置，当前是否可用，以及已经擦写地次数。当有新的擦写请求的时候，根据以下原则选择区块：尽量连续擦写次数最少
即使是更新已经存在的数据，也会使用以上原则分配新的区块。同样，这张表的存放位置也不能是固定不变的，否则这张表所占据的区块就会最先损坏。当要更新这张表的时候，同样要使用以上算法分配区块。
如果存储器上有大量的静态数据，那么上述算法就只能针对剩下的空间生效，这种情况下还要实现对这些静态数据的搬运的算法。但是这种算法会降低写操作的性能，也增加了算法的复杂度。一般都只使用动态均衡算法。
目前比较成熟的损耗均衡的文件系统有JFFS2,和YAFFS。也有另一种思路就是在FAT16等传统文件系统上实现损耗均衡，只要事先分配一块足够大的文件，在文件内部实现损耗均衡算法。不过必须修改FAT16的代码，关闭对最后修改时间的更新。
现在的CF卡和SD卡有的已经在内部实现了损耗均衡，这种情况下就不需要软件实现了。
2、错误恢复
如果在向存储器写数据的时候发生断电或者被拔出，那么所写的区域的数据就处于未知的状态。在一些应用中，这会导致不完整的文件，而在另一些应用中，则会导致系统失败。所以对这类错误的恢复也是嵌入式软件设计必须考虑的。常用的思路有两种：
①日志型的文件系统
这种文件系统并不是直接存储数据，而是一条条的日志，所以当发生断电的时候，总可以恢复到之前的状态。这类文件系统的代表如ext3。
②双备份
双备份的思路更简单，所有的数据都写两份。每次交替使用。文件分区表也必须是双备份的。假设有数据块A，A1是他的备份块，在初始时刻和A的内容是一致的。在分区表中，F指向数据块A，F1是他的备份块。当修改文件时，首先修改数据块A1的内容，如果此时断电，A1的内容错误，但因为F指向的是完好的A，所以数据没有损坏。如果A1修改成功，则修改F1的内容，如果此时断电，因为F是完好的，所以依然没有问题。
现在的Flash设备，有的已经内置错误检测和错误校正技术，可以*在断电时数据的完整。还有的*括自动的动态/静态损耗均衡算法和坏块处理，完全无须上层软件额外对待，可以当作硬盘使用。所以，硬件越发达，软件就会越可靠，技术不断的进步，将让我们可以把更多的精力投入到软件功能的本身，这是发展的趋势。
3、故障成本高昂
嵌入式产品都是软硬件一起销售的给用户的，所以这带来了一个纯软件所不具备的问题，那就是当产品发生故障时，如果需要返厂才能修复，则成本就很高。嵌入式设备常见有以下的几类故障：
a)数据故障。由于某些原因导致数据不能读出或者不一致。比如断电引起的数据库错误。
b)软件故障。软件本身的缺陷，需要通过发布补丁程序或者新版本的软件修正。
c)系统故障。比如用户下载了错误的系统内核，导致系统无法启动。
d)硬件故障。这种故障只有返厂，不属于我们的讨论范围。
针对前三类故障，要尽可能*客户自己，或者现场技术人员就可以解决。从架构的角度考虑，如下原则可以参考：
a)使用具备错误恢复能力的数据管理设计。当数据发生错误时，用户可以接受的处理依次是：
i.错误被纠正，所有数据有效
ii.错误发生时的数据(可能不完整)丢失，之前的数据有效。
iii.所有数据丢失
iv.数据引擎崩溃无法继续*
一般而言，满足第二个条件即可。(日志，事务，备份，错误识别)
b)将应用程序和系统分离。应用程序应该放置在可插拔的Flash卡上，可以通过读卡器进行文件复制升级。非必要的情况不要使用专用应用软件来升级应用程序。
c)要有“安全模式”。即当主系统被损坏后，设备依然可以启动，重新升级系统。常见的uboot可以*这一点，在系统损坏后，可以进入uboot通过tftp重新升级。
