1.亿道信息丨手持终端PDA EM-R51：零售高效运营的码分得力助手
2.4步成功将三方库——speexdsp移植到OpenHarmony
3.OpenHarmony轻量设备Hi3861芯片开发板启动流程分析
4.v51.04 鸿蒙内核源码分析(ELF格式) | 应用程序入口并非main | 百篇博客分析OpenHarmony源码
5.OpenHarmony Camera源码分析
6.鸿蒙轻内核M核源码分析：中断Hwi

亿道信息丨手持终端PDA EM-R51：零售高效运营的得力助手

       亿道信息推出的PDA EM-R，专为零售行业设计，码分是码分零售高效运营的得力助手。它搭载了鸿蒙OpenHarmonyOS操作系统，码分同时支持Android、码分星光麒麟Starkylin、码分下载上传网站源码统信UOS以及Linux，码分运行速度快，码分性能稳定，码分操作简便。码分

       此外，码分PDA EM-R还配备了多样的码分通讯方式，如WiFi和蓝牙，码分提供便捷的码分连接体验。其大容量电池确保了持久的码分续航能力，而高防护等级则使其适应各种复杂苛刻的工作环境。内置GPS定位系统与自动对焦摄像头，助力零售业在日常运营中更加高效。

       具体优势如下：

       在零售行业中，PDA EM-R广泛应用于库存管理、商品盘点、订单处理、客户服务等多个环节。其强大的性能、稳定的运行和丰富的功能，能够显著提升工作效率、降低运营成本，并提升服务质量，从而实现高效运营和管理。

       技术参数方面，PDA EM-R的具体配置和功能将根据实际需求进行详细设计和调整，确保满足零售行业多样化的需求。亿道信息凭借其专业技术和严谨态度，致力于为客户提供优质、高效、可靠的解决方案，助力零售业迈向更高的发展水平。

4步成功将三方库——speexdsp移植到OpenHarmony

       四步实现三方库移植：

       第一步：三方库的下载与Linux下编译分析。下载最新分支代码，通过分析编译过程，确保正确构建动态链接库与测试用可执行文件。这一步通常涉及两种编译方式：一是手机赚钱接口源码通过CMakeLists.txt文件在原生库根目录中使用cmake或cmake-gui生成makefile，然后执行make；二是通过autogen.sh和configure.ac文件在原生库目录中构建，使用./autogen.sh和./configure生成Makefile，最后执行make和make install。在Linux环境下，需要配置编译环境，确保安装了cmake、make、automake等工具，并对编译过程进行深入分析。

       第二步：将三方库加入OpenHarmony的编译构建体系。定义子系统，将三方库放置在OpenHarmony源码的third_party目录下，并在ohos.build文件中配置子系统，将其添加到build/subsystem_config.json中。定义组件和目标模块，确保在gn文件中正确引用组件名，并将目标模块加入相应的组件。同时，产品引用中添加子系统及其组件，例如在vendor/hihope/rk/config.json中定义。

       第三步：增量编译动态链接库与可执行文件。在OpenHarmony源码中执行./build.sh命令，指定产品名称、ccache选项、目标编译库名称及目标CPU架构（如arm，适用于OHOS 3.2及以上版本）。根据编译结果调整gn文件，消除编译警告，并生成动态链接库与测试用的可执行文件，存放于out目录下。

       第四步：验证移植功能与API接口导出。将编译出的动态链接库与可执行文件部署到开发板上，并使用hdc_std工具验证三方库功能正常。对于API接口导出，需要在PC端生成包含所有对外导出头文件的allHeads.h文件、动态库放置在allDySos目录下、测试用的可执行文件存放于allTests目录中，并执行自动化测试脚本export_interface.sh以导出接口。

       总结：完成三方库移植需搭建OpenHarmony南向开发环境，具备开发板与hdc_std工具的使用能力。移植时需注意库与平台的多空带源码兼容性，确保不涉及对os_api、opensl、opengl依赖，不涉及硬件与驱动。遵循以上四步，三方库移植过程得以顺利实现。

