OpenHarmony(鸿蒙南向开发)——轻量系统STM32F407芯片移植案例

往期知识点记录:

  • 鸿蒙(HarmonyOS)应用层开发(北向)知识点汇总
  • 鸿蒙(OpenHarmony)南向开发保姆级知识点汇总~
  • OpenHarmony(鸿蒙南向开发)——轻量和小型系统三方库移植指南(一)
  • OpenHarmony(鸿蒙南向开发)——轻量和小型系统三方库移植指南(二)
  • OpenHarmony(鸿蒙南向开发)——轻量系统芯片移植案例(一)
  • OpenHarmony(鸿蒙南向开发)——轻量系统芯片移植案例(二)
  • OpenHarmony(鸿蒙南向开发)——轻量系统芯片移植案例(三)
  • OpenHarmony(鸿蒙南向开发)——轻量系统STM32F407芯片移植案例
  • 持续更新中……

轻量系统STM32F407芯片移植案例

介绍基于STM32F407IGT6芯片在拓维信息 Niobe407 开发板上移植OpenHarmony LiteOS-M轻量系统,提供交通、工业领域开发板解决方案。移植架构采用BoardSoC分离方案,使用arm gcc工具链Newlib C库,实现了lwiplittlefshdf等子系统及组件的适配,开发了配套应用示例代码,支持通过Kconfig图形化配置编译选项。

适配准备

  • 下载 stm32cubemx 图形工具。
  • 准备ubuntu20.04系统环境,安装 arm-none-eabi-gcc 交叉编译工具链。

生成可用工程

通过stm32cubemx工具生成STM32F407IGT6芯片的Makefile工程,在此给出如下配置建议:

  • 系统相关配置采用默认配置。
  • 时钟配置时将SYSCLK选项配置为168MHz,发挥芯片最强性能。
  • 配置USART1用作调试串口,用来打印适配过程中的调试信息。
  • 配置stm32cubemx工程选项时,将Toolchain/IDE选项选为Makefile。

生成的工程目录如下:

├── Core
│   ├── Inc
│   │    ├── main.h
│   │    ├── stm32f4xx_hal_conf.h
│   │    └── stm32f4xx_it.h
│   └── Src
│        ├── main.c                --- 主函数
│        ├── stm32f4xx_hal_msp.c   --- HAL库弱函数配置文件
│        ├── stm32f4xx_it.c        --- 中断回调函数文件
│        └── system_stm32f4xx.c    --- 系统
├── Drivers
│   ├── CMSIS                      --- CMSIS接口
│   └── STM32F4xx_HAL_Driver       --- HAL库驱动
├── Makefile                       --- Makefile编译
├── STM32F407IGTx_FLASH.ld         --- 链接文件
├── startup_stm32f407xx.s          --- 启动文件
└── stm32f407_output.ioc           --- stm32cubemx工程文件

验证生成的工程

将生成的工程拷贝至Ubuntu,进入工程目录下执行make命令编译,确定能够编译成功。

arm-none-eabi-gcc build/main.o build/stm32f4xx_it.o build/stm32f4xx_hal_msp.o build/stm32f4xx_hal_tim.o build/stm32f4xx_hal_tim_ex.o build/stm32f4xx_hal_uart.o build/stm32f4xx_hal_rcc.o build/stm32f4xx_hal_rcc_ex.o build/stm32f4xx_hal_flash.o build/stm32f4xx_hal_flash_ex.o build/stm32f4xx_hal_flash_ramfunc.o build/stm32f4xx_hal_gpio.o build/stm32f4xx_hal_dma_ex.o build/stm32f4xx_hal_dma.o build/stm32f4xx_hal_pwr.o build/stm32f4xx_hal_pwr_ex.o build/stm32f4xx_hal_cortex.o build/stm32f4xx_hal.o build/stm32f4xx_hal_exti.o build/system_stm32f4xx.o build/startup_stm32f407xx.o -mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=hard -specs=nano.specs -TSTM32F407IGTx_FLASH.ld  -lc -lm -lnosys  -Wl,-Map=build/stm32f407_output.map,--cref -Wl,--gc-sections -o build/stm32f407_output.elf
arm-none-eabi-size build/stm32f407_output.elftext    data     bss     dec     hex filename5000      20    1636    6656    1a00 build/stm32f407_output.elf
arm-none-eabi-objcopy -O ihex build/stm32f407_output.elf build/stm32f407_output.hex
arm-none-eabi-objcopy -O binary -S build/stm32f407_output.elf build/stm32f407_output.bin

编译完成会生成一个.bin文件,为了确认该程序能在开发板中成功运行,需要main函数中的串口初始化之后,通过串口输出一段字符串,运行时若收到打印信息,则开发板启动成功。

printf("hello world!!\r\n");

适配printf输出到串口,只需要重写_write函数即可,参考如下:

#include <stdio.h>int _write(int fd, char *ptr, int len)
{ return HAL_UART_Transmit(&huart1, (uint8_t *)ptr, len, 0xFFFF); 
}

重新编译代码,将其烧录至开发板中验证。

编译构建

目录规划

芯片适配目录规划为:

device
├── board                                --- 单板厂商目录
│   └── talkweb                          --- 单板厂商名字:拓维信息
│       └── niobe407                     --- 单板名:与产品名一致
└── soc									 --- SoC厂商目录└── st                               --- SoC厂商名称└── stm32f4xx					 --- SoC Series名:stm32f4xx是一个系列,包含该系列soc相关代码

产品样例目录规划为:

vendor
└── talkweb							     --- 开发产品样例厂商目录└── niobe407         			     --- 产品名字:niobe407

获取 OpenHarmony源码 ,根据上述目录规划,创建相应文件夹。

预编译适配

预编译适配内容就是围绕hb set命令的适配,使工程能够通过该命令设置根目录、单板目录、产品目录、单板公司名等环境变量,为后续适配编译做准备。

具体的预编译适配步骤如下:

1.在vendor/talkweb/niobe407目录下新增config.json文件,用于描述这个产品样例所使用的单板、内核等信息,描述信息可参考如下内容:

{"product_name": "niobe407",           --- 用于hb set进行选择时,显示的产品名称"type": "mini",                       --- 构建系统的类型,mini/small/standard"version": "3.0",                     --- 构建系统的版本,1.0/2.0/3.0"device_company": "talkweb",          --- 单板厂商名,用于编译时找到/device/board/talkweb目录"board": "niobe407",                  --- 单板名,用于编译时找到/device/board/talkweb/niobe407目录"kernel_type": "liteos_m",            --- 内核类型,因为OpenHarmony支持多内核,一块单板可能适配了多个内核,所以需要指定某个内核进行编译"kernel_version": "3.0.0",            --- 内核版本,一块单板可能适配了多个linux内核版本,所以需要指定某个具体的内核版本进行编译"subsystems": [ ]                     --- 选择所需要编译构建的子系统
}

2.在//device/board/talkweb/niobe407目录下创建board目录,在创建的目录下新增一个config.gni文件,用于描述该产品的编译配置信息:

# Kernel type, e.g. "linux", "liteos_a", "liteos_m".
kernel_type = "liteos_m"                --- 内核类型,跟config.json中kernel_type对应# Kernel version.
kernel_version = "3.0.0"                --- 内核版本,跟config.json中kernel_version对应

3.验证hb set配置是否正确,输入hb set能够显示如下信息:

