核心技术博客 on TiJet

Hugo 静态网站图片加速：8.6MB 到 310KB 的实战记录

Tue, 04 Aug 2026 00:00:00 +0000

1. 为什么要做图片加速

静态网站加载卡顿，图片往往是最大元凶：

原因	说明
图片体积大	一张 2560×1440 PNG 可能有 8-10MB
格式低效	PNG 无损压缩，适合截图但不适合照片
没有懒加载	页面一次性加载所有图片
没有缓存	每次访问都重新下载

核心思路： 让浏览器下载更小的文件。

2. Hugo 图片处理管道原理

Hugo 内置图片处理能力，构建时自动完成：

原始图片 (assets/img/wall4.png)
 ↓ Hugo 构建时处理
Resize "1920x webp q75"
 ↓
优化后图片 (public/img/wall4_hu_xxx.webp)

操作	语法	说明
缩放	`Resize "800x"`	限制宽度 800px
裁剪	`Crop "800x600"`	裁成指定尺寸
填充	`Fill "800x600"`	填充并居中裁剪
转格式	`webp` / `jpg` / `png`	WebP 体积最小
质量	`q75`	75% 质量（默认 75）

3. 方案一：CSS 背景图优化（实测）

步骤 1：图片放到 Hugo 资源目录

mkdir -p web-site/assets/img
cp 你的图片.png web-site/assets/img/wall4.png

步骤 2：创建处理 partial

新建 layouts/partials/hero-bg.html：

Jenkins CI/CD 入门实战：从零搭建自动构建流水线

Tue, 04 Aug 2026 00:00:00 +0000

1. 为什么要用 Jenkins

Jenkins 是开源的持续集成/持续部署（CI/CD）工具。核心作用：代码 push 到 Git 仓库后，自动完成「拉代码 → 编译 → 测试 → 打包 → 部署」等一系列操作。

你 push 代码到 Gitee
 ↓
Jenkins 自动拉取最新代码
 ↓
自动构建（编译 / hugo / 打包）
 ↓
自动部署 / 归档产物

核心概念

概念	说明
Job / Item	一个构建任务
Pipeline	用 Groovy 脚本定义的构建流水线
Stage	流水线里的一个阶段（拉代码→构建→部署）
Step	每个阶段里的具体操作
Webhook	Git 仓库通知 Jenkins “有新提交了”

2. 安装与启动

前提：Java

Jenkins 是 Java 写的，必须装 Java 17 或 21。太新的版本（如 Java 26）启动会报错：

Running with Java 26 ... not yet fully supported. Supported Java versions are: [17, 21]

解决： 装 Java 21，用显式路径启动：

工控固件安全实战：从裸奔到硬件信任根的完整链路

Wed, 22 Jul 2026 00:00:00 +0000

1. 为什么要搞安全启动？

在工控领域，固件被篡改不只是数据泄露的问题——它是物理安全威胁。被篡改的固件可能禁用看门狗、改写热关断阈值，或悄无声息地窃取核心运动控制参数。

然而现实是，大多数工业物联网设备出厂时 JTAG 全开，固件完整性校验仅靠 CRC32。CRC32 能抓比特翻转，但对有动机的攻击者毫无作用。

2025 年中，我们对泰诺固件供应链做了安全审计，发现多处缺口：OTA 载荷未签名、无版本回滚防护、生产设备调试接口未关闭。这篇文章记录完整修复方案。

2. 信任链设计

我们的安全启动实现了三级信任链：

ROM Boot Code（不可变，掩膜 ROM 固化）
 ↓ 验证 ECDSA 签名
第一级：Bootloader（公钥哈希烧录在 OTP eFuse 中）
 ↓ 验证 ECDSA 签名
第二级：应用固件
 ↓ 验证 ECDSA 签名
第三级：FPGA 比特流 + 标定数据

每一级的公钥内嵌于上一级，信任根锚定于 i.MX RT1064 的一次性可编程（OTP）eFuse。公钥哈希一旦烧入 OTP，除非物理更换芯片，否则无法修改。

所有签名使用 ECDSA with NIST P-256。选择 ECDSA 而非 RSA 基于两个考量：签名体积更小（64 字节 vs. 同等安全强度的 256+ 字节），以及在 Cortex-M 核上的验证速度更快（无需硬件加密加速器即可获得可接受的性能）。

