程序员日志

git 推送时提示：send-pack: unexpected disconnect while reading sideband packet fatal: the remote end hung up unexpec

ahe — Wed, 06 May 2026 13:35:06 +0000

搜索各种办法无效，我的场景：

提交了一个48M大小的更改，无法push

使用
git config –global http.postBuffer 524288000

设置超时时间后再push，问题解决。

ESP32 4G拨号实战：ML307A和ML307R的PPP指令差异详解（附完整代码）

ahe — Thu, 26 Mar 2026 04:36:47 +0000

最近在做一个基于ESP32S3的户外数据采集项目，需要用到4G Cat.1模组进行网络通信。手头正好有移远通信的ML307A和ML307R两款模组，本以为都是同一系列，AT指令应该大同小异，结果在PPP拨号这个环节上却结结实实踩了个坑。ML307R用ATD*99#一切正常，换到ML307A上就死活连不上，串口只返回ERROR。折腾了大半天，翻遍了手册和论坛，才发现问题就出在那个看似不起眼的拨号指令上——ML307A需要显式指定PDP上下文ID。这个细微的差异，对于嵌入式物联网开发者来说，可能就是项目进度卡上一天的关键所在。

这篇文章，我就从一个实际开发者的角度，把这两款模组在ESP32S3上进行PPP拨号时的指令差异、背后的原理、完整的配置流程以及如何编写健壮的兼容性代码，给大家掰开揉碎了讲清楚。无论你是正在选型纠结用哪款模组，还是已经遇到了连接问题，希望这里的实战经验能帮你快速绕过这些“坑”。

1. 理解PPP拨号与AT指令基础
在深入ML307A和ML307R的差异之前，我们有必要先统一一下基础认知。PPP，即点对点协议，是物联网设备通过蜂窝模组接入互联网的经典方式。它本质上是在设备的MCU（如ESP32S3）和蜂窝模组之间建立一条透明的数据通道，模组负责无线通信，MCU则通过串口使用PPP协议栈来处理IP数据包。

整个过程始于一系列AT指令的交互。AT指令是调制解调器的“语言”，我们通过UART发送特定的文本命令来控制模组。一个典型的PPP连接建立流程，可以概括为以下几个核心阶段：

模组初始化与网络注册：确保模组上电、SIM卡就绪并成功注册到运营商网络。
PDP上下文定义：告诉模组使用哪个接入点名称（APN）来建立数据连接。你可以把它理解为给本次数据会话办理“入网手续”。
PDP上下文激活：正式向网络发起请求，分配IP地址等资源。
发起PPP拨号：启动模组内部的PPP协议栈，并将串口切换到PPP数据模式。
MCU侧PPP协议栈处理：ESP32S3上的LwIP PPP协议栈开始与模组协商，最终建立IP层连接。
注意：很多新手容易混淆“PDP上下文激活”和“PPP拨号”。前者是蜂窝网络层面的数据承载建立，后者是在这个承载之上建立点对点协议链路。两者必须按顺序成功完成。

对于ESP32开发者，乐鑫提供了esp-modem组件来简化这部分工作。它封装了AT指令交互和PPP协议栈的对接，但我们仍然需要准确配置底层的拨号指令，这正是本文要解决的核心问题。

2. ML307A与ML307R的拨号指令关键差异剖析
为什么ATD*99#在ML307R上好用，到了ML307A上就不行？这需要我们从模组的固件行为和协议规范层面来理解。

*99#是一个通用的蜂窝数据呼叫号码，用于请求建立PPP连接。而ATD是发起呼叫的指令。关键在于，在发起呼叫时，模组需要知道使用哪一个之前定义好的PDP上下文。PDP上下文可以有多个（ID通常为1-3），用于不同的网络连接（比如主用和备用APN）。

ML307R的处理方式更为“宽松”或“智能”。当你发送ATD*99#时，如果当前只有一个PDP上下文（通常是ID为1的上下文）被定义和激活，模组会默认使用它。这种设计简化了操作，对开发者友好。

ML307A则要求“显式指定”。它的固件在处理ATD*99#时，不会自动关联已激活的上下文，因此会因参数不全而失败。必须使用ATD*99***X#的格式，其中X就是你想要使用的PDP上下文ID（通常是1）。***作为分隔符，其后紧跟的数字明确告知模组：“请使用第X号PDP上下文发起本次PPP呼叫”。

这个差异看似微小，但影响巨大。我们可以通过一个简单的表格来对比两款模组在这个环节上的不同：

特性 ML307R ML307A 说明与影响
默认拨号指令 ATD*99# ATD*99***1# ML307A必须携带上下文ID参数。
固件行为自动关联首个激活的上下文。必须显式指定上下文ID。 ML307A的行为更严格遵循某些AT命令规范。
开发者适配简单，通用指令兼容性好。需特别注意指令格式，否则连接失败。在代码中需做模组类型判断或指令适配。
错误现象指令正确则返回CONNECT。使用ATD*99#会直接返回ERROR。这是最直接的排查线索。
提示：除了拨号指令，两款模组在绝大多数其他AT指令（如网络查询、信号强度获取、短信功能等）上都是兼容的。差异主要集中在这条特定的拨号命令上。

那么，ATD*99***1#中的“1”是否可以更改？当然可以，前提是你定义并激活了其他ID的PDP上下文。例如，如果你为备用APN定义了上下文ID=2，那么拨号时就可以使用ATD*99***2#。但在绝大多数单数据通道的应用中，我们只使用上下文1。

3. 完整的PPP连接配置流程与AT指令序列
理解了核心差异，我们来看一个完整的、可操作的配置流程。这里以ML307A为例，给出每一步的AT指令和预期响应。对于ML307R，你只需要修改最后一步的拨号指令即可。

3.1 硬件连接与基础检查
首先，确保你的ESP32S3与ML307模组正确连接。至少需要连接电源、地线、主串口（用于AT指令和PPP数据）的TX和RX。建议额外连接PWRKEY引脚以便软件控制开机。

上电后，先通过串口工具手动发送AT指令，确认通信正常，应返回OK。

# 基础AT指令测试
AT
# 预期响应: OK

接着，检查SIM卡状态和网络注册情况。

# 查询SIM卡是否就绪
AT+CPIN?
# 预期响应: +CPIN: READY

# 查询网络注册状态
AT+CREG?
# 预期响应: +CREG: 0,1 (其中第二个参数为1表示已注册到本地网)

bash
3.2 定义并激活PDP上下文
这是建立数据通道的基础。你需要将替换为你所使用的运营商APN，例如中国移动的cmnet。

# 1. 定义PDP上下文（上下文ID=1，协议为IP，APN为cmnet）
AT+CGDCONT=1,"IP","cmnet"
# 预期响应: OK

# 2. 激活上面定义的PDP上下文
AT+CGACT=1,1
# 预期响应: OK
# 第一个参数1表示“激活”，第二个参数1表示上下文ID

bash
执行AT+CGACT=1,1后，模组会向蜂窝网络发起数据承载请求。你可以通过AT+CGACT?来查询激活状态。

3.3 发起PPP拨号（关键步骤）
对于ML307A，使用显式指定上下文的指令：

ATD*99***1#
# 成功则返回: CONNECT
# 此后串口将进入PPP数据模式，不再响应AT指令。

bash
对于ML307R，使用通用指令：

ATD*99#
# 成功则返回: CONNECT

bash
一旦收到CONNECT，模组的串口就会切换模式。此时，ESP32S3端的PPP协议栈应该开始工作，与模组进行LCP、IPCP等协议协商，最终为你分配一个IP地址。

3.4 断开连接
当需要断开网络时，对于PPP连接，通常不是发送AT指令（因为串口已在数据模式），而是由MCU侧的PPP协议栈发起断开流程。协议断开后，模组会自动退出数据模式。你也可以通过给模组发送+++（需要在前后有至少1秒的静默时间）返回到命令模式，再发送ATH来挂断呼叫。

4. 在ESP32S3项目中实现兼容性代码
在实际项目中，我们不可能每次都在串口工具里手动输入指令。我们需要将上述流程固化为ESP32S3上的代码，并且要优雅地处理ML307A和ML307R的差异。

乐鑫的esp-modem组件是我们的好帮手。它提供了esp_modem_dce抽象层来处理与各种模组的通信。下面，我将展示如何配置和使用它，并实现拨号指令的兼容。

4.1 项目配置与组件引入
首先，在你的项目idf.py menuconfig中，需要配置PPP支持：

