English / 日本語

Gregory J. Durnan, PhD, CEng, FIMarEST

Free Embedded Coding 5 — RISC-Vと CH32V003
San Diego, CA, USA · Contact · durnan.org

RISC-Vと CH32V003 ——刷新されたWin10/11ツールチェーン、PowerShell不要

余談:これは新シリーズ「Free Embedded Coding」の第一弾です——ごく普通のWindows 10/11マシン上で、完全にオープンソースのツールだけを使い、無料で、本物の、安価で、しかし十分に高性能な ハードウェアに実際のファームウェアを書き込むシリーズです。本来ならこの前に4本の基礎的な記事があるはずですが まだ書けていないため(いずれ書きます)、番号は便宜上「5」としています。ツールチェーン全体の記憶が新しい うちに、この記事だけ先に書いておきたかったのです。

上のjMiniNECが数十年前のBASICを忠実に現代のJavaへ移植したものだとすれば、これはその正反対のプロジェクト です:真新しいシリコンです。チップはWCHのCH32V003——数十円程度で買える32ビットRISC-V マイコン——で、オープンソースのツールチェーンで完全にサポートされています。ベンダー製IDEも、ライセンス 認証の面倒な手続きも、「コミュニティ版」のうるさい通知画面も一切不要。必要なのはGCCとMake、そして WCH-LinkEと呼ばれるUSBデバッグプローブだけです。この記事の目標は、開封したばかりのWCH-LinkEから、他の チップ用にすでに使っているかもしれないエディタの中で、ワンクリックのビルド&書き込みワークフローに たどり着くこと——その過程でのWindowsの面倒事をできる限り減らすことです。

必要なもの

パッケージの中身

必要なものはすべて、並んだ2つのフォルダに収まっています:CH32_SDK(WCH CH32Vファミリーの 全チップ向けのレジスタヘッダー、リンカスクリプト、Makefile、そしてすぐ動かせるサンプル集一式)と WCH_CH32V003_programmer(USB経由の書き込み/デバッグツール本体と、Windowsドライバと RISC-V GCCツールチェーンの両方をインストールしてくれる小さなセットアップ補助ツール——PowerShellスクリプト も別途ダウンロードも不要です)。

Windowsエクスプローラーに並んだCH32_SDKとWCH_CH32V003_programmerフォルダ
必要なものはすべて、この2つのフォルダに
謝辞とクレジット:この2つのフォルダは、Charles Lohr氏とそのコントリビューターによる 2つの優れたオープンソースプロジェクト——cnlohr/ch32fun(SDK側)とその相棒である minichlink(プログラマ側)——を、名称を整理して一貫性を持たせただけのフォークです。 名前の変更は純粋に見た目の問題で、中身の本当のエンジニアリングはすべて彼らによるものです。同梱している ツールチェーンは、xPackプロジェクトによるxpack-riscv-none-elf-gccのWindows版をそのまま 無改変で使用しています。

配線する

WCH-LinkEはPD1ピン上のワンワイヤー方式のデバッグプロトコルでCH32V003と通信します。必要な配線はわずか 3本——電源、グラウンド、そしてPD1(SWIO)だけです。1-wireモードでは別途クロック線は不要です。

ブレッドボード上でCH32V003ボードに配線されたWCH-LinkE
赤 = VDD、黒 = GND、青 = PD1(SWIO)

Windowsと「署名なしドライバ」問題

ここがWindowsとRISC-Vデバッグプローブの組み合わせで唯一本当に面倒な部分です。最近のWindows 10/11は 標準設定で、署名されていないWinUSBドライバのインストールを拒否します。そしてWCH-LinkEのような安価な デバッグプローブが必要とするのは、まさにこの手のドライバです。ロックダウンされたマシン上で手動で ドライバインストーラを実行すると、この壁によく突き当たります。

