Mttty多线程串口源码资源-CSDN下载

共2个文件

rar：1个

pdf：1个

5星 · 超过95%的资源需积分: 10 95 浏览量 2011-08-07 13:07:25 上传评论收藏 210KB RAR 举报

《Mttty 多线程串口源码》是一个针对串口通信的编程实例，它利用Windows API直接进行串口的配置与管理，并且在接收和发送数据时采用了多线程技术，使得串口通信更加高效和灵活。理解并掌握这个源码，将对你的串口编程能力有着显著提升。串口编程是计算机硬件接口技术中的重要一环，常用于设备间的通信，如工控设备、打印机、GPS模块等。Windows API提供了丰富的函数接口来操作串口，如CreateFile、SetCommState、ReadFile和WriteFile等。这些API函数可以实现串口的打开、设置参数、读取数据和发送数据等基本功能。在这个源码中，多线程技术的应用解决了串口通信中可能存在的阻塞问题。传统的串口通信通常在一个单独的线程中进行，如果接收或发送数据量大或者速度慢，可能导致应用程序响应变慢。而采用多线程，可以将接收和发送任务分开到不同的线程，这样即使其中一个任务执行时间较长，也不会影响其他操作的及时性，提高了程序的并发处理能力。微软的《微软串口.pdf》文档很可能详细阐述了串口通信的基本概念、API函数的使用方法以及多线程在串口编程中的应用。这份文档通常会包括以下内容： 1. **串口基础**：介绍串口的工作原理，如波特率、数据位、停止位、校验位等基本设置。 2. **Windows API串口操作**：详细解释如何使用CreateFile、SetCommState、SetCommMask、PurgeComm等函数进行串口的初始化、配置和清理。 3. **事件驱动编程**：讲解如何通过WaitCommEvent函数监听串口事件，实现异步通信。 4. **多线程编程**：阐述如何创建和管理线程，以及如何在多线程环境中同步串口操作，避免数据冲突。 5. **错误处理**：提供处理串口通信中可能出现的错误和异常的策略。《微软串口程序.rar》文件则可能包含了源码示例，读者可以通过阅读和分析这些代码，加深对串口编程和多线程技术的理解。学习和实践《Mttty 多线程串口源码》，不仅可以提升你在工控领域的专业技能，还可以帮助你应对各种串口通信的挑战，为你的职业生涯添加重要的砝码。记得，理论结合实践，不断探索和调试，才能真正掌握这项技术。

资源推荐

资源详情

资源评论

收起资源包目录

mttty.rar （2个子文件）

微软串口.pdf 207KB

微软串口程序.rar 75KB

Files and I/0 Technical Articles

Serial Communications in Win32

Allen Denver

Microsoft Windows Developer Support

December 11, 1995

Applies to:

Microsoft® Win32®

Microsoft Windows®

Summary: Learn how serial communications in Microsoft Win32 is significantly different from serial

communications in 16-bit Microsoft Windows. This article assumes a familiarity with the fundamentals

of multiple threading and synchronization in Win32. In addition, a basic understanding of the Win32

heap functions is useful to fully comprehend the memory management methods used by the

Multithreaded TTY (MTTTY) sample included with this article. (35 printed pages)

Download the MTTTY sample (4918.exe)

[ http://download.microsoft.com/download/4/7/2/47291d3a-

b5b5-4447-8182-4b72b505a603/4918.exe ] for this technical article.

Contents

Overview

Introduction

Opening a Port

Reading and Writing

Serial Status

Serial Settings

Conclusion

Bibliography

Overview

Serial communications in Microsoft® Win32® is significantly different from serial communications in

16-bit Microsoft Windows®. Those familiar with 16-bit serial communications functions will have to

relearn many parts of the system to program serial communications properly. This article will help to

accomplish this. Those unfamiliar with serial communications will find this article a helpful foundation

for development efforts.

This article assumes you are familiar with the fundamentals of multiple threading and synchronization

in Win32. In addition, a basic familiarity of the Win32 heap functions is useful to fully comprehend the

memory management methods used by the sample, MTTTY, included with this article.

For more information regarding these functions, consult the Platform SDK documentation, the Microsoft

Win32 SDK Knowledge Base, or the Microsoft Developer Network Library. Application programming

interfaces (APIs) that control user interface features of windows and dialog boxes, though not discussed

here, are useful to know in order to fully comprehend the sample provided with this article. Readers