Component config -> LWIP -> Enable PPP networking (NEW)
Component config -> LWIP -> PPP support -> Enable PPPoS client support (NEW)
然后，在CMakeLists.txt中添加esp_modem组件依赖：

set(EXTRA_COMPONENT_DIRS $ENV{IDF_PATH}/components/esp_modem)
# 或者如果你将esp_modem作为组件放在项目内部
list(APPEND EXTRA_COMPONENT_DIRS ${CMAKE_CURRENT_SOURCE_DIR}/components)
cmake
4.2 定义模组配置与拨号指令适配
我们可以创建一个头文件，如modem_config.h，来定义不同模组的配置参数和拨号指令。

// modem_config.h
#pragma once

#include "esp_modem_config.h"

// 定义模组类型枚举
typedef enum {
MODEM_TYPE_ML307R,
MODEM_TYPE_ML307A
} modem_type_t;

// 根据模组类型获取拨号指令
static inline const char* get_ppp_dial_command(modem_type_t type) {
return (type == MODEM_TYPE_ML307A) ? "ATD*99***1#" : "ATD*99#";
}

// 通用的ML307系列配置（波特率、流控等）
#define ML307_COMMON_CONFIG() { \
.command_terminator = "\r", \
.pdp_context = { \
.apn = "cmnet", // 你的APN \
.user = "", \
.password = "", \
}, \
.timeout_ms = 10000, \
}

4.3 主程序中的初始化与拨号流程
在主程序源文件中，我们实现完整的逻辑。关键点在于：在调用esp_modem_dce_start_ppp()之前，如果我们检测到是ML307A，需要手动设置拨号指令。

// main.c
#include "esp_log.h"
#include "esp_modem.h"
#include "modem_config.h"

static const char *TAG = "PPP_EXAMPLE";

// 假设我们通过某种方式（如GPIO检测、配置菜单）确定了模组类型
modem_type_t current_modem_type = MODEM_TYPE_ML307A; // 或 MODEM_TYPE_ML307R

void app_main(void) {
esp_err_t err = ESP_OK;

// 1. 配置DCE（数据电路终端设备，即模组）
esp_modem_dce_config_t dce_config = ML307_COMMON_CONFIG();
esp_modem_dce_t *dce = NULL;

// 2. 创建DCE实例，假设使用UART1，引脚为GPIO4(TX)、GPIO5(RX)
err = esp_modem_dce_create(&dce_config, UART_NUM_1, 4, 5, &dce);
if (err != ESP_OK) {
ESP_LOGE(TAG, "Failed to create DCE! err=0x%x", err);
return;
}

// 3. 【关键步骤】针对ML307A，覆盖默认拨号指令
if (current_modem_type == MODEM_TYPE_ML307A) {
const char* dial_cmd = get_ppp_dial_command(current_modem_type);
ESP_LOGI(TAG, "Using modem-specific dial command: %s", dial_cmd);
// 通过generic command接口预置拨号指令
err = esp_modem_dte_generic_command(dce, dial_cmd, NULL, 0);
// 注意：这里只是设置指令，并非立即拨号。真正的拨号由start_ppp触发。
if (err != ESP_OK) {
ESP_LOGW(TAG, "Pre-set dial command may not be supported, PPP start will use default.");
}
}

// 4. 启动PPP会话
// esp_modem_dce_start_ppp()内部会处理PDP上下文定义、激活和拨号全过程。
// 对于ML307R，它使用默认的ATD*99#。
// 对于ML307A，如果我们上一步预置成功，它会使用我们设置的指令。
err = esp_modem_dce_start_ppp(dce);
if (err != ESP_OK) {
ESP_LOGE(TAG, "Failed to start PPP session! err=0x%x", err);
// 这里可以加入重试或错误处理逻辑
esp_modem_dce_delete(dce);
return;
}

ESP_LOGI(TAG, "PPP session started successfully!");

// 5. 此时，网络已连接。你可以使用socket API进行通信。
// ...

// 6. 应用运行... 当需要断开时：
// esp_modem_dce_stop_ppp(dce);
// esp_modem_dce_delete(dce);
}

4.4 更健壮的自动检测与适配方案
上面的代码假设我们已经知道模组类型。一个更完善的方案是在运行时自动检测。这可以通过发送AT指令查询模组型号来实现。

// 在初始化阶段添加模组类型检测函数
modem_type_t detect_modem_type(esp_modem_dce_t *dce) {
char resp[128] = {0};
esp_err_t err = esp_modem_dte_generic_command(dce, "ATI\r", resp, sizeof(resp)-1, pdMS_TO_TICKS(2000));
if (err == ESP_OK) {
ESP_LOGI(TAG, "Modem info: %s", resp);
// 解析响应，判断是ML307A还是ML307R
if (strstr(resp, "ML307A") != NULL) {
return MODEM_TYPE_ML307A;
} else if (strstr(resp, "ML307R") != NULL) {
return MODEM_TYPE_ML307R;
}
}
// 如果检测失败，可以返回一个默认类型，或根据其他特征判断
ESP_LOGW(TAG, "Modem detection failed, using default (ML307R).");
return MODEM_TYPE_ML307R; // 假设ML307R更常见
}

// 然后在app_main中调用
current_modem_type = detect_modem_type(dce);

通过这种设计，你的代码就能智能地适配不同型号的ML307模组，大大提高项目的可维护性和硬件的兼容性。在实际部署中，这种自动检测机制能避免因生产批次或物料替换带来的固件升级问题。
————————————————
版权声明：本文为CSDN博主「sony5」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/sony5/article/details/152875556

C 和 C++ 对 enum 处理的差异，以及强制转换在GCC/ARMCC 下的实际表现

ahe — Sat, 14 Mar 2026 08:35:23 +0000

1. C 里的 enum，本质上更像“带名字的整数常量集合”

在 C 语言里：

typedef enum

{

MODE_A = 0,

MODE_B = 1,

MODE_C = 2

} Mode;

这并不表示 Mode 类型的变量只能取 0/1/2。

它更准确的含义是：

定义了一个枚举类型 Mode
定义了几个命名常量 MODE_A/MODE_B/MODE_C
Mode 类型的对象通常仍然按整数方式存储和运算

所以：

Mode m = (Mode)123;

在 C 里通常是允许的，m 的值就是 123。

也就是说，C 的 enum 不是运行时受限集合。

2. C 里为什么容易出 bug

因为代码看起来像“只有几个合法状态”，但实际上变量能装更多值。

例如：

typedef enum
{
SYS_IDLE = 0,
SYS_RUN = 1,
SYS_ERR = 2
} SysState;

void process(SysState s)
{
switch (s)
{
case SYS_IDLE:
// …
break;
case SYS_RUN:
// …
break;
case SYS_ERR:
// …
break;
}
}

如果有人传入：

process((SysState)99);

那么：

不会报错
不会崩溃
switch 没有匹配项
函数可能什么都不做

这类 bug 在嵌入式里很常见，尤其是：

Flash 读配置
UART/CAN 收协议字段
EEPROM 恢复状态
上位机下发模式值

3. C 标准层面再严谨一点

C 标准并没有要求“枚举变量必须只能持有枚举器中列出的值”。

但是它会涉及一个更细的点：

枚举类型有一个底层整数表示范围

如果你强转进去的整数值 落在该枚举类型可表示范围内，通常就只是一个“未命名枚举值”。

如果 超出该实现能表示的范围，结果就可能变成实现定义，甚至不可靠。

不过在绝大多数 STM32 开发里：

enum 往往按 int 处理
0、1、2、99、255 这种小值一般都能存进去

所以日常看到的现象通常是：

“可以存，能比较，能打印，但逻辑上非法。”

4. C++ 里的普通 enum

C++ 里的传统 enum 和 C 很像：

enum Color
{
RED = 0,
GREEN = 1,
BLUE = 2
};

Color c = (Color)5;

这通常也能成立。

区别主要在于类型检查会稍微严格一些，但只要你显式强转，编译器一般还是接受。

所以 C++ 的传统 enum 也并不天然安全。

5. C++11 的 enum class 才更“强类型”

例如：

enum class Color : uint8_t

{

Red = 0,

Green = 1,

Blue = 2

};

它有几个特点：

不能隐式转成 int

Color c = Color::Red;

// int x = c; // 编译错误

int x = (int)c; // 需要显式转换

不会把枚举项污染外层命名空间

Color c = Color::Red;

而不是直接写 RED。

但注意