署名なしWinUSBドライバのインストールをWindowsが拒否する画面
前:署名なしドライバをWindowsが拒否
セットアップツールがドライバのインストールに成功する画面
後:セットアップツールによる一度きりの修正

この問題の解決策は、Windowsのドライバ署名ポリシーを一度だけ変更することです。現在は同梱のセットアップ ツールがこれを自動でやってくれます。WCH_CH32V003_setup.exeを開き(管理者権限を求められますが、 ドライバインストールには常に必要なものなので想定内です)、「Install WCH-LinkE driver」を選んでください。 プローブを一度抜き差しして、Windowsが新しいドライバの下でデバイスを再認識すれば、そのマシンでは恒久的に 完了です。

プログラマがチップを認識できるか確認する

他に何かをインストールする前に、WCH-LinkEとCH32V003が実際に通信できているかを確認しておく価値が あります:

wch_ch32v003_programmer.exe

Found WCH Link
WCH Programmer is LinkE version 2.18
Detected CH32V003
Flash Storage: 16 kB
Part UUID: 1d-ff-ab-cd-86-14-bc-48
Part Type: 00-30-05-00
Read protection: disabled
Interface Setup

これはチップとの本物の対話です——正確なシリコン型番、フラッシュ容量、固有のパートUUID、そして リードプロテクションの状態まで。これが表示されれば、一番大変な部分は終わりです。

ツールチェーンをダウンロードせず同梱する

実はこれが本当に直したかった部分です。以前のやり方では、インストール時にPowerShellスクリプトが サードパーティのミラーサイトからGCCをダウンロードしていました——しかしミラーサイトは落ちることもあれば、 廃止されることも、会社のファイアウォールにブロックされることもあります。今回はダウンロードするものが 一切ありません。xpack-riscv-none-elf-gcc(GCC 14.2.0)のWindows版フルビルドと、小さな make/busyboxバンドルが、パッケージの中にすでに同梱されています。

セットアップツールが同梱のRISC-Vツールチェーンをコピーし、PATHを更新する画面
メニュー一つで:ツールチェーンをコピーし、PATHを更新して完了
余談:この「ダウンロードせず同梱する」というやり方は、ディスク容量というコストを 伴います——刈り込んでいないxpackの完全な配布物をそのまま使っているため、展開後で約1.4 GBです。しかし その代わり、たとえ将来GitHubから元のxpackリリースが消えてしまったとしても、この記事(とこの パッケージ)は5年後でも全く同じように動作します。今どき数ギガバイトのディスク容量など大した出費では ないことを考えれば、これは簡単に受け入れられるトレードオフでした。

コマンドラインからビルドして書き込む

ツールチェーンがPATHに通っていれば、CH32_SDKから実際のサンプルをビルドするのはコマンド 一発です:

cd CH32_SDK\examples\blink
make build

Memory region     Used Size  Region Size  %age Used
  FLASH:               688 B      16 KB      4.20%
  RAM:                   0 B       2 KB      0.00%
コマンドラインからmake buildでblink.cをコンパイルする画面
動作するblinkでたったの688バイト、16 kBのフラッシュの中で

結果の書き込みもコマンド一発です:

wch_ch32v003_programmer.exe -w blink.bin 0x08000000

0x08000000はCH32V003のフラッシュのベースアドレスです。「Image written」と表示されれば、 チップは既にあなたのコードを実行しています——LEDを配線していれば、もう点滅しているはずです。

Geanyに2つ目のアーキテクチャを教える

コマンドラインでのmake buildとフラッシュコマンドだけでも、十分に機能するループです。 ですが、もし他の用途ですでにGeanyを使っているなら——私の場合は8051のSDCC用に設定済みです——既存の 設定に一切手を触れずに、5分だけ時間をかけてRISC-Vをそこに組み込んでおく価値があります。

