2024-12-20 00:00:00
Zephyr 工程的整个构建体系是怎样的，这里做一个具体的分析和学习
最近小米的Vele 也开源了，不过由于缺少文档，而且架构非常庞大，光是仓库就传了两三百个，想看明白不太容易，但是基础的CMake、Kconfig等等全都有。
CMake 推荐使用 “Out-of-source” 构建方式，即将构建文件放在源代码目录之外的独立目录中
一个比较简单的CMake例程
https://github.com/elmagnificogi/MyTools/tree/master/CMake/MyProject1
#include <iostream>
int main() {
std::cout << "Hello, CMake!" << std::endl;
return 0;
}
cpp文件
#ifndef MAIN_H
#define MAIN_H
// Declarations of module functions
#endif // MAIN_H
头文件
# 指定最低 CMake 版本
cmake_minimum_required(VERSION 3.10)
# 定义项目名称和版本
project(MyProject1 VERSION 1.0)
# 设置 C++ 标准
set(CMAKE_CXX_STANDARD 11)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
include_directories(${PROJECT_SOURCE_DIR}/include)
# 创建可执行文件目标
add_executable(MyExecutable ${PROJECT_SOURCE_DIR}/src/main.cpp)
比较简单的CMakeLists.txt定义
新建build目录，将源码和编译路径分开
生成一个MinGW的Makefiles文件
D:\CMake\bin\cmake.exe .. -G "MinGW Makefiles"
编译
mingw32-make.exe
测试
I:\cmake\CMakeTutorialCN\MyProject\build\src>MyExecutable.exe
Hello, CMake!
稍微复杂一些，但是包含了库，移除了测试库，windows下拉不到这个测试库
https://github.com/elmagnificogi/MyTools/tree/master/CMake/MyProject0
CMake确实稍微步骤多了一些，组织编排就要跑一会，还是这么简单的工程
cmake_minimum_required(VERSION 3.20.0)
# 寻找依赖包Zephyr
# $ENV{Zephyr_BASE} 设置了 Zephyr 的根目录路径
find_package(Zephyr REQUIRED HINTS $ENV{Zephyr_BASE})
project(untitled)
# target_sources 指令用于为 CMake 目标添加源文件。这种方法的优点在于它可以将源文件添加到目标中，并且可以在 CMake 的生成阶段自动更新。
# target: 要添加源文件的目标，通常是通过 add_executable 或 add_library 定义的目标。
# INTERFACE: 指定这些源文件对其他目标是可见的，但不会包含在目标本身的构建中。这通常用于接口库。
# PUBLIC: 指定这些源文件对其他链接到该目标的目标是可见的，同时也包含在目标本身的构建中。
# PRIVATE: 指定这些源文件仅对目标本身可见，不会传播到链接到该目标的其他目标。
target_sources(app PRIVATE src/main.c)
编译时执行的 build.py 脚本中引用了 Zephyr\scripts\west_commands\Zephyr_ext_common.py，在这个脚本中设置了 Zephyr_BASE 的宏。
untiled内容比较少，还是需要去看Zephyr内的CMake
先看一眼nRF的SDK包构成
Zephyr的包主要存储在这里，通过上面的CMake搜索到这里
Zephyr的CMake主要调用逻辑
Zephyr/share/Zephyr-package/cmake/ZephyrConfigVersion.cmake
Zephyr/share/Zephyr-package/cmake/Zephyr_package_search.cmake
Zephyr/cmake/modules/version.cmake
Zephyr/share/Zephyr-package/cmake/ZephyrConfig.cmake
Zephyr主要是两个阶段，配置阶段、编译阶段
根据这个图来说，最终Kconfig生成了autoconf.h，同时持久化了一个.config配置方便后续使用
Zephyr同时也生成了一个设备树，这个概念基本和Linux一样，都是通过设备树来注册驱动进去的，类似的设备树也有同样的一个.h文件。
最终这部分生成文件和产生的Makefile一起进行最后的编译，生成对应固件
在untiled下面新建Kconfig文件，输入以下内容
menu "Test Params setting"
config TEST_ENABLE
bool "Enable test work"
default n
help
Will print debug information if enable.
config TEST_SHOW_STRING
string "The show string info"
default "Test 123"
config TEST_SHOW_INT
int "The show int info"
range 0 255
default 123
config TEST_TOP_ENABLE
bool "Test Top Func"
default n
help
Function Test Top
config TEST_SUB_0_ENABLE
bool "Test Sub 0 Func"
default n
help
Function Test Sub 0
config TEST_SUB_1_ENABLE
bool "Test Sub 1 Func"
default n
depends on TEST_TOP_ENABLE
help
Function Test Sub 1
config TEST_SHOW_SUB_INT
int
default 456 if TEST_SUB_0_ENABLE && TEST_SUB_1_ENABLE
default 123
endmenu
# 注意一定要引用这个，不然加不进去，并且CMake不了
source "Kconfig.zephyr"
工程越大越复杂，还是希望能稍微控制一下复杂度
参考这个教程，但是这个教程写的一坨屎，为什么还会有人点星
https://github.com/shendeguize/CMakeTutorialCN
https://blog.csdn.net/qq_37805392/article/details/141337664
https://zhuanlan.zhihu.com/p/705640074
https://docs.Zephyrproject.org/latest/build/index.html
https://blog.csdn.net/My_CSDN_IT/article/details/118180074
https://lgl88911.github.io/2020/03/08/Zephyr%E6%9E%84%E5%BB%BA%E8%BF%87%E7%A8%8B%E7%AE%80%E8%BF%B0/
https://www.cnblogs.com/jayant97/articles/17794813.html
2024-12-18 00:00:00
绕了这么大一圈，似乎只有kconfig是比较成熟的，能与之相媲美的管理工具很少
在windows下使用Kconfig，至少得有python，否则界面等内容无法正常显示
python需要先安装这几个包
python -m pip install windows-curses
python -m pip install kconfiglib
测试安装，可以正常显示命令
menuconfig -h
参考工程sample_1
https://github.com/bobwenstudy/test_kconfig_system
编译所有
make all
修改配置
menuconfig
运行main.exe就能看到结果了
hello, world
CONFIG_TEST_ENABLE
CONFIG_TEST_SHOW_STRING: Test 123
CONFIG_TEST_SHOW_INT: 123
CONFIG_TEST_SUB_0_ENABLE
CONFIG_TEST_SHOW_SUB_INT: 123
可能会报错，这个是因为curses库他需要终端执行，但是不识别你当前使用的终端，换一个就行了，比如cmd
make 提示Redirection is not supported.
这个例子里还只有一种config，还不能支持多config配置，可以看到主要就只能生成一个autoconfig.h
all: main.o
gcc main.o -o main
main.o: main.c autoconfig.h
gcc main.c -c -o main.o
clean:
del main.o main.exe
autoconfig.h:.config
python ../scripts/kconfig.py Kconfig .config autoconfig.h log.txt .config
.config:
menuconfig
menuconfig:
menuconfig
# 默认编译test1
APP ?= app/test1
OUTPUT_PATH := output
INCLUDE_PATH := -I$(APP) -Idriver -I$(OUTPUT_PATH)
# 主要用户定义的配置是在每个app下的，这里也可以单独提取一个对应的版本目录来做
# define user .config setting
USER_CONFIG_SET :=
USER_CONFIG_SET += $(APP)/prj.conf
# define menuconfig .config path
DOTCONFIG_PATH := $(OUTPUT_PATH)/.config
# 用户文件追踪
# define user merged path
USER_RECORD_CONFIG_PATH := $(OUTPUT_PATH)/user_record.conf
# define autoconfig.h path
AUTOCONFIG_H := $(OUTPUT_PATH)/autoconfig.h
#define Kconfig path
KCONFIG_ROOT_PATH := Kconfig
#For windows work.
FIXPATH = $(subst /,\,$1)
all: $(APP)/main.o driver/driver_test.o
gcc $^ -o $(OUTPUT_PATH)/main.exe
$(APP)/main.o: $(APP)/main.c
gcc $< $(INCLUDE_PATH) -c -o $@
driver/driver_test.o: driver/driver_test.c $(AUTOCONFIG_H)
gcc $< $(INCLUDE_PATH) -c -o $@
clean:
del /q /s $(call FIXPATH, $(APP)/main.o driver/driver_test.o $(OUTPUT_PATH))
# 根据对应的autoconfig的目录来生成
$(AUTOCONFIG_H):$(DOTCONFIG_PATH)
python ../scripts/kconfig.py $(KCONFIG_ROOT_PATH) $(DOTCONFIG_PATH) $(AUTOCONFIG_H) $(OUTPUT_PATH)/log.txt $(DOTCONFIG_PATH)
# 从用户的项目路径里拿刀用户定义的config
$(USER_RECORD_CONFIG_PATH): $(USER_CONFIG_SET)
@echo Using user config.
# create user_record.conf to record current setting.
@copy $(call FIXPATH, $^) $(call FIXPATH, $@)
# create .config by user config setting.
python ../scripts/kconfig.py --handwritten-input-configs $(KCONFIG_ROOT_PATH) $(DOTCONFIG_PATH) $(AUTOCONFIG_H) $(OUTPUT_PATH)/log.txt $(USER_CONFIG_SET)
export KCONFIG_CONFIG=$(DOTCONFIG_PATH)
$(DOTCONFIG_PATH):$(USER_RECORD_CONFIG_PATH)
@echo .config updated
menuconfig:$(DOTCONFIG_PATH)
# set KCONFIG_CONFIG=$(DOTCONFIG_PATH)
menuconfig $(KCONFIG_ROOT_PATH)
对应这样的配置就可以使用下面的方式来独立生成每个APP的配置，这样就可以同时维护多个版本，而要多一个APP，就再加一个配置就行了
make APP=app\test1
make APP=app\test2
上面这个配置还少了一点，生成的都是同一个文件，同一个目录，互相覆盖，其实可以参考OpenWRT，每次不同配置生成都在不同文件夹里，然后对应文件名就更好了
APP ?= app/test1
OUTPUT_PATH := output/$(APP)
TARGET := main
INCLUDE_PATH := -I$(APP) -Idriver -I$(OUTPUT_PATH)
# define user .config setting
USER_CONFIG_SET :=
USER_CONFIG_SET += $(APP)/prj.conf
# define menuconfig .config path
DOTCONFIG_PATH := $(OUTPUT_PATH)/.config
# define user merged path
USER_RECORD_CONFIG_PATH := $(OUTPUT_PATH)/user_record.conf
# define autoconfig.h path
AUTOCONFIG_H := $(OUTPUT_PATH)/autoconfig.h
#define Kconfig path
KCONFIG_ROOT_PATH := Kconfig
#For windows work.
FIXPATH = $(subst /,\,$1)
all: $(APP)/main.o driver/driver_test.o
gcc $^ -o $(OUTPUT_PATH)/$(TARGET).exe
$(APP)/main.o: $(APP)/main.c | $(OUTPUT_PATH)
gcc $< $(INCLUDE_PATH) -c -o $@
driver/driver_test.o: driver/driver_test.c $(AUTOCONFIG_H)
gcc $< $(INCLUDE_PATH) -c -o $@
$(OUTPUT_PATH):
@mkdir $(call FIXPATH, $@)
clean:
del /q /s $(call FIXPATH, $(APP)/main.o driver/driver_test.o $(OUTPUT_PATH))
$(AUTOCONFIG_H):$(DOTCONFIG_PATH)
python ../scripts/kconfig.py $(KCONFIG_ROOT_PATH) $(DOTCONFIG_PATH) $(AUTOCONFIG_H) $(OUTPUT_PATH)/log.txt $(DOTCONFIG_PATH)
$(USER_RECORD_CONFIG_PATH): $(USER_CONFIG_SET)
@echo Using user config.
# create user_record.conf to record current setting.
@copy $(call FIXPATH, $^) $(call FIXPATH, $@)
# create .config by user config setting.
python ../scripts/kconfig.py --handwritten-input-configs $(KCONFIG_ROOT_PATH) $(DOTCONFIG_PATH) $(AUTOCONFIG_H) $(OUTPUT_PATH)/log.txt $(USER_CONFIG_SET)
export KCONFIG_CONFIG=$(DOTCONFIG_PATH)
$(DOTCONFIG_PATH):$(USER_RECORD_CONFIG_PATH)
@echo .config updated
menuconfig:$(DOTCONFIG_PATH)
# set KCONFIG_CONFIG=$(DOTCONFIG_PATH)
menuconfig $(KCONFIG_ROOT_PATH)
稍微修改一下，增加路径自动创建，这样后续就可以不同配置生成到不同目录中，不会互相覆盖了。同时也自动适配生成的文件名和路径分割符
当然这个Makefile还是有一些缺点，比如所有要编译的.c和.o都得一个个加，还是有点傻
Kconfig发展了这么久，难道没有人想着用VScode来做一下可视化嘛，事实上是有的，但是也都有限，不是很通用
第一个插件只能提供kconfig的语法高亮，不能解决显示问题
第二个就是nRF Kconfig，下面的Konfig for Zephyr Project也停止开发，转而使用nRF Kconfig了
https://marketplace.visualstudio.com/items?itemName=nordic-semiconductor.nrf-kconfig
nRF Kconfig想要用起来还稍微有点麻烦，直接启动不了，所以单独开个段落说明如何使用。
至于非VScode的版本，基本上大部分都是依赖kconfiglib的python库完成显示，或者是结合一下TUI、Tkinter等比较轻量化的框架实现，而整体交互逻辑依然离不开比较原始的上下左右菜单式的
https://github.com/ulfalizer/Kconfiglib
https://github.com/cuinixam/kspl
https://github.com/CoryXie/SConf
其他Kconfig，比如ESP-IDF，就可以很好的体现esp的kconfig内容
但是ESP是专用的，并不适用于其他开发环节或者板子，而且体积很大
由于要启动kconfig必须要配置完工程才能启动，所以记录一下nRF SDK是怎么启动、编译的
首先安装nRF Connect Extendtion Pack
其实相当于是插件包，我细看了一下，基本上需要的开发环境他都给你打包整合好了，设备树、Kconfig、Cmake、调试、Flash等等工具都有，相当于就是一个IDE了
选择一个工具链，然后等安装完成，这里直接选最新的就行了
继续安装SDK，选择一个路径安装，回车后等待完成
新建一个应用，然后添加编译配置，选择板子，构建配置，开始编译
编译完成，但是注意一下新工程里面没有Kconfig，但是ACtion里已经可以显示Kconfig UI了
经过测试nRF的Kconfig GUI无法直接打开前面的sample_2工程，显示非nRF工程
这里详细分析一下untitled的默认工程
untitled一共三个文件
mian.c
CMakeLists.txt
prj.conf
prj.conf中直接是空白的，main中也没啥特殊内容，主要就是CMakeLists可以被识别？
cmake_minimum_required(VERSION 3.20.0)
find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE})
project(untitled)
target_sources(app PRIVATE src/main.c)
实际CMakeLists中的内容也非常少
实际把prj.conf直接复制到sample_2中，Kconfig就可以打开了，但是发现打开的还是untitled的config，而不是sample_2的
关掉其他文件，再打开GUI，就无法启动了。
这里绑定有点深，必须CMakeLists，必须要在build以后才能用GUI，否则无法直接打开GUI界面
而添加Build Config以后，Build文件夹中的内容非常复杂，非常多内容
看了一眼nRF Kconfig，源码竟然还是python，也就是跑这个必须有对应的python环境，否则还跑不起来，怪不得那个工具链安装好久，原来在下python。python本质上还是调用kconfiglib库来完成kconfig的解析，最后再转成数据送给VS 前端去加载显示
目前看起来源码没有做加密或者混淆，所以要改一个非nRF强关联的版本，应该是比较容易的
回过头再看Zephyr的kconfig，这个竟然是开源项目，那么只需要搞定他的入口，就可以显示任何kconfig了
https://github.com/trond-snekvik/vscode-kconfig
后续计划一下改出来一个带UI的通用版本
目前看只有Zephyr和nRF的Kconfig结合比较深，后续可能还会详细分析一下Zephyr的整体架构是什么样的，整个build是怎么串起来的
https://github.com/bobwenstudy/test_kconfig_system
https://stackoverflow.com/questions/68748824/how-to-fix-redirection-is-not-supported
https://docs.nordicsemi.com/bundle/nrf-connect-vscode/page/get_started/install.html
https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/installation/install_ncs.html
2024-12-07 00:00:00
测试一下QEMU模拟运行FreeRTOS
QEMU安装需要先安装MSYS2
直接下载安装
https://www.msys2.org/
安装完成以后，QEMU使用pacman包进行安装
https://www.qemu.org/download/#windows
pacman -S mingw-w64-x86_64-qemu
添加新的环境变量，把刚才安装的路径加进去
D:\msys64\mingw64\bin
查看版本，显示正确
qemu-system-arm -version
QEMU emulator version 9.1.1
Copyright (c) 2003-2024 Fabrice Bellard and the QEMU Project developers
选择FreeRTOS 202212.01版本下载，包含所有演示项目的
https://freertos.org/zh-cn-cmn-s/Documentation/02-Kernel/01-About-the-FreeRTOS-kernel/03-Download-freeRTOS/01-DownloadFreeRTOS
这里主要是测试使用FreeRTOS/Demo/CORTEX_MPS2_QEMU_IAR_GCC/build/gcc这个项目，需要至少arm-eabi-none-gcc的环境和make，否则进行不下去
进入到gcc目录，先编译一下
make
正常编译完成
qemu启动模拟
qemu-system-arm -machine mps2-an385 -cpu cortex-m3 -kernel ./output/RTOSDemo.out -monitor none -nographic -serial stdio
正常启动，并且task跑起来了，正在输出内容
qemu这里的参数含义
官方QEMU支持的STM32不是很多，而且用起来很麻烦，需要安装两个环境，而且很容易出问题
所以有人打包了QEMU，并且加入了比较多的ST的开源板子，支持的型号比较多
https://github.com/beckus/qemu_stm32
这个QEMU环境需要重新编译，耗时比较多，或者是从Ubuntu里调用，倒是不用打包成exe
bule bill 的工程用QEMU模拟
https://github.com/beckus/stm32_p103_demos
直接编译
make
编译完成以后每个demo下面都有对应的bin文件，可以直接拿来模拟使用
qemu-system-arm -M stm32-p103 -kernel main.bin
同时RT-Thread，他们的IDE里也集成了专属的QEMU版本，也可以快捷完成模拟
挺简单的，只是问题QEMU支持的现成芯片、板子比较少，需要自己去找对应的开发板，甚至自己开发，有点麻烦
https://blog.csdn.net/weixin_42607526/article/details/142263258
https://freertos.org/zh-cn-cmn-s/Documentation/02-Kernel/03-Supported-devices/04-Demos/03-Emulation-and-simulation/QEMU/freertos-on-qemu-mps2-an385-model
https://www.cnblogs.com/asmer/p/16813129.html
https://www.qemu.org/docs/master/system/arm/stm32.html
2024-12-03 00:00:00
体验一下群友的宏管理工具
https://gitee.com/li-shan-asked/lite-manager
群友的宏管理工具，主要在gitee上更新，github更新不及时，release文件可能不能用
主要是用来方便管理宏定义和生成Makefile，但是大部分设置还是要熟悉Makefile本身，你才能完成lm的配置文件编写，本质上并没有变换脚本语言或者什么的流程
lite-manager在这里有点类似于Kconfig
至少需要一个make和gun c的环境，之前系统里一直有一个MinGW32 13年的版本，gcc大概只有6，编译过不去（后来发现应该不是这个问题）
通过下面的方式在线安装MinGW64
https://github.com/Vuniverse0/mingwInstaller/releases/download/1.2.1/mingwInstaller.exe
安装完成以后添加环境路径
如果环境里没有多的make，可以把mingw32-make.exe复制一个改名叫make.exe，不然最好还是保持原样，否则会影响到系统里其他地方的make使用
测试demo，发现无法正常运行，链接脚本无法识别-M的参数
仔细看了一下Makefile，是生产的链接参数就是-M而不是-Map
还好lite-manager源码也是有的，修改一下生成脚本
再把生成的lm.exe拖到对应的测试目录下，进行测试，一切正常了
先生成Makefile
./lm.exe -g Makefile -p hello
然后可以生成config文件，并且查看宏定义情况
make config
编译
make
lm.cfg，用来定义宏的定义以及宏之间的关系
proj.cfg，用户定义实际想要的宏
.lm.mk，缓存
config.h，最终处理完约束条件后实际定义出来的宏
lm.cfg中判断条件是自上而下的，遇到冲突点，首先会关闭自身，然后文件之间是从左向右流动的
其中n，表示宏关闭，‘n’是正常使用n这个关键字
同时下面的文件编译的约束也可以同时使用宏来管控
多模块、多组件的工程目录
├───build
├───subdirA
| ├───mac_a.c
| └───lm.cfg
├───subdirB
| ├───mac_b.c
| └───lm.cfg
└───lm.cfg
可以使用include直接把下面的配置加载进去
include "subdirA/lm.cfg"
include "subdirB/lm.cfg"
lm的工程实例可以参考这里，有些技巧example里没有用到，可以看看实例是怎么跑的
https://gitee.com/li-shan-asked/ebraid
lite-manager 同时也有类似tui的交互版本，不过作者说比较老、过时，所以不推荐用了
# 自顶向下来看Makefile的设计
# 首先目标是hello 然后编译输出到build目录
TARGET := hello
BUILD_DIR := build
# 定义一个伪指令，主要用来检测是否从lm的config中生成的
# 简单说基本上只要不是最终生成的目标，那都是伪指令
# 伪指令主要是完成一些辅助性的工作，比如clean，检测，切换配置，生成配置等等
# 检测是否有.lm.mk文件
.PHONY: check_lmmk
# wildcard自动寻找.lm.mk的文件
ifneq ($(wildcard .lm.mk),)
-include .lm.mk
else
check_lmmk:
@echo "Please run 'make config'"
endif
# 主要涉及使用的工具链，比如 arm-none-eabi-, 这里用默认gcc即可
CC_PREFIX ?=
CC = $(CC_PREFIX)gcc
# 汇编编译的文件来源是C++ 支持的是.S 如果要支持.s 也在这里修改
AS = $(CC_PREFIX)gcc -x assembler-with-cpp
# copy命令
CP = $(CC_PREFIX)objcopy
# 文件size section 字段分析
SZ = $(CC_PREFIX)size
# 调试 debug的工具
OD = $(CC_PREFIX)objdump
# 生成hex文件
HEX = $(CP) -O ihex
# 生成bin文件
BIN = $(CP) -O binary -S
# 以上工具写的比较多，实际是为了以后适配使用，demo里可能没用到
# 定义额外的宏、库、等路径
CFLAGS := $(C_PATH) $(C_DEFINE) $(C_FLAG) $(CPP_FLAG)
# 同上，定义链接文件的来源和参数
# 链接时生成map文件
LDFLAGS := $(LD_FLAG) $(LIB_PATH) -Wl,-Map=$(BUILD_DIR)/$(TARGET).map
# 这里定义生成全部的目标
.PHONY: all
all: $(BUILD_DIR)/$(TARGET).exe elf_info
#获取到所有要编译的目标对象，这里是从build目录中获取所有c和c++目标
OBJECTS = $(addprefix $(BUILD_DIR)/,$(notdir $(patsubst %.c, %.o, $(patsubst %.cpp, %.o, $(C_SOURCE)))))
# 指定具体的.c文件的搜索路径
vpath %.c $(sort $(dir $(C_SOURCE)))
vpath %.cpp $(sort $(dir $(C_SOURCE)))
#获取到所有要编译的汇编对象
OBJECTS += $(addprefix $(BUILD_DIR)/,$(notdir $(ASM_SOURCE:.S=.o)))
vpath %.S $(sort $(dir $(ASM_SOURCE)))
# 创建存储.o和.c文件依赖关系的.d文件
# -MMD -MP -MF $(@:%.o=%.d) 是利用gcc自动生成依赖关系
# 将build路径下的所有c文件编译成.o文件
# Makefile文件自身也是依赖文件，如果Makefile文件发生变动，也需要重新编译
# -Wa,-a,-ad,-alms=$(BUILD_DIR)/$(notdir $(<:.c=.lst))：生成临时中间文件
# -c 仅仅编译，不进行链接
# $@是指这条指令的所有操作对象
# $<是第一个文件
$(BUILD_DIR)/%.o: %.c Makefile | $(BUILD_DIR)
@echo "CC $<"
@$(CC) -c $(CFLAGS) -MMD -MP \
-MF $(BUILD_DIR)/$(notdir $(<:.c=.d)) \
-Wa,-a,-ad,-alms=$(BUILD_DIR)/$(notdir $(<:.c=.lst)) $< -o $@
# 同上，只不过此处仅编译c++文件
$(BUILD_DIR)/%.o: %.cpp Makefile | $(BUILD_DIR)
@echo "CC $<"
@$(CC) -c $(CFLAGS) -MMD -MP \
-MF $(BUILD_DIR)/$(notdir $(<:.cpp=.d)) \
-Wa,-a,-ad,-alms=$(BUILD_DIR)/$(notdir $(<:.cpp=.lst)) $< -o $@
# 同上，此处仅编译.S的汇编文件
$(BUILD_DIR)/%.o: %.S Makefile | $(BUILD_DIR)
@echo "AS $<"
@$(AS) -c $(CFLAGS) -MMD -MP \
-MF $(BUILD_DIR)/$(notdir $(<:.S=.d)) $< -o $@
# 生成exe文件
$(BUILD_DIR)/$(TARGET).exe: $(OBJECTS) Makefile
@echo "LD $@"
@$(CC) $(OBJECTS) $(LDFLAGS) -o $@
@$(OD) $(BUILD_DIR)/$(TARGET).exe -xS > $(BUILD_DIR)/$(TARGET).s $@
@echo ''
@echo "Build Successful!"
@echo "ELF $@"
elf_info: $(BUILD_DIR)/$(TARGET).exe
@echo "=================================================================="
@$(SZ) $<
@echo "=================================================================="
# 生成build文件夹
$(BUILD_DIR):
@mkdir $@
# 清除指令
.PHONY: config clean
# 如果工程配置文件存在，那么就调用lm重新生成配置
# 这里主要是生成对应的 config.h，不是重新生成Makefile
config: proj.cfg
@./lm.exe --projcfg proj.cfg --lmcfg lm.cfg --out config.h --mem 50
@./lm.exe --rmdir $(BUILD_DIR)
# 清空编译
clean:
@./lm.exe --rmdir $(BUILD_DIR)
实际在hello的lm.cfg中只有一行，就是加了一个文件进去
SRC += hello.c
这里指定了生成的目标是hello
./lm.exe -g Makefile -p hello
剩下的Makefile全都靠lm内部自动生成
以stm32f103的工程为例，相当于Makefile是一个通用的Makefile，而lm.cfg 相当于是一个PreMakefile，在这里直接定义Makefile要用的一些参数即可，剩下就是Makefile足够项目通用即可
# 添加link文件
LDS += stm32f10x_64KB_flash.ld
# 添加汇编文件
ASM += startup_stm32f10x_md.s
# 添加一些关联文件路径
PATH += lib/cmsis
PATH += ./
# 添加源文件
SRC += stm32f10x_it.c
SRC += main.c
# 增加宏定义
DEFINE += STM32F10X_HD USE_STDPERIPH_DRIVER
# 编译参数
CFLAG += -g -O2 -mthumb -mcpu=cortex-m3 -march=armv7-m -Wl,-Bstatic -ffunction-sections -fdata-sections -nostdlib -ffreestanding
# 链接参数
LDFLAG += -lnosys -Wl,--cref -Wl,--no-relax -Wl,--gc-sections -ffreestanding -Wl,-Bstatic -Wl,--no-warn-rwx-segments
# 汇编参数
ASFLAG += -Wl, -Bstatic
# 引入库文件里的lm
include "hal/STM32F10x_StdPeriph_Driver/lm.cfg"
使用当前比较通用的arm-none-eabi的老库
GNU Arm Embedded Toolchain\10 2021.10
STM32F103的工程是无法正常编译的
如果没有看过类似的例子或者直接参考Makefile原工程，不可能上手直接使用
如果使用Arm GNU Toolchain arm-none-eabi\13.3 rel1 确实可以直接编译过
在不同的使用情景下，lite-manager带来的效果还是有一些差别的，假如你是一个对工程特别熟悉的人，那么对应的lm.cfg或者是proj.cfg中的宏都是可以随手改的。但是并不是每个做工程的人都对整个宏特别熟悉，此时就会出现给了一个不熟悉的人去修改，那么他就得一一对照整个lm.cfg里的约束关系和宏定义的可能，再去设置proj.cfg，如果只是几个宏，那随手就改了（几个宏为什么还要用lm？）
如果是几十个宏，此时要查表，再去决定这个宏可以用什么
这个时候lm的结构就变成负担了，虽然lm可以显示最终结果，但是当你发现结果不对的时候，你依然需要逐项去排查是哪里冲突了
类比传统的Makefile工程来说，lm省去了你手动Makefile里各种if条件的书写，确实简化了一部分Makefile复杂的地方
这里提一点我的想法，有一个比较通用的UI显示，类似于xml或者json的UI化显示，定义好一些规则，直接就能把这种宏配置管理给做了
lite-manager 总体还是挺小的，显示也还凑活，代码是开放的，完全可以自定义一些
总体来说lm简化了Makefile，但是想要使用起来依然需要懂Makefile，需要给项目下的每个文件夹增加配置文件，类比.mk文件
https://gitee.com/li-shan-asked/lite-manager/tree/noui/
https://blog.csdn.net/ysu_wangli/article/details/106677907
2024-12-02 00:00:00
当一套代码兼容了多个软件、硬件，需要面对不同情况下，进行不同的build的时候，就需要额外的工具来辅助完成这一个事情。
多数情况下，我们使用的各种IDE都有自己的一套UI或者配置文件来完成这个事情。
以VS为例，一般情况对于一个项目的整体构建的配置大概是这样的
顶级就是Solution 一个解决方案，一个方案下面可能有多个工程共同构成，比如某些工程依赖的库、依赖的测试工程、依赖的一些子应用。解决方案里必然也有一个配置，用来指定各个工程在解决方案级别进行构建时，各个工程适用什么配置来进行组合构建。
单独的工程来说，有一个或者多个配置文件，比如debug和release，这种最常见的，剩下就是对于整个项目的源码文件、库文件、依赖文件、资源文件的组合，可能不同配置用到了不同的组合。
下面实际组织代码和编译的工具链也有可能是不同的，最终把结果输出到指定目录
类似于成品IDE来说，这些配置或者架构都是基础，实际去操作或者修改这些的东西，表面上看都是在UI界面上去填写或者勾选，实际最终都需要通过各种渠道或者命令参数，转化到最底层的工具链中，往往高级的IDE都会封装自有的工具里，不允许外部工具链介入
类似一个Linux Distribution的构建，不仅仅是要编译内核，还有boot、各种app、各种工具链，对应一整套Build工具就非常复杂，而且要统一在一起，才能实现后续的自动化测试或者发布等要求
一般来说buildroot这一套用的比较多一些，很多开发板或者芯片厂商也会使用这一套来维护自己的sdk等
Buildroot是将一个个工程或者说应用，当作一个package单元，本质上就是把所有package编译好，打包到一起就得到了一个镜像，就可以烧给对应系统使用了
一般工作流程是先拉下来所有需要依赖的源码或者包，然后进行配置，核心配置工具就是menuconfig，他就类似于VS中的整个Solution的配置，规定了各个工程要以什么样的方式进行编译，还有需要使用什么样的编译器来编译，同时对应的编译工具链都会直接拉到工程内，之后进入到每个工程以后还有各自详细的makefile去管理这个模块怎么编译，最终编译完成输出到output中。
kconfig就是用来描述各种包的依赖关系、配置选型的，最终由menuconfig具象化。
一些SDK也是使用了类似的机制，比如ESP-idf，就通过kconfig来选择组件等。
无论是何种方式进行的构建，大都逃不过这么几个构建的组合，文件、宏、脚本。本质上就是选择文件，修改替换文件的部分内容，以及通过宏选择文件内容，就能完成整个构建的目的了。
而负责处理这部分的程序就是Make、Cmake、Ninja、Meson、Xmake等
说来也比较搞笑，最初大家都用Make Makefile这一套流程，但是写Makefile是个麻烦事，而且随着工程越来越大，平台越来越多，这个东西就更麻烦了，为了解决这个问题，于是引入了CMake，但是CMake也需要用户输入啊，CMake需要写CMakelist。
同时期也出现了make本身很多时候都没有在做代码编译的事情，而是在组织安排代码，并且效率很低，所以出现了Ninja，Ninja借鉴了很多make的问题，做了大幅简化，速度是很快了，不过可能功能上就有些情况不能处理了。而Ninja也要写.Ninja，这也是个麻烦事，还好后续Cmake也支持了Ninja，所以那就都只写CMakelist就行了
在编译构建工具发展的过程中还是存在一些小问题，比如Makefile、.Ninja、CMakelist他们无论怎么简化，他们都有各自的语法，你都要学一下才能写，而且这种小众语法，很多时候不常用，经常要查，对应的他们的官方文档又写的不是很好，很多奇巧淫技都是从别人代码里看来的。
到这里就有人想到了为什么我不能用我自己熟悉语言来写规则呢，那不是更简单？
于是乎就有了xmake，xmake主要用lua来写脚本，lua相比其他语言来说更加轻量，依赖非常少。xmake还有一些其他方面的功能
Xmake ≈ Make/Ninja + CMake/Meson + Vcpkg/Conan + distcc + ccache/sccache
https://gitee.com/tboox/xmake
同样的国外也有人觉得脚本语法难用，所以他用python也做了一套，叫Meson，现在基本上人手一个python，你要是不会python，多少都有点奇怪。
https://mesonbuild.com/
https://github.com/mesonbuild/meson
虽然用python简单，但是python本身稍微有点重，还是不够好
SCons也做了类似的事情，使用python来写
https://scons.org/
作为工具链的头头GNU也有一套构建工具GNU Autotools，但是对于其他平台的支持就不太行了
试用一下xmake，主要是看看他的menu图形化是怎么做的，文档里也没有详细说明
安装xmake，windows直接下载exe版本即可
https://github.com/xmake-io/xmake/releases
拉下来xmake的代码，测试工程都在test/project中
https://github.com/xmake-io/xmake
创建一个hello工程
xmake create -l c -P ./hello
如果正常的话，可以直接xmake，但是实际可能不行
xmake
xmake会自动检测设备环境，自动关联查找各种库，由于默认的xmake.lua中没有设定环境，所以导致实际上自动找的工具链大概率是错的，编译过不去
首先指定环境
xmake f -p windows -a x64
他会自动找到对应安装的环境
checking for Microsoft Visual Studio (x64) version ... 2022
checking for Microsoft C/C++ Compiler (x64) version ... 19.35.32019
再次xmake，这次编译成功了
[ 50%]: compiling.release src\main.c
[ 75%]: linking.release hello.exe
[100%]: build ok, spent 1.032s
运行程序，直接输出hello world
xmake run
再测试一下嵌入式环境，进入到xmake\tests\projects\embed\mdk\hello\路径中
嵌入式环境比较复杂，xmake都算作交叉编译，参考这部分文档
xmake show -l toolchains可以显示当前支持的工具链cross这里默认就是指交叉编译的库
xmake f -p cross -a cortex-m3 --toolchain=armcc -c
xmake
armcc的方式可以正常编译过
xmake f -p cross -a cortex-m3 --toolchain=armclang -c
xmake
armclang，也就是keil的v6编译，过不去
cross这里默认就是指交叉编译的库，具体sdk路径最好带上引号
xmake f -p cross --toolchain=gnu-rm --sdk="D:\GNU Arm Embedded Toolchain\10 2021.10"
xmake
如果遇到这种问题，实际就是你的编译工具链不完整，缺少内容
note: the following packages are unsupported on msys/x86_64:
-> gnu-rm 2021.10 [host]
看似可以一键直接使用
xmake f --menu
但实际上不行，这里需要tui支持，windows这边的git bash客户端不支持这个界面，但是如果直接用cmd反而支持tui
xmake.lua中添加下面的几个选型，即可在菜单中增加一些选型，后续可以和实际编译关联在一起
-- 'boolean' option
option("test1")
set_default(true)
set_showmenu(true)
set_category("root menu/test1")
-- 'choice' option with values: "a", "b", "c"
option("test2")
set_default("a")
set_values("a", "b", "c")
set_showmenu(true)
set_category("root menu/test2")
-- 'string' option
option("test3")
set_default("xx")
set_showmenu(true)
set_category("root menu/test3/test3")
-- 'number' option
option("test4")
set_default(6)
set_showmenu(true)
set_category("root menu/test4")
实际这个menu中除了用户自定义的这一部分，剩下的选型基本就是xmake的参数配置，可以在menu中一层层配置好，就是操作起来有点麻烦。
回归初心，实际如果用类似这样的menu做构建，真的比直接用现成的IDE好了嘛，只能说这样的menu是一种通用的交互手段，可以跨平台服务各种代码，但是对于本身不太需要跨平台的项目来说，menu就是一种倒退。
类似的linux，menu能用起来是建立在完善的配置项上，各种模块之间耦合或者冲突都需要完善到配置文件中，否则别人用起来也会出一堆问题。
https://www.cnblogs.com/zxdplay/p/17768181.html
https://www.cnblogs.com/zzb-Dream-90Time/p/7111435.html
https://cloud.tencent.com/developer/article/1825589
https://tboox.org/cn/2018/02/03/update-v2.1.9/
2024-11-22 00:00:00
安装gRPC库
pip install grpcio
安装gRPC工具
pip install grpcio-tools
下载官方例程
git clone -b v1.66.0 --depth 1 --shallow-submodules https://github.com/grpc/grpc
演示用例在这里
grpc/examples/python/helloworld
先启动服务端
python greeter_server.py
可以看到已经在监听了
再启动客户端
python greeter_client.py
正常连接到了服务端
服务端
from concurrent import futures
import logging
import grpc
import helloworld_pb2
import helloworld_pb2_grpc
# 继承自helloworld_pb2_grpc.GreeterServicer,重写了sayhello的函数
class Greeter(helloworld_pb2_grpc.GreeterServicer):
def SayHello(self, request, context):
# 对应返回 hello 和访问者的名字
return helloworld_pb2.HelloReply(message="Hello, %s!" % request.name)
def serve():
# 启动还是比较简单的，设置好端口
port = "50051"
# 调用helloworld_pb2_grpc就完成了
server = grpc.server(futures.ThreadPoolExecutor(max_workers=10))
helloworld_pb2_grpc.add_GreeterServicer_to_server(Greeter(), server)
server.add_insecure_port("[::]:" + port)
server.start()
print("Server started, listening on " + port)
server.wait_for_termination()
if __name__ == "__main__":
logging.basicConfig()
serve()
客户端
from __future__ import print_function
import logging
import grpc
import helloworld_pb2
import helloworld_pb2_grpc
def run():
# NOTE(gRPC Python Team): .close() is possible on a channel and should be
# used in circumstances in which the with statement does not fit the needs
# of the code.
print("Will try to greet world ...")
# 设置本地 端口
with grpc.insecure_channel("localhost:50051") as channel:
stub = helloworld_pb2_grpc.GreeterStub(channel)
# 发送信息 并等待结果
response = stub.SayHello(helloworld_pb2.HelloRequest(name="you"))
print("Greeter client received: " + response.message)
if __name__ == "__main__":
logging.basicConfig()
run()
helloworld_pb2_grpc.py
# 继承的原型函数在这里
class GreeterServicer(object):
"""The greeting service definition.
"""
def SayHello(self, request, context):
"""Sends a greeting
"""
context.set_code(grpc.StatusCode.UNIMPLEMENTED)
context.set_details('Method not implemented!')
raise NotImplementedError('Method not implemented!')
def SayHelloStreamReply(self, request, context):
"""Missing associated documentation comment in .proto file."""
context.set_code(grpc.StatusCode.UNIMPLEMENTED)
context.set_details('Method not implemented!')
raise NotImplementedError('Method not implemented!')
def SayHelloBidiStream(self, request_iterator, context):
"""Missing associated documentation comment in .proto file."""
context.set_code(grpc.StatusCode.UNIMPLEMENTED)
context.set_details('Method not implemented!')
raise NotImplementedError('Method not implemented!')
# 主要是这个函数，把函数的返回绑定到一起
def add_GreeterServicer_to_server(servicer, server):
rpc_method_handlers = {
'SayHello': grpc.unary_unary_rpc_method_handler(
servicer.SayHello,
request_deserializer=helloworld__pb2.HelloRequest.FromString,
response_serializer=helloworld__pb2.HelloReply.SerializeToString,
),
'SayHelloStreamReply': grpc.unary_stream_rpc_method_handler(
servicer.SayHelloStreamReply,
request_deserializer=helloworld__pb2.HelloRequest.FromString,
response_serializer=helloworld__pb2.HelloReply.SerializeToString,
),
'SayHelloBidiStream': grpc.stream_stream_rpc_method_handler(
servicer.SayHelloBidiStream,
request_deserializer=helloworld__pb2.HelloRequest.FromString,
response_serializer=helloworld__pb2.HelloReply.SerializeToString,
),
}
# 创建服务名称和通用句柄
generic_handler = grpc.method_handlers_generic_handler(
'helloworld.Greeter', rpc_method_handlers)
# server添加通用的句柄
server.add_generic_rpc_handlers((generic_handler,))
# 将处理方法注册给server
server.add_registered_method_handlers('helloworld.Greeter', rpc_method_handlers)
helloworld_pb2.py
"""Generated protocol buffer code."""
from google.protobuf import descriptor as _descriptor
from google.protobuf import descriptor_pool as _descriptor_pool
from google.protobuf import runtime_version as _runtime_version
from google.protobuf import symbol_database as _symbol_database
from google.protobuf.internal import builder as _builder
_runtime_version.ValidateProtobufRuntimeVersion(
_runtime_version.Domain.PUBLIC,
5,
27,
2,
'',
'helloworld.proto'
)
# @@protoc_insertion_point(imports)
_sym_db = _symbol_database.Default()
# 这里直接用代码的形式写了一个helloworld的描述符
DESCRIPTOR = _descriptor_pool.Default().AddSerializedFile(b'\n\x10helloworld.proto\x12\nhelloworld\"\x1c\n\x0cHelloRequest\x12\x0c\n\x04name\x18\x01 \x01(\t\"\x1d\n\nHelloReply\x12\x0f\n\x07message\x18\x01 \x01(\t2\xe4\x01\n\x07Greeter\x12>\n\x08SayHello\x12\x18.helloworld.HelloRequest\x1a\x16.helloworld.HelloReply\"\x00\x12K\n\x13SayHelloStreamReply\x12\x18.helloworld.HelloRequest\x1a\x16.helloworld.HelloReply\"\x00\x30\x01\x12L\n\x12SayHelloBidiStream\x12\x18.helloworld.HelloRequest\x1a\x16.helloworld.HelloReply\"\x00(\x01\x30\x01\x42\x36\n\x1bio.grpc.examples.helloworldB\x0fHelloWorldProtoP\x01\xa2\x02\x03HLWb\x06proto3')
_globals = globals()
_builder.BuildMessageAndEnumDescriptors(DESCRIPTOR, _globals)
_builder.BuildTopDescriptorsAndMessages(DESCRIPTOR, 'helloworld_pb2', _globals)
if not _descriptor._USE_C_DESCRIPTORS:
_globals['DESCRIPTOR']._loaded_options = None
_globals['DESCRIPTOR']._serialized_options = b'\n\033io.grpc.examples.helloworldB\017HelloWorldProtoP\001\242\002\003HLW'
_globals['_HELLOREQUEST']._serialized_start=32
_globals['_HELLOREQUEST']._serialized_end=60
_globals['_HELLOREPLY']._serialized_start=62
_globals['_HELLOREPLY']._serialized_end=91
_globals['_GREETER']._serialized_start=94
_globals['_GREETER']._serialized_end=322
# @@protoc_insertion_point(module_scope)
实际这里使用的proto文件，是如下定义的
// The greeting service definition.
service Greeter {
// Sends a greeting
rpc SayHello (HelloRequest) returns (HelloReply) {}
}
// The request message containing the user's name.
message HelloRequest {
string name = 1;
}
// The response message containing the greetings
message HelloReply {
string message = 1;
}
实际使用的proto文件是在examples/protos/helloworld.proto中的，这里添加一个新的函数
syntax = "proto3";
option java_multiple_files = true;
option java_package = "io.grpc.examples.helloworld";
option java_outer_classname = "HelloWorldProto";
option objc_class_prefix = "HLW";
package helloworld;
// The greeting service definition.
service Greeter {
// Sends a greeting
rpc SayHello (HelloRequest) returns (HelloReply) {}
rpc SayHello2 (HelloRequest) returns (HelloReply) {}
rpc SayHelloStreamReply (HelloRequest) returns (stream HelloReply) {}
rpc SayHelloBidiStream (stream HelloRequest) returns (stream HelloReply) {}
}
// The request message containing the user's name.
message HelloRequest {
string name = 1;
}
// The response message containing the greetings
message HelloReply {
string message = 1;
}
需要重新生成对应的代码
python -m grpc_tools.protoc -I../../protos --python_out=. --pyi_out=. --grpc_python_out=. ../../protos/helloworld.proto
这里就会重新生成了
def add_GreeterServicer_to_server(servicer, server):
rpc_method_handlers = {
'SayHello': grpc.unary_unary_rpc_method_handler(
servicer.SayHello,
request_deserializer=helloworld__pb2.HelloRequest.FromString,
response_serializer=helloworld__pb2.HelloReply.SerializeToString,
),
'SayHello2': grpc.unary_unary_rpc_method_handler(
servicer.SayHello2,
request_deserializer=helloworld__pb2.HelloRequest.FromString,
response_serializer=helloworld__pb2.HelloReply.SerializeToString,
),
server和client都增加hello2以后，再次运行就能看到已经给过来正确的反应了
到这里最简单的gRPC就完成了
核心就三步：
上面演示的例子都是C/S架构的，也是gRPC常用的模式，一方请求，一方应答，这是普通的RPC。服务方是不能主动发起请求的，只有客户方主动。还有其他3种方式。
还是之前的例子中，有对应的流式实现
NUMBER_OF_REPLY = 10
class Greeter(MultiGreeterServicer):
async def sayHello(
self, request: HelloRequest, context: grpc.aio.ServicerContext
) -> HelloReply:
logging.info("Serving sayHello request %s", request)
for i in range(NUMBER_OF_REPLY):
yield HelloReply(message=f"Hello number {i}, {request.name}!")
对于服务端的响应，这里可以看到返回了10此请求，并且这个函数是异步的
async def run() -> None:
async with grpc.aio.insecure_channel("localhost:50051") as channel:
stub = hellostreamingworld_pb2_grpc.MultiGreeterStub(channel)
# Read from an async generator
async for response in stub.sayHello(
hellostreamingworld_pb2.HelloRequest(name="you")
):
print(
"Greeter client received from async generator: "
+ response.message
)
# Direct read from the stub
hello_stream = stub.sayHello(
hellostreamingworld_pb2.HelloRequest(name="you")
)
while True:
response = await hello_stream.read()
if response == grpc.aio.EOF:
break
print(
"Greeter client received from direct read: " + response.message
)
客户端这边，前面是异步流式获取，后面是正常流式获取获取
可能看例子，这里流式传输的意义不是很明显，除了能多次发送请求或者多次响应，还有啥用。
grpc的双向流式可以类比成WebSocket，客户端和服务器都可以互相发送信息
// The greeting service definition.
service Greeter {
// Sends a greeting
rpc SayHello (HelloRequest) returns (HelloReply) {}
rpc SayHello2 (HelloRequest) returns (HelloReply) {}
rpc SayHelloStreamReply (HelloRequest) returns (stream HelloReply) {}
rpc SayHelloBidiStream (stream HelloRequest) returns (stream HelloReply) {}
}
在流式传输的例子中proto文件的定义使用了一个特殊关键词，stream凡是被stream修饰的参数，那么传输时就会采用流式。
如果修饰到返回值，那就是服务器流式，如果修饰参数，那就是客户端流式，如果同时有那就是双向流式传输
总体来说gRPC就是这样，流式上感觉似乎没有WebSocket简单，特别是如果是用来做双向交互的时候WebSocket似乎更简单，更好做一些
https://grpc.io/docs/languages/python/quickstart/
https://blog.yuanpei.me/posts/grpc-streaming-transmission-minimalist-guide/
https://hamhire.tech/posts/coding/grpc-03.stream-demo.html