STM新汎用MCU STM32G0

2018年12月4日、STマイクロエレクトロニクス(以下STM)の公式ブログで新汎用MCU STM32G0、Cortex-M0+/64MHzを発表しました。以下の特徴があります。
※汎用=メインストリームと本稿では考えます。

新汎用STM32G0、Cortex-M0+/64MHz、メインストリーム90nmの特徴

STM32メインストリームMCU
STM32メインストリームMCU:STM32FxとSTM32G0の違い(出典:STM32 Mainstream)
  • 「メインストリーム初の90nmプロセスMCU」:従来メインストリームSTM32F0は180nmプロセス
  • 「ハイブリッド」:STM32L4(90nmプロセス)の低消費電力とSTM32F0のメインストリームの両方をハイブリッド
  • 「モアIO」:64ピンパッケージSTM32F071比較でIOピン9本増加、48ピンでもIOピン7本増加
  • 「単一電源供給」:PCBパターン設計が容易
  • 「セキュリティハード内蔵/非内蔵」:128/256ビットAES、セキュアブート、乱数発生器、Memory Protection Unit (MPU)
  • 「USB-C」: IPによりUSB-Type-C可能
  • NUCLEO-G071RB board」:低価格評価ボード提供中、「STM32G081B-EVAL board」:$382
STM32G0ラインナップ (出典:STM公式ブログ)
供給中の3種製品とSTM32G0ラインナップ (出典:STM公式ブログ)
STM32G0 Product Lines(出典:STM32G0 Serie Presentation)
STM32G0 Product Linesから3種製品の違いが解る(出典:STM32G0 Serie Presentation)

STM32G0オンライントレーニング

データシートよりも解りやすいSTM32G0オンライントレーニング資料が多数あります(要ログイン)。

例えば、以下のような興味深い情報が得られます。各数ページの英文スライド形式ですので、STM32G0以外のMCUを使用中の方でも、チョットした空き時間に読めます。

  • STM32G0 Series Presentation:内蔵ハードウェアによりValue/Access/Access & Encryptionの3種製品特徴
  • ARM Cortex-M0+ (Core):Cortex-M0とM0+の差、Memory Protection Unit 説明
  • Safety:安全基準とその実現方法
  • Random Number Generator (RNG):アナログノイズに基づいた32ビット乱数発生
  • STM32G0 Boards:NUCLEO-G071RB board解説

STM32CubeMX V5.0.0

STM32G0のコード生成は、STM32CubeMX V5.0.0からサポートされました。

V4までと同じSW4STM32、TrueSTUDIO、両方のIDEで使えます。STM32CubeMX V5が提供するMCUファームパッケージで、本ブログ関連を抜粋したのが下表です。

