ARTICLE DETAIL

资讯详情

深耕网站视觉设计与运营推广的一线实战洞察。

RISC-V交叉编译环境搭建:K210工具链安装配置实战

RISC-V交叉编译环境搭建:K210工具链安装配置实战 简介面向Windows 64位系统的Kendryte RISC-V开发工具链安装包版本8.2.02019年4月发布专为基于RISC-V架构的K210等芯片的嵌入式与AI边缘计算开发设计适合物联网开发者、嵌入式工程师使用。压缩包共1069个文件约51.36MB内部以头文件h/hpp、库文件a/la、可执行工具exe及编译相关配置tcc、specs为主体涵盖GCC编译器、链接器、调试器等核心组件并附带SDK头文件与少量Python辅助脚本可直接在命令行或IDE中调用。工具链针对Kendryte芯片优化支持C/C开发与硬件外设访问配合gdb可完成断点调试、内存检查等操作是K210应用开发、语音图像处理等场景的基础环境。目前已有239人学习使用适合希望快速搭建Kendryte Windows开发环境、熟悉RISC-V工具链的开发者参考。1. 先搞清楚这个zip里到底是什么我第一次下载kendryte-toolchain-win-amd64-8.2.0-20190409.zip的时候心里也犯嘀咕这不就是一个压缩包嘛能有什么技术含量实际上这个文件基本上是把K210芯片和一个“编译器”打包在一起专门用来在Windows系统上开发K210这块RISC-V架构芯片的交叉编译环境。如果你的项目和K210、嘉楠开发板、AI边缘计算、甚至某些带摄像头的人脸识别门锁有什么关系那你迟早要和这个压缩包打交道。很多人一开始容易误解以为arduino或者keil C51那种方式就能直接写K210程序。其实K210和常见的51、STM32差别很大它用的不是ARM Cortex-M内核而是RISC-V双核架构。你要在PC上写出能在K210上跑的程序就必须用交叉编译工具链。交叉编译是什么意思用生活类比你在一台装着Windows的电脑上写代码但最终代码要跑到一块完全不同的芯片上。你的电脑CPU和K210芯片的指令集架构ISA不一样本机编译器编出来的程序根本不认识。所以你需要一个专门“翻译”成RISC-V指令集的编译器。这个zip就是干这个活的——一个可以在Windows上运行的、目标平台是RISC-V的GCC工具链。顺带说一句这个压缩包对应的是嘉楠早期开源SDKKendryte Standalone SDK配套工具链。现在官方主推的Kendryte IDE虽然也内置了交叉编译环境但核心编译器仍然是同一套riscv64-unknown-elf-gcc所以理解和会手动配这个工具链对你后续用IDE、写Makefile、甚至接入VS Code都会非常有用。2. 安装前必须知道的三个关键点2.1 解压不等于安装环境变量才是主角很多人下载完这个zip双击解压到某个目录然后发现命令行输入riscv64-unknown-elf-gcc --version直接报“不是内部或外部命令”。原因很简单压缩包解压后不会自己注册到系统PATH里你需要手动把bin目录加到环境变量。我建议先把整个目录放到一个干净、无中文、无空格的位置比如C:\kendryte-toolchain\。为什么强调无空格因为后面SDK的Makefile脚本在拼接路径时如果目录里带空格比如C:\Program Files\kendryte-toolchain很容易出现路径截断或转义错误。这个坑我在命令行版SDK上踩过不止一次。2.2 为什么是amd64而不是arm64标题里的amd64指的是你这台电脑的CPU架构不是K210芯片的架构。Intel和AMD的64位CPU一般用x86_64指令集而微软叫它amd64。arm64是ARM架构的64位指令集。如果你的电脑是普通Windows台式机、笔记本绝大多数Intel/AMD芯片选amd64版如果是Windows on ARM设备比如部分骁龙平台的平板就需要arm64版工具链。不要以为这无所谓。交叉编译器本身也是个程序也要能在你的Windows系统里运行。选错了架构轻则根本无法启动重则跑起来后莫名其妙崩溃。下载之前先确认自己的系统类型WinR输入msinfo32找到“系统类型”就能看到是x64还是ARM64。2.3 版本号里藏着的信息8.2.0-20190409这一段不是随便写的8.2.0GCC主版本号。K210的BSP板级支持包在编某些驱动时对编译器版本比较敏感8.2.0是嘉楠官方当时验证过的版本。20190409构建日期。2019年4月9日。这个日期很关键——如果你去下载更新的工具链比如RISC-V官方发布的9.2.0或10.1.0在编译老版本的Kendryte SDK时可能会遇到内联汇编语法兼容性问题。所以如果遇到“这个工具链太老了吧”的想法我的建议是只要你的SDK版本不是特别新的主线代码就用官方这个配套版本最稳。升级工具链虽然能解决部分编译告警但也会引入一些未知的兼容性风险。3. 实操步骤从解压到跑通第一个程序3.1 安装与验证工具链我把完整流程分成四步每一步都给出验证方法避免你到最后一步才发现前面配错了。第一步解压把zip解压到C:\kendryte-toolchain\。解压完你应该能看到以下主要目录C:\kendryte-toolchain\ ├── bin\ # 编译器可执行文件在此 ├── lib\ # 运行库 ├── libexec\ ├── riscv64-unknown-elf\ # 目标系统的库文件和头文件 └── share\第二步添加环境变量WinR输入sysdm.cpl打开“高级→环境变量”在“系统变量”中找到Path追加一行C:\kendryte-toolchain\bin注意是追加不是替换。然后打开新的CMD窗口旧窗口不会刷新环境变量测试riscv64-unknown-elf-gcc --version如果输出以riscv64-unknown-elf-gcc (GCC) 8.2.0开头说明工具链已经能用了。第三步检查辅助工具光有编译器还不够SDK的构建流程还依赖make、python和git。make建议装一个带make的GNU工具集。我推荐直接装gcc-make独立工具包或者用小熊猫C自带的MinGW工具集里的make。pythonKendryte SDK的烧录脚本kflash.py是Python写的需要Python 3.6以上。装完记得把Python也加进PATH。git拉取SDK源码用推荐装标准版Git for Windows。第四步验证完整编译链进入SDK目录先跑一个最简单的编译指令make如果能正常生成.elf和.bin文件说明你的工具链和SDK联动正常。3.2 用命令行版SDK跑通一个点灯例程很多教程会直接让你打开Kendryte IDE但我觉得对于理解底层流程来说命令行方式更清晰。以Kendryte Standalone SDK为例完整跑通一个blink例程分三步。第一步拉取SDKgit clone https://github.com/kendryte/kendryte-standalone-sdk.git cd kendryte-standalone-sdk如果你想省事也可以用Gitee镜像速度会更快。这里我用的是github地址只是作为常见来源之一。第二步修改编译配置SDK顶层的kendryte-package.json或Makefile里会有一个变量指定工具链前缀。有的版本默认是riscv64-unknown-elf-有的SDK分支使用riscv64-known-elf-。如果你配置完环境变量后直接make报错提示找不到编译器检查这个前缀是否匹配你的工具链。通常不需要改但如果你把工具链装到了非默认路径则需要显式指定make TOOLCHAIN_PATHC:/kendryte-toolchain/bin第三步编译和烧录在SDK根目录下先编译一个最简单的例程。比如src/demo里有现成的hello worldmake demo_hello_world生成的固件在build/hello_world.bin。接下来烧录到开发板python kflash.py -p COM3 -b 1500000 build/hello_world.bin其中COM3换成你实际串口号-b 1500000表示波特率。K210的ISP在系统编程协议支持最高1.5M波特率实测这个速度在多数USB转串口芯片上都比较稳。提示烧录时要先让开发板进入下载模式。K210开发板一般有一个BOOT按键按住BOOT再按一下RESET然后松开BOOT板子就会进入ISP模式。如果你直接烧录失败先检查这一步。4. 常见的坑与排查技巧4.1 “不是内部或外部命令”这是新手遇到最多的报错。排查顺序重新打开CMD窗口确认PATH已经生效可以echo %PATH%查看是否包含你的工具链bin。确认文件名。bin目录下应该有一个riscv64-unknown-elf-gcc.exe不是所有版本都叫这个名。有的工具链会把编译器命名为riscv64-unknown-elf-gcc-8.2.0有一个后缀。如果是这样你需要手动创建一个无后缀的副本或者直接使用完整文件名。以管理员身份打开CMD。有些环境变量修改后非管理员窗口可能没有正确刷新。4.2 make报错“missing separator”这个问题通常出现在你手动修改过SDK的Makefile之后使用了空格缩进而不是Tab缩进。Makefile对格式极其严格命令行必须以Tab开头不能用空格替代。另外如果你把SDK放在了中文目录下或者路径里带空格也会出现类似“file not found”或路径截断的问题。Windows下编译RISC-V项目路径“干净”是第一原则。4.3 烧录时报“No module named serial”kflash.py依赖pyserial库。运行pip install pyserial有时候还需要requests库一并装了就完了。如果Flask脚本还报别的缺模块直接看报错内容缺什么补什么。4.4 Python2和Python3混用有些老文档会建议用Python2但kflash.py是Python3的脚本。如果你电脑上同时装了Python2和Python3直接用python命令可能会调用到Python2导致语法错误。建议用python3或py -3显式指定版本。4.5 “undefined reference to__adddf33” 类型的链接错误这个问题我在用新版本GCC9.2.0以上编译老SDK时遇到过。原因是指令集扩展不匹配——旧SDK配置文件里没有正确启用软浮点或硬件浮点支持。K210支持RV64IMAFDC即带F和D扩展但你用的编译器如果默认生成rv64imac的目标代码在链接时就会缺浮点运算的辅助函数。解决办法是检查SDK的CMake或Makefile配置里是否有-marchrv64imafc或-marchrv64imafdc没有就手动加。如果没有加这个参数且你用的是新版编译器就会因为软浮点库缺失而链接失败。4.6 环境变量配置了但重启后又失效“系统变量”和“用户变量”的区别如果改的是用户变量Windows重启后某些服务比如VS Code或某些终端软件不会继承需要彻底关闭并重新打开。如果改的是系统变量也需要重新启动所有已打开的终端窗口。还有一个更隐蔽的问题如果Path里既有用户变量又有系统变量且系统变量的Path中有一个无效路径可能会导致整个Path解析中断。排除方法把工具链路径加到用户变量并且在CMD里直接运行完整路径C:\kendryte-toolchain\bin\riscv64-unknown-elf-gcc.exe --version如果完整路径能运行说明工具链本身没问题问题出在PATH。5. 工具链之外你还差这三样5.1 一个顺手的编辑器很多教程默认用VS Code C/C插件。我可以直接告诉你用这套搭配编译K210项目很简单安装插件后在.vscode/c_cpp_properties.json里指定compilerPath为工具链里的gcc并设置intelliSenseMode为gcc-x64includePath指向SDK的lib和include目录就行。用同一个工具链做语法补全和代码跳转比用本机gcc更准确因为宏定义和目标平台指令集都匹配。5.2 对Makefile体系的基本认识Kendryte官方SDK虽然是cmake也能构建但很多示例项目的入口还是Makefile。你不需要做CMake专家但至少要能看懂几个关键变量CROSS_COMPILE交叉编译器前缀通常是riscv64-unknown-elf-ARCH目标架构RISC-V的K210一般写成rv64imafdcCFLAGS编译参数包含-march... -mabilp64d -O2等5.3 一个串口调试工具烧录和输出log都依赖串口。推荐用MobaXterm或者SSCOM前者功能强、界面清晰后者是绿色单文件使用简单。串口波特率一般是115200开发板的log输出默认就是这频率。K210的ISP烧录波特率可以和log波特率不同这是两个独立的概念。6. 最后再分享一点真实踩坑经验我个人实际用这套工具链做了大概半年多的K210项目最大的体会是这个工具链虽然老但千万别小看它也别随便升级。有一段时间我图新鲜换成了RISC-V官方最新的GCC 10.1.0版。编译跑起来确实没报错但烧录到板子上程序初始化就卡死折腾了整整三天最后发现是链接脚本里某些符号的地址对齐方式变了新版GCC生成的代码段布局和老版不一样。换回8.2.0版本之后问题立刻消失一切正常。从那之后我手机上存放的始终是官方这个版本只有当项目明确需要某种新特性时才会谨慎评估升级。另外还有一个习惯值得推荐不要把工具链路径添加到用户目录下的.bashrc而忽略系统PATH尤其在Windows上配合MSYS2或Git Bash使用时PATH的拼接顺序会影响工具链的优先级。如果你同时装了多个RISC-V工具链建议专门用一个名字特别清晰的文件夹区分比如C:\toolchains\riscv-8.2.0避免时间一久自己都搞混。这个压缩包本身虽然只有一百多兆但它背后涉及的交叉编译、RISC-V指令集、SDK构建体系足以让一个新手研究很久。如果你能把上面这些步骤都跑通K210对你来说基本就没有门槛了。后续不管是做人脸识别门禁、智能语音助手还是边缘视觉检测你都能直接在此基础上展开不再会被“编译环境”这种基础问题卡住。本文还有配套的精品资源点击获取
返回列表