OpenHarmony轻量设备Hi芯片开发板启动流程分析

       OpenHarmony作为一款覆盖从嵌入式实时物联网操作系统到移动操作系统的全面操作系统，其内核包括LiteOS-M、LiteOS-A和Linux。LiteOS-M是专为物联网领域设计的轻量级内核，适合没有MMU的处理器。例如，Hi是一款集成2.4GHz SoC WiFi芯片，具有高性能位微处理器、最大工作频率MHz、SRAM KB、ROM KB和2MB Flash。采用LiteOS-M的OpenHarmony开发板，如深开鸿、润和软件和小熊派等厂商的设备均采用相同的启动流程。

       Boot作为操作系统的启动软件，通常称为bootloader，Hi的Boot分为四个部分：RomBoot、FlashBoot、LoaderBoot和CommonBoot。RomBoot负责加载LoaderBoot到RAM，进一步利用LoaderBoot下载镜像到Flash、烧写EFUSE并校验引导FlashBoot。FlashBoot分为AB两面，A面校验成功直接启动，校验失败则尝试B面，B面校验成功会修复A面并引导启动，否则系统会复位重启。LoaderBoot主要负责下载镜像到Flash和烧写EFUSE，而CommonBoot则是FlashBoot与LoaderBoot共享的功能模块。

       在分析启动流程时，可以关注编译完成固件中的几个关键部分，如文本段包含源代码函数和字符串常量。通过map文件和asm文件，可以理解编译链接工具生成的全局符号、函数地址及其占用空间和位置。直播 源码 打包APP这些文件位于out目录，与操作系统固件平级，有助于分析崩溃原因和跳转关系。

       LiteOS-M启动流程从Boot开始，通过跳转调用到内核初始化函数LOS_KernelInit，主要负责内存、中断和任务初始化，为API函数调用准备全局信息。接着，OHOS_Main函数负责调用OpenHarmony系统相关和用户应用相关代码，确保在LOS_start之前任务列表已填充，以实现系统调度。

       用户应用的启动原理基于宏定义，展开后调用系统初始化函数。通过链接文件和map文件，可以发现应用代码位于特定的初始化段中。总结而言，最小硬件系统配置后，通过系统初始化、调用OpenHarmony和应用代码，最终启动操作系统。

       在没有源代码的情况下，通过对map文件和asm文件的分析，可以有效理解Hi芯片开发板LiteOS-M的启动流程。整个过程从最小硬件系统配置开始，由LOS_KernelInit初始化系统到合适状态，AppInit调用OpenHarmony和应用相关代码，最后由LOS_Start启动操作系统。

v. 鸿蒙内核源码分析(ELF格式) | 应用程序入口并非main | 百篇博客分析OpenHarmony源码

       鸿蒙内核源码分析(ELF格式篇) | 应用程序入口并非main

       深入解析ELF格式与鸿蒙源码的关系，探寻应用程序入口的奥秘。本文将带你从一段简单的C代码开始，跟踪其编译成ELF格式后的神秘结构，揭秘ELF的组成与内部运作机制。

       以E:\harmony\docker\case_code_目录下的main.c文件为例，通过编译生成ELF文件，运行后使用readelf -h命令查看应用程序头部信息。了解ELF文件的全貌，从ELF头信息、段信息、段区映射关系、区表等多方面深入探讨。壁虎数据恢复 源码

       ELF格式文件由四大部分组成：头信息、段信息、段区映射关系和区表。头信息包含关键元数据，如文件类型、字节顺序、文件大小等；段信息描述了可执行代码和数据段的属性和位置；段区映射关系展示了段与区的关联；区表则存储了每个区的详细信息。

       通过readelf -l命令，可以观察到段信息及其在程序中的作用，如初始化数组、动态链接、栈区等。在运行时，不同段以特定方式映射到内存中，实现代码的加载和执行。

       在深入分析后，发现应用程序的真正入口并非通常理解的main函数，而是一个名为_start的特殊函数。这揭示了鸿蒙内核在启动时的执行流程，以及如何在ELF格式中组织和加载代码。

       本文以ELF格式为切入点，带你全面理解鸿蒙内核源码的组织结构与运行机制。通过百万汉字注解，带你精读内核源码，深入挖掘其地基。在Gitee仓(gitee.com/weharmony/ker...)同步注解，共同探索鸿蒙研究站(weharmonyos)的奥秘。