STM32CubeMX V5.0.0提供MCUファームウェア版数
対象MCU firmware(評価ボード、STM32G0ボード暫定) 最新Version
STM32F1(STM32F103RB、Cortex-M3/64MHz V1.7.0
STM32F0(STM32F072RB、Cortex-M0/48MHz V1.9.0
STM32G0(V5で新設、STM32G071RB、Cortex-M0+/64MHz V1.0.0

STM32Fxテンプレートでも使用中のHAL(Hardware Abstraction Layer)ライブラリでコード生成すれば、STM32F1、STM32F0とSTM32G0間で、流用/応用が容易なソフトウェア開発ができると思います。

まとめ

新発売のSTM32G0は、90nmプロセス初のメインストリーム汎用MCUです。一般的に製造プロセスを微細化すれば、動作クロックが高速になり電力消費も低下します。さらに、STM32G0は、Cortex-M0より性能が向上したCortex-M0+コアの採用により、Cortex-M3のSTM32F1クラスに並ぶ高性能と超低消費電力動作をハイブリッドした新汎用MCUと言えます。

周辺回路では、IoTで懸念されるセキュリティ対策をハードウェアで実施、IOピン数増加、PCB化容易、USB-Type Cインタフェース提供など、各種IoTエッジMCU要求を満たす十分な魅力を持つMCUです。

競合するライバルMCUは、Cortex-M0+のNXP S32K116/S32K118(2018/7発売)などが考えられます。

関連投稿:NXP新汎用MCU S32K1

NXP新汎用MCU S32K1

NXPセミコンダクターズ(以下NXP)から車載・産業機器向けの、新しい汎用Cortex-M0+/M4 MCU S32K1ファミリが発売中です。
同社の汎用MCUと比べ、何が新しいかを調べました。

S32K1の特徴(汎用MCUとの差分)

セキュリティ強化ARMコアは、Cortex-M23/M33があります。ところが、NXPのS32K1ファミリは、従来のCortex-M0+/M4コアを使います。Cortex-M0/M0+/M3汎用MCUと比べると、差分として以下の特徴があります。

AEC-Q100グレード1規格準拠

AEC-Q100:Automotive Electronics Council、車載用電子部品信頼性の規格化団体の規格AEC-Q100は、世界標準規格で欧米の車載向け集積回路の規格。製品使用温度範囲によりグレード0~3まであり、グレード0が-40℃から+150℃で最も広範囲、グレート1は-40℃から+125℃。

セキュリティ強化ハードウェア内蔵MCU

SHE準拠Cryptographic Services Engine (CSEc) - AES128、セキュアブート、ユニークID

専用IDEのソフトウェア開発

S32 Design Studio(Processor Expert)、無償、コードサイズ制限なし

車載・産業 両方向けの汎用MCUで最低15年供給

S32K11x(Cortex-M0+):S32K116/S32K118(2018/7発売)、評価ボード$49
S32K14x(Cortex-M4):S32K142/S32K144/S32K146/S32K148(2017/12発売)、評価ボード$49/$149

S32K MCUs for Automotive and Industrial Applicationsから抜粋したS32K1ファミリの特徴が下図です。図はAEC-Q100グレード0と表記がありますが、Cortex-M0+のS32K11xは、データシートによるとグレード1です。

S32K1特徴
S32K1の特徴 (出典:S32K MCUs for Automotive and Industrial Applications)

S32K118EVB-Q064はDigiKeyで購入可能

新汎用MCUのセキュリティ強化策と専用IDE:S32 Design Studio(Processor Expert)

IoTでは汎用MCUであってもセキュリティ強化が必須です。現在、対策として3アプローチあります。

  1. 汎用コアMCUに、セキィリティ強化回路を内蔵(本稿)
  2. 汎用コアMCUに、外付けセキュリティデバイスを追加 → 関連投稿:セキュリティ強化デバイス:A71CH
  3. セキュリティ強化コアを採用 → 関連投稿:セキュリティ強化ARMコアCortex-M23/M33

1のメリットは、2と比べ部品点数が少ないこと、3と比べ従来の汎用コア開発との親和性が高く、セキュリティ関連開発が容易になる可能性があることです。

専用IDE:S32 Design StudioのAPI生成ツールは、旧FreescaleのProcessor Expertです。NXPが、なぜ既存LPCXpresso IDEでなく、専用S32 Design studioとProcessor Expertを用いたかは不思議です。が、Processor Expertという優れたAPI生成ツールのことを知っている開発者にとっては朗報になるかもしれません。

S32K1の魅力:車載・産業機器・IoT全共用

現在のS32K1ファミリ想定アプリケーションは下記です。車載・産業向けに別々のS32K1が有るわけではなく共用です。

S32Kアプリケーション
S32Kアプリケーション(出典:車載・産業機器向け Arm® Cortex®ベース S32Kマイクロコントローラ (REV 3.1))

2017~2018年に供給が始まり、最低15年の供給保障、全てに評価ボードもあります。Cortex-M0+とCortex-M4間の接続は、次世代車載ネットワークCAN FDです。

S32K14x(Cortex-M4)がNode MCU化しIoT無線通信機能を実装すれば、S32K11x(Cortex-M0+)をEdge MCUとして利用可能で、S32K1が「車載・産業機器・IoT全てを狙える新しい汎用MCU」に大化けする可能性はあると思います。

関連投稿:Node MCUとEdge MCU、気になる点2の章参照

そのほか、FlexIO、FlexTimerなどの新しい周辺回路も実装されていますので、S32K1を引き続き調査する予定です。

Cortex-M0/M0+/M3比較とコア選択

デバイスが多く選択に迷う方も多いマイコン:MCU。周辺ハードウェアも異なるので、最初のMCUコア選択を誤ると、最悪の場合、開発のし直しなどに繋がることもあります。

本稿は、STマイクロエレクトロニクスのSTM32マイコンマンスリー・アップデート10月号P8のトレーニング資料、STM32L0(Cortex-M0+)掲載のARM Cortex-M0/M0+/M3の比較資料を使ってMCUコア選択方法についての私案を示します。

STM32L0(Cortex-M0+)トレーニング資料

各種STM32MCU(Cortex-Mx)毎の非常に良くできた日本語のテクニカルスライド資料が入手できます。例えばSTM32L0(Cortex-M0+)は194ページあり、1ページ3分で説明したとしても、約10時間かかる量です。他のMCU(Cortex-Mx)資料も同様です。

開発に使うMCUが決まっている場合には、当該資料に目を通しておくと、データシート読むよりも解りやすいと思います。しかし、Cortex-Mxコア差を理解していない場合や、開発機器の将来的な機能拡張や横展開等を考慮すると、どのMCU(Cortex-Mx)を現状開発に使うかは重要検討項目です。

ここで紹介するSTM32L0(Cortex-M0+)トレーニング資料には、Cortex-M0+特徴説明のため、通常データシートには記載が無いCortex-M0やCortex-M3との違いも記載されています。

そこで、STMマイコンのみでなく一般的なARMコアのMCU選択に重要な情報としても使えるこの重要情報ページを資料から抜き出しました。

Cortex-M0/M0+/M3比較

バイナリ上位互換性

Cortex-Mxのバイナリ互換性(出典:STM32L0(Cortex-M0+)トレーニング資料)
Cortex-Mxのバイナリ互換性(出典:STM32L0(Cortex-M0+)トレーニング資料)

先ず、P22のCortex-Mプロセッサのバイナリ互換性です。この図は、Cortex-Mxコアの命令セットが、xが大きくなる方向には、上位互換であることを示しています(ただし再コンパイル推薦)。逆に、xが小さくなる方向は、再コーディングが必要です。

つまり、Cortex-M0ソースコードは、M0+/M3/M4へも使えるのです。Cortex-Mxで拡張された命令セットの特徴を一言で示したのが、四角で囲まれた文章です(Cortex-M3なら、“高度なデータ処理、ビットフィールドマニピュレーション”)。
さらに、STM32MCU内臓周辺ハードウェアは、各シリーズで完全互換なので、同じ周辺ハードウェア制御ソースコードはそのまま使えます。

もちろんxが大きくなるにつれコア性能も向上します。しかし、よりCortex-Mx(x=+/3/4)らしい性能を引き出するなら、この四角文章のコーディングに力点を置けば、それに即した命令が用意されているので筋が良い性能向上が期待できる訳です。

超低電力動作Cortex-M0+、39%高性能Cortex-M3

P22ではCortex-M0とM0+の違いが解りません。そこで、P19のCortex-M0/0+/3機能セット比較を見るとCortex-M0+が、Cortex-M0とCortex-M3の良いとこ取り、中間的なことが解ります。また、Cortex-M3が、M0比39%高性能だということも解ります。

Cortex-M0_M0+_M3セット比較(出典:STM32L0(Cortex-M0+)トレーニング資料)
Cortex-M0_M0+_M3セット比較(出典:STM32L0(Cortex-M0+)トレーニング資料)

具体的なCortex-M0+とCortex-M0との差は、P20が解りやすいです。Cortex-M0+は、性能向上より30%もの低消費動作を重視しています。また、1サイクルの高速GPIOも特徴です。Cortex-M0+は、M0の性能を活かしつつより既存8/16ビットMCU市場の置換えにチューニングしたからです。

Cortex-M0とCortex-M0+の比較(出典:STM32L0(Cortex-M0+)トレーニング資料)
Cortex-M0とCortex-M0+の比較(出典:STM32L0(Cortex-M0+)トレーニング資料)

さらにP21には、低電力化に寄与した2段になったパイプラインも示されています。Cortex-M0/M0+は、今年初めから話題になっている投機的実行機能の脆弱性もありません。

Cortex-M0とCortex-M0+のブランチ動作(出典:STM32L0(Cortex-M0+)トレーニング資料)
Cortex-M0とCortex-M0+のブランチ動作(出典:STM32L0(Cortex-M0+)トレーニング資料)

関連投稿:Cortex-Mシリーズは、投機的実行機能の脆弱性はセーフ

共通動作モード:Sleep

Cortex-M0とCortex-M0+の低消費電力モード(出典:STM32L0(Cortex-M0+)トレーニング資料)
Cortex-M0とCortex-M0+の低消費電力モード(出典:STM32L0(Cortex-M0+)トレーニング資料)

低電力化は、Cortex-M0+で追加された様々な動作モードで実現します。この一覧がP70です。つまり、Cortex-M0+らしさは、M0にない動作モード、LP RUNやLP sleep (Regulator in LP mode)で実現できるのです。

逆に、SleepやSTANBYの動作モードは、Cortex-M0/M0+で共通です。さらに、Cortex-M3でも、アーキテクチャが異なるので数値は異なりますが、SleepとSTANBY動作モードはM0/M0+と共通です。

ここまでのまとめ:Cortex-M0/M0+/M3の特徴

Cortex-M0/M0+/M3の特徴・違いを一言で示したのが、下表です(関連投稿より抜粋)。

各コアの特徴は、MCUアーキテクチャや命令セットから生じます。但し、M0/M0+/M3でバイナリ上位互換性があるので、全コアで共通の動作モードがあることも理解できたと思います。

ARM Cortex-Mx機種 一言で表すと…
Cortex-M0+

超低消費電力ハイパフォーマンスマイコン

Cortex-M0

低消費電力マイコン

Cortex-M3

汎用マイコン

Cortex-M4

デジタル信号制御アプリケーション用マイコン

関連投稿:ARMコア利用メリットの評価

MCUコア選択方法

  1. Cortex-M0またはCortex-M0+コアでプロトタイプ開発を行い、性能不足が懸念されるならCortex-M3コア、さらなる消費電力低下を狙うならCortex-M0+コアを実開発で選択。
    プロトタイプ開発に用いるソースコードは、そのまま実開発にも使えるように、全コアで共通の動作モードで開発。
  2. 早期にプロトタイプ開発を実開発に近い形で作成するために、弊社マイコンテンプレートを利用。

1.は、本稿で示した内容を基に示したMCUコア選択指針です。低消費電力がトレンドですので、プロトタイプ開発の段階から超低消費電力のCortex-M0+を使うのも良いと思います。しかし、初めから超低消費動作モードを使うのでなく、全コアで共通動作モードでの開発をお勧めします。

理由は、万一Cortex-M0+で性能不足が懸念される時にCortex-M3へも使えるソースコードにするためです。プロトタイプ開発の段階では、ソースコードの実開発流用性と実開発の評価を目的にすべきです。チューニングは、実開発段階で行えばリクスも少なくなるでしょう。

2.は、プロトタイプ開発実現手段の提案です。マイコンテンプレートは、複数のサンプルソフトを結合して1つにできます。実開発に使える(近い)サンプルソフトさえ見つけられれば、それらをバラック的にまとめて動作確認できるのです。これにより、当該コアのプロトタイプ評価が早期にできます。

また、マイコンテンプレートで使用したSTM32評価ボードは、ボードレベルでピンコンパチなのでCortex-M0/M0+/M3への変更も簡単です。

関連投稿:マイコンテンプレートを使ったアプリケーション開発手順

MCUコア選択の注意事項:重要度評価

ARMコア向けの弊社マイコンテンプレートは、全てCortex-M0/M0+/M3共通の動作モードで開発しています。
その理由は、テンプレートという性質・性格もありますが、本稿で示した他のARMコアへのソースコード流用性が高いからです。試しに開発したソースコードであっても、無駄にはならないのです。

最後に、P184、P185に示されたCortex-M0(STM32F0)とCortex-M3(STM32L1)、Cortex-M0+(STM32L0)のADCの差分を示します。

Cortex-M0/M0+/M3のADC比較1(出典:STM32L0(Cortex-M0+)トレーニング資料)
Cortex-M0/M0+/M3のADC比較1(出典:STM32L0(Cortex-M0+)トレーニング資料)
Cortex-M0/M0+/M3のADC比較2(出典:STM32L0(Cortex-M0+)トレーニング資料)
Cortex-M0/M0+/M3のADC比較2(出典:STM32L0(Cortex-M0+)トレーニング資料)

STM32MCU内臓周辺ハードウェアは、各シリーズで完全互換と先に言いましたが、スペックを細かく見るとこのように異なります。

このハードウェア差を吸収するのが、STM32CubeMXで提供されるHAL(Hardware Abstraction Layer)です。つまり、STMマイコンを使うには、コア選択も重要ですが、STM32CubeMX活用も同じように重要だということです。もちろん、STM32FxマイコンテンプレートもSTM32CubeMXを使っています。

ARMコアは、バイナリ上位互換ができる優れたMCUコアです。MCUベンダーは、同じARMコアを採用していますが、自社のMCU周辺ハードウェアレベルにまで上位互換やその高性能を発揮できるような様々な工夫・ツールを提供しています。

開発MCUを選択する時には、コア選択以外にも多くの選択肢があり迷うこともあるでしょう。多くの場合、Core-M0/M0+/M3などの汎用MCUコアでプロトタイプ開発を行えば、各選択肢の重要度評価もできます。スペックだけで闇雲に選択するよりも、実務的・工学的な方法だと思います。

STM32MCUのアンチ・タンパ機能

STマイクロエレクトロニクス(以下STM)のSTM32MCUマンスリー・アップデート最新10月号から、アンチ・タンパ機能を紹介します。

関連投稿:「日本語マイコン関連情報」のSTM32マイコン マンスリー・アップデート

タンパとは

タンパ:tamperとは、(許可なく)いじくることです。例えば、MCUパッケージをこじ開けるなどの行為(=タンパイベント)を検出した場合、内部バックアップ・レジスタを全消去し、重要データが盗まれるのを防ぐのがアンチ・タンパ機能です。MCUハードウエアによるセキュリティの一種です。

※マンスリー・アップデート10月号、P13の“STM32のココが便利”、今月のテーマ:~その2~参照

セキュリティの重要性がユーザで認識されつつあるので、開発者としては、「タンパ保護」、「アンチ・タンパ」、「RTCレジスタ保護」、「GPIO設定ロック」などのキーワードは覚えておくと良いでしょう。基本機能実装後にセキュリティを追加する時や、他社差別化に役立つからです。

STM32MCUのセキュリティ機能

マンスリー・アップデート9月号、P12今月のテーマにもセキュリティ機能がありますが、これはSTM32MCU独自というより、ARM Cortex-MコアMCU全てに実装の機能です。STM32MCUと他社の差別化には使いにくいと思います。

差別化に適すのは、ARM Cortex-Mコア以外の周辺回路です。そこで、RTCとGPIOについて、本ブログ掲載中の評価ボード実装MCU、STM32F072RB(Cortex-M0)とSTM32F103RB(Cortex-M3)のタンパ機能設定方法をデータシートで調べました。

出典:STM32F071x8 STM32F071xBデータシート 2017/1版
出典:STM32F103x8 STM32F103xBデータシート 2015/8版

関連投稿:STM32マイコンの評価ボード選定

RTC

MCUで処理実時刻を記録する場合などには、RTCが便利です。

RTCのアンチ・タンパ機能は、アラーム・タイムスタンプとRTCレジスタ保護の2つがあります。RTCレジスタ保護は、RTCレジスタへのアクセス手順のことです。RTC利用時、通常レジスタと異なる面倒な手順でRTCレジスタを設定しているのをサンプルソフトで見た記憶があります。

アラーム・タイムスタンプは、タンパイベント発生時のカレンダーを記録する機能です。但し、データシート内の説明は少なく、実際にソフトウェアでどのように設定すれば機能するかは不明です。

試しにSTM32CubeMXでSTM32F072RBのRTCを設定すると、Tamper 2のみ設定可能です。ヘルプ資料UM1718の説明も少なく、やはり詳細は不明です。
但し、将来アンチ・タンパ機能を実装するなら、Tamper 2に連動してアクティブ化するPA0ピンは、リザーブした方が良さそうです。

STM32F072RBのTamper 2とPA0
STM32F072RBのTamper 2に連動してアクティブ化するPA0ピン

同じ理由で、STM32F103RBならPA13ピンをアンチ・タンパ機能用にリザーブできると良いでしょう。

GPIO設定ロック

GPIO機能を固定するGPIO設定ロックについては、データシート内をTamperで検索してもヒットせず記述もありません。

まとめ

STM32MCUのアンチ・タンパ機能を、STM32マイコン マンスリー・アップデートから抜粋、解説しました。

ユーザがMCUセキュリティを重視しつつあるので、STM32MCUハードウエアが提供するセキュリティの一種であるアンチ・タンパは、他社差別化機能として役立つと思います。

そこで、STM32F072RBとSTM32F103RBのRTC/GPIOソフトウェアでのアンチ・タンパ設定方法をデータシートで調査しましたが、具体的情報は得られませんでした。

対策として、RTC/GPIOサンプルソフトから設定を得る方法があります。但し、ソースコードには、アンチ・タンパ機能の目的や、なぜ面倒な設定手順が必要かについての記述は無いので、マンスリー・アップデートのアンチ・タンパ、RTCレジスタ保護やGPIO設定ロックの理解が、サンプルソフト解読に必要だと思います。

Windows 10更新中断、μT-Kernal、IoTマイコン

Windows 10 1809更新によりユーザファイルが消失するトラブルが発生しています。このためMicrosoftは、Windows 10 1809への更新を一時中断しました。

Windows 10更新でマイドキュメントフォルダ消失!

消失フォルダは、よりによってC:\User\[user name]\Documentsだそうです。マイコンIDEのプロジェクトファイルをマイドキュメントフォルダへ設定している方(私がそうです)は、1809更新を待った方が良いかもしれません。

幸い私の3台のPCは、全て問題なく1809更新に成功し、Documentsフォルダも無事でした。

よく言われる最悪を避けるには、個人データのバックアップです。しかし、Windows機能更新時に、最も守るべきユーザデータを壊す/消すという不具合は、OSとしては許されません。Fast/Slow リングで検証できなかったのでしょうか?

μT-Kernal

OSと言えば、マイコン向けのリアルタイムOS:μT-Kernalの解説がトランジスタ技術2018年10月号の組込みOS入門という別冊にあり、第2章~第6章にリアルタイムOS(RTOS)の説明があります。

また、トロンフォーラムへの登録が必要ですがルネサスRL78/G14向けにポーティングしたμT-Kernalを無料でダウンロードできます。

※μT-Kernalは、ITRONベースに2003年公開の32ビットマイコン向けオープン・ソースRTOS。

本ブログではこれまでRTOSとしてFreeRTOSを紹介してきました。μT-Kernalと比較するとより理解が進むと思います。

関連投稿:マイコンRTOS習得

IoTマイコンとRTOS

IoTマイコンにRTOSを使うと、今回のWindows 10のようなトラブルを招く可能性が生じます。ただIoT通信手段が何になるにせよ、高度なセキュリティや公共リソース利用のための通信処理をマイコンで行うには、RTOSが必要になると思います。

この状況ならいっそのことIoTマイコンには、Cortex-M4(または同等クラス)とCortex-M0/M0+マルチコアを導入し、Cortex-M4でIoT関連処理、Cortex-M0/M0+で従来のMCU処理に2分割、さらにIoT関連処理はMCUベンダーが全て無償提供してくれればIoT MCUの爆発的普及が進むと思います。

つまり、Cortex-M4のIoT関連処理がWindows 10に相当する訳です。これならIoT通信手段やセキュリティが変わってもCortex-M4部分のソフトウェアをOTA(Over The Air)で変えれば対応できます。我々開発者は、本来のマイコン処理に集中できます。
理想的な空想ですがね…。

関連投稿:OTAについてIoT端末の脆弱性対応はOTA:Over The Air更新が必須の章参照

STM32マイコン マンスリー・アップデート

STマイクロエレクトロニクス(以下STM)の「日本語マイコン関連情報」、STM32マイコン マンスリー・アップデートを紹介します。

STM32マイコン マンスリー・アップデート
STM32マイコン マンスリー・アップデート。2018年バックナンバーも示す(出典:STマイクロエレクトロニクス)。

無料の登録制です。

  1. MCU最新トピックス(コラム、半ページ技術解説含む)
  2. MCU資料:更新/新規追加の一覧
  3. 開発環境(IDE)更新情報、日本語資料(トレーニング資料含む)

その他、開発に役立つ情報が、丁寧に整理されています。

特に、1最後の”今月のコラムと技術解説”は、A4:1ページに纏まっていて、チョットした空き時間に目を通しておくと、後々役立つ情報になると思います。

また、2と3のMCU資料更新や新規追加、IDE更新情報は、リンク一覧で当該場所が判る優れたハイパーテキストです。

STM32開発者以外のARM Cortex-M開発者にも有用

STM32開発者に限らずARM Cortex-M開発者なら一読の価値がある月刊誌でお勧めです。

最新ARM Cortex-Mマイコン動向とIoT MCUを特徴付ける3要素

最新ARM Cortex-Mマイコン:MCU製品からその動向を調査します。前稿ルネサスエレクトロニクス(以下ルネサス)RL78ファミリの汎用MCU変遷に続き、ARM Cortex-MコアMCU編という位置づけです。最後に両者を比較し、IoT MCUを特徴付ける3要素についての私見を示します。

最新ARM Cortex-Mマイコン製品の特徴

本ブログ掲載中のベンダ各社とMCUです。

ブログ掲載中の各社MCU
ブログ掲載中の各社MCU

ルネサス以外は、全てARM Cortex-Mコアを用いています。これらをARMコア製品、一方ルネサスはNon ARMコア製品と呼ばれます。現在のMCUは殆どがARMコア製品です。

各社ともIoT向けのMCU新製品を発売中です。その中からNXPセミコンダクターズ(以下NXP)のLPC51U68 MCU(2018年3月発売)をピックアップし特徴を抽出します。

LPC51U68は、8/16ビット置換えを狙う低消費電力Cortex-M0+コアを最大100MHz動作まで高め、USB2.0、256KB ROM、96KB RAM実装、12bit 5Mspsと高機能ADC内蔵のMCUです。

LPC51U68 MCU Block Diagram (出典:LPC51U68 Fact Sheet)
LPC51U68 MCU Block Diagram (出典:LPC51U68 Fact Sheet)

コア速度のアプリケーション対応(置換えからIoT市場開拓へ)

32ビットCortex-M0/M0+コア本来の目的は、既存8/16ビットMCUの置換えです。従ってこれまでは、既存MCU(例えばルネサスS1/S2/S3コア)速度と同等の30~50MHzがCortex-M0/M0+コア動作速度でした。しかし、NXPはより低速で低消費電力な8MHzや15MHzのコア速度の新製品を発表しました。

関連投稿:8MHz Cortex-M0+コア採用のLPC8N04

関連投稿:15MHz Cortex-M0+コア採用のLPC80x

つまり、既存MCU置換えだけでなく、よりアプリケーションに適したコア速度採用のARMコア製品の一環として開発されたのが紹介した100MHz動作のLPC51U68です。

ARMコア製品は、8/16ビット置換えから、IoTアプリケーション市場開拓への展開も始めたと言えるでしょう。

IoT向きの周辺回路実装(汎用からIoTアプリケーションMCUへ)

従来MCUもUSB接続でプログラムダウンロードやデバッグはできます。これらに加えLPC51U68のUSBは、USB 2.0ホスト機能もライブラリで提供します。PC同様、USBキーボードやデータロガー用に簡単に大容量USBメモリがMCUに接続できるので、HMI(Human Machine Interface)に優れたIoTデバイスが開発できます。

ADCもE-meterなどにも使いやすいような高機能版が用いられています。

ROM/RAM容量が増えるのは、これらIoT向け周辺回路を制御・活用するために必要で、副次的なものと言えるでしょう。

評価ボードLPCXpresso51U68 (OM40005) Development Board価格も¥3,518(DigiKey調べ)であることから、これだけ機能が増えても、従来ARMコア製品と同レベルで入手できると思われます。

LPCXpresso51U68 (OM40005) Development Board
LPCXpresso51U68 (OM40005) Development Board

最新ARM Cortex-Mマイコン動向まとめ

NXP)LPC51U68だけでなく、競合他社Cortex-M0/M0+/M3新製品についても同様の傾向が見られます。最新Cortex-Mマイコンの動向をまとめたのが下記です。

  1. IoTアプリケーションのためコア動作速度を数MHz~100MHz超の範囲で電力消費最適化
  2. USBホスト機能や高機能アナログなど、IoTアプリケーション対応高機能周辺回路を実装

一方、前稿Non ARMコア製品のルネサスMCU動向をまとめると、

  1. 低消費電力16ビットS1/S2/S3コアの使い分けで、きめ細かな電力消費へ対応
  2. アナログ機能やモータ制御機能を追加実装し、IoTアプリケーションMCUへ展開

どちらも、無線通信やセキュリティの要求が高いIoT MCUに対して、従来の汎用MCU製品のままでは対応しにくく、より具体的なIoTアプリケーションへ向けた機能拡張を行い、セミASSP的なIoT MCU製品となっています。
※セミASSP:汎用MCUをベースに、特定アプリケーション向けに調整したMCU。汎用MCU開発に慣れた開発者が、特定アプリ開発に臨む時、ASSPに比べ馴染みやすく開発障壁が低い。

ARMコア製品が柔軟性や拡張性に富み、一方で、Non ARMコア製品のルネサスもIoT向きに汎用MCUを調整しています。いずれにしても汎用MCUは、よりアプリケーション向きのMCUへ変化しつつあります。

IoT MCUを特徴付ける3要素

IoT MCUは、以下3要素から構成されると考えると理解が容易になります。

  1. IoTアプリケーション対応高機能周辺回路
  2. MCUコア
  3. 汎用周辺回路:タイマー、GPIO、UART、I2C、一般的ADC

先ず、どのようなアプリケーションにMCUを使うかで「IoTアプリケーション対応周辺回路」が実装されます。例えば、USBホスト機能が必要なアプリであれば、NXP)LPC51U68などです。

次に、そのアプリケーション周辺回路制御に十分な動作周波数や性能をもつ「MCUコア」が決まります。

最後に、「汎用周辺回路:タイマーやGPIO、UART、I2C回路」の実装数がアプリケーションに対して十分か調べます。

IoT MCUの3要素
IoT MCUの3要素。NXP)LPC51U68の分解例と開発方法。

