AI 辅助嵌入式开发实录:BLE 项目踩坑记

#AI在嵌入式软硬件开发中的应用

最近花了点时间，总算把 CLINE + DEEPSEEK 的环境给配通了。其实选 DeepSeek 没那么多高大上的理由，主要就是国产好用，而且对咱们个人用户来说，性价比确实高。现在万事俱备，是时候开工大干一场了！结果。。。。。。

刚好手头有个 Telink TLSR8258 BLE 的项目，板子上还带了一颗 GC1103 射频功放（PA），正好拿来给新环境练练手。#AI硬件工程师

完整的配置过程图文参考下方链接

嵌入式开发太苦了？教你装上 AI 外挂(VS Code + Roo Cline + Deepseek），效率瞬间翻 10 倍

我的思路很简单：先把相关的电路原理图、SDK、IC 规格书打包到一个项目文件夹里，让 AI 先熟悉一下整个硬件环境。接着，让它写个“点灯+连接手机蓝牙”的测试代码，验证一下基础功能。

结果嘛……呵呵，理想很丰满，现实很骨感。中间硬生生踩了 N 个坑，捣腾了半天才终于把蓝牙给打通。

不过有一说一，抛开这些坑不谈，AI 纯写代码的效率确实快得离谱。不信？我录了个屏，大家可以直接感受一下这手速：

已关注

关注

重播分享赞

视频详情

第一坑：AI 在引脚配置中反复无常

一开始，AI 信誓旦旦地让我用 AS_TX_CYC2PA 和 AS_RX_CYC2LNA 这两个宏，说硬件能自动控制 PA;在 boards_config.h 里加好配置，结果一编译——直接报错。

AI 倒好，轻描淡写地来了一句：“哦，这芯片不支持，换 GPIO 手动控制吧。” 然后反手给了我一套 GPIO_PC6 和 GPIO_PC5 的新方案。

行吧，你说了算。但这一来一回，硬生生浪费了我半小时。要是它一开始老老实实查一下 Datasheet 的引脚功能表，这出闹剧根本就不会有。

第二坑：十六进制都能写错

AI在 boards_config.h 里加一个板子宏定义：

#defineBOARD_CUSTOM 0xCUST

我盯着屏幕看了三秒......

0xCUST？这什么鬼十六进制？CUST？C语言里哪来的U和S？

我说："0xCUST编译不过。"

AI沉默了一会儿："抱歉，应该是 0xC000。"

一个AI，连十六进制都能写错，这合理吗？

第三坑：GPIO初始化电平搞反

GC1103的规格书上写得很清楚：TXEN和RXEN高电平有效。AI初始化的时候拉低：

看起来没问题对吧？但后来发现，GC1103在TXEN=0, RXEN=0时是 Shutdown 模式，RF信号根本过不去。手机当然搜不到设备。

我说："AI，手机搜不到蓝牙。"

AI："你把TXEN和RXEN都拉高试试，进入Bypass模式。"

改了之后，信号强度 -56dBm，一切正常。

所以一开始为什么要拉低？

第四坑：时钟频率搞错

板子上用的是24M晶振，AI让我在配置里写16M：

#defineCLOCK_SYS_CLOCK_HZ 16000000

我说："AI，板子上是24M晶振。"

AI："哦，那改成24M。"

#defineCLOCK_SYS_CLOCK_HZ 24000000

这种基本信息，难道不是应该先读原理图再给建议吗？

第五坑：PA控制逻辑反复横跳

这是最离谱的。AI对GC1103的控制逻辑改了整整5遍。

同一个问题，AI给了5种不同的答案。如果我是个完全不懂硬件的新手，早就被带沟里了。

来看看最终被改了N遍的PA控制代码长什么样：

旁边的关PA代码已经被注释掉了——因为AI自己都不确定要不要关：

第六坑：只有ELF文件没有bin

编译完发现只有 .elf 文件，没有 .bin 文件。

我问："AI，怎么没有bin文件？"

AI："需要在cmake配置里加一个 obj_copy 命令把elf转成bin。"

加了之后，bin文件出来了，烧录进去设备正常工作了。

所以默认配置为什么不生成bin？这也要我来问？

总结

AI的"罪状"（该骂还是要骂）

AI擅长"看起来正确的答案"，而不是"真正正确的答案"。它给出的代码语法上往往没问题，但逻辑上可能完全跑不通。
AI不会主动读规格书。GC1103的datasheet就在那里，但它不会自己去查真值表，而是凭"经验"瞎猜。
AI没有硬件调试能力。它不知道示波器探头点上去是什么波形，不知道天线端有没有信号，不知道PA的使能时序对不对。
AI会犯低级错误。十六进制写错、时钟频率搞错、引脚号搞混......这些错误如果工程师不仔细检查，烧的是硬件，亏的是钱。

AI的"功劳"（该夸也得夸）

但平心而论，如果没有AI辅助，这个项目不可能在两天内跑通。AI在以下方面确实帮了大忙：

代码补全效率极高。写个 gpio_set_ 后面自动补全，不用翻datasheet查寄存器地址，省了大量翻手册的时间。
模块代码一键生成。像 app_att.c 这种几百行的属性表配置，让AI写框架、自己改参数，比自己从头敲快了不止一倍。
改代码飞快。"把PC4改成PC5"这种需求，传统方式要手动搜索替换，AI秒改还不容易漏。
格式对齐强迫症福音。大括号对齐、缩进规范、空行分隔，AI生成的代码比很多老工程师写得还工整。
加注释不用催。写完函数让AI补注释，它还能给你写出doxygen风格的，比自己写省心多了。
快速原型验证。想试一个功能，跟AI描述一下就能生成可编译的代码，行不行跑一下就知道，比先翻两天手册再动手效率高太多。

嵌入式这种软硬件深度耦合的领域，AI 目前顶多算个“高级实习生”：它干活快、态度好、从不抱怨，但前提是——必须有人给它兜底。而那个兜底的人，只能是你。

所以，正确的姿势绝不是“把活儿全甩给 AI”，而是“让它帮你踩油门，你来把控方向盘”。它写代码，你审逻辑；它搭框架，你填细节；它出方案，你做决策。

各位同行，AI 不是来抢饭碗的，它是来发“加速器”的。说实话，不管你是写代码还是干别的活儿，道理都一样。大胆用起来，但别盲目全信它，把它当成一个免费又得力的助手就好。

但是大伙放心，“它连个 GC1103 都搞不定”，离取代我们？还早着呢！

#嵌入式开发#AI编程#蓝牙BLE#deepseek