抱怨：CH32V103 不支持公版开发工具，开源用户掉坑里了。

如题。

CH32V103 不支持公版 J-Link v10 的 SWD 模式，不支持公版 Eclipse CDT Embedded 和 OpenOCD，据说甚至不支持公版 RISC-V GCC。像我只用公版开源环境，连一台运行 Windows 的电脑都没有的开发者，就直接掉进坑里被劝退了。

您好，公版可以，只是沁恒RISC-V芯片有很多特色功能（快速中断、特色指令等），用公版实现不了，这样就降低成普通RISC-V的水平，用MRS能发挥更好性能。另外MRS已经可以支持Linux环境使用，可以在此下载：MounRiver Studio。

WCHTech2 发表于 2021-4-22 18:52
您好，CH32V103支持公版RISC-V GCC编译，也可以使用公版 Eclipse CDT Embedded加载我们提供的例程。
沁恒在 ...

问题其一：开源跨平台的 OpenOCD 不支持 WCH-Link，WCH-Link 自身的软件不支持 Linux 和 macOS，因此不用 Windows 就不能使用 WCH-Link。
问题其二：CH32V103 本身不支持标准的 SWD 协议。因此说哪怕 OpenOCD 更新加入了 WCH-Link 支持，或 WCH-Link 加入了 CMSIS-DAP 标准协议兼容当前公版 OpenOCD，当前的公版 OpenOCD 也无法支持 CH32V103。

公版 Eclipse CDT 可以加载是一回事，可以烧录可以调试是另一回事。

xcvista 发表于 2021-4-22 19:45
问题其一：开源跨平台的 OpenOCD 不支持 WCH-Link，WCH-Link 自身的软件不支持 Linux 和 macOS，因此不用 ...

您好，MRS集成开发环境，Linux系统下开发环境及工具链在此下载：MounRiver Studio

xcvista 发表于 2021-4-22 19:45
问题其一：开源跨平台的 OpenOCD 不支持 WCH-Link，WCH-Link 自身的软件不支持 Linux 和 macOS，因此不用 ...

windows下用他们的gcc版本就好了。我已经亲测VSCODE+OPENOCD可以仿真CH573,只是偶尔不稳定,目前还没有时间去找原因
mac及linux确认没有，有点可惜

WCHTech2 发表于 2021-4-23 13:23
您好，沁恒RISC-V 系列MCU目前只提供了Windows版本的编译开发环境MounRiver Studio，Linux下会尽快提供开 ...

你们也别搞这些吃力的事情了，先把最核心的问题解决：写一个跨平台的 WCH-Link GDB Server，然后就可以直接对接公版开源工具了。J-Link 配公版工具本质上就是这个原理，J-Link 有 JLinkGDBServer。

jlink就别想了，swd要回避专利问题，ch32v没有jtag。gcc，openocd可以从win版移植

xiaowuzxc 发表于 2021-4-24 22:41
jlink就别想了，swd要回避专利问题，ch32v没有jtag。gcc，openocd可以从win版移植

1. CH32F103 ARM Cortex-M 系列芯片的存在意味着 WCH 一定有 SWD 的专利授权。（参考 GD：GD32VF103 的调试功能直接就是从 GD32F103 Cortex-M3 上面拿来的公版 SWD + JTAG。这个是 J-Link 直接支持的。）
2. 如果 WCH-Link 在 Windows 下用了 OpenOCD，麻烦把代码提交给 OpenOCD 主线，这样更符合开源精神。如果是 WCH 自己开发的接口软件，那就需要从这个软件出发做一个跨平台 GDB server。

WCHTech2 发表于 2021-4-23 13:23
您好，沁恒RISC-V 系列MCU目前只提供了Windows版本的编译开发环境MounRiver Studio，Linux下会尽快提供开 ...

为什么一定要用MountRiver呢,把OpenOCD跟下载工具开放出来,让大家灵活来使用不是更符合RISC-V这种开源架构的精神吗

lanjackg2003 发表于 2021-4-27 12:37
为什么一定要用MountRiver呢,把OpenOCD跟下载工具开放出来,让大家灵活来使用不是更符合RISC-V这种开源架 ...

我前面说的就是这个意思。如果下载调试工具是基于 OpenOCD 的，那么 WCH 依许可证应该放出对应的源代码（OpenOCD 本身是 GPLv2 授权协议）最好是可以将源代码贡献给上游的 OpenOCD 主线项目。如果下载调试工具不是基于 OpenOCD 的，虽说法律上没有这个义务，但在道义上也应该提供 linux-amd64、linux-i686、linux-arm64、linux-armv7、linux-rv64g、linux-rv32g、xnu-amd64 和 xnu-arm64 这八个版本的二进制文件啊（分别对应 64 和 32 位，x86、ARM 和 RISC-V 的 Linux 系统，以及 64 位 x86 和 ARM 的 macOS）而且作为命令行工具，因为 Linux 和 macOS 都是 UNIX，这个软件完全可以调试一个 linux-amd64 或 xnu-arm64 然后同一个源代码针对八个平台编译。至于测试，一台 Intel MacBook Pro，一台 M1 MacBook Pro，一块树莓派 4 就可以测八个平台中的六个了，剩下的 RV64G 和 RV32G 可以先 as-is 等阿里的 RISC-V 大芯片出来再测。

linux下开发单片机，总体来说应该是个比较小众的需求，厂家支持有限可以理解。

zchong 发表于 2021-4-30 07:34
linux下开发单片机，总体来说应该是个比较小众的需求，厂家支持有限可以理解。 ...

这个只能说是您接触的单片机应用场景太少。有太多的 IoT 场景都是单片机直接和 Linux 服务器或 Linux 汇总节点互动，如果你强行用 Windows 做开发，你好需要专门联调联试。如果开发环境直接就是 Linux，那每次调试就都是联调联试。

感谢楼主的分享，不错的一个建议。

还是支持国产芯片的，沁恒一直在用。

xcvista 发表于 2021-4-30 11:30
这个只能说是您接触的单片机应用场景太少。有太多的 IoT 场景都是单片机直接和 Linux 服务器或 Linux 汇 ...

学到了，

学习了，最近在研究risc，不喜欢太复杂的操作

真是理解不了这个操作。
1. 貌似不支持 JTAG ?
2. 这个所谓的 RVSWD， 不开放， 如果一直这样， 其实没有多大便利性。

一个开发者怎么可能让一个开发环境绑住手脚，每种芯片都有它自己最方便的开发模式。 STM8，PIC，AVR，arm等等太多了，适应环境才是最好的选择。

支持公版 RISC-V GCC  

这个有自己的下载器