即使是 enum class，你仍然可以这样写：

Color c = (Color)5;

或者：

Color c = static_cast<Color>(5);

这仍然可能得到一个“不对应任何枚举项”的值。

所以：

enum class 改善的是类型安全和命名安全，不是自动帮你做合法性检查。

这一点非常重要。

6. C 和 C++ 的核心差异，最实用的理解

你可以这么记：

C 的 enum

更接近整数
类型约束弱
很容易出现“非法但可存”的值

C++ 的传统 enum

比 C 稍强一点
但本质仍然接近整数
强转后同样可能有非法值

C++ 的 enum class

强类型得多
不会乱隐式转换
但显式强转后仍可能得到非法枚举值

7. GCC / ARMClang / Keil 下的实际表现

在 STM32 常见环境里，通常会遇到这些编译器/前端：

GCC
ARMClang / armclang
Keil MDK（现在主要也是 ARMClang，老项目可能 ARMCC）
IAR

它们在大多数默认配置下，对 enum 的行为都很类似：

现象一：通常按 int 宽度处理

例如：

typedef enum

{

A = 0,

B = 1,

C = 2

} MyEnum;

很多情况下 sizeof(MyEnum) 会是 4。

但这不是永远绝对的，因为编译器可以选合适的整数类型。

现象二：强转非法值通常不会报错

MyEnum e = (MyEnum)100;

一般照样编译通过。

现象三：switch 优化可能埋坑

看这个例子：

int f(MyEnum e)

{

switch (e)

{

case A: return 1;

case B: return 2;

case C: return 3;

}

return 0;

}

如果传进来 100，大多数时候会返回 0。
但编译器在高优化下，可能基于一些假设做优化，尤其当代码写法让它认为“这个分支不可能出现”时，行为可能变得和你预期不同。

在 C 里这种问题通常不算特别夸张，但在 C++ 配合更激进优化时更值得警惕。

8. `-fshort-enums` 这类选项要特别小心

GCC 有个常见选项：

–fshort–enums

它会让编译器尽量用更小的整数类型存 enum。

例如原本是 4 字节，可能变成 1 字节。

这在嵌入式里可能是为了省 RAM/Flash，但会带来几个风险：

风险 1：结构体布局变化

typedef struct

{

uint8_t a;

MyEnum e;

uint8_t b;

} Data_t;

有无 -fshort-enums，sizeof(Data_t) 可能不同。

这会影响：

通信协议
Flash 存储结构
EEPROM 映射
与上位机二进制数据对接

风险 2：超范围值截断风险更大

如果 enum 被压成 uint8_t 或 int8_t 风格的底层存储，那你强转的超大值可能被截断。

例如：

MyEnum e = (MyEnum)300;

结果可能不再是你直觉里的 300。

风险 3：跨模块 ABI 不一致

一个模块开了 -fshort-enums，另一个没开，接口里又传 enum，可能出很隐蔽的问题。

所以嵌入式项目里，枚举如果用于对外接口、通信协议、存储格式，最好不要依赖其底层大小。

9. 在嵌入式里最危险的几个场景

场景 A：直接把协议字段强转成 enum

cmd.mode = (WorkMode)rxBuf[3];

如果协议异常、数据损坏、上位机发错值，后续状态机可能乱跑。

更稳妥：

uint8_t raw = rxBuf[3];

if (raw <= WORK_MODE_MAX)

{

cmd.mode = (WorkMode)raw;

}

else

{

cmd.mode = WORK_MODE_INVALID;

}

场景 B：把 Flash/EEPROM 的脏数据恢复成 enum

掉电后存储区可能不是你预期值。

cfg.mode = (WorkMode)flash_data.mode;

最好加校验。

场景 C：switch 没有 default

switch (state)

{

case S0: …

case S1: …

case S2: …

}

如果状态非法，什么都不做，很难查。

嵌入式里推荐：

switch (state)

{

case S0: …

break;

case S1: …

break;

case S2: …

break;

default:

// 错误处理、回退默认状态、计数告警

break;

}

10. 编译器告警能帮到什么程度

你可以打开一些告警：

GCC / Clang 常见有用项

-Wall
-Wextra
-Wswitch
-Wswitch-enum
-Wconversion

其中：

-Wswitch-enum 能提示 switch(enum) 是否漏掉某些枚举项
但它不能阻止非法整数强转成 enum

所以编译器只能帮一部分，值合法性还是得你自己查。

11. 最推荐的安全写法

方法一：定义 INVALID 项

这是嵌入式里最实用的。

typedef enum

{

MODE_IDLE = 0,

MODE_RUN = 1,

MODE_STOP = 2,

MODE_INVALID = 255

} Mode;

然后：

static inline Mode Mode_FromInt(int x)

{

switch (x)

{

case MODE_IDLE: return MODE_IDLE;

case MODE_RUN: return MODE_RUN;

case MODE_STOP: return MODE_STOP;

default: return MODE_INVALID;

}

}

方法二：配套 IsValid 函数

static inline int Mode_IsValid(int x)

{

return (x == MODE_IDLE) ||

(x == MODE_RUN) ||

(x == MODE_STOP);

}

使用时：

int raw = get_mode();

if (Mode_IsValid(raw))

{

mode = (Mode)raw;

}

else

{

// 错误处理

}

方法三：连续枚举可做范围判断

如果你的枚举是连续的：

typedef enum

{

MODE_IDLE = 0,

MODE_RUN,

MODE_STOP,

MODE_COUNT

} Mode;

那么可以：

if ((unsigned)raw < MODE_COUNT)

{

mode = (Mode)raw;

}

else

{

// invalid

}

这个写法很适合 STM32 项目。

但前提是：

枚举值必须连续
从 0 开始最好
中间不能插空洞值

12. 一个 STM32 项目里的实战建议

如果是状态机、工作模式、菜单页面这类枚举，我建议你这样设计：

typedef enum

{

PAGE_HOME = 0,

PAGE_MENU,

PAGE_SETTING,

PAGE_COUNT,

PAGE_INVALID = 0xFF

} Page_t;

然后统一入口转换：

static inline Page_t Page_Parse(uint8_t raw)

{

return (raw < PAGE_COUNT) ? (Page_t)raw : PAGE_INVALID;

}

这样后续代码几乎不会踩坑。

13. 总结成一句话

在 C 里

enum 不是“只能取这几个值”的严格集合，而更像“有名字的整数”。

在 C++ 里

enum class 更安全，但也只是防止乱隐式转换，不负责检查你强转进去的值是否合法。

在 GCC / ARMClang / Keil 嵌入式环境里

非法整数强转成枚举，通常不会立刻出错；真正的风险在于后续逻辑 silently 出问题。

14. 你可以直接记住这条工程规则

凡是从外部输入、存储恢复、通信报文、寄存器解析得到的整数，转 enum 前都先校验。

这是最稳的。

STM32+CubeMX 配置ADC配合DMA多通道多次采样并自动取平均

ahe — Sun, 01 Mar 2026 08:10:34 +0000

一、推荐参数

先用这一组，比较稳：

Oversampling Ratio = 8x
Right Bit Shift = 3

这等价于：

每个通道内部采 8 次
累加后右移 3 位（即除以 8）
输出结果仍保持接近 12 位量程

也就是说，你拿到的就是“8 次平均值”。STM32L4 的硬件过采样支持把输出当作 averaging function 来用。

如果你更想抑制噪声，可改成：

16x + Shift 4

但总转换时间会进一步增加。

二、CubeMX 配置

下面按 “软件触发一次，采完 6 个通道（每个都做过采样），DMA 搬 6 个值” 来配。

1）ADC1 基本参数

在 ADC1 > Parameter Settings 里：

Scan Conversion Mode：Enable
Nbr Of Conversion：6
把你的 6 个通道分别设成 Rank 1 ~ Rank 6
Resolution：12 bits
Data Alignment：Right
Continuous Conversion Mode：Disable
Discontinuous Conversion Mode：Disable
External Trigger Conversion Source：Software Start
DMA Continuous Requests：Disable
End Of Conversion Selection：End of Sequence

说明：

你要的是“触发一次，拿一组”，所以 Continuous 要关
DMA 用 Normal 模式，一次搬完 6 个结果就停
EOC 选 End of Sequence，这样一整组 6 通道完成后再作为一次完整结果处理，更省心。STM32L4 的 ADC 支持 single-shot 或 continuous 的单通道/扫描模式，规则组数据也可通过 DMA 获取。

2）每个通道的 Sampling Time

