Foreword

RSS难得新增一员，体验一下Follow，看看和TTRss有啥不一样的，有啥改进的点

Follow

https://follow.is/

Follow支持opml导入，所以TTRSS的内容可以直接导进来，对应也有配套的APP，不用自己去找支持TTRSS的订阅APP，生态整体比较完整

Follow整个界面也更加现代一些，TTRSS则是更简洁，更快，动效上明显多了很多内容

相比TTRSS可能需要设置各种插件来爬取文章内容，Follow似乎把这一块都简化了，更容易上手一些

打开某一个blog的文章，是可以看到有多少人也一起订阅了这个网站的内容

甚至可以看到我自己的的网站被多少人订阅了，我可以看到具体谁阅读过我的文章

认证

如果这是你的订阅源，需要本人认证，可以通过下面的三种方式

大致看了下，内容和描述都要插入一些奇怪的东西，不喜欢，还是插入RSS标签好一点

对应我Blog中的feed.xml增加标签即可

---
layout: null
---
<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Elmagnifico's Blog</title>
    <description>后端与嵌入式、maya与游戏 | elmagnifico， Back-end engineer &amp; Embedded System Lover | 这里是elmagnifico的个人博客，君子之交淡如水。</description>
    <link>https://elmagnifico.tech/</link>
    <atom:link href="https://elmagnifico.tech/feed.xml" rel="self" type="application/rss+xml" />
    <pubDate>Sun, 23 Feb 2025 01:14:03 +0800</pubDate>
    <lastBuildDate>Sun, 23 Feb 2025 01:14:03 +0800</lastBuildDate>
    <generator>Jekyll v4.3.2</generator>
    <follow_challenge>
        <feedId>55855418052542483</feedId>
        <userId>101522814280570880</userId>
    </follow_challenge>    
    
      <item>
        <title>Kconfig与CMake初步模块化工程</title>
        <description>## Foreword

使用CMkae+Kconfig最小化的创建一个可以模块化的工程，可以适用于大部分MCU类型的工程，并且有一定程度的扩展性。

## 需求环境

环境需要的东西比较多，要安装4个独立程序才行，对比IDE一键安装，是复杂了一些

#### Arm GNU Toolchain

&gt; https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads

Arm交叉编译的环境，这个是编译的必需品，选择10.3的经典版本，实际上选择最新版（13.3和14.2）也没问题

Version 10.3-2021.10

&gt; https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/downloads

14.2.Rel1 版本

&gt; https://developer.arm.com/-/media/Files/downloads/gnu/14.2.rel1/binrel/arm-gnu-toolchain-14.2.rel1-mingw-w64-x86_64-arm-none-eabi.exe

安装时勾选加入环境变量，省的手动添加

#### MinGW64

&gt; https://github.com/niXman/mingw-builds-binaries/releases

还需要mingw64的make工具链，需要手动加入环境变量，最好顺手把`mingw32-make.exe`改成`make.exe`，不然用起来很麻烦

#### CMake

&gt; https://cmake.org/download/

安装时勾选加入环境变量，省的手动添加

#### Kconfig-Python

还需要python环境和对应的包，某些情况可能会用到离线包，这里也一起说明

