北京泰诺恒创科技 on TiJet

当前开启打印流程

Mon, 01 Jan 0001 00:00:00 +0000

当前开启打印流程

本文档记录当前 C 客户端、C SDK 和 tijet_1/tincore gRPC 服务端的实际开启打印流程。

本文档只描述当前代码和当前客户端行为，不包含未来改造方案。

源码基准

模块	代码库	分支
Proto 契约与 C SDK	`tijet_1/sw-grpc-libraries`	`master`
tincore gRPC 服务端	`tijet_1/tincore`	`feature-grpc-cpp`

参与者

参与者	职责
Qt 客户端业务层	注册事件回调、上传打印数据、重试 `START_PRINT`、等待最终结果
C SDK 调用线程	封装 `SetPrintData` 和 `StartPrint` RPC
C SDK 事件线程	持续读取 `SubscribeEvents` 服务端流，并调用客户注册的事件回调
`TinCoreServiceImpl`	gRPC 协议层，将 RPC 请求转交给服务端 Handler
`DefaultTinCoreHandlers`	执行打印数据接收、数据就绪校验和异步开启打印逻辑
`gAFBridge` / 喷头硬件	后台处理打印数据、控制驱动板电源、与喷头通信并开启高压

当前调用时序

sequenceDiagram
 autonumber
 participant Caller as 调用端
 participant Callee as 被调用端

 Caller->>Callee: tijet_client_set_event_callback(callback, user_data)
 Callee-->>Caller: 回调注册完成

 Caller->>Callee: tijet_client_start_event_subscription()
 Callee-->>Caller: TIJET_OK
 Note over Callee: 后台创建事件线程
 Note over Callee: SubscribeEvents() 持续读取

 Caller->>Callee: tijet_client_set_print_data(data, index, is_static)
 Callee-->>Caller: SetPrintDataResponse{success=true}
 Note over Callee: 打印数据进入后台处理
 Note over Callee: 返回时 DATA_READY 可能仍为 0

 loop START_PRINT 重试，总超时 10 秒
 Caller->>Callee: tijet_client_print_control(START_PRINT)
 alt DATA_READY == 0
 Callee-->>Caller: TIJET_ERR_SERVER
 Note over Caller: 等待 1 秒后重试
 else DATA_READY != 0
 Callee-->>Caller: TIJET_OK
 Note over Callee: 创建高压启动线程
 end
 end

 Note over Caller: START_PRINT 成功后，等待 PrintStarted

 alt 高压开启成功
 Callee-->>Caller: PrintStarted{success=true}
 Note over Caller: 可进入喷印状态
 else 高压开启失败
 Callee-->>Caller: PrintStarted{success=false}
 Note over Caller: 失败，message 含未就绪喷头数
 else 10 秒未收到 PrintStarted
 Note over Caller: 等待超时
 end

重试与超时流程

flowchart TD
 A["调用端: 连接服务端"] --> B["调用端: 注册事件回调<br/>启动事件订阅"]
 B --> C["调用端: set_print_data() 上传打印数据"]
 C --> D{"被调用端: 上传 RPC 成功？"}

 D -->|"否"| D1["失败，流程结束"]
 D -->|"是"| E["被调用端: 数据进入后台处理<br/>DATA_READY 可能仍为 0"]

 E --> F["调用端: 开始 START_PRINT 重试计时"]
 F --> G["调用端: print_control(START_PRINT)"]
 G --> H{"被调用端: DATA_READY 是否为 0？"}

 H -->|"是：数据未就绪"| I{"重试总时间达 10 秒？"}
 I -->|"否"| J["调用端: 等待 1 秒"]
 J --> G
 I -->|"是"| K["失败：打印数据准备超时"]

 H -->|"否：数据已就绪"| L["被调用端: 创建高压启动线程<br/>返回 TIJET_OK"]
 L --> M["调用端: 等待 PrintStarted 事件<br/>超时 10 秒"]
 M --> N{"结果"}

 N -->|"success=true"| O["成功：高压开启完成<br/>进入可喷印状态"]
 N -->|"success=false"| P["失败：高压开启失败"]
 N -->|"超时"| Q["失败：等待高压结果超时"]

返回值的当前含义

位置	返回值	当前实际含义
`tijet_client_set_print_data()`	`TIJET_OK`	打印数据上传 RPC 已完成；不表示后台数据处理完成，也不表示 `DATA_READY=1`
`tijet_client_print_control(..., "START_PRINT")`	`TIJET_ERR_SERVER`	gRPC 调用失败，或服务端返回 `success=false`；当前客户端不区分原因，统一等待 1 秒后重试
`tijet_client_print_control(..., "START_PRINT")`	`TIJET_OK`	服务端同步校验通过并创建了高压启动线程；不表示高压已经开启
`PrintStarted.success`	`true`	高压开启成功，并已调用 `setDataParamReady(true)`
`PrintStarted.success`	`false`	高压开启失败，`message` 包含未就绪喷头数量

