SG板移植开发交流

[chyyuu]

预期目标：

1. StarryOS可在SG板上启动；
2. StarryOS可支持SG板上的基本Linux应用；
3. StarryOS适配sg2002的TPU驱动；
4. StarryOS适配sg2002的其它驱动（支持存储、支持摄像头、支持I2C、wifi等），从而支持更多的Linux应用；
5. StarryOS支持YOLOv8，支持驱动299的小车底盘（大概率是用I2C接口）。

开发启动时间：2026.01.13

参考信息：

• 开发板Sipeed LicheeRV Nano SG2002(WiFi)开发板
  • LicheeRV-Nano文档
  • LicheeRV-Nano例程
  • LicheeRV-Nano硬件
  • 交流平台
  • 算能官方资料
• 基于 sg2002的milkv板：详细描述了 怎么使用 sg2002 的 tpu

[yfblock]

目前搜集到的一些信息：https://shimo.im/docs/m4kMM20wzKC9DBkD/ 《CV系列处理器 TPU SDK 开发资料》，可复制链接后用石墨文档 App 打开

还有之前我在 os 比赛时开发的 cv1811h sd 卡驱动，当时时间比较紧，需要改改修复一下应该就能用：https://github.com/Byte-OS/cv1811-sd/tree/main

目前开发板买了一块 licheerv nano wifi 款的，

[yfblock]

2026-01-13 讨论：

1. 目前大家都先搜集一些相关的资料，看看对什么比较感兴趣
2. 板子到手后可以共同做 任务1，2，每个人都对 StarryOS 和 sg2002 都有一些了解
3. 可能有的问题是目前 Starry 中用的是 musl libc，但是 sg2002 linux 中应该用的是 glibc，可能需要换掉 libc
4. 需要明确要跑哪些 linux 应用，也许可以在 Starry 上利用 yolo 在 cpu 上跑已有的图像或视频识别
5. 摄像头可能是难点，可以用一些简单的摄像头先捕捉到画面（使用 spi 协议，比如 ov7670: https://web.mit.edu/6.111/www/f2016/tools/OV7670_2006.pdf ） ，或者使用其他的比较简单的方法，目前找到的推荐用的是基于 MIPI 协议的 GC4653
6. tpu 是比较难的部分，大家先搜集资料，到时候共同学习一下

[elliott10]

算能微信群交流记录：

https://github.com/sophgo/cviruntime/blob/master/doc/cvitek_tpu_sdk_development_manual.md
https://github.com/sophgo/cvikernel
仓库是开源的 文档我没有找到

如果要在其它系统上编译这里有个alios的cvi仓库
https://github.com/sophgo/cvi_alios_open
应该可以借鉴一下

kernel和runtime的开发文档
https://github.com/sophgo/cviruntime/blob/master/doc/cvitek_tpu_sdk_development_manual.md

[yfblock]

• 搜素了一些信息发现 qemu riscv64 有 thead-c906 的支持，可以在遇到问题的时候进行调试
  尝试编写了一个程序发现 riscv64 能运行在上面，只是需要避免使用 c.lbu 指令
• xuantie 的 github 仓库中也有修改的 qemu, https://github.com/XUANTIE-RV/qemu ，这里支持的完善一些
• 尝试为 arceos 添加了新平台（完成）。也尝试了为 Starry 添加新平台（还未跑通）
• 尝试利用一些 AI 工具搜索信息（NotebookLM，Cursor，gemini）
  搜索 gc4653 摄像头的信息，已经都放在了石墨文档中：https://shimo.im/docs/m4kMM20wzKC9DBkD/

[elliott10]

据悉李老师组，目前也在使用厂商配套的的GC4653摄像头。

GC4653摄像头驱动源码，在AliOS和FreeRTOS中找到有完整驱动实现:

• https://github.com/sophgo/freertos/tree/sg200x-dev/cvitek/driver/sensor/src/gcore_gc4653/
• https://github.com/sophgo/cvi_alios_open/tree/master/components/cvi_sensor/gcore_gc4653/

[yfblock]