在 6 个通道各自的 Rank 设置里，给一个相对稳妥的采样时间：

若信号源阻抗不高：24.5 cycles 或 47.5 cycles
若是分压电阻较大 / 传感器阻抗高：建议 92.5 cycles 或更长

STM32L4 允许每个通道单独设置采样时间；高阻信号需要更长采样时间。

3）打开 Oversampling

在 ADC1 的参数页里，找到 Oversampling / Regular Oversampling（不同 CubeMX 版本位置略有不同），设置：

Oversampling Mode：Enable
Oversampling Ratio：8x
Right Bit Shift：3 bits
Triggered Oversampling Mode / Regular Oversampling Mode：
- 若有这个选项，建议先用 Continued mode（连续过采样）
- 也就是一次规则转换内，把 8 次子采样连续完成，再给出一个结果

说明：

L4 的硬件过采样支持 2/4/8/16/32/64/128/256 倍。
8x + shift 3 是最像“硬件平均 8 次”的配置。

4）DMA 配置

在 ADC1 > DMA Settings 添加一个 DMA 通道：

Direction：Peripheral to Memory
Mode：Normal
Peripheral Increment：Disable
Memory Increment：Enable
Peripheral Data Width：Half Word
Memory Data Width：Half Word
Priority：Low / Medium 都可以

因为 ADC 数据寄存器是 16 位，DMA 用 Half Word 最合适。STM32 的 ADC 结果寄存器是 16 位，数据可由 DMA 取走。

三、CubeMX 生成代码关键检查

不同 HAL 版本字段名略有差异，但核心会类似下面这样。

`MX_ADC1_Init()` 里关键部分（示例）

hadc1.Instance = ADC1;

hadc1.Init.ClockPrescaler = ADC_CLOCK_ASYNC_DIV2; // 或按你的需求

hadc1.Init.Resolution = ADC_RESOLUTION_12B;

hadc1.Init.DataAlign = ADC_DATAALIGN_RIGHT;

hadc1.Init.ScanConvMode = ADC_SCAN_ENABLE;

hadc1.Init.EOCSelection = ADC_EOC_SEQ_CONV;

hadc1.Init.LowPowerAutoWait = DISABLE;

hadc1.Init.ContinuousConvMode = DISABLE;

hadc1.Init.NbrOfConversion = 6;

hadc1.Init.DiscontinuousConvMode = DISABLE;

hadc1.Init.ExternalTrigConv = ADC_SOFTWARE_START;

hadc1.Init.ExternalTrigConvEdge = ADC_EXTERNALTRIGCONVEDGE_NONE;

hadc1.Init.DMAContinuousRequests = DISABLE;

hadc1.Init.Overrun = ADC_OVR_DATA_OVERWRITTEN;

hadc1.Init.OversamplingMode = ENABLE;

然后还有 Oversampling 结构体（字段名按你当前 HAL 为准）：

hadc1.Init.Oversampling.Ratio = ADC_OVERSAMPLING_RATIO_8;

hadc1.Init.Oversampling.RightBitShift = ADC_RIGHTBITSHIFT_3;

hadc1.Init.Oversampling.TriggeredMode = ADC_TRIGGEREDMODE_SINGLE_TRIGGER;

hadc1.Init.Oversampling.OversamplingStopReset = ADC_REGOVERSAMPLING_CONTINUED_MODE;

这里最后两个枚举名在不同 HAL 版本中可能略有差异；CubeMX 生成什么就以什么为准。
你只需要保证逻辑上是：一次启动后，每个规则转换会连续完成 8 次子采样并输出平均值。

四、6 通道配置示例（Rank 1~6）

这个你前面已经配好了，只确认保留：

ADC_ChannelConfTypeDef sConfig = {0};

sConfig.SamplingTime = ADC_SAMPLETIME_47CYCLES_5;
sConfig.SingleDiff = ADC_SINGLE_ENDED;
sConfig.OffsetNumber = ADC_OFFSET_NONE;
sConfig.Offset = 0;

/* Rank 1 */
sConfig.Channel = ADC_CHANNEL_1;
sConfig.Rank = ADC_REGULAR_RANK_1;
HAL_ADC_ConfigChannel(&hadc1, &sConfig);

/* Rank 2 */
sConfig.Channel = ADC_CHANNEL_2;
sConfig.Rank = ADC_REGULAR_RANK_2;
HAL_ADC_ConfigChannel(&hadc1, &sConfig);

/* … 一直到 Rank 6 */

STM32L4 的 sequencer 可按任意顺序转换多达 16 个通道；你这里只用 6 个没问题。

五、应用代码模板（一次触发，DMA 收 6 个“已平均值”）

1）全局变量

#include “main.h”

extern ADC_HandleTypeDef hadc1;

#define ADC_CH_NUM 6

uint16_t adc_avg_buf[ADC_CH_NUM];
volatile uint8_t adc_done = 0;

2）初始化时先做一次校准

STM32L4 官方建议在应用中做 ADC 校准；当参考电压变化超过 10%（如复位、某些低功耗恢复）时建议重新校准。

void ADC1_AppInit(void)

{

HAL_ADCEx_Calibration_Start(&hadc1, ADC_SINGLE_ENDED);

}

3）启动一次采样

HAL_StatusTypeDef ADC1_ScanOnce_Oversampled_Start(void)

{

adc_done = 0;

return HAL_ADC_Start_DMA(&hadc1, (uint32_t *)adc_avg_buf, ADC_CH_NUM);

}

这里的 adc_avg_buf[0..5] 不是“原始单次值”，而是：

Rank1 通道：内部 8 次平均后的值
Rank2 通道：内部 8 次平均后的值
…
Rank6 通道：内部 8 次平均后的值

4）DMA 完成回调

void HAL_ADC_ConvCpltCallback(ADC_HandleTypeDef *hadc)

{

if (hadc->Instance == ADC1)

{

adc_done = 1;

HAL_ADC_Stop_DMA(&hadc1);

}

}

5）使用方法

if (ADC1_ScanOnce_Oversampled_Start() == HAL_OK)

{

// 等待 adc_done 或在主循环里异步判断

}

主循环里：

if (adc_done)
{
adc_done = 0;

// adc_avg_buf[0] -> Rank1 通道的平均值
// adc_avg_buf[1] -> Rank2
// …
// adc_avg_buf[5] -> Rank6
}

六、这时“单次采样时间”会怎么变

这是你最容易忽略的点。

如果你原来单通道一次转换耗时近似是：

$T_{one} = T_{sample} + T_{convert}$

那打开 8x oversampling 后，每个通道大致会变成：

$Tone_os≈8×(Tsample+Tconvert)T_{one\_os} \approx 8 \times (T_{sample} + T_{convert})$

所以 整组 6 通道 的总时间也大约乘以 8。STM32L4 的硬件过采样就是先做多次采样并累加，再输出给 DMA。

举例（粗略）：

若原来 6 通道一轮约 20µs
开 8x 后，可能接近 160µs

所以如果你有“50µs 内完成”的硬限制，8x 可能就太慢了；那就改成：

2x + shift1
或 4x + shift2

七、最常见的坑

1）开了 Oversampling，却还按“原采样速度”估算

这是最常见误判。过采样会显著拉长转换时间。

2）DMA 长度还写成 `6*N`

模板 B 下，DMA 长度就是 6，不是 6×8。
因为多次采样在 ADC 内部已经处理完了。

3）采样时间太短

如果前端源阻抗偏大（比如几十 kΩ 分压），哪怕开了过采样，采样电容本身还没充稳，结果照样漂。
这时应优先增加 Sampling Time，而不是盲目加大 Oversampling Ratio。

4）误以为分辨率一定“真实提高”

过采样确实能改善随机噪声、实现平均/基本滤波，L4 在一定条件下可把 12 位输出扩展到 16 位表现；但这依赖噪声特性和输入信号条件，不是“无条件白捡 4 位有效精度”。

电容NP0、C0G、X7R、X5R、Y5V、Z5U的区别

ahe — Sat, 28 Feb 2026 04:56:18 +0000

主要是介质材料不同。不同介质种类由于它的主要极化类型不一样，其对电场变化的响应速度和极化率亦不一样。在相同的体积下的容量就不同，随之带来的电容器的介质损耗、容量稳定性等也就不同。介质材料划按容量的温度稳定性可以分为两类，即Ⅰ类陶瓷电容器和Ⅱ类陶瓷电容器， NPO属于Ⅰ类陶瓷，而其他的X7R、X5R、Y5V、Z5U等都属于Ⅱ类陶瓷。