源码索引

C SDK

sdk/c/src/tijet_core.cpp:342：tijet_client_set_print_data()。
sdk/c/src/tijet_core.cpp:396：注册事件回调。
sdk/c/src/tijet_core.cpp:408：启动事件订阅和创建事件线程。
sdk/c/src/tijet_core.cpp:641：tijet_client_print_control()。
sdk/c/src/tijet_core.cpp:655：匹配 START_PRINT 并调用 StartPrint RPC。
sdk/c/include/tijet_core.h:441：打印数据上传 C API 声明。
sdk/c/include/tijet_core.h:480：事件回调注册 C API 声明。
sdk/c/include/tijet_core.h:500：事件订阅 C API 声明。
sdk/c/include/tijet_core.h:650：打印控制 C API 声明。

Proto 契约

proto/print.proto:7：SetPrintDataRequest。
proto/print.proto:19：StartPrintRequest。
proto/print.proto:22：StartPrintResponse。
proto/event.proto:48：PrintDataStatus。
proto/event.proto:53：PrintStarted。
proto/tincore.proto:27：SetPrintData RPC。
proto/tincore.proto:28：StartPrint RPC。
proto/tincore.proto:33：SubscribeEvents RPC。

`tijet_1/tincore` gRPC 服务端

以下路径相对于 tijet_1/tincore 代码库的 feature-grpc-cpp 分支：

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 库完美适配，兼顾了极致性能与绝对内存安全。

参数读写

Mon, 01 Jan 0001 00:00:00 +0000

参数读写

读写服务端配置参数，通过 Key 命名约定区分全局参数与驱动板参数。

`tijet_client_set_parameter`

设置参数。

通过 Key 命名约定区分全局参数与驱动板参数：

"key" → 全局参数
"board.N.key" → 驱动板编号 N 的参数（N 为板号）
client: 客户端句柄。
key: 参数名（区分大小写，UTF-8 编码），支持层级命名。
value: 参数值（JSON 字符串格式，参见 param_type_convention 节）。
返回: TIJET_OK — 设置成功
返回: TIJET_ERR_NOT_CONNECTED — 未连接
返回: TIJET_ERR_INVALID_ARG — client / key / value 为 NULL
返回: TIJET_ERR_SERVER — 服务端拒绝该参数

使用示例：

// 全局参数
tijet_client_set_parameter(cli, "print_speed", "100");
// 驱动板 #0 的参数
tijet_client_set_parameter(cli, "board.0.print_speed", "80");

参见: tijet_client_get_parameter()

`tijet_client_get_parameter`

获取参数（单次调用）。

不再需要"两次调用"模式——调用方预分配至少 TIJET_MAX_PARAM_VALUE 字节的缓冲区，传入 buf_size 告知容量，一次调用即可获取参数值。

通过 Key 命名约定区分全局参数与驱动板参数（同 set）。

错误码

Mon, 01 Jan 0001 00:00:00 +0000

错误码

所有接口函数返回的状态码。

`TIJET_OK`

操作成功。

`TIJET_ERR_INVALID_ARG`

参数无效（NULL 指针、越界等）。

`TIJET_ERR_NOT_CONNECTED`

尚未连接到服务器。

`TIJET_ERR_TIMEOUT`

操作超时。

`TIJET_ERR_BUFFER_TOO_SMALL`

用户提供的缓冲区太小。调用 tijet_client_last_error() 获取所需大小。

`TIJET_ERR_SERVER`

服务器返回错误。

`TIJET_ERR_INTERNAL`

内部错误（内存不足、线程错误等）。

`tijet_client_t`

客户端句柄（opaque pointer）。

通过 tijet_client_create() 创建，用毕后必须调用 tijet_client_destroy() 释放。内部结构不对外暴露，所有操作均通过本头文件中声明的函数完成。

打印数据

Mon, 01 Jan 0001 00:00:00 +0000

打印数据

向服务端发送打印数据。

`tijet_client_set_print_data`

发送打印数据到服务端。

