曼彻斯特与差分曼彻斯特编码：从原理推导到STM32实现

数字信号编码这块内容，我在做嵌入式通信和工业总线的时候踩过不少坑。最早接触曼彻斯特编码，是因为一个STM32项目里需要把传感器数据通过单根信号线传出去，同时还要让接收端能自己恢复时钟——当时试过NRZ编码，结果接收端时钟漂移严重，数据错得一塌糊涂。后来换成曼彻斯特编码，问题迎刃而解。但真正把曼彻斯特和差分曼彻斯特的推导过程吃透，是在一次需要手动解码RFID信号的时候，那时候没有现成的解码芯片，只能用MCU的定时器捕获边沿，然后靠软件还原比特流。也就是从那时候起，我才真正理解了这两种编码方式在波形层面的每一个细节。

这篇文章我会从最基础的推导开始，把曼彻斯特编码和差分曼彻斯特编码的每一个电平跳变、每一个比特周期讲清楚。不管你是刚开始学通信原理的学生，还是需要在STM32上实现软件编码的工程师，或者是在做RFID、以太网、工业总线解码的从业者，这篇内容都能给你一套可以直接复现的完整方案。我会把推导过程、代码实现、示波器实测波形、以及常见问题排查都串起来讲，尽量做到你看完就能动手。

1. 从NRZ到曼彻斯特：为什么需要自同步编码

1.1 NRZ编码的致命缺陷

NRZ，也就是不归零编码，是最直观的数字信号编码方式。高电平代表1，低电平代表0，一个比特周期内电平保持不变。这种编码方式实现简单，频谱效率高，在短距离、有时钟线的通信中非常常见，比如SPI、UART（加上起始位和停止位后）都在用类似思路。

但NRZ有一个致命问题：没有自同步能力。所谓自同步，就是接收端能从数据信号本身提取出时钟信息，而不需要额外的一根时钟线。NRZ信号里，如果连续发送多个相同的比特，比如连续八个1，信号线会一直保持高电平，接收端根本不知道每一位的边界在哪里。时间一长，收发两端的时钟如果有微小偏差，累积起来就会导致采样点偏移，最终解码错误。

我当初在STM32上做单线通信时就遇到了这个问题。发送端用72MHz主频分频出来的波特率，接收端用内部RC振荡器，两者偏差大概在2%左右。发送端连续发了32个0，接收端到后面几位就开始错位，读出来的数据完全不对。这就是NRZ在没有独立时钟线时的硬伤。

1.2 曼彻斯特编码的核心思想

曼彻斯特编码的思路很巧妙：把时钟信息嵌入到数据波形里。具体做法是，在每个比特周期的中间时刻，强制产生一次电平跳变。这个跳变既承载了数据信息，又给接收端提供了时钟参考。

标准曼彻斯特编码的约定是：

• 比特1：从高电平跳到低电平，也就是前半周期高、后半周期低
• 比特0：从低电平跳到高电平，也就是前半周期低、后半周期高

这样一来，无论数据内容是什么，每个比特周期中间一定有一次跳变。接收端只要检测到这个中间跳变，就能锁定比特边界，从而实现自同步。这个中间跳变我习惯叫它“时钟跳变”，而比特边界处的跳变叫“数据跳变”——不过要注意，在标准曼彻斯特编码里，比特边界处不一定有跳变，取决于相邻两个比特的值。

1.3 自同步带来的代价与收益

自同步不是免费的。曼彻斯特编码的跳变频率是NRZ的两倍，这意味着信号带宽翻倍。换句话说，同样的数据速率，曼彻斯特编码需要更大的信道带宽。在以太网早期标准里，10Mbps的曼彻斯特编码实际占用的带宽相当于20MHz的方波频率成分，这就是代价。

但收益也很明显：只需要一根信号线，接收端就能恢复时钟和数据；信号的平均直流分量为零，适合变压器耦合和AC耦合的传输链路；跳变频繁，便于接收端做边沿检测和同步。所以在10BASE-T以太网、RFID的某些协议、红外遥控、以及一些工业现场总线里，曼彻斯特编码都被广泛采用。

