拓冰建站拓冰建站
首页 / 资讯中心 / 正文

Simplicity Studio 的 VS Code Extension 使用,这次用 TaoToken 走通 Codex 的 CMake 验证

1. 先装「Simplicity Studio for VS Code」再把项目生成器切过去1.1 扩展商店里装官方插件打开 VS Code 扩展商店搜索 Simplicity Studio for VS Code认准发布者是 Silicon Labs。安装完成后不用急着配置插件本身只是一个入口真正干活的是你本机的 Simplicity Studio 和 Gecko SDK Suite。如果你还没装过 Studio插件会在首次启动时提示你先去安装对应版本的 SDK。这一步绕不过去后续 CMake 支持文件全部依赖本机 SDK 的位置和版本。装完插件后VS Code 会识别出你机器上的 Simplicity Studio 安装路径工具栏里会出现 Simplicity Studio 相关的入口用来打开工程、选择构建目标和启动调试会话。到这里插件侧的工作就算完成接下来要把 Simplicity Studio 的项目生成器切到 VS Code。1.2 新项目向导和 Project Configurator 两个入口新建项目时向导第一步会让你选择 Target、SDK 和 Generator在 Generator 一栏直接选 VS Code之后生成的项目就是给 VS Code 用的。已经用 Simplicity 生成器建好的旧项目也不用手工搬文件打开 Project Configurator 的 Overview 页找到 Change Target/SDK/Generators把生成器换成 VS Code确认后 Simplicity Studio 会重新生成项目结构。生成完成后要记住一个分工Simplicity Studio 还是负责创建初始项目以及通过 Project Configurator 的图形界面做组件级的配置变更但项目的编辑、构建和调试后续都在 VS Code 里收尾。官方文档里特别提了一句不要尝试同时在 Simplicity Studio 和 VS Code 里构建同一个工程两个构建系统会互相干扰浪费的时间比省下来的多得多。2. 生成器切换后冒出来的 CMake 文件到底谁是谁2.1 CMakePresets.json构建预设清单切到 VS Code 生成器并完成 Generate 之后工程根目录会多出 CMakePresets.json。这个文件是 CMake 新版本推荐的预设入口里面定义 configurePresets 和 buildPresets。configurePresets 写清楚用哪个生成器通常是 Ninja、源码目录在哪、CMakeLists.txt 的位置以及 toolchainFile 指向哪里buildPresets 负责把编译动作绑到对应的 configure 结果上。VS Code 的 CMake Tools 扩展打开工程时会读这个文件并在底部状态栏列出可用的 preset。如果文件里 toolchainFile 引用的路径在你的机器上不存在CMake Tools 会在配置阶段直接报错。换句话说这个文件对不对决定了你能不能顺利点下 Build 按钮。2.2 toolchain.cmake 和项目名_cmake文件夹toolchain.cmake 是交叉编译的工具链描述文件里面包含编译器、链接器、GSDK 的头文件路径、芯片型号相关的宏定义。它和 CMakePresets.json 配合使用预设里的 CMAKE_TOOLCHAIN_FILE 就指向它。另一个新出现的项目名_cmake文件夹存放的是生成器产出的中间描述文件属于构建系统的输入不是用户源码平时不需要打开修改。还有个容易被忽略的 vscode.conf它给 VS Code 侧提供 SDK 位置、工程类型和调试器配置的提示。Silicon Labs 的扩展会读取这个文件来决定如何连接 Simplicity Studio 的编译器和调试器。这几个文件缺一不可如果你不确定哪个文件该不该改先别动后面用只读方式核对一遍再说。2.3 弹窗问你怎么处理旧配置时选 Keep my file在生成过程中Simplicity Studio 可能会弹窗询问某些既有配置文件如何处理。这里保留默认的 Keep my file 选项然后点确认。这个选项的含义是生成器只补充新文件和差异项不去覆盖你手动维护过的旧配置。反过来如果你选了其他选项之前对配置文件做过的定制修改可能被自动改写后面排查起来很被动。最保险的做法就是保持默认把生成器当成一个只输出新文件的工具。提示VS Code 生成器与 Gecko SDK Suite 相互独立搭配任何 4.x 版本的 GSDK 都能工作。所以当路径对不上时优先怀疑版本号写错而不是生成器本身不支持。3. 用 Codex 走 TaoToken 做 CMake 只读预检3.1 先拿 Key再把 ~/.codex/config.toml 指到 TaoToken准备工作要做两件事。第一打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 注册账号创建 API Key并把模型广场里准备给 Codex 用的模型 ID 记下来。第二在 ~/.codex/config.toml 里新增一个 model provider把 Codex 的请求收口到 TaoToken 这个统一接入通道。这样以后换模型不用改 Base URL只换 model 字段即可。model 模型广场上选好的模型ID model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api chat把刚才创建的 Key 配置到环境变量 TAOTOKEN_API_KEY然后重启 Codex让新配置生效。这里最容易混淆的是两个地址带 UTM 的 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 留给浏览器用来注册、建 Key、看模型广场和用量填进工具配置文件的 Base URL 一律用 https://taotoken.net/api末尾不要加 /v1也不要试图把网页地址复制进来。3.2 把配置文件贴给 Codex 只读核对不连本地磁盘预检不用 Codex 去扫描你的本地文件系统更不需要先在 Simplicity Studio 构建一次。做法是打开 CMakePresets.json 和 toolchain.cmake把内容复制进 Codex 对话让它做只读检查确认 CMake 最低版本要求是否满足toolchainFile 路径与当前 GSDK 版本是否匹配vscode.conf 里引用的 preset 名与 CMakePresets.json 中定义的名字是否一致。明确告诉它不要给出修改后的完整文件也不要运行任何编译命令。我遇到过的情况是 GSDK 从 4.4.0 升到 4.4.2生成器输出的 toolchainFile 却还指向旧版本目录Codex 一眼就指出了这个矛盾。放在以前我得先回 Simplicity Studio 构建一次等报错才知道路径不对现在用一次只读预检就能定位问题。Codex 返回正常结果的同时这次调用也已经真实发生去官网看用量时能看到对应的一笔记录。4. 预检通过后回 VS Code 正式构建两个常见报错4.1 CMake Tools 选对 preset 再点 Build预检说配置自洽再回到 VS Code 打开工程。CMake Tools 会自动列出可用的 configure preset选择 Codex 刚刚核对过的那个然后执行 Build。到这一步才是真正的本地编译需要你在自己机器上操作把 Codex 给出的核对结论作为参考再决定是否直接构建。日常使用顺序建议固定下来先在 Simplicity Studio 里通过 Project Configurator 添加或调整组件让生成器重新输出 CMake 支持文件然后切回 VS Code 构建、烧录、调试。Simplicity Studio 只在需要改组件配置时启动平时开发完全不碰它。4.2 toolchainFile 版本对不上、401 的对照解法第一个常见的报错是配置阶段提示 toolchainFile 文件不存在。原因几乎都是 GSDK 路径里的版本号与当前安装版本不一致。解法两种回 Simplicity Studio 重新 Generate 一次让生成器写入正确路径或者手动把 CMakePresets.json 里的路径改成当前 SDK 的真实位置前提是你清楚改动的后果。第二个报错是 401 Unauthorized。出现时先检查 TAOTOKEN_API_KEY 环境变量是否真的被 Codex 读到必要时在终端确认一下其次检查 model 字段里填的模型 ID 是否在模型广场真实存在。这两个条件都满足请求就能正常通过。5. 这次预检到底烧了多少 Token去官网看用量5.1 用量页面找到这一次调用记录打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 登录后进用量页面能看到刚才那次 Codex 调用的模型名、请求时间、Token 消耗量。因为只贴了 CMakePresets.json 和 toolchain.cmake 两份文本Token 消耗很小相当于正式构建前花几毛钱做一次配置体检。这个动作对应原文「在 VS Code 里做任何更改之前先在 Simplicity Studio 里验证构建成功」那一步只是更轻。界面上的请求记录还能帮你确认请求确实走了 TaoToken 通道而不是本地某个缓存。这样当 Codex 的回答看起来异常时你能先判断是模型输出问题还是配置问题。如果你还没在这台机器上跑通过 TaoToken正好借这次预检把它配好去官网创建 Key、把 Codex 的 base_url 指到 https://taotoken.net/api、贴一份配置让它核对然后再回 VS Code 构建。5.2 之后遇到同类问题我会怎么处理以后处理同类问题我打算固定用这套流程先在 Simplicity Studio 把项目生成器切到 VS Code把新生成的 CMakePresets.json、toolchain.cmake 和 vscode.conf 贴给 Codex 做只读核对确认 toolchainFile 路径和 preset 引用都没问题时再回 VS Code 正式构建空闲时去官网用量页面对一眼 Token 开销。这样既验证了 API 通道是通的也验证了 CMake 配置自洽整个过程不依赖 Simplicity Studio 先跑一遍全量编译。这次先记到这里后面碰到新的坑我再回来更新。
分享:

看完干货,该让你的企业上线了

免费需求沟通 · 48 小时内出具建站方案 · 河南本地可上门