企业官网建设流程全解析

1. 项目概述

在嵌入式人机交互（HMI）领域，图形用户界面（GUI）和语音识别正成为提升用户体验的两大核心驱动力。前者提供了直观的视觉反馈，后者则带来了无需动手的自然交互方式。然而，将这两者无缝集成到资源受限的MCU平台上，并确保其稳定、高效地运行，一直是开发者面临的实际挑战。NXP推出的SLN-TLHMI-IOT开发套件，基于高性能的i.MX RT117H跨界MCU，为我们提供了一个绝佳的实验平台。它不仅仅是一块开发板，更是一个完整的“框架”（Framework）解决方案，旨在将机器视觉、语音识别和图形界面这三项计算密集型任务，整合到一颗芯片上协同处理。

我之前在多个工业HMI项目中尝试过集成语音功能，过程往往伴随着复杂的底层驱动适配、实时性调优以及GUI响应逻辑的纠缠。而NXP的这个框架，其价值在于它提供了一套标准化的架构，将摄像头、麦克风、显示、算法等硬件和功能模块抽象成统一的“设备”和“管理器”，并通过“消息/事件”机制进行通信。这相当于为开发者搭建好了舞台和后台管理系统，我们只需要专注于编写自己的“剧目”——也就是具体的应用逻辑。本次实践的目标，就是在这个成熟的框架之上，构建一个支持中英文语音指令的LVGL GUI应用。我们将从零开始，完成从硬件驱动添加、语音模型集成、输出UI适配到最终GUI应用开发的全过程，深入理解如何利用框架的“灵活性”和“易用性”来加速产品开发。

2. 开发环境与框架深度解析

2.1 软硬件环境搭建要点

工欲善其事，必先利其器。项目的成功复现，第一步在于搭建一个稳定、版本匹配的开发环境。硬件方面，核心是SLN-TLHMI-IOT开发板，它集成了i.MX RT117H双核处理器、MIPI摄像头、PDM麦克风阵列和LCD显示屏，是验证语音视觉融合应用的理想硬件。调试器需要使用SEGGER J-Link，并搭配9针Cortex-M适配器，确保能稳定连接RT117H的CM7核心。

软件环境的版本控制至关重要，不同版本间的API或库文件可能存在不兼容的情况。经过实测，以下组合是稳定可用的：

• IDE与工具链：MCUXpresso IDE V11.7.0。这是一个基于Eclipse的集成开发环境，对NXP MCU支持良好，内置了编译、调试和SDK管理工具。
• GUI设计工具：GUI Guider V1.6.1。这是NXP提供的LVGL可视化设计工具，通过拖拽组件即可生成GUI代码，极大提升了界面开发效率。
• 基础工程：lvgl_gui_camera_preview_cm7。这是NXP官方提供的一个示例工程，实现了在框架上运行LVGL并显示摄像头预览。我们将以此工程为蓝本进行改造。
• 底层SDK：RT1170 SDK V2.13.0。它提供了芯片所有外设的底层驱动、中间件和启动代码，是工程运行的基石。
• 框架源代码：SLN-TLHMI-IOT software V1.1.2。这是智能HMI解决方案的核心框架代码，托管在NXP的GitHub仓库。这里有一个关键操作：我们需要用从GitHub克隆的V1.1.2版本中的framework文件夹，替换掉基础工程里自带的框架文件。但要注意，inc\目录下的fwk_log.h和fwk_common.h文件已被应用笔记系列修改过，需要保留，不能覆盖。

注意：务必从NXP官网或指定的代码仓库（如MCUXpresso App Code Hub, GitHub）获取上述所有软件包。自行从其他渠道下载的版本可能会因配置差异导致编译或运行错误。安装完成后，建议首先按照《Getting Started with the SLN-TLHMI-IOT》文档，验证基础工程能否在开发板上正常编译、下载并运行摄像头预览功能，确保基础环境无误。

2.2 框架架构与设计哲学

在动手修改代码之前，深刻理解框架的设计思想是避免后续开发陷入混乱的关键。这个框架的核心目标是三个：易用性（Ease-of-use）、灵活性/可移植性（Flexibility/Portability）和性能（Performance）。它是如何实现这些目标的呢？

整个软件架构可以清晰地分为三层：硬件层、框架层和应用层。框架层是承上启下的核心，其内部运作机制围绕几个核心概念展开：

