1.疯壳出品鸿蒙os-驱动程序接收应用程序的鸿蒙鸿蒙消息
2.毕业设计竞赛选题推荐 | 鸿蒙嵌入式物联网应用之智能垃圾桶项目实战（含文档及源码）
3.鸿蒙轻内核M核源码分析：中断Hwi
4.umi3源码解析之核心Service类初始化
5.鸿蒙内核源码分析(构建工具篇) | 顺瓜摸藤调试鸿蒙构建过程
6.鸿蒙轻内核M核源码分析：LibC实现之Musl LibC

疯壳出品鸿蒙os-驱动程序接收应用程序的消息

       鸿蒙操作系统（HarmonyOS）的驱动程序设计允许应用程序向驱动发送消息。此过程通过`HdfIoServiceBind`接口实现，实例实例其在`hdf_io_service_if.h`文件中声明如下：

       `struct HdfIoService *HdfIoServiceBind(const char *serviceName,源码源码 mode_t permission)`

       该接口接受服务名称和权限作为参数。成功获取服务后，鸿蒙鸿蒙调用服务的实例实例`Dispatch`方法向驱动发送消息。参数`serviceName`指向服务名称的源码源码生成程序源码指针，`permission`表示创建设备节点的鸿蒙鸿蒙权限，通常用户空间调用时使用默认值0。实例实例

       在`myapp`应用基础上添加接口以获取`sample_service`服务并调用`Dispatch`方法，源码源码代码如下：

       完整程序如下：（略）

       驱动实现中，鸿蒙鸿蒙需要在`IDeviceIoService`类中实现`Dispatch`方法，实例实例其函数指针在`HdfDeviceIoClient`结构体中定义。源码源码驱动代码包括：

       1. 在`sample_driver.c`文件中定义兼容`Dispatch`的鸿蒙鸿蒙方法，示例如下：

       完整驱动代码如下：（略）

       编译源码后，实例实例烧录到板子中执行`app`，源码源码结果显示消息发送和接收符合预期：

       打印信息验证了程序逻辑的正确性。

       `app`代码示例：

       包括但不限于头文件和函数定义，如下：

       完整代码如下：（略）

       `驱动`代码示例：

       包括`hdf_device_desc.h`头文件引用，日志接口头文件引用，服务结构定义，`Dispatch`方法实现，以及驱动接口函数，如下：

       完整代码如下：（略）

毕业设计竞赛选题推荐 | 鸿蒙嵌入式物联网应用之智能垃圾桶项目实战（含文档及源码）

       智能垃圾桶项目案例，采用华清远见鸿蒙基础套餐（Hi鸿蒙开发板）+雷达控制模块（含舵机）作为硬件平台。项目功能设计如下：

       1. **感应功能**：通过红外感应或微波感应技术，当有物体或手靠近感应区时，盖子自动开启，离开后自动关闭，实现无需手动或脚踩操作。

       2. **卫生与环保**：减少细菌传播，避免异味和蚊虫滋生，降低环境污染，通过自动关闭功能减少能耗。

       项目实现内容包括：人体与垃圾桶的距离感知、OLED显示屏状态显示、人体靠近时自动开启盖子，远离时自动关闭。

       技术点涉及：人体距离感知技术、OLED显示屏驱动、智能设备自动化控制。

       项目整体框架：硬件平台搭建、传感器与执行器连接、软件编程实现功能。

       硬件平台：FS-Hi鸿蒙开发板，配备丰富的板载资源与拓展模块，支持鸿蒙系统。

       开发板优势：适用于物联网教学、学生毕设、个人学习及竞赛，easefilter源码配套教程、视频课程与项目案例。

       项目源码与文档领取：添加小元老师微信号(yyzlab)，获取智能垃圾桶项目完整配套文档及源码，还有鸿蒙物联网开发板相关资料。

鸿蒙轻内核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() 函数注册中断处理程序，传入中断号、jmeterlistener源码优先级和中断模式。函数内部验证参数，设置中断处理程序，最终通过调用 CMSIS 函数完成中断创建。

       删除中断 HalHwiDelete()

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

       中断处理执行入口程序

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

       开关中断

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

       小结

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

