eCos仿真目标机(1)——简介

原文：http://ecos.sourceware.org/docs-latest/ref/synth.html
译文：http://blog.csdn.net/zoomdy/article/details/8887459
mingdu.zheng <at> gmail <dot> com

通常情况下，eCos运行在针对特定应用定制的板子上，或者是最终的板子出来之前就能够使用的某种类型的开发板上。 这些板子有一些共同点：

1. 很明显，这些板子至少有一颗处理器（CPU/MCU）。一般情况下是32位的处理器，也有可能是其他位宽的处理器。 处理器的速度依据具体应用而定，有快有慢。
2. 这些板子需要存储器存储代码和数据。 典型的系统通常会有两种类型的存储器，一种是像Flash、 EEPROM、 掩模ROM之类的非易失存储器，还有一种是像DRAM、SRAM之类的易失存储器。 一般情况下，应用程序的代码存储在非易失存储器，而所有的RAM用来存储数据。 但是更新非易失存储器并非易事，比较便捷的做法是：首先烧录一个与硬件匹配的固件（例如RedBoot）到非易失存储器， 然后使用这个固件加载准备调试的应用程序到RAM中执行，这需要为这个固件预留一些存储空间。
3. 这些板子必须提供指定的最小I/O设备，多数eCos配置需要一个时钟信号或者是类似的周期性输入信号。 同时也必须提供输出诊断信息的通信接口，通常是串口，也可以是其它类型的通信接口。 除非使用专门的调试电路，否则还要为调试器提供连接开发主机和目标硬件的双向通信接口， 通常使用串口或者以太网建立调试通信通道。
4. 有了上诉的这些基本特性后，这些板子实际上还是没什么用处， 因为除了能输出诊断信息外还不能与其他事物进行任何的交互。因此通常情况下嵌入式设备还会有其他附加的I/O设备， 这可能是一些标准的设备像以太网或USB接口，也可能是针对特定的应用设计的专用设备，更普遍的情况是既包含标准设备也包含定制设备。 像以太网或USB之类的标准设备是由eCos的设备驱动程序和协议栈实现的，而定制设备则由应用程序直接控制。

上诉的很多特性均可以使用一台运行Linux系统的PC机来仿真（Emulate）， 处于开发阶段的嵌入式应用程序可以作为Linux的一个进程在Linux系统上运行，而不仅仅是在目标机上运行。 所使用的处理器是PC机的处理器，比如说x86处理器，所使用的存储器是进程的地址空间。 一些I/O设备可以直接通过系统调用来仿真，比如说滴答定时器可以通过设置可以产生间隔中断的SIGALRM信号来实现。 这种对真实硬件的仿真在时间上不可能非常精确，通常情况下PC机的运算速度比嵌入式设备的运算速度要快得多， 而且不同的PC机配置其运行速度也不尽相同，撇开速度上的问题，仿真对于大多数开发工作都是利大于弊的。

其它的I/O设备通过I/O辅助进程（I/O auxiliary process, ecosynth）来仿真， I/O辅助进程由eCos应用程序在初始化过程开启。当一个eCos设备驱动期望执行某些I/O操作时，例如发送一个以太网数据包， 设备驱动就发送请求到I/O辅助进程。I/O辅助进程是一个常规的Linux进程，因此I/O辅助进程可以访问所有的Linux系统上的I/O设备。 I/O辅助进程通过发送SIGIO信号给eCos应用程序来仿真中断，HAL安装了信号处理函数来处理SIGIO信号，信号处理函数被SIGIO信号触发调用， 随后信号处理函数调用标准的eCos的ISR/DSR中断处理函数。I/O辅助进程主要是通过TCL语言实现的，这使得扩展和定制变得更加容易， 通过配置仿真目标机(Synthetic target)达到非常近似地仿真硬件I/O功能是完全可能的。

图 1. eCos与I/O辅助进程

实现仿真目标机(Synthetic target)代码的关键是：eCos应用程序不能链接到任何的Linux系统库， 例如Linux系统下的C库，eCos和Linux系统库可能会导出相同的符号，例如printf函数，这将导致符号冲突最终导致链接失败。 因此仿真目标机(Synthetic target)必须直接通过Linux内核的系统调用接口来实现。比方说，内核提供了一个写操作（write）的系统调用， 实际上write函数是在系统的C库里实现的，write函数将入参压入堆栈或者存储在指定的寄存器中， 然后执行系统调用指令（例如x86的int 0×80指令），系统调用指令被CPU执行后，CPU控制权交给了内核， 内核检查入参然后执行相应的操作。但是仿真目标机(Synthetic target)不能链接到系统的C库，取而代之的是cyg_hal_sys_write函数， 这个函数就跟C库里的write函数一样将入参压入堆栈然后执行系统调用指令。 Linux内核没有办法区分系统调用是C库请求的还是仿真目标机(Synthetic target)请求的，所以Linux内核一样会处理仿真目标机(Synthetic target)发送的系统调用。 有了执行系统调用的方法后，就可以使用系统调用来仿真I/O请求了。 例如，通过系统调用cyg_hal_sys_fork和cyg_hal_sys_execve来启动I/O辅助进程； 通过cyg_hal_sys_write向I/O辅助进程发送请求。

在很多方面，在仿真目标机上进行开发和在真实嵌入式系统上进行开发并没有什么区别。 eCos必须正确地配置，选择一个适用的目标机(Target)（例如i386linux），配置系统会根据目标机加载所有必须的组件， 包括一个架构HAL组件和平台相关组件，架构组件包含了可应用在所有Linux平台上的通用代码， 平台相关组件包含了特定的Linux实现的相关代码，例如x86版本的实现，还包含了处理器相关的代码。 选择目标机还会引入一些设备驱动组件。其它方面的配置取决于模板、组件的添加和删除、组件的细粒度配置等。

另一方面，在仿真目标机上进行开发比在真实嵌入式系统上进行开发要更加的简单。 比方说，不再需要通过串口或者类似的接口下载以及调试应用程序。 编译仿真目标机的eCos应用程序就像编译普通的Linux程序一样简单， 在Linux终端输入可执行文件名就可以运行eCos应用程序，使用Linux系统的任意版本的gdb就可以对应用程序进行调试， 不需要编译或安装交叉编译器。特别地，使用仿真目标机可以绕开开发过程中的那些与真实硬件有关的问题，比方说， 硬件尚未准备就绪或者存在严重的设计缺陷。使用仿真目标机也使得软件和硬件的并发设计变得可能。

eCos的仿真目标机提供了仿真（emulation）的功能，而不是模拟（simulation）的功能。 在适当的架构模拟器上运行eCos是可能的，但是使用模拟器进行软件开发是另一种套路。 比如说，在ARM模拟器上运行eCos需要一个合适的交叉编译器来编译ARM的可执行文件， 然后ARM模拟器加载可执行文件并对每一条指令进行解释，试着模拟出真实硬件的执行效果， 这涉及到非常多的处理过程，但是模拟器可以给出与真实硬件非常接近的结果。 当开发仿真目标机应用时，代码被编译成使用PC机指令的可执行文件，而且以全速执行可执行文件， 不需要模拟器和其它特别的工具，和模拟器相比，这种方式运行速度更快而且操作起来更简单， 但是不能精确的模仿真实硬件的特性。