2026 ADI CodeFusion 竞赛-基于 CFS 开发的 MAX32655 智能植物监护器

1. 项目介绍与完成题目

1.1 完成题目

所选任务：任务5——入门级题目2：智能植物监护器

随着家庭绿植、智能农业以及物联网技术的发展，通过电子设备对植物生长环境进行实时监测具有较强的实际应用价值。传统植物养护通常依赖人工观察和经验判断，例如通过观察土壤状态判断是否需要浇水，但这种方式难以持续、准确地掌握植物周围温度、空气湿度、光照以及土壤干湿状态的变化。

本项目按照“智能植物监护器”题目要求进行设计与实现，以 MAX32655FTHR 为核心控制平台，并使用 CodeFusion Studio™（CFS） 完成程序开发、工程构建、固件下载以及调试。

系统能够采集植物生长环境中的环境温度、空气湿度、环境光照以及土壤湿度相关模拟量。MAX32655 对各类传感器数据进行处理后，一方面通过 BLE 无线通信发送至 Android 移动端，实现实时监测；另一方面按照设定时间间隔将环境数据保存至外部 W25Q128 SPI Flash，使移动端能够进一步查询历史数据并观察环境参数随时间的变化。

本项目还针对实际使用需求设计了一块 MAX32655FTHR 专用扩展 PCB，将电源转换、电源保护、电源分配、主控连接以及传感器接口集中在同一硬件平台上，提高系统连接可靠性和后期扩展能力。

当前版本主要完成植物生长环境的感知、记录与无线监护，尚未实际安装水泵，因此自动浇水不属于当前已经实现的功能。但自研扩展板在设计过程中预留了多路供电和外设接口，后期可以增加 MOSFET、水泵驱动或继电器等模块，并结合土壤湿度阈值进一步扩展缺水提醒和自动浇水功能。

2. 系统总体方案与设计思路

2.1 系统总体方案

本系统以 MAX32655FTHR 为核心，由传感器采集模块、MAX32655 主控模块、自研扩展板、电源模块、BLE 无线通信模块、历史数据存储模块以及 Android 移动端组成。

传感器部分包括 AHT30 温湿度传感器、VEML7700 环境光传感器以及电容式土壤湿度传感器。其中，AHT30 用于获取环境温度和空气相对湿度；VEML7700 用于检测植物周围环境光照；电容式土壤湿度传感器输出与土壤干湿状态相关的模拟电压，并由 MAX32655 ADC 完成采样。

MAX32655 获取各类环境数据后进行解析和整理。对于实时监测数据，通过自定义 BLE GATT Service 发送至 Android APP；对于需要长期保存的数据，则按照设定周期写入 W25Q128 SPI Flash。移动端除了能够查看实时数据，还能够通过 BLE 向 MAX32655 发起历史数据查询，由 MAX32655 从 Flash 中读取指定时间范围的数据并返回移动端。

因此系统形成了两条主要数据链路：

实时链路：传感器 → MAX32655 → BLE → Android APP 实时显示

历史链路：传感器 → MAX32655 → W25Q128 → BLE 历史查询 → Android APP 历史数据显示

这种设计使系统不仅能够回答“植物当前环境如何”，还能够对一段时间内环境参数的变化进行回溯。程序中已经设计历史记录、BLE 历史查询和移动端历史数据显示功能。

2.2 设计思路

项目开发采用“先模块验证，再系统集成，最后硬件整合”的思路。

开发初期首先利用 MAX32655FTHR 和现成传感器模块进行功能验证，分别完成基础工程、BLE、AHT30、VEML7700 和 ADC 等功能的调试。每个模块独立工作正常后，再逐步整合到最终固件工程中。

随着传感器数量增加，使用杜邦线直接连接逐渐出现线路杂乱、连接可靠性较低、电源分配不统一等问题。因此在软件功能基本验证完成后，进一步设计专用扩展 PCB，将电源和接口集中管理。

最终形成从：

需求分析 → 器件选型 → 单模块驱动 → 多传感器联合采集 → BLE通信 → 历史数据存储 → Android APP → 原理图设计 → PCB Layout → 整机调试的一套较完整的嵌入式系统开发流程。

3. 系统硬件设计

3.1 MAX32655FTHR 主控开发板

本项目采用 MAX32655FTHR 作为系统核心控制平台。

MAX32655 负责整个系统的软件运行、外设管理、传感器数据采集、数据处理、历史记录以及 BLE 无线通信。本项目主要使用其 GPIO、I²C、ADC、SPI 和 BLE 等功能。

系统运行后，MAX32655 周期性完成环境数据采集，并根据不同数据的用途分别进行实时 BLE 发送和历史数据记录。

采用 MAX32655FTHR 开发板也便于前期快速开发。项目早期可以直接使用开发板连接传感器验证软件；自研扩展板制作完成后，则可将开发板直接连接到扩展板，在保留原有软件工程的基础上完成整机硬件集成。