umi3源码解析之核心Service类初始化

       前言

       umi是一个插件化的企业级前端应用框架，在开发中后台项目中应用颇广，确实带来了许多便利。借着这个契机，便有了我们接下来的“umi3源码解析”系列的分享，初衷很简单就是从源码层面上帮助大家深入认知umi这个框架，能够更得心应手的使用它，学习源码中的设计思想提升自身。该系列的大纲如下：

       开辟鸿蒙，今天要解析的就是第一part，内容包括以下两个部分：

       邂逅umi命令，看看umidev时都做了什么？

       初遇插件化，了解源码中核心的Service类初始化的过程。

       本次使用源码版本为?3.5.，地址放在这里了，接下来的eaapp源码每一块代码笔者都贴心的为大家注释了在源码中的位置，先clone再食用更香哟！

邂逅umi命令

       该部分在源码中的路径为：packages/umi

       首先是第一部分umi命令，umi脚手架为我们提供了umi这个命令，当我们创建完一个umi项目并安装完相关依赖之后，通过yarnstart启动该项目时，执行的命令就是umidev

       那么在umi命令运行期间都发生了什么呢，先让我们来看一下完整的流程，如下图：

       接下来我们对其几个重点的步骤进行解析，首先就是对于我们在命令行输入的umi命令进行处理。

处理命令行参数//packages/umi/src/cli.tsconstargs=yParser(process.argv.slice(2),{ alias:{ version:['v'],help:['h'],},boolean:['version'],});if(args.version&&!args._[0]){ args._[0]='version';constlocal=existsSync(join(__dirname,'../.local'))?chalk.cyan('@local'):'';console.log(`umi@${ require('../package.json').version}${ local}`);}elseif(!args._[0]){ args._[0]='help';}

       解析命令行参数所使用的yParser方法是基于yargs-parser封装,该方法的两个入参分别是进程的可执行文件的绝对路径和正在执行的JS文件的路径。解析结果如下：

//输入umidev经yargs-parser解析后为：//args={ //_:["dev"],//}

       在解析命令行参数后，对version和help参数进行了特殊处理：

       如果args中有version字段，并且args._中没有值，将执行version命令，并从package.json中获得version的值并打印

       如果没有version字段，args._中也没有值，将执行help命令

       总的来说就是，如果只输入umi实际会执行umihelp展示umi命令的使用指南，如果输入umi--version会输出依赖的版本，如果执行umidev那就是接下来的步骤了。

       提问：您知道输入umi--versiondev会发什么吗？

       运行umidev

//packages/umi/src/cli.tsconstchild=fork({ scriptPath:require.resolve('./forkedDev'),});process.on('SIGINT',()=>{ child.kill('SIGINT');process.exit(0);});//packages/umi/src/utils/fork.tsif(CURRENT_PORT){ process.env.PORT=CURRENT_PORT;}constchild=fork(scriptPath,process.argv.slice(2),{ execArgv});child.on('message',(data:any)=>{ consttype=(data&&data.type)||null;if(type==='RESTART'){ child.kill();start({ scriptPath});}elseif(type==='UPDATE_PORT'){ //setcurrentusedportCURRENT_PORT=data.portasnumber;}process.send?.(data);});

       本地开发时，大部分脚手架都会采用开启一个新的线程来启动项目，umi脚手架也是如此。这里的fork方法是基于node中child_process.fork()方法的封装，主要做了以下三件事：

       确定端口号，使用命令行指定的端口号或默认的，如果该端口号已被占用则prot+=1

       开启子进程，该子进程独立于父进程，两者之间建立IPC通信通道进行消息传递

       处理通信，主要监听了RESTART重启和UPDATE_PORT更新端口号事件

       接下来看一下在子进程中运行的forkedDev.ts都做了什么。