多くのアプリケーションに広く対応できる汎用MCUの汎用周辺回路のみで開発できるアプリケーションであれば、実績が多い汎用MCUを選び、IoTに必要となる無線やセキュリティ機能を外付け部品で構成すると良いと思います。

より具体的なIoTアプリケーションに対応する場合は、IoTアプリケーション対応周辺回路を持つ各社の新製品MCU(セミASSP MCU)を選び、開発するのが良いと思います。

「IoTアプリケーション対応高機能周辺回路」とは、文字通りアプリに応じた開発や応用、最適化が必要です。各社はこのIoTアプリケーション対応周辺回路に対して、ライブラリやアプリケーションノートを提供しますので、開発はそれらを応用、流用するとリスクが低くなります。

一方、「MCUコア」と「汎用周辺回路:タイマーやGPIO、UART、I2C回路、一般的なADC」は、既存の開発ソフトウェアやハードウェアがほとんどそのまま使える可能性が高い部分です。

IoT MCUを早期開発するには、この既存ソフトウェアやハードウェアを流用し、より多くの時間をIoTアプリケーション開発へ配分する方法が適します。弊社マイコンテンプレートは、この汎用開発部分に役立ちます。ご活用ください。

マイコンテンプレート活用プロトタイピング開発(4)

マイコンテンプレートへ機能を追加するには、既に枠組みが出来上がっているテンプレートへ、追加機能名のファイルを新規作成し、追加機能をこのファイル内で記述、テンプレートのLauncher()で起動すれば完成です。長文であった第3回を、一口で言えばこうなります(トホホ… Orz)。

