Hi3861 OpenHarmony开发实战：环境搭建与多线程编程

1. Hi3861 OpenHarmony 开发环境搭建与基础认知

1.1 Hi3861 开发板特性解析

Hi3861作为一款面向物联网领域的Wi-Fi SoC芯片，其核心优势在于低功耗与高集成度。这款芯片采用32位RISC-V架构，主频可达160MHz，内置352KB SRAM和2MB Flash，完全满足轻量级物联网设备的开发需求。在实际开发中，我发现其GPIO驱动能力值得特别注意——虽然标称支持最大20mA的驱动电流，但在实际点灯实验中，建议通过三极管或MOS管进行电流放大，避免直接驱动大功率LED导致芯片过热。

开发板上的IO口布局也有讲究：GPIO5~GPIO9这组引脚默认复用为SPI功能，若需用作普通GPIO，需要在代码中显式配置。我曾在项目初期踩过这个坑，调试了半天才发现引脚无响应是因为复用功能未正确解除。

1.2 OpenHarmony 轻量系统适配要点

OpenHarmony轻量系统（LiteOS-M内核）为Hi3861提供了完善的任务调度和驱动框架。与标准Linux环境不同，其线程模型更为精简，每个线程默认栈大小仅2KB，这在开发多线程应用时需要特别注意。通过实测，建议将涉及复杂操作的线程栈大小至少调整为4KB，可通过修改target_config.h中的LOSCFG_BASE_CORE_TSK_DEFAULT_STACK_SIZE配置项实现。

环境搭建时，官方推荐的Docker开发镜像确实能省去不少依赖问题，但我在实际使用中发现其内部工具链版本有时会与最新代码不兼容。更稳妥的做法是参照build.py脚本中的工具链要求，在Ubuntu 20.04 LTS环境下手动安装指定版本的gn、ninja等工具。

重要提示：当同时使用PWM和GPIO功能时，务必检查引脚复用冲突。例如GPIO2与PWM0共用引脚，启用其中任一功能都会导致另一功能失效。

2. 多线程编程实战与内存管理

2.1 LiteOS-M 线程创建与管理

OpenHarmony轻量系统提供了类似POSIX的线程接口，但底层实现差异显著。创建线程的标准做法是使用osThreadNew函数，其参数结构体需要特别注意优先级设置。系统默认提供0-31共32个优先级，数值越大优先级越高。但在实际项目中，我建议保留优先级0-5给系统关键任务，应用线程从优先级6开始分配。

c复制osThreadAttr_t thread_attr = {
    .name = "demo_thread",
    .stack_size = 4096,  // 建议不小于4KB
    .priority = osPriorityNormal,  // 对应优先级6
};

void thread_function(void *arg) {
    // 线程执行体
}

osThreadId_t thread_id = osThreadNew(thread_function, NULL, &thread_attr);

线程间通信的几种典型方式及其适用场景：

1. 事件（Event）：适合状态通知，消耗资源最少
2. 消息队列（Message Queue）：适合带数据的异步通信
3. 信号量（Semaphore）：适合资源计数和同步
4. 互斥锁（Mutex）：确保临界区资源独占访问

2.2 内存管理实战技巧

Hi3861的352KB SRAM看似充裕，但在多线程场景下仍需精细管理。通过实践总结出以下经验：

• 动态内存分配尽量使用malloc/free而非new/delete，因C++异常处理会额外消耗资源
• 频繁创建释放的小对象建议使用静态内存池
• 线程栈溢出是常见崩溃原因，可通过LOS_TaskInfoGet定期检查栈使用率

内存泄漏检测的一个实用技巧：在malloc/free处添加日志钩子，记录分配释放的地址和大小，形成内存操作流水账。当系统运行一段时间后内存不足时，通过对比分配和释放记录即可快速定位泄漏点。

3. 定时器开发与时间管理

3.1 硬件定时器精准控制

Hi3861内置4个通用硬件定时器（Timer），每个定时器支持独立配置。在PWM模式下的一个隐蔽特性：当同时启用多个PWM通道时，它们必须属于同一个定时器组。例如PWM0和PWM1可以同时使用（同属Timer0），但不能与PWM2（属Timer1）混用。

硬件定时器初始化代码示例：

c复制hi_u32 timer_id = 0; // 使用Timer0
hi_timer_attr_t attr = {
    .period = 1000000, // 周期1秒(单位微秒)
    .mode = HI_TIMER_MODE_PERIOD,
    .func = timer_callback,
    .arg = NULL
};
hi_timer_init(timer_id, &attr);
hi_timer_start(timer_id);

3.2 软件定时器应用场景

当硬件定时器资源紧张时，可以使用基于系统tick的软件定时器。需要注意的是，软件定时器的精度受系统tick影响（默认10ms一个tick），不适合高精度场景。创建软件定时器时应考虑以下参数优化：

c复制osTimerAttr_t timer_attr = {
    .name = "soft_timer",
    .attr_bits = 0,
    .cb_mem = NULL,
    .cb_size = 0,
};

osTimerId_t timer = osTimerNew(timer_callback, osTimerPeriodic, NULL, &timer_attr);
osTimerStart(timer, 100); // 100个tick(约1秒)