//packages/umi/src/forkedDev.ts(async()=>{ try{ //1、设置NODE_ENV为developmentprocess.env.NODE_ENV='development';//2、InitwebpackversiondeterminationandrequirehookinitWebpack();//3、实例化Service类，执行run方法constservice=newService({ cwd:getCwd(),//umi项目的根路径pkg:getPkg(process.cwd()),//项目的package.json文件的路径});awaitservice.run({ name:'dev',args,});//4、父子进程通信letclosed=false;process.once('SIGINT',()=>onSignal('SIGINT'));process.once('SIGQUIT',()=>onSignal('SIGQUIT'));process.once('SIGTERM',()=>onSignal('SIGTERM'));functiononSignal(signal:string){ if(closed)return;closed=true;//退出时触发插件中的onExit事件service.applyPlugins({ key:'onExit',type:service.ApplyPluginsType.event,args:{ signal,},});process.exit(0);}}catch(e:any){ process.exit(1);}})();

       设置process.env.NODE_ENV的值

       initWebpack（接下来解析）

       实例化Service并run（第二part的内容）

       处理父子进程通信，当父进程监听到SIGINT、SIGTERM等终止进程的信号，也通知到子进程进行终止；子进程退出时触发插件中的onExit事件

       initWebpack

//packages/umi/src/initWebpack.tsconsthaveWebpack5=(configContent.includes('webpack5:')&&!configContent.includes('//webpack5:')&&!configContent.includes('//webpack5:'))||(configContent.includes('mfsu:')&&!configContent.includes('//mfsu:')&&!configContent.includes('//mfsu:'));if(haveWebpack5||process.env.USE_WEBPACK_5){ process.env.USE_WEBPACK_5='1';init(true);}else{ init();}initRequreHook();

       这一步功能是检查用户配置确定初始化webpack的版本。读取默认配置文件.umirc和config/config中的配置，如果其中有webpack5或?mfsu等相关配置，umi就会使用webpack5进行初始化，否则就使用webpack4进行初始化。这里的mfsu是webpack5的模块联邦相关配置，umi在3.5版本时已经进行了支持。

初遇插件化

       该部分在源码中的路径为：packages/core/src/Service

       说起umi框架，最先让人想到的就是插件化，这也是caddcl源码框架的核心，该部分实现的核心源码就是Service类，接下来我们就来看看Service类的实例化和init()的过程中发生了什么，可以称之为插件化实现的开端，该部分的大致流程如下

       该流程图中前四步，都是在Service类实例化的过程中完成的，接下来让我们走进Service类。

Service类的实例化//packages/core/src/Service/Service.tsexportdefaultclassServiceextendsEventEmitter{ constructor(opts:IServiceOpts){ super();this.cwd=opts.cwd||process.cwd();//当前工作目录//repoDirshouldbetherootdirofrepothis.pkg=opts.pkg||this.resolvePackage();//package.jsonthis.env=opts.env||process.env.NODE_ENV;//环境变量//在解析config之前注册babelthis.babelRegister=newBabelRegister();//通过dotenv将环境变量中的变量从.env或.env.local文件加载到process.env中this.loadEnv();//1、getuserconfigconstconfigFiles=opts.configFiles;this.configInstance=newConfig({ cwd:this.cwd,service:this,localConfig:this.env==='development',configFiles});this.userConfig=this.configInstance.getUserConfig();//2、getpathsthis.paths=getPaths({ cwd:this.cwd,config:this.userConfig!,env:this.env,});//3、getpresetsandpluginsthis.initialPresets=resolvePresets({ ...baseOpts,presets:opts.presets||[],userConfigPresets:this.userConfig.presets||[],});this.initialPlugins=resolvePlugins({ ...baseOpts,plugins:opts.plugins||[],userConfigPlugins:this.userConfig.plugins||[],});}}

       Service类继承自EventEmitter用于实现自定义事件。在Service类实例化的过程中除了初始化成员变量外主要做了以下三件事：

       1、解析配置文件