![image-20250222185916218](https://img.elmagnifico.tech/static/upload/elmagnifico/202502221859309.png)

注意python安装时的tcl/tk 这个需要安装，否则会缺少tkinter，打不开kconfig gui

核心就是这两个包得安装

pip install kconfiglib pip install windows-curses




如果使用whl的离线安装包，就可以这样安装

pip install windows_curses-2.4.1-cp313-cp313-win_amd64.whl pip install kconfiglib-2.2.2-py2.py3-none-any.whl

## 架构

#### 结构

核心就几个文件夹，把各个模块解耦，组合到一起就行了

- application，系统的入口，启动文件，调用各个module完成业务
- driver，驱动层，驱动各种具体的设备
- module，任务层，实现各种业务细节
- platform，硬件层，给driver层提供硬件接口，实际使用的MCU的HAL或者标准驱动层
- rtos，使用的操作系统
- tools，完成Kconfig转换的代码
- cmake，编译器或者跨平台的相关CMake代码

这里重点是如何利用CMake和Kconfig进行组合，不是架构内的细节代码要怎么写

#### 使用方法

配置工程

python -m guiconfig


生成头文件

python tools/kconfig.py Kconfig .config autoconf.h kconfigLog.txt .config


预设

cmake -S . -B build/Debug –preset Debug


make

cmake –build build/Debug –target project-debug-make


编译

cmake –build build/Debug –target project-debug-build


清空

cmake –build build/Debug –target project-debug-clean

## 解析

#### 实现细节

如果是Makefile+Kconfig，平常也是把Kconfig的宏引入到Makefile中，同理CMake+Kconfig也需要，否则只能通过宏去括起来整个文件，那种方式就非常麻烦

ifdef CONFIG_XXX … endif

- 有很多代码都需要挨个加这个宏，那可太费劲了



最关键的点就是这里，将Kconfig生成的宏利用CMake读取进来，并且转换成CMake的宏

```cmake
# Add sources and includes
file(READ &quot;autoconf.h&quot; config_content)
#message(STATUS &quot;Found config macro: ${config_content}&quot;)
string(REGEX MATCHALL &quot;CONFIG_[A-Z0-9_]+&quot; config_macros ${config_content})

foreach(macro ${config_macros})
    #message(STATUS &quot;Found config macro: ${macro}&quot;)
    set(${macro} ${macro})
    #target_compile_definitions(${CMAKE_PROJECT_NAME} PRIVATE ${macro})
endforeach()

还有一种方式就是通过python独去Kconfig，然后转成一个CMake文件，再被主CMakeLists引入，不过这样就需要依赖python，我不太喜欢，实现代码如下

import os


def parse_config_file_cmake(config_file):
    config_vars = {}
    with open(config_file, 'r') as f:
        for line in f:
            # Skip comments and empty lines
            if line.startswith('#') or line.strip() == '':
                continue
            # Parse configuration line
            key, value = line.strip().split('=', 1)
            # Remove 'CONFIG_' prefix from the key name
            key = key[7:] if key.startswith('CONFIG_') else key
            # Handle quotes in the value
            if value.startswith('&quot;') and value.endswith('&quot;'):
                value = value[1:-1]
            # Add to dictionary
            config_vars[key] = value
    return config_vars


def write_cmake_file(config_vars, cmake_file):
    with open(cmake_file, 'w') as f:
        f.write('# Automatically generated by config_to_cmake.py\n')
        for key, value in config_vars.items():
            f.write('set({} &quot;{}&quot;)\n'.format(key, value))


def convert_config_to_cmake(config_file, cmake_file):
    config_vars = parse_config_file_cmake(config_file)
    write_cmake_file(config_vars, cmake_file)


def parse_config_file_header(config_file):
    config_vars = []
    with open(config_file, 'r') as f:
        for line in f:
            # Skip comments and empty lines
            if line.startswith('#') or line.strip() == '':
                continue
            # Parse configuration line
            key, value = line.strip().split('=', 1)
            # If the value is 'y', replace it with a space
            value = value.strip()
            if value == 'y':
                value = '1'
            # Remove 'CONFIG_' prefix from the key name
            key = key[7:] if key.startswith('CONFIG_') else key
            # Add to list
            config_vars.append((key, value))
    return config_vars


def write_config_header(config_vars, header_file):
    with open(header_file, 'w') as f:
        f.write('// Automatically generated by config_to_header.py\n')
        f.write('#ifndef __KCONFIG_H__\n')
        f.write('#define __KCONFIG_H__\n\n')

        for key, value in config_vars:
            f.write('#define {} {}\n'.format(key, value))

        f.write('\n#endif // __KCONFIG_H__')


def convert_config_to_header(config_file, header_file):
    config_vars = parse_config_file_header(config_file)
    write_config_header(config_vars, header_file)


config_file = '.config'       # Path to your .config file
cmake_file = 'kconfig.cmake'  # Path to the generated kconfig.cmake file
header_file = 'kconfig.h'     # Path to the generated kconfig.h file

# Convert .config file to kconfig.cmake file
convert_config_to_cmake(config_file, cmake_file)

# Convert .config file to kconfig.h file
convert_config_to_header(config_file, header_file)

每个需要做选择的地方都放置一个kconfig，用来生成宏，在对应上级的位置引入这个kconfig

menu &quot;Driver Configuration&quot;
  config LED
      bool &quot;LED&quot;

  config Motor
      bool &quot;Motor&quot;
endmenu

有了宏以后就可以通过宏来控制文件编译

# sources

if(CONFIG_LED)
    target_sources(${CMAKE_PROJECT_NAME} PRIVATE
        ${CMAKE_CURRENT_SOURCE_DIR}/driver/led.c
    )
    # include
    target_include_directories(${CMAKE_PROJECT_NAME} PRIVATE 
        ${CMAKE_CURRENT_SOURCE_DIR}/driver
    )
endif()

if(CONFIG_MOTOR)
    file(GLOB_RECURSE DRIVER_SOURCES
        # 加入文件夹
        ${CMAKE_CURRENT_SOURCE_DIR}/driver/motor/*.*
    )
    target_sources(${CMAKE_PROJECT_NAME} PRIVATE ${DRIVER_SOURCES})

    # include
    target_include_directories(${CMAKE_PROJECT_NAME} PRIVATE 
        ${CMAKE_CURRENT_SOURCE_DIR}/driver/motor
    )
endif()

小技巧

利用 dir /b指令可以快速获取当前文件夹内各文件的名称，从而给AI去帮我们写模板化的代码（AI无法获取文件结构）

不仅仅kconfig可以这么处理，实际上cmake也可以这么处理，快速将已有的文件加入到某个编译选型内

注意检查，copilot偶尔会写错，比如之前把某两个字母顺序写倒了，编译半天总是报错，才发现路径不对

其他

记录一些CMake的操作

CMake排除文件，使用正则的方式进行排除

file(GLOB_RECURSE USER_SOURCES
    &quot;libs/*.*&quot;
)

将含有math/vector路径、desperate的文件排除
list(FILTER USER_SOURCES EXCLUDE REGEX &quot;desperated&quot;)
list(FILTER USER_SOURCES EXCLUDE REGEX &quot;math/vector&quot;)

还有一种使用删除进行删除

file(GLOB_RECURSE FILE *.cpp *.c *.h)
 
file(GLOB_RECURSE WEBRTC_FILE webrtc_test.*  ${CMAKE_CURRENT_SOURCE_DIR}/src/webrtc_*)
 
file(GLOB_RECURSE WEBRTC_DIR ${CMAKE_CURRENT_SOURCE_DIR}/src/webrtc/*)
list(REMOVE_ITEM FILE ${WEBRTC_FILE})
list(REMOVE_ITEM FILE ${WEBRTC_DIR})

CMake有两种方式添加库，或者说叫添加.a文件

# Add linked libraries
target_link_libraries(${CMAKE_PROJECT_NAME}
    # Add user defined libraries
    -l:xxxx.a
    libyyyy.a
)

一种是需要你把原本的库命名为lib开头的，一种是通过-l指定非lab开头的库

.cmake和CMakeLists的区别

.cmake，是通过include()方式进行引入的，本质上是嵌入主cmake文件中的，所以是按照顺序执行的
CMakeLists，是通过add_subdirectory()方式引入，不嵌入主cmake中，执行顺序是比主cmake优先的

.cmake由于是嵌入，所以也就不存在什么局部变量全局变量一说，都是在主cmake中的，所以通用，但是CMakeLists不是，他作为子部分，默认情况下他的变量只能他自己使用，只有cmake自己的全局变量是可以被使用的，用户自定义的是无法使用的。

但是也有办法使用主cmake的变量

set(LINKER_SCRIPT ${CMAKE_CURRENT_SOURCE_DIR}/xxx/link.ld CACHE STRING &quot;Linker Script Path&quot; FORCE)

首先是将变量变成CACHE，这样这个变量就会被全局缓存，但是这种方式只是会保存这个变量，也就是子cmake可以用主cmake的这个变量的值，但是子cmake不能反过来设置这个值

如果要设置这个值，必须使用后面的FORCE关键字来修改

总而言之子CMakeLists的作用域类似于编程语言中的函数，写在其中的内容的作用域也类似于一个函数内的各种变量的作用域

Summary

还没有完全优化完成，比如同时编译四五个配置，怎么把这四五个配置暂存下来，方便后续编译，而不是每次都要切换配置去编译，还有CMake和Kconfig能不能只写其中一个，另外一个自动生成？

目前对于模块的引入能不能自动识别加入，而不用手动写引入的部分。

CMake和Kconfig这种模式还有一个小问题，生成的宏是直接文件级别跳过编译的，但是如果要同时兼容IDE或者VSCode这类的时候，能不能将这些关联导入到这些IDE里，否则IDE里总是显示不正常的，快速跳转也会跳到错误的位置上

Quote

> https://github.com/LuckkMaker/apm32-kconfig-example

</description> Sat, 22 Feb 2025 00:00:00 +0800 https://elmagnifico.tech/2025/02/22/Kconfig-CMake/</link> https://elmagnifico.tech/2025/02/22/Kconfig-CMake/

    <category>Kconfig</category>
    
    <category>CMake</category>
    
    
  </item>

  <item>
    <title>VSCode Kconfig插件</title>
    <description>## Foreword

还是决定自己写一个Kconfig通用插件，这里记录一下相关的内容

KconfigLib

Kconfig ：是一款Linux可视化配置文件格式。
Kconfiglib：是一款基于Kconfig格式实现的Linux可视化配置工具。

还是先玩明白目前的python系是怎么显示和处理Kconfig的

查了一下guiconfig.py 似乎可以以更好的形式来显示Kconfig配置内容

安装

pip install kconfiglib
pip install windows-curses

测试

正常情况下可以通过这种方式调用menuconfig，从而显示kconfig内容

python D:\\Python\\Python312\\Lib\\site-packages\\menuconfig.py

移除绝对地址以后，可以使用下面这种方式调用

python -m menuconfig

如果使用guiconfig，可以看到界面是类似QT的形式了，可以直接选择而不是嵌入在命令行中了

python -m guiconfig

突然发现这种方式似乎就够目前使用了，VSCode的版本甚至可以往后放一下

生成配置时使用下面的命令就可以生成一个config.h文件

python -m genconfig

也可以自定义一个.h的配置

python -m genconfig --header-path hello.h

kconfig-frontends

深入调研以后发现，kconfig还有qt的版本，那理论上也有windows的版本，qt转windows还是比较简单的

理论上这些kconfig都是来源于kconfig-frontends

> https://github.com/uvc-ingenieure/kconfig-frontends

NuttX似乎都是基于kconfig-qconf的

目前看到各个框架似乎都抛弃了kconfig-frontends，迎接KconfigLib去了

> https://github.com/RT-Thread/rt-thread/pull/9050

kconfig-frontends似乎长年不更新，而KconfigLib里有一些新特性可以简化Kconfig

Summary

先凑活用，日后还有需要再继续在这里完善

Quote

> https://zhuanlan.zhihu.com/p/6068151451 > > https://github.com/LuckkMaker/apm32-kconfig-example > > https://blog.csdn.net/wenbo13579/article/details/127464764 > > https://boozlachu.medium.com/using-kconfig-for-own-projects-deb21e0d1804 > > https://www.jianshu.com/p/00ce218ab598 > > https://bbs.21ic.com/icview-3412466-1-1.html

</description> Thu, 23 Jan 2025 00:00:00 +0800 https://elmagnifico.tech/2025/01/23/VSCode-Kconfig-Extension/</link> https://elmagnifico.tech/2025/01/23/VSCode-Kconfig-Extension/

    <category>build</category>
    
    
  </item>

  <item>
    <title>2024游戏短评</title>
    <description>## Foreword

一年一度短评环节又到了

steam自建的2024年游戏回顾

> https://store.steampowered.com/replay/76561198094167163/2024

今年游玩

今年一共玩了44款游戏，比去年还多一些，60%都是新游戏

大侠立志传

大侠立志传确实是又一个金庸群侠传，很不错

神仙醋确实继承了以前金庸群侠传的衣钵，今年还看到了神仙醋他们的的纪录片，想做一个这样的小游戏确实不容易，醋神他们也是暴死了好几次，靠着一款产品续命，才能养活这样一个单机游戏，而单机游戏想要长期收入是不太可能的，做完一款就必须投入到下一款去了。对于制作人来说，相当于是一直在绞尽脑汁挖掘灵感，制作游戏，否则就会陷入没有产出，收入下滑的问题。

对于武侠游戏、开放世界、像素风，这个类型来说，盘子确实比较小，能带来的收入是有限的，而且最重要的是他有很大可能会暴死，只要玩家不买账，那么这一年或者两年的投入直接打水漂，对于团队来说这种风险很高，得要有一帮子多年的老人才能玩的下去。

对于神仙醋熟悉的领域来说，会买账的大多也是当年的一些人了，更年轻的人他们想要的东西，有些时候其实和老人的审美或者角度，已经不一样了。想要再成功一次可能是比较难的，而对于一些经典模式的复刻反而是比较稳妥的实现。

Super Raft Boat Together

游戏内容过少了，难度相对也比较简单，定价58，实在是有点吃亏，8块可能比较合适

熔炉密林

手残的一年，但是把熔炉密林打通了，新DLC也随便打通了。游戏看起来简单，但是实际操作有很多技巧，这些游戏内都不是很容易摸索出来，需要外部攻略，游戏又非常肝，需要反复刷很久才能遇到想要的装备。

土豆兄弟

从家庭组白嫖的游戏，也挺好玩的，自由组合搭配各种build，节奏比吸血鬼幸运者快一些，能玩的组合很多种

暖雪

前几年出的Roguelite游戏，今年才有空白嫖玩一下，操作很爽，自己摸到了一个套路，直接全通关了。游戏内build也蛮丰富的，我估计就玩了10%不到的可能性

传说法师1/2Demo

传说法师重温了1代，确实挺难的，找了几个组合还是有点手残不好打，打击感超棒的。

传说法师2代也同时发布了，不过2代有点不好玩，Demo流程很短，很多东西都没解锁，手残玩起来很难。

后续2代发布以后，直接就褒贬不一了

Hades

家庭分享，哈迪斯整体操作手感是真的不错，对比暖雪、熔炉、传说法师等等，画面细节、北欧众神、各种搞笑的小桥段，整个游戏刷是一方面，但是剧情在循序渐进，让你有一个明显的盼头，知道下一次刷他会出现什么东西。一代基本都是近战或者类似近战的操作，非常耐玩，手残也能打过最终的boss。

Hades2

哈迪斯2就有点难评了，2代以妹妹为操作对象，妹妹是个法师，很多操作都改变了，2代需要很多长按，蓄力类的操作来打伤害，和一代的那种按一下就能打出来伤害来说，操作显得极其难受。2代的进阶操作或者说更高伤害都需要长按，不知道为什么要这么设计，这样手感就变得很差，虽然打通了，但是总是爽不起来。

由于2代是EA，所以很多内容都还没完善，有点意思的是2代在游戏中可以直接进入1代场景，也顺便看了一下2代的游戏代码，竟然就是lua直接控制的，那其实1代就给出来一个游戏框架了，2代只需要填入素材和数值，就可以直接套模板，所以一二代可以直接实现穿越式的体验，甚至很多Mod或者修改，都是直接修改源码中的条件，如果有人愿意再深入一下，完全可以以Hades为基础，搞一个自己的游戏。

Darkest Dungeon

之前先玩过了铁轨与墓穴，EA的时候很简单，说是和这个游戏差不多，所以来看看，再看到这个游戏这么多年了还有人在玩，在直播，不可思议，所以试试。一试发现这游戏太难了，打了N个mod，简化了游戏内容，我都觉得难得要死，不会再玩第二次了。暗黑地牢，是真的黑暗，一个人玩都能玩的心惊胆战，团灭了三次，每次都想弃坑，好不容易培养的4个6级顶级天赋的人直接变坟堆，气得要死。

最后开着加速器总算是把游戏剧情全打通了，这还是最简单的难度，最高难度不敢想象，一个个都是数值管理大师。

火山的女儿

额，一个养女儿的游戏，不是这类游戏受众，只能说来体验一下为什么这么多人玩这个，感觉算是以前的4399集大成者，缝合了很多内容进来，但是比较巧妙的是作者没有让每个东都变得很难受，控制了一下复杂度，大多数情况都可以稍微思考一下找到解，没有让系统爆炸，没有那么紧迫的感觉，慢慢养女儿就行。只能说还可以，但是我不喜欢。

刀剑江湖路

看起来是想做一个武侠+DNF+金庸群侠传的游戏，甚至可能还有一点太吾的意思，不过系统不完善，目前剧情很多也没做完，分支也没有，主角很多时候的选择完全没用。虽然是DNF式的横板战斗搓招，但是手感差的要死，操控起来很难受。

如果有老菊之类的再给他做个长视频，游戏机制再完善完善，估计会很有意思

超级键盘侠

一个挺恶搞的游戏，游戏里梗比较多，但是套路有点少

Glyphica Typing Survival

> https://elmagnifico.tech/2024/05/30/Glyphica/

一个打字游戏，非常有意思，之前评论过了不再重复，作者也在加班加点搞中文版本，很不错

夜族崛起

化身吸血鬼，培养血奴，害怕太阳，把吸血鬼复刻到游戏里，整体还能联机、生存、剧情、刷刷刷、还需要一些操作，有build可玩，就是后期肝度实在是太高了，游戏里的极品道具都非常难获取，估计上百小时才能刷满一套。游戏完成度比较高，还在持续更新。

Abiotic Factor

非生物因素，把恐怖元素结合进来的生存游戏，多人联机会比较好，游戏内容还不完善，剧情也没有写完，还是等后续更新吧

小丑牌

策略游戏，有意思，一出就风靡全球，简单的玩法，一上手就都懂了，一局时间相对比较短，由此开启一个新游戏模式，各种丑牌、甚至麻将等等模仿者接接踵而至。

Chained together

平台跳跃游戏，但是能联机，这种游戏以前也有很多，但是这个游戏他把人链接在一起了，游戏中间可以有保存点，错了还能重来，疯狂压力队友，贼搞笑，不过游戏目前场景比较少，如果后续有自定义工坊等等，内容更多了，可能比较欢乐。

戴森球计划

一直想玩一直拖着，拖到这游戏都4年了，很像程序员开发的东西，整个流水线的配置和写代码式的，不过游戏目标不知道是什么，没有动力玩下去了

杀戮台球

杀戮台球，把策略和各种build带到了台球里，也不是很贵，玩起来比较轻松

中华一商

免费领的游戏，就是过程有点繁琐，中间偏后期很无聊

ASTRONEER

当年玩的时候游戏内容还很少，后面越发展内容越多了，后期的玩法就是3D版本的戴森球了，自动化工厂流水线，每年大概有几个活动事件，总体也是挂机自动化的干活

POE2

poe的二代，当年就听说开发了，现在才出来，二代相对一代去掉了系统里很多很繁杂的设定，整个系统变得简单了。

玩了一个月差不多终局毕业了，就是这个游戏排骨人太多了，基本全都是来刷了赚钱的，没有好好玩游戏的，有点难受

雨中冒险：回归

雨冒一代，操作有点难受，反人类，不知道为啥重置不愿意改一下，整体玩法一般般，还是二代好玩

失落城堡2

之前失落城堡各种父子玩耍，现在总算出二代了，玩了Demo，但是bug一堆，玩法深度也一般，等到EA版本出来，果然直接跌下神坛，多半好评了。

已买待玩

雾锁王国

这个去年就要玩来着，还是没玩，据说是类似夜族崛起的那种模式，不过还在EA，还能等正式版

绝世好武功

1.0版本总算出了，可以重新体验一下了

大江湖之苍龙与白鸟

这游戏跳票这么久，大侠同时期的游戏，现在都还没做完，等他实际完成看看吧

博德之门3

今年可能会试试这个游戏，看看他是什么样的模式，为什么这么多好评

赛博朋克

可能会玩一下

巫师3

可能会玩一下

小缇娜的奇幻之地

无主的番外篇，据说无主4也要出了，可以体验一下

诺兰德

一直没空玩，在等他EA结束，似乎现在可以了

新游期待

主要是一些Demo游戏的游玩体验，感觉不错

咒印链接

即时战斗策略游戏，游戏里可以得到各种各样的链接或者道具，连在一起就可以形成各种comb，最终通关。有点以前POE的宝石链接的意思，但是可以连得更长，更多种形式，目前Demo很不错，期待后期发售

腐朽默示

一个像素风，但是可以生存、建造、打僵尸、招小弟的游戏，可惜只能单人，目前玩起来还可以。

如果能支持多人联机估计会更好

息风谷战略

策略游戏，但是回合战斗，同时又能自动战斗，还能养成，养老婆的游戏，Demo的可玩内容已经挺多的了，不过玩法也比较单一，目前深度不是很够，build玩法没有明显构建起来

Sephiria

像素风的Roguelite游戏，游戏难度比较高，也是背包管理类型，格子各种搭配可以组合出来一些特效，手感也不错。

Hell Clock

玩的时间不长，但是作为Rougelite+刷子游戏，总体build还是有点意思的

Monster Hunter Wilds

怪猎荒野，试玩，但是感觉机器带不动了，卡卡的，任务引导也莫名其妙的，手感似乎和上一代差不多，等2.28发售再说吧

梦之形

Roguelite游戏，MOBA风格，刷起来很爽，支持联机，已经打通全程，今年在日本还在展会遇到了制作组，挺不错的

其他

活侠传

没玩，但是出了果然就挨骂了，剧本不错，但是评论两极分化

黑神话：悟空

云完了，没有玩，挺不错的，不过不是我喜欢的类型

Summary

还是有一些期待2025的 </description> Wed, 22 Jan 2025 00:00:00 +0800 https://elmagnifico.tech/2025/01/22/Game-Comment5/</link> https://elmagnifico.tech/2025/01/22/Game-Comment5/

    <category>Game</category>
    
    
  </item>

  <item>
    <title>SES Threads 自定义JS脚本</title>
    <description>## Foreword

最近又遇到了一些奇怪的bug，意外发现调试手段上还是有所欠缺，而SES的js脚本可以做更多自定义的工具，可以进一步改造方便疑难杂症使用

Threads Script

需要注意Threads Script用的是Java Script，而不是Jlink Script（前面查了半天发现不对），虽然都简称成了js，但是Jlink Script应该只有Jlink的一些批处理程序才会使用这种方式写脚本

之前有说过SES的RTOS Awareness好像有点问题，老是显示不全，不如Ozone的

貌似这个问题在我提给官方以后修复了

之前有提到显示操作系统线程情况的脚本，这里发现其实这个东西可以自定义的程度还是蛮高的

/*********************************************************************
*               SEGGER MICROCONTROLLER GmbH                          *
*       Solutions for real time microcontroller applications         *
**********************************************************************
*                                                                    *
*       (c) 1995 - 2019  SEGGER Microcontroller GmbH                 *
*                                                                    *
*       www.segger.com     Support: support@segger.com               *
*                                                                    *
**********************************************************************
*                                                                    *
*       Please note:                                                 *
*                                                                    *
*       Knowledge of this file may under no circumstances            *
*       be used to write a similar product                           *
*                                                                    *
*       Thank you for your fairness !                                *
*                                                                    *
**********************************************************************
*                                                                    *
*       Current version number will be inserted here                 *
*       when shipment is built.                                      *
*                                                                    *
**********************************************************************

----------------------------------------------------------------------
File        : FreeRTOSPlugin_CM7.js
Purpose     : Ozone FreeRTOS-awareness JavaScript Plugin for Cortex-M7
---------------------------END-OF-HEADER------------------------------
*/

/*********************************************************************
*
*       Local Functions
*
**********************************************************************
*/

/*********************************************************************
*
*       GetTaskStackGrowDir
*  
* Function description
*   Indicates if the task stack grows in positive (1) or negative (-1) memory direction
*
* Notes
*   (1) The stack grow direction depends on the FreeRTOS-port.
*       Currently, a positive grow direction is only used on the PIC architecture.
*/
function GetTaskStackGrowDir() {    
  return -1;
}

/*********************************************************************
*
*       GetTaskPrioName
*  
* Function description
*   Returns the display text of a task priority
*
* Parameters
*   Priority: task priority (integer)
*/
function GetTaskPrioName(Priority) {
    
  var sName;
  
  if (Priority == 0) {
    sName = &quot;Idle&quot;
  } else if (Priority == 1) {
    sName = &quot;Low&quot;
  } else if (Priority == 2) {
    sName = &quot;Normal&quot;;
  } else if (Priority == 3) {
    sName = &quot;High&quot;;
  } else if (Priority == 4) {
    sName = &quot;Highest&quot;;
  } else {
    return Priority.toString();
  } 
  sName = sName + &quot; (&quot; + Priority + &quot;)&quot;;
  return sName;
}

/*********************************************************************
*
*       GetTaskName
*  
* Function description
*   Returns the display text of a task name
*
* Parameters
*   tcb:   task control block (type tskTCB)
*   Addr:  control block memory location
*/
function GetTaskName(tcb, Addr) {
    
   var sTaskName;
   
   sTaskName = Debug.evaluate(&quot;(char*)(*(tskTCB*)&quot; + Addr + &quot;).pcTaskName&quot;);
   if (sTaskName == undefined) {
     sTaskName = Debug.evaluate(&quot;(char*)(*(TCB_t*)&quot; + Addr + &quot;).pcTaskName&quot;);
   }
   
   if (tcb.uxTCBNumber != undefined) {
     sTaskName = &quot;#&quot; + tcb.uxTCBNumber + &quot; \&quot;&quot; + sTaskName + &quot;\&quot;&quot;;
   }
   return sTaskName;
}

/*********************************************************************
*
*       GetTaskID
*  
* Function description
*   Returns the display text of a task ID
*
* Parameters
*   tcb:   task control block (type tskTCB)
*   Addr:  control block memory location
*/
function GetTaskID(tcb, Addr) { 
   return  &quot;0x&quot; + (tcb.uxTCBNumber == undefined ? Addr.toString(16) : tcb.uxTCBNumber.toString(16));
}

/*********************************************************************
*
*       GetTCB
*  
* Function description
*   Returns the task control block of a task
*
* Parameters
*   Addr: control block memory location
*/
function GetTCB(Addr) { 
  var tcb;
  tcb = Debug.evaluate(&quot;*(tskTCB*)&quot; + Addr);
  if (tcb == undefined) {
    tcb = Debug.evaluate(&quot;*(TCB_t*)&quot; + Addr);
  }
  return tcb;
}

/*********************************************************************
*
*       GetTaskNotifyStateStr
*  
* Function description
*   Returns the display string of a task notify state
*
* Parameters
*   tcb: task control block (type tskTCB)
*/
function GetTaskNotifyStateStr(tcb) {

   if (tcb.ucNotifyState == undefined) {
     return tcb.eNotifyState == undefined ? &quot;N/A&quot; : tcb.eNotifyState.toString();
   } else {
     return tcb.ucNotifyState.toString()
   }
}

/*********************************************************************
*
*       GetTaskStackInfoStr
*  
* Function description
*   Returns a display text of the format &quot;&lt;free space&gt; / &lt;stack size&gt;&quot;
*
* Parameters
*   tcb: task control block (type tskTCB)
*
* Notes
*   (1) pxEndOfStack is only available when FreeRTOS was compiled with 
*       configRECORD_STACK_HIGH_ADDRESS == 1
*/
function GetTaskStackInfoStr(tcb) {
  var FreeSpace;
  var UsedSpace;
  var Size;
  //                                GrowDir == 0     GrowDir == 1
  //
  // pxStack       |  Low Addr   |  Stack Top     |  Stack Base    |
  //               |             |                |                |
  // pxTopOfStack  |             |  Stack Pointer |  Stack Pointer |       
  //               |             |                |                |
  // pxEndOfStack  |  High Addr  |  Stack Base    |  Stack Top     |
  // 
  if (GetTaskStackGrowDir() == 1) { // stack grows in positive address direction
  
    if (tcb.pxEndOfStack == undefined) {
      UsedSpace  =  tcb.pxTopOfStack - tcb.pxStack;
      FreeSpace  =  undefined;
      Size       =  undefined;  
    } else {
      FreeSpace  =  tcb.pxEndOfStack - tcb.pxTopOfStack;
      UsedSpace  =  tcb.pxTopOfStack - tcb.pxStack;
      Size       =  FreeSpace + UsedSpace;  
    }
  } else {    // stack grows in negative address direction
  
    if (tcb.pxEndOfStack == undefined) {
      FreeSpace  =  tcb.pxTopOfStack - tcb.pxStack;     
      UsedSpace  =  undefined;      
      Size       =  undefined;
    } else {
      FreeSpace  =  tcb.pxTopOfStack - tcb.pxStack;     
      UsedSpace  =  tcb.pxEndOfStack - tcb.pxTopOfStack;      
      Size       =  FreeSpace + UsedSpace;
    }   
  }   
  return FreeSpace + &quot; / &quot; + (Size == undefined ? &quot;N/A&quot; : Size);   
}

function GetLabel1(tcb) {
  var FreeSpace;
  var UsedSpace;
  var Size;
  //                                GrowDir == 0     GrowDir == 1
  //
  // pxStack       |  Low Addr   |  Stack Top     |  Stack Base    |
  //               |             |                |                |
  // pxTopOfStack  |             |  Stack Pointer |  Stack Pointer |       
  //               |             |                |                |
  // pxEndOfStack  |  High Addr  |  Stack Base    |  Stack Top     |
  // 
  if (GetTaskStackGrowDir() == 1) { // stack grows in positive address direction
  
    if (tcb.pxEndOfStack == undefined) {
      UsedSpace  =  tcb.pxTopOfStack - tcb.pxStack;
      FreeSpace  =  undefined;
      Size       =  undefined;  
    } else {
      FreeSpace  =  tcb.pxEndOfStack - tcb.pxTopOfStack;
      UsedSpace  =  tcb.pxTopOfStack - tcb.pxStack;
      Size       =  FreeSpace + UsedSpace;  
    }
  } else {    // stack grows in negative address direction
    // FreeRTOS -1 ,go on here
    if (tcb.pxEndOfStack == undefined) {
      FreeSpace  =  tcb.pxTopOfStack - tcb.pxStack;     
      UsedSpace  =  undefined;      
      Size       =  undefined;
    } else {
      FreeSpace  =  tcb.pxTopOfStack - tcb.pxStack;     
      UsedSpace  =  tcb.pxEndOfStack - tcb.pxTopOfStack;      
      Size       =  FreeSpace + UsedSpace;
    }   
  }   
  return &quot;0x&quot;+tcb.pxTopOfStack.toString(16) + &quot; / &quot; + &quot;0x&quot;+tcb.pxStack.toString(16);   
}

function GetLabel2(addr) {
  return addr.toString(16);   
}

function GetLabel3(param) {
  return param.toString(16);   
}

/*********************************************************************
*
*       AddTask
*  
* Function description
*   Adds a task to the task window
*
* Parameters
*   Addr:            memory location of the task's control block (TCB)
*   CurrTaskAddr:    memory location of the executing task's control block (TCB)
*   sState:          state of the task (e.g. &quot;executing&quot;)
*/
function AddTask(Addr, CurrTaskAddr, sState) {
  var tcb;
  var sTaskName; 
  var sPriority;
  var sRunCnt;
  var sMutexCnt;
  var sTimeout;
  var sStackInfo;
  var sID;
  var sNotifiedValue;
  var sNotifyState; 
  var Lable1
  var Lable2
  var Lable3

  tcb            = GetTCB(Addr);
  sTaskName      = GetTaskName(tcb, Addr);
  sID            = GetTaskID(tcb, Addr);
  sStackInfo     = GetTaskStackInfoStr(tcb);
  sPriority      = GetTaskPrioName(tcb.uxPriority);
  sNotifyState   = GetTaskNotifyStateStr(tcb);
  sTimeout       = (tcb.Timeout          == undefined ? &quot;N/A&quot; : tcb.Timeout.toString());
  sRunCnt        = (tcb.ulRunTimeCounter == undefined ? &quot;N/A&quot; : tcb.ulRunTimeCounter.toString());
  sNotifiedValue = (tcb.ulNotifiedValue  == undefined ? &quot;N/A&quot; : tcb.ulNotifiedValue.toString());
  sMutexCnt      = (tcb.uxMutexesHeld    == undefined ? &quot;N/A&quot; : tcb.uxMutexesHeld.toString());

  // custom labels
  Lable1  = GetLabel1(tcb);
  Lable2  = GetLabel2(Addr);
  Lable3  = GetLabel3(0);
 
  if (Addr == CurrTaskAddr) {
    sState = &quot;executing&quot;;
  } 
  Threads.add(sTaskName, sRunCnt, sPriority, sState, sTimeout, sStackInfo, sID, sMutexCnt, sNotifiedValue, sNotifyState, Lable1,Lable2,Lable3,(Addr == CurrTaskAddr) ? undefined : Addr);
}

/*********************************************************************
*
*       AddList
*  
* Function description
*   Adds all tasks of a task list to the task window
*
* Parameters
*   List:            task list (type xLIST)
*   CurrTaskAddr:    memory location of the executing task's control block (TCB)
*   sState:          common state of all tasks within 'list'
*/
function AddList(List, CurrTaskAddr, sState) {
  var i;
  var Index;
  var Item;
  var TaskAddr;

  if ((List != undefined) &amp;&amp; (List.uxNumberOfItems &gt; 0)) {
      
    Index = List.xListEnd.pxNext;
    
    for (i = 0; i &lt; List.uxNumberOfItems; i++) {
        
      Item = Debug.evaluate(&quot;*(xLIST_ITEM*)&quot; + Index);

      TaskAddr = Item != 0 ? Item.pvOwner : 0;

      if (TaskAddr != 0) {
        AddTask(TaskAddr, CurrTaskAddr, sState);
      }
      Index = Item.pxNext;

      if (i &gt; 1000) { // infinite loop guard
        break;
      }
    }
  }
}

/*********************************************************************
*
*       API Functions
*
**********************************************************************
*/

/*********************************************************************
*
*       init
*  
* Function description
*   Initializes the task window
*/
function init() {
    
  Threads.clear();
  Threads.newqueue(&quot;Task List&quot;);
  Threads.setColumns(&quot;Name&quot;, &quot;Run Count&quot;, &quot;Priority&quot;, &quot;Status&quot;, &quot;Timeout&quot;, &quot;Stack Info&quot;, &quot;ID&quot;, &quot;Mutex Count&quot;, &quot;Notified Value&quot;, &quot;Notify State&quot;,&quot;Lable1&quot;,&quot;Lable2&quot;,&quot;Lable3&quot;);
  Threads.setColor(&quot;Status&quot;, &quot;ready&quot;, &quot;executing&quot;, &quot;blocked&quot;);
}

/*********************************************************************
*
*       update
*  
* Function description
*   Updates the task window
*/
function update() {
  var i;
  var pList;
  var List;
  var MaxPriority;
  var CurrTaskAddr;

  Threads.clear();

  if((Debug.evaluate(&quot;pxCurrentTCB&quot;) == 0) || (Debug.evaluate(&quot;pxCurrentTCB&quot;) == undefined)) {
    return;
  }
  MaxPriority  = Debug.evaluate(&quot;uxTopReadyPriority&quot;);  
  CurrTaskAddr = Debug.evaluate(&quot;pxCurrentTCB&quot;);

  for (i = MaxPriority; i &gt;= 0; i--) {
    List = Debug.evaluate(&quot;pxReadyTasksLists[&quot; + i + &quot;]&quot;);
    AddList(List, CurrTaskAddr, &quot;ready&quot;);
  }

  pList = Debug.evaluate(&quot;pxDelayedTaskList&quot;);
  if (pList != 0) {
    List = Debug.evaluate(&quot;*(xLIST*)&quot; + pList);
    AddList(List, CurrTaskAddr, &quot;blocked&quot;);
  }

  pList = Debug.evaluate(&quot;pxOverflowDelayedTaskList&quot;);
  if (pList != 0) {
    List = Debug.evaluate(&quot;*(xLIST*)&quot; + pList);
    AddList(List, CurrTaskAddr, &quot;blocked&quot;);
  }

  List = Debug.evaluate(&quot;xSuspendedTaskList&quot;);
  if (List != 0) {
    AddList(List, CurrTaskAddr, &quot;suspended&quot;);
  } 
}

/*********************************************************************
*
*       getregs
*
* Function description
*   Returns the register set of a task.
*   For ARM cores, this function is expected to return the values
*   of registers R0 to R15 and PSR.
*
* Parameters
*   hTask: integer number identifiying the task.
*   Identical to the last parameter supplied to method Threads.add.
*   For convenience, this should be the address of the TCB.
*
* Return Values
*   An array of unsigned integers containing the tasks register values.
*   The array must be sorted according to the logical indexes of the regs.
*   The logical register indexing scheme is defined by the ELF-DWARF ABI.
*
**********************************************************************
*/
function getregs(hTask) { 
  var i;
  var SP;
  var LR;
  var Addr;
  var tcb;
  var aRegs = new Array(17);

  tcb  =  GetTCB(hTask);
  SP   =  tcb.pxTopOfStack;
  Addr =  SP;
  
  /* the following registers are pushed by the FreeRTOS-scheduler */
  //
  // R4...R11
  //
  for (i = 4; i &lt; 12; i++) {
    aRegs[i] = TargetInterface.peekWord(Addr); 
    Addr += 4;
  }
  //
  // EXEC_RET
  //
  LR = TargetInterface.peekWord(Addr);
  Addr += 4;
  //
  // S16...S31
  //
  if ((LR &amp; 0x10) != 0x10) { // FP context has been saved?
    Addr += 4*16; // skip S16..S31
  }
  /* the following registers are pushed by the ARM core */
  //
  // R0...R3
  //
  for (i = 0; i &lt; 4; i++) {
    aRegs[i] = TargetInterface.peekWord(Addr);  
    Addr += 4;
  }
  //
  // R12, LR, PC, PSR
  //
  aRegs[12] = TargetInterface.peekWord(Addr); 
  Addr += 4;
  aRegs[14] = TargetInterface.peekWord(Addr);  
  Addr += 4;
  aRegs[15] = TargetInterface.peekWord(Addr); 
  Addr += 4;
  aRegs[16] = TargetInterface.peekWord(Addr); 
  Addr += 4;
  //
  // S0..S15
  //
  if ((LR &amp; 0x10) != 0x10) { // FP context has been saved?
    Addr += 4*18; // skip S0...S15
  }
  if (aRegs[16] &amp; (1&lt;&lt;9)) { // Stack has been 8-byte aligned
    Addr += 4;
  }
  //
  // SP
  //
  aRegs[13] = Addr;
  
  return aRegs;
}

/*********************************************************************
*
*       getContextSwitchAddrs
*
*  Functions description
*    Returns an unsigned integer array containing the base addresses 
*    of all functions that complete a task switch when executed.
*/
function getContextSwitchAddrs() {
  
  var aAddrs;
  var Addr;
  
  Addr = Debug.evaluate(&quot;&amp;vTaskSwitchContext&quot;);
  
  if (Addr != undefined) {
    aAddrs = new Array(1);
    aAddrs[0] = Addr;
    return aAddrs;
  } 
  return [];
}

/*********************************************************************
*
*       getOSName()
*
*  Functions description:
*    Returns the name of the RTOS this script supplies support for
*/
function getOSName() {
  return &quot;FreeRTOS&quot;;
}

这里主要是增加了三个标签的显示

可以显示栈的起始指针和当前指针位置、TCB指针位置，还多了一个标签待定，随便定义显示什么

整个脚本里主要显示的表格是Threads，只要在它里面去加内容就行了

function init() {
    
  Threads.clear();
  Threads.newqueue(&quot;Task List&quot;);
  Threads.setColumns(&quot;Name&quot;, &quot;Run Count&quot;, &quot;Priority&quot;, &quot;Status&quot;, &quot;Timeout&quot;, &quot;Stack Info&quot;, &quot;ID&quot;, &quot;Mutex Count&quot;, &quot;Notified Value&quot;, &quot;Notify State&quot;,&quot;Lable1&quot;,&quot;Lable2&quot;,&quot;Lable3&quot;);
  Threads.setColor(&quot;Status&quot;, &quot;ready&quot;, &quot;executing&quot;, &quot;blocked&quot;);
}

剩下显示具体变量也好，还是什么其他东西也好，都可以使用这个函数来完成

Debug.evaluate(&quot;pxCurrentTCB&quot;)

他会把对应的变量转成实际的内容返回

如果要调试某个函数，还可以通过这种方式来获取到具体的函数名称

Debug.getfunction(address)

如果相加额外的表格列，对应加上一个数字即可

function init()
{
  ...
  Threads.setColumns2(&quot;Timers&quot;, &quot;Id(Timers)&quot;, &quot;Name&quot;, &quot;Hook&quot;, &quot;Timeout&quot;, &quot;Period&quot;, &quot;Active&quot;);

function update()
{
  ...
  Threads.add2(&quot;Timers&quot;, &quot;0x1FF0A30&quot;, &quot;MyTimer&quot;, &quot;0x46C8 (Timer50)&quot;, &quot;50(550)&quot;, &quot;50&quot;, &quot;1&quot;);

每次更新脚本以后只需要Reload一下，就可以直接加载允许了，不需要断开jlink重连什么的，还是非常方便的

特别是如果遇到踩内存或者需要遍历各个队列什么的，就可以用js脚本直接写一个然后输出到外部框里就行了

其他

虽然官方文档里有Echo，类似console.log，但是试了一下在js这里写这个内容是完全无效的，可以正常执行，但是结果不知道输出到哪里去了

WScript.Echo(s)

这个小插件的报错有点不友好，很容易看不出来具体错误是什么，要怎么改

而又缺少对这个小插件调试的手段，只能一遍遍试着跑，有点蛋疼

Summary

好用的脚本还是得多积累积累，下次遇到问题才能派上用场

Quote

> https://studio.segger.com/index.htm?https://studio.segger.com/ide_debug_expressions.htm

</description> Tue, 21 Jan 2025 00:00:00 +0800 https://elmagnifico.tech/2025/01/21/JS-SES-Ozone/</link> https://elmagnifico.tech/2025/01/21/JS-SES-Ozone/

    <category>SES</category>
    
    
  </item>

  <item>
    <title>RSS Follow体验</title>
    <description>## Foreword

RSS难得新增一员，体验一下Follow，看看和TTRss有啥不一样的，有啥改进的点

Follow

> https://follow.is/

Follow支持opml导入，所以TTRSS的内容可以直接导进来，对应也有配套的APP，不用自己去找支持TTRSS的订阅APP，生态整体比较完整

Follow整个界面也更加现代一些，TTRSS则是更简洁，更快，动效上明显多了很多内容

相比TTRSS可能需要设置各种插件来爬取文章内容，Follow似乎把这一块都简化了，更容易上手一些

打开某一个blog的文章，是可以看到有多少人也一起订阅了这个网站的内容

甚至可以看到我自己的的网站被多少人订阅了，我可以看到具体谁阅读过我的文章

认证

如果这是你的订阅源，需要本人认证，可以通过下面的三种方式

大致看了下，内容和描述都要插入一些奇怪的东西，不喜欢，还是插入RSS标签好一点

对应我Blog中的feed.xml增加标签即可

---
layout: null
---
&lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&gt;
&lt;rss version=&quot;2.0&quot; xmlns:atom=&quot;http://www.w3.org/2005/Atom&quot;&gt;
  &lt;channel&gt;
    &lt;title&gt;{{ site.title | xml_escape }}&lt;/title&gt;
    &lt;description&gt;{{ site.description | xml_escape }}&lt;/description&gt;
    &lt;link&gt;{{ site.url }}{{ site.baseurl }}/&lt;/link&gt;
    &lt;atom:link href=&quot;{{ &quot;/feed.xml&quot; | prepend: site.baseurl | prepend: site.url }}&quot; rel=&quot;self&quot; type=&quot;application/rss+xml&quot; /&gt;
    &lt;pubDate&gt;{{ site.time | date_to_rfc822 }}&lt;/pubDate&gt;
    &lt;lastBuildDate&gt;{{ site.time | date_to_rfc822 }}&lt;/lastBuildDate&gt;
    &lt;generator&gt;Jekyll v{{ jekyll.version }}&lt;/generator&gt;
    &lt;follow_challenge&gt;
        &lt;feedId&gt;55855418052542483&lt;/feedId&gt;
        &lt;userId&gt;101522814280570880&lt;/userId&gt;
    &lt;/follow_challenge&gt;    
    {% for post in site.posts limit:10 %}
      &lt;item&gt;
        &lt;title&gt;{{ post.title | xml_escape }}&lt;/title&gt;
        &lt;description&gt;{{ post.content | xml_escape }}&lt;/description&gt;
        &lt;pubDate&gt;{{ post.date | date_to_rfc822 }}&lt;/pubDate&gt;
        &lt;link&gt;{{ post.url | prepend: site.baseurl | prepend: site.url }}&lt;/link&gt;
        &lt;guid isPermaLink=&quot;true&quot;&gt;{{ post.url | prepend: site.baseurl | prepend: site.url }}&lt;/guid&gt;
        {% for tag in post.tags %}
        &lt;category&gt;{{ tag | xml_escape }}&lt;/category&gt;
        {% endfor %}
        {% for cat in post.categories %}
        &lt;category&gt;{{ cat | xml_escape }}&lt;/category&gt;
        {% endfor %}
      &lt;/item&gt;
    {% endfor %}
  &lt;/channel&gt;
&lt;/rss&gt;

认证完成以后就会有一个小勾了

这是我多年积攒下来的一些订阅源，直接用Follow就可以分享，甚至还可以出售

> https://app.follow.is/share/lists/104444993002142720

看起来似乎Follow想通过这种订阅或者说活跃转化成对应的虚拟货币进而维持或者是激励？？

这里是我自己的归类，似乎和上面的一样，只是订阅这个人可以订阅到他设置的所有订阅源？

> https://app.follow.is/share/users/101522814280570880

看了下RSSHub，在这里竟然是有人提供RSSHub实例然后收费，帮你爬取一些内容，普通人部署了RSSHub也可以加入其中，目前官方应该是免费给你用的，可能某一天官方就不免费了，就要你自己去爬取内容了？那我为什么不用TTRSS，直接全集成好了，还不要去给别人掏钱，费这个鸟劲。

Summary

目前Follow已经是公测阶段，可以免费加入了，但是功能不是完全体的，要完全功能还是得邀请码激活，这个比较麻烦，我也是问人要了一个才能导入甚至分享订阅的

目前看Follow有点意思，但是不多，比我的TTRSS其实没好多少，很多页面也是完全爬不到，还得配合RSSHub来一起使用抓取内容，那我感觉就没啥必要了，不能直接整合这个东西，体验上还是差一点的

目前看起来这个生态只是个金字塔，只有顶端流量大的人有的赚，其他人只能被收割，看起来并不是一个能循环起来的东西。前一段时间的火爆，现在很少看到相关内容了，估计后续生态起不来依然会沉寂到死

他只能对现有RSS的订阅再次划分，而不能产生新的内容，甚至想依靠这种划分来收割一波，信息差这么好利用吗，而至于你订阅源是否能得到利益，那就很难说了，订阅源作为核心的产出者，没有得到应有的流量，反而把利润分给了分发者和服务部署的人。生产者和消费者被剥削了，中介从中获利？

Quote

> https://app.follow.is/share/lists/104444993002142720

</description> Tue, 21 Jan 2025 00:00:00 +0800 https://elmagnifico.tech/2025/01/21/RSS-Follow/</link> https://elmagnifico.tech/2025/01/21/RSS-Follow/

    <category>RSS</category>
    
    
  </item>

  <item>
    <title>nRF-Kconfig插件解析</title>
    <description>&lt;h2 id=&quot;foreword&quot;&gt;Foreword&lt;/h2&gt;

之前刚好看过一点VScode插件原理，这里就能用上了，看一下nRF-Kconfig是怎么实现的，改一个通用版本来，方便大家使用

<h2 id="nrf-kconfig">nRF-Kconfig</h2>

Kconfig插件的安装目录在这里

<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>C:\Users\用户名.vscode\extensions\nordic-semiconductor.nrf-kconfig-2024.12.13 </code></pre></div></div>

实际这个插件也没有加密或者混淆什么的，可以直接看

<h3 id="尝试build">尝试build</h3>

<div class="language-json highlighter-rouge"><div class="highlight"><pre class="highlight"><code> "scripts": { "vscode:prepublish": "npm run build && npm run changelog", "build": "rimraf dist && tsx ./scripts/build.js –production", "watch": "tsx ./scripts/build.js –watch", "dev": "tsx ./scripts/build.js –watch", "type-check": "tsc –noEmit", "lint": "tsx ../scripts/lint.ts nrf-kconfig", "lintfix": "tsx ../scripts/lint.ts –fix nrf-kconfig", "changelog": "tsx ../scripts/changelog.ts kconfig", "copyright": "npm run –prefix ../ copyright", "buildHeaderFiles": "tsx ../scripts/buildHeaderFiles.ts", "update-build-number": "node ../scripts/updateBuildNumber.js kconfig", "copy-css": "copyfiles \"src//.css\" \"src/**/.scss\" out/nrf-kconfig && copyfiles \"../common/src//.css\" \"../common/src/**/.scss\" out/common", "build-tests": "tsc -p . –outDir out", "watch-tests": "tsc -p . -w –outDir out", "pretest": "npm run build-tests && npm run build && npm run copy-css", "test": "node ./out/nrf-kconfig/test/runTests.js" }, </code></pre></div></div>

直接使用Package.js中的script部分，可以直接build或者prepublish

可能会遇到下面的错误

<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>npm : 无法加载文件 D:\nodejs\npm.ps1，因为在此系统上禁止运行脚本 </code></pre></div></div>

查看脚本允许策略，可以看到返回值是严格，这样不允许npm调用ps1的脚本

<div class="language-powershell highlighter-rouge"><div class="highlight"><pre class="highlight"><code>Get-ExecutionPolicy </code></pre></div></div>

修改策略，改为允许远程运行

<div class="language-powershell highlighter-rouge"><div class="highlight"><pre class="highlight"><code>Set-ExecutionPolicy RemoteSigned </code></pre></div></div>

修改完成，再次进行build，正常了

依然提示缺少rimraf命令，但是至少说明脚本跑起来了，这个问题后面再处理

安装一下rimraf就行了，实际上后续还会有tsx也缺少，一起都安装了

<div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code>npm install –save rimraf npm install –save tsx </code></pre></div></div>

继续往下跑就会发现，这样copy的代码缺少一个script文件夹，这里面包含了各种打包的脚本文件，这里只能先到此为止了

<div class="language-json highlighter-rouge"><div class="highlight"><pre class="highlight"><code>{ "contributes": { # 这里注册了各种使用的按钮 "commands": [ { "command": "kconfig.add", "category": "nRF Kconfig", "title": "Kconfig: Add build folder" }, { "command": "kconfig.showGui", "category": "nRF Kconfig", "title": "Kconfig: Show Config GUI" }, { "command": "kconfig.goToSymDefinition", "category": "nRF Kconfig", "title": "Go to Symbol Definition" }, { "command": "kconfig.expandSubtree", "category": "nRF Kconfig", "title": "Expand Subtree" }, { "command": "kconfig.collapseSubtree", "category": "nRF Kconfig", "title": "Collapse Subtree" }, { "command": "kconfig.ctx.setActive", "category": "nRF Kconfig", "title": "Set Active Context", "icon": "$(edit)" } ], "menus": { "webview/context": [ { "command": "kconfig.goToSymDefinition", "when": "canGoToSymDefinition == true" }, { "command": "kconfig.expandSubtree", "when": "canExpandSubtree == true" }, { "command": "kconfig.collapseSubtree", "when": "canCollapseSubtree == true" } ], "commandPalette": [ { "command": "kconfig.goToSymDefinition", "when": "never" }, { "command": "kconfig.expandSubtree", "when": "never" }, { "command": "kconfig.collapseSubtree", "when": "never" } ], "view/item/context": [], "editor/context": [] }, "submenus": [], # 这里是一些这个插件的一些设置参数 "configuration": { "title": "nRF Kconfig", "type": "object", "description": "Settings for nRF Kconfig", "properties": { "kconfig.zephyr.base": { "type": "string", "description": "Override location of Zephyr. This is only necessary if you want to use nRF Kconfig by itself and the main extension is not installed.", "scope": "machine-overridable" }, "kconfig.python": { "type": "string", "markdownDescription": "Location of Python executable. Python 3 is required to use nRF Kconfig. If no location is specified, then the PATH of the current workspace is used.", "scope": "machine-overridable" }, "kconfig.liveValue": { "type": "boolean", "description": "Show changed values in conf files as ghost assignments on the same line as their original assignment.", "scope": "application", "default": true } } }, # 这里主要是对文件解析和提示的配置，什么类型文件才会被调用解析器进行解析、高亮、补全等 "languages": [ # language定义一个数组，每个数组表示一种支持的语言类型 { # id是每个语言的标识符 "id": "kconfig", # 别名 "aliases": [ "Kconfig" ], # 特指文件名 "filenames": [ "Kconfig" ], # 特指符合某些规则的文件名 "filenamePatterns": [ "Kconfig." ], # 这个里面是语言的具体规则，应该是内容识别的规则（折叠段识别） "configuration": "./language-configuration.json", "icon": { "dark": "./dist/images/dark/kconfig.svg", "light": "./dist/images/light/kconfig.svg" } }, # 下面是特指了一些文件内容，相当于是exclude，排除了某些文件 # 单独指定了他们是什么类型的语言文件，防止误识别 { "id": "python", "filenamePatterns": [ "Kconfig.py" ] }, { "id": "cmake", "filenamePatterns": [ "Kconfig.cmake" ] }, { "id": "css", "filenamePatterns": [ "Kconfig.css" ] }, { "id": "properties", "filenamePatterns": [ "_defconfig", "*.conf", ".config", ".config.sysbuild" ] } ], "viewsWelcome": [] }, "__metadata": { "id": "3c214a32-71ea-4549-a492-0f972af076a5", "publisherId": "c9e8387e-6a8a-4101-bcc0-52d8bf37ca83", "publisherDisplayName": "Nordic Semiconductor", "targetPlatform": "undefined", "isApplicationScoped": false, "isPreReleaseVersion": false, "hasPreReleaseVersion": false, "installedTimestamp": 1734425172758, "pinned": false, "preRelease": false, "source": "gallery", "size": 2490675 }, # 前面安装的几个依赖的模块，这里其实有提示 "dependencies": { "rimraf": "^6.0.1", "tsx": "^4.19.2" } }

</code></pre></div></div>

重点还是看<code class="language-plaintext highlighter-rouge">kconfig.showGui</code>做了些啥

正常应该有一个js调用的脚本，但是没找到，只看到了py文件，找到了py的入口，直接让Copilot帮我分析了一下，大致是启动了一个LSP的语言分析（language symbol phrase）服务，然后这个服务和什么东西用的是rpc通信。

<div class="language-python highlighter-rouge"><div class="highlight"><pre class="highlight"><code>if name == "main": args = parse_args()

&lt;span class=&quot;n&quot;&gt;srv&lt;/span&gt; &lt;span class=&quot;o&quot;&gt;=&lt;/span&gt; &lt;span class=&quot;n&quot;&gt;KconfigServer&lt;/span&gt;&lt;span class=&quot;p&quot;&gt;()&lt;/span&gt;
&lt;span class=&quot;n&quot;&gt;sys&lt;/span&gt;&lt;span class=&quot;p&quot;&gt;.&lt;/span&gt;&lt;span class=&quot;n&quot;&gt;stdout&lt;/span&gt; &lt;span class=&quot;o&quot;&gt;=&lt;/span&gt; &lt;span class=&quot;n&quot;&gt;srv&lt;/span&gt;&lt;span class=&quot;p&quot;&gt;.&lt;/span&gt;&lt;span class=&quot;n&quot;&gt;log&lt;/span&gt;
&lt;span class=&quot;n&quot;&gt;sys&lt;/span&gt;&lt;span class=&quot;p&quot;&gt;.&lt;/span&gt;&lt;span class=&quot;n&quot;&gt;stderr&lt;/span&gt; &lt;span class=&quot;o&quot;&gt;=&lt;/span&gt; &lt;span class=&quot;n&quot;&gt;srv&lt;/span&gt;&lt;span class=&quot;p&quot;&gt;.&lt;/span&gt;&lt;span class=&quot;n&quot;&gt;err&lt;/span&gt;

&lt;span class=&quot;k&quot;&gt;print&lt;/span&gt;&lt;span class=&quot;p&quot;&gt;(&lt;/span&gt;&lt;span class=&quot;s&quot;&gt;&quot;Server starting&quot;&lt;/span&gt;&lt;span class=&quot;p&quot;&gt;)&lt;/span&gt;

&lt;span class=&quot;k&quot;&gt;if&lt;/span&gt; &lt;span class=&quot;n&quot;&gt;args&lt;/span&gt;&lt;span class=&quot;p&quot;&gt;.&lt;/span&gt;&lt;span class=&quot;n&quot;&gt;debug&lt;/span&gt;&lt;span class=&quot;p&quot;&gt;:&lt;/span&gt;
    &lt;span class=&quot;n&quot;&gt;wait_for_debugger&lt;/span&gt;&lt;span class=&quot;p&quot;&gt;()&lt;/span&gt;

&lt;span class=&quot;k&quot;&gt;if&lt;/span&gt; &lt;span class=&quot;n&quot;&gt;args&lt;/span&gt;&lt;span class=&quot;p&quot;&gt;.&lt;/span&gt;&lt;span class=&quot;n&quot;&gt;log&lt;/span&gt;&lt;span class=&quot;p&quot;&gt;:&lt;/span&gt;
    &lt;span class=&quot;n&quot;&gt;srv&lt;/span&gt;&lt;span class=&quot;p&quot;&gt;.&lt;/span&gt;&lt;span class=&quot;n&quot;&gt;logging&lt;/span&gt; &lt;span class=&quot;o&quot;&gt;=&lt;/span&gt; &lt;span class=&quot;bp&quot;&gt;True&lt;/span&gt;

&lt;span class=&quot;n&quot;&gt;srv&lt;/span&gt;&lt;span class=&quot;p&quot;&gt;.&lt;/span&gt;&lt;span class=&quot;n&quot;&gt;loop&lt;/span&gt;&lt;span class=&quot;p&quot;&gt;()&lt;/span&gt; &lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;/div&gt;

目前看起来这个LSP服务主要是用来做代码提示、符号信息、Kconfig内容查找？，不知道和具体文件解析有没有关系。

syntaxes下的kconfig.tmGrammar.json是kconfig高亮的配置文件

目前看应该还有一个前端或者是什么东西，通过rpc通信，将符号信息送给Kconfig进行分析，然后返回对应的信息

比如平常常用的查找定义，客户端发送请求，指定文件和符号所在行和字符（这里为啥不用指定字符的长度？不是很懂）

KconfigServer接收请求并处理

<div class="language-python highlighter-rouge"><div class="highlight"><pre class="highlight"><code>@handler(‘textDocument/definition’) def handle_definition(self, params): sym = self.get_sym(params) if sym: return loc(sym) </code></pre></div></div>

KconfigServer接着发送响应

客户端接收并处理响应，跳转到符号定义位置，那么这次通信就算完成了

但是这个问题，似乎就是nRF Kconfig插件其实没加载，表面上看安装了，但是真正的加载和注册命令是需要extension的其他插件来完成的，虽然代码里写着独立运行，实际上并不可行

<div class="language-json highlighter-rouge"><div class="highlight"><pre class="highlight"><code> configuration: { title: ‘nRF Kconfig’, type: ‘object’, description: ‘Settings for nRF Kconfig’, properties: { ‘kconfig.zephyr.base’: { type: ‘string’, description: ‘Override location of Zephyr. This is only necessary if you want to use nRF Kconfig by itself and the main extension is not installed.’, scope: ‘machine-overridable’, }, ‘kconfig.python’: { type: ‘string’, markdownDescription: ‘Location of Python executable. Python 3 is required to use nRF Kconfig. If no location is specified, then the PATH of the current workspace is used.’, scope: ‘machine-overridable’, }, ‘kconfig.liveValue’: { type: ‘boolean’, description: ‘Show changed values in conf files as ghost assignments on the same line as their original assignment.’, scope: ‘application’, default: true, }, }, }, </code></pre></div></div>

<code class="language-plaintext highlighter-rouge">contributes.ts</code>中主要是用TS写的这个<code class="language-plaintext highlighter-rouge">contributes</code>的字段内容，打包过程中会被用来替换package.json中的内容。而<code class="language-plaintext highlighter-rouge">submenus</code>则是由build脚本填充的，由于缺少这一块，所以这里就空了

<code class="language-plaintext highlighter-rouge">kconfiglsp.py</code>中的<code class="language-plaintext highlighter-rouge">KconfigServer</code>类实现了一个Kconfig语言服务器协议（LSP）服务器。这个服务器通常由一个支持LSP的客户端（如Visual Studio Code或其他支持LSP的编辑器）调用和使用。以下是调用和使用<code class="language-plaintext highlighter-rouge">kconfiglsp.py</code>的典型流程：

<h4 id="1-客户端如vs-code启动lsp服务器">1. 客户端（如VS Code）启动LSP服务器</h4>

当用户在支持LSP的编辑器中打开一个Kconfig文件时，编辑器会根据配置启动相应的LSP服务器。

在VS Code中，这通常通过<code class="language-plaintext highlighter-rouge">package.json</code>中的<code class="language-plaintext highlighter-rouge">contributes</code>和<code class="language-plaintext highlighter-rouge">activationEvents</code>字段配置。例如：

<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>{ "contributes": { "languages": [ { "id": "kconfig", "extensions": [".kconfig"], "configuration": "./language-configuration.json" } ], "commands": [ { "command": "extension.kconfigServer", "title": "Start Kconfig Server" } ] }, "activationEvents": [ "onLanguage:kconfig" ] } </code></pre></div></div>

<ul> <li>这里的分析推敲，其实反向验证了package.json内的内容</li> </ul>

<h4 id="2-启动lsp服务器">2. 启动LSP服务器</h4>

当满足激活条件（如打开Kconfig文件）时，编辑器会启动LSP服务器进程。

这个进程会运行<code class="language-plaintext highlighter-rouge">kconfiglsp.py</code>中的代码，创建并启动<code class="language-plaintext highlighter-rouge">KconfigServer</code>实例。

<h4 id="3-客户端与lsp服务器通信">3. 客户端与LSP服务器通信</h4>

启动后，客户端和LSP服务器通过JSON-RPC协议进行通信。

客户端发送各种LSP请求（如<code class="language-plaintext highlighter-rouge">textDocument/didOpen</code>、<code class="language-plaintext highlighter-rouge">textDocument/didChange</code>、<code class="language-plaintext highlighter-rouge">textDocument/completion</code>等）到服务器，<code class="language-plaintext highlighter-rouge">KconfigServer</code>类处理这些请求，并返回相应的响应。

<h4 id="4-处理请求和响应">4. 处理请求和响应</h4>

<code class="language-plaintext highlighter-rouge">KconfigServer</code>类中的方法（如<code class="language-plaintext highlighter-rouge">handle_initialize</code>、<code class="language-plaintext highlighter-rouge">handle_completion</code>、<code class="language-plaintext highlighter-rouge">handle_definition</code>等）处理来自客户端的请求。

<h4 id="5-服务器发送通知">5. 服务器发送通知</h4>

除了处理请求，<code class="language-plaintext highlighter-rouge">KconfigServer</code>还可以主动发送通知给客户端，例如发布诊断信息（<code class="language-plaintext highlighter-rouge">publish_diags</code>方法）或通知状态变化（<code class="language-plaintext highlighter-rouge">notify_status</code>方法）。

<h3 id="nrf-connect-extension-pack">nRF-connect-extension-pack</h3>

由于上面所有的逻辑都是copilot直接给出来的，实际在这份工程中并没有找到对应的代码，所以不是清楚是怎么一步步调用<code class="language-plaintext highlighter-rouge">kconfiglsp.py</code>的。怀疑这部分的JS代码是直接内嵌在了nRF的整体扩展中，所以单独只安装一个kconfig插件是无法直接显示kconfig的结果的，必须要配合大插件包才能正常启动

这里再把<code class="language-plaintext highlighter-rouge">nordic-semiconductor.nrf-connect-extension-pack-2024.9.5</code>的包拿出来分析一下，看看具体内容是怎么来的

看了一下pack的package.json，发现他好像只是一个整合包，实际并没有什么具体的代码

再仔细看一下extension.js的代码

<div class="language-js highlighter-rouge"><div class="highlight"><pre class="highlight"><code>"use strict"; var objCreate = Object.create; var objProperty = Object.defineProperty; var objPropertyDescriptor = Object.getOwnPropertyDescriptor; var objPropertyNames = Object.getOwnPropertyNames; var objGet = Object.getPrototypeOf, objHasOP = Object.prototype.hasOwnProperty; var b = (n, e) => { for (var t in e) objProperty(n, t, { get: e[t], enumerable: !0 }) }, d = (n, e, t, s) => { if (e && typeof e == "object" || typeof e == "function") for (let i of objPropertyNames(e)) !objHasOP.call(n, i) && i !== t && objProperty(n, i, { get: () => e[i], enumerable: !(s = objPropertyDescriptor(e, i)) || s.enumerable }); return n }; var f = (n, e, t) => (t = n != null ? objCreate(objGet(n)) : {}, d(e || !n || !n.__esModule ? objProperty(t, "default", { value: n, enumerable: !0 }) : t, n)), C = n => d(objProperty({}, "__esModule", { value: !0 }), n); var y = {}; </code></pre></div></div>

使用 b函数将属性从 <code class="language-plaintext highlighter-rouge">source</code> 对象定义到 <code class="language-plaintext highlighter-rouge">target</code> 对象上，而不是直接使用 <code class="language-plaintext highlighter-rouge">source</code> 对象，有几个好处：

封装和模块化：

<ul> <li>通过将属性定义到 <code class="language-plaintext highlighter-rouge">target</code> 对象上，可以更好地封装和模块化代码。这样可以避免直接暴露 <code class="language-plaintext highlighter-rouge">source</code> 对象的内部实现细节。</li> </ul>

动态扩展对象：

<ul> <li>可以动态地将属性添加到 <code class="language-plaintext highlighter-rouge">target</code> 对象上，而不需要修改 <code class="language-plaintext highlighter-rouge">source</code> 对象。这在需要扩展对象功能时非常有用。</li> </ul>

控制属性访问：

<ul> <li>使用 <code class="language-plaintext highlighter-rouge">Object.defineProperty</code> 可以精确控制属性的行为，例如设置属性为只读、可枚举等。在这个例子中，属性被定义为 getter 函数，并且是可枚举的。</li> </ul>

避免命名冲突：

<ul> <li>如果直接使用 <code class="language-plaintext highlighter-rouge">source</code> 对象，可能会与现有对象的属性发生命名冲突。通过将属性定义到 <code class="language-plaintext highlighter-rouge">target</code> 对象上，可以避免这种冲突。</li> </ul>

灵活性：

<ul> <li>可以根据需要选择性地将某些属性定义到 <code class="language-plaintext highlighter-rouge">target</code> 对象上，而不是将整个 <code class="language-plaintext highlighter-rouge">source</code> 对象暴露出来。</li> </ul>

就是通过Object.defineProperty实现一个代理类，后续代码基本都是围绕这个目标来做的。

最终把一些按钮或者触发器注册进了VSCode，这些id就对应上了具体的界面按钮和后续的事件触发机制

可以看到就是在这里把kconfig相关的指令注册进去了，前面报的kconfig不存在，也是因为connect没有启动，这里没有加载

所以还是得去看connect部分的代码

<h3 id="nordic-semiconductornrf-connect">nordic-semiconductor.nrf-connect</h3>

查看extension.js，格式化以后发现这个js的行数有12w，这就有点离谱了

copilot直接放弃工作了，让他读一下直接不会了

看了一下打包文件夹是dist，应该是套在某个框架上写完以后重新打包成了一个.js，所以这个内容就很难反向查了

<h2 id="summary">Summary</h2>

还是重写一个更快，这里能借鉴的只有Kconfig LSP这个部分了 </description> Thu, 02 Jan 2025 00:00:00 +0800 https://elmagnifico.tech/2025/01/02/VSCode-Kconfig/</link> https://elmagnifico.tech/2025/01/02/VSCode-Kconfig/

    <category>build</category>
    
    
  </item>

  <item>
    <title>Zephyr build 架构</title>
    <description>&lt;h2 id=&quot;foreword&quot;&gt;Foreword&lt;/h2&gt;

Zephyr 工程的整个构建体系是怎样的，这里做一个具体的分析和学习

最近小米的Vele 也开源了，不过由于缺少文档，而且架构非常庞大，光是仓库就传了两三百个，想看明白不太容易，但是基础的CMake、Kconfig等等全都有。

<h2 id="cmake">CMake</h2>

<ol> <li>创建构建目录：保持源代码目录整洁。</li> <li>使用 CMake 生成构建文件：配置项目并生成适合平台的构建文件。</li> <li>编译和构建：使用生成的构建文件执行编译和构建。</li> <li>清理构建文件：删除中间文件和目标文件。</li> <li>重新配置和构建：处理项目设置的更改。</li> </ol>

CMake 推荐使用 “Out-of-source” 构建方式，即将构建文件放在源代码目录之外的独立目录中

<h3 id="cmake例程">CMake例程</h3>

一个比较简单的CMake例程

<blockquote> https://github.com/elmagnificogi/MyTools/tree/master/CMake/MyProject1 </blockquote>

<div class="language-c++ highlighter-rouge"><div class="highlight"><pre class="highlight"><code>#include <iostream> int main() { std::cout << "Hello, CMake!" << std::endl; return 0; } </code></pre></div></div>

cpp文件

<div class="language-c++ highlighter-rouge"><div class="highlight"><pre class="highlight"><code>#ifndef MAIN_H #define MAIN_H // Declarations of module functions

#endif // MAIN_H </code></pre></div></div>

头文件

<div class="language-cmake highlighter-rouge"><div class="highlight"><pre class="highlight"><code># 指定最低 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) </code></pre></div></div>

比较简单的CMakeLists.txt定义

新建build目录，将源码和编译路径分开

生成一个MinGW的Makefiles文件

<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>D:\CMake\bin\cmake.exe .. -G "MinGW Makefiles" </code></pre></div></div>

<ul> <li>不指定的话，默认是VS的工程文件</li> </ul>

编译

<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>mingw32-make.exe </code></pre></div></div>

测试

<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>I:\cmake\CMakeTutorialCN\MyProject\build\src>MyExecutable.exe Hello, CMake! </code></pre></div></div>

稍微复杂一些，但是包含了库，移除了测试库，windows下拉不到这个测试库

<blockquote> https://github.com/elmagnificogi/MyTools/tree/master/CMake/MyProject0 </blockquote>

CMake确实稍微步骤多了一些，组织编排就要跑一会，还是这么简单的工程

<h2 id="基于nrf-untiled例程分析">基于nRF untiled例程分析</h2>

<div class="language-cmake highlighter-rouge"><div class="highlight"><pre class="highlight"><code>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) </code></pre></div></div>

编译时执行的 <code class="language-plaintext highlighter-rouge">build.py</code> 脚本中引用了 <code class="language-plaintext highlighter-rouge">Zephyr\scripts\west_commands\Zephyr_ext_common.py</code>，在这个脚本中设置了 Zephyr_BASE 的宏。

<ul> <li>宏的值被设置为了之前sdk安装路径，比如I:\ncs\v2.7.0\Zephyr</li> </ul>

untiled内容比较少，还是需要去看Zephyr内的CMake

先看一眼nRF的SDK包构成

<ul> <li>west 是Zephyr的生成工具</li> <li>modules里面是hal、lab库、文件系统、加密等等模块</li> <li>test测试库</li> <li>Zephyr的主要内容</li> </ul>

Zephyr的包主要存储在这里，通过上面的CMake搜索到这里

Zephyr的CMake主要调用逻辑

<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>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 </code></pre></div></div>

Zephyr主要是两个阶段，配置阶段、编译阶段

根据这个图来说，最终Kconfig生成了autoconf.h，同时持久化了一个.config配置方便后续使用

Zephyr同时也生成了一个设备树，这个概念基本和Linux一样，都是通过设备树来注册驱动进去的，类似的设备树也有同样的一个.h文件。

最终这部分生成文件和产生的Makefile一起进行最后的编译，生成对应固件

<h2 id="自定义kconfig">自定义Kconfig</h2>

在untiled下面新建Kconfig文件，输入以下内容

<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>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" </code></pre></div></div>

重新build一下，然后打开Kconfig GUI就能看到对应显示了

这里比较麻烦的地方就是这个工程每次重新打开，这个GUI就打不开了，必须要点开nRF Connect才能重新打开，非常难受

<h2 id="summary">Summary</h2>

工程越大越复杂，还是希望能稍微控制一下复杂度

参考这个教程，但是这个教程写的一坨屎，为什么还会有人点星

<blockquote> https://github.com/shendeguize/CMakeTutorialCN </blockquote>

<h2 id="quote">Quote</h2>

<blockquote> 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 </blockquote> </description> Fri, 20 Dec 2024 00:00:00 +0800 https://elmagnifico.tech/2024/12/20/Zephyr-Build/</link> https://elmagnifico.tech/2024/12/20/Zephyr-Build/

    <category>build</category>
    
    
  </item>

  <item>
    <title>配置管理工具之kconfig</title>
    <description>&lt;h2 id=&quot;foreword&quot;&gt;Foreword&lt;/h2&gt;

绕了这么大一圈，似乎只有kconfig是比较成熟的，能与之相媲美的管理工具很少

<h2 id="kconfig">Kconfig</h2>

在windows下使用Kconfig，至少得有python，否则界面等内容无法正常显示

python需要先安装这几个包

<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>python -m pip install windows-curses python -m pip install kconfiglib </code></pre></div></div>

测试安装，可以正常显示命令

<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>menuconfig -h </code></pre></div></div>

参考工程sample_1

<blockquote> https://github.com/bobwenstudy/test_kconfig_system </blockquote>

编译所有

修改配置

<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>menuconfig </code></pre></div></div>

运行<code class="language-plaintext highlighter-rouge">main.exe</code>就能看到结果了

<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>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 </code></pre></div></div>

可能会报错，这个是因为curses库他需要终端执行，但是不识别你当前使用的终端，换一个就行了，比如cmd

<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>make 提示Redirection is not supported. </code></pre></div></div>

这个例子里还只有一种config，还不能支持多config配置，可以看到主要就只能生成一个autoconfig.h

<div class="language-makefile highlighter-rouge"><div class="highlight"><pre class="highlight"><code>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 </code></pre></div></div>

<h3 id="多config">多config</h3>

<div class="language-makefile highlighter-rouge"><div class="highlight"><pre class="highlight"><code># 默认编译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) </code></pre></div></div>

对应这样的配置就可以使用下面的方式来独立生成每个APP的配置，这样就可以同时维护多个版本，而要多一个APP，就再加一个配置就行了

上面这个配置还少了一点，生成的都是同一个文件，同一个目录，互相覆盖，其实可以参考OpenWRT，每次不同配置生成都在不同文件夹里，然后对应文件名就更好了

<div class="language-makefile highlighter-rouge"><div class="highlight"><pre class="highlight"><code>APP ?= app/test1 OUTPUT_PATH := output/$(APP) TARGET := main

# 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

$(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, $@)

$(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)

稍微修改一下，增加路径自动创建，这样后续就可以不同配置生成到不同目录中，不会互相覆盖了。同时也自动适配生成的文件名和路径分割符

当然这个Makefile还是有一些缺点，比如所有要编译的.c和.o都得一个个加，还是有点傻

Kconfig发展了这么久，难道没有人想着用VScode来做一下可视化嘛，事实上是有的，但是也都有限，不是很通用

第一个插件只能提供kconfig的语法高亮，不能解决显示问题

第二个就是nRF Kconfig，下面的Konfig for Zephyr Project也停止开发，转而使用nRF Kconfig了

<blockquote> https://marketplace.visualstudio.com/items?itemName=nordic-semiconductor.nrf-kconfig </blockquote>

nRF Kconfig想要用起来还稍微有点麻烦，直接启动不了，所以单独开个段落说明如何使用。

至于非VScode的版本，基本上大部分都是依赖kconfiglib的python库完成显示，或者是结合一下TUI、Tkinter等比较轻量化的框架实现，而整体交互逻辑依然离不开比较原始的上下左右菜单式的

<blockquote> https://github.com/ulfalizer/Kconfiglib

https://github.com/cuinixam/kspl

https://github.com/CoryXie/SConf </blockquote>

其他Kconfig，比如ESP-IDF，就可以很好的体现esp的kconfig内容

但是ESP是专用的，并不适用于其他开发环节或者板子，而且体积很大

<h3 id="demo体验">Demo体验</h3>

由于要启动kconfig必须要配置完工程才能启动，所以记录一下nRF SDK是怎么启动、编译的

<ul> <li>nRF也从SES逃离了，投入VSCode的怀抱了，我SES反馈的问题，SES官方就改了一个，其他的问题都视而不见，无语</li> </ul>

首先安装nRF Connect Extendtion Pack

其实相当于是插件包，我细看了一下，基本上需要的开发环境他都给你打包整合好了，设备树、Kconfig、Cmake、调试、Flash等等工具都有，相当于就是一个IDE了

选择一个工具链，然后等安装完成，这里直接选最新的就行了

继续安装SDK，选择一个路径安装，回车后等待完成

<ul> <li>SDK都有点大，会拉很多Tag进来，最好提前准备好翻墙相关内容</li> <li>2.8.0的SDK貌似拉不下来？，所以切换到2.7.0才正常，对应前一步的toolchains也需要调整到2.7.0</li> </ul>

新建一个应用，然后添加编译配置，选择板子，构建配置，开始编译

编译完成，但是注意一下新工程里面没有Kconfig，但是ACtion里已经可以显示Kconfig UI了

<h3 id="untitled">untitled</h3>

经过测试nRF的Kconfig GUI无法直接打开前面的sample_2工程，显示非nRF工程

这里详细分析一下untitled的默认工程

untitled一共三个文件

<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>mian.c CMakeLists.txt prj.conf </code></pre></div></div>

prj.conf中直接是空白的，main中也没啥特殊内容，主要就是CMakeLists可以被识别？

<div class="language-cmake highlighter-rouge"><div class="highlight"><pre class="highlight"><code>cmake_minimum_required(VERSION 3.20.0) find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE})

project(untitled)

target_sources(app PRIVATE src/main.c) </code></pre></div></div>

实际CMakeLists中的内容也非常少

实际把prj.conf直接复制到sample_2中，Kconfig就可以打开了，但是发现打开的还是untitled的config，而不是sample_2的

关掉其他文件，再打开GUI，就无法启动了。

这里绑定有点深，必须CMakeLists，必须要在build以后才能用GUI，否则无法直接打开GUI界面

而添加Build Config以后，Build文件夹中的内容非常复杂，非常多内容

<h3 id="nordic-semiconductornrf-kconfig">nordic-semiconductor.nrf-kconfig</h3>

看了一眼nRF Kconfig，源码竟然还是python，也就是跑这个必须有对应的python环境，否则还跑不起来，怪不得那个工具链安装好久，原来在下python。python本质上还是调用kconfiglib库来完成kconfig的解析，最后再转成数据送给VS 前端去加载显示

目前看起来源码没有做加密或者混淆，所以要改一个非nRF强关联的版本，应该是比较容易的

<h2 id="vscode-kconfig">vscode-kconfig</h2>

回过头再看Zephyr的kconfig，这个竟然是开源项目，那么只需要搞定他的入口，就可以显示任何kconfig了

<blockquote> https://github.com/trond-snekvik/vscode-kconfig </blockquote>

后续计划一下改出来一个带UI的通用版本

<h2 id="summary">Summary</h2>

目前看只有Zephyr和nRF的Kconfig结合比较深，后续可能还会详细分析一下Zephyr的整体架构是什么样的，整个build是怎么串起来的

<h2 id="quote">Quote</h2>

<blockquote> 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 </blockquote>

</description> Wed, 18 Dec 2024 00:00:00 +0800 https://elmagnifico.tech/2024/12/18/Macro-ManagerTools3/</link> https://elmagnifico.tech/2024/12/18/Macro-ManagerTools3/

    <category>build</category>
    
    
  </item>

  <item>
    <title>QEMU模拟运行FreeRTOS</title>
    <description>&lt;h2 id=&quot;foreword&quot;&gt;Foreword&lt;/h2&gt;

测试一下QEMU模拟运行FreeRTOS

QEMU安装需要先安装MSYS2

直接下载安装

<blockquote> https://www.msys2.org/ </blockquote>

安装完成以后，QEMU使用pacman包进行安装

<blockquote> https://www.qemu.org/download/#windows </blockquote>

<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>pacman -S mingw-w64-x86_64-qemu </code></pre></div></div>

添加新的环境变量，把刚才安装的路径加进去

<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>D:\msys64\mingw64\bin </code></pre></div></div>

查看版本，显示正确

<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>qemu-system-arm -version QEMU emulator version 9.1.1 Copyright (c) 2003-2024 Fabrice Bellard and the QEMU Project developers </code></pre></div></div>

<h2 id="freertos">FreeRTOS</h2>

选择FreeRTOS 202212.01版本下载，包含所有演示项目的

<blockquote> https://freertos.org/zh-cn-cmn-s/Documentation/02-Kernel/01-About-the-FreeRTOS-kernel/03-Download-freeRTOS/01-DownloadFreeRTOS </blockquote>

这里主要是测试使用<code class="language-plaintext highlighter-rouge">FreeRTOS/Demo/CORTEX_MPS2_QEMU_IAR_GCC/build/gcc</code>这个项目，需要至少arm-eabi-none-gcc的环境和make，否则进行不下去

进入到gcc目录，先编译一下

正常编译完成

qemu启动模拟

<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>qemu-system-arm -machine mps2-an385 -cpu cortex-m3 -kernel ./output/RTOSDemo.out -monitor none -nographic -serial stdio </code></pre></div></div>

正常启动，并且task跑起来了，正在输出内容

qemu这里的参数含义

<ul> <li>-machine mps2-an385，这个是ARM的原型版，开发板模型</li> <li>-cpu cortex-m3，指定cpu架构</li> <li>-kernel ./output/RTOSDemo.out 指定使用的镜像文件</li> <li>-monitor none，显示是否要监控，启用的话类似串口，可以使用中断输入输出一些状态信息</li> <li>-nographic，不使用图形界面</li> <li>-serial stdio，串口通过标准终端输入和输出</li> <li>-s -S，链接调试器</li> </ul>

官方QEMU支持的STM32不是很多，而且用起来很麻烦，需要安装两个环境，而且很容易出问题

所以有人打包了QEMU，并且加入了比较多的ST的开源板子，支持的型号比较多

<blockquote> https://github.com/beckus/qemu_stm32 </blockquote>

这个QEMU环境需要重新编译，耗时比较多，或者是从Ubuntu里调用，倒是不用打包成exe

bule bill 的工程用QEMU模拟

<blockquote> https://github.com/beckus/stm32_p103_demos </blockquote>

直接编译

编译完成以后每个demo下面都有对应的bin文件，可以直接拿来模拟使用

<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>qemu-system-arm -M stm32-p103 -kernel main.bin </code></pre></div></div>

同时RT-Thread，他们的IDE里也集成了专属的QEMU版本，也可以快捷完成模拟

<h2 id="summary">Summary</h2>

挺简单的，只是问题QEMU支持的现成芯片、板子比较少，需要自己去找对应的开发板，甚至自己开发，有点麻烦

<h2 id="quote">Quote</h2>

<blockquote> 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 </blockquote>

</description> Sat, 07 Dec 2024 00:00:00 +0800 https://elmagnifico.tech/2024/12/07/QEMU-FreeRTOS/</link> https://elmagnifico.tech/2024/12/07/QEMU-FreeRTOS/

    <category>FreeRTOS</category>
    
    <category>QEMU</category>
    
    
  </item>

  <item>
    <title>宏管理工具之lite-manager</title>
    <description>&lt;h2 id=&quot;foreword&quot;&gt;Foreword&lt;/h2&gt;

体验一下群友的宏管理工具

<h2 id="lite-manager">lite-manager</h2>

<blockquote> https://gitee.com/li-shan-asked/lite-manager </blockquote>

群友的宏管理工具，主要在gitee上更新，github更新不及时，release文件可能不能用

主要是用来方便管理宏定义和生成Makefile，但是大部分设置还是要熟悉Makefile本身，你才能完成lm的配置文件编写，本质上并没有变换脚本语言或者什么的流程

lite-manager在这里有点类似于Kconfig

至少需要一个make和gun c的环境，之前系统里一直有一个MinGW32 13年的版本，gcc大概只有6，编译过不去（后来发现应该不是这个问题）

通过下面的方式在线安装MinGW64

<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>https://github.com/Vuniverse0/mingwInstaller/releases/download/1.2.1/mingwInstaller.exe </code></pre></div></div>

安装完成以后添加环境路径

如果环境里没有多的make，可以把<code class="language-plaintext highlighter-rouge">mingw32-make.exe</code>复制一个改名叫<code class="language-plaintext highlighter-rouge">make.exe</code>，不然最好还是保持原样，否则会影响到系统里其他地方的make使用

<h3 id="链接脚本问题">链接脚本问题</h3>

测试demo，发现无法正常运行，链接脚本无法识别-M的参数

仔细看了一下Makefile，是生产的链接参数就是<code class="language-plaintext highlighter-rouge">-M</code>而不是<code class="language-plaintext highlighter-rouge">-Map</code>

还好lite-manager源码也是有的，修改一下生成脚本

再把生成的lm.exe拖到对应的测试目录下，进行测试，一切正常了

<ul> <li>如果不修改lm，make config时也显示不出来当前宏的状态</li> </ul>

先生成Makefile

<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>./lm.exe -g Makefile -p hello </code></pre></div></div>

然后可以生成config文件，并且查看宏定义情况

<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>make config </code></pre></div></div>

编译

lm.cfg，用来定义宏的定义以及宏之间的关系

proj.cfg，用户定义实际想要的宏

.lm.mk，缓存

config.h，最终处理完约束条件后实际定义出来的宏

lm.cfg中判断条件是自上而下的，遇到冲突点，首先会关闭自身，然后文件之间是从左向右流动的

其中n，表示宏关闭，‘n’是正常使用n这个关键字

同时下面的文件编译的约束也可以同时使用宏来管控

多模块、多组件的工程目录

<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>├───build ├───subdirA | ├───mac_a.c | └───lm.cfg ├───subdirB | ├───mac_b.c | └───lm.cfg └───lm.cfg </code></pre></div></div>

可以使用include直接把下面的配置加载进去

<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>include "subdirA/lm.cfg" include "subdirB/lm.cfg" </code></pre></div></div>

lm的工程实例可以参考这里，有些技巧example里没有用到，可以看看实例是怎么跑的

<blockquote> https://gitee.com/li-shan-asked/ebraid </blockquote>

lite-manager 同时也有类似tui的交互版本，不过作者说比较老、过时，所以不推荐用了

<h3 id="makefile解析">Makefile解析</h3>

<div class="language-makefile highlighter-rouge"><div class="highlight"><pre class="highlight"><code># 自顶向下来看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)

</code></pre></div></div>

<h3 id="lmcfg解析">lm.cfg解析</h3>

实际在hello的lm.cfg中只有一行，就是加了一个文件进去

<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>SRC += hello.c </code></pre></div></div>

这里指定了生成的目标是hello

<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>./lm.exe -g Makefile -p hello </code></pre></div></div>

剩下的Makefile全都靠lm内部自动生成

以stm32f103的工程为例，相当于Makefile是一个通用的Makefile，而lm.cfg 相当于是一个PreMakefile，在这里直接定义Makefile要用的一些参数即可，剩下就是Makefile足够项目通用即可

<div class="language-makefile highlighter-rouge"><div class="highlight"><pre class="highlight"><code># 添加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"

</code></pre></div></div>

使用当前比较通用的<code class="language-plaintext highlighter-rouge">arm-none-eabi</code>的老库

<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>GNU Arm Embedded Toolchain\10 2021.10 </code></pre></div></div>

STM32F103的工程是无法正常编译的

如果没有看过类似的例子或者直接参考Makefile原工程，不可能上手直接使用

如果使用<code class="language-plaintext highlighter-rouge">Arm GNU Toolchain arm-none-eabi\13.3 rel1</code> 确实可以直接编译过

在不同的使用情景下，lite-manager带来的效果还是有一些差别的，假如你是一个对工程特别熟悉的人，那么对应的lm.cfg或者是proj.cfg中的宏都是可以随手改的。但是并不是每个做工程的人都对整个宏特别熟悉，此时就会出现给了一个不熟悉的人去修改，那么他就得一一对照整个lm.cfg里的约束关系和宏定义的可能，再去设置proj.cfg，如果只是几个宏，那随手就改了（几个宏为什么还要用lm？）

如果是几十个宏，此时要查表，再去决定这个宏可以用什么

这个时候lm的结构就变成负担了，虽然lm可以显示最终结果，但是当你发现结果不对的时候，你依然需要逐项去排查是哪里冲突了

类比传统的Makefile工程来说，lm省去了你手动Makefile里各种if条件的书写，确实简化了一部分Makefile复杂的地方

这里提一点我的想法，有一个比较通用的UI显示，类似于xml或者json的UI化显示，定义好一些规则，直接就能把这种宏配置管理给做了

<ul> <li>事实上ESP32已经实现了这样的效果，VScode中一个插件就能把esp32的配置文件变成可视化的，极大方便了玩家DIY</li> </ul>

<h2 id="summary">Summary</h2>

lite-manager 总体还是挺小的，显示也还凑活，代码是开放的，完全可以自定义一些

总体来说lm简化了Makefile，但是想要使用起来依然需要懂Makefile，需要给项目下的每个文件夹增加配置文件，类比.mk文件

<h2 id="quote">Quote</h2>

<blockquote> https://gitee.com/li-shan-asked/lite-manager/tree/noui/

https://blog.csdn.net/ysu_wangli/article/details/106677907 </blockquote>

</description> Tue, 03 Dec 2024 00:00:00 +0800 https://elmagnifico.tech/2024/12/03/Macro-ManagerTools2/</link> https://elmagnifico.tech/2024/12/03/Macro-ManagerTools2/

    <category>build</category>
    
  </item>

</channel> </rss>

```

认证完成以后就会有一个小勾了

这是我多年积攒下来的一些订阅源，直接用Follow就可以分享，甚至还可以出售

https://app.follow.is/share/lists/104444993002142720

看起来似乎Follow想通过这种订阅或者说活跃转化成对应的虚拟货币进而维持或者是激励？？

这里是我自己的归类，似乎和上面的一样，只是订阅这个人可以订阅到他设置的所有订阅源？

https://app.follow.is/share/users/101522814280570880

Summary

Quote

https://app.follow.is/share/lists/104444993002142720

Foreword

Follow

认证

小技巧

其他

Summary

Quote

KconfigLib

安装

测试

kconfig-frontends

Summary

Quote

今年游玩

大侠立志传

Super Raft Boat Together

熔炉密林

土豆兄弟

暖雪

传说法师1/2Demo

Hades

Hades2

Darkest Dungeon

火山的女儿

刀剑江湖路

超级键盘侠

Glyphica Typing Survival

夜族崛起

Abiotic Factor

小丑牌

Chained together

戴森球计划

杀戮台球

中华一商

ASTRONEER

POE2

雨中冒险：回归

失落城堡2

已买待玩

雾锁王国

绝世好武功

大江湖之苍龙与白鸟

博德之门3

赛博朋克

巫师3

小缇娜的奇幻之地

诺兰德

新游期待

咒印链接

腐朽默示

息风谷战略

Sephiria

Hell Clock

Monster Hunter Wilds

梦之形

其他

活侠传

黑神话：悟空

Summary

Threads Script

其他

Summary

Quote

Follow

认证

分享

Summary

Quote

注意一定要引用这个，不然加不进去，并且CMake不了

define user .config setting

define user merged path

首先目标是hello 然后编译输出到build目录

简单说基本上只要不是最终生成的目标，那都是伪指令

伪指令主要是完成一些辅助性的工作，比如clean，检测，切换配置，生成配置等等

检测是否有.lm.mk文件

链接时生成map文件

-MMD -MP -MF $(@:%.o=%.d) 是利用gcc自动生成依赖关系

将build路径下的所有c文件编译成.o文件

Makefile文件自身也是依赖文件，如果Makefile文件发生变动，也需要重新编译

-Wa,-a,-ad,-alms=$(BUILD_DIR)/$(notdir $(&lt;:.c=.lst))：生成临时中间文件

-Wa,-a,-ad,-alms=$(BUILD_DIR)/$(notdir $(<:.c=.lst))：生成临时中间文件

$<是第一个文件