4.通过hb env可以查看选择出来的预编译环境变量:

5.hb介绍

hb是OpenHarmony为了方便开发者进行代码构建编译,提供的python脚本工具,其源码就在//build/lite仓库目录下。在执行hb set命令时,脚本会遍历//vendor/<product_company>/<product_name>目录下的config.json,给出可选产品编译选项。在config.json文件中,product_name表示产品名,device_company和board用于关联出//device/board/<device_company>/目录,匹配该目录下的<any_dir_name>/config.gni文件,其中<any_dir_name>目录名可以是任意名称,但建议将其命名为适配内核名称(如:liteos_m、liteos_a、linux)。hb命令如果匹配到了多个config.gni,会将其中的kernel_type和kernel_version字段与vendor/<device_company>下config.json文件中的字段进行匹配,从而确定参与编译的config.gni文件。

至此,预编译适配完成,但工程还不能执行hb build进行编译,还需要准备好后续的LiteOS-M内核移植。

内核移植

内核移植需要完成LiteOS-M Kconfig适配、gn的编译构建和内核启动最小适配。

Kconfig文件适配

1.在//vendor/talkweb/niobe407目录下创建kernel_configs目录,并创建空文件,命名为debug.config。

2.打开//kernel/liteos_m/Kconfig文件,可以看到在该文件通过orsource命令导入了//device/board//device/soc下多个Kconfig文件,后续需要创建并修改这些文件:

orsource "../../device/board/*/Kconfig.liteos_m.shields"
orsource "../../device/board/$(BOARD_COMPANY)/Kconfig.liteos_m.defconfig.boards"
orsource "../../device/board/$(BOARD_COMPANY)/Kconfig.liteos_m.boards"
orsource "../../device/soc/*/Kconfig.liteos_m.defconfig"
orsource "../../device/soc/*/Kconfig.liteos_m.series"
orsource "../../device/soc/*/Kconfig.liteos_m.soc"

3.在//device/board/talkweb下参考如下目录结构创建相应的Kconfig文件:

.
├── Kconfig.liteos_m.boards
├── Kconfig.liteos_m.defconfig.boards
├── Kconfig.liteos_m.shields
└── niobe407├── Kconfig.liteos_m.board                --- 开发板配置选项├── Kconfig.liteos_m.defconfig.board      --- 开发板默认配置选项└── liteos_m└── config.gni
  1. 修改Kconfig文件内容:
  • //device/board/talkweb/Kconfig.liteos_m.boards文件中添加:
            if SOC_STM32F407orsource "niobe407/Kconfig.liteos_m.board"    --- 可根据SOC定义,加载指定board目录定义endif
  • //device/board/talkweb/Kconfig.liteos_m.defconfig.boards文件中添加:
            orsource "*/Kconfig.liteos_m.defconfig.board"
  • //device/board/talkweb/Kconfig.liteos_m.defconfig.boards文件中添加:
           orsource "shields/Kconfig.liteos_m.shields"
  • //device/board/talkweb/niobe407/Kconfig.liteos_m.board文件中添加:
            menuconfig BOARD_NIOBE407bool "select board niobe407"depends on SOC_STM32F407	 --- niobe407使用的是stm32f407的SoC,只有SoC被选择后,niobe407的配置选项才可见、可以被选择。
  • //device/board/talkweb/niobe407/Kconfig.liteos_m.defconfig.board中添加:
            if BOARD_NIOBE407--- 用于添加BOARD_NIOBE407默认配置endif #BOARD_NIOBE407
  • //device/soc/st下参考如下目录结构创建相应的Kconfig文件,并将stm32cubemx自动生成工程中的Drivers目录拷贝至stm32f4xx/sdk目录下:
        .├── Kconfig.liteos_m.defconfig├── Kconfig.liteos_m.series├── Kconfig.liteos_m.soc└── stm32f4xx├── Kconfig.liteos_m.defconfig.series├── Kconfig.liteos_m.defconfig.stm32f4xx├── Kconfig.liteos_m.series├── Kconfig.liteos_m.soc└── sdk└── Drivers├── CMSIS└── STM32F4xx_HAL_Driver

6.修改Kconfig文件内容:

  • //device/soc/st/Kconfig.liteos_m.defconfig中添加:
    rsource "*/Kconfig.liteos_m.defconfig.series"
  • //device/soc/st/Kconfig.liteos_m.series中添加:
    rsource "*/Kconfig.liteos_m.series"
  • //device/soc/st/Kconfig.liteos_m.soc中添加:
    config SOC_COMPANY_STMICROELECTRONICSboolif SOC_COMPANY_STMICROELECTRONICSconfig SOC_COMPANYdefault "st"rsource "*/Kconfig.liteos_m.soc"endif # SOC_COMPANY_STMICROELECTRONICS
  • //device/soc/st/stm32f4xx/Kconfig.liteos_m.defconfig.series中添加:
    if SOC_SERIES_STM32F4xxrsource "Kconfig.liteos_m.defconfig.stm32f4xx"config SOC_SERIESstringdefault "stm32f4xx"endif
  • //device/soc/st/stm32f4xx/Kconfig.liteos_m.defconfig.stm32f4xx中添加:
    config SOCstringdefault "stm32f4xx"depends on SOC_STM32F4xx
  • //device/soc/st/stm32f4xx/Kconfig.liteos_m.series中添加:
    config SOC_SERIES_STM32F4xxbool "STMicroelectronics STM32F4xx series"select ARCH_ARMselect SOC_COMPANY_STMICROELECTRONICSselect CPU_CORTEX_M4helpEnable support for STMicroelectronics STM32F4xx series
  • //device/soc/st/stm32f4xx/Kconfig.liteos_m.soc中添加:
    choiceprompt "STMicroelectronics STM32F4xx series SoC"depends on SOC_SERIES_STM32F4xxconfig SOC_STM32F407bool "SoC STM32F407"endchoice
  1. kernel/liteos_m目录下执行make menuconfig,使得能够对SoC Series进行选择:

结果将自动保存在$(PRODUCT_PATH)/kernel_configs/debug.config,下次执行make menuconfig时会导出保存的结果。

BUILD.gn文件适配

为了快速熟悉gn的编译和适配,建议先阅读 LiteOS-M内核BUILD.gn编写指南。

(注意,BUILD.gn文件中不要出现tab字符,所有tab用空格代替)

  1. kernel/liteos_m/BUILD.gn 中,可以看到,通过deps指定了BoardSoC的编译入口:
    deps += [ "//device/board/$device_company" ]            --- 对应//device/board/talkweb目录deps += [ "//device/soc/$LOSCFG_SOC_COMPANY" ]          --- 对应//device/soc/st目录
  1. //device/board/talkweb/BUILD.gn中,新增内容如下:
    if (ohos_kernel_type == "liteos_m") {import("//kernel/liteos_m/liteos.gni")module_name = get_path_info(rebase_path("."), "name")module_group(module_name) {modules = [ "niobe407" ]}}

3.在niobe407目录下创建BUILD.gn,为了方便管理,将目录名作为模块名:

    import("//kernel/liteos_m/liteos.gni")module_name = get_path_info(rebase_path("."), "name")module_group(module_name) {modules = [ "liteos_m",]}

