用Go语言搞定DM365通过USB传输视频，这事儿其实挺接地气的

如果你手头有个老款的TI DM365开发板，想把它当成一个“USB摄像头”用，把采集到的视频流通过USB线传到电脑上，然后用Go语言来读取、处理甚至推流——这听起来是不是有点像科技宅的周末小项目？其实这事做起来没想象中那么玄乎,但确实有一些坑需要绕过去。

先搞清楚DM365和USB传输的关系

DM365这颗芯片，本身是TI家的达芬奇系列，主打视频编解码和图像处理，它自带USB 2.0 OTG接口，这意味着它既能当主机（比如接U盘），也能当外设（比如被电脑识别成设备），我们要做的，就是把DM365伪装成一个UVC（USB Video Class）设备,让电脑觉得你插了个摄像头上去。

这步很关键，因为Linux内核里自带UVC驱动，如果DM365能正确枚举成UVC设备，那电脑端根本不需要装驱动，直接用/dev/video0就能读视频流。

硬件上怎么接线？

小提示：有些开发板需要额外给USB_DP加上1.5kΩ上拉电阻，不然电脑可能检测不到设备，我当初就因为这个折腾了一下午，差点以为芯片坏了。

DM365端：配置内核，变成UVC设备

DM365跑的是嵌入式Linux（一般是2.6.32或3.x内核），要让它变成UVC设备,得在内核配置里打开这几个选项：

Device Drivers → USB support → USB Gadget Support
  → [*] USB Gadget Drivers
  → <M> USB Video Class (UVC) Gadget
  → [*] UVC Gadget: Video streaming support

然后编译进内核或者作为模块加载，加载模块的时候,还要指定参数：

modprobe g_uvc

这时候插上USB线，电脑上应该能识别到一个名为“UVC Camera”的设备，用lsusb能看到类似：

Bus 001 Device 003: ID 0525:a4a2 Netchip Technology, Inc. Linux-USB UVC Gadget

如果没出现，多半是硬件识别问题，检查上面表格里的接线,特别是ID引脚的电平。

视频源怎么给到USB Gadget？

DM365的摄像头接口（一般是Parallel接口或BT.656）接到CMOS传感器（比如OV9712），采集到的原始视频数据，需要经过V4L2框架处理，然后送到UVC Gadget的缓冲区。

这里有个非常关键的步骤：V4L2采集的格式必须匹配UVC Gadget支持的格式，UVC Gadget通常支持YUYV或MJPEG，我踩过最大的坑就是采集了RGB格式，然后UVC直接静默——没报错,就是不出画面。

在DM365上，可以这样用v4l2-ctl测试：

v4l2-ctl -d /dev/video0 --set-fmt-video=width=640,height=480,pixelformat=YUYV

然后在另一个终端启动UVC Gadget的流：

echo streamon > /sys/kernel/debug/uvc-gadget/stream

要是运气好，电脑上用cheese或者ffplay /dev/video0就能看到画面了。

电脑端：用Go语言读取视频流

好了，现在DM365已经变成了一个USB摄像头，在电脑上，它显示为/dev/video0（Linux）或某个COM口（Windows，但Windows下UVC走的是DirectShow，比较麻烦，推荐Linux开发）。

Go语言里读/dev/video0，最直接的办法是调用v4l2的ioctl，不过相比直接用C写，Go里可以用github.com/blackjack/webcam这个库，它封装了V4L2的常用操作,省得自己去纠结ioctl的参数结构体。