unfamiliar with general Windows programming practices should learn some of the fundamentals of

general Windows programming before taking on serial communications. In other words, get your feet

wet before diving in head first. (36 printed pages)

Introduction

The focus of this article is on application programming interfaces (APIs) and methods that are

compatible with Microsoft Windows NT and Windows 95; therefore, APIs supported on both platforms

are the only ones discussed. Windows 95 supports the Win32 Telephony API (TAPI) and Windows NT

3.x does not; therefore, this discussion will not include TAPI. TAPI does deserve mention, however, in

that it very nicely implements modem interfacing and call controlling. A production application that

works with modems and makes telephone calls should implement these features using the TAPI

页码，1

24(W)w

2010/7/4http://msdn.microsoft.com/en-us/librar

/ms810467(printer).aspx

interface. This will allow seamless integration with the other TAPI-enabled applications that a user may

have. Furthermore, this article does not discuss some of the configuration functions in Win32, such as

GetCommProperties.

The sample included with this article, MTTTY: Multithreaded TTY (4918.exe), implements many of the

features discussed here. It uses three threads in its implementation: a user interface thread that does

memory management, a writer thread that controls all writing, and a reader/status thread that reads

data and handles status changes on the port. The sample employs a few different data heaps for

memory management. It also makes extensive use of synchronization methods to facilitate

communication between threads.

Opening a Port

The CreateFile function opens a communications port. There are two ways to call CreateFile to open

the communications port: overlapped and nonoverlapped. The following is the proper way to open a

communications resource for overlapped operation:

Removal of the FILE_FLAG_OVERLAPPED flag from the call to CreateFile specifies nonoverlapped

operation. The next section discusses overlapped and nonoverlapped operations.

The Platform SDK documentation states that when opening a communications port, the call to

CreateFile has the following requirements:

fdwShareMode must be zero. Communications ports cannot be shared in the same manner that

files are shared. Applications using TAPI can use the TAPI functions to facilitate sharing resources

between applications. For Win32 applications not using TAPI, handle inheritance or duplication is

necessary to share the communications port. Handle duplication is beyond the scope of this

article; please refer to the Platform SDK documentation for more information.

fdwCreate must specify the OPEN_EXISTING flag.

hTemplateFile parameter must be NULL.

One thing to note about port names is that traditionally they have been COM1, COM2, COM3, or COM4.

The Win32 API does not provide any mechanism for determining what ports exist on a system.

Windows NT and Windows 95 keep track of installed ports differently from one another, so any one

method would not be portable across all Win32 platforms. Some systems even have more ports than

the traditional maximum of four. Hardware vendors and serial-device-driver writers are free to name

the ports anything they like. For this reason, it is best that users have the ability to specify the port

name they want to use. If a port does not exist, an error will occur (ERROR_FILE_NOT_FOUND) after

attempting to open the port, and the user should be notified that the port isn't available.

Reading and Writing

Reading from and writing to communications ports in Win32 is very similar to file input/output (I/O) in

Win32. In fact, the functions that accomplish file I/O are the same functions used for serial I/O. I/O in

Win32 can be done either of two ways: overlapped or nonoverlapped. The Platform SDK documentation

uses the terms asynchronous and synchronous to connote these types of I/O operations. This article,

however, uses the terms overlapped and nonoverlapped.

Nonoverlapped I/O is familiar to most developers because this is the traditional form of I/O, where an

operation is requested and is assumed to be complete when the function returns. In the case of

overlapped I/O, the system may return to the caller immediately even when an operation is not

finished and will signal the caller when the operation completes. The program may use the time

between the I/O request and its completion to perform some "background" work.

Copy Code

HANDLE hComm;

hComm = CreateFile( gszPort,

GENERIC_READ | GENERIC_WRITE,

OPEN_EXISTING,

FILE_FLAG_OVERLAPPED,

0);

if (hComm == INVALID_HANDLE_VALUE)

// error opening port; abort

页码，2

24(W)w

2010/7/4http://msdn.microsoft.com/en-us/librar

/ms810467(printer).aspx

Reading and writing in Win32 is significantly different from reading and writing serial communications

ports in 16-bit Windows. 16-bit Windows only has the ReadComm and WriteComm functions. Win32

reading and writing can involve many more functions and choices. These issues are discussed below.

Nonoverlapped I/O

Nonoverlapped I/O is very straightforward, though it has limitations. An operation takes place while the

