STM32CubeMXをGCC(JDE)で使う(1)

STM32CubeMXについて

Stm32CubeMXはベースとなるライブラリHALも動作が安定してきて既にSTM32CubeMX抜きの開発など考えられないほど便利な開発環境です。
ただ、便利になったぶん構造が複雑になって、以前のライブラリのようにフリーの開発環境で簡単にHALを使うのは難しくなりました。

統合開発環境JDEの生い立ち

私は組込開発に専ら自作の開発環境であるJDEを使っています。
現在、組込用メインCPUとしているtm32Fシリーズを使い始める前は、H8、SHシリーズを使っていて、その前はV25を組込み開発用のCPUとして使っていました。

V25はPCと同じ86系のCPUなので、PC用のコンパイラであるBCC(Borland C Builder)とBCCが生成したPC用のオブジェクトを組込ボードで動作させるために作ったV25モニタを使ってコンパイル、転送、実行が素早くできる工夫をして自社製品にも活用しましたしV25ボードも様々な方に愛用していただきました。
そのV25がディスコンなどで使えなくなりH8,SHシリーズを使い始めた時に作ったのがGCCをベースにしたJDEです。

GCC

H8、SHシリーズを使い始めた時に開発用のコンパイラとして何を選ぶかという問題がありました。
当時はまだオープンソースのソフトをキワモノ扱いする人も多くメーカー純正コンパイラの評価が圧倒的に高い時代でしたが将来的にはGCCが優位に立つという見通しでGCCを選択しました。
他の理由としてはCPUボードや製品を愛用していただいている方に学校関係者や研究職の方が多いため「出来るだけフリーソフトで開発できるようにしたい。」ということもありました。
今ではLinuxが普及したこともあり汎用コンパイラとしてのGCCの評価は完全に固まり、組み込み用としても最適化性能を除いてはGCCが優位になりました。

最適化性能をどれだけ問題にするかは立場によって異なります。
民生機器のように数円のコストが問題になる場合はギリギリの性能と最小限のROM/RAMを持つCPUを使うためにコストや汎用性等他の点を犠牲にしても最適化性能に優れたコンパイラを使う必要があります。
一方私たちのようにFA分野の仕事を手掛ける場合や研究職、教育関係者の方々にとっては最適化性能より汎用性、コストパーフォーマンスに優れたコンパイラを使う方が有利です。
何故なら、組込分野では使えるCPUの性能は様々であり多少のコストアップで最適化性能の差を埋めるCPUを使うことが出来るからです。

具体的な例をみると、マイコンカーラリーのレギュレーションで決まっているR8Cボードに搭載されているR8C/38Aという16ビットCPUは秋月価格450円でROM128KB,RAM20KB、クロック20MHzですが、マイコンカーラリー用のデータロガーボードの試作に使ったDigiKeyで入手できる価格1517円のSTM765VGT6は32ビットでクロック216MHz、ROM1MB、RAM512KBと一桁以上の性能を有しています。
このくらいのROM/RAMがあればリアルタイムOSも楽に動くので制御ループと同時にモニタプログラムを走らせておくことも出来ますし浮動小数形式が使える普通のprintfを使っても全く問題がありません。

つまり最新の高性能組込用CPUを使えば最適化性能を気にする必要は無く、オープンソースのGCCを問題なく使えるということになります。

JDEの履歴

JDEを作った当初の目的はGCCを使うこと以外にV25モニタの思想を引き継いだH8用モニタを使ってコンパイラから転送、実行までの流れを自動化するということにありました。
私が開発を効率化するために最も重視するのはボード上の情報可視化とターンアラウンドタイムの短縮です。
H8はボード上のCPUにシリアルケーブルだけでプログラムを書き込み出来るオンボードプログラミング方式の先駆けとなったCPUでしたがCPUに書き込むために「電源を切る → ブートモードSW ON → 書き込み → 電源を切る → ブートモードSW OFF → 電源投入」という手順を踏む必要がありました。(今のR38C/38Aボードも同じです)
H8モニタを使えば書き込むために一度ボードのリセットボタンを押す必要はありますがボード上のスイッチを操作しなくても転送から実行が出来ますし、モニタモードでボードのメモリ情報を見ることが出来るようになっています。
僅かな差ですが、スイッチ操作の削減とモニタモードでの情報があることで、開発が効率的になるものです。

H8、SHシリーズに見切りをつけたのはルネサスの大手メーカーだけを向いた営業姿勢により突然デバイスの供給が数か月中断するといった事態が起こり始めたのがきっかけでした。(具体的には自動車メーカーの都合で一般へのデバイス供給が中断した件)

JDEはGCCがサポートしているCPUなら何でも使えますから、GCCが組サポートしているアーキテクチャの中で最も前途有望と思われるARM系のCPUにターゲットを絞って検討を開始し、最初はATMEL社のCPUを暫く使ってみてその後、周辺機能が充実したstm32シリーズを使い始めて今に至っています。

JDEにSTM32CubeMXが生成したプロジェクトのインポート機能追加

STM32CubeMXが出てくるまではJDEをプロジェクト管理ツール+OopenOCD仕様の書き込みアダプタを使った書き込みツールとして便利に使ってきました。
それだけならば特にJDEにこだわる必要もありませんでしたが、STM32CubeMXが生成したプロジェクトをインポートする機能を追加出来たことで自分が好きなように改造できるツールJDEを使っていて良かったと、改めて思っているところです。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA


日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)