1. 设备管理器（Device Managers）：这是框架的“调度中心”。每种设备类型（如输入Input、输出Output、显示Display、算法Algo）都有其专属的管理器。管理器的职责是注册、初始化、启动所属的硬件抽象层（HAL）设备，并负责在不同设备间传递消息。例如，Input Manager管理着所有输入设备（如麦克风、按钮），Audio Manager管理音频处理流程。
2. 硬件抽象层设备（HAL Devices）：这是框架与具体硬件的“翻译官”。每个HAL设备（如hal_input_pdm_mic.c）封装了对底层硬件驱动（如PDM、I2C、SPI）的复杂操作，向上提供一套统一的、易于理解的API。当我们需要更换一个不同型号的麦克风时，理论上只需修改或替换对应的HAL设备实现，上层的应用和管理器代码几乎不用动，这体现了“可移植性”。
3. 消息/事件（Messages/Events）：这是框架内各组件通信的“血液”。它是一种异步通信机制。当一个事件发生时（例如，麦克风采集到一帧音频数据），对应的HAL设备会生成一个消息，发送给自己的管理器。管理器根据预定的规则，将这个消息转发给其他相关的管理器或HAL设备（例如，转发给Audio Manager进行前端处理）。这种松耦合的设计使得增加新功能或调整数据流变得非常灵活。

以本次的语音识别流程为例，在框架内的数据流是这样的：PDM麦克风HAL采集原始音频流，通过Input Manager发送给Audio Manager；Audio Manager调用Audio Processing AFE HAL，触发VoiceSeeker算法进行降噪、回声消除等预处理，得到“干净”的音频流；随后，干净音频流被送往Voice Algo Manager，由其决定调用DSMT ASR HAL或VIT ASR HAL，加载对应的语音识别模型进行推理；最终，识别出的文本指令结果被发送给Output Manager，并由Output UI HAL在GUI上做出相应的视觉反馈。

理解了这个数据流，我们在添加新功能时，就能清晰地知道应该在哪个环节插入代码，以及如何通过事件机制来驱动整个流程。

3. 语音识别功能在框架上的集成实战

3.1 语音识别架构与硬件支持添加

框架已经为我们定义了清晰的语音识别架构，如图2所示。我们的工作不是重新发明轮子，而是“填空”，将必要的驱动和算法库集成到这个架构中。首先从硬件驱动开始。

添加麦克风驱动：开发板上的麦克风通过PDM接口和DMA进行数据采集。我们需要从RT1170 SDK V2.13.0中复制相关的驱动文件到我们工程的drivers目录下。关键文件包括：

• fsl_pdm.[c/h]：PDM接口驱动。
• fsl_pdm_edma.[c/h]：使用EDMA（增强型DMA）进行PDM数据传输的驱动。
• fsl_edma.[c/h]和fsl_dmamux.[c/h]：EDMA及其多路复用器驱动。

复制完成后，需要在板级支持包中进行初始化：

1. 在pin_mux.c中，从参考工程（如coffee_machine）复制BOARD_InitMicPins()函数，并在BOARD_InitBootPins()中，通过宏定义ENABLE_INPUT_DEV_PdmMic来控制其调用。这完成了麦克风相关GPIO引脚的功能复用配置。
2. 在board.c中，复制BOARD_InitEDMA()函数，并添加必要的头文件包含（#include “fsl_edma.h”等）。这个函数用于初始化EDMA控制器，这是实现高效、低功耗音频数据搬运的关键。

实操心得：在复制这些底层驱动文件时，务必检查函数名和宏定义是否与当前工程已有的定义冲突。有时不同SDK版本或示例工程中的函数实现略有差异，直接复制可能导致链接错误。最稳妥的方法是先对比两个文件，只复制当前工程中缺失的必要代码段。

3.2 语音算法库与模型的集成与适配

这是集成工作的核心部分，涉及到静态库和模型资源的引入与修改。

第一步：添加算法库。智能HMI解决方案的远场语音识别功能，依赖于第三方提供的算法静态库。我们需要从coffee_machine示例中复制整个local_voice文件夹到我们工程的libs目录下。这个文件夹包含了：

• VoiceSeekerLight.lib：音频前端（AFE）处理库，负责语音增强、去噪等。
• VIT_CM7_v04_07_07.lib：用于VIT语音识别模型的推理库。
• sln_asr.lib：用于DSMT语音识别模型的推理库。
• arm_cortexM7lfdp_math.lib：ARM的CMSIS-DSP数学库，为算法提供优化的数学函数。