client: 客户端句柄。
data: 二进制打印数据缓冲区。
data_len: 数据长度（字节）。
index: 打印数据序号（由业务层传入，用于去重 / 顺序控制）。
is_static: 0 = 普通数据（一次性打印），非 0 = 静态数据（重复打印同一份）。静态数据会被服务端缓存以优化重复传输。
checksum_buf (输出): 校验和输出缓冲区。传 NULL 表示不关心校验和。
checksum_buf_size (输入/输出):
[in] checksum_buf 的容量（字节）。checksum_buf 为 NULL 时传 0。
[out] 校验和字符串所需字节数（含结尾 \0）。当前实现输出 64 字符的 SHA-256 十六进制字符串，需要 65 字节。
返回: TIJET_OK — 发送成功
返回: TIJET_ERR_NOT_CONNECTED — 未连接
返回: TIJET_ERR_INVALID_ARG — client / data 为 NULL 或 data_len 为 0
返回: TIJET_ERR_BUFFER_TOO_SMALL — checksum_buf 不足

连接管理

Mon, 01 Jan 0001 00:00:00 +0000

连接管理

建立与断开打印服务的连接。

`tijet_client_connect`

连接到打印服务。

自动识别地址类型：

包含 : 后跟数字端口（如 127.0.0.1:50051）→ TCP 直连
其他非空字符串 → Unix Domain Socket（自动添加 unix: 前缀）
NULL 或空字符串 → 使用 TIJET_DEFAULT_UDS_PATH
client: 客户端句柄。
address: 服务地址（UTF-8 字符串）。传 NULL 或空字符串使用默认 UDS 路径。
返回: TIJET_OK — 连接成功
返回: TIJET_ERR_INVALID_ARG — client 为 NULL
返回: TIJET_ERR_TIMEOUT — 连接超时
返回: TIJET_ERR_SERVER — 服务端拒绝连接

注意: 重复调用会先断开当前连接再重新连接。参见: tijet_client_disconnect() 参见: TIJET_DEFAULT_UDS_PATH

`tijet_client_disconnect`

断开与服务端的连接。

自动停止事件订阅和日志订阅（若已启动），安全关闭 gRPC channel。未连接时调用是安全的（空操作）。

client: 客户端句柄。
返回: TIJET_OK — 断开成功
返回: TIJET_ERR_INVALID_ARG — client 为 NULL

`tijet_client_is_connected`

查询是否已连接。

日志订阅

Mon, 01 Jan 0001 00:00:00 +0000

日志订阅

订阅服务端的远程日志推送（WatchLogs）。

`tijet_client_set_log_callback`

注册服务端日志回调。

必须在 tijet_client_start_log_subscription() 之前调用。如未注册，日志默认写入客户端 spdlog（需链接 spdlog 库）。

client: 客户端句柄。
callback: 日志回调函数。传 NULL 恢复默认（spdlog 输出）。
user_data: 用户自定义数据，回调时原样传入。可以为 NULL。

注意: 回调在内部日志线程中执行，务必保证线程安全。参见: tijet_log_callback_t 参见: tijet_client_start_log_subscription()

`tijet_client_stop_log_subscription`

停止日志订阅。

安全关闭日志流并等待内部线程退出，阻塞直到线程完全退出。未启动订阅时调用是安全的（空操作）。

client: 客户端句柄。
返回: TIJET_OK — 停止成功
返回: TIJET_ERR_INVALID_ARG — client 为 NULL

参见: tijet_client_start_log_subscription()

生命周期

Mon, 01 Jan 0001 00:00:00 +0000

生命周期

客户端句柄的创建与销毁。

`tijet_client_create`

创建客户端实例。

分配并初始化内部资源。返回的句柄在使用前需要调用 connectToServer() 建立与服务端的连接。

返回: 非 NULL 的客户端句柄。内部内存分配失败时返回 NULL。

注意: 用毕后必须调用 tijet_client_destroy() 释放。

参见: tijet_client_destroy()

`tijet_client_destroy`

销毁客户端实例。

自动断开连接（如有）、释放所有内部资源。传入 NULL 是安全的（空操作）。

client: 客户端句柄。可以为 NULL。

参见: tijet_client_create()

事件订阅

Mon, 01 Jan 0001 00:00:00 +0000

事件订阅

订阅服务端的异步事件推送。

`tijet_client_set_event_callback`

注册服务端事件回调。

必须在 tijet_client_start_event_subscription() 之前调用。未注册回调时启动事件订阅不会产生效果。

client: 客户端句柄。
callback: 事件回调函数。传 NULL 取消注册。
user_data: 用户自定义数据，回调时原样传入。可以为 NULL。

注意: 回调在内部事件线程中执行，务必保证线程安全。参见: tijet_event_callback_t 参见: tijet_client_start_event_subscription()

`tijet_client_stop_event_subscription`

停止事件订阅。

安全关闭事件流并等待内部线程退出，阻塞直到线程完全退出。未启动订阅时调用是安全的（空操作）。

client: 客户端句柄。
返回: TIJET_OK — 停止成功
返回: TIJET_ERR_INVALID_ARG — client 为 NULL

