大致紹介#
EIDE は、マイコンプロジェクトを開発するための VSCode プラグインです。例えば、8051、stm8、stm32、other cortex-m mcus などです。
EIDE を Keil プロジェクトの後続アプリケーション開発に推奨します。ボードの開発や周辺機器の開発は Keil で行うのが良いでしょう。公式のものであり、安心です。また、stm32cubemx で生成された Keil プロジェクトも非常に便利で、初めての周辺機器探索は Keil で行うのが良いでしょう。
なぜ EIDE を選ぶのか、PlatformIO IDE ではなく？#
最も重要なのは、EIDE が Keil プロジェクトをシームレスにインポートできることです！これにより、元々安定しているプロジェクトを再検証する必要がなくなります。EIDE は Keil の唯一の価値あるコンポーネントである AC6 コンパイラをサポートしています。
次に、EIDE は中国人が開発したプラグインであり、コミュニティとのコミュニケーションにストレスがありません。作者は非常にアクティブで、返信も非常に迅速です。また、プラグイン以外の技術的な問題についても、作者に問い合わせることができます。
以下はコミュニティのアドレスです。
Embedded IDE Forum (em-ide.com)
前期準備#
前期準備の目標を明確にしましょう。vscode+EIDE のインストールを完了し、EIDE プラグインが ARM-GCC および AC6 のツールチェーンを検出できるようにします。
インストールに関しては、この記事では手取り足取りの指導はしません。
まずは公式ドキュメントを確認することをお勧めします。少なくとも公式ドキュメントの「始めに」セクションを完全に読み終えてください。
インストール | Embedded IDE For VSCode (em-ide.com)
次に、コミュニティのブログ記事も良いですが、やはり公式ドキュメントに従って環境設定を行うことを最もお勧めします。
[VSCODE] 基于 EIDE 插件搭建 vscode 下的 STM32 单片机开发环境 - Foriver - 博客园 (cnblogs.com)
追加準備#
追加準備はデバッグのために行います。ご存知の通り、オンボードプログラムがステップデバッグできない場合、複雑なプログラムを開発することは基本的に不可能です。
必要なクラシックな神器 Cortex-debug プラグインを使用します。
再度、公式コミュニティのドキュメントを参照します。
cortex-debug 用法 - 博客 - Embedded IDE Forum (em-ide.com)
簡単に言うと、以下の 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 でこのプロジェクトが正常にコンパイルされ、ボードが点灯することを確認することをお勧めします。
公式ドキュメントに従ってこのプロジェクトをインポートします。
プロジェクトのインポート | Embedded IDE For VSCode (em-ide.com)
インポート時に、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 プラグインでデバッグします。"device"：チップの完全なモデル。デバッガがサポートする必要があります。通常、私たちは JLink のデバッガ exe 実行ファイルを使用するため、JLink がサポートする名前と同じにしておけば大丈夫です。（もし書き込み設定で間違った場合、大変なことになりますので、誰かに頼んでください。）"servertype"：使用するものに応じて選択します。ここでは jlink を使用していますが、openocd の場合は openocd に変更します。"interface"：デバッグ接続方式。"svdFile"：system view description。アプリケーションエンジニアにとっては必須ではありませんが、デバッグ時にレジスタの値を見るために使用されます。必要な場合は、ST の公式サイトで探すことができますが、他のマイコンでは svd ファイルが公開されていない可能性があります（Keil の pack パッケージから抽出できます）。”liveWatch“：変数のリアルタイム値と計算式の結果を表示するオプション。実際にはデフォルトで有効になっているため、設定する必要はありません。