接下来需要在MCUXpresso IDE的工程属性中进行配置：

• 库文件路径：在Project > Properties > C/C++ Build > Settings > MCU C++ Linker > Libraries中，添加上述库文件名及其搜索路径（“${workspace_loc:/${ProjName}/libs/local_voice}”等）。
• 头文件路径：在MCU C Compiler > Includes和MCU C++ Compiler > Includes中，添加VIT库头文件所在的路径。

第二步：复制音频处理相关代码。将coffee_machine示例中的audio文件夹复制到工程根目录。这个文件夹包含了驱动AFE算法的头文件和公共工具函数。复制后，需要在工程视图中右键点击该文件夹，取消“Exclude resource from build”的勾选，并将其路径添加到编译器的包含路径中。

第三步：复制模型资源与引擎。将coffee_machine示例中的另一个local_voice文件夹（注意，与libs下的同名文件夹内容不同）复制到工程根目录。这个文件夹包含了DSMT模型的二进制资源文件（.bin）以及将语音识别结果转换为具体动作命令的“引擎”代码。同样需要取消排除构建并添加包含路径。

第四步：模型资源的定制化修改。这是将通用语音识别能力适配到我们特定应用的关键。原coffee_machine工程的模型识别的是“制作咖啡”、“加糖”等指令，我们需要将其改为我们设计的“注册”、“识别”、“预览”等指令。

1. 更新模型文件：
   • DSMT模型：使用第三方工具（如Sensory的TrulyHandsFree工具链）重新训练模型，生成包含我们自定义唤醒词（“Hey NXP”/“你好 恩智浦”）和命令词（“registration”, “recognition”, “preview”及其中文对应词）的.bin文件。用新生成的oob_demo_en_pack_WithMapID.bin（英文）和oob_demo_cn_pack_WithMapID.bin（中文）替换工程中对应文件。对于不支持的法语和德语模型文件，可以清空其内容以简化。
   • VIT模型：使用NXP在线VIT工具生成新的VIT_Model_en.h和VIT_Model_cn.h头文件，替换libs\local_voice\vit\RT1170_CortexM7\Lib目录下的旧文件。对于不支持的德语模型，可以在VIT_Model_de.h中将原数组定义注释掉，替换为一个空数组声明。
2. 修改命令索引与映射逻辑：这是代码修改的重点，集中在IndexCommands.h、IndexCommands_vit.h、IndexCommands_dsmt.h以及IndexToCommand_xx.h系列文件中。
   • 在IndexCommands.h中，将枚举类型_coffee_machine_action重命名为_voice_rec_demo_action，并重新定义动作类型，如kVoiceRecDemoActionReg、kVoiceRecDemoActionRec等。同时，将文件中所有出现的“COFFEE_MACHINE”和“coffee_machine”字符串替换为“VOICE_REC_DEMO”和“voice_rec_demo”。
   • 在IndexCommands_vit.h和IndexCommands_dsmt.h中，需要按照新的动作枚举，重新定义不同语言对应的动作映射数组action_voice_rec_demo_en[]和action_voice_rec_demo_cn[]。对于不支持的语言，数组可以只包含无效动作。
   • 在IndexToCommand_en.h和IndexToCommand_cn.h中，需要根据DSMT工具生成的词汇表（ww.txt和cmd_voice_rec_example.txt），重新定义唤醒词和命令词的字符串数组。例如，将英文唤醒词数组改为char *ww_en[] = {“Hey NXP”};。
3. 更新HAL层枚举：在hal_voice_algo_asr_local.h中，添加我们新应用对应的命令类型定义，如ASR_CMD_VOICE_REC_DEMO = (1U << 1U)，以便框架能正确路由到我们的处理逻辑。

注意事项：DSMT和VIT是两种不同的语音识别模型，它们不能在同一时刻被启用。我们需要通过工程中的宏定义（如ENABLE_DSMT_ASR或ENABLE_VIT_ASR）来切换使用哪一种。在修改代码时，要确保两种模型对应的配置文件（如IndexCommands_vit.h和IndexCommands_dsmt.h）都得到了同步更新，以保证无论启用哪种模型，语音指令都能被正确映射。

3.3 硬件抽象层（HAL）的配置与更新

框架的威力在于其HAL设计，我们需要对相关的HAL驱动进行使能和微调。

