TM1300是Philips公司为音频、视频等多媒体应用而专门设计的多媒体处理器。除具有DSP的基本功能外，该处理器还针对音视频应用进行了优化，并在片内集成了视频输入/输出、音频输入/输出及高速同步串行通信等接口，因而在多媒体信息处理领域有非常广泛的应用。图1给出了笔者设计的多媒体处理平台的系统结构。

    系统的核心是运行pSOS操作系统的TM1300芯片。视频输入和输出接口利用TM1300本身提供的视频输入/输出单元，结合外围的视频A/D、D/A芯片共同完成。其中，视频A/D使用Philips公司的SAA7111，而D/A则使用SAA7121。它们可以与TM1300进行无缝连接。事实上，所有与CCIR656/CCIR601兼容的视频A/D、D/A芯片均可以直接与TM1300的视频输入输出单元相连。
    音频输入/输出接口上的A/D、D/A芯片采用了Analog Devices公司的AD1849立体声处理芯片。AD1849是16位串行接口立体声信号编解码器。它具有多个输入通道和输出通道，支持μ率PCM、A率PCM、16位线性PCM和8位无符号PCM四种编码方式。

    除音频、视频接口外，还设计了基于CS8900的以太网接口，以便能将多媒体处理的结果直接发送到以太网。RS-232接口是本设计的另一个通用接口，计算机可以通过该接口对系统的运行进行控制，并获取系统运行状况。
    在实际应用过程中，由于用户的需求各不相同且经常变化，这就要求多媒体处理平台的参数需要经常调整，某些时候还需要实时调整。尽管这些功能可以通过RS-232接口实现，但这要求操作人员到现场用计算机对多媒体处理平台进行控制，很不方便。为此，设计一个嵌入式Web服务器，利用网络对整个平台进行控制成为一种必然的选择。一方面它可以为用户提供可视化的图形界面，方便用户进行各种参数控制；另一方面，用户可以在任何时间对参数进行调整，满足自己的需要。
1 嵌入式Web服务器开发的难点
    谈到Web服务器，人们自然会想到目前常见的Web服务器, 如Windows IIS、Apache、CERN Server、Netscape
Enterprise Server等。由于这些服务器程序的功能非常强大，通常需要在高性能计算机上运行，以便为用户提供高速、并发的访问。
    相对于计算机上运行的Web服务程序，在TM1300上运行的Web服务有很多独特的特点：
    首先，尽管TM1300的运算处理能力非常强大，但由于其主要功能是完成多媒体信息的处理，使得Web服务所能使用的系统资源非常有限。这就意味着不能将传统的Web服务程序直接移植到TM1300上，而必须对其功能进行裁减，去除那些不需要的功能，减少其对资源的要求，提高运行效率。
    其次，TM1300没有自己的文件系统，这就意味着不能依赖文件系统来保存网页，而必须要Web服务器自己来维护和提供不同功能的网页。
    此外，由于该Web服务主要用于控制多媒体平台的运行参数，通常情况下不会有很大的外部访问流量。因此Web服务器的功能相对简单。
    根据以上特点，笔者设计了在TM1300上运行的Web服务器程序。该程序首先对接收到的HTTP消息进行解析，然后调用不同的处理程序进行处理，最后将处理的结果以HTTP消息的方式回送给浏览器。