calling thread is blocked. Once the operation is complete, the function returns and the thread can

continue its work. This type of I/O is useful for multithreaded applications because while one thread is

blocked on an I/O operation, other threads can still perform work. It is the responsibility of the

application to serialize access to the port correctly. If one thread is blocked waiting for its I/O operation

to complete, all other threads that subsequently call a communications API will be blocked until the

original operation completes. For instance, if one thread were waiting for a ReadFile function to return,

any other thread that issued a WriteFile function would be blocked.

One of the many factors to consider when choosing between nonoverlapped and overlapped operations

is portability. Overlapped operation is not a good choice because most operating systems do not

support it. Most operating systems support some form of multithreading, however, so multithreaded

nonoverlapped I/O may be the best choice for portability reasons.

Overlapped I/O

Overlapped I/O is not as straightforward as nonoverlapped I/O, but allows more flexibility and

efficiency. A port open for overlapped operations allows multiple threads to do I/O operations at the

same time and perform other work while the operations are pending. Furthermore, the behavior of

overlapped operations allows a single thread to issue many different requests and do work in the

background while the operations are pending.

In both single-threaded and multithreaded applications, some synchronization must take place between

issuing requests and processing the results. One thread will have to be blocked until the result of an

operation is available. The advantage is that overlapped I/O allows a thread to do some work between

the time of the request and its completion. If no work can be done, then the only case for overlapped

I/O is that it allows for better user responsiveness.

Overlapped I/O is the type of operation that the MTTTY sample uses. It creates a thread that is

responsible for reading the port's data and reading the port's status. It also performs periodic

background work. The program creates another thread exclusively for writing data out the port.

Note Applications sometimes abuse multithreading systems by creating too many

threads. Although using multiple threads can resolve many difficult problems, creating

excessive threads is not the most efficient use of them in an application. Threads are less

a strain on the system than processes but still require system resources such as CPU

time and memory. An application that creates excessive threads may adversely affect the

performance of the entire system. A better use of threads is to create a different request

queue for each type of job and to have a worker thread issue an I/O request for each

entry in the request queue. This method is used by the MTTTY sample provided with this

article.

An overlapped I/O operation has two parts: the creation of the operation and the detection of its

completion. Creating the operation entails setting up an OVERLAPPED structure, creating a manual-

reset event for synchronization, and calling the appropriate function (ReadFile or WriteFile). The I/O

operation may or may not be completed immediately. It is an error for an application to assume that a

request for an overlapped operation always yields an overlapped operation. If an operation is

completed immediately, an application needs to be ready to continue processing normally. The second

part of an overlapped operation is to detect its completion. Detecting completion of the operation

involves waiting for the event handle, checking the overlapped result, and then handling the data. The

reason that there is more work involved with an overlapped operation is that there are more points of

failure. If a nonoverlapped operation fails, the function just returns an error-return result. If an

overlapped operation fails, it can fail in the creation of the operation or while the operation is pending.

You may also have a time-out of the operation or a time-out waiting for the signal that the operation is

complete.

Reading

The ReadFile function issues a read operation. ReadFileEx also issues a read operation, but since it is

页码，3

24(W)w

2010/7/4http://msdn.microsoft.com/en-us/librar

/ms810467(printer).aspx

not available on Windows 95, it is not discussed in this article. Here is a code snippet that details how

to issue a read request. Notice that the function calls a function to process the data if the ReadFile

returns TRUE. This is the same function called if the operation becomes overlapped. Note the

fWaitingOnRead flag that is defined by the code; it indicates whether or not a read operation is

overlapped. It is used to prevent the creation of a new read operation if one is outstanding.

The second part of the overlapped operation is the detection of its completion. The event handle in the

OVERLAPPED structure is passed to the WaitForSingleObject function, which will wait until the

object is signaled. Once the event is signaled, the operation is complete. This does not mean that it was

completed successfully, just that it was completed. The GetOverlappedResult function reports the

result of the operation. If an error occurred, GetOverlappedResult returns FALSE and GetLastError

returns the error code. If the operation was completed successfully, GetOverlappedResult will return

TRUE.

Note GetOverlappedResult can detect completion of the operation, as well as return

the operation's failure status. GetOverlappedResult returns FALSE and GetLastError

returns ERROR_IO_INCOMPLETE when the operation is not completed. In addition,