sg2002 的 pin 会被复用，Uart 或 IIC 可能会在同一个 Pin 上，且同一时刻只能用一个功能，所以需要设置复用来选择用哪一个功能。目前的资料：

sipeed 中的资料：https://wiki.sipeed.com/hardware/zh/lichee/RV_Nano/5_peripheral.html
PINOUT 表（看表中的 1.管脚信息表（QFN））： https://github.com/sophgo/sophgo-hardware/blob/master/SG200X/04_SG2002/04_SG2002_PINOUT.xlsx

今天摄像头到了，开发板还没到（分开运输的）。

[elliott10]

使用Cursor GPT 5.2 Codex对之前比赛的rk3588 npu驱动进行分析：

---

Rk3588 npu 驱动 c 到 rust 迁移仓库分析

---

User

请帮我分析一下这个项目：将rk3588硬件板子的linux npu驱动：kernel/drivers/rknpu 将这个C语言的NPU驱动，改写成了Rust语言的无系统依赖的驱动npu-driver-qcl/drivers， 其中的rknpu文件夹中是NPU驱动npu-driver-qcl/drivers/rknpu

---

Cursor

下面是对你描述的两个项目（C 版 Linux 内核驱动与 Rust 版无系统依赖驱动）的结构与对应关系分析，基于你给的路径与实际代码内容整理。

总体定位与目标

• Rust 版 rknpu 明确定位为“最小化设备层”，通过 OSAL 抽象系统依赖，仅保留硬件操作逻辑与 IOCTL 语义映射；这与 Linux 内核驱动的“完整设备驱动”方向不同。
  参考 README.md：功能范围、模块结构与“最小化设备层”的定位说明。

15:38:rknpu/README.md
# RKNPU Minimal Device Layer
...
## 模块结构
src/
├── lib.rs          # 主入口，对外API
├── osal.rs         # 操作系统抽象层
├── hal.rs          # 硬件抽象层
├── memory.rs       # 内存管理器
├── device.rs       # 设备接口层
├── config/         # 配置管理
├── registers/      # 寄存器定义
└── err.rs          # 错误类型定义

Rust 端核心结构与职责

• 整体入口与动作分发：lib.rs 定义 Rknpu 主结构，提供 action() 等接口，保持与 C 版 rknpu_action 语义相近（但多数动作还未真正实现）。

10:112:rknpu/src/lib.rs
#![no_std]
...
pub struct Rknpu {
    base: Vec<RknpuCore>,
    ...
    iommu_enabled: bool,
    pub(crate) gem: GemPool,
}
...
pub fn action(&mut self, action: RknpuAction) -> Result<u32, RknpuError> {
    match action {
        RknpuAction::GetHwVersion => { ... }
        ...
        RknpuAction::SetBwPriority => { ... Err(RknpuError::InternalError) }
        ...
    }
}

• 寄存器定义与 MMIO 操作：Rust 用 tock-registers 封装寄存器访问，避免硬编码偏移。

1:179:rknpu/src/registers/mod.rs
//! Memory-mapped register definitions for the Rockchip NPU.
...
pub struct RknpuCore {
    base: NonNull<u8>,
}
...
pub fn submit_pc(&mut self, config: &RknpuData, args: &SubmitRef) -> Result<(), RknpuError> {
    ...
    self.pc().operation_enable.set(1);
    mb();
    self.pc().operation_enable.set(0);
    ...
}

• 设备配置参数移植：Rust 的 RknpuData::new_3588() 直接体现了 C 驱动里 rk3588_rknpu_config 的关键字段，如 dma_mask=40、pc_data_amount_scale=2 等。

55:74:rknpu/src/data/mod.rs
fn new_3588() -> Self {
    Self {
        bw_priority_addr: 0x0,
        bw_priority_length: 0x0,
        dma_mask: dma_bit_mask(40),
        pc_data_amount_scale: 2,
        pc_task_number_bits: 12,
        pc_task_number_mask: 0xfff,
        pc_task_status_offset: 0x3c,
        pc_dma_ctrl: 0,
        irqs: RK3588_IRQS,
        nbuf_phyaddr: 0,
        nbuf_size: 0,
        max_submit_number: (1u64 << 12) - 1u64,
        core_mask: 0x7,
        ...
    }
}