4.将stm32cubemx生成的示例工程Core目录下的文件、startup_stm32f407xx.s启动文件和STM32F407IGTx_FLASH.ld链接文件拷贝至//device/board/talkweb/niobe407/liteos_m/目录下,并在该目录下创建BUILD.gn,添加如下内容:

import("//kernel/liteos_m/liteos.gni")
module_name = get_path_info(rebase_path("."), "name")
kernel_module(module_name) {sources = ["startup_stm32f407xx.s","Src/main.c","Src/stm32f4xx_hal_msp.c","Src/stm32f4xx_it.c","Src/system_stm32f4xx.c",]include_dirs = [ "Inc",]
}config("public") {ldflags = ["-Wl,-T" + rebase_path("STM32F407IGTx_FLASH.ld"),"-Wl,-u_printf_float",]libs = ["c","m","nosys",]
}

5.在make menuconfig中配置(Top) → Compat → Choose libc implementation,选择newlibc。

6.由于_write函数会与kernel的文件操作函数重名,会导致编译失败。后续会换一种方法来适配printf函数,此处我们先将main.c文件中对_write函数的重写删除,将printf函数改用如下方式进行串口打印测试。

uint8_t test[]={"hello niobe407!!\r\n"};
int len = strlen(test);
HAL_UART_Transmit(&huart1, (uint8_t *)test, len, 0xFFFF);

7.同理//device/soc/st/BUILD.gn也是一样,按照目录结构层层依赖包含,最终在//device/soc/st/stm32f4xx/sdk/BUILD.gn中通过kernel_module模板中指定需要参与编译的文件及编译参数,参考如下:

import("//kernel/liteos_m/liteos.gni")
module_name = "stm32f4xx_sdk"
kernel_module(module_name) {asmflags = board_asmflagssources = ["Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_rcc.c","Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_rcc_ex.c","Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_gpio.c","Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_dma_ex.c","Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_dma.c","Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_cortex.c","Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal.c","Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_exti.c","Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_uart.c",]
}
#指定全局头文件搜索路径
config("public") {include_dirs = ["Drivers/STM32F4xx_HAL_Driver/Inc","Drivers/CMSIS/Device/ST/STM32F4xx/Include",]
}

config.gni文件适配

在预编译阶段,在//device/board/talkweb/niobe407/liteos_m目录下创建了一个config.gni文件,它其实就是gn脚本的头文件,可以理解为工程构建的全局配置文件。主要配置了CPU型号、交叉编译工具链及全局编译、链接参数等重要信息:

# Kernel type, e.g. "linux", "liteos_a", "liteos_m".
kernel_type = "liteos_m"# Kernel version.
kernel_version = "3.0.0"# Board CPU type, e.g. "cortex-a7", "riscv32".
board_cpu = "cortex-m4"# Board arch, e.g.  "armv7-a", "rv32imac".
board_arch = ""# Toolchain name used for system compiling.
# E.g. gcc-arm-none-eabi, arm-linux-harmonyeabi-gcc, ohos-clang,  riscv32-unknown-elf.
# Note: The default toolchain is "ohos-clang". It's not mandatory if you use the default toolchain.
board_toolchain = "arm-none-eabi-gcc"use_board_toolchain = true# The toolchain path installed, it's not mandatory if you have added toolchain path to your ~/.bashrc.
board_toolchain_path = ""# Compiler prefix.
board_toolchain_prefix = "arm-none-eabi-"# Compiler type, "gcc" or "clang".
board_toolchain_type = "gcc"#Debug compiler optimization level options
board_opt_flags = ["-mcpu=cortex-m4","-mthumb","-mfpu=fpv4-sp-d16","-mfloat-abi=hard",
]# Board related common compile flags.
board_cflags = ["-Og","-Wall","-fdata-sections","-ffunction-sections","-DSTM32F407xx",
]
board_cflags += board_opt_flagsboard_asmflags = ["-Og","-Wall","-fdata-sections","-ffunction-sections",
]
board_asmflags += board_opt_flagsboard_cxx_flags = board_cflagsboard_ld_flags = board_opt_flags# Board related headfiles search path.
board_include_dirs = [ "//utils/native/lite/include" ]# Board adapter dir for OHOS components.
board_adapter_dir = ""

如上所示,比较难理解的就是board_opt_flags、board_cflags、board_asmflags等几个参数配置。可以参考如下描述,从stm32cubemx生成的工程中的Makefile文件中提取出来:

board_opt_flags : 编译器相关选项,一般为芯片架构、浮点类型、编译调试优化等级等选项。
board_asmflags  :汇编编译选项,与Makefile中的ASFLAGS变量对应。
board_cflags    :C代码编译选项,与Makefile中的CFLAGS变量对应。
board_cxx_flags :C++代码编译选项,与Makefile中的CXXFLAGS变量对应。
board_ld_flags  :链接选项,与Makefile中的LDFLAGS变量对应。

内核子系统适配

在//vendor/talkweb/niobe407/config.json文件中添加内核子系统及相关配置,如下所示:

{"product_name": "niobe407","type": "mini","version": "3.0","device_company": "talkweb","board": "niobe407","kernel_type": "liteos_m","kernel_version": "3.0.0","subsystems": [ {"subsystem": "kernel","components": [{"component": "liteos_m"}]}],"product_adapter_dir": "","third_party_dir": "//third_party"
}

target_config.h文件适配

在//kernel/liteos_m/kernel/include/los_config.h文件中,有包含一个名为target_config.h的头文件,如果没有这个头文件,则会编译出错。

该头文件的作用主要是定义一些与soc芯片相关的宏定义,可以创建一个空头文件,再配合编译报错提示信息来确定需要定义哪些宏。经验证,Cortex-M4的核适配只需定义LOSCFG_BASE_CORE_TICK_RESPONSE_MAX宏并包含stm32f4xx.h头文件即可将kernel编译通过。

若前期不知如何配置,可以参考虚拟机qemu示例中//device/qemu/arm_mps2_an386/liteos_m/board/target_config.h的配置。

#ifndef _TARGET_CONFIG_H
#define _TARGET_CONFIG_H#define LOSCFG_BASE_CORE_TICK_RESPONSE_MAX                  0xFFFFFFUL
#include "stm32f4xx.h"			//包含了stm32f4平台大量的宏定义#endif

其中宏定义LOSCFG_BASE_CORE_TICK_RESPONSE_MAX是直接参考的//device/qemu/arm_mps2_an386/liteos_m/board/target_config.h文件中的配置,//device/qemu/arm_mps2_an386cortex-m4的虚拟机工程,后续适配可以直接参考,在此不做深入讲解。

内核启动适配

至此,已经可以成功将kernel子系统编译通过,并且在out目录下生成OHOS_Image.bin文件。将生成的OHOS_Image.bin文件烧录至开发板,验证板子能否正常启动运行,如果能成功打印出main函数中串口输出的正确的打印信息,则可以开始进行内核启动适配。

1.为liteos_m分配内存,适配内存分配函数

在文件//kernel/liteos_m/kernel/src/mm/los_memory.c中,OsMemSystemInit函数通过LOS_MemInit进行了内存初始化。可以看到几个比较关键的宏需要我们指定,我们将其添加到target_config.h中:

extern unsigned int __los_heap_addr_start__;
extern unsigned int __los_heap_addr_end__;
#define LOSCFG_SYS_EXTERNAL_HEAP 1
#define LOSCFG_SYS_HEAP_ADDR ((void *)&__los_heap_addr_start__)
#define LOSCFG_SYS_HEAP_SIZE (((unsigned long)&__los_heap_addr_end__) - ((unsigned long)&__los_heap_addr_start__))

