企业官网建设流程全解析

做嵌入式开发这几年，我经手过的开发板少说也有二十来块。从几十块钱拿来学4G通信的合宙Air202 S6，到正点原子阿尔法IMX6ULL，再到带FPGA的AXU15EGP系列，每一块板子到手之后，我基本都会按同一套流程走一遍：选型、开箱、看原理图、搭环境、烧录、调外设、排错。这套流程走顺了，换新板子也能很快上手。今天就把这条完整的开发板使用流程拆开聊一聊，适合刚拿到第一块板子的新手，也适合被各种奇怪问题卡住的老手参考。整篇会覆盖硬件连接、交叉编译、系统挂载、设备树、通信调试和问题排查，照着走一遍，多数板子都能在半天之内跑起来。

1. 拿到开发板之前：先想清楚你要干什么

1.1 板卡选型不是越贵越好

很多新手买开发板，第一反应是“贵的肯定好”，但实际用过之后会发现，选型的关键不是价格，是你要做的场景和手上已有的工具链。比如你只是想学串口、GPIO、低功耗通信，那合宙Air202 S6这类4G Cat.1模组开发板绰绰有余；你要做图像识别、跑Linux系统，那正点原子IMX6ULL、粤嵌GEC6818、T113开发板这类嵌入式Linux板卡更合适；要是碰上了FPGA+ARM异构的需求，就得看Zynq7100或者AXU15EGP系列。

我自己踩过的最大的坑，就是高估了板卡的性能需求，低估了资料成熟度的重要性。复旦微MFQL20开发板这种国产化平台，芯片本身没问题，但如果你手头没有任何可参考的教程，遇到问题连问的地方都少，学习成本会直线上升。所以选型的优先级顺序应该是：资料成熟度 > 社区活跃度 > 芯片性能 > 价格。

1.2 常见板卡定位与上手难度对照

我整理了一张自己对常见板卡的定位表，不一定完全权威，但可以帮助你在买之前快速判断“这块板子到底适不适合我”。

Radxa Rock 5B+这种板子的处理器定位很高，跑桌面级Ubuntu也没问题，适合当小主机、跑容器应用。如果你要做视频编解码、跑较大的模型，Rock 5B+值得考虑；但如果只做点灯和串口，那它大部分算力其实都是浪费的。选择开发板之前，把“最终要交付什么”写下来，再倒推选型，比对着参数比来比去靠谱得多。

2. 开箱后的第一件事：别急着上电

2.1 线序、排针和原理图

很多人拿到开发板第一件事就是插USB线，然后发现电脑没反应、屏幕不亮，就开始到处问。我自己也干过这种蠢事。正确做法是先找原理图，再碰硬件。比如合宙Air202 S6开发板，板子上的26pin排针引出了电源、地、UART、SIM卡和GPIO等信号，丝印非常密，不戴放大镜很容易看错。你如果直接把杜邦线插上，正负极一接反，板子很可能当场烧掉。

正确姿势是把官方规格书里的管脚定义表下载下来，对照板子上的丝印，先在纸上把排针编号标出来。像正点原子IMX6ULL开发板，虽然引脚标注比较清楚，但不同的排针接口对应的UART、I2C、SPI是不同的，不查原理图想当然去接，大概率没输出。ESP32开发板的原理图也要重点看电源网络和GPIO复用关系，尤其是同一个引脚同时接了按键、LED和外部接口的情况，必须确认引脚复用是否冲突。

读原理图这件事，是开发板使用流程里最容易被新手忽略的一步。我的建议是：拿到板子先别上电，花一个小时把电源树过一遍，把串口、下载模式、启动模式相关的引脚在原理图里高亮出来。

2.2 电源与串口：最基礎也最影响体验

开发板调试期间遇到最多的问题，基本都是电源和串口引起的。ESP32-CAM是个典型例子，它板载的3.3V稳压器输入电流有限，如果你只有一个普通USB口供电，拍照瞬间电流拉高，板子就会重启。实测下来，用5V 2A以上的电源单独给ESP32-CAM供电，才能稳定跑摄像头应用。

串口方面，不管是什么板卡，调试串口几乎都是TXD、RXD、GND三根线，用USB转TTL工具连接时，必须记得TX交叉接RX、RX交叉接TX，GND共地。以IMX6ULL为例，默认调试串口是UART1，波特率通常为115200，数据位8，停止位1，无校验。

这里给出一个串口连接的最小检查清单：

