可能是因为是小白吧，这几天翻遍了论坛也没有搞的太清楚。抛开模型训练不谈，如何用arm-himix200-linux编译一个最简单的app demo上线到相机？

intel ice驱动1.9.11 版本在openeuler22.03-LTS  无法直接编译安装，需要按照以下步骤操作环境 openeuler22.03-LTS aarch641.intel官网下载驱动链接：https://downloadmirror.intel.com/738725/ice-1.9.11.tar.gz2.解压软件包tar -xvf ice-1.9.11.tar.gz3.cd ice-1.9.11/src替换这三个文件（文件在附件中）ice_ethtool.c ice_ptp.c 路径 ice-1.9.11/srcauxiliary_bus.h 路径 ice-1.9.11/src/linux4.cd ice-1.9.11/src5.make install6.查看新驱动 modinfo ice|more环境 openeuler22.03-LTS x86_641.intel官网下载驱动链接：https://downloadmirror.intel.com/738725/ice-1.9.11.tar.gz2.解压软件包tar -xvf ice-1.9.11.tar.gz3.cd ice-1.9.11/src替换这两个文件（文件在附件中）ice_ethtool.c  路径 ice-1.9.11/srcauxiliary_bus.h 路径 ice-1.9.11/src/linux4.cd ice-1.9.11/src5.make install6.查看新驱动 modinfo ice|more

