简介《Visual C/Turbo C串口通信编程实践第2版》配套源代码包面向学习串口通信编程的VC开发者与嵌入式爱好者对应书中串口通信基础、API编程、MSComm控件、多线程收发等章节可配合教材完成从Turbo C到Visual C的串口实践。压缩包共787个文件约16.57MB主要包含147个h头文件、118个cpp源文件、101个obj目标文件、42个ico图标、40个pdb调试信息、26个exe可执行程序以及丰富的dsp/dsw/plg工程文件、rc资源脚本、txt说明文档等涵盖串口调试助手、通信测试、Socket通信演示等多个完整示例工程每个工程都带有可编译的源码头文件与工程配置适合直接打开、编译运行和对照学习。目前已有362人学习下载。通过此包可深入理解串口通信协议解析、数据收发流程、界面与多线程结合等实现细节也能借鉴其工程组织方式用于二次开发或毕业设计。1. 这本书的源码到底值不值得折腾两代工具链讲透串口底层的最后一份教材很多人以为《Visual C/Turbo C串口通信编程实践第2版》的配套源码是古董最多拿来应付老旧工控设备的维护。我的看法恰好相反这套源码把串口通信拆成两套实现——一套用 Visual C 在 Windows 下走事件驱动另一套用 Turbo C 在 DOS 下直接操作 UART 寄存器。前者让你学会写上位机后者让你看清硬件底层到底发生了什么。对刚从单片机转向 PC 开发的工程师、需要对接老设备的上位机开发者以及想弄懂“串口为什么乱码、为什么丢字节”的人这份源码比大部分新出版教程都值得照着重编一遍。前提是你别指望它下载下来就能编译通过。2. 源码结构拆解Visual C 与 Turbo C 两条技术路线先从哪读拿到源码包第一件事不是找 .exe也不是双击 .dsw 工程文件而是先分辨它内部那两套完全不同的工程组织方式。Visual C 部分通常是一组 MFC 对话框项目默认带着 MSComm ActiveX 控件的封装类Turbo C 部分则是几个散落的 .c 文件靠#include dos.h和寄存器地址完成收发。这两套代码的阅读顺序、编译方式、调试方法完全不同混在一起看只会越看越乱。2.1 两套实现对应两条学习路径Windows 事件驱动与 DOS 寄存器直操作先做一个对比帮你在动手前定方向。书里给的 Visual C 源码走的是“控件消息”路线MSComm 控件封装了串口打开、读写、事件通知你不需要关心硬件寄存器。Turbo C 源码走的是“寄存器中断”路线直接读写 8250/16550 UART 的端口地址状态靠轮询数据到达靠 IRQ4 中断。下表是两条路线的本质差异对比项Visual C 实现Turbo C 实现运行环境Windows 98/2000/XPMFC 对话框程序DOS或 DOSBox 虚拟环境串口访问方式MSComm ActiveX 控件封装或 Win32 APIoutportb/inportb直接操作寄存器数据到达通知OnComm 事件消息RThreshold 触发8259A 中断 自定义 ISR调试手段断点、变量监视、串口助手对发printf 到屏幕或写内存再查看适合场景上位机界面、协议解析、多串口管理理解 UART 底层时序、嵌入式底层移植我的建议是如果你以后要做 Windows 上位机重点啃 Visual C 源码如果你要对接单片机、写底层驱动或者排查硬件电平问题Turbo C 源码才是真正的宝藏。不要指望一份源码覆盖两个方向书把两套代码放一起本身就是让你对照着理解“同一件事在操作系统层面和硬件层面的不同做法”。2.2 拿到源码从哪个文件读起按“初始化→收发→协议解析”三步走常见做法是先列目录找出工程入口文件然后按三层结构读初始化层、收发层、协议层。不要一上来就扑到某个按钮的响应函数里那会陷入界面控件的细节。具体阅读顺序我一般这样安排# 第一步列出所有源码文件分辨工程类型 find . -name *.dsw -o -name *.dsp -o -name *.mak -o -name *.c -o -name *.cpp # 第二步对 VC 工程找对话框头文件里的 MSComm 控件成员 grep -in mscomm *.h # 第三步对 TC 工程找初始化串口函数 grep -in outportb\|inportb\|0x3f8\|setvect *.c三步做完你基本能画出这本书源码的地图VC 部分的重点在OnOnCommMscomm1这类事件处理函数TC 部分的重点在serial_init和中断服务函数。如果 grep 结果里什么都没有先检查是不是源码文件编码损坏再检查是不是这个源码包只收录了书里部分章节的代码并不完整。第 2 版书里的串口调试助手、GPS 解析、MODEM 通信这些示例在不同源码包里文件命名差异很大但不影响上面三层的阅读框架。2.3 收发参数其实只有一组波特率、数据位、校验位怎么对齐Visual C 和 Turbo C 源码的侧重点不同但串口参数最终由硬件寄存器决定所以两套代码里的参数必须保持一致。VC 侧靠 MSComm 的Settings属性字符串完成例如9600,n,8,1TC 侧靠往 Line Control RegisterLCR写除数因子和帧格式位。这是一个新手最容易忽略的点你在 VC 上位机里设为 9600、8、1下位机或另一台设备也要完全一致否则不是乱码就是收不到。参数核对表长这样参数项VC 侧设置位置TC 侧寄存器位常见出错点波特率put_Settings(9600,n,8,1)第一段除数锁存器 Divisor Latch除数算错误差超 2% 就乱码数据位Settings 第三段LCR bit0-1设为 5/6/7 位时校验位配置会变校验位Settings 第二段LCR bit3-4“无校验”也要显式写 n停止位Settings 第四段LCR bit21 还是 2看对端设备要求这一节解决的是“代码没写错但收发不正常”里最大的一类根因两端参数表没对齐。后续第 3、4 章分别给出 TC 和 VC 侧的最小可运行代码时你始终要回到这张表检查参数。3. 把 Visual C 串口 Demo 跑起来控件注册、事件挂接与参数验证3.1 两条路线MSComm 控件与 Win32 API先选一个定方向Visual C 部分最常见的实现是 MSComm 控件因为书里示例、网上流传的类封装几乎都以它为主。它的优点是把串口封装成 ActiveX 控件界面上拖一个图标就可以用事件驱动写起来非常直观缺点是目标机器必须注册mscomm32.ocx系统如果是 64 位还需要放在 SysWOW64 目录下并处理注册表指向这一步每年都能卡住一批人。另一种路线是用 Win32 API 直接写CreateFile 打开串口、SetupComm 初始化、重叠 IO 或事件通知接收数据。这条路不依赖任何第三方控件但代码量多出三四倍而且涉及到 DCB 结构体和超时设置的细节。如果你只是为了验证书里的示例先走 MSComm 路线。它最快能让你看到“串口打开、收到数据、界面显示”的完整链路等你需要把程序部署到别人机器时再考虑把 MSComm 换成 API 版本或者把 OCX 打包进安装程序。不必一开始就两条路都学先跑通一条理解事件模型之后另一条路只是实现方式不同。3.2 最小工程注册 ActiveX 控件、搭对话框、挂 OnComm 事件以 VC6 或 VS2010 创建一个 MFC 对话框工程为基底在资源编辑器里右键工具箱把“Microsoft Communications Control, version 6.0”拖到对话框上这一步会生成一个名为MSComm1的控件变量。如果工具箱里找不到这个控件先手动注册# 以管理员身份运行64 位系统注意路径 regsvr32 C:\Windows\SysWOW64\mscomm32.ocx注册成功后在OnInitDialog里做初始化这是整个 Demo 的核心注释里标了每个参数的实际效果// 对话框初始化函数VC6 下是 BOOL CSerialDlg::OnInitDialog() BOOL CSerialDlg::OnInitDialog() { CDialog::OnInitDialog(); // 选择串口号1 表示 COM12 表示 COM2注意不要超过实际可用串口 m_mscomm.put_CommPort(1); // 设置通信参数波特率 9600、无校验、8 个数据位、1 个停止位 m_mscomm.put_Settings(_T(9600,n,8,1)); // RThreshold1接收缓冲区每收到 1 个字节就产生一次 OnComm 事件 m_mscomm.put_RThreshold(1); // InputMode1二进制方式读取数据避免文本方式把 0x00 当结束符 m_mscomm.put_InputMode(1); // InputLen0每次 Input 操作一次性取走接收缓冲区全部内容 m_mscomm.put_InputLen(0); // 打开串口如果串口被占用这里会抛出异常或返回 FALSE if (!m_mscomm.get_PortOpen()) m_mscomm.put_PortOpen(TRUE); return TRUE; }这段代码里最容易让人翻车的是put_Settings的字符串格式。它严格遵循“波特率,校验位,数据位,停止位”的顺序中间用逗号分隔没有空格。9600,n,8,1是经典写法n 代表 None 无校验如果换9600,e,8,1就是偶校验。RThreshold设成 1 意味着每收到一个字节就触发一次事件这在低速率下性能没问题但 115200 波特率高吞吐时会频繁触发消息实际项目里可以设成 16 或者更大来批量处理。这就是后面要提到的事件批处理优化的起点。接收数据靠 OnComm 事件在对话框里给控件添加事件处理函数后写类似下面的代码// MSComm 控件的 OnComm 事件映射函数 void CSerialDlg::OnOnCommMscomm1() { // 2 表示“接收字符”事件其他值如 1 表示发送完成1001 表示错误 if (m_mscomm.get_CommEvent() ! 2) return; COleVariant v m_mscomm.get_Input(); // 一次性取走接收缓冲区内容 CString s v.bstrVal; // 以字符串形式取出 // 这里做实际业务处理可以按帧头解析、转发到界面或写入文件 m_list.AddString(s); }这里有个容易踩的坑get_Input()返回的是COleVariant直接取bstrVal适合纯文本协议如果下位机发来的是二进制帧里面可能包含 0x00CString 会在这里被截断。二进制场景要用COleSafeArray把数据转成字节数组再逐字节处理第 5 章的避坑清单里会再展开。3.3 参数怎么设与验证Settings 字符串、RThreshold、InputMode 逐个讲透验证这套 Demo 是否正常工作不需要真实设备直接把开发机的 COM1 和 COM2 用一根交叉串口线连起来或者用 USB 转串口模块对接另一个串口一台机器上跑两个程序互发即可。更简单的做法是用串口助手类工具作为对端手动发送字符串看你的 Demo 能否在列表里显示出来。打开串口前到设备管理器里确认串口号是 COM1 还是 COM5。USB 转串口经常生成 COM5 以上的编号如果把put_CommPort(1)硬写成 COM1实际打不开设备MFC 会弹出一个“无法打开串口”的消息框。别急着改代码逻辑先回头检查端口号。这个看起来小的问题占了串口调试里至少三分之一的“为什么打不开”。参数层面的经验是调试阶段RThreshold1最直观能逐字节看到数据到达正式模块里改成 16 或InputLen配合消息批处理否则每字节一条消息UI 刷新会明显卡顿。4. Turbo C 源码落地在 DOSBox 里重编译寄存器级收发例程4.1 Turbo C 源码的价值绕过 API 直接看 UART 寄存器如果说 Visual C 源码是“用起来”Turbo C 源码就是“拆开看”。这部分实现里没有 CreateFile、没有 DCB只有三个端口地址0x3F8 是 COM1 的数据端口0x3FB 是线路控制寄存器LCR0x3FD 是线路状态寄存器LSR0x3F9 是中断使能寄存器IER。你在 Windows 里调 API 时其实底层也是操作这一组寄存器只是系统帮你包了一层驱动。对于想搞懂“波特率为什么必须是整除关系”“为什么 4800 会乱码而 9600 正常”这些问题亲自算一次除数比看十遍 API 文档都管用。4.2 在 DOSBox 里搭一个可编译环境头文件路径与内存模型设置Turbo C 2.0 的源码拿到现代 Windows 上直接编译基本不可能因为dos.h、conio.h这些头文件依赖 DOS 环境而且中断向量安装要用实模式。常见做法是装 DOSBox把 Turbo C 2.0 挂载到一个虚拟 C 盘里然后在 DOS 环境下编译。配置要点有三个配置项设置方式出错表现内存模型菜单 Options → Compiler → Model 选 Large中断函数里访问远数组导致数据错乱Include 路径Options → Directories → Include找不到 conio.h/dos.h编译报无法打开头文件输出模式菜单 Options → Linker 选 Standard DOS生成 .exe 在 DOSBox 里运行时指令集不匹配内存模型是这里最像黑匣子的一个选项。Turbo C 默认是 Tiny 模型代码、数据、栈全都挤在同一个 64KB 段里串口中断服务程序一旦访问一个数组指针可能落到错误段。选 Large 模型之后数据和代码分段管理中断函数内部访问全局缓冲区才可靠。这个设置错误的典型现象是程序在 DOSBox 里能启动但一收到串口数据就死机或屏幕乱跳。4.3 最小收发例程查询式发送与中断接收初始化串口的核心是写除数寄存器。UART 的时钟频率通常是 1.8432 MHz波特率 115200 / 除数所以 9600 波特率对应的除数就是 12。因为除数寄存器与数据寄存器共用地址所以要先在 LCR 里把高位地址锁存位设为 1写完除数后再改回 0后续代码才能正常访问数据口。#include dos.h #include conio.h #define COM1 0x3F8 /* COM1 的基地址所有寄存器都以它为偏移 */ /* 初始化 COM19600 波特率8 数据位无校验1 停止位 */ void serial_init(void) { outportb(COM1 3, 0x80); /* LCR bit71进入“写除数”模式 */ outportb(COM1 0, 0x0C); /* 除数低字节115200/960012 */ outportb(COM1 1, 0x00); /* 除数高字节12 256 所以为 0 */ outportb(COM1 3, 0x03); /* LCR0x038N1同时退出除数模式 */ outportb(COM1 1, 0x01); /* IER允许“接收数据可用”中断 */ outportb(COM1 2, 0x07); /* FCR使能 FIFO清空收发缓冲触发阈值为 1 字节 */ }发送一个字节是典型的查询式操作。每次写数据之前先读 LSR 状态寄存器检查发送保持寄存器是否为空不为空就一直等着。这个while空转在单任务 DOS 环境下没问题但如果拿到 Windows 上这么做会占满一个 CPU 核心。书里源码用这种方式教学没问题应用到现代系统上就要换事件驱动或者线程 超时。/* 发送一个字节查询式等待发送保持寄存器为空 */ void serial_putc(unsigned char c) { while ((inportb(COM1 5) 0x20) 0) ; /* LSR bit51 表示发送保持寄存器空 */ outportb(COM1 0, c); /* 把数据写入发送保持寄存器 */ }接收端如果也用查询式主循环要一直循环读 LSR这在波特率高于 38400 时很容易丢字节——你还没读到下一个字节已经把寄存器覆盖了。所以书中接收侧通常给中断方式留了口子serial_init里已经使能了接收中断接下来要写一个中断服务函数配合setvect(0x0C, isr)注册到 IRQ4 上。第 6 章会给一份可直接编译的完整版环形缓冲实现这里先记住一个结论查询式适合简单的调试程序实战接收必须中断 缓冲区。5. 串口源码复现的五个常见坑从控件丢失到丢字节5.1 现象一运行就弹 ActiveX 创建失败窗口根本起不来原因MSComm 控件mscomm32.ocx没有注册到目标系统。源代码里写了#import或工程里引用了 OCX但系统注册表里没有对应条目MFC 在创建控件时会直接抛异常。有些机器上 OCX 文件存在但注册信息指向了 32 位注册表视图64 位程序读了另一个分支也会出现同样症状。 解决以管理员身份执行regsvr32 C:\Windows\SysWOW64\mscomm32.ocx64 位系统或regsvr32 mscomm32.ocx32 位系统。注册后重启程序。如果项目要发给别人使用把注册命令写进安装脚本或批处理别指望用户手动操作。5.2 现象串口能打开但两个程序互发数据全都收不到原因大部分情况下不是代码问题是物理链路或流控设置问题。两个串口直接相连必须一端的 TX 接另一端的 RX地线 GND 要相连交叉线做成了直通线收发自然全断。另一类原因是握手信号代码里没打开 RTS/CTS 流控但设备端要求 DSR/DTR 信号就绪否则不回数据。 解决先用一根杜邦线把同一块板子的 TX 和 RX 短接做自发自收如果自发自收正常说明代码没问题去检查连线和对端设备配置。在put_OutBufferSize、put_Handshake属性上把流控设为0无握手排除串口助手工具把流控选项勾上了的干扰。5.3 现象标准波特率下乱码换一个低速率反而正常原因波特率除数不是所有数值都能整除误差超过一定百分比就对不上时序。比如某些开发板外部晶振是 14.7456 MHz 或 22.1184 MHz常规公式算出来的除数和 1.8432 MHz 基准差别很大115200 能对上9600 反而不准。这个在书籍源码里通常不会提示因为源码默认使用标准 IBM PC 串口。 解决对目标板卡先查晶振频率手动计算实际波特率误差。误差公式是实际波特率 115200 / 除数再把(理论值 - 实际值) / 理论值换算成百分比超过 2% 就要换相邻的可整除波特率或者换非标准除数手动设。5.4 现象Turbo C 源码在 Windows 命令行下编译报一堆找不到头文件原因TC 源码依赖 DOS 时代头文件dos.h、conio.h、bios.h这些在 Windows 原生工具链里不存在。更隐蔽的是即使你用了某个模拟兼容环境中断函数里如果没有把函数声明为interrupt编译器生成的函数进入退出代码不会保存全部寄存器串口数据一到现场直接崩掉。 解决放弃 Windows 原生编译使用 DOSBox Turbo C 2.0 组合。编译前确认内存模型是 Large中断服务函数声明为void interrupt far serial_isr(void)。这一对条件同时满足TC 源码才能稳定复现。5.5 现象长帧数据收发丢字节收到的内容被截断原因接收侧缓冲不够或者每次触发只读一个字节。MSComm 的get_Input()如果InputLen设成 1每次只取一个字节而高波特率下字节会持续涌入消息处理速度跟不上。Turbo C 侧如果没有用 FIFO 或中断处理不及时硬件接收寄存器被新字节覆盖丢字节是必然。 解决MSComm 侧把InputLen设 0一次取空所有数据Turbo C 侧启用 FIFO 并给中断服务函数加环形接收缓冲。环形缓冲在第 6 章给出可直接抄走的实现这是解决丢字节的最终方案。6. 给书里代码加一个环形接收缓冲再跑一回自发自收的环路测试6.1 环形接收缓冲实现解决高波特率丢字节的通用方案Turbo C 源码里最常见的接收写法是主循环查询 LSR然后读一个字节处理一个。这在 115200 波特率下大概率翻车主循环只要被显示、延时、键盘处理打断后续字节就丢了。我习惯的做法是给接收侧加一层环形缓冲中断服务函数只管把字节压进队列主循环按自己的节奏读队列。这样便把“硬件到达”和“业务处理”解耦。#define RX_BUFFER_SIZE 256 /* 环形缓冲读写指针volatile 防止编译器优化掉对中断现场可见的变量 */ volatile unsigned char rx_buf[RX_BUFFER_SIZE]; volatile unsigned int rx_head 0; /* 写入位置中断里更新 */ volatile unsigned int rx_tail 0; /* 读取位置主循环里更新 */ /* 中断服务函数只负责把字节丢进环形缓冲 */ void interrupt far serial_isr(void) { unsigned char c; /* 判断是不是“接收数据就绪”防止中断误触发 */ if (inportb(COM1 5) 0x01) { c inportb(COM1 0); /* 读走数据同时自动清除中断标志 */ /* 队列满时覆盖最旧的数据简单可靠代价是丢最老不丢最新 */ rx_buf[rx_head] c; rx_head (rx_head 1) % RX_BUFFER_SIZE; } /* 向 8259A 发 EOI否则后续中断全被屏蔽 */ outportb(0x20, 0x20); } /* 主循环读取接口读到返回 1无数据返回 0 */ int serial_read(unsigned char *out) { if (rx_head rx_tail) return 0; *out rx_buf[rx_tail]; rx_tail (rx_tail 1) % RX_BUFFER_SIZE; return 1; }配合setvect(0x0C, serial_isr)注册后主循环里调用serial_read就不会再丢字节。缓冲区大小按一个通信帧长度估算比如你的协议最长一帧 128 字节缓冲区设 256 就留了一倍余量。如果业务里处理一帧数据耗时较长比如要写数据库缓冲区还要按“处理时间内可能到达的最大字节数”重新算。这个思路同样适用于 Visual C 侧把 MSComm 的RThreshold调大靠事件批量读取再压入自己的队列而不是每字节刷新一次界面。6.2 自发自收验证短接 TXD 与 RXD确认不丢字节环形缓冲写完必须验证。最省事的做法是把开发板或 USB 转串口的 TXD 与 RXD 用杜邦线短接程序里不断发送一串固定数据同时调用serial_read接收比对收到的内容是否与发送一致。注意短接只适合测试真实设备对接时不要这么干会形成环回干扰正常通信。# DOS 或 Windows 的命令行下直接编译以 Turbo C 为例 tcc -ml -c serial.c tcc -ml serial.obj -o serial.exe-ml就是前面强调的 Large 内存模型。如果自发自收测试通过说明初始化、发送、接收中断、环形缓冲整条链路正常如果收到的字节数量对但内容错位多半是波特率误差如果数量不足多半是中断没触发或 FIFO 没使能。这套验证方法我从调书里源码用到现在无论是 DOS 下的旧例程还是 Windows 上的新项目短接测试始终是串口调试的第一步也是最省时间的“后悔药”。希望帮到你。本文还有配套的精品资源点击获取