什么是Ⅰ类陶瓷，有什么特点？

Ⅰ类陶瓷电容器（ClassⅠceramic capacitor），过去称高频陶瓷电容器（High-frequency ceramic capacitor），介质采用非铁电（顺电）配方，以TiO2为主要成分（介电常数小于150），因此具有最稳定的性能；或者通过添加少量其他（铁电体）氧化物，如CaTiO3 或SrTiO3，构成“扩展型”温度补偿陶瓷，则可表现出近似线性的温度系数，介电常数增加至500。这两种介质损耗小、绝缘电阻高、温度特性好。特别适用于振荡器、谐振回路、高频电路中的耦合电容，以及其他要求损耗小和电容量稳定的电路，或用于温度补偿。

Ⅰ类陶瓷的温度特性怎么表示

Ⅰ类陶瓷的温度容量特性（TCC）非常小，单位往往在ppm/℃，容量较基准值的变化往往远小于1皮法。美国电子工业协会（EIA）标准采用“字母+数字+字母” 这种代码形式来表示Ⅰ类陶瓷温度系数。比如常见的C0G。

C0G代表的温度系数究竟是多少？

C 表示电容温度系数的有效数字为 0 ppm/℃

0 表示有效数字的倍乘因数为 -1（即10的0次方）

G 表示随温度变化的容差为 ±30ppm

计算下来，C0G电容最终的TCC为：0×（-1）ppm/℃±30ppm/℃。而相应的其他Ⅰ类陶瓷的温度系数，例如U2J电容，计算下来则为：-750 ppm/℃±120 ppm/℃。

NPO和C0G是同一种电容吗？

NPO是美国军用标准（MIL）中的说法，其实应该是NP0（零），但一般大家习惯写成NPO（欧）。这是Negative-Positive-Zero的简写，用来表示的温度特性。说明NPO的电容温度特性很好，不随正负温度变化而出现容值漂移。

从前面我们已经知道，C0G是I类陶瓷中温度稳定性最好的一种，温度特性近似为0，满足“负-正-零”的含义。所以C0G其实和NPO是一样的，只不过是两个标准的两种表示方法（当然，容值更小、精度略差一点的C0K、C0J等也是NPO电容）。类似的，U2J对应于MIL标准中的组别代码为N750。

NPO 电容器随封装形式不同其电容量和介质损耗随频率变化的特性也不同，大封装尺寸的要比小封装尺寸的频率特性好。

什么是Ⅱ类陶瓷，有什么特点？

Ⅱ类陶瓷电容器（Class Ⅱ ceramic capacitor）过去称为为低频陶瓷电容器（Low frequency ceramic capacitor），指用铁电陶瓷作介质的电容器，因此也称铁电陶瓷电容器。这类电容器的比电容大，电容量随温度呈非线性变化，损耗较大，常在电子设备中用于旁路、耦合或用于其它对损耗和电容量稳定性要求不高的电路中。其中Ⅱ类陶瓷电容器又分为稳定级和可用级。X5R、X7R属于Ⅱ类陶瓷的稳定级，而Y5V和Z5U属于可用级。

X5R、X7R、Y5V、Z5U之间的区别是什么？

区别主要还在于温度范围和容值随温度的变化特性上。下表提示了这些代号的含义。

以X7R为例。

X 代表电容最低可工作在 -55℃

7 代表电容最高可工作在 +125℃

R 代表容值随温度的变化为 ±15%

同样的，Y5V正常工作温度范围在-30℃～+85℃, 对应的电容容量变化为+22～82%；而Z5U 正常工作温度范围在+10℃～+85℃，对应的电容容量变化为+22～-56%。

取消新款MacBook的掀盖自动启动功能以及恢复开机音效

ahe — Wed, 25 Feb 2026 12:22:59 +0000

去年 2016 新款 MacBook Pro 起，預設打開筆電上蓋或連接電源供應器時，電腦就會自動開機而且開機時沒有啟動聲，本文教你如何將這些東西調整回原本的樣子。

以下指令都是透過「工具程式」→「終端機」來達成。

取消自動開機：

sudo nvram AutoBoot=%00

重新啟用自動開機：

sudo nvram AutoBoot=%03

開啟開機音效：

sudo nvram BootAudio=%01

取消開機音效：

sudo nvram BootAudio=%00

輸入指令後若提示你輸入密碼，就打吧！

以上，提供大家參考。

龙芯架构软件体系中的旧世界与新世界

ahe — Fri, 19 Dec 2025 05:57:44 +0000

我需要关心这问题吗？

简单来讲，如果您不自行编译安装软件，或许就不必关心。当然，随意浏览下这篇文章，以后见到这俩说法不至于一头雾水，或者其他同学遇到问题您可以给 tā 们指路，也是不错的。

如果您目前在龙架构电脑上使用 Loongnix、麒麟或者 UOS 这些系统，几个月或一两年之后，一定会有一次全系统升级。
- 如果您不升级，那么本身外界如何变化也与您无关。
- 如果您升级，那么升级之后您应该也感受不到使用上的差别，这其实就是「移民新世界」了。
如果您目前在龙架构电脑上使用 Arch、Gentoo 等等这些系统，那么您已经是新世界住民了，这一切也与您无关。

会被坑到的情况目前来看只有：

您使用 Loongnix、麒麟或者 UOS 这些系统，但自行编译了一些要用的软件。在未来那次全系统升级之后，您自行编译的软件应该不再能工作，需要重新编译或从系统包管理器安装。
您是为龙架构适配或开发软件的开发者用户。会来到这个页面，基本是已经被坑到了，那就往下读吧！

截至目前（2024 年初），LoongArch 有两套不兼容的软件体系，习惯上大家把它们叫作「旧世界」和「新世界」。龙芯中科的材料中也有「ABI1.0」、「ABI2.0」的提法（目前所见的表述均未在 ABI 与数字之间加空格）。

旧世界是指最早在龙芯中科内部适配的、随着 LoongArch 公开一并发布的那个 LoongArch 软件生态。 新世界是指龙芯中科与社区同仁一道，以典型开源社区协作模式打造的，完全开源的 LoongArch 软件生态。

两个世界的产生是龙芯中科对 LoongArch 采取了秘密开发、突然全盘推出的商业策略，由于未能预见到这一版工作有些地方不得不做不兼容修改，而使客户和自身不得不面对的无奈后果。按照目前的趋势和一些公开消息，未来旧世界将逐渐消亡。从龙芯 3A6000 一代产品起，相关产品的出厂配套固件都已达到兼容新、旧世界的状态，但就 2024 年 2 月初的现状而言，可能发行版方面（Loongnix 及其他商业发行版）仍需更长时间才能完成迁移，因此未能赶上 3A6000 的正式发布。

在讨论龙芯话题时，新旧世界的说法仅仅被用来区分两个不兼容的 LoongArch 生态。 MIPS 型号的龙芯既不是新世界也不是旧世界。一般只会说「MIPS 时代的龙芯」（the MIPS-era Loongson）怎么怎么样。

「旧世界」、「新世界」的名词形式英译即为「the old world」、「the new world」。作形容词时一般以连字符连接前后部分即「old-world」、「new-world」。如果在一段话中频繁使用，有时也会用「OW」、「NW」的缩写形式。

我在哪个世界？

如果符合以下任一条件，你就在用旧世界：

系统是麒麟、Loongnix、UOS 其中之一
内核版本以 4.19 开头
有 WPS 用但没有安装过 libLoL 等旧世界兼容方案

如果一条都没中，你就在用新世界。

这个判断方法是基于 2024 年 2 月的已知信息设计的。后续如果没及时更新，可能会不准。

手头这软件是哪个世界的？

可以使用 file 工具方便地检查一个二进制程序属于哪个世界。假设你想检查 someprogram 这个文件，就执行 file someprogram，如果输出的行含有这些字样：

interpreter /lib64/ld.so.1, for GNU/Linux 4.15.0

就表明这是一个旧世界程序。

相应地，如果输出的行含有这些字样：

interpreter /lib64/ld-linux-loongarch-lp64d.so.1, for GNU/Linux 5.19.0

就表明这是一个新世界程序。

以上的判断都适用于系统 libc 为 glibc 且动态链接的程序。如果程序是静态链接的，便没有 interpreter 信息；如果程序是 Go 语言的或者使用了 musl 作为 C 库，那么文件里就没有对应到 for GNU/Linux 这部分信息的标记。这种时候试着运行一下就可以了，「异世界」的程序几乎没有可能正常启动。