其中,__los_heap_addr_start__与__los_heap_addr_end__变量在STM32F407IGTx_FLASH.ld链接文件中被定义, 将_user_heap_stack花括号内内容修改为:

._user_heap_stack :
{. = ALIGN(0x40);__los_heap_addr_start__ = .;__los_heap_addr_end__ = ORIGIN(RAM) + LENGTH(RAM);
} >RAM

除此之外,我们还需要适配内存分配函数,由于内核中已经对_malloc_r等内存分配函数进行了实现,在此我们采用包装函数的方式来适配,用内核中的内存分配函数替换标准库中的内存分配函数即可,在//device/board/talkweb/niobe407/liteos_m/config.gni中board_ld_flags链接参数变量修改为:

board_ld_flags = ["-Wl,--wrap=_calloc_r","-Wl,--wrap=_malloc_r","-Wl,--wrap=_realloc_r","-Wl,--wrap=_reallocf_r","-Wl,--wrap=_free_r","-Wl,--wrap=_memalign_r","-Wl,--wrap=_malloc_usable_size_r",
]
board_ld_flags += board_opt_flags

2.适配printf打印

为了方便后续调试,第一步需要先适配printf函数。而printf的函数适配可大可小,在此只做简单适配,具体实现可以参考其它各开发板源码。

在main.c同级目录下创建dprintf.c文件,文件内容如下:

#include <stdarg.h>
#include "los_interrupt.h"
#include <stdio.h>extern UART_HandleTypeDef huart1;INT32 UartPutc(INT32 ch, VOID *file)
{char RL = '\r';if (ch =='\n') {HAL_UART_Transmit(&huart1, &RL, 1, 0xFFFF);}return HAL_UART_Transmit(&huart1, (uint8_t *)&ch, 1, 0xFFFF);
}static void dputs(char const *s, int (*pFputc)(int n, FILE *cookie), void *cookie)
{unsigned int intSave;intSave = LOS_IntLock();while (*s) {pFputc(*s++, cookie);}LOS_IntRestore(intSave);
}int printf(char const  *fmt, ...)
{char buf[1024] = { 0 };va_list ap;va_start(ap, fmt);int len = vsnprintf_s(buf, sizeof(buf), 1024 - 1, fmt, ap);va_end(ap);if (len > 0) {dputs(buf, UartPutc, 0);} else {dputs("printf error!\n", UartPutc, 0);}return len;
}

在串口初始化之后使用printf函数打印,测试是否适配成功。

3.调用LOS_KernelInit初始化内核,进入任务调度。

在main函数中串口初始化之后,调用LOS_KernelInit进行初始化,创建任务示例,进入任务调度。

#include "los_task.h"UINT32 ret;
ret = LOS_KernelInit();  //初始化内核
if (ret == LOS_OK) {TaskSample();  //示例任务函数,在此函数中创建线程任务LOS_Start();   //开始任务调度,程序执行将阻塞在此,由内核接管调度
}

其中TaskSample()函数内容如下:

VOID TaskSampleEntry2(VOID)
{while (1) {printf("TaskSampleEntry2 running...\n");(VOID)LOS_TaskDelay(2000); /* 2000 millisecond */}
}VOID TaskSampleEntry1(VOID)
{while (1) {printf("TaskSampleEntry1 running...\n");(VOID)LOS_TaskDelay(2000); /* 2000 millisecond */}
}
VOID TaskSample(VOID)
{UINT32 uwRet;UINT32 taskID1;UINT32 taskID2;TSK_INIT_PARAM_S stTask = {0};stTask.pfnTaskEntry = (TSK_ENTRY_FUNC)TaskSampleEntry1;stTask.uwStackSize = 0x1000;stTask.pcName = "TaskSampleEntry1";stTask.usTaskPrio = 6; /* Os task priority is 6 */uwRet = LOS_TaskCreate(&taskID1, &stTask);if (uwRet != LOS_OK) {printf("Task1 create failed\n");}stTask.pfnTaskEntry = (TSK_ENTRY_FUNC)TaskSampleEntry2;stTask.uwStackSize = 0x1000;stTask.pcName = "TaskSampleEntry2";stTask.usTaskPrio = 7; /* Os task priority is 7 */uwRet = LOS_TaskCreate(&taskID2, &stTask);if (uwRet != LOS_OK) {printf("Task2 create failed\n");}
}

适配完内核启动后,可以通过调试串口看到如下打印信息:

后续还需要对整个基础内核进行详细适配验证。

内核基础功能适配

内核基础功能适配项包括:中断管理任务管理内存管理内核通信机制时间管理软件定时器,可以参考对应链接中的编程实例进行内核基础功能验证。在验证的过程中发现问题,针对相应问题进行具体的适配。

从上一节中打印信息输出时间间隔可以看出,LOS_TaskDelay函数的延时时间不准确,我们可以在target_config.h中定义如下宏进行内核时钟适配:

#define OS_SYS_CLOCK                                        168000000
#define LOSCFG_BASE_CORE_TICK_PER_SECOND                    (1000UL)

其它内核基础功能的适配方法大多也是围绕于target_config.h中的宏定义,需要大家配合//kernel/liteos_m下源码,自行尝试摸索,在此不做进一步讲解。

littlefs文件系统移植适配

Niobe407开发板外挂了16MB的SPI-FLASH,Niobe407基于该Flash进行了littlefs适配。

内核已经对littlefs进行了适配,我们只需要开启Kconfig中的配置,然后适配Littlefs如下接口:

  int32_t LittlefsRead(const struct lfs_config *cfg, lfs_block_t block,lfs_off_t off, void *buffer, lfs_size_t size){W25x_BufferRead(buffer, cfg->context + cfg->block_size * block + off, size);return LFS_ERR_OK;}int32_t LittlefsProg(const struct lfs_config *cfg, lfs_block_t block,lfs_off_t off, const void *buffer, lfs_size_t size){W25x_BufferWrite((uint8_t *)buffer,cfg->context + cfg->block_size * block + off,size);return LFS_ERR_OK;}int32_t LittlefsErase(const struct lfs_config *cfg, lfs_block_t block){W25x_SectorErase(cfg->context + cfg->block_size * block);return LFS_ERR_OK;}int32_t LittlefsSync(const struct lfs_config *cfg){return LFS_ERR_OK;}

W25x_BufferRead等函数是spi-flash读写操作的接口,不同型号的spi-flash其实现也不同,Niobe407的SPI-Flash操作具体实现可参考//device/board/talkweb/niobe407/liteos_m/drivers/spi_flash/src/w25qxx.c

由于SPI已经hdf化了,而littlefs依赖于spi驱动,为了方便对文件系统进行配置,可以将littlefs的配置加入至.hcs文件中,具体参考://device/board/talkweb/niobe407/liteos_m/hdf_config/hdf_littlefs.hcs文件

misc {littlefs_config {match_attr = "littlefs_config";mount_points = ["/talkweb"];partitions = [0x800000];block_size = [4096];block_count = [256];}
}

板级驱动移植

驱动适配相关文件放置在//drivers/adapter/platform中,对应有gpioi2cpwmspiuartwatchdog,都是通过HDF机制加载,本章节以pwm为例进行说明。

