仅仅是通过计算缓冲器的存储状态来清除该标志就完成了硬件流控制的操作。由于在此过程中IST与其他部分是同步执行的,所以这个时候如果使用XFlow可能还会需要做一次安全检查。这样接收的流程就结束了。
发送分支： 我们同样来看看TX_BUFFER_INFO结构，看样子似乎该结构维护了一个和TX缓冲类似的缓冲区，但事实上这个缓冲区域是不独立存在的，发送的流程因为可以直接使用所需发送的数据的存储区域来作为发送缓冲，所以这个缓冲没有独立存在的必要。由于使用其它进程的数据区域，所以这里增加了权限控制项的成分，用于突破进程间的访问限制。
typedef struct __TX_BUFFER_INFO {
DWORD Permissions; /* @field Current permissions */
ULONG Read; /* @field Current Read index. */
ULONG Length; /* @field Length of buffer */
PUCHAR TxCharBuffer; /* @field Start of buffer */
CRITICAL_SECTION CS; /* @field Critical section */
} TX_BUFFER_INFO, *PTX_BUFFER_INFO;
下面来看看代码的具体内容。首先是对OpenCnt的检查，也就是设备是否被打开。若当会话已经关闭也就没有必要继续将数据送出了，并同时重置缓冲器的各个标志位。整个流程比较简单，在需要流控制时设置RTS或检查Xflow的情况后将数据送入硬件缓冲器.如果在没有数据需要发送的情况下简单的清除中断标示并发出发送结束事件就可以了。至于SetProcPermissions设置的目的在于获得访问其它线程数据空间的手段。
至于所谓的Modem和Line的情况则全部交给PDD来处理，我们后面再讨论。在这些全部都处理完了以后如果前面处理了接收，则发出接收（有可用的数据用于接收）的消息，让程序开始接收。后面还跟进了一个EvaluateEventFlag 函数，这个函数用于产生标准的Communication Events EV_RXFLAG，而且由于该驱动程序本身支持mult-open模式，所以需要将该事件送发到所有的实例中去。在ist期间有一些互锁、临界区的操作，因为不影响流程，同步化的内容这里我没有提。中断服务的分析大致就是如此，没有涉及到逻辑环节在后面的PDD部分再进行讨论。
COM_Read
COM_Read是获取串口所接收到数据的操作，在前面的IST中没有看到对RX buffer进行修改Read标记的操作，也就是这儿来完成的。该函数有三个参数，第一个参数是从上面的COM_OPEN通过设备管理器交换来的，后两个参数与文件系统的使用方法完全一样，一个是接受缓冲指针，另一个是长度。代码的开始照样是例行公事的参数检查，包括对存取权限，OpenCnt等。之后计算超时时间，如果设定了超时读取动作会在超时后返回，不管是否读到了足够长度的数据。随后就是简单对软件缓冲进行读取的操作了，读取的操作是在RX_CS中完成的。下面要处理器的主要就是几种异常的情形，读取过程中设备被关闭/取消读取和超时。最后在读取的过程中需要处理的就只是流控制的成本了。首先是软件流的情形，如果缓冲的状态由高于分位点至分位点以下就发出XON标记，启动发送端的发送。而硬件流的情形无论是RTS还是DTR与软件流的相类似，同样由一个分为点(50%)来决定发出启动发送端的信号，仅仅是这里使用的具体措施的不同。这些硬件信号的发出都是由PDD来完成的，其中包括HWSetRTS和HWSetDTR(2选一)。至此Read的流程就结束了。
COM_Write
COM_Write是与COM_Read相对应的操作。所传递的参数的形式也是很相似的，仅仅是数据流向的不同。在程序的开始，同样也是参数检查，内容与COM_Read一致。在数据检查完成之后进入临界区(保障多线程下的独占)将送入的目标地址和长度设置为TX buffer，待到数据发送完成事件后调用DoTxData来启动发送。这里启动发送的目的在于获得硬件中断维持发送流程。在这里DoTxData是作为两种状态来执行的，在通过COM_Write的执行的过程中是在device.exe所创建的线程空间内执行的，但由系统中断事件主动启动的过程中属于IST本身的的进程空间，这样在COM_Write中调用DoTxData之前设置的权限代码(由GetCurrentPermissions获得)就可以由TxBufferInfo传递到IST中去使得中断过程也具备了访问缓冲的权限(结合前面说明IST的流程)。当提交中断处理发送后待到pSerialHead->hTransmitEvent被设置或是异常或超时后就结束了发送流程，在这部分的最后。与COM_Read类似需要处理一些异常情况，当然如果使用了硬件流控制还需要在这里清除掉发送请求信号，当这些状态处理完成以后发送EV_TXEMPTY事件通告所有open的句柄发送结束就完成了该部分的流程。
COM_PowerUp/ COM_PowerDown
这两个函数的调用都
|
