一、这份清单怎么用
先说一句可能不太中听的结论:检查清单的价值不在于项目多,而在于每一条都对应一个“我曾经真的踩过”的故障现象。 从别处抄来的一百条注意事项,抄的时候很安心,用的时候一条也想不起来; 而“上电先等 500 ms 再跑外设”这种条目,我之所以记得住,是因为它曾经让我在实验室里连着换过三块屏。
所以我给自己定了三条使用规则:
- 每条必须能说出后果。写不出“漏了会怎样”的条目,说明我并不知道它为什么重要,那就先删掉,等真的踩过再补进来。
- 每条必须能在一分钟内检查完。要跑仿真、要做实验才能判断的条目,不适合放进“打样前自查”这个环节,它应该属于设计阶段。
- 清单是活的,而且只增不减是不对的。如果一个项目从头到尾没在这条上出过问题,而且我确信以后也不会,那就把它删掉,让清单保持短小。
下面五组覆盖的是我最常出问题的五个方向:电源与上电时序、时钟与复位、模拟与基准、 通信接口与保护、可制造性与可测试性。每组是一张表,左列是检查项,右列是我见过的后果。 这些后果全部来自我自己做过的板子和读过的固件, 为了脱敏,行业一律用中性说法(比如“加注计量设备”“变频驱动场合”),不涉及任何单位与项目信息。
二、第一组:电源与上电时序
这一组是我踩坑最多的一组。原因很简单:电源问题在实验室往往看不出来, 因为实验室的电源干净、负载轻、插拔次数少,而现场什么都占全了。
| 检查项 | 漏了会怎样(我见过的现象) |
|---|---|
| MCU 开始跑外设之前,是否等了电源稳定 | 带显示模组的板子上电后偶发花屏、字库读不出来,重新上电又好了。后来在主程序开头加了 500 ms 延时(注释写的是“开机时延迟 500 ms 保证电源稳定后再开始运行”),偶发问题消失。上电瞬间的电源跌落比稳态纹波可怕得多。 |
| 是否有独立的电源检测脚(比如 5 V 检测)接到 MCU | 整机掉电时 MCU 还靠电容残压跑着,参数写到一半断电,参数区直接烂掉。有检测脚才能做“掉电保存”:检测脚变低先记下时刻,保持一段时间再判定为真掉电,恢复后还要再等 300 ms 才允许复位——这样才能把“瞬时掉电”和“真掉电”分开。 |
| 母线/输入电压采样的分压比,是否留了量程余量 | 分压比定小了,输入到上限时 ADC 先饱和,欠压与过压判定全部失真。我用过的两条真实换算:母线通道 ADC×3300/4096×12(12:1 分压),液位通道 ADC×3300/4096×1.51(1.51 是整定系数)。硬件一旦改分压,软件不跟着改就是系统性偏差,而且看起来“一直很准”,只是整体偏了一个比例。 |
| 每个电源引脚是否有就近去耦,模拟部分是否单独一组 | 这是通用做法:每个电源脚一颗 100 nF 紧贴引脚,每组电源再配一颗容量大一些的储能电容,ADC 与基准单独一组。漏了的典型现象是采集值随机抖动、通信误码率偏高,而你在示波器上看电源纹波却“挺正常”。 |
| 上下电顺序是否确认过 | 3.3 V 比 5 V 先建立,外设通过 IO 灌电流,出现“上电后外设不响应、重新插拔一次就好了”。另一端的现象是断电时 MCU 先掉、外设还在工作,IO 上出现反向电流。 |
| 欠压/过压判定是否有软件去抖 | 单次采样命中就报故障,负载一动作(比如阀或继电器吸合)就误报。我在固件里的做法是连续命中 2 次才置故障;欠压判定值还做成可设置项,过压则用更高的固定阈值。 |
| “显示值”和“判定值”是否分开 | 我遇到过一整批板子的 ADC 通道存在约 0.3 V 系统偏差(采集值比实际低 0.3 V)。修正是给上报和显示加 300 mV,但欠压判定仍然用未修正的原始值。如果两者混用,要么天天误报,要么保护点整体偏移 0.3 V。这是个很容易被“顺手改一下”破坏的设计。 |
上电初始化的顺序,我后来固定成下面这个骨架,几个项目的做法基本一致:
/* 上电初始化顺序:先弄清"这次为什么复位",再等稳定,最后才开狗 */
void App_PowerOnInit(void)
{
uint8_t cause = RMU_GetResetCause(); /* 上电?看门狗?软件复位?先读清楚 */
RMU_ClrResetFlag(); /* 读完立刻清标志,免得下次读到旧的 */
delay1ms(POWER_SETTLE_MS); /* 等电源稳定:这个延时省不得 */
Ddl_Delay1ms(ONCHIP_READY_MS); /* 再等片上模块加载完成 */
if (cause == RESET_CAUSE_WDT) {
Sys_LogFault(FAULT_WDT_RESET); /* 看门狗复位不能被静默吞掉 */
}
Wdt_Config(); /* 看门狗永远放在最后一步启动 */
}这段顺序里有三个“反直觉”的点,都是我改过之后才定下来的: 复位原因要最先读(清了就没了)、延时要在开狗之前(开了狗再延时就要考虑喂狗)、 看门狗要最后启动(否则初始化稍慢一点就被自己复位)。
三、第二组:时钟与复位
时钟和复位加起来只占两三个引脚,但它们对应的故障有一个共同特征: 看起来像“这块板子坏了”,换一块就好。这类故障最难查,因为它不稳定复现。
| 检查项 | 漏了会怎样(我见过的现象) |
|---|---|
| 晶振的负载电容是否按晶振规格选,而不是照抄参考设计 | 起振慢或者根本不起振。典型现象是“冷机不启动,用手碰一下晶振脚就起来了”——这种故障我一开始以为是焊接不良,换了几块板才反应过来是负载电容不匹配。 |
| 外部晶振失效时,固件有没有兜底 | 时钟初始化只依赖外部晶振,晶振不振就是死机。有项目的版本记录里明确写着“外部晶振失效时启用内部时钟”;也有项目干脆一开始就用内部高速 RC 经 PLL 到 48 MHz,完全不依赖外部晶振。要不要兜底取决于场景:要绝对精度就得外晶振,要绝对能起机就用内部 RC。 |
| 复位引脚是否引出,是否有上拉与滤波电容 | 复位脚悬空会被干扰误复位;没有测试点或者复位按键,出问题时只能靠拔插电源,排查效率极低。 |
| 固件是否能读出本次复位原因 | 现场“偶发重启”如果分不清是看门狗、掉电还是硬件复位,就只能靠猜。我的做法是上电先读一次复位原因寄存器、清标志,把看门狗复位记进故障码,再启动看门狗。 |
| 看门狗复位时间是否算过,和最长任务对得上吗 | 这是最容易想当然的一条。我核过的一个工程:时钟分频 2048、计数 65536、100% 刷新窗口,复位时间 = 65536/(500000/2048) ≈ 2.68 s;另一个工程用的是 1 s。复位时间比最长任务还短,正常工况就会被复位;比故障恢复时间还长,保护等于没有。 |
| 进低功耗之后,谁来喂狗 | 有工程出现过“休眠唤醒后被看门狗复位”,最后的解法是把一个定时器从“计时”改成“周期性唤醒喂狗”,原来的计时功能迁到另一个定时器上。只要系统会休眠,就必须重新排一遍喂狗路径。 |
| 通信卡死是否会被看门狗兜住 | 产线测试用例里我记得有一条是“发送不完整帧(超过 200 ms)→ 触发看门狗复位”。这条之所以写成测试用例,就是因为它真的发生过:串口异常识别空闲标志位,导致只收到 1 个字节就再也不动了。 |
看门狗这一条我单独列了一张小表,因为它值得算而不是抄:
| 要素 | 我核对过的一个实例 | 要问自己的问题 |
|---|---|---|
| 看门狗时钟源与分频 | PCLK3 再分频 2048,折算到计数时钟约 244 Hz | 分频变了,超时时间会跟着变,公式还作数吗? |
| 计数上限 | 65536 | 是不是按“最大值”配的?最大值往往意味着最长的超时 |
| 刷新窗口 | 100%(整个周期都能刷新) | 如果改成窗口模式,最晚/最早能喂狗的时间各是多少? |
| 复位动作 | 直接请求复位,而不是先中断 | 我希望它复位还是先抢救一下? |
| 实测超时 | 65536/(500000/2048) ≈ 2.68 s | 最长的那个任务周期是多少?留了几倍余量? |
四、第三组:模拟与基准
模拟部分的坑有一个共同点:它不会“坏”,它只会“不准”。 不准是最难被发现的故障,因为设备还在正常工作,只是数据慢慢偏了。
| 检查项 | 漏了会怎样(我见过的现象) |
|---|---|
| 分压电阻的精度与温漂,是否算进量程误差预算 | 分压比误差会一比一落在换算结果上。用 1% 电阻时,两只电阻的误差叠加就已经接近 2%,再加上参考电压本身的误差——这部分误差里,随温度变化的那一段是软件标定消不掉的。我现在的做法是:先算一遍最坏情况,确认它小于我能接受的量程误差,再决定要不要换更高精度的电阻。 |
| ADC 用内部参考还是外部基准,够不够用 | 用 AVDD 当参考,AVDD 抖多少采集就跟着抖多少。我在一个采集板上就是直接用 AVDD(3.3 V)做参考、采样时间 12 个时钟,够用;但在要绝对精度的板子上,就必须用外部基准,并且给基准芯片单独的使能脚与滤波——我见过一个工程专门留了基准使能引脚(Boot 和 App 用的是不同引脚),开机后才打开基准。 |
| 分压点是否加了滤波电容,位置对不对 | 从一个变频驱动场合的板子上学到的:母线电压采样如果不就近滤波,开关噪声会直接进 ADC。这类噪声不是“读数抖一下”,而是让欠压判定误动作。 |
| ADC 输入阻抗与采样时间是否匹配 | 源阻抗太高(比如为了省电用了大阻值分压),采样保持电容在一个采样窗口里充不满,读出来的值偏低,而且会随扫描顺序变化——前一个通道充得多,后一个通道就跟着变。解决办法通常是把分压总阻值降下来,或者延长采样时间,或者加一级缓冲。 |
| 满量程与换算系数是否只写在同一个地方 | 我整理过同一族换算公式在这批固件里的四种写法:×3300/4096×12(母线 12:1)、×3300/4096×1.51(液位整定)、446×ADC/4096(0~446 V 满量程)、以及×3300/4096 之后再额外加 300 mV 修正。四种写法散在不同文件里,改硬件时漏改一处就长期带病运行。我现在的做法是所有换算集中到一个头文件,每个常数后面写清来源。 |
| 滤波策略是否与干扰类型匹配 | 工业现场的主要干扰是脉冲型尖峰(继电器、变频器开关),而纯滑动平均最怕的就是单点尖峰——一个坏点会把整段平均带偏。我读过的这几个工程里,滤波清一色是“排序 + 去极值”:20 点排序后取中间 3 点平均、6 轮采样去掉最大最小后取中间 4 点平均、5 点取中值再 3 点取中值。没有一个人用纯滑动平均,这不是巧合。 |
| 模拟地与数字地怎么处理 | 我的做法是小板子直接整片铺地、靠布局把模拟走线远离开关节点;确实需要分区时,模拟地和数字地单点连接,连接点选在 ADC 的地附近。漏了这一条的现象通常是“精度时好时坏”,而且跟你测哪儿关系很大。 |
换算这件事我后来统一成一个写法,把三件事在一次计算里做完,避免散落:
/* 采集换算:分压比、整定系数、显示值与判定值分离(按个人理解重写的骨架) */
#define ADC_FS 4096u /* 12 位 ADC 满量程(通用常数) */
#define ADC_VREF_MV 3300u /* 参考电压(通用常数) */
/* 母线通道:按硬件的分压比还原(比例来自实际分压网络,此处符号化) */
bus_mv = (uint32_t)adc_bus * ADC_VREF_MV / ADC_FS * BUS_DIV_NUM / BUS_DIV_DEN;
/* 液位通道:按前端的整定系数还原,用整数乘除避免浮点 */
level_mm = (uint32_t)adc_lev * ADC_VREF_MV / ADC_FS * LVL_GAIN_NUM / LVL_GAIN_DEN;
/* 该通道存在一个固定的系统偏差:显示加修正,判定不加 */
disp_mv = bus_mv + BUS_DISP_TRIM;
if (bus_mv <= POWER_LOW_VALUE) { /* 判定用未修正值 */
if (++low_cnt >= DEBOUNCE_N) { /* 连续若干次才认,做软件去抖 */
Sys_SetFault(FAULT_UNDER_VOLTAGE);
}
} else {
low_cnt = 0u;
}五、第四组:通信接口与保护
RS485 是这批板子里出现频率最高的接口,也是“看起来最简单、实际最容易翻车”的接口。 它的坑几乎全在时序和地回路上。
| 检查项 | 漏了会怎样(我见过的现象) |
|---|---|
| RS485 方向脚(DE/RE)的切换时序,是否在收发前后都留了延时 | 第一字节的起始位被削掉,上位机看到的是“偶尔收到一帧乱码”或者“CRC 校验失败率很高”,换线、换波特率都没用。我在固件里见过的几种取值:收发各 1 ms;发送前 1 ms、切回接收前 2 ms(源码注释明确写着“485 发送完毕后切换读取必须先延时”);9600 波特率下发完固定延时 10 ms 才切回接收(9600 下 1 字节约 1.04 ms,靠延时保证移位寄存器排空);产线程序里则是发送前 2 µs、切回接收前 3000 µs。数值各不相同,但“必须延”是一致的。 |
| 这些延时是不是硬编码?波特率改了会不会跟着改 | 我见过波特率做成可配置、延时却写死在宏里的工程。这在 9600 下没问题,一旦有人把波特率改成 115200,那个 10 ms 的延时虽然仍然“够用”,但收发吞吐会被拖垮;反过来把波特率降到 1200,10 ms 就不够了。这是一个定时炸弹,而且是那种“改了配置才爆”的。 |
| 方向脚的极性对不对(有的器件 DE 高有效、RE 低有效) | 接反了表现为“永远收不到”或者“永远发不出”,而且用万用表量电平还是对的,特别容易被判成芯片坏了。 |
| 终端电阻要不要、怎么留 | 总线拉长、或者挂的设备多了之后,通信开始“时好时坏”。我的做法是在板子上留终端电阻的位置和跳线(或拨码),默认不装;现场调不通时再按总线两端各一个的规则装上,装之前先用示波器看波形有没有明显的反射台阶。 |
| 要不要隔离,隔离电源有没有一起做 | 跨柜、长距离、旁边有变频器的场合,如果只隔离信号不隔离电源,两地地电位差照样会打坏收发器。典型现象是“换一块收发器用几天又坏了”,属于反复维修的故障。要隔离就信号和电源一起隔。 |
| 总线入口的保护器件位置有没有留 | 浪涌过后收发器损坏,表现为整条总线上的设备一起掉线。我现在的做法是至少把 TVS、共模电感、自恢复保险丝的位置在布局上留出来,哪怕第一版不装。 |
| 串口引脚有没有和别的外设抢复用 | 有个显示项目里,字库驱动的引脚在同一组硬件 SPI 上和其他功能冲突,最后保留了两套实现(硬件 SPI 和软件模拟 SPI)用宏切换,软件 SPI 做兜底。代价是速度掉下来。画原理图之前先看一眼复用表,比事后写软 SPI 便宜得多。 |
| SDIO / USB 这类“复位后默认不是你要的功能”的复用引脚 | 这类外设的引脚在复位后有默认功能,如果硬件按另一种功能接,就会出现“程序没跑起来时引脚状态不对”,进而影响外部电路(比如把某个使能脚拉错电平)。画图前要看数据手册的“复位后引脚状态”表,不只看复用功能表。 |
六、第五组:可制造性与可测试性
这一组最容易被“赶进度”牺牲掉,而且牺牲的时候往往觉得“下个版本再补”。 但打样回来的板子是要焊、要测、要烧程序的,这一组的每一条都直接决定我要不要在实验室里多花一天。
| 检查项 | 漏了会怎样(我见过的现象) |
|---|---|
| 调试口(SWD 等)是否保留,做成排针还是测试点 | 全保留会占引脚;全释放就再也接不上调试器,只能拆机返工。我核过的一个量产工程里,固件会把调试口控制器改成“只保留 SW 调试脚,其余复用为普通 IO”——这是很常用的省引脚手法,但前提是原理图上给 SW 留了可接触的焊盘或排针。 |
| 量产版本要不要关调试打印,怎么关 | 我读到的发布注意事项里,同一句话在两代产品文档里原样重复:“发布版本需要打开芯片保护和看门狗功能,关闭所有串口打印和调试功能。”能被写进两代文档的同一句话,说明它被违反过至少两次。我的做法是调试打印用编译开关统一控制,不靠一条条注释掉。 |
| 关键网络有没有测试点(电压、地、通信差分对、复位) | 产线上要测的电压和波形如果没有测试点,只能拿探针去戳元件,效率和一致性都差。我看过一个产线工装的实现,它把检测流程写成了“指令 + 等待响应时间 + 测试点数组”的数据模型,也就是说每一条检测项都绑定到具体的测试点上——板子上没有这些点,这套流程就落不了地。 |
| 丝印与位号:极性、1 脚、按键与指示灯 | 极性元件没标、连接器 1 脚没标,手工焊接时贴反;位号压在焊盘上,维修时找不到 R23。这一条看起来最琐碎,但它是唯一一条“改起来最便宜、收益最直接”的。 |
| 新封装第一次用,有没有 1:1 打印比对过 | 封装画错只能飞线。我的做法是任何没用过的封装,打样前一定 1:1 打印出来,把实物放上去比一遍,重点看引脚间距和焊盘长度。 |
| 钢网开口与引脚间距是否匹配 | 间距很小的封装如果用统一厚度的钢网,容易连锡。这一条我吃过一次亏之后就固定下来了:细间距器件在钢网上单独标注,让加工方按他们的经验处理开口。 |
| Flash 编程方式:留了什么接口,产线怎么烧 | 没有预留编程接口,产线只能把板子拆下来烧;另一个我核过的工程里,Flash 是 8 字节双字编程,不足 8 字节要补齐(传入 63 字节时自动补 1 字节写入对齐),而且擦除非页对齐地址会直接返回错误。这些约束如果不在布局阶段想清楚,产线一定会卡住。 |
| 参数区放在哪一页,擦写寿命算过吗 | 把日志写进片内 Flash 是常见错误。手册里这类 Flash 的最低擦写次数是 1000 次量级,按“每次开机写一条日志”算,几个月就能把一页写坏。结论:日志不要写 Flash,参数区要算写入频次。 |
| 参数结构体在 Boot 与 App 之间是否一致 | 我核过一个工程:Boot 和 App 共用同一块参数区,但两边对参数结构体的定义不一样(App 侧多两个字节)。这种“布局耦合”平时不出事,一旦改结构体就会读到错位参数,而且没有任何编译错误提醒你。 |
| 参数有没有自校验与回退 | 参数区损坏后设备带着乱参数运行,比直接罢工更糟。我后来固定用“结构体最后一个字存 CRC、覆盖前面 N−1 个字”的写法,校验不过就整体恢复默认值;测试方法也很简单——把 CRC 字段改成 0xFFFF,看默认参数是否生效。 |
参数区的这两条,落到代码上大概是这样:
/* 参数页自校验 + 双字(8 字节)编程的最小子集(按个人理解重写) */
#define PARAM_WORDS (sizeof(SysSet) / 4u)
/* 1) 开机自校验:最后一个字存 CRC,覆盖前面 N-1 个字 */
if (HAL_CRC_Calculate(&hcrc, (uint32_t *)&SysSet, PARAM_WORDS - 1u)
!= ((uint32_t *)&SysSet)[PARAM_WORDS - 1u]) {
defaultParameter(); /* 校验不过就整体回默认,不要带病运行 */
}
/* 2) 双字编程:不足 8 字节必须补齐,否则最后一包写不进去 */
static void flash_write_dw(uint32_t addr, const uint8_t *buf, uint32_t len)
{
uint8_t pack[8];
uint32_t i;
uint32_t left;
for (i = 0u; i < len; i += 8u) {
left = len - i;
memset(pack, 0xFF, sizeof(pack)); /* 不足部分补 0xFF */
memcpy(pack, &buf[i], (left >= 8u) ? 8u : left);
HAL_FLASH_Program(FLASH_TYPEPROGRAM_DOUBLEWORD,
addr + i, *(uint64_t *)pack);
}
}七、打样前的最后十项确认
上面五组是“设计时随时看”的,这一张是点下“确认下单”之前必须逐条打勾的。 十项是我能稳定坚持下来的上限,再多就会开始敷衍。
| ✓ | 确认项 | 判定标准(我自己用的) |
|---|---|---|
| ☐ | 电源网络全部检查完 | 每个电源脚有去耦、每组电源有储能、上电顺序确认过、每个电源网络都有明确的来源与电流估算 |
| ☐ | 地平面完整 | 没有大面积的“孤岛地”,模拟区域没有数字回流穿过去,分割处单点连接 |
| ☐ | 时钟与复位 | 晶振负载电容按规格选;复位脚有上拉与测试点;固件能读复位原因 |
| ☐ | ADC 与基准 | 分压比与量程余量算过;参考源选型确认;采样点有滤波;换算常数集中在一处 |
| ☐ | 通信接口 | 方向脚时序确认;终端电阻位置留出;保护器件位置留出;复用冲突核对过数据手册 |
| ☐ | 调试与编程接口 | SWD 可接触;编程方式确定;量产时是否释放调试引脚已决定 |
| ☐ | 测试点 | 电源、地、复位、通信差分对、关键模拟量各至少一个可测点 |
| ☐ | 丝印与位号 | 极性、1 脚、按键与指示灯齐全;位号不压焊盘;板名与版本号在板上 |
| ☐ | 封装核对 | 新封装全部 1:1 打印比对过;极性与 1 脚方向在封装库里也确认过 |
| ☐ | 参数与存储 | 参数区位置、擦写频次、自校验与默认值回退都想清楚了 |
最后加一条不在这十项里、但我每次都会做的事:把原理图和 PCB 各自导出一次 PDF,从头到尾读一遍网络名。 我抓到的错误里,有相当一部分是“网络名拼错导致两根线连在一起”或者“上拉电阻忘了放”, 这类错误用工具查不出来,只能靠人眼过一遍。
八、几条我反复用到的经验
- 能写出后果的条目才留在清单里。写不出后果,说明我还没真正理解它,那就等踩过再加。
- 硬件与固件是同一次设计。分压比、上电延时、看门狗时间、方向脚延时,这四样东西每一次都是软硬交界处的约定;任何一边改了,另一边必须同步。
- 凡是“延时就够了”的地方,都要把延时值写清来源。是算出来的、还是示波器上试出来的,注释里要能一眼看出来。否则下一个人(包括我自己)会以为它是随便写的,然后随手改掉。
- 模拟量的误差要预算,不要靠标定兜底。能靠软件标定消掉的只有固定偏差,随温度和批次变化的那部分必须靠硬件选型解决。
- 保护器件的位置要留,装不装是第二步的事。位置没留,现场出问题时只能改板。
- 可测试性不是“以后再补”的项。打样回来第一件事就是上电测,没有测试点,这一步会多花一天。
- 清单要短。十项能坚持,一百项一定会被跳过——被跳过的清单等于没有清单。
这份清单是活的,每次打样回来我都会往里加一两条、删掉一两条。 如果你也在整理自己的版本,欢迎先看看我另外两篇记录: 《采样数据的处理:环形缓冲、中值滤波与迟滞控制》 讲的是第三组里“滤波策略”那一条的完整实现; 《双通道相位可调 PWM 脉冲发生小板》 则是一块 16 KB Flash / 2 KB RAM 的小板子的完整实验记录, 里面关于上电资源账和时序约束的取舍,和这份清单是互相印证的。 列表页在学习笔记与个人实验。
参考资料与说明
- 国际电子工业联接协会(IPC)发布的一系列通用电子组装与设计规范,例如关于印制板设计要求、表面贴装设计、焊盘图形与可制造性设计的公开标准名称,常被用于 DFM 自查。具体条款以标准原文为准。
- 各 MCU 厂商公开的参考手册与应用笔记中关于复位来源寄存器、独立看门狗时钟与超时计算、ADC 采样时间与输入阻抗要求、Flash 编程对齐与擦写寿命(数据手册中的擦写次数指标)的章节。
- RS485 收发器数据手册中关于使能建立时间、失效安全与总线终端匹配的说明,属公开器件资料。
- 本文提到的具体设计取值(12:1 分压、1.51 整定系数、300 mV 偏差修正、500 ms 上电延时、1 ms 方向脚延时、8 字节双字编程、1000 次擦写寿命等)均来自我个人做过的板子与读过的固件,只用于说明方法,不构成对任何场景的参数建议。
- 文中出现的芯片与标准名称仅用于说明技术方案,与相关厂商、标准组织无隶属或授权关系。
- 示例代码为按个人理解重写的最小片段,不代表任何产品或交付代码。