PWM驱动适配

在HDF框架中,PWM的接口适配模式采用独立服务模式,在这种模式下,每一个设备对象会独立发布一个设备服务来处理外部访问,设备管理器收到API的访问请求之后,通过提取该请求的参数,达到调用实际设备对象的相应内部方法的目的。独立服务模式可以直接借助HDF DeviceManager的服务管理能力,但需要为每个设备单独配置设备节点。

  • 接口说明
1. pwm open初始化函数:DevHandle PwmOpen(uint32_t num);参数说明: num:     PWM设备编号。return:  获取成功返回PWM设备句柄,失败返回NULL。
2. pwm close去初始化函数:void PwmClose(DevHandle handle);参数说明:handle:   pwm设备句柄。return:    无。
3. 设置PWM设备参数:int32_t PwmSetConfig(DevHandle handle, struct PwmConfig *config);参数说明:handle:   pwm设备句柄。*config    参数指针。return:    返回0表示设置成功,返回负数表示失败。
  • PWM HDF HCS配置文件解析

device_info.hcs文件位于//device/board/talkweb/niobe407/liteos_m/hdf_config/device_info.hcs,以下示例为使用TIM2、TIM3和TIM7定时器输出PWM信号:

device_pwm1 :: device {pwm1 :: deviceNode {policy = 2;priority = 100;moduleName = "ST_HDF_PLATFORM_PWM";serviceName = "HDF_PLATFORM_PWM_1";deviceMatchAttr = "config_pwm1";}
}
device_pwm2 :: device {pwm2 :: deviceNode {policy = 2;priority = 100;moduleName = "ST_HDF_PLATFORM_PWM";serviceName = "HDF_PLATFORM_PWM_2";deviceMatchAttr = "config_pwm2";}
}
device_pwm7 :: device {pwm7 :: deviceNode {policy = 2;priority = 100;moduleName = "ST_HDF_PLATFORM_PWM";serviceName = "HDF_PLATFORM_PWM_7";deviceMatchAttr = "config_pwm7";}
}

hdf.hcs文件位于//device/board/talkweb/niobe407/liteos_m/hdf_config/hdf.hcs,在此文件中配置TIM定时器具体信息:

--- 注意:tim2-tim7、tim12-tim14时钟频率为84M,TIM1、TIM8~TIM11为168M,tim6和tim7不能输出pwm。
--- tim1~tim5、tim8有4个channel,tim9、tim12有2个channel,tim10、tim11、tim13、tim14只有1个channel。pwm_config {pwm1_config {match_attr = "config_pwm1";pwmTim = 1; 		--- 定时器ID tim2(0:tim1,1:tim2,...,tim6和tim7不可用)pwmCh = 3; 			--- 对应channel数(0:ch1、1:ch2、2:ch3、3:ch4)prescaler = 4199; 	--- 预分频数,例如tim2时钟为84M,(84M/(4199+1))=20khz,则以20khz为基准。}       pwm2_config {match_attr = "config_pwm2";pwmTim = 2;pwmCh = 0;prescaler = 8399;} pwm3_config {match_attr = "config_pwm7";pwmTim = 7;pwmCh = 0;prescaler = 8399;}
}

hdf pwm适配代码请参考://drivers/adapter/platform/pwm/pwm_stm32f4xx.c

hdf pwm使用示例可请参考://device/board/talkweb/niobe407/applications/206_hdf_pwm

子系统适配

OpenHarmony子系统适配一般包含两部分:

  • config.json中增加对应子系统和部件,这样编译系统会将该部件纳入编译目标中。
  • 针对该部件的HAL层接口进行硬件适配,或者可选的软件功能适配。

LWIP部件适配

LiteOS-M kernel通过Kconfig配置可以使lwip参与编译,并可以在kernel组件中指定lwip编译适配的目录。如下:

{"subsystem": "kernel","components": [{"component": "liteos_m","features": ["ohos_kernel_liteos_m_lwip_path = \"//device/board/talkweb/niobe407/liteos_m/lwip_adapter\"" --- 指定适配路径]}]
}

在指定的编译适配目录中,通过#include_next "lwip/lwipopts.h"的方式入侵修改lwip三方库中头文件配置,关于有线以太网LWIP适配部分,后续会补充详细适配步骤,在此先不做深入讲解。

启动恢复子系统适配

启动恢复子系统适配bootstrap_litesyspara_lite两个组件。请在//vendor/talkweb/niobe407/config.json中新增对应的配置选项。

{"subsystem": "startup","components": [{"component": "bootstrap_lite","features": []},{"component": "syspara_lite","features": []}]
}

适配bootstrap_lite部件时,需要在链接文件//device/board/talkweb/niobe407/liteos_m/STM32F407IGTx_FLASH.ld中手动新增如下段:

__zinitcall_bsp_start = .;
KEEP (*(.zinitcall.bsp0.init))
KEEP (*(.zinitcall.bsp1.init))
KEEP (*(.zinitcall.bsp2.init))
KEEP (*(.zinitcall.bsp3.init))
KEEP (*(.zinitcall.bsp4.init))
__zinitcall_bsp_end = .;
__zinitcall_device_start = .;
KEEP (*(.zinitcall.device0.init))
KEEP (*(.zinitcall.device1.init))
KEEP (*(.zinitcall.device2.init))
KEEP (*(.zinitcall.device3.init))
KEEP (*(.zinitcall.device4.init))
__zinitcall_device_end = .;
__zinitcall_core_start = .;
KEEP (*(.zinitcall.core0.init))
KEEP (*(.zinitcall.core1.init))
KEEP (*(.zinitcall.core2.init))
KEEP (*(.zinitcall.core3.init))
KEEP (*(.zinitcall.core4.init))
__zinitcall_core_end = .;
__zinitcall_sys_service_start = .;
KEEP (*(.zinitcall.sys.service0.init))
KEEP (*(.zinitcall.sys.service1.init))
KEEP (*(.zinitcall.sys.service2.init))
KEEP (*(.zinitcall.sys.service3.init))
KEEP (*(.zinitcall.sys.service4.init))
__zinitcall_sys_service_end = .;
__zinitcall_sys_feature_start = .;
KEEP (*(.zinitcall.sys.feature0.init))
KEEP (*(.zinitcall.sys.feature1.init))
KEEP (*(.zinitcall.sys.feature2.init))
KEEP (*(.zinitcall.sys.feature3.init))
KEEP (*(.zinitcall.sys.feature4.init))
__zinitcall_sys_feature_end = .;
__zinitcall_run_start = .;
KEEP (*(.zinitcall.run0.init))
KEEP (*(.zinitcall.run1.init))
KEEP (*(.zinitcall.run2.init))
KEEP (*(.zinitcall.run3.init))
KEEP (*(.zinitcall.run4.init))
__zinitcall_run_end = .;
__zinitcall_app_service_start = .;
KEEP (*(.zinitcall.app.service0.init))
KEEP (*(.zinitcall.app.service1.init))
KEEP (*(.zinitcall.app.service2.init))
KEEP (*(.zinitcall.app.service3.init))
KEEP (*(.zinitcall.app.service4.init))
__zinitcall_app_service_end = .;
__zinitcall_app_feature_start = .;
KEEP (*(.zinitcall.app.feature0.init))
KEEP (*(.zinitcall.app.feature1.init))
KEEP (*(.zinitcall.app.feature2.init))
KEEP (*(.zinitcall.app.feature3.init))
KEEP (*(.zinitcall.app.feature4.init))
__zinitcall_app_feature_end = .;
__zinitcall_test_start = .;
KEEP (*(.zinitcall.test0.init))
KEEP (*(.zinitcall.test1.init))
KEEP (*(.zinitcall.test2.init))
KEEP (*(.zinitcall.test3.init))
KEEP (*(.zinitcall.test4.init))
__zinitcall_test_end = .;
__zinitcall_exit_start = .;
KEEP (*(.zinitcall.exit0.init))
KEEP (*(.zinitcall.exit1.init))
KEEP (*(.zinitcall.exit2.init))
KEEP (*(.zinitcall.exit3.init))
KEEP (*(.zinitcall.exit4.init))
__zinitcall_exit_end = .;

