为FPGA软处理器选择操作系统

在本文中，我们研究了选择嵌入式操作系统的各种方案，并且针对嵌入式和实时操作系统，讨论一些选择标准，并强调由可编程逻辑解决方案引入的设计折衷。阐述了一个典型实例，这里我们以在莱迪思半导体公司的FPGA 上运行的LatticeMico32软处理器设计为例提供一个典型方案的讨论。
　
　　引言

　　操作系统能够提高可移植性，并提供多种经过测试的抽象层，服务层和应用模块层以供选择，从而加快产品上市时间并减少应用程序出错的可能性。然而，选择一个嵌入式操作系统( OS )从来就不是一个简单的过程，因为集成嵌入式软件的方式选择余地很大，你可以完全都由自己来编写，或通过商业定制专门实时操作系统，也可以直接购买通用操作系统不作任何修改，现成的通用操作系统。FPGA性能的提高和软处理器核的出现，直接导致了可编程逻辑SoC解决方案的产生，随着这一变化，关于选择标准，设计方案以及折中考虑等传统经验也需要与时俱进以适应这些新的开发方式。

　　在本文中，我们研究了选择嵌入式操作系统的各种方案，并且针对嵌入式和实时操作系统，讨论一些选择标准，并强调由可编程逻辑解决方案引入的设计折衷。阐述了一个典型实例，这里我们以在莱迪思半导体公司的FPGA 上运行的LatticeMico32软处理器设计为例提供一个典型方案的讨论。

　　传统经验

　　根据传统经验，一个操作系统的选择有四个主要方式。

　　无操作系统

　　许多简单的嵌入式系统不需要操作系统。该代码通常始于设立堆栈指针和初始化几个时钟和外设寄存器。然后，该代码进入主循环(也称为超级循环) ，以执行产品的功能。编写中断服务程序( ISR)用以处理异步事件，以提供一些响应而不是轮询设备方式来进行服务。 ISR的响应通常是在0到10微秒的范围。如果 处理器速度 足够 快，以及超级循环是小而紧凑的，这是一个完全可行的选择。然而，如果进行更复杂的操作，如执行控制循环，提供图形显示服务，使用文件系统或网络堆栈( TCP / IP协议或其他)，超级循环将无法正常工作。如果考虑一个 快速和 功能强大的 处理器， 如开放源 代码LatticeMico32软处理器， 应该选择一个操作系统。

　　自己编写操作系统

　　对于一些特定需求，现有的解决方案无法满足需要，或者现有的解决方案成本太高，通常就需要考虑自己编写操作系统。自己编写RTOS (实时操作系统)通常不是一个好的选择，因为总是严重低估所需付出的努力。一个简单的“tasker”要写几天或几周，但更艰巨的挑战是需要对实现鲁棒性商业产品的努力。例如，一个商业的RTOS ，如μC/OS-II可能包含超过10000行的代码，已经在各种各样的产品中得到了现场验证，并可能已被认证应用于，如电子和医疗产品等。如果选择你自己编写，谁将确保长期维护，并且完成详细的文档?

　　从商业的观点来看，自己编写的RTOS不是一个好的选择。

　　商业RTOS

　　实时操作系统是一个管理微控制器，微处理器或DSP时间的软件。最重要的一个特点是它对实时事件的响应，通常不到25微秒。这种响应通常是确定性，在某些情况下，甚至相当稳定。一个实时操作系统以应用编程接口( API )的形式为应用程序员提供了许多“服务”。当选择一个实时操作系统时，从技术和业务问题方面考虑会有数十种选择。

　　技术问题可以大致分类为：

　　* RTOS对应用作出的响应够吗?

　　* 实时操作系统提供了所需的功能吗?大多数实时操作系统提供相同的基本功能：任务管理，时间管理，信号量，消息队列，事件标志等。

　　* RTOS可以实时用于不同的CPU (即代码可以移植吗)吗 ?一个 实时操作系统，如μC/OS-II已移植到超过45种不同CPU 架构， 所以在这种 情况下，可移植性不会成为问题，产品和其一部分的长寿性是得到保证的。如果使用一个新的架构，移植 到一个 CPU通常需要一两个星期。

　　* 使用RTOS是否有足够的ROM和RAM?根据所需的特性RTOS的空间可以减少吗?例如，μC/OS-II是可以升级的，代码 空间的要求在6千字节到24 千字节的之间，最低只需要500字节的RAM 。

　　从商业角度，事情并非那么容易解决。具体来说，嵌入式开发者需要从操作系统供应商那里得到满意答复，了解价格结构，支持结构和供应商的声誉和稳定性。寻找一个ROTS操作系统或RTOS的供应商时，调查通常是一个好的开端。

　　当系统响应速度是最重要时，如控制和监测应用程序，就会选择商业的RTOS，因为它们很依赖于软件的执行功能。如果你可以选择用硬件实现时间至关重要的功能，通常就不需要由RTOS提供严格的时间保证。