定时器使用中的常见陷阱：

1. 回调函数执行时间过长会导致后续触发延迟
2. 未及时停止定时器可能导致资源泄漏
3. 在定时器回调中调用阻塞API可能引发死锁

4. GPIO控制与外设驱动开发

4.1 数字IO口深度应用

Hi3861的GPIO驱动能力在不同电压下表现差异明显。当VDDIO为3.3V时，GPIO输出高电平实际约为2.8V，这在驱动某些对电压敏感的器件时需要特别注意。输入模式下的内部上拉电阻约50kΩ，在高速信号采集时建议外接更精确的上拉电阻。

GPIO配置的最佳实践：

c复制// 初始化GPIO5为输出模式
hi_io_set_func(HI_IO_NAME_GPIO_5, HI_IO_FUNC_GPIO_5_GPIO);
hi_gpio_set_dir(HI_GPIO_IDX_5, HI_GPIO_DIR_OUT);

// 设置GPIO6为输入带上拉
hi_io_set_pull(HI_IO_NAME_GPIO_6, HI_IO_PULL_UP);
hi_gpio_set_dir(HI_GPIO_IDX_6, HI_GPIO_DIR_IN);

// 读取GPIO状态
hi_u32 val;
hi_gpio_get_input_val(HI_GPIO_IDX_6, &val);

4.2 PWM输出精准控制

Hi3861的PWM输出在实际使用中需要注意占空比精度问题。虽然理论支持256级调节，但由于时钟分频限制，在某些频率下实际可用的占空比步进会变粗。通过实测发现，当PWM频率设置在1kHz以下时，可获得最佳线性度。

PWM初始化示例：

c复制hi_pwm_init(HI_PWM_PORT_PWMO);
hi_pwm_set_clock(PWM_CLK_160M); // 选择160MHz主时钟

hi_pwm_attr_t attr = {
    .duty = 50,      // 50%占空比
    .freq = 1000,    // 1kHz频率
    .polarity = 0    // 正常极性
};
hi_pwm_set_attr(HI_PWM_PORT_PWMO, &attr);
hi_pwm_start(HI_PWM_PORT_PWMO);

5. 外设集成与系统优化

5.1 传感器数据采集优化

在连接I2C传感器时，Hi3861的硬件I2C控制器有时会出现时钟拉伸问题。针对这种情况，我有两个解决方案：一是将I2C时钟频率从默认400kHz降至100kHz；二是改用软件模拟I2C，虽然效率降低但稳定性大幅提升。

ADC采集时的抗干扰技巧：

1. 在ADC输入引脚添加0.1uF滤波电容
2. 采样前先执行3次空转换丢弃不稳定数据
3. 对连续10次采样结果取中值滤波

5.2 低功耗设计要点

Hi3861在深度睡眠模式下电流可低至5μA，但唤醒源配置需要特别注意。GPIO唤醒只能使用特定引脚（GPIO0~GPIO5），且上升沿和下降沿触发需要硬件电路配合。在实际项目中，我通常采用RTC定时唤醒+GPIO紧急唤醒的双重设计。

电源管理API使用示例：

c复制// 配置GPIO5为唤醒源
hi_pm_set_wakeup_source(HI_PM_WAKEUP_SOURCE_GPIO, HI_GPIO_IDX_5, HI_PM_GPIO_WAKEUP_EDGE_RISING);

// 进入深度睡眠
hi_pm_reboot_config(HI_PM_REBOOT_TYPE_DEEP_SLEEP);
hi_pm_deepsleep(0); // 参数为保留字段

6. 调试技巧与性能优化

6.1 日志系统高效使用

虽然Hi3861支持printf输出，但在多线程环境下直接使用会导致输出混乱。建议通过hi_log.h提供的分级日志系统，配合LOG_LEVEL宏控制输出量级。一个实用技巧是在开发初期添加详细的函数入口/出口日志：

c复制#define DEBUG_FUNC_ENTRY() HI_LOG_DEBUG("[%s] entry\n", __FUNCTION__)
#define DEBUG_FUNC_EXIT() HI_LOG_DEBUG("[%s] exit\n", __FUNCTION__)

void critical_function(void) {
    DEBUG_FUNC_ENTRY();
    // 函数逻辑...
    DEBUG_FUNC_EXIT();
}

6.2 性能分析实战

使用Hi3861内置的CYCCNT计数器可以进行精确的代码性能分析。下面是一个测量代码段执行时间的实用宏：

c复制#include "hi_arm926.h"

#define MEASURE_TIME_START() \
    do { \
        hi_u32 _start = __hi_arm926_get_cycle_count()

#define MEASURE_TIME_END() \
        hi_u32 _end = __hi_arm926_get_cycle_count(); \
        HI_LOG_INFO("Execution time: %u cycles\n", _end - _start); \
    } while (0)

// 使用示例
void test_function(void) {
    MEASURE_TIME_START();
    // 被测代码...
    MEASURE_TIME_END();
}

通过这种测量方法，我发现频繁的GPIO状态切换（间隔小于10μs）会因为硬件响应延迟导致实际波形失真。最终通过预计算指令周期数，插入精确的nop延迟解决了这个问题。