新手避坑指南：用ADB给盈鹏飞T113开发板传文件，这几点不注意就白忙活了

嵌入式开发实战：T113开发板ADB文件传输避坑手册

第一次用ADB给盈鹏飞T113开发板传文件时，我盯着屏幕上"device not found"的提示发呆了半小时。后来才发现，问题出在一根看似普通的USB线上——这种Type-A to Type-A的线材在消费电子领域几乎绝迹，却是嵌入式开发的常备工具。这类"新手专属陷阱"在嵌入式开发中比比皆是，本文将用实战经验带你避开那些教科书不会写的坑。

1. 硬件连接：那些容易被忽略的物理细节

1.1 USB线材的隐藏玄机

大多数开发者第一次连接开发板时，会本能地掏出手机数据线（Type-A to Type-C/Micro USB）。但T113开发板的OTG接口采用Type-A母座设计，这意味着：

• 必须使用Type-A公头 to Type-A公头的USB线（俗称USB双公头线）
• 普通手机线无法直接连接开发板与电脑
• 线材质量直接影响传输稳定性，劣质线可能导致ADB频繁断开

推荐备一根带磁环的屏蔽线，传输大文件时更稳定。我曾用某宝9.9包邮的线传100MB文件，中途断了三次，换成工业级线材后一次成功。

1.2 物理开关的致命位置

T113开发板上的SW3开关控制OTG模式切换，但它的拨动方向与直觉相反：

开关位置	功能模式	典型错误现象
1-2	USB Device模式	电脑无法识别设备
2-3	USB Host模式	ADB命令报"no permissions"错误

验证技巧：通过串口终端观察内核日志，正确设置为Device模式时会打印：

[ 203.818326] android_work: sent uevent USB_STATE=CONNECTED [ 203.928644] configfs-gadget gadget: high-speed config #1: c

1.3 供电不足的幽灵问题

当同时使用OTG接口和多个外设时，可能遇到：

• 文件传输中途失败
• 开发板随机重启
• ADB设备列表频繁刷新

解决方案：

1. 使用带外接电源的USB Hub
2. 降低CPU负载后再传输（top命令查看）
3. 关闭不必要的外设（如HDMI输出）

2. 软件配置：脚本与服务的暗礁

2.1 关键脚本的复活指南

开发板默认的/etc/init.d/rcS可能未启用adb服务，需要检查：

1. 用vi编辑rcS文件：

vi /etc/init.d/rcS

2. 确保包含以下行（注意最后的&符号）：

/etc/adb_conf.sh start&

常见踩坑：

• 忘记&符号导致启动卡死
• 文件权限不正确（需chmod +x /etc/adb_conf.sh）
• Windows换行符导致脚本失效（可用dos2unix转换）

2.2 ADB服务的手动调试

当脚本失效时，可手动启动服务：

# 停止现有服务 killall adbd # 重新启动 adb_conf.sh start # 查看进程是否运行 ps | grep adbd

注意：部分固件版本可能需要先执行export ANDROID_ADB_SERVER_PORT=5555指定端口

2.3 防火墙的隐形拦截

在Linux主机上，UFW防火墙可能阻止ADB通信：

# 查看防火墙状态 sudo ufw status # 允许ADB端口 sudo ufw allow 5555/tcp

Windows用户需检查Windows Defender防火墙设置，临时关闭或添加ADB例外。

3. ADB命令实战：从入门到精通

3.1 路径格式的跨平台陷阱

不同操作系统下的路径差异：

• Windows：adb push C:\Users\test\demo.txt /sdcard/
• Linux/macOS：adb push /home/test/demo.txt /sdcard/

易错点：

• 在Windows中使用\导致路径解析失败
• Linux下忘记转义空格字符
• 目标路径没有写权限（先adb shell chmod 777 /target）

3.2 传输验证的完整流程

安全传输四步法：

1. 检查设备连接：

adb devices # 应显示设备序列号

2. 测试shell连接：

adb shell ls / # 查看开发板文件系统

3. 执行推送（示例）：

adb push ./app.bin /usr/local/bin/

4. 验证文件：

adb shell "md5sum /usr/local/bin/app.bin" # 与本地文件对比 md5sum ./app.bin

3.3 大文件传输优化技巧

传输超过100MB文件时建议：

• 先压缩再传输（开发板上用busybox解压）
• 使用adb sync替代adb push（仅传输差异部分）
• 启用压缩传输：

adb --compress push large_file.zip /sdcard/

4. 深度排错：当ADB罢工时的自救指南

4.1 连接失败的六步诊断法

1. 物理层检查：

   • USB线是否双公头
   • SW3开关位置
   • 接口是否有松动

2. 内核日志观察：

   dmesg | grep usb # 或直接查看串口输出

3. USB设备枚举测试：

   lsusb # 应显示Allwinner设备

4. ADB服务状态：

   adb kill-server adb start-server

5. 端口占用检查：

   netstat -tulnp | grep 5555

6. 固件兼容性验证：

   • 尝试不同版本的ADB工具
   • 检查开发板系统镜像日期

4.2 权限问题的花式解法

当遇到no permissions错误时：

Linux主机解决方案：

# 创建udev规则 echo 'SUBSYSTEM=="usb", ATTR{idVendor}=="1f3a", MODE="0666"' | sudo tee /etc/udev/rules.d/51-android.rules # 重新加载规则 sudo udevadm control --reload-rules

Windows备用方案：

1. 打开设备管理器
2. 找到"Android Device"下的"Android ADB Interface"
3. 右键更新驱动，选择"Android ADB Interface"

4.3 固件层面的终极解决方案

当所有方法都失效时，可能需要：

1. 重新烧写系统镜像
2. 更新bootloader
3. 编译自定义内核（开启CONFIG_USB_CONFIGFS_F_ACC）

警告：此操作有风险，建议先备份重要数据

有一次我遇到ADB完全无响应的情况，最后发现是内核配置中缺少CONFIG_USB_LIBCOMPOSITE支持。重新编译内核后问题解决，整个过程耗费两天——这就是嵌入式开发的常态，每个坑都是进阶的台阶。