[toc] ### 快速入门之Hello World ------  - #### **进程一：添加hello world源码文件** 1.新建my_app文件夹 ​ 在./applications/BearPi/BearPi-HM_ Nano/sample路径 下新建一个my_ app目录,用于存放业务源码文件。  2.新建hello_world.c文件 ​ 在./applications/BearP/BearPi-HM_ Nano/sample/my_ app路径下新建一个hello_ _world.c文件，该文件为业务源码文件。  ---- 3.新增BUILD.gn文件 ​ 在./applications/BearPi/BearPi-HM_ Nano/sample/my_ app路径下新建一个BUILD.gn文件， 该文件为业务源码编译脚本。  - #### **进程二：编写Hello World业务代码** ​ 打印与有关，APP FEATURE INIT与“ohos_init.h”有关。  - #### 进程三：编写编译构建文件BUILD.gn 在/applications/BearPi/BearPi-HM/sample/my_ app 下的BUILD.gn文件中添加如下代码。  在/applications/BearPi/BearPi-HM/sample下的BUILD.gn  ​ 先屏蔽掉“B2_ basic button : button example ”  - #### **进程四**：调试Hello World程序 进入MX，登录。直接输入hmp dist，编译失败。（原因：未进入文件）  进入bundle.json,继续编译hmp dist，编译成功。 - #### **进程五：使用开发板** 电脑插上开发板，打开“电脑”-----“设备管理器”查看COM口，设置波特率921600，选择烧录文件（工程目录下out----BearPi-HM_Nano------选择Hi3861 wifliot app allinone.bin），勾选normal，点击connect，至此代码烧录完毕，led闪烁。 **串口工具看现象** 执行下图操作后，按开发板上复位按键即可。   ### HarmonyOS编译框架介绍 ------ - #### ninji编译工具简介 在Unix/Linux下通常使用Makefile来控制代码的编译,但是Makefile对于比较大的项目有时候会比较慢，Google的程序员在开发Chrome的时候因为受不了Makefile的速度，自己重新开发出来一套新的控制编译的工 具叫作Ninja, Ninja相对于Makefile这套Makefile具更注重于编译速度。除了Chrome现在还有一些其他的比较大的项目也在开始使用Ninja。 - #### 如何编译模块 用vs code访问服务器操作如下： 终端——新终端——输入用户名 登录名@地址——输入密码——进入源码目录——编译（hpm dist）  ​ 后边听不懂了。。。。。。。。。。。 ### HarmonyOS CMSIS接口简介 ------ #### 什么是CMSIS-RTOS2接口？ CMSIS是Cortex微控制器软件接口标准(Cortex Microcontroller Software Interface Standard)是ARM和一些编译器厂家以及半导体厂家共同遵循的一套标准，是由ARM专门]针对Cortex-M系列提出的标准。在该标准的约定下，ARM和芯片厂商会提供- -些通用的API接口来访问Cortex内核以及一 些专用外设，以减少更换芯片以及开发工具等移植工作所带来的金钱以及时间上的消耗。CMSIS-RTOS2 (CMSIS-RTOS API Version 2)是Arm⑧Cortex⑧-M处理器的通用的RTOS接口。为需要RTOS功能的软件组件提供了标准化的API。DCMSIS-RTOS2是一个通用的API,它与底层的RTOS内核无关,写应用程序的程序员在用户代码中调用CMS] S-N,RTOS2 API函数，可以更方便地将应用程序从-个RTOS到另一个RTOS,使用CMSIS-RTOS2 API的中间件也可以避免很多不必要的移植工作。 #### 鸿蒙与CMSIS-RTOS2接口联系 鸿蒙在CMSIS- RTOS2接口中封装了LiteOS- m的内核代码 最新CMSIS-RTOS2实现://kernel/liteos m/kal/cmsis/cmsis liteos2.c  上层应用或中间键要使用用内核的功能的话，我们通过调用CMSIS-RTOS API v2来实现对内核功能的调用。   #### 如何使用CMSIS-RTOS2接口？ ------ 1、在业务代码中包含"cmsis_ os2.h“ 2、通过调用"cmsis_ os2.h"中的API函数使用系统相关功能  ### HarmonyOS内核开发一任务管理(上) ------ #### 1.任务管理简介 基本概念 1、从系统的角度看，任务是竞争系统资源的最小运行单元。任务可以使用或等待CPU、使用内存空间 等系统资源，并独立于其它任务运行。 2、LiteOS的任务模块可以给用户提供多个任务,实现了任务之间的切换和通信，帮助用户管理业务程序 流程。这样用户可以将更多的精力投入到业务功能的实现中。 3、LiteOS中的任务 是抢占式调度机制，高优先级的任务可打断低优先级任务，低优先级任务必须在高 优先级任务阻塞或结束后才能得到调度，同时支持时间片轮转调度方式。 4、LiteOS的任务默认有32个优先级(0-31),最高优先级为0,最低优先级为31。（具体有多少个，可以进 行配置） #### 2.任务相关概念 **任务状态** 任务状态通常分为以下四种: **就绪**(Ready) :该任务在就绪列表中，只等待CPU。 **运行**(Running) :该任务正在执行。 **阻塞**(Blocked) :该任务不在就绪列表中。包含任务被挂起、任务被延时、任务正在等待信号量、读写队 列或者等待读写事件等。 **退出态**(Dead) :该任务运行结束，等待系统回收资源。 ------ **任务ID**:在任务创建时通过参数返回给用户，作为任务的- -个非常重要的标识。 **任务优先级**:优先级表示任务执行的优先顺序。 **任务入口函数**:每个新任务得到调度后将执行的函数。 **任务控制块TCB**:每一个任务都含有一个任务控制块(TCB)。TCB包含了任务上下文栈指针(stack pointer)、 任务状态、任务优先级、任务ID、 任务名、任务栈大小等信息。TCB可以反映出每个任务运行情况。 **任务栈**:每- -个任务都拥有一一个独立的栈空间，我们称为任务栈。 **任务上下文**:任务在运行过程中使用到的-些资源，如寄存器等,我们称为任务上下文。LiteOS在任务挂起的时候会将本任务的任务上下文信息，保存在自己的任务栈里面，以便任务恢复后，从栈空间中恢复挂起时的上下文信息，从而继续执行被挂起时被打断的代码。 **任务切换:**任务切换包含获取就绪列表中最高优先级任务、切出任务上下文保存、切入任务上下文恢复等动作。 #### 3.任务的调度机制  #### 4.实现任务的管理    **Attention：①先创建的任务先运行②改完代码要在MS编译（同快速入门Hello World进程四）**

