碎片

RK3506 uart 高波特率通信报错问题

Thu, 23 Jul 2026 00:00:00 +0000

在测试接收一个 1Mbps 串口数据的驱动上，RK3506 平台有时候启动后会有报错:

[   23.781504] ttyS4: maybe rx pin is low or baudrate is not correct!
[   23.783156] ttyS4: Frame error!
[   23.783175] ttyS4: maybe rx pin is low or baudrate is not correct!
[   23.785058] ttyS4: Frame error!
[   23.785077] ttyS4: maybe rx pin is low or baudrate is not correct!
[   23.786474] ttyS4: Frame error!
[   23.786483] ttyS4: maybe rx pin is low or baudrate is not correct!
[   23.788138] ttyS4: Frame error!
[   23.788146] ttyS4: maybe rx pin is low or baudrate is not correct!
[   23.789813] ttyS4: Frame error!
[   23.789825] ttyS4: maybe rx pin is low or baudrate is not correct!
[   23.791473] ttyS4: Frame error!
[   23.791483] ttyS4: maybe rx pin is low or baudrate is not correct!
[   23.793137] ttyS4: Frame error!

但这个错误出现几率不高，一旦出现会一直持续报错，断电重启后较大几率会消失。

所以高度怀疑是高波特率通信的电气兼容问题，通过查看内部 UART 时钟发现：

$ sudo cat /sys/kernel/debug/clk/sclk_uart1/clk_rate
24000000
$ sudo cat /sys/kernel/debug/clk/sclk_uart2/clk_rate
24000000
$ sudo cat /sys/kernel/debug/clk/sclk_uart3/clk_rate
24000000
$ sudo cat /sys/kernel/debug/clk/sclk_uart4/clk_rate
16000000

串口 uart1-3 都使用的115200波特率，时钟频率比使用1M波特率的 uart4 更高，这就奇怪了，理论上通信波特率越高，时钟频率应该更高。

而且 uart 是16倍过采样，这种情况下，16M 时钟对于 1Mbps 的通信而言，没有任何余量，任何电气上的影响延迟都会影响通信。所以怀疑是这个地方的问题。

源码文件在 drivers/tty/serial/8250/8250_dw.c中：

static void dw8250_set_termios(struct uart_port *p, struct ktermios *termios,
			       struct ktermios *old)
{
#ifndef CONFIG_ARCH_ROCKCHIP
	unsigned long newrate = tty_termios_baud_rate(termios) * 16;
#endif
	struct dw8250_data *d = to_dw8250_data(p->private_data);
	long rate;
#ifdef CONFIG_ARCH_ROCKCHIP
	unsigned int baud = tty_termios_baud_rate(termios);
	unsigned int rate_temp, diff;
#endif
	int ret;

