CPU 内部的以太网控制器只提供了MAC(媒体接入控制器)，需在外部接一个物理层芯片完成编解码和时钟恢复等功能。串行接口芯片主要完成串行线路接口的电平转换。

(4)CPLD 和 FIFO

为了能使系统支持实时数据通信，需要在外设和嵌入式系统的外部总线之间加上 FIFO 和CPLD。FIFO 用于数据缓冲，CPLD 用于产生 FIFO控制逻辑和外部总线控制逻辑。

1．2 操作系统

ARM7TDMI 内核已被众多的嵌入式操作系统所支持，如 VxWorks、pSOS 及

Nucleus 等。这些商业化操作系统在网络和用户图形界面等方面都有很好的支持，并且在稳定性和实时性方面都有相应的保证，但其价格也相当高。这里选用了开放源码的嵌入式 Linux，它一般免费或花较少的费用就可得到，同时它在网络和图形界面方面也有很好的支持。另外，嵌入式 Linux 的高度模块化使它可以根据实际应用需要灵活配置，能有效精简内核代码。嵌入式 Linux 具有很高的稳定性。在实时性方面，尽管 Linux 本身未作过多关注，但可通过打实时 Linux(RTLinux)补丁解决。

针对所采用的 CPU 没有 MMU，选用了目前在嵌入式系统中被广泛使用的μClinux。μClinux 是从标准的Linux 2．0 内核发展而来的，但其源代码针对典型的嵌入式应用已经作了许多精简和修改，使得其内核比标准的 Linux 内核要小很多，不过它仍然保留了标准 Linux的主要特色。

目前最新的μClinux 版本已经支持 S3C4510B 及典型开发板，如果所采用的 CPU 及开发板没有被支持，应根据实际情况移植。此外，由于在外部总线接了 CPLD和 FIFO，为了使应用程序能访问它，需要在μClinux 下开发相应的驱动程序。

2 实时数据接口的扩展

2．1 应用要求

将上述嵌入式系统应用于实时多媒体数据的网络传输，如图2所示。这里的实时多媒体可以是 MPEG-4或 MPEG-2 等，其数据流一般是连续、恒定码率的。

2．2 硬件扩展

根据上述数据流的特点，需在嵌入式系统与外设(编、解码器)之间加入数据缓冲控制单元。对于发送端和接收端，数据缓冲控制单元的设计有所不同，下面以MPEG-2 为例说明。这里考虑系统的处理能力、网络的承受能力以及图像质量，MPEG-2 的输出为 4Mbps 的CBR(固定比特率)TS流。

2．2．1 发送端

编码器送出连续、恒定速率的码流。如果将此码流直接送到 CPU 外部总线，将会导致操作系统频繁地处理中断，甚至会产生中断不能及时处理从而导致数据丢失。因此，有必要在编码器与外部总线之间加上 FIFO，同时用 CPLD 实现 FIFO 的读写控制逻辑。编码器送出的数据流连续不断地以恒定速率写入FIFO；当FIFO中的数据积聚到一定值后，每写入若干个数据就向CPU发一个中断；CPU在收到中断后通过外部总线读入相当量的数据，并将其打包送入网络。正常情况下，每个中断读数据个数是一定的，在一段时间内FIFO写入和读出将维持平衡，且不会产生“饥饿”状态；当操作系统因处理别的任务而没有及时响应中断时，FIFO将暂时进入“饱和”状态，但只要FIFO容量足够大就不会产生数据溢出现象。由于CPU从FIFO读取单位数据的速度大大高于外设向FIFO写单位数据的速度，“饱和”状态一般能消除。由此，可以解决前述问题。

2．2．2 接收端

在接收端，由于解码器的输入要求是一个连续、恒定速率的码流，同样要求在CPU外部总线与编码器之间加上FIFO和CPLD。同时，接收端的数据包由于经过了网络，不可避免地会引入延时，且数据包之间的延时是不确定的，甚至会产生数据包的丢失。这些都需要在接收端予以考虑，增加了接收端数据缓冲控制单元的复杂度。

为了解决数据包到达延时及抖动问题(数据包的丢失将间接导致延时的增加)，可以简单地靠增大FIFO容量解决。但增大FIFO将意味着从编码器到解码器之间延时的增加，影响了实时性。因此，为了保证一定的实时性，同时考虑成本因素，不能单纯靠增大FIFO解决。

由于FIFO容量的限制，在出现大延时的情况下

上一页  [1] [2] [3] 下一页