ざっくり紹介
EIDE は VSCode のプラグインで、マイコン（MCU）プロジェクトの開発に使います。例えば、8051、stm8、stm32、other cortex-m mcus などなど……
Keil プロジェクトのその後のアプリケーション開発には EIDE をおすすめします。ボードの立ち上げやペリフェラルの初期設定は、やはり Keil で行いましょう。公式のものですから安心です。また、STM32CubeMX で Keil プロジェクトを生成するのも非常に便利なので、ペリフェラルの初期検証も Keil の方が良いでしょう。
なぜ EIDE を選ぶのか？PlatformIO IDE ではなく
最も重要なのは、EIDE が Keil プロジェクトをシームレスにインポートできることです。安定して動作している既存プロジェクトを、改めて検証し直す必要がありません。EIDE は、Keil の中で唯一価値のあるコンポーネント、AC6 コンパイラをサポートしています。
次に、EIDE は中国の開発者によるプラグインなので、コミュニティでのコミュニケーションにストレスがありません。作者もネット活動が活発で、返信も非常に迅速です。プラグインとは無関係の技術的な質問でも、作者にちょっと絡んでみてもいいでしょう。
以下がコミュニティのアドレスです。
事前準備
事前準備の目標を明確にしておきます。VSCode + EIDE のインストールを完了し、EIDE プラグインが ARM-GCC と AC6 のツールチェーンを検出できる状態にします。
インストールのやり方は、この記事では手取り足取り説明しません。
まずは公式ドキュメントを読むのが一番のおすすめです。最低でも、公式ドキュメントの「Getting Started」の章は最後まで一通り読みましょう。
また、コミュニティのブログ記事も1本良いものがありますが、環境構築はやはり公式ドキュメントに沿って進めるのが最もおすすめです。
![[VSCODE]基于EIDE插件搭建vscode下的STM32单片机开发环境 - Foriver - 博客园](https://img2020.cnblogs.com/blog/2702372/202201/2702372-20220106152721430-1125632006.png)
追加の準備
追加の準備はデバッグのために行います。ご存知の通り、チップ上のプログラムをシングルステップでデバッグできないなら、複雑なプログラムの開発はほぼ不可能です。
必要になるのが、定番の神プラグイン Cortex-debug です。
改めて、公式コミュニティのドキュメントを紹介します。
簡単に言うと、設定が必要なのは次の2点です。
- ARM-GCC ツールチェーンのパスを設定する。私の環境では
C:\111_APPS\arm-gnu-toolchain-13.2.Rel1-mingw-w64-i686-arm-none-eabi\binです。ここに arm-none-eabi-gcc.exe や arm-none-eabi-ld.exe などのツールチェーンのプログラムがあります。 - 必要な GDB アプリケーションのパスを設定する。例えば、私は JLink でデバッグしているので、JLink GDBServer Path を設定する必要があります。私の環境では
C:\111_APPS\SEGGER\JLink_V794fです。ここに JLinkGDBServer.exe というアプリケーションがあります。JLink を使っていない場合は、OpenOCD でのデバッグが必要になるかもしれません。その場合は、OpenOCD Path を設定してください。
私が設定したのは、設定画面の次の2項目です。
使い始める
EIDE プラグインを初めて使う人には、まずバックアップを取った Keil プロジェクトをテスト用に用意し、そのプロジェクトが Keil で正常にコンパイルでき、ボードの LED を点灯できることを確認しておくことをおすすめします。
公式ドキュメントに従って、このプロジェクトをインポートします。
インポートすると、VSCode ワークスペースのプロジェクトをどこに置くかを尋ねるダイアログが表示されます。初めて使う場合は、元の Keil プロジェクトのファイルと同じ場所に置くのがおすすめです。余計な操作を避けられます。ただし、テスト用プロジェクトで新しい開発環境に慣れた後は、開発環境ごとにプロジェクトを分離しておきましょう。環境ごとの設定を分離する能力すら備わっていないなら、基本的にもう詰んでいます。
開発環境の落とし穴
単純だけど単純ではない落とし穴で、開発環境を立ち上げられるかどうかに関わってきます。ここで関係するのは AC6 コンパイラだけです。GCC コンパイラはやはり非力です。
アセンブリコンパイルの大落とし穴
アセンブラの設定は以下の通りです。ここに大きな落とし穴があります！
私たちが入手するアセンブラのコードは、さまざまなアセンブラ形式で書かれています。
- GNU 形式。特徴：
/**/や//でコメントを書き、.syntax、.section、.globalなどのディレクティブを使う - ARM 形式。特徴：
;でコメントを開始し、.xxxで始まるディレクティブを使わない
アセンブラの種類を自動選択する必要がありますが、ここでアセンブラの種類を auto に設定すると、プリプロセッサ定義が使えなくなってしまいます。そこで、アセンブラを「arm-clang」に選択し、アセンブラの追加オプションに「-masm=auto」を追加すれば、アセンブラを自動選択しつつ、プリプロセッサ定義も使えるようになります。
シングルステップデバッグの設定
ご存知の通り、大多数の MCU エンジニアは、ソフトウェアエンジニアのふりをしているハードウェアエンジニアです。こうした設定は MCU エンジニアにはやはり難しすぎます。これこそ、今なお Keil が主流 IDE であり続ける理由です。
まずデバッグページを開き、ワークスペースのデバッグ設定を追加します。プロジェクトとソースコードが別々のディレクトリにあるので、ワークスペース単位でデバッグ設定をするのが良いでしょう。
するとワークスペースの JSON に少量のコードが自動生成されます。補完で埋めるか、自分で書いて、次のような形にしましょう。
その中で重点的に設定すべき項目は次の通りです。
"cwd": current working directory、つまり現在の作業ディレクトリです。通常はここを ${workspaceRoot} に設定します。私たちのワークスペースにはフォルダが1つではなく、少なくとも EIDE プロジェクトフォルダと SRC ソースフォルダの2つがあるので、末尾に:EIDEを追加して、EIDE プロジェクトフォルダを基準に指定する必要があります。"executable": 生成される実行可能ファイルです。EIDE プロジェクトのコンパイル出力ディレクトリから探します。"name": デバッグタスクの名前です。後でデバッグページのドロップダウンに表示され、選択できるようになります。"type": デバッガのタイプです。チップに接続してデバッグするので、cortex-debug と入力し、cortex-debug プラグインでデバッグすれば OK です。"device": チップの完全な型番です。デバッガが対応している必要があります。通常は JLink のデバッガ exe を使うので、使用する JLink がサポートしている名前を書きます。書き込み設定の名前と同じにしておけば OK です。（書き込み設定を間違えると大変なことになるので、そのときは人を呼びましょう）"servertype": 使用しているものに合わせて選択します。ここでは jlink なので jlink です。OpenOCD の場合は openocd に変更すれば OK です。"interface": デバッグの接続方式です。"svdFile": System View Description です。アプリケーションエンジニアにはあってもなくても構わないもので、デバッグ時にレジスタの値を確認するために使います。欲しければ ST の公式サイトで探せますが、他のマイコンでは SVD ファイルが公開されていないかもしれません（Keil の Pack から抽出できます）。"liveWatch": 変数のリアルタイム値や計算式の結果を確認するオプションです。実際にはデフォルトで有効なので、設定しなくても構いません。