通常在一个项目里，我们的规则是：1）如果这个工程没有编译过，那么我们的所有C文件都要编译并被链接。2）如果这个工程的某几个C文件被修改，那么我们只编译被修改的C文件，并链接目标程序。3）如果这个工程的头文件被改变了，那么我们需要编译引用了这几个头文件的C文件，并链接目标程序。其实就是智能的识别哪些编译链接需要做，哪些不用做避免不必要的时间消耗只要我们的Makefile写得够好，我们只用一个make命令就可以完成，make命令会自动智能地根据当前的文件修改的情况来确定哪些文件需要重编译，从而自己编译所需要的文件和链接目标程序。target … : prerequisites …command……target：也就是一个目标文件，可以是ObjectFile，也可以是执行文件。还可以是一个标签（Label），对于标签这种特性，暂不叙述。prerequisites：要生成那个target所需要的文件或是目标。command：也就是make需要执行的命令。（任意的Shell命令）这是一个文件的依赖关系，也就是说，target这一个或多个的目标文件依赖于prerequisites中的文件，其生成规则定义在command中。说白一点就是说，prerequisites中如果有一个以上的文件比target文件要新的话，command所定义的命令就会被执行。这就是Makefile的规则。也就是Makefile中最核心的内容。hello_demo : hellospeak.o speak.o   //由hellospeak.o speak.o链接成目标hello_demo                                          gcc -o hello_demo hellospeak.o speak.o  //执行下面的命令                                hellospeak.o : hellospeak.c speak.h  //如果一些hellospeak.c的函数声明是在头文件speak.h中那么也得在这后面加上                                                 gcc -c hellospeak.c                                                speak.o : speak.c  speak.h                                                          gcc -c speak.c                                                    clean :                                                                          rm hello_demo speak.o  hellospeak.o  //当执行make clean时就会执行这个语句 //speak.h#include<stdio.h>#include<stdlib.h>void helloSpeak();--------------------------------------------------------------    //speak.c#include"speak.h"void helloSpeak(){ printf("Hello Makefile\n");}--------------------------------------------------------------    //main.c#include"speak.h"int main(){  helloSpeak();  return 0;}   --------------------------------------------------------------//MakefileHello: main.o speak.o        gcc -o Hello  main.o speak.omain.o: main.c speak.h        gcc -c main.cspeak.o: speak.c speak.h        gcc -c speak.cclean:        rm Hello speak.o main.o ~

感谢点击与帮助。【功能模块】摄像头，采用的是树莓派V2.1【操作步骤&问题现象】cann的智能小车实验步骤参考的是：《智能系统与应用》课程方案_在线课程_华为云开发者学堂_云计算培训-华为云 (huaweicloud.com)部署摄像头时，用cmake命令生成makefile文件，makelists走第19行报错第19行代码块：if (NOT DEFINED ENV{INSTALL_DIR})    MESSAGE(FATAL_ERROR "Not Defined INSTALL_DIR")endif()最初认为是没有c++编译器导致的，但是使用--version命令可以查询到camke gcc g++的版本，cmake的版本3.10.2也满足cmakelist的要求【截图信息】【日志信息】（可选，上传日志内容或者附件）

一、目标1、了解makefile的基本概念和基本结构；2、初步掌握编写简单makefile的方法、利用GNU Make编译应用程序的方法；二、步骤（一）简单的makefile文件的使用（1）用vi 创建5个程序文件：①/*main.c*/    #include <stdio.h>     #include "mytool1.h"    #include "mytool2.h"    int main()    {     mytool1_print("hello,mytool1!");     mytool2_print("hello,mytool2!");     return 0;    }             ②/*mytool1.c*/    #include "mytool1.h"    void mytool1_print(char *print_str)    {     printf("This is mytool1 print : %s ",print_str);    }     ③/*mytool1.h*/    #ifndef _MYTOOL_1_H    #define _MYTOOL_1_H     void mytool1_print(char *print_str);    #endif     ④/*mytool2.c*/    #include "mytool2.h"    void mytool2_print(char *print_str)    {     printf("This is mytool2 print : %s ",print_str);    }    ⑤/*mytool2.h*/    #ifndef _MYTOOL_2_H    #define _MYTOOL_2_H     void mytool2_print(char *print_str);    #endif（2）创建一个如下内容的makefile文件（注：命令行中的前面的空位是按TAB键生成的）。main: main.o mytool1.o mytool2.ogcc -o main main.o mytool1.o mytool2.omain.o: main.cgcc -c main.cmytool1.o: mytool1.c mytool1.hgcc -c mytool1.cmytool2.o: mytool2.c mytool2.hgcc -c mytool2.c如下图所示：（3）在命令窗口输入命令make，执行makefile进行编译，如下图：（4）执行最终生成的程序（5）再次执行make，结果失败因为makefile中要生成的文件已存在目录中（二）makefile中变量的使用（1）将makefile文件另存一个备份后，修改为如下内容：# makefile test for hello programOBJS = main.o mytool1.o mytool2.oCC = gccmain: $(OBJS)       $(CC)  $(OBJS) -o mainmain.o: main.c       $(CC) -c main.cmytool1.o: mytool1.c mytool1.h       $(CC) -c mytool1.cmytool2.o: mytool2.c mytool2.h       $(CC) -c mytool2.c（2）删除当前目录下的所有.o文件后，重新执行make（三）自动变量及隐式规则的使用（1）将makefile文件备份后，修改为如下内容：# makefile test for hello programOBJS = main.o mytool1.o mytool2.oCC = gccmain: $(OBJS)$(CC)  $^ -o $@main.o: main.c$(CC) -c $< -o $@mytool1.o: mytool1.c mytool1.h$(CC) -c $< -o $@mytool2.o: mytool2.c mytool2.h$(CC) -c  $< -o $@ （2）删除当前目录下的所有.o文件后，重新执行make

