把一块CH552插上电脑，Windows弹出“叮咚”一声，接着设备管理器里出现“HID键盘设备”，这个瞬间成就感是实打实的。沁恒CH552是一颗带USB控制器的8位单片机，和很多人直觉相反，做HID键盘模拟器这件事，并不需要ARM Cortex-M，也不需要外挂USB协议栈芯片，一颗几块钱的51内核单片机就能搞定。这篇文章记录我从选型、硬件、USB描述符、源码编写到实机联调，完整搭出一只USB HID键盘模拟器的全过程，源码部分可以直接拿去改。适合正在做低成本USB外设原型验证的人，也适合第一次接触USB HID、想搞懂枚举和报告机制的嵌入式爱好者。
1. 为什么是CH552：这块8位单片机做USB HID的真实边界
1.1 “USB单片机的低成本选项”是怎么来的
CH552是沁恒（WCH）推出的增强型E8051内核单片机，官方定位就是“带USB的低成本MCU”。它内部集成了USB全速/低速控制器，这意味着芯片本身就具备收发USB数据包的能力，不需要外部再接CH340这类转接芯片，也不需要在外围专门挂一颗USB控制器芯片。芯片自己就能枚举成键盘、鼠标、游戏手柄这类HID设备。
这个能力放在Cortex-M平台上并不稀奇，但关键在于成本和集成度。CH552单芯片价格长期在几块钱的量级，封装又小，SOP16、TSSOP20这类封装在洞洞板上也能手工焊。对于做一个功能相对单一的USB小尾巴、宏键盘、快捷键板来说，这种“一颗芯片解决全部问题”的体验非常舒服。官方还提供了CH552EVT开发包，里面直接有HID键盘、HID鼠标、自定义HID等工程模板。你要做的不是从零写USB协议栈，而是在现成的工程里改描述符和业务逻辑。
1.2 和STM32、ATmega32U4、RP2040放一起比
很多人做USB HID设备时，第一反应是STM32或者Arduino系列，我也在这条路上纠结过。把几个常见方案放在一起看，优劣势非常明显：
| 方案 | 单价量级 | USB外设 | 上手难度 | 适合场景 |
|---|---|---|---|---|
| CH552 | 几元 | 内置USB Device控制器 | 低，官方EVT有现成HID模板 | 低成本HID小外设、宏键盘、USB小产品 |
| STM32F103 | 十几到几十元 | 内置USB Device，SDK较复杂 | 中高，需要配置CubeMX和中间件 | 复合HID、需要大量计算和存储的场景 |
| ATmega32U4 | 中高，且货源不如国产稳定 | 内置USB，Arduino生态成熟 | 低，但板级成本高 | 开源键盘/客制化键盘，玩家生态强 |
| RP2040 | 较高，开发板体积大 | 内置USB，支持PIO | 低，MicroPython/D2XX | 教育、原型、高算力需求场景 |
我的结论很直接：如果项目目标是做一个“插上就被电脑认成标准键盘、按键数量不多、逻辑不复杂”的模拟器，CH552是路径最短的那个。反过来，如果你需要同时做USB Host去读U盘，或者需要大量缓存做复合设备，CH552的RAM和算力会很快撞墙，这时候老老实实上Cortex-M更省事。
1.3 什么情况别选CH552
CH552不是万能的。它本质是8位E8051内核，主频不高，片上SRAM也比不了ARM平台。HID键盘这种“事件驱动型”负载很轻松，但如果你想在设备端做复杂的加密、音频流、大缓存采样，这些任务会把8位机累垮。另外，如果产品需要同时模拟键盘和鼠标，也就是复合HID设备，CH552也能做，但描述符和中断处理会复杂一截，代码空间也更紧张。
还有一点要注意：CH552的USB设备控制器做HID很顺手，但它的USB Host能力相对受限。如果项目要读U盘、外接USB键盘，我建议直接换CH554或者用STM32。选型这件事，选对边界比选高主频重要得多。
2. 电脑怎么认出这是一把键盘：USB枚举与描述符配合
2.1 从插进USB口到“叮咚”一声，中间发生了什么
USB键盘模拟器的工作核心不是“发送按键”，而是先让电脑把你识别成一把键盘。这个识别过程叫枚举。可以把它理解成一次双向的自我介绍：主机会在设备插入后对设备发出若干标准请求，设备必须按顺序回答自己的身份信息和能力。
整个流程大致是：
- 设备插入，主机检测到USB D+/D-线上电平变化，识别到有新设备。
- 主机对地址0发送复位信号，然后发送GET_DESCRIPTOR请求，要求设备返回“设备描述符”，里面包含VID、PID、USB版本等。
- 主机再次发送GET_DESCRIPTOR请求，这次要“配置描述符”，里面包含接口数量、端点数量、供电方式等。
- 如果是HID设备，主机还会请求HID报告描述符，用来说明这个设备的按键数据格式。
- 主机分配一个地址，设备后来都用这个新地址通信。
- 主机发送SET_CONFIGURATION，设备进入工作状态。
- 之后主机会周期性轮询中断端点，读取键盘上报的按键数据。
在这个过程里，CH552芯片负责物理层的收发，你的固件负责正确响应每一次请求。这也是为什么描述符数组写错一个字节、长度对不上，可能出现“设备管理器显示未知设备”或者枚举到一半失败。
2.2 HID报告描述符逐字节拆解
很多人第一次打开HID报告描述符会觉得像天书，其实它的逻辑是“告诉主机：我的报告有几个字节，每个bit代表什么”。标准键盘的报告描述符通常长这样：
// HID报告描述符: 标准键盘（Boot Keyboard） code UINT8 HIDRepDesc[] = { 0x05, 0x01, // Usage Page (Generic Desktop) 0x09, 0x06, // Usage (Keyboard) 0xA1, 0x01, // Collection (Application) 0x05, 0x07, // Usage Page (Key Codes) 0x19, 0xE0, // Usage Minimum (224) 0x29, 0xE7, // Usage Maximum (231) 0x15, 0x00, // Logical Minimum (0) 0x25, 0x01, // Logical Maximum (1) 0x75, 0x01, // Report Size (1) 0x95, 0x08, // Report Count (8) 0x81, 0x02, // Input (Data, Variable, Absolute) 0x95, 0x01, // Report Count (1) 0x75, 0x08, // Report Size (8) 0x81, 0x01, // Input (Constant) 0x95, 0x05, // Report Count (5) 0x75, 0x01, // Report Size (1) 0x05, 0x08, // Usage Page (LEDs) 0x19, 0x01, // Usage Minimum (1) 0x29, 0x05, // Usage Maximum (5) 0x91, 0x02, // Output (Data, Variable, Absolute) 0x95, 0x01, // Report Count (1) 0x75, 0x03, // Report Size (3) 0x91, 0x01, // Output (Constant) 0x95, 0x06, // Report Count (6) 0x75, 0x08, // Report Size (8) 0x15, 0x00, // Logical Minimum (0) 0x25, 0x65, // Logical Maximum (101) 0x05, 0x07, // Usage Page (Key Codes) 0x19, 0x00, // Usage Minimum (0) 0x29, 0x65, // Usage Maximum (101) 0x81, 0x00, // Input (Data, Array) 0xC0 // End Collection };这段描述符定义了一个经典8字节报告：
- 第0字节：修饰键，8个bit分别表示Ctrl、Shift、Alt、GUI（Windows键）等是否按下。
- 第1字节：保留，固定为0。
- 第2到第7字节：最多同时6个普通按键的键值。
所以键盘上报数据包长度是8字节，主机拿到后会根据这份描述符解析。如果你改动了报告格式，比如加多媒体键的Consumer页，就必须同步修改描述符，否则主机无法正确解析数据。
2.3 Boot协议和通用HID协议的区别
描述符里有一个细节很重要：HID接口描述符中的bInterfaceSubClass如果设为1，表示支持Boot Protocol。Boot Keyboard是BIOS环境下也能直接用的协议，报告格式固定为8字节，报告描述符即使主机暂时读不到，也能按固定格式解析。
对我们来说，把这个字段设成Boot Keyboard有两个好处：一是兼容性好，二是很多主机在早期启动阶段也能识别。缺点是报告格式被限制成标准键盘结构，想做多媒体复合设备就得另加接口。实际项目中，大多数宏键盘产品仍然采用Boot Keyboard作为基础，额外的多媒体功能通过第二个接口实现。
3. 硬件准备：最小系统、USB引脚的确认与供电设计
3.1 元件清单和最小连线
我做这块板子的时候，元件非常少，核心就这几样：
| 元件 | 规格/说明 | 数量 |
|---|---|---|
| CH552 | TSSOP20/SOP16均可 | 1 |
| LDO稳压 | ME6211或XC6206，3.3V输出 | 1 |
| 电容 | 10uF钽电容或陶瓷电容，用于电源滤波 | 1 |
| 电容 | 100nF，靠近芯片VCC引脚 | 1 |
| USB座 | Type-C或Micro USB或直接引线 | 1 |
| 按键 | 轻触开关，用作键盘按键 | 若干 |
| 电阻 | 10k上拉，复位脚用 | 1 |
| 电阻 | 22Ω，串在D+/D-上，可选 | 2 |
最小连线的思路是：USB口的VBUS 5V进LDO，LDO输出3.3V给CH552的VCC；USB D+接到CH552的P3.0，USB D-接到CH552的P3.1；GND全部连通。
这里最需要确认的是USB引脚定义。CH552的D+和D-与P3.0、P3.1是复用关系，具体哪个脚对应D+、哪个对应D-，一定要看官方数据手册的引脚图。我第一次焊接的时候想当然按印象接，结果插上电脑毫无反应，后来一查手册才发现D+和D-接反了。这个坑非常隐蔽，因为USB线没有“正反”一说，但芯片引脚有明确区分。
3.2 不需要外部晶振，但电源和D+/D-不能大意
CH552内置了振荡器和PLL，USB时钟可以直接用内部PLL生成，所以大部分情况下不需要外挂晶振。这也是它适合做小体积USB设备的优势之一。不过省掉晶振的前提是电源质量要过关，USB 5V经过LDO后，3.3V的纹波和电压稳定度会直接影响USB通信稳定性。VCC引脚附近必须放100nF和10uF电容，位置尽量靠近芯片，别图省事。
另外，CH552内部已经集成了USB上拉电阻，也就是全速设备D+上那个1.5k电阻不需要你外接。有些第一次画USB设备板的人习惯按传统电路在D+上多加一个上拉电阻，结果导致信号电平被拉得过低，设备反而不被识别。画板前确认一下：CH552不需要外加上拉，D+/D-上可以各串一个22Ω电阻做信号限流和ESD防护，但不要再加对VCC的上拉。
3.3 下载模式怎么进：BOOT脚与复位时序
CH552出厂自带ISP引导程序，这意味着第一次使用不需要专门的烧录器，用USB线或者串口就能下载固件。USB下载的进入条件一般是：把BOOT选择脚（通常是P3.6相关）置为指定电平，然后复位或重新上电，芯片就会停留在ISP模式。在开发板上通常做成了一个按键，丝印写着DOWNLOAD或者BOOT。
最实用的操作方法是：先按住下载键不放，再插USB线，或者按一下复位键，电脑侧会识别出一个“USB ISP”设备，这时候用WCHISPTool软件就能烧录。如果设备管理器没有任何反应，先检查BOOT电平是否满足手册要求，再确认USB线是否带数据功能，很多“无法识别设备”其实是充电线导致的。
4. 开发环境与烧录链路：从官方EVT到WCHISPTool
4.1 为什么要基于官方EVT工程改
我强烈建议不要自己新建空白工程写USB驱动，而是去沁恒官网下载CH552EVT开发包，解压后直接复制里面的HID键盘例程来改。原因很简单：CH552的USB寄存器配置涉及大量位标志和时序细节，官方工程已经把这些封装成了可用的状态机，直接在例程基础上改描述符和业务逻辑，效率最高，出错面也最小。
EVT包里通常能看到这些目录：GPIO、UART、TIMER、ADC、USB等。USB目录下一般有HIDKeyboard、CustomHID这类例程。先别急着大改，做一步验证就够：打开工程，重新编译，烧录到板子里，确认电脑能识别出键盘。这一步通了，说明硬件、烧录链路、基础固件都没问题，之后再改代码，心里就有底。
4.2 Keil C51和SDCC的取舍
编译CH552固件主要用Keil C51或SDCC。Keil C51的生态很成熟，官方EVT工程默认也是Keil格式，装了WCH的芯片支持包后，工程里可以直接选CH552型号，编译下载一条龙。SDCC是开源编译器，如果你习惯命令行和Makefile，SDCC也能支持CH552，但工程配置需要自己搭。
一个实用经验：如果对Keil不熟，也别硬啃。直接下载WCH提供的IDE版本，打开例程，按F7编译，默认配置基本不用动。编译生成的HEX文件路径一般在工程输出目录里，之后用WCHISPTool选择这个HEX就能烧录。真正要改的东西是描述符和主循环逻辑，不是编译器。
4.3 USB ISP与串口ISP两种烧录方式的切换逻辑
WCHISPTool支持USB和串口两种ISP方式。USB方式最方便：设备进入ISP模式后直接通过USB线下载，不需要额外接线。串口方式适合外壳封闭后不方便按键进ISP的情况，用一颗CH340串口模块接到UART引脚，软件选择串口ISP，通过复位和特定时序进入下载。
我的建议是开发阶段多用USB ISP，因为不用额外接串口线。唯一要注意的是：USB ISP模式下载完成后，芯片会退出ISP并运行用户程序，如果用户程序里没有再次进入ISP的逻辑，下次下载需要重新按键进ISP。我把这个“一键进入ISP”的逻辑做成一个简单的按键检测：上电时如果检测到某个引脚被拉低，就直接跳进软件复位进入ISP，调试会省很多事。
5. 源码拆解：描述符数组、USB中断和主循环的三块拼图
5.1 设备描述符、配置描述符、HID报告描述符
源码里最核心的是三类描述符数组。设备描述符告诉主机“你是谁”，配置描述符告诉主机“你有几个接口、几个端点”，报告描述符告诉主机“每次报告的数据长什么样”。它们组合起来，就是设备的完整身份证。
下面是我实际使用并精简后的示例，寄存器名和宏名以你下载的SDK头文件为准：
// 设备描述符 code const UINT8 DevDesc[] = { 0x12, // bLength: 18字节 0x01, // bDescriptorType: Device 0x00, 0x02, // bcdUSB: 0x0200 0x00, // bDeviceClass: 由接口决定 0x00, // bDeviceSubClass 0x00, // bDeviceProtocol 0x08, // bMaxPacketSize0: EP0最大包长8字节 0x09, 0x12, // idVendor: 0x1209（开源项目常用VID） 0x01, 0xC0, // idProduct: 自定义 0x00, 0x01, // bcdDevice: 0x0100 0x01, // iManufacturer: 字符串索引，未提供则填0 0x02, // iProduct 0x00, // iSerialNumber 0x01 // bNumConfigurations: 1个配置 }; // 配置描述符 + 接口描述符 + HID描述符 + 端点描述符 code const UINT8 CfgDesc[] = { 0x09, 0x02, 0x22, 0x00, 0x01, 0x01, 0x00, 0x80, 0x32, // 配置描述符，9字节 0x09, 0x04, 0x00, 0x00, 0x01, 0x03, 0x01, 0x01, 0x00, // 接口描述符，HID Boot Keyboard 0x09, 0x21, 0x00, 0x01, 0x00, 0x01, 0x22, 0x41, 0x00, // HID描述符，报告描述符长度0x41 0x07, 0x05, 0x81, 0x03, 0x08, 0x00, 0x0A // 端点描述符，EP1 IN，中断，8字节，10ms轮询 };注意配置描述符里wTotalLength的值是0x0022，也就是34字节，刚好覆盖后面三段描述符的总和。这个长度写错是枚举失败的常见原因之一。HID报告描述符数组用前面那一份标准Boot Keyboard描述符，长度是0x41。
5.2 USB中断服务：枚举请求和端点完成事件
CH552的USB控制器通过中断通知MCU处理事件。中断里要做的事情概括起来就是：判断当前发生的是什么事件，如果是枚举相关的SETUP请求，就响应主机；如果是IN端点发送完成，就清掉“忙”标志，允许主循环发下一包。
一个精简的中断服务流程如下：
void USB_ISR(void) interrupt INT_USB // 中断号以SDK工程配置为准 { UINT8 is; is = USB_INT_FG; // 读取中断标志 if (is & UIF_BUS_RST) { // 总线复位，初始化端点和状态，等SETUP USB_DEV_AD = 0x00; UEP1_CTRL = bUEP_AUTO_TOG | UEP_T_RES_NAK; } if (is & UIF_SETUP) { // 收到SETUP包，解析请求，返回设备/配置/报告描述符 // 或者处理 SET_ADDRESS、SET_CONFIGURATION // 这里会判断 bRequest 和 wValue，把相应描述符发到EP0 } if (is & UIF_EP1_IN) { // EP1 IN传输完成，说明上一包8字节按键数据已经发给主机 usbBusy = 0; } USB_INT_FG = is; // 清标志 }实际官方例程会把SETUP解析单独拆成一个函数，处理GET_DESCRIPTOR、SET_ADDRESS、SET_CONFIGURATION等标准请求。你需要改的地方通常很少：只改描述符数组和报告发送逻辑，中断状态机基本可以保持原样。
5.3 主循环：按键扫描、消抖、组包与上报时机
USB中断负责“枚举成功”和“发送完成”，主循环则负责按键检测和组包上报。键盘是状态上报设备，不是流式设备，所以我只在按键状态发生变化时发送一包数据。按下时发包含按键码的8字节报告，松开时发全零报告，主机收到全零报告就知道按键已经释放。
按键检测部分我用了最简单的轮询加消抖：
__bit KeySta; // 当前有效按键状态 UINT8 KeyCode; // 当前按键编码 UINT8 KeyScan(void) { // 假设按键接在P1.0，低电平有效 if ((P1 & 0x01) == 0) { delay_ms(5); // 简单消抖 if ((P1 & 0x01) == 0) { return 0x04; // 返回按键编码，0x04是USB键码A } } return 0x00; // 无按键或已释放 } void SendKeyReport(UINT8 mod, UINT8 key) { while (usbBusy); // 等待上一包发送完成 EpBuf[0] = mod; // 修饰键：Ctrl/Shift/Alt/GUI EpBuf[1] = 0x00; // 保留字节 EpBuf[2] = key; // 第一个按键编码 EpBuf[3] = EpBuf[4] = EpBuf[5] = 0; EpBuf[6] = EpBuf[7] = 0; usbBusy = 1; // 触发EP1 IN发送，具体寄存器位名以SDK为准 UEP1_CTRL |= MASK_UEP1_T_RES; }主循环里只需要做一件事：反复扫描按键并判断状态变化，需要发送时调用SendKeyReport。千万不要在按键没变化的时候反复发送相同报告，这不仅浪费总线时间，还可能引发连接不稳。需要注意的是，因为USB主机驱动自己会处理长按重复，所以按住按键时不重复发也不会导致“打不出字”。
6. 实机联调：枚举失败、按键无效和丢键的排查链路
6.1 插上没反应：按照这个顺序去查
我做第一版键盘模拟器的时候，插上USB后设备管理器纹丝不动。当时没有好思路，只能瞎试，后来总结出一个固定排查顺序，效率和成功率都高很多：
- 先确认USB线是数据线。很多手机充电线只有电源没有数据，插上去芯片供电正常但枚举永远无法开始。换一根已知能传数据的线，排除这个最闹心的问题。
- 测量VCC对GND电压，确认稳定在3.3V附近。电压偏高偏低都会让芯片工作异常。
- 确认D+/D-没有接反。对照数据手册引脚图，用万用表蜂鸣档从USB座一直通到芯片引脚。
- 确认BOOT脚状态没有影响正常运行。如果芯片一直停在ISP模式，电脑只会识别出ISP设备而不是HID设备，看起来就像“没反应”。
- 最后才怀疑代码。把官方HID例程原封不动烧录一遍，如果官方例程能被识别，说明你的代码里一定哪里改出了问题，这时再回头检查描述符和状态机。
6.2 枚举成功但按了没反应：报告格式和收发时机
设备管理器里已经显示“HID键盘设备”，但按按键没有任何输出，这种问题比“不识别”更隐蔽。最常见原因是报告描述符定义的长度与实际发送长度不一致。比如描述符说报告是8字节，但主循环只填了前几字节，或者端点发送长度配置成了其他值，主机会把不完整报告丢弃。
另一个常见问题是发送时机。USB键盘的中断IN端点有固定的轮询间隔，如果主循环在上一次传输还没完成时又写缓冲区，Windows会收到一段错乱的数据。标准做法就是我上面代码里的usbBusy标志：发送前先确认上一包发完，没发完就等着。
6.3 丢键与6键无冲：两种不同的问题
实际打字过程中偶尔丢一个键，很多人第一反应是程序问题，其实要分情况。USB HID标准规定普通按键最多同时上报6个，一旦超过6个，主机无法表示所有按键，就会出现键位丢失或随机替换。这是“6键无冲”的限制，不是芯片性能问题。CH552本身完全可以做全键无冲方案，但那是通过把设备声明成游戏手柄或者多接口键盘实现的，协议复杂度会明显增加。
如果同时按下的键不超过6个仍然丢键，那才是时序问题。排查重点放在usbBusy标志上：每次IN发送完成后是否清标志，发送函数里是否有合适的等待逻辑。另外中断服务里清标志的时机也要注意，不要在主循环里手工清，否则可能把下一次传输的状态弄乱。
6.4 USB抓包验证一次完整上报
当问题定位到协议层面时，抓包是唯一可靠的手段。Windows下可以用Wireshark加USBPcap组合，开启USB捕获后，插入设备，观察枚举阶段的GET_DESCRIPTOR和后续的中断IN传输。你要关注的信息有三类：设备描述符返回的VID/PID是否正确、配置描述符的wTotalLength是否和实际数组长度一致、中断IN端点收到的8字节报告内容是否符合预期。
第一次看到抓包数据时会觉得字段太多，其实只需要关注URB的请求和响应。如果某一项描述符请求返回的是STALL而不是数据，说明设备的SETUP解析有分支没处理到，逐行对照官方例程就能定位到漏掉的请求。
7. 从HID键盘模拟器到宏键盘：我踩过的几个扩展示范
7.1 组合键和字符串序列输入的写法
标准键盘模拟器跑通之后，最大的乐趣就是做宏键盘。最简单的一个功能是“按一次物理键，发送组合快捷键”，比如按下K1，电脑执行Win+D回到桌面。实现这个只需要在发送时填上修饰键和键码：
#define MOD_GUI 0x08 #define KEY_D 0x07 // 发送 Win + D：按下 SendKeyReport(MOD_GUI, KEY_D); // 等待几毫秒后发送空报告 delay_ms(30); SendKeyReport(0x00, 0x00);要注意的是组合键消息必须“按下-释放”成对发送，否则Windows会以为你的GUI键一直被按着。如果要做更复杂的多键序列，比如自动输入一串字符，可以用循环去发：把字符串预先把每个字符转成对应键码，中间加5到10毫秒延时，逐字符发送。延时不能太短，否则Windows会漏收。
7.2 多媒体键：改报告描述符还不够
想加Play/Pause、音量加减这类多媒体键，只改报告数据是不够的，因为标准键盘报告里没有这些键位。你需要在HID报告描述符里增加一个Consumer Page（Usage Page 0x0C），并让设备上报2字节的Consumer Control报告，或者在键盘报告里扩展字段。
我建议第一次扩展时不要盲目改键盘的报告格式，而是直接在原8字节报告后面追加2字节的Consumer Control字段，然后同步修改报告描述符的长度和配置描述符里HID报告描述符的长度。CH552的8字节端点包长会不够用，需要把端点最大包长改成16字节。这里最容易踩的坑是只改了描述符，忘记改端点发送长度，结果主机还是按旧格式解析数据。
7.3 我个人做这块芯片的一点体会
把CH552从“一块能跑点灯的51单片机”变成“能模拟键盘的USB设备”，最大的门槛其实是理解USB描述符和状态之间的逻辑关系。芯片本身很便宜，官方SDK也很完善，大多数时间不是在调寄存器，而是在和自己的耐心较劲。先跑通官方例程，再一点一点改功能，这个顺序我每次做USB相关项目都会坚持。另外，调试时手边最好常备一根确认过数据功能的USB线，很多“板子坏了”的假象，最后都只是线材的问题。