• 内存/GEM 机制简化：Rust 版用 dma_api::DVec 直接做 DMA buffer 池，替代 Linux DRM GEM / DMA heap 体系。

1:53:rknpu/src/gem.rs
pub struct GemPool {
    pool: BTreeMap<u32, DVec<u8>>,
    handle_counter: u32,
}
...
pub fn create(&mut self, args: &mut RknpuMemCreate) -> Result<(), RknpuError> {
    let data = DVec::zeros(...);
    ...
    args.dma_addr = data.bus_addr();
    args.obj_addr = data.as_ptr() as _;
    self.pool.insert(args.handle, data);
    Ok(())
}

• IOCTL 语义结构映射：Rust ioctrl.rs 与 C 的 rknpu_ioctl.h 是一一对应的数据布局（#[repr(C)]），如 RknpuMemCreate、RknpuSubmit 等。

35:114:rknpu/src/ioctrl.rs
#[repr(C)]
pub struct RknpuSubmit {
    pub flags: u32,
    pub timeout: u32,
    pub task_start: u32,
    pub task_number: u32,
    ...
    pub subcore_task: [RknpuSubcoreTask; 5],
}

51:136:rknpu/include/rknpu_ioctl.h
enum e_rknpu_job_mode { ... };
enum e_rknpu_action { ... };
struct rknpu_mem_create { ... };

• OSAL 现状：README 描述了 OSAL trait，但实际代码里 osal.rs 目前只有类型与错误定义，未看到 trait 定义或实现逻辑（可能还未完成）。

1:23:rknpu/src/osal.rs
//! Operating System Abstraction Layer (OSAL) ...
pub type PhysAddr = u64;
pub type DmaAddr = u64;
pub type TimeStamp = u64;
pub enum OsalError { ... }

C 版 Linux 驱动的主要职责（对照用）

• C 版驱动完整依赖 Linux 内核子系统：IRQ、devfreq、PM、IOMMU、DRM GEM、DMA heap、waitqueue 等。
• rknpu_drv.h 中的 rknpu_device 结构体现了复杂的 Linux 管理逻辑与平台依赖。

114:180:rknpu/include/rknpu_drv.h
struct rknpu_device {
    void __iomem *base[RKNPU_MAX_CORES];
    struct device *dev;
    ...
    struct devfreq *devfreq;
    unsigned long current_freq;
    unsigned long current_volt;
    ...
    struct iommu_domain *iommu_domains[RKNPU_MAX_IOMMU_DOMAIN_NUM];
    ...
};

核心差异与可见的“简化点”

• 设备管理：C 版依赖 Linux 设备模型；Rust 版没有设备生命周期、驱动注册与 sysfs 相关逻辑。
• 内存管理：C 版走 GEM/heap；Rust 版是 GemPool + DVec 的轻量化替代。
• IOMMU/电源/时钟：C 版有完整 IOMMU、PM、clock、devfreq；Rust 版仅保留状态字段与 TODO/日志提示。
• 中断处理：C 版使用 IRQ 子系统注册 handler；Rust 版仅保留 handle_interrupt() 和 new_irq_handler() 的入口，外部需自行集成。
• OSAL：README 宣称 OSAL 抽象接口，但实际代码里只有类型定义（可能后续才补齐）。

大致模块映射关系（Rust -> C）