3.2 AHT30 温湿度传感器

AHT30 用于检测植物周围的环境温度和空气相对湿度。

该传感器采用数字方式输出测量结果，并通过 I²C 与 MAX32655 进行通信。主控向传感器发送测量命令，待内部测量完成后读取原始数据，再按照传感器数据格式换算得到实际温度和相对湿度。

在植物监护应用中，环境温度和空气湿度能够反映植物所处的基本生长环境，因此也是系统持续监测的重要参数。

3.3 VEML7700 环境光传感器

VEML7700 用于检测植物周围环境的光照强度。

光照是影响植物生长的重要环境因素，因此本项目将其作为主要监测参数之一。完成传感器初始化及参数配置后，MAX32655 周期读取环境光测量结果，并将其转换为用于显示和记录的光照数据。

最终程序中 VEML7700 使用 GPIO 模拟 I²C 的方式与 MAX32655 通信，SCL 和 SDA 分别使用 P1.8 和 P1.9，引入 Soft-I²C 后可以更加灵活地协调现有工程中的引脚和外设配置。

3.4 电容式土壤湿度传感器

土壤湿度检测采用电容式土壤湿度传感器。

与 AHT30 和 VEML7700 的数字通信不同，该传感器输出与土壤状态相关的模拟电压信号。当探头周围土壤含水状态发生变化时，传感器输出电压也会随之发生变化。

传感器模拟输出接入 MAX32655 的 P2.0/AIN0，由 ADC 完成模数转换。程序能够获得 ADC Raw 数据并进一步计算相应模拟电压，为判断土壤干湿状态提供依据。

需要说明的是，当前系统已经完成土壤湿度相关模拟量的稳定采集，目前 APP 中出现的数百量级数值主要反映 ADC 原始采样量，而不是百分比湿度。设备只需要上传ADC数据，将主动权让渡给APP。

3.5 W25Q128 外部 Flash

为了实现历史环境数据的长期保存，系统使用 W25Q128 外部 SPI Flash 作为非易失数据存储器。

MAX32655 将周期采集的环境数据按照设定间隔写入 Flash。相比仅在 RAM 中保存数据，非易失 Flash 能够使历史记录在系统重新启动后继续保留。

固件采用环形方式管理历史记录，使有限的 Flash 空间能够循环使用，更适合植物环境监测设备持续运行的应用场景。

4. 自研扩展板设计

4.1 扩展板设计目的

项目早期可以通过 MAX32655FTHR 和杜邦线直接连接传感器完成软件验证，但随着传感器数量增加，临时连接逐渐出现线路杂乱、接触可靠性不足、电源管理不统一以及不便于长期运行等问题。

因此本项目进一步设计了一块针对 MAX32655FTHR 智能植物监护器的专用扩展 PCB。

扩展板主要承担统一供电、输入保护、电压转换、电源分配、主控连接、传感器连接以及后续功能扩展等任务，使系统从开发板实验进一步发展为较完整的硬件平台。

4.2 扩展板总体架构

根据最终设计，扩展板主要电源链路为：

8～24 V DC输入 → 输入保护 → XL4015E1 DC-DC降压 → 5V_MAIN → 3.3 V稳压 → 3V3_MAIN

5V_MAIN 和 3V3_MAIN 分别向主控、传感器以及外部扩展接口提供相应电源。

扩展板还设置了多路 I²C（双信号线）、ADC （单信号线）和外部供电接口，包括 3 路 I²C （双信号线）外设接口、3 路 ADC（单信号线，可自由选择对应电压） 外设接口、2 路 5 V 外部扩展供电接口以及 2 路 3.3 V 外部扩展供电接口。

4.3 输入电源及保护设计

扩展板采用较宽范围的直流电源输入，使系统能够适应不同外部供电条件。

外部电源进入系统后首先经过输入保护部分，再进入 DC-DC 降压模块。将保护电路设置在主要电源转换模块之前，可以降低外部异常供电对后级 MAX32655 和传感器造成影响的风险。

4.4 5 V 电源设计

扩展板采用 XL4015E1 作为主要 DC-DC 降压器件，将外部输入转换为系统内部的 5V_MAIN。

5V_MAIN 除用于后续 3.3 V 电源产生外，还可以为需要 5 V 的外部模块和后期扩展设备提供供电。

相较于完全依赖开发板本身的供电能力，独立设计主电源模块能够提高整个扩展系统的供电能力和扩展性。

4.5 3.3 V 电源设计

在 5V_MAIN 基础上进一步生成 3V3_MAIN，用于 MAX32655 相关接口和 3.3 V 外设供电。

由于传感器接口和主控数字接口对电源稳定性具有一定要求，因此在扩展板中将 5 V 和 3.3 V 电源进行统一管理，避免多个传感器分别从不同位置取电造成接线混乱。

4.6 分路电源管理

扩展板部分供电通道采用 MT9700-N 进行分路电源管理。

