专利名称：以软件实现的在通用计算机上在非实时环境中操作的调制解调器的制作方法
技术领域：
本发明涉及数据通信，特别是涉及调制解调器的软件实现，它能在具有非实时、多任务运行环境的通用计算机上操作。
现代调制解调器用于把PC或其他数据终端设备(DTE)连入广域通信网，在其中使用电话系统携带从一个PC到另一PC的信息。多年来，已经开发了许多通信标准，使一个制造商制造的遵从标准的调制解调器能与另一个制造商制造的遵从标准的调制解调器通信。这些协议规定了一个通信协议的各个方面，例如在此标准下使用的信号构象(constellation)和编码方法。
迄今为止，调制解调器通常一直是以专用电路或可编程数字信号处理器(DSP)来实现。在典型安排下，一个微处理器和一个DSP会以主从关系有效地合作。微处理器将起“控制器”的作用，承担控制功能，如配置该系统等，而DSP将基本上起专用计算引擎的作用去处置信号处理的各方面。
上述典型安排要在“实时”前后关系(context)中运行。就是说，微处理器和DSP二者都要是专用的，以分别运行调制解调器控制器和DSP软件。实时前后关系提供了确定性行为，而这种确定性行为又是调制解调器前后关系中所希望的，因为调制解调器数据流是连续的并以固定速率到达。
虽然上述结构安排已在市场中被广泛接受，但DSP和其他专用硬件涉及部件费用问题。再有，它们增加了相关联的制造、供给和维护方面的费用，并影响整个系统的可靠性。
在附图中
图1是本发明一个实施例的硬件结构图；图2A是传统的现有技术调制解调器的中断模式；
图2B是一个实施例中的中断模式；图3是软件结构图，说明本发明的一个在多任务、可预占的操作系统中运行的实施例；图4是软件结构图，说明本发明一个实施例的各个子系统；图5说明根据本发明的一个实施例，各子系统操作所处优先级；图6与本发明的一个实施例的子系统一起说明优先级的赋值；图7显示本发明一个实施例的选定数据泵(datapump)的各方面；图8显示本发明一个实施例的HRT中断服务例程的逻辑结构；图9显示本发明一个实施例的一个数据泵的发送部分逻辑结构；图10显示本发明一个实施例的一个数据泵的接收部分逻辑结构；以及图11显示本发明一个实施例的一个数据泵的发送部分方框图。
本发明的实施例是调制解调器的软件实现，特别设计成在一个主处理器上操作，该主处理器由一个非实时的、多任务操作系统(OS)控制，例如视窗95操作系统(Windows95 OS)。调制解调器的软件设计是可缩放的(scaleable)和轻便的。按这种风格，通信协议(特别是数据泵)可以容易地添加到系统中或从系统中去掉，而且调制解调器可以容易地适应于在其他类型处理器和操作系统上使用。
与具有专用微处理器和DSP的通常调制解调器结构安排不同，本发明实施例除了主PC外只需较少量的硬件。图1显示了ISA卡形式的一个这样的实施例。(这个硬件结构安排在赋予Sridhar等的待决美国专利申请08/607,911中讨论，该申请被转让给本申请的受让人，并在这里全文纳入作为参考)。下文中对此硬件结构安排的概括说明只以理解本发明的实施例所必须的程度为限。
实施例硬件结构安排100包括一个主处理器102，与一ISA总线104耦合，该总线与一ISA卡105耦合。ISA卡包括一个示例ASIC 106，它在总线104上经由IRQ/Addr/Data线114进行通信。ASIC 106与一个声音编码解码器108及一个数据编码解码器110耦合，数据编码解码器110与一数据访问结构安排(DAA)耦合。声音编码解码器108与一微音器输入及一扬声器输出耦合，而DAA与电话线116耦合。
简单地说，编码解码器108、110完成A/D和D/A转换。ASIC包括接收和发送数据FIFO 118r和118t，它们分别保持最终要被软件调制解调器解调和处理的数据样本和已被软件调制解调器调制和处理但需要转换成模拟形式的数据样本。ASIC 106进一步包括接收和发送声音数据FIFO 120r和120t，它们以例如8位PCM(例如μ-律)形式保持要被主处理器102处理的声音数据。FIFO的大小及其控制允许对主处理器102的中断等待时间被延长。各实施例的实际大小及其控制在该待决申请中讨论。
虽然所示示例结构安排100是作为一个ISA卡结构安排，但本领域技术人员会理解，本发明可应用于其他结构安排。例如，模拟逻辑可以在另一种ASIC结构安排中实现，其中FIFO在ASIC外部的存储器芯片中实现，或者其中的编码解码器在ASIC中实现。再有，其他结构安排可以在含有主处理器102的母板上实现而不是在ISA卡上实现，而且声音编码解码器和FIFO是可选的。
图2A和2B一起比较典型DSP结构安排和软件调制解调器实施例的“中断模式”。图2A显示典型的DSP结构安排的中断模式。在此模式下，一个数据符号(或波特(baud))是由调制解调器在一次中断中处理的。这个数据符号可能对应于若干个数据样本，例如3个。图2B显示一个实施例的中断模式。例如，对于一个给定的硬件中断，可以取得90个样本(以7.2KHz的取样率)，这对于以2400波特运行的数据泵和有3X采样率的系统，则相应于30个符号。在这一模式下，ASIC 106收集许多符号而对主PC 102以基本上规则的间隔产生中断。在主PC上执行的软件调制解调器响应这些中断收集若干样本并根据调制解调器算法处理它们。
图2B缓存和中断模式提供了若干好处。第一，缓存缓解了中断等待时间的不可预测性；就是说，至少与传统调制解调器的实时前后关系相比是不可预测的。第二，缓存允许主处理器102响应中断的速率低于实时前后关系中的DSP要响应中断的速率。在一个多任务环境中，较低的中断速率减少了前后关系中往返切换中断服务例程的次数，这样不仅减少了要执行的指令(即前后关系中的切换所涉及的指令)，而且改善了高速缓存的利用，从而改善了系统的性能。
如在该待决申请中解释的那样，主PC能动态调节FIFO深度和中断速率。以这种方式，一种中断速率可以用于稳定状态的操作，而另一种速率可以用于启动序列的某些阶段，在那些阶段存在一些时间紧迫的需求。例如，在稳定状态操作期间，中断速率可设为大约12到12.5ms，而在某些启动阶段，该中断速率可设为2.5ms。在这种安排下，在稳定状态操作期间一次主处理器中断处理大约90个数据样本，而在V.32的测距(ranging)阶段在中断期间处理约18个数据样本。
图3显示本发明一个实施例的高层软件结构图，该软件是要用于视窗95 OS的。由虚线部分310包围的软件部件是传统的视窗OS基础结构，包括使应用程序320与一传统调制解调器319(如果它与系统相连的话)通信用的传统基础结构。软件应用程序320代表了可通过调制解调器链路进行通信的各种应用。
在一种意义上讲，软件调制解调器包括部分330的部件。软件调制解调器的核是Soft Modem VxD 334(基于主机的调制解调器)。UARTVxD 332是传统的UART的软件仿真，例如在允许DOS应用程序用于图示的环境方面很有用。(UART仿真可在市场上买到)。电话线接口卡336是指前文概述的有各种形式的所有硬件。
基于主机的调制解调器334使用传统技术通过OS的VCOMM实体314与OS基础结构集成在一起。简言之，在这种模式下，基于主机的调制解调器334作为一个串行通信装置以VCOMM有效地登录其本身。它还以OS Unimodem V实体312进行登录和由OS Unimodem V实体312控制，作为一个数据/传真/声音调制解调器，这也是使用传统技术实现的。
希望使用调制解调器进行通信的任何应用程序322、324通过OS基础结构310，特别是通过VCOMM 314，使其请求送到基于主机的调制解调器334的适当入口点。如果使用的是硬件调制解调器319，则由VCOMM 314使请求通过串行VxD 316(OS基础结构310的部件)送到硬件UART 317并最终送到硬件调制解调器319。
图4显示一个基于主机的调制解调器示例334的更详细的软件结构400。如在下文中按前后关系更详细解释的那样，该结构有各种子系统。每个子系统可以有在三个优先级之一执行的软件逻辑，或有响应在这三个优先级之一上执行的软件的软件逻辑，这三个优先级是HRT、SRT和BRT(从最高优先级到最低优先级)。例如对应用320，OS也承认其他优先级。在一给定优先级，例如BRT，OS将根据预先定义的调度规则作出调度决策。这样，例如，在时间分片循环算法之下，在其优先级低于BRT下操作的一个应用程序将有一个最大时间量，在此期间它能使用主处理器102，然后它将不得不放弃控制。再有，一个给定的优先级，例如BRT，能被一个较高优先级的例程，例如一个HRT例程，予先占领，即使该BRT例程尚未结束。
通过使用多优先级，使基于主机的调制解调器334更能在有效地处理实时数据流和经济地使用主处理器资源这两种对立需求之间取得平衡。考虑一个不成熟的设计会使这一点更加清楚。一个不成熟的设计将使整个基于主机的调制解调器在最高优先级操作。因为该逻辑将只在最高优先级操作，所以它不能被其他例程预先占领，这样，便会使其环境多少类似于传统的实时环境。(当然，HRT例程能被另一个HRT例程阻挡，所以该不成熟设计和传统实时设计不是严格等效)。虽然这个不成熟的设计在原理上讲是可以操作的，但使用者大概会发现这个不成熟设计是他们所不希望的，因为它可能会从其他应用，包括使用者正在用于建立通信的那些应用那里去霸占系统资源。因此，本实施例努力在操作实时数据流和经济地使用系统资源二者之间建立平衡。
HRT是“硬实时(Hard Real-Time)”的缩写，它是作为一个硬件中断服务例程(ISR)来实现的。除了其他情况外，HRT逻辑可以被认为是负责处理发送和接收FIFO118、120(图1)的。对于调制方式而言，如果不能跟上相应的数据速率，则将对数据链路造成很显著的压力。这样，HRT例程实现了SoftChip数据泵410的一些部分，特别是用于状态机器控制逻辑的数字信号处理部分和时间紧要的部分。类似地，HRT逻辑包括ASIC驱动器465的一些部分和系统服务455的一些部分，它们在波特级被调用。HRT任务的调用是来自ASIC硬件的中断的结果(大约每12至12.5ms一次)。下面将讨论该逻辑如何被调用。
SRT是“软实时(Soft Real-Time)”的缩写，它是作为一个全局事件例程在例如视窗95 OS中实现的。在一个实施例中，HRT ISR在每隔一次的HRT ISR触发中发送全局事件。这样，由于HRT ISR大约每12.5ms操作一次，所以SRT例程大约每25ms被触发一次。称作中央调度(CD)的一个子系统除了其他事情之外还保持一个SRT计时器队列。当400中各子系统的任何一个需要实现计时或监测操作时，例如监测超时，它们便把参考发送给CD的SRT计时器队列中的一个回调例程中。然后该计时器队列将在适当时刻调用该回调例程。以这种方式，发出回调的子系统可以监视延续时间等，而这是实现通信标准所必须的。当然。在计时器队列中参考的实际回调例程随着基于主机的调制解调器系统334的状态而动态的变化。例如，基于主机的调制解调器在某些情况下需要及时监视超时状态，但在其他情况下则不必。可以以各种切换方式使回调例程进入计时器序列。例如，该回调例程可以以指明它应保持在队列中直至被清除或直至发生一指定的超时这样的信息进行登录。或者，该回调例程还可以以一个指示来登录，该指示指出在一指定时间后一特定事件应被发送到BRT事件队列中。(更多描述见下文)然而，HRT软件逻辑可概括为负责发送和接收FIFO，SRT逻辑可被认为是负责通常在调制解调器中发现的各种“计时器例程”。例如，典型的调制解调器有各种功能去测量消耗的时间或监测或查询某些信号。
BRT是“后台实时(Background Real-Time)”的缩写，它是基于主机的调制解调器334所用的最低优先级，但不一定被整个PC系统使用。如下文所描述的那样，基于主机的调制解调器334实际上使用2个单独的可调度的BRT例程。与SRT计时器队列多少相似，中央调度415包括一个事件队列。在这个意义上，尽管在SRT队列中回调例程的调用是基于时间的并具有25ms的时间“颗粒”，但BRT例程的调用是基于事件和消息的，没有时间颗粒。在基于主机的调制解调器334中所用各种子系统通过事件和消息彼此通信。这样，例如在一个AT命令中，数据IO单元450可以被首先用于接收字符流，并当检测到一个回车时它将向自动呼叫(autocall)单元430发送一个事件，通知它已经收到一个AT命令。这样，在这个意义上，基于主机的调制解调器在所描述的子系统级可以被认为是一个大状态(large state)机器，其中的状态转换由事件触发。(如下文中描述的那样，各子系统又有它们自己的状态)。在某些情况下，一个子系统需要基本上进入“睡眠状态”，例如，一个子系统可能需要等待一个响应或超时。所以，SRT队列包括一个在这些情况中发送事件的机制。这样，如果发生一个超时，则向等待响应或超时的子系统发送一个事件，从而使它从其等待或睡眠状态中醒来并将超时通告给该子系统。
在一个实施例中，SRT和BRT在效果上是次优先执行级。其上设执行优先级对应于由HRT发出的全局事件。全局事件通过系统服务455传送到CD 415中的一个回调例程，它对应于SRT调度逻辑。SRT调度逻辑在效果上实现次优先级，作法是首先处理在SRT计时器队列上的回调例程。然后，在主BRT事件队列上的事件被处理，后跟EC BRT逻辑。两组BRT都包括逻辑以确保它们只做有限的处理而且它们不会使其他例程缺乏资源(例如循环计数逻辑)。再有，它们包括逻辑以检验一个状态标志，从而确定在它们进行处理期间HRT ISR是否已发出了另一个全局事件，如果是的话，则它们重新启动。
上述逻辑多少是在视窗95 OS下运行的实施例的结果。这个OS(操作系统)的可用执行优先级个数有限，所以本实施例实现上述次级优先基本上是因为该OS没有提供所需要的优先级。(具有更多优先级的其他OS可以在真正单独的由OS实现的执行优先级上实现SRT和BRT，而不必象在本实施例中所作的那样使用仿真)。再有，在本实施例中使用逻辑限制处理，这是因为在视窗95下操作系统不对处理硬件中断或全局事件的各例程进行时间分片。
本发明的另一实施例以在应用执行优先级上的两个单独任务来实现上述在BRT优先级上执行的逻辑。虽然这一实施例提供的好处是OS级支持执行优先和对BRT例程时间分片(以避免使其他应用缺乏资源)，但在使用者大量并发运行的应用时，它易于延迟。
参考图4，一些子系统被认为是一个“公共核”，由于它的设计使它很易于移到其他平台上。其他方面是更针对平台的，其结果是不太易于移动；这些其他方面通常做成针对平台的，借以用牺牲可移值性来改善性能。
这公共核包括SoftChip(软芯片)数据泵部分410，中央调度(CD)415，主控420，配置管理425，AutoCall(自动呼叫)命令处理430，协议处理435，软芯片控制440以及测试445。
SoftChip数据泵部分处理所有的数据泵和信号处理功能，如音调产生、呼叫进行、呼叫分类以及其他传统的数据泵和信号处理功能。这些功能可以依赖于相应的标准，如V.34，V.32bis等，它们每一个要有相应的能耦合到结构中的数据泵，而且它们每一个要被集成到SoftChip(软芯片)数据泵部分410。它还包括自动方式逻辑。(自动方式(automode)是本领域公知的)。
在SoftChip(软芯片)数据泵410内的每个数据泵基本上包括两类代码状态机器控制代码和数字信号处理代码(请勿与DSP所用代码混淆)。源代码被设计成高度可移植的。数字信号处理部分是用“宏”实现的，这些宏在效果上是迫使编译器以某种方式编译这些宏，例如编译成机器指令特定序列。(以后各部分描述用于改进其可移植性和可伸缩性的其他方面)。
中央调度(CD)415管理事件(BRT)和计时器队列(SRT)。简言之，对于后台优先级及计时器优先级，主处理循环从此地开始，并根据队列的状态使控制调度到一个适当的子系统。
主控420提供更高级别的控制功能，诸如连接/断开处理；例如通知一指定序列中的各子系统关于断开的情况。
配置管理425维持一个配置数据库，它类似于由传统调制解调器和控制器完成的数据库。这一部分的软传逻辑是传统的，允许配置波特率、流控制等，就像在传统调制解调器中的情况那样。
Autocall(自动呼叫)命令处理器(ACU)430处理来自终端的命令，类似于传统调制解调器的控制器。这些命令可以是不同的已知格式，如AT、V.25bis以及LPDA。
协议处理器(PP)435处理数据方式协议。例如，这部分包括软件逻辑支持具有MNP 2-5和/或V.42bis的错误校正/数据压缩(EC/DC)。这部分还可能支持其他协议，如用于传真、蜂窝电话、或同时声音传送的协议。数据压缩逻辑能包括针对平台优化过的宏。这一部分包括它自己单独的可调度BRT任务，用于纠错(EC)逻辑，它以这种方式组织使得EC逻辑造成其他BRT线程缺乏资源的危险性最小。
软芯片控制440把事件翻译成用于软芯片数据泵410的适当控制设置。如下文将描述的那样，SoftChip(软芯片)数据泵有一个与专用DSP的接口类似的接口，以改进可移植性和可伸缩性。除了其他方面外，这一点允许写出用于各实施例或用于各DSP的数据泵。这一控制将把发送给软芯片控制440的事件翻译成适当的寄存器设置，以启动数据泵。
测试部分445包括测试和诊断支持逻辑。
结构400的更针对平台的方面包括数据IO部分450，系统服务接口455，串行驱动器接口460以及ASIC驱动器465。
数据IO部分450提供较低级别的服务，用于内部数据传送，例如，对诸如串行通信控制器(SCC)等有用外部设备的仿真，例如异步组帧功能和HDLC组帧。
系统服务接口455把上述核与操作系统隔离，例如与视窗95隔离。以这种方式，使基于主机的调制解调器334可以大大地独立于OS，而把许多必须的依赖部分留在系统服务接口455中。
ASIC驱动器465提供软件逻辑用于与上述硬件接口。它主要负责从ASIC FIFO中读出数据和向ASIC FIFO中写入数据。
图6把图4和图5中的部件组合起来，从而使优先级和数据流更加显然。图6说明，作为一种一般情况，软件逻辑越接近于硬件，则该软件执行时所处优先级越高。
图5显示伴随各子系统的优先级赋予以及任务赋予。这样，该图显示2个BRT任务，一个用于协议处理，特别是用于EC逻辑，第二个任务用于作为BRT事件队列的结果已被调用的所有逻辑。类似地，也可以说，SRT任务是在CD计时器队列中被登录并作为全局事件(大约每25ms一次)的结果被触发的那些回调例程的集合。HRT任务基本上是HRTISR，它响应ASIC 106中断。(下文中将更详细描述)。
图6把图4和图5的部件组合起来，说明一般情况下在数据路径上的软件子系统在HRT和SRT级上操作，其中较接近ASIC的子系统在HRT级运行，而在控制路径上的实体在BRT级操作。
图7显示一个数据泵410A的一部分，作为软芯片数据泵部分410的一部分。(软芯片数据泵部分410包括用于各种通信标准，如V.34、V.32bis、传真标准等的数据泵，加上自动方式处理)。除其他东西外，数据泵410A包括一个控制/数据结构710，它包括一个接口部分711用于与软芯片控制部分440接口。这个接口被设计成基于寄存器的接口，类似于传统调制解调器中所用的接口，但以其他方式扩展了，例如用于与传真有关的数据泵。有限状态机器变量(FSM Vars)部分712保持的数据指出在确定数据泵状态变化是否适当时所考虑的各种变量。DSP变量(DSPVars)部分713含有数据泵算法所用变量。控制部分714包括调制解调器状态714a、发送矢量714b、接收矢量714c、发送DSP矢量714d、以及接收DSP矢量714e。
发送DSP矢量714d和接收DSP矢量714e分别为指向发送和接收DSP任务的指针。发送矢量714b和接收矢量714c分别是指向发送和接收状态逻辑的指针；这一状态逻辑在确定是否修改调制解调器状态714a时考虑调制解调器状态和其他变量。
当ASIC 106产生一个中断时，HRT ISR最终被调用。通常情况下，产生中断和ISR被调用的时刻之间的延迟是小的，但这一时间能变化而且变得很大，如果在收到中断时另一个ISR正在执行的话，从而阻碍HRTISR的执行。
参考图8，HRT在步骤801起始，并进入步骤810。在步骤810，HRT例程从ASIC 106的RX FIFO 118r读出样本。样本数取决于各种情况，如编码解码器的采样速率和ASIC 106的程序中断速率。在一个实施例中将读出90个数据样本。
逻辑进入步骤820，在那里确定是否有更多的波特或符号需要处理。例如，如果使用3x取样，则90个样本对应于30波特。要处理的波特量取决于所涉及的数据泵以及采样速率和波特率。
如果有更多波特要处理，则逻辑进入步骤830，在那里处理发送波特。步骤830涉及访问状态控制逻辑，该状态控制逻辑是由被选定的数据泵410a的数据/控制结构714b中的txvec(发送矢量)714b指向的。被txvec 714b所指向的状态控制逻辑将查看调制解调器状态714a和在控制结构710中的各个变量，并相应地更新调制解调器状态，所有这些都对应于数据泵的特定算法。在更新调制解调器状态之后，于是步骤830处理与下一个要发送的波特相对应的样本(例如3个)。这通过访问控制结构710中的txdspvec(发送DSP矢量)714d所指的软件逻辑来完成。Txdspvec指向与图9中所见相似的逻辑，它对于大多数数据泵410a是有相当代表性的。所调用的各种例程对应于一典型的发送器结构，例如图11的方框图结构。然而，在这种情况中，实现发送器功能的逻辑是在主处理器上执行，而不是在专用DSP上执行。例如，图11中在各部件下面显示的数据类型。是在基于主机的调制解调器334中使用时的情况，而不是在传统的DSP数据泵中使用时的情况。数据类型SC-Dsp DATA和SC_cDsp DATA是一般化了的数据类型。整数是用于整数数值值的一般数据类型。(一般化数据类型可以由针对平台的宏来实现，例如，如果由主处理器102或协处理器(未画出)提供了浮点能力，则可利用浮点能力来实现)。
在处理发送波特之后，在步骤840将样本(例如3个)存入缓存器。然后逻辑进入步骤850。
在步骤850，HRT于是处理一接收波特。这多少类似于处理发送波特。例如，在步骤810中与所有其他样本一起读回的3个数据样本被一次处理，对应于一个接收波特。作为处理的一部分，HRT例程调用由选定数据泵410a的控制结构710中的rxdspvec(接收DSP矢量)714e指向的逻辑。由714e指向的这个逻辑在图10中表示出来，它类似于图9中的情况，对于典型的接收器结构有相当的代表性。再有，与图9中的情况类似，由图10的逻辑例程实现的实际算法也是针对数据泵的，而且是在主处理器102中实现，而不是在专用DSP中实现。在完成数字信号处理操作之后，接收器的状态控制逻辑通过调用rxvec(接收矢量)714c所指向的逻辑而得到更新，rxvec所指向的逻辑查看调制解调器状态和控制结构710中的各变量，并相应地修改状态714a。
在处理接收波特之后，逻辑循环回到步骤820，在那里确定是否还有波特需要处理。如果没有，则逻辑进入步骤860。
在步骤860，在步骤840的若干次重复中存储的数据样本被写入ASIC 106的发送FIFO 118t。
然后逻辑在步骤899结束，但它被下一个ASIC中断再次调用(还是每12-12.5ms一次)。
上面提到的状态控制逻辑714b、c和dsp逻辑714d、e驻留在数据泵410a中。类似地，在确定是否还有更多波特需要处理时所用变量712、713也从控制结构710间接收访问。这样，可以通过访问驻留在数据泵中的各种逻辑，而不是把这些逻辑硬编码(hardcoding)到HRT图像中，从而使HRT例程可以被作成不依赖数据泵的。
向数据泵发送信息和从数据泵提取信息是通过数据泵的410a基于寄存器的接口实现的。这通过软芯片控制子系统440来控制。
该调制解调器的操作概括如下。在启动时，基于主机的调制解调器334被以OS 310使用传统技术登录。中央调度(CD)415被初始化，这如同该调制解调器的其他各部分通过调用每部分的init(初始化)例程来初始化。作为init例程的一部分，每个子系统将发出具有必要的SRT和BRT队列的必要的回调。ASIC 106被初始化，除了其他情况外，它将使ASIC将开始发动对主处理器102的硬件中断，在稳定状态约每12至12.5ms一次。
然后，主控部分使两个BRT级任务启动，以此作为稳定状态操作的初始化。其主任务根据需要传送事件和消息。EC任务在必要时进行操作。可以预见，在某些系统状态，一个EC操作可能实际上占用不只一个BRT时间量。
然后，使用CM 425和一个装置控制块中保持的一组缺省值对调制解调器334进行配置，该装置控制块是伴随这基于主机的调制解调器334的。这包括设置各种调制解调器参数，这些参数通常是在传统调制解调器中使用传统技术设置的。
然后，该系统以基本上由事件驱动和中断驱动的方式进行操作，它的确切表现取决于提供给调制解调器的实际命令和遇到的实际数据流。ACU 430、主控420和协议处理435的控制逻辑与现代调制解调器中所用的逻辑相似，但改进成为如上所述的事件驱动和中断驱动结构。CD 415和软芯片控制440已在前面描述过。在数据泵部分410中的各种数据泵和自动方式逻辑使用DSP算法，类似于典型DSP中所用的算法，但潜在地进行了修改，以用于通用主微处理器102。如前所述，数字信号处理算法是以用于通用化的DSP函数和数据类型的宏来实现的。一个实施例使用为了V.34、C.32bis、V.32、V.22bis和传真的数据泵，但不难扩展到其他，因为有定义得很好的接口。
为了使系统可移植，遵循了某些约定。在实践中尽可能以高级语言例如“C”来实现设计。再有，尽可能避免针对平台的算法；例如，对于数值值，所作假定依赖于大/小endian安排。(有时为了性能而必须用针对平台的算法，但这些算法应收集到针对平台的库中)。在可能的地方，把常数和变量分开，以有助于实现基于ROM/RAM的设计。代码不依赖于对变量的直接访问，代之以假定OS可以使用动态数据空间分配。使用模块设计技术。
与传统的调制解调器不同，在软芯片数据泵部分410中的每个数据泵被设计成在通用微处理器上执行。一般而言，数字信号处理算法可得到的指令集不包括硬件do循环、分数运算、模编址和其他通常以DSP可得到的其他函数。为克服这一点，各种数据泵被设计成其源代码将使用为传统DSP指令造成的宏。更具体地说，创建一组定义的和通用化的DSP数据类型和宏，它们被数据泵代码使用。当编译时，这些将变成主PC 102的通用处理器的指令序列，而不是专用DSP指令和数据类型。每个宏多半是不依赖于平台的。这样对于各种平台，原始源代码将不需改变许多，而宏库将要改变。例如，如果目标处理器提供了浮点能力，则这些宏可能利用这浮点能力。
本发明可以以其他具体形式实现而不离开本发明的精神或基本特点。所描述的实施例在所有方面都只应认为是说明性的而不是限制性的。
权利要求
1.一种以通用处理器运行的多调制方式调制解调器，在一多任务操作系统控制下操作，有一存储器与通用处理器耦合，以及一缓存装置能保持多个以广域链路为目标或从广域链路接收的发送和接收样本，该操作系统包括至少两个执行优先级，用于操作系统的调度决策，该调制解调器包含在处理器可读介质中的通用处理器可执行的第一指令集，响应来自缓存装置的中断，并在最高相对执行级操作，这第一指令集包括使缓存装置向主处理器提供从广域链路收到的接收样本的指令；根据数据泵接收指令使收到的样本受到处理的指令，这数据泵接收指令对应于多调制方式之一；用于接收信息的指令，其接收信息路径是通过操作系统到调制解调器，这些指令还用于根据数据泵发送指令使该信息受到处理，这数据泵发送指令对应于多调制方式之一，这数据泵发送指令提供发送样本；使发送样本提供给缓存装置的指令，可以在该缓存装置的控制下将发送样本从缓存装置发送到广域链路上；在处理器可读介质中的通用处理器可执行的第二指令集，响应以基本上规则的速率发生的全局事件并在相对低于第一指令集执行优先级的一个执行优先级上操作，这第二指令集包括调制解调器控制功能，用于通过操作系统到调制解调器的路径接收命令和用于对其作出响应，所作的响应是根据预先指定的一组调制解调器操作去控制调制解调器。
2.权利要求1的调制解调器，这里第二指令集包括的控制器功能含有控制器指令第一子集，这些指令以调制解调器所用的相对最低执行优先级操作，该第一子集包括控制调度指令，用于维持一个基于计时器的队列和一个基于事件的队列，这里有多个指令例程可被基于计时器的队列和基于事件的队列访问，该控制调度指令包括指令用于确定何时应调用可被基于计时器的队列访问的指令例程，并包括指令用于调用基于事件队列上的例程，这里预先指定的一组调制解调器操作至少有一部分是在控制器功能第一子集中实现的，这一部分包括指令用于将控制器例程引用到基于计时器的队列和事件队列；以及控制器指令的第二子集，这些指令在调制解调器所用的中等执行优先级上操作，这第二指令集包含控制器例程，它们被第一集控制器指令的子集引用到基于计时器的队列，这里，相对最低执行优先级的和中等执行优先级是作为操作系统的一个执行优先级的次级优先级实现的。
3.权利要求1的调制解调器，这里通用处理器可执行的第一指令集包括一个驱动器例程用于响应来自缓存装置的中断，该驱动器例程包括一组指令用于间接访问构成多调制方式之一的数据泵的一组指令，还包括一组指令用于间接访问保持该数据泵状态描述的一组指令，这里该数据泵响应该状态描述。
全文摘要
一个调制解调器的软件实现,专门设计成在一通用主处理器上执行,由一非实时多任务操作系统(OS)控制,如视窗95OS。该软件调制解调器是可伸缩的和可移植的。以这种方式,通信协议(特别是数据泵)可以容易地添加到该系统或从系统中去掉,而且该调制解调器可以被容易地修改以适用于其他类型处理器和操作系统。控制器和数据泵部分作为多个交互作用子系统执行,每一个子系统能执行至少若干优先级之一。一个HRT级例程负责处一个ASIC,它缓存以电话线为目标和从电话线接收的发送和接收样本。一个SRT级任务包括需要时间功能的逻辑,但它不象HRT逻辑那样对时间苛求。BRT例程以事件驱动为基础去执行,用于许多控制器功能。
文档编号H04L27/00GK1251184SQ98803578
公开日2000年4月19日 申请日期1998年2月24日 优先权日1997年3月21日
发明者明宏 申请人:摩托罗拉公司