简介这是面向创龙C6678多核DSP开发者的TCP图像传输完整工程包解决PC端通过NDK发送图像、DSP端接收并处理的核心场景。资源共159个文件压缩包约14.29MB包含C/C源码、H头文件、CCS工程配置、编译链接脚本mak/mk/bld、XML及cfg配置文件以及中间编译产物obj/out等既可直接参照工程结构复现实验也能通过源码学习Socket通信、图像编码解码与C6678多核任务划分。已有355人学习下载。内容覆盖从PC端TCP客户端到DSP服务器端的传输链路配套资源管理、平台初始化与网络配置模块适合正在做DSP网络通信、图像采集传输或异构平台联调的工程师和嵌入式学习者可快速理解NDK在DSP上的移植要点、数据包重组与性能优化思路并根据自身需求改造为稳像、识别等图像处理应用。 做 DSP 算法的人应该都有过这种经历算法在 PC 端仿真跑得飞快一上板子就抓瞎。想喂一张测试图像进去要么通过仿真器在 CCS 里一点一点查看内存向量要么把图像转成 C 数组硬编译进工程换一张图就要重新编译一次一个下午就这么耗进去了。这个标题为NDK_TCP电脑发图像DSP接收的项目做的其实就是一条更省心的路电脑作为发送端通过 TCP 把图像数据直接丢给 DSP 板卡DSP 这边用网口接收任务收下完整一帧再交给后面的算法处理。标题里这个 NDK我在群里见过不少新人误以为是 Android 的 Native Development Kit连 Termux 装 ndk r27 那套交叉编译工具链都能扯进来。其实在 DSP 领域它指的是 TI 的 Network Developers Kit也就是 TI 为自家处理器提供的 TCP/IP 网络协议栈。先把这个概念对齐后面看资料才不会云里雾里。这篇文章要讲的就是这个电脑端发图 DSP 端收图项目的完整链路从为什么选 TCP、NDK 怎么配置到图像封包、socket 接收、拼帧处理再到现在实际测试中很容易踩的坑我都按实战过程展开。适合正在做 DSP 网络化传输的工程师、想给算法板子加网口的同学以及所有被图像数据进不去板子折磨过的人。1. 项目全景为什么需要一个电脑发图像、DSP 接收的通道1.1 仿真器之外的另一条路很多人习惯用 CCS XDS 仿真器把数据直接灌进 DSP 内存这在调试算法逻辑的早期没有任何问题。但一旦你的算法要迭代几十上百张图或者板子已经装进设备里、根本没有仿真器接口这条路就断了。项目量产之后不可能给每台设备都留一个 JTAG 下载口更不可能让现场工程师抱着一台 CCS 去操作。网络接口则不同它既能跑协议栈又能传大块数据还能顺便做远程更新、参数配置、结果回传是仿真器之外最值得投入的方向。我从 C6748 开始接触 NDK后来又把它挪到多核 C6678 上最大的感受是一旦 DSP 上跑起了 TCP/IP 协议栈它就不再是必须用仿真器才能喂数据的黑盒子而是一个标准网络节点。你可以用 Python、C、Matlab 甚至手机 App把图像数据传过去这对算法联调和产品部署都是质的改变。1.2 这套系统由哪几部分组成完整跑通这个项目实际需要三大部分发送端PC 上的发送程序C / Python 均可负责读入图像、按自定义格式封包、通过 TCP 发送传输通道以太网。开发时多用网线直连 PC 与 DSP 板链路较复杂的环境再介入交换机接收端DSP 板卡包括以太网 PHY 芯片、EMAC 控制器、TI NDK 协议栈以及我们自己在 SYS/BIOS 里创建的接收任务。硬件方面TI C6748、C6678 这类带 EMAC 接口的芯片都能跑 NDK。DSP 端不走协议栈也可以直接用 lwIP 裸跑但如果你用的是 SYS/BIOS 系统TI 自家的 NDK 集成度更高不用自己操心底层信号量、任务调度和缓存一致性细节。1.3 选型前先回答TCP 还是 UDP图像数据不比普通状态报文它是几千字节到几兆字节的大块载荷丢一个包就可能让整幅画面花掉丢多次包算法甚至会直接退出。这也是这个项目选择 TCP 的最核心理由。TCP 建立连接前有著名的三次握手SYN、SYNACK、ACK交换完初始序号之后才进入数据传输。后续的数据发送自带 ACK 确认与超时重传能保证字节流有序、无错地到达对端。代价是协议开销大、内存占用更高。UDP 则是发了就不管内存占用低、实时性强但丢包后没有补救手段。对于通用图像传输场景我建议直接用 TCP后续要做视频流时再考虑在 UDP 之上加序号、重传、前向纠错那是另一套设计不是这个项目的第一版该操心的事。2. TI NDK网络协议栈在 DSP 上怎么落地2.1 NDK 由哪三层组成很多资料把 NDK 当黑盒子用我觉得至少要理解它的三层结构否则真出了问题连日志都不知道去哪找协议栈核心即 TCP/IP 协议栈本身对外暴露 BSD 风格的 socket APIsocket()、bind()、listen()、accept()、send()、recv()这些接口在 DSP 上都能直接写风格跟 PC 端非常接近底层驱动NSP / EMAC负责把协议栈数据帧发到物理网口包括 PHY 初始化、中断处理、收发描述符管理系统集成层NDK 运行在 SYS/BIOS 之上它为协议栈分配任务、信号量、内存池把网络事件接到 SYS/BIOS 的事件机制上。也就是说NDK 不是简单的一个库文件它是一整套在 RTOS 环境下运行的网络服务。你在工程里启用它后系统里会多出几个网络任务recv()这类调用通常是阻塞在信号量上的并不占用额外的 CPU 轮询。2.2 CCS 工程里如何把 NDK 加进来以 CCS 里的 SYS/BIOS 工程为例。先在工程属性里确认有 NDK 产品组件然后在.cfg配置文件中启用 NDK 模块填写本机 IP 地址、网关、子网掩码。开发阶段我习惯用静态 IP例如 DSP 端固定为192.168.1.100子网掩码255.255.255.0网关可以留空这样调试时 PC 端不必依赖 DHCP 服务器。配置完成后代码里做这样几件事#include ti/ndk/inc/netmain.h #include ti/ndk/inc/netcfg.h NtwkInit(); NtwkStart();NtwkInit()会去读取配置文件中的网络参数NtwkStart()启动协议栈和网络任务。之后调用标准的socket()创建套接字即可。如果NtwkStart()之后 ping 都不通第一步是查看 PHY 的 link 状态寄存器第二步是查 IP 配置是否和 PC 处于同一网段这两类问题占了八成以上。这里再提醒一次网上搜NDK 配置十有八九出来的都是 Android 的 Native Development Kit——什么termux ndk r27、APP 交叉编译环境全是另一条线。TI 的 NDK 在 TI 官网叫 Network Developers Kit隶属于 Processor SDK 里 RTOS 组件下载时不要找错。3. 电脑端图像发送封包与 TCP 细节3.1 图像不是字节流要按帧组织TCP 是一个流式协议它只保证你收到的字节顺序正确但不保证一次send()对应对端的一次recv()。也就是说如果你只管把图像字节send()过去DSP 端收到的一定是一堆没有边界的字节流根本无法确定哪里是头、哪里是尾、图像宽高是多少。所以发送前必须先做分帧。我给这个项目定义了一个简单的帧格式供你参考字段长度说明magic4 字节固定值 0x5A5AA5A5用于识别帧起始width4 字节图像宽度网络字节序height4 字节图像高度网络字节序channels1 字节通道数灰度图填 1RGB 填 3data_len4 字节图像数据字节数即 widthheightchannelsdatadata_len 字节图像原始像素数据crc162 字节对 data 的校验可选严谨场景建议加字段统一使用大端字节序。原因是 TCP/IP 协议栈本身就是大端序DSP 处理器多为小端协定时统一用网络字节序DSP 端用ntohl()/ntohs()转换能避免后面踩到字节序匹配的坑。3.2 发送端代码框架我用 Python 写过一版最简发送端代码量很小适合先验证链路import socket import struct def send_image(host, port, img_bytes, width, height, channels): magic 0x5A5AA5A5 data_len len(img_bytes) header struct.pack(I, magic) header struct.pack(I, width) header struct.pack(I, height) header struct.pack(B, channels) header struct.pack(I, data_len) s socket.create_connection((host, port), timeout10) s.sendall(header) s.sendall(img_bytes) s.close()这里特意没有用一整条格式化字符串来 pack而是逐字段拼接。实际项目里很多人就是栽在这里结构体字段一多编译器对齐、格式串写错都会让 DSP 端解析错位。逐字段拼接虽然啰嗦但每一段都能在出错时单独对照文档排查稳。发送时用sendall()而不是send()。send()在系统发送缓冲区满时可能只发送部分数据你要自己维护偏移量sendall()内部帮你循环发完出错才抛异常。对于图像这种大块数据几乎一定会触发多次底层 send用sendall()省心得多。3.3 电脑与 DSP 的网络打通发送之前先把网络物理链路调通。PC 和 DSP 网口直连时PC 手动设置静态 IP例如192.168.1.50DSP 端按上一节配置成192.168.1.100。两边子网掩码一致即可通信。项目里如果经过交换机只要同网段也一样。连通性测试用ping 192.168.1.100通了以后再改用一个简单的 TCP 端口测试在 DSP 上监听某个端口PC 上直接telnet 192.168.1.100 8000。如果 ping 通但 telnet 不通问题基本都在 DSP 端 socket 监听逻辑或 PHY 驱动上。另外一个隐形元凶是 PC 防火墙尤其是 Windows 自带防火墙会拦截非常用端口的入站连接开发时可以先关闭再排查。4. DSP 端接收socket 流程与图像拼帧4.1 bind 到 recv 的嵌入式差异DSP 端的 socket 流程和 PC 端长得几乎一样socket(AF_INET, SOCK_STREAM, 0)然后bind()绑定端口listen()进入监听accept()等待连接最后recv()读取数据。但有几个嵌入式环境下特有的点要留意。第一accept 连接会占用系统资源。在 PC 上开几百个线程无压力DSP 上内存有限如果是点对点传输场景我建议只 accept 一次后续复用这个连接发完所有图像不要为每帧图像重新建立连接。频繁的 connect/close 会让协议栈积累 TIME_WAIT 状态的连接轻则端口占用报错重则拖垮 NDK 内存池。第二recv()要放在一个独立的 SYS/BIOS 任务里跑不要放在主循环轮询。NDK 的 socket 接口默认是阻塞式放在主循环里会把整个系统卡死。任务优先级可以设得偏中高但不能高于网络协议栈自身的任务否则可能出现调度问题。void recv_task(UArg a0, UArg a1) { int srv, cli; struct sockaddr_in addr; char buf[4096]; srv socket(AF_INET, SOCK_STREAM, 0); addr.sin_family AF_INET; addr.sin_addr.s_addr htonl(INADDR_ANY); addr.sin_port htons(8000); bind(srv, (struct sockaddr *)addr, sizeof(addr)); listen(srv, 1); cli accept(srv, NULL, NULL); while (1) { int n recv(cli, buf, sizeof(buf), 0); if (n 0) { process_bytes(buf, n); } else if (n 0) { break; // 对端关闭 } } }这段代码只演示流程实际拼帧不能用固定 4096 直接处理要看下一节。4.2 从 recv 到完整一帧拼包状态机TCP 流式传输意味着 DSP 端的一次recv()可能收到半帧、一帧或者好几帧。正确的做法是维护一个接收状态机先收帧头解析出 payload 长度再循环收满整个图像。enum { WAIT_MAGIC, WAIT_HEADER, WAIT_PAYLOAD }; static void process_payload(char *payload, int len); void process_bytes(char *buf, int n) { static int state WAIT_MAGIC; static char hdr[17]; static int hdr_off 0; static char *payload NULL; static int payload_len 0; static int payload_off 0; int i 0; while (i n) { switch (state) { case WAIT_MAGIC: if (n - i 4) { unsigned int magic ntohl(*(unsigned int *)(buf i)); if (magic 0x5A5AA5A5) { state WAIT_HEADER; hdr_off 0; } i 4; } else { i n; // 等下一包 } break; case WAIT_HEADER: while (i n hdr_off 17) { hdr[hdr_off] buf[i]; } if (hdr_off 17) { // 解析 width/height/channels/data_len payload_len /* data_len from hdr */; payload malloc(payload_len); payload_off 0; state WAIT_PAYLOAD; } break; case WAIT_PAYLOAD: while (i n payload_off payload_len) { payload[payload_off] buf[i]; } if (payload_off payload_len) { process_payload(payload, payload_len); free(payload); payload NULL; state WAIT_MAGIC; } break; } } }这个状态机还有一个好处它能正确处理 TCP 粘包。当一帧的结束和下一帧的 magic 同时出现在同一个 buf 里时外层while循环会继续消费剩余字节不会漏掉下一帧头。如果你发现收到的图像偶尔报宽高错误多半是 magic 判断太宽松把图像像素里的偶然数据误当成了帧头。实际项目中我会把 magic 设为 4 字节且带多个固定标志位这个误判率能压到非常低。4.3 字节序与 Cache 一致性C6748 是小端处理器而网络字节序是大端。帧头里的宽、高、长度都必须调用ntohl()转换。如果你发现 DSP 接收端解析出的宽高数值极大或为 0先怀疑字节序再怀疑结构体对齐这两个原因占了拼帧错乱的大部分情况。图像数据本身的每个像素是单字节不涉及字节序转换。但数据从网口 DMA 进内存后可能和 DSP 的 Cache 之间存在一致性问题。接收缓冲区如果放在普通 DDR 并用 Cache 加速网络 DMA 写入的数据对 CPU 不一定立即可见常见表现是收完一帧后打印出来头几个字节对、后面全是乱值。解决办法是把接收缓冲所在地址段配置为非 Cache通过 MAR 寄存器或者在读完数据后主动做Cache_inv()。这个坑在 C6678 这种带大 Cache 的多核芯片上比 C6748 更明显调通之前别急着优化速度。5. 实测中的坑连接失败、粘包和吞吐量瓶颈5.1 bind 报错端口被占用与地址重用DSP 端重启程序后经常会在bind()时遇到类似 only one usage of each socket address 的错误。原因是上一次连接在协议栈里残留了 TIME_WAIT 状态端口还没释放新进程直接bind()就会冲突。解决方法是监听 socket 在bind()之前设置地址重用int opt 1; setsockopt(srv, SOL_SOCKET, SO_REUSEADDR, (void *)opt, sizeof(opt));注意 TI NDK 对setsockopt的支持跟 Linux 并不完全一致有些版本对SO_REUSEADDR支持不全如果设置无效另一个土办法是把 DSP 的端口换一个或者等一段时间等连接自然超时。5.2 connect 超时PC 端连不上 DSPPC 端connect()一直超时最常见的是三类原因。第一DSP 没有进入监听状态代码执行到accept()了吗在 DSP 端加 log 确认。第二IP 不通ping 一下最直接。第三PC 防火墙拦截。Debug 顺序应该是先看网口 link 灯再看 ping再看端口最后才怀疑协议栈配置。不要一开始就去看代码。PC 端的connect()默认超时非常长因为 TCP 协议栈本身会重传 SYN开发调试时给socket.create_connection()显式传一个timeout5失败快一点能省很多等待时间。5.3 粘包与半包为什么收到的图有时花屏花屏有一个非常隐蔽的来源图像帧在 TCP 里传输时被合并或拆分如果 DSP 端没有按状态机拼帧而是直接假设一次 recv 就是一帧图大概率在图像尺寸稍大时出现数据错位。TCP 没有消息边界这不是协议 bug而是它天生的流式特性。解决办法就是我上一节写的拼帧状态机任何图像传输项目都绕不开这一步。另外一个建议帧头里加一个单调递增的帧序号。连续发多张图时DSP 端可以判断收到的帧序号是否连续丢帧或重复帧一目了然排查问题比只看图像内容和宽高高效得多。5.4 吞吐量上不去窗口、MTU 与缓冲我第一次用这套链路传输 720p 图像时帧率只有个位数折腾了很久才发现是多个因素叠加。这里给一张我排查时用的对照表现象可能原因排查或解决办法发送端大图卡在 sendall发送缓冲太小或对端 recv 慢增大 PC 端 SO_SNDBUF、DSP 端 SO_RCVBUF吞吐量长期上不去MTU 不统一、TCP 分片多两端都设 1500或同时启用巨帧要一致接收时 CPU 占用极高recv 循环里频繁分配内存预先分配接收池收完数据后复用图像数据乱值Cache 一致性问题配置 MAR 非 Cache 或 Cache_inv实话说DSP 单核平台做纯净 TCP 图像传输吞吐量很难和 PC 之间千兆网卡的满速比。工程上要抓重点确认用户需要的是实时视频流还是单帧高保真传输。前者往往要把 TCP 换成带丢包转发的专用协议后者则要针对 MTU、DMA 描述符做充分优化。项目标题这个 zip 包主要解决的是后者——让 DSP 能稳定收到电脑发来的单帧图像够算法用就成功了一多半。6. 从单帧图像到连续视频流项目还能怎么扩展6.1 双缓冲与帧序号单帧传通之后下一步自然是连发多帧。这时如果 DSP 端只有一个接收缓冲数据进来后必须立刻处理完才能收下一帧图像越大越容易丢帧。建议改成双缓冲一个 buffer 被网络任务填数据另一个 buffer 被算法任务读两个角色交替。帧序号同时承担乱序检测角色发现序号跳跃就清空当前缓冲避免把两帧图像拼成一张错乱的图。6.2 双向通道与控制指令电脑发图通常不只是单向的。算法处理完图像后需要把检测框、统计结果、处理耗时回传电脑。可以在同一个 TCP 连接上做双向传输发图走一个协议格式回传数据走另一个协议格式两者用不同的 magic 区分。这样上位机既能发图又能实时拿到 DSP 的结果联调效率会提升很多。我实际的做法是电脑端定义一个总控制协议报文第一字节是类型0x01表示图像数据0x02表示参数配置0x03表示状态查询。DSP 端收到后按类型分发到不同处理函数。往后做远程参数调整、算法内部状态观测全部复用这一条通道。6.3 一些想留给你的调试习惯最后分享一个我自己的土办法图像传输链路联调时别一上来就跑大图。先用16x16的纯色小图跑通全流程再把尺寸逐步放大。纯色图哪怕拼帧错了你也能从宽高字段、帧序号、打印日志上判断是头部解析问题还是数据搬运问题而不是对着花屏图像猜。我还会在 DSP 端的串口上打印每帧的收包状态每收齐一帧打一个点这个动作看似简单却能帮你快速定位问题到底出在网络层、拼帧层还是算法层。NDK、TCP、DSP 三个词放在一起看着硬核真正调通之后你会发现它不过是给算法板子开了一扇普通的网口而你要做的就是让图像数据在这条链路上有序地流动。本文还有配套的精品资源点击获取
DSP网络图像传输实战：NDK+TCP接收全链路解析
简介这是面向创龙C6678多核DSP开发者的TCP图像传输完整工程包解决PC端通过NDK发送图像、DSP端接收并处理的核心场景。资源共159个文件压缩包约14.29MB包含C/C源码、H头文件、CCS工程配置、编译链接脚本mak/mk/bld、XML及cfg配置文件以及中间编译产物obj/out等既可直接参照工程结构复现实验也能通过源码学习Socket通信、图像编码解码与C6678多核任务划分。已有355人学习下载。内容覆盖从PC端TCP客户端到DSP服务器端的传输链路配套资源管理、平台初始化与网络配置模块适合正在做DSP网络通信、图像采集传输或异构平台联调的工程师和嵌入式学习者可快速理解NDK在DSP上的移植要点、数据包重组与性能优化思路并根据自身需求改造为稳像、识别等图像处理应用。 做 DSP 算法的人应该都有过这种经历算法在 PC 端仿真跑得飞快一上板子就抓瞎。想喂一张测试图像进去要么通过仿真器在 CCS 里一点一点查看内存向量要么把图像转成 C 数组硬编译进工程换一张图就要重新编译一次一个下午就这么耗进去了。这个标题为NDK_TCP电脑发图像DSP接收的项目做的其实就是一条更省心的路电脑作为发送端通过 TCP 把图像数据直接丢给 DSP 板卡DSP 这边用网口接收任务收下完整一帧再交给后面的算法处理。标题里这个 NDK我在群里见过不少新人误以为是 Android 的 Native Development Kit连 Termux 装 ndk r27 那套交叉编译工具链都能扯进来。其实在 DSP 领域它指的是 TI 的 Network Developers Kit也就是 TI 为自家处理器提供的 TCP/IP 网络协议栈。先把这个概念对齐后面看资料才不会云里雾里。这篇文章要讲的就是这个电脑端发图 DSP 端收图项目的完整链路从为什么选 TCP、NDK 怎么配置到图像封包、socket 接收、拼帧处理再到现在实际测试中很容易踩的坑我都按实战过程展开。适合正在做 DSP 网络化传输的工程师、想给算法板子加网口的同学以及所有被图像数据进不去板子折磨过的人。1. 项目全景为什么需要一个电脑发图像、DSP 接收的通道1.1 仿真器之外的另一条路很多人习惯用 CCS XDS 仿真器把数据直接灌进 DSP 内存这在调试算法逻辑的早期没有任何问题。但一旦你的算法要迭代几十上百张图或者板子已经装进设备里、根本没有仿真器接口这条路就断了。项目量产之后不可能给每台设备都留一个 JTAG 下载口更不可能让现场工程师抱着一台 CCS 去操作。网络接口则不同它既能跑协议栈又能传大块数据还能顺便做远程更新、参数配置、结果回传是仿真器之外最值得投入的方向。我从 C6748 开始接触 NDK后来又把它挪到多核 C6678 上最大的感受是一旦 DSP 上跑起了 TCP/IP 协议栈它就不再是必须用仿真器才能喂数据的黑盒子而是一个标准网络节点。你可以用 Python、C、Matlab 甚至手机 App把图像数据传过去这对算法联调和产品部署都是质的改变。1.2 这套系统由哪几部分组成完整跑通这个项目实际需要三大部分发送端PC 上的发送程序C / Python 均可负责读入图像、按自定义格式封包、通过 TCP 发送传输通道以太网。开发时多用网线直连 PC 与 DSP 板链路较复杂的环境再介入交换机接收端DSP 板卡包括以太网 PHY 芯片、EMAC 控制器、TI NDK 协议栈以及我们自己在 SYS/BIOS 里创建的接收任务。硬件方面TI C6748、C6678 这类带 EMAC 接口的芯片都能跑 NDK。DSP 端不走协议栈也可以直接用 lwIP 裸跑但如果你用的是 SYS/BIOS 系统TI 自家的 NDK 集成度更高不用自己操心底层信号量、任务调度和缓存一致性细节。1.3 选型前先回答TCP 还是 UDP图像数据不比普通状态报文它是几千字节到几兆字节的大块载荷丢一个包就可能让整幅画面花掉丢多次包算法甚至会直接退出。这也是这个项目选择 TCP 的最核心理由。TCP 建立连接前有著名的三次握手SYN、SYNACK、ACK交换完初始序号之后才进入数据传输。后续的数据发送自带 ACK 确认与超时重传能保证字节流有序、无错地到达对端。代价是协议开销大、内存占用更高。UDP 则是发了就不管内存占用低、实时性强但丢包后没有补救手段。对于通用图像传输场景我建议直接用 TCP后续要做视频流时再考虑在 UDP 之上加序号、重传、前向纠错那是另一套设计不是这个项目的第一版该操心的事。2. TI NDK网络协议栈在 DSP 上怎么落地2.1 NDK 由哪三层组成很多资料把 NDK 当黑盒子用我觉得至少要理解它的三层结构否则真出了问题连日志都不知道去哪找协议栈核心即 TCP/IP 协议栈本身对外暴露 BSD 风格的 socket APIsocket()、bind()、listen()、accept()、send()、recv()这些接口在 DSP 上都能直接写风格跟 PC 端非常接近底层驱动NSP / EMAC负责把协议栈数据帧发到物理网口包括 PHY 初始化、中断处理、收发描述符管理系统集成层NDK 运行在 SYS/BIOS 之上它为协议栈分配任务、信号量、内存池把网络事件接到 SYS/BIOS 的事件机制上。也就是说NDK 不是简单的一个库文件它是一整套在 RTOS 环境下运行的网络服务。你在工程里启用它后系统里会多出几个网络任务recv()这类调用通常是阻塞在信号量上的并不占用额外的 CPU 轮询。2.2 CCS 工程里如何把 NDK 加进来以 CCS 里的 SYS/BIOS 工程为例。先在工程属性里确认有 NDK 产品组件然后在.cfg配置文件中启用 NDK 模块填写本机 IP 地址、网关、子网掩码。开发阶段我习惯用静态 IP例如 DSP 端固定为192.168.1.100子网掩码255.255.255.0网关可以留空这样调试时 PC 端不必依赖 DHCP 服务器。配置完成后代码里做这样几件事#include ti/ndk/inc/netmain.h #include ti/ndk/inc/netcfg.h NtwkInit(); NtwkStart();NtwkInit()会去读取配置文件中的网络参数NtwkStart()启动协议栈和网络任务。之后调用标准的socket()创建套接字即可。如果NtwkStart()之后 ping 都不通第一步是查看 PHY 的 link 状态寄存器第二步是查 IP 配置是否和 PC 处于同一网段这两类问题占了八成以上。这里再提醒一次网上搜NDK 配置十有八九出来的都是 Android 的 Native Development Kit——什么termux ndk r27、APP 交叉编译环境全是另一条线。TI 的 NDK 在 TI 官网叫 Network Developers Kit隶属于 Processor SDK 里 RTOS 组件下载时不要找错。3. 电脑端图像发送封包与 TCP 细节3.1 图像不是字节流要按帧组织TCP 是一个流式协议它只保证你收到的字节顺序正确但不保证一次send()对应对端的一次recv()。也就是说如果你只管把图像字节send()过去DSP 端收到的一定是一堆没有边界的字节流根本无法确定哪里是头、哪里是尾、图像宽高是多少。所以发送前必须先做分帧。我给这个项目定义了一个简单的帧格式供你参考字段长度说明magic4 字节固定值 0x5A5AA5A5用于识别帧起始width4 字节图像宽度网络字节序height4 字节图像高度网络字节序channels1 字节通道数灰度图填 1RGB 填 3data_len4 字节图像数据字节数即 widthheightchannelsdatadata_len 字节图像原始像素数据crc162 字节对 data 的校验可选严谨场景建议加字段统一使用大端字节序。原因是 TCP/IP 协议栈本身就是大端序DSP 处理器多为小端协定时统一用网络字节序DSP 端用ntohl()/ntohs()转换能避免后面踩到字节序匹配的坑。3.2 发送端代码框架我用 Python 写过一版最简发送端代码量很小适合先验证链路import socket import struct def send_image(host, port, img_bytes, width, height, channels): magic 0x5A5AA5A5 data_len len(img_bytes) header struct.pack(I, magic) header struct.pack(I, width) header struct.pack(I, height) header struct.pack(B, channels) header struct.pack(I, data_len) s socket.create_connection((host, port), timeout10) s.sendall(header) s.sendall(img_bytes) s.close()这里特意没有用一整条格式化字符串来 pack而是逐字段拼接。实际项目里很多人就是栽在这里结构体字段一多编译器对齐、格式串写错都会让 DSP 端解析错位。逐字段拼接虽然啰嗦但每一段都能在出错时单独对照文档排查稳。发送时用sendall()而不是send()。send()在系统发送缓冲区满时可能只发送部分数据你要自己维护偏移量sendall()内部帮你循环发完出错才抛异常。对于图像这种大块数据几乎一定会触发多次底层 send用sendall()省心得多。3.3 电脑与 DSP 的网络打通发送之前先把网络物理链路调通。PC 和 DSP 网口直连时PC 手动设置静态 IP例如192.168.1.50DSP 端按上一节配置成192.168.1.100。两边子网掩码一致即可通信。项目里如果经过交换机只要同网段也一样。连通性测试用ping 192.168.1.100通了以后再改用一个简单的 TCP 端口测试在 DSP 上监听某个端口PC 上直接telnet 192.168.1.100 8000。如果 ping 通但 telnet 不通问题基本都在 DSP 端 socket 监听逻辑或 PHY 驱动上。另外一个隐形元凶是 PC 防火墙尤其是 Windows 自带防火墙会拦截非常用端口的入站连接开发时可以先关闭再排查。4. DSP 端接收socket 流程与图像拼帧4.1 bind 到 recv 的嵌入式差异DSP 端的 socket 流程和 PC 端长得几乎一样socket(AF_INET, SOCK_STREAM, 0)然后bind()绑定端口listen()进入监听accept()等待连接最后recv()读取数据。但有几个嵌入式环境下特有的点要留意。第一accept 连接会占用系统资源。在 PC 上开几百个线程无压力DSP 上内存有限如果是点对点传输场景我建议只 accept 一次后续复用这个连接发完所有图像不要为每帧图像重新建立连接。频繁的 connect/close 会让协议栈积累 TIME_WAIT 状态的连接轻则端口占用报错重则拖垮 NDK 内存池。第二recv()要放在一个独立的 SYS/BIOS 任务里跑不要放在主循环轮询。NDK 的 socket 接口默认是阻塞式放在主循环里会把整个系统卡死。任务优先级可以设得偏中高但不能高于网络协议栈自身的任务否则可能出现调度问题。void recv_task(UArg a0, UArg a1) { int srv, cli; struct sockaddr_in addr; char buf[4096]; srv socket(AF_INET, SOCK_STREAM, 0); addr.sin_family AF_INET; addr.sin_addr.s_addr htonl(INADDR_ANY); addr.sin_port htons(8000); bind(srv, (struct sockaddr *)addr, sizeof(addr)); listen(srv, 1); cli accept(srv, NULL, NULL); while (1) { int n recv(cli, buf, sizeof(buf), 0); if (n 0) { process_bytes(buf, n); } else if (n 0) { break; // 对端关闭 } } }这段代码只演示流程实际拼帧不能用固定 4096 直接处理要看下一节。4.2 从 recv 到完整一帧拼包状态机TCP 流式传输意味着 DSP 端的一次recv()可能收到半帧、一帧或者好几帧。正确的做法是维护一个接收状态机先收帧头解析出 payload 长度再循环收满整个图像。enum { WAIT_MAGIC, WAIT_HEADER, WAIT_PAYLOAD }; static void process_payload(char *payload, int len); void process_bytes(char *buf, int n) { static int state WAIT_MAGIC; static char hdr[17]; static int hdr_off 0; static char *payload NULL; static int payload_len 0; static int payload_off 0; int i 0; while (i n) { switch (state) { case WAIT_MAGIC: if (n - i 4) { unsigned int magic ntohl(*(unsigned int *)(buf i)); if (magic 0x5A5AA5A5) { state WAIT_HEADER; hdr_off 0; } i 4; } else { i n; // 等下一包 } break; case WAIT_HEADER: while (i n hdr_off 17) { hdr[hdr_off] buf[i]; } if (hdr_off 17) { // 解析 width/height/channels/data_len payload_len /* data_len from hdr */; payload malloc(payload_len); payload_off 0; state WAIT_PAYLOAD; } break; case WAIT_PAYLOAD: while (i n payload_off payload_len) { payload[payload_off] buf[i]; } if (payload_off payload_len) { process_payload(payload, payload_len); free(payload); payload NULL; state WAIT_MAGIC; } break; } } }这个状态机还有一个好处它能正确处理 TCP 粘包。当一帧的结束和下一帧的 magic 同时出现在同一个 buf 里时外层while循环会继续消费剩余字节不会漏掉下一帧头。如果你发现收到的图像偶尔报宽高错误多半是 magic 判断太宽松把图像像素里的偶然数据误当成了帧头。实际项目中我会把 magic 设为 4 字节且带多个固定标志位这个误判率能压到非常低。4.3 字节序与 Cache 一致性C6748 是小端处理器而网络字节序是大端。帧头里的宽、高、长度都必须调用ntohl()转换。如果你发现 DSP 接收端解析出的宽高数值极大或为 0先怀疑字节序再怀疑结构体对齐这两个原因占了拼帧错乱的大部分情况。图像数据本身的每个像素是单字节不涉及字节序转换。但数据从网口 DMA 进内存后可能和 DSP 的 Cache 之间存在一致性问题。接收缓冲区如果放在普通 DDR 并用 Cache 加速网络 DMA 写入的数据对 CPU 不一定立即可见常见表现是收完一帧后打印出来头几个字节对、后面全是乱值。解决办法是把接收缓冲所在地址段配置为非 Cache通过 MAR 寄存器或者在读完数据后主动做Cache_inv()。这个坑在 C6678 这种带大 Cache 的多核芯片上比 C6748 更明显调通之前别急着优化速度。5. 实测中的坑连接失败、粘包和吞吐量瓶颈5.1 bind 报错端口被占用与地址重用DSP 端重启程序后经常会在bind()时遇到类似 only one usage of each socket address 的错误。原因是上一次连接在协议栈里残留了 TIME_WAIT 状态端口还没释放新进程直接bind()就会冲突。解决方法是监听 socket 在bind()之前设置地址重用int opt 1; setsockopt(srv, SOL_SOCKET, SO_REUSEADDR, (void *)opt, sizeof(opt));注意 TI NDK 对setsockopt的支持跟 Linux 并不完全一致有些版本对SO_REUSEADDR支持不全如果设置无效另一个土办法是把 DSP 的端口换一个或者等一段时间等连接自然超时。5.2 connect 超时PC 端连不上 DSPPC 端connect()一直超时最常见的是三类原因。第一DSP 没有进入监听状态代码执行到accept()了吗在 DSP 端加 log 确认。第二IP 不通ping 一下最直接。第三PC 防火墙拦截。Debug 顺序应该是先看网口 link 灯再看 ping再看端口最后才怀疑协议栈配置。不要一开始就去看代码。PC 端的connect()默认超时非常长因为 TCP 协议栈本身会重传 SYN开发调试时给socket.create_connection()显式传一个timeout5失败快一点能省很多等待时间。5.3 粘包与半包为什么收到的图有时花屏花屏有一个非常隐蔽的来源图像帧在 TCP 里传输时被合并或拆分如果 DSP 端没有按状态机拼帧而是直接假设一次 recv 就是一帧图大概率在图像尺寸稍大时出现数据错位。TCP 没有消息边界这不是协议 bug而是它天生的流式特性。解决办法就是我上一节写的拼帧状态机任何图像传输项目都绕不开这一步。另外一个建议帧头里加一个单调递增的帧序号。连续发多张图时DSP 端可以判断收到的帧序号是否连续丢帧或重复帧一目了然排查问题比只看图像内容和宽高高效得多。5.4 吞吐量上不去窗口、MTU 与缓冲我第一次用这套链路传输 720p 图像时帧率只有个位数折腾了很久才发现是多个因素叠加。这里给一张我排查时用的对照表现象可能原因排查或解决办法发送端大图卡在 sendall发送缓冲太小或对端 recv 慢增大 PC 端 SO_SNDBUF、DSP 端 SO_RCVBUF吞吐量长期上不去MTU 不统一、TCP 分片多两端都设 1500或同时启用巨帧要一致接收时 CPU 占用极高recv 循环里频繁分配内存预先分配接收池收完数据后复用图像数据乱值Cache 一致性问题配置 MAR 非 Cache 或 Cache_inv实话说DSP 单核平台做纯净 TCP 图像传输吞吐量很难和 PC 之间千兆网卡的满速比。工程上要抓重点确认用户需要的是实时视频流还是单帧高保真传输。前者往往要把 TCP 换成带丢包转发的专用协议后者则要针对 MTU、DMA 描述符做充分优化。项目标题这个 zip 包主要解决的是后者——让 DSP 能稳定收到电脑发来的单帧图像够算法用就成功了一多半。6. 从单帧图像到连续视频流项目还能怎么扩展6.1 双缓冲与帧序号单帧传通之后下一步自然是连发多帧。这时如果 DSP 端只有一个接收缓冲数据进来后必须立刻处理完才能收下一帧图像越大越容易丢帧。建议改成双缓冲一个 buffer 被网络任务填数据另一个 buffer 被算法任务读两个角色交替。帧序号同时承担乱序检测角色发现序号跳跃就清空当前缓冲避免把两帧图像拼成一张错乱的图。6.2 双向通道与控制指令电脑发图通常不只是单向的。算法处理完图像后需要把检测框、统计结果、处理耗时回传电脑。可以在同一个 TCP 连接上做双向传输发图走一个协议格式回传数据走另一个协议格式两者用不同的 magic 区分。这样上位机既能发图又能实时拿到 DSP 的结果联调效率会提升很多。我实际的做法是电脑端定义一个总控制协议报文第一字节是类型0x01表示图像数据0x02表示参数配置0x03表示状态查询。DSP 端收到后按类型分发到不同处理函数。往后做远程参数调整、算法内部状态观测全部复用这一条通道。6.3 一些想留给你的调试习惯最后分享一个我自己的土办法图像传输链路联调时别一上来就跑大图。先用16x16的纯色小图跑通全流程再把尺寸逐步放大。纯色图哪怕拼帧错了你也能从宽高字段、帧序号、打印日志上判断是头部解析问题还是数据搬运问题而不是对着花屏图像猜。我还会在 DSP 端的串口上打印每帧的收包状态每收齐一帧打一个点这个动作看似简单却能帮你快速定位问题到底出在网络层、拼帧层还是算法层。NDK、TCP、DSP 三个词放在一起看着硬核真正调通之后你会发现它不过是给算法板子开了一扇普通的网口而你要做的就是让图像数据在这条链路上有序地流动。本文还有配套的精品资源点击获取