//packages/core/src/Config/Config.tsconstDEFAULT_CONFIG_FILES=[//默认配置文件'.umirc.ts','.umirc.js','config/config.ts','config/config.js',];//...if(Array.isArray(opts.configFiles)){ //配置的优先读取this.configFiles=lodash.uniq(opts.configFiles.concat(this.configFiles));}//...getUserConfig(){ //1、找到configFiles中的第一个文件constconfigFile=this.getConfigFile();this.configFile=configFile;//潜在问题：.local和.env的配置必须有configFile才有效if(configFile){ letenvConfigFile;if(process.env.UMI_ENV){ //1.根据UMI_ENV添加后缀eg:.umirc.ts-->.umirc.cloud.tsconstenvConfigFileName=this.addAffix(configFile,process.env.UMI_ENV,);//2.去掉后缀eg:.umirc.cloud.ts-->.umirc.cloudconstfileNameWithoutExt=envConfigFileName.replace(extname(envConfigFileName),'',);//3.找到该环境下对应的配置文件eg:.umirc.cloud.[ts|tsx|js|jsx]envConfigFile=getFile({ base:this.cwd,fileNameWithoutExt,type:'javascript',})?.filename;}constfiles=[configFile,//eg:.umirc.tsenvConfigFile,//eg:.umirc.cloud.tsthis.localConfig&&this.addAffix(configFile,'local'),//eg:.umirc.local.ts].filter((f):fisstring=>!!f).map((f)=>join(this.cwd,f))//转为绝对路径.filter((f)=>existsSync(f));//clearrequirecacheandsetbabelregisterconstrequireDeps=files.reduce((memo:string[],file)=>{ memo=memo.concat(parseRequireDeps(file));//递归解析依赖returnmemo;},[]);//删除对象中的键值require.cache[cachePath]，下一次require将重新加载模块requireDeps.forEach(cleanRequireCache);this.service.babelRegister.setOnlyMap({ key:'config',value:requireDeps,});//requireconfigandmergereturnthis.mergeConfig(...this.requireConfigs(files));}else{ return{ };}}

       细品源码，可以看出umi读取配置文件的优先级：自定义配置文件?>.umirc>config/config，后续根据UMI_ENV尝试获取对应的配置文件，development模式下还会使用local配置，不同环境下的配置文件也是有优先级的

       例如：.umirc.local.ts>.umirc.cloud.ts>.umirc.ts

       由于配置文件中可能require其他配置，这里通过parseRequireDeps方法进行递归处理。在解析出所有的配置文件后，会通过cleanRequireCache方法清除requeire缓存，这样可以保证在接下来合并配置时的引入是实时的。

       2、获取相关绝对路径

//packages/core/src/Service/getPaths.tsexportdefaultfunctiongetServicePaths({ cwd,config,env,}:{ cwd:string;config:any;env?:string;}):IServicePaths{ letabsSrcPath=cwd;if(isDirectoryAndExist(join(cwd,'src'))){ absSrcPath=join(cwd,'src');}constabsPagesPath=config.singular?join(absSrcPath,'page'):join(absSrcPath,'pages');consttmpDir=['.umi',env!=='development'&&env].filter(Boolean).join('-');returnnormalizeWithWinPath({ cwd,absNodeModulesPath:join(cwd,'node_modules'),absOutputPath:join(cwd,config.outputPath||'./dist'),absSrcPath,//srcabsPagesPath,//pagesabsTmpPath:join(absSrcPath,tmpDir),});}

       这一步主要获取项目目录结构中node_modules、dist、src、pages等文件夹的绝对路径。如果用户在配置文件中配置了singular为true，那么页面文件夹路径就是src/page，默认是src/pages

       3、收集preset和plugin以对象形式描述

       在umi中“万物皆插件”，preset是对于插件的描述，可以理解为“插件集”，是为了方便对插件的管理。例如：@umijs/preset-react就是一个针对react应用的插件集，其中包括了plugin-access权限管理、plugin-antdantdUI组件等。

//packages/core/src/Service/Service.tsthis.initialPresets=resolvePresets({ ...baseOpts,presets:opts.presets||[],userConfigPresets:this.userConfig.presets||[],});this.initialPlugins=resolvePlugins({ ...baseOpts,plugins:opts.plugins||[],userConfigPlugins:this.userConfig.plugins||[],});

       在收集preset和plugin时，首先调用了resolvePresets方法，其中做了以下处理：

       3.1、调用getPluginsOrPresets方法，进一步收集preset和plugin并合并