通过对不同外设供电支路进行管理，可以增强外部设备接入时的供电可控性和保护能力。同时，这种设计也为后续接入功耗更高的扩展设备提供了比单纯传感器接口更好的硬件基础。

4.7 I²C 与 ADC 接口

扩展板设计了多组 I²C 和 ADC 接口，以满足数字传感器和模拟传感器同时使用的需求。

I²C 接口适用于 AHT30 等数字传感器；ADC 接口则适用于电容式土壤湿度传感器等模拟输出设备。

统一接口后，传感器可以直接连接扩展板，减少临时杜邦线连接，使供电和信号路径更加清晰。

4.8 外部扩展接口

除当前植物监护器所需传感器外，扩展板还预留多路 5 V 和 3.3 V 外部供电接口。

这些接口可以用于后续增加其他传感器、指示设备或者控制模块，使扩展板不仅服务于当前版本，也具有一定二次开发能力。

4.9 PCB 布局设计

PCB Layout 过程中将电源模块、主控连接区域以及传感器接口进行相对独立的功能分区，并通过地平面等方式建立统一参考地。

接口位置尽量靠近 PCB 边缘，便于外部传感器连接；电源转换部分则集中布置，以减少大电流路径对低电平传感器信号的影响。

通过自研 PCB，系统从前期大量杜邦线连接转变为固定接口连接，提高了整体结构的整洁程度和连接可靠性。

4.10 自动浇水扩展能力

当前版本没有实现自动浇水。

但是扩展板已经具备相应的供电和外设扩展能力，后续可以增加：

MAX32655 GPIO → MOSFET/继电器或专用驱动模块 → 小型水泵的控制链路。

在完成土壤湿度标定后，还可以设置启动和停止两个不同阈值形成回差控制。当土壤过于干燥时开启水泵，达到较高湿度后停止，从而避免湿度值在单一阈值附近波动造成水泵频繁开关。

5. 软件系统设计

5.1 软件总体架构

本项目最终固件工程为 BLE_LED。该名称来源于项目早期 BLE 功能验证阶段，随着开发推进，在原有工程基础上逐步增加植物监护器所需的传感器驱动、ADC、BLE 自定义服务和历史数据功能，最终形成完整固件。

软件采用模块化设计。其中 main.c 主要负责系统初始化、BLE 协议栈运行以及周期任务调度；sensor_aht20.c 负责温湿度采集；sensor_light.c 负责光照传感器；sensor_soil.c 和 adc_driver.c 负责土壤模拟信号采集；sensor_svc.c 负责 BLE GATT 服务；历史记录相关模块则负责外部 Flash 数据管理。

模块化设计将传感器底层驱动与 BLE 应用逻辑进行分离，使各部分可以分别调试，也便于后续增加新的传感器或控制功能。

5.2 软件运行流程

系统启动后首先完成硬件和 BLE 协议栈初始化，随后进入事件驱动和周期任务运行状态。

传感器任务按照设定周期采集温度、空气湿度、土壤 ADC 和光照数据。当前固件中的实时传感器任务周期约为 500 ms。

如果手机已经建立 BLE 连接并订阅相应 Characteristic，则将最新数据通过 Notify 发送至移动端。同时，程序按照更长的历史记录周期将当前环境数据写入外部 Flash。

因此软件主流程可以概括为：

系统初始化 → BLE运行 → 周期采集 → 数据处理 → BLE实时发送 → 定期历史存储 → 等待下一事件

5.3 AHT30 非阻塞温湿度采集

温湿度传感器需要在发送测量命令后等待一定时间才能读取有效结果。

项目早期如果采用传统的：

发送命令 → 阻塞延时 → 读取结果

方式，单独测试传感器时能够正常工作，但 BLE 协议栈同时运行后，较长时间阻塞可能影响协议栈任务及时执行。

因此最终将温湿度测量拆分为两个阶段。

第一阶段只发送测量命令，然后立即返回，使 BLE 协议栈继续运行；随后通过 WSF Timer 设置定时事件，在约 90 ms 后执行第二阶段，再读取传感器转换完成的数据。

最终形成：

StartMeasurement → 返回 BLE 任务 → WSF Timer → ReadResult

的非阻塞工作方式。原稿也记录了这种设计是为避免长时间等待影响 BLE 运行。