1. USB转TTL模块的TXD接开发板的RXD，RXD接开发板的TXD，GND对GND。
2. 串口工具（比如MobaXterm、minicom、PuTTY）选择对应的COM口。
3. 波特率先按115200试，如果全是乱码，再试9600、57600、1500000等常见值。
4. 如果USB转TTL模块和开发板各自供电，建议先共地再接信号线。

2.3 无线板卡的管理地址：WiFi初始化之后去哪里访问

像ESP32-CAM、ESP32-S3这类自带WiFi的板卡，很多都有默认的管理地址，也就是板子自己开热点后的IP。ESP32-CAM的典型流程是：烧录程序后，板子启动一个名字类似“ESP32-CAM”的AP热点，手机或电脑连上这个热点，在浏览器里打开192.168.4.1，就能进入摄像头预览页。这个地址在官方示例里基本是固定的，但如果你改了NetworkServer配置，就得看串口日志里打印的实际IP。

如果板子配置成了STA模式，连到路由器上，管理IP就会由路由器分配，这时候必须通过串口日志查看。我自己调ESP32-CAM时，最常用的办法就是一开始在代码里固定一个静态IP，比如192.168.1.99，这样既能避免每次查IP，又能减少WiFi连接不稳定的干扰。需要留意的是，这类板卡的文件系统和配置参数很多保存在Flash里，重新烧录程序不一定会清掉旧配置，遇到连不上热点的情况，先插上串口看日志，不要直接怀疑硬件坏了。

3. 搭建开发环境：交叉编译、挂载与终端

3.1 开发机与交叉工具链

我强烈建议所有做嵌入式Linux开发的朋友，主机直接装Ubuntu，或者至少装一个Ubuntu虚拟机。开发板挂载Ubuntu这个需求，本质上就是希望用主机上的交叉编译工具链来编译内核、设备树、驱动模块，然后把编译产物放到开发板上运行。比如IMX6ULL属于ARM Cortex-A7架构，用PC上的gcc编译出来的程序是不能直接跑的，必须用arm-linux-gnueabihf-gcc这类交叉编译器。

拿正点原子阿尔法IMX6ULL开发板举例，最基本的编译流程是：

sudo apt install gcc-arm-linux-gnueabihf libncurses5-dev bison flex export ARCH=arm export CROSS_COMPILE=arm-linux-gnueabihf- make imx6ull_alientek_emmc_defconfig make zImage -j4 make dtbs

编译完成后，在arch/arm/boot目录下会生成zImage，在arch/arm/boot/dts目录下会生成imx6ull-alientek-emmc.dtb。很多教程会让你直接下载别人编译好的镜像，但自己编译一遍能帮你理解内核、设备树和根文件系统之间的关系，排查问题时也更有底。

3.2 开发板怎么挂载 Ubuntu：NFS 方式详解

开发板挂载Ubuntu，最常见的场景是让开发板通过网络文件系统（NFS）直接运行主机上的rootfs。也就是说，根文件系统不在开发板的SD卡或EMMC里，而是放在Ubuntu主机的某个目录下，开发板启动时通过NFS去读取。这样做的好处是，你在主机上改的代码能立即在开发板上生效，不用反复烧写存储介质。我自己调驱动时一直用这种方式，效率比每次打包镜像高很多。

配置步骤大概是这样的：

1. 在Ubuntu主机上安装NFS服务：

sudo apt install nfs-kernel-server

2. 编辑/etc/exports，添加允许挂载的目录和权限：

/opt/nfsroot *(rw,sync,no_root_squash,no_subtree_check)

3. 重启NFS服务：

sudo systemctl restart nfs-kernel-server

4. 在开发板U-Boot里设置启动参数，让内核挂载NFS根文件系统。常见配置如下：

setenv bootargs 'console=ttyS0,115200 root=/dev/nfs nfsroot=192.168.1.100:/opt/nfsroot,tcp rw ip=192.168.1.50:192.168.1.100::255.255.255.0::eth0:off' saveenv

这里的192.168.1.100是Ubuntu主机IP，192.168.1.50是分配给开发板的IP。开发板和主机要在同一网段，并且能互相ping通。挂载成功后，你在主机/opt/nfsroot里放一个测试程序，开发板上直接就能执行，调试体验非常好。

3.3 串口终端与编码设置：MobaXterm 正常、屏幕终端乱码的原因

用串口调试的时候，很多朋友会碰到一个典型问题：同一块IMX6ULL开发板，接到电脑上用MobaXterm串口连上去，中文显示正常；但把开发板接到自带的屏幕终端上，中文就变成乱码。问题通常出在两个地方：字符编码和字体文件。