//packages/core/src/Service/utils/pluginUtils.tsgetPluginsOrPresets(type:PluginType,opts:IOpts):string[]{ constupperCaseType=type.toUpperCase();return[//opts...((opts[type===PluginType.preset?'presets':'plugins']asany)||[]),//env...(process.env[`UMI_${ upperCaseType}S`]||'').split(',').filter(Boolean),//dependencies...Object.keys(opts.pkg.devDependencies||{ }).concat(Object.keys(opts.pkg.dependencies||{ })).filter(isPluginOrPreset.bind(null,type)),//userconfig...((opts[type===PluginType.preset?'userConfigPresets':'userConfigPlugins']asany)||[]),].map((path)=>{ returnresolve.sync(path,{ basedir:opts.cwd,extensions:['.js','.ts'],});});}

       这里可以看出收集preset和plugin的来源主要有四个：

       实例化Service时的入参

       process.env中指定的UMI_PRESETS或UMI_PLUGINS

       package.json中dependencies和devDependencies配置的，需要命名规则符合?/^(@umijs\/|umi-)preset-/这个正则

       解析配置文件中的，即入参中的userConfigPresets或userConfigPresets

       3.2、调用pathToObj方法：将收集的plugin或preset以对象的形式输出

//输入umidev经yargs-parser解析后为：//args={ //_:["dev"],//}0

       umi官网中提到过：每个插件都会对应一个id和一个key，id是路径的简写，key是进一步简化后用于配置的唯一值。便是在这一步进行的处理

       形式如下：

//输入umidev经yargs-parser解析后为：//args={ //_:["dev"],//}1

       思考：为什么要将插件以对象的形式进行描述？有什么好处？

执行run方法，初始化插件

       在Service类实例化完毕后，会立马调用run方法，run()执行的第一步就是执行init方法，init()方法的功能就是完成插件的初始化，主要操作如下：

       遍历initialPresets并init

       合并initpresets过程中得到的plugin和initialPlugins

       遍历合并后的plugins并init

       这里的initialPresets和initialPlugins就是上一步收集preset和plugin得到的结果，在这一步要对其逐一的init，接下来我们看一下init的过程中做了什么。

       Initplugin

//输入umidev经yargs-parser解析后为：//args={ //_:["dev"],//}2

       这段代码主要做了以下几件事情：

       getPluginAPI方法：newPluginAPI时传入了Service实例，通过pluginAPI实例中的registerMethod方法将register方法添加到Service实例的pluginMethods中，后续返回pluginAPI的代理，以动态获取最新的register方法，以实现边注册边使用。

//输入umidev经yargs-parser解析后为：/