	clk_disable_unprepare(d->clk);
#ifdef CONFIG_ARCH_ROCKCHIP
	if (d->clk) {
		if (baud <= 115200)
			rate = 24000000;
		else if (baud == 230400)
			rate = baud * 16 * 2;
		else if (baud == 1152000)
			rate = baud * 16 * 2;
		else
			rate = baud * 16;

		ret = clk_set_rate(d->clk, rate);
		rate_temp = clk_get_rate(d->clk);
		diff = rate * 20 / 1000;

这里可以看到，115200 波特率一下时钟固定为24M，然后针对 230400/1152000 做了特殊处理，其他情况下，时钟频率就只有默认的16倍了，对于过采样而言，没有余量。

修改的话，比较简单，可以考虑将115200到1152000之间，统一做倍频处理：

		if (baud <= 115200)
			rate = 24000000;
		else if (baud <= 1152000)
			rate = baud * 16 * 2;
		else
			rate = baud * 16;

然后重新构建内核镜像并刷入，经过多次重启和断电测试，报错消失。

虽然可以通过优化电气连接等方法避免，但是某些情况也不是很方便做到，提高时钟频率算是一个更为合适的做法。

IRQ 中 BH 处理的选择

Fri, 12 Jun 2026 00:00:00 +0000

这是一个内核模块开发的备忘，主要是中断处理中的 Botto-Half 处理框架选择有关。

(本文均为古法手搓，没有 AI 加成，如有错字语病实属正常)

今天在调试之前时间同步相关的内核模块时，连接一个基于 realtime 触发的 Trigger 模块到一个基于 gpio 输入的 Event 模块（通过 GPIOs 连接）时，Event 的时间戳相对 Trigger 的时间戳有较大延迟，平均在 20 微秒，理论上在这个 RK3506 平台上不应该有这么大的延迟，应该在 10 us 以内（GPIO 3-4us 加上内核调度延迟）。

那只能继续细看并分析了。

现有的内核模块时这样处理的，在 hrtimer / irq 回调中，会将时间戳和数据打包到 kfifo 中，然后通知可能阻塞等待新数据的用户进程(用户空间poll)，这里用到了 wake_up_interruptible()，实测发现当真的有程序在等待时，这个调用有接近10us 的开销，但是没有程序等待时，则开销很低。

但是使用这个模块必然需要程序来监听读取数据，那么简单，把这个调用放到 Bottom-Half 就行了。因为 wake_up 没有实时性要求，所以直接选择了 workqueue 来做，workqueue 工作在 process context 下，实质在 kworker 中，调用阻塞接口也没有关系。

改动：

# 新增结构
struct work_struct wake_work
# 初始化
INIT_WORK(...)
# irq 调用
schedule_work(&ctx->wake_work)
# 销毁
cancel_work_sync(...)

然后测试，Event 与 Trigger 延迟基本降低在 12 us 左右，有改善。但是多次测试下来发现，有时候延迟还是会上升到 20+ us ，而且一旦在这个级别，延迟会稳定在这个级别。

这就有点奇怪了，在负载变化不变的情况下，不应该是这个现象。既然好复现，就直接输出调试时间差。

结果发现，Trigger 的 irq 全程差不多要 10-21 us 左右，而且基本上都超过 10us 了，这不符合预期。因为实际硬件上 Trigger 使用的 HARD hrtimer 模式，也就是在回调中 irq 会被禁用，而且 Event 的 irq 与 Trigger 在同一个 CPU 上，那么这时候 irq 就是串行的，意味着 Trigger 处理耗时，那么 Event 的延迟必然增大。而且这里有时候延迟 20+ 与直接在 irq 中调用 wake_up 就很相似了。

继续测量时间，发现 Trigger 的回调中，schedule_work 的耗时很不稳定，间隔的忽高忽低，高可以到 10+ us(含调试代码），低的时候只有几百 ns。这也与预期不符合，直觉说明 schedule_work 有隐藏开销。

schedule_work 底层实现上，因为依赖内核进程，那么需要通知/激活对应的进程，如果进程在休眠，则还需要调度唤醒，这里面就会有开销。这跟 tasklet 很不一样，tasklet 基于 softirq 实现，tasklet_schedule 只需要标记下，后续 softirq 会直接执行对应任务，要求是任务里不能阻塞而已。

从这一点分析，在 Trigger 回调之后，唤醒的 kworker 被调度运行，这时 Event irq 触发，那么又需要切换上下文进入中断。本身 schedule_work 的最差开销加上两次切换，那么的确会恶化延迟。

继续修改：

# 新增结构
struct tasklet_struct wake_tasklet
# 初始化
tasklet_init(...)
# irq 调用
tasklet_schedule(&ctx->wake_tasklet)
# 销毁
tasklet_kill(...)

继续测试：

# Trigger 数据：                Event 数据:
11687: 1781254159 000002905  | 0 11687: 1781254159 000013405
11688: 1781254159 200002550  | 0 11688: 1781254159 200009550
11689: 1781254159 400004237  | 0 11689: 1781254159 400014153
11690: 1781254159 600004173  | 0 11690: 1781254159 600011465
11691: 1781254159 800002943  | 0 11691: 1781254159 800009652
11692: 1781254160 000003172  | 0 11692: 1781254160 000009589
11693: 1781254160 200003984  | 0 11693: 1781254160 200010400
11694: 1781254160 400003629  | 0 11694: 1781254160 400010337
11695: 1781254160 600003565  | 0 11695: 1781254160 600009690
11696: 1781254160 800003794  | 0 11696: 1781254160 800011377
11697: 1781254161 000003439  | 0 11697: 1781254161 000013939
11698: 1781254161 200003667  | 0 11698: 1781254161 200011834
11699: 1781254161 400005646  | 0 11699: 1781254161 400013521
11700: 1781254161 600003249  | 0 11700: 1781254161 600009666
11701: 1781254161 800004644  | 0 11701: 1781254161 800012811

总体上看，延迟要好很多，平均在 10 us 以内了，也符合预期。

总体分析，因为 hrtimer HARD 模式下，回调会禁用 irq ，那么整体会串行(同一个 cpu 下)，前者处理时间越长，那么后者延迟就越大。第一次分析出了部分原因，但是使用了不合适的 BH 处理框架。

虽然内核现在开始冻结 tasklet 的使用，并且提供了 BH workqueue 来代替(kernel 6.9+)，但是可见很长时间以内，tasklet 还是可以可靠使用的，尤其针对这种时间敏感型模块。

使用 safe-rm 避免意外删除

Thu, 26 Mar 2026 00:00:00 +0000

命令行操作中，难以避免 rm 命令的使用，如果脑袋昏了或者慢摆拍，很容易误删重要的文件，尤其是用户目录下的，不像根目录那样需要权限确认。

这里可以使用 safe-rm 工具来防止这种意外情况，在对被保护的目录/文件进行删除时，会打印提示并忽略。

安装及配置

Debian/Ubuntu 可以通过命令 apt install safe-rm 来安装，这个工具本质是对 rm 的一层包装，加了目标目录的检查。

安装后当前用户的默认 rm 指令就会指向 safe-rm /usr/share/safe-rm/bin/rm ，这个可以通过 which rm 来确认。接下来，我们可以通过配置全局和用户级别的 safe-rm 文件来保护需要的目录和文件：

# 全局配置文件路径: /etc/safe-rm.conf
# 这里已经有一些预制的目录，主要是重要的系统级别目录
/
/bin
/boot
/dev
/etc
/home
/initrd
/lib
/proc
/root
/sbin
/sys
/usr
/usr/bin
/usr/include
/usr/lib
/usr/local
/usr/local/bin
/usr/local/include
/usr/local/sbin
/usr/local/share
/usr/sbin
/usr/share
/usr/src
/var
# 在下面，我们可以添加自己需要保护的全局目录/文件，可以使用通配符
/home/*
/home/*/Documents
/home/*/.config
/home/*/.ssh
/home/*/.mozilla

用户级别配置文件在 ~/.config/safe-rm :

1
2
3

# 该配置仅对当前用户有效
# 建议与全局配置一样，用绝对路径配合通配符
/home/*/.local

然后在删除时，如果不小心误写，也可以提醒并忽略：

1
2

rm -rf /
safe-rm: Skipping /.

应用到 sudo 环境

以上配置对当前用户有效，但对 root 命令中调用的 rm 却无效，因为 sudo 会使用安全的环境，safe-rm 无法优先于 rm 调用。

方法是通过命令 sudo visudo 编辑sudoers 文件，找到 Defaults secure_path 行，将 safe-rm 加入：

1
2

# 将 /usr/share/safe-rm/bin 加入 secure_path 中并优先
Defaults    secure_path="/usr/share/safe-rm/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

然后通过命令 sudo which rm 来确认是否生效：

1
2

sudo which rm
/usr/share/safe-rm/bin/rm

修改打包好的Alpine文件系统

Fri, 16 Jan 2026 00:00:00 +0000

之前介绍过嵌入式用的 Alpine Linux 发行版和如何移植，本文主要讲述对于打包好的系统压缩包，如何方便的添加删除软件包。

对于已经打包的 alpine 文件系统，经常需要根据需要添加或删除软件包，如果通过开发板操作再重新打包，不够方便，这里可以利用 static 编译的 apk 工具在宿主机上进行操作。

这还需要 archivemount 工具辅助，用于直接挂载压缩包:

`1`	`sudo apt install archivemount`

以及 apk.static 工具：

# 版本根据需要选择
wget https://dl-cdn.alpinelinux.org/alpine/latest-stable/main/x86_64/apk-tools-static-3.0.3-r1.apk
tar xvzf apk-tools-static-3.0.3-r1.apk
sudo mv sbin/apk.static /usr/local/bin

对于已经打包好的文件系统 alpine.tar.gz ，使用工具 archivemount 挂载：

1
2

mkdir ./mnt_alpine
sudo archivemount alpine.tar.gz ./mnt_alpine/

这里针对目标alpine架构是 armhf，操作命令如下：

# 添加包
sudo apk.static --root ./mnt_alpine/ --arch armhf add daemontools-encore
# 删除包
sudo apk.static --root ./mnt_alpine/ --arch armhf del daemontools-encore

而文件的编辑删除则可以直接通过挂载目录进行修改即可。

等待编辑结束，可以通过 umount 保存压缩包：

`1`	`sudo umount ./mnt_alpine`

同时，会创建一份挂载前的未修改副本，以 .orig 结尾。

这相对于在开发板上进行修改再打包会方便的多，尤其适合迭代开发过程中的更新修改。

RK3506 PWM oneshot 模式驱动修正

Tue, 13 Jan 2026 00:00:00 +0000

Rockchip RK3506 芯片的 PWM 控制器支持 oneshot 模式，使用时，可以通过驱动模块、sysfs接口来配置周期、占空比和需要发送的数量（个数和重复次数），激活后硬件自动发送指定数量波形并结束。

这个功能非常适合用来变频控制外部设备，比如步进电机。

但是在实际使用时，通过 sysfs 调试，如果设置的周期过大（样例文档的 10us 没有问题），比如 100us 以上，当设置 enable 为 1 后，波形发送结束时，会出现驱动崩溃及内核panic(驱动=y构建)，提示检测到 scheduling while atomic.

通过实际驱动 drivers/pwm/rockchip-pwm.c 中可以看 irq 函数，这里主要是针对 PWMv4:

static irqreturn_t rockchip_pwm_irq_v4(int irq, void *data)
{
	struct rockchip_pwm_chip *pc = data;
	int val;
	irqreturn_t ret = IRQ_NONE;

	val = readl_relaxed(pc->base + INTSTS);
#ifdef CONFIG_PWM_ROCKCHIP_ONESHOT
	if (val & ONESHOT_END_INT) {
		struct pwm_state state;

		writel_relaxed(ONESHOT_END_INT, pc->base + INTSTS);

		/*
		 * Set pwm state to disabled when the oneshot mode finished.
		 */
		pwm_get_state(&pc->chip.pwms[0], &state);
		state.enabled = false;
		state.oneshot_count = 0;
		state.oneshot_repeat = 0;
		pwm_apply_state(&pc->chip.pwms[0], &state);

		rockchip_pwm_oneshot_callback(&pc->chip.pwms[0], &state);

		ret = IRQ_HANDLED;
	}
#endif
	if (val & CAP_LPR_INT) {

重点看 pwm_apply_state 这部分代码，这里是要清除已经设置的 oneshot 模式参数，保证结束时内部状态一致，但是 pwm_apply_state 这个函数内部明确标记 might_sleep() ，在 irq 中调用可能阻塞的函数会导致死锁等问题，而这个函数最终内部会调用rockhip_pwm及底层pinctrl一系列函数。

要解决这个崩溃问题，我们需要将 pwm_apply_state 从 top-half 移出去，丢给可以阻塞的上下文处理。驱动中最简单的修改办法，就是利用驱动结构体提供但未使用的 pwm_work 来实现。

具体就是删除这5行代码，新建一个处理函数：

+static void rockchip_pwm_work(struct work_struct *work)
+{
+    struct rockchip_pwm_chip *pc = container_of(work, struct rockchip_pwm_chip, pwm_work.work);
+    struct pwm_device *pwm = &pc->chip.pwms[0];
+    struct pwm_state state;
+    pwm_get_state(pwm, &state);
+    state.enabled = false;
+    state.oneshot_count = 0;
+    state.oneshot_repeat = 0;
+    pwm_apply_state(pwm, &state);
+}
+

然后，在 irq 函数中，调用：

	if (val & ONESHOT_END_INT) {
		struct pwm_state state;

		writel_relaxed(ONESHOT_END_INT, pc->base + INTSTS);

		/*
		 * Set pwm state to disabled when the oneshot mode finished.
		 */
+		schedule_delayed_work(&pc->pwm_work, 0);
		rockchip_pwm_oneshot_callback(&pc->chip.pwms[0], &state);

		ret = IRQ_HANDLED;
	}

并在 probe 函数中初始化：

static int rockchip_pwm_probe(struct platform_device *pdev)
 		goto err_pclk;
 	}
 
+       INIT_DELAYED_WORK(&pc->pwm_work, rockchip_pwm_work);
        rockchip_pwm_debugfs_init(pc);
 
        /* Keep the PWM clk enabled if the PWM appears to be up and running. */

以及 remove 函数中移除：

static int rockchip_pwm_remove(struct platform_device *pdev)
 	u32 val;
 
 	rockchip_pwm_debugfs_deinit(pc);
+	cancel_delayed_work_sync(&pc->pwm_work);
 
 	/*
 	 * For oneshot mode, it is needed to wait for bit PWM_ENABLE

需要注意的时，delayed_work 运行在进程上下文中，其调度受 CONFIG_HZ 的 jiffies影响，其执行可能存在较大的延迟（若干毫秒），如果业务应用对这个时间不敏感，则无所谓，如果敏感，则需要另外的修改方法，比如 threaded_irq 处理，但是这样改动相对较大，此处不再展开。

基于 x-macros 的命令行参数解析库实现

Mon, 12 Jan 2026 00:00:00 +0000

在之前文档讲述了一下 C X-Macros 的特性和一些应用场景，也提到在编译期可以确定的范式基本都可以通过 X-Macros 来辅助实现，比如命令行参数解析，这里就具体讲述如何实现。

具体代码在 github：macros_args

目标

因为使用过 argtable 这样的库，所以充分考虑了这种基于描述的命令行参数解析，但是也觉得还有一些繁琐，明明可以用一张表来表示所有参数，使用时却需要一个一个的初始化，而且库还有一些过于复杂的东西，比如特殊单位的处理支持。

设想中，这样的参数解析应该这样：

纯 header 文件实现，无 c 文件依赖；
表驱动配置解析参数，明确各个参数类型和特性；
支持参数重复，也就是同个参数传递多个值；
支持短参数和长参数，支持 literal/int/float/string 这样简单的参数类型；
尽量少依赖，不依赖动态内存分配，只适用少量 std 库和 getopt;
无全局状态，支持多实例；

考虑到实现复杂度，不依赖 std 库和 getopt 则会代码量巨大且不可维护，基本上就是需要利用标准库少量函数和getopt，来实现一个类似 argtable 这样的命令行参数解析。

思路

有了目标，就可以考虑如何实现了，本质上，就是如何将一个参数描述表转换为最终的 getopt 调用。

首先，需要考虑参数原型设计，基于以上，考虑设计4种基本参数类型：

LIT，也就是 literial，比如 -h -v 这样的开关参数，在内部应该是个整数表示是否出现及出现次数；
INT，整数参数，内部用 int 保存即可。
NUM，浮点参数，内部用 double 保存。
STR，字符串参数，内部需要用 char *保存指针即可。对于同参多值，可以将1个参数的情况作为多参数特例，所以表设计应该如下：

项目	描述
类型	参数类型，宏
最大数量	允许的最大数量，`0` 表示无限制（可以内部预设最大限制）
名称	参数在代码中的引用名称，需要符合 token 央视
短参名	类似 `-t` 的短参，用 `'c'` 这样表示，实际是整数，没有则写`0`
长参名	类似`--long`的长参，用`"long"`这样的字面量表示，没有则写 `""` 空字符串
参数提示	类似 `"<count>"` 这样的字面量，用于帮助中提示带参的类型
默认值	参数默认值，对于多参数，只有第一个参数会被设置
描述	描述这个参数用来做什么

使用时，需要用户提供一个 X Macros 列表，我们再基于这个列表，来实现我们的必要拼装：

利用表生成一个结构体定义，用来存储我们的参数；
利用表来生成解析函数，用来解析命令行并存储结果；
利用表明来实现实例唯一，可以保证无全局状态多实例；
利用表进行约束检查，避免错误使用；

实现

具体实现可以参考代码，其中最重要的就是 _ARG_IF_ELSE 这个编译期条件宏，可以基于条件生成编译期代码，而非运行期：

#define _ARG_IF_ELSE_0(THEN, ELSE) ELSE
#define _ARG_IF_ELSE_1(THEN, ELSE) THEN
#define _ARG_IF_ELSE_IMPL(CONDITION, THEN, ELSE)    _ARG_CONCAT2(_ARG_IF_ELSE_, CONDITION)(THEN, ELSE)
#define _ARG_IF_ELSE(CONDITION, THEN, ELSE)         _ARG_IF_ELSE_IMPL(CONDITION, THEN, ELSE)

宏的实现就是简单的宏拼接，所以其应用很受限，只能基于宏展开时字面量数字来进行条件选择，参数必须是字面量0或1，如果直接使用，会很受限，需要配合_ARG_BOOL宏：

#define _ARG_CHECK_N(x, n, ...)     n
#define _ARG_PROBE(x)               x, 0,
#define _ARG_PROBE_0                _ARG_PROBE(~)
#define _ARG_CHECK(...)             _ARG_CHECK_N(__VA_ARGS__)
#define _ARG_BOOL(x)                _ARG_CHECK(_ARG_CONCAT2(_ARG_PROBE_, x), 1)

这个宏更绕一些，是根据宏字面量的0或非0来条件生成字面量0或1，这里用到了__VA_ARGS__ 展开参数数量，具体可以仔细揣摩。

有了这些宏，在结构体定义、静态检查和函数实现中，可以基于参数最大数量和参数类型来生成不同的编译期代码，避免编译器告警。

使用时，程序需要提供一个类似如下的参数列表宏，并利用库的宏来生成必要定义：

#define APP_ARGS_LIST(X) \
    ARG_LITX(X, help,       'h', "help",        "show help") \
    ARG_LIT1(X, print,      'p', "print",       "print arg struct") \
    ARG_LITX(X, verbose,    'v', "verbose",     "verbose") \
    ARG_NUM1(X, timeout,    't', "timeout",     "<secs>",  0.0,  "timeout in secs") \
    ARG_LIT1(X, longonly,   0,   "longonly",    "test long only arg") \
    ARG_LIT1(X, shortonly,  's', "",            "test short only arg") \
    ARG_STR1(X, from,       'f', "from",        "<file>",  "1.txt", "file path") \
    ARG_STRX(X, token,      'k', "token",       "<token>", "token0", "process tokens")

// 2. Generate essential
ARG_DEFINE(APP_ARGS_LIST);

然后在主函数中，可以进行解析：

// 3. Decleare struct to storage parse result
ARG_STRUCT_INIT(APP_ARGS_LIST, arg);
// 4. Parse argv with struct
// ret > 0 => optind, < 0 => error!
int ret = ARG_PARSE(APP_ARGS_LIST, argc, argv, &arg);

后续就可以利用arg成员，来判断参数，或者使用宏来打印参数帮助信息：

if (ret < 0) {
    printf("Usage: %s", argv[0]);
    ARG_PRINT_SYNTAX(APP_ARGS_LIST);
    printf("\n");
    return ret;
}
// Use struct field to check result
// For LIT, use n_XXX
if (arg.n_print > 0) {
    printf("optind =%d\n", ret);
    ARG_STRUCT_PRINT(APP_ARGS_LIST, &arg);
    printf("\n");
}
if (arg.n_help > 0) {
    printf("Usage: %s", argv[0]);
    ARG_PRINT_SYNTAX(APP_ARGS_LIST);
    printf("\n\nExample:\n");
    ARG_PRINT_GLOSSARY(APP_ARGS_LIST, 30);
    return 0;
}

因为实现利用了大量宏，所以阅读起来会比较费劲，尤其是琐碎的条件处理。目前仍需要改进的部分就是利用短参字符字面量拼接getopt_long字符串参数时，通过手动去除单引号实现，这里之前考虑使用字面量而不是字符字面量，但是问题在于：

#宏可以方便实现字符串字面量，但是很难基于宏实现字符字面量；
getopt_long中即要字符字面量，也要字符串字面量；

手动去除虽然拙劣但十分有效。

Linux 接入 ADIS16505 IMU

Thu, 06 Nov 2025 00:00:00 +0000

本文主要记录如何在 Rockchip RK3506 上接入并驱动 ADIS16505 IMU 模块。

Linux 有 IIO 子系统（工业输入输出)，用于接入一些工业传感器，其中就包括 IMU。Analog ADIS16505 是一款使用较多的 MEMS IMU 模组，其驱动早已进入内核。

下面直接介绍相关适配工作，适配的 SOC 是 Rockchip RK3506，内核6.1，使用的模块是 ADIS16505-2。

参考资料：

1. 驱动适配

内核 CONFIG 修改：

1
2
3

+CONFIG_ADIS16475=m
+CONFIG_IIO_ADIS_LIB_BUFFER=y
+CONFIG_IIO_ADIS_LIB=y

然后编译出来 adis_lib.ko 和 adis16475.ko 拷贝到开发板，添加到 /lib/modules/$(uname -r)/kernel/drivers/iio/imu 下。

DTS 修改，在对应 spi 节点下添加 imu@0 节点（ADIS16505 最大只支持 2M 时钟，所以一般无法和其他外设共享 SPI 总线，建议单独一个 SPI 与之连接）：

+ imu@0 {
+            compatible = "adi,adis16505-2";
+            reset-gpios = <&gpio1 RK_PC7 GPIO_ACTIVE_LOW>;
+            reg = <0>;
+            spi-cpha;
+            spi-cpol;
+            spi-max-frequency = <2000000>;
+            interrupts = <RK_PB5 IRQ_TYPE_EDGE_RISING>;
+            interrupt-parent = <&gpio0>;
+            status = "okay";
+ };

pinctrl 配置复位和终端引脚：

+ &pinctrl {
+        adis16505 {
+                imu_pins: imu-pins {
+			             rockchip,pins =
+			             <1 RK_PC7 RK_FUNC_GPIO &pcfg_pull_none>,
+			             <0 RK_PB3 RK_FUNC_GPIO &pcfg_pull_none>;
+		         };
+        };
+}

编译，烧写 boot 镜像。

启动后，会自动加载 adis 内核模块驱动，检查 lsmod | grep adis 会输出。

2. 读取验证

数据检查，安装 apt install libiio-utils ，然后用 sudo iio_info 检查，一般输出如下：

sudo iio_info
Library version: 0.23 (git tag: v0.23)
Compiled with backends: local xml ip usb
IIO context created with local backend.
Backend version: 0.23 (git tag: v0.23)
Backend description string: Linux rk3506-iot 6.1.99 #18 SMP PREEMPT Sun Sep 28 16:51:31 CST 2025 armv7l
IIO context has 2 attributes:
        local,kernel: 6.1.99
        uri: local:
IIO context has 2 devices:
        iio:device0: adis16505-2 (buffer capable)
                8 channels found:
                        anglvel_x:  (input, index: 0, format: be:S32/32>>0)
                        3 channel-specific attributes found:
                                attr  0: calibbias value: 0
                                attr  1: raw value: 822982
                                attr  2: scale value: 0.000000006
                        anglvel_y:  (input, index: 1, format: be:S32/32>>0)
                        3 channel-specific attributes found:
                                attr  0: calibbias value: 0
                                attr  1: raw value: 632205
                                attr  2: scale value: 0.000000006
                        anglvel_z:  (input, index: 2, format: be:S32/32>>0)
                        3 channel-specific attributes found:
                                attr  0: calibbias value: 0
                                attr  1: raw value: -574057
                                attr  2: scale value: 0.000000006
                        accel_x:  (input, index: 3, format: be:S32/32>>0)
                        3 channel-specific attributes found:
                                attr  0: calibbias value: 0
                                attr  1: raw value: -182676799
                                attr  2: scale value: 0.000000037
                        accel_y:  (input, index: 4, format: be:S32/32>>0)
                        3 channel-specific attributes found:
                                attr  0: calibbias value: 0
                                attr  1: raw value: 73639656
                                attr  2: scale value: 0.000000037
                        accel_z:  (input, index: 5, format: be:S32/32>>0)
                        3 channel-specific attributes found:
                                attr  0: calibbias value: 0
                                attr  1: raw value: -172736170
                                attr  2: scale value: 0.000000037
                        temp0:  (input, index: 6, format: be:S16/16>>0)
                        2 channel-specific attributes found:
                                attr  0: raw value: 307
                                attr  1: scale value: 100
                        timestamp:  (input, index: 7, format: le:S64/64>>0)
                4 device-specific attributes found:
                                attr  0: current_timestamp_clock value: monotonic

                                attr  1: filter_low_pass_3db_frequency value: 720
                                attr  2: sampling_frequency value: 400.000000
                                attr  3: waiting_for_supplier value: 0
                3 buffer-specific attributes found:
                                attr  0: data_available value: 0
                                attr  1: direction value: in
                                attr  2: watermark value: 1
                6 debug attributes found:
                                debug attr  0: firmware_date value: 08-19-2021
                                debug attr  1: firmware_revision value: 1.7
                                debug attr  2: flash_count value: 55
                                debug attr  3: product_id value: 16505
                                debug attr  4: serial_number value: 0x2aa7
                                debug attr  5: direct_reg_access value: 0x0
                Current trigger: trigger0(adis16505-2-dev0)
        trigger0: adis16505-2-dev0
                0 channels found:
                No trigger on this device

如果有 error 或问题，则需要检查 DTS 引脚与实际的接线，接线有问题会导致出现问题。

这里需要注意 anglvel 和 accel 的 scale 字段，会跟手册的对不上，这个稍后解释。

读取实际数据，可以交叉编译内核 tools/iio/iio_generic_buffer 程序，使用 sudo iio_generic_buffer -n adis16505-2 -a -c -1 来连续可读所有数据，包括时间戳：

sudo iio_generic_buffer -n adis16505-2 -a -c -1
iio device number being used is 0
iio trigger number being used is 0
Enabling all channels
Enabling: in_accel_y_en
Enabling: in_temp0_en
Enabling: in_anglvel_z_en
Enabling: in_accel_x_en
Enabling: in_timestamp_en
Enabling: in_anglvel_y_en
Enabling: in_accel_z_en
Enabling: in_anglvel_x_en
/sys/bus/iio/devices/iio:device0 adis16505-2-dev0
0.003762 0.003326 -0.000192 -6.759874 2.724417 -6.391016 30600.000000 1759115389553132535 
0.001698 0.002608 -0.001356 -6.764592 2.726806 -6.392885 30600.000000 1759115389555627474 
0.000364 0.004624 -0.000209 -6.756444 2.718365 -6.381812 30600.000000 1759115389558121829 
-0.000038 0.003894 -0.000131 -6.760957 2.724637 -6.373475 30600.000000 1759115389560619101 
-0.000031 0.004665 -0.001059 -6.754562 2.714244 -6.378930 30800.000000 1759115389563114623 
0.001390 0.003611 -0.001513 -6.760931 2.723385 -6.377503 31000.000000 1759115389565610144 
0.002020 0.003198 -0.000661 -6.759657 2.719233 -6.383900 31000.000000 1759115389568120833 
0.002179 0.002808 -0.004133 -6.762529 2.723939 -6.387537 31000.000000 1759115389570598855 
0.001080 0.004518 -0.003293 -6.761709 2.727158 -6.387032 30700.000000 1759115389573096710 
0.000033 0.002241 -0.002442 -6.756791 2.720568 -6.381608 30700.000000 1759115389575591065 
0.000519 0.003776 -0.003139 -6.759673 2.720824 -6.381290 30700.000000 1759115389578086587 
0.000121 0.003285 -0.004375 -6.761266 2.715935 -6.379437 30600.000000 1759115389580582108 
-0.000275 0.003437 -0.003296 -6.761114 2.716521 -6.379723 30600.000000 1759115389583077047 
0.002979 0.004323 -0.002205 -6.760320 2.717569 -6.381045 30600.000000 1759115389585569360 
0.003052 0.003355 -0.003360 -6.764820 2.720145 -6.388940 30500.000000 1759115389588067799 
0.001705 0.003426 -0.002130 -6.761583 2.715266 -6.392511 30500.000000 1759115389590562446 
0.002971 0.003035 -0.003745 -6.760653 2.715627 -6.385410 30500.000000 1759115389593058259 
0.001787 0.003784 -0.002825 -6.763578 2.716290 -6.383574 30600.000000 1759115389595552614 
0.000679 0.003716 -0.004219 -6.761706 2.714494 -6.381908 30600.000000 1759115389598048428 
0.001852 0.001673 -0.002511 -6.764761 2.713016 -6.385989 30600.000000 1759115389600543949 
0.001230 0.003286 -0.003984 -6.759422 2.706651 -6.386874 30600.000000 1759115389603039471 
0.001944 0.003745 -0.001667 -6.764474 2.714547 -6.382912 30500.000000 1759115389605535285

驱动默认使用 realtime，可以通过修改 /sys/bus/iio/devices/iio:deviceX/current_timestamp_clock 来修改时间戳，可选 monotonic 使用 MONO 时间，来避免系统时间调整导致的跳跃。

3. 注意事项

由于内核中不支持浮点数，所以内核驱动在 sysfs 中展示的浮点字段，都存在精度损失(内核打印浮点只保留1e-9的精度，无法满足这款IMU的比例系数)，也就意味着，不能直接使用驱动提供的 sysfs 中的 scale 字段来求解物理值，而是直接使用芯片手册中的比例换算，在用户空间解算物理值，否则会有严重的精度丢失。针对 IIO 驱动，只使用 buffer 提供的原始值，和手册的比例系数进行换算，是最为稳妥的方式。

同时驱动在 /sys/kernel/debug/iio/iio\:deviceX/ 目录下提供一些额外信息：

1
2

ls  /sys/kernel/debug/iio/iio\:device1/
direct_reg_access  firmware_date      firmware_revision  flash_count        product_id         serial_number

这些字段可以通过参考资料2了解具体含义，比较有用的是 direct_reg_access 这个文件，可以通过它来实现直接的底层寄存器读写：

# 读取 0x60
echo 0x60 > direct_reg_access
cat 0x60
=> 0x2c1
# 写入 0x60
echo 0x60 0x2c1 > direct_reg_access
cat 0x60
=> 0x2c1

另外如频率设置、滤波设置等，可以参考资料说明，直接写入 sysfs 下对应文件即可。

C 语言中的 X-Macros

Mon, 18 Aug 2025 00:00:00 +0000

在 C 语言中，有一种较为高级的宏用法，称为 X-Macros，本文就是讲述 X-Macros 的应用。

X-Macros 用在一些需要“表驱动法”的地方，针对编译期间已知的数据集合，生成对应的接口方法，当修改数据时，只需要考虑修改“表”本身，而已有的接口方法会自动适应。

一般来说 X-Macros 核心就是一个列表宏，形如：

1
2
3

#define LIST_XMACROS_LIST(x) \
    X(a, b, c ,d, e) \
    X(f, g, h)

LIST_XMACROS_LIST 是一个列表宏，一行定义一个元素，其宏参数 X 是一个操作宏，当需要使用列表的时候，传入不同的操作宏，来实现针对列表数据的不同处理。

最常见的，就是枚举类型的字面字符串和值之间的匹配，参见如下代码：

#define MAIN_STATE_LIST(X) \
    X(ERROR, "something error") \
    X(INIT, "initialize device") \
    X(BUSY, "busy moving") \
    X(READY, "ready for scan") \
    X(SCAN, "scanning")

#define MAIN_STATE(NAME)    MST_##NAME
#define ENUM_MAIN_STATE(NAME, ...) MAIN_STATE(NAME),
enum MainStateEnum {
    MAIN_STATE_LIST(ENUM_MAIN_STATE)
    MAIN_STATE__ENUM_CNT
};

static const struct MainStateBundles {
    int state;
    const char *str;
    const char *desc;
} M_STATE_BUNDLES[] = {
#define BUNDLE_MAIN_STATE(NAME, DESC, ...) \
{ \
    .state = MAIN_STATE(NAME), \
    .str = #NAME, \
    .desc = DESC, \
},
    MAIN_STATE_LIST(BUNDLE_MAIN_STATE)
};
#undef BUNDLE_MAIN_STATE

代码最终基于列表生成一个常量结构体数组，并按照枚举值、枚举名字面量和描述来自动填充，后续函数就可以根据这个常量结构体数组，来实现枚举值、字符串和描述之间的匹配和转换。

本质上，宏是递归地字符串替换，那么，就可以利用 X-Macros 实现更复杂的功能，比如说，参数的序列化和反序列化。可以将用到的参数，定义一个列表宏，将其类型、名称、限制、是否必选等属性填入其中，然后利用该列表来完成序列化/反序列化的接口函数。

一个样例代码如下，这其中，还将参数按照 SECTION 来区分分组，目前的限制就是不支持超过2级的层次参数：

// 编译 gcc test.c -o test $(pkg-config --cflags --libs libcjson)
//
#include <stdio.h>
#include <stddef.h>
#include <stdbool.h>
#include <string.h>
#include <cjson/cJSON.h>

#define CFG_STR_MAXCHARS    32

#define LTS_CFG_CONTROL_LIST(X) \
    X(STR, serial, CFG_STR_MAXCHARS, "/dev/ttyS4", "control serial device", true) \
    X(INT, baudrate, 460800, "control serial baudrate", false) \
    X(FLOAT, scan_speed, 5.0, "scan speed deg/s", false)

#define LIDAR_ROT_DEFAULT ((double[]){ 0, 0, -1, -1, 0, 0, 0, 1, 0 })

#define LTS_CFG_LIDAR_LIST(X) \
    X(STR, ip, CFG_STR_MAXCHARS, "192.168.0.240", "lidar ip addr", false) \
    X(INT, port, 2111, "lidar port", false) \
    X(FLOAT_N, p_rot, 9, LIDAR_ROT_DEFAULT, "rot matrix", true)

#define LTS_CFG_CAMERA_LIST(X) \
    X(STR, device, CFG_STR_MAXCHARS, "/dev/video0", "camera device", false) \
    X(INT, width, 1920, "camera frame width", false) \
    X(INT, height, 1080, "camera frame height", false)

#define LTS_CFG_SECTIONS_LIST(SECTION, X) \
    SECTION(control,  LtsConfigControl,   LTS_CFG_CONTROL_LIST(X)) \
    SECTION(lidar,    LtsConfigLidar,     LTS_CFG_LIDAR_LIST(X)) \
    SECTION(camera,   LtsConfigCamera,    LTS_CFG_CAMERA_LIST(X))

#define X_INT__STDEF(N, DEF, DESC, REQD)               int     N;
#define X_FLOAT__STDEF(N, DEF, DESC, REQD)             double  N;
#define X_FLOAT_N__STDEF(N, L, DEF, DESC, REQD)        double  N[L];
#define X_STR__STDEF(N, L, DEF, DESC, REQD)            char    N[L + 1];

#define X_STDEF(TYPE_MACRO, N, ...) X_##TYPE_MACRO##__STDEF(N, __VA_ARGS__)

#define X_SECTION__STRUCT(name, stname, list) \
    struct stname { \
        list \
    } name;

struct LtsConfig {
    LTS_CFG_SECTIONS_LIST(X_SECTION__STRUCT, X_STDEF)
};

#define X_INT__INIT(N, DEF, DESC, REQD)                 cfg->N = DEF;
#define X_FLOAT__INIT(N, DEF, DESC, REQD)               cfg->N = DEF;
#define X_FLOAT_N__INIT(N, L, DEF, DESC, REQD)          memcpy(cfg->N, DEF, sizeof(cfg->N));
#define X_STR__INIT(N, L, DEF, DESC, REQD)              snprintf(cfg->N, sizeof(cfg->N), "%s", DEF);

#define X_INIT(TYPE_MACRO, N, ...) X_##TYPE_MACRO##__INIT(N, __VA_ARGS__)

#define X_SECTION__INIT(name, stname, list) \
    { \
        struct stname *cfg = &config->name; \
        list \
    }

static inline void lts_config_init(struct LtsConfig *config)
{
    LTS_CFG_SECTIONS_LIST(X_SECTION__INIT, X_INIT)
}

#define X_INT__PRINT(N, DEF, DESC, REQD)      fprintf(fp, "  %-10s = %d\n", #N, sec->N);
#define X_FLOAT__PRINT(N, DEF, DESC, REQD)    fprintf(fp, "  %-10s = %f\n", #N, sec->N);
#define X_FLOAT_N__PRINT(N, L, DEF, DESC, REQD) \
    { \
        fprintf(fp, "  %-10s = [", #N); \
        for (size_t i = 0; i < (L); i++) { \
            fprintf(fp, "%f%s", sec->N[i], (i + 1 < (L)) ? ", " : ""); \
        } \
        fprintf(fp, "]\n"); \
    }
#define X_STR__PRINT(N, L, DEF, DESC, REQD)   fprintf(fp, "  %-10s = \"%s\"\n", #N, sec->N);
#define X_PRINT(TYPE_MACRO, N, ...) X_##TYPE_MACRO##__PRINT(N, __VA_ARGS__)

#define X_SECTION__PRINT(name, stname, list) \
    { \
        const struct stname *sec = &config->name; \
        fprintf(fp, "[%s]\n", #name); \
        list \
        fprintf(fp, "\n"); \
    }

static inline void lts_config_fprint(FILE *fp, const struct LtsConfig *config)
{
    LTS_CFG_SECTIONS_LIST(X_SECTION__PRINT, X_PRINT)
}


#define X_INT__JSON(N, DEF, DESC, REQD) \
    cJSON_AddNumberToObject(sec_json, #N, sec->N);
#define X_FLOAT__JSON(N, DEF, DESC, REQD) \
    cJSON_AddNumberToObject(sec_json, #N, sec->N);
#define X_FLOAT_N__JSON(N, L, DEF, DESC, REQD) \
    { \
        cJSON *arr = cJSON_CreateArray(); \
        for (size_t i = 0; i < (L); i++) { \
            cJSON_AddItemToArray(arr, cJSON_CreateNumber(sec->N[i])); \
        } \
        cJSON_AddItemToObject(sec_json, #N, arr); \
    }
#define X_STR__JSON(N, L, DEF, DESC, REQD) \
    cJSON_AddStringToObject(sec_json, #N, sec->N);

#define X_JSON(TYPE_MACRO, N, ...) X_##TYPE_MACRO##__JSON(N, __VA_ARGS__)
#define X_SECTION__JSON(name, stname, list) \
    { \
        const struct stname *sec = &config->name; \
        cJSON *sec_json = cJSON_CreateObject(); \
        list \
        cJSON_AddItemToObject(root, #name, sec_json); \
    }

// 主函数
static inline char *lts_config_dump_json(const struct LtsConfig *config)
{
    cJSON *root = cJSON_CreateObject();
    if (!root) return NULL;

    LTS_CFG_SECTIONS_LIST(X_SECTION__JSON, X_JSON)

    char *json_str = cJSON_Print(root);
    cJSON_Delete(root);
    return json_str; // 调用者需要 free(json_str)
}

int main(int argc, char *argv)
{
    struct LtsConfig config;
    lts_config_init(&config);
    lts_config_fprint(stdout, &config);
    char *json = lts_config_dump_json(&config);
    printf("JSON len=%zu:\n %s\n", strlen(json), json);
    return 0;
}

这里需要注意的是，不同类型的参数，其参数数量是不同的，然后根据类型来实现不同的操作宏，最终利用占位宏来实现不同类型的不同处理宏方法：

1
2

// 基于二次展开的展位宏，利用 ## 拼接真正的操作宏
#define X_INIT(TYPE_MACRO, N, ...) X_##TYPE_MACRO##__INIT(N, __VA_ARGS__)

如果想在这个参数中，实现无 SECTION 全局参数，可选的办法是，除了 SECTION 外，还提供一个 MAIN 宏，来针对处理全局参数，这里不再赘述。

X-Macros 虽然不能让你像用库一样写很少的接口代码，但是允许只用写一次代码的代价来实现后续修改的自适应。其难点在于理解起来稍微有点绕，还有就是，编译时候出错的话，错误信息会较难理解。但是对于 C 语言而言，静态地类似方法，除了宏外，别无选择。

在 Lan 网络中自动识别 Wan 网络中的共享设备

Tue, 18 Feb 2025 00:00:00 +0000

局域网中通常有一些共享设备比如 NAS、打印机等，在同网络的主机可以自主发现这些设备，但是该网络的下属子网无法自动识别。

如果使用的是 OpenWrt 路由，那么可以尝试使用 mdns-repeater 这个工具来帮助子网获取上级网络的共享设备。

NAS、打印机等共享设备的自主发现均基于 UDP 的 mDNS 协议，如果要实现 Wan 到 Lan 的设备自主发现，则需要将 Wan 网络的 mDNS 消息播发到 Lan 网络中。

mdns-repeater 就是这样一个工具，在 OpenWrt 路由中，可以通过系统-> 软件包搜索 mdns 来安装该包，然后通过终端修改其配置文件，主要是指定 Wan 和 Lan 网络的接口名称：

# /etc/config/mdns_repeater

config mdns_repeater 'main'
        list interface 'wan'
        list interface 'br-lan'

然后在终端执行 /etc/init.d/mdns-repeater enable 和 /etc/init.d/mdns-repeater start 来使能开机启动和启动程序。

同时还需要修改路由防火墙，允许 Wan 的 mDNS 消息可以通过。在网络->防火墙中添加一条通信规则：名称 Allow-mDNS，协议选择 UDP，源区域选择 wan，目标区域选择 设备(输入)，目标端口选择 5353，操作选择 接受，然后保存应用。

然后过一段时间后，在 Lan 网络的主机就可以识别到 Wan 网络上的而共享设备了。

参数解析库 argtable2 的使用

Thu, 02 Jan 2025 00:00:00 +0000

C 程序解析命令行参数一般都会使用 getopt/getoptlong 这两个 GNU 接口，简单的参数设计还好，稍微复杂的就会维护起来很麻烦，比如手写 usage、命令参数的分散性（参数的异常处理）等等。

argtable2 是一个底层基于 getopt 的命令行参数处理库，开源协议为 LGPL，使用它开发复杂命令行接口简单且易于维护。

argtable2 在设计上，是面向参数本身，与该参数有关的信息都会汇聚在一起，成为一个 arg 对象。也就是说，该参数的特性，以及其 usage 都是在一起的，这对于开发和维护会特别方便(相对于基础的 getopt 而言)。

先来一个实际代码示例：

#include <stdio.h>
#include <argtable2.h>

int main(int argc, char *argv[])
{
    int ret = 0;
    // 命令行参数处理
    struct arg_lit *arghelp         = arg_lit0("h", "help", "Show help and exit");
    struct arg_lit *argversion      = arg_lit0("v",  "version", "Show version");
    struct arg_str *argdev          = arg_str0("d",  "device", "<device>", "Input device, eg '/dev/ttyUSB0'");
    struct arg_int *argbaud         = arg_int0("b",  "baudrate", "<baudrate>", "Input device baudrate, eg '115200'");
    struct arg_file *argrecord      = arg_file0("r", "record", "<file>", "Enable record to file");
    struct arg_end *end             = arg_end(20);

    void *argtable[] = {arghelp, argversion, argdev, argbaud, argrecord, end};
    if (arg_nullcheck(argtable)) {
        fprintf(stderr, "OOM\n");
        ret = 1;
        goto CLEANUP;
    }
    // 预设值默认参数
    argdev->sval[0] = "ttyUSB0";
    argbaud->ival[0] = 115200;

    int nerr = arg_parse(argc, argv, argtable);

    if (arghelp->count > 0) {
        printf("Usage: %s", argv[0]);
        arg_print_syntaxv(stdout, argtable, "\n");
        printf("\nExample:\n");
        arg_print_glossary(stdout, argtable, " %-30s %s\n");

        ret = 0;
        goto CLEANUP;;
    }

    if (argversion->count > 0) {
        printf("Version: %s\n", "v1.0");
        ret = 0;
        goto CLEANUP;
    }

    if (nerr > 0) {
        arg_print_errors(stderr, end, argv[0]);
        printf("use '%s --help' for more info.\n", argv[0]);

        ret = 1;
        goto CLEANUP;
    }
    // 打印配置
    printf("device='%s' baudrate=%d\n", argdev->sval[0], argbaud->ival[0]);


CLEANUP:
    arg_freetable(argtable, sizeof(argtable) / sizeof(argtable[0]));

    return ret;
}

其中的核心设计就是 struct arg_xxx 系列的对象，用于存储参数的类型(literal/int/double/str/date 等)、短标识(比如 -v)、长标识(比如 --version)、参数表征类型(比如 <device>)、参数说明。因为 argtable 支持多次参数设置，所以还包含一个参数数量。

arg_lit0/arg_str0 这样的函数，用来初始化参数对象，其中 lit 代表无类型参数，比如 -v 这些，后面的数字代表参数的出现次数，0 类似正则中的 ?，即 0 或者 1次，而 1 代表必须 1 次，而 n 则代表可出现1次或多次。arg_end 是一个特殊对象，用来存储参数解析的异常情况，arg_end(X) 的参数代表可以存储最多多少个错误信息。

在解析时，则需要将各个参数对象放置到一个 argtable 中，然后利用 arg_nullcheck 和 arg_parse 去初始化和解析参数。

对于 usage 打印，可以使用 arg_print_syntaxv 这样的接口，这个接口会打印精简的命令行帮助，而 arg_print_glossary 则可以打印表格样式的命令行帮助：

# gcc -o test 1.c -largtable2
# ./test -h
./test -h
Usage: ./test [-h|--help] [-v|--version] [-d|--device=<device>] [-b|--baudrate=<baudrate>] [-r|--record=<file>]

Example:
 -h, --help                     Show help and exit
 -v, --version                  Show version
 -d, --device=<device>          Input device, eg '/dev/ttyUSB0'
 -b, --baudrate=<baudrate>      Input device baudrate, eg '115200'
 -r, --record=<file>            Enable record to file

而对于参数的处理上，使用对应参数对象的 count 属性，来判断参数出现的次数，进而取值进行处理。需要注意的是，参数对象的值只在 arg_freetable 前生存有效，使用时需要注意生命周期管理。

不过对于程序而言，有时为了方便，可以不考虑调用 arg_freetable，毕竟程序结束时系统会进行回收，而参数处理，只有在程序运行时才执行1次而已，在程序运行期间保有这部分资源也还好。

如果参数对象需要设置默认参数值，则需要在 arg_nullcheck 后 arg_parse 前对字段进行赋值。

argtable2 本身底层仍然是调用 getopt 接口实现的，不过这种基于参数对象的管理设计，对于维护性有很大的提升，有时候，手写复杂的 getopt 太琐碎了。而且，argtable2 还支持 date 这样类型的参数处理，以及 kb/mb/gb 这样的尾缀表达，开发起来友好不少。

rv1106 适配 Wiznet-W5500 SPI以太网模块

Fri, 20 Dec 2024 00:00:00 +0000

本文主要记录如何在 LuckFox Pico Max RV1106 开发板上驱动 Wiznet-W5500 SPI以太网模块。

前文给开发板适配 Alpine Linux 介绍了一个 RV1106 的开发板，尺寸小巧，功能十足，只有一个 100M 以太网口对于有些应用不大够用，USB 也是跟 Type-C 共享不容易引出扩展，GPIO 针脚上引出有 SPI 总线，可以利用 Wiznet-W5500 模组扩展一个低速网口使用。

板载 GPIO 扩展引脚如下图所示：

W5500 模块除了连接 SOC SPI 总线外，还需要额外两个 GPIO 引脚用于连接 INT (中断处理) 和 RST (重置)，如上图所示，SPI 片选使用 RV1106 的 CS0 ，中断（INT）使用 GPIO2_A6(29 引脚)，重置(RST) 使用 GPIO2_A0 (24 引脚)，需要注意硬件上电平转换。

硬件连接完成后，还需要配置 RV1106 BSP 以驱动该模块。Wiznet-W5500 在内核中使用 wiznet/w5100-spi 驱动模块，我们只需要配置内核 CONFIG 以及 DTS 即可。

Kernel Config 修改如下，激活 Wiznet/w5100-spi：

#FILE: source/kernel/arch/arm/configs/luckfox_rv1106_linux_defconfig

-# CONFIG_NET_VENDOR_WIZNET is not set
+CONFIG_NET_VENDOR_WIZNET=y
+CONFIG_WIZNET_W5100=m
+CONFIG_WIZNET_W5100_SPI=m

DTS 修改如下，配置 SPI，以及 w5500 INT 和 RST 引脚：

#FILE: source/kernel/arch/arm/boot/dts/rv1106g-luckfox-pico-pro-max.dts

 // /**********SPI**********/
 &spi0 {
 	status = "okay";
 	pinctrl-names = "default";
 	pinctrl-0 = <&spi0m0_pins>;
-	cs-gpios = <&gpio1 RK_PC0 1>;
-	// cs-gpios = <&gpio1 26 1>;
+	//cs-gpios = <&gpio1 RK_PC0 1>;
+	cs-gpios = <&gpio1 16 1>;
 	#address-cells = <1>;
 	#size-cells = <0>;
 	spidev@0 {
+		status = "disabled";
 		compatible = "rockchip,spidev";
 		spi-max-frequency = <50000000>;
 		reg = <0>;
 	};
+	w5500@0 {
+		status = "okay";
+		compatible = "wiznet,w5500";
+		spi-max-frequency = <50000000>;
+		reg = <0>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&uart1m1_ctsn>;
+		interrupt-parent = <&gpio2>;
+		interrupts = <6 IRQ_TYPE_EDGE_FALLING>;
+	};
 };

以上修改完成后，编译 BSP 生成镜像刷机即可，启动后会额外生成 eth1 设备，可以安装 iperf3 工具用来测试网口性能：

基本可以达到 W5500 的 15 Mbps 的速率上限，此时 CPU 占用约在 50% 左右(多数在内核 sys 数据处理上，si 并不高)，主要原因还是 rv1106 只有单核，性能有限。

这样扩展的网口，速率只有 10 Mbps 水平，对于一些收发数据率不高的应用场景，也足够了。

适合安卓的 sing-box 客户端配置

Wed, 18 Sep 2024 00:00:00 +0000

本配置适合安卓客户端，版本需要 1.10.0-beta 以上版本。

安卓版本使用 tun 来实现代理，与 Linux 桌面版本略有不同。

配置策略

本配置主要策略：

DNS 提供国内和国外分流，且避免 DNS 泄漏；
流量基于 GeoIP/GeoSite 实现国内外分流;
过滤广告;
忽略部分国内主流应用（微信/淘宝/京东等，避免流量经过代理）；
忽略本地/似有地址的流量；

配置文件内容

本配置主要内容如下，适合 sing-box 1.10 beta 以上版本:

{
  "log": {
    "level": "info"
  },
  "dns": {
    "servers": [
      {
        "tag": "dns-remote",
        "address": "https://1.1.1.1/dns-query",
        "detour": "proxy",
        "client_subnet": "1.0.1.0"
      },
      {
        "tag": "dns-default",
        "address": "local",
        "detour": "direct"
      },
      {
        "tag": "dns-block",
        "address": "rcode://refused"
      }
    ],
    "rules": [
      {
        "rule_set": "anti-ad",
        "server": "dns-block"
      },
      {
        "rule_set": [
          "geosite-cn"
        ],
        "server": "dns-default"
      },
      {
        "outbound": "any",
        "server": "dns-default"
      }
    ],
    "final": "dns-remote",
    "disable_expire": true
  },
  "inbounds": [
    {
      "type": "tun",
      "tag": "tun-auto",
      "mtu": 9000,
      "address": [
        "172.18.0.1/30",
        "fdfe:dcba:9876::1/126"
      ],
      "auto_route": true,
      "strict_route": true,
      "route_address": [
        "0.0.0.0/1",
        "128.0.0.0/1",
        "::/1",
        "8000::/1"
      ],
      "route_exclude_address": [
        "10.0.0.0/8",
        "172.16.0.0/12",
        "192.168.0.0/16",
        "fc00::/7"
      ],
      "exclude_package": [
        "com.jingdong.app.mall",
        "com.douban.frodo",
        "com.taobao.taobao",
        "com.eg.android.AlipayGphone",
        "com.tencent.mm",
        "com.tencent.mp",
        "com.tencent.soter.soterserver",
        "com.tencent.wemeet.app",
        "com.tencent.weread",
        "com.tencent.wework"
      ],
      "udp_timeout": "5m",
      "stack": "mixed",
      "platform": {
        "http_proxy": {
          "server": "127.0.0.1",
          "server_port": 8080
        }
      },
      "sniff": true
    }
  ],
  "outbounds": [
    {
      "type": "selector",
      "tag": "proxy",
      "outbounds": [
        "trojan",
        "hysteria"
      ],
      "default": "trojan"
    },
    {
      "type": "trojan",
      "tag": "trojan",
      ...
    },
    {
      "type": "hysteria",
      "tag": "hysteria",
      ...
    },
    {
      "type": "direct",
      "tag": "direct"
    },
    {
      "type": "block",
      "tag": "block"
    },
    {
      "type": "dns",
      "tag": "dns-out"
    }
  ],
  "route": {
    "rules": [
      {
        "rule_set": "anti-ad",
        "outbound": "block"
      },
      {
        "protocol": "dns",
        "outbound": "dns-out"
      },
      {
        "ip_is_private": true,
        "rule_set": [
          "geoip-cn",
          "geosite-cn"
        ],
        "outbound": "direct"
      }
    ],
    "rule_set": [
      {
        "type": "remote",
        "tag": "anti-ad",
        "format": "binary",
        "url": "https://github.com/SagerNet/sing-geosite/raw/rule-set/geosite-category-ads-all.srs",
        "download_detour": "proxy"
      },
      {
        "type": "remote",
        "tag": "geosite-cn",
        "format": "binary",
        "url": "https://github.com/SagerNet/sing-geosite/raw/rule-set/geosite-cn.srs",
        "download_detour": "proxy"
      },
      {
        "type": "remote",
        "tag": "geoip-cn",
        "format": "binary",
        "url": "https://github.com/SagerNet/sing-geoip/raw/rule-set/geoip-cn.srs",
        "download_detour": "proxy"
      }
    ],
    "final": "proxy",
    "auto_detect_interface": true
  },
  "experimental": {
    "cache_file": {
      "enabled": true
    }
  }
}

备注

需要注意的地方：

由于 sing-box 内部 DNS 服务性能原因，建议境内 DNS 使用 local，尽量不用 DOH/DOT，否则会因为解析延迟影响体验；
tun.exclude_package 里是需要忽略的应用包名，常见应用可以去搜索包名添加，以避免走代理；
route.rules.auto_detect_interface 是需要设置的，否则代理会无法生效；

适合 Linux 桌面的 sing-box 客户端配置

Thu, 12 Sep 2024 00:00:00 +0000

sing-box 作为代理工具的集大成者，支持多协议多功能，且覆盖多平台，但是配置起来比较复杂，这里给出一个适合 Linux 桌面使用的配置样本，供参考。

本配置适合 Linux 桌面，不适配 Windows 和 Android，Mac OS 也许可以参考部分。

配置策略

本配置主要实现的目的：

提供本地 HTTP/HTTPS/SOCKS5 代理，供给浏览器（Firefox）和命令行工具等使用，自动分流国内和国外流量（基于 GeoIP 和 GeoSite）；
通过代理的 DNS 同样提供国内和国外分流；
提供本地 DNS 服务器，通过该服务器可以实现 DNS 国内和国外分流；
避免 DNS 泄漏（DNS 泄漏可以认为是：访问的境外域名泄漏给国内 DNS 服务商，使之可以获悉你访问的境外网站）；
过滤广告;

配置内容

本配置主要内容如下，适合 sing-box 1.10 beta 以上版本，如果使用版本为 1.9.x，则可以考虑删除广告过滤的配置即可：

{
  "log": {
    "disabled": false,
    "level": "info",
    "timestamp": false
  },
  "dns": {
    "servers": [
      {
        "tag": "dns-remote",
        "address": "https://1.1.1.1/dns-query",
        "detour": "proxy",
        "client_subnet": "1.0.1.0"
      },
      {
        "tag": "dns-local",
        "address": "local",
        "detour": "direct"
      },
      {
        "tag": "dns-default",
        "address": "https://223.5.5.5/dns-query",
        "detour": "direct"
      },
      {
        "tag": "dns-block",
        "address": "rcode://refused"
      }
    ],
    "rules": [
      {
        "rule_set": [
          "anti-ad"
        ],
        "server": "dns-block",
        "disable_cache": true
      },
      {
        "inbound": [
          "global"
        ],
        "server": "dns-remote"
      },
      {
        "rule_set": [
          "geosite-cn"
        ],
        "server": "dns-default"
      },
      {
        "outbound": "any",
        "server": "dns-default"
      }
    ],
    "final": "dns-remote",
    "independent_cache": true
  },
  "inbounds": [
    {
      "tag": "dns-in",
      "type": "direct",
      "listen": "127.0.0.1",
      "listen_port": 5335,
      "network": "udp",
      "sniff": true,
    },
    {
      "tag": "global",
      "type": "mixed",
      "listen": "127.0.0.1",
      "listen_port": 1091,
      "sniff": true,
      "set_system_proxy": false
    },
    {
      "tag": "auto",
      "type": "mixed",
      "listen": "127.0.0.1",
      "listen_port": 1090,
      "sniff": true,
      "set_system_proxy": false
    }
  ],
  "outbounds": [
    {
      "tag": "proxy",
      "type": "selector",
      "outbounds": [
        "trojan",
        "hysteria"
      ],
      "default": "hysteria"
    },
    {
      "tag": "trojan",
      "type": "trojan",
      ...
    },
    {
      "tag": "hysteria",
      "type": "hysteria",
      ...
    },
    {
      "tag": "direct",
      "type": "direct"
    },
    {
      "tag": "block",
      "type": "block"
    },
    {
      "tag": "dns-out",
      "type": "dns"
    }
  ],
  "route": {
    "rules": [
      {
        "inbound": "dns-in",
        "outbound": "dns-out"
      },
      {
        "rule_set": [
          "anti-ad"
        ],
        "outbound": "block"
      },
      {
        "inbound": [
          "global"
        ],
        "outbound": "proxy"
      },
      {
        "rule_set": [
          "geoip-cn",
          "geosite-cn"
        ],
        "ip_is_private": true,
        "outbound": "direct"
      },
      {
        "protocol": "dns",
        "outbound": "dns-out"
      }
    ],
    "final": "proxy",
    "rule_set": [
      {
        "tag": "anti-ad",
        "type": "remote",
        "format": "binary",
        "url": "https://anti-ad.net/anti-ad-sing-box.srs",
        "download_detour": "proxy"
      },
      {
        "tag": "geosite-cn",
        "type": "remote",
        "format": "binary",
        "url": "https://github.com/SagerNet/sing-geosite/raw/rule-set/geosite-cn.srs",
        "download_detour": "proxy"
      },
      {
        "tag": "geoip-cn",
        "type": "remote",
        "format": "binary",
        "url": "https://github.com/SagerNet/sing-geoip/raw/rule-set/geoip-cn.srs",
        "download_detour": "proxy"
      }
    ]
  },
  "experimental": {
    "cache_file": {
      "enabled": true
    }
  }
}

备注

主要配置思路：

dns 服务器部分，国内使用 alidns 作为境内 dns 服务器，有普通和 DOH 两个，国外使用 Cloudflare 的 DOH dns 服务器，同时创建了一个用于屏蔽的 dns-block 服务器；
dns 规则部分较为简单，基于 anti-ad 规则进行 dns 屏蔽；对于全局代理入口 global 则都转发到 dns-remote 解析；对于域名匹配了 GeoIP-CN 和 GeoSite-CN 规则集，则使用境内 dns 服务器； final 使用 dns-remote。这里实现了 dns 分流和广告屏蔽。outbound=any 规则保证了代理服务器域名的解析，否则代理无法正常启动。
inbounds 提供了 3 个服务入口：
- dns-in 提供本地 dns 服务，后续可以将系统 dns 请求转发到这里（配合 systemd-resolved）；
- global 提供本地全局代理，支持 HTTP/HTTPS/SOCKS5，代理流量全部走境外；
- auto 提供本地分流代理，支持 HTTP/HTTPS/SOCKS5，代理流量会自动分流；
outbounds 除了常规的 direct、block 外，创建了一个 dns-out 服务，以及用于代理的 selector 和真正的 trojan/hyseria，这里具体配置则根据实际的来。
route 规则部分，主要包括：
- dns-in 转发给 dns-out，用于本地 dns 服务器；
- 基于 anti-ad 的广告屏蔽；
- global 的全局代理路由；
- 基于境内网站、IP 匹配或私有网络 IP 匹配，则流量通过本地；
- final 设置为 proxy 走境外来保证境外流量规则；
- protocol=dns 部分走 dns-out 是为了 dns 分流；
规则集部分，除了 anti-ad 需要 1.10 beta 以上版本支持，其他都兼容 1.9.x。这里都是用远程规则集，并使用了 experimental.cache_file 来保证本地缓存。
需要额外注意的是，不要在 DNS 规则中使用 IP 规则集（比如 GeoIP 等），这会导致在 DNS 路由处理前将域名解析为 IP 进行匹配，以至于在这个阶段发生 DNS 泄漏。

自启动管理

为了实现 sing-box 自启动和权限，则可以使用如下 systemd service 文件，需要注意可执行文件路径及配置文件路径：

# path: /usr/local/lib/systemd/system/sing-box.service
[Unit]
Description=Sing-Box
After=network.target 
Wants=network-online.target

[Service]
Type=simple
# 限制用户权限
DynamicUser=yes
ExecStart=/usr/local/bin/sing-box run -D ${CACHE_DIRECTORY} -c /usr/local/etc/sing-box/config.json
# 提供特权端口监听权限
AmbientCapabilities=CAP_NET_BIND_SERVICE
NoNewPrivileges=true
CacheDirectory=sing-box
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

通过 systemctl enable sing-box –now 后，通过 systemctl status sing-box 查看状态，通过 journalctl -u sing-box 查看日志。

DNS 转发

另外，如果想将系统 DNS 全部转发给 sing-box，我们则可以通过 ~~systemd-resolved~~ dnsmasq 来转发请求(dnsmasq 可以利用 strict-order 来实现 fallback 机制)。

安装完 dnsmasq 后，新增配置文件:

# path: /etc/dnsmasq.d/dns-servers.conf
# only bind to lo
interface=lo
bind-interfaces
# not use or poll /etc/resolv.conf
no-resolv
no-poll
# cache
# max live in cache
max-cache-ttl=3600
# min live in cache
min-cache-ttl=300
# cache size
cache-size=1000
# keep strict order on servers
strict-order
# sing-box server
server=127.0.0.1#5335
# fallback server if sing-box failed
server=223.5.5.5

然后 systemctl restart dnsmasq 来重启服务。

同时，需要手动修改 /etc/resolv.conf 文件来指定使用 dnsmasq 服务器:

# path: /etc/resolv.conf
nameserver ::1
nameserver 127.0.0.1
options edns0 trust-ad

为了避免 /etc/resolv.conf 被以外修改，可以使用 sudo chattr +i /etc/resolv.conf 来标记不可变属性。

对于 Firefox，需要将配置中的代理配置为 127.0.0.1:1090，所有协议共用这个端口。对于普通命令行工具，则可以在 ~/.bashrc 文件中追加两行：

1
2

export http_proxy=http://127.0.0.1:1090
export https_proxy=$http_proxy

DNS 泄漏检测

所有正常后，想检查是否存在 DNS 泄漏，则可以用 Firefox 访问以下两个网站任意一个即可：

如果访问的 ip 显示境外，且 dns 服务器也在境外，则表明不存在泄漏。另外，还可以使用 wireshark 来抓 dns 包检查。

关闭 popen 打开的子进程

Wed, 07 Aug 2024 00:00:00 +0000

常见功能开发中，需要获取其他命令的输出数据时，通常可以采用 popen 打开子进程进行读操作，但是 popen 并没有提供终止子进程的接口，pclose 会阻塞等待子进程自己结束然后才返回。导致在一些会持续输出的命令调用中，无法方便的结束子进程。

一种解决方法是使用 fork 来自行实现类似 popen 的接口，比如 Kill a process started with popen，但是在一些简单场景，可以尝试更为简单的方法。

popen 在 Linux 上通常是调用 shell 去创建会话执行命令，可以利用 shell 的方法来获取会话进程的 pid，然后在输出中输出 pid ，这样在调用 pclose 之前可以使用 pkill 调用去终止会话及子进程以避免 pclose 阻塞。

shell（常见 bash）中，$$ 变量表示当前 shell 的进程 pid, 我们可以利用该变量来控制子进程。以 ping 指令为例，使用如下命令创建子进程：

1
2
3

# 需要注意 \$\$ 而非 $$，否则当前 shell 会直接解译该变量导致输出为当前 shell pid，
# 而非会话子进程
sh -c "echo pid=\$\$; ping 223.5.5.5"

其输出:

pid=62853
PING 223.5.5.5 (223.5.5.5) 56(84) bytes of data.
64 bytes from 223.5.5.5: icmp_seq=1 ttl=116 time=24.1 ms
64 bytes from 223.5.5.5: icmp_seq=2 ttl=116 time=23.3 ms
64 bytes from 223.5.5.5: icmp_seq=3 ttl=116 time=24.4 ms
64 bytes from 223.5.5.5: icmp_seq=4 ttl=116 time=23.4 ms
...

这时，在另外 shell 中执行 pkill -P 62883 来终止会话子进程(该命令无需 root 权限, pkill -P 只终止父进程 pid 匹配的进程, shell 进程在子进程命令结束后自然退出)，子会话及其子进程会终止退出：

pid=62853
PING 223.5.5.5 (223.5.5.5) 56(84) bytes of data.
64 bytes from 223.5.5.5: icmp_seq=1 ttl=116 time=24.6 ms
64 bytes from 223.5.5.5: icmp_seq=2 ttl=116 time=24.7 ms
64 bytes from 223.5.5.5: icmp_seq=3 ttl=116 time=24.5 ms
64 bytes from 223.5.5.5: icmp_seq=4 ttl=116 time=24.2 ms
64 bytes from 223.5.5.5: icmp_seq=5 ttl=116 time=22.6 ms
64 bytes from 223.5.5.5: icmp_seq=6 ttl=116 time=21.2 ms
64 bytes from 223.5.5.5: icmp_seq=7 ttl=116 time=26.3 ms
64 bytes from 223.5.5.5: icmp_seq=8 ttl=116 time=24.7 ms
Terminated

利用该特性，在实践中可以在 popen 后，利用 fgets 从输出中获取会话 pid，然后在 pclose 前，调用 system("pkill -P xxxx") 来终止会话子进程，然后再调用 pclose 去释放资源，此时 pclose 调用不会阻塞，该方法虽不优雅，但足够 quick-and-dirty.

解决 LXC 客户机中登陆缓慢的问题

Tue, 19 Mar 2024 00:00:00 +0000

如果在 LXC 容器中运行 Ubuntu/Debian，有时候会碰到登陆缓慢卡住的情况，尤其是跨架构的容器，需要很久才登陆成功：

使用 lxc-attach xxxx 后，使用 su user 切换用户时，卡住；
直接使用 ssh user@10.0.3.xxx，输入完用户名密码后，卡住；

卡住之后，系统负载上升，检查会发现容器的 systemd 进程 CPU 占用很高，需要很久才正常，然后登陆成功。同样，关闭 LXC 容器时，命令也会等待很久。

解决办法可以参考 Fix Debian 11 bullseye slow SSH login and sudo on LXC Proxmox：

在容器中运行 systemctl mask systemd-logind；
在容器中运行 pam-auth-update 然后取消选择 Register user sessions in the systemd control group hierarchy，即可。或者直接运行 pam-auth-update --remove systemd.

具体原因倒不是特别清晰，这种现象特别影响效率。

LXC 容器无法 DHCP 获取到 IP

如果 LXC 容器已经使用 DHCP 获取 IP, 但是启动后无法正常获取 IP，则可以通过这种方法解决：

临时方案：在宿主系统运行 ethtool -K vethXXXX tx off 和 ethtool -K lxcbrXXX tx off，命令需要 root 权限，该命令会关闭 LXC 虚拟网卡的校验功能。
永久方案：使用 udev 规则来自动处理校验关闭，创建文件 /etc/udev/rules.d/90-lxc-net.rules:

1
2

ACTION=="add",SUBSYSTEM=="net",KERNEL=="veth*", RUN+="/usr/sbin/ethtool -K $env{INTERFACE} tx off"
ACTION=="add",SUBSYSTEM=="net",KERNEL=="lxcbr*",RUN+="/usr/sbin/ethtool -K $env{INTERFACE} tx off"

这种现象原因是，虚拟网卡一般不需要在 IP 包中附加校验，但是 DHCP 工具目前会主动校验数据包，造成检验失败，DHCP 握手失败。

给开发板适配 Alpine Linux

Thu, 16 Nov 2023 00:00:00 +0000

本文主要记录如何将 Alpine Linux 的 rootfs 移植到 RV1106 开发板上，重点是细节坑的处理。

手头有一个 LuckFox（幸狐）的开发板，型号是 Luckfox Pico Max，SOC 是瑞芯微的 RV1106，尺寸小巧，接口俱全，跟一个 U 盘差不多大小:

规格方面，可以看官方 Wiki 介绍，主要是如下这些：

瑞芯微 RV1106 Cortex A7 1.2G 单核
0.5 TOPS NPU
256MB DDR3L
SPI NAND 256MB
10/100M 以太网
5M@30fps ISP + MIPI CS2 2-lane
GPIO/UART/PWM/I2C/SPI/USB 等外设接口

虽然 RV1106 是为 IPC 应用设计的，但是这个价格和外设，在低端工控/物联网领域，性价比十足，这个顶配的 LuckFox Pico Max 开发板，也才￥70 RMB 左右，加上 Linux 的开发效率，可以替代很多 MCU 的应用场景了。

自带的系统带有很多程序，主要是 IPC 应用。我们可以移植 Alpine Linux 的 rootfs 给这个开发板，这样就可以方面的配置系统和包管理了，而无需自己来编译移植各种程序。

Alpine Linux 的 rootfs 的移植主要参考社区的一篇文章「当幸狐来敲门」适配Alpine Linux下篇–适配Alpine Linux的详细步骤，但是实际操作起来有一些坑需要注意。

构建自己的 Alpine Linux rootfs

可以用 docker 镜像来提取 rootfs，也可以用 lxc 容器来做，这里介绍 lxc 的方法。

首先需要更新 lxc 的 alpine 文件模板，这个跟系统 lxc-templates 版本有关。主要是因为 alpine 的验证 keys 更新，系统 apt 安装的 lxc-templates 还未引入这个变更。

# 修改文件 /usr/share/lxc/templates/lxc-alpine
# 参考上游代码变更 <https://github.com/lxc/lxc-templates/commit/2163a7e4e04383696bb88a9da2f7fa61ab4781b7>
# 更新 APK_KEYS_SHA256 和 APK_KEYS_URI
sudo vim /usr/share/lxc/templates/lxc-alpine

创建一个兼容 arm A7 架构(armv7l/armhf) 的 lxc 容器，这里容器名称为 alpine-armhf:

# debian 系系统中 lxc 中 armv7 架构已经改名为 armhf
# 这里默认会安装 alpine 3.18 版本，如果想使用滚动发行版本 edge
# 则命令为
#     sudo lxc-create -n alpine-armhf -t alpine -- --release edge --arch armhf
sudo lxc-create -n alpine-armhf -t alpine -- --arch armhf

创建存储 rootfs 的文件并挂载到容器中：

# 这部分参考文章中使用文件挂载。
# 其实在 lxc 中更为简单，因为每个容器的 rootfs 都存在系统中，可以直接访问
#    /var/lib/lxc/[container-name]`/rootfs
# 
# 创建临时文件，用来存储 rootfs
dd if=/dev/zero of=rootfs.ext4 bs=1M count=100
# 格式化文件，创建文件系统
sudo mkfs.ext4 rootfs.ext4
# 挂在临时文件到 /tmp/my-rootfs
mkdir /tmp/my-rootfs
sudo mount rootfs.ext4 /tmp/my-rootfs

# 编辑 alpine-armhf config 文件，映射挂载点 LXC /mnt -> HOST /tmp/my-rootfs
# 在 /var/lib/lxc/alpine-armhf/config 文件末尾添加如下行
lxc.mount.entry = /tmp/my-rootfs  mnt none    bind,create=file    0   0

启动 alpine-armhf 容器并登陆容器：

# 启动 alpine-armhf 容器
sudo lxc-start alpine-armhf
# 进入 alpine-armhf 系统
sudo lxc-attach -n alpine-armhf

进行基本的配置：

# 注意，这里的命令都是在 alpine-armhf 容器中操作
# 使用 alpine 中科大镜像源
sed -i 's/dl-cdn.alpinelinux.org/mirrors.ustc.edu.cn/g' /etc/apk/repositories
apk update

# 安装 openrc
apk add openrc
# 配置 openrc 添加必要启动服务
rc-update add devfs boot
rc-update add procfs boot
rc-update add sysfs boot

# 配置串口登陆
echo ttyFIQ0 >> /etc/securetty

# 编辑 /etc/inittab 文件
# 删除 tty1 到 tty6 的行
# 添加 ttyFIQ0 行
ttyFIQ0::respawn:/sbin/getty -L ttyFIQ0 0 vt100
# 如果需要 ttyFIQ0 自动登陆，则添加
ttyFIQ0::respawn:/sbin/agetty --autologin root ttyFIQ0 vt100
# 并安装 agettty 包
apk add agetty 


# 修改 hostname
echo "YourHostname" > /etc/hostname


# 安装 dropbear ssh server
# dropbear 比 openssh-server 更节省空间
apk add dropbear dropbear-dbclient dropbear-openrc dropbear-scp
# 添加 dropbear 自动启动
rc-update add dropbear default

# 设置密码
# 需要注意的是，这里暂时需要指定 root 密码加密方法为 md5，否则会使用 sha256 
# 但是 BSP 中编译的 busybox 版本只支持 md5，BSP 版本会覆盖安装 rootfs 中的 busybox
# 会导致 ssh 登陆失败
# 另外一种解决方法是，编译 BSP 时，修改 busybox 配置
#   make busybox_menuconfig
# 重新设置 root 密码
passwd -a md5

# 配置网络
# alpine 使用 ifupdown-ng 来管理网络
# 可以编辑 /etc/network/interfaces 
# DHCP:
#   auto eth0
#   iface eth0 inet dhcp
# 固定 IP
#   auto eth0
#   iface eth0 inet static
#       address 192.168.100.100
#       netmask 255.255.255.0
#       gateway 192.168.100.1
# 根据需要修改，但是不建议修改容器本身的，因为容器需要 dhcp 来接入网络更新 apk
vi /etc/network/interfaces
# 添加网络自启动
rc-update add networking default

# 设置时区
apk add tzdata
cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime
echo "Asia/Shanghai" > /etc/timezone
# 节省空间
apk del tzdata

# 添加基本包
apk add bash bash-completion
apk add util-linux
# 添加 mtd ubi 工具
apk add mtd-ubi

# 修改默认 root 登陆 shell
# 修改 /etc/passwd 文件
# 将 root 行末尾的 /bin/ash 改为 /bin/bash
vi /etc/passwd

至此，我们需要的 rootfs 已经在容器中构建，现在需要进行打包和“最后的修改”：

# 这里仍然在 alpine-armhf 容器中操作
cd /
for d in bin etc lib root sbin usr; do tar c "$d" | tar x -C /mnt; done
for dir in dev proc run sys var; do mkdir /mnt/${dir}; done

# 进行“最后的修改”
# alpine 中程序是可以感知到在容器中运行，所以有些配置跟实际板子上不同，这里需要
# 做一些修改，但是这些修改不适合容器本身，所以在这里加上一些“最后的修改”
cd /mnt
# 以下操作均在 /mnt 进行，且文件前无 / 前缀
# 给 bbsuid rw 权限，否则 BSP 编译时会提示无法覆盖 /bin/bbsuid
chmod u+rw bin/bbsuid
# 修改 openrc 配置文件，去掉 lxc 模式 
# 找到 rc_sys="lxc" 行，改为
# rc-sys=""
# 否则有些服务会在板子上不启动，比如 sysfs，会导致其他问题
vi etc/rc.conf

# NOTE: 修改 /etc/inittab 文件，加上 root 重挂载命令:
# 官方的 BSP 中也有这个配置，否则板子启动后为默认为只读 root 文件系统
# 在 ::sysinit:/sbin/openrc sysinit 行前加上一行
#
#   ::sysinit:/bin/mount -o remount,rw,noatime /
# 这行是将 root 重挂载为可读写模式 noatime 可以提高性能
# 
# 同时，删除或用 # 注释掉最后两行的 Main LXC console console 
# # Main LXC console console
# #::respawn:/sbin/getty 38400 console
vi etc/inittab

# 打包 rootfs
cd /mnt
tar czf alpine.tar.gz *
# 此时，/mnt/alpine.tar.gz 为我们打包好的 rootfs

此时退出 alpine-armhf 容器，在主机上 /tmp/my-rootfs 目录下有一个 alpine.tar.gz 文件，将其复制到 Luckfox 官方 BSP 的 sysdrv/custom_rootfs 目录下，没有则自行创建目录。
关闭容器并取消挂载。

1
2
3

sudo lxc-stop alpine-armhf
sudo umount /tmp/my-roofs
rm rootfs.ext4

修改编译设置

开发板官方 BSP 搭建可以参考 SDK 环境搭建，我这里使用了 lxc 创建构建环境，没有使用虚拟机，BSP 仓库地址为 https://github.com/LuckfoxTECH/luckfox-pico.git.

根据官方 wiki 创建好环境后，修改 SDK 根目录的 build.sh 文件，找到 1044 行 function __PACKAGE_ROOTFS() 函数，将 build_get_sdk_version 前内容修改为

function __PACKAGE_ROOTFS()
{
        local rootfs_tarball _target_dir _install_dir

        if [ -f $rootfs_tarball ]; then
            if [ -z $RK_CUSTOM_ROOTFS ]; then
                rootfs_tarball="$RK_PROJECT_PATH_SYSDRV/rootfs_${RK_LIBC_TPYE}_${RK_CHIP}.tar"
                    tar xf $rootfs_tarball -C $RK_PROJECT_OUTPUT
                else
                    rootfs_tarball="$RK_CUSTOM_ROOTFS"
                    if [ ! -d $RK_PROJECT_PACKAGE_ROOTFS_DIR ]; then
                        mkdir $RK_PROJECT_PACKAGE_ROOTFS_DIR
                    fi
                    tar xf $rootfs_tarball -C $RK_PROJECT_PACKAGE_ROOTFS_DIR
                fi
        else
                msg_error "Not found rootfs tarball: $rootfs_tarball"
                exit 1
        fi

        build_get_sdk_version

修改 BSP 根目录下的 .BoardConfig.mk 文件（需要先 ./build.sh lunch 生成对应开发板配置).在文件末尾添加

`1`	`export RK_CUSTOM_ROOTFS=../sysdrv/custom_rootfs/alpine.tar.gz`

重新执行 ./build.sh 命令生成镜像即可。

自定义系统配置

结合了另外一篇文章 RV1103 魔改，我也对开发板的配置进行了修改，主要也是减少 CMA 内存和调整 NAND 布局，将整个 NAND 都作为根分区使用，去掉了 oem 和 userdata. 这里要修改 BSP 目录下的 .BoardConfig.mk 文件:

# BoardConfig.mk 文件的介绍可以参见 BSP 目录下的 project/cfg-all-iterms-instroction.txt 文件
# 减少 CMA 内存，默认为 66 M，也可以配置更少，比如 1M
# 这个主要影响图像视频的 AI 处理
# Config CMA size in environment
export RK_BOOTARGS_CMA_SIZE="24M"

# 配置分区布局，仅使用 rootfs 分区
export RK_PARTITION_CMD_IN_ENV="256K(env),256K@256K(idblock),512K(uboot),12M(boot),232M(rootfs)"
export RK_PARTITION_FS_TYPE_CFG=rootfs@IGNORE@ubifs

更大的 rootfs 分区可以安装更多的包。修改配置后重新执行 ./build.sh 构建即可。

刷机注意事项

构建好镜像后，将 image 复制到 Windows 刷机时，需要注意 rootfs.img/oem.img/userdata.img 均为链接，其大小可能为 1kb，再使用刷机工具时，这几个 img 需要选择称对应的实际文件，而非链接本身，否则不会执行刷入。

也可以在刷机工具下方选择更新固件，刷入 update.img.

如果刷机工具一直无法找到 Maskrom 设备，则有可能是用的 typec 线有问题，尽量选择全芯数据线，而不是充电线。

问题及方法

ssh 登陆开发板一直提示 Permission denied, please try again，哪怕 root 密码输入是对的。

这个问题就是开发板 root 密码加密用的是 sha256/sha512 哈希算法，但是 busybox 不支持导致的。查看 rootfs /etc/shadow 文件 root 行，如果 root: 后是 $1 开头，那么则是 md5 加密，其他数字就是其他加密方法。要么 passwd -a md5 使用 md5 重新设置密码，要么就编译 BSP 时修改 busybox 配置，以支持这些加密方法。
BSP 构建时，提示无法写入 bin/bbsuid 报错。

这个问题参见构建 rootfs 的第 6 步骤。
进入开发板系统后， mount 显示 ubi0:rootfs 为 ro 只读模式。

这个问题同样参见构建 rootfs 的第 6 步骤。可以修改 /etc/inittab 添加重挂载选项。
进入开发板系统后，rc-status -a 显示 sysfs 不在激活序列中，且已经 rc-update add sysfs boot 添加过了。

修改 /etc/rc.conf 文件，将 rc_sys="lxc" 修改为 rc_sys="".

使用 LXC 创建交叉架构的容器

Thu, 12 Oct 2023 00:00:00 +0000

如果部署程序的设备是 ARM 环境，通常程序编译要么交叉编译器，要么使用开发板进行编译。本文介绍一种利用 LXC 交叉架构创建一个用于编译程序的容器。

当使用交叉编译器时，如果程序依赖很多包，维护交叉编译环境就特别麻烦，需要自己维护特定的 rootfs 。当使用开发板编译时，代码编辑到编译不方便，而且占用一块开发板。如果我们可以在开发主机上搭建一个与设备架构环境一致的系统，那么将大大提升开发的便捷性。比如设备上用的 aarch64 的 ubuntu focal(20.04)，我们可以在开发主机上使用 LXC 搭建一个 aarch64 的 ubuntu focal 系统容器，所有开发编译都可以在这个容器里进行，除了依赖板子设备硬件的程序，其他程序都还可以在这个容器里调试运行。

LXC 的安装可以参考前一篇博文使用 LXC 创建用于构建 BSP 的容器机。

下面介绍搭建交叉架构的容器，以 aarch64 ubuntu focal 为例：

创建容器

因为使用交叉架构，那么需要安装 qemu 的一个库，用来转义系统调用，然后创建容器：

# 交叉架构依赖 qemu-user-static
sudo apt install qemu-user-static
# 创建 arm64(aarch64)架构的容器
sudo lxc-create -n ubuntu-aarch64 -t download  --  --dist ubuntu --release focal --arch arm64

配置容器系统

默认安装的发行版本没有给出用户 ubuntu 密码，而且网络部分存在一些问题，都需要手动进行配置。

首先，可以通过 lxc-attach 命令进入系统

1
2

# 无密码进入系统
sudo lxc-attach -n ubuntu-aarch64

修改 ubuntu 用户密码：

1
2

# 修改 ubuntu 用户密码
passwd ubuntu

临时配置网络

1
2

# 临时使用 dhcp 配置网络，然后就可以安装新包了
dhclient eth0 -v

需要卸载模块中的 netplan，然后使用 ifupdown 来管理网络：

1
2
3

# 使用 ifupdown 代替 netplan
apt remove netplan.io libnetplan0
apt install ifupdown

为了开发方便，还需要安装 ssh server:

1
2

# 安装 ssh server
apt install openssh-server

然后可以编辑网络，创建 /etc/network/ 文件夹并写入配置到 /etc/network/interfaces 文件中

# 编辑网络
mkdir /etc/network

cat << EOF | sudo tee /etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp

source /etc/network/interface.d/*
EOF

然后就可以退出 lxc-attach ，来验证容器是否正常化。

# 首先退出 Lxc-AttacH
# 停止容器
lxc-stop ubuntu-aarch64
# 启动容器
lxc-start ubuntu-aarch64
# 等待几秒，查看容器是否已有 ip
lxc-ls -f
# 通过 ip 进入系统
ssh ubuntu@10.0.3.x

备注

为了编译方便，还可以挂在主机上的代码工程文件夹到容器中，参考前一篇博文，这样就可以在主机上编辑代码，在容器中进行编译测试了。

使用 LXC 创建用于构建 BSP 的容器机

Tue, 26 Sep 2023 00:00:00 +0000

工作电脑用的系统是 Debian Sid(当前代号 trixie, Debian 13)，工作内容中经常需要构建 BSP，厂商提供的构建要求通常为指定版本的 Ubuntu，如果不想换掉系统或者使用 Docker，可以考虑使用 LXC 创建指定版本的 Ubuntu 用于构建。

Debian 使用 LXC 可以参考官方Wiki，虽然 LXC VM 分为 Unprivileged 和 Privileged，前者隔离对主机更为安全，但是局限很多。在 BSP 构建中通常需要进行 mount 等操作，所以我们需要使用 Privileged VM。

安装和配置

安装 LXC：

`1`	`sudo apt install lxc`

容器默认使用主机共享网络。我们需要修改默认 apparmor 配置，在文件 /etc/lxc/default.conf：

# /etc/lxc/default.conf
lxc.net.0.type = veth
lxc.net.0.link = lxcbr0
lxc.net.0.flags = up

# 修改如下内容
lxc.apparmor.allow_nesting = 1
lxc.apparmor.profile = unconfined

创建使用 VM

创建一个 ubuntu focal 的 VM，名称为 ubuntu-focal：

1
2

# -n 指定名称(name) -t 指定模板(template) -r 指定 发行版(release)
sudo lxc-create -n ubuntu-focal -t ubuntu -- -r focal

检查当前存在的 VM：

sudo lxc-ls -f
# 以下为输出示例
# NAME         STATE   AUTOSTART GROUPS IPV4 IPV6 UNPRIVILEGED 
# ubuntu-focal STOPPED 0         -      -    -    false

配置 ubuntu-focal，定义一些本地挂载，以及允许 mount 等一些操作，修改该 VM 的配置 /var/lib/lxc/ubuntu-focal/config：

# 添加以下内容到 /var/lib/lxc/ubuntu-focal/config 文件中

# allow  mount loop
lxc.apparmor.profile = unconfined 
lxc.cgroup2.devices.allow = b 7:* rwm
lxc.cgroup2.devices.allow = c 10:237 rwm

# 定义本地挂载点，将本地 /home/some_user/some_dir 自动挂载到 ubuntu-focal 的 /mnt 下
# 注意 lxc.mount.entry VM 中挂载点不使用 `/` 前缀
lxc.mount.entry = /home/some_user/some_dir   mnt     none    bind,create=file        0       0

# 挂载 loop 设备
lxc.mount.entry = /dev/loop0    dev/loop0       none    bind,create=file        0       0
lxc.mount.entry = /dev/loop1    dev/loop1       none    bind,create=file        0       0
lxc.mount.entry = /dev/loop2    dev/loop2       none    bind,create=file        0       0
lxc.mount.entry = /dev/loop3    dev/loop3       none    bind,create=file        0       0
lxc.mount.entry = /dev/loop4    dev/loop4       none    bind,create=file        0       0
lxc.mount.entry = /dev/loop5    dev/loop5       none    bind,create=file        0       0
lxc.mount.entry = /dev/loop-control     dev/loop-control        none    bind,create=file        0       0

启动 VM：

# 启动 ubuntu-focal
sudo lxc-start ubuntu-focal

# 查看当前运行的 VM 和 IP
sudo lxc-ls -f 
# 以下为输出
# NAME         STATE   AUTOSTART GROUPS IPV4       IPV6 UNPRIVILEGED 
# ubuntu-focal RUNNING 0         -      10.0.3.179 -    false

现在可以通过 ssh ubuntu@10.0.3.179 进入 VM 进行操作了。不需要使用时可以用命令 sudo lxc-stop ubuntu-focal 关掉 VM。

疑难问题

在构建 BSP 中提示 binfmt_misc 权限问题，请检查 VM 的配置中 lxc.apparmor.profile 字段，是否为 unconfined。
在构建 BSP 中提示 mount -o loop 权限问题，请检查 VM 配置中与上一章节示例中的有关 allow mount loop 相关的配置。

小结

使用 LXC 而不是 Docker 源于个人选择和使用场景，相对来说，支持同 VM 多进程的 LXC 更为适合用于构建 BSP 的 VM 工具，而 Docker 则适合部署使用。

Linux 移动硬盘安全关闭

Thu, 25 May 2023 00:00:00 +0000

最近固态价格越来越便宜了，就买了一个航雄M2移动硬盘盒，方案是 RTL9120B，支持 Nvme/Sata 双协议，然后弄了一块 1T 的大杯固态。然后把用了2年多的 U盘 Debian系统迁移过去。具体迁移方法过后再写篇文章仔细描述，GPT/UEFI 系统迁移实在是太简单了。

之前用的 U盘，没有 SMART 信息，换移动硬盘后就发现，当笔记本关机后，移动硬盘还是工作状态，我这个硬盘盒指示灯是双色，绿色代表工作（总线桥接中），蓝色代表待机（Nvme电源关闭），关机后直到电脑 USB 自动断电，硬盘盒断电，再进入系统看 SMART 就可以看到“不安全关机（Unsafe Shutown Counts”会递增 1。虽然固态硬盘这个计数实际不会损害，但是过于膈应，而且我觉得系统本身不可能不支持自动给移动硬盘自动弹出。

这个跟旧固件的 RTK9210B 硬盘盒 bug 不同，我的硬盘盒固件是比较新的 1.31，弹出硬盘不安全关机次数递增的 bug 已经修正了。我这种情况是 Linux 系统装在移动硬盘上，然后关机时系统没有通知 USB 设备进入待机（Standby）状态。查询了许多资料，都是让在 /lib/systemd/system-shutdown 中使用 udisksctl 或者 hdparm 去卸载/关闭 USB 存储，实际操作下来并没有什么用，直到看到论坛帖子 Graceful way to spin down (unload head) USB attached mobile hard drive BEFRORE shutdown(poweroff/reboot/halt)，才找到正确的解决方案。

具体就是，需要使能系统 scsi_disk 模块对于 USB 存储的 manage_start_stop 标志，这样系统就会管理这些设备的启动和停止任务。对于一般的外置移动硬盘而言，通常是用户自行加载移除设备，但是对于运行了系统的移动硬盘而言，用户无法自行处理移除，需要系统自己在关机时处理。比较奇怪的是为什么 Linux 没有默认使能这个标志。

解决方案：

手动处理（需要root权限，重启失效）：

# 使能 manage_start_stop, [...] 为硬盘节点，可以补全
echo 1 | sudo tee /sys/class/scsi_disk/[...]/manage_start_stop
# 检查
cat /sys/class/scsi_disk/[...]/manage_start_stop

利用 udev 规则，自动处理：

1
2

# 创建文件 /etc/udev/rules.d/01-manage-start-stop.rules
echo 'ACTION=="add|change", DRIVERS=="usb-storage|uas", SUBSYSTEM=="scsi_disk", ATTR{manage_start_stop}="1"' | sudo tee /etc/udev/rules.d/01-manage-start-stop.rules

另外，对于使用 RTL9210b 方案，Linux 系统默认状态下固态并不支持 TRIM 指令，可以通过一个 udev 规则来默认激活 TRIM 支持:

`1`	`echo 'ACTION=="add\|change", ATTRS{idVendor}=="0bda", ATTRS{idProduct}=="9210", SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap"' \| sudo tee /etc/udev/rules.d/10-uas-discard.rules`

然后通过命令 lsblk -D 检查 TRIM 支持：

$ lsblk -D
NAME        DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda                0      512B       4G         0
├─sda1             0      512B       4G         0
├─sda2             0      512B       4G         0
├─sda3             0      512B       4G         0
└─sda4             0      512B       4G         0

Linux 下 Logitech G29 编程

Tue, 15 Mar 2022 00:00:00 +0000

本文介绍在 Linux 下 Logitech G29 套件的编程接入，包括摇杆数据读取、自动归中配置以及 LED 控制。

Linux 内核对于摇杆输入处理分几个部分，其中数据读取是 Kernel Joystick API, 设备是 /dev/input/jsX，对于 G29 而言，可以通过 /dev/input/by-id 来获取节点名，通常为 /dev/input/by-id/usb-Logitech_G29_Driving_Force_Racing_Wheel-joystick。

而反馈，是 Kernel Force feeback API，设备是 /dev/input/eventX，也可以通过 /dev/input/by-id 来获取节点名。

这两部分参考内核文档即可读取传感器数据和设置反馈归中等效果。G29上还带了一个 LED 带，通常用于游戏中的视觉特效，比如发动机转速等。这个 LEDs 在内核中不属于通用设备，没有特定 API 支持，映射的设备文件为 /dev/hidrawX，可以通过 hidraw 与之通信，来控制 LEDs 状态，这部分可以参考 Logitech G29 Shifter LEDs. 需要注意的是，需要设定 udev 规则来配置该 hidrawX 的写入权限，因为默认该设备所属用户组均为 root。

完整样例代码如下，请注意需要将 G29 配置成 PS3 模式（G29在不同配置模式下，生成的 USB ID不同）。需要内核支持 Logitech 驱动，一般桌面 Linux 发行版已经打开了对应编译开关。

#include <stdio.h>
#include <linux/joystick.h>
#include <linux/input.h>
#include <unistd.h>
#include <string.h>
#include <signal.h>
#include <fcntl.h>
#include <sys/select.h>
#include <stdlib.h>

#include <libudev.h>


static sig_atomic_t m_signal = 0;
static void signal_cb(int sig)
{
    m_signal = sig;
    signal(sig, signal_cb);
}

static unsigned char LED_ON[] =   { 0xf8, 0x12, 0x1f, 0x00, 0x00, 0x00, 0x01 };
static unsigned char LED_OFF[] =  { 0xf8, 0x12, 0x00, 0x00, 0x00, 0x00, 0x01 };


static int open_g29_led()
{
    struct udev* udev = udev_new();
    if (!udev) {
        printf("udev_new() failed\n");
        return -1;
    }
    int hid = -1;
    struct udev_enumerate *enumerate = udev_enumerate_new(udev);
    udev_enumerate_add_match_subsystem(enumerate, "hidraw");
    udev_enumerate_scan_devices(enumerate);

    struct udev_list_entry *devices = udev_enumerate_get_list_entry(enumerate);
    struct udev_list_entry *entry;
    udev_list_entry_foreach(entry, devices) {
        const char *path = udev_list_entry_get_name(entry);
        struct udev_device *dev = udev_device_new_from_syspath(udev, path);
        if (dev) {
            struct udev_device *hid_dev =
                udev_device_get_parent_with_subsystem_devtype(dev, "usb", "usb_device");
            if (hid_dev) {
                const char *node = udev_device_get_devnode(dev); // devnode should be hidraw, not usb
                const char *vendor = udev_device_get_sysattr_value(hid_dev, "idVendor");
                const char *product = udev_device_get_sysattr_value(hid_dev, "idProduct");
                if (node && vendor && product) {
                    printf("%s\t%s:%s\n", node, vendor, product);
                    if (strtol(vendor, NULL, 16) == 0x046d && strtol(product, NULL, 16) == 0xc24f) {
                        printf("g29 led hidraw path: %s\n", node);
                        hid = open(node, O_WRONLY);
                        if (hid == -1) {
                            perror("open() hidraw");
                        }
                        break;
                    }
                }
            }
            udev_device_unref(dev);
        }
    }

    udev_enumerate_unref(enumerate);
    udev_unref(udev);
    return hid;
}

int main(int argc, char **argv)
{
    signal(SIGTERM, signal_cb);
    signal(SIGINT, signal_cb);
    char *input = "/dev/input/by-id/usb-Logitech_G29_Driving_Force_Racing_Wheel-joystick";
    char *event = "/dev/input/by-id/usb-Logitech_G29_Driving_Force_Racing_Wheel-event-joystick";
    if (argc > 1) {
        input = argv[1];
    }
    if (argc > 2) {
        event = argv[2];
    }
    printf("device: %s\n", input);
    printf("event: %s\n", event);
    open_g29_led();
    int fd = open(input, O_RDONLY);
    if (fd == -1) {
        perror("open");
        return -1;
    }
    int ev = open(event, O_RDWR);
    if (ev == -1) {
        close(fd);
        perror("open");
        return -1;
    }

    int autocenter = 65;
    struct input_event ie;
    ie.type = EV_FF;
    ie.code = FF_AUTOCENTER;
    ie.value = 0xFFFFUL * autocenter / 100;
    if (write(ev, &ie, sizeof(ie)) == -1) {
        perror("set auto-center");
    }

    int led = open_g29_led();
    if (led == -1) {
        printf("open led failed, ignore LEDs\n");
    }
    if (led != -1) {
        write(led, LED_ON, sizeof(LED_ON));
    }
    puts("Hello, world!");
    sleep(1);

    while (m_signal == 0) {
        fd_set fds;
        FD_ZERO(&fds);
        FD_SET(fd, &fds);
        struct timeval tv;
        tv.tv_sec = 0;
        tv.tv_usec = 50000;
        int rv = select(fd + 1, &fds, NULL, NULL, &tv);
        if (rv == -1) {
            perror("select");
            break;
        }
        if (rv == 0) {
            continue;
        }

        struct js_event e;
        int r = read(fd, &e, sizeof(e));
        if (r == -1) {
            perror("read");
            break;
        } else if (r == 0) {
            printf("!!!\n");
        } else {
            int init = (e.type & JS_EVENT_INIT) != 0;
            e.type &= ~JS_EVENT_INIT;
            printf("%.3lf %d\t%d\t%d\t%d\n", e.time * 1E-3, init,  e.type, e.number, e.value);
        }
    }
    printf("signal : %s\n", strsignal(m_signal));

    if (led != -1) {
        write(led, LED_OFF, sizeof(LED_OFF));
        close(led);
    }

    ie.type = EV_FF;
    ie.code = FF_AUTOCENTER;
    ie.value = 0xFFFFUL * 0 / 100;
    if (write(ev, &ie, sizeof(ie)) == -1) {
        perror("set auto-center");
    }

    close(fd);
    close(ev);
    return 0;
}

备注，对于 LED 控制权限问题，可以通过 udev rule 来配置：

`1`	`ACTION=="add",SUBSYSTEMS=="usb",ATTRS{idVendor}=="046d",ATTRS{idProduct}=="c24f",GROUP="users",MODE="0666"`

FTDI 串口驱动数据包延迟

Mon, 14 Mar 2022 00:00:00 +0000

最近项目测试发现串口收取时存在延迟、拥堵现象，多个 packet 接收的时间戳是一样的，但是发送的时候的确是每帧间隔固定时间。

测试了手头的 USB转串口模块，CH340的没有这个问题，但是 FT 系列都存在这个问题，包括 FT232/FT2232 等。现象是高频小包数据通信时，多个包拥堵到达，达到时间是一样的，但是发送时候是明显单包单包发送，就好像传输过来有缓冲区一样。

搜索了 “FTDI+Latency"后，发现如果使用的是 FTDI 厂商的 USB 转 UART 串口模块，默认是存在传输延迟的，参见 FTDI Linux USB latency，通过一下命令可以查看当前的默认延迟时间，默认一般为 16ms，这个对于高频率小包传输的影响是相当明显的：

`1`	`cat /sys/bus/usb-serial/devices/ttyUSB0/latency_timer`

对于目前的新版内科而言，命令 echo 1 > /sys/bus/usb-serial/devices/ttyUSB0/latency_timer 无法使用，提示 Input/Output Error，正确的方法是通过系统 API 来配置串口描述符的 Low Latency 属性：

#include <sys/ioctl.h>
#include <linux/serial.h>
...
// low latency
int serial = open(...);
...
struct serial_struct kernel_serial_settings;
ioctl(serial, TIOCGSERIAL, &kernel_serial_settings);
kernel_serial_settings.flags |= ASYNC_LOW_LATENCY;
ioctl(serial, TIOCSSERIAL, &kernel_serial_settings);

如此设置后，内核会通知 ftdi 驱动部分去降低 latency_timer 值，设置后可以通过 cat /sys/bus/usb-serial/devices/ttyUSB0/latency_timer 查看到该值已变更为 1.

利用 CMake 在 C\C++ 中嵌入资源

Mon, 25 Jan 2021 00:00:00 +0000

在程序中嵌入资源是很常见的需求，资源可以是 GLSL Shader、LICENSE/EULA 文本、预定义公钥、图标图片等等。特定的平台和SDK里，会有特定的接口和工具来导入管理这些资源，比如 VC 的rc、QT 的 qrc，或者直接使用文件读写、dlopen/dlsym 来加载外部资源。对于C\C++而言，可以直接将资源转换成字符串字面量或数组，嵌入到程序中使用，本文即讲解如何在 cmake 构建中方便的嵌入各种资源。

嵌入文本资源可以在源文件中写字面量，但是字符转义和格式调整会比较麻烦，二进制资源可以使用 xxd / hexdump 工具来转成数组，但这增加额外依赖。其实利用 CMake 本身的指令语法，就可以实现上述的资源嵌入。主要思路如下：

将资源文件纳入工程中，利用 cmake 获取文件大小、文件名以及文件内容；
利用 string(MAKE_C_IDENTIFIER...) 转换文件名为合法的 C 符号，后面将会使用该符号作为资源字节数组名；
利用 string(REGEX...) 转换文件内容为 HEX 编码，并导出到生成的 C 文件中；

再配合 CMake 中使用 protobuf/protobuf-c 文中的 add_custom_target 方法，可以实现只有资源文件修改后才会触发构建转换。

以示例工程为例，工程有3个文件，分别是

a_demo_assets.assets，项目资源文件，其内容是 GPLv2 License 文本；
main.c，项目主程序源码，内容是打印资源文件大小和内容；
CMakeLists.txt，构建脚本；

main.c 源码内容如下，其中 a_demo_assets.assets.h 是资源生成的头文件，文件名与资源文件名相关，头文件就包含两个常量定义 A_DEMO_ASSETS_ASSETS__SIZE 和 A_DEMO_ASSETS_ASSETS__DATA，分别为资源字节大小和资源字节数组。

需要注意的是，转换的资源字节数组最后会多一个 0x00 字节，用来保证文本资源可以满足 C 风格字符串末尾截断。

#include <stdio.h>
#include "a_demo_assets.assets.h"

int main(int argc, char **argv)
{
    printf("a_demo_assets size=%u\n", A_DEMO_ASSETS_ASSETS__SIZE);
    printf("a_demo_assets data=\n");
    fwrite(A_DEMO_ASSETS_ASSETS__DATA, A_DEMO_ASSETS_ASSETS__SIZE, 1, stdout);
    return 0;
}

CMakeLists.txt 内容如下，这里是实现的核心地方，细节可以参见注释。

cmake_minimum_required(VERSION 3.0)
project(demo_cmake_embed)

# 需要生成嵌入的文件
file (GLOB EMBED_FILES
    "${CMAKE_CURRENT_SOURCE_DIR}/*.assets"
)
# 输出文件目录
set (GEN_EMBED_OUTPUT_HDR_DIR
    "${CMAKE_CURRENT_BINARY_DIR}/gen_inc")
set (GEN_EMBED_OUTPUT_SRC_DIR
    "${CMAKE_CURRENT_BINARY_DIR}/gen_src")
file(MAKE_DIRECTORY ${GEN_EMBED_OUTPUT_HDR_DIR})
file(MAKE_DIRECTORY ${GEN_EMBED_OUTPUT_SRC_DIR})

# 依次处理文件
foreach(input_src ${EMBED_FILES})
    # 配置输出文件名
    file(SIZE ${input_src} embed_file_size)
    get_filename_component(embed_file ${input_src} NAME)
    set(gen_embed_file        "${GEN_EMBED_OUTPUT_SRC_DIR}/${embed_file}.c")
    set(gen_embed_file_header "${GEN_EMBED_OUTPUT_HDR_DIR}/${embed_file}.h")
    # 清空输出文件
    file(WRITE ${gen_embed_file} "")
    file(WRITE ${gen_embed_file_header} "")
    # for c compatibility
    string(MAKE_C_IDENTIFIER ${embed_file} token)
    # to upper case
    string(TOUPPER ${token} token)
    # read hex data from file
    file(READ ${input_src} filedata HEX)
    # convert hex data for C compatibility
    string(REGEX REPLACE "([0-9a-f][0-9a-f])" "0x\\1," filedata ${filedata})
    # append data to output file
    file(APPEND ${gen_embed_file}
        "const unsigned char ${token}__DATA[] = {\n${filedata}0x00\n};\n"
        "const unsigned long ${token}__SIZE   = ${embed_file_size};\n")
    file(APPEND ${gen_embed_file_header}
        "extern const unsigned char ${token}__DATA[];\n"
        "extern const unsigned long ${token}__SIZE;\n")
    # 加入到生成文件列表
    list(APPEND GEN_EMBED_FILES
        ${gen_embed_file}
        ${gen_embed_file_header}
    )
endforeach()

add_custom_target(
    embed_gen_files
    DEPENDS ${GEN_EMBED_FILES}
)
include_directories(${GEN_EMBED_OUTPUT_HDR_DIR})

add_executable(${PROJECT_NAME} main.c ${GEN_EMBED_FILES})
add_dependencies(${PROJECT_NAME} embed_gen_files)
#target_link_libraries(${PROJECT_NAME} m)

在构建中，每个资源会对应生成头文件和C文件，头文件只包含大小和资源字节数组声明，C文件包含实际定义。在大项目中，可以将资源统一在一个子模块中，模块最终输出成静态库或动态库，其他需要使用资源的模块可以链接该模块来获取资源。

示例工程源码下载.

自动使能 CAN 总线

Thu, 05 Nov 2020 00:00:00 +0000

Linux 上 CAN 总线接口以网络设备形式呈现，默认系统启动时 CAN 总线处于 DOWN 模式，需要手动使用 ip 命令配置并使能 UP。但也可以使用系统 network 的 interfaces 式文件来实现 CAN 总线自动化配置和激活。

以 can0 总线设备为例，如果设备为非可插拔（固定）总线，则可以新建 /etc/network/interfaces.d/can 文件，写入如下内容（假设使用 500k 波特率)：

auto can0
iface can0 inet manual
        pre-up /sbin/ip link set $IFACE type can bitrate 500000 restart-ms 10
        up /sbin/ip link set $IFACE up
        down /sbin/ip link set $IFACE down

重启，然后使用 ip -details link show can0 来查看总线是否激活。

对于可插拔总线，比如 USB 转换的 CAN 总线，需要修改 auto can0 为 allow-hotplug can0：

allow-hotplug can0
iface can0 inet manual
        pre-up /sbin/ip link set $IFACE type can bitrate 500000 restart-ms 10
        up /sbin/ip link set $IFACE up
        down /sbin/ip link set $IFACE down

这样当 CAN 设备插入时，系统会自动配置并激活。

Linux To Go 系统优化

Mon, 02 Nov 2020 00:00:00 +0000

本文主要讲述如何优化配置 U 盘上安装的 Debian/Linux 系统，使其适配各种硬件主机并优化 U 盘上性能。

在高速 U 盘上安装 Linux 系统随身携带使用是很方便的事情，这跟 LiveCD 模式不同，所有的系统配置和文件都是随盘保存，不会随着重启重置，也不会因为更换机器而产生差异。

硬件及系统选择

U 盘硬件直接影响系统性能，主要影响指标为容量以及主控性能。

建议使用 U 盘容量大于等于 128G，不管是文件系统大小还是从用户数据考量，过小的容量很容易造成磁盘满载，而 U 盘满载会导致 IO 等待 GC 处理而卡顿，影响体验和 U 盘寿命。

而 U 盘主控同样影响，尤其是主控的 4K 随机读写性能。市面上大多数 U 盘都是连续读写速度还不错，但是小文件 4K 性能很渣，而操作系统大多数都是受制于 4K 读写性能。这里推荐三星的三款 U 盘，Bar Plus，Fit Plus，Duo Plus，这三款 4K 性能都很优异（4K IO > 10MB/s）。

系统镜像方面，推荐使用最新内核 (5.6 以上）的系统，这样可以支持最新的硬件平台而保证在各个硬件上启动，而且新的内核已知问题更少。这里推荐使用 Debian testing（bullseye），镜像建议使用附带非自由驱动的 firmware-debian-testing-dvd DVD 镜像。

分区及挂载优化

U 盘相对于 SSD，存在天然的短板（读写性能差，没有磨损平衡等），所以选择合适的文件系统并适当配置，可以提升不少性能和寿命优化。

本文推荐 U 盘系统将根 / 和用户目录 /home 独立分区，并且采用 btrfs 文件系统。独立分区可以后期更换系统而保留用户文件数据，使用 btrfs 可以获得一些先进的文件系统特性，但是使用 btrfs 文件系统可能存在不稳定的情况，所以推荐安装的系统都尽量使用最新的内核（越新的内核中 btrfs 已知问题越少）。

在安装完系统后，建议修改 /etc/fstab 中 btrfs 文件系统的挂载参数如下：

`1`	`defaults,noatime,compress=lzo,ssd_spread,autodefrag`

其中：

noatime. 默认为 relatime，每次读取文件会更新文件访问时间而增加 IO，修改为 noatime 后可以大幅提升文件系统性能。
compress=lzo. 启用文件系统透明压缩（lzo 算法），可以缩小文件系统占用磁盘空间（在 / 上大概可以获得 30% 压缩，在 /home 上大约可以获得 20% 的压缩），提升 IO 吞吐量（因为压缩），而代价仅略微增加 CPU 消耗（btrfs压缩算法有 3 种，默认为zlib，压缩效果好，但是占用 CPU 高，lzo压缩快，CPU 占用低，zstd 在两者之间，但是 grub 目前还不支持 zstd 压缩）。
ssd_spread. 启用 btrfs 为低速 SSD 设备的优化策略。
autodefrag. 启用在线整理，可以后台自动优化文件系统布局。

需要注意的是，在系统安装时，默认 btrfs 是不激活透明压缩的，在修改 /etc/fstab 后，透明压缩也只对新生成的文件生效，想要对已有文件进行压缩处理，需要执行如下指令：

1
2

sudo btrfs filesystem defragment -v -r /
sudo btrfs filesystem defragment -v -r /home/

想要粗略知道 btrfs 文件系统大小和占用磁盘大小，可以执行如下指令：

1
2

sudo btrfs filesystem show /
sudo btrfs filesystem show /home

源及驱动安装

针对 Debian testing 系统的更新源建议使用清华大学开源镜像站的源（国内）：

# /etc/apt/sources.list
deb http://mirrors.tuna.tsinghua.edu.cn/debian/ testing main contrib non-free
# deb-src http://mirrors.tuna.tsinghua.edu.cn/debian/ testing main contrib non-free
deb http://mirrors.tuna.tsinghua.edu.cn/debian/ testing-updates main contrib non-free
# deb-src http://mirrors.tuna.tsinghua.edu.cn/debian/ testing-updates main contrib non-free
deb http://mirrors.tuna.tsinghua.edu.cn/debian-security testing-security main
# deb-src http://mirrors.tuna.tsinghua.edu.cn/debian-security testing-security main

建议在系统中安装如下额外驱动包，以适配广泛的平台硬件：

sudo apt-get install  \
        firmware-amd-graphics \
        firmware-brcm80211 \
        firmware-iwlwifi \
        firmware-misc-nonfree \
        firmware-realtek

CMake 中使用 protobuf/protobuf-c

Mon, 05 Oct 2020 00:00:00 +0000

本文主要提供一种在 C\C++ 项目中嵌入 Protobuf/Protobuf-C proto 源文件进行编译的应用方法。

Protobuf 的 proto 源文件在 C\C++ 项目构建需要首先通过 protoc 工具生成对应的 C++ 源码文件，然后参与编译过程。将这个工具生成过程也集成到 CMake 构建中会方便 proto 定义变更的及时跟进，也可以将 proto 文件同时纳入版本管理中。

在 CMake 中可以使用 execute_process 来手动调用 protoc 来进行源码生成，但是这样在每次 cmake 命令时都重新生成源码文件，导致依赖的其他构建目标也重新编译，在 proto 定义未修改的情况下无端增加了编译时间。本文提供的方法可以避免这个问题。

主要思路如下：

proto 文件构建作为 cmake 工程一个的 subdirectory。允许多个 proto 文件参与构建，同时将生成的源码编译为库作为其他目标的链接对象，而不是以源码形式参与其他目标的编译。
利用 cmake 的 add_custom_command 和 add_custom_target 进行 proto 文件生成。将生成源码文件与 proto 源文件增加依赖关系，只有当 proto 文件更改时才需要重新生成。

在项目中，将项目使用的 proto 文件放到一个子目录比如 proto 中，在目录中同时增加一个 CMakeLists.txt 作为项目 subdirectory。项目主 CMakeLists.txt 去 add_subdirectory 这个 proto 目录，然后 include_directories 对应的头文件目录变量。

以下为 proto 中的 CMakeLists.txt示例，同时包括了 protobuf 和 protobuf-c 两个示例：

# 获取编译器
find_program(
    PROTOC_C
    protoc-c
    DOC "Protobuf-c Compiler (protoc-c)"
    REQUIRED
)
find_program(
    PROTOC_CXX
    protoc
    DOC "Protobuf Compiler (protoc)"
    REQUIRED
)

# 需要编译的 proto 文件
file (GLOB PROTO_SOURCE_FILES
    "${CMAKE_CURRENT_SOURCE_DIR}/*.proto"
)

set(PROTO_PATH    "${CMAKE_CURRENT_SOURCE_DIR}")
set(PROTO_C_OUT   "${CMAKE_CURRENT_BINARY_DIR}/gen_c")
set(PROTO_CXX_OUT "${CMAKE_CURRENT_BINARY_DIR}/gen_cxx")

file(MAKE_DIRECTORY ${PROTO_C_OUT})
file(MAKE_DIRECTORY ${PROTO_CXX_OUT})

# 使用 protoc 处理 proto 文件
foreach(input_proto ${PROTO_SOURCE_FILES})
    get_filename_component(DIR ${input_proto} DIRECTORY)
    get_filename_component(FILE_NAME ${input_proto} NAME_WE)

    set(OUTPUT_C_HEADER     "${PROTO_C_OUT}/${FILE_NAME}.pb-c.h")
    set(OUTPUT_C_SOURCE     "${PROTO_C_OUT}/${FILE_NAME}.pb-c.c")
    list(APPEND OUTPUT_SOURCES_C
        ${OUTPUT_C_HEADER} ${OUTPUT_C_SOURCE})

    set(OUTPUT_CXX_HEADER   "${PROTO_CXX_OUT}/${FILE_NAME}.pb.h")
    set(OUTPUT_CXX_SOURCE   "${PROTO_CXX_OUT}/${FILE_NAME}.pb.cc")
    list(APPEND OUTPUT_SOURCES_CXX
        ${OUTPUT_CXX_HEADER} ${OUTPUT_CXX_SOURCE})
endforeach()

add_custom_command(
    OUTPUT  ${OUTPUT_SOURCES_C}
    COMMAND ${PROTOC_C} --c_out=${PROTO_C_OUT} --proto_path=${PROTO_PATH} ${PROTO_SOURCE_FILES}
    DEPENDS ${PROTO_SOURCE_FILES}
    WORKING_DIRECTORY ${PROTO_PATH}
    COMMENT "Generate C Protobuf Source Files"
)1

add_custom_command(
    OUTPUT  ${OUTPUT_SOURCES_CXX}
    COMMAND ${PROTOC_CXX} --cpp_out=${PROTO_CXX_OUT} --proto_path=${PROTO_PATH} ${PROTO_SOURCE_FILES}
    DEPENDS ${PROTO_SOURCE_FILES}
    WORKING_DIRECTORY ${PROTO_PATH}
    COMMENT "Generate Cpp Protobuf Source Files"
)

add_custom_target(
    compile_c_protos
    DEPENDS ${OUTPUT_SOURCES_C}
)
add_custom_target(
    compile_cxx_protos
    DEPENDS ${OUTPUT_SOURCES_CXX}
)

# 设置生成源文件包含目录变量供上层引用
set(PROTO_GEN_C_INCLUDE_DIRS ${PROTO_C_OUT} PARENT_SCOPE)
set(PROTO_GEN_CXX_INCLUDE_DIRS ${PROTO_CXX_OUT} PARENT_SCOPE)

# 将生成的文件打包为库 proto_gen_c
# 程序可以链接到该库
add_library(proto_gen_c	${OUTPUT_SOURCES_C})
target_link_libraries(proto_gen_c protobuf-c)
add_dependencies(proto_gen_c compile_c_protos)

add_library(proto_gen_cxx ${OUTPUT_SOURCES_CXX})
target_link_libraries(proto_gen_cxx protobuf)
add_dependencies(proto_gen_cxx compile_cxx_protos)

在项目主 CMakeLists.txt 中，如下引用：

1
2
3

add_subdirectory(proto)
include_directories(${PROTO_GEN_C_INCLUDE_DIRS})
include_directories(${PROTO_GEN_CXX_INCLUDE_DIRS})

在需要使用 proto 的目标 CMakeLists.txt 脚本中，只需要目标链接 proto_gen_cxx 或 proto_gen_c 即可。

Nuklear 界面库使用

Fri, 01 May 2020 00:00:00 +0000

Nuklear 是一个 C 编写的、只有头文件的 GUI 界面库，也是 imgui 类的界面实现工具，支持多种渲染后端，包括 gdi/gdi+/D3D/X11/Xft/SDL/opengl 等，特别适合跨平台和工具软件的界面实现。

Nuklear 其实核心是实现了基于2D绘图的界面控件绘制以及交互事件处理，而底层的渲染和用户操作事件处理，则由使用的后端来实现。Nuklear 实现了大部分常用控件，包括 label、button、radio、checkbox、edit、slider、chart 等，但没有提供常用对话框比如 MessageBox 和 FileDialog（毕竟控件都只是绘制）。

下图是一个样例代码实现的界面，源码托管在 GitHub 上。其中使用了 tinyfiledialogs 来实 MessageBox 和 FileDialog 对话框功能。

Nuklear 的文档都包含在头文件里，接口和样例齐全，WIKI 里也有部分控件的使用样例代码，这里说一些使用时的注意点：

Nuklear 的界面在每一帧中都会重新绘制，所以没有其他界面库的事件循环和回调，通常实现一些功能需要在代码里保存一些状态。
Nuklear 的控件布局是基于行的，建议多看一下头文件中关于 layout row 的说明和示例。
Nuklear 支持多 window，这些 window 都在同一个系统窗口内。
可以自定义界面控件的外观，具体参见样例代码中的 style.c 文件。
推荐使用 gdp+(win) 和 xft(linux)后端，其他后端多数需要携带字体文件，如果需要显示中文，部署需要携带字体，如果只是英文，nuklear 自带了一块字体。
所有后端的实现代码可以参见 Nuklear 仓库的示例。
tinyfiledialogs 库使用后部署无依赖，win 上基于 comdlg32 和 ole32，linux 是基于命令行调用的窗口。需要注意的是，在程序中调用对话框后会阻塞已有的 Nuklear 程序。
Nuklear 支持在 window 中直接进行2D绘图，主要是调用 nk_window_get_canvas() 后使用自带的绘图函数进行绘制操作，需要注意的是坐标处理（建议使用 nk_window_get_content_region() 获取窗口范围）。

每个工具都有应用的长处和短处，Nuklear 适合快速原型、工具小软件或者编辑器，但并不适合实现复杂的、侧重用户交互的程序，在实际中有时也需要权衡。

PS: 在 Linux 上需要屏幕录制时，推荐软件 peek。

CORS 中继程序

Wed, 01 Apr 2020 00:00:00 +0000

随着 CORS 全国一张网的运行，类似千寻这样的网络差分在实际运用中越来越普遍。这里开源一个可以中继重分发已有 CORS 服务的程序 cors-relay.

cors-relay 是为了解决现有 CORS 服务的一些限制性，就像 README 文档中提到的，cors-relay 就是针对以下需求场景开发的：

源 CORS 的服务重分发以及高效利用。使用多个源 CORS 帐号建立帐号池，然后使用 cors-relay 创建多用户，在保证源 CORS 帐号安全的情况下，重分发 CORS 服务。这么做，可以将包月包年的源 CORS 服务以灵活的服务期限进行分发（包天，包周，甚至几个小时）。同时，因为用户一般不会同时进行连接，那么可以进行超量分发，类似于飞机票的“超卖”。
同地区的差分广播。利用 cors-relay 客户端差分数据复用的特性，可以利用 1 个 CORS 帐号，实现地区的无限制差分数据服务，覆盖范围可以达到1000平方公里（30km x 30km）。
源 CORS 的安全分享。在不失去已有 CORS 帐号的安全控制前提下，提供新的用户名密码分发已有 CORS 服务给第三方。

现有的 CORS 服务，比如千寻，官方渠道都只提供包年包月的帐号，但在测绘施工实际使用中，由于项目进度或者天气原因，RTK 测量并不是连续的密集的使用，多数测量人员都希望有包天的服务，这样投入更少，也更灵活。利用 cors-relay 进行池化，可以重分发灵活期限的 CORS 服务，成规模后怎会大幅减少帐号购买的费用。

多人同地区作业也是如此，以往的电台作业中，一个基准站可以覆盖50KM以内的移动站需求。但现在，每个移动站都需要一个 CORS 帐号来进行作业，本来可以共用差分数据源的，却要付出成倍的成本。cors-relay 可以复用相近的差分源，覆盖同一地区只需要一个源 CORS 帐号。

cors-relay 是基于之前开源的 ntripcaster 项目开发的，期间也经历过实际运用测试。

目前 cors-relay 也有一些需要改进的地方，在 README 里也有提及，不过暂时可能没有太多时间花在这上面。

(完)

U盘Linux系统在任何PC上启动

Wed, 15 Jan 2020 00:00:00 +0000

将系统安装在U盘中随身携带使用已经很容易了，比如 Windows 就有 Windows To Go。将系统装在U盘上需要一个寿命长久的U盘，而且随机读写性能要强。

Linux 发行版都提供 Live ISO 镜像，也可以将系统直接装载 U盘上，但很多时候安装后的U盘可以在安装的 PC 上启动，换一个 PC 就无法启动了。这篇文章就讲述如何解决其他 PC 上启动的问题。

这里只考虑 UEFI 模式的启动，毕竟都2020年了。

安装后无法在其他 PC 上正常启动的原因，是 UEFI 启动的文件一般都会安装在 PC 的内部硬盘上，而不是目标U盘上。

解决方法：

安装前，在U盘上新建一个大于300MB的FAT32格式的 ESP 分区。
启动 Linux 发行版，安装系统到 U盘上。推荐根 / 和主目录 /home 分别挂载在不同的U盘分区。
安装后进入PC主系统，如果是windows，推荐使用 DiskGenus 打开PC硬盘的 ESP 分区，拷贝 EFI\xxx\ 目录（xxx 一般为发行版名称，Debian 为 debian，Ubuntu 为 ubuntu），复制到 U盘的 ESP 分区 EFI 目录下（没有则新建），并重命名 xxx 为 boot。主系统非 Linux 可以使用 PE 启动盘操作。
重命名 U盘 ESP 分区下 EFI\boot 目录的 grubx64.efi 文件为 bootx64.efi 。

完成以上步骤后，将U盘插在其他PC上，在 UEFI 模式下，手动选择启动盘为U盘，则可以顺利进入U盘Linux系统。

如果想在U盘上安装多个系统，可以考虑使用 refind 来代替 grub 进行启动管理，即将 refind 拷贝到U盘 ESP 分区下 EFI\boot 目录下，并重命名 refind_x64.efi 文件为 bootx64.efi。refind 会在启动时搜索所有可启动的 EFI 系统，提供用户选择。

(完)

一个基于 libev 的 ntripcaster 简单实现

Thu, 08 Aug 2019 00:00:00 +0000

Ntripcaster 是测绘领域GNSS相关的服务器软件，服务于差分GNSS测量、RTK测量等高精度测量测绘。

这里开源一个基于 libev，用 C 实现的简单 ntripcaster 服务器。

Ntripcaster 是基于 Ntrip协议的 broker 程序，给 Ntrip Client 传输所请求的 GNSS 差分数据，接受来自 Ntrip Server 产生的差分数据来源。网络图例如下：

|--------|          |--------|         |--------|
| Ntrip  | <------> | Ntrip  | <------ | Ntrip  |
| Client |          | Caster |         | Source |
|--------|          |--------|         |--------|

libev 是一个 C 实现的跨平台事件库，支持 IO、定时器、文件状态监控等等，特别适合用来写网络服务程序，其接口也简洁好用。

简单实现的 Ntripcaster 源码： https://github.com/lazytinker/ntripcaster

预编译的二进制可执行文件（linux/windows）：https://github.com/lazytinker/ntripcaster_bin

目前支持的功能：

支持 Ntrip 1.0 协议，支持动态源列表(source tables)。
支持 linux 和 windows(MinGW 编译)。
支持用户名密码验证，支持多用户、多源单独密码管控。
至此后同用户客户端多连接。

目前不支持的功能：

VRS虚拟站。
根据客户端GGA提供最近站差分数据。
动态用户名密码增减支持。

除了 VRS，其他功能添加也比较简单，只不过暂时没有什么动力去完善，编写这个程序主要还是为了 libev 的练手。有什么问题，可以与我联系。

(完)

交叉编译 LCM 库

Wed, 27 Feb 2019 00:00:00 +0000

LCM (Lightweight Communications and Marshalling)是一个基于 UDP 网络的消息传递库，适合高带宽和低延迟的通信需求，模式为发布/订阅。

本文讲述如何交叉编译 LCM 库到 arm linux上。

LCM 依赖 glib 2.0 库，glib 又依赖 zlib/libffi，所以需要依次编译依赖的库。如果目标平台 rootfs 中已有这些库，那么则可以直接最终的 LCM。

需要的源码包

根据目标 arm 平台不同，需要修改后面脚本命令中的 HOST 变量定义，用来指定交叉编译器:

armel: arm-linux-gnueabi
armhf: arm-linux-gnueabihf
aarch64(arm64): aarch64-linux-gnu

交叉编译器编译器可以通过 apt-get install crossbuild-essential-??? 来安装，具体后缀与目标 arm 平台一致。

0. 环境变量配置

以下为编译环境配置，需要在终端中执行，并且之后的编译命令也需要在该终端中执行。

export HOST=arm-linux-gnueabihf      # 不同平台需要修改变量
export ROOTFS="~/dev_rootfs/${HOST}" # 指定编译文件存放根目录
export CFLAGS="-L${ROOTFS}/usr/local/lib -I${ROOTFS}/usr/local/include"
export CC=${HOST}-gcc
export AR=${HOST}-ar
export NM=${HOST}-nm
export LD=${HOST}-ld
export STRIP=${HOST}-strip
export RANLIB=${HOST}-ranlib
export PREFIX=${ROOTFS}/usr/local

1. 编译 zlib/libffi

以下为编译 zlib 和 libffi 的命令，使用配置过环境变量的终端进入源码目录执行。

# 注意：
# 编译 zlib  不需要 --host 参数
# 编译 libffi 需要 --host 参数
./configure --prefix=${PREFIX} --host=${HOST}

make 
make install

这里需要注意 libffi 的头文件会安装到 ${ROOTFS}/usr/local/lib 目录中，需要手动移动到 ${ROOTFS}/usr/local/include 目录里，否则编译 glib 时会提示找不到头文件。

2. 编译 glib

编译 glib 2.0，如果本机架构不是 x86_64，则需要修改 --build 参数项。

MN=nm ./configure --prefix=${PREFIX} \
   --build=x86_64-linux \
   --host=${HOST} \
   glib_cv_stack_grows=no \
   glib_cv_uscore=no \
   ac_cv_func_posix_getpwuid_r=yes \
   ac_cv_func_posix_getgrgid_r=yes \
   ac_cv_lib_rt_clock_gettime=no \
   glib_cv_monotonic_clock=yes \
   --enable-libmount=no \
   --with-pcre=internal

make 
make install

3. 编译 LCM

编译 LCM，需要使用 cmake 工具。

cmake .. -DCMAKE_CROSSCOMPILING=true \
         -DCMAKE_C_COMPILER=${HOST}-gcc \
         -DCMAKE_CXX_COMPILER=${HOST}-g++ \
         -DCMAKE_FIND_ROOT_PATH=${ROOTFS}/usr/local/ \
         -DCMAKE_INSTALL_PREFIX:PATH=${ROOTFS}/usr/local/ \
         -DLCM_ENABLE_TESTS=OFF \
         -DCMAKE_BUILD_TYPE=Release

make
make install

备注：编译 LCM 也可以使用 cmake toolchain 文件，这样更简洁方便。

编译完成后将头文件/库文件保存到交叉编译rootfs中，即可用来交叉编译应用程序，将动态库文件复制到目标 arm 板子上的 /usr/lib 或 /usr/local/lib 中(需要使用 ldconfig 命令刷新动态库缓存)，即可用来运行程序。

关于 nng/nanomsg 库的一点想法

Fri, 22 Feb 2019 00:00:00 +0000

NNG/nanomsg 是最近项目上使用到的一个通信库，用来实现进程间过程调用和线程间通信，很是方便。

NNG 是 nanomsg 的继任版本，而 nanomsg 则是流行的 ZMQ 的 C 重写版。

NNG 将通信使用的协议和传输分离，同一个协议可以工作在不同的传输层上，类似与 TCP/IP 的应用层和传输层的分层，同时接口上屏蔽了底层细节，统一用字符串 URL 来描述传输模式。这样当使用场景修改时，可以通过简单修改 URL 来实现适应，极具灵活性。

同时如 NNG 描述所言 “light-weight brokerless messaging”，NNG 中的通信各方是不需要第三方程序介入的，这与 MQTT/Redis 通信需要服务器不同。这样很适合作为通信库来使用而没有其他依赖。

NNG 支持的通信协议主要有以下几种：

PAIR 一对一双向通信。
PIPELINE(PUSH/PULL) 单向通信，类似与生产者消费者模型的消息队列。
PUB/SUB 单向广播。
REQ/REP 请求-应答模式，类似与 RPC 模式。
BUS 网状连接通信，每个加入节点都可以发送/接受广播消息。
SURVEY 用于多节点表决或者服务发现。

NNG 支持的传输模式主要有以下三种常用，其他还有tcp附加tls 1.2加密的tls传输和基于WebSocket的ws传输：

inproc 进程内线程间传输
ipc 主机内进程间传输
tcp 网络内主机间传输

通信协议里除了 PAIR 之外，基本都是一对多的通信模式，这点需要注意，以 PIPELINE 和 PUB/SUB 为例：

PIPELINE 的 PUSH 端是 client，一个 PUSH 可以连接多个 PULL 端，发送数据时会选择其中一个可用的发送；PULL 端是 server，一个 PULL 可以接收多个 PUSH 连接和数据。
PUB/SUB 的 SUB 端是 client，一个 SUB 可以连接多个不同的 PUB 端，接收多个 PUB 端广播的数据；PUB 端是 server，一个 PUB 可以接收多个 SUB 连接并广播数据。

基于以上，多个程序是没办法共用一个 PUB/SUB 通道来广播数据的，这与 ROS 里的 topic 和 LCM 中的 channel 模式不同。如果要实现类似功能，则可以使用 PIPELINE + PUB/SUB 来处理：

独立一个话题发布的程序，拥有一个 PULL 和 PUB。
PULL 约定一个 URL，所有需要发布该话题的程序都 PUSH 数据到该 URL 上。
PUB 约定一个 URL，所有需要获取该话题的程序都 SUB 到该 URL 上。
程序内部循环将 PULL 读取的数据发送到 PUB 上。

以上则可以模拟出 ROS topic 数据合并或者 LCM 中 channel 的类似功能。

整体上看，NNG 的 API 很简约，主要是 4 个，open/recv/send/close，open 根据协议不同使用的函数会不同。配置则是 setopt/getopt，与 UNIX API 类似。API 中没有上下文环境（context-less）依赖，只需要一个 nng_socket，这种设计和实现方法值得去学习一下（初步揣测应该是使用指针值作为handle，如果要强制编译器做类型检测，则会套上一层 struct，如 typedef struct { _nng_xxx_socket * p } nng_socket;）。

NNG 协议基本上囊括了常见的通信需求，一些特殊的需求，也可以通过组合协议来实现，比如上面的模拟 ROS topic 或者 LCM channel 的方法。这样一来，如果在程序中使用 NNG，不管是多进程，还是多线程，通过设计，可以进一步增强模块化，同时不乏灵活性。如果环境变化，程序不管是由多进程改成多线程，还是由多线程改成多主机，都很容易实现。

常见模块/进程/线程间通信，可以依据具体需求来使用 PIPELINE（消息队列）还是 REQ/REP（过程调用），而不是锁+全局变量，每个模块单元只需要做单一相关的具体事务，无需知晓全局状态。

Python tkinter GUI 中调用 shell 脚本

Wed, 25 Jul 2018 00:00:00 +0000

本文给出一个 Python tkinter GUI 程序中调用 shell 脚本的代码示例，在 GUI 的一个文本框中会不断输出脚本的标准输出和标准错误且不会阻塞 GUI 窗体事件响应，同时也会在脚本执行完毕后根据状态（exit code）弹出提示框，如果在脚本运行中关闭窗口，会弹出提示并中断脚本的执行。

这个样例很适合编写一些提供给非技术人员使用的小工具。

代码如下，略长，使用的是 python 3，因为依赖 select 的原因，仅测试过 linux 下的使用，非 Posix 系统不能保证功能正常。代码也适合调用其他 console 程序，而不仅限于 shell 脚本。

#!/usr/bin/env python3
# -*- coding:utf-8 -*-

import tkinter
from tkinter import messagebox, scrolledtext
import subprocess
import select
import os
import signal

WINDOW_SIZE = "600x400"

# Run Button
btn_upd = None
# Output textbox
txt_out = None
# current script job/process
cur_process = None
# mark if Tk is closing
close_flag = False
# Tk root
root = tkinter.Tk()


def disable_allbtn():
    global close_flag
    global btn_upd
    if close_flag:
        return
    btn_upd.configure(state=tkinter.DISABLED)

def enable_allbtn():
    global close_flag
    global btn_upd
    if close_flag:
        return
    btn_upd.configure(state=tkinter.NORMAL)

def cb_runbash_withoutput(script):
    global cur_process
    global txt_out
    global root
    global close_flag
    # clear output
    txt_out.delete(1.0, tkinter.END)
    # create subprocess
    process = subprocess.Popen(script, shell=True, preexec_fn=os.setsid,
        stderr=subprocess.PIPE, stdout=subprocess.PIPE)
    # read subprocess stderr/stdout in non-blocking
    outpoll = select.poll()
    errpoll = select.poll()
    outpoll.register(process.stdout, select.POLLIN)
    errpoll.register(process.stderr, select.POLLIN)
    # store current subprocess
    cur_process = process
    while True:
        output = ""
        errput = ""
        # poll stdout, timeout 2ms
        if outpoll.poll(2):
            output = process.stdout.readline().decode()
            # insert stdout to txt_out
            if output and not close_flag:
                txt_out.insert(tkinter.INSERT, output)
        # poll stderr, timeout 2ms
        if errpoll.poll(2):
            errput = process.stderr.readline().decode()
            # insert stderr to txt_out
            if errput and not close_flag:
                txt_out.insert(tkinter.INSERT, errput)
        # scroll text if have output
        if (output or errput) and not close_flag:
            txt_out.see(tkinter.END)
        # do eventloop when not closing
        if not close_flag:
            root.update()
        # process end
        if output == "" and process.poll() is not None:
            break
    # get process return code
    code = process.poll()
    # reset current subprocess
    cur_process = None
    return code

# callback 函数
def cb_update():
    global close_flag
    disable_allbtn()
    code = cb_runbash_withoutput("./bash_script_sample.sh")
    # exit when closing
    if close_flag:
        return
    if code != 0:
        messagebox.showerror(title="Error", message="run bash script failed")
    else:
        messagebox.showinfo(title="Info", message="run bash script success")
    enable_allbtn()


def on_closing():
    global cur_process
    global root
    global close_flag
    # if cur_process still running
    if cur_process:
        if messagebox.askokcancel("Quit", "There is task running, do you want to quit?"):
            # kill subprocess
            os.killpg(os.getpgid(cur_process.pid), signal.SIGTERM)
            cur_process = None
        else:
            return
    # mark closing
    close_flag = True
    # close window
    root.destroy()

root.title("Hello world")
root.geometry(WINDOW_SIZE)
# register cloing event callback
root.protocol("WM_DELETE_WINDOW", on_closing)

btn_upd = tkinter.Button(root, text="Update", command = cb_update)
btn_upd.pack(fill=tkinter.X, pady=10)

txt_out = scrolledtext.ScrolledText(root)
txt_out.pack(fill=tkinter.BOTH, expand=True, padx=20, pady=20)

tkinter.mainloop()

核心是使用 subprocess 调用 console 程序，然后在 GUI callback 中不断读取程序的 stdout/stderr，同时不阻塞 GUI 事件循环。

在 CMake C\C++ 项目中使用 Git 仓库版本号

Thu, 05 Jul 2018 00:00:00 +0000

为了便于自动化版本管理，在C\C++项目中通常会考虑使用 Git 标识的版本作为程序版本号，本文介绍如何在 CMake 构建的项目中加入此项功能支持。

核心思路是，利用 CMake 调用 Git 命令获取仓库版本状态，然后将信息输出到一个头文件中，程序需要使用版本信息的，包含头文件并使用对应宏即可。

CMakeLists.txt 例子如下

cmake_minimum_required(VERSION 2.8)
project(Foo)

find_package(Git)
# 生成版本描述字符串类似 TAG-X-gHASH
execute_process(COMMAND ${GIT_EXECUTABLE} describe --abbrev=6 --dirty --always --tags
    WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}
    OUTPUT_VARIABLE  GIT_REPO_VERSION
    OUTPUT_STRIP_TRAILING_WHITESPACE
)
# 获取最新 commit 日期，YYYY-MM-DD
execute_process(COMMAND ${GIT_EXECUTABLE} log -1 --format=%cd --date=short
    WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}
    OUTPUT_VARIABLE  GIT_REPO_DATE
    OUTPUT_STRIP_TRAILING_WHITESPACE
)
# 获取最新 commit Hash
execute_process(COMMAND ${GIT_EXECUTABLE} log -1 --format=%H
    WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}
    OUTPUT_VARIABLE  GIT_REPO_HASH
    OUTPUT_STRIP_TRAILING_WHITESPACE
)
# 写入头文件宏定义的版本字符串，日期和 Hash
file(WRITE ${PROJECT_BINARY_DIR}/repo_version.h
    "#define REPO_VERSION \"${GIT_REPO_VERSION}\"\n#define REPO_DATE \"${GIT_REPO_DATE}\"\n#define REPO_HASH \"${GIT_REPO_HASH}\"\n"
)
# 包含引用目录，源文件可以直接用 #include "repo_version.h" 包含
include_directories(${PROJECT_BINARY_DIR})

aux_source_directory(. SRC)
# 添加头文件依赖，保证更改后重新编译
add_executable(foo ${SRC} ${PROJECT_BINARY_DIR}/repo_version.h)

程序示例代码如下：


#include <stdio.h>
#include "repo_version.h"


int main(int argc, char** argv)
{
    printf("version: %s\n", REPO_VERSION);
    printf("date: %s\n", REPO_DATE);
    printf("hash: %s\n", REPO_HASH);
    return 0;
}

如果项目小，可以不使用头文件方式，而是直接在 CMake 传入宏定义。宏定义方法不适合中大型项目，因为每次都会导致项目重编译，编译时间又长，影响效率。

Linux Shell Tips

Mon, 16 Oct 2017 00:00:00 +0000

适用于桌面以及嵌入式 Linux 环境脚本编程。

1. 串口操作

配置串口模式（波特率 9600, 数据位 8 位，停止位 1 位，无校验）：

`1`	`stty -F /dev/ttyS0 9600 cs8 -cstopb -parenb`

具体可以通过 man stty 来了解其他配置。

按行读取串口文本：

cat /dev/ttyS0 | while read line
do
    # do somehing with $line
    echo "$line"
done

2. 数值操作

整数变量累加可以参考以下示范：

count=0
echo $count     # => 1

let count+=1
echo $count     # => 2

计算平均数可以参考以下示范：

# 计算数值列平均数
# 文件 data.txt 存放如下文本
# 31 41 59
# 26 53 58
# 97 93 23
# 

# 过滤空行
data=$(cat data.txt | sed '/^\s*$/d')
# 计算列和 以及 列平均数
echo "$data" | awk '{ c1+=$1; c2+=$2; c3+=$3 } END { printf "sum=%d, %d, %d\navg=%f, %f, %f\n", c1, c2, c3, c1/NR, c2/NR, c3/NR}'

# => sum=154, 187, 140
#    avg=51.333333, 62.333333, 46.666667

3. 字符串处理

字符串变量使用时尽量用双引号包含起来。

去除空白符（Strip Whitespace)：

1
2
3

a=" ab cde fg "
a=$(echo "$a" | xargs)
echo "^$a$"  # => ^ab cde fg$

字符串判断：

empty=""
ok="ok"
hello="hello"

# 判断字符串为空
if [ -z "$empty" ]; then
        echo "Empty String"
fi
# => Empty String

# 判断字符串非空
if [ -n "$hello" ]; then
        echo "Non-empty String"
fi
# => Non-empty String

# 判断字符串相等
if [ "$ok" = "ok" ]; then
        echo "OK"
else
        echo "FAIL"
fi
# => OK

# 判断字符串不等
if [ "$ok" != "ok" ]; then
        echo "Not Same"
else
        echo "Same"
fi
# => Same

apt源arm gcc交叉编译器注意事项

Wed, 13 Sep 2017 00:00:00 +0000

做嵌入式 Linux 开发时候都需要使用交叉编译工具，这些一般是方案厂商提供，但我们通常也可以使用那些打包好的通用交叉编译工具，比如 Debian 上 apt 也有打包好的 arm 交叉编译工具： gcc-arm-linux-gnueabi 和 gcc-arm-linux-gnueabihf，对应 c++ 版本以 g++ 开头，这两类主要区别在于 CPU 对于浮点的处理上，涉及到 armel 和 armhf 架构的区别，详情参照这里，你只需要选择对应开发板的架构工具即可。

由于是 Debian 自己维护更新的包，上述的两个交叉编译工具通常都会更新比较频繁，会支持最新的标准和特性，但是我们的开发板上系统通常都不是最新的，所以在使用时需要注意，否则会出现编译后的程序无法在开发板上运行。

最近在将 mruby 应用到嵌入式环境时就遇到这个问题。

问题和溯因

将静态链接了 mruby 库的测试程序 mirb 放入嵌入式环境上运行时，提示

`1`	./mirb: /lib/libc.so.6: version `GLIBC_2.16' not found (required by ./mirb)

嵌入式环境没有 2.16 版本以上的 glibc 库，但是理论上测试程序不需要这么高版本的 glibc 库。在嵌入式命令行上用 ldd （有些嵌入式环境可能没有附带这个工具）查看一下可执行文件信息：

#ldd -v mirb
./mirb: /lib/libc.so.6: version `GLIBC_2.16' not found (required by ./mirb)
        libm.so.6 => /lib/libm.so.6 (0x401ed000)
        libc.so.6 => /lib/libc.so.6 (0x40293000)
        /lib/ld-linux.so.3 (0x401c4000)

        Version information:
        ./mirb:
                libm.so.6 (GLIBC_2.4) => /lib/libm.so.6
                libc.so.6 (GLIBC_2.7) => /lib/libc.so.6
                libc.so.6 (GLIBC_2.16) => not found

                libc.so.6 (GLIBC_2.4) => /lib/libc.so.6
        /lib/libm.so.6:
                ld-linux.so.3 (GLIBC_PRIVATE) => /lib/ld-linux.so.3
                libc.so.6 (GLIBC_2.4) => /lib/libc.so.6
        /lib/libc.so.6:
                ld-linux.so.3 (GLIBC_2.4) => /lib/ld-linux.so.3
                ld-linux.so.3 (GLIBC_PRIVATE) => /lib/ld-linux.so.3

可执行程序 mirb 的确引用 2.16 版本的 glibc 库，那就继续查一下引用了 2.16 版本 glibc 库的哪些符号。

在开发主机（不需要在嵌入式主机中）上可以使用 objdump 工具查看可执行程序的符号表（参数 -t）：

1
2

$ objdump -t mirb | grep 2.16
00000000       F *UND*	00000000              timespec_get@@GLIBC_2.16

可以看出是 timespec_get 这个函数符号需要 2.16 版本的 glibc 库，那么就得在代码中查一下哪个地方调用了这个函数。

在这里可以看出 mruby 源码的 time.c 文件中使用了 timespec_get 函数：

  tm = (struct mrb_time *)mrb_malloc(mrb, sizeof(*tm));
#if defined(TIME_UTC)
  {
    struct timespec ts;
    if (timespec_get(&ts, TIME_UTC) == 0) {
      mrb_free(mrb, tm);
      mrb_raise(mrb, E_RUNTIME_ERROR, "timespec_get() failed for unknown reasons");
    }
    tm->sec = ts.tv_sec;
    tm->usec = ts.tv_nsec / 1000;
  }
#elif defined(NO_GETTIMEOFDAY)

宏定义 TIME_UTC 控制着代码是否调用 timespec_get 函数。

通过搜索了解到，TIME_UTC 和 timespec_get 都是 C11 标准里定义的。由于在编译 mruby 时没有指定编译参数，交叉编译工具使用了默认参数导致 C11 标准也被支持，mruby 库也就使用了最新的 C11 标准，引用了新函数 timespec_get，产生了 glibc 2.16 版本的依赖。

解决方法

在知晓原因后，解决方法就简单了。就是在交叉编译 mruby 库时，去指定编译标准（c标准），修改 mruby 的编译配置文件 build_config.rb ：

conf.cc do |cc|
    cc.command = "arm-linux-gnueabi-gcc"
    cc.flags << "-std=gnu99"
end

将编译 c 标准指定为 gnu99（-std=gnu99），这里也可以使用 c99 标准（-std=c99）。

然后重新编译测试程序，放到嵌入式环境上运行，OK。

结语

使用编译器尤其是交叉编译器时，最好要指定编译参数，确定编译标准，否则目标平台可能不支持，导致程序无法运行。在向第三方提供开发库而不是源码的情况下，需要特别注意，尽量使用统一的编译参数标准，推荐 c99 或者 gnu99。

在遇到类似 /lib/libc.so.6: version GLIBC_X.XX not found 问题时，可以借助 ldd 和 objdump 工具来确定依赖的符号源，寻找解决方法。

CMake 项目模块化布局

Sun, 06 Aug 2017 00:00:00 +0000

在 C\C++ 项目中，通常会有不止一个可执行程序，或者需要将一些调用封装成动态或静态库，来实现项目的模块化，本文就讲解一种支持这种项目布局的方法。

CMake 支持子目录构建（add_subdirectory 指令），本文介绍的布局方法就是基于这个功能来实现。

项目

项目根目录编写一个 CMakeLists.txt，主要描述项目名称，也可以将一些项目级别的配置写入，来影响所有项目构建目标。比如编译的警告级别设置，如果要在项目级别上统一，可以写入，如果要针对不同构建目标来设置，可以留到构建目标 CMakeLists.txt 文件中写入。

项目的各个构建目标作为子目录存放在项目根目录下，每个子目录均包含相应的构建 CMakeLists.txt 文件。使用 add_subdirectory 指令将构建目标子目录添加到项目 CMakeLists.txt 中，构建目标间可以相互引用，只要在添加子目录到项目 CMakeLists.txt 时保持依赖顺序即可。

项目 CMakeLists.txt 示例：

cmake_minimum_required(VERSION 2.6)

# 项目名称
set(PROJECT_NAME "TestApps")
project(${PROJECT_NAME})

# 统一构建目标输出目录
# 将所有构建目标输出目录定位在构建目录下，按类型分类子目录
#     静态库输出目录 => 构建目录/lib
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${PROJECT_BINARY_DIR}/lib)
#     动态库输出目录 => 构建目录/bin
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${PROJECT_BINARY_DIR}/bin)
#     可执行程序输出目录 => 构建目录/bin
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${PROJECT_BINARY_DIR}/bin)

# ---------- 库 ----------
# staticlib 库
add_subdirectory(staticlib)
# 添加头文件搜索路径，这样其他构建目标可以引用其头文件
include_directories(staticlib)

# sharelib 库
add_subdirectory(sharelib)
# 添加头文件搜索路径，这样其他构建目标可以引用其头文件
include_directories(sharelib)

# ---------- 应用程序 ----------
# testapp 程序
add_subdirectory(testapp)

# 配置文件类
add_subdirectory(config)

项目 TestApps 中包含4个构建目标目录，2 个库 staticlib 和 sharelib，依赖库的 1 个应用程序 testapp，以及配置文件类目标 config。4 个目标的输出文件均统一到了构建目录下，按类型分类，这样便于构建结果的归档处理。

通常将构建目标子目录名与目标名一致，这样便于项目管理。

目标

每个构建目标对应在项目根目录下的各个子目录，每个子目录中都有一个 CMakeLists.txt 文件，记录着对应的构建配置。这些构建配置均会继承项目 CMakeLists.txt 文件中的配置。

以下针对示例项目，讲解各个子目录的 CMakeLists.txt ，用以理解如何进行具体的项目布局。

目标 `staticlib`（静态库编译示例）：

# 编译选项
add_definitions("-std=gnu99")
add_definitions("-Wall")

set(SLIB "staticlib")
aux_source_directory("." SLIB_SRC)
add_library(${SLIB} STATIC ${SLIB_SRC})
# 依赖库
target_link_libraries(${SLIB} m)

add_library 指令添加一个库目标，参数 STATIC 表示编译成静态库，该目标链接时需要链接数学库。

目标 `sharelib`（动态库编译示例）：

add_definitions("-std=gnu99")
add_definitions("-Wall")

set(DLIB "sharelib")
aux_source_directory("." DLIB_SRC)
add_library(${DLIB} SHARED ${DLIB_SRC})

与目标 staticlib 差不多，只是add_library 参数 SHARED 表示编译成动态库。

目标 `testapp`（执行程序编译示例）：

# 编译选项
add_definitions("-std=gnu99")
add_definitions("-Wall")

set(APP "testapp")
aux_source_directory("." APP_SRC)
add_executable(${APP} ${APP_SRC})
target_link_libraries(${APP}
        staticlib
        sharelib)

add_executable 指令添加一个可执行目标，其依赖于静态库 staticlib 和动态库 sharelib。

目标 `config`（配置文件示例）：

# 拷贝文件到输出目录，便于后续打包安装文件
file(COPY .
    DESTINATION ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}
    # 忽略文件匹配模式
    PATTERN "CMakeLists.txt" EXCLUDE
    PATTERN "README.md" EXCLUDE
    )

config 目标是一个特殊目标，其不构建库或可执行程序，而是执行一个文件拷贝工作，在此示例中，将 config 目录下的文件（除 CMakeLists.txt 和 README.md）都拷贝到可执行输出目录中。这个用法一般用于拷贝程序的默认配置文件。这样做的好处在于可以将默认配置文件纳入版本管理，也方便打包程序以及测试部署，既能将代码与输出分离，又能实现自动化整合。

结语

CMake 是一个很便利的跨平台构建工具，使用模块化布局方法可以更契合多人共享开发模式，促进项目复用代码，方便上下游库协同管理。如果与 Git 的 submodule 配合，就更能体现出模块化。

Shell中高效分割字符串

Wed, 11 Jan 2017 00:00:00 +0000

通常来说，使用 shell 脚本时候不需要太顾及程序的效率性，能完成任务，只要不是太慢，都可以接受。

但在一些特定应用场合，脚本效率也是一个硬性限制，不能耗时太久，比如说，用 shell 来编写一些处理 HTTP 请求的 CGI 程序，脚本的执行效率直接影响了 HTTP 的响应速度。

在 shell 中分割字符串有多种方法，比如利用 awk、cut 工具，还有内置方法，虽然效果相同，但是执行效率差距较大，尤其在处理大数据量上更是显著。

用 cut 工具分割字符串一般是以下用法：

1
2

# -f 指定列序号 -d 指定分隔符
echo $line | cut -f1 -d ' '

用 awk 工具分割字符串类似：

1
2
3

# $1 代表第一列 以此类推
# -F 指定分割符号
echo $line | awk -F ' ' {'print $1'}

内部方法分割字符串，用的是 IFS 变量和 set 命令：

# 设置分隔符
IFS=" "
# 分割 line
set -- $line
# $1 代表第一列，以此类推
echo $1

在 shell 脚本中，使用 awk/cut 这些工具在运行时会创建 sub-shell 来运行，相当于 C 语言中的 system/popen 调用，当需要使用的次数比较多时，这种调用会显著降低脚本的执行速度（创建进程是比较昂贵的）。

而使用内置方法则无需调用外部工具，执行起来效率更高，没有额外开销。

以处理 1000 行的空格分割的数字并分别累加为例，其文件内容大概如下：

1    25   30  100
2    26   33  102
3    27   36  104

...

999  1023 3024 2096
1000 1024 3027 2098

保存为文件 test.data。然后编写2个测试脚本，split1.sh 和 split2.sh。

split1.sh内容如下：

#!/bin/sh

DataFile="test.data"

if [ ! -e $DataFile ]; then
	echo "Fail to open file"
	exit 1
fi

F1=0
F2=0
F3=0
F4=0
# 设置分割符
IFS=" "

while read line
do
	[ -z "$line" ] && continue
	set -- $line

	F1=$((F1+$1))
	F2=$((F2+$2))
	F3=$((F3+$3))
	F4=$((F4+$4))
done < $DataFile

echo "F1=$F1"
echo "F2=$F2"
echo "F3=$F3"
echo "F4=$F4"

split2.sh文件内容如下：

#!/bin/sh

DataFile="test.data"

if [ ! -e $DataFile ]; then
	echo "Fail to open file"
	exit 1
fi

F1=0
F2=0
F3=0
F4=0
IFS=" "

while read line
do
	[ -z "$line" ] && continue
	l1=$(echo $line | cut -f1 -d ' ')
	l2=$(echo $line | cut -f2 -d ' ')
	l3=$(echo $line | cut -f3 -d ' ')
	l4=$(echo $line | cut -f4 -d ' ')

	F1=$((F1+$l1))
	F2=$((F2+$l2))
	F3=$((F3+$l3))
	F4=$((F4+$l4))
done < $DataFile

echo "F1=$F1"
echo "F2=$F2"
echo "F3=$F3"
echo "F4=$F4"

split1.sh使用内置方法，split2.sh使用 cut 工具来处理。在 shell 中运行程序并用 time 命令监控执行时间，会发现速度对比特别显著。

以本人测试电脑为例，内置方法执行输出如下：

$ time ./split1.sh
F1=500500
F2=524500
F3=1528500
F4=1099000

real	0m0.045s
user	0m0.024s
sys	0m0.020s

$ time ./split2.sh
F1=500500
F2=524500
F3=1528500
F4=1099000

real	0m4.603s
user	0m0.004s
sys	0m0.736s

粗略看出执行速度相差 100 倍左右。

备注：因为要获取各列数据累加，所以在脚本2中，使用了4次 cut 调用，相当于字符串分割了4此，而脚本1中只使用了一次字符串分割，这种策略也显著增加了执行开销。可以通过使用数组返回 cut 结果来避免多次调用，但是这得看 shell 环境是否支持，某些情况下是不支持数组的，比如 busybox 的 sh 环境。

（完）

Freescale Yocto 编译自定义 Linux 系统镜像

Mon, 29 Aug 2016 00:00:00 +0000

Yocto Project 是一个开源的协作软件，提供模板、工具和方法帮你创建定制的 Linux 系统和嵌入式产品，而无需关心硬件体系。适合嵌入式Linux开发人员使用。

下面来以 Freescale 的 i.MX6UL 开发板为例，详细叙述如何搭建 Yocto 环境以及 Linux 镜像的定制编译和烧录。

1. Freescale Yocto环境搭建

Yocto 需要一个 Linux 主机环境，可以通过搭建虚拟机来实现，发行版推荐 Ubuntu/Debian，其他主流发行版也可以。

如果通过虚拟机来搭建 Linux 环境，那么请注意分配足够的硬盘空间用来 Yocto 编译，推荐 100GB 以上。

这一节内容可以参阅 Freescale Yocto Project Main Page.

1.1 安装 Yocto 依赖包。

针对 Ubuntu/Debian 系统，可以使用如下命令安装所需要的包：

`1`	`sudo apt-get install gawk wget git-core diffstat unzip texinfo build-essential chrpath libsdl1.2-dev xterm curl`

其他发行版可以参照此链接来安装依赖包。

1.2 下载 Freescale BSP 包

下载 Freescale 的板载支持包，Yocto 已经内置在包内。

这一小节内容可以参阅 FSL Community BSP.

下载 BSP 包需要 repo 工具，首先安装 repo 工具:

1
2
3

mkdir ~/bin
curl https://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
chmod a+x ~/bin/repo

备注：如果因为 GFW 的原因无法下载 repo，那么可以通过修改 hosts 文件来绕过：

# 也可以通过访问项目 https://github.com/racaljk/hosts 手动下载
curl https://raw.githubusercontent.com/racaljk/hosts/master/hosts > ~/hosts
# 请勿直接覆盖 /etc/hosts，否则会影响 apt-get 工具的使用
sudo cat ~/hosts >> /etc/hosts

下载 BSP 源码：

PATH=${PATH}:~/bin
mkdir fsl-community-bsp
cd fsl-community-bsp
repo init -u https://github.com/Freescale/fsl-community-bsp-platform -b jethro
repo sync

这一步会下载大量数据，完成后 Yocto 所需要的所有元数据已经齐备。

2. 镜像编译及自定义配置

现在已经可以编译 Linux 镜像了，以默认提供的 core-image-minimal 镜像配置为例：

`1`	`source ./setup-environment build`

这条命令用于初始化编译环境，其中 build 为指定的编译目录，也可以使用其他目录来当做编译目录。

编辑 build 目录下的 conf/local.conf 文件，指定开发板型号和配置并行编译参数：

1
2
3

MACHINE ?= "imx6ulevk"
BB_NUMBER_THREADS = "4"
PARALLEL_MAKE = "-j 4"

根据实际情况来配置，如果主机 CPU 核心数更多，可以将并行编译参数修改为 8.

备注：这里也可以使用图形化的工具 hob 而不是手动修改来指定开发板型号和其他配置， hob 可以输入命令 hob 启动。

编译 core-image-minimal 镜像，这是一个预定义的 Linux 系统镜像：

`1`	`bitbake core-image-minimal`

编译过程中会下载所有需要的包的源码，编译过程比较耗时，也会占用不少硬盘空间。

2.1 自定义配置

上面编译的是预定义的镜像，但在实际应用中，我们一般会希望能自定义镜像配置，比如添加去除一些组件，修改系统的设置等等。这一小节就来讲讲如何通过添加 Yocto Layer 来实现我们需要的自定义配置。

这一小节内容可以参阅 Yocto part III – a custom meta layer.

这里以添加一个自定义 Layer foobar 为例，并进行一些配置修改来说明自定义配置的一般方法。

1) 自定义 layer 镜像

切换到 fsl-community-bsp/sources 目录，使用命令添加一个 meta-foobar layer:

`1`	`yocto-layer create foobar`

命令提示一路回车确认即可。

添加完空 layer 后，在 meta-foobar 目录下，用如下命令创建目录树：

`1`	`mkdir -p recipes-foobar/images`

在新创建的目录下，创建一个 foobar-image.bb 文件，文件内容填写如下：

`1`	`require recipes-core/images/core-image-minimal.bb`

意思是我们以 core-image-minimal 为模板，给 foobar layer 添加了一个镜像目标，后续对镜像的自定义配置也是针对此镜像目标来操作，而不是直接去修改预定义的 core-image-minimal。

如果要编译 foobar 的镜像，切换到 build 编译目录下，并修改 conf/bblayers.conf 文件，按照已有的格式，将我们创建的 meta-foobar layer 添加到 BBLAYERS 变量中。

输入如下命令进行镜像编译：

`1`	`bitbake foobar-image`

2) 修改 busybox 配置

Busybox 是一个很有用的组件，提供了很多系统工具，但是默认并不激活所有工具，我们也要根据情况来激活/禁用某些工具(比如激活 telnetd)。

使用如下命令来进行 busybox 的图形化配置:

`1`	`bitbake -c menuconfig busybox`

根据界面提示和实际需要来进行配置操作。

使用如下命令来输出配置变更内容：

`1`	`bitbake -c diffconfig busybox`

保存路径设置为 ~/busybox.conf

在 meta-foobar 路径下创建目录树 recipes-core/busybox/files，将 busybox.conf 文件复制到此目录下保存。然后，在 recipes-core/busybox 目录下，创建文件 busybox_%.bbappend 文件，文件内容填写如下：

1
2

FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
SRC_URI += "file://busybox.cfg"

重新编译 foobar-image，这样我们自定义的 busybox 配置就生效了。

从这里可以看出，如果我们要修改一个 Yocto 自带的一个组件，那么我们就通过添加 layer，同时使用相同的 recipes 路径配合 bbappend 文件，来对默认的配置进修改即可。(bbappend 文件名中的 % 符号是版本号的占位符)

3) 修改默认系统名

Linux 系统名是由 sources/poky/meta/recipes-core/base-files/ 下的 base-files_3.0.14.bb 文件控制的，那么我们通过添加对应的 bbappend 文件来进行配置。

在 meta-foobar layer 路径下创建目录树 recipes-core/base-files，并在目录下创建 base-files_%.bbappend 文件，文件内容如下：

`1`	`hostname = "foobar"`

这样子就修改了默认系统名为 foobar。

4) 修改 root 默认密码

修改 root 密码、添加用户，可以参考链接：FAQ:How do I set or change the root password.

修改 recipes-foobar/images/foobar-image.bb 文件，添加如下代码：

1
2

inherit extrausers
EXTRA_USERS_PARAMS = "usermod -P 123456 root;"

其中 123456 即为设置的 root 密码。

备注：如果要使 root 密码生效，需要修改 build 目录下的 conf/local.conf 文件，注释掉 EXTRA_IMAGE_FEATURES = "debug-tweaks 这个选项。

5) 修改 sshd 默认配置

sshd 提供 ssh 登录服务，但是默认配置下不允许 root 进行登录，默认也不允许密码验证，在实际使用中并不方便（方便也意味这安全隐患），要允许 root 以密码验证方式登录，可以使用如下方法修改。

sshd 组件的默认配置保存在 recipes-connectivity/openssh/openssh 路径下的 sshd_config 文件中，允许 root 登录是由选项 PermitRootLogin 控制，允许密码验证是由选项 PasswordAuthentication 控制，我们看到这两项默认被注释掉了。

要修改此配置，我们要在 meta-foobar 下创建目录树 recipes-connectivity/openssh/files，并将默认的 sshd_config 文件复制一份到此目录下，并取消 PermitRootLogin yes 和 PasswordAuthentication yes 的两行注释。

然后在目录 recipes-connectivity/openssh 下创建 openssh_%.bbappend 文件，内容如下：

`1`	`FILESEXTRAPATHS_prepend := "${THISDIR}/files:"`

这样子我们修改过的 sshd_config 文件配置会覆盖默认配置。

6) 修改默认时区

如果不修改，默认编译的系统镜像，时区设置的是 UTC 时区，通常我们想修改为当地时区，比如中国为 PRC 时区。

时区组件配置由 recipes-extended/tzdata/tzdata_2016e.bb 文件中的 DEFAULT_TIMEZONE 来控制。

我们在 meta-foobar 下创建目录树 recipes-extended/tzdata，并在目录下创建 tzdata_%.bbappend 文件，内容如下：

`1`	`DEFAULT_TIMEZONE = "PRC"`

这样就将默认时区设置为中国。

以上 1-6 就详细叙述了常见的配置修改，修改模式基本都是通过自定义的配置去覆盖默认配置实现，用 bbappend 文件去调整默认配置，而不是直接去修改默认配置文件。

3. 镜像的烧录

编译的镜像都存放在 tmp/deploy/images 下，针对 SD 卡的镜像为 sdcard 或 sdcard.gz 结尾的文件(gz 文件需要解压后烧录)。

在 linux 环境下，可以使用如下命令来烧录镜像到 SD 卡中：

`1`	`sudo dd if=foobar-image-xxx.sdcard of=/dev/sdb`

在 Windows 上，可以使用 USB Image Tool 来烧录镜像。

需要注意的是，Yocto 默认编译生成的镜像只占用 SD 卡上的一个小分区，如果想让系统使用全部的 SD 卡空间，需要使用工具来调整。这里推荐使用 GParted 工具的 resize/move 功能，此工具为图形化工具，非常方便。

GParted 安装:

`1`	`sudo apt-get install gparted`

GParted 运行：

`1`	`sudo gparted`

（完）

32feet.net 蓝牙虚拟串口编程

Fri, 27 May 2016 00:00:00 +0000

Windows 上的蓝牙编程并不方便，由于操作系统并没有提供统一的蓝牙操作接口，通常是由各个蓝牙设备商提供蓝牙栈，所以要想编程兼容这些不同的厂商蓝牙是一个问题。好在有个软件项目 32feet.NET 针对主流蓝牙协议栈提供了支持，包括 Microsfot, Widcomm, BlueSolei 等，同时还支持红外传输协议。

蓝牙虚拟串口是一个较为常见的需求，为了兼容已有使用串口设备的程序，需要将蓝牙连接转为系统上的虚拟串口，然后提供给其他程序或库使用。32feet.NET 对此也提供了支持。

32feet.NET 依赖 .NET 3.5 版本以上框架，支持 Windows 桌面版本、Wndows CE 以及 Windows Phone。

安装

如果使用 Visual Studio 2015 或者安装有 NuGet 工具的，可以直接通过 NuGet 安装。在 NuGet 命令行中输入

`1`	`Install-Package 32feet.NET`

这样 NuGet 会自动下载安装并添加到当前 .NET 项目中。可以检查项目 References 项，如果存在 InTheHand.Net.Personal 则表明已成功加入到项目中，如果没有，可以手动添加引用，NuGet 下载存放在 SolutionName\packages\32feet.NET.x.x.x.x\ 路径下。

使用

下面主要讲解 32feet.NET 的使用，覆盖蓝牙搜索、配对、直接连接以及虚拟串口服务。

1. 检测系统蓝牙可用性

如果系统没有蓝牙设备或者蓝牙设备被禁用，那么可以通过以下函数来进行检查：

/* 定义于类 BTHelper 中 */
public static bool IsPlatformSupportBT()
{
    BluetoothClient bc;
    try
    {
        bc = new BluetoothClient();
    }
    catch (PlatformNotSupportedException)
    {
        return false;
    }
    bc.Close();
    return true;
}

如果系统不支持蓝牙设备，那么 new BluetoothClient 会抛出 PlatformNotSupportedException 异常，通过捕获这个异常，来检测系统蓝牙设备可用性。

2. 蓝牙搜索

BluetoothClient 对象有个方法 DiscoverDevices 用于搜索蓝牙设备，该方法有多个重载版本，最终都是调用如下这个接口：

`1`	`public BluetoothDeviceInfo[] DiscoverDevices(int maxDevices, bool authenticated, bool remembered, bool unknown, bool discoverableOnly);`

第一个参数表明搜索的最大设备数，第二个参数表示是否搜索已配对设备，第三个表示是否搜索记住的设备，第四个表示是否搜索未知设备，第五个参数表示是搜索范围内可被发现的设备。

这里面重要的是第二和第五个参数，第二个代表搜索系统中已配对列表中的设备，即使它们现在并不在线。第五个参数 XP 系统上不支持，表示搜索范围内可被发现的设备。

如果我们需要获得系统中已配对列表中的蓝牙设备，可以这样调用 DiscoverDevices(255, true, false, false)，这里使用了4个参数的重载版本，只将第二个参数置为 true。

如果我们需要搜索周围环境中可用的蓝牙设备，可以这样调用 DiscoverDevices(255, false, false, false, true)，这个调用等同于 DiscoverDevicesInRange()。

需要注意的是，这个调用是同步阻塞的，在搜索没有结束之前函数不会返回。所以通常我们需要将这个调用放入工作线程中。例外的是，如果只是获取系统中已配对列表中的设备，这个调用会很快完成，不会占用当前线程太多时间。

库中同时提供了一个异步搜索方法，由类 BluetoothComponent 提供，由事件 DiscoverDevicesProgress 和事件 DiscoverDevicesComplete 以及方法 DiscoverDevicesAsync 来实现。这个和用 BackgroundWorker 来实现 DiscoverDevices() 异步查找是一样的。

PS: 可以通过 VS 的 Object Browser 查看 InTheHand.Net.Personal 库中的函数接口说明，说明非常翔实。

3. 检测蓝牙设备是否在范围内

当需要检查一个蓝牙设备是否在有效范围内，可以通过查询一个 Fake Service ID 来实现。

如果蓝牙设备在范围内可访问，那么查询的结果是返回的服务记录为空，表示不支持此服务；如果蓝牙设备不在范围内，那么会抛出套接字异常。

以下为检测代码：

/* 定义于类 BTHelper 中 */
public static bool TestingIfInRange(BluetoothAddress addr)
{
    bool inRange = false;
    Guid fakeUuid = new Guid("{F13F471D-47CB-41d6-9609-BAD0690BF891}");
    BluetoothDeviceInfo device = new BluetoothDeviceInfo(addr);

    try
    {
        ServiceRecord[] records = device.GetServiceRecords(fakeUuid);
        Debug.Assert(records.Length == 0, "Why are we getting any records? len: " + records.Length);
        inRange = true;
    }
    catch (SocketException)
    {
        inRange = false;
    }
    return inRange;
}

需要注意的是，因为蓝牙设备通信需要时间，所以这个调用也需要较长时间才能完成，未完成之前进入阻塞不返回，所以这个方法也需要放入工作线程中执行。

这部分内容可以参考官方文档： Tesing if a device is in rage.

4. 蓝牙设备配对

蓝牙配对功能由类 BluetoothSecurity 的静态方法 PairRequest(BluetoothAddress device, string pin) 提供，其中第一个参数是目标设备地址，第二个参数是用于配对的 Pin 码。配对成功返回 true，失败返回 false。

解除配对是 BluetoothSecurity.RemoveDevice(BluetoothAddress device) 。

配对操作也需要将长时间完成，所以这个方法也需要放入工作线程中执行。

5. 蓝牙直接连接

如果不需要蓝牙虚拟串口而直接读写蓝牙数据，那么可以使用直接连接，这个可以参照官方文档：General Bluetooth Data Connections.

通过直接连接获取一个可读写的 System.IO.Stream 流对象，就可以直接对蓝牙进行读写数据操作了。以下为官方样例中的代码

BluetoothAddress addr = BluetoothAddress.Parse("001122334455");
Guid serviceClass;
serviceClass = BluetoothService.SerialPort;
// - or - etc
// serviceClass = MyConsts.MyServiceUuid
//
var ep = new BluetoothEndPoint(addr, serviceClass);
var cli = new BluetoothClient();
cli.Connect(ep);
Stream peerStream = cli.GetStream();
// peerStream.Write/Read ...

6. 蓝牙虚拟串口

这部分讲解如何实现将蓝牙连接转为系统上的虚拟串口并获取串口名，还可以参阅官方文档： Bluetooth Serial Ports.

首先需要说明的是，虚拟串口和直接连接数据读写不能同时使用，如果已经使用了其中一个方法进行读写，那么另外的一个方法会失败。

生成虚拟串口需要将蓝牙设备服务设置为 BluetoothService.SerialPort，官方样例代码如下：

BluetoothAddress addr = BluetoothAddress.Parse("123456789012");
BluetoothDeviceInfo device = new BluetoothDeviceInfo(addr);  // Or from discovery etc
bool state = true;
device.SetServiceState(BluetoothService.SerialPort, state, true);

SetServiceState 的第一个函数表示服务标识，第二个表示要设置的服务状态，true 为启用， false 为禁用，第三个参数表示如果设置失败是否抛出异常。

但在实际使用中，某些双模蓝牙在设置时，虽然设置成功但是依然会抛出 Win32Exception 异常，所以这里建议调用此函数的重载版本 SetServiceState(System.Guid service, bool state)，而想要知道是否设置成功，下面会介绍其他方法来获得。

这个方法调用并不会告诉我们新生成的串口名，官方文档中的建议是通过设置前后的系统串口列表差异来获取新生成的串口名，而获取系统串口列表则可以调用静态方法 SerialPort.GetPortNames。

但是不建议用这个方法来获取虚拟串口名，因为这个不可靠而且容易出错，下面介绍另外一个可靠方法，而且这个方法也可以同时告诉我们设置虚拟串口服务是否成功。

获取蓝牙虚拟串口名

这部分参阅官方文档：Getting Virtual COM Port Names for Remote Bluetooth Devices.

蓝牙虚拟串口在系统中都有记录，我们可以通过检索这个记录，来找到所设置的设备的虚拟串口名，同时也可以得知我们的蓝牙虚拟串口是否设置成功。

通过调用 WMI 查询，可以枚举出系统中每个串口的详细信息。这里可以通过 PowerShell 来查询：

`1`	`C:\> Get-WmiObject -query "select DeviceID,PNPDeviceID from Win32_SerialPort"`

输出样例（其中 COM66 对应的蓝牙设备地址为 00803A686519）：

DeviceID     : COM66
PNPDeviceID  : BTHENUM\{00001101-0000-1000-8000-00805F9B34FB}\7&1D80ECD3&0&00803A686519_C00000003

......

可以看出蓝牙虚拟串口的 PNPDeviceID 是以 BTHENUM 开头，并且会将蓝牙地址存放其中。

这个查询也可以通过 C# 代码实现：

using System.Management;

const string Win32_SerialPort = "Win32_SerialPort";
SelectQuery q = new SelectQuery(Win32_SerialPort);
ManagementObjectSearcher s = new ManagementObjectSearcher(q);
foreach (object cur in s.Get()) {
    ManagementObject mo = (ManagementObject)cur;
    object id = mo.GetPropertyValue("DeviceID");
    object pnpId = mo.GetPropertyValue("PNPDeviceID");
    console.WriteLine("DeviceID:    {0} ", id);
    console.WriteLine("PNPDeviceID: {0} ", pnpId);
    console.WriteLine("");
}//for

综上，我们可以定义一个函数，这个函数通过 WMI 检索所有串口设备信息，然后返回一个 Hashtable，其中存储的键为蓝牙设备地址，存储的值为串口名。

函数定义如下：

/* 定义于类 BTHelper 中 */
public static Hashtable QueryBTHPorts()
{
    const string Win32_SerialPort = "Win32_SerialPort";
    SelectQuery q = new SelectQuery(Win32_SerialPort);
    ManagementObjectSearcher s = new ManagementObjectSearcher(q);

    Hashtable hashResult = new Hashtable();
    foreach (object cur in s.Get())
    {
        ManagementObject mo = (ManagementObject)cur;
        string id = mo.GetPropertyValue("DeviceID").ToString();
        string pnpId = mo.GetPropertyValue("PNPDeviceID").ToString();
        Debug.WriteLine("WMI>>DeviceID: " + id);
        Debug.WriteLine("WMI>>PNPDeviceID: " + pnpId);
        Debug.WriteLine("");

        /* 仅处理蓝牙串口 */
        if (pnpId.StartsWith("BTHENUM"))
        {
            /* 从 PNPDeviceID 中提取出蓝牙地址，策略是逆序字符串  & 后 _ 之前 */
            /* 蓝牙地址为6字节，HEX为12位字符 */
            int rBound = pnpId.LastIndexOf('_');
            int lBound = pnpId.LastIndexOf('&');
            Debug.Assert(rBound - lBound == 13, "Get BT Addr, this will nevery happened.");
            string addr = pnpId.Substring(lBound + 1, 12);
            if (!hashResult.Contains(addr))
            {
                hashResult.Add(addr, id);
            }
            else
            {
                Debug.WriteLine("Get BT Addr, addr" + addr + " has more than 1 ports");
            }
        }
    }

    return hashResult;
}

同样，WMI 检索也比较耗时，所以这个函数调用需要放入工作线程中执行。

有了这个函数，我们可以通过结果中查找我们设置的蓝牙设备地址，就可以得知对应的虚拟串口名，而如果结果中没有我们设置的蓝牙设备地址，那么就可以认定设置虚拟串口服务失败了。

样例代码

这里介绍通过配合使用 BackgroundWorker 来实现蓝牙设备的配对、生成虚拟串口的样例代码：

我们通过传入蓝牙设备地址给 worker，worker 在 DoWork 中帮我们处理所有步骤，过程中报告进度，并最终告诉我们结果。

worker 的 DoWork 事件代码：

/* 进行蓝牙连接操作的后台线程执行函数 */
/* 传入 蓝牙地址字符串 作为参数 */
/* 利用 ReportProgress 报告进度 */
/* 利用 DoWorkEventArgs.Result 报告状态 */
void bgworkerConnection_DoWork(object sender, DoWorkEventArgs e)
{
    BackgroundWorker worker = sender as BackgroundWorker;
    string args = e.Argument as string;
    string finalportname = "";

    do
    {
        BluetoothAddress addr = BluetoothAddress.Parse(args);
        BluetoothDeviceInfo deviceinfo = new BluetoothDeviceInfo(addr);

        /* 检测设备是否在服务范围内，有些设备能被发现但不能被配对连接（如果已经被其他终端配对连接） */
        /* 不在范围内则报告错误信息 */
        worker.ReportProgress(10, "Testing if device in range...");
        if (!BTHelper.TestingIfInRange(addr))
        {
            string msg = string.Format("Error: Device {0}({1}) is not reachable!",
                    deviceinfo.DeviceName,
                    deviceinfo.DeviceAddress.ToString());
            e.Result = msg;
            return;
        }

        worker.ReportProgress(10, "Device is in range.");

        /* 检测设备是否是已配对设备 */
        if (deviceinfo.Authenticated)
        {
            /* 已配对设备枚举系统蓝牙串口，检测是否已绑定虚拟串口 */
            worker.ReportProgress(10, "Querying Bluetooth serialport...");
            Hashtable bthTable1 = BTHelper.QueryBTHPorts();
            if (bthTable1.ContainsKey(addr.ToString()))
            {   /* 获取绑定串口 */
                finalportname = bthTable1[addr.ToString()] as string;
                /* !!! 跳出 !!! */
                break;
            }
            /* 此处 else 需考虑枚举结果中没有绑定串口的处理，如果没有绑定串口，那么重新设置串口服务 */
            /* 此处 else 部分会在下面的流程处理，见下方设置串口服务部分 */
        }
        else /* 需要进行配对 */
        {
            worker.ReportProgress(10, "Start pairing...");
            if (!BluetoothSecurity.PairRequest(addr, "1234"))
            {  /* 配对失败 */
                string msg = string.Format("Error: Can not pair to Device {0}({1})!",
                        deviceinfo.DeviceName,
                        deviceinfo.DeviceAddress.ToString());
                e.Result = msg;
                return;
            }
        }

        /* 设置串口服务 */
        /* SLC蓝牙设置串口服务时，如果 SetServiceState */
        /* 第三个参数为 true (允许异常) 那么则一定会抛出异常，即使虚拟串口创建成功 */
        /* 所以这里调用2个参数的重载版本 */
        /* 之后检查串口服务是否设置成功的方法就是 设置后检索蓝牙串口 */
        worker.ReportProgress(10, "Enable serialport service...");

        deviceinfo.SetServiceState(BluetoothService.SerialPort, true);

        /* 枚举系统蓝牙串口，检查对应蓝牙是否有串口绑定 */
        Hashtable bthTable2 = BTHelper.QueryBTHPorts();
        if (bthTable2.ContainsKey(addr.ToString()))
        {
            /* 获取绑定的串口 */
            finalportname = bthTable2[addr.ToString()] as string;
            /* !!! 跳出 !!! */
            break;
        }
        else
        {   /* 启用串口服务失败或者无法检测到绑定串口 */
            string msg = string.Format("Error: Failed to set Serialport service for Device {0}({1})!",
                    deviceinfo.DeviceName,
                    deviceinfo.DeviceAddress.ToString());
            e.Result = msg;
            return;
        }

    } while (false);

    worker.ReportProgress(10, "Open serialport...");

    Debug.WriteLine(string.Format(">>PORT NMAE: {0}", finalportname));

    /* 成功 */
    /* 将串口名放入消息中返回 */
    string okmsg = string.Format("OK: {0}", finalportname);
    e.Result = okmsg;
}

代码中通过灵活使用 string 作为 Result 来表明执行结果。

worker 的 RunCompleted 事件代码：

void bgworkerConnection_RunCompleted(object sender, RunWorkerCompletedEventArgs e)
{
    string msg = e.Result as string;
    if(msg.StartsWidth("OK"))
    {   /* OK */
        MessageBox.Show(msg);
    }
    else
    {  /* Error */
        MessageBox.Show(msg);
    }
}

后续可以通过字符串处理提取出生成的串口名。

worker 的启动代码：

`1`	`bgworkerConnection.RunWorkerAsync(addrstring);`

这样子我们就获取到了绑定的虚拟串口名，但是在使用串口中要注意的是，虚拟串口打开过程中，本质上还是发起了一个蓝牙数据连接，所以打开过程会耗时较长，所以这个虚拟串口打开过程也需要放入工作线程中处理。如果虚拟串口对应的蓝牙设备没有在线或者其他原因造成不可用，那么打开时会抛出异常，需要在代码上进行处理。

一旦蓝牙设备经过绑定并且设置虚拟串口服务成功，那么对应的串口会一直存在与系统的串口列表中，但这并不代表它是可用的，请在打开这类串口时添加异常处理代码。

(完)

远程调试C#程序环境的配置

Thu, 26 May 2016 00:00:00 +0000

远程调试适用于需要在本机调试在其他 Windows 设备上运行的程序，典型的比如调试 Surface 上的程序。

目标 Windows 主机不具备安装 Visual Studio 开发环境条件的，也可以用远程调试来进行调试。

微软MSDN官方有文章讲解如何进行远程调试，链接：Remote Debugging。

下载安装远程调试工具

根据所使用的 Visual Studio 版本下载对应的远程调试工具，VS2015 版本的下载链接在此：Remote Tools for Visual Studio 2015。

远程调试工具根据架构分别有 x86，x64 和 ARM 版本，根据开发主机和调试目标设备的架构进行下载，注意下载版本需要与机器架构一致，即 x64 的机器必须安装 x64 版本的远程调试工具，不能使用 x86 版本的（在安装过程中会提示不支持）。

在开发主机上和调试目标设备上分别安装远程调试工具。

远程调试工具配置

远程调试需要开发主机和目标设备处于同一局域网、工作组或者家庭组。远程调试不能通过 Internet 连接。

1. 目标设备配置

首先，需要设置目标设备上的远程调试器。

运行目标设备上安装好的 Remote Debugger，首次运行会提示进行配置，按照默认配置就好，主要是添加防火墙例外，另外一点是是否将远程调试配置成服务，根据需要或者参照官方文章进行配置。

另外，我们需要在目标设备上添加一个账户，用于开发主机连接到目标主机上的 Remote Debugger。打开控制面板的用户帐户，新建一个普通账户，用户名为 debug，同时设置一个密码。

点击 Remote Debugger 的菜单项 Tools/Options，默认选中了 “Windows Authentication”，点击右侧的 “Permissions…” 按钮，进入权限设置对话框。点击 “Add” 手动输入 debug 账户名，添加 debug 账户的调试权限。同时需要设置一下 “Maximum idle time” ，这个是指 Remote Debugger 运行时的最大空闲时间，如果超过这个时间，Debugger 就会自动关闭，建议设置较长时间，比如 3600 (1小时)，否则可能需要频繁手动启动 Remote Debugger。

这样目标设备上的配置完成。

PS:

调试 .NET 程序只能使用 “Windows Authentication”，不支持 “No Authentication” 选项。
可能每次启动 Remote Debugger 都需要重新添加 “Permissions…” 账户。

2. 开发主机配置

然后，需要配置开发主机上的调试环境。

打开需要进行远程调试的工程，打开工程的 Properties 页面，选择 Debug 标签，勾选其中的 Use remote machine 选项，然后填写入目标设备的名称，这个名称可以打开目标设备的系统信息看到，VS 会自动在其后添加端口号。这里同样可以填写目标设备IP。此外确保 Working directiory 为空，下方 Enable native code debugging 未被选中。

这时候基本的远程调试就可以用了，但是我们需要在项目编译后将文件手动复制到远程主机上才能调试，这样很不方便（每次重新编译都需要重新复制）。官方文章中也没有提到如何实现自动部署。

我们可以使用 Windows 文件共享来解决这个问题。

启用开发主机上的 Guest 账户。进入控制面板/用户帐户，启用 Guest 账户，同时，进入控制面板/系统和安全/管理工具/本地安全策略，从左侧打开本地策略/用户权限分配，右侧找到拒绝从网络访问这台计算机，打开，然后删除掉 Guest 账户并保存。这样目标设备就可以通过局域网共享访问这台计算机的文件了。
在开发主机上新建一个 Shared 目录，右键设置共享，添加 Guest 账户为读取权限。
修改工程 Properties 页面，选择 Build 标签，修改下面 Output 的 Output path 路径为共享目录路径，注意这里的应该为 \\XXX\Shared\project_name\bin\Debug\， XXX 部分是开发主机的名称。这里不能直接使用本机的目录路径，否则目标设备无法访问。

启动项目调试，VS 会自动搜索目标设备名，如果找到则会提示输入认证用的用户名和密码，这里输入 debug 和用户密码即可。

这样就可以开始程序调试了。

中软统一终端加密文件解密

Mon, 23 May 2016 00:00:00 +0000

背景不提，通过搜索能看到这篇文章的，请彼此保持同情。

中软统一终端这个软件通过网内文件加密存储，使用时自解密，保证一个局部网络的资料安全性，防止泄漏，主要用于密级文档、源代码和工程图纸的管控。

听起来很高大上，但是在文件加密解密这条策略链上，漏洞是很多的，在具体部署上，漏洞就更多了。下面介绍一下如何利用策略漏洞解密被加密的文件，这里主要针对源代码，其他文档类似。

首先讲一下中软终端的文件加密解密过程。

加密解密过程

安装统一终端后，如果有加密策略部署，程序后台会扫描所有文件，判断文件后缀名或文件类型是否与策略一致来进行加密操作。

策略中通常会有针对加密文件类型相关软件的白名单，在这个名单中的程序，去处理加密的文件时，会透明地读取到解密后的文件，然后再保存该类型的文件时，文件又自动被加密了。如果白名单程序新生成该类型文件，那么文件保存时会自动被加密。

白名单程序的存在是为了保证日常操作，否则都不能用了岂不是因噎废食。

当某类文件被白名单程序读取时，中软终端会自动把加密的文件解密，然后提供给程序。中软是通过文件驱动来实现了这一中间人角色，来桥接加密文件和程序，对于非白名单程序则不提供解密，这样打开就会乱码报错。

策略的漏洞

这一套“透明地”加密解密的确很不错，但是停下想一想，尤其想一想互联网安全相关的实例，是不是有什么漏洞可破？

互联网安全相关通常都是这个问题：Can I trust you?

白名单是策略的关键，一个程序加入其中就表示对其可信，程序可以读取被加密的文件，这时候鉴权就很重要了。我们来根据实际来分析一下可能的鉴权策略：

最简单的，根据进程名来判定程序是否归属白名单中。这个方法最简单，也最灵活，部署也很方便，但是，只根据进程名会不会不大可靠？
进阶一点的，根据程序文件 Hash。在部署策略时，将可执行程序文件的 Hash 也加入其中，只有 Hash 匹配才认定程序是归属白名单中。这个是一个不错的方法，但是维护就很麻烦，因为很多程序经常会升级，这时候文件变了 Hash 也变了，策略就不得不更新，而对于一些离线机器得不到策略更新就更悲剧了。
在2的基础上，继续完善，使用程序数字签名验证。程序文件的 Hash 会变，但是经过数字签名那么就可以认定这的确是谁谁谁家的程序。这个方法在终端中应该是被用到的，但肯定不是全部，毕竟只有大公司软件产品才会进行数字签名，比如 word/ppt/excel，可执行程序都是签名过的。而在软件开发中，有相当多开源工具是不可能进行签名的。

通过上述分析，可以猜测中软终端使用了方法1和3，而方法1只根据进程名判定是一个可以被利用的漏洞，我们可以编写克隆程序来读取加密文件。

读取这边解决了，还需要考虑输出这环节。白名单程序保存文件时会进行加密，但是并不会加密所有文件。因为工具也可能用来处理不重要的事情，或者其他必须不能加密的地方，比如编译代码最终生成可执行程序，可执行程序不能被加密。而这部分通常是根据文件后缀名来判断是否需要被加密的。

所以我们写一个与白名单中同名的程序，读取文件内容并输出到一个不会被加密的格式即可。

例子代码

因为依赖程序进程名，所以用脚本在这里不合适，最简单可以用 C，一个简单的文件拷贝就可以

#include <stdio.h>
#include <stdlib.h>

int main(int argc, const char *argv[])
{
    FILE *fp;
    FILE *nfp;
    char buf[512];
    unsigned long read;

    if(argc != 2) {
        fputs("Invalid args count!\n", stderr);
        exit(1);
    }

    fp = fopen(argv[1], "rb");
    snprintf(buf, sizeof(buf), "%s.xxx", argv[1]);
    nfp = fopen(buf, "wb");

    if(fp == NULL) {
        fputs("File not exists!\n", stderr);
        exit(1);
    }
    if(nfp == NULL) {
        fputs("Can't create file!\n", stderr);
        exit(1);
    }

    while((read = fread(buf, 1, sizeof(buf), fp)) != 0) {
        fwrite(buf, 1, read, nfp);
    }

    fclose(fp);
    fclose(nfp);

    return 0;
}

这个程序接收一个参数，参数为文件名，然后输出一个源文件的拷贝，命名为原文件名 + “.xxx”，这里 “.xxx” 可以选别的易于识别而且不会被加密的就行。

然后根据我们要解密的文件类型（这里以源代码为例），我们可以知道白名单程序中会有哪些程序，比如 IDE 中的 Visual Studio(devenv.exe)， Android Studio(androidstudio.exe)，代码管理程序的 SVN(svn.exe)，等等。

这里以 SVN 作为例子，我们编译程序 gcc -o svn xxx.c，然后就生成了 svn.exe 程序。

在一台安装了统一终端并启用加密的机器上，拷贝 svn.exe 到被加密代码的根目录。现在我们需要批量来解密我们需要的文件。

用 Shift + 右键打开目录的命令行，然后输入 powershell 进入 PowerShell 执行环境，然后输入如下代码

`1`	`foreach($i in Get-ChildItem -Recurse -Include *.c) { .\svn $i.FullName }`

该代码表示遍历目录下所有（包括子目录，子子目录）以 .c 结尾的文件，然后对其执行 svn，也就是我们写的 svn.exe 程序，FullName 表示使用绝对路径。

该代码只是解密了所有 C 文件，如果需要解密其他文件，则需要再次输入并修改后缀名即可。

PS: 因为 Windows 对于 Powershell 脚本的安全限制，这里并不能写入脚本中用 Powershell 执行，必须手动输入执行。

最后，我们需要把解密的文件的文件名复原，这里使用脚本语言就比较容易了，例如 Ruby，写一个 rename.rb 放根目录然后执行即可：

1
2
3

Dir.glob("**/*.xxx") do |fname|
  File.rename(fname, fname.chomp(".xxx"))
end

结束

找出这种漏洞并不是有意为之，而是某些时候这样做反而效率干脆，臃肿的官僚管理和流程太折磨人了，本来这个系统被利用多数也是懒政造就，系统本身带来的负面影响已经盖过了积极意义。机器运行缓慢，加密导致的奇怪问题，开发部署环境不一致的 bug 等等等，而这其中，这个系统部署和维护不够专业及时也加重了消耗。

多点真诚，少点套路。机械依赖工具而不改变思维通常都是徒劳。

添加可执行程序到 Path 中

Thu, 28 Apr 2016 00:00:00 +0000

将一个程序加入到环境 Path 中，通常做法是将程序文件所在目录附加到系统或者用户的 Path 变量中，这样我们在任何路径下的命令行中，都可以调用该程序工作。大部分应用程序安装过程中的做法也是如此。

但是这样会将目录中的所有文件暴露到 Path 中，其中大部分是我们不需要用到的。这样做也增加了潜在 DLL Hell 隐患，比如同名不同版本 DLL 暴露到 Path 中低版本覆盖了高版本导致程序运行时异常。

最好的做法是，只将我们需要用到的 exe 文件加入到 Path 中，Windows 上也的确有这样的解决方法。

以 vim 为例。我们新建一个 vim.bat 文件，编辑文件加入以下代码：

`1`	`@"C:\Program Files (x86)\Vim\vim74\gvim.exe" %*`

将该文件保存到一个目录中，然后再将该目录加入到用户或系统 Path 变量中。这样，这个 vim.bat 就暴露到 Path 中，可以在命令行中随时调用了，调用名为 vim，即 .bat 文件的文件名。

@ 表示禁止调用的回显，"" 引号包含目标程序的完整路径（这样路径中允许有空白符），%* 表示将传递给 .bat 文件的参数原封不动的传递给目标程序。

我们可以在此目录下新建其他 bat 文件，来向 Path 中加入各种所需的程序（同时也可以自定义名称）。

PS: 其实如果打开 Ruby 的安装目录，我们就会发现，irb 和 gem 都使用了这种方法。

NDK 实例

Tue, 12 Apr 2016 00:00:00 +0000

本文通过编写一个算法类二进制库以及示例App应用来介绍NDK开发，重点是二进制库编写、编译以及自定义参数的传递。

1. Java层接口定义

在做so库之前，需要首先设计约定库的接口，包括实现哪些功能，具体函数以及接口参数等等，这也是Java层调用所使用的接口。

在这个例子中，我们准备实现一个算法库，其中实现2个函数，一个返回算法库版本号，另一个计算线段中点坐标，主要用来展示so库编写以及参数传递过程。如果有需要其他的接口实现，可以参照这两个函数来做。

要实现的接口文件 com/zhdgps/ts/TSMath.java，其中 tsmath 是要实现的so库名字。

package com.zhdgps.ts;

public class TSMath {
	static {
		System.loadLibrary("tsmath");
	}

	/* 获取版本信息 */
	public static native String getVersion();
	/* 计算两点连线中心点 */
	public static native TSCoord calcCenter(TSCoord a, TSCoord b);
}

System.loadLibrary 用来加载so库，static 表示这段代码要最先运行。

接口函数用 native 关键字修饰表明这是源生方法实现而不是 java 代码实现（JNI），在这里就是指在so库中实现的方法。

同时辅助用的 TSCoord 定义文件 com/zhdgps/ts/TSCoord.java。

package com.zhdgps.ts;

public class TSCoord {
	public double N;
	public double E;
	public double Z;
}

两个文件都放属于包 com.zhdgps.ts 。

2. so库C代码实现和编译

完成库接口设计后，下面介绍如何用C来实现接口对应的功能。

新建文件夹 tsmath，用于存放 so 库工程。在 tsmath 下新建子文件夹 jni （命名为jni 是 NDK 编译的需要）用于存放 so 库的源文件。

在 jni 文件夹下新建文件 tsmath.h、tsmath.c、algorithm.h、algorithm.c、Android.mk 以及 Application.mk 文件。

其中，tsmath.h 和 tsmath.c 是 so 库的实现文件，algorithm.h 和 algorithm.c 是实际算法实现，相对来说 tsmath.c 是 JNI 接口层，而 algorithm.c 则是实际的算法C代码。这样区分有助于代码逻辑分层，当然都写在 tsmath.c 中也是可行的。

Android.mk 和 Application.mk 是用于编译so库所需要的 ndk-build 脚本文件，后面会进行详细叙述。

2.1 算法实现（`Algorithm`）

Algorithm.h 文件内容：

#ifndef TS_ALGORITHM_H
#define TS_ALGORITHM_H

#ifdef __cplusplus
extern "C" {
#endif

typedef struct _TSCoord {
    double N;
    double E;
    double Z;
}TSCoord;

enum TSAlgo_ErrorCode {
    TSALGO_NOERROR,
};

int TSAlgo_CalcCenter(const TSCoord *a, const TSCoord *b, TSCoord *result);

#ifdef __cplusplus
}
#endif

#endif

头文件主要声明了一个计算中点的函数以及参数结构体类型，实现文件 Algorithm.c 内容如下：

#include "algorithm.h"

int TSAlgo_CalcCenter(const TSCoord *a, const TSCoord *b, TSCoord *result)
{
    result->N = (a->N + b->N) / 2;
    result->E = (a->E + b->E) / 2;
    result->Z = (a->Z + b->Z) / 2;

    return TSALGO_NOERROR;
}

如果有其他要实现的算法，都可以在这个模块内实现。此模块将被 JNI 接口层调用。

2.2 JNI 接口实现

JNI 接口部分是 so 库的核心，用于在 Java 调用和实际的 C/C++ 调用之间充当中间层。JNI 的实现有两种方法，一种是静态注册，一种是动态注册。

静态注册是指用 javah 工具来生成 C/C++ 头文件，获得正确的函数名。在运行时 JNI 按照指定规则的函数命名来调用对应的 C 函数。

动态注册是指在动态库模块被加载的时候，模块注册的函数功能到 JVM 中。在对应函数被调用时，JVM会按照指定的注册函数名去调用实际的函数。

静态注册生成的函数命名很长，而且如果要修改函数名，那么就要重新修改编译。静态注册的模块只有在被调用时才会被查找检查，如果函数命名有问题，会直接运行异常。

动态注册在向 JVM 注册函数时，可以指定函数名，在编写时可以使用自定义的函数命名，如果需要修改维护，则只需要修改注册时的命名即可。

NDK 推荐使用动态注册，在模块中定义 JNI_OnLoad 函数,此函数在模块被加载时（即System.loadLibrary）被调用，模块在此函数中注册所有函数。

综上，我们要在模块中实现3个主要函数：

/* 动态库加载时候被调用的方法，进行初始化并注册模块函数 */
JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved);
/* 对应 TSMath.getVersion */
JNIEXPORT jstring JNICALL native_get_version(JNIEnv *env, jobject thiz);
/* 对应 TSMath.calcCenter */
JNIEXPORT jobject JNICALL native_calc_center(JNIEnv *env, jobject thiz, jobject coorda, jobject coordb);

native_get_version 和 native_calc_center 即 TSMath 的 JNI 实现，函数参数和返回值也与之对应，每个函数的前两个参数 JNIEnv * 和 jobject 是 JNI 函数固定传入的参数。jstring 对应 Java 的 String，而自定义类对象均用 jobject 来对应，完整的 JNI 类型匹配可以参见 Primitive Types.

要实现动态注册，我们需要编写注册方法：

/* ------------------------------------------------------------- */
/* 方法注册资源表 */
static JNINativeMethod native_methods[] = {
    {"getVersion", "()Ljava/lang/String;", (void *)native_get_version},
    {"calcCenter", "(Lcom/zhdgps/ts/TSCoord;Lcom/zhdgps/ts/TSCoord;)Lcom/zhdgps/ts/TSCoord;", (void *)native_calc_center},
};
#define NATIVE_METHODS_COUNT (sizeof(native_methods)/sizeof(native_methods[0]))

/* 为某一个类注册方法 */
static int register_navtive_methods(JNIEnv *env,
                                    const char *classname,
                                    JNINativeMethod *methods,
                                    int methods_num)
{
    jclass clazz;
    clazz = (*env)->FindClass(env, classname);
    if(clazz == NULL) {
        return JNI_FALSE;
    }

    if((*env)->RegisterNatives(env, clazz, methods, methods_num) < 0) {
        return JNI_FALSE;
    }

    return JNI_TRUE;
}

/* 为所有类注册本地方法 */
static int register_natives(JNIEnv *env)
{
    /* 指定要注册的类名 */
    const char *classname = "com/zhdgps/ts/TSMath";
    return register_navtive_methods(env, classname, native_methods, NATIVE_METHODS_COUNT);
}

JNINativeMethod 是在 <jni.h> 中定义的结构体，用于存储要动态注册的函数信息。第一个成员是字符串，用以表示要注册的函数所使用的函数名。第二个成员是字符串，用以表示函数的参数和返回值接口(Type Signatures)，在这个字符串中，"()"内表示函数的参数类型，然后是函数的返回值类型，"()" 表示函数参数为空，而如果函数返回值为空，则用 "()V" 表示。 "Ljava/lang/String;" 表示为 java.lang.String，"Lxxx;" 是 xxx 类型的完整写法，包字段分隔用斜杠代替，比如 "Lcom/zhdgps/ts/TScoord;" 表示类型为 com.zhdgps.ts.TSCoord 。如果参数有多个，依次写出对应类型。Java 源生类型可以参考 Type Signatures.

在 register_natives 中，我们将这两个函数注册到了类 com/zhgps/ts/TSmath 中，这个类就是之前在 Java 层定义的 com.zhdgps.ts.TSMath。

下面继续 native_get_version 和 native_calc_center 两个函数的实现

#define TSMATH_VERSION  "v0.1 alpha"

JNIEXPORT jstring JNICALL native_get_version(JNIEnv *env, jobject thiz)
{
    return (*env)->NewStringUTF(env, TSMATH_VERSION);
}

native_get_version 比较简单，就返回一个版本文本字符串。这里需要注意的是，如果函数需要返回非ASCII的字符串，则不能直接使用 NewStringUTF，因为 JNI 使用了修改版的 UTF-8 编码，具体可以参考 Modified UTF-8 Strings.

/* 保存全局 TSCoord 的信息，便于后续检索成员 */
struct TSCoordJNIInfo {
    /* ICS 4.0 之后，jclass 可能会变化，所以在获取后，调用 NewGlobalRef 保存引用，然后就不再变化 */
    jclass cls;
    /* ID 一般不会变化 */
    jfieldID fid_n;
    jfieldID fid_e;
    jfieldID fid_z;
    jmethodID mid_init;
} g_tscoord_jni;

static int helper_init_tscoord_jniinfo(JNIEnv *env)
{
    jclass cls = (*env)->FindClass(env, "com/zhdgps/ts/TSCoord");
    jfieldID fid_n = (*env)->GetFieldID(env, cls, "N", "D");
    jfieldID fid_e = (*env)->GetFieldID(env, cls, "E", "D");
    jfieldID fid_z = (*env)->GetFieldID(env, cls, "Z", "D");
    jmethodID mid_init = (*env)->GetMethodID(env, cls, "<init>", "()V");

    /* ICS 4.0 之后保存全局引用需要调用此函数，后续需要解除引用，使用函数 DeleteGlobalRef */
    cls = (jclass)((*env)->NewGlobalRef(env, cls));
    g_tscoord_jni.cls = cls;
    g_tscoord_jni.fid_n = fid_n;
    g_tscoord_jni.fid_e = fid_e;
    g_tscoord_jni.fid_z = fid_z;
    g_tscoord_jni.mid_init = mid_init;

    return 0;
}

static jobject helper_new_tscoord(JNIEnv *env)
{
    jobject tscoord = (*env)->NewObject(env, g_tscoord_jni.cls, g_tscoord_jni.mid_init);
    return tscoord;
}

static TSCoord helper_get_tscoord(JNIEnv *env, jobject coord)
{
    TSCoord res_coord;

    jdouble n = (*env)->GetDoubleField(env, coord, g_tscoord_jni.fid_n);
    jdouble e = (*env)->GetDoubleField(env, coord, g_tscoord_jni.fid_e);
    jdouble z = (*env)->GetDoubleField(env, coord, g_tscoord_jni.fid_z);

    res_coord.N = n;
    res_coord.E = e;
    res_coord.Z = z;

    return res_coord;
}

static void helper_set_tscoord(JNIEnv *env, jobject coord, const TSCoord *source)
{
    (*env)->SetDoubleField(env, coord, g_tscoord_jni.fid_n, source->N);
    (*env)->SetDoubleField(env, coord, g_tscoord_jni.fid_e, source->E);
    (*env)->SetDoubleField(env, coord, g_tscoord_jni.fid_z, source->Z);
}

JNIEXPORT jobject JNICALL native_calc_center(JNIEnv *env, jobject thiz, jobject coorda, jobject coordb)
{
    TSCoord a, b, c;
    jobject obj;

    a = helper_get_tscoord(env, coorda);
    b = helper_get_tscoord(env, coordb);

    TSAlgo_CalcCenter(&a, &b, &c);

    obj = helper_new_tscoord(env);
    helper_set_tscoord(env, obj, &c);

    return obj;
}

我们定义了一个结构体 struct TSCoordJNIInfo 用于保存 Java 类 com.zhdgps.ts.TSCoord 保存在 JVM 中的信息，包括类句柄、各字段ID（N，E，Z）以及构造函数ID。这些信息到后面获取/设置类对象字段时会用到，用全局结构体保存这些信息是为了效率，对于 FieldID 和 MethodID 来说，一旦类初始化后就不再变化，如果每次需要获取类对象信息时都去调用 GetFieldID 和 GetMethodID ，会给 JVM 带来负担，而且代码也有冗余。这里需要注意的是类句柄，对于 ICS4.0 以后的安卓系统，内存中的句柄可能会因为内存整理而移动，这意味着类句柄是会变化的，需要使用函数 NewGlobalRef 来保证句柄不变。

函数 helper_init_tscoord_jniinfo 用于获取类信息，这个函数需要在 JNI_OnLoad 中调用，保证在函数被调用前初始化全局信息。

函数 helper_new_tscoord、 helper_get_tscoord 和 helper_set_tscoord 是定义的三个辅助函数，用于新建 TSCoord Java 对象、TSCoord Java 对象与 C 结构体互相转换。

如上，要获取一个类对象信息，依次需要使用 FindClass 来获取类句柄，然后通过句柄来获取各个字段的 FieldID，之后就可以通过这些字段 ID 来获取实际的值。com.zhdgps.ts.TSCoord 字段均为 double 所以使用 GetDoubleField 来获取字段值，如果有其他类型，可以以此类推。

函数 native_calc_center 的逻辑就比较简单了，通过转换对象，然后转为调用 Algorithm 中的算法，然后再将结果转换为 Java 对象返回。

函数注册的是在 JNI_OnLoad 函数中，此函数会在 so 文件被加载时由 Java 虚拟机调用。

/* System.loadLibrary 时调用，成功返回 JNI 版本，失败返回 -1
 *
 * 可在此函数中进行初始化等操作
 * */
JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved)
{
    JNIEnv *env = NULL;
    jint result = -1;

    if((*vm)->GetEnv(vm, (void **)&env, JNI_VERSION_1_4) != JNI_OK) {
        D_LOG("Get env failed!");
        return -1;
    }

    if(register_natives(env) != JNI_TRUE) {
        D_LOG("Register failed!");
        return -1;
    }

    /* 填充TSCoord JNI Info */
    helper_init_tscoord_jniinfo(env);
    D_LOG("Init TSCoord succ!");

    result = JNI_VERSION_1_4;
    return result;
}

2.3 编译 so 库

编辑 Android.mk 文件

LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)

# 架构
LOCAL_ARM_MODE := arm
# 模块名
LOCAL_MODULE := tsmath
# 模块编译源文件
LOCAL_SRC_FILES := tsmath.c algorithm.c
# 模块依赖的库，比如要使用 android log 库
LOCAL_LDLIBS := -llog

# 编译为动态库
include $(BUILD_SHARED_LIBRARY)

这个文件是用于 so 模块的编译，其中模块名为 tsmath，这样编译出的文件会自动加前后缀，输出为 libtsmath.so。源文件部分加上项目使用的所有 C 文件，头文件不必加入其中。如果有依赖的安卓库，则加到 LOCAL_LDLIBS 链接部分。

编辑 Application.mk 文件

`1`	`APP_OPTIM := release`

这里指定生成 release 版本的 so 库。如果这里如果需要生成其他平台库，则需要设置 APP_ABI 字段。比如要生成全平台，则添加一句 APP_ABI := all，这样会同时生成其他平台（x86 等）。

下载 NDK ，完成安装并设置好系统 Path 变量。下载地址 Android NDK.

在 jni 上一级目录 tsmath 下打开命令行，输入命令 ndk-build 进行编译，编译完成后的 so 文件自动会保存到 libs 目录下。

3. so 库的使用

下面来新建一个 Android 项目来测试一下 so 库。

使用 Android Studio 新建一个 Hello World 项目，这里可以设置项目命名空间为 com.zhdgps.ts 来方便后面的测试。在项目文件夹的 app/src/main 目录下，新建文件夹 jniLibs，然后复制 tsmath/libs 目录下的编译输出到该文件夹中，注意保留 so 库的目录结构，比如 arm 架构编译的为 jniLibs/armeabi/libtsmath.so。将 TSCoord.java 和 TSMath.java 文件复制到 app/src/main/java/com/zhdgps/ts 目录下。Android Studi 会自动将添加的文件加入到工程中。

修改 MainActivity.java 文件，在 onCreate 中添加测试代码

TSCoord a = new TSCoord();
a.N = 1.0;
a.E = 2.0;
a.Z = 3.0;

TSCoord b = new TSCoord();

b.N = 3.0;
b.E = 6.0;
b.Z = 9.0;

TSCoord c = TSMath.calcCenter(a, b);
String output = String.format("A(%f, %f, %f), B(%f, %f, %f) center: (%f, %f, %f)",
				a.N, a.E, a.Z,
				b.N, b.E, b.Z,
				c.N, c.E, c.Z);

TextView view = (TextView)findViewById(R.id.message);
view.setText(output);

这里测试了函数 TSMath.calcCenter。编译项目并运行，就可以看到结果了。

源码可以点击这里下载

ndk-build提示“系统找不到指定的路径”问题

Mon, 28 Mar 2016 00:00:00 +0000

如果是win32系统，使用ndk-build时提示出错，但是在命令行工具中看不到错误信息，进一步使用 ndk-build 2>1.txt 来重定向，发现错误信息是“系统找不到路径”，那么你可能和我遇到相同的问题了。

这个并不是因为ndk-build不在 path 路径中，而是NDK自己的问题。观察 ndk-build 命令输出详细，调用 gcc 的路径实际上并不对。

在命令中使用的是 <ndk_dir>/toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86/ 路径，但实际在x86版本的NDK目录中对比，其中只有 <ndk_dir>/toolchains/arm-linux-androideabi-4.9/prebuilt/windows 目录，不是 windows-x86 ，将其重命名为 windows-x86 即可。

这可能是r11b-x86版本NDK的一个bug。