参见: tijet_client_start_event_subscription()

网络配置

Mon, 01 Jan 0001 00:00:00 +0000

网络配置

配置设备网络（IP / 掩码 / 网关）。

`tijet_client_network_config`

配置设备网络参数。

client: 客户端句柄。
ip: IPv4 地址（如 "192.168.1.100"）。传 NULL 或空字符串跳过。
ip_mask: 子网掩码（如 "255.255.255.0"）。传 NULL 或空字符串跳过。
gateway: 默认网关（如 "192.168.1.1"）。传 NULL 或空字符串跳过。
返回: TIJET_OK — 配置成功
返回: TIJET_ERR_NOT_CONNECTED — 未连接
返回: TIJET_ERR_SERVER — 服务端返回配置错误
返回: TIJET_ERR_INVALID_ARG — client 为 NULL

注意: 三个参数中至少应提供一个非空值。全为空将返回 TIJET_ERR_INVALID_ARG。

元信息

Mon, 01 Jan 0001 00:00:00 +0000

元信息

错误信息查询与版本信息。

`tijet_client_last_error`

获取最近一次错误的可读描述。

client: 客户端句柄。返回: 指向静态错误字符串的指针。无错误时返回 "No error"。该指针在下次对同一句柄的操作前一直有效。

注意: 返回的字符串不需要（也不能）由调用方释放。

`tijet_client_version`

获取 SDK 版本号。

返回: 版本字符串，格式 "major.minor.patch"，如 "1.0.0"。返回的字符串为静态常量，不可释放。

`TIJET_VERSION_MAJOR`

SDK 主版本号。

`TIJET_VERSION_MINOR`

SDK 次版本号。

`TIJET_VERSION_PATCH`

SDK 修订版本号。

`TIJET_SHA256_HEX_LEN`

SHA-256 十六进制字符串长度（不含结尾 \0）。

北京泰诺恒创科技 on TiJet

当前开启打印流程

当前开启打印流程

源码基准

参与者

当前调用时序

重试与超时流程

返回值的当前含义

源码索引

C SDK

Proto 契约

tijet_1/tincore gRPC 服务端

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

1. 为什么要做图片加速

2. Hugo 图片处理管道原理

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

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

步骤 2：创建处理 partial

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

1. 为什么要用 Jenkins

核心概念

2. 安装与启动

前提：Java

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

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

2. 信任链设计

3. OTA 防回滚

4. CI/CD 中的密钥管理

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

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

2. PREEMPT_RT 地基

3. 引入 Xenomai 4（EVL 核）

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

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

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

3. 架构设计

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

1. Bootloader 的困局

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

3. 架构设计

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

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

2. 为什么选择 gRPC + Protobuf？

参数读写

参数读写

tijet_client_set_parameter

tijet_client_get_parameter

错误码

错误码

TIJET_OK

TIJET_ERR_INVALID_ARG

TIJET_ERR_NOT_CONNECTED

TIJET_ERR_TIMEOUT

TIJET_ERR_BUFFER_TOO_SMALL

TIJET_ERR_SERVER

TIJET_ERR_INTERNAL

tijet_client_t

打印数据

打印数据

tijet_client_set_print_data

连接管理

连接管理

tijet_client_connect

tijet_client_disconnect

tijet_client_is_connected

日志订阅

日志订阅

tijet_client_set_log_callback

tijet_client_stop_log_subscription

生命周期

生命周期

tijet_client_create

tijet_client_destroy

事件订阅

事件订阅

tijet_client_set_event_callback

tijet_client_stop_event_subscription

网络配置

网络配置

tijet_client_network_config

`tijet_1/tincore` gRPC 服务端

`tijet_client_set_parameter`

`tijet_client_get_parameter`

`TIJET_OK`

`TIJET_ERR_INVALID_ARG`

`TIJET_ERR_NOT_CONNECTED`

`TIJET_ERR_TIMEOUT`

`TIJET_ERR_BUFFER_TOO_SMALL`

`TIJET_ERR_SERVER`

`TIJET_ERR_INTERNAL`

`tijet_client_t`

`tijet_client_set_print_data`

`tijet_client_connect`

`tijet_client_disconnect`

`tijet_client_is_connected`

`tijet_client_set_log_callback`

`tijet_client_stop_log_subscription`

`tijet_client_create`

`tijet_client_destroy`

`tijet_client_set_event_callback`

`tijet_client_stop_event_subscription`

`tijet_client_network_config`

`tijet_client_last_error`

`tijet_client_version`

`TIJET_VERSION_MAJOR`

`TIJET_VERSION_MINOR`

`TIJET_VERSION_PATCH`

`TIJET_SHA256_HEX_LEN`