Basic Form of Embedded Software (Initial Setting and Repetitive)
無限ループ前に1回実行する初期設定処理と、無限ループ内の繰返し処理の2つから構成される「組込みソフトの基本形」

これは、Arduino IDEの新規作成ファイル画面です。このsetup()とloop()の構造は、Arduinoに限らず全ての「組込みソフトの基本形」です。つまり、無限ループ前に1回実行する「初期設定処理」と、無限ループ内の「繰返し処理」の2つから構成されます。

弊社マイコンテンプレートもこの基本形に則っています。但し、機能追加がし易いように、無限ループがLauncher()に変形し、複数のユーザ関数を起動できるように工夫しているだけです。

従って、最も安直(!?)な機能追加の方法は、追加機能のサンプルソフトを見つけることです。あとはテンプレートのLauncher()でこのサンプルソフトを起動すれば、テンプレートへ機能追加ができるのです。

今回の目標は、テンプレートへのSDカード機能の追加です。そこで、このSDカード機能追加に最適と思うサンプルソフト:Developing Applications on STM32Cube with FatFs:UM1721を解説します。

UM1721: Developing Applications on STM32Cube with FatFs

2014年6月版 UM1721では、STM32Cubeと記述されていますが、これはSTM32CubeMX(以下CubeMX)のことです。また、STM32F4xxとSTM32CubeF4で記述されていますが、全てのSTM32デバイスとCubeMXに置換えて読めば使えます。