3. OTA 防回滚

仅有签名是不够的。攻击者可以截获一个有效但过时的 OTA 包，将其重放以将设备降级到存在已知漏洞的旧版本。

我们的防回滚机制简单且硬件支持：

每个固件镜像在其签名元数据中携带一个单调递增的安全版本号。
当前安全版本号存储在 eFuse 实现的单调计数器中（只能烧 1，不能清 0）。
Bootloader 拒绝任何安全版本号小于 eFuse 计数值的镜像。
提升安全版本的 OTA 更新会烧录新的 eFuse 比特——这是一个物理上不可逆的操作，即使全片擦除也无法撤销。

4. CI/CD 中的密钥管理

密钥管理是大多数安全启动方案在实际落地中最薄弱的环节。密钥存在开发者的笔记本上，就意味着迟早会泄露。

驯服 Linux 抖动：PREEMPT_RT + Xenomai 实现 50µs 硬实时闭环控制

Tue, 21 Jul 2026 00:00:00 +0000

1. 挑战：在 30 美元的 SoC 上跑软 PLC

泰诺下一代运动控制器需要在单颗 SoC 上运行软 PLC 运行时，同时对六个伺服轴执行 20kHz 的闭环 PID 控制。目标硬件：售价约 30 美元的全志 A40i（四核 Cortex-A7）。没有 FPGA，没有专用 DSP——只有普通的 ARM 核跑 Linux。

问题显而易见：标准 Linux 即使配置了 SCHED_FIFO，在这类硬件上仍会出现 200~500µs 的调度抖动。对于周期仅 50µs 的 20kHz 控制环来说，这完全不可接受。错过截止时间意味着相位误差累积，最终导致机械系统失稳。

2. PREEMPT_RT 地基

第一步很直接：应用 PREEMPT_RT 补丁集，配置内核 CONFIG_PREEMPT_RT_FULL=y。这几乎将所有 Spinlock 临界区转换为可抢占的互斥锁，让内核实现近乎完全可抢占。

关键内核配置：

CONFIG_PREEMPT_RT_FULL=y
CONFIG_HZ=1000
CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
CONFIG_NO_HZ_FULL=y

仅凭 PREEMPT_RT，最差调度延迟从 ~480µs 降至 ~80µs。有改善，但仍达不到 50µs 的预算。

3. 引入 Xenomai 4（EVL 核）

Xenomai 4 的 EVL 核与 Linux 并行运行一个独立的实时核心，在中断到达 Linux 内核之前就进行拦截。实时线程由 EVL 核直接调度，完全绕过 Linux 调度器。

FPGA 加速视觉检测：从 200ms 到 8µs 的延迟优化之路

Mon, 20 Jul 2026 00:00:00 +0000

1. 问题的原点：软件视觉检测撞上性能墙

在泰诺的 PCB 印刷产线中，锡膏检测（SPI）是核心品控环节。每一块经过产线的 PCB 仅有不到 50ms 的时间窗口用于缺陷检测——超出这个时间，整条产线就会产生背压。

多年来，我们一直使用基于 GPU 加速的 OpenCV 流水线运行在 x86 边缘节点上。方案确实能用——但仅限低负载场景。当检测分辨率提升到 8K 级别后，单帧处理延迟偶尔飙升至 180~220ms。这 180ms 的抖动意味着漏检、误放行和产线拥塞。根本原因在于架构：通用 GPU 流水线无论怎样优化，都无法消除调度延迟和 PCIe 传输开销的不确定性。

2. 为什么选择 FPGA：硬件流水线的不可替代性

我们决定将整条检测流水线下沉到 FPGA，让芯片直接对接图像传感器的 MIPI 接口。核心理由有三：

流式架构：像素从 ADC 输出的那一刻就开始逐级流过流水线，不存在帧缓存、DMA 传输和内核上下文切换。
确定性延迟：精心设计的流水线具有精确的 N 个时钟周期的像素延迟，N 即流水线总深度，不存在方差。
能效优势：FPGA 方案功耗约 4W，而同等工作负载在 GPU 边缘节点上需要 45W。

3. 架构设计

我们在 Xilinx Kintex-7 上实现了五级流水线：