需要新增上述段是因为bootstrap_init提供的对外接口,见//utils/native/lite/include/ohos_init.h文件,采用的是灌段的形式,最终会保存到上述链接段中。主要的服务自动初始化宏如下表格所示:

接口名描述
SYS_SERVICE_INIT(func)标识核心系统服务的初始化启动入口
SYS_FEATURE_INIT(func)标识核心系统功能的初始化启动入口
APP_SERVICE_INIT(func)标识应用层服务的初始化启动入口
APP_FEATURE_INIT(func)标识应用层功能的初始化启动入口

通过上面加载的组件编译出来的lib文件需要手动加入强制链接。

如在 //vendor/talkweb/niobe407/config.json 中配置了bootstrap_lite 部件

    {"subsystem": "startup","components": [{"component": "bootstrap_lite"},...]},

bootstrap_lite部件会编译//base/startup/bootstrap_lite/services/source/bootstrap_service.c,该文件中,通过SYS_SERVICE_INIT将Init函数符号灌段到__zinitcall_sys_service_start和__zinitcall_sys_service_end中,由于Init函数是没有显式调用它,所以需要将它强制链接到最终的镜像。如下:

static void Init(void)
{static Bootstrap bootstrap;bootstrap.GetName = GetName;bootstrap.Initialize = Initialize;bootstrap.MessageHandle = MessageHandle;bootstrap.GetTaskConfig = GetTaskConfig;bootstrap.flag = FALSE;SAMGR_GetInstance()->RegisterService((Service *)&bootstrap);
}
SYS_SERVICE_INIT(Init);   --- 通过SYS启动即SYS_INIT启动就需要强制链接生成的lib

在//base/startup/bootstrap_lite/services/source/BUILD.gn文件中,描述了在//out/niobe407/niobe407/libs 生成 libbootstrap.a,如下:

static_library("bootstrap") {sources = ["bootstrap_service.c","system_init.c",]...

适配syspara_lite部件时,系统参数会最终写到文件中进行持久化保存。在轻量系统中,文件操作相关接口有POSIX接口与HalFiles接口这两套实现。

因为对接内核的文件系统,采用POSIX相关的接口,所以features字段中需要增加enable_ohos_startup_syspara_lite_use_posix_file_api = true。

如果对接HalFiles相关的接口实现的,则无须修改。

DFX子系统适配

进行DFX子系统适配需要添加hilog_lite和hievent_lite部件,直接在config.json文件配置即可。

{"subsystem": "hiviewdfx","components": [{"component": "hilog_lite","features": []},{"component": "hievent_lite","features": []}]
}

配置完成之后,需要注册日志输出实现函数,并加入编译。

bool HilogProc_Impl(const HiLogContent *hilogContent, uint32_t len)
{char tempOutStr[LOG_FMT_MAX_LEN];tempOutStr[0] = 0,tempOutStr[1] = 0;if (LogContentFmt(tempOutStr, sizeof(tempOutStr), hilogContent) > 0) {printf(tempOutStr);}return true;
}HiviewRegisterHilogProc(HilogProc_Impl);

系统服务管理子系统适配

进行系统服务管理子系统适配需要添加samgr_lite部件,直接在config.json配置即可。

{"subsystem": "systemabilitymgr","components": [{"component": "samgr_lite","features": []}]
}

在轻量系统中,samgr_lite配置的共享任务栈大小默认为2048。在适配时可以在features中,通过config_ohos_systemabilitymgr_samgr_lite_shared_task_size重新设置共享任务栈大小。

"config_ohos_systemabilitymgr_samgr_lite_shared_task_size = 4096"

安全子系统适配

进行安全子系统适配需要添加huks组件,直接在config.json配置即可。

{"subsystem": "security","components": [{"component": "huks","features": ["huks_use_lite_storage = true","huks_use_hardware_root_key = true","huks_config_file = \"hks_config_lite.h\"","huks_key_store_path = \"storage\""]}]
}

huks部件适配时,huks_key_store_path配置选项用于指定存放秘钥路径,huks_config_file为配置头文件名称。

公共基础库子系统适配

公共基础库子系统适配添加了kv_storefileos_dump组件,直接在config.json配置即可。

{"subsystem": "utils","components": [{"component": "file","features": []},{"component": "kv_store","features": ["enable_ohos_utils_native_lite_kv_store_use_posix_kv_api = false"]},{"component": "os_dump","features": []}]
},

与适配syspara_lite部件类似,适配kv_store部件时,键值对会写到文件中。在轻量系统中,文件操作相关接口有POSIX接口与HalFiles接口这两套实现。因为对接内核的文件系统,采用POSIX相关的接口,所以features需要增加enable_ohos_utils_native_lite_kv_store_use_posix_kv_api = true。如果对接HalFiles相关的接口实现的,则无须修改。

HDF子系统适配

与启动恢复子系统适配类似,我们需要在链接文件//device/board/talkweb/niobe407/liteos_m/STM32F407IGTx_FLASH.ld中手动新增如下段:

_hdf_drivers_start = .;
KEEP(*(.hdf.driver))
_hdf_drivers_end = .;

然后,在kernel初始化完成后调用DeviceManagerStart函数,执行完成后,才能调用hdf接口控制外设。

#include "devmgr_service_start.h"   --- 注意需要包含该头文件#ifdef LOSCFG_DRIVERS_HDFDeviceManagerStart();
#endif

devmgr_service_start.h头文件所在路径为: //drivers/framework/core/common/include/manager,为保证编译时能找到该头文件,需要将其加入到include_dirs中:

XTS兼容性测评子系统适配

产品兼容性规范

产品兼容性规范文档请参考 产品兼容性SIG介绍。

添加XTS子系统

XTS测试参考资料见 xts参考资料,进行XTS子系统适配需要添加xts_actsxts_tools组件,直接在config.json配置即可,配置如下:

{"subsystem": "xts","components": [{"component": "xts_acts","features": []},{"component": "xts_tools","features": []}]
}

我们可以在xts_acts组件的features数组中指定如下属性:

  • config_ohos_xts_acts_utils_lite_kv_store_data_path 配置挂载文件系统根目录的名字。
  • enable_ohos_test_xts_acts_use_thirdparty_lwip 表示如果使用thirdparty/lwip目录下的源码编译,则设置为true,否则设置为false
编译XTS

在配置config.json后,使用hb build是不会去编译xts的,只有在debug版本编译时才会参与编译,并且需要我们强制链接需要进行测试的套件静态库。

在我们//device/board/talkweb/liteos_m下包含kernel_module的BUILD.gn 脚本中添加如下内容:

config("public") {if (build_xts) {lib_dirs = [ "$root_out_dir/libs" ]ldflags += ["-Wl,--whole-archive",     --- 开启whole-archive特性,可以把在其后面出现的静态库包含的函数和变量输出到动态库"-lbootstrap","-lbroadcast","-lhctest",#公共基础库# "-lmodule_ActsUtilsFileTest",# "-lmodule_ActsKvStoreTest",#DFX"-lmodule_ActsDfxFuncTest","-lmodule_ActsHieventLiteTest",#启动恢复# "-lmodule_ActsBootstrapTest",# "-lmodule_ActsParameterTest",#分布式任务调度# "-lmodule_ActsSamgrTest","-Wl,--no-whole-archive",  --- 关掉whole-archive这个特性]}
}

由于Niobe407开发板内存有限,xts测试时需要分套件测试。执行如下编译命令,即可生成包含xts测试的固件。

hb build -f -b debug --gn-args build_xts=true

此外,我们还需要修改//vendor/talkweb/niobe407/hals/utils/sys_param/hal_sys_param.c文件,将这些字符串定义正确。

static const char OHOS_DEVICE_TYPE[] = {"Evaluation Board"};
static const char OHOS_DISPLAY_VERSION[] = {"OpenHarmony 3.1"};
static const char OHOS_MANUFACTURE[] = {"Talkweb"};
static const char OHOS_BRAND[] = {"Talkweb"};
static const char OHOS_MARKET_NAME[] = {"Niobe"};
static const char OHOS_PRODUCT_SERIES[] = {"Niobe"};
static const char OHOS_PRODUCT_MODEL[] = {"Niobe407"};
static const char OHOS_SOFTWARE_MODEL[] = {"1.0.0"};
static const char OHOS_HARDWARE_MODEL[] = {"2.0.0"};
static const char OHOS_HARDWARE_PROFILE[] = {"RAM:192K,ROM:1M,ETH:true"};
static const char OHOS_BOOTLOADER_VERSION[] = {"twboot-v2022.03"};
static const char OHOS_ABI_LIST[] = {"armm4_hard_fpv4-sp-d16-liteos"};
static const char OHOS_SERIAL[] = {"1234567890"};  // provided by OEM.

验证XTS

编译完成后,将固件烧录至开发板,xts全部跑完会有显示xx Tests xx Failures xx Ignored等信息,以下以公共基础库测试为例:

../../../test/xts/acts/utils_lite/kv_store_hal/src/kvstore_func_test.c:590:testKvStoreClearCache002:PASS
../../../test/xts/acts/utils_lite/kv_store_hal/src/kvstore_func_test.c:625:testKvStoreCacheSize001:PASS
../../../test/xts/acts/utils_lite/kv_store_hal/src/kvstore_func_test.c:653:testKvStoreCacheSize002:PASS
../../../test/xts/acts/utils_lite/kv_store_hal/src/kvstore_func_test.c:681:testKvStoreCacheSize003:PASS
../../../test/xts/acts/utils_lite/kv_store_hal/src/kvstore_func_test.c:709:testKvStoreMaxSize001:PASS
../../../test/xts/acts/utils_lite/kv_store_hal/src/kvstore_func_test.c:737:testKvStoreMaxSize002:PASS
../../../test/xts/acts/utils_lite/kv_store_hal/src/kvstore_func_test.c:765:testKvStoreMaxSize003:PASS
../../../test/xts/acts/utils_lite/kv_store_hal/src/kvstore_func_test.c:793:testKvStoreMaxSize004:PASS
+-------------------------------------------+-----------------------
32 Tests 0 Failures 0 Ignored 
OK
All the test suites finished!

经常有很多小伙伴抱怨说:不知道学习鸿蒙开发哪些技术?不知道需要重点掌握哪些鸿蒙应用开发知识点?

为了能够帮助到大家能够有规划的学习,这里特别整理了一套纯血版鸿蒙(HarmonyOS Next)全栈开发技术的学习路线,包含了鸿蒙开发必掌握的核心知识要点,内容有(ArkTS、ArkUI开发组件、Stage模型、多端部署、分布式应用开发、WebGL、元服务、OpenHarmony多媒体技术、Napi组件、OpenHarmony内核、OpenHarmony驱动开发、系统定制移植等等)鸿蒙(HarmonyOS NEXT)技术知识点。

在这里插入图片描述

《鸿蒙 (Harmony OS)开发学习手册》(共计892页):https://gitcode.com/HarmonyOS_MN/733GH/overview

如何快速入门?

1.基本概念
2.构建第一个ArkTS应用
3.……

开发基础知识:

1.应用基础知识
2.配置文件
3.应用数据管理
4.应用安全管理
5.应用隐私保护
6.三方应用调用管控机制
7.资源分类与访问
8.学习ArkTS语言
9.……

在这里插入图片描述

基于ArkTS 开发

1.Ability开发
2.UI开发
3.公共事件与通知
4.窗口管理
5.媒体
6.安全
7.网络与链接
8.电话服务
9.数据管理
10.后台任务(Background Task)管理
11.设备管理
12.设备使用信息统计
13.DFX
14.国际化开发
15.折叠屏系列
16.……

在这里插入图片描述

鸿蒙开发面试真题(含参考答案):https://gitcode.com/HarmonyOS_MN/733GH/overview

在这里插入图片描述

OpenHarmony 开发环境搭建

图片

《OpenHarmony源码解析》:https://gitcode.com/HarmonyOS_MN/733GH/overview

  • 搭建开发环境
  • Windows 开发环境的搭建
  • Ubuntu 开发环境搭建
  • Linux 与 Windows 之间的文件共享
  • ……
  • 系统架构分析
  • 构建子系统
  • 启动流程
  • 子系统
  • 分布式任务调度子系统
  • 分布式通信子系统
  • 驱动子系统
  • ……

图片

OpenHarmony 设备开发学习手册:https://gitcode.com/HarmonyOS_MN/733GH/overview

图片
在这里插入图片描述

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.rhkb.cn/news/423876.html

如若内容造成侵权/违法违规/事实不符,请联系长河编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

【getshell】phpmyadmin后台getshell(4.8.5)

&#x1f3d8;️个人主页&#xff1a; 点燃银河尽头的篝火(●’◡’●) 如果文章有帮到你的话记得点赞&#x1f44d;收藏&#x1f497;支持一下哦 【getshell】phpmyadmin后台getshell&#xff08;4.8.5&#xff09; 一、进入sql命令输入界面二、上传代码三、getshell 一、进入…

Kubernetes (k8s)v1.27.1版本安装步骤

这 一、k8s 安装步骤1.1 安装docker及containerd容器1.2、设置每台服务器的参数1.3、安装kubelet、kubeadm、kubectl1.4、修改 kubelet 的 cgroup 和 docker 的 cgroup-driver 保持一致1.5、使用containerd 默认容器的配置1.6、使用kubeadm进行初始化1.7、初始化成功1.8、集群部…

海外云手机有哪些推荐?

随着云手机的发展&#xff0c;越来越多的企业和个人开始使用云手机来满足他们的海外业务需求。用户可以通过云手机实现方便、快捷的海外访问&#xff0c;一般用来进行tiktok运营、亚马逊电商运营、海外社媒运营等操作。海外云手机平台有很多&#xff0c;以下是一些比较好的云手…

✨机器学习笔记(四)—— 逻辑回归、决策边界、过拟合、正则化

Course1-Week3: https://github.com/kaieye/2022-Machine-Learning-Specialization/tree/main/Supervised%20Machine%20Learning%20Regression%20and%20Classification/week3机器学习笔记&#xff08;四&#xff09; 1️⃣逻辑回归&#xff08;logistic regression&#xff09;…

Java的衍生生态有哪些?恐怖如斯的JAVA

Java的衍生生态极其丰富&#xff0c;涵盖了多个层面和领域。以下是Java衍生生态的一些主要方面&#xff1a; 1. 开源工具 开发工具&#xff1a;如Eclipse&#xff0c;这是一款非常优秀的Java IDE工具&#xff0c;支持Java以及其他语言的代码编写。Spring官方还基于Eclipse开发…

Excel单元格操作:读写单元格数据、格式设置与条件格式详解

目录 一、Excel单元格的基本操作 1.1 单元格的选取与编辑 案例一&#xff1a;基本数据录入 1.2 单元格的读取与写入 案例二&#xff1a;使用公式计算销售额 二、单元格格式设置 2.1 字体与颜色设置 案例三&#xff1a;设置标题格式 2.2 数字格式设置 案例四&#xff…

树形弹窗选择框/vue2/Element/弹框选择

前言 此类选择器根据vueelementUI实现&#xff0c;使用vue3的可以根据此案例稍作改动即可实现&#xff0c;主要功能有弹出选择、搜索过滤、搜索结果高亮等&#xff0c;此选择器只支持单选&#xff0c;如需多选可在此基础进行改造。 效果图 代码实现 使用时&#xff0c;props-…

【C++ Primer Plus习题】15.1

大家好,这里是国中之林! ❥前些天发现了一个巨牛的人工智能学习网站&#xff0c;通俗易懂&#xff0c;风趣幽默&#xff0c;忍不住分享一下给大家。点击跳转到网站。有兴趣的可以点点进去看看← 问题: 解答: main.cpp #include <iostream> #include "tv.h" us…

openstack之cinder介绍

概念 cinder 为虚拟机提供管理块存储服务。支持的文件系统&#xff1a;lvm、iscsi、nfs、san、RBD 组件构成及功能介绍 cinder api&#xff1a;在控制节点运行&#xff0c;管理服务的接口&#xff0c;被命令行、其他组件调用&#xff1b; cinder scheduler&#xff1a;类似n…

VMware Fusion Pro 13 Mac版虚拟机 安装Win11系统教程

Mac分享吧 文章目录 Win11安装完成&#xff0c;软件打开效果一、VMware安装Windows11虚拟机1️⃣&#xff1a;准备镜像2️⃣&#xff1a;创建虚拟机3️⃣&#xff1a;虚拟机设置4️⃣&#xff1a;安装虚拟机5️⃣&#xff1a;解决连不上网问题 安装完成&#xff01;&#xff0…

怎么使用ai 免费生成ppt?这4个工具可以帮忙

随之AI工具的流行&#xff0c;网络上也涌现了一批 AIPPT 工具&#xff0c;可以在办公上帮助我们节省很多制作PPT的时间。通常它们的操作也比较简单&#xff0c;所以适合很多人使用。为了可以帮助大家提高办公效率&#xff0c;我在这里跟大家分享4款可以免费使用的AIPPT制作工具…

文件误删危机应对:数据恢复全解析

文件误删&#xff1a;数字化时代的隐形挑战 在数字化的浪潮中&#xff0c;文件已成为我们工作、学习和生活中不可或缺的一部分。它们记录着我们的思想、成果与回忆&#xff0c;是连接现实与虚拟世界的桥梁。然而&#xff0c;这份便捷与高效背后&#xff0c;却隐藏着文件误删这…

OpenCV结构分析与形状描述符(14)拟合直线函数fitLine()的使用

操作系统&#xff1a;ubuntu22.04 OpenCV版本&#xff1a;OpenCV4.9 IDE:Visual Studio Code 编程语言&#xff1a;C11 算法描述 拟合一条直线到2D或3D点集。 fitLine 函数通过最小化 ∑ i ρ ( r i ) \sum_i \rho(r_i) ∑i​ρ(ri​)来拟合一条直线到2D或3D点集&#xff0c…

crossover激活码免费 crossover24破解版免费下载安装教程

CrossOver 可以在 Mac 上运行成千上万的 Windows 程序。从办公软件、实用工具、游戏到设计软件&#xff0c;您只需在 Mac 的 dock 轻按一下便可运行。您可以 Windows 程序和 Mac 程序之间随意切换&#xff0c;而这一切无需重启、无需虚拟机&#xff0c;也无需购买 Windows 授权…

音视频入门基础:AAC专题(1)——AAC官方文档下载

一、AAC简介 高级音频编码&#xff08;英语&#xff1a;Advanced Audio Coding&#xff0c;AAC&#xff09;是有损音频压缩的专利数字音频编码标准&#xff0c;由Fraunhofer IIS、杜比实验室、贝尔实验室、Sony、Nokia等公司共同开发。出现于1997年&#xff0c;为一种基于MPEG…

GNSS CTS GNSS Start and Location Flow of Android15

目录 1. 本文概述2.CTS 测试3.Gnss Flow3.1 Gnss Start Flow3.2 Gnss Location Output Flow 1. 本文概述 本来是为了做Android 14 Gnss CTS 的相关环境的搭建和测试&#xff0c;然后在测试中遇到了一些问题&#xff0c;去寻找CTS源码(/cts/tests/tests/location/src/android/l…

Leetcode 最长连续序列

算法流程&#xff1a; 哈希集合去重&#xff1a; 通过将数组中的所有元素放入 unordered_set&#xff0c;自动去除重复元素。集合的查找操作是 O(1)&#xff0c;这为后续的快速查找提供了保证。 遍历数组&#xff1a; 遍历数组中的每一个元素。对于每个元素&#xff0c;首先检…

大数据新视界 --大数据大厂之Kafka消息队列实战:实现高吞吐量数据传输

&#x1f496;&#x1f496;&#x1f496;亲爱的朋友们&#xff0c;热烈欢迎你们来到 青云交的博客&#xff01;能与你们在此邂逅&#xff0c;我满心欢喜&#xff0c;深感无比荣幸。在这个瞬息万变的时代&#xff0c;我们每个人都在苦苦追寻一处能让心灵安然栖息的港湾。而 我的…

Ansys HFSS的边界条件与激励端口

本文将介绍HFSS边界条件、激励端口,然后重点介绍连接器信号完整性仿真应用最多的波端口(wave port)及其尺寸设置要点。 HFSS (电磁仿真)边界条件 HFSS中所谓的边界并非真正意义上的边界,边界条件是指定问题区域和对象边缘的场行为接口。在HFSS的背景下,边界的存在主要有两个…

[Linux入门]---使用exec函数实现简易shell

文章目录 1.简易实现2.人机交互&#xff0c;获取命令行3.命令行分割4.执行命令5.内建命令6.myshell代码 1.简易实现 2.人机交互&#xff0c;获取命令行 代码如下&#xff1a; int quit0; #define LEFT "[" #define RIGHT "]" #define LABLE "#&quo…