STM32CubeIDE事始め

STM32CubEIDEについて

STマイクロエレクトロニクスから、統合開発環境TrueSTUDIOに、MCUの周辺機能を設定して自動的にライブラリを作成するSTM32CubeMXを組み込んだ無償版の開発環境STM32CubeIDEがリリースされました。

STM32CubeMXとTrueSTUDIOを統合して使い勝手をシンプルにしたというコンセプトで、STマイクロとしては今後、推奨開発環境をSTM32CubeIDE一本に絞るということです。
これまで、stm32シリーズのプログラム開発ツールとして有償無償版を含め、いくつかありましたが、今後は無償版のIDEをメーカーが本腰を入れてサポートするとアナウンスしたことは歓迎できます。

俺様開発環境のJDEからSTM32CubeIDEに移る

私はルネサスのH8、SHシリーズを使っていた時代からこれまで、GCCをベースにした自作の統合開発環境JDEを使ってきました。

JDEを作って使い続けてきた理由の一つは無償版の開発環境がなかったことです。
私の会社の顧客には教育・研究開発機関があり、ユーザーがプログラムを開発・変更出来るように開発環境を含めたシステムを提供することがあるため、高価な有償の開発環境を避けたかったことがあります。

もう一つは、私がかつてのVZエディターやDelphiのDOSIDEキーマップにこだわっているということがありました。
このキーマップは Ctrl-Sで左、Ctrl-Dで右、Ctrl-Eで上、Ctrl-Xで下にカーソルが移るDOSの時代に流行ったものです。
マウスを使わずにコードを編集したいということもありますが、このキーマップに慣れていてWindowsの標準キーマップを使うと、うっかりCtrl-Xを押してラインを消去してしまうことが頻発するためです。

STM32CubeIDEはメーカー推奨の無償版開発環境で、最新のEclipseをベースにしていて、キーのカスタマイズが自由に出来るためほぼ不満のない使い勝手となりました。

もう一つの理由として、STM32CubeIDEがOpenOCDをサポートしてくれたことがあります。
これまでMCUボードへの書き込み手段としてJtagKeyをベースにしたFT2232Dを使った書き込みボードをOpenOCDから使っていました。
この書き込みボードはJtagKeyで空いていた9,10番ピンにFT2232Dで使える仮想 COMポートのTx,Rxを割り当てて、プログラム書き込みと同時にUSBシリアル機能が使えるようにしたもので、リアルタイム制御プログラムで欠かせないシリアルモニタ機能をサポートするものです。

STM32CubeMXがリリースされたときにJDEでCubeMXを使うために、JDEにCubeMX が生成するプロジェクトをインポートする機能を追加したりもしましたが、これから発表される可能性のある新機能に対応していくのも面倒なため、この機会にSTM32CubeIDEを本格的に使い始めることにしました。

MCUボード設計に役立つSTM32CubeMX

※MCUはマイクロコントローラの略称でCPUとタイマーやADなどの高機能な周辺機能をワンチップに集積したICです。

STM32CubeMXは強力なプログラム開発支援ツールです

STM32CubeMXはstMicroが提供するstm32シリーズ用無償開発環境で、GUI画面でMCU周辺機能を設定することで、自動的に主変機能の初期化及び設定のプログラムを自動生成してくれるプログラミング支援ツールです。
特長はstm32シリーズのラインアップを全てをサポートし、RTOSやfatFS、LANをサポートするミドルウェアが一体化していることです。
未だリリースされていないMCUもSTM32CubeMXの選択画面にはリストアップされていて、メーカーがツールを重要視し、MCUの開発と一体化して進めているようです。

MCUの周辺機能が高機能で複雑になった現在では、このようなツールの性能がMCUのマーケットシェアを左右するため、半導体各社は使いやすくて高機能なツールを提供することに努めています。

MicroChipのMPLAB-Xも同様のコンセプトの開発環境ですが、プロ用ツールとしてはSTM32CubeMXが優れていると感じます。

ルネサスもスマートコンフィギュレータという名のツールを提供しているようですが、開発環境としては遅れている印象があるのは否めません。
今はMCU内のCPU性能より内蔵周辺機能や開発環境の使いやすさがMCU選択の決め手になる時代です。このままではstMicroやMirochipとの勢いに差がつく一方です、日本のMCUメーカーとして開発環境の拡充に力を入れていただきたいものです。

マイコンボードの設計支援ツールとして役立つSTM32CubeMX

STM32CubeMXはプログラム開発支援ツールですが、実はMCUボードの回路設計でも大活躍します。
STM32シリーズに限らず最近のMCUはADコンバータ、タイマー、シリアル通信、CAN、SPI、DMA、USB、LAN等の豊富な周辺機能を搭載しています。

豊富な内蔵周辺機能のおかげでコンパクトなMCUボードで色々なアプリケーションに対応できるのですが、設計時にどのMCUを使ってどの端子を割り当てかを決めるのにデータシートをひっくり返しながら悩む必要がありました。

その作業がSTM32CubeMXを使うようになってから格段に楽になりました。

手順としては、まず最初にSTM32CubeMXでプロジェクトを作成し使えそうなMCU選定します。
次にSTM32CubeMXの画面で必要な機能を有効にして端子を割り当てていきます。必要な機能を割り当てることが出来たら、そのMCUを使うことに決定し、割り当てた端子を使って回路図を作成します。

