示例应用程序 - Qualcomm Dragonwing Documentation

使用这些示例应用程序，从可正常工作的 MCU 环境过渡到实际的接口、事件和电源管理流程。您可以一次验证一项能力，确认预期行为，并将这些模式复用为您自己应用逻辑的起点。这种方法可以帮助您降低启动风险、及早隔离问题，并在添加更复杂的功能之前建立信心。 3.1 运行 UART 日志应用程序 启动一条低风险的控制台或服务路径，以便在转向更复杂的流程之前验证镜像执行、中断传递和基本的驱动程序初始化。 先决条件 ■ UART 路径或环回设置。 ■ 在项目配置中启用日志和串口支持。 ■ 已针对所选串行引擎验证中断路由步骤

启用串行路径和日志后端。
初始化所需的串行引擎并确认驱动程序正确绑定。
启动 MCU 镜像并注册 UART 回调或服务例程。
发送一个已知的小字符串，或等待一条预期的启动消息。
如果该路径是中断驱动的，请验证接收就绪或发送完成行为。

预期结果。 您会看到稳定的控制台输出或环回活动，并且基本的事件驱动 UART 路径保持稳定。 相关测试源代码 您可以使用位于 core/buses/v2/uart/test/uart_zephyr_test.c 的测试源代码作为起点。 代码示例

static void uart_user_cb(const struct device *dev,
 struct uart_event *evt,
 void *user_data)
{
 switch (evt->type) {
 case UART_RX_RDY:
 /* Consume bytes or wake a worker. */
 break;
 case UART_TX_DONE:
 case UART_RX_DISABLED:
 case UART_RX_BUF_REQUEST:
 default:
 break;
 }
}

3.2 运行 Inter-Integrated Circuit 传感器读取应用程序 通过 I2C 从已知传感器寄存器读取一个或多个字节，以验证真实的外设路径。 先决条件 ■ 具有稳定地址和一个可安全读取的寄存器的 I2C 设备。 ■ 已启用 I2C 子系统。 ■ 所选 QUP 串行引擎的时钟和电源依赖项可通过平台 API 获得。步骤

确认传感器地址、目标寄存器和总线实例。
初始化 I2C 实例并验证驱动程序正确绑定。
声明 QUP 路径所需的平台投票或依赖项。
使用原生 I2C 写-读流程执行寄存器读取，并捕获返回的字节。
传输完成后释放临时投票或依赖项，并重复读取。

预期结果 传感器寄存器读取完成，没有超时或总线错误，并且在重复读取时响应保持稳定。 相关测试源代码 您可以使用位于 core/buses/v2/i2c/test/i2c_zephyr_test.c 的测试源代码作为起点。 代码示例

int sensor_reg_read(const struct i2c_dt_spec *bus,
 uint8_t reg,
 uint8_t *buf,
 size_t len)
{
 int ret;
 vote_clock(CLK_QUPx, ON);
 vote_vdd_cx(ON);
 ret = i2c_write_read_dt(bus, &reg, 1, buf, len);
 drop_vote(CLK_QUPx);
 drop_vote(VDD_CX);
 return ret;
}

3.3 运行 GPIO 中断和唤醒应用程序 通过中断注册、ISR 交接和唤醒处理，验证来自外部信号线的离散事件处理。 先决条件 ■ 一条已布线的 GPIO 线，可产生受控的边沿或电平事件。 ■ 已确认外部信号线的中断路由。 ■ 在 ISR 进入后已准备好接收事件的工作线程或回调。步骤

为目标信号线配置方向、上下拉、极性以及边沿或电平行为。
注册中断处理程序，并将 GPIO 事件映射到 MCU 中断路径。
如果该事件同时也是唤醒源，请在进入等待路径之前对其正确分类。
触发外部事件并观察 ISR 进入和交接。
在活动模式和有效的等待或低功耗进入路径中分别重复该事件。

预期结果 MCU 可靠地处理该事件，并且在平台允许的情况下，同一条 GPIO 线可以被验证为具有唤醒能力的事件源。 3.4 运行低功耗模式和唤醒应用程序 验证低功耗进入、唤醒源处理和恢复行为，以便确认 MCU 保留或恢复了您预期的状态。 先决条件 ■ 至少一条已知可用的协议路径，例如 UART 或 I2C。 ■ 一个有效的唤醒源，例如 QTIMER、GPIO、UART 接收活动或传感器中断。 ■ 可用的日志、跟踪或调试状态捕获步骤

从一条已知良好的协议或应用路径开始。
设置一个有效的唤醒源，并确认系统能够识别它。
强制满足目标电源状态所需的平台策略规定的空闲或负载条件。
进入目标低功耗状态，并捕获已达到预期状态的证据。
触发唤醒事件，并确认唤醒发生且活动路径恢复

预期结果。 MCU 进入预期的低功耗状态，通过所选的唤醒源被唤醒，恢复预期的执行路径，并在恢复后保持接口行为稳定。 3.5 运行常开监控应用程序 将事件驱动的 MCU 模型转变为实用的监控循环，等待定时器或传感器事件，在本地对其进行判定，并仅在策略要求时才向主机上报。 先决条件 ■ 稳定的定时器或传感器事件源。 ■ 一条日志路径。 ■ 明确的策略，规定应用程序何时应忽略、记录、处理或上报事件步骤

创建一个小型事件驱动循环，等待定时器、中断或其他平台信号。
在事件到达时捕获所需的最少数据。
应用本地决策逻辑或阈值。
如果该事件需要处理，请执行本地工作，或向主机上报简明的信号。
返回等待路径，并确认可重复的长时间运行行为

预期结果 MCU 在事件驱动循环中保持响应，将后台工作留在本地，并将主机唤醒活动限制在仅符合策略的情况。 3.6 通过 QUP 和 GPI 运行高吞吐量数据传输 验证可选的传输路径，该路径使用 QUP 作为协议控制器，使用 GPI 作为面向突发或较高吞吐量流量的基于描述符或环的数据搬运引擎。 先决条件 ■ 在引入 GPI 之前，同一串行引擎已有经过验证的基本协议路径。 ■ 已分配环或描述符资源，并在软件中定义了其所有权模型。 ■ 完成、超时和错误中断已路由到 MCU。步骤

为目标协议和模式初始化 QUP 串行引擎。
在流量开始之前初始化 GPI 通道并配置环或描述符资源。
编程完成、阈值、超时和错误中断。
排入一个具有代表性的传输，并监控描述符所有权、完成情况和状态变化。
完成后，验证载荷正确性和环的正常行为。

预期结果 MCU 以更低的内核参与度完成传输，并且在正常完成和受控错误测试之后，环或描述符状态保持一致。 代码示例

int mcu_bus_stack_init(struct qup_ctx *ctx)
{
 vote_clock(ctx->clk_id, ON);
 vote_vdd_cx(ON);
 qup_reset(ctx->se_id);
 gpi_channel_init(ctx->tx_chan);
 gpi_channel_init(ctx->rx_chan);
 gpi_ring_config(ctx->tx_chan, ctx->tx_ring_base, ctx->tx_ring_size);
 gpi_ring_config(ctx->rx_chan, ctx->rx_ring_base, ctx->rx_ring_size);
 qup_enable_irqs(ctx->se_id,
 IRQ_XFER_DONE | IRQ_ERROR | IRQ_TIMEOUT);
 return 0;
}