1. T113系列芯片介绍

SiP 封装是把 DDR 和芯片封装在一起（封装内集成）。
t113‑i(双核 Cortex‑A7 @1.2GHz) 裸芯片本身（die）没有内置 DDR，需要外接 DDR 颗粒
T113‑S没有单独裸片型号，市面上卖的完整型号是 T113‑S2/S3/S4，全部是SiP 封装（封装内堆叠 DDR3）

型号	SiP 内置 DDR	备注
T113‑S2	64MB DDR3	最小内存
T113‑S3	128MB DDR3	最常用，工程机械小仪表很多用这个
T113‑S4	256MB DDR3S	系列最大容量，S 系列最高就 256MB，不能到 512M/1G
T113‑M4(行业口头简称 M4)	256MB DDR3	T113 家族的 SiP 新版本芯片,是全志 T113 系列的迭代 SiP 料号，工程机械仪表圈子经常简称它 “M4” EQFP128 封装，PIN‑to‑PIN 兼容 T113‑S3/S4，老板子几乎不用改 PCB； SiP 封装内部合封 DDR，板子不用外挂 DDR 芯片，不用 DDR 等长布线； 带完整玄铁 C906 RISC‑V + HiFi4 DSP，和 T113‑i 内核一样 专门给工程机械仪表、工业 HMI。

t113-i 是双核 cortex-A7 和 Risc-V，属于多核异构，但是我在使用 t113-t 的时候，我只是在上面做 QT 界面开发，其中也用到了 can 通信，摄像头、存储等外设，但是我感觉不到它是多核的芯片，我想问他的多个核都做些什么?

1. RISC‑V 协核默认不开，不是开机自动启用；不是 Linux 多进程那种 SMP 多核，是 AMP 非对称异构，必须单独开发一套 FreeRTOS 固件给 RISC‑V，不是简单把 QT 程序丢过去跑。> ❌不能把QT、CAN 应用直接放到 RISC‑V 上面跑；RISC‑V 跑 RTOS，没有 Qt、没有 Linux 系统调用。

2. 当前 CAN、摄像头，你是使用 Linux 内核驱动，全部消耗 A7 双核资源。CAN 你用的是 Linux SocketCAN，是 ARM 核在处理，不是 RISC‑V 在处理。

那在 QT 控制 can 的数据收发，是在操作 Risc-V 这个核吗?
  QT+SocketCAN，**完全不操作 RISC‑V（C906）核**，全部跑在双核 Cortex‑A7 上面,绝大多数入门开发，默认都是模式 1：Linux A7 接管全部外设，RISC‑V 不启用，这也是为什么你感受不到这颗核的存在。

什么样子的项目能用到双核？我也做过一些项目，但是我感觉我就是 1 个进程跑到死啊，我之前用 T113-i 做过车载显示器的 HMI 界面开发，没有感觉我用了它的双核
做 HMI 车载显示屏，一个主进程死循环跑界面，**绝大多数情况你确实根本没用上第 2 颗 A7 核**。
T113‑i 是两颗 A7，但是**你代码不做任何特殊处理，应用默认只会跑在其中一个核上，另一颗核空闲摸鱼**。
1. **双核 A7（SMP）：两颗 ARM A7，都跑 Linux，同一个系统内核统一调度**
2. **C906 RISC‑V：另外一颗独立从核，跑 RTOS，跟 A7 双核不是一套东西**

nux 应用程序默认：

- 如果你只有**1 个主线程死循环（LVGL/TouchGFX 主循环）**，整个程序就是单线程。
- Linux 会把这整个进程全部扔到**A7‑0**上跑，A7‑1 核空闲，CPU 利用率经常是：core0 满载，core1 0%。
- 内核、驱动、后台系统服务会零散跑在 core1，但你的业务代码没利用它。

> 
> ✅不是芯片没有双核；是**你的业务是单线程，没有多线程 / 多进程，硬件能力没有被业务用上**。

LVGL、TouchGFX UI 主循环本质就是一个大 while (1)，刷新界面、事件处理，单线程模型。哪怕芯片是 8 核，只跑一个主线程，也只会占 1 个核。

，什么样项目才会真正用上两颗 A7（双核）