int AHT20_Init(void)
{
    int ret;


    MXC_GPIO_SetConfigLock(MXC_GPIO_CONFIG_UNLOCKED);


    /* Bus recovery before switching pins to I2C2 alternate function */
    AHT20_BusRecovery();


    /* Initialize I2C2 as master at 100kHz */
    ret = MXC_I2C_Init(AHT20_I2C_INST, 1, 0);
    if (ret != E_NO_ERROR) {
        return ret;
    }
    MXC_I2C_SetFrequency(AHT20_I2C_INST, AHT20_I2C_FREQ);


    /* Set P0.30/P0.31 I/O rail (VDDIOH 3.3V or VDDIO 1.8V, per AHT20_I2C_3V3) */
    AHT20_SetPinsLevel();


    /* Send init command */
    const uint8_t cmd[] = {AHT20_CMD_INIT, 0x08, 0x00};
    if (AHT20_I2C_Write(cmd, sizeof(cmd)) != E_NO_ERROR) {
        return AHT20_ERR_WRITE;   /* write failed: no ACK from sensor */
    }
    MXC_Delay(MXC_DELAY_MSEC(20));
    return E_NO_ERROR;
}

5.4 VEML7700 与 Soft-I²C

VEML7700 最终没有直接增加另一组硬件 I²C，而是使用 P1.8/P1.9 通过 GPIO 实现 Software I²C。

Soft-I²C 模块实现 Start、Stop、ACK、字节发送、字节接收以及组合读写等基本操作，在此基础上完成 VEML7700 的寄存器访问和环境光数据读取。

底层 Soft-I²C 与上层 VEML7700 驱动分开，使光照传感器驱动只需要调用统一通信接口，而不直接处理 GPIO 时序，有利于软件结构清晰和后续维护。

/* Read 16-bit register (little-endian) */
static int veml_read_reg(uint8_t reg, uint16_t *val)
{
    uint8_t buf[2];
    int ret;


    /* Protect the bit-bang transaction from BLE interrupts, which would
       otherwise corrupt the timing and cause intermittent NACKs. */
    WsfCsEnter();
    ret = SoftI2C_WriteRead(&lightI2c, VEML7700_I2C_ADDR, &reg, 1, buf, 2);
    WsfCsExit();


    if (ret < 0) {
        return VEML7700_ERR_I2C;
    }
    *val = (uint16_t)(buf[0] | ((uint16_t)buf[1] << 8));
    return VEML7700_ERR_NONE;
}

5.5 土壤湿度 ADC 采集

电容式土壤湿度传感器模拟输出连接至 P2.0/AIN0。

ADC 调试过程中重点分析了 MAX32655 ADC 参考源、量程、SCALE 配置以及 Raw 数据与实际输入电压之间的关系，并结合已知电压进行验证。保留 ADC Raw 数据，将其作为反映土壤干湿变化的原始测量值，授权APP做状态判断。

5.6 BLE 数据通信

固件为植物环境数据建立自定义 BLE Sensor Service，通过不同 Characteristic 传输温度、空气湿度、土壤数据、光照以及历史记录相关数据。

当前工程中的主要 Characteristic 包括：

实时传感器数据主要采用 Notify 方式发送。只有设备已经建立 BLE 连接并且移动端完成相应订阅后，固件才发送数据，从而减少无效通信。

5.7 历史数据存储

除了实时监测外，本项目还实现历史环境数据记录。

MAX32655 按照设定时间间隔将温度、空气湿度、土壤相关数据和光照信息保存至 W25Q128 SPI Flash。

历史记录采用环形方式进行管理。当存储空间达到设计范围后，可以循环利用已有存储区域，使系统能够持续记录新的环境信息。

这一设计使植物监护器在手机暂时未连接的情况下仍可以独立保存环境数据，待移动端再次连接后查询之前的历史记录。

static int w25_platform_init(void)
{
    mxc_spi_pins_t spi_pins;
    mxc_gpio_cfg_t wp_hold;
    int err;


    /* GPIO 在 soc_init.c PinInit() 末尾会被锁定；必须先解锁才能配置
       SPI/引脚（与 AHT20_Init/SoftI2C 等驱动一致的自解锁约定）。
       否则 SPI 引脚配置静默失败 → W25 事务超时 → 阻塞 main() → BLE 广播不启动。 */
    MXC_GPIO_SetConfigLock(MXC_GPIO_CONFIG_UNLOCKED);


    /* WP(P0.8)/HOLD(P0.9) 必须拉高（Single SPI 模式要求） */
    wp_hold.port   = MXC_GPIO0;
    wp_hold.mask   = W25_WP_PIN | W25_HOLD_PIN;
    wp_hold.func   = MXC_GPIO_FUNC_OUT;
    wp_hold.pad    = MXC_GPIO_PAD_NONE;
    wp_hold.vssel  = MXC_GPIO_VSSEL_VDDIOH;
    wp_hold.drvstr = MXC_GPIO_DRVSTR_0;
    MXC_GPIO_Config(&wp_hold);
    MXC_GPIO_OutSet(MXC_GPIO0, W25_WP_PIN | W25_HOLD_PIN);


    /* SPI0：CLK(P0.7)/MISO(P0.6)/MOSI(P0.5) + SS1(P0.11)=W25 CS。
     * 不开 SS0(避免占用 P0.4)、不开 SS2/SDIO2/SDIO3。 */
    spi_pins.clock   = true;
    spi_pins.ss0     = false;
    spi_pins.ss1     = true;
    spi_pins.ss2     = false;
    spi_pins.miso    = true;
    spi_pins.mosi    = true;
    spi_pins.sdio2   = false;
    spi_pins.sdio3   = false;
    spi_pins.vddioh  = true;   /* SPI0 引脚在 VDDIOH(3.3V) 域 */


    err = MXC_SPI_Init(MXC_SPI0, 1, 1, 1, 0, EXT_FLASH_BAUD, spi_pins);
    if (err != E_NO_ERROR) {
        return err;
    }


    MXC_SPI_SetDataSize(MXC_SPI0, 8);
    MXC_SPI_SetMode(MXC_SPI0, SPI_MODE_0);
    return E_NO_ERROR;
}

