搞中科蓝讯方案的兄弟应该都有印象第一次打开SDK配套的CodeBlocks 17.12时满屏英文界面加上一长串编译配置确实有点劝退。但只要你把RV32-Toolchain和这个IDE之间的关系理顺整套环境从零到能编译固件正常情况下5分钟真能收工。这篇文章就专门聊中科蓝讯RISC-V开发环境怎么快速装好重点解决CodeBlocks 17.12和RV32工具链的配置问题顺带把启动时那个“thesaurus files not found”报错、汉化、MINGW版本选择这些容易卡人的细节一并说清楚。不管你是刚拿到SDK的新手还是被环境折腾到想砸电脑的老哥照着下面的步骤走一遍都能少踩几个坑。1. 先搞清楚这套环境到底是怎么回事1.1 为什么中科蓝讯要用RV32-Toolchain中科蓝讯的蓝牙音频SoCTWS耳机、音箱、Soundbar这类产品里很常见用的是RISC-V架构的32位内核不是ARM也不是8051。这意味着它需要一套专门的交叉编译工具链也就是我们常说的RV32-Toolchain来把C源码编译成芯片能跑的机器码。这套工具链里核心的几个命令是riscv32-unknown-elf-gcc、riscv32-unknown-elf-objcopy、riscv32-unknown-elf-size作用分别对应编译、格式转换和查看固件体积。很多刚上手的朋友会问为什么不能直接用电脑上的GCC因为电脑的GCC编译出来的是x86指令芯片根本执行不了。交叉编译工具链就是干这个的——它在x86的电脑上运行产出的却是RISC-V指令集的固件。中科蓝讯SDK在Windows下的传统开发姿势就是把RV32工具链和CodeBlocks 17.12捆绑使用。CodeBlocks本身只是个IDE外壳真正干活的编译器是背后的RV32-GCC。这个组合的好处是CodeBlocks足够轻量打开工程速度快不像Keil那么臃肿也不像VS Code那样需要自己配一堆插件。对产线调试和快速改代码来说这种老派但稳定的组合反而很顺手。1.2 为什么偏偏是CodeBlocks 17.12这里得说句实话中科蓝讯的SDK没有强制你非用某个IDE但官方例程、Makefile脚本、链接脚本的目录结构都是按CodeBlocks工程来组织的。你用其他IDE当然也能编前提是你会自己写Makefile或者手工敲命令。对绝大多数人来说直接用官方配好的CodeBlocks 17.12工程是最省事的。为什么是17.12而不是更新版本因为新版本CodeBlocks的工程文件格式和内置的编译器自动检测逻辑有些变化官方SDK当年开发验证时用的就是17.12你换新版反而可能遇到工程文件兼容或者编译器路径识别异常的问题。这就好比你用一把用顺手了的螺丝刀非要换新的反而拧不顺手。CodeBlocks 17.12还有一个特点它自带一个TDM-GCC或者MINGW的GCC编译器。你安装时如果勾选了带MINGW的版本它就能在本地编译一小部分工具程序。但注意这个自带GCC和RV32工具链是两码事不要混淆。真正编译目标固件时CodeBlocks调用的是RV32-Toolchain里的riscv32-unknown-elf-gcc而不是自带的MINGW gcc。这个区分很关键后面配置的时候如果搞混了编译出来的东西在芯片上跑不起来你还找不到原因。2. 安装前的关键准备选对安装包后面少走弯路2.1 带不带MINGW的区别千万别选错关于CodeBlocks的安装包网上能搜到两类一类是codeblocks-17.12mingw-setup.exe另一类是codeblocks-17.12-setup.exe后者不带MINGW编译器。这两者的区别很多教程里都没讲明白。对于中科蓝讯开发来说建议直接下载带MINGW的版本。不是因为编译固件一定要用它而是因为SDK里有一部分辅助脚本和工具是用shell或者批处理写的依赖MINGW环境里的make和rm命令。你只装不带MINGW的版本到时候执行某些清理脚本就会报错。这里补充一个细节CodeBlocks挂在编译器列表里的“GNU GCC Compiler”默认指向MINGW的gcc而中科蓝讯的RV32编译器在CodeBlocks里通常注册为“GNU ARM Cross Compiler”这种自定义名称或者直接就是“RV32 Compiler”。安装完CodeBlocks之后编译器列表里默认只会显示GNU GCC CompilerRV32那一条需要你手动添加。别急着编译先确认这一点。下载时也留意一下安装路径。很多朋友图省事直接默认装到C:\Program Files\CodeBlocks这个路径其实能用但最好改成C:\CodeBlocks或者D:\CodeBlocks这种纯英文、无空格、无特殊字符的路径。空格和Program Files里的括号在某些脚本解析时容易出幺蛾子。RV32工具链的路径同样建议放简单一点比如C:\RV32_Toolchain别学我一开始放D:\Download\新文件夹(3)\toolchain后面配置环境变量时真的会想打人。2.2 环境变量与安装路径规划RV32-Toolchain装好之后最关键的一步是让系统能找到它。工具链安装包里通常有个bin目录里面放着一堆riscv32-unknown-elf-*的可执行文件。在Windows上要么把bin目录加入系统PATH环境变量要么在CodeBlocks的编译器设置里指定完整路径。我建议两个都做加PATH是为了在命令行里随时能敲riscv32-unknown-elf-gcc -v查看版本省得每次都要输完整路径CodeBlocks里指定路径则是为了让IDE的构建过程稳定找到编译器。具体加PATH的方法不难右键“此电脑”-“属性”-“高级系统设置”-“环境变量”在系统变量里找到Path编辑新建一条填入工具链的bin目录完整路径确定保存。改完记得重新打开终端窗口因为环境变量刷新需要新进程才能读到。然后敲一下riscv32-unknown-elf-gcc -v如果能看到版本信息说明工具链本身没问题问题都集中在CodeBlocks的配置上。有个小坑必须提醒有些人电脑上装了多套工具链比如以前搞ESP32或者其他RISC-V项目留下的riscv-none-embed-gcc这套工具的gcc命令名跟中科蓝讯的riscv32-unknown-elf-gcc不一样一般情况下不会冲突。但如果你把不同工具链的bin目录都加进了PATH而它们恰好都有make.exe或者objcopy.exe那就可能造成调用混乱。建议只保留中科蓝讯SDK配套的RV32工具链在PATH里其他临时用到的工具链用完就删掉干净利落。2.3 中科蓝讯SDK的目录结构长什么样装好CodeBlocks和工具链之后接下来就是从官网或FAE那边拿SDK压缩包。解压之后你会看到SDK里通常有application、demo、doc、lib、toolchain这类目录。注意SDK里可能自带一份toolchain也可以单独下载。如果SDK里自带优先用自带的因为版本经过官方验证和SDK代码的兼容性最好。你要是自己跑去网上随便下个新版的riscv-gcc编译时可能因为工具链版本太新优化选项不兼容冒出一些莫名其妙的报错。SDK里的工程文件后缀是.cbp这是CodeBlocks的工程文件。你用CodeBlocks打开它时IDE会提示你选择编译器这时候一定要选RV32那个自定义编译器而不是默认的GNU GCC Compiler。如果没看到RV32的选项说明编译器还没注册成功需要到Settings-Compiler中手动添加。这一步是很多人卡住的第一道坎下面详细说。3. 5分钟核心配置操作把RV32工具链接进CodeBlocks3.1 验证工具链是否可用正式动手配置之前先花30秒验证一下工具链能不能用。打开cmdWinR输入cmd回车进入工具链的bin目录或者你已经配置了PATH直接敲riscv32-unknown-elf-gcc -v正常情况下会看到gcc version x.x.x以及target: riscv32-unknown-elf这类信息。如果提示“不是内部或外部命令”说明PATH配置有问题或者你输入的命令名不对。这时候检查bin目录下是不是真的存在riscv32-unknown-elf-gcc.exe。有些SDK里工具链叫riscv32-elf-gcc或者riscv-none-embed-gcc以你实际拿到的为准。这一步通过了后面的配置才顺理成章。如果你的工具链bin目录里确实有gcc可执行文件但命令行还是报找不到那问题基本出在PATH没生效。记住改完PATH一定要重新开一个cmd窗口不要用老的窗口测。这个细节我说过好多次但每次还是有人踩。3.2 在CodeBlocks里设置编译器路径打开CodeBlocks 17.12菜单栏点Settings选Compiler。这个界面左边是全局编译器设置右边是具体的编译选项。默认选中的是GNU GCC Compiler我们要新增一条。点左下角的Copy按钮把这个编译器复制一份然后重命名成“RV32 GCC Compiler”或者任何你记得住的名字。接下来在Selected compiler下拉框里选中这个新的编译器到Toolchain executables选项卡把Compilers installation directory改成RV32工具链的根目录也就是包含bin文件夹的那个目录。改完之后下面的Program Files区域会自动检测出一串文件名称比如C compiler是riscv32-unknown-elf-gcc.exeC compiler对应gLinker for dynamic libs等等。如果某些字段是空的手动点旁边的Auto-detect按钮让它自动补全。这里有个细节CodeBlocks自带的自动检测不一定能精确识别riscv32-unknown-elf-gcc如果检测结果不对就手动把每个字段填成对应的riscv32-unknown-elf-*可执行文件。C compiler填riscv32-unknown-elf-gcc.exeLinker填riscv32-unknown-elf-gcc.exe链接器一般也用gcc它会自动调ldStatic library linker填riscv32-unknown-elf-ar.exe。切换到Compiler settings选项卡这里要确认C compiler flags里没有奇奇怪怪的东西。中科蓝讯SDK的某些工程会在Additional options里写一堆自定义参数比如-marchrv32imc -mabiilp32这些是给RISC-V内核指定指令集和ABI的。你不需要手工加工程文件里通常会通过Makefile传入。但注意如果你在代码里用了DSP扩展指令而编译参数里没有开对应的-march编译会报错或者生成非法指令。这个和芯片型号强相关务必以SDK自带的配置为准别自己乱改。提示CodeBlocks全局设置里配置的编译器只是默认值。工程文件可以在Project-Build options里单独指定编译器并且往往和全局设置不同。中科蓝讯SDK例程一般会内置好编译器配置所以你只需要保证全局设置里存在RV32编译器让它能按名字匹配上就行。如果在全局设置里改了半天编译时提示找不到编译器记得看一下Build options里Selected compiler是不是选对了。3.3 用SDK自带工程验证整个链路配置好编译器之后直接用SDK里的例程来验证整个环境是否打通。打开一个最简单的工程比如GPIO点灯或者UART回环的demo点击菜单栏的Build按钮或者按CtrlF9开始编译。第一次编译因为要生成依赖文件和中间产物会慢一点大概几十秒。看到编译输出里出现类似这样的内容就说明正常riscv32-unknown-elf-gcc -c main.c -o main.o riscv32-unknown-elf-gcc main.o -o demo.elf -T script.ld riscv32-unknown-elf-objcopy -O binary demo.elf demo.bin编译结束后到工程的bin或output目录下找生成的.bin文件。这个bin文件就是要烧录进芯片的固件。如果你用的是中科蓝讯的烧录工具直接把这个bin拖进去烧就行。到这一步整个环境就算打通了。整个过程如果顺利确实用不了5分钟。但现实总是充满意外所以下面重点讲几个我碰到过的高频问题。4. CodeBlocks启动报错与汉化等环境问题处理4.1 启动时提示thesaurus files not found怎么解决这是个非常经典的老问题很多人在安装完CodeBlocks 17.12后第一次启动就会弹出一个英文警告大意是找不到thesaurus文件路径指向\spellchecker\th_en_us.idx。其实这个报错跟中科蓝讯开发没什么直接关系纯粹是CodeBlocks自带的拼写检查插件抽风了。它默认会加载一个英文词库文件但17.12自带安装包的路径处理有点bug导致插件找不到词库。解决办法有几种最省事的是直接禁用拼写检查插件。步骤如下CodeBlocks菜单栏点Plugins-Manage plugins找到SpellChecker勾选前面的复选框把它停用然后重启CodeBlocks。这个操作一劳永逸反正我们搞嵌入式开发也不需要IDE帮你检查英文单词拼写。第二种办法如果你不想禁用插件那就把安装目录下的spellchecker文件夹和th_en_us.idx文件路径重新定位一下但说实话没必要直接禁用最干净。还有一种情况是首次启动时弹出一个“Select your toolbar”的向导让你选工具条布局这个选默认的Default就行不影响任何功能。别在这些小弹窗上浪费太多时间它们跟编译环境毫无关系。4.2 界面汉化与编码设置有不少朋友习惯中文界面CodeBlocks 17.12本身的汉化机制也挺老的。常见做法是去网上下载一个locale文件夹里面是zh_CN的翻译文件放到CodeBlocks安装目录下然后在Settings-Environment-View里把界面语言改成Chinese。改完重启就能看到中文界面。不过说实话CodeBlocks这版的中文翻译并不完整很多子菜单和设置项还是英文所以也不用过分追求全中文看得懂关键几个菜单就够了。和汉化同样重要的是文件编码。中科蓝讯SDK的源码注释和字符串里有些中文如果CodeBlocks默认编码不是UTF-8编译时可能会报warning或者源码里中文注释变成乱码。建议在Settings-Editor-General settings里把Encoding设为UTF-8同时勾选“Use encoding when opening files”。这样打开源码文件时不容易乱码。编译输出窗口里如果打印出中文日志也建议把系统区域设置为中国否则可能乱码。4.3 踩坑记录最容易被忽略的三个设置第一个坑是工程Debug与Release版本的选择。CodeBlocks左下角有个下拉框可以切换Debug或Release。中科蓝讯SDK有些工程默认在Release配置下才能正常编译你用Debug编译会缺宏定义或者报链接错误。如果编译失败但又看不出明显原因先切到Release试试。第二个坑是工程的working directory。CodeBlocks在运行目标程序时依赖工程设置的工作目录但对嵌入式开发来说我们并不在电脑上直接运行固件所以工作目录设不设都行但千万不要因为设了不存在的目录导致构建阶段报错。我看到过有人把工程路径整个移动过导致相对路径失效编译时找不到链接脚本报错信息提示找不到ld文件。解决方法是重新打开.cbp工程让CodeBlocks重新解析一遍路径或者检查Build options里的Search directories是否还指向旧路径。第三个坑是杀毒软件误杀。RV32工具链里的riscv32-unknown-elf-gcc.exe是交叉编译器有些杀毒软件会把它误判为未知程序直接拦截或者隔离。表现就是编译到一半提示找不到gcc但打开bin目录发现文件还在。这时候需要把工具链目录加入杀毒软件信任区或者干脆在编译时临时关闭实时防护。这种事遇到一次就够烦的建议提前设置好。5. 编译过程中常见错误与排查5.1 链接阶段报错“无法打开文件 libgcc.a”这个报错我印象特别深因为它特别有迷惑性。报错信息会显示“cannot find -lgcc”或者“cannot open libgcc.a: No such file or directory”乍一看像是工具链缺文件其实大多数情况下是链接脚本或者库搜索路径不对。RV32-GCC在编译完C文件之后链接阶段需要找到libgcc.a这个运行库它通常位于工具链目录的lib/gcc/riscv32-unknown-elf/版本号/下面。如果工具链目录结构不完整或者CodeBlocks里链接器搜索路径配错了就会报这个错。排查方法先手动在命令行里跑一遍编译命令加上-v参数看它实际去哪些目录找库。如果命令行的输出能定位到libgcc.a但CodeBlocks编译时找不到那问题就是CodeBlocks的Search directories配置。到Project-Build options-Linker settings里把工具链的lib路径加进去比如C:\RV32_Toolchain\lib\gcc\riscv32-unknown-elf\版本号。还有一种特殊情况SDK里自带了某些静态库libxxx.a如果这些库放在工程目录的lib文件夹下也要把lib文件夹路径加进去。注意链接脚本.ld文件里指定的内存布局是芯片原厂给的不要随意修改。如果你发现自己添加了外部库导致链接地址溢出报错通常是“region FLASH overflowed”这种情况要检查的是代码体积和库的适配性而不是去强行改脚本。5.2 编译时提示找不到riscv32-unknown-elf-gcc或make这个问题基本都出在编译器路径没有配对。CodeBlocks是根据全局设置里的Toolchain executables去调用编译器的如果你在全局设置里填的是GNU GCC Compiler的路径而工程又指定用RV32编译器那构建日志里就会出现一大堆“找不到gcc”或者“Permission denied”。解决方法是回到Settings-Compiler确认当前Selected compiler是RV32检查Toolchain executables里的C compiler是否精准指向riscv32-unknown-elf-gcc.exe。另外make命令找不到也是高频问题。CodeBlocks的构建过程本质上是调用make工具去执行Makefile。如果你用的是带MINGW的CodeBlocks它会自带一个mingw32-make.exe但CodeBlocks默认的make名字是make.exe。解决思路有两个一是到MINGW目录下把mingw32-make.exe复制一份改名为make.exe二是在Settings-Compiler-Toolchain executables里把Make program改成mingw32-make.exe。我前面强调装带MINGW版本的CodeBlocks这就是原因之一。5.3 万能排查顺序编译报错的时候最忌讳的就是盯着错误日志瞎猜。我个人的排查顺序是固定的供你参考第一步看编译器有没有被正确调用。在Build log里把构建日志从“Build log”切换成“Full command line”看一下实际执行的第一条命令是不是riscv32-unknown-elf-gcc。如果不是说明编译器没选对。第二步看头文件路径。报错“xxx.h: No such file or directory”就去Project-Build options-Search directories-Compiler里把对应头文件目录加上。第三步看链接脚本路径。报错“cannot find -Txxx.ld”就去Linker settings里或者工程的Additional options里检查-T后面的路径是否正确。第四步看是不是代码问题。排除了上述三类问题之后再怀疑源码本身。中科蓝讯SDK的例程一般是验证过的但如果你改了代码编译器报错内容是语法错误或者未定义变量那就是改坏了跟环境无关。这里单独说一下如何看完整编译命令。CodeBlocks的构建日志默认只显示“xx.o -o xx.elf”这种简化内容很多信息被吞了。点构建日志窗口下方的“Full command line”复选框才能看到完整的编译命令和参数。我在帮别人排查环境问题时第一件事就是让他切到这个视图把日志发过来。光看简化日志真的看不出什么名堂。5.4 关于CodeBlocks 17.12的“老旧”与“稳定”之我见聊到最后想多说两句关于CodeBlocks 17.12本身。这版IDE在2024年来看确实谈不上现代界面朴素代码补全能力也一般。但在中科蓝讯这个特定生态里它反而成了最不容易出错的选项。RISC-V工具链迭代很快但芯片原厂SDK往往跟着稳定版本走不会轻易升级IDE。你在网上搜索中科蓝讯开发教程十有八九看到的就是CodeBlocks 17.12配RV32-Toolchain这说明这套组合在大量量产项目里经受过验证。我个人在实际操作中的体会是环境配置这件事七分在准备三分在操作。把安装包选对把路径规划好把PATH设干净后面基本一气呵成。剩下那些报错九成都是路径问题、编译器选择问题、头文件目录问题没有一个是玄学。真遇到解决不了的还有一个笨办法把SDK解压到一个全新的纯英文目录里用全新的CodeBlocks重新配一遍。很多时候折腾半天不如推倒重来因为中间改来改去的残留配置是最难查的。最后再分享一个小技巧配好环境之后马上建一个空的CodeBlocks工程把上面说的RV32编译器选上随便写个空的main函数编译一遍。确保这个空工程能通过再打开SDK例程编译。这样以后换SDK版本、换电脑时你有一个最简实验环境用来验证工具链是否正常排查问题快得多。别小看这个操作我在新电脑上装环境时全靠这个空工程先验证编译器本身再谈其他。
中科蓝讯RISC-V开发环境配置：CodeBlocks 17.12与RV32工具链实战指南
搞中科蓝讯方案的兄弟应该都有印象第一次打开SDK配套的CodeBlocks 17.12时满屏英文界面加上一长串编译配置确实有点劝退。但只要你把RV32-Toolchain和这个IDE之间的关系理顺整套环境从零到能编译固件正常情况下5分钟真能收工。这篇文章就专门聊中科蓝讯RISC-V开发环境怎么快速装好重点解决CodeBlocks 17.12和RV32工具链的配置问题顺带把启动时那个“thesaurus files not found”报错、汉化、MINGW版本选择这些容易卡人的细节一并说清楚。不管你是刚拿到SDK的新手还是被环境折腾到想砸电脑的老哥照着下面的步骤走一遍都能少踩几个坑。1. 先搞清楚这套环境到底是怎么回事1.1 为什么中科蓝讯要用RV32-Toolchain中科蓝讯的蓝牙音频SoCTWS耳机、音箱、Soundbar这类产品里很常见用的是RISC-V架构的32位内核不是ARM也不是8051。这意味着它需要一套专门的交叉编译工具链也就是我们常说的RV32-Toolchain来把C源码编译成芯片能跑的机器码。这套工具链里核心的几个命令是riscv32-unknown-elf-gcc、riscv32-unknown-elf-objcopy、riscv32-unknown-elf-size作用分别对应编译、格式转换和查看固件体积。很多刚上手的朋友会问为什么不能直接用电脑上的GCC因为电脑的GCC编译出来的是x86指令芯片根本执行不了。交叉编译工具链就是干这个的——它在x86的电脑上运行产出的却是RISC-V指令集的固件。中科蓝讯SDK在Windows下的传统开发姿势就是把RV32工具链和CodeBlocks 17.12捆绑使用。CodeBlocks本身只是个IDE外壳真正干活的编译器是背后的RV32-GCC。这个组合的好处是CodeBlocks足够轻量打开工程速度快不像Keil那么臃肿也不像VS Code那样需要自己配一堆插件。对产线调试和快速改代码来说这种老派但稳定的组合反而很顺手。1.2 为什么偏偏是CodeBlocks 17.12这里得说句实话中科蓝讯的SDK没有强制你非用某个IDE但官方例程、Makefile脚本、链接脚本的目录结构都是按CodeBlocks工程来组织的。你用其他IDE当然也能编前提是你会自己写Makefile或者手工敲命令。对绝大多数人来说直接用官方配好的CodeBlocks 17.12工程是最省事的。为什么是17.12而不是更新版本因为新版本CodeBlocks的工程文件格式和内置的编译器自动检测逻辑有些变化官方SDK当年开发验证时用的就是17.12你换新版反而可能遇到工程文件兼容或者编译器路径识别异常的问题。这就好比你用一把用顺手了的螺丝刀非要换新的反而拧不顺手。CodeBlocks 17.12还有一个特点它自带一个TDM-GCC或者MINGW的GCC编译器。你安装时如果勾选了带MINGW的版本它就能在本地编译一小部分工具程序。但注意这个自带GCC和RV32工具链是两码事不要混淆。真正编译目标固件时CodeBlocks调用的是RV32-Toolchain里的riscv32-unknown-elf-gcc而不是自带的MINGW gcc。这个区分很关键后面配置的时候如果搞混了编译出来的东西在芯片上跑不起来你还找不到原因。2. 安装前的关键准备选对安装包后面少走弯路2.1 带不带MINGW的区别千万别选错关于CodeBlocks的安装包网上能搜到两类一类是codeblocks-17.12mingw-setup.exe另一类是codeblocks-17.12-setup.exe后者不带MINGW编译器。这两者的区别很多教程里都没讲明白。对于中科蓝讯开发来说建议直接下载带MINGW的版本。不是因为编译固件一定要用它而是因为SDK里有一部分辅助脚本和工具是用shell或者批处理写的依赖MINGW环境里的make和rm命令。你只装不带MINGW的版本到时候执行某些清理脚本就会报错。这里补充一个细节CodeBlocks挂在编译器列表里的“GNU GCC Compiler”默认指向MINGW的gcc而中科蓝讯的RV32编译器在CodeBlocks里通常注册为“GNU ARM Cross Compiler”这种自定义名称或者直接就是“RV32 Compiler”。安装完CodeBlocks之后编译器列表里默认只会显示GNU GCC CompilerRV32那一条需要你手动添加。别急着编译先确认这一点。下载时也留意一下安装路径。很多朋友图省事直接默认装到C:\Program Files\CodeBlocks这个路径其实能用但最好改成C:\CodeBlocks或者D:\CodeBlocks这种纯英文、无空格、无特殊字符的路径。空格和Program Files里的括号在某些脚本解析时容易出幺蛾子。RV32工具链的路径同样建议放简单一点比如C:\RV32_Toolchain别学我一开始放D:\Download\新文件夹(3)\toolchain后面配置环境变量时真的会想打人。2.2 环境变量与安装路径规划RV32-Toolchain装好之后最关键的一步是让系统能找到它。工具链安装包里通常有个bin目录里面放着一堆riscv32-unknown-elf-*的可执行文件。在Windows上要么把bin目录加入系统PATH环境变量要么在CodeBlocks的编译器设置里指定完整路径。我建议两个都做加PATH是为了在命令行里随时能敲riscv32-unknown-elf-gcc -v查看版本省得每次都要输完整路径CodeBlocks里指定路径则是为了让IDE的构建过程稳定找到编译器。具体加PATH的方法不难右键“此电脑”-“属性”-“高级系统设置”-“环境变量”在系统变量里找到Path编辑新建一条填入工具链的bin目录完整路径确定保存。改完记得重新打开终端窗口因为环境变量刷新需要新进程才能读到。然后敲一下riscv32-unknown-elf-gcc -v如果能看到版本信息说明工具链本身没问题问题都集中在CodeBlocks的配置上。有个小坑必须提醒有些人电脑上装了多套工具链比如以前搞ESP32或者其他RISC-V项目留下的riscv-none-embed-gcc这套工具的gcc命令名跟中科蓝讯的riscv32-unknown-elf-gcc不一样一般情况下不会冲突。但如果你把不同工具链的bin目录都加进了PATH而它们恰好都有make.exe或者objcopy.exe那就可能造成调用混乱。建议只保留中科蓝讯SDK配套的RV32工具链在PATH里其他临时用到的工具链用完就删掉干净利落。2.3 中科蓝讯SDK的目录结构长什么样装好CodeBlocks和工具链之后接下来就是从官网或FAE那边拿SDK压缩包。解压之后你会看到SDK里通常有application、demo、doc、lib、toolchain这类目录。注意SDK里可能自带一份toolchain也可以单独下载。如果SDK里自带优先用自带的因为版本经过官方验证和SDK代码的兼容性最好。你要是自己跑去网上随便下个新版的riscv-gcc编译时可能因为工具链版本太新优化选项不兼容冒出一些莫名其妙的报错。SDK里的工程文件后缀是.cbp这是CodeBlocks的工程文件。你用CodeBlocks打开它时IDE会提示你选择编译器这时候一定要选RV32那个自定义编译器而不是默认的GNU GCC Compiler。如果没看到RV32的选项说明编译器还没注册成功需要到Settings-Compiler中手动添加。这一步是很多人卡住的第一道坎下面详细说。3. 5分钟核心配置操作把RV32工具链接进CodeBlocks3.1 验证工具链是否可用正式动手配置之前先花30秒验证一下工具链能不能用。打开cmdWinR输入cmd回车进入工具链的bin目录或者你已经配置了PATH直接敲riscv32-unknown-elf-gcc -v正常情况下会看到gcc version x.x.x以及target: riscv32-unknown-elf这类信息。如果提示“不是内部或外部命令”说明PATH配置有问题或者你输入的命令名不对。这时候检查bin目录下是不是真的存在riscv32-unknown-elf-gcc.exe。有些SDK里工具链叫riscv32-elf-gcc或者riscv-none-embed-gcc以你实际拿到的为准。这一步通过了后面的配置才顺理成章。如果你的工具链bin目录里确实有gcc可执行文件但命令行还是报找不到那问题基本出在PATH没生效。记住改完PATH一定要重新开一个cmd窗口不要用老的窗口测。这个细节我说过好多次但每次还是有人踩。3.2 在CodeBlocks里设置编译器路径打开CodeBlocks 17.12菜单栏点Settings选Compiler。这个界面左边是全局编译器设置右边是具体的编译选项。默认选中的是GNU GCC Compiler我们要新增一条。点左下角的Copy按钮把这个编译器复制一份然后重命名成“RV32 GCC Compiler”或者任何你记得住的名字。接下来在Selected compiler下拉框里选中这个新的编译器到Toolchain executables选项卡把Compilers installation directory改成RV32工具链的根目录也就是包含bin文件夹的那个目录。改完之后下面的Program Files区域会自动检测出一串文件名称比如C compiler是riscv32-unknown-elf-gcc.exeC compiler对应gLinker for dynamic libs等等。如果某些字段是空的手动点旁边的Auto-detect按钮让它自动补全。这里有个细节CodeBlocks自带的自动检测不一定能精确识别riscv32-unknown-elf-gcc如果检测结果不对就手动把每个字段填成对应的riscv32-unknown-elf-*可执行文件。C compiler填riscv32-unknown-elf-gcc.exeLinker填riscv32-unknown-elf-gcc.exe链接器一般也用gcc它会自动调ldStatic library linker填riscv32-unknown-elf-ar.exe。切换到Compiler settings选项卡这里要确认C compiler flags里没有奇奇怪怪的东西。中科蓝讯SDK的某些工程会在Additional options里写一堆自定义参数比如-marchrv32imc -mabiilp32这些是给RISC-V内核指定指令集和ABI的。你不需要手工加工程文件里通常会通过Makefile传入。但注意如果你在代码里用了DSP扩展指令而编译参数里没有开对应的-march编译会报错或者生成非法指令。这个和芯片型号强相关务必以SDK自带的配置为准别自己乱改。提示CodeBlocks全局设置里配置的编译器只是默认值。工程文件可以在Project-Build options里单独指定编译器并且往往和全局设置不同。中科蓝讯SDK例程一般会内置好编译器配置所以你只需要保证全局设置里存在RV32编译器让它能按名字匹配上就行。如果在全局设置里改了半天编译时提示找不到编译器记得看一下Build options里Selected compiler是不是选对了。3.3 用SDK自带工程验证整个链路配置好编译器之后直接用SDK里的例程来验证整个环境是否打通。打开一个最简单的工程比如GPIO点灯或者UART回环的demo点击菜单栏的Build按钮或者按CtrlF9开始编译。第一次编译因为要生成依赖文件和中间产物会慢一点大概几十秒。看到编译输出里出现类似这样的内容就说明正常riscv32-unknown-elf-gcc -c main.c -o main.o riscv32-unknown-elf-gcc main.o -o demo.elf -T script.ld riscv32-unknown-elf-objcopy -O binary demo.elf demo.bin编译结束后到工程的bin或output目录下找生成的.bin文件。这个bin文件就是要烧录进芯片的固件。如果你用的是中科蓝讯的烧录工具直接把这个bin拖进去烧就行。到这一步整个环境就算打通了。整个过程如果顺利确实用不了5分钟。但现实总是充满意外所以下面重点讲几个我碰到过的高频问题。4. CodeBlocks启动报错与汉化等环境问题处理4.1 启动时提示thesaurus files not found怎么解决这是个非常经典的老问题很多人在安装完CodeBlocks 17.12后第一次启动就会弹出一个英文警告大意是找不到thesaurus文件路径指向\spellchecker\th_en_us.idx。其实这个报错跟中科蓝讯开发没什么直接关系纯粹是CodeBlocks自带的拼写检查插件抽风了。它默认会加载一个英文词库文件但17.12自带安装包的路径处理有点bug导致插件找不到词库。解决办法有几种最省事的是直接禁用拼写检查插件。步骤如下CodeBlocks菜单栏点Plugins-Manage plugins找到SpellChecker勾选前面的复选框把它停用然后重启CodeBlocks。这个操作一劳永逸反正我们搞嵌入式开发也不需要IDE帮你检查英文单词拼写。第二种办法如果你不想禁用插件那就把安装目录下的spellchecker文件夹和th_en_us.idx文件路径重新定位一下但说实话没必要直接禁用最干净。还有一种情况是首次启动时弹出一个“Select your toolbar”的向导让你选工具条布局这个选默认的Default就行不影响任何功能。别在这些小弹窗上浪费太多时间它们跟编译环境毫无关系。4.2 界面汉化与编码设置有不少朋友习惯中文界面CodeBlocks 17.12本身的汉化机制也挺老的。常见做法是去网上下载一个locale文件夹里面是zh_CN的翻译文件放到CodeBlocks安装目录下然后在Settings-Environment-View里把界面语言改成Chinese。改完重启就能看到中文界面。不过说实话CodeBlocks这版的中文翻译并不完整很多子菜单和设置项还是英文所以也不用过分追求全中文看得懂关键几个菜单就够了。和汉化同样重要的是文件编码。中科蓝讯SDK的源码注释和字符串里有些中文如果CodeBlocks默认编码不是UTF-8编译时可能会报warning或者源码里中文注释变成乱码。建议在Settings-Editor-General settings里把Encoding设为UTF-8同时勾选“Use encoding when opening files”。这样打开源码文件时不容易乱码。编译输出窗口里如果打印出中文日志也建议把系统区域设置为中国否则可能乱码。4.3 踩坑记录最容易被忽略的三个设置第一个坑是工程Debug与Release版本的选择。CodeBlocks左下角有个下拉框可以切换Debug或Release。中科蓝讯SDK有些工程默认在Release配置下才能正常编译你用Debug编译会缺宏定义或者报链接错误。如果编译失败但又看不出明显原因先切到Release试试。第二个坑是工程的working directory。CodeBlocks在运行目标程序时依赖工程设置的工作目录但对嵌入式开发来说我们并不在电脑上直接运行固件所以工作目录设不设都行但千万不要因为设了不存在的目录导致构建阶段报错。我看到过有人把工程路径整个移动过导致相对路径失效编译时找不到链接脚本报错信息提示找不到ld文件。解决方法是重新打开.cbp工程让CodeBlocks重新解析一遍路径或者检查Build options里的Search directories是否还指向旧路径。第三个坑是杀毒软件误杀。RV32工具链里的riscv32-unknown-elf-gcc.exe是交叉编译器有些杀毒软件会把它误判为未知程序直接拦截或者隔离。表现就是编译到一半提示找不到gcc但打开bin目录发现文件还在。这时候需要把工具链目录加入杀毒软件信任区或者干脆在编译时临时关闭实时防护。这种事遇到一次就够烦的建议提前设置好。5. 编译过程中常见错误与排查5.1 链接阶段报错“无法打开文件 libgcc.a”这个报错我印象特别深因为它特别有迷惑性。报错信息会显示“cannot find -lgcc”或者“cannot open libgcc.a: No such file or directory”乍一看像是工具链缺文件其实大多数情况下是链接脚本或者库搜索路径不对。RV32-GCC在编译完C文件之后链接阶段需要找到libgcc.a这个运行库它通常位于工具链目录的lib/gcc/riscv32-unknown-elf/版本号/下面。如果工具链目录结构不完整或者CodeBlocks里链接器搜索路径配错了就会报这个错。排查方法先手动在命令行里跑一遍编译命令加上-v参数看它实际去哪些目录找库。如果命令行的输出能定位到libgcc.a但CodeBlocks编译时找不到那问题就是CodeBlocks的Search directories配置。到Project-Build options-Linker settings里把工具链的lib路径加进去比如C:\RV32_Toolchain\lib\gcc\riscv32-unknown-elf\版本号。还有一种特殊情况SDK里自带了某些静态库libxxx.a如果这些库放在工程目录的lib文件夹下也要把lib文件夹路径加进去。注意链接脚本.ld文件里指定的内存布局是芯片原厂给的不要随意修改。如果你发现自己添加了外部库导致链接地址溢出报错通常是“region FLASH overflowed”这种情况要检查的是代码体积和库的适配性而不是去强行改脚本。5.2 编译时提示找不到riscv32-unknown-elf-gcc或make这个问题基本都出在编译器路径没有配对。CodeBlocks是根据全局设置里的Toolchain executables去调用编译器的如果你在全局设置里填的是GNU GCC Compiler的路径而工程又指定用RV32编译器那构建日志里就会出现一大堆“找不到gcc”或者“Permission denied”。解决方法是回到Settings-Compiler确认当前Selected compiler是RV32检查Toolchain executables里的C compiler是否精准指向riscv32-unknown-elf-gcc.exe。另外make命令找不到也是高频问题。CodeBlocks的构建过程本质上是调用make工具去执行Makefile。如果你用的是带MINGW的CodeBlocks它会自带一个mingw32-make.exe但CodeBlocks默认的make名字是make.exe。解决思路有两个一是到MINGW目录下把mingw32-make.exe复制一份改名为make.exe二是在Settings-Compiler-Toolchain executables里把Make program改成mingw32-make.exe。我前面强调装带MINGW版本的CodeBlocks这就是原因之一。5.3 万能排查顺序编译报错的时候最忌讳的就是盯着错误日志瞎猜。我个人的排查顺序是固定的供你参考第一步看编译器有没有被正确调用。在Build log里把构建日志从“Build log”切换成“Full command line”看一下实际执行的第一条命令是不是riscv32-unknown-elf-gcc。如果不是说明编译器没选对。第二步看头文件路径。报错“xxx.h: No such file or directory”就去Project-Build options-Search directories-Compiler里把对应头文件目录加上。第三步看链接脚本路径。报错“cannot find -Txxx.ld”就去Linker settings里或者工程的Additional options里检查-T后面的路径是否正确。第四步看是不是代码问题。排除了上述三类问题之后再怀疑源码本身。中科蓝讯SDK的例程一般是验证过的但如果你改了代码编译器报错内容是语法错误或者未定义变量那就是改坏了跟环境无关。这里单独说一下如何看完整编译命令。CodeBlocks的构建日志默认只显示“xx.o -o xx.elf”这种简化内容很多信息被吞了。点构建日志窗口下方的“Full command line”复选框才能看到完整的编译命令和参数。我在帮别人排查环境问题时第一件事就是让他切到这个视图把日志发过来。光看简化日志真的看不出什么名堂。5.4 关于CodeBlocks 17.12的“老旧”与“稳定”之我见聊到最后想多说两句关于CodeBlocks 17.12本身。这版IDE在2024年来看确实谈不上现代界面朴素代码补全能力也一般。但在中科蓝讯这个特定生态里它反而成了最不容易出错的选项。RISC-V工具链迭代很快但芯片原厂SDK往往跟着稳定版本走不会轻易升级IDE。你在网上搜索中科蓝讯开发教程十有八九看到的就是CodeBlocks 17.12配RV32-Toolchain这说明这套组合在大量量产项目里经受过验证。我个人在实际操作中的体会是环境配置这件事七分在准备三分在操作。把安装包选对把路径规划好把PATH设干净后面基本一气呵成。剩下那些报错九成都是路径问题、编译器选择问题、头文件目录问题没有一个是玄学。真遇到解决不了的还有一个笨办法把SDK解压到一个全新的纯英文目录里用全新的CodeBlocks重新配一遍。很多时候折腾半天不如推倒重来因为中间改来改去的残留配置是最难查的。最后再分享一个小技巧配好环境之后马上建一个空的CodeBlocks工程把上面说的RV32编译器选上随便写个空的main函数编译一遍。确保这个空工程能通过再打开SDK例程编译。这样以后换SDK版本、换电脑时你有一个最简实验环境用来验证工具链是否正常排查问题快得多。别小看这个操作我在新电脑上装环境时全靠这个空工程先验证编译器本身再谈其他。