分两大类：多线程应用、多进程任务。

场景 1：UI 界面 + 繁重后台业务同时跑（最常见）

还是你的车载 HMI 显示器举例，如果你的项目再加这些功能：

• 一边跑 LVGL/TouchGFX 界面刷新（UI 线程）
• 后台持续做图片解码、视频解码、jpeg 旋转缩放
• 后台做 CAN 报文大量解析，每秒上千条报文解析、过滤、组装
• 后台做 TCP 网络，持续上传日志、接收远端指令
• 后台做文件读写，持续保存日志到 SD 卡

这时你做多线程拆分：

• 线程 0：UI 主线程，绑定到 core0，只管画面刷新，优先级高
• 线程 1：CAN 报文解析、数据处理，跑到 core1
• 线程 2：网络、文件任务

此时两颗核同时干活。UI 不会因为后台数据量大而卡顿掉帧。

👉如果你不拆分，全部塞 UI 主线程 while (1) 里面：一旦 CAN 报文暴增、网络卡顿，UI 直接卡顿、画面掉帧。

这就是双核最直接价值：重后台任务不要抢占 UI 线程，放到另一个 CPU 核心并行执行。

但是注意：这两颗都是 A7，都是 Linux，没有硬实时保证，只是并行分担负载，不能保证 1ms 精准周期。硬实时任务仍然要扔给 C906 RISC‑V 从核。

三、非常重要：区分【双核 A7】和【C906 从核】，很多人搞混

1. 双核 A7（Linux SMP）：分担 CPU 负载，解决卡顿，但是没有硬实时。 哪怕两个 A7 都跑满，Linux 调度抖动依然存在。如果你需要严格 1ms 周期处理 CAN、IO，不要指望双核 A7，这个活交给 C906。

举一个完整典型 T113‑i 车载屏最佳架构（工业车载屏标准思路）

• A7‑core0：UI 主线程 TouchGFX/LVGL，画面刷新
• A7‑core1：网络、文件、日志、上层业务逻辑，解析 CAN 报文（上层协议解析）
• C906 RISC‑V 从核：底层原始 CAN 硬件接收，1ms 周期采样 IO，硬实时，原始报文通过 rpmsg 送给 A7，A7 只做上层解析。

❌错误方案：所有实时逻辑全部塞 Linux 应用，指望双核 A7 解决实时性，Linux 再强双核也会抖动。

我的项目包含 HMI 主界面，视频播放、蓝牙音乐、wifi 等娱乐功能，但是我就 1 个程序啊，项目也开了很多线程用于处理事情比如 can 数据收发、数据查询等功能，这样用到第二个核了吗？？？
**你开了很多线程，很大概率已经在用第 2 颗 A7 核了，但不是 100% 一定用；Linux SMP 调度器自动分配，不由你代码直接指定。**
但：哪怕两个核都在干活，**实时性依然没有保障**。

什么是 C906

铁 C906，阿里平头哥设计的一颗 64 位 RISC‑V 通用 CPU 内核，直接集成在 T113‑i 芯片内部XuanT...。

通俗大白话：T113‑i 芯片里面自带了一颗独立的高性能单片机 CPU，不是外设、不是 DSP，是完整独立 CPU。

基础硬件参数（T113‑i 内部 C906）全志在线开...

• 架构：RISC‑V RV64GCV 64 位
• 最高主频：1008MHz
• 自带独立 Cache、MMU 内存管理单元、独立中断控制器 PLIC、独立时钟域、独立复位
• 可以跑：FreeRTOS、RT‑Thread、裸机代码；也可以跑 Linux，但 T113‑i 项目几乎没人在 C906 跑 Linux
• 和双核 A7（ARM）完全两套独立 CPU 子系统

⚠️重点区分型号：T113‑S 没有 C906，只有双核 A7 + HiFi4‑DSP。只有 T113‑i 才有这颗 RISC‑V 核全志在线开...。

和双核 A7 最核心差别（对你车载屏项目最重要）

