瑞昱RTL8735B这颗芯片在安防和边缘视觉圈子里其实不算新面孔但真正把它做成一块两百元级别、能同时跑1080P视频流和AI推理的开发板市面上并不多见。我最早注意到它是因为一个做智能门铃的朋友抱怨传统方案要么用高算力主控加独立ISP成本压不下来要么用低端MCU加外挂摄像头视频编码和AI推理只能二选一。RTL8735B的出现恰好卡在这个缝隙里——它把ISP、H.264编码器、NPU和Wi-Fi蓝牙全部塞进一颗SoC外围只需要加DDR、Flash和少量电源器件就能出图。这篇文章不打算复述官方数据手册而是从实际拿到板子、点亮摄像头、跑通视频流、部署AI模型这条完整链路出发把每一步的选型逻辑、踩过的坑和实测数据摊开来讲。如果你正在评估边缘视觉方案或者手头有一块RTL8735B开发板不知道怎么下手下面的内容应该能帮你省下不少试错时间。1. 先搞清楚RTL8735B到底适合做什么1.1 这颗芯片的定位不是通用开发板很多人拿到RTL8735B开发板的第一反应是把它当成树莓派或者ESP32-S3那样的通用平台想在上面跑Ubuntu、接显示器、装各种软件包。这个预期从一开始就偏了。RTL8735B是一颗面向电池供电视觉终端的SoC它的设计目标非常明确在极低功耗下完成图像采集、视频编码和轻量级神经网络推理然后把结果通过Wi-Fi或蓝牙送出去。它跑的是FreeRTOS或者厂商提供的RTOS SDK不是Linux。这意味着两件事。第一你不需要考虑开发板挂载Ubuntu这类操作它的软件栈是裸机或RTOS级别的启动时间通常在几百毫秒量级。第二它的AI推理能力有明确边界——NPU算力在0.5TOPS左右具体数值以官方最新文档为准适合跑MobileNetV2、YOLO-Fastest、NanoDet这类轻量模型不要指望它跑YOLOv8s以上的模型还能保持实时帧率。我实测下来这块板子最舒服的场景是1080P30fps的H.264编码推流 同时以5到10fps的频率跑一个人形检测或人脸检测模型。这个组合覆盖了智能门铃、IP摄像头、宠物看护、婴儿监控等大量实际需求。1.2 和ESP32-S3、K230这些热门方案的差异市面上经常被拿来对比的是ESP32-S3加摄像头方案和K230开发板。我三个平台都实际用过说几个关键差异。ESP32-S3的优势是生态成熟、资料多、社区活跃但它的短板在视频编码——它没有硬件H.264编码器做1080P视频流只能靠JPEG逐帧传输或者软编码帧率和画质都受限。RTL8735B有独立硬件编码器1080P30fps的H.264码流是实打实硬编出来的CPU占用极低。K230的AI算力比RTL8735B强不少能跑更复杂的模型但它的功耗和外围成本也更高而且视频编码链路和AI推理的并行调度需要更细致的调优。如果你的产品是插电使用的K230更合适如果是电池供电、对功耗敏感RTL8735B的优势就出来了。下面这张表是我实测三块板子在1080P视频流场景下的粗略对比对比项RTL8735BESP32-S3K230硬件H.264编码支持1080P30fps不支持支持NPU算力约0.5TOPS无专用NPU约1TOPS典型功耗视频AI300-500mW500-800mW800mW-1.2W开发环境RTOS SDKESP-IDFLinuxRTOS适合场景电池视觉终端轻量IoT图像插电边缘AI注意上表功耗数据是我用USB功率计在典型工作负载下读到的平均值不同固件版本和外围配置会有波动仅供参考。1.3 两百元价位到底买到了什么拆开一块典型的RTL8735B开发板你能看到的核心器件包括RTL8735B主控、一颗DDR通常是DDR2或DDR3L容量64MB到128MB、SPI Flash8MB到16MB、Wi-Fi天线接口、MIPI CSI摄像头接口、USB接口、TF卡槽、麦克风和扬声器接口。有些版本还会带以太网PHY。这个配置在两百元价位算是相当扎实的。DDR容量决定了你能同时开多大的帧缓冲和模型内存占用64MB是底线128MB会舒服很多。SPI Flash决定了固件和模型文件能放多少8MB勉强够用16MB可以放两个模型做切换。我建议在购买前确认三个参数DDR容量、Flash容量、摄像头接口类型。有些低价版本用的是SPI摄像头接口而非MIPI画质和帧率会打折扣。2. 从零搭建开发环境的完整路径2.1 工具链安装中最容易卡住的地方瑞昱为RTL8735B提供的SDK通常基于GCC工具链在Linux环境下开发最顺畅。我用的是Ubuntu 22.04Windows下通过WSL2也能跑通但USB设备直通偶尔会抽风建议还是用原生Linux或者虚拟机。安装步骤大致是下载SDK包、解压、运行环境配置脚本、安装交叉编译工具链。这里有个坑——SDK里自带的工具链版本和系统GCC版本可能有冲突如果你系统里已经装了其他ARM工具链PATH变量顺序不对会导致编译时调用错误的编译器。我的做法是在SDK目录下单独开一个终端手动export工具链路径不污染全局环境。# 假设SDK解压在 ~/rtl8735b_sdk cd ~/rtl8735b_sdk export PATH$PWD/toolchain/bin:$PATH export CROSS_COMPILEarm-none-eabi- # 验证工具链 arm-none-eabi-gcc --version编译第一个固件之前先确认menuconfig或者类似的配置工具能正常打开。如果打开时报ncurses相关错误装一下libncurses5-dev就行。2.2 烧录方式的选择与实操RTL8735B开发板通常支持两种烧录方式USB烧录和SD卡烧录。USB烧录速度快适合开发阶段频繁迭代SD卡烧录适合量产或者现场升级。USB烧录需要进入下载模式一般是按住某个按键再上电或者短接特定引脚。烧录工具是瑞昱提供的专用软件Windows版本比较成熟Linux下通常用命令行工具。我第一次烧录时卡了很久原因是USB线只支持充电不支持数据传输换了一根带数据线的才识别到设备。这个坑很低级但很常见建议先用lsusb确认系统能不能看到设备。SD卡烧录的流程是把编译出的固件按特定命名规则放到SD卡根目录插入板子上电后bootloader会自动检测并烧录。这个方式的好处是不依赖USB驱动但要注意SD卡格式必须是FAT32exFAT和NTFS都不认。2.3 串口调试的配置细节串口是调试RTL8735B最重要的通道。板子上一般会引出一个UART接口通过USB转串口模块连接到电脑。波特率通常是115200或者1500000具体看SDK配置。我习惯用minicom或者picocom配置如下# 查看串口设备 ls /dev/ttyUSB* # 用picocom连接波特率1500000 picocom -b 1500000 /dev/ttyUSB0提示如果串口输出乱码九成是波特率不对。RTL8735B的bootloader阶段和RTOS阶段的波特率可能不同注意看SDK文档里的说明。串口日志里会打印启动流程、内存分配、摄像头初始化状态等关键信息。养成看串口日志的习惯很多问题在日志里都有明确提示比盲目猜效率高得多。3. 1080P视频流跑通的每一步3.1 摄像头选型与MIPI CSI配置RTL8735B支持MIPI CSI接口的摄像头模组常见搭配是OV5647、GC2053、IMX307等。选摄像头时重点看三个参数分辨率、接口类型、供电电压。1080P30fps是基本要求接口必须是MIPI CSI不是SPI供电通常是1.8V和2.8V双路。接线时注意MIPI的差分线对要等长虽然开发板上通常已经做好了走线匹配但如果你自己画转接板这点很关键。我第一次自己画转接板时没注意等长出图有横纹折腾了两天才找到原因。SDK里配置摄像头的流程一般是初始化MIPI控制器、配置摄像头寄存器的初始化序列、设置输出格式和分辨率。初始化序列通常由摄像头厂商提供是一大串I2C寄存器写入操作。这部分代码SDK里一般有现成的你只需要确认分辨率参数和你的摄像头匹配。3.2 H.264编码参数怎么调硬件编码器的配置直接决定视频流的画质和带宽。关键参数有四个码率、GOP长度、帧率、编码档次。码率方面1080P30fps在H.264 High Profile下2Mbps到4Mbps是比较合理的范围。太低会糊太高浪费带宽。我实测2Mbps在室内场景下画质可接受4Mbps在运动场景下明显更清晰。GOP长度决定关键帧间隔通常设为帧率的1到2倍也就是30到60。GOP太短会导致码率飙升太长会导致丢包后恢复慢。如果是网络推流场景建议GOP设为30。// 典型的编码器配置结构伪代码具体字段名以SDK为准 enc_cfg.bitrate 2048; // 单位kbps enc_cfg.gop 30; enc_cfg.fps 30; enc_cfg.profile H264_HIGH; enc_cfg.rc_mode RC_CBR; // 恒定码率注意CBR恒定码率适合网络推流VBR可变码率适合本地存储。如果你的场景是RTSP推流用CBR更稳。3.3 RTSP推流的实现与延迟优化把H.264码流通过RTSP推出去是最常见的需求。SDK里通常有RTSP服务器的示例代码你需要做的是把编码器输出的码流喂给RTSP的发送队列。延迟优化有几个关键点。第一编码器输出不要攒太多帧再发一帧编完就发。第二RTSP的发送缓冲区不要设太大否则延迟会累积。第三TCP和UDP的选择——UDP延迟低但可能丢包TCP可靠但延迟高。局域网内建议UDP公网建议TCP。我实测在局域网内从摄像头采集到RTSP客户端显示端到端延迟可以做到150ms到250ms。如果超过500ms检查是不是缓冲区设大了或者网络有问题。3.4 实测帧率与资源占用用top或者SDK自带的性能监控工具看1080P30fps编码时CPU占用大约在30%到40%DDR带宽占用约40%。这个数据说明芯片还有余量跑AI推理。帧率稳定性方面我连续跑了2小时帧率波动在28到30fps之间没有明显掉帧。发热方面主控表面温度在45度左右室温25度不需要额外散热片。4. AI推理部署的实际操作4.1 模型选型什么模型能跑什么跑不动RTL8735B的NPU对模型结构有偏好。实测下来MobileNetV2的分类模型和YOLO-Fastest、NanoDet的检测模型跑得比较顺。输入分辨率建议控制在224x224到320x320之间超过416x416帧率会明显下降。我试过跑YOLOv5n输入320x320帧率只有3到4fps而且内存占用接近极限。换成NanoDet之后同样输入分辨率能到8到10fps精度损失在可接受范围内。模型转换工具链通常是瑞昱提供的把ONNX或者TFLite模型转成NPU能识别的格式。转换过程中要注意算子支持列表有些算子NPU不支持会回退到CPU速度会慢很多。转换工具一般会输出哪些算子被映射到了NPU哪些回退了这个日志要仔细看。4.2 模型量化与精度取舍NPU通常只支持INT8量化模型。把FP32模型量化成INT8精度会有损失但速度提升明显。量化过程中需要一批校准数据通常从你的实际场景里抽几百张图就行。我做人形检测时量化后的模型在测试集上mAP掉了大约3个百分点但帧率从4fps提升到了9fps。这个取舍在大多数场景下是值得的。提示量化校准数据要覆盖你的实际使用场景。如果你用室内数据校准拿到室外用精度会掉得更多。4.3 视频流和AI推理的并行调度这是整个项目里最考验工程能力的地方。视频编码和AI推理都要占用DDR带宽和CPU时间调度不好会互相拖累。我的做法是编码器优先级高于AI推理。因为视频流是实时的掉帧用户立刻能感知AI推理结果晚一两帧影响不大。具体实现上编码任务放在高优先级线程AI推理放在低优先级线程中间用消息队列传递帧数据。另外不要对每一帧都做AI推理。1080P30fps的流抽帧做推理就行比如每3帧或每5帧推理一次。这样AI推理的负载降低到6到10fps和视频编码互不干扰。// 抽帧推理的简单逻辑 if (frame_count % 3 0) { // 把当前帧送到AI推理队列 ai_queue_push(current_frame); } frame_count;4.4 推理结果怎么和视频流叠加如果你需要把检测框画在视频流上有两种做法。一种是在编码前把框画到YUV数据上这样客户端收到的流就带框另一种是把推理结果通过单独通道发给客户端客户端自己叠加。第一种做法简单直接但会占用CPU做YUV绘制。第二种做法对板子更友好但客户端要做额外工作。我一般推荐第二种因为板子的CPU资源更宝贵。如果一定要在板子上画框建议用硬件加速的2D图形模块如果芯片有的话比纯CPU绘制快很多。5. 那些文档里不会写的踩坑记录5.1 DDR带宽被吃满导致的诡异现象有一次我同时开了1080P编码和AI推理发现视频流每隔几秒卡一下串口日志里没有报错。排查了很久最后用带宽监控工具发现DDR带宽在卡顿时刻接近100%。原因是AI推理的模型权重加载和编码器的帧缓冲读写抢带宽。解决办法是把模型权重常驻内存不要每次推理都重新加载同时把编码器的帧缓冲数量从4个减到3个释放一些带宽。这个问题的诡异之处在于它不报错只是性能下降如果没有带宽监控工具很难定位。5.2 摄像头初始化失败的几种原因摄像头出不来图按以下顺序排查I2C通信是否正常——用示波器或者逻辑分析仪看I2C波形确认地址和时序对。MIPI时钟是否锁定——串口日志里通常有MIPI PHY的锁定状态。供电是否达标——摄像头模组的1.8V和2.8V要用万用表实测不能只看原理图。初始化序列是否匹配——不同批次的摄像头模组寄存器序列可能不同找厂商要对应版本的。我遇到过最坑的一次是摄像头模组的地线没接好I2C能通但MIPI出图有噪点查了两天才发现是接地问题。5.3 固件升级后配置丢失RTL8735B的配置通常存在Flash的特定分区里。如果你烧录新固件时选择了全片擦除配置分区也会被清掉需要重新配置Wi-Fi、摄像头参数等。建议在烧录工具里只擦除固件分区保留配置分区。如果必须全擦提前把配置导出备份。5.4 Wi-Fi吞吐量对视频流的影响1080P30fps的H.264码流在2Mbps到4Mbps之间理论上Wi-Fi完全能承载。但实际测试中如果Wi-Fi信号弱或者周围干扰多吞吐量会波动导致视频流卡顿。我的建议是用5GHz频段如果板子支持干扰少、吞吐稳定。如果只能用2.4GHz把码率降到2Mbps并且开启编码器的抗丢包模式。另外Wi-Fi的省电模式要关掉省电模式会导致周期性休眠视频流会一顿一顿的。6. 这套方案的成本与适用边界6.1 物料成本拆解以两百元的开发板为基础加上摄像头模组约30到50元、天线约5元、外壳和电源约20元整套硬件成本在260到280元之间。如果做产品化去掉开发板上的调试接口和多余器件PCBA成本可以压到150元以内。对比同功能的Linux方案比如全志V831或者瑞芯微RV1106RTL8735B的方案在功耗上有优势但开发灵活性不如Linux方案。选哪个取决于你的产品定位。6.2 什么场景不适合这块板子如果你的需求包含以下任何一条RTL8735B可能不是最佳选择需要跑YOLOv8s以上的大模型需要接多个摄像头同时编码需要本地存储高码率视频比如4Mbps以上连续录制需要复杂的用户交互界面需要Linux下的丰富软件生态这些场景更适合算力更强的Linux平台。RTL8735B的甜点区就是单摄像头、1080P编码、轻量AI推理、电池供电这个组合。6.3 从开发板到产品的距离开发板跑通不等于产品能落地。从开发板到产品你还需要处理电源管理电池充放电、低功耗休眠唤醒、结构设计散热、防水、镜头视场角、固件OTA升级、量产测试每块板子的摄像头校准、Wi-Fi校准。其中OTA升级是最容易被低估的环节。RTL8735B的Flash分区设计要提前规划好留出足够的空间给OTA备份。我见过不少项目因为Flash分区没规划好后期加OTA功能时不得不换更大容量的Flash。电源管理方面如果做电池供电产品要充分利用芯片的休眠模式。实测在休眠模式下功耗可以降到几十微安级别配合PIR传感器唤醒电池续航可以做到几个月。整体来说RTL8735B是一颗被低估的芯片。它的算力不算强生态不算丰富但在低功耗视觉终端这个细分场景里它提供的集成度和性价比确实很难找到替代品。如果你正好在做这类产品值得花时间把它吃透。