当然，如果你得到的输出类似下边几行之一：

someprogram: Python script, Unicode text, UTF-8 text executable
someprogram: Bourne-Again shell script, ASCII text executable, with escape sequences

这种情况代表你检查的程序是个脚本。一般脚本语言的程序都无所谓新旧世界的，但它仍然有可能依赖一些二进制组件才能正常工作：因此最靠谱的方法还是试着跑一下！

为啥叫「新旧世界」？

在汉语圈其他领域已有「新旧世界」的说法了，例如「旧/新世界猴」、「旧/新世界葡萄酒」：这里的「世界」其实就是「大陆」。 LoongArch 的新世界也比旧世界出现得晚，并且也存在做事方式上的不兼容，相互之间也有一定的沟通交流，因此这样的类比在一定程度上还比较贴切。

在技术领域，「新旧世界」的说法也有先例。怀旧计算（retro-computing）群体对 Macintosh 电脑的不同型号就使用 Old World、New World 来区分。他们的「旧世界」是指系统硬件包含一块 ROM 芯片，其中搭载了 Macintosh Toolbox 这个老固件。「新世界」硬件则没有这块芯片。使用 Old/New World ROM 的 Macintosh 型号就被叫作 Old/New World Macs。

另一方面，使用 Linux 源码发行版如 Gentoo 的用户群体，口语上也有「重做世界」（rebuild world）之类的表达。此处的「世界」是系统上所有包的统称，这层意义上 world 的含义类似 userland：统称在用户态运行的所有程序。对 Gentoo 用户而言，还恰好表示 @world 集合。而 LoongArch 的新旧世界区分，很大程度上正是由于内核态提供的系统调用界面有细微差别，导致了用户态的程序相互间不兼容。

俩世界区别在哪？

源码开放程度不一样。新世界都是开源代码，而旧世界的部分底层代码由于知识产权等原因始终没有开放，尽管其中也有一部分后来放出了。比方说旧世界的 binutils、gcc 在最初发布之后过了几个月有了完整源码，Linux 源码直到 2023 年才有，但 GSGPU 的 shader 编译器源码就始终没有。放出的源码基本也比较少有完整的 Git 提交历史，因此不便基于它二次修改或者将其移植到上游新版本。

可用的发行版不一样。由于外界拿不到旧世界的完整源码，旧世界发行版只有几个商业公司能做。社区制作的发行版都属于新世界。

目前已知的旧世界发行版（移植）有：（按英文名字母顺序排序）

麒麟 (Kylin)
Loongnix
UOS

目前已知的新世界发行版（移植）有：（按英文名字母顺序排序）

注意

有些新世界发行版是由龙芯员工制作，因此相比其他纯社区工作，可能会额外集成一些：

尚未正式合入上游的代码（如内核的二进制翻译支持）
授权不清晰的内容（如 LATX 没有许可协议，默认为所有权利保留，无法被龙芯中科以外的主体集成、分发等）
尚未开源的内容（如 libffi、LibreOffice、Chromium 等软件，在 CLFS、Loong Arch Linux 很早就有包了，比相应的开源补丁最早一版还早。它们的移植都更晚甚至仍未完全进入上游。最极端的例子是 2021 年初 LoongArch 工具链、内核源码、QEMU 移植都还没开源，硬件也很难买到，CLFS 就已经出来了。）

不过随着时间推移，更多内容会进入上游或变成熟，这种情况以后也会越来越少直至消失。

软件版本不一样。旧世界的基础组件版本主要跟随当初移植时基于的 Debian 或 RHEL 大版本。因为商业公司不一定有优先级（或者能力）去关心跟进新版本的事情，所以旧世界的基础组件版本几乎不会有大的更新。视具体用户场景和开发、部署习惯而定，有时候这是个好事，有时候很糟心。

以下是一些常见软件、开发工具在两个世界的版本对比：

软件	旧世界版本	新世界版本
Linux	4.19	≥ 5.19，常见 ≥ 6.1
binutils	2.31	≥ 2.38，常见 ≥ 2.40
gcc	8.3	≥ 12.1，常见 ≥ 13.1
glibc	2.28	≥ 2.36
LLVM	8	≥ 16
Node.js	14.16.1	≥ 18
Go	1.15、1.18、1.19	≥ 1.19
Rust	1.41、1.58	≥ 1.71

怎么兼容两个世界？

鉴于新旧世界的差异可谓不大不小，想要实现完美的兼容性十分困难：一个方案无法同时具备以下的全部优势，而必须作出取舍。

所需磁盘空间尽可能少，
性能开销尽可能低，
对宿主系统的侵入式修改尽可能少，
（尤指极端场景下）尽量保证正确性：不使原世界本应成功的操作在兼容下失败，也不使原世界本应失败的操作在兼容下成功。

目前，源自 AOSC 社区的 libLoL 是完成度最高的解决方案，已为许多新世界发行版所集成。龙芯方面也表态过会开发兼容方案，但截至 2024 年 1 月，未有任何此方面的公开消息。

常见的坑

执行一个程序，报「没有那个文件或目录」，咋回事？

如果您执行一个程序却被告知这个程序不存在，类似这样：

$ ./foo
zsh: no such file or directory: ./foo

$ ./foo
zsh: 没有那个文件或目录: ./foo

如果这个文件确实存在，那么大概率是您在尝试执行异世界的程序。不存在的文件并非程序本身，而是所谓「ELF 解释器」，即上文教你判断一个程序是新世界还是旧世界那里提到的 ELF interpreter。请换对应您系统的程序版本，或要求软件提供者增加适配。

我给龙架构交叉编译的 Go 程序，运行报段错误，咋回事？

可能是由于未使用正确的 Go 工具链，导致不经意间构建了与您预期 ABI 相异的二进制。

为旧世界发行版构建，必须搭配使用龙芯提供的 Go 工具链与 goproxy 源（所谓「龙芯源」；见下）。
为新世界发行版构建，必须搭配使用上游版本的 Go 工具链，不可使用「龙芯源」。

具体而言，Go 程序在异世界运行时，初始化过程中必须的一次 rt_sigprocmask 系统调用会由于它使用的 NSIG 常量定义与当前运行内核不同而失败，此时 Go 会故意访问一个非法地址直接崩溃：此时从程序视角看，必然成功的系统调用居然失败，这说明内核服务已经不再可靠，继续下去没有意义。

龙芯提供了很多镜像源（「龙芯源」），我能用吗？

龙芯确实提供了很多「龙芯源」。旧世界开发者必须使用（系统可能已默认加载了相应的配置修改），新世界开发者不可使用。

出于 SEO 以及行侠仗义（天下开发者是一家）的精神，此处破例提供相应的旧世界文档。

种类	典型地址	备注
Go	`http://goproxy.loongnix.cn:3000`	文档
PyPI	`https://pypi.loongnix.cn/loongson/pypi`	文档
npm	`https://registry.loongnix.cn:4873`	文档
NuGet	`https://nuget.loongnix.cn`	文档
Rust (crates.io)	`https://crates.loongnix.cn`	文档
Harbor (容器镜像)	`https://cr.loongnix.cn`	文档

由于旧世界 ABI、API 并未上游，也不会被上游，那些需要关心系统底层 ABI、API 细节的包，其正式版本——也就是从上游或常规镜像站下到的版本——在旧世界不可能正常工作：要么没适配过龙架构，要么适配的是新世界。因此为了方便为旧世界适配软件，龙芯搭建了这些源：那些会受影响的包和相应版本，在这些源里被针对旧世界改过了。

这就是为何新世界开发者不可贪图方便使用它们：从这些软件源中下载的有些包，对新世界而言反而是坏的，更何况完整性校验不会通过——龙芯提供魔改代码的行为与「中间人攻击」没有外观上的差别。换个角度看，这也是旧世界开发者必须开启它们，并且关闭相应的完整性校验的原因。

Nuget 生成本地包源v3 feed的自动批处理脚本

ahe — Fri, 05 Dec 2025 00:29:44 +0000

@echo off
setlocal enabledelayedexpansion

:: ========================================
:: 配置区 —— 请按需修改
:: ========================================
set RAW_ROOT=F:\third_ext\NAPS2
set LOCAL_FEED=F:\third_ext\LocalFeed
set NUGET_EXE=F:\Tools\nuget.exe
:: ========================================