5.8 BLE 历史数据查询

自定义 BLE 服务中设置了专门用于历史数据交互的控制和数据 Characteristic。

移动端可以向 MAX32655 发送时间同步和历史时间范围查询指令，MAX32655 根据请求从外部 Flash 中查找对应时间范围内的历史记录，再通过 BLE 将历史数据返回移动端。

其基本流程为：

APP发送查询 → MAX32655解析时间范围 → Flash读取记录 → BLE分批返回 → APP解析数据

从而使本地非易失存储与移动端数据查看形成完整闭环。

5.9 Android 移动端

本项目配套开发 PlantMonitorApp，用于通过 BLE 与 MAX32655 进行通信。

移动端建立连接后订阅对应 Characteristic，可以实时接收温度、空气湿度、土壤湿度相关 ADC 数据以及光照信息。

同时，移动端还能够发起历史数据查询，接收 MAX32655 返回的历史记录并用于历史数据查看。

因此整个系统已经形成：

传感器采集—本地处理—BLE实时传输—Flash历史保存—手机实时查看/历史回溯

的完整数据链路。

6. CodeFusion Studio 开发与系统调试

6.1 CodeFusion Studio 开发环境

本项目采用 CodeFusion Studio™（CFS） 作为 MAX32655 的主要软件开发与调试环境，并结合 MAX32655 MSDK 完成工程构建、程序编译、固件烧录以及在线调试。

开发并非直接从最终植物监护器程序开始，而是首先利用官方示例验证 MAX32655FTHR 的基础开发环境。

在确认编译工具链、调试器、程序下载以及开发板能够正常工作后，再逐步加入 BLE、传感器、ADC 和历史数据等功能。这种方式可以先建立一个已知正常的开发基线，降低后续故障定位难度。

6.2 BLE_LED 工程结构

最终固件保留 BLE_LED 作为工程名称。

随着功能增加，工程逐步形成多个独立模块，包括系统主程序、温湿度驱动、光照驱动、土壤传感器、ADC、Soft-I²C、BLE Sensor Service、历史数据存储以及外部 Flash 等部分。

相比将全部功能写在 main.c 中，这种模块化工程结构更加便于调试和维护。

6.3 CFS 工程构建

在 CFS 中完成代码修改后，对工程进行 Build，并根据 Build Console 判断编译状态。

MAX32655 工程不仅包含应用层 C 代码，还涉及 MSDK、Makefile、芯片和开发板配置以及 Cordio BLE 协议栈，因此出现编译错误时不能只检查应用程序。

开发过程中逐渐形成以下处理流程：

修改代码 → Build → 查看第一个有效 Error → 定位源文件或工程配置 → 修改 → 重新 Build → 生成 ELF → 下载运行

尤其当编译器一次输出大量错误时，应优先处理最前面的有效错误。某一个头文件或宏定义问题可能产生大量后续连锁错误，从最后一条错误开始排查往往效率较低。

6.4 程序烧录与在线调试

工程编译成功后生成可执行固件，并通过 MAX32655FTHR 调试接口进行程序下载和运行。

调试过程中综合使用：

CFS在线调试 + 程序断点 + UART串口日志 + BLE手机端数据

判断系统状态。

例如程序无法正常启动时，可通过调试器判断是否进入 main()；传感器无数据时检查驱动初始化和 UART 日志；BLE 异常时分别验证广播、连接、Service、Characteristic 和 Notify 状态。

6.5 官方示例基线验证

当自己的工程出现问题而无法快速确定是程序、开发板还是工具链故障时，本项目采用重新运行 MAX32655 MSDK 官方基础示例的方法进行判断。

如果官方 Hello_World 等示例能够正常完成：

编译 → 烧录 → 运行 → UART输出

则说明开发板、调试器以及基本 CFS/MSDK 工具链工作正常，故障范围可以进一步缩小到自己的工程。

这种“先恢复已知正常状态，再继续排查”的方法在后续调试中提高了问题定位效率。

6.6 系统集成调试

项目采用逐级集成方式，而不是一次性将所有功能加入工程。

整体调试过程为：

基础 GPIO/UART → BLE → 单个传感器 → 多传感器 → ADC → BLE实时数据 → 历史数据 → Android APP → 扩展板整机