MobaXterm这类终端软件，默认或者手动设置了UTF-8编码，和系统locale一致，所以显示正常。但开发板本地屏幕终端跑的是另一个程序或服务，它没有加载中文字体，或者locale环境变量不对，就会把UTF-8编码的中文按ASCII或其它编码显示成乱码。可以先在终端里执行：

export LANG=zh_CN.UTF-8 export LC_ALL=zh_CN.UTF-8

如果还不行，就检查系统里有没有安装中文字体，比如fonts-wqy-zenhei。嵌入式Linux根文件系统为了精简，经常把中文字体裁掉了，这种情况下只能手动往rootfs里放字体文件。我自己处理过一个粤嵌GEC6818开发板的类似问题，最终原因是rootfs里没有中文字体，和串口软件完全无关。所以排查的方向别一直盯着终端，也要检查开发板本地的locale和字体。

4. 烧录固件与启动系统

4.1 镜像烧录工具选型

不同芯片平台的烧录方式差异很大。IMX6ULL这类NXP芯片，最常见的是用SD卡启动，把编译好的zImage、设备树、rootfs复制到SD卡上，拨码开关拨到SD卡启动位置即可。也可以用USB烧录工具把镜像烧写到EMMC。ESP32系列则是用esptool.py工具，或者Arduino IDE自动烧录，关键点是在进入下载模式时把IO0引脚拉低。

如果是瑞芯微方案的板卡，比如合众恒跃的瑞芯微3506开发板、Radxa Rock 5B+，通常用瑞芯微官方的RKDevTool，在Maskrom模式下烧写整个镜像。操作步骤一般是：先安装驱动，然后按住板上的Maskrom按键或RECOVERY键，再上电，USB连接电脑，工具识别到设备后加载对应的update.img。这个流程第一次走会有点慌，但核心就一句话：进入烧录模式，再连USB，顺序错了就识别不到设备。

Zynq7100和AXU15EGP系列的烧录不太一样，这类板卡需要把FSBL、bitstream、U-Boot打包成BOOT.BIN，再和image.ub一起放到SD卡里，启动阶段由BootROM引导。如果只是拿它当ARM开发板用，流程和普通Linux板卡差不多；一旦涉及PL端逻辑，就要先在Vivado里综合出bitstream，再打包烧录。烧录工具的选型其实看的是平台，拿到板卡先翻官方wiki，找到“烧录/Download”那一页，按官方工具走，别自己在网上随机找工具，容易把分区表搞坏。

4.2 启动过程与串口日志：一切调试的基础

开发板上电后的第一手信息，全部来自串口日志。以IMX6ULL为例，正常启动时串口会依次输出U-Boot版本信息、内核启动日志，最后是登录提示符。如果按下电源键后串口什么也不打印，优先检查供电、串口接线、波特率，以及启动拨码开关状态。U-Boot阶段还可以手动中断启动，进入命令行，用printenv查看环境变量，用setenv临时修改启动参数。

我自己的习惯是，在正式调试外设前，先把启动日志从头到尾读一遍，重点关注内核有没有报I2C、MMC、网络相关的错误。启动过程中看到一个warning，比如某个regulator初始化失败，可能当前不影响跑系统，但等你调某个外设时就会突然冒出来。举个例子，我调一块T113开发板的以太网时，发现日志里出现“mdio_bus: probe fail”，查了半天，最终发现是设备树里PHY的复位GPIO配置和原理图对不上。

所以，无论你用的是IMX6ULL、T113、RK3506，还是STM32MP157，只要看到串口能打印日志，就先存档一份，再干别的。这个日志在后续排查问题时特别关键。

4.3 编译设备树点亮板载 LED：流程里的第一个里程碑

拿到任何一块Linux开发板，我都建议把点亮板载LED作为第一个动手目标。这个任务能验证交叉编译环境、设备树、内核启动、GPIO子系统是否全部正常。以正点原子阿尔法IMX6ULL开发板为例，板载LED一般接在某个GPIO上，先把板子自带的设备树源文件打开，找到LED节点。

设备树里控制LED的方式通常是这样：

led { compatible = "gpio-leds"; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_led>; led-gpios = <&gpio5 3 GPIO_ACTIVE_LOW>; default-state = "off"; };

其中led-gpios指定了LED接在哪个GPIO，GPIO_ACTIVE_LOW表示低电平点亮。修改完设备树后重新编译：

make dtbs

然后把新生成的imx6ull-alientek-emmc.dtb拷贝到SD卡的boot分区，重启后在/sys/class/leds目录下就能看到对应节点，用以下命令控制点亮和熄灭：