OpenHarmony Camera源码分析

       当前，开源在科技进步和产业发展中扮演着越来越重要的角色，OpenAtom OpenHarmony（简称“OpenHarmony”）成为了开发者创新的温床，也为数字化产业的发展开辟了新天地。作为深开鸿团队的OS系统开发工程师，我长期致力于OpenHarmony框架层的研发，尤其是对OpenHarmony Camera模块的拍照、预览和录像功能深入研究。

       OpenHarmony Camera是多媒体子系统中的核心组件，它提供了相机的预览、拍照和录像等功能。本文将围绕这三个核心功能，对OpenHarmony Camera源码进行详细的分析。

       OpenHarmony相机子系统旨在支持相机业务的开发，为开发者提供了访问和操作相机硬件的接口，包括常见的预览、拍照和录像等功能。

       系统的主要组成部分包括会话管理、设备输入和数据输出。在会话管理中，负责对相机的采集生命周期、参数配置和输入输出进行管理。设备输入主要由相机提供，开发者可设置和获取输入参数，如闪光灯模式、缩放比例和对焦模式等。数据输出则根据不同的场景分为拍照输出、预览输出和录像输出，每个输出分别对应特定的类，上层应用据此创建。

       相机驱动框架模型在上层实现相机HDI接口，在下层管理相机硬件，如相机设备的枚举、能力查询、流的创建管理以及图像捕获等。

       OpenHarmony相机子系统包括三个主要功能模块：会话管理、设备输入和数据输出。会话管理模块负责配置输入和输出，以及控制会话的开始和结束。设备输入模块允许设置和获取输入参数，而数据输出模块则根据应用场景创建不同的输出类，如拍照、预览和录像。

       相关功能接口包括相机拍照、预览和录像。相机的主要应用场景涵盖了拍照、预览和录像等，本文将针对这三个场景进行流程分析。

       在分析过程中，我们将通过代码注释对关键步骤进行详细解析。以拍照为例，首先获取相机管理器实例，然后创建并配置采集会话，包括设置相机输入和创建消费者Surface以及监听事件，配置拍照输出，最后拍摄照片并释放资源。通过流程图和代码分析，我们深入理解了拍照功能的实现。

       对于预览功能，流程与拍照类似，但在创建预览输出时有特定步骤。开始预览同样涉及启动采集会话，并调用相关接口进行预览操作。

       录像功能则有其独特之处，在创建录像输出时，通过特定接口进行配置。启动录像后，调用相关方法开始录制，并在需要时停止录制。

       通过深入分析这三个功能模块，我们对OpenHarmony Camera源码有了全面的理解，为开发者提供了宝贵的参考和指导。

       本文旨在全面解析OpenHarmony Camera在预览、拍照和录像功能上的实现细节，希望能为开发者提供深入理解与实践的指导。对于感兴趣的技术爱好者和开发者，通过本文的分析，可以更深入地了解OpenHarmony Camera源码，从而在实际开发中应用这些知识。