• src/lib.rs ↔ rknpu_drv.c（设备主入口/动作分发）
• src/data/mod.rs ↔ rknpu_drv.c 中的 rknpu_config
• src/registers/* ↔ rknpu_ioctl.h 的寄存器偏移 + C 侧硬编码操作
• src/ioctrl.rs ↔ rknpu_ioctl.h
• src/gem.rs ↔ rknpu_gem.c / rknpu_mem.c
• src/job.rs / src/task/* ↔ rknpu_job.c（任务提交与调度）

---

[pengzechen]

sg2002 的应该是tpu。
sg2002 的tpu应该重点就两部分 tdma 和 tiu，比3588的简单。

[Ticonderoga2017]

1. 板子刚到，上电之后电脑没识别到任何信息，经请教发现缺少usb转换模块，连夜购买转接线
2. 借助AI分析移植到SG2002板卡可供参考的平台包：
   • [Ticonderoga2017/axplat-riscv64-visionfive2 (github.com)](https://github.com/Ticonderoga2017/axplat-riscv64-visionfive2)
   • [axplat_crates/platforms/axplat-riscv64-qemu-virt at main · Ticonderoga2017/axplat_crates (github.com)](https://github.com/Ticonderoga2017/axplat_crates/tree/main/platforms/axplat-riscv64-qemu-virt)
3. 开始尝试编译Starry OS

[elliott10]

C906虚拟内存

sg2002开发板使用了平头哥的C906的CPU。

根据Linux源码中的riscv架构相关代码部分，在构建虚拟内存页表项时，需要分别为内核镜像内存地址空间和设备地址空间进行额外的页表flags属性。具体如下：

• 为内核镜像内存地址空间PAGE_KERNEL添加相比普通页表的额外的flags属性位：bit[62] CACHE,bit[61] BUF，bit[60] SHARE；

• 为设备地址空间PAGE_IOREMAP添加额外的属性：bit[63] SO，bit[60] SHARE;

这些页表项的额外的flags属性位，可以通过查询C906芯片手册获知其定义信息，如下图，C906额外页面属性位于63:59位，包括了SO, CACHE, BUF, SHARE, SEC

根据其他CPU芯片手册，可知道这些平头哥CPU的拓展属性，不单在C906中存在，在C910 CPU中也同样存在。

平头哥CPU自定义的页表的额外的flags属性位，通过查找芯片手册，可以在拓展状态寄存器MXSTATUS中找到了相应的设置位MAEE。C906 CPU的MAEE拓展位可以设置是否打开拓展的MMU地址属性，即是否使能拓展MMU中PTE的地址属性SO, CACHE, BUF, SHARE, SEC

默认在打开maee的状态时，可以在页表项PTE中设置对应位，这里需要注意内核镜像和设备地址空间所设置的PTE额外属性值不同。

更多的请见： 平头哥C910的页表项拓展属性位

[yfblock]

搜索了一下之前参加比赛的时候对 C906 的支持，想起来 C906 在读写内存之后需要进行 dcache 的刷新，否则会产生异常。可能在 Starry 的移植过程中遇到这个问题，https://gitlab.eduxiji.net/202310464101015/oskernel2023-byteos/-/blob/on-site-qemu/arch/src/riscv64/addr.rs#L195

[pengzechen]

我梳理了一下linux tpu驱动，主要重写下 cvi_tpu_interface.c 和 tpu_platform.c 就行。

[elliott10]

在sg2002物理板子上，调通Cursor生成的BSP代码，发现还是有不少错误需要根据实际运行情况作修改。如地址，中断设置等
sg2002 BSP仓库放在：https://github.com/elliott10/axplat-riscv64-sg2002.git
在StarryOS上编译参数：

make ARCH=riscv64 APP_FEATURES=sg2002 MYPLAT=axplat-riscv64-sg2002 LOG=debug BUS=mmio UIMAGE=y build

[yfblock]

尝试做了 sg2002 上的辅助核心支持，SG2002 一共有四个核心 (1GHz C906 和 1GHz A53 二选一) + 700MHz C906 辅助核心 + 8051。尝试启动了 700MHz 的辅助核心，但是和大核之间无硬件缓存一致性的支持，所以直接作为 AP 核心比较麻烦，也许可以在大小核上分别启动一个 Linux 和一个 ArceOS。

[Ticonderoga2017]

尝试实现WiFi驱动模块，但目前还存在诸多问题，如：CMD53扩展IO指令超时，SDIO错误等，正在调试
https://github.com/Ticonderoga2017/sg2002-wifi-driver.git

[Ticonderoga2017]

目前WiFi驱动初始化已完成，开始调试信号扫描和接收处理

[Ticonderoga2017]

AIC8801芯片WiFi驱动开发日志：

1. 包含以下模块：
   1. 主驱动接口，配置管理，GPIO控制，网络设备接口
   2. SDIO协议栈
   3. AIC8800芯片驱动
   4. IEEE 802.11协议栈
2. 当前已完成的功能：
   1. 驱动初始化，包括：
      1. GPIO初始化
      2. SDIO设备初始化
      3. AIC8801芯片初始化
      4. 固件加载
   2. 扫描局域网
      1. 驱动发送扫描请求
      2. 固件响应请求
      3. 固件返回响应结果并交给驱动处理
3. TODO：
   1. 将驱动的几个模块分成独立的crate
   2. 解决目前固件加载问题
   3. 调试网络连接和数据传输
   4. 优化响应延迟
   5. 人机交互
      项目地址：https://github.com/Ticonderoga2017/sg2002-wifi-driver.git

[Ticonderoga2017]

关于固件加载问题：

1. 第一种方案是直接从LicheeRV-Nano-Build里面提取固件，但是在加载过程中发现缺少fmacfw_patch.bin，原因可能是LicheeRV-Nano-Build默认从文件系统加载固件，而不是使用内嵌数组，因为有些芯片版本可能不需要这个补丁？
2. clone了固件仓库（https://github.com/lxowalle/aic8800-sdio-firmware.git）来获取固件和补丁
   基于以上工作，完善了系统配置，固件和补丁版本验证，完整性验证和固件启动逻辑，从日志输出中可以看到系统配置正确，固件匹配且完整，固件启动，但启动后没有收到确认消息，进一步的调试和验证正在进行中

[elliott10]

FreeRTOS正常运行于小核, 如下图：
注: alios在当前板子的sdcard，发现并不能正常启动。原因应该在于该alios仓库只为特定EVB板型试验。

[elliott10]

编译选项打开’CONFIG_ENABLE_FREERTOS’

[Ticonderoga2017]

WiFi模块当前开发进展：已验证开放网络连接，加密网络四次握手AP拒绝M2帧问题暂时未解决
为sg2002平台实现PLIC支持：https://github.com/Ticonderoga2017/StarryOS/tree/sg2002/axplat-riscv64-sg2002；
WiFi模块完整实现：https://github.com/Ticonderoga2017/StarryOS/tree/sg2002/wireless，WiFi功能实现在fdrv crate下，并提供sdio驱动以支持WiFi功能

[elliott10]

2026-04-01 有关sg2002机器人手臂的交流纪要

@李明  @xiaoxiao  @御风  @泽辰  @stone-san 和@chyyuu 对2002机器人的工作进行了探讨，形成的初步分工。请@xiaoxiao@御风@泽辰@stone-san 在github discussion上进行工作进展的记录和技术方案的讨论。
我们争取能在这个月内完成如下目标：

1. 基于linux的机器人能够移动并捡起网球
2. 基于Starry的机器人能移动并捡起网球
3. 基于Starry的机器人比基于Linux的机器人在同样操作的流程中有某些方面的优势

• 目标概述：
  1. 完成 SG2002 平台上Starry的基本驱动；
  2. 实现视觉识别， 完成小球图像识别能力；
  3. TPU驱动的AI推理加速；
  4. 最终实现小车机械臂在Starry上的自动捡球应用；
  5. 在打通sg2002平台的识别并运动控制，到稳定性验证， 含异常重启等条件，尝试AI编程工具进行迭代；

---

初步分工

YJB

• 负责摄像头识别, 实现小球图像的识别；
• 尝试继电器实现板子重启方案；
• 对 UART、PWM等接口进行硬件验证。

SZH

• 负责与 PZC 对接需求与接口；在 Linux 系统上先行把“自动捡球”应用跑起来，形成可执行的Linux基线版本。

XLY

• 尝试在小核上运行 RTOS，并实现整机重启功能；
• 逐步整合现有驱动到统一仓库，降低后续协作成本。
  sg2002平台的支持及整合驱动的仓库放在：
  https://github.com/elliott10/StarryOS/tree/sg2002-dev
  并写了一个指导文档供参考：
  https://github.com/elliott10/axplat-riscv64-sg2002/blob/main/get-started.md

[pengzechen]

PZC

• 将原有tpu代码整理成单独crate，供萧老师集成
• 将原有ion也尝试整理为单独crate
• 协助志航跑通用户态机械臂程序

[pengzechen]

@yfblock 我看了你的aka0仓库，我觉得是不是可以添加抽象保留原来的摄像头的逻辑，兼容uart传输？

[pengzechen]

wifi传输的抽象可以放弃了，这个我已经验证过了。2002开热点性能不太行

[yfblock]

目前已经完成了 StarryOS 在 sg2002 上实现图像采集、识别到控制机器抓取的全流程，相关仓库如下：

https://github.com/yfblock/StarryOS/tree/sg2002
https://github.com/yfblock/axplat-riscv64-sg2002-1/tree/sg2002
https://github.com/yfblock/aka0
https://github.com/yfblock/arceos/tree/sg2002

esp32 固件如下：

https://github.com/yfblock/esp32-cam-firmware

esp32-cam 的 uart0 连接到 sg2002 的 uart3 上，电机连接 pwm 4 5 6 7 芯片上，舵机控制连接在 uart2 上。

由于 sg2002 的 uart0 被复用为 pwm 4 5，所以在使用的时候如果需要调试，需要将 https://github.com/yfblock/StarryOS/blob/646f5ba6e874a63138ba1238e593f116d4cbcd34/api/src/vfs/dev/robo_ctl.rs#L265-L272 注释掉。

esp32 firmware 中含有测试的 python 文件，如果有usb 转串口可以在电脑上尝试，但是经过 usbipd 或者虚拟化后在 1.5Mbps 下可能会有问题（Linux x86_64 也是如此）。

如果 Starry 的调试信息输出过多可能会导致接收数据异常（由于 log 的时候会关闭中断，而串口信息通过中断接收，如果串口大量快速发送消息那么超过缓冲区后就会丢失数据，在整合 dma 后会恢复正常）

[yfblock]

yfblock/sg200x-bsp@e31bd95 已经加入了 dma 控制器代码并且在 Starry 上测试了 uart 的 dma 操作，在目前小数据量的时候可以正常发送。大数据量和接收正在尝试。

[pengzechen]

esp32-cam wifi 固件：https://github.com/[pengzechen/esp32_camera_mjpeg_multiclient](https://github.com/pengzechen/esp32_camera_mjpeg_multiclient)
目前WiFi版本的固件经过测试，可以连续正常工作4个小时。要使用稳定的电源

[pengzechen]

小车 “摄像头捕获 推理 控制” Loop 效率最值得优化的点是模型量化。 200ms -> 50ms 大概能快四倍

[elliott10]

对系列的sg2002硬件平台支持的组件库，进行了修改整合提交，方便其他大库进行同步过去。 涉及到的StarryOS 适配 SG2002 的所有组件修改的说明：https://github.com/elliott10/axplat-riscv64-sg2002/blob/main/doc/sg2002-porting-components.md

[elliott10]

具体的组件修改如下：
arceos axdriver的添加存储的mbr分区表支持：arceos-org/arceos#364
axdriver_block存储设备驱动，基于yjb驱动库：arceos-org/axdriver_crates#27
axcpu更新了对sstatus寄存器拓展属性的设置； 并在进入用户空间前刷新所有指令cache：arceos-org/axcpu#36
对页表项的拓展的修改pr：arceos-org/page_table_multiarch#46
发布了串口驱动：https://crates.io/crates/dw_uart_rs
发布了sg2002硬件平台支持包： https://crates.io/crates/axplat-riscv64-sg2002
发布独立的sg2002 tpu加速驱动库 https://crates.io/crates/tpu-sg2002

[Ticonderoga2017]

WiFi驱动初试版本目前已开发完成，受限于TCP拥塞控制和PIO传输模式，数据传输平均速度约1.4Mbps。
下一步计划：1. 代码风格优化，2. 支持SDIO DMA

[pengzechen]

使用esp32+drv8833做了一块编码电机驱动板。目前可正常驱动两个电机。
pengzechen/encoder_motor

[pengzechen]

编码电机可以方便获得小车轨迹和位置。
另外后续act模型可以传入实时电机速度，可以训练出更好的模型。
硬件上面原有的n20电机容易坏，和志航调车的时候就坏了多次，新的tt编码电机不容易坏比较稳。
自己做的编码电机驱动板向上暴漏一个uart口，比原方案少占用两个口。
缺点：
成本比原来贵了8块。
要烧录一下32的程序。

[elliott10]

小核运行freertos，并使用uart1串口，可以通过串口交互，通过reboot重启系统。实现了串口给sg2002关机重启的功能。
以下bootloader镜像，替换原版的文件/boot/fip.bin
https://github.com/elliott10/freertos/releases/download/tag-sg200x-dev-202508/fip_rtos.bin

[elliott10]

[pengzechen]

这个工作目前可能只作为研究学习了。李老师这边要量产的板子没小核，uart1目前是用来控制小车底盘

[elliott10]

补齐sstatus/mstatus寄存器上的一些位的设置，VS(（sg2002上设置,enable vector status bits), UBE, UXL等。
在riscv正式仓库提交PR请见：rust-embedded/riscv#396

[elliott10]

2026-04-16 SG2002机器人开发讨论纪要

• 通过AI开发方式，yjb在 sg2002 板子上支持了有线网，并能通过curl访问starry的网页

• 对于板子重启问题，使用的继电器控制来控制设备的开关；

• pzc提到杜邦线连sdio传输jpg编码图片有比较慢的问题，

• 讨论到，其他还有SPI或USB方式传图像的可行方法；

• 当前板子硬件口占用情况：

  • UART3 - 连接esp32摄像头；
  • Port 16, 17 - 作为开发调试串口；
  • UART1 - 控制底盘轮子；
  • UART2 - 控制机械臂；

• pzc在starry添加了一个穿透的串口驱动，实现从用户态程序来控制2个底盘轮子，这样编码电机可以方便获得小车轨迹和位置，也能释放一个sg2002的UART串口；原理是esp32作为pwm的输入，从esp读编码电机的输出，来控制轮子电机；

• 李老师处目前在开发3个SOC：sg2002, 另一个只有riscv核的算能芯片cv1812c-p, 还有3588

• szh在sg2002机器人上，基于GC4653摄像头，跑通了Linux基线版本。讨论到starry还只支持esp32摄像头，GC4653没有驱动，所以需要在Linux上同步试验esp32摄像头的情况；

• 讨论到，作为starry系统与Linux的性能对比，建议集成同一套用户态实现，系统走通摄像头取帧，包括从esp32摄像头。获得整个通路的延时，公平对比及作为后期优化的目标；

[Ticonderoga2017]

WiFi驱动开发已完成，crates路径如下：
arceos,增加了动态注册网络设备接口：https://github.com/Ticonderoga2017/sg2002-arceos.git
axplat,增加了PLIC支持和mmio配置参数：https://github.com/Ticonderoga2017/axplat-riscv64-sg2002.git
sdhci-cv1800,SD控制器：https://github.com/Ticonderoga2017/sdhci-cv1800.git
sdio,SDIO协议抽象层：https://github.com/Ticonderoga2017/axdriver_sdio.git
firmware，固件层：https://github.com/Ticonderoga2017/aic8800_fw.git
fdrv，驱动层：https://github.com/Ticonderoga2017/aic8800_fdrv.git
api，封装了顶层接口：https://github.com/Ticonderoga2017/aic8800_wireless.git
common，封装了驱动层和固件层一些公共常量：https://github.com/Ticonderoga2017/aic8800_common.git

[Ticonderoga2017]

解决了一些线程竞态问题，最新测试结果，上传速度4Mbps，下载速度接近20Mbps，各项功能接口正常