1. 先说清楚这套环境到底解决什么问题中科蓝讯的蓝牙音频芯片内核用的都是RISC-V 32位架构你要给这类芯片写固件、做二次开发绕不开RV32-Toolchain这套工具链。而CodeBlocks 17.12是官方SDK默认绑定的IDE很多刚拿到开发包的人第一步就卡在环境搭不上——不是工具链解压失败就是CodeBlocks启动报错再要么编译器配好了却编不过官方例程。这篇文章把从零到编译点亮一块板子的完整流程写出来中间包含我踩过的所有坑和排查思路适合刚拿到中科蓝讯SDK的嵌入式新手也适合要给团队统一部署开发环境的组长。我当年第一次装这套环境断断续续折腾了一个周末。中间换过三个版本的CodeBlocks重装过两个来源的RV32工具链才搞清楚问题在哪。后来帮同事配过不下十次摸清了里面的门道其实按正确顺序来做快的话真的5分钟就能搞定。整个过程说白了就三件事装对CodeBlocks、解压工具链并配好路径、在IDE里告诉编译器去哪找人。任何一步顺序错了或者版本不对后面就会连环报错。1.1 中科蓝讯芯片和RV32工具链是什么关系中科蓝讯的音频SoC内部CPU核用的是RISC-V指令集架构。RV32的32指的就是32位RISC-V指令集。RISC-V是开放指令集任何公司都可以基于它实现自己的处理器中科蓝讯在内核基础上还做了自定义扩展比如针对音频编解码、蓝牙协议栈优化过的指令。这部分扩展只有在官方工具链里才有完整支持。这就带来一个非常实际的问题你不能随便拿一个通用RISC-V GCC去编中科蓝讯的代码。标准C代码也许能编过但一碰到寄存器定义、中断处理、音频DSP相关的底层操作就可能直接编译失败或者编出的固件在芯片上行为异常。所以必须用官方的RV32-Toolchain。这个工具链里的编译器有些版本叫riscv32-unknown-elf-gcc有些叫riscv-none-embed-gcc具体以你SDK里集成的版本为准后面配置时按实际文件名填。1.2 为什么偏偏是CodeBlocks 17.12很多朋友拿到SDK第一反应是这都什么年代了官方怎么还在用17.12这种老IDE说实话我最初也这么想。后来才明白嵌入式原厂选IDE优先考虑的从来不是新潮而是可控和稳定。CodeBlocks开源、免费、支持挂载任意自定义编译器非常适合原厂直接打包进SDK做默认IDE。而17.12这个版本虽然界面朴素但对自定义编译器、自定义Makefile的支持相当成熟原厂所有例程都是在这个版本上验证过的你跟着用自然最省心。你要是强行换新版CodeBlocks或者换别的IDE第一关就是SDK自带的workspace文件可能打不开或者部分兼容工程模板对不上自动化脚本识别不了。那就不叫升级叫给自己找活干。我的建议很直接别换就用官方搭配。省下来的时间拿去写业务代码比什么都值。2. 开工前的准备下载清单和版本匹配2.1 需要准备哪些文件先把需要的文件列全免得装到一半发现缺东西还得回头重新下载。建议一次性备齐CodeBlocks 17.12安装包。注意选不带MinGW的版本文件名里一般不含mingw字样。带MinGW的版本会捆绑一份x86 GCC编译器我们对接的是RISC-V工具链用不上它反而容易让IDE在编译器选择上变混乱。RV32-Toolchain工具链包。通常是压缩包解压即用。官方SDK整合包里一般会带没有的话单独下载对应版本。中科蓝讯官方SDK包。里面是芯片头文件、驱动库、链接脚本、官方示例工程。开发板资料和一个准备烧录验证的官方例程。如果打算汉化额外准备与17.12严格对应的汉化包一般是zh_CN.mo文件或整个locale目录。这里特别提醒很多人看到CodeBlocks 17.12习惯性跑官网下最新版。中科蓝讯SDK里官方用的就是17.12SDK里的自动化脚本、预置模板都是按这个版本验证过的。用其他版本你可能需要手动移植工程配置还不一定完全兼容。2.2 版本搭配的三个原则根据我反复踩坑总结的经验版本搭配认准三条第一IDE版本以SDK指定为准。用17.12官方workspace双击就能打开Build按钮一按就编过。用其他版本就得手动移植配置纯属浪费时间。第二工具链版本跟着SDK走。RV32-Toolchain有多个版本迭代不同版本的编译器名称、默认库路径都有差异。比如有的版本编译器叫riscv32-unknown-elf-gcc有的叫riscv-none-embed-gcc。官方SDK如果按前者配置你装个后者编译一开始就会报错。第三所有路径避免中文和空格。包括安装路径、工程路径、SDK路径。Windows下程序里带空格的路径经常让Makefile和编译脚本断掉特别是在参数传递时没有做引号转义的情况下。宁可最开始多花三分钟把路径理顺也不要等编译报错了再回头找原因。3. CodeBlocks 17.12 安装步骤与首启配置3.1 安装主程序时容易忽略的细节安装过程本身不难但几个细节直接决定后面顺不顺。双击安装包同意协议一路下一步。安装路径建议改成D:\CodeBlocks或C:\CodeBlocks。不建议用默认的C:\Program Files\CodeBlocks带空格的路径在调用make和工具链脚本时容易出状况这是实际经验。组件选择界面默认勾选就够了。如果下载的是带MinGW的版本安装时它会捆绑GCC编译器。这东西我们不需要反而会在首次启动时被CodeBlocks自动检测为默认编译器后面打开官方工程IDE可能默认走GCC编出来的东西根本烧不进芯片。最稳的做法就是下载不带MinGW的版本。装好后先别急着打开。等RV32工具链和路径准备好再一次性配置避免反复折腾。如果用的是官方SDK整合包里自带的便携版CodeBlocks那就更简单了解压到D:\CodeBlocks就能用。便携版的好处是干净整个目录可以随意搬迁缺点是不会自动关联文件类型但这不影响日常使用。3.2 thesaurus files报错原因和三种解法CodeBlocks 17.12装好后首次启动很多人会遇到一个弹窗thesaurus files \spellchecker\th_en_us.idx not found这个弹窗的意思是拼写检查插件SpellChecker在初始化时要加载英文同义词词典文件th_en_us.idx但在它预期的路径下找不到文件。这并不是你的安装有问题而是17.12版在部分系统上的已知毛病。我第一次遇到这个报错第一反应是安装包坏了重装了一遍还在报才去认真查原因。后来发现这是插件配置里记录的相对路径与实际安装目录对不上。如果系统是中文Windows路径解析更容易出问题。网上能搜到大量相关内容说明不是个例。解决方案按推荐顺序排三个第一种直接忽略。点掉弹窗继续用。这个报错不影响编译、不影响代码编辑只是每次启动都会弹一下。不想折腾就用这种方式。第二种停用SpellChecker插件。打开CodeBlocks菜单栏点击Plugins - Manage plugins在列表里找到SpellChecker选中后点Disable重启CodeBlocks弹窗彻底消失。这是最一劳永逸的做法强烈推荐。第三种手动补文件。网上下载th_en_us.idx放进CodeBlocks安装目录下的SpellChecker目录没有这个目录就新建一个。如果确实需要保留拼写检查功能可以这样修。不过做嵌入式开发这功能本身用处不大不建议在这里花时间。3.3 汉化要不要做怎么做我的建议是可以汉化但别在初次配置的时候做。等环境全部配好、官方例程编译通过再汉化不迟。先汉化有个问题菜单名、选项名全变了你再去看官方教程或者技术文章里面提到的英文菜单项就对不上号配置效率反而更低。而且不少汉化包会改动配置文件如果编译器路径还没配好就汉化出了问题更不好排查。汉化步骤不复杂准备与17.12严格对应的汉化包把zh_CN.mo文件复制到CodeBlocks安装目录下的locale\zh_CN\LC_MESSAGES文件夹里没有就依次创建然后打开CodeBlocks进入Settings - Environment - View勾选internationalization选择Chinese重启生效。需要强调一句不要下载来路不明的汉化整合版。我见过有人用的所谓“精简便携汉化版”里面被塞了额外插件还有人的汉化包把编译器路径配置全改了重新配了一下午才恢复。要汉化就用原版加对应版本的汉化包干净可控。4. RV32-Toolchain安装与系统路径配置4.1 解压工具链到统一目录RV32-Toolchain不需要像普通软件那样走安装向导拿到压缩包直接解压就能用。重点在于解压到哪里。我建议建一个专门的嵌入式工具目录比如D:\embedded把工具链解压到D:\embedded\rv32-toolchain。目录清晰好管理以后工具链升级、备份都方便。解压完成后你会看到bin、lib、include、riscv32-unknown-elf等目录。bin里面放的是真正会被CodeBlocks调用的可执行文件包括编译器riscv32-unknown-elf-gcc.exe、交叉调试器riscv32-unknown-elf-gdb.exe、固件格式转换工具riscv32-unknown-elf-objcopy.exe以及make.exe。一个容易被忽略的问题解压前先确认杀毒软件没有把工具链误报清除。RISC-V工具链里的部分可执行文件没有数字签名有些杀软会误报。如果解压后发现文件夹里文件不全或者运行没反应先翻杀软隔离区。这个事我遇到过不是开玩笑。4.2 设置PATH环境变量工具链解压完为了让命令行和CodeBlocks都能直接找到编译器需要把bin目录加进系统PATH。Windows各版本操作路径略有差别但核心逻辑一样右键“此电脑”选择“属性”选择“高级系统设置”点击“环境变量”在“系统变量”里找到Path双击编辑点击“新建”填入D:\embedded\rv32-toolchain\bin确定保存这里反复强调一定要配置在“系统变量”栏不要只配在“用户变量”。原因很现实CodeBlocks开发时经常以管理员权限启动管理员权限下用户环境变量读取范围与普通权限不一致可能会导致同一个工具链一会儿能编译一会儿又报找不到编译器。配置系统变量后所有用户、所有程序统一可见排查问题少一个变量。4.3 命令行验证编译器是否可用环境变量配完后必须验证。打开一个全新的命令行窗口注意是新开的窗口旧窗口不会自动刷新环境变量。输入riscv32-unknown-elf-gcc --version如果看到类似riscv32-unknown-elf-gcc (GCC) 版本信息的输出说明工具链路径生效。如果提示“不是内部或外部命令”按下面的顺序排查环境变量是否真的保存了。有时候点了确定窗口却异常退出实际上没存上。填写的路径和实际解压路径是否一致。D:\embedded\rv32-toolchain\bin少一层都不行。编译器文件名是否匹配。有些工具链版本里编译器叫riscv32-unknown-elf-gcc.exe有些叫riscv-none-embed-gcc.exe。我在公司给同事配环境时最常遇到的情况是环境变量明明配对了但SDK工程里写的是riscv32-unknown-elf-gcc工具链bin目录里实际是riscv-none-embed-gcc.exe。这种不匹配会出现典型的“自己编译别想编过官方例程也可能直接报错”的现象。我的建议是保留工具链原始文件名到CodeBlocks的编译器配置里改成实际名字不要乱改工具链文件结构。5. CodeBlocks中对接RV32工具链编译第一个例程5.1 在编译器设置里新增RV32编译器工具链和系统环境都处理好后回到CodeBlocks做最后一步对接。核心逻辑就是让IDE认识这套新编译器。具体操作打开CodeBlocks点击菜单Settings - Compiler在弹出的对话框左下角先点Copy按钮复制一份当前编译器配置重命名为RV32 GCC。这样做的目的是复用默认编译参数避免从零配置漏掉选项在Selected compiler下拉框里选择刚才创建的RV32 GCC切到Toolchain executables选项卡把Compilers installation directory改成D:\embedded\rv32-toolchainProgram Files区域里C compiler填riscv32-unknown-elf-gcc.exeC compiler填riscv32-unknown-elf-g.exe其他字段按默认确认无误后点OK保存这里有个高频细节安装目录填的是工具链根目录不是bin目录。CodeBlocks会自己到根目录下的bin目录找可执行文件你填成bin目录反而找不到编译器。这个错误我见好几个同事犯过单独拎出来说。5.2 打开或新建工程三个路径必须核对编译器配置好之后打开官方SDK里的workspace文件一般是.workspace或.cbp格式的工程描述文件。打开后三个路径十有八九藏着坑第一个Project - Build options - Search directories里的Compiler路径。在Compiler选项卡里确认头文件搜索路径已经包含SDK的include目录。如果你把SDK复制到了别的目录官方工程里原本的相对路径可能会失效需要手动改成绝对路径。第二个Linker路径。切到Linker选项卡确认链接脚本所在目录、启动文件和库文件目录都在搜索路径里。中科蓝讯SDK里的链接脚本一般是.ld文件启动文件是startup相关的汇编或目标文件。这些路径不对的话会出现“编译全过、链接全挂”的诡异情况。第三个Make命令。在Build options里找到Make commands相关设置CodeBlocks默认调用mingw32-make或make。如果你用的工具链包里自带make.exe建议明确指定完整路径避免CodeBlocks误抓到系统的make参数风格不兼容。三个路径核对完保存工程。这个过程大约两分钟但能省下后面无数个排查的夜晚。5.3 第一个例程的编译体验路径配好后找官方例程试水。中科蓝讯SDK里一般都有点灯、按键、Flash读写这类基础例程先用最简单的点灯例程验证环境。点击Build按钮底部日志窗口开始滚动编译输出。第一次编译要生成各种中间文件慢一些正常十几秒到半分钟不等。看到日志最后出现0 errors, 0 warnings基本就能确认环境可用了。如果只有几个warning没有error先别慌。嵌入式代码里的warning有很多种变量未使用、函数未声明通常不影响最终固件生成。但如果你发现warning数量特别大建议回去检查编译器版本是否和SDK预期一致版本不匹配才是大量warning的真凶。编译成功生成的固件文件一般在工程目录的bin\Debug或bin\Release下。.bin文件直接烧录Flash.hex文件适合调试器下载。用官方烧录工具把固件烧进开发板看到LED亮起来的那一刻整套环境就彻底打通了。6. 坑都替你们踩过了常见报错与完整排查链路6.1 thesaurus files报错从弹窗到彻底解决这个报错前面已经介绍过这里用排查视角再过一遍完整链路方便你遇到同类问题时知道怎么下手。假设刚装完CodeBlocks双击启动弹窗出现thesaurus files \spellchecker\th_en_us.idx not found。我的排查顺序是第一步判断是不是安装不完整。打开安装目录找spellchecker文件夹看里面有没有th_en_us.idx文件。文件在说明文件齐全问题出在插件配置文件不在重新安装或从别人机器复制一份。第二步看安装路径和用户目录有没有中文。17.12在中文路径下SpellChecker插件对相对路径的解析特别容易出现偏差。这个报错在中文系统用户里出现频率很高网上相关内容一大把。第三步不想再纠结直接禁插件。Plugins - Manage plugins禁用SpellChecker重启就没了。整个过程不超过二十秒。说到底这个报错和编译环境没有半点关系。很多第一次接触CodeBlocks的人会误以为环境搭建失败反复卸载重装纯粹浪费时间。它只是IDE自带拼写插件显示层面的问题。6.2 编译提示make: command not found或找不到编译器这个报错极其经典。点击Build按钮日志窗口直接报错意思是CodeBlocks根本找不到可用的编译器和make程序。排查链路检查Settings - Compiler - Toolchain executables里Selected compiler是否真的选到了RV32 GCC。很多人改了编译器设置但当前工程还在用默认的GNU GCC CompilerBuild时自然找不到riscv相关命令。检查C compiler字段的编译器名字确保是riscv32-unknown-elf-gcc.exe。如果工具链bin目录里实际是riscv-none-embed-gcc.exe就在这里填实际存在的名字。检查Make Program字段。这个字段在默认情况下可能为空或者指到了系统里不存在的make。需要手动指向工具链bin目录下的make.exe。我第一次遇到这个问题就是因为Make Program为空。填上之后编译流程瞬间正常。这个字段平时不显眼但在嵌入式工具链场景下特别容易空值或错值。6.3 编译时报找不到头文件stdint.h、stdio.h编译时报fatal error: stdint.h: No such file or directory说明编译器没有找到标准头文件。你要清楚RISC-V工具链的标准头文件路径跟Windows系统GCC完全不一样它在工具链目录下的riscv32-unknown-elf\include里。排查链路先通过系统搜索找到工具链下include目录的完整路径。再到Project - Build options - Search directories - Compiler里加上这个include目录。确认没有把系统自带的Windows include路径混进来。两套头文件混用表面可能编过但底层ABI不一致固件烧到芯片上就会表现怪异。这个问题在工程从一台电脑复制到另一台电脑时特别常见。路径失效了就直接改回来属于问题里最好修的一类。6.4 链接阶段找不到启动文件或库文件如果编译能过但链接时报错cannot find -lxxx或者undefined reference to_start说明链接脚本、启动文件或者库文件的路径没配对。中科蓝讯SDK的链接脚本定制性很强芯片型号不同、Flash大小不同链接脚本就不同启动文件里的汇编内容也不同。我的建议是除非你非常清楚自己在做什么否则优先用官方workspace不要自己新建工程。官方workspace报错先检查工程路径是否变过。SDK整体挪了位置相对路径很可能失效。去Build options - Search directories - Linker把启动文件、链接脚本、静态库所在目录全部加上。链接脚本要在Linker options里显式指定比如-Tscript.ld这种参数。缺了这个链接器不知道把代码放到哪个内存地址。这类问题通常是还不熟SDK结构时遇到最多的一种。解决办法不复杂拿着官方工程和官方Makefile对照哪个路径缺了一眼就能看出来。6.5 汉化包导致的乱码和配置失效最后一个坑专门说给想汉化的人。我有一次帮同事排查了一个下午发现他的CodeBlocks打开后菜单全是乱码之前配好的RV32编译器全部消失。最后发现他用的所谓“高清完整汉化版”是第三方整合包里面改了配置文件路径和插件结构之前配好的信息存在旧路径整合版读的是新路径自然全部失效。解决办法是卸载整合版用官方原版重装再手动打汉化补丁。折腾一下午又回到最原始的方案。这件事之后我的原则很明确能用原版就不碰整合版。工具链配置这件事稳定压倒一切。真想要中文界面也等所有功能跑通之后再汉化顺序千万别颠倒。最后再说一点实操经验。整个流程走顺之后我给新同事配环境最快的一次确实只用了五分钟三分半钟解压工具链、装CodeBlocks一分半钟配环境变量、指定编译器路径。想达到这个速度关键是把所有工具版本固定下来不要每次用不同来源的安装包反复试。一旦有人在团队里配成功了就把整个工具链目录和CodeBlocks安装目录打包分享其他人直接解压就能用环境变量写个脚本一键设置。这个做法能省掉大量重复劳动。反正环境装好就是为了赶紧写代码别在这件事上磨洋工。
中科蓝讯RISC-V开发环境搭建：CodeBlocks与RV32工具链配置指南
1. 先说清楚这套环境到底解决什么问题中科蓝讯的蓝牙音频芯片内核用的都是RISC-V 32位架构你要给这类芯片写固件、做二次开发绕不开RV32-Toolchain这套工具链。而CodeBlocks 17.12是官方SDK默认绑定的IDE很多刚拿到开发包的人第一步就卡在环境搭不上——不是工具链解压失败就是CodeBlocks启动报错再要么编译器配好了却编不过官方例程。这篇文章把从零到编译点亮一块板子的完整流程写出来中间包含我踩过的所有坑和排查思路适合刚拿到中科蓝讯SDK的嵌入式新手也适合要给团队统一部署开发环境的组长。我当年第一次装这套环境断断续续折腾了一个周末。中间换过三个版本的CodeBlocks重装过两个来源的RV32工具链才搞清楚问题在哪。后来帮同事配过不下十次摸清了里面的门道其实按正确顺序来做快的话真的5分钟就能搞定。整个过程说白了就三件事装对CodeBlocks、解压工具链并配好路径、在IDE里告诉编译器去哪找人。任何一步顺序错了或者版本不对后面就会连环报错。1.1 中科蓝讯芯片和RV32工具链是什么关系中科蓝讯的音频SoC内部CPU核用的是RISC-V指令集架构。RV32的32指的就是32位RISC-V指令集。RISC-V是开放指令集任何公司都可以基于它实现自己的处理器中科蓝讯在内核基础上还做了自定义扩展比如针对音频编解码、蓝牙协议栈优化过的指令。这部分扩展只有在官方工具链里才有完整支持。这就带来一个非常实际的问题你不能随便拿一个通用RISC-V GCC去编中科蓝讯的代码。标准C代码也许能编过但一碰到寄存器定义、中断处理、音频DSP相关的底层操作就可能直接编译失败或者编出的固件在芯片上行为异常。所以必须用官方的RV32-Toolchain。这个工具链里的编译器有些版本叫riscv32-unknown-elf-gcc有些叫riscv-none-embed-gcc具体以你SDK里集成的版本为准后面配置时按实际文件名填。1.2 为什么偏偏是CodeBlocks 17.12很多朋友拿到SDK第一反应是这都什么年代了官方怎么还在用17.12这种老IDE说实话我最初也这么想。后来才明白嵌入式原厂选IDE优先考虑的从来不是新潮而是可控和稳定。CodeBlocks开源、免费、支持挂载任意自定义编译器非常适合原厂直接打包进SDK做默认IDE。而17.12这个版本虽然界面朴素但对自定义编译器、自定义Makefile的支持相当成熟原厂所有例程都是在这个版本上验证过的你跟着用自然最省心。你要是强行换新版CodeBlocks或者换别的IDE第一关就是SDK自带的workspace文件可能打不开或者部分兼容工程模板对不上自动化脚本识别不了。那就不叫升级叫给自己找活干。我的建议很直接别换就用官方搭配。省下来的时间拿去写业务代码比什么都值。2. 开工前的准备下载清单和版本匹配2.1 需要准备哪些文件先把需要的文件列全免得装到一半发现缺东西还得回头重新下载。建议一次性备齐CodeBlocks 17.12安装包。注意选不带MinGW的版本文件名里一般不含mingw字样。带MinGW的版本会捆绑一份x86 GCC编译器我们对接的是RISC-V工具链用不上它反而容易让IDE在编译器选择上变混乱。RV32-Toolchain工具链包。通常是压缩包解压即用。官方SDK整合包里一般会带没有的话单独下载对应版本。中科蓝讯官方SDK包。里面是芯片头文件、驱动库、链接脚本、官方示例工程。开发板资料和一个准备烧录验证的官方例程。如果打算汉化额外准备与17.12严格对应的汉化包一般是zh_CN.mo文件或整个locale目录。这里特别提醒很多人看到CodeBlocks 17.12习惯性跑官网下最新版。中科蓝讯SDK里官方用的就是17.12SDK里的自动化脚本、预置模板都是按这个版本验证过的。用其他版本你可能需要手动移植工程配置还不一定完全兼容。2.2 版本搭配的三个原则根据我反复踩坑总结的经验版本搭配认准三条第一IDE版本以SDK指定为准。用17.12官方workspace双击就能打开Build按钮一按就编过。用其他版本就得手动移植配置纯属浪费时间。第二工具链版本跟着SDK走。RV32-Toolchain有多个版本迭代不同版本的编译器名称、默认库路径都有差异。比如有的版本编译器叫riscv32-unknown-elf-gcc有的叫riscv-none-embed-gcc。官方SDK如果按前者配置你装个后者编译一开始就会报错。第三所有路径避免中文和空格。包括安装路径、工程路径、SDK路径。Windows下程序里带空格的路径经常让Makefile和编译脚本断掉特别是在参数传递时没有做引号转义的情况下。宁可最开始多花三分钟把路径理顺也不要等编译报错了再回头找原因。3. CodeBlocks 17.12 安装步骤与首启配置3.1 安装主程序时容易忽略的细节安装过程本身不难但几个细节直接决定后面顺不顺。双击安装包同意协议一路下一步。安装路径建议改成D:\CodeBlocks或C:\CodeBlocks。不建议用默认的C:\Program Files\CodeBlocks带空格的路径在调用make和工具链脚本时容易出状况这是实际经验。组件选择界面默认勾选就够了。如果下载的是带MinGW的版本安装时它会捆绑GCC编译器。这东西我们不需要反而会在首次启动时被CodeBlocks自动检测为默认编译器后面打开官方工程IDE可能默认走GCC编出来的东西根本烧不进芯片。最稳的做法就是下载不带MinGW的版本。装好后先别急着打开。等RV32工具链和路径准备好再一次性配置避免反复折腾。如果用的是官方SDK整合包里自带的便携版CodeBlocks那就更简单了解压到D:\CodeBlocks就能用。便携版的好处是干净整个目录可以随意搬迁缺点是不会自动关联文件类型但这不影响日常使用。3.2 thesaurus files报错原因和三种解法CodeBlocks 17.12装好后首次启动很多人会遇到一个弹窗thesaurus files \spellchecker\th_en_us.idx not found这个弹窗的意思是拼写检查插件SpellChecker在初始化时要加载英文同义词词典文件th_en_us.idx但在它预期的路径下找不到文件。这并不是你的安装有问题而是17.12版在部分系统上的已知毛病。我第一次遇到这个报错第一反应是安装包坏了重装了一遍还在报才去认真查原因。后来发现这是插件配置里记录的相对路径与实际安装目录对不上。如果系统是中文Windows路径解析更容易出问题。网上能搜到大量相关内容说明不是个例。解决方案按推荐顺序排三个第一种直接忽略。点掉弹窗继续用。这个报错不影响编译、不影响代码编辑只是每次启动都会弹一下。不想折腾就用这种方式。第二种停用SpellChecker插件。打开CodeBlocks菜单栏点击Plugins - Manage plugins在列表里找到SpellChecker选中后点Disable重启CodeBlocks弹窗彻底消失。这是最一劳永逸的做法强烈推荐。第三种手动补文件。网上下载th_en_us.idx放进CodeBlocks安装目录下的SpellChecker目录没有这个目录就新建一个。如果确实需要保留拼写检查功能可以这样修。不过做嵌入式开发这功能本身用处不大不建议在这里花时间。3.3 汉化要不要做怎么做我的建议是可以汉化但别在初次配置的时候做。等环境全部配好、官方例程编译通过再汉化不迟。先汉化有个问题菜单名、选项名全变了你再去看官方教程或者技术文章里面提到的英文菜单项就对不上号配置效率反而更低。而且不少汉化包会改动配置文件如果编译器路径还没配好就汉化出了问题更不好排查。汉化步骤不复杂准备与17.12严格对应的汉化包把zh_CN.mo文件复制到CodeBlocks安装目录下的locale\zh_CN\LC_MESSAGES文件夹里没有就依次创建然后打开CodeBlocks进入Settings - Environment - View勾选internationalization选择Chinese重启生效。需要强调一句不要下载来路不明的汉化整合版。我见过有人用的所谓“精简便携汉化版”里面被塞了额外插件还有人的汉化包把编译器路径配置全改了重新配了一下午才恢复。要汉化就用原版加对应版本的汉化包干净可控。4. RV32-Toolchain安装与系统路径配置4.1 解压工具链到统一目录RV32-Toolchain不需要像普通软件那样走安装向导拿到压缩包直接解压就能用。重点在于解压到哪里。我建议建一个专门的嵌入式工具目录比如D:\embedded把工具链解压到D:\embedded\rv32-toolchain。目录清晰好管理以后工具链升级、备份都方便。解压完成后你会看到bin、lib、include、riscv32-unknown-elf等目录。bin里面放的是真正会被CodeBlocks调用的可执行文件包括编译器riscv32-unknown-elf-gcc.exe、交叉调试器riscv32-unknown-elf-gdb.exe、固件格式转换工具riscv32-unknown-elf-objcopy.exe以及make.exe。一个容易被忽略的问题解压前先确认杀毒软件没有把工具链误报清除。RISC-V工具链里的部分可执行文件没有数字签名有些杀软会误报。如果解压后发现文件夹里文件不全或者运行没反应先翻杀软隔离区。这个事我遇到过不是开玩笑。4.2 设置PATH环境变量工具链解压完为了让命令行和CodeBlocks都能直接找到编译器需要把bin目录加进系统PATH。Windows各版本操作路径略有差别但核心逻辑一样右键“此电脑”选择“属性”选择“高级系统设置”点击“环境变量”在“系统变量”里找到Path双击编辑点击“新建”填入D:\embedded\rv32-toolchain\bin确定保存这里反复强调一定要配置在“系统变量”栏不要只配在“用户变量”。原因很现实CodeBlocks开发时经常以管理员权限启动管理员权限下用户环境变量读取范围与普通权限不一致可能会导致同一个工具链一会儿能编译一会儿又报找不到编译器。配置系统变量后所有用户、所有程序统一可见排查问题少一个变量。4.3 命令行验证编译器是否可用环境变量配完后必须验证。打开一个全新的命令行窗口注意是新开的窗口旧窗口不会自动刷新环境变量。输入riscv32-unknown-elf-gcc --version如果看到类似riscv32-unknown-elf-gcc (GCC) 版本信息的输出说明工具链路径生效。如果提示“不是内部或外部命令”按下面的顺序排查环境变量是否真的保存了。有时候点了确定窗口却异常退出实际上没存上。填写的路径和实际解压路径是否一致。D:\embedded\rv32-toolchain\bin少一层都不行。编译器文件名是否匹配。有些工具链版本里编译器叫riscv32-unknown-elf-gcc.exe有些叫riscv-none-embed-gcc.exe。我在公司给同事配环境时最常遇到的情况是环境变量明明配对了但SDK工程里写的是riscv32-unknown-elf-gcc工具链bin目录里实际是riscv-none-embed-gcc.exe。这种不匹配会出现典型的“自己编译别想编过官方例程也可能直接报错”的现象。我的建议是保留工具链原始文件名到CodeBlocks的编译器配置里改成实际名字不要乱改工具链文件结构。5. CodeBlocks中对接RV32工具链编译第一个例程5.1 在编译器设置里新增RV32编译器工具链和系统环境都处理好后回到CodeBlocks做最后一步对接。核心逻辑就是让IDE认识这套新编译器。具体操作打开CodeBlocks点击菜单Settings - Compiler在弹出的对话框左下角先点Copy按钮复制一份当前编译器配置重命名为RV32 GCC。这样做的目的是复用默认编译参数避免从零配置漏掉选项在Selected compiler下拉框里选择刚才创建的RV32 GCC切到Toolchain executables选项卡把Compilers installation directory改成D:\embedded\rv32-toolchainProgram Files区域里C compiler填riscv32-unknown-elf-gcc.exeC compiler填riscv32-unknown-elf-g.exe其他字段按默认确认无误后点OK保存这里有个高频细节安装目录填的是工具链根目录不是bin目录。CodeBlocks会自己到根目录下的bin目录找可执行文件你填成bin目录反而找不到编译器。这个错误我见好几个同事犯过单独拎出来说。5.2 打开或新建工程三个路径必须核对编译器配置好之后打开官方SDK里的workspace文件一般是.workspace或.cbp格式的工程描述文件。打开后三个路径十有八九藏着坑第一个Project - Build options - Search directories里的Compiler路径。在Compiler选项卡里确认头文件搜索路径已经包含SDK的include目录。如果你把SDK复制到了别的目录官方工程里原本的相对路径可能会失效需要手动改成绝对路径。第二个Linker路径。切到Linker选项卡确认链接脚本所在目录、启动文件和库文件目录都在搜索路径里。中科蓝讯SDK里的链接脚本一般是.ld文件启动文件是startup相关的汇编或目标文件。这些路径不对的话会出现“编译全过、链接全挂”的诡异情况。第三个Make命令。在Build options里找到Make commands相关设置CodeBlocks默认调用mingw32-make或make。如果你用的工具链包里自带make.exe建议明确指定完整路径避免CodeBlocks误抓到系统的make参数风格不兼容。三个路径核对完保存工程。这个过程大约两分钟但能省下后面无数个排查的夜晚。5.3 第一个例程的编译体验路径配好后找官方例程试水。中科蓝讯SDK里一般都有点灯、按键、Flash读写这类基础例程先用最简单的点灯例程验证环境。点击Build按钮底部日志窗口开始滚动编译输出。第一次编译要生成各种中间文件慢一些正常十几秒到半分钟不等。看到日志最后出现0 errors, 0 warnings基本就能确认环境可用了。如果只有几个warning没有error先别慌。嵌入式代码里的warning有很多种变量未使用、函数未声明通常不影响最终固件生成。但如果你发现warning数量特别大建议回去检查编译器版本是否和SDK预期一致版本不匹配才是大量warning的真凶。编译成功生成的固件文件一般在工程目录的bin\Debug或bin\Release下。.bin文件直接烧录Flash.hex文件适合调试器下载。用官方烧录工具把固件烧进开发板看到LED亮起来的那一刻整套环境就彻底打通了。6. 坑都替你们踩过了常见报错与完整排查链路6.1 thesaurus files报错从弹窗到彻底解决这个报错前面已经介绍过这里用排查视角再过一遍完整链路方便你遇到同类问题时知道怎么下手。假设刚装完CodeBlocks双击启动弹窗出现thesaurus files \spellchecker\th_en_us.idx not found。我的排查顺序是第一步判断是不是安装不完整。打开安装目录找spellchecker文件夹看里面有没有th_en_us.idx文件。文件在说明文件齐全问题出在插件配置文件不在重新安装或从别人机器复制一份。第二步看安装路径和用户目录有没有中文。17.12在中文路径下SpellChecker插件对相对路径的解析特别容易出现偏差。这个报错在中文系统用户里出现频率很高网上相关内容一大把。第三步不想再纠结直接禁插件。Plugins - Manage plugins禁用SpellChecker重启就没了。整个过程不超过二十秒。说到底这个报错和编译环境没有半点关系。很多第一次接触CodeBlocks的人会误以为环境搭建失败反复卸载重装纯粹浪费时间。它只是IDE自带拼写插件显示层面的问题。6.2 编译提示make: command not found或找不到编译器这个报错极其经典。点击Build按钮日志窗口直接报错意思是CodeBlocks根本找不到可用的编译器和make程序。排查链路检查Settings - Compiler - Toolchain executables里Selected compiler是否真的选到了RV32 GCC。很多人改了编译器设置但当前工程还在用默认的GNU GCC CompilerBuild时自然找不到riscv相关命令。检查C compiler字段的编译器名字确保是riscv32-unknown-elf-gcc.exe。如果工具链bin目录里实际是riscv-none-embed-gcc.exe就在这里填实际存在的名字。检查Make Program字段。这个字段在默认情况下可能为空或者指到了系统里不存在的make。需要手动指向工具链bin目录下的make.exe。我第一次遇到这个问题就是因为Make Program为空。填上之后编译流程瞬间正常。这个字段平时不显眼但在嵌入式工具链场景下特别容易空值或错值。6.3 编译时报找不到头文件stdint.h、stdio.h编译时报fatal error: stdint.h: No such file or directory说明编译器没有找到标准头文件。你要清楚RISC-V工具链的标准头文件路径跟Windows系统GCC完全不一样它在工具链目录下的riscv32-unknown-elf\include里。排查链路先通过系统搜索找到工具链下include目录的完整路径。再到Project - Build options - Search directories - Compiler里加上这个include目录。确认没有把系统自带的Windows include路径混进来。两套头文件混用表面可能编过但底层ABI不一致固件烧到芯片上就会表现怪异。这个问题在工程从一台电脑复制到另一台电脑时特别常见。路径失效了就直接改回来属于问题里最好修的一类。6.4 链接阶段找不到启动文件或库文件如果编译能过但链接时报错cannot find -lxxx或者undefined reference to_start说明链接脚本、启动文件或者库文件的路径没配对。中科蓝讯SDK的链接脚本定制性很强芯片型号不同、Flash大小不同链接脚本就不同启动文件里的汇编内容也不同。我的建议是除非你非常清楚自己在做什么否则优先用官方workspace不要自己新建工程。官方workspace报错先检查工程路径是否变过。SDK整体挪了位置相对路径很可能失效。去Build options - Search directories - Linker把启动文件、链接脚本、静态库所在目录全部加上。链接脚本要在Linker options里显式指定比如-Tscript.ld这种参数。缺了这个链接器不知道把代码放到哪个内存地址。这类问题通常是还不熟SDK结构时遇到最多的一种。解决办法不复杂拿着官方工程和官方Makefile对照哪个路径缺了一眼就能看出来。6.5 汉化包导致的乱码和配置失效最后一个坑专门说给想汉化的人。我有一次帮同事排查了一个下午发现他的CodeBlocks打开后菜单全是乱码之前配好的RV32编译器全部消失。最后发现他用的所谓“高清完整汉化版”是第三方整合包里面改了配置文件路径和插件结构之前配好的信息存在旧路径整合版读的是新路径自然全部失效。解决办法是卸载整合版用官方原版重装再手动打汉化补丁。折腾一下午又回到最原始的方案。这件事之后我的原则很明确能用原版就不碰整合版。工具链配置这件事稳定压倒一切。真想要中文界面也等所有功能跑通之后再汉化顺序千万别颠倒。最后再说一点实操经验。整个流程走顺之后我给新同事配环境最快的一次确实只用了五分钟三分半钟解压工具链、装CodeBlocks一分半钟配环境变量、指定编译器路径。想达到这个速度关键是把所有工具版本固定下来不要每次用不同来源的安装包反复试。一旦有人在团队里配成功了就把整个工具链目录和CodeBlocks安装目录打包分享其他人直接解压就能用环境变量写个脚本一键设置。这个做法能省掉大量重复劳动。反正环境装好就是为了赶紧写代码别在这件事上磨洋工。