注意：曼彻斯特编码的“1”和“0”定义并不是唯一的。有些协议规定比特1是低到高，比特0是高到低，正好反过来。实际使用时必须和收发双方约定一致，否则解出来的数据全是反的。我在第一次做RFID解码时就因为搞反了定义，折腾了半天才发现。

2. 曼彻斯特编码的完整推导与波形分析

2.1 比特周期与跳变时刻的数学定义

设比特周期为T，码元速率为R=1/T。在标准曼彻斯特编码中，每个比特周期被分成两个相等的半周期，每个半周期长度为T/2。中间跳变发生在t=T/2时刻，比特边界跳变发生在t=T时刻（也就是下一个比特的起始）。

用数学方式描述，设第n个比特为b_n，b_n∈{0,1}。标准曼彻斯特编码的信号s(t)在区间[nT,(n+1)T)内可以表示为：

• 当b_n=1时：s(t)=+A，t∈[nT, nT+T/2)；s(t)=-A，t∈[nT+T/2, (n+1)T)
• 当b_n=0时：s(t)=-A，t∈[nT, nT+T/2)；s(t)=+A，t∈[nT+T/2, (n+1)T)

这里A是信号幅度。可以看到，无论b_n取什么值，在t=nT+T/2处一定有一次电平翻转。这就是自同步的物理基础。

2.2 逐比特推导：以序列1011001为例

光看公式不够直观，我拿一个具体序列来推。假设要发送的比特序列是1 0 1 1 0 0 1，比特周期T=1μs，高电平为3.3V，低电平为0V。

按照标准曼彻斯特编码（1=高到低，0=低到高）：

这里需要仔细核对边界跳变。让我重新梳理：

• 比特1：前半高，后半低。结束电平是低(0V)。
• 比特0：前半低，后半高。起始电平是低(0V)，和前一比特结束电平相同，所以边界处无跳变。结束电平是高(3.3V)。
• 比特1：前半高，后半低。起始电平是高(3.3V)，和前一比特结束电平相同，边界处无跳变。结束电平是低(0V)。
• 比特1：前半高，后半低。起始电平是高(3.3V)，但前一比特结束是低(0V)，所以边界处有跳变（上升沿）。结束电平是低(0V)。
• 比特0：前半低，后半高。起始电平是低(0V)，和前一比特结束相同，边界无跳变。结束电平是高(3.3V)。
• 比特0：前半低，后半高。起始电平是低(0V)，但前一比特结束是高(3.3V)，边界有跳变（下降沿）。结束电平是高(3.3V)。
• 比特1：前半高，后半低。起始电平是高(3.3V)，和前一比特结束相同，边界无跳变。结束电平是低(0V)。

所以边界跳变并不是每个比特都有，而是取决于相邻比特的值。但中间跳变是每个比特都有的，这是关键。

2.3 波形特征与频谱含义

把上面的序列画成波形，你会看到一串宽度为T/2的方波，每个比特中间必有一次翻转。从频谱角度看，曼彻斯特编码的主瓣宽度是NRZ的两倍，零点出现在2R处（R是比特率）。这意味着如果比特率是1Mbps，曼彻斯特编码的第一零点在2MHz。

这个频谱特性带来两个实际影响：一是需要更宽的传输带宽，二是不含直流分量。不含直流分量这点很重要，因为很多传输介质（比如变压器、电容耦合链路）无法传递直流。NRZ如果连续发送长串的1或0，信号会偏向一边，导致耦合失效。曼彻斯特编码因为每个比特都有跳变，平均直流为零，所以天然适合AC耦合。

2.4 用STM32定时器生成曼彻斯特波形

在实际项目中，我经常用STM32的定时器和GPIO来软件生成曼彻斯特波形。思路很简单：用定时器产生T/2周期的中断，在中断里根据当前比特和半周期位置翻转GPIO。