每加入一个模块都先验证其独立功能，再继续进行下一阶段集成。

这种方法能够在问题出现时快速确定新增模块是否与现有功能产生冲突，也降低了 BLE、传感器、ADC 和 Flash 等多个功能同时运行时的调试复杂度。

7. 系统测试与功能验证

7.1 整机运行

完成固件和扩展板调试后，将 MAX32655FTHR、扩展板以及各类传感器组合成完整的智能植物监护系统。

系统上电后，扩展板完成电压转换并向主控和传感器供电。MAX32655 初始化完成后开始周期采集环境数据，并根据 BLE 连接状态向移动端发送实时数据。

同时，系统按照历史记录周期将环境数据保存至外部 Flash，实现实时监测与历史记录并行运行。

7.2 温湿度测试

AHT30 工作后能够持续获得环境温度和空气相对湿度。

测试时通过改变传感器周围环境状态，观察采集数据是否产生相应变化，并通过 UART 和手机端数据进行对照，从而验证从 I²C 采集到 BLE 显示的完整数据链路。

7.3 光照测试

VEML7700 光照检测可以通过遮挡传感器或改变照射条件进行验证。

当环境光照发生明显变化时，MAX32655 获取的光照数据也应产生对应变化，并进一步通过 BLE 更新至移动端。

该测试同时能够验证 GPIO Soft-I²C、VEML7700 驱动以及 BLE 数据发送是否正常工作。

7.4 土壤湿度模拟量测试

土壤传感器通过 ADC 进行采集。

测试过程中可将探头置于不同干湿环境，观察 ADC Raw 数据及相应输入电压是否发生变化。

当前测试重点是验证传感器能够反映土壤状态变化，而不是直接验证百分比含水率。后续完成实际干湿标定后，再将 Raw 数据映射为 0～100% 的相对湿度。

7.5 BLE 实时数据测试

手机与 MAX32655 建立 BLE 连接后，对相应 Characteristic 进行订阅。

MAX32655 周期发送最新环境数据，移动端接收并更新显示。

通过该测试验证：

传感器 → MAX32655 → 数据处理 → BLE GATT → Android APP

整条实时数据链路能够正常工作。

7.6 历史数据测试

历史数据功能测试主要包括 Flash 数据写入和 BLE 历史查询两个部分。

系统持续运行后，MAX32655 按照设定时间间隔写入历史记录。移动端随后发起指定时间范围查询，MAX32655 从 Flash 中检索相应记录并通过历史数据 Characteristic 返回。

该功能验证了系统在实时监测之外还具有环境数据长期记录和回溯能力。

7.7 Android APP 联调

移动端与 MAX32655 联调过程中，需要依次验证 BLE 扫描、建立连接、发现 Service、订阅 Characteristic、实时数据接收以及历史数据查询等功能。

实时数据显示能够反映当前环境状态；历史数据功能则用于观察环境参数在一段时间内的变化。

因此 APP 不仅承担数据显示功能，也是验证整个 BLE 通信协议和历史查询机制的重要组成部分。

7.8 实物演示

7.9 功能测试结果

最终报告中的功能测试可以按照实际测试情况填写：

8. 开发过程中遇到的难点及解决方法

8.1 CFS 工程编译时间过长

项目开发过程中曾出现工程重新编译耗时明显过长的问题，影响程序修改和验证效率。

排查工程配置后发现，project.mk 中存在额外的 GCC 中间文件输出相关参数，使编译过程中产生大量不必要文件。

通过删除不需要的 GCC dump 参数并重新整理工程构建配置后，编译时间明显下降。

这个问题使我认识到，当嵌入式工程构建异常缓慢时，除了代码规模，还需要检查编译参数、Makefile 和整个构建系统。

8.2 Windows Make/Shell 兼容问题

MAX32655 MSDK 工程使用 Makefile 进行构建，而 Windows 环境下不同 Shell 工具的执行方式存在差异。

开发过程中曾遇到 xPack 环境中的 sh.exe 与 MSDK Makefile Windows 分支之间的兼容问题。

实际调试中通过调整 Shell 执行方式，例如使用：

make SHELL=cmd

使工程按照正确的 Windows 命令环境进行构建。

这个问题也使我进一步认识到，CFS 图形界面背后仍然包含完整的编译器、Make、SDK 和构建脚本，工程问题不能只从 C 源代码层面分析。

8.3 编译符号未定义

开发过程中曾遇到 E_NO_ERROR 等符号未定义问题。

经过定位发现，这类错误并非应用程序逻辑错误，而是对应 MAX32655 SDK 定义所在的头文件没有正确包含。

根据 CFS 编译信息定位符号来源并补充相应头文件，例如：

#include <mxc_device.h>

即可解决相应编译错误。

由此也形成了一个实际调试经验：当出现大量连锁编译错误时，应首先解决编译器输出中的第一个有效错误。