2 Web服务在TM1300上的实现
    本Web服务程序主要负责接收IE浏览器发送的请求，然后对请求进行分析和处理，并将处理结果以HTML方式返回给浏览器。核心是对HTTP请求进行分析。下面以修改图像编码尺寸为例，介绍具体的实现方法。
    假定在某个时刻用户希望修改多媒体平台所处理的图像尺寸，于是通过IE浏览器访问所设计的Web服务器，得到图2（a）所示的界面。当用户在文本框中输入合适的数值后，点击“确定”按钮，IE浏览器将向Web服务器发送图2（b）所示的HTTP报文。

    其中最重要的是第一行和最后一行。在第一行中，/changimagesize 告诉服务器程序用户希望修改图像尺寸。最后一行中的xsize=352和ysize=288表示新的图像尺寸。由于 HTTP数据包是纯文本格式^[1]，因此在Web服务程序需要对第一行文本进行分析，取出字符串“POST”和“HTTP”之间的字符串即可判断出用户操作的类型。
    接下来需要从HTTP头信息^[2]中，找到Content-Length这一行。如果Content-Length=0,则表明后面没有参数，否则在这个HTTP数据包中包含用户提交的信息，并且信息的长度值就是Content-Length的值。
    假定用户在HTTP消息中带有消息体，那么首先要找到一个空白行(即：Cache-Control:no-cache后面一行)，因为它是消息体和HTTP头信息的分界线。接下来需要分析消息主体的内容。这方面的工作非常简单，就是根据字符‘&’将文本串分为三部分，即：xsize=352,ysize=288,submit=%CC%E1%BD%BB。然后根据字符‘=’进一步区分参数的名称和对应的值。通过分析知道参数xsize的值为352，ysize的值为288。
    通过对HTTP消息的解析，可以确定用户需要完成的操作及操作所需要的参数，进而可以对底层的硬件或软件进行控制，以完成用户的请求。
    由此可以看出，服务器程序的核心工作就是对HTTP数据包解析，决定下一步的处理。针对上面的例子，Web服务程序首先要对视频输入输出接口进行控制，改变输入输出图像的尺寸；接下来还要输出HTTP数据包送给IE浏览器，图3给出了Web服务程序产生的HTTP数据包及用户看到的界面。

    图3(a)是服务器回送给IE浏览器的HTTP消息。第一行HTTP/1.1 200 OK通知IE浏览器，刚才的请求已经被服务器处理。下面一行是服务器的处理时间。 Content-type:text/html这一行通知IE浏览器HTTP消息主体部分传送的内容是纯文本格式的HTML网页。后面的空行是HTTP头信息与HTTP消息主体的分界线。当IE浏览器获取HTTP头信息后，就可以根据消息主体的格式调用对应的HTML解析器对内容进行解析，并将解析的结果显示在浏览器的窗口中。
3 Web服务进程与其他进程间的通信
    由于多媒体处理平台需要同时进行音频、视频处理及网络通信，即在同一个时刻需要有多个任务同时运行，并且这些任务之间需要进行通信，例如：当用户改变了系统编码参数后，Web服务器需要通知视频编码进程，让它们在后续的编码过程中采用新的参数。由于TM1300运行pSOS系统，而pSOS只有进程，没有线程，因此Web服务程序作为一个单独的进程来运行。当需要与其他任务通信时，采用了信号量方法。图4以Web服务进程和视频编码进程之间的通信为例，给出了系统实现进程间通信的过程。

    首先在Flash中开辟一块区域，专门用来存储所需修改的参数。当Web服务器接收到客户端提交的修改参数的请求时，采用以下步骤进行处理：（1）Web服务进程将信号量锁定；（2）Web服务进程将用户提交的参数写入到参数区；（3）Web服务器进程释放信号量；（4）Web服务进程向视频处理进程发送信号^[3]，通知视频编码进程读取参数；（5）视频处理进程将信号量锁定；（6）视频处理进程读取参数；（7）视频处理信号释放信号量。经过一系列操作后，Web服务器进程和视频编码进程间的通信结束，完成了一次参数的修改。Web服务进程与音频编码进程间的通信与上述过程类似。
    本文重点探讨了在TM1300上实现嵌入式Web服务器的方法与具体实现中的一些关键问题。通过在现有的多媒体处理平台中增加Web服务，用户可以采用Web页面的方式来监控硬件的运行状态，并能对系统运行参数进行在线修改，降低了系统的使用难度，提高了交互的友好性，进而增强了系统的功能和可用性。目前，笔者开发的Web服务已经在TM1300上稳定运行，下一步工作主要是扩充其功能，并提供网管功能。
参考文献
1 RFC 822.Standard for ARPA Internet Text Messages[s].1982
2 RFC2616.Hypertext  Transfer  Protocol----HTTP/1.1[s].1999
3 W. Richard Stevens著，尤晋元译. UNIX环境高级编程.北京：机械工业出版社，2000