下面是一段基于STM32 HAL库的伪代码，展示核心逻辑：

// 假设定时器中断周期为T/2 volatile uint8_t bit_index = 0; volatile uint8_t half_phase = 0; // 0表示前半周期，1表示后半周期 volatile uint8_t data_bits[8] = {1,0,1,1,0,0,1,0}; volatile uint8_t total_bits = 8; void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim) { if (htim == &htim2) { uint8_t current_bit = data_bits[bit_index]; if (half_phase == 0) { // 前半周期 if (current_bit == 1) { HAL_GPIO_WritePin(GPIOA, GPIO_PIN_5, GPIO_PIN_SET); // 高 } else { HAL_GPIO_WritePin(GPIOA, GPIO_PIN_5, GPIO_PIN_RESET); // 低 } half_phase = 1; } else { // 后半周期 if (current_bit == 1) { HAL_GPIO_WritePin(GPIOA, GPIO_PIN_5, GPIO_PIN_RESET); // 低 } else { HAL_GPIO_WritePin(GPIOA, GPIO_PIN_5, GPIO_PIN_SET); // 高 } half_phase = 0; bit_index++; if (bit_index >= total_bits) { bit_index = 0; // 循环发送 } } } }

这段代码的关键点在于：定时器中断频率必须是比特率的两倍。比如你要发1Mbps，定时器中断频率就是2MHz，也就是每500ns进一次中断。在STM32F103上，72MHz主频，定时器预分频设为0，自动重装载值为35，就能得到2MHz中断（72M/(35+1)=2M）。实际调试时，中断服务程序的执行时间必须远小于500ns，否则会丢中断。如果中断里操作太复杂，建议用DMA加定时器的方式，或者用硬件SPI加编码电路。

实操心得：软件生成曼彻斯特波形时，中断优先级一定要设高，而且中断里尽量只做GPIO翻转，不要做复杂运算。我最早把数据数组的索引计算放在中断里，结果因为除法运算耗时太长，波形出现了抖动。后来改成查表法，把每个比特对应的前半周期和后半周期电平预先算好存到数组里，中断里直接查表输出，波形就干净了。

3. 差分曼彻斯特编码的推导与对比

3.1 差分曼彻斯特的核心规则

差分曼彻斯特编码和标准曼彻斯特编码最大的区别在于：数据不再由跳变方向表示，而是由比特起始处是否有跳变来表示。中间跳变依然保留，只用于时钟同步。

具体规则是：

• 每个比特周期的中间时刻，一定有一次电平跳变（和标准曼彻斯特一样）
• 比特的起始处，如果和前一个比特的结束电平相比有跳变，表示比特0；如果没有跳变，表示比特1

注意，这个“0”和“1”的定义也可以反过来，取决于协议约定。有些协议规定有跳变是1，无跳变是0。这里我采用常见的一种约定：起始有跳变=0，起始无跳变=1。

差分曼彻斯特的好处是：极性无关。也就是说，如果你把信号线反接，或者传输过程中信号被反相了，解码结果依然正确。因为解码只看跳变的有无，不看电平的高低。这在变压器耦合或差分传输中非常有用。

3.2 逐比特推导：同样以1011001为例

为了和前面对比，我还是用序列1 0 1 1 0 0 1，比特周期T=1μs。假设初始参考电平（第一个比特开始前的电平）为低(0V)。

按照规则：中间必跳变；起始有跳变=0，起始无跳变=1。

这里需要仔细核对。差分曼彻斯特的推导容易绕晕，我建议用状态机的方式理解：维护一个“当前电平”状态，每个比特开始时，根据比特值决定是否翻转当前电平（0翻转，1不翻转），然后前半周期保持这个电平，后半周期再翻转一次。

用状态机重新推：