1. PDM麦克风HAL：文件hal_input_pdm_mic.c通常无需修改，只需在board_define.h中添加宏定义#define ENABLE_INPUT_DEV_PdmMic来启用它。
2. 音频处理AFE HAL：在hal_audio_processing_afe.c中，需要处理一个全局变量g_MQSPlaying。这个变量在音频播放相关的HAL中声明，但我们的示例不支持音频播放。因此，我们需要在条件编译中声明并初始化它，避免链接错误。同时，在board_define.h中定义AFE使用的内存区域（AT_NONCACHEABLE_SECTION_ALIGN_DTC）并添加启用宏#define ENABLE_AUDIO_PROCESSING_DEV_Afe。
3. 语音算法HAL：对于hal_voice_algo_dsmt_asr.c和hal_voice_algo_vit_asr.c，主要修改是让它们知道当前运行的是我们的新应用。在board_define.h中，通过#define ENABLE_VOICE_REC_DEMO和#define CURRENT_DEMO ASR_CMD_VOICE_REC_DEMO来设置。同时，在hal_voice_algo_asr_local.h中，将默认激活语言修改为仅支持中英文（#define DEFAULT_ACTIVE_LANGUAGE (ASR_ENGLISH | ASR_CHINESE)）。
4. 内存配置：语音识别算法需要较大的连续内存。我们需要在工程属性的MCU Settings中，调整SRAM_OC1的内存区域大小（例如扩大到0x100000），并将SRAM_OC2的空间合并或删除，以满足算法库的内存需求。同时，在board_define.h中通过AT_CACHEABLE_SECTION_ALIGN_OCRAM宏将算法相关缓冲区分配到这块内存中。

3.4 创建专属的输出UI HAL

这是连接语音识别结果与GUI应用的关键桥梁。原coffee_machine示例有一个复杂的hal_output_ui_coffee_machine.c，它处理咖啡制作、人脸识别、音频播放等多种逻辑。我们需要从中剥离出与语音和GUI相关的核心部分，创建一个精简的hal_output_ui_voice_rec.c。

主要改造步骤：

1. 克隆与重命名：复制原文件并重命名，然后将文件中所有的“CoffeeMachine”字符串替换为“VoiceRecDemo”。
2. 功能裁剪：删除所有与人脸识别（vision）、音频播放（prompt）以及咖啡机特定业务（如咖啡类型选择）相关的代码和头文件引用。我们的HAL只关心三件事：语音指令触发、识别结果处理、以及与GUI的会话管理（如待机屏超时返回）。
3. 更新语音命令枚举：定义我们自己的语音命令类型，如VOICE_CMD_REG、VOICE_CMD_REC、VOICE_CMD_PRE。
4. 重写结果处理函数：修改_InferComplete_Voice()函数。移除原咖啡机相关的case，添加对我们定义的三种语音命令的处理逻辑。在每个case中，调用一个来自GUI应用的API（例如gui_show_voice_rec_action()）来更新界面状态。
5. 简化UI回调：更新UI_EnterScreen_Callback()函数，只保留对kScreen_Home（主屏幕）和kScreen_Standby（待机屏幕）的处理。移除不需要的UI_Finished_Callback()函数。新增UI_GetLanguage_Callback()函数，用于向GUI应用报告当前系统识别的语言索引。
6. 声明GUI接口：添加#include “custom.h”，以使用GUI应用提供的函数，如get_current_screen()、gui_set_home()等。
7. 使能HAL：最后，在board_define.h中添加#define ENABLE_OUTPUT_DEV_UiVoiceRecDemo来启用这个新的UI输出设备。

实操心得：创建新的HAL驱动时，最好的方法是先通读一遍原始的、功能复杂的HAL文件，理解其函数调用关系和事件流。然后用注释标记出所有与我们目标功能相关的代码块，再将这些代码块小心地提取到新文件中。这个过程就像外科手术，务必确保不破坏原有的消息传递机制和回调函数接口。

3.5 显示HAL的微调

在基础示例中，摄像头预览是持续开启的。但在我们的设计中，待机屏幕不需要摄像头预览。因此，需要修改显示HAL驱动hal_display_lvgl_camerapreview.c中的HAL_DisplayDev_LVGLCameraPreview_Blit()函数。增加一个判断：如果当前屏幕是待机屏幕（kScreen_Standby），则跳过或停止摄像头数据的获取与渲染，以节省处理器资源和功耗。

