1. 这块200元价位的板子到底能干什么瑞昱RTL8735B这颗芯片在圈子里其实不算新面孔但真正把它当主力开发板来折腾的人并不多。大多数人第一次接触它是在一些网络摄像头、智能门铃或者低功耗视觉终端的主板上看到一颗印着Realtek字样、周围围着DDR和Flash的小芯片然后就没再深究。直到最近两年边缘AI推理的需求往下沉大家才开始重新审视这类“不起眼但什么都有”的SoC——RTL8735B就是典型代表。它本质上是一颗面向物联网视觉场景的SoC集成了CPU、NPU、ISP、视频编解码器和丰富的外设接口。你可以把它理解成一个“视觉专用的小型电脑”CPU负责跑系统逻辑NPU负责跑神经网络推理ISP负责处理摄像头原始信号视频编解码器负责把画面压成H.264/H.265码流。这四块能力凑在一起就构成了一个完整的“采集—处理—推理—编码—传输”链路。200元左右的开发板通常会把DDR、Flash、Wi-Fi模组、摄像头接口、TF卡槽、USB口都焊好你拿到手基本就能跑起来。那它到底能做什么最直接的场景就是1080P视频流加AI推理同时跑。比如做一个智能门禁摄像头采集1080P画面NPU实时检测人脸检测到人之后把画面编码成H.265通过Wi-Fi推出去同时本地保存一段录像。整个过程不需要云端参与延迟可以压到几百毫秒以内。再比如做工业质检摄像头对着流水线NPU跑缺陷检测模型发现异常就触发报警并抓拍。这些场景的共同特点是——需要视频需要AI但对算力要求不算极端功耗和成本又卡得很死。RTL8735B正好卡在这个位置上。适合谁来参考这篇内容如果你是有一定嵌入式基础、玩过STM32或者ESP32、想往视觉AI方向进阶的开发者这块板子是个不错的跳板。如果你是完全零基础的小白建议先补一下Linux基础操作和C语言否则后面配环境、编译固件、调摄像头参数会比较吃力。如果你是企业里做方案选型的工程师这篇内容可以帮你判断这颗芯片能不能满足你的产品需求以及大概要投入多少人力。我拿到板子之后的第一感受是它的资料不像树莓派那么“保姆级”但也没有想象中那么难啃。瑞昱官方提供了一套SDK里面包含了BSP、驱动、示例代码和编译工具链。社区里也有不少人在分享踩坑记录。真正花时间的地方在于——你要搞清楚它的启动流程、内存布局、摄像头通路和NPU模型转换流程。这几块搞明白了后面就是搭积木。2. 核心架构拆解为什么它能同时跑视频和AI2.1 CPU、NPU、ISP、编解码器各自的分工RTL8735B的架构可以拆成四条并行的流水线。第一条是CPU子系统通常是一颗ARM Cortex-A系列核心具体型号不同批次略有差异主频在几百MHz到1GHz之间跑的是轻量级Linux或者RTOS。它的任务不是做重计算而是做调度管理内存、控制外设、协调各模块之间的数据流。你可以把它当成一个“工头”自己不搬砖但要知道谁在搬、搬到哪。第二条是NPU这是整颗芯片里最值钱的部分。它的算力通常在0.5TOPS到1TOPS之间具体取决于型号和频率支持INT8量化推理。这个算力放在手机里不值一提但在200元价位的开发板上属于“够用”级别。跑一个MobileNetV2做图像分类或者跑一个轻量级YOLO做目标检测帧率可以做到15到30帧。关键是它不占CPU资源CPU可以同时去处理网络协议栈和文件系统。第三条是ISP图像信号处理器。摄像头传感器输出的是Bayer格式的原始数据必须经过ISP做去马赛克、白平衡、降噪、锐化、伽马校正才能变成人眼看起来正常的画面。RTL8735B的ISP支持最高1080P30fps的输入支持自动曝光和自动白平衡。如果你直接用CPU去软处理这些根本跑不动。ISP是硬件单元不占CPU周期。第四条是视频编解码器支持H.264和H.265的硬件编码和解码。1080P30fps的H.265编码码率可以压到2Mbps左右画质还能接受。这个模块也是硬件的CPU只需要把YUV数据喂给它它自己完成压缩然后通过DMA把码流写到内存里。四条流水线并行工作才使得“1080P视频流AI推理”同时跑成为可能。2.2 内存带宽和DDR布局对性能的影响很多人忽略的一点是视频和AI同时跑瓶颈往往不在算力而在内存带宽。1080P的YUV420画面一帧大概是3MB左右。30帧就是90MB/s的读写量。NPU推理时还要读模型权重、写中间特征图又是几十MB/s。编码器读YUV、写码流再占一部分。如果DDR带宽不够就会出现丢帧、推理延迟抖动、编码卡顿。RTL8735B开发板通常板载DDR3或DDR4容量从128MB到512MB不等。我手上这块是256MB DDR3实测下来同时跑1080P视频和MobileNetV2推理内存带宽占用大概在60%到70%之间还有余量。但如果你把NPU模型换成更大的比如ResNet50或者把视频分辨率提到4K带宽就会吃紧。所以选型时要关注两个参数DDR容量和DDR位宽。位宽越大带宽越高。一般32位位宽的DDR3在400MHz频率下理论带宽是1.6GB/s实际可用大概60%到70%。另外内存布局也很关键。SDK里通常会划分几块保留内存一块给NPU的权重和特征图一块给ISP的帧缓冲一块给编码器的码流缓冲。这些保留内存不参与Linux的内存管理是物理连续的。你在写应用的时候要确保摄像头采集的buffer、NPU输入的buffer、编码器输入的buffer尽量复用减少拷贝次数。我见过有人在每一帧都做一次memcpy结果帧率直接掉一半。正确的做法是用DMA-BUF或者ION内存让各模块直接共享同一块物理内存。2.3 视频通路的完整数据流从摄像头到网络数据要经过这样几条路传感器通过MIPI CSI或DVP接口把Bayer数据送给ISPISP处理后输出YUV420到内存。然后分两路一路给NPU做推理一路给编码器做压缩。NPU输出的是检测框和类别编码器输出的是H.264/H.265码流。最后CPU把码流打包成RTSP或者RTMP协议通过Wi-Fi发出去。这条链路里最容易出问题的是ISP到NPU这一路。因为NPU通常要求输入是RGB格式而ISP输出的是YUV。如果你在CPU里做YUV转RGB一帧1080P大概要几十毫秒根本来不及。所以SDK里一般会提供一个硬件转换模块或者让NPU直接支持YUV输入。我在调试的时候就遇到过这个问题NPU推理结果一直不对后来发现是YUV转RGB的公式用错了导致颜色通道颠倒。换成硬件转换之后结果就正常了。还有一点是帧同步。摄像头采集、NPU推理、编码器编码这三个环节的帧率不一定完全一致。如果NPU推理慢就会导致编码器拿到的帧是旧的画面和检测框对不上。解决办法是用一个帧队列每个环节从队列里取帧处理完再放回去。队列长度一般设3到5帧太短容易丢帧太长延迟高。3. 上手实操从零跑通第一个AI推理Demo3.1 开发环境搭建与SDK编译第一步是装工具链。瑞昱的SDK通常自带一个预编译的GCC工具链解压之后把bin目录加到PATH里就行。我建议在Ubuntu 20.04或者22.04上做开发因为SDK里的脚本大多是基于bash写的Windows下用WSL也可以但USB设备透传有时候会抽风。装好之后用arm-linux-gnueabihf-gcc -v确认一下版本能打印出来就说明OK。第二步是拿SDK。官方SDK一般是一个大的压缩包里面分几个目录bootloader、kernel、rootfs、apps、npu。bootloader是启动引导kernel是Linux内核rootfs是根文件系统apps是示例应用npu是NPU相关的库和模型转换工具。编译顺序一般是先编bootloader再编kernel再编rootfs最后编apps。每个目录下都有一个build.sh或者makefile直接跑就行。这里有个坑SDK里的编译脚本有时候会依赖一些特定的库版本比如libssl-dev、libncurses-dev、python2之类的。如果你用的是比较新的Ubuntu可能默认没有python2需要手动装一下。另外编译内核的时候可能会报“missing header”之类的错误一般是内核配置里少选了某个选项去menuconfig里补上就行。第三步是烧录。开发板通常支持TF卡启动或者USB烧录。TF卡启动最简单把编译好的镜像写到TF卡里插上板子上电就能跑。USB烧录需要用瑞昱提供的烧录工具在Windows下运行把bootloader、kernel、rootfs依次写进Flash。我建议先用TF卡启动因为方便改改坏了重新写卡就行不用怕把板子刷成砖。3.2 摄像头配置与1080P视频流验证板子跑起来之后第一件事是确认摄像头能不能出图。SDK里一般会带一个v4l2-ctl工具用v4l2-ctl --list-devices看看有没有识别到摄像头设备。如果识别到了用v4l2-ctl --device/dev/video0 --set-fmt-videowidth1920,height1080,pixelformatYUYV设置格式然后用v4l2-ctl --stream-mmap --stream-count10 --stream-totest.yuv抓10帧存成文件。抓完之后用ffmpeg或者yuvplayer看一下能出正常画面就说明摄像头通路没问题。如果不出图先查三个地方一是摄像头排线有没有插反MIPI CSI的排线方向很容易搞错二是设备树里有没有使能对应的CSI控制器和传感器节点三是供电够不够有些摄像头模组功耗比较大USB供电可能带不动需要外接电源。我遇到过一种情况摄像头识别到了但抓出来的图全是绿的。后来发现是ISP的自动白平衡没启动手动设置一下增益就正常了。1080P视频流验证可以用RTSP。SDK里通常带一个rtsp_server示例跑起来之后在电脑上用VLC打开rtsp://板子IP:8554/stream就能看到画面。如果画面卡顿先看Wi-Fi信号强度再看编码码率是不是设得太高。1080P30fps的H.265码率设2Mbps到4Mbps比较合适。设太高Wi-Fi带宽不够设太低画质糊。3.3 NPU模型转换与推理部署NPU推理的第一步是模型转换。瑞昱的NPU通常支持ONNX或者TensorFlow Lite格式的模型但需要经过它自己的转换工具转成专用格式。转换工具一般在SDK的npu/tools目录下用法大概是./convert --modelmodel.onnx --outputmodel.rknn --quantizeint8。量化是关键INT8量化可以把模型体积压到原来的四分之一推理速度提升两到三倍精度损失一般在1%到3%之间。如果你的模型对精度要求很高可以用FP16但速度会慢一些。转换的时候要注意输入尺寸。NPU通常要求输入是固定尺寸的比如224x224或者416x416。如果你的模型输入是动态尺寸转换工具可能会报错。解决办法是在转换前把模型固定成某个尺寸或者在推理前把图像resize到指定尺寸。resize这一步可以在CPU里做也可以用硬件加速。我一般用CPU做因为resize的计算量不大1080P缩到416x416大概几毫秒。模型转好之后把它放到板子的文件系统里然后在应用里调用NPU的API加载模型、创建推理上下文、喂数据、取结果。SDK里一般会带一个npu_demo跑起来之后会打印推理耗时和结果。我第一次跑MobileNetV2的时候单帧推理耗时大概30毫秒也就是30帧左右。后来把CPU频率锁到最高耗时降到25毫秒。再后来把DDR频率也锁高降到22毫秒。所以频率调节对性能影响挺大的建议在跑推理之前先把CPU和DDR的governor设成performance。3.4 视频流与AI推理同时跑的调优记录同时跑视频流和AI推理最大的挑战是资源竞争。我一开始的做法是摄像头采集线程、NPU推理线程、编码线程各跑各的结果帧率很不稳定有时候掉到10帧以下。后来用top和perf看了一下发现CPU大部分时间花在内存拷贝上。因为每个线程都在做自己的buffer分配和释放导致内存碎片和缓存失效。优化方案是改成流水线模式一个采集线程负责从摄像头取帧放到一个环形队列里一个推理线程从队列取帧做推理把结果写到共享内存一个编码线程从队列取帧做编码把码流写到另一个队列一个发送线程从码流队列取数据通过网络发出去。队列用信号量做同步buffer用ION内存预分配避免运行时分配。改完之后帧率稳定在25帧以上CPU占用从80%降到50%左右。还有一个调优点是NPU的批处理。如果你的应用允许一定延迟可以把多帧攒在一起做批推理比如一次推理4帧。这样NPU的利用率更高但延迟会增加。我实测下来批大小为4的时候单帧平均耗时从22毫秒降到15毫秒但延迟从22毫秒增加到60毫秒。如果你的场景对延迟不敏感比如录像分析可以用批处理如果对延迟敏感比如实时监控就用单帧。4. 踩坑实录与常见问题排查4.1 摄像头不出图、花屏、颜色异常的排查思路摄像头问题占了新手求助的一大半。我把常见现象和原因整理成一张表方便对照排查。现象可能原因排查方法设备节点不存在排线没插好、设备树没使能检查排线方向用dmesg看内核日志出图全黑镜头盖没开、曝光时间太短手动设置曝光检查镜头出图全绿白平衡没启动、YUV格式不对手动设置增益确认pixelformat花屏、撕裂带宽不够、DDR频率太低降低分辨率提高DDR频率帧率低USB带宽不够、CPU占用高换MIPI接口关掉无关进程我印象最深的一次是摄像头出图正常但NPU推理结果全是乱的。查了半天发现是ISP输出的YUV顺序是NV12而NPU要求的是NV21两者UV分量顺序相反。改了一下配置就好了。这种问题不看文档根本想不到但一旦踩过就记住了。4.2 NPU推理精度下降的常见原因INT8量化之后精度下降是正常现象但如果下降太多比如从90%掉到60%那就有问题了。常见原因有三个一是量化校准集选得不好校准集应该覆盖实际场景的分布不能随便拿几张图凑数二是某些层的量化敏感度太高比如第一层和最后一层可以对这些层保留FP16三是输入预处理不一致训练时用的归一化参数和推理时用的不一样。我的做法是先用FP16跑一遍确认模型本身没问题再用量化工具做INT8对比精度如果掉太多就逐层分析把敏感层挑出来保留FP16。瑞昱的转换工具一般支持混合精度可以在配置文件里指定哪些层用FP16。这样可以在速度和精度之间取一个平衡。4.3 视频编码延迟与网络传输卡顿视频编码延迟主要来自三个地方编码器本身的缓冲、码流队列的缓冲、网络发送的缓冲。编码器一般会缓冲几帧再做码率控制这个缓冲可以调小但太小会导致码率波动大。码流队列我一般设2到3帧太多延迟高太少容易丢帧。网络发送用UDP比TCP延迟低但UDP会丢包需要自己加重传或者前向纠错。Wi-Fi传输卡顿最常见的原因是信道干扰。2.4G频段干扰严重建议用5G频段。如果板子只支持2.4G那就把信道固定到1、6、11这三个互不重叠的信道之一避开邻居的Wi-Fi。另外Wi-Fi的省电模式也会导致延迟抖动把power_save关掉会好很多。4.4 开发板发热与长时间运行稳定性RTL8735B在同时跑视频和AI的时候功耗大概在2W到3W之间芯片表面温度可以到60度以上。如果散热不好会触发降频性能直接掉一半。我建议加一个小散热片或者用金属外壳辅助散热。如果是在密闭环境里最好加一个小风扇。长时间运行稳定性方面我遇到过内存泄漏的问题。跑十几个小时之后系统变慢最后OOM。用valgrind查了一下发现是某个线程里的buffer没有释放。嵌入式开发里这种问题很常见因为很多人习惯用malloc但忘了free。建议在开发阶段就打开内存检测工具或者用静态分析工具扫一遍代码。5. 这套方案还能怎么扩展5.1 多路摄像头输入的可能性RTL8735B通常支持一路MIPI CSI和一路DVP理论上可以接两个摄像头。但两路同时跑1080P带宽和NPU算力都会吃紧。如果非要双路建议一路1080P做AI推理另一路720P做录像或者两路都降到720P。SDK里一般有双路采集的示例但需要自己改设备树和驱动配置。5.2 模型剪枝与量化进一步压缩如果你觉得INT8量化之后模型还是太大可以试试剪枝。剪枝就是把模型里不重要的权重去掉让模型变稀疏。剪枝之后需要重新训练微调精度会掉一点但模型体积可以再压30%到50%。瑞昱的NPU对稀疏模型的支持情况需要查一下文档不是所有NPU都支持稀疏加速。5.3 本地存储与断网续传如果网络不稳定可以在本地TF卡上做录像缓存网络恢复之后再上传。TF卡的写入速度要够Class 10以上比较稳妥。录像文件可以按时间分片比如每5分钟一个文件方便管理和续传。断网续传的逻辑可以用一个简单的队列实现录像文件先写本地上传成功之后打标记定期清理已上传的文件。5.4 与云端协同的混合推理架构如果本地NPU算力不够可以把一部分推理放到云端。比如本地只做目标检测把检测框对应的区域裁剪出来上传到云端做精细分类。这样既减少了上传带宽又利用了云端的强算力。RTL8735B的Wi-Fi和网络协议栈支持这种架构关键是要设计好任务拆分和结果合并的逻辑。我个人在实际操作中的体会是这颗芯片的潜力比它看起来要大但前提是你愿意花时间啃SDK和调参数。它不像树莓派那样开箱即用但一旦跑通性价比确实很高。如果你正在找一个能同时跑视频和AI的低成本方案RTL8735B值得一试。最后再分享一个小技巧调试的时候把串口日志级别调到最高很多问题看日志就能定位比盲猜快得多。