• 初始电平：低(0V)
• 比特1：不翻转，前半=低，后半=高，结束=高
• 比特0：翻转，前半=低（从高翻到低），后半=高，结束=高
• 比特1：不翻转，前半=高，后半=低，结束=低
• 比特1：不翻转，前半=低，后半=高，结束=高
• 比特0：翻转，前半=低（从高翻到低），后半=高，结束=高
• 比特0：翻转，前半=低（从高翻到低），后半=高，结束=高
• 比特1：不翻转，前半=高，后半=低，结束=低

这个结果和上面的表格有出入，因为表格里我手动判断起始跳变时容易出错。状态机方法更可靠。让我用状态机的结果为准。

对比标准曼彻斯特的波形，差分曼彻斯特的中间跳变依然存在，但起始跳变的位置和方向不同。标准曼彻斯特的跳变方向直接对应比特值，而差分曼彻斯特的跳变有无对应比特值。

3.3 两种编码的对比表格

3.4 差分曼彻斯特的解码状态机实现

差分曼彻斯特的解码比编码更需要小心。在MCU上实现时，我通常用外部中断捕获边沿，然后测量边沿之间的时间间隔来判断是中间跳变还是起始跳变。

解码思路：

1. 捕获第一个边沿，记录时间戳
2. 捕获后续边沿，计算与上一个边沿的时间差
3. 如果时间差接近T/2，说明是中间跳变，继续等待
4. 如果时间差接近T，说明从上一个中间跳变到当前起始跳变之间没有中间跳变？不对，中间跳变每个比特都有，所以边沿间隔要么是T/2（中间到起始，或起始到中间），要么是T（如果起始无跳变，则上一个中间跳变到下一个中间跳变之间是T）

实际上，差分曼彻斯特的边沿间隔只有两种：T/2和T。当起始有跳变时，边沿序列是：起始跳变、中间跳变、起始跳变、中间跳变……间隔都是T/2。当起始无跳变时，边沿序列是：中间跳变、中间跳变……间隔是T。

所以解码逻辑可以简化为：测量相邻边沿的时间间隔。如果间隔是T/2，说明这个比特起始有跳变（比特0）；如果间隔是T，说明这个比特起始无跳变（比特1）。但要注意，第一个边沿可能是起始跳变也可能是中间跳变，需要先同步。

下面是一段基于STM32输入捕获的解码伪代码：