FatFsは、ユーザアプリケーションと下層HAL(Hardware Abstraction Layer)の間で機能するミドルウェアで、主目的は、開発するアプリケーションが読書きするデータと、物理ストレージファイルの割付(領域管理)です。パソコンなどでは、本来WindowsなどのOSが行う機能を代行するのがFatFsと考えれば良いでしょう。また、FatFs自体はMCUハードウェアには依存しないので、本稿STマイクロエレクトロニクス以外のマイコンでも使えます。

FatFs Middleware module architecture (Source:UM1721)
FatFs Middleware module architecture (Source:UM1721)

もっと知りたい方は、UM1721の2章までに詳しく記述されています。本投稿は、FatFsを使うサンプルソフトが目的ですので読み進めると、3.3のサンプルソースが見つかります。

FatFsサンプルソフト

FatFs Sample Software (Source:UM1721)
FatFs Sample Software (Source:UM1721)

懇切丁寧なサンプルソフトとは言えませんが、必要最低限で記述しているのでしょう。一見、組込みソフトの基本形と違うと思われるかもしれませんが、初期設定処理はCubeMXが自動生成し、別の場所にソースコードを出力するため(おそらく)省略しています。また、ファイルアクセスは低速なので、繰返し回数を1で処理すると考えれば、このサンプルソフトも基本形に則っています。