鸿蒙内核源码分析(构建工具篇) | 顺瓜摸藤调试鸿蒙构建过程

       构建工具的重要性不言而喻，它在工程的编译、连接、打包过程中发挥着关键作用。构建工具定义了哪些源文件需要被编译、如何编译，哪些库文件需要创建以及如何创建，最终输出所需文件的规则。鸿蒙轻内核（L1/liteos）的构建工具是hb，它是ohos-build的简称，而ohos则是openharmony os的简称。hb通过命令行安装，是一个用Python编写的构建工具。其源代码位于./build/lite目录下。

       鸿蒙构建系统由Python、gn、ninja、makefile几个部分组成。每个部分都有其特定功能，负责处理各自擅长的构建任务。在构建过程中，如果直接跳过hb部分，而使用gn gen命令，可以看到构建流程的简化结果。

       为了更有效地调试hb，推荐使用VSCode进行。创建一个launch.json文件，然后粘贴特定代码即可进行调试。调试过程包括设置和编译两个关键步骤。

       在设置阶段，通过执行hb set命令，系统会在源码根目录生成ohos_config.json配置文件。这个配置文件包含固定的配置项，由Config类管理。通过设置断点，可以直观地观察调试现场，为后续的编译步骤做好准备。

       编译阶段通过hb build命令进行。源码主要位于./build/lite/hb/build/*.py目录下。建议深入探索这些源码，以理解每个细节。编译流程分为两步：首先通过gn_build生成.ninja文件，然后使用ninja_build执行构建任务。关于gn和ninja的使用方法，后续会有详细的文章进行说明。

       在执行编译过程时，最后会调用exec_command方法来执行相关命令。这个方法位于build/lite/hb/common/utils.py文件中，通过在此处设置断点，可以跟踪exec_command方法的调用流程，深入了解构建工具的内部实现细节。

       通过深入理解和调试构建工具，开发者可以更高效地完成项目构建任务，同时也能对构建流程有更深入的了解。最后，建议在调试过程中保持耐心，逐步探索每个步骤的细节，以便更好地掌握构建工具的使用和优化。

鸿蒙轻内核M核源码分析：LibC实现之Musl LibC

       本文探讨了LiteOS-M内核中Musl LibC的实现，重点关注文件系统与内存管理功能。Musl LibC在内核中提供了两种LibC实现选项，使用者可根据需求选择musl libC或newlibc。本文以musl libC为例，深度解析其文件系统与内存分配释放机制。

       在使用musl libC并启用POSIX FS API时，开发者可使用文件kal\libc\musl\fs.c中定义的文件系统操作接口。这些接口遵循标准的POSIX规范，具体用法可参阅相关文档，或通过网络资源查询。例如，mount()函数用于挂载文件系统，而umount()和umount2()用于卸载文件系统，后者还支持额外的卸载选项。open()、close()、unlink()等文件操作接口允许用户打开、关闭和删除文件，其中open()还支持多种文件创建和状态标签。read()与write()用于文件数据的读写操作，lseek()则用于文件读写位置的调整。

       在内存管理方面，LiteOS-M内核提供了标准的POSIX内存分配接口，包括malloc()、free()与memalign()等。其中，malloc()和free()用于内存的申请与释放，而memalign()则允许用户以指定的内存对齐大小进行内存申请。

       此外，calloc()函数在分配内存时预先设置内存区域的值为零，而realloc()则用于调整已分配内存的大小。这些函数构成了内核中内存管理的核心机制，确保资源的高效利用与安全释放。

       总结而言，musl libC在LiteOS-M内核中的实现，通过提供全面且高效的文件系统与内存管理功能，为开发者提供了强大的工具集，以满足不同应用场景的需求。本文虽已详述关键功能，但难免有所疏漏，欢迎读者在遇到问题或有改进建议时提出，共同推动技术进步。感谢阅读。

鸿蒙内核源码分析(编译过程篇) | 简单案例窥视编译全过程

       一个 .c 源文件的编译过程，从源文件开始，经过预处理、编译、汇编、链接，最终生成可执行文件。

       GCC 是 GNU 编译器套件，用于多种编程语言的编译。

       以 main.c 为例，编译过程分为以下几个步骤：

       1. 预处理：处理源代码中的预处理指令，生成 main.i 文件。此步骤主要处理 # 开始的指令。

       2. 编译：将预处理后的文件进行词法、语法和语义分析，优化后生成汇编代码，即 main.s。

       3. 汇编：将汇编代码转化为机器指令，生成机器码文件，main.o 为主要目标文件。

       4. 链接：链接器 ld 将所有目标文件合并，解决符号和库依赖关系，生成可执行文件。

       执行程序：运行可执行文件，执行程序。

       在链接阶段，可能会发现 s_inter_init() 和 s_exter_no_init() 之间的地址只相差两个字节，而 int 变量应为四个字节。这是由于 GCC 在链接过程中使用了重定位，将符号引用与实际的内存地址关联，从而优化内存使用和性能。这种重定位在编译和链接阶段进行，确保程序在不同环境中运行时的一致性。

鸿蒙系统体验之在IMX6ULL上体验鸿蒙系统

       请先下载以下文件，里面含有烧写软件：

       鸿蒙内核Liteos-a的官方代码目前只支持海思的芯片，我作为首批开发者入驻华为一个多月，成功在ASK_IMX6ULL上移植了Liteos-a。

       本文先让大家体验一下Liteos-a，后续会发布教程、视频、源码。

       百问网开发了一款烧写软件：ask_imx6ull_flashing_tool，它的界面如下：

       使用这软件，只需要一条USB线连接电脑和开发板USB OTG口，只需要点击一个按钮就可以体验鸿蒙系统。

       1.1 熟悉ASK_IMX6ULL启动开关1.1.1 全功能版

       ask_imx6ull全功能版支持USB、EMMC、SD/TF卡三种启动方式。使用后2种启动方式之前，需要先在EMMC或SD/TF卡上烧写系统。

       板子背后画有一个表格，表示这3种方式如何设置。表格如下：

       BOOT CFG

       这3种启动方式的设置示意图如下：

       其中的USB启动模式主要用来烧写系统。 注意：设置为USB启动时，不能先插上SD/TF卡。

       1.1.2 MINI EMMC版

       百问网 IMX6ULL EMMC版支持USB、EMMC、SD/TF卡三种启动方式。使用后2种启动方式之前，需要先在EMMC或SD/TF卡上烧写系统。 板子背后画有一个表格，表示这3种方式如何设置。表格如下：

       这3种启动方式的设置示意图如下：

       其中的USB启动模式主要用来烧写系统。 注意：设置为USB启动时，不能先插上SD/TF卡。

       1.2 安装驱动程序

       下载“ask_imx6ull烧写工具v4.zip” 后，把它解压可得如下目录：

       运行上图中的程序。

       1.2.2 连接USB OTG线

       先把开发板设置为USB启动方式，接好2条USB线，开发板上电。

       (1) 全功能版接线方式

       (2) MINI EMMC版接线方式

       1.2.3 安装IMX6ULL的USB驱动程序

       通过USB下载或是烧写程序时，需要把开发板的OTG口用USB线连接到电脑。一般都会自动安装驱动，烧写软件的绿灯不亮时，则很有可能是驱动程序没有安装好，这时需要手工安装驱动程序。

       要选择“连接到主机”，勾选“记住我的选择，以后不再询问”。也许你不慎点错了“连接到虚拟机”，那也没关系，在VMWARE的菜单中把“Freescale SE Blank 6ULL”或“Netchip USB download gadget”断开连接，如下图所示：

       安装第2个驱动：当烧写工具的“设备已连接”绿灯亮起，就可以在“专业版”点击“运行”按钮，这时电脑会识别出“USB download gadget”设备，一般都会自动给它安装驱动程序，如下图：

       如果没有自动安装好驱动程序(“固件已运行”绿灯没亮)，先去

       下载zadig并运行，然后参考下图安装驱动程序：

       如果一切正常，烧写工具的2个绿灯都会亮，如下：

       这就表示所有驱动都安装好了，可以重启开发板，就可以参考后面章节体验鸿蒙了。

       1.3 鸿蒙文件在哪

       在“ask_imx6ull烧写工具v4”目录下，

       1.4 一键体验鸿蒙：下载到内存运行1.4.1 一键启动

       把开发板设置为USB启动，接好2条USB线，装好驱动程序后，运行烧写工具，点击下图所示按钮，观察串口信息，可以看到板子启动进入鸿蒙系统了：

       串口信息如下：

       1.4.2 执行shell命令

       执行help命令，可以看到支持的SHELL命令，如下：

       1.4.3 执行数码相框GUI程序

       注意：必须用“./bin/digitpic”，不能用绝对路径“/bin/digitpic” 注意：这个GUI程序是我们自己写得，很丑，与鸿蒙无关。

       在板子屏幕上可以看到：

       1.4.4 退出程序

       执行task命令确定进程号，然后执行“kill -9 PID”杀掉进程，比如：

       1.5 开机自动启动鸿蒙

       把开发板设置为USB启动，接好2条USB线，装好驱动程序后，运行烧写工具.

       先烧写，点击下图所示按钮：

       然后设置默认系统，如下图所示：

       最后，设置为EMMC启动，重新上电后就可以自动进入鸿蒙系统。