echo.
echo ======= 自动 NuGet Feed 更新（安全版） =======
echo RAW_ROOT = %RAW_ROOT%
echo LOCAL_FEED = %LOCAL_FEED%
echo NUGET_EXE = %NUGET_EXE%
echo ================================================
echo.

:: ===== 检查路径是否存在 =====
if not exist "%RAW_ROOT%" (
echo [错误] RAW_ROOT 路径不存在：
echo %RAW_ROOT%
pause
exit /b 1
)

if not exist "%NUGET_EXE%" (
echo [错误] 未找到 nuget.exe：
echo %NUGET_EXE%
pause
exit /b 1
)

:: ===== 创建本地 Feed 目录 =====
if not exist "%LOCAL_FEED%" (
echo [Info] LOCAL_FEED 不存在，正在创建...
mkdir "%LOCAL_FEED%"
)

:: ===== 初始化 feed =====
if not exist "%LOCAL_FEED%\index.json" (
echo [Info] 正在初始化 NuGet V3 feed...
"%NUGET_EXE%" init "%RAW_ROOT%" "%LOCAL_FEED%"
echo 初始化完成！
)

echo.
echo [Info] 开始扫描子目录...
echo.

:: ===== 递归扫描所有 .nupkg（必须加引号） =====
for /R "%RAW_ROOT%" %%f in (*.nupkg) do (
echo [Add] %%f

:: 强制使用引号，避免路径非法
"%NUGET_EXE%" add "%%f" -Source "%LOCAL_FEED%"
echo.
)

echo ================================================
echo 所有包已成功导入！
echo 本地源： "%LOCAL_FEED%"
echo ================================================
echo.

pause
exit /b 0

.Net Core web项目“检测到URL存在 http host 头攻击漏洞”的修复及验证

ahe — Wed, 26 Nov 2025 00:34:02 +0000

基于.Net 6.0的SSO认证小应用，交付后进行web安全扫描，提示“检测到URL存在 http host 头攻击漏洞”，验证过程：

Chrome浏览器安装ModHeader插件，启用插件后，在ModHeader中添加Host abcdexxx.com，此时刷新目标网址，如果能正常显示或试图跳转至abcdexxx.com ，则证明漏洞存在。修复后应提示400 host invalid，无法正常访问。

ModHeader插件下载modheader_idgpnmonknjnojddfkpgkljpfnnfcklj

以下是修复过程：

Host Header Attack 是什么？

攻击者通过伪造 Host: 请求头，使应用产生错误行为，例如：

伪造生成带恶意域名的回调 URL
绕过某些基于 Host 判断的逻辑
触发开放重定向等漏洞

IIS 默认不会严格验证 Host，所以 ASP.NET Core 应用必须自己限制可信 Host。

ASP.NET Core 官方推荐做法：使用 Host Filtering Middleware

ASP.NET Core 自带 Microsoft.AspNetCore.HostFiltering 中间件，可以 限制允许访问的 Host 列表。

1）在 appsettings.json 添加允许的 Host

必须列出所有可能访问的 Host
例如：

不带 www
带 www
内网 IP（如有需要）
HTTPS 端口如使用 5001 这种自定义端口要标明：yourdomain.com:5001

2）在 Program.cs / Startup.cs 启用 Host Filtering

.NET 6+（Program.cs）

若使用 Startup.cs

中间件会做什么？

当请求头中 Host: 不在 AllowedHosts 内：

ASP.NET Core 返回 400 Bad Request
阻止进一步处理请求
→ 有效修补 Host Header Attack

IIS 额外加固（可选）

1）限制操作系统级别的 Host 绑定（强烈推荐）

在 IIS 网站绑定中：

只填写正确的 Host Name（如 www.yourdomain.com）
不要使用 *:* 或空的 Host

例如：

Type	Host Name	Port
https	www.yourdomain.com	443
https	yourdomain.com	443

这样 IIS 只接受你允许的 Host。

额外防护：阻止 X-Forwarded-Host 注入（若使用反向代理）

如果你在前面使用 Nginx / Apache / Load Balancer
请开启 Host Forwarding Strict 模式：

完整修补步骤总结

在麒麟KylinOS、统信UOS等Linux系统安装.Net SDK

ahe — Tue, 25 Nov 2025 12:32:22 +0000

本文演示如何使用安装脚本或通过提取二进制文件，在 Linux 上安装 .NET SDK 或 .NET 运行时。有关支持内置包管理器的发行版列表，请参阅在 Linux 上安装 .NET。

如果要开发 .NET 应用，请安装 SDK（包括运行时）。或者，如果只需运行应用程序，请安装运行时。如果要安装该运行时，建议安装 ASP.NET Core 运行时，因为它同时包括 .NET 和 ASP.NET Core 运行时。

使用 dotnet --list-sdks 和 dotnet --list-runtimes 命令查看安装的版本。有关详细信息，请参阅如何检查是否已安装 .NET。

.NET 版本

有两种类型的受支持版本：长期支持（LTS）和标准期限支持（STS）。所有版本的质量都是一样的。唯一的区别是支持的时间长短。 LTS 版本获得三年的免费支持和修补程序。 STS 版本可以获得两年的免费支持和修补程序。有关详细信息，请参阅 .NET 支持策略。

下表列出了每个版本的 .NET（和 .NET Core）的支持状态：

受支持	支持不足
10 （LTS）	7
9 （STS）	6
8 （LTS）	5
	3.1
	3.0
	2.2
	2.1
	2.0
	1.1
	1.0

依赖项

安装 .NET 时，可能不会安装某些特定的依赖项，特别是在手动安装时。以下列表详细介绍了Microsoft支持的 Linux 分发版，并具有可能需要安装的依赖项。更多信息，请查看发行版页面：

有关依赖项的一般信息，请参阅独立式 Linux 应用。

RPM 依赖项

如果以前未列出分发版且基于 RPM，则可能需要以下依赖项：

glibc
libgcc
CA证书
openssl-libs
libstdc++
libicu
tzdata
krb5-libs

DEB 依赖项

如果以前未列出分发版且基于 debian，则可能需要以下依赖项：

libc6
libgcc1
libgssapi-krb5-2
libicu70
libssl3
libstdc++6
zlib1g

脚本安装

dotnet-install 脚本用于 SDK 和运行时的自动化和非管理员安装。可通过 https://dot.net/v1/dotnet-install.sh 下载脚本。如果以这种方式安装 .NET，必须安装 Linux 发行版所需的依赖项。使用在 Linux 上安装 .NET一文中的链接获得特定 Linux 分发版。

重要

需要 Bash 才能运行该脚本。

可通过 wget 下载脚本：

Bash

wget https://dot.net/v1/dotnet-install.sh -O dotnet-install.sh

或者，使用 curl：

Bash

curl -L https://dot.net/v1/dotnet-install.sh -o dotnet-install.sh

运行此脚本之前，请确保授予此脚本作为可执行文件运行的权限：

Bash

chmod +x ./dotnet-install.sh

该脚本默认安装最新的长期支持（LTS） SDK 版本，即 .NET 10。若要安装最新版本（可能不是 (LTS) 版本），请使用 --version latest 参数。

Bash

./dotnet-install.sh --version latest

若要安装 .NET 运行时而非 SDK，请使用 --runtime 参数。

Bash

./dotnet-install.sh --version latest --runtime aspnetcore

可以通过 --channel 参数更改特定主要版本来指示特定版本。以下命令安装 .NET 9.0 SDK。

Bash

./dotnet-install.sh --channel 9.0

有关详细信息，请参阅 dotnet-install 脚本参考。

若要在命令行上启用 .NET，请参阅设置系统范围的环境变量。

若要了解如何使用 .NET CLI，请参阅 .NET CLI 概述。

手动安装

除了使用包管理器，还可以下载并手动安装 SDK 和运行时。手动安装通常作为持续集成测试的一部分执行，或在不支持的 Linux 发行版上执行。对于开发人员或用户，使用包管理器会更好。

从以下站点之一下载 SDK 或运行时的二进制版本。 .NET SDK 包括相应的运行时：

提取已下载的文件并使用 export 命令将 DOTNET_ROOT 设置为提取文件夹的位置，然后确保 .NET 位于 PATH 中。导出 DOTNET_ROOT 会使 .NET CLI 命令在终端中可用。有关 .NET 环境变量的详细信息，请参阅 .NET SDK 和 CLI 环境变量。

可以将不同版本的 .NET 提取到同一文件夹，这些版本并存。

示例