サンプルソフトから、FatFsを使うAPI(Application Programming Interface)が5種、FatFsとLow Level Disk I/O Driversをリンクする2種のAPIを使えば、SDカードへの読書きができることが解ります。
※書込み:f_write()を、f_read()に置換えれば読込みができます。

FatFsサンプルソフトで使用するAPI
用途 API
FatFsとアプリケーション間

f_mount()

f_open()

f_close()

f_read()

f_write()

FatFsとLow Level Disk I/O Driversリンク間

FATFS_LinkDriver()

FATFS_UnLinkDriver()

FatFsサンプルソフトAPI動作テスト

このサンプルソフトを、第3回で使用したレファレンスプロジェクトへ挿入し、各APIの動作を確認します。

FatFs Sample API Test Source
レファレンスプロジェクトへ挿入したFatFsサンプルソフト。

結果は、FatFsとアプリケーション間5種全てのAPIで正常動作が確認できました。つまり、レファレンスプロジェクトでは、このサンプルソフトを使いSDカードへの読書きができます。その結果、SDカードへwtext[] = “text to write logical disk”のデータを、ファイル名STM32.txtとして保存できました。

FatFs Write Test to SD Card
FatFsサンプルソフトを使い、SDカードへ書込んだファイルSTM32.txtと書込みデータ。

レファレンスプロジェクトは、Low Level Disk I/O Driversリンク側のAPI相当を、エキスパートが自作しているのでコメントアウトしています。

STM32CubeMXでFatFs機能追加

第3回と同様、シンプルテンプレートをRenameし、機能追加用のSPI1FatFs_Sdプロジェクトを作成し、CubeMXでSPI1とFatFs機能を追加します。また、SdCard.cファイルを作成し、この中に前章で動作確認したサンプルソフトを挿入します(プロジェクトやファイル作成の詳細は、第3回を参照)。

FATFS and SPI1 Functions Add by STM32CubeMX
STM32CubeMXでFATFSとSPI1を追加。SPI1のピン割付は、実装シールド基板に合わせている。

Launcher()からサンプルソフトを起動し、1回のみ処理するように変更を加え、レファレンスプロジェクトと同様各APIのリターン値を確認しましたが、f_open()以降で正常動作しません。

初期設定処理を自動生成するCubeMXのFatFs設定に間違いが無ければ、SPI1FatFs_SdプロジェクトでもユーザデータをSDカードへ読書きできるハズです。UM1721には、FatFsの設定記述がないので、CubeMXのFatFsデフォルト設定にしましたが、お手上げです。

そこで、STM Communityを検索すると、例えばコチラのように現在のCubeMXのFatFsにはバグがあるようです。対策もCommunityにありますが、STMもバグ状況を把握していますのでCubeMXの改版を待つ方が良さそうです。

*  *  *

サンプルソフト自体は、レファレンスプロジェクトで動作確認済みです。CubeMXのFatFs初期設定生成に問題があることは間違いありません。つまり、組込みソフト基本形の初期設定以外の半分(50%)の処理をUM1721から獲得できたと言えます。

Tips: 動作サンプルソフトは、FatFsがMCUハードウェアに依存しないので、他社マイコンでも使えます。獲得した50%処理は、適用範囲が広いものです。

対策としては、STMによるCubeMX改版を待つこと、レファレンスプロジェクトからFatFs関連の初期設定を抜き出すこと、の2つあります。後者については、検討中です。

NFCを使うLPC8N04のOTA

5/31~6/21の4回に渡り行われたNXPセミコンダクターズ LPC80x WebinarでLPC80xシリーズ概要が解ります(8/16ビットMCUの置換えを狙う32ビットARM Cortex-M0+コア採用のLPC80xシリーズ特徴や商品戦略が解るWebinarスライドは、リンク先からダウンロード可能)。

LPC8xx Family History (Source:Webinar Slides)
LPC8xxは、LPC81x/LPC82xから、2017年高集積LPC84x、2018年価格高効率LPC80xへ展開(出典:Webinar Slides)

LPC8xxファミリは、2016年発売のLPC81x/LPC82xをベースに、2017年にLPC84xで高集積大容量化、2018年はLPC80xで価格効率を上げる方向に発展中です。