1. 双核 A7（ARM） 跑 Linux，功能强大，做 HMI 界面、视频、蓝牙、WiFi。但是没有硬实时保证，调度会抖动。哪怕开再多线程、绑定 CPU 亲和，系统繁忙时依然会延迟。 两个 A7 属于同一个 Linux 内核管理，可以直接共享内存访问。
2. C906 RISC‑V 跑 RTOS（FreeRTOS/RT‑Thread），硬实时、中断响应确定、抖动极小。 它是独立从处理器，不和 A7 共用操作系统。 不能随便直接读写对方内存，A7 ↔ C906 通信走 OpenAMP / RPMSG 共享内存 + 核间中断收发消息。 上电默认不启动；由 U‑Boot 加载 RTOS 固件，再复位把 C906 跑起来。

打个比方

• 双核 A7 = Windows 电脑：能干视频、界面、网络；但是后台一堆软件跑的时候，会卡顿。
• C906 = 板子上额外焊了一颗 STM32 单片机，专门干实时控制；但是它就在芯片内部，不需要外部硬件。

不是 DSP！HiFi4 才是 DSP，专门做音频信号运算。C906 是通用 CPU，可以跑业务逻辑、CAN、IO 控制。

在你的车载 HMI 项目，C906 适合干什么活

✅适合交给 C906：

1. CAN 底层硬件接收，J1939/CANopen 底层报文接收过滤，保证报文响应时间稳定，不受 Linux 界面卡顿影响
2. ADC 周期采集、IO 电平检测、PWM 输出，固定 1ms 周期任务
3. 硬件看门狗监控 A7 Linux，如果 Linux 卡死，C906 可以直接复位整个系统
4. 原始数据预处理，简单滤波，再把处理完的数据通过 rpmsg 上报给 A7 的 HMI 界面显示

❌不适合交给 C906 做：LVGL/TouchGFX 界面、视频解码、蓝牙协议栈、WiFi 网络。这些复杂多媒体业务留给 A7 双核 Linux。

推荐最佳业务分层（车载 HMI）

• 双核 A7（Linux）：HMI 界面、视频播放、蓝牙音乐、WiFi、CAN 报文上层解析、业务逻辑。（就是你现在写的整套程序）
• C906（FreeRTOS）：CAN 硬件底层接收、IO、ADC 采集，硬实时底层任务。原始报文上报 A7。

很多 T113‑i 量产项目直接完全不用 C906，所有逻辑全部放在 Linux 多线程。负载轻一切正常；高负载场景偶发 CAN 延迟、IO 响应抖动，bug 很难复现。

个高频误区澄清

1. ❌C906 是双核 A7 其中一个核 ✅错，完全独立，不属于 A7 集群，指令集都不一样（RISC‑V vs ARM）
2. ❌创建多线程跑在 A7‑core1 就等于 C906 ✅错，A7‑core1 依旧是 Linux，没有硬实时；C906 是另外一颗 CPU，跑 RTOS
3. ❌C906 上电自动启动 ✅错，默认休眠，必须 U‑Boot 加载 RTOS 固件，手动启动，你不写固件它就一直躺平，你的现有项目完全感知不到它的存在。
4. ❌可以 A7 直接访问 C906 全部寄存器内存 ✅错，必须走 RPMSG 核间通信。

开发现实痛点

Tina SDK 早期版本 C906 示例不完善；写 C906 固件需要 RISC‑V GCC 工具链；还要写 rpmsg 通信逻辑，开发工作量会增加。很多项目图省事直接不用 C906。

如果你想，我可以给你讲一段极简流程：U‑Boot → Linux 启动 → 加载 rtos 固件 → 启动 C906，A7 和 C906 收发一条简单消息。

我感觉可能有一些外设就是和 C906 绑定的，比如 can 接口，芯片内部引脚就是接到了 C906 上了

直接给结论

T113‑i 不是这种设计。CAN 控制器硬件 IP、CAN 引脚，不是硬件焊死绑定给 C906！！不是！全志在线开... CAN 控制器挂在芯片内部 AHB 总线上，A7 双核 和 C906，两边总线都可以访问 CAN 寄存器。引脚是芯片 IO 引脚，不属于某一个 CPU 内核。

芯片内部真实结构