鸿蒙轻内核M核源码分析：中断Hwi

       在鸿蒙轻内核源码分析系列中，本文将深入探讨中断模块，旨在帮助读者理解中断相关概念、鸿蒙轻内核中断模块的源代码实现。本文所涉及源码基于OpenHarmony LiteOS-M内核，读者可通过开源站点 gitee.com/openharmony/k... 获取。

       中断概念介绍

       中断机制允许CPU在特定事件发生时暂停当前执行的任务，转而处理该事件。这些事件通常由外部设备触发，通过中断信号通知CPU。中断涉及硬件设备、中断控制器和CPU三部分：设备产生中断信号；中断控制器接收信号并发出中断请求给CPU；CPU响应中断，执行中断处理程序。

       中断相关的硬件介绍

       硬件层面，中断源分为设备、中断控制器和CPU。设备产生中断信号；中断控制器接收并转发这些信号至CPU；CPU在接收到中断请求后，暂停当前任务，转而执行中断处理程序。

       中断相关的概念

       每个中断信号都附带中断号，用于识别中断源。中断优先级根据事件的重要性和紧迫性进行划分。当设备触发中断后，CPU中断当前任务，执行中断处理程序。中断处理程序由设备特定，且通常以中断向量表中的地址作为入口点。中断向量表按中断号排序，存储中断处理程序的地址。

       鸿蒙轻内核中断源代码

       中断相关的声明和定义

       在文件 kernel\arch\arm\cortex-m7\gcc\los_interrupt.c 中定义了结构体、全局变量和内联函数。关键变量 g_intCount 记录当前正在处理的中断数量，内联函数 HalIsIntActive() 用于检查是否正在处理中断。中断向量表在中断初始化过程中设置，用于映射中断号到相应的中断处理程序。

       中断初始化 HalHwiInit()

       系统启动时，在 kernel\src\los_init.c 中初始化中断。HalHwiInit() 函数在 kernel\arch\arm\cortex-m7\gcc\los_interrupt.c 中实现，负责设置中断向量表和优先级组，配置中断源，如系统中断和定时器中断。

       创建中断 HalHwiCreate()

       开发者可通过 HalHwiCreate() 函数注册中断处理程序，传入中断号、优先级和中断模式。函数内部验证参数，设置中断处理程序，最终通过调用 CMSIS 函数完成中断创建。

       删除中断 HalHwiDelete()

       中断删除操作通过 HalHwiDelete() 实现，接收中断号作为参数，调用 CMSIS 函数失能中断，设置默认中断处理程序，完成中断删除。

       中断处理执行入口程序

       默认的中断处理程序 HalHwiDefaultHandler() 仅用于打印中断号后进行死循环。HalInterrupt() 是中断处理执行入口程序的核心，它包含中断数量计数、中断号获取、中断前后的操作以及调用中断处理程序的逻辑。

       开关中断

       开关中断用于控制CPU是否响应外部中断。通过宏 LOS_IntLock() 关闭中断， LOS_IntRestore() 恢复中断状态， LOS_IntUnLock() 使能中断。这组宏对应汇编函数，使用寄存器 PRIMASK 控制中断状态。

       小结

       本文详细解析了鸿蒙轻内核中断模块的源代码，涵盖了中断概念、初始化、创建、删除以及开关操作。后续文章将带来更多深入技术分享。欢迎在 gitee.com/openharmony/k... 分享学习心得、提出问题或建议。关注、点赞、Star 和 Fork 到个人账户，便于获取更多资源。

鸿蒙轻内核M核的故障管家：Fault异常处理

       摘要：本文简要介绍了Fault异常类型、向量表及其代码，以及异常处理的C语言程序，随后详细分析了异常处理汇编函数的实现代码。

       本文内容来源于华为云社区《鸿蒙轻内核M核源码分析系列十八 Fault异常处理》，作者：zhushy。

       Fault异常处理模块与OpenHarmony LiteOS-M内核芯片架构紧密相关，它能够处理HardFault、MemManage、BusFault、UsageFault等故障异常。关于Cortex-M芯片的相关知识，不在本文的讨论范围内，读者可参考《Cortex™-M7 Devices Generic User Guide》等官方资料。本文所涉及的源码以OpenHarmony LiteOS-M内核为例，可在开源站点gitee.com/openharmony/k...获取。

       1、Fault Type异常类型

       Fault类型表格显示了各种故障及其处理机制、Bit Name标记、Fault status register故障状态寄存器。该表格摘自《Cortex™-M7 Devices Generic User Guide》。

       2、Vector table向量表

       向量表包含栈指针的复位值和开始地址，也称为异常向量。异常可以看作特殊的中断，本文主要关注NMI、HardFault、Memory management fault、Bus fault、Usage fault、SVCall等异常。

       在中断初始化时，会初始化该异常向量表，代码位于kernel\arch\arm\cortex-m7\gcc\los_interrupt.c。本文主要分析这些汇编函数的代码。

       3、HalExcHandleEntry异常处理C程序入口

       HalExcHandleEntry异常处理函数是汇编异常函数跳转到C语言程序的入口，定义在文件kernel\arch\arm\cortex-m7\gcc\los_interrupt.c，被kernel\arch\arm\cortex-m7\gcc\los_exc.S文件中的汇编函数调用。函数参数由汇编程序中的R0-R3寄存器传值进来。

       4、Los_Exc异常处理汇编函数

       上文介绍了Vector table向量表，已经提到了在文件kernel\arch\arm\cortex-m7\gcc\los_exc.S中定义的异常处理函数。当发生Fault故障异常时，会调度执行这些异常处理函数，本文会详细分析函数的源代码来掌握内核如何处理这些发生的异常。

       本文介绍了Fault异常类型、向量表及其代码，异常处理C语言程序，异常处理汇编函数实现代码。感谢阅读，如有任何问题、建议，都可以在博客下留言给我，谢谢。