1. 项目概述与核心价值
如果你正在为嵌入式设备开发USB Power Delivery（USB PD）功能，并且手头有一个基于NXP FRDM-KL27Z开发板和其早期USB PD中间件的成熟项目，那么当你想把项目升级到性能更强、资源更丰富的平台（比如FRDM-K64F）时，面临的第一个难题可能就是“如何迁移”。官方文档往往只给出骨架，真正的血肉——那些关键的配置细节、踩过的坑和验证过的步骤——需要你自己一点点摸索。我最近就完整走了一遍从FRDM-KL27Z到MCUXpresso SDK 2.2平台（以FRDM-K64F为例）的USB PD软件迁移，这个过程远不止是复制粘贴文件那么简单，它涉及硬件引脚的重映射、I2C外设的切换、中断处理的调整，乃至整个工程框架的适配。
这次迁移的核心价值在于，它不是一个简单的“换板子”实验。通过这个过程，你能深刻理解USB PD协议栈与硬件平台的解耦设计，掌握如何将一套成熟的电源管理逻辑灵活部署到不同的MCU上。无论是为了产品升级（从Cortex-M0+到Cortex-M4内核），还是为了评估不同平台的成本与性能，这套迁移方法论都具有很强的实践意义。接下来，我将以FRDM-K64F为目标平台，拆解从SDK准备、工程创建、代码移植到最终调试的完整流程，并分享其中容易出错的环节和我的解决思路。
2. 迁移前的核心思路与准备工作
在动手写代码之前，我们必须先理清迁移的本质和需要做的准备工作。原项目基于FRDM-KL27Z（MKL27Z644芯片）和其特定的USB PD软件包，而目标平台是FRDM-K64F（MK64FN1M0芯片）及MCUXpresso SDK 2.2。这两者之间的差异构成了我们所有工作的基础。
2.1 硬件差异分析与设计思路
首先，最直观的差异在于硬件连接。USB PD功能通常通过一个独立的Type-C端口控制器（TCPC，如PTN5110）实现，MCU作为端口管理器（TCPM）通过I2C总线与TCPC通信，并处理PD协议。在FRDM-KL27Z的参考设计中，TCPC板（USBPD-C-SHIELD）通过Arduino接口连接，关键信号线是固定的：
- I2C总线 (D14, D15)：用于主通信。
- 备用I2C总线 (A4, A5)：提供灵活性。
- 中断引脚 nALERT (D8)：TCPC通知MCU有事件发生。
- 电源使能引脚 EXTRA_EN_SRC (D4)：控制外部供电开关。
迁移时，我们的目标不是改变TCPC板的接线，而是让FRDM-K64F开发板上的GPIO去“模拟”FRDM-KL27Z上对应引脚的功能。因此，第一步就是对照两张开发板的原理图或引脚分配表，进行引脚映射。例如，FRDM-K64F的D14/D15可能对应完全不同的I2C模块实例和物理引脚（PTE24/PTE25，使用I2C0），而A4/A5可能对应另一组（PTC10/PTC11，使用I2C1）。这里的核心思路是“功能对应，而非引脚编号对应”。我们需要为FRDM-K64F建立一张自己的信号映射表，并据此重新配置引脚复用（Pin Mux）和驱动代码。
2.2 软件架构与SDK差异
在软件层面，NXP的USB PD协议栈以中间件（Middleware）形式提供，位于SDK的middleware/usb目录下。不同版本的SDK，其USB中间件版本可能不同（例如KL27Z的SDK可能包含usb_1.7.0，而K64F的SDK 2.2自带的是usb_1.6.3）。直接覆盖可能会因API微小变动导致编译错误。更稳妥的做法是以目标平台SDK为基础，仅移植必要的PD协议栈源文件，并仔细核对头文件兼容性。
此外，工程模板、启动文件、时钟配置、驱动库（如fsl_i2c.c和fsl_i2c_edma.c的区别）都因芯片而异。FreeRTOS的配置（FreeRTOSConfig.h）也需要根据新芯片的硬件特性（如系统时钟、优先级位数）进行调整。因此，迁移不是单个文件的搬家，而是一个系统工程，需要从构建系统、驱动层、中间件到应用层逐层适配。
2.3 工具链与开发环境确认
本次迁移主要涉及两种主流IDE：IAR Embedded Workbench和MCUXpresso IDE。虽然步骤相似，但工程文件格式（.ewwvs.project）、链接脚本、调试配置等截然不同。你需要提前确认：
- 已安装目标芯片（MK64FN1M0）的器件支持包。
- 已准备好基于MCUXpresso SDK 2.2 for FRDM-K64F的软件开发环境。
- 拥有FRDM-KL27Z USB PD软件包的完整源码（通常是一个独立的SDK附加包）。
实操心得：在开始前，我强烈建议在电脑上创建两个清晰的工作区目录，例如
WorkSpace_KL27Z_Source和WorkSpace_K64F_Target。将所有原始资料和目标SDK分别放置，避免文件混淆。同时，准备好开发板的原理图PDF和芯片参考手册，查询引脚和寄存器时会频繁用到。
3. 详细迁移步骤解析
有了清晰的思路和准备，我们就可以开始一步步实施迁移了。下面我将以IAR IDE为例，详细说明流程，MCUXpresso IDE的差异点会额外指出。
3.1 获取并准备基础SDK
迁移的基石是正确配置的SDK包。你需要为**源平台（FRDM-KL27Z）和目标平台（FRDM-K64F）**分别生成包含USB Stack和FreeRTOS组件的SDK。
步骤详解：
- 访问NXP官方MCUXpresso SDK构建器网站。
- 登录后，选择“新建配置”。
- 搜索并选择“FRDM-KL27Z”开发板。
- 在配置设置中，关键步骤是务必在“中间件”选项中勾选“USB Stack”和“FreeRTOS”。工具链根据你的IDE选择IAR或MCUXpresso。
- 提交构建并下载SDK包，解压到本地，例如
SDK_2.2.1_FRDM-KL27Z_USBPD。这个包里包含了USB PD的示例源码和中间件。 - 为FRDM-K64F重复步骤1-5，生成并下载
SDK_2.2_FRDM-K64F。这个包是我们移植的“地基”。
注意事项：在线构建SDK时，如果“Download Now”按钮不可用，需要点击“Request to Build”，等待系统处理（通常几分钟到半小时），完成后在“SDK Archive”页面下载。务必确保两个SDK的版本（如2.2.x）尽可能接近，以减少底层API变更带来的麻烦。
3.2 创建目标工程框架
我们不直接在原示例上修改，而是创建一个新的、干净的工程目录结构，这有利于版本管理。
- 在FRDM-K64F的SDK目录中，导航至
boards\frdmk64f\usb_examples。 - 新建一个文件夹，命名为
usb_pd（与你移植的示例名一致）。 - 进入
usb_pd，再新建一个freertos文件夹。 - 从
boards\frdmk64f\project_template复制工程模板文件：board.c,board.h,clock_config.c,clock_config.h,pin_mux.c,pin_mux.h。粘贴到刚创建的freertos文件夹中。这些文件提供了板级初始化的骨架。 - 从
rtos\freertos_9.0.0\template_application\ARM_CM4F复制FreeRTOSConfig.h到freertos文件夹。注意：FRDM-KL27Z是Cortex-M0+内核，模板在ARM_CM0目录；FRDM-K64F是Cortex-M4F内核，必须使用ARM_CM4F目录下的配置模板。 - 从
boards\frdmk64f\cmsis_driver_examples\i2c\interrupt_transfer复制RTE_Device.h到freertos文件夹。这个文件对CMSIS驱动配置很重要。
3.3 移植USB PD应用源码与中间件
这是移植的核心，需要将KL27Z的PD应用逻辑“嫁接”到K64F的工程框架上。
- 从已解压的FRDM-KL27Z USB PD SDK包中，找到
boards\frdmkl27z\usb_examples\usb_pd\freertos目录。 - 复制所有应用层源文件和头文件到K64F的
freertos目录。关键文件包括：main.c：应用入口。pd_app.c/.h,pd_app_demo.c：PD应用状态机和演示逻辑。pd_power_app.c,pd_power_interface.c/.h：电源管理接口。pd_command_app.c,pd_command_interface.c/.h：命令处理接口。usb_pd_config.h：PD协议栈配置文件。usb_io.h,usb_kinetis_io_drv.c,usb_pit_drv.c,usb_timer.h：硬件抽象层驱动。
- 移植中间件：这是容易出错的一步。不要简单地将整个
usb_1.7.0文件夹覆盖到K64F的SDK中。正确做法是： a. 从KL27Z SDK的middleware\usb_1.7.0目录下，复制pd文件夹（包含协议栈核心实现）。 b. 将复制的pd文件夹粘贴到K64F SDK的middleware\usb_1.6.3目录下。此时，usb_1.6.3目录下应同时包含原有的host,device等文件夹和新增的pd文件夹。c. 用KL27Z SDK中的middleware\usb_1.7.0\include\usb_misc.h文件，替换K64F SDK中middleware\usb_1.6.3\include目录下的同名文件。这个头文件通常包含了一些版本特定的类型定义或宏，直接替换可以避免编译错误。
3.4 使用MCUXpresso Config Tools配置引脚
硬件引脚的重映射是迁移成功的关键。手动修改pin_mux.c和pin_mux.h极易出错，强烈推荐使用NXP提供的图形化配置工具MCUXpresso Config Tools。
- 打开Config Tools，选择“使用现有SDK包开发”，并指向你的
SDK_2.2_FRDM-K64F根目录。 - 新建一个配置，可以基于“hello_world”示例克隆，命名为如
usbpd_k64。 - 打开Pins工具，开始根据表1：USB PD-C-SHIELD引脚映射表进行配置。以下是针对FRDM-K64F rev E的配置要点：
| Arduino 名称 | Shield 功能 | FRDM-K64F 引脚 | 配置要求 |
|---|---|---|---|
| D4 | EXTRA_EN_SRC | PTB23 | GPIO， 输出方向 |
| D8 | nALERT | PTC12 | GPIO， 输入方向， 使能上拉， 配置中断 |
| D14 | PTN5110_SDA | PTE25 | I2C0_SDA， 驱动强度可设为高 |
| D15 | PTN5110_SCL | PTE24 | I2C0_SCL， 驱动强度可设为高 |
| A4 | SDA (备用) | PTC11 | I2C1_SDA |
| A5 | SCL (备用) | PTC10 | I2C1_SCL |
| SW2 | 电源请求按钮 | PTC6 | GPIO， 输入， 使能上拉 |
| SW3 | 电源切换按钮 | PTA4 | GPIO， 输入， 使能上拉 |
- 在Pins工具中，逐一搜索上述引脚，将其功能（Mux）配置为表中要求的模式（GPIO或I2C）。
- 关键操作：为I2C引脚创建专用的初始化和反初始化函数。在“Routed Pins”标签页，点击“+”添加新函数，分别命名为
I2C0_InitPins和I2C0_DeinitPins。在I2C0_InitPins函数下，将PTE24和PTE25配置为I2C0_SCL和I2C0_SDA；在I2C0_DeinitPins函数下，将它们配置回GPIO模式。对于I2C1（A4/A5）也进行类似操作。这样设计是为了在I2C总线锁死时，可以通过GPIO模拟时钟信号进行总线恢复。 - 配置完成后，在Source标签页，将生成的
pin_mux.c和pin_mux.h导出，覆盖到我们之前创建的freertos目录中。
3.5 适配IAR工程文件（针对IAR IDE）
如果你使用IAR，需要手动创建或修改工程文件。
- 从
boards\frdmk64f\project_template\cproject_generator_templates\iar复制IAR工程模板文件到freertos\iar目录。 - 将所有模板文件中
$[project_name]替换为你的工程名，如usb_pd_freertos。 - 打开
.eww工作空间文件，同样进行全局替换。 - 在IAR中新建工作空间和工程，并参照KL27Z原工程的目录结构，在“Workspace”中创建对应的文件组（Group），如
board,drivers,freertos,sources,usb,utility等。 - 配置编译器路径和预定义宏：这是保证编译通过的核心。
- 包含路径：需要将原KL27Z工程中的包含路径列表复制过来，并将其中的所有
MKL27Z644替换为MK64F12，将ARM_CM0替换为ARM_CM4F。 - 预定义宏：在“Define symbols”中，必须添加针对MK64F12芯片的宏：
CPU_MK64FN1M0VLL12。同时，添加FreeRTOS相关的宏：USB_STACK_FREERTOS,FSL_RTOS_FREE_RTOS，并根据需要调整USB_STACK_FREERTOS_HEAP_SIZE的值（例如32768）。
- 包含路径：需要将原KL27Z工程中的包含路径列表复制过来，并将其中的所有
- 按照表3：FRDM-K64F源文件列表，将对应的源文件添加到工程相应的文件组中。务必注意驱动文件路径已变为
devices\MK64F12\drivers\。
3.6 关键源代码修改与适配
工程框架搭建好后，需要对从KL27Z复制过来的应用代码进行针对性修改，使其适应K64F的硬件。
修改硬件抽象层（HAL）：
- 打开
usb_io.h文件，添加K64F的端口枚举定义，因为原文件可能只定义了KL27Z的端口。// 在 usb_io.h 中添加 typedef enum _k64_ports { kPTA = 0, kPTB, kPTC, kPTD, kPTE } k64_ports;
- 打开
调整FreeRTOS配置：
- 修改
FreeRTOSConfig.h中的堆栈大小。K64F内存更大，可以适当增加。#define configTOTAL_HEAP_SIZE ((size_t)(32*1024)) // 例如调整为32KB #define configMAX_PRIORITIES (8) #define configUSE_TIME_SLICING (1) #define configTIMER_TASK_PRIORITY (configMAX_PRIORITIES - 1)
- 修改
修改中断与引脚控制代码：
- 在
main.c的HW_TimerInit函数中，将KL27Z的中断号PIT_IRQn改为K64F对应的PIT0_IRQn。 - 根据引脚映射表，修改
BOARD_I2C0_ReleaseBus和BOARD_I2C1_ReleaseBus函数内的具体GPIO操作。例如，对于K64F，操作I2C0（D14/D15）的引脚是PTE24和PTE25，需要将函数内所有关于端口和引脚的宏或数字进行修改。 - 修改电源使能函数
HW_GpioExternalSourceEnable，将其控制的引脚改为PTB23。 - 修改按键读取函数
HW_GpioReadPowerRequestSW和HW_GpioReadPRSwapSW，根据表2将引脚改为PTC6和PTA4。 - 在
HW_GpioInit函数中，根据新的引脚定义，重新初始化EXTRA_EN_SRC、两个按键SW2/SW3以及nALERT中断引脚。 - 修改中断服务函数（ISR）名称。例如，nALERT连接在PTC12，其端口中断应改为
PORTC_IRQHandler，并在函数内检查PTC12对应的位（第12位）。
- 在
更新板级支持定义：
- 从K64F SDK的其他示例（如
hello_world）的board.h中，复制BOARD_SW2_GPIO、BOARD_SW3_GPIO等按键相关的宏定义，粘贴到我们工程里的board.h中。 - 在
board.h中手动添加Arduino接口相关的IRQ和索引宏，供协议栈调用。#define BOARD_ARDUINO_INT_IRQ PORTC_IRQn // nALERT中断 #define BOARD_ARDUINO_I2C_IRQ I2C0_IRQn // 主I2C中断 #define BOARD_ARDUINO_I2C_INDEX 0 // 主I2C实例号
- 从K64F SDK的其他示例（如
全局替换应用层变量名：
- 由于KL27Z使用SW1作为电源请求键，而K64F映射为SW2，需要在
pd_app.h和pd_app_demo.c等文件中，将所有sw1State和sw1Time的变量名全局替换为sw2State和sw2Time。使用IDE的“查找与替换”功能可以高效完成。
- 由于KL27Z使用SW1作为电源请求键，而K64F映射为SW2，需要在
3.7 针对MCUXpresso IDE的额外步骤
如果使用MCUXpresso IDE，步骤3.5有所不同，更依赖于XML配置文件。
- 除了复制源文件，还需要复制KL27Z工程中的
example.xml和usb_pd_freertos.xml文件。 - 用文本编辑器打开这两个XML文件，进行全局替换：
- 将
FRDM-KL27Z,frdmkl27z替换为FRDM-K64F,frdmk64f。 - 将芯片型号
MKL27Z644替换为MK64F12。 - 将USB中间件版本号
1.7.0替换为1.6.3。 - 将内核相关定义
ARM_CM0替换为ARM_CM4F。 - 特别注意：将DMA驱动引用从
fsl_dma.和fsl_i2c_dma替换为K64F对应的fsl_edma.和fsl_i2c_edma。K64F使用增强型DMA（eDMA）。
- 将
- 修改SDK清单文件（
FRDM-K64F_manifest.xml）。将KL27Z清单文件中关于USB PD示例工程的部分（通常是一段XML代码块），复制并插入到K64F清单文件的相应位置（通常在<examples>节点内），并同样进行上述替换操作。这步是为了让MCUXpresso IDE的“导入SDK示例”功能能识别出我们移植的usb_pd工程。 - 在IDE中，通过“Quick Start Panel”的“Import SDK example(s)…”功能，选择
frdmk64f板卡，你应该能在usb_examples下看到usb_pd工程，导入即可。
4. 编译、调试与问题排查实录
完成所有代码修改后，就可以尝试编译了。这个过程很少能一次通过，以下是我遇到的一些典型问题及解决方法。
4.1 常见编译错误与解决
错误：未找到
fsl_dma.h或相关DMA函数- 问题根源：K64F使用eDMA，而非KL27Z的DMA。在驱动层和工程配置中未同步修改。
- 解决方案：
- 在工程中，移除
drivers组下原有的fsl_dma.c/.h文件。 - 添加
fsl_edma.c/.h和fsl_i2c_edma.c/.h文件。 - 在
pin_mux.c中，检查I2C初始化函数，确保其调用的是eDMA相关的驱动API（如果使用DMA传输）。更简单的方法是，在usb_pd_config.h或工程设置中，暂时先禁用DMA，使用中断模式进行I2C传输，待基本功能调通后再启用DMA优化。
- 在工程中，移除
错误：
PIT_IRQn未定义- 问题根源：芯片头文件中定时器中断枚举名不同。KL27Z可能为
PIT_IRQn，而K64F为PIT0_IRQn。 - 解决方案：打开芯片头文件（如
MK64F12.h）搜索PIT相关IRQn定义，确认正确的名称并修改main.c中的代码。
- 问题根源：芯片头文件中定时器中断枚举名不同。KL27Z可能为
错误：
PORTB_PORTC_PORTD_PORTE_IRQHandler未定义或链接错误- 问题根源：K64F的端口中断是分开的，PORTA、PORTB、PORTC等各有独立的中断向量，而KL27Z可能是合并的。
- 解决方案：根据nALERT引脚实际连接的端口（如PTC12），将中断处理函数名改为
PORTC_IRQHandler，并在pin_mux.h和启动文件中确保该中断已正确启用。
警告：函数声明隐式或类型不匹配
- 问题根源：头文件包含路径不正确，或不同SDK版本间API有细微变化。
- 解决方案：仔细核对IAR或MCUXpresso IDE中的包含路径设置，确保指向了正确的K64F SDK目录。对比
usb_misc.h等关键头文件，确保数据类型定义一致。
4.2 运行时问题与调试技巧
I2C通信失败，TCPC无响应
- 排查思路：这是最可能遇到的问题。
- 第一步：检查硬件。用万用表或示波器测量I2C（SCL， SDA）和nALERT引脚的电平，确保连接正确，上拉电阻正常（通常shield板已集成）。
- 第二步：检查引脚配置。使用调试器，在
I2C_Init函数后设置断点，查看pin_mux.c中生成的I2C0_InitPins函数是否被正确调用，以及PORT和GPIO的寄存器配置是否符合预期。确认SCL和SDA引脚已被正确复用为I2C功能，而非GPIO。 - 第三步：检查I2C初始化参数。确认I2C的时钟频率（波特率）设置是否合理（例如100kHz或400kHz）。K64F的系统时钟与KL27Z不同，I2C分频计算需要重新核对。
- 第四步：使用逻辑分析仪。这是最有效的工具。抓取I2C总线波形，看是否有起始信号、地址帧（PTN5110的I2C地址通常是0x51或0x28，需查手册）、ACK/NACK响应。如果总线一直为低，可能是总线锁死，此时
BOARD_I2C0_ReleaseBus函数就派上用场了，可以在初始化前调用它来“解锁”总线。
- 排查思路：这是最可能遇到的问题。
按键中断不触发
- 排查思路：
- 确认
pin_mux.c中按键引脚（PTC6， PTA4）已配置为上拉输入。 - 确认
board.h中的BOARD_SW2_IRQ等宏定义正确指向了PORTC_IRQn。 - 在
HW_GpioInit中，确认已调用EnableIRQ使能了对应的端口中断。 - 在中断服务函数中设置断点，并手动按下按键，看是否能进入中断。如果不能，检查引脚电平变化（按下是否为低电平），以及中断触发边沿设置是否正确。
- 确认
- 排查思路：
PD协议栈初始化失败，无法进入电源协商
- 排查思路：
- 确保
usb_pd_config.h中的配置（如定时器周期、任务优先级、堆栈大小）适合FreeRTOS和K64F的平台。 - 打开协议栈的调试输出（如果有的话），查看初始化流程在哪一步卡住。
- 检查
HW_GpioExternalSourceEnable函数是否正确控制PTB23，用示波器测量该引脚在使能时是否有跳变，以确认外部电源开关控制信号正常。
- 确保
- 排查思路：
实操心得：调试USB PD这类涉及硬件交互和复杂状态机的系统，分步验证至关重要。不要试图一次让整个系统跑通。我的建议是：
- 先裸机：注释掉所有FreeRTOS和PD协议栈的代码，先写一个简单的程序，仅测试I2C能否成功读取PTN5110的寄存器（如设备ID）。这能最直接地验证硬件连接和底层驱动是否正确。
- 再加RTOS：加入FreeRTOS，创建简单的任务，确保调度正常。
- 最后集成PD栈：将PD协议栈任务加入，并逐步测试按键中断、定时器、电源控制等各个模块。
- 善用调试器：不仅仅是设断点，更要观察外设寄存器（I2C状态寄存器、GPIO数据寄存器等）的值，这往往比打印日志更能直接定位问题。
5. 迁移后的验证与优化建议
当工程编译通过，并且基本功能（如I2C通信、按键响应）测试正常后，就可以连接USB PD-C-SHIELD和Type-C设备进行最终验证了。
功能验证：
- 将FRDM-K64F与USB PD-C-SHIELD连接好，通过USB线连接一个支持PD协议的设备（如手机、充电宝）。
- 打开串口调试助手，查看PD协议栈的打印信息（如果有）。你应该能看到CC检测、Source Capabilities广播、电压电流协商等过程。
- 操作板载按键SW2（电源请求）和SW3（电源角色切换），观察串口输出和设备反应（如充电状态变化）是否符合预期。
性能与稳定性优化：
- 调整任务优先级：USB PD协议栈对实时性有一定要求。确保其任务优先级高于非实时任务，但低于关键硬件中断。
- 优化堆栈大小：使用FreeRTOS的堆栈溢出检查功能，合理设置
pd_app_task等任务的堆栈大小，避免浪费内存或溢出。 - 启用DMA：如果I2C通信数据量较大或追求低CPU占用，可以重新配置并使用eDMA进行I2C传输。这需要仔细配置DMA描述符和中断，并测试其稳定性。
- 功耗考虑：如果设备是电池供电，在PD协商完成后，可以考虑让MCU进入低功耗模式，由PTN5110通过nALERT中断来唤醒MCU处理事件。
代码维护建议：
- 使用宏定义集中管理引脚：将所有的引脚定义（如
EXTRA_EN_SRC_PIN,NALERT_PIN,I2C0_SCL_PIN）集中到一个头文件（如board_pins.h）中。这样，未来如果更换硬件平台，只需修改这个文件即可。 - 为硬件抽象层（HAL）函数添加平台判断：可以对
usb_io.h和usb_kinetis_io_drv.c进行重构，使用#if defined(CPU_MK64FN1M0VLL12)这样的宏来区分不同平台的实现，提高代码的可移植性。 - 文档化你的修改：在代码的关键修改处添加清晰的注释，说明为何修改以及对应的硬件变更。这对于你未来回顾或团队协作至关重要。
- 使用宏定义集中管理引脚：将所有的引脚定义（如
这次从FRDM-KL27Z到MCUXpresso SDK 2.2平台的USB PD软件迁移，本质上是一次完整的嵌入式软件移植实践。它考验的不仅仅是对USB PD协议的理解，更是对MCU硬件差异、SDK框架、驱动开发和系统调试的综合把握。过程中最深的体会是，官方迁移指南提供了路线图，但填平路上的每一个坑，需要的是对细节的执着和对整个系统运行机制的透彻理解。希望这份详尽的记录，能帮你更顺畅地完成自己的平台迁移之旅。