8.4 BLE 能扫描但无法建立连接

BLE 开发过程中曾出现手机能够扫描到 MAX32655 广播，但无法正常建立连接的情况。

能够扫描到设备说明基础 BLE 广播已经运行，因此故障不能简单归结为 BLE 完全没有启动。

进一步检查 Cordio BLE 工程配置后，发现 Peripheral 角色相关编译配置需要正确启用。通过补充相应配置，例如：

-DINIT_PERIPHERAL=1

重新编译和烧录后继续进行连接测试。

这个问题使后续 BLE 调试形成了更加完整的验证顺序：

广播 → 扫描 → 建立连接 → Service发现 → Characteristic发现 → CCCD订阅 → Notify数据传输

而不再仅以“手机能扫描到设备”作为 BLE 正常工作的判断依据。

8.5 UART 串口无输出

UART 是项目调试过程中非常重要的日志输出工具，但开发阶段曾出现程序烧录后串口没有预期输出的问题。

最初从波特率、UART 初始化和 USB 串口等方面进行排查，随后进一步发现问题与 MAX32655 GPIO 初始化状态有关。

通过重新检查 soc_init.c 中 PinInit() 以及 GPIO 初始化顺序，通过CFS配置在 UART 初始化前正确处理相关 GPIO 状态，使 UART 引脚能够重新配置到对应复用功能，最终恢复串口输出。

恢复 UART 后，其又成为后续 I²C、ADC、BLE 和传感器调试的重要手段。

8.6 AHT30 阻塞读取影响 BLE 稳定性

项目早期单独调试温湿度传感器时，可以在发送测量命令后直接延时等待转换完成。

但与 BLE 协议栈整合后发现，较长时间的阻塞等待可能影响协议栈事件及时处理，工程调试过程中曾出现与 BLE supervision timeout 相关的连接异常。

最终将 AHT 测量过程拆分为“启动测量”和“读取结果”两个阶段，并使用 WSF Timer 在转换完成后触发读取。

这样在传感器等待测量的几十毫秒期间，CPU 不需要停留在阻塞延时中，BLE 协议栈仍可以继续运行。

这个问题使我认识到，在带无线协议栈的嵌入式系统中，一个传感器能够独立运行，并不意味着其阻塞式驱动适合直接加入完整系统。

8.7 I²C 通信异常与 Bus Recovery

多个传感器与 BLE 同时运行后，I²C 通信稳定性也成为系统长期运行需要考虑的问题。

如果某次通信过程异常，从设备可能没有按照预期释放 SDA，使后续 I²C 操作继续失败。

因此温湿度驱动中加入 I²C Bus Recovery。当检测到总线状态异常时，通过释放 SDA 并产生若干 SCL 时钟，使可能处于异常通信状态的从设备释放总线，再恢复正常 I²C 工作。

对于部分瞬时通信错误还增加了必要的重试机制。

最终从最初的“默认每次通信一定成功”，改进为：

错误检测 → 总线恢复 → 必要时重试 → 恢复通信

提高了系统长期运行的容错能力。

8.8 VEML7700 与现有外设配置协调

VEML7700 调试过程中，需要同时考虑 MAX32655 引脚复用、已有工程配置以及其他外设资源。

最终没有强行增加另一套硬件 I²C，而是在 P1.8/P1.9 上使用 GPIO 实现 Soft-I²C，并将底层通信独立封装。

VEML7700 驱动只负责寄存器配置和数据读取，不直接处理 GPIO 时序。

这种方式既解决了实际引脚配置问题，也使软件层次更加清晰。

8.9 MAX32655 ADC 量程与传感器匹配

ADC 是本项目调试过程中另一个比较典型的问题。

项目初期对 MAX32655 ADC 的参考电压、REF_SEL、REF_SCALE、SCALE 和 Raw 数据对应的实际输入电压进行了多次测试。

如果简单按照普通 MCU 使用经验直接将 ADC 满量程理解为固定的 3.3 V，就可能导致程序换算结果与实际电压不一致。

因此最终采用：

数据手册分析 → ADC配置 → 已知输入电压 → Raw采样 → 万用表实测对比

的方式进行闭环验证，并根据土壤传感器约 0～2 V 的模拟输出选择合适的 ADC 配置。

目前能够稳定获得土壤传感器 ADC Raw 数据，但若需要进一步显示为 0～100% 的“土壤湿度”，还需要针对实际传感器和土壤环境进行干湿标定，而不能直接将 ADC Raw 值作为百分比。

8.10 多模块集成问题

AHT30、VEML7700、ADC 和 BLE 分别测试时相对容易判断是否正常，但所有功能加入同一工程后，会出现外设资源、程序时序以及协议栈调度之间的相互影响。

因此开发过程中没有一次性加入全部模块，而是采用：

GPIO/UART → BLE → 单个传感器 → 多传感器 → ADC → BLE实时数据 → Flash历史数据 → APP