【功能模块】collect2.exe: error: ld returned 1 exit statusmake: *** [Makefile:149: build/Huawei_LiteOS.elf] Error 1exit code=2[2021/4/5 21:45:04] 编译失败。【操作步骤&问题现象】1、依照视频教程编写编译代码，编译失败2、【截图信息】【日志信息】（可选，上传日志内容或者附件）vscode日志和工程已上传附件

什么是MakefileMakefile是一个名为GNU-Make软件所需要的脚本文件，该脚本文件可以指导Make软件控制arm-gcc等工具链去编译工程文件最终得到可执行文件，几乎所有的Linux发行版都内置了GNU-Make软件，VScode等多种IED也内置了Make程序。你见到的xxx.mk文件或者Makefile都统称为Makefile脚本文件。Makefile脚本文件的语法学习可以参考：https://www.gnu.org/software/make/manual/make.html （GNU make官方文档）https://seisman.github.io/how-to-write-makefile/overview.html （跟我一起写Makefile 陈皓）SDK和工程中的Makefile结构https://bbs.huaweicloud.com/blogs/195973 请参考这篇博客。修改Makefile脚本文件一共有三个Makefile文件需要进行修改，分别为targets\STM32F103RC\GCC\Makefile、 targets\STM32F103RC\GCC\project.mk和targets\STM32F103RC\.config修改MakefileSTM32F103不支持硬件浮点运算，并且为m3内核，我们需要修改第83行，将CPU = -mcpu=cortex-m4修改为CPU = -mcpu=cortex-m3，85行FPU变量后的值删除，87行FLOAT-ABI变量后的值删除，如下图所示。修改project.mk将HAL_DRIVER_SRC变量后我们没有使用的库文件路径删除，并将STM32L4修改为STM32F1，如果不确定有没有使用可以选择保留不影响使用，这里我移除了IIC、SPI等相关的库文件路径，注意：“\”为接续符，最后是没有接续符的。将HARDWARE_SRC变量后的路径删除，因为我们没有使用LCD和一些该目录下代码所对应的硬件，如果你使用了外设（OLED、网卡、DHT11等等），你可以把他们的初始化代码所在路径添加到这里，让make软件能找到他们并编译，修改后如下图所示。将HAL_DRIVER_SRC_NO_BOOTLOADER变量后的路径删除，我们并未使用DMA、RNG，修改后如下图所示。     将后的USER_SRC变量后的$(TARGET_DIR)/Src/Huawei_IoT_QR_Code.c、$(TARGET_DIR)/Src/spi.c 、$(TARGET_DIR)/Src/i2c.c 删除，system_stm32l4xx修改为system_stm32F1xx，stm32l4xx_it修改为stm32F1xx_it，添加上$(TARGET_DIR)/Src/stm32f1xx_hal_msp.c，如果你也有其他的用户逻辑代码可以添加在这里，修改后如下图所示。将HAL_DRIVER_INC变量后的路径中的L4修改为F1，如下图所示。移除HARDWARE_INC变量后的路径，修改后如下图所示。       将C_DEFS后的STM32L431xx修改为STM32F103xx如下图所示。       未提及的地方均不用修改。修改.config       .config暂不用修改，可以等后期全部一直完成后，通过IoT Link Studio中的图形化界面进行配置并自动修改即可。