Sensor → Bayer2RGB → 色彩校正 → 二值化/阈值 → 连通域检测 → 判定锁存
 ↓ ↓ ↓ ↓ ↓ ↓
 MIPI 第1级 第2级 第3级 第4级 第5级
 (原始) (3周期) (2周期) (1周期) (8周期) (1周期)

总流水线深度：15 个时钟周期。在 200MHz 时钟下，单个像素从进入到缺陷标志输出的延迟为 75 纳秒。整帧图像以行速率流转，8K × 8K 的帧在传感器输出完成的同时即完成检测——不引入任何额外延迟。

裸机 Rust 实战：重写 Bootloader，零内存错误的背后

Sun, 19 Jul 2026 00:00:00 +0000

1. Bootloader 的困局

泰诺的工业控制板卡上搭载一颗 MCU，负责电源时序管理、看门狗和 OTA 固件升级。Bootloader 约 8000 行 C 代码，已"稳定"运行多年——但在嵌入式语境下，“稳定"往往意味着"已知的坑都补上了，未知的等待下一次现场翻车”。

每隔 6 到 9 个月，新的 OTA 边界场景就会浮现：固件镜像校验时的缓冲区溢出、Flash 擦除例程的 off-by-one、CAN 总线命令分发器中的 use-after-free。每一次修复都需要全量 OTA 推送，而针对已部署的工控设备群，一次全量 OTA 是以周为单位的痛苦过程。

2. 为什么要在裸机上用 Rust

2026 年初，团队决定用 Rust 重写 Bootloader，目标平台为 thumbv7em-none-eabihf（ARM Cortex-M7）。这个决定不是出于技术信仰，而是工程经济学的考量：

编译期内存安全：借用检查器在编译阶段就消灭了 use-after-free、double-free 和缓冲区溢出——这几类问题占据了我们 Bootloader CVE 的约 70%。
零成本抽象：Rust 的 no_std 生态提供了 RAII、类型化状态机和穷尽模式匹配，却不引入任何运行时和分配器。
生态成熟度：embedded-hal、cortex-m、cortex-m-rt、probe-rs 已达到生产级水准，有活跃维护和商业支持。

3. 架构设计

我们的 Bootloader 被建模为一个类型级强制的有限状态机：

enum BootState {
 PowerOn(Peripherals),
 VerifyFirmware(Peripherals, FlashHandle),
 ReadyToBoot(VerifiedImage),
 Fallback(Error),
}

impl BootState {
 fn transition(self) -> Self {
 match self {
 Self::PowerOn(p) => self.init_peripherals(p),
 Self::VerifyFirmware(p, f) => self.verify_image(p, f),
 // 编译器保证每个状态都被处理
 }
 }
}

核心设计原则：非法状态不可表达。你不可能在镜像校验尚未完成时意外调用 jump_to_firmware()，因为该函数只接受 VerifiedImage 类型——而构造该类型的唯一路径就是通过校验流程。

从自建协议到 gRPC：泰诺异构工控系统通信架构的重大跨越

Sat, 18 Jul 2026 00:00:00 +0000

1. 为什么我们必须废除原有的自建私有协议？

在过去很长一段时间里，泰诺的工业控制板卡与上位机、打印控制端之间采用的是自建的私有协议。这类协议在特定单一品类开发中确实具备轻量、灵活、随改随用的特点。然而，随着泰诺逐步迈向工业 5.0 标准，我们的系统架构正在向"通用工业级异构计算与智能控制平台"产生蜕变。

在这种背景下，原有私有协议暴露出三大难以调和的痛点：多语言 SDK 维护成本高昂（C#、C++/Rust 异构端需手动重写解析流）、缺乏强大的类型安全边界、异构系统难以灵活扩展 RPC 服务。

2. 为什么选择 gRPC + Protobuf？

截至 2026 年 7 月，团队迎来重大里程碑：我们彻底抛弃了过去的自建协议与 JSON，全线切换为 gRPC 通信框架。并在所有联调测试和极限压力测试中取得了全部通过（Pass）的成绩。

gRPC 给泰诺带来了质的飞跃：契约先行（Schema-First）、二进制序列化带来的极致高性能与低延迟。同时无缝对接了董佳琦主导的 tincore 核心"氧化计划"，通过 Rust 生态的 tonic 库完美适配，兼顾了极致性能与绝对内存安全。