以下命令使用 Bash 将环境变量 DOTNET_ROOT 设置为当前工作目录，后跟 .dotnet。如果该目录不存在，则会创建它。 DOTNET_FILE 环境变量是要安装的 .NET 二进制版本的文件名。此文件会提取到 DOTNET_ROOT 目录中。 DOTNET_ROOT 目录及其 tools 子目录都添加到 PATH 环境变量中。

重要

如果运行这些命令，请记住将 DOTNET_FILE 值更改为下载的 .NET 二进制文件的名称。

Bash

DOTNET_FILE=dotnet-sdk-9.0.306-linux-x64.tar.gz
export DOTNET_ROOT=$(pwd)/.dotnet

mkdir -p "$DOTNET_ROOT" && tar zxf "$DOTNET_FILE" -C "$DOTNET_ROOT"

export PATH=$PATH:$DOTNET_ROOT:$DOTNET_ROOT/tools

可以在同一文件夹中安装多个版本的 .NET。

还可以将 .NET 安装到由 HOME 变量或 ~ 路径标识的主目录：

Bash

export DOTNET_ROOT=$HOME/.dotnet

若要了解如何使用 .NET CLI，请参阅 .NET CLI 概述。

验证下载的二进制文件

下载安装程序或二进制版本后，请对其进行验证，以确保文件未被更改或损坏。可以验证计算机上的校验和，然后将其与下载网站上报告的内容进行比较。

从官方下载页下载文件时，文件的校验和会显示在文本框中。选择“复制”按钮将校验和值复制到剪贴板。

使用 sha512sum 命令打印已下载的文件的校验和。例如，以下命令显示 dotnet-sdk-9.0.306-linux-x64.tar.gz 文件的校验和：

Bash

$ sha512sum dotnet-sdk-9.0.306-linux-x64.tar.gz
bbb6bdc3c8048e7cc189759b406257839e7d4bd6b8b1ba4bcdaeea8f92340e6855231043dd73f902130ca5357af72b810bb51a4da4d1315a2927ff85f831f1d5  dotnet-sdk-9.0.306-linux-x64.tar.gz

将校验和与下载站点提供的值进行比较。

使用校验和文件进行验证

.NET 发行说明包含校验和文件的链接，可用于验证下载的文件。以下步骤介绍了如何下载校验和文件并验证 .NET 安装二进制文件：

GitHub https://github.com/dotnet/core/tree/main/release-notes/9.0#releases 上 .NET 9 的发行说明页包含名为 Releases 的部分。该部分的表格链接到每个 .NET 9 版本的下载和校验和文件。下图显示了 .NET 8 发布表作为参考：
选择下载的 .NET 版本的链接。
上一部分使用了 .NET SDK 9.0.306，该版本位于 .NET 9.0.10 版本中。
在发布页面中，可以看到 .NET 运行时和 .NET SDK 版本，以及校验和文件的链接。下图显示了 .NET 8 发布表作为参考：
右键单击 校验和 链接并将其复制到剪贴板。
打开终端。
使用 curl -O {link} 下载校验和文件。
用复制的链接替换以下命令中的链接。

Bash
```
curl -O https://builds.dotnet.microsoft.com/dotnet/checksums/9.0.10-sha.txt
```
将校验和文件和 .NET 版本文件下载到同一目录后，请使用 sha512sum -c {file} --ignore-missing 命令来验证下载的文件。
如果验证通过，会看到打印了 OK 状态的文件：

Bash
```
$ sha512sum -c 9.0.10-sha.txt --ignore-missing
dotnet-sdk-9.0.306-linux-x64.tar.gz: OK
```
如果看到文件标记为失败，则下载的文件无效，不应使用。

Bash
```
$ sha512sum -c 9.0.10-sha.txt --ignore-missing
dotnet-sdk-9.0.306-linux-x64.tar.gz: FAILED
sha512sum: WARNING: 1 computed checksum did NOT match
sha512sum: 9.0.10-sha.txt: no file was verified
```

设置系统范围的环境变量

如果使用了以前的安装脚本，则设置的变量仅适用于当前的终端会话。将其添加到 shell 配置文件。 Linux 提供了许多不同的 shell，每个都有不同的配置文件。例如：

Bash Shell: ~/.bash_profile 或 ~/.bashrc
Korn Shell：~/.kshrc 或 .profile
Z Shell：~/.zshrc 或 .zprofile

在 shell 配置文件中设置以下两个环境变量：

DOTNET_ROOT
此变量设置为 .NET 安装到的文件夹，如 $HOME/.dotnet：

Bash
```
export DOTNET_ROOT=$HOME/.dotnet
```
PATH
此变量应同时包含 DOTNET_ROOT 文件夹和 DOTNET_ROOT/tools 文件夹：

Bash
```
export PATH=$PATH:$DOTNET_ROOT:$DOTNET_ROOT/tools
```

程序员日志

git 推送时提示：send-pack: unexpected disconnect while reading sideband packet fatal: the remote end hung up unexpec

ESP32 4G拨号实战：ML307A和ML307R的PPP指令差异详解（附完整代码）

C 和 C++ 对 enum 处理的差异，以及强制转换在GCC/ARMCC 下的实际表现

1. C 里的 enum，本质上更像“带名字的整数常量集合”

2. C 里为什么容易出 bug

3. C 标准层面再严谨一点

枚举类型有一个底层整数表示范围

4. C++ 里的普通 enum

5. C++11 的 enum class 才更“强类型”

不能隐式转成 int

不会把枚举项污染外层命名空间

但注意

6. C 和 C++ 的核心差异，最实用的理解

C 的 enum

C++ 的传统 enum

C++ 的 enum class

7. GCC / ARMClang / Keil 下的实际表现

现象一：通常按 int 宽度处理

现象二：强转非法值通常不会报错

现象三：switch 优化可能埋坑

8. -fshort-enums 这类选项要特别小心

风险 1：结构体布局变化

风险 2：超范围值截断风险更大

风险 3：跨模块 ABI 不一致

9. 在嵌入式里最危险的几个场景

场景 A：直接把协议字段强转成 enum

场景 B：把 Flash/EEPROM 的脏数据恢复成 enum

场景 C：switch 没有 default

10. 编译器告警能帮到什么程度

GCC / Clang 常见有用项

11. 最推荐的安全写法

方法一：定义 INVALID 项

方法二：配套 IsValid 函数

方法三：连续枚举可做范围判断

12. 一个 STM32 项目里的实战建议

13. 总结成一句话

在 C 里

在 C++ 里

在 GCC / ARMClang / Keil 嵌入式环境里

14. 你可以直接记住这条工程规则

STM32+CubeMX 配置ADC配合DMA多通道多次采样并自动取平均

一、推荐参数

二、CubeMX 配置

1）ADC1 基本参数

2）每个通道的 Sampling Time

3）打开 Oversampling

4）DMA 配置

三、CubeMX 生成代码关键检查

MX_ADC1_Init() 里关键部分（示例）

四、6 通道配置示例（Rank 1~6）

五、应用代码模板（一次触发，DMA 收 6 个“已平均值”）

1）全局变量

2）初始化时先做一次校准

3）启动一次采样

4）DMA 完成回调

5）使用方法

六、这时“单次采样时间”会怎么变

七、最常见的坑

1）开了 Oversampling，却还按“原采样速度”估算

2）DMA 长度还写成 6*N

3）采样时间太短

4）误以为分辨率一定“真实提高”

电容NP0、C0G、X7R、X5R、Y5V、Z5U的区别

取消新款MacBook的掀盖自动启动功能以及恢复开机音效

龙芯架构软件体系中的旧世界与新世界

我在哪个世界？

手头这软件是哪个世界的？

为啥叫「新旧世界」？

俩世界区别在哪？

怎么兼容两个世界？

常见的坑

执行一个程序，报「没有那个文件或目录」，咋回事？

我给龙架构交叉编译的 Go 程序，运行报段错误，咋回事？

龙芯提供了很多镜像源（「龙芯源」），我能用吗？

Nuget 生成本地包源v3 feed的自动批处理脚本

.Net Core web项目“检测到URL存在 http host 头攻击漏洞”的修复及验证

Host Header Attack 是什么？

ASP.NET Core 官方推荐做法：使用 Host Filtering Middleware

1）在 appsettings.json 添加允许的 Host

8. `-fshort-enums` 这类选项要特别小心

`MX_ADC1_Init()` 里关键部分（示例）

2）DMA 长度还写成 `6*N`