echo 1 > /sys/class/leds/led/brightness echo 0 > /sys/class/leds/led/brightness

这一步跑通后，说明你已经掌握了“改设备树->编译->部署->验证”的完整闭环，后面的各种外设开发都是在这个基础上扩展的。

5. 外设开发：从数据手册到实际通信

5.1 阅读开发板原理图的方法论

很多朋友看到原理图就头大，其实开发板原理图不需要全部看懂，先学会“按模块找信号”就够了。比如你现在想找一个UART口，就在原理图里搜索“UART”“TXD”“RXD”；找GPIO，就搜引脚编号或网络名。合宙Air202 S6的26pin排针定义就非常适合拿来练手，你能在原理图上看到VBAT、GND、UART_TX、UART_RX、SIM_VCC这些网络，一一对应到排针位置。

Espressif家的ESP32开发板原理图更直观，它会把芯片的每个引脚通过网络标签连接到排针或外设芯片上，你要做的就是把芯片引脚名和物理位置对应起来。比如ESP32-S3开发板硬件上有一个USB转串口芯片，原理图里会标注TX、RX连接到哪两个引脚，这就是你调试串口的关键路径。在看原理图过程中，我还习惯顺带确认每个引脚的默认上下拉，有时候外设读不到数据，不是代码问题，而是引脚悬空导致电平不确定。

读原理图还有一个作用，就是确认电平转换。ESP8266开发板与STM32通信时，如果STM32是5V电平，直接接到ESP8266的3.3V引脚上是有风险的，轻则通信异常，重则烧毁模块。原理图上如果没看到电平转换芯片，就要自己加或者用分压方式处理。

5.2 ESP8266 开发板与 STM32 通信实录

ESP8266开发板和STM32通信，是物联网项目里非常常见的组合，也是很多入门者第一个实际联调的项目。整体思路很简单：STM32通过串口给ESP8266发AT指令，ESP8266负责WiFi连接和数据传输，STM32把收到的数据解析出来再执行逻辑。

接线方面，以STM32F103为例，如果板子是5V供电，ESP8266模块用3.3V供电，信号线上最好加电平转换。实际很多开发板为了省事直接连，也能工作，但长时间运行不稳定。CH_PD（EN）引脚必须拉高，模块才正常工作，这个细节经常有人漏掉。

典型AT指令流程如下：

AT AT+CWMODE=1 AT+CWJAP="MyWiFi","password" AT+CIPMUX=0 AT+CIPSTART="TCP","192.168.1.100",8080 AT+CIPSEND=5 hello

每条指令结尾都要带回车换行，如果把AT指令写进STM32的代码里，发送时记得在字符串末尾加上“\r\n”。STM32端最好用串口中断去接收ESP8266的回显，不要用delay等待，因为网络响应时间不稳定，阻塞等待很容易把整个程序卡死。通信数据量大的时候，把缓冲区开大一点，并且做好帧头帧尾解析。

实测下来，ESP8266和STM32通信踩坑最多的地方不是AT指令本身，而是电源。ESP8266在WiFi发射瞬间电流可能到300mA以上，如果STM32开发板的3.3V是由USB口直接提供的，通信时很容易掉线或重启。建议给ESP8266单独一个AMS1117-3.3V供电，或者用5V输入再稳压，输入电压至少给到5V 1A以上。

5.3 摄像头、屏幕和 AI 板卡的扩展玩法

板卡的基础流程走通后，基本就可以玩出花样了。ESP32-CAM是典型的低成本图像采集方案，默认固件烧录后可以连上热点进入192.168.4.1页面，实时预览摄像头画面。这个板卡有几个细节值得注意：天线区域尽量不要被金属外壳遮挡，否则WiFi信号衰减非常明显；摄像头排线很脆弱，插拔时最好断电操作，避免把排线座弄坏。

如果用的是Radxa Rock 5B+这类性能更强的板卡，就能直接跑Ubuntu桌面，接HDMI屏幕后当一个迷你电脑。我上手测试过Rock 5B+基本配置，预装系统里自带桌面环境，连接键鼠后使用体感接近普通PC，跑轻量级开发环境完全没问题。对于这种板卡，建议先跑一遍官方的系统安装工具，确认固件OK，再去折腾GPIO和PCIe外设。它的高性能虽然令人兴奋，但散热问题也会随之而来，不加散热片长时间高负载跑编译任务，温度会明显上升。