第147到149行规则所需的依赖全部都生成好了，可以开始执行该规则的命令，将所有依赖通过LDFLAGS变量中的值链接生成Huawei_LiteOS.elf文件并列出程序文件中各段的大小。LDFLAGS变量中通过MCU变量定义了内核相关参数，例如ARM架构的版本以及是否支持硬件浮点数运算等参数，如下图所示，如果你需要将工程移植到不是STM32L431系类的MCU上，就需要修改MCU变量的值。LDFLAGS变量中通过LDSCRIPT变量读取os.ld链接脚本来控制程序该如何链接，每个段应该存放在程序中的何处，在os.ld链接脚本中还指明了MCU的RAM和FLASH大小及起始位置，我们在进行移植时也需要修改。Huawei_LiteOS.elf文件是第143至145行规则的依赖，将该elf文件转换为Huawei_LiteOS.hex和Huawei_LiteOS.bin文件，即可烧录。现在大家应该明白make控制下的整个程序编译过程了吧，以及Makefile文件起到的作用，我们再来看看前面的include导入的文件，如下图所示：首先导入了.config文件，这由Kconfig软件读取用户通过图形化配置的各项参数信息生成的，其中包含了对SDK中各组件参数的配置信息，如下图所示：以AT组件为例，CONFIG_AT_ENABLE=y代表使能AT组件；CONFIG_AT_DEVNAME="atdev"将AT组件用到的串口以"atdev"注册到driver层中；CONFIG_AT_OOBTABLEN=6 OOB表的长度配置为6个，这时用于接收异步数据的结构体，意味着我们最多能配置6个特定字符串，当这时字符串出现时调用相应处理函数进行处理；CONFIG_AT_RECVMAXLEN=1024将AT框架中的接收缓存区大小配置为1024字节，如果你的MCU资源受限可以减少这里的大小；CONFIG_AT_TASKPRIOR=10将AT任务的优先级配置为10，注意：这里只有第35行这条语句会影响Make的编译，其余语句是为了记录用户做了哪些配置和生成iot_config.h所用。       .config文件中所有的组件配置都和上面分析的一致，如果组件没有被使能如下图所示：相信大家看到这里又有新的疑问了，这些配置是如何影响到程序的编译呢？回到前面的第70行include $(SDK_DIR)/iot_link/iot.mk，来看看这个SDK/iot_link目录下的iot.mk文件中有什么你就有答案了，如下图所示：该Makefile将每个组件所属文件夹下的Makefile也导入进来了，我们还是以AT框架为例，第31行，导入at目录下的at.mk文件，该Makefile内容如下图所示：看到了吧，第7行与前面的CONFIG_AT_ENABLE=y变量相对应，ifeq ($(CONFIG_AT_ENABLE),y)语句的意思是如果CONFIG_AT_ENABLE变量的值为y，则将ifeq到endif之间的语句全部执行。       第8至9行将at目录下所有.c文件添加到C_SOURCES变量中，注意这里用的是+=是追加上去。       第11至12行将at目录下所有.h文件所在路径（注意是路径，通过-I参数指定头文件所在的路径，这样编译器才能找到头文件，否则会因为找不到头文件导致编译失败）添加到C_INCLUDES变量中，注意这里用的是+=是追加上去。       第14至14行将-D CONFIG_AT_ENABLE=1文本追加到C_DEFS变量中。       这三个变量大家都很眼熟吧，这就是工程目录/GCC目录中Makefile中的那三个变量，如下图所示：这样AT组件中的所有源文件和头文件就参与了编译。       回到第三个include，include $(MAKEFILE_DIR)/project.mk，这是用于包含（引入）工程目录/GCC目录下的project.mk，该Makefile部分内容如下图所示：主要用于包含Hal库中的文件以及用户自己添加进去的文件，这也是移植时需要进行修改的文件之一，大家可以仿照我前面分析的方法自己分析一下。最终所有被添加进入的.c源文件会被追加到C_SOURCES变量中，所有.h头文件所在的路径会被追加到C_INCLUDES变量中。总结以上就是LiteOS_Lab中Makefile运行的机制了，大家可以自己跟着文章全部分析分析一边以加深影响，SDK中所有的Makefile文件都不需要也不能进行修改，只需要修改工程中的三个Makefile，.config（这个不用手动修改，可以通过图形化配置进行修改），Makefile（根据目标MCU修改MCU相关的参数即可，也就是MCU这个变量的值），project.mk（根据目标MCU修改、添加或删除库文件以及用户文件以及最后的C_DEFS变量即可）。