GetOverlappedResult can be made to block until the operation completes. This

effectively turns the overlapped operation into a nonoverlapped operation and is

accomplished by passing TRUE as the bWait parameter.

Here is a code snippet that shows one way to detect the completion of an overlapped read operation.

Note that the code calls the same function to process the data that was called when the operation

completed immediately. Also note the use of the fWaitingOnRead flag. Here it controls entry into the

detection code, since it should be called only when an operation is outstanding.

Copy Code

DWORD dwRead;

BOOL fWaitingOnRead = FALSE;

OVERLAPPED osReader = {0};

// Create the overlapped event. Must be closed before exiting

// to avoid a handle leak.

osReader.hEvent = CreateEvent(NULL, TRUE, FALSE, NULL);

if (osReader.hEvent == NULL)

// Error creating overlapped event; abort.

if (!fWaitingOnRead) {

// Issue read operation.

if (!ReadFile(hComm, lpBuf, READ_BUF_SIZE, &dwRead, &osReader)) {

if (GetLastError() != ERROR_IO_PENDING) // read not delayed?

// Error in communications; report it.

else

fWaitingOnRead = TRUE;

}

else {

// read completed immediately

HandleASuccessfulRead(lpBuf, dwRead);

}

Copy Code

#define READ_TIMEOUT 500 // milliseconds

DWORD dwRes;

if (fWaitingOnRead) {

dwRes = WaitForSingleObject(osReader.hEvent, READ_TIMEOUT);

switch(dwRes)

{

// Read completed.

case WAIT_OBJECT_0:

if (!GetOverlappedResult(hComm, &osReader, &dwRead, FALSE))

// Error in communications; report it.

页码，4

24(W)w

2010/7/4http://msdn.microsoft.com/en-us/librar

/ms810467(printer).aspx

Writing

Transmitting data out the communications port is very similar to reading in that it uses a lot of the

same APIs. The code snippet below demonstrates how to issue and wait for a write operation to be

completed.

else

// Read completed successfully.

HandleASuccessfulRead(lpBuf, dwRead);

// Reset flag so that another opertion can be issued.

fWaitingOnRead = FALSE;

break;

case WAIT_TIMEOUT:

// Operation isn't complete yet. fWaitingOnRead flag isn't

// changed since I'll loop back around, and I don't want

// to issue another read until the first one finishes.

// This is a good time to do some background work.

break;

default:

// Error in the WaitForSingleObject; abort.

// This indicates a problem with the OVERLAPPED structure's

// event handle.

break;

}

Copy Code

BOOL WriteABuffer(char * lpBuf, DWORD dwToWrite)

{

OVERLAPPED osWrite = {0};

DWORD dwWritten;

DWORD dwRes;

BOOL fRes;

// Create this write operation's OVERLAPPED structure's hEvent.

osWrite.hEvent = CreateEvent(NULL, TRUE, FALSE, NULL);

if (osWrite.hEvent == NULL)

// error creating overlapped event handle

return FALSE;

// Issue write.

if (!WriteFile(hComm, lpBuf, dwToWrite, &dwWritten, &osWrite)) {

if (GetLastError() != ERROR_IO_PENDING) {

// WriteFile failed, but isn't delayed. Report error and abort.

fRes = FALSE;

}

else

// Write is pending.

dwRes = WaitForSingleObject(osWrite.hEvent, INFINITE);

switch(dwRes)

{

// OVERLAPPED structure's event has been signaled.

case WAIT_OBJECT_0:

if (!GetOverlappedResult(hComm, &osWrite, &dwWritten, FALSE))

fRes = FALSE;

else

// Write operation completed successfully.

fRes = TRUE;

break;

default:

页码，5

24(W)w

2010/7/4http://msdn.microsoft.com/en-us/librar

/ms810467(printer).aspx

size of the buffer

评论收藏

内容反馈

zcube

2013-02-28

里面有个4918.exe文件，运行该文件解压即可得到源代码。我原先以为是执行程序呢！这个资源应该是微软原版的，不过是英文的。如果需要完美翻译版，可以去我空间看。
Trinco

2013-12-03

实例很有参考价值，仔细阅读的话可以了解多线程的编程方式
REDJON

2014-07-12

不错，微软的代码还是很不错的
pbnc2005

2013-04-26

很不错的承袭，微软还是相当强大啊
n174840001

2013-11-13

很好的资料，对于学习串口编程时很好的实例。