重要なポイント:Geanyの「グローバル」なビルドコマンドは、開くすべての.c ファイルに適用されます——ここだけは触れてはいけません。代わりに、RISC-Vのフォルダを独立したGeanyの 「プロジェクト」として開き、プロジェクト → プロパティ → ビルド から、プロジェクト単位でビルド コマンドを設定してください。プロジェクトの設定は、そのプロジェクトが開かれている間だけグローバル 設定を上書きします。
Geanyのプロジェクトプロパティ・ビルドタブに未設定のグレーのデフォルト値が表示されている画面
前:Geanyから継承したデフォルト(素の gcc)
Geanyのプロジェクトプロパティ・ビルドタブにmake buildとフラッシュコマンドが入力された画面
後:プロジェクト単位のビルド/フラッシュコマンド

そのダイアログに直接タイプするのは3つのフィールドだけです:Compileと Buildはどちらもmake buildに設定し、実行(Execute)コマンド (「Flash (WCH-LinkE)」とラベルを変更しました)にはwch_ch32v003_programmer.exeへの フルパスに続けて-w "%e.bin" 0x08000000を指定します。Geanyのcppcheckベースの Lintはそのままにしておきます——アーキテクチャに依存しないので、触る理由がありません。

うまくいかなかった近道:最初に試したのは、ビルドコマンドをあらかじめ書き込んだ .geanyプロジェクトファイルを手作業で用意し、新しいマシンにそのままドロップすればすぐ 使える状態にする、というやり方でした。しかし実際には、Geanyは手書きのファイルからこのセクションを 確実には読み込んでくれませんでした。上記のように、プロジェクト → プロパティ → ビルド に3つの コマンドを直接タイプするやり方が、確実に動作するバージョンです。

証明:LEDの点滅速度が変わるのを見る

本当のテストはエラーなくコンパイルできることではなく、実際にチップの挙動が変わるのをこの目で見る ことです。RISC-Vプロジェクトの下でblink.cを開いた状態で、Geany自身のメニューから ビルド、続けてフラッシュを実行すると、コマンドラインで行ったのと全く同じコンパイル&書き込みの手順が、 それぞれワンクリックで実行されます。古いバイナリやキャッシュされたビルドの可能性を排除する証拠が 欲しいなら、LEDトグル遅延を目に見えて違う値に変更し、ビルドしてフラッシュし、点滅速度が実際に変わる のを見てください。ログメッセージは嘘をつくことがありますが、物理的に速くなったり遅くなったりする 点滅は嘘をつきません。

点滅速度が変わった状態でLEDが点灯しているブレッドボード上のCH32V003ボード
同じボード、新しい点滅速度——ビルドとフラッシュが本当に実行された証拠

まとめ

以上が、箱から出したばかりのWCH-LinkEから、他のアーキテクチャ用にすでに使っているかもしれない エディタの中で、ワンクリックのRISC-Vビルド&書き込みワークフローに至るまでの、完全に無料で、ゼロから 組み立てた道筋です。ベンダー製IDEも不要、腐ってしまうダウンロードも不要、そして他のチップ用にすでに 構築済みのツールチェーンを乱すこともありません。Windowsは標準設定で署名なしのWinUSBドライバをよく 拒否しますが、ツールチェーンを同梱することで、多少のディスク容量と引き換えに特定のダウンロード ミラーに何が起きようと動き続けるという安心感が得られます。そしてGeanyのプロジェクト単位のビルド 設定は、既存のエディタ環境を乱すことなく2つ目のアーキテクチャを追加するのに最適な方法です。

完全なパッケージ——CH32_SDK、名称を整理したプログラマツール、セットアップ補助ツール、 そして同梱のRISC-Vツールチェーン——はご要望に応じてお渡しできます。

#RISCV #EmbeddedSystems #CH32V003 #WCH #EmbeddedC #Microcontrollers #OpenSourceTools #Geany #FirmwareDevelopment #GregoryJDurnan #DurnanOrg #GregDurnanRF #RFEngineering #MicrowaveSystems