什么是MakefileMakefile是一个名为GNU-Make软件所需要的脚本文件，该脚本文件可以指导Make软件控制arm-gcc等工具链去编译工程文件最终得到可执行文件，几乎所有的Linux发行版都内置了GNU-Make软件，VScode等多种IED也内置了Make程序。你见到的xxx.mk文件或者Makefile都统称为Makefile脚本文件。Makefile脚本文件的语法学习可以参考：https://www.gnu.org/software/make/manual/make.html （GNU make官方文档）https://seisman.github.io/how-to-write-makefile/overview.html （跟我一起写Makefile 陈皓）Makefile的规则Makefile的规则如下，这里的[TAB]指键盘上的TAB按键，不是空格，如果在命令前输入了空格则会造成错误，并且在Makefile中TAB键不能随意使用：目标 : 依赖[TAB]命令 例如：Hello :       @echo “Hello”这时执行make命令就会输出一条语句”Hello”，Hello是目标，依赖为空，为了生成目标，需要执行echo “Hello”语句，从而导致输出Hello。 例如：假设我们有一个Hello.c C语言源文件，需要将其编译不链接为Hello.o文件，最后在进行连接，Makefile内容如下：Hello.out : Hello.o       gcc -o Hello.out Hello.oHello.o : Hello.c       gcc -c -o Hello.o Hello.c这时执行make命令，make解释器发现目标为“Hello.out”，但是生成Hello.out需要Hello.o，发现目录下找不到“Hello.o”，就向下查找是否有生成Hello.o的规则，找到了，发现”Hello.o”依赖于”Hello.c”，在目录下也找到了Hello.c，就执行语句“gcc -c -o Hello.o Hello.c”生成”Hello.o”，只要编译过程不出错，即可得到”Hello.o”，这时可以执行“gcc -o Hello.out Hello.o“生成”Hello.out”从哪里开始分析？这里可以用分析一个C语言或Java语言程序来类比，一般都是根据程序是执行流来进行分析，也就是先找到main函数，因为main函数是程序的执行入口，Makefile也有执行入口，在执行make命令时，make解释器默认搜索当前目录下名为“Makefile”的文件，找到后，执行生成第一个目标的命令及生成其依赖所需的命令。这里选择在SDK/Targets目录中STM32L431_BearPi工程中的GCC目录下的Makefile开始分析。第1行到第140行都是设置一些变量和导入一些makefile文件（其中也没有任何规则，都是进行一些变量的设置），第143行是第一条规则当我们执行make或make all时，就开始生成all目标，其依赖于BUILD_DIR（GCC/build）目录中的TARGET（Huawei_LiteOS）.elf文件，BUILD_DIR和TARGET为两个变量，一开始就被赋值，如下图所示，实际使用时$(变量)会被替换为变量的值，例如$(TARGET).elf最终会被替换为Huawei_LiteOS.elf。可是Huawei_LiteOS.elf还不存在，make只好继续向下查找是否有生成Huawei_LiteOS.elf的规则，好在第147行的目标为Huawei_LiteOS.elf，这就是生成Huawei_LiteOS.elf的规则，该规则依赖为$(OBJ_DIRS) $(C_OBJ) $(S_OBJ)分别对应三个目录，这三个目录都不存在，所以make只好继续向下查找，它发现第152行正好为目标是该目录的规则，就创建了该目录，解决了$(OBJ_DIRS)这个依赖，接着该处理$(C_OBJ)这个依赖Make向下查找依赖发现位于第156行出现生成这个以来的规则，这里的$(C_OBJ):$(BUILD_DIR)/%.o:%.c对应makefile中的静态模式，我这里简单的说一下，大家如果想深入了解可以自行百度。静态模型的格式如下：目标列表: 与目标列表相匹配的模型: 与依赖相匹配的模型[TAB]命令来看一个例子， 目标列表中有foo.o、bar.o和test.s三个值，首先将匹配%.o的模型找出来，test.s不匹配就被遗弃了，将匹配的foo.o和bar.o替换为foo.c和bar.c，最终这一条规则等于执行了下列这两条规则，为什么要这样做呢？你可以试想以下，假设目标列表中有几千个文件，这样做的话是不是就可以少写很多规则：       回到LiteOS_Lab的Makefile上来，156行将C_OBJ变量中的符合build/xxx.o格式的文件作为xxx.c格式的依赖，C_OBJ变量的赋值如下图所示：$(patsubst PATTERN, REPLACEMENT, TEXT)函数的作用是模式替换，将TEXT中以空格隔开的每个单词(文件名)，符合PATTERN格式的替换为REPLACEMENT格式，例如第124行，将所有的C_SOURCE变量中的文件名，凡是只要在SDK/ iot_link目录下的都替换为.o后缀，SDK/ iotlink目录中有一个符合该模型的文件，link_main.c，在执行该规则对应的命令时，目标文件为link_main.o，第125和126行同上。这里以link_main.c为例向大家讲解指令，经过模式替换后规则如下：link_main.o: link_main.c       $(CC) -c $(CFLAGS) -Wa,-a,-ad,-alms=$(@:%.o=%.lst) $<  -o $@这里的CC是指arm-none-eabi-gcc，CFLAGS是指各类编译参数，例如-MMD -MP -Wno-missing-braces，$(@:%.o=%.lst)函数的作用是将$@目标符合%.o模型的值替换为%. lst，这里就将link_main.o替换link_main. lst，$<是指第一个依赖，$@是指目标，组合的命令后如下：arm-none-eabi-gcc -c -MMD -MP -Wno-missing-braces -Wa,-a,-ad,-alms=link_main. lst link_main.c  -o link_main.o。一句话来说就是将所有的.c源文件编译不链接生成.o文件和.lst文件，等待后续进一步操作。第160和161行的操作类似于上面的操作，将所有的汇编文件都编译不链接生成.o文件等待后续进一步操作。