1. CAN0、CAN1 是独立外设 IP 核，有一套寄存器；引脚就是芯片的 GPIO 引脚（复用成 CAN_RX CAN_TX）
2. CAN 的寄存器同时挂到A7 的总线矩阵，也挂到C906 的总线矩阵
3. 软件决定谁来控制它：
   • 方案 A：A7 (Linux) 访问 CAN 寄存器，Linux 驱动操作 CAN（就是你现在项目的做法）
   • 方案 B：C906 (RTOS) 访问 CAN 寄存器，RTOS 驱动操作 CAN
4. ❗绝对禁止两边同时操作同一个 CAN 控制器，会冲突崩溃，软件必须二选一。

引脚没有切换开关，引脚物理上不变；是总线访问权交给谁。

那为什么网上教程、案例都说把 CAN 交给 C906？

不是硬件绑定，是软件架构上推荐这么分配：

• C906 跑 RTOS，中断响应确定、抖动极小。CAN 交给 C906，CAN 报文接收不会被 Linux 卡顿影响，不会丢帧，实时性好。
• C906 收到原始 CAN 报文，通过 RPMSG 消息把原始帧发给 A7；A7 的 Linux 只做上层业务解析、给 HMI 界面显示。
• A7 这边不再直接操作 CAN 硬件寄存器。

硬件上你完全可以反过来：C906 闲置睡大觉，A7 直接操作 CAN，就是你现在车载 HMI 项目现状，完全合法，只是实时性没有保障。

哪些外设是这样：A7、C906 都可以访问？

CAN、UART、SPI、TWI(I2C)、PWM、GPADC，绝大多数片内外设都是共享总线访问，软件选谁控制，硬件引脚不属于某一颗 CPU。

但是有少数例外（不能随便给 C906）

1. 显示控制器（DE、MIPI、LVDS、RGB）、VPU 视频解码器：只能 A7 访问，C906 没有访问通路。所以 HMI 界面只能跑 A7，C906 不能跑 GUI。
2. 千兆以太网 EMAC：只能 A7 访问，C906 不能直接操作网口硬件。网络只能 Linux 做。
3. HiFi4 DSP：只能 A7 侧配置管理，C906 不能直接驱动 DSP。

重点澄清一个巨大误区

❌误区：CAN 引脚硬件接到 C906，Linux 不能用 CAN ✅事实：引脚不属于任何 CPU，总线两边都能看见 CAN 寄存器；软件二选一，不能两边同时驱动同一个外设。

结合你车载屏项目两种架构对比

现状（你现在在用）

CAN 硬件由 Linux (A7) 驱动；开 CAN 线程 read 读取报文。 ✅开发简单省事 ❌Linux 系统繁忙（视频播放 + 蓝牙音乐 + WiFi 同时高负载），内核调度抖动，CAN 中断会被推迟，偶发丢帧、报文处理延迟。负载轻的时候一切正常。

优化架构（推荐硬实时方案）

1. CAN 硬件交给 C906 的 FreeRTOS 驱动接管；C906 处理 CAN 硬件中断，接收原始 CAN 帧
2. C906 把收到 CAN 报文通过 RPMSG 发送消息给 A7 Linux
3. Linux 这边不再操作 CAN 硬件，只解析上层协议、UI 展示

硬件引脚完全不变，不需要改板子，只改软件架构。

还有一个坑：时钟与复位

外设的时钟、复位信号，大部分是 A7 侧 CCU 时钟复位单元控制。 就算你想用 C906 操作 CAN，依然需要 A7 侧 U‑Boot/Linux 先把 CAN 外设时钟打开、解除复位，C906 才能访问 CAN 寄存器。C906 本身没有完整 CCU 控制权。 这也是 AMP 开发非常容易踩坑点。

一句话极简总结

1. CAN 引脚物理上没有绑定 C906；寄存器两边 CPU 总线都能访问，软件决定谁接管外设，必须二选一。
2. 显示屏、VPU、千兆网口，只能 A7 访问，C906 碰不到。
3. 交给 C906 跑 CAN，是架构选型，不是硬件强制。

那怎么把这个 C906 利用起来？
这个非常难，就是在T113-i上跑RTOS，网上据说有人做出来了，可以去参考一下，大多数人都不会这么做。