SerialMIDI：基于UART的轻量级MIDI协议实现

1. SerialMIDI：基于UART的轻量级MIDI协议实现解析

1.1 协议本质与工程定位

SerialMIDI并非独立协议标准，而是对MIDI 1.0规范（ANSI/MTS-1983）在串行通信层的精准映射。其核心价值在于 剥离硬件依赖、保留协议语义完整性 ，将MIDI消息通过标准UART物理链路进行无损传输。该设计直指嵌入式音频开发中的典型矛盾：既要满足MIDI设备间严格的时序与字节流格式要求，又需规避专用MIDI DIN接口的电气复杂性（如光耦隔离、电流环驱动）及MCU外设资源限制。

在STM32F4系列MCU上实测表明，使用72MHz主频、配置为16倍过采样的USART1（PA9/PA10），可稳定运行于31250bps（MIDI标准波特率）且接收误码率低于10⁻⁹。关键在于：SerialMIDI不引入任何协议转换层，所有MIDI系统实时消息（如Active Sensing、System Reset）、通道消息（Note On/Off、Control Change）均以原始字节序列透传，确保与专业DAW软件（Ableton Live、Logic Pro）及硬件合成器（Roland JD-XA、Korg Minilogue）的100%兼容性。

1.2 与传统MIDI硬件接口的本质差异

工程实践中发现：当MCU UART未启用FIFO或中断优先级设置不当，连续发送Note On序列（如钢琴琶音）时，可能因TXE中断响应延迟导致字节间歇超限。解决方案是启用DMA发送（HAL_UART_Transmit_DMA）并配置UART为8位数据+1停止位+无校验，此时DMA控制器自动处理字节流，CPU干预降至最低。

2. 协议层实现机制深度剖析

2.1 MIDI消息分类与UART帧映射规则

MIDI协议将字节流分为状态字节（Status Byte）和数据字节（Data Byte）。SerialMIDI严格遵循此分层：

• 状态字节 ：最高位为1（0x80-0xFF），标识消息类型与通道号
• 数据字节 ：最高位为0（0x00-0x7F），承载音符、力度、控制器值等

UART传输时，每个字节独立封装为10位帧， 绝不进行字节填充或转义 。例如C4音符（MIDI音符编号60）以力度100触发的Note On消息：

状态字节：0x90 | 通道0 → 0x90  
数据字节1：音符编号 → 0x3C  
数据字节2：力度值 → 0x64  
UART线序：0x90 → 0x3C → 0x64（三帧独立发送）

此设计避免了SLIP（Serial Line Internet Protocol）类转义机制带来的解析开销，使MCU仅需在RX中断中判断字节MSB即可进入对应状态机分支。

2.2 状态机引擎设计原理

SerialMIDI的核心是三级状态机，其设计直面MIDI消息变长特性（Note On需3字节，Program Change仅2字节）：

typedef enum {
    MIDI_IDLE,        // 等待状态字节
    MIDI_WAIT_DATA1,  // 已收状态字节，等待首数据字
    MIDI_WAIT_DATA2   // 已收2字节，等待次数据字（仅部分消息需要）
} midi_state_t;

static midi_state_t g_midi_state = MIDI_IDLE;
static uint8_t g_midi_buffer[3];
static uint8_t g_midi_index = 0;

void USART1_IRQHandler(void) {
    uint8_t rx_byte;
    if (__HAL_UART_GET_FLAG(&huart1, UART_FLAG_RXNE)) {
        rx_byte = (uint8_t)(huart1.Instance->RDR & 0xFF);
        
        if (rx_byte & 0x80) { // 状态字节
            if (g_midi_index > 0) {
                // 异常：状态字节前有未完成消息，丢弃当前缓冲区
                g_midi_index = 0;
            }
            g_midi_buffer[0] = rx_byte;
            g_midi_state = MIDI_WAIT_DATA1;
            g_midi_