AI语音方向的小智开发板，主打的是语音唤醒和自然语言交互，本质上也是一个集成麦克风、喇叭、WiFi的嵌入式Linux设备。如果你已经能按前面几步烧录固件并通过串口查看日志，再去看这种AI板卡就会轻松很多，无非是多了一个音频链路和对应的识别引擎配置。开发板的玩法可以有很多，但底层流程始终是同一套。

6. 常见问题与排查技巧实录

6.1 上电无打印和乱码问题的系统排查方法

嵌入式开发中，常遇到的问题其实就那么几类。我把这几年排查的经验整理成了一张速查表，遇到问题可以对照着看。

排查要讲究顺序，先串口、再电源、再启动参数、再硬件连接。不要一上来就怀疑芯片坏了，嵌入式系统绝大多数“坏掉”的板子，最后都发现是某个接线细节没处理好。

6.2 烧录失败与启动异常的经验复盘

烧录失败是很多新手的噩梦，但大部分都能从“模式、驱动、占用”这三个角度解决。先确认开发板是否进入了正确的烧录模式，比如RK3506开发板要用Maskrom模式，ESP32要拉低IO0，IMX6ULL要拨对启动开关。然后确认电脑是否识别到设备，CH340、CP2102这类USB转串口芯片需要安装驱动，瑞芯微的工具也有自己的驱动步骤。

一个很隐蔽的问题是串口被占用。你打开RKDevTool或某些串口助手时，它会瞬间占用串口端口，导致烧录工具无法访问。解决办法很简单：把所有串口调试工具全部关掉，再重新插拔USB线，让设备重新枚举。还有一次我烧写ESP32-CAM失败，卡在“Connecting…”，原因是我一边用Arduino IDE烧录，一边又开着串口监视器，两个软件抢同一个串口。这种低级错误，以后我都先关闭调试窗口再烧录。

启动异常方面，如果烧录成功但系统起不来，最快的方法是看串口日志停在哪一步。卡在U-Boot说明boot分区引导文件有问题；卡在内核启动早期，可能是设备树不匹配；卡在挂载根文件系统，大概率是rootfs路径或文件系统类型写错了。日志里每一个关键词都可以去搜，问题定位基本都能锁定在启动的某一个阶段。

6.3 中文显示乱码的根源与一劳永逸的解决办法

回到开头提到的IMX6ULL屏幕终端中文乱码问题，这个问题的根源永远只有一个：显示中文的一方所采用的编码和系统内部存储/传输的编码不一致。MobaXterm默认使用UTF-8编码，能正常显示开发板console输出的UTF-8中文；但开发板上直接接的屏幕终端程序，要么用的locale不是UTF-8，要么根文件系统里压根没有中文字体。

处理方式分成两步。第一步，确认开发板系统里中文字体是否存在，很多精简rootfs会裁剪字体，可以用命令找一下：

fc-list | grep -i wqy

如果没有输出，就需要安装或者拷贝中文字体文件到/usr/share/fonts目录。第二步，在开机脚本或终端初始化里显式设置locale和编码，把下面的内容添加到/etc/profile或者.bashrc里：

export LANG=zh_CN.UTF-8 export LC_ALL=zh_CN.UTF-8

设置完以后重启开发板，或者重新登录终端，再执行中文程序，屏幕终端就能正常显示了。如果是U-Boot阶段的菜单中文乱码，那属于另一个层面，通常和字体存储格式有关，需要在U-Boot里配置中文字库支持，这种需求一般比较少，大多数情况下开发板的U-Boot界面用英文就好。

顺手说一下，如果只是开发板通过串口和电脑通信，首要检查的还是波特率和编码，这两个参数都对了，中文乱码基本不会再出现。屏幕终端和串口工具显示结果不一致时，先别怀疑终端软件，重点看开发板本地的字体和locale，这是我调过好几块板子之后总结出来的经验。

这几年玩开发板，我最深的体会是流程比型号重要。每一块板子看起来都不一样，但使用流程极其相似：先看原理图确认硬件，再搭环境编译，再烧录启动，再通过日志验证，最后才写业务逻辑。这个流程能不能走通，直接决定了你拿到新板卡后的第一印象。很多朋友问我为什么上手新板子速度这么快，其实不是我经验多，而是我习惯了拿到板子先按流程走一遍，哪怕是个完全陌生的平台，也能在半天内定位到核心问题。如果只让我分享一条经验，我会说：遇到任何奇怪问题，先回到串口日志和原理图，别瞎猜，也别轻易换硬件。开发板这东西，绝大多数时候它都没坏，只是你还没找到正确的打开方式而已。