的逐级集成方式。

每增加一个功能先进行独立验证，再进行整体运行测试，从而降低故障定位难度。

9. 项目总结与心得体会

9.1 项目成果总结

本项目以任务5“入门级题目2：智能植物监护器”为目标，基于 MAX32655FTHR 和 CodeFusion Studio 完成了一套植物生长环境监测系统。

系统能够采集环境温度、空气湿度、环境光照以及土壤湿度相关模拟量，并通过 BLE 将实时数据发送至 Android 移动端。同时增加 W25Q128 历史数据存储功能，使移动端能够进一步查询一段时间内的环境记录。

硬件方面，项目从最初 MAX32655FTHR 配合传感器模块和杜邦线验证，进一步发展为自主设计专用扩展 PCB。扩展板集成直流输入、电源保护、DC-DC 转换、3.3 V电源、多路传感器接口和外部扩展接口，提高了系统连接可靠性，也为后期增加其他传感器和控制设备提供硬件基础。

软件方面，项目逐步完成传感器驱动、ADC、BLE 自定义服务、历史数据记录以及移动端通信等功能，并针对 BLE 和传感器并行运行过程中的阻塞、I²C异常和 ADC量程等问题进行了相应优化。

9.2 开发心得

本次项目开发过程中，我对 MAX32655 的认识从最初运行开发板示例程序，逐渐深入到 GPIO、I²C、ADC、SPI、BLE 协议栈以及多模块协同运行等方面。

实际开发中发现，能够让一个传感器单独输出正确数据只是第一步。当多个传感器、ADC、Flash 和 BLE 同时运行后，还需要考虑引脚复用、电压域、通信异常、程序执行时序以及无线协议栈调度等问题。

例如，温湿度传感器最初采用阻塞式等待虽然能够正常获得数据，但加入 BLE 后会影响协议栈运行，因此最终利用定时事件将测量过程拆分；ADC 调试也经历了从直接读取 Raw 数据，到重新理解参考源、SCALE 和实际输入范围，再通过万用表实测验证的过程。

这些问题使我认识到，实际嵌入式系统开发不是简单地将多个 Demo 代码组合在一起，而需要从硬件接口、软件架构、通信时序和系统可靠性等多个方面进行整体考虑。

9.3 对 CodeFusion Studio 使用的体会

通过本项目，我逐渐熟悉了 CodeFusion Studio 下 MAX32655 工程的建立、构建、下载和调试流程，同时对 CFS、MSDK、Makefile、编译工具链以及调试器之间的关系有了更加具体的认识。

项目开发过程中，CFS 的 Build Console、在线调试和工程管理功能为定位编译问题和程序运行问题提供了较大帮助。

同时也认识到，在嵌入式开发中不能只依赖图形界面。当出现构建异常时，还需要理解 project.mk、Makefile、编译宏以及 SDK 头文件之间的关系；当自己的工程出现复杂问题时，重新运行官方示例建立“已知正常基线”也是非常有效的调试方法。

经过本项目实践，我形成了“先验证官方示例—再建立最小功能—逐个增加模块—每一步保持可运行—最后完成系统集成”的开发思路，相比一次性加入大量功能，这种方式更容易定位问题。

9.4 当前不足与后续改进

当前系统已经完成主要植物环境参数采集、BLE 实时通信以及历史数据记录，但仍有进一步完善空间。

当前版本没有实现自动浇水。后续可以利用扩展板预留的供电和外设接口增加 MOSFET 或其他水泵驱动模块，并采用具有回差的湿度阈值控制策略，实现自动灌溉。

此外，还可以进一步研究 MAX32655 的低功耗工作模式，降低长期监测时的系统功耗；也可以增加更多环境传感器或者外部联网模块，使系统由近距离 BLE 植物监护进一步扩展为具有远程数据访问能力的植物环境监测平台。

9.5 对本次活动的体会与建议

通过本次活动，我完整经历了从需求分析、器件选型、传感器驱动、BLE 通信，到原理图设计、PCB Layout、软件开发、移动端通信以及系统联合调试的开发过程。

相比单独完成某一个传感器实验，本项目更加重视不同软硬件模块之间的配合，也使我对嵌入式系统工程化开发有了更加完整的认识。

在活动过程中，基于实际题目完成项目的方式能够促使开发者主动学习芯片外设、SDK、无线通信和硬件设计，而不仅停留在运行官方 Demo 的阶段。尤其是在遇到真实工程问题并逐步排查解决后，对 MAX32655 和 CodeFusion Studio 的使用理解更加深入。

总体而言，本项目已经实现了从环境感知、数据处理、无线传输、本地历史记录到移动端查看的完整植物监护数据链路，并完成了配套扩展 PCB 设计。后续在现有软硬件平台基础上继续完善土壤湿度标定、缺水提醒、低功耗以及自动浇水等功能，可以进一步提高系统的实用性和完整性。