4. LVGL GUI应用的设计与实现

4.1 GUI应用与框架的交互设计

GUI应用运行在框架之上，它与框架的交互是双向的，主要通过custom.c和custom.h这两个文件作为接口。理解这个交互模式至关重要：

• 框架 -> GUI：框架（具体是Output UI HAL）通过调用custom.c中实现的函数来驱动GUI变化。例如，当语音识别出“预览”命令后，Output UI HAL会调用gui_show_voice_rec_action(VOICE_CMD_PRE)，这个函数内部会操作LVGL控件，在状态标签上显示“previewing…”。
• GUI -> 框架：用户在GUI上的操作（如触摸按钮、选择语言）会触发LVGL事件。这些事件在event.c中处理，并调用custom.c中的函数，进而调用框架提供的API（如WakeUp()）来通知框架。例如，触摸待机屏幕会调用WakeUp(kWakeUpSource_Touch)，通知框架进入主屏幕。

我们的任务就是在custom.c中实现这两类接口函数，并在GUI Guider中配置事件响应。

4.2 多语言支持与界面逻辑实现

多语言实现：为了支持中英文切换，我们需要在custom.c中维护两套字符串资源。例如，可以定义二维数组s_HomeTitleStr[kLanguage_Ids][1]，其中kLanguage_Ids包含kLanguage_English和kLanguage_Chinese。然后实现gui_home_set_language_UI(lang_id)函数，根据传入的语言ID，遍历主屏幕上的所有文本控件（如标题、按钮标签、提示文字），并调用LVGL的lv_label_set_text()函数设置对应的语言字符串。

界面状态管理：我们需要实现几个核心的界面控制函数：

• gui_set_standby()：切换到待机屏幕。此函数应隐藏主屏幕，显示待机屏幕，初始化语言选择下拉框，并启动一个60秒的超时定时器（或通知框架启动）。超时后若无人操作，则自动返回待机屏。
• gui_set_home()：切换到主屏幕。显示摄像头预览、三个功能按钮和状态标签，同时刷新界面文本为当前语言。
• get_current_screen()：返回当前屏幕的枚举值，供Output UI HAL查询。

语音动作反馈：实现gui_show_voice_rec_action(action)函数。它根据传入的action（注册、识别、预览），更新主屏幕上的状态标签文字，并可以伴随简单的动画或颜色变化，给予用户明确的视觉反馈。

平台兼容性处理：一个棘手的问题是，UI_EnterScreen_Callback等函数是Output UI HAL的一部分，需要在嵌入式平台上运行。但同时，我们在GUI Guider的模拟器里设计界面时，也需要调用这些函数来测试交互逻辑。为了解决这个矛盾，我们在custom.c中使用条件编译#ifdef LV_USE_GUIDER_SIMULATOR。在模拟器环境下，实现一组简化的、不做实际硬件操作的桩函数；在嵌入式平台环境下，则包含真正的Output UI HAL头文件，调用实际的函数。我们需要将GUI Guider工程中的lv_conf.h文件复制到MCUXpresso工程的source目录，并将其中的LV_USE_GUIDER_SIMULATOR定义为0，以禁用模拟器模式。

4.3 使用GUI Guider进行界面设计与事件绑定

1. 创建GUI Guider工程：复制基础示例中的camera previewGUI工程文件夹，重命名为voice_rec。将我们修改好的custom.c和custom.h复制进去。
2. 界面设计：打开GUI Guider，设计两个屏幕：
   • 待机屏幕（Standby）：包含一个下拉列表（Dropdown List），选项为“English”和“中文”。可以添加一些提示性文字，如“请选择语言 / Please select language”。屏幕其他区域可设置为触摸唤醒区域。
   • 主屏幕（Home）：顶部显示标题“相机预览 / Camera preview”。中间区域为摄像头预览显示控件（lv_img）。下方放置三个按钮（Button），分别对应“用户注册 / Registration”、“人脸识别 / Recognition”和一个用于触发预览的隐形区域或按钮。底部有一个状态标签（Label），用于显示“等待指令…”、“识别中…”等提示信息。同样，在主屏幕上也放置一个语言选择下拉框。
3. 事件绑定：这是连接视觉设计与程序逻辑的关键。
   • 为待机屏幕的触摸区域（或整个屏幕）添加“Pressed”事件处理器，在其中调用WakeUp(kWakeUpSource_Touch)。
   • 为两个屏幕的下拉框添加“Value changed”事件，调用gui_standby_language_changed_cb()或gui_home_language_changed_cb()，并传入新的选项值。
   • 为主屏幕的三个按钮添加“Pressed”事件，分别调用gui_show_voice_rec_action()并传入对应的命令枚举值。