関連投稿:LPC80xの価格効率化の方法

ベースとなったLPC810、LPC812、LPC824に対して弊社は、LPC8xxテンプレートを提供中です。このテンプレートは、発展したLPC84xやLPC80xへも適用できると思います。

*  *  *

さて、本投稿は、今後IoT MCUの必須機能となる可能性が高いOTA(Over The Air)について、LPC8N04スライドにその説明がありましたので、速報としてまとめます。

NFCを使うLPC8N04のOTA更新

LPC8N04 は、近距離無線通信(NFC)機能を搭載し15MHz動作のLPC802/LPC804よりもコア速度をさらに8MHzへ下げ、NFCアプリケーション開発に適したMCUです。スマホとNFCで連動する温度センサーロガーの動作例がNXPサイトの動画で見られます。

関連投稿:LPC8N04の特徴

無線ペアリングが簡単にできるNFC搭載MCUは、家電や産業機器の故障診断、パラメタ設定などの分野へ急成長しています。Webinarスライドでは、このNFCを使った電力供給やMCUファームウェア更新方法(OTAテクニカルノート:TN00040)も紹介されています。

IoT MCUには、製品化後にも無線更新できるセキュリティ対策は必須です。OTAはこの実現手段の1つで、具体的にどうすればOTAができるのかがTN00040に簡単ですが記載されています。

前提条件として、LPC8N04のブートROMバージョンが0.14以上であること、OTA実行中は電池かUSBでの電力供給などが必要です。Androidを使ったNFC OTA動作例が下図です。

LPC8N04 FW Update Over NFC (Source:TN00040)
LPC8N04のNFCを使ったOTA更新(出典:TN00040)

更新には、LPC8N04のSBL(Secondary Boot Loader)を使い、通信は暗号化されていますので、OTA中のセキュリティも万全です。OTA用のアプリケーション開発には、通常開発にリビジョン番号(図の1.0.0、1.1.0)付与が必須など様々な制約(オーバーヘッド)があります。

OSを使わないアプリケーション開発の場合、開発者自らがこれらOTAオーバーヘッドの追加が必要になるなど煩雑ですが、決まり文句として納得するか、または、IoT MCU用RTOSとして期待されるAmazon FreeRTOS提供のOTAなどを利用するしかなさそうです。

関連投稿:Amazon、IoTマイコンへFreeRTOS提供

今回はLPC8N04のNFCによるOTAを示しました。IoT無線通信がどの方式になっても、おそらく今回のような方法になると思います。SBL利用や暗号化、更新NG時の対処など留意事項が多く、現場へ行ってIDEで再プログラミングする従来方法よりも洗練されている分、リスクも高くなりそうです。

マイコンテンプレート活用プロトタイピング開発(3)

マイコンテンプレートを使ったプロトタイプ開発の第3回は、シールド基板Joystick機能のテンプレート追加です。

Joystick for HMI (Source:Adafruit)
4方向入力とプッシュ操作ができるジョイスティック(出典:Adafruit)

要旨

STM32Fx用テンプレートを題材にしましたが、他テンプレートでも同様です。説明が長くなったので、先に本投稿の開発手順と要旨を示します。

  1. シンプルテンプレートをRenameし、「機能追加用テンプレートを作成」
  2. API作成ツール、サンプルソフトやレファンレンスなどを利用し、「追加機能を理解」
  3. 「追加機能ファイルを作成」し、追加処理をプログラミング
  4. ユーザ関数起動「Launcher()で追加処理を起動し、デバッグ」

要旨:マイコンテンプレートをプロトタイプ開発に利用すると、既に基本動作する枠組みやライブラリが準備済みなので、機能追加の開発効率が上がり、追加処理が1ファイルに閉じ込められるため、ソフトウェア資産として流用性も高まる。

シールド基板構成

機能追加に使うシールド基板は、SDカードに液晶表示画像が保存されており、カードから画像を読込み、それを液晶に出力する、これにMCUのSPIインタフェースを使う構成です。Joystickは、液晶表示の選択肢を入力するためのHMI(Human Machine Interface)に使います。

Shield Fabrication Print
TFT液晶出力、SDカードのデータ入出力、Joystickでの5SW入力、これら3機能ハードウェアを追加するシールド基板(Source:Adafruit)

回路図からも解るようにJoystickは、シールド基板のSDカードやTFT液晶とは完全に別物です。1個のJoystickで「上下左右」と「プッシュ」の5入力を1本のADC入力だけで処理できますので、効率的で低価格なHMI実現手段の1つと言えます。

本投稿は、このJoystickのADC入力を弊社STM32Fxシンプルテンプレートへ追加し、ADC_Joystickプロジェクトを作り動作確認します。

関連投稿:テンプレート活用プロトタイピングの開発方針:第1回ソフトウェア概要:第2回

テンプレート変更準備

今回は、初めてですので、少し丁寧に説明を加えます。

最初に、ワークスペースへシンプルテンプレートを取込み、これに「変更を加える前」にプロジェクト名をADC_JoystickへRenameします。

Template Project Rename
Template Project Rename

Renameを選択すると、プロジェクト名の入力ダイアログが現れますのでADC_Joystickと入力します。

さらに、「手動」でcfg/ico/pdf/txtの4ファイル名をADC_Joystick. cfg/ico/pdf/txtに変更します。

最後に、ADC_JoystickをClean ProjectとBuild Projectすると、正常にコンパイルされ、シンプルテンプレートからADC_JoystickへRenameが成功したことが確認できます。

Tips:リネームプロジェクト名は、「追加周辺回路_装置」としました。プロジェクト名を見れば、時間が経過した後でも、内容が解りやすいメリットがあります。

関連投稿:Eclipse IDEプロジェクトのImportやRename方法

また、レファレンスプロジェクトとしてTFTシールドサンプルソフトもワークスペースへ取込みます。方法は、
File>Import>Existing Projects into Workspaceで
Repository>STM32Cube FW F0 V1.9.0>Project>STM32F072RB-Nucleo>Demonstrations>STM32F072RB-Nucleoを選択しImportしてください。

以上で、2プロジェクトがワークスペースへ入り、ADC_Joystickに変更を加える準備ができました。

Renamed to ADC_Joystick Project
ADC_JoystickプロジェクトとTFTシールドサンプルソフト(STM32F072RB-Nucleo)がワークスペースへ入る

STM32CubeMXでADC追加

Joystickで利用するADCを、STM32CubeMX(以下CubeMX)でADC_Joystickプロジェクトへ追加します。