volatile uint32_t last_capture = 0; volatile uint32_t current_capture = 0; volatile uint32_t interval = 0; volatile uint8_t decoded_bits[32]; volatile uint8_t bit_count = 0; volatile uint8_t synced = 0; void HAL_TIM_IC_CaptureCallback(TIM_HandleTypeDef *htim) { if (htim == &htim3) { current_capture = HAL_TIM_ReadCapturedValue(htim, TIM_CHANNEL_1); if (last_capture != 0) { interval = current_capture - last_capture; // 假设T/2对应定时器计数值为HALF_T，T对应FULL_T if (interval > HALF_T * 0.75 && interval < HALF_T * 1.25) { // 间隔约T/2，起始有跳变，解码为0 if (synced) { decoded_bits[bit_count++] = 0; } } else if (interval > FULL_T * 0.75 && interval < FULL_T * 1.25) { // 间隔约T，起始无跳变，解码为1 if (synced) { decoded_bits[bit_count++] = 1; } } else { // 间隔异常，重新同步 synced = 0; bit_count = 0; } } last_capture = current_capture; if (!synced && bit_count == 0) { synced = 1; // 简化处理，实际需要更严谨的同步逻辑 } } }

这段代码只是示意，实际应用中还需要处理定时器溢出、边沿抖动、以及同步头的识别。我在做RFID解码时，通常会在数据前面加一个已知的同步头，比如“10101010”，接收端先检测同步头，锁定比特边界后再开始解码有效数据。

常见问题：差分曼彻斯特解码时，如果第一个边沿判断错误，后面所有比特都会错位。解决办法是发送端在数据前加足够长的前导码，接收端用前导码做同步。前导码一般用交替的0和1，这样边沿间隔规律，容易锁定。

4. 实际项目中的编码选择与STM32实现细节

4.1 什么时候选曼彻斯特，什么时候选差分曼彻斯特

这个问题我在不同项目里反复权衡过。总结下来：

• 如果传输链路极性固定，收发双方共地，标准曼彻斯特更简单，编解码代码少，CPU开销低。
• 如果传输链路可能反相，比如变压器耦合、差分线对、或者无线RFID，差分曼彻斯特更稳妥。
• 如果对EMI敏感，两种编码的频谱差不多，但差分曼彻斯特的跳变模式更均匀，某些频点的能量分布更平滑。
• 如果MCU资源紧张，标准曼彻斯特的编码可以用硬件SPI加异或门实现，差分曼彻斯特则需要软件维护状态，开销稍大。

我在一个工业传感器项目里，传输线长达50米，用的是RS-485差分传输。虽然RS-485本身有极性，但现场接线时工人偶尔会把A、B线接反。用标准曼彻斯特时，接反后数据全错；换成差分曼彻斯特后，接反也能正常解码，现场调试时间大幅缩短。

4.2 STM32硬件编码方案：SPI加外部逻辑

如果MCU的SPI外设支持，可以用SPI的MOSI输出NRZ数据，然后用一个异或门把时钟和数据异或，得到曼彻斯特编码。具体电路是：SPI的SCK和MOSI接到异或门两个输入，异或门输出就是曼彻斯特编码。因为SPI在SCK的每个周期输出一位数据，异或门在SCK为高时输出MOSI的反相，SCK为低时输出MOSI的原相，正好对应曼彻斯特的前半周期和后半周期。

这个方案的优点是CPU几乎不参与，编码速率可以很高。缺点是只能实现标准曼彻斯特，差分曼彻斯特需要额外的逻辑。而且SPI的时钟极性需要配置正确，否则编码会反。

4.3 软件编码的定时器参数计算

以STM32F103为例，假设系统时钟72MHz，要发送500kbps的曼彻斯特编码。比特周期T=2μs，半周期T/2=1μs。定时器中断频率需要是1MHz，也就是每1μs进一次中断。

定时器配置：预分频器PSC=71，自动重装载值ARR=0。定时器时钟=72MHz/(71+1)=1MHz，计数周期=1μs。这样每次更新中断就是1μs，正好对应半周期。

如果要发送1Mbps，半周期500ns，定时器需要2MHz中断。PSC=35，ARR=0，定时器时钟=72MHz/36=2MHz。但500ns的中断间隔对STM32F103来说压力很大，中断服务程序必须极短。我实测下来，如果中断里只有GPIO翻转和简单的变量自增，可以稳定运行。但如果加上数组索引和条件判断，就会丢中断。这时候建议用DMA加定时器触发GPIO的方式，或者换用更高主频的MCU。

4.4 接收端解码的过采样与滤波

接收端解码时，如果直接用边沿中断，信号上的毛刺会导致误触发。我通常会在GPIO输入前加一个RC低通滤波，截止频率设为比特率的2到3倍。比如500kbps的曼彻斯特编码，最高跳变频率是1MHz，RC截止频率设为2MHz左右，R=1kΩ，C=100pF，时间常数100ns，对1MHz信号影响不大，但能滤掉几十纳秒的毛刺。

另外，用定时器输入捕获时，可以开启输入滤波，STM32的TIM输入捕获有数字滤波器，可以设置采样频率和滤波长度。我一般设为采样频率f_DTS/4，滤波长度8个采样点，这样能有效抑制高频噪声。

实操心得：接收端解码时，不要一检测到边沿就立即解码，而是先测量边沿间隔，如果间隔在合理范围内才认为是有效边沿。我最早做RFID解码时，没有做间隔校验，结果环境噪声导致大量误码。后来加了间隔窗口判断，只有间隔在T/2的±25%或T的±25%范围内才接受，误码率大幅下降。

5. 常见问题与排查技巧实录

5.1 波形抖动与中断丢失

现象：示波器上看曼彻斯特波形，某些半周期宽度不均匀，有的宽有的窄。

原因：定时器中断被更高优先级中断打断，或者中断服务程序执行时间过长，导致下一次中断响应延迟。

排查：用示波器同时观察GPIO翻转和中断标志，或者用MCU的DWT计数器测量中断服务程序执行时间。如果执行时间接近半周期，必须优化代码。

解决：把中断服务程序里的复杂运算移到主循环，中断里只做标志置位和GPIO翻转。或者改用DMA方式，让DMA在定时器触发下自动搬运数据到GPIO。

5.2 解码错位与同步丢失

现象：接收端解码数据偶尔错位，重新上电后又正常。

原因：接收端在数据流中间开始解码，没有找到比特边界。

排查：检查发送端是否有前导码，接收端的同步逻辑是否健壮。

解决：发送端在每帧数据前加至少8个比特的前导码，比如“10101010”。接收端先检测前导码，锁定边沿间隔规律后再开始解码。前导码的边沿间隔是固定的T/2，很容易识别。

5.3 极性接反导致数据全错

现象：标准曼彻斯特编码，接收端解出来的数据全是发送数据的反码。

原因：传输线接反，或者变压器耦合的极性反了。

解决：改用差分曼彻斯特编码，或者在接收端加一个极性检测电路，自动翻转。极性检测可以用前导码实现：如果前导码解出来是“01010101”而不是“10101010”，说明极性反了，软件里把后续数据全部取反即可。

5.4 常见问题速查表

5.5 一个真实的调试案例

我在做一个红外遥控解码项目时，遥控器用的是曼彻斯特编码，比特率大概2kbps。一开始用STM32的输入捕获，解码成功率只有70%左右。后来用示波器看波形，发现红外接收头的输出信号在边沿处有大约50μs的振铃。这个振铃导致输入捕获触发了多次，解码自然就乱了。

解决办法是在软件里加一个“消隐时间”：每次捕获到边沿后，在接下来的100μs内忽略所有边沿。因为比特周期是500μs，半周期250μs，100μs的消隐不会影响正常边沿检测，但能滤掉振铃。加上消隐后，解码成功率到了99.9%。

这个经验告诉我，曼彻斯特解码的难点往往不在编码理论，而在信号完整性和噪声处理。理论推导再清楚，实际信号上的毛刺和振铃不解决，照样解不出数据。

6. 从理论到落地：我的完整实现建议

如果你要在STM32上从零实现曼彻斯特或差分曼彻斯特编解码，我建议按这个顺序来：

第一步，先用示波器或者逻辑分析仪确认发送端的波形。不要急着写接收端代码，先把发送波形调对。发送端可以用定时器中断，也可以用PWM加DMA。我通常先用最简单的定时器中断方式，把波形调出来，确认每个比特的中间跳变和起始跳变都符合预期。

第二步，用逻辑分析仪的协议解码功能验证。很多逻辑分析仪自带曼彻斯特解码，你可以把发送波形接上去，看解码结果是否和发送数据一致。这一步能快速验证编码逻辑。

第三步，写接收端解码。先用输入捕获测量边沿间隔，把间隔数据打印出来，人工分析。确认间隔只有T/2和T两种，并且和发送数据对应。然后再写自动解码逻辑。

第四步，做压力测试。连续发送大量随机数据，统计误码率。如果误码率高于预期，检查信号质量和同步逻辑。

第五步，优化性能。如果速率要求高，把软件编码改成DMA加定时器，把软件解码改成DMA加边沿检测。如果MCU资源允许，可以用硬件SPI加异或门实现标准曼彻斯特编码。

最后分享一个小技巧：在调试曼彻斯特编解码时，我习惯在数据里插入一个已知的“指纹”序列，比如每帧数据末尾加“11001100”。接收端解码后检查指纹，如果指纹不对，说明这一帧解码有误，直接丢弃。这样能避免错误数据进入后续处理，提高系统的鲁棒性。这个技巧在无线通信和长线传输里特别有用，因为这两种场景误码率相对较高，指纹校验能挡掉大部分坏帧。