Code Migration Check - 代码迁移检查#

概述#

系统性地检查代码从一个嵌入式平台迁移到另一个平台时的兼容性问题。

迁移检查清单#

1. 编译器兼容性#

检查项说明数据类型int 大小、对齐方式字节序大端/小端编译器扩展****attribute, pragma内联汇编目标平台语法

2. 硬件抽象层#

检查项原平台目标平台状态GPIO 接口HAL_GPIO_xxxgpio_xxx⚠️SPI 接口HAL_SPI_xxxspi_xxx⚠️定时器HAL_TIM_xxxtimer_xxx⚠️中断NVICINTC⚠️

3. 外设差异#

• 寄存器地址不同
• 功能特性差异
• 时序参数差异

4. 系统特性#

• 启动流程
• 内存映射
• 低功耗模式
• 看门狗

迁移流程#

text

1. 分析原代码结构
      ↓
2. 识别平台相关代码
      ↓
3. 创建目标平台 HAL
      ↓
4. 逐模块迁移
      ↓
5. 编译验证
      ↓
6. 功能测试

风险评估#

风险级别定义处理🔴 高需要重写预留时间🟡 中需要适配正常处理🟢 低可直接复用简单验证

输出格式#

markdown

# 代码迁移检查报告

## 基本信息
- 源平台: STM32F103 (HAL)
- 目标平台: ESP32-S3 (ESP-IDF)
- 代码规模: ~10K 行

## 风险评估

### 高风险项 🔴
1. **SPI 驱动** - 需要重写
   - 原因: API 完全不同
   - 建议: 使用目标平台 SPI 驱动重新实现

### 中风险项 🟡
1. **定时器** - 需要适配
   - 差异: 定时器结构不同
   - 建议: 抽象定时器接口

### 低风险项 🟢
1. **业务逻辑** - 可直接复用
2. **数据结构** - 可直接复用

## 迁移建议
1. 先搭建目标平台框架
2. 实现 HAL 层适配
3. 逐模块迁移验证

## 工作量估算
- HAL 层适配: 3 人天
- 驱动迁移: 2 人天
- 测试验证: 2 人天
- 总计: 7 人天

与 Core Workflow 集成#

在 Act 阶段调用:

• 迁移项目的第一步
• 输出迁移计划用于 writing-plans