摘要：本节将对前几节中创建好的工程进行进一步的修改，使其适配我们的STM32L476一、修改GCC/project.mk文件project.mk文件主要用于指示我们的arm-gcc工具链如何对我们的工程文件进行编译操作，有关编译、链接等操作可以参考0x01基础知识中的介绍。首先将文件中所有的STM32L431_BearPi_OS_Func全部替换为STM32L476RG_NB476在HAL_DRIVER_SRC 变量中删除我们没有用到的STM32的库文件，并添加上使用了没有添加的文件，修改好后如下图在HARDWARE_SRC变量中删除我们没有使用的外设驱动文件，添加上使用了的外设驱动文件，修改后如下图，以下用到的驱动代码给大家在附件中放上，解压到Hardware文件夹即可在USER_SRC变量中删除我们没有使用的内部外设初始化，添加上使用了的内部外设初始化文件，也就是也就是前面我们勾选的将初始化代码分别生成到不同文件中的选项，修改后如下图：并将C_DEFS +=  -D USE_HAL_DRIVER -D STM32L431xx -D NDEBUG中的STM32L431xx替换为STM32L476xx二、再次复制部分文件从targets\STM32L431_BearPi\Src和Inc中复制以下文件到我们的Src和Inc中dwt.c  dwt.h   用于延时sys_init.c sys_init.h 用于配置系统时钟、获取随机数、重启系统等ota_port.c 用于OTAflash_adaptor.c 用于读、写Flashuart_debug.c    用于实现fputc和fgetc、处理串口中断、初始化shellat_hal.h            用于发送AT指令board.h            OTA相关common.h        OTA相关PS：附件中的“资料”是我修改好的project.mk和Hardware中用到的驱动文件，解压后，将project.mk放到GCC目录下即可，将其余文件放到Hardware目录下即可！

