大致紹介#
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} に設定しますが、私たちの作業スペースには複数のフォルダーがあるため、少なくとも 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“：変数のリアルタイム値と計算式の結果を表示するオプション。実際にはデフォルトでオンになっているため、設定する必要はありません。