package main
import (
    "fmt"
    "image"
    "image/jpeg"
    "os"
    "github.com/blackjack/webcam"
)
func main() {
    cam, err := webcam.Open("/dev/video0")
    if err != nil {
        panic(err)
    }
    defer cam.Close()
    // 设置格式，要和DM365端一致
    format := cam.GetSupportFormats()[0] // 假设第一个是YUYV
    _, _, err = cam.SetImageFormat(format.PixelFormat, 640, 480)
    if err != nil {
        panic(err)
    }
    err = cam.StartStreaming()
    if err != nil {
        panic(err)
    }
    defer cam.StopStreaming()
    for i := 0; i < 100; i++ {
        err = cam.WaitForFrame(5) // 5秒超时
        if err != nil {
            continue
        }
        frame, err := cam.ReadFrame()
        if err != nil {
            continue
        }
        // 如果是MJPEG格式，可以直接解压成图片
        if format.PixelFormat == webcam.PixelFormatMJPEG {
            img, _, err := image.Decode(bytes.NewReader(frame))
            if err == nil {
                f, _ := os.Create(fmt.Sprintf("frame_%d.jpg", i))
                jpeg.Encode(f, img, nil)
                f.Close()
                fmt.Printf("保存了第%d帧\n", i)
            }
        }
    }
}

这代码我现场写的，可能有个别拼写错误，但思路是对的，实际跑的时候要注意权限问题——/dev/video0默认只有root能读，记得sudo或者把用户加到video组。

性能优化：别让DM365的USB带宽成为瓶颈

DM365的USB 2.0理论速度是480Mbps，但实际跑视频流的时候，YUYV 640x480@30fps大概要147Mbps，MJPEG压缩后能降到20~50Mbps，所以强烈建议在DM365上输出MJPEG格式，不然USB带宽可能扛不住,掉帧会很明显。

在DM365内核里，UVC Gadget的传输端点（endpoint）的缓冲区大小也可以调，在drivers/usb/gadget/uvc_queue.c里：

#define UVC_QUEUE_BUFFER_SIZE      (1920 * 1080 * 2)  // 默认2MB，够了

还有一点：DM365的RAM通常只有128MB或256MB，视频缓存区分配太多会导致系统其他进程OOM，建议分配2~4个v4l2 buffer，每个512KB~1MB,不要贪多。

如果画面延迟很大怎么办？

这是个老问题，DM365本身编解码有硬件加速，但通过USB传输会引入USB传输延迟和UVC驱动内部队列的延迟，我自己的测试，大概有100ms~200ms的延迟，如果做实时监控还行，但做互动场景（比如直播答题）就有点勉强。

解决办法：

1. 减少UVC Gadget内部的缓冲区数量（降低到2个）
2. 在DM365上手动丢弃部分帧（比如只传输25fps,不要30fps）
3. 电脑端用零拷贝技术（mmap模式读取,不要内存复制）

Go语言里用webcam库默认就是mmap模式,所以这点上Go反而有优势。

遇到过的奇葩问题和对策

• 电脑识别出设备但没画面：检查DM365上摄像头模块是否正常工作，用v4l2-ctl --all看格式是否匹配。
• 画面是绿的或花的：YUYV和MJPEG搞混了，UVC Gadget内部可以同时支持两种格式，但电脑端的应用（比如Chrome或ffplay）可能只认一种,建议固定为MJPEG。
• 传输中断，/dev/video0消失：DM365的USB驱动偶尔会挂掉，加个看门狗脚本，定时检测并重置USB Gadget模块。
• Go程序卡死：多半是WaitForFrame超时没有正确处理，加个graceful shutdown的goroutine。

文献参考

• TI DM365 DaVinci媒体处理器技术参考手册（SPRU977）
• Linux UVC Gadget驱动文档，位于内核源码Documentation/usb/gadget_uvc.txt
• V4L2规范，由Linux Media Subsystem维护

其实说这么多，真上手搞一遍比看十篇文章都管用，我当时是把一块吃灰的DM365开发板拆出来，焊了根USB线，然后用Go写了不到200行代码，居然真的把图像传到了电脑屏幕上——那一刻感觉还挺奇妙的，虽然后来发现延迟有点高，画面还有点偏色，但从0到1的快乐，比什么都值。

你手头的DM365要是也闲置着，不妨试试这个路子，不一定非得跑出完美高清，光是看到“活的画面”在屏幕上动起来,那个感觉就够了。