如题，我对hiai_demo更改了一点，但是用到了ros，在进行工程编译时，需要用到ros相关的库。假如我的ros的库的路径为：/opt/ros/kinetic我应该如何更改makefile-main以及makefile-so这两个文件。

一、准备工作    1、到openssl官网下载最新版本openssl（如openssl-1.1.1d.tar.gz），上传到linux编译机上（如上传到目录/home/test下），并使用tar -xvf openssl-1.1.1d.tar.gz解压：        2、将要用到的交叉编译工具链解压后，找到交叉编译器所在路径（如果直接使用系统的gcc，可跳过这一步，但要保证gcc已安装）：        注意：gcc/g++/ar/ranlib/nm等文件的名字根据编译链的不同，文件名开头会有所不同，但文件名结尾是不变的，如arm架构比较常见的编译器是arm-linux-gcc二、配置       进入openssl源码目录，运行如下配置命令    ./config shared --prefix=/home/test/openssl --openssldir=/home/test/openssl/ssl或./config  no-asm shared --prefix=/home/test/openssl --openssldir=/home/test/openssl/ssl    其中prefix 是安装目录，openssldir 是配置文件目录，shared 作用是生成动态链接库(即.so库)     注意：no-asm表示不使用汇编代码，如果编译有问题再加，没有问题就不加        注意： 如果遇到64位的编译链，需要添加sysroot参数，用如下命令配置（+参考图片）：    ./config no-asm shared --prefix=/home/test/openssl --openssldir=/home/test/openssl/ssl --sysroot="{头文件所在路径}"        一般来说，头文件所在路径 与 XXX-gcc/g++/ar/nm等（XXX是交叉编译器名字的前缀）的所在目录不一样，在另外一个大目录下（如下图所示）        Tips:     可以先用find ./ -name *-gcc命令找到gcc/g++/ar/ranlib/nm等文件所在目录，那另一个目录就是头文件所在路径        从上图看，gcc/g++/ar/ranlib/nm等文件在sysroots/x86_64-fslsdk-linux的某目录，所以头文件一般在另一个目录sysroots/ppc64e6500-fsl-linux下，且sysroots/ppc64e6500-fsl-linux下的usr/include目录下面有许多（不是一两个）头文件（也就是说--sysroot的值是usr/include所在的目录）：    三、修改Makefile    配置完成后会在openssl源码目录下生成一个Makefile文件，打开查看内容，会看到CROSS_COMPILE的值是空的        这时要将CROSS_COMPILE的值修改为XXX-gcc所在绝对路径+XXX-gcc的文件名前缀（参考下图），也就是说要先找到交叉编译工具xxx-gcc/g++/ar/nm等文件所在路径（其中“XXX-”是交叉编译工具文件名前缀）：        修改CROSS_COMPILE的值最终是为了修改arm-linux-xxx-gcc/ar/ranlib/nm等的路径，在比较老的openssl版本中，没有CROSS_COMPILE参数，需要修改如下5个变量的值 (注意下图所用的交叉编译工具不是跟前面的不一样，所以路径也不同)：    四、编译出库        修改完Makefile后就可以进行编译了，到openssl源码目录下，运行make命令：    openssl源码目录下，运行make命令：    make    如果没有报错，再运行make install    make install    在配置的openssl安装目录下/home/test/openssl找到lib目录，有如下两个文件：    libcrypto.so.1.1、libssl.so.1.1和软链接libcrypto.so、libssl.so        五、其他说明    1、交叉编译工具不是在任何环境上都可使用的，需要系统环境和编译工具匹配才可以，主要看CPU和指令集    2、如果不需要交叉编译工具，而是直接使用gcc，那么，配置生成Makefile后不需要修改Makefile（即跳过第三步），直接编译即可    3、如果make出错后修改了Makefile，记得make clean后再make    4、有的编译工具是32位的，如果在64位的linux机器上使用，可能会报如下错误，这时只要将Makefile中的-m64都删除，再进行编译即可          

文档位置已迁移至如下链接：https://support.huaweicloud.com/prtg-kunpenghpcs/kunpenghpcs_prtg_0005.html

文档位置已迁移至如下链接：https://support.huaweicloud.com/tstg-kunpenghpcs/kunpenghpcs_tstg_0003.html