4. 代码生成与整合：在GUI Guider中完成设计后，点击生成代码。然后将生成文件夹（generated）中除了images子文件夹外的所有.c和.h文件，复制到MCUXpresso工程中替换原有文件。

4.4 图像资源的处理与打包

GUI中使用的图标（如NXP的Logo）需要被转换为C数组并打包成二进制资源文件，以便嵌入到固件中。基础示例提供了资源构建工具（resource_build文件夹）。

1. 复制resource_lvgl_gui_camera_preview文件夹和resource_build工具文件夹到新工程，并相应重命名。
2. 删除之前生成的文件resource_information_table.txt和camera_preview_resource.bin。
3. 将文件夹内所有文件（如.txt脚本）中的“camera_preview”字符串替换为“voice_rec”。
4. 从GUI Guider工程生成的images文件夹中，复制出我们实际使用的图像源文件（如_NxpVoiceRec_alpha_185x55.c），替换资源文件夹中的旧版图像文件。
5. 更新voice_rec_resource.txt文件，确保其中列出的图像文件名与实际文件一致。
6. 运行资源构建脚本（如voice_rec_resource_build.bat），生成新的voice_rec_resource.bin和resource_information_table.txt。由于我们只是替换了文件名，图像数据本身未变，所以无需更新工程中关于资源内存地址和大小的配置。

5. 系统集成、调试与问题排查

5.1 工程配置与编译

完成所有代码修改和资源准备后，在MCUXpresso IDE中进行最后的工程配置与编译：

1. 刷新索引：在Project Explorer中右键点击工程，选择“Index > Rebuild”，确保IDE能识别所有新添加的头文件和源文件。
2. 检查包含路径：再次确认所有新增文件夹（audio,local_voice,framework/hal/voice等）的路径都已正确添加到编译器的“Includes”设置中。
3. 检查库文件：确认链接器（Linker）的“Libraries”和“Library search path”设置正确，包含了所有必要的静态库（VoiceSeekerLight,VIT_CM7_v04_07_07,sln_asr,arm_cortexM7lfdp_math）。
4. 内存布局：确认SRAM_OC1区域已按前述要求扩大，并且链接器脚本（.ld文件）中没有冲突的区域定义。
5. 编译与链接：执行“Build Project”。首次编译可能会较慢。重点关注是否有“undefined reference”（未定义引用）或“multiple definition”（多重定义）错误，这通常是由于头文件包含错误、库文件缺失或函数重复定义导致。

5.2 典型问题与排查技巧

在实际部署和调试过程中，你可能会遇到以下典型问题：

5.3 调试与优化建议

• 善用日志系统：框架自带日志功能（FWK_LOG）。在关键函数入口、数据流转节点添加不同级别的日志（INFO,DEBUG,ERROR），是追踪程序流和定位问题最有效的手段。可以通过串口输出日志。
• 分段测试：不要试图一次性集成所有功能。建议的步骤是：1) 先确保原摄像头预览工程能在新环境下运行；2) 仅添加麦克风驱动和AFE库，测试能否采集到音频数据并看到AFE处理日志；3) 集成一种语音模型（如DSMT），测试唤醒词；4) 最后集成GUI和完整的交互逻辑。
• 性能关注点：语音识别和GUI渲染都是计算密集型任务。在RT117H上，可以将LVGL渲染、摄像头处理放在CM7核，而将语音识别算法放在CM4核上运行，以充分发挥双核性能。这需要对框架的任务分配进行更深入的配置，是后续优化的方向。
• 电源与噪声：在实际产品中，语音识别的准确度极度依赖麦克风的信号质量。确保PCB布局中麦克风电路远离噪声源（如DC-DC、数字信号线），并考虑在软件中启用AFE提供的各种滤波和降噪功能进行调优。

通过以上步骤，你应该能够成功在NXP i.MX RT117H框架上构建起一个支持中英文语音控制的LVGUI应用。这个过程虽然涉及环节较多，但框架的模块化设计使得每一步都清晰可控。最重要的是，一旦你掌握了这套方法，未来为这个平台添加其他传感器功能或设计更复杂的交互逻辑，都将变得有章可循。