简介一份面向单片机开发者和电子爱好者的PS2手柄通讯手册解决主机如STM32与手柄接收器之间的串行通信问题涵盖引脚定义、通讯时序、数据格式与硬件连接示例。包体为1个PDF文档大小146KB内容精炼但系统完整可直接对照阅读。已有857人学习适用于需要快速集成PS2手柄到嵌入式项目的场景。手册详细介绍了DI/DAT、DO/CMD、CS/SEL等引脚功能以及0x01命令、ID回复0x41/0x73、0x42请求数据、0x5A数据就绪的握手流程并给出按键数据映射表、摇杆模拟值和STM32平衡车接线方案。读者可据此掌握红灯/绿灯模式下按键与摇杆的解析方式为游戏控制器、机器人遥控等DIY项目提供可靠参考减少逆向协议与排错时间。1. PS2 手柄通讯手册一套协议两条数据线六个有效字节做平衡车、机械臂这类项目的人多半都动过用游戏手柄做无线遥控的念头。PS2 手柄是市面上最容易买到、也最常被搜到资料的外设之一但网上关于它的说法相当零散有人说是 SPI有人说必须 GPI/O 模拟时序有人贴了引脚图却没说哪根必须接、哪根可以空着。这份通讯手册把 9 根引脚定义、0x01/0x42/0x5A 三段握手流程以及红灯绿灯两种工作模式一次讲清楚了适合想用 STM32 这类单片机把手柄接入自己项目的开发者也适合调试时用来倒推问题。先记住两条结论真正需要接的线只有六根真正有用的数据只有六个字节。2. 九根引脚与三步握手从引脚定义到时序读取的完整链路接收器是一个单排 9 针的小板子上面有丝印标注引脚序号不同卖家板子的丝印位置略有差异接线前最好拿万用表确认第 1 脚到底在哪边别上来就按颜色猜。这 9 根脚里3 号和 8 号是 NC 空脚9 号 ACK 在编程时用不到真正参与通讯的只有 6 根。这一章先把每根引脚讲透再把一帧数据的完整读取流程串起来。2.1 九根引脚逐一说清DI、DO、CS、CLK 各管什么ACK 为什么可以不接先说引脚定义。接收器 9 针定义如下表其中 DI/DAT 和 DO/CMD 这两根最容易搞混后面避坑章节会专门说到接反的表现。序号名称信号方向说明1DI/DAT手柄 → 主机8bit 串行数据下降沿同步2DO/CMD主机 → 手柄8bit 串行命令下降沿同步3NC-空脚4GND-电源地5VDD-电源正允许 3~5V6CS/SEL主机 → 手柄片选低电平有效7CLK主机 → 手柄时钟由主机产生8NC-空脚9ACK手柄 → 主机应答信号编程时未使用DI/DAT 是手柄往主机方向回数据DO/CMD 是主机往手柄方向发命令两者都是 8bit 串行、在时钟下降沿同步。也就是说每次时钟从高变低的那一瞬间数据线上必须已经是稳定电平程序读取的时机就要卡在这个下降沿上。CLK 完全由主机给出手柄不产生时钟所以单片机不主动打时钟手柄就一句话都不说。CS 在整个通讯期间必须保持低电平所有字节读完后拉高表示本次通讯结束这个拉高动作经常被忽略也是帧错位的常见来源。ACK 这根线值得单独说。手册里描述 ACK 会在每个 8bit 数据发送的最后一个周期变低前提是 CS 保持低电平但在实际编程时并没有人真去等这个信号。原因很简单主机的读取流程是「拉低 CS → 按次序发命令字节、收数据字节 → 拉高 CS」只要 CS 一拉高整个流程就复位了程序根本不需要知道手柄什么时候 ACK。资料里还特别注明如果 CS 一直不恢复正常电平约 60 微秒后主机会尝试寻找其他外设对应到我们的代码里就是每读完一帧必须把 CS 拉高并稳定一小段时间给接收器一个重新同步的机会。VDD 标称是 3~5V我一般会直接接到和单片机相同的电源域也就是 3.3V 就都接 3.3V5V 系统就都接 5V。这样做的原因是避免电平不匹配如果手柄这边用 5V 供电DI 线上回传的高电平就是 5V对只容忍 3.3V 的 MCU 引脚有风险反过来手柄用 3.3V、单片机用 5V 倒是能读但逻辑电平余量偏小容易在干扰环境下误判。同电源域是最省事的做法。手册给出的 STM32 连接方式是标准接法我实际项目里也是照这个接功能接收器引脚STM32 引脚DI/DAT1PB14DO/CMD2PB15GND4GNDVDD5VCC3.3VCS/SEL6PB12CLK7PB13这里多说一句这套线序看起来和 SPI 很像DI 像 MISO、DO 像 MOSI、CLK 像 SCK、CS 像片选但它不是标准 SPI。一是每轮传输的命令字节不一样第 0 轮发 0x01、第 1 轮发 0x42、后面几轮主机不发命令但时钟不能停标准 SPI 设备没法表达这种「只给时钟不发数据」的中间态二是采样沿定义也比较特殊。所以实际工程里绝大多数人是用 GPIO 模拟时序而不是开硬件 SPI。GPIO 模拟的另一个好处是时钟速度可以压得很低几十 kHz 到几百 kHz 都稳定PS2 手柄本身对时钟频率不敏感稳定比速度重要。2.2 三步握手与九轮传输0x01、0x42、0x5A 是怎么串起来的手柄和接收器上电后会自动配对配对成功前接收器绿灯闪烁、手柄上的灯也闪配对成功后接收器绿灯常亮。绿灯常亮之后主机就可以开始读数据了。一次完整的读取包含 9 轮传输每轮 8bit由主机控制 CS 和 CLK流程如下主机把 CS 拉低选中接收器第 0 轮DO 线上发 0x01手柄收到后知道主机要读它第 1 轮DO 发 0x42 请求数据同时从 DI 读回手柄 ID第 2 轮DO 空闲DI 收到 0x5A意思是「数据来了」第 3~8 轮DO 继续空闲DI 依次送出按键和摇杆数据全部读完CS 拉高一帧结束。把 9 轮传输的 DO 和 DI 行为列成表会更直观顺序DO主机发DI主机收00x01空闲10x42ID0x41 绿灯 / 0x73 红灯2空闲0x5A3空闲按键 14空闲按键 25空闲PSS_RX 右摇杆 X6空闲PSS_RY 右摇杆 Y7空闲PSS_LX 左摇杆 X8空闲PSS_LY 左摇杆 Y表里的「空闲」不是什么都不做而是「不给 DO 赋值有效命令但 CLK 必须继续打」。因为 DI 上的数据是跟着时钟一位一位移出来的只要 CLK 在跳DI 就在输出主机侧每轮都要照常给出 8 个时钟脉冲才能把这一字节完整采回来。我见过有人把「空闲」理解成可以停时钟结果后面数据全错位这个坑放到第 4 章细说。关于下降沿采样的实现含义程序里要做到先拉低 CLK再把 DO 命令位放上去然后把 CLK 拉高再拉低在从高到低的这个边沿去读 DI。这样可以保证读到的是命令和数据都已稳定的值。如果顺序反过来在上升沿读经常能读到上一拍残留的旧数据表现出来就是按键值偶尔跳变、摇杆值抖得厉害。3. 数据帧解析按键的负逻辑、摇杆模拟值以及红灯绿灯模式差异第 3~8 轮收到的 6 个字节就是每次按键和摇杆状态的完整快照。这一章把每个比特的含义拆开讲并给出可以直接搬进工程用的解析函数。重点在理解按键数据的负逻辑和两种模式的区别这两点理解不到位后面写解析层大概率翻车。3.1 按键字节位映射SELECT 到 □ 的 16 个键按下为 0第 3 轮和第 4 轮是两个按键字节每个字节 8bit共 16 个按键。按位对应关系如下接收字节Bit7Bit6Bit5Bit4Bit3Bit2Bit1Bit0frame[3]LEFTDOWNRIGHTUPSTARTR3L3SELECTframe[4]□╳○△R1L1R2L2注意这里是最低位对应 Bit0也就是 SELECT 在第 3 字节的最低位。收到的一字节数据里按键没按下时对应位是 1按下时是 0负逻辑。手册里的例子很典型按下 SELECT 时frame[3] 11111110B也就是 0xFE最低位变成 0。为什么手柄要用这种反逻辑因为按键扫描的自然状态就是高电平按下时被拉低协议层直接把这个 IO 电平固化成了数据位。所以解析时先整体取反一次按下就变成 1后续用位掩码判断逻辑最简单也最不容易写错。后文 3.3 的代码就是这么干的。第 5~8 轮是 4 个摇杆字节PSS_RX、PSS_RY 是右摇杆PSS_LX、PSS_LY 是左摇杆。摇杆输出的是模拟量映射到 0x00~0xFF 的整数0x00 往一个方向极限0xFF 往另一个方向极限中间值大约在 0x80 附近。手册给的方向定义是PSS_RX 的 0x00 对应左、0xFF 对应右PSS_RY 的 0x00 对应上、0xFF 对应下LX、LY 同理。这个方向映射是手柄默认的实际装到车上的方向不匹配时程序里取反一下就行数据本身没有对错问题。3.2 红灯模式与绿灯模式一个输出模拟量一个输出方向开关手柄面板上的 MODE 键可以切换工作模式模式不同摇杆行为完全不同而且 ID 也会跟着变。手册给的对应关系很明确0x41 是模拟绿灯0x73 是模拟红灯。两种模式的差异如下表项目绿灯模式ID0x41)红灯模式ID0x73)摇杆输出无模拟值推极限触发方向键0x00~0xFF 完整模拟量摇杆按下 L3/R3无效有效典型用途方向开关控制比例调速、舵机角度绿灯模式下摇杆推到极限时不会输出模拟值而是直接触发对应方向按键等效于把摇杆当十字键用只有四个极限方向所以叫「模拟绿灯」红灯模式下摇杆才是真正的模拟量输出同时 L3/R3 这两个「摇杆往下按」的开关量也有效。也就是说红灯模式的摇杆信息量更大位置是连续模拟值按下动作是开关量两种信息在数据里都能拿到。工程上怎么选纯方向控制比如小车前进后退左转右转绿灯模式就够了解析简单也不怕摇杆中位漂移需要连续比例控制比如差速转向的转弯曲率、机械臂关节速度就必须用红灯模式。还有一点容易被忽略红灯模式下如果程序没判断 ID直接按下方向键对应的「按键按下为 0」逻辑照样成立但摇杆模拟值不受按键影响容易出现「我按了方向键怎么摇杆没动」的错觉。反过来绿灯模式下推摇杆可能只有到极限那一下才有反应中间位置推多少都没用这是模式本身的特性不是手柄坏了。3.3 解析代码把 9 字节帧转成结构体一次取反解决负逻辑知道了位映射解析层就很直接了。先定义结构体再把 frame[3] 和 frame[4] 取反后逐位拆开摇杆字节直接赋值。这里的关键点就是取反必须在解析入口做一次而不是在每次判断按键时再处理。typedef struct { uint8_t select, l3, r3, start; uint8_t up, right, down, left; uint8_t l2, r2, l1, r1; uint8_t triangle, circle, cross, square; uint8_t rx, ry, lx, ly; } PS2_Data; void PS2_Parse(uint8_t* frame, PS2_Data* out) { uint8_t key1 ~frame[3]; // SELECT,L3,R3,START,UP,RIGHT,DOWN,LEFT uint8_t key2 ~frame[4]; // L2,R2,L1,R1,TRIANGLE,CIRCLE,CROSS,SQUARE out-select (key1 0) 1; out-l3 (key1 1) 1; out-r3 (key1 2) 1; out-start (key1 3) 1; out-up (key1 4) 1; out-right (key1 5) 1; out-down (key1 6) 1; out-left (key1 7) 1; out-l2 (key2 0) 1; out-r2 (key2 1) 1; out-l1 (key2 2) 1; out-r1 (key2 3) 1; out-triangle (key2 4) 1; out-circle (key2 5) 1; out-cross (key2 6) 1; out-square (key2 7) 1; out-rx frame[5]; out-ry frame[6]; out-lx frame[7]; out-ly frame[8]; }这段代码没有任何玄学就是按位拆。key1 和 key2 各取反一次之后原来的「按下为 0」就变成「按下为 1」后面的移位和与运算一眼能看懂。摇杆字节不要取反它们是模拟量原始值是多少程序就用多少。解析层写完后还有一个工程习惯值得保留先判断 ID 再决定走哪条解析分支。绿灯模式0x41下摇杆数据本质上是方向开关红灯模式0x73下才是模拟量。程序里可以保留一个 mode 字段每次读帧时刷新解析逻辑按模式分开走避免在同一个分支里混着处理两种完全不同的语义。我在实际项目里是直接在结构体里加了一个mode_id字段主循环根据它决定把摇杆值当成方向键还是模拟量。4. 避坑排查读不到 ID、数据错位、模式失效的五个典型现场这章记录的是我拆过和调试 PS2 手柄时真正踩过的坑每一条都有具体的现场表现以及排查时最先看哪里。如果你照着手册接完线却发现读不到数据先按这五条顺序过一遍大概率能找到问题。4.1 读不到 ID串口打出来全是 0xFF现象代码跑起来串口打印第 0 字节 0x01 正常第 1 字节一直是 0xFF后面跟着全是 0xFF或者整帧所有字节都是 0xFF。手柄灯是常亮的说明配对正常。原因DI 和 DO 接反或者 GND 没和单片机共地。PS2 的串行数据是电平信号必须和主机共地才有参考电位DI/DO 接反则主机发命令的线实际接到了手柄的数据线上读回来的自然全是无效位。解决先拿万用表量接收器 GND 和单片机 GND 是否通不通先补地线。通的话把 DIPin1接 PB14、DOPin2接 PB15 重新对一遍就按手册这组接法来不要自己乱换。我在初始化函数里加了一行调试打印上电先打一次 ID看到 0x41 或 0x73 就说明 DI/DO 方向对了。4.2 接收器绿灯一直闪手柄上的灯也闪现象接收器灯和手柄灯都没有进入常亮状态而是一直闪单片机侧完全读不到数据。程序逻辑检查了很多遍都没问题。原因手柄没和接收器配对成功。配对是手柄和接收器之间的自动过程发生在两者都通电并打开手柄开关之后和单片机无关也不受程序控制。如果你只给接收器通了电、忘记打开手柄侧面的开关或者手柄和接收器不是原配的就会一直闪。解决把接收器重新上电再打开手柄开关等绿灯从闪烁变成常亮。如果反复无效检查 VDD 供电电压低于 3V 时配对容易不稳定。可以换 5V 供电再试但要注意 5V 供电时 DI 线上的高电平接近 5V3.3V 单片机需要确认引脚是否容忍或者串个限流电阻、用分压处理。4.3 红灯绿灯模式搞混摇杆推了数值不动现象程序按摇杆模拟值解析但推摇杆时数据不变只有推到极限那一下才跳变或者按方向键没反应摇杆却触发了方向键。原因手柄当前处于绿灯模式ID0x41摇杆本身不输出模拟量推极限才映射成方向键程序没有判断 ID把方向开关当模拟量处理自然觉得数据不对。或者反过来手柄在红灯模式ID0x73程序却按方向键解析导致按下方向键没反应。解决读帧后先判断 ID 再解析绿灯模式走方向键分支红灯模式走模拟值分支按 MODE 键切换后重新读一次 ID。另外红灯模拟量有一个中位偏移问题摇杆物理中位通常不是精确的 0x80会有 ±0x10 左右的偏差程序里要做死区处理比如abs(value - 0x80) 0x10就当作中位否则小车可能会自己慢慢走。4.4 第一帧正常第二帧开始数据错位现象上电后的第一次读取结果是对的从第二帧开始按键数据对不上号帧长度看起来也是乱的复位后第一帧又正常。原因上一帧读完后 CS 没有拉高接收器状态没有复位或者两次读取间隔太短接收器还没准备好下一帧。CS 保持低电平时手柄会一直处于传输状态你再次拉低 CS 发 0x01它可能从半截状态开始响应字节边界就乱了。解决每帧读完强制把 CS 拉高并且等 1~2 毫秒再开始下一帧。我一般会在读取函数开头写一个复位序列先 CS 拉高 → 延时 → CS 拉低 → 再延时 → 才开始发第一个命令字节。这个序列看起来多余但对通讯稳定性帮助很大尤其是在主循环里还有其他任务抢占 CPU 时间的场合。4.5 GPIO 模拟时 DO 线空闲状态不定偶尔读到随机值现象按键数据偶尔出现随机跳变同一个按键按下去这次读到 0下次读到的位变成了 1。用示波器看 CLK 和 DO 波形又看不太出问题。原因GPIO 模拟时DO 在每个时钟周期都必须被明确赋值要么是命令位要么是 0。如果程序里只在有命令的那两轮写了 DO后面几轮放任不管DO 引脚可能停在上一轮的残余电平。更隐蔽的是 DO 被配置成开漏输出空闲时被外部干扰拉成不稳定电平导致手柄收到的命令位出错。解决移位函数里每一轮、每一位都对 DO 引脚做一次赋值命令字节传 0 也要写不要用 if 判断「有命令才写」。另外把 DO 引脚配置成推挽输出开漏在这个场景没必要。这个问题的根源是「默认状态不可控」把每一拍都写清楚就不会有随机值混进来。5. STM32 实战读取GPIO 模拟时序先打印原始帧再写解析层最后落到 STM32 上的完整读取实现。下面这套代码可以直接抄进工程初始化 GPIO、移位收发、读一帧 9 字节三部分各司其职。#include main.h #define PS2_CS_PIN GPIO_PIN_12 #define PS2_CLK_PIN GPIO_PIN_13 #define PS2_DI_PIN GPIO_PIN_14 // 手柄 - 主机 #define PS2_DO_PIN GPIO_PIN_15 // 主机 - 手柄 void PS2_GPIO_Init(void) { GPIO_InitTypeDef gpio {0}; __HAL_RCC_GPIOB_CLK_ENABLE(); gpio.Pin PS2_CS_PIN | PS2_CLK_PIN | PS2_DO_PIN; gpio.Mode GPIO_MODE_OUTPUT_PP; gpio.Pull GPIO_NOPULL; gpio.Speed GPIO_SPEED_FREQ_LOW; HAL_GPIO_Init(GPIOB, gpio); gpio.Pin PS2_DI_PIN; gpio.Mode GPIO_MODE_INPUT; gpio.Pull GPIO_PULLUP; HAL_GPIO_Init(GPIOB, gpio); HAL_GPIO_WritePin(GPIOB, PS2_CS_PIN, GPIO_PIN_SET); } static uint8_t PS2_Shift(uint8_t cmd) { uint8_t rx 0; for (uint8_t i 0; i 8; i) { HAL_GPIO_WritePin(GPIOB, PS2_CLK_PIN, GPIO_PIN_RESET); HAL_GPIO_WritePin(GPIOB, PS2_DO_PIN, (cmd (0x80 i)) ? GPIO_PIN_SET : GPIO_PIN_RESET); delay_us(2); HAL_GPIO_WritePin(GPIOB, PS2_CLK_PIN, GPIO_PIN_SET); delay_us(2); HAL_GPIO_WritePin(GPIOB, PS2_CLK_PIN, GPIO_PIN_RESET); rx 1; if (HAL_GPIO_ReadPin(GPIOB, PS2_DI_PIN)) rx | 0x01; delay_us(2); } return rx; } uint8_t PS2_ReadFrame(uint8_t* buf) { HAL_GPIO_WritePin(GPIOB, PS2_CS_PIN, GPIO_PIN_SET); delay_us(10); HAL_GPIO_WritePin(GPIOB, PS2_CS_PIN, GPIO_PIN_RESET); delay_us(2); buf[0] PS2_Shift(0x01); buf[1] PS2_Shift(0x42); for (uint8_t i 2; i 9; i) buf[i] PS2_Shift(0); HAL_GPIO_WritePin(GPIOB, PS2_CS_PIN, GPIO_PIN_SET); return buf[1]; }PS2_Shift 的时序顺序是先拉低 CLK再放 DO 命令位然后拉高再拉低并采样 DI。这个顺序对应手册说的下降沿读取保证在采样的瞬间数据线已经稳定。GPIO 速度配 LOW 就够PS2 手柄本来就是低速设备CLK 周期放慢反而更稳。delay_us 建议按实际时钟频率调2 微秒在 72MHz 主频下约合 144 个时钟周期误差不大但如果你跑在 48MHz 或者开了中断最好用定时器延时或者 DWT 延时函数别依赖空循环。主循环里的验证方法是关键。先把原始帧打出来不做任何解析uint8_t frame[9]; while (1) { uint8_t id PS2_ReadFrame(frame); printf(ID0x%02X B30x%02X B40x%02X LX%d\n, id, frame[3], frame[4], frame[7]); HAL_Delay(20); }验证时看三个点第一ID 是不是 0x41 或 0x73不是就返回到第 4 章第一条排查第二B3/B4 原始字节里按下按键对应位是否变成 0SELECT 按下时 B3 应为 0xFE第三红灯模式下推左摇杆LX 应从 0x00 到 0xFF 连续变化绿灯模式下只在极限位置跳变到方向键对应值。这三步确认完再调用第 3 章的 PS2_Parse 写业务逻辑基本不会再出时序问题。从那以后我每换一块板子或者新买一个手柄都会强制走一遍这个流程先查共地、看供电灯再打印原始帧最后才写解析层。宁可多花五分钟看原始字节也不愿意对着一个玄学 bug 查一下午。这套通讯手册把协议细节和数据映射都写齐了照着这份流程一步步验证你也能把 PS2 手柄稳定地接进自己的项目希望帮到你。本文还有配套的精品资源点击获取