CubeMXを起動し前章で手動変更したADC_Joystick.icoをLoadすると、シンプルテンプレートのCubeMX設定がロードされます。これに周辺回路ADCを追加します。

ADCのIN8に☑を入れると、PB0ピン、PB.00を使うことが解ります。このPB.00がArduinoコネクタA3に接続されており、Joystickのアナログ値がADCへ入力されます。

STM32CubeMX Setting
STM32CubeMX Setting

通常は、ここでADCを利用するサンプルソフトなどを参照し、詳細設定を調べます。しかし今回は、もっと直接役立つレファレンスプロジェクトのADC関連ソースを読みます。

※レファンレンスソースは一部しか抜粋しませんので、解りにくいと思いますが、文章が分かれば十分です。

TFT_ShieldDetect Logic
TFT_ShieldDetect Logic

ADC関連は、最初にmain.cのL120でシールド基板の実装有無を確認し、実装(SHIELED DETECTED)ならばTFTを初期化(BSP_LCD_Init())し、SDカードから画像読込み(SDCard_Config())を実行します。

L116のコメントから、PB.00電圧レベルで基板有無を確認していることが解ります。そこで、ShieledDetect()を読むと、アナログ入力として使う予定のPB.00を、ここでGPIO入力+プルダウンへ初期設定した後、電圧レベルを読込み、0以外で基板実装と判断しています。

PB.00をアナログ入力に設定しているのは、TFT_DisplayImages()の中、L304のBSP_JOY_Init()です。

つまり、最初にPB.00をGPIO入力+プルダウンに設定し、入力が0以外で基板実装と判断し、次に同じPB.00をADCのIN8に再設定(stm32f0xx_nucleo.cのL841)します。アナログ入力では基板有無の判定ができないのです。
プルダウンが設定できるGPIO入力なら基板無し(電圧レベル=0)の判定が可能です。また、ADC設定は、CubeMXのデフォルト設定で良いことも解ります。

Tips:「同じピン機能をADCからGPIOに切替えて実装有無を判断するテクニック」は、今回だけでなく他でも使えるので覚えておくと役立ちます。

以上、レファンレンスからADCの使い方が解りました。CubeMXへADC追加後のConfigurationタブを示します。CubeMX ProjectをセーブしGenerate Code、Generate Reportを実行し、初期化コードを生成して下さい。

STM32CubeMX Configuration
STM32CubeMX Configuration

シールド基板実装判定GPIOとADCの切り替え

ADC_Joystickのmain.cには、PB.00のADC初期化コードMX_ADC_Init()がCubeMXにより自動追加されます。では、どこで基板実装有無を確認するかというと、L232のUserInit()で行います。

UserInit()
テンプレートに準備済みのUserInit()

UserInit()は、無限ループ実行直前に、何らかの独自設定をユーザが行うための関数です。テンプレートには初めからこの関数が準備されています。

Shield Detection Logic in UserInit
Shield Detection Logic in UserInit

UserInit()のL128で基板実装判定のため、PB.00を再度GPIOに設定し直します。そして、判定結果をUSB経由のCOMポートへ出力します。テンプレートには、COMポート出力機能がありますので、簡単に判定結果が出力できます。

基板実装を確認したら、L146でPB.00を再再度ADCに設定します。

つまり、PB.00はCubeMXでADCとして初期設定しますが、UserInit()で基板実装判定のためGPIOに再設定し、実装済みならもう1度ADC初期設定をします。ADC初期設定コードは、CubeMX自動生成コードですので、将来ADC設定に変更が生じたとしてもCubeMXを変えれば良いだけで、ソースはそのまま使えます。

後は、ADCの値を読んで、stick位置を判断し、その結果も基板実装結果と同様、COMポートへ出力すればJoystick関連の追加処理は完成です。

STM32F0とSTM32F1のBSP

BSPはBoard Support Packageのことで、評価ボード用のライブラリです。
STM32F0用は、Drivers>BSP>stm32f0xx_nucleo.c/hです。STM32F1用は、stm32f1xx_nucleo.c/hです。

関連投稿:BSP解説は、コチラの投稿のSTM32Fxファームウエア構成やHAL Examplesの章を参照。

Joystickのstick位置判断関数BSP_JOY_GetState()もこのBSPで提供されますが、面白いことに、F0用とF1用のBSP_JOY_GetState()の閾値が異なります。どちらも同一条件で動作するので異なる必要はありません。また、if~else if~else文で分岐するのも、処理時間が長くなります。

Difference Between F0 BSP_JOY_GetState() and F1
Difference Between F0 BSP_JOY_GetState() and F1

そこで、F0用のより広い判断閾値を使い、if文とgoto文で分岐する方法を用いました。

Stick Position Judgement
Stick Position Judgement

ADC_Joystickプロジェクト動作確認

Joystickのみ機能追加する場合に備え、stick位置のCOMポート出力、STM32F0xとF1xで共用のための#ifdef~#endifなどの関連処理を新規追加のJoystick.cファイルに集め、ADC_Joystickプロジェクトへ加えました。

ADC_Joystick File Configuration
ADC_Joystick File Configuration

シールド基板を実装すると評価ボード上の青SWが操作できませんので、ユーザ関数を起動するLauncher()のSwScan()はコメントアウトし、代わりに40ms周期起動にstick位置の取得判断関数:JoystickSacn()を入れました。

完成したADC_Joystickプロジェクト動作中のCOMポート出力例を示します。

ADC_Joystick COM Output Example
ADC_Joystick COM Output Example

まとめ

STM32Fxシンプルテンプレートを使って、シールド基板のJoystick機能のみを追加しました。

長文説明になりましたが、実際に行った処理は、下記のようにとても簡単で単純です。

  1. テンプレートプロジェクトをRenameし、ADC_Joystickプロジェクト作成
  2. STM32CubeMXで、作成プロジェクトへADC機能を追加
  3. レファレンスプロジェクトのADC関連部分を読み、使い方と設定理解
  4. 機能追加/削除を容易にするため、Joystick.cファイルを新規追加し、ADC関連処理記述
  5. Launcher()で起動し、必要に応じて処理結果をCOMポートへ出力し、追加処理の動作確認

テンプレートには、COMポート出力やUserInit()などの基本的な処理と枠組み、BSPなど開発に必要となるライブラリが既に準備済みなので、「追加する処理にのみ集中して開発できる」ことがお判り頂けたと思います。

Joystickファイルを新規追加すると、機能の追加/削除、他プロジェクトへの応用も簡単です。ユーザが手動で変更する箇所は、ユーザ関数を起動するLauncher()やUserInit()、COMポートへの出力メッセージ程度で、初期化コードなどはAPI作成ツールSTM32CubeMXが自動的に生成します。