STM32G431跑NES模拟器帧数翻倍？聊聊HAL库下LCD驱动与6502汇编优化的那些事

在嵌入式开发领域，将经典游戏机模拟器移植到资源有限的微控制器上一直是极具挑战性的任务。最近，不少开发者尝试在STM32G431上运行NES模拟器，但普遍遇到帧率不足的问题。本文将深入探讨如何通过底层优化，让模拟器性能实现质的飞跃。

1. 性能瓶颈分析与优化思路

当我们把NES模拟器移植到STM32G431这类Cortex-M4内核的微控制器上时，通常会遇到两个主要性能瓶颈：LCD驱动效率和CPU模拟效率。

基础实现的典型性能表现：

• 使用标准HAL库函数进行LCD写入：约72FPS
• 直接调用官方封装好的LCD写入函数：帧率波动较大
• 默认优化等级(-O0或-O1)：指令执行效率较低

通过实际测试发现，以下几个因素对性能影响最大：

1. LCD写入延迟：每次像素写入的配置开销
2. 内存访问模式：非连续访问导致的性能损失
3. 中断处理：不必要的上下文切换
4. 编译器优化：默认设置未能充分利用硬件特性

提示：在开始优化前，务必建立可靠的性能测量机制。可以使用定时器中断精确计算帧率，避免主观判断。

2. LCD驱动深度优化

2.1 传统LCD写入的问题

标准HAL库提供的LCD驱动函数通常设计为通用型，考虑了各种使用场景，但在连续写入大量像素时效率不高。主要问题包括：

• 每次写入前都要重新配置控制寄存器
• 使用软件延时确保信号稳定
• 未充分利用DMA或硬件加速功能

// 典型的基础实现画点函数
void LCD_DrawPoint(uint16_t x, uint16_t y, uint16_t color) {
    LCD_SetCursor(x, y);  // 设置位置
    LCD_WriteRAM_Prepare();  // 准备写入
    LCD->RAM = color;  // 写入颜色
    HAL_Delay(1);  // 短暂延时
}

2.2 优化后的连续写入方案

针对NES模拟器的特点（连续区域更新），我们可以实现专门的优化版本：

1. 减少控制指令：只在区域开始时配置一次
2. 消除冗余延时：利用硬件自动时序控制
3. 批量写入：使用内存指针连续操作

// 优化后的区域填充函数
void LCD_FillArea(uint16_t x, uint16_t y, uint16_t w, uint16_t h, uint16_t *colors) {
    LCD_SetWindow(x, y, x+w-1, y+h-1);  // 一次性设置整个区域
    LCD_WriteRAM_Prepare();  // 准备写入
    
    uint32_t pixelCount = w * h;
    while(pixelCount--) {
        LCD->RAM = *colors++;  // 连续写入
    }
}

性能对比：

优化项	基础实现	优化实现	提升幅度
单点写入时间	~2μs	-	-
区域写入时间	-	~0.3μs/像素	6-7倍
帧率(FPS)	72	114	58%

3. 6502 CPU模拟优化

3.1 基础实现的性能问题

NES使用的6502 CPU模拟通常通过解释器循环实现，在资源有限的MCU上会成为主要性能瓶颈：

• 每条指令需要多次内存访问
• 状态标志处理效率低
• 与宿主机的交互开销大

// 典型的解释器主循环
void execute6502Opcode(uint8_t opcode) {
    switch(opcode) {
        case 0xA9: // LDA immediate
            A = readMem(PC++);
            setNZFlags(A);
            break;
        case 0xAD: // LDA absolute
            A = readMem(readMem16(PC));
            PC += 2;
            setNZFlags(A);
            break;
        // ...更多指令处理
    }
}

3.2 关键优化技术

3.2.1 汇编级优化

将核心循环用汇编实现可以显著提升性能：

; 优化后的6502模拟片段
LDA_immediate:
    ldrb r0, [r1], #1    @ 读取立即数，PC自动递增
    ands r2, r0, #0x80   @ 设置N标志
    orreq r2, r2, #0x02  @ 设置Z标志
    bx lr

3.2.2 状态标志优化

传统实现中，每条指令后都更新标志寄存器效率极低。可以采用惰性计算：

// 标志位优化处理
uint8_t flags = 0;

#define N_FLAG 0x80
#define Z_FLAG 0x02

void setNZFlags(uint8_t value) {
    flags &= ~(N_FLAG | Z_FLAG);
    flags |= (value & N_FLAG);
    if(value == 0) flags |= Z_FLAG;
}

3.2.3 内存访问优化

6502的内存访问模式有很强的局部性，可以优化：

1. 使用内存访问缓存
2. 预取下一条指令
3. 特殊处理零页访问

优化前后对比：

指标	基础实现	优化实现
指令周期	~50时钟周期	~15时钟周期
帧率影响	主要瓶颈	降低30%负载
代码大小	较小	增加约20%

4. 系统级优化策略

4.1 编译器优化配置

正确的编译器选项可以带来显著提升：

# Makefile中的关键优化选项
CFLAGS = -mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=hard \
         -O3 -ffunction-sections -fdata-sections -flto

各优化等级效果：

优化等级	帧率(FPS)	代码大小	适合场景
-O0	62	最小	调试
-O1	85	较小	一般开发
-O2	105	中等	发布
-O3	114	较大	性能优先
-Os	98	最小	空间受限

4.2 中断与调度优化

1. 降低中断频率：合并相关中断
2. 优化ISR：使用寄存器变量
3. 优先级调整：确保关键任务优先

// 优化后的定时器中断配置
void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim) {
    if(htim->Instance == TIM6) {
        static uint32_t count = 0;
        if(++count >= 60) {
            fps = frameCount;
            frameCount = 0;
            count = 0;
        }
    }
}

4.3 内存布局优化

通过调整链接脚本确保关键代码在最快的内存区域：

MEMORY
{
  FLASH (rx)      : ORIGIN = 0x08000000, LENGTH = 128K
  RAM (xrw)       : ORIGIN = 0x20000000, LENGTH = 32K
  CCMRAM (xrw)    : ORIGIN = 0x10000000, LENGTH = 10K
}

SECTIONS
{
  .ccmram :
  {
    *(.ccmram)
    *(.ccmram*)
  } >CCMRAM
}

5. 实战案例：超级玛丽优化前后对比

以经典游戏《超级玛丽》为例，我们来看具体优化效果：

测试条件：

• STM32G431RBT6 @ 170MHz
• 2.4寸TFT LCD
• 优化等级-O3

性能数据：

场景	基础FPS	优化后FPS	提升幅度
标题画面	76	121	59%
游戏场景	68	112	65%
过场动画	72	118	64%

实际体验差异：

• 基础版：明显卡顿，音效断续
• 优化版：流畅运行，音画同步

在项目开发中，我们遇到一个有趣的现象：当马里奥进行跳跃动作时，基础实现的帧率会骤降。通过分析发现，这是因为跳跃时屏幕需要更新的精灵数量大幅增加。最终的解决方案是对PPU的精灵渲染逻辑进行了特定优化，使用预计算的位置信息减少了实时计算量。