-
XVF3800 默认核资源使用分析（上）： 16 个逻辑核，一个都没闲着
给 XVF3800 加功能（UART、自定义协议、常驻算法）之前，必须先回答一个问题：芯片还有没有核可用？本文对 v3.2.1 默认源码（main_tile0.c / main_tile1.c 的 PAR_JOBS 结构）与官方预编译的 23 个 .xe 固件逐一做 xobjdump 实测，把 16 个逻辑核、每 tile 512 KB SRAM 的账算清楚。一句话结论：两个 tile 的 8 个
2026-10-26 吴昊 2
-
XVF3800 默认核资源使用分析（中）： xobjdump 实测与内存推算
上篇确认了两个 tile 的 8 个逻辑核全部占满。本篇用 xobjdump 对官方固件逐一实测：--resources 汇总怎么读、tile[1] 那 5 行数字的真实含义，以及每 tile 512 KB SRAM 的推算方法。一、xobjdump 实测结果1.1 --resources 原始输出（UA 构建 ua-io48-lin）Applicationidnumber:0x00000000t
2026-10-26 吴昊 3
-
XVF3800 默认核资源使用分析（下）： 构建差异、数据流与工程建议
上篇给出核分配模型，中篇给出 xobjdump 实测与内存推算。本篇收尾：UA 与 INT 两种构建的核心差异、音频数据流与逻辑核的对应关系、加功能时的工程建议，以及全部数值的复现命令与常见误读澄清。一、UA 与 INT 构建的核心差异项目UA 构建（USB Audio）INT 构建（I2S/SPI 从机）tile[0] 裸金属核pp 3 + mic 1 + usb_buffer 1 + XUD
2026-10-26 吴昊 2
-
XTAG4 的 J4（xSYS2）20 脚定义：<br>哪几根线真正在干活
这块 2×10 的 IDC 座看起来有 20 个脚，真正承载信号的只有 10 根：8 根奇数脚全部接地，另外 2 根奇数脚（1、11）是目标板送过来的电平参考。剩下的偶数脚里，5 根做 JTAG 与复位控制，4 根做 XMOS Link——xScope 走的就是这 4 根。自制裁线或做转接板时，按下面这张分工表对照即可。一句话结论：J4 是「10 信号 + 2 参考 + 8 地」的结构，两颗 VR
2026-10-28 吴昊 1
-
XVF3800 的 DOA： 从四个麦克风到一圈指示灯
读 AUDIO_MGR_SELECTED_AZIMUTHS 时，最常见的两个疑问是：为什么有时返回 NAN？为什么同一个人说话，读到的角度会来回跳几度？答案不在「DOA 算法」里，而在它上游的三波束结构和下游的三层过滤。一句话结论：XVF3800 的 DOA 不是独立模块，而是波束成形的副产品——每个波束自带一个方位角。固件把这 4 个原始角与 4 个语音能量做 VAD 和三层过滤，才合成「说话人
2026-10-26 吴昊 5
-
XMOS 的 OTP 加密：原理与完整烧录流程
用 xflash 烧进 SPI Flash 的镜像，默认是明文的：谁把 Flash 拆下来读一遍，就能拿到完整固件；改几个字节再烧回去，设备照样能跑。OTP 加密要解决的就是这三件事——防读取、防篡改、防克隆。一句话结论：XMOS 不是「给 Flash 加个密」，而是把一段解密程序（xAES Module）和两把 128bit 密钥焊进片内 4KB OTP，再用三个安全位把芯片锁成 secure
2026-10-26 吴昊 14
-
xvf_host 命令是怎么解析的： 从命令行参数到 I²C 字节流
为什么 xvf_host LED_COLOR 0xff8800 能直接控制设备，而自己写 I²C 裸机驱动却读回乱码？答案在于三件事：命令名的查表机制、参数的类型化打包、以及读写靠的是同一个字节的不同 bit。一句话结论：命令名并不写死在程序里——它由固件编译期生成的 command_map 动态库解析成「ResID + CmdID + 参数类型表」；参数按类型定长、依序、小端打包进 payloa
2026-10-26 吴昊 1
-
XVF3800 的 I²C 双身份：Master 与 Slave 到底能不能切换
XMOS 技术解析 · 接口与配置XVF3800 的 I²C 双身份：Master 与 Slave 到底能不能切换上一篇讲的是 USB 与 I²C 的分工。这一篇聚焦 I²C 自身：同一颗芯片，为什么既要做从机被 MCU 控制，又要做主机去控制 DAC 和扩展器？两者在什么条件下互斥、什么条件下可以并存？一句话结论：XVF3800 的 I²C 只有一对引脚（Pin 44 / Pin 45），数据手
2026-10-26 吴昊 1