MCUボードが完成したら、そのプロジェクトを使ってソフト開発を始めます。
このような手順で開発を進めることによって数倍の効率で開発を進めることが出来るようになりました。

HALを使うべきか使わざるべきか

HALとは Hardware Abstraction Layer  すなわちハードウェアを抽象化して、様々なハードウェアに同じプログラムでアクセスできるようにする仕組みのことです。

PCでおなじみのBIOSもHALの一種に入ります。

STMicroのSTM32CubeMXが生成するライブラリはHALライブラリと呼ばれていて、MPLAB-Xが生成するコードも似たようなもので、HALライブラリを使うとデータシートを見ながら周辺機能レジスタの値を設定する面倒な作業から解放されます。

HALを使わずにPWM出力をおこなう

PWMについて調べていて、HALを使わないでPWM出力をおこなうプログラムについて書いてある上の記事を見つけました。記事の主題は次のようなものです。

「HALを使わないでPWM設定プログラムを書いてみた。 基本的なペリフェラルならレジスタ手打ちで行くのが一流STM32erの流儀らしい(英文サイト参照)。でも、やはりSTM32CubeMXは便利。」

ここで紹介されている About STM32 HAL quality and performance – Stack Overflowを見るとHALに対して「わかりにくい、バグがある、オーバヘッドがある。」というコメントがありました。

STM32CubeMXが発表されて既に3年以上経ちます。当初は「わかりにくいし、バグだらけで使いにくい。」という意見を多く見かけましたが、最近になって安定してきたせいか、前向きの評価が増えてきたようです。

STMicroはSTM32CubeMXを発表する前に Standard Peripheral Library という名前のHALライブラリを提供していました。

Standard Peripheral Library も良く出来たライブラリでUSBやLANを使うためには欠かせず、使い込んだライブラリでしたが、新し物好きの私はSTM32CubeMXが出てすぐにHALライブラリに乗り換えました。

STM32CubeMX+HALライブラリの効果

私が組み込み用として使うのはstm32シリーズに決めていますが、アプリケーションによって最適なCPUが異なるのと、次々と高性能なstm32が発表されることからプロジェクトごとに新しいCPUボードを設計しています。

新規CPUボードのソフトウェア開発で一番時間がかかるのは、周辺機能の動作を一通り確認出来るまでの段階でしたが、STM32CubeMX+HALライブラリのおかげで、この段階は劇的に効率化されました。

確かにHALライブラリには「わかりにくい、バグがある、オーバヘッドが大きい。」というデメリットもありますが、開発の効率化とプログラムの標準化という大きなメリットに比べれば些細な問題に過ぎません。

HALライブラリはわかりにくい?

レジスタに値を設定する単純なプログラムに比べると、HALライブラリはとっつきにくいのは確かです。
ただ、初期化プログラムの開発で発生するトラブルは、データシートからは読み取りにくいレジスタ設定の抜けや設定の順番に起因するもので、USBやLANなどの複雑な処理では、解決までに試行錯誤で数週間を費やすことも珍しくはありませんでした。
HALライブラリを使うと、その無駄な試行錯誤をしなくて済むという効果が大きいのです。
つまり、プログラム表記としては複雑でわかりにくく見えますが、プログラム開発で行き詰まってしまうわかりにくさは大幅に減ったといえます。

HALライブラリのバグ

実際のところHALライブラリのバグで悩まされた経験は殆どありません。
HALライブラリは多くの人が使っていて、不審な動作に出会ったときは検索するとたいてい誰かが情報を発信しているので回避策を素早く見つけることが出来るためです。
コンパイラやライブラリのバグを見つけて鬼の首を取ったように非難している人がたまにいますが、よほど枯れたシステムでない限りバグフリーのコンパイラやライブラリはあり得ないので、バグを上手く回避して使うのがコツです。

気にならないHALライブラリのオーバヘッド

民生分野でなく、開発効率化優先で豊富なハードウェアリソースを使うようにしている私の経験からはHALライブラリのオーバヘッドが気になったことはありません。
最近のCPUはワンチップの中にLinuxを組み込めるのではないかと思うほどFlashもRAMサイズも大きくなっていて、もともとコードサイズの小さい制御プログラムを書く上では、コードサイズの肥大は無視できるレベルです。

必要以上にCPUの性能が高くなっているのに加えてDMAなど周辺ハードウェアだけでこなせる処理が増えているため、HALライブラリのオーバヘッドによる処理速度の低下に悩まされることも無くなりました。

初期化時に実行するだけのHALライブラリがほとんどで、繰り返し実行する部分は単純なレジスタ処理だけで済むこともあります。

HALライブラリを使わないプログラムは勉強になる

プログラムのベテランなら積極的にHALライブラリを使うべきだと思いますが、HALライブラリの中で行われていることを全く理解していないと、問題にぶち当たったときに全く前に進めない場合があります。

HALライブラリのレジスタに値を設定している部分を参考にして、レジスタに直接値を設定してみて、HALライブラリの処理を理解するのは解りやすく制御プログラミングのトレーニングとしても大いに役にたちます。