Cortex-M0からCortex-M0+変化

2020年7月3日2020年7月10日 WithHappy

前稿で示したNXP MCUラインナップ図には、ARM Cortex-M0/M0+両方のコアが掲載中でした。しかし、最新版MCUXpresso IDEのコア選択ダイアログには、Cortex-M0選択肢がありません。

そこで、Cortex-M0+とCortex-M0の違いを調べた結果、新規MCU開発にNXPのCortex-M0コアを使う必然性は低いという結論に達しました。本稿は、その根拠を示します。

ARM Cortex-M0+とCortex-M0の差

弊社関連投稿：Cortex-M0/M0+/M3比較とコア選択や、ARMコア利用メリットの評価、ARM MCU変化の背景をまとめ、ARMコアの発表年順に示したのが下表です。※M4の発表年は間違っているかもしれませんが、市場に出回ったCortex-Mxコアの順番は下表で正しいハズです😌。

ARM Cortex-Mx性能、発表年
Cortex-Mコア	性能 (MIPS @ MHz)	ARM発表年	MCUモデル
Cortex-M3	1.25	2004	旧メインストリーム
Cortex-M0	0.9	2009	ローコスト
Cortex-M0+	0.95	2011	ローパワー
Cortex-M4	1.25	2012頃	デジタル信号処理新メインストリーム

要するに、Cortex-M0+やCortex-M4は、Cortex-M0やCortex-M3をベースに市場ニーズに即した変更を加えた新しいARMコアだと言うことです。本稿では、特にCortex-M0+とM0の違いに注目します。

Cortex-M0+には、表の差以外にも高速IOアクセス、高速パイプライン、低消費動作モードなどCortex-M0には無い数々の特徴がありますが、Cortex-M0よりも高性能（0.9→0.95MIPS@MHz）で、シリコンチップ高速化にも好都合です。

つまり、新規開発にCortex-M0+の代わりに敢えてCortex-M0コアを用いる理由は、見当たらない訳です。

NXPの新しい統合開発環境MCUXpresso IDEのSDKのコア選択肢に、Cortex-M0が無いのは、上記が理由だと思います。※ローコストに関しては、コア単体の相対評価はできても、使用数量でかなり変動するためMCUコスト絶対評価を難しくしています。

NXP MCUXpresso SDK対応評価ボード数

最新MCUXpresso IDE v11.1.1のSDKで対応中の評価ボード数を一覧にしました。例えば、Cortex-M33コアなら下図のように7個です。

評価ボードは、プロトタイプ開発には必須で、その評価ボードで動作するSDK（Software Development Kit）があればソフトウェア開発効率は向上します。Cortex-Mxコア間のソフトウェア移植性は高く、同じコアのソフトウェアであれば、異なる評価ボードへの移植もさらに容易です。

つまり、評価ボード数が多いCortex-M0+やCortex-M4が、現在最もCortex-Mxコアソフトウェア開発効率が高いことを示しています。また、Cortex-M3コア選択肢がない理由も、Cortex-M0コアがない理由と同じと推測します。

本当の並列処理が要求されるマルチコア開発なら、Cortex-M0+とM4のペア、または、IoTセキュリティを強化したCortex-M33コアx2であることも判ります。※Cortex-M33は、2016年ARM発表のセキュリティ強化コアです。

新規ARM Cortex-Mxソフトウェア開発は、Cortex-M0+コアまたはCortex-M4コア利用に収束してきたと思います。
※Cortex-M33コアは、従来コアに無いIoT向けセキュアゾーンなどが新規機能追加されていますので除外しています。

弊社テンプレート開発方針

前稿のNXP MCUラインナップからCortex-M0とCortex-M3を除き、現状SDK提供中のARM Cortex-Mxコアラインナップをまとめると下図になります。※Cortex-M33は未掲載です。

Software Development Kit開発から見たNXP MCUラインナップ

弊社もCortex-M0+、Cortex-M4、Cortex-M33コア向けのテンプレート開発を進める方針です。

中国製STM32互換MCU

2020年1月31日2020年2月3日 WithHappy

1月28日、EE Times Japanに“互換チップが次々と生まれる中国、半導体業界の新たな潮流”という記事が掲載されました。スイス・ジュネーヴ本社のSTマイクロエレクトロニクス（以下STM）のSTM32互換MCUが、中国で製造プロセス縮小、ローコスト化し販売中だそうです。

STM32F030、STM32F103互換MCU

記事記載の互換デバイスは、STM32F030（Cortex-M0、64KB Flash、8KB RAM）と、STM32F103（Cortex-M3、７2MHz、128KB Flash、20KB RAM）の2種。どちらもSTM純正180nmプロセス製造MCUを、130nmプロセスで製造しており、ローコスト化、低電力化、動作周波数アップが狙いです。

さらに、ARM Cortex-Mコア部分のみをオープン仕様RISC-Vコアへ変えた、STM32互換RISC-V MCUもあるそうです（記事、図４参照）。

記事筆者の清水氏（テカナリエ）は、これら中国製互換デバイスを否定するのが目的ではなく、現状の事実、互換製造ができる高い技術力、STM32MCUが汎用MCUデファクトスタンダードであること、中国半導体業界のこの方向性が、ますます加速する可能性があると報告しています。

日本が見習うべきもの

RISC-Vはオープン仕様ですが、Cortex互換MCU販売には、ARMライセンスフィーなど気になる事柄もあります。但し、本ブログ筆者も清水氏と同じく、その背景にある技術力、ビジネスセンスについて見習うべきものが多いと思います。

STM互換MCUは、純正品よりも安く、しかも高性能です。開発環境や評価ボード、開発ソフトウェアはそのまま互換MCUでも動作します。欧州ベンダのSTM互換MCU開発・販売は、米国ベンダ互換よりもハードルが低いでしょう。世界情勢なども反映された成功事例だと思います。

例え安く高性能な部品（BOM：Bill Of Matrix）が提供されても、それを使って開発できる技術者がいなければ製品化はできません。技術者スキルが最も伸びるのは、開発中です。中国技術者は、高性能製品を低価格で、次々と提供できている事実があります。

もちろん失敗事例もたくさんあるハズです。しかし、技術者にとっては、成功失敗を問わずどんな事例でも開発経験はスキルに直結します。

一方、日本の環境は、時短や効率化など見た目の生産性や成功例のみに注目しがちです。ただ、技術者スキルは世界レベルで評価されるので、このままの環境では、先々の日本開発案件は無くなるのではと危惧しています。

例えば自動車は、日本メーカを選択する人はいても、それが日本開発かは問題にしません。むしろ世界各地で開発されています。
※日産の先進自動運転技術（ADAS）は、米国女性技術者が中心で開発されたと、何かで読んだ記憶があります。

5G、6G世代のネット高速化、自動翻訳やAIなどの環境変化で、日本開発に拘るユーザは、減少の一途となるでしょう。

日本技術者は、次世代の自分自身のため、世界で通用するスキルを身に付ける必要があります。

弊社STM32F0/F1に使えるSTM32FxテンプレートやSTM32G0xテンプレート、その他ベンダのMCUテンプレートは、初心者～中級レベルソフトウェア技術者向きです。初級～中級技術を効率的に習得し、さらに高度なスキル獲得に少しでもお役立てれば幸いです。と、最後は自社広告になってしまいました😌。

STM32CubeIDE v1.1.0更新と文字化け対策（その2）

2019年11月8日2019年11月15日 WithHappy

STマイクロエレクトロニクス（以下STM）の統合開発環境：STM32CubeIDEが、v1.1.0に更新され、前投稿：その1では、従来SW4STM32プロジェクトをSTM32CubeIDEインポート時の日本語文字化け対策と、最新STM32MCU開発環境を示しました。

その2では、最新開発環境での文字化けと、開発環境更新リスク、ファームウェア更新へのリスク対応案について示します。

開発環境更新リスク

MCU開発ソフトウェア（＝アプリケーション）への影響が一番大きいのは、ファームウェア：FW_F0/F1/G0/G4更新です。統合開発環境：CubeIDEやコード生成ツール：CubeMXの更新は、操作性や見た目へ変化を与えますが、アプリケーションそのものへの影響は、少ないです。

MCUアプリケーション開発は、STM32MCUに限らずベンダ提供API：Application Programming Interfaceのユーザ開発アプリケーションによる操作です。ファームウェア更新は、このベンダ提供APIのバグ取りや、新デバイス追加に関連するものが一般的です。開発済みユーザアプリケーションの場合は、デバイスは変わらないので、ファームウェア更新による影響があるのは使用中APIです。

従って、開発したアプリケーションの使用APIが変わらなければ、ファームウェア更新は問題ないハズです。

ところが、稀にファームウェア更新により正常に動作していたAPIにも影響が生じトラブルが発生することがあります。ファームウェア更新には、このリスクがあることも知っておきましょう。
※このリスク対策としてCubeMXは、旧版ファームウェアをRepositoryフォルダへ保存し、いつでも旧版へ戻せる準備をしています。

ベンダAPI、つまりファームウェア互換性には期待しない方が無難です。

理由は、最新ベンダMCU製造プロセス（＝ハードウェア）、WindowsなどのパソコンOS、ベースのEclipse IDE、ARM CMSISなどのアプリケーション下層の更新、などなど様々なバージョンアップの組合せ結果が、ベンダAPI更新や刷新となるからです。

ベンダAPI互換が、既存ユーザにとっては理想です。しかし、元々非力なMCU能力を、従来API互換へ使うよりも、むしろファームウェア更新時点で、MCU能力を最も引き出すAPIへ使い、新規ユーザへアピールしたいとベンダが判断してもやむを得ないと思います。
※高性能MPU/GPUでさえAPI互換が無いことがあります。APIとは、そういうものだと割切って、例えAPIが変わっても柔軟に対応できるソフトウェア開発者が求められるのかもしれません。

ファームウェア更新リリースノートに、このAPI互換性の詳細説明を求めるのは、多分無理です。既存ユーザは、開発環境、特にファームウェア更新に関しては、慎重に対処すべきだと思います。

MCUアプリケーションは、開発完了時の開発環境依存度が非常に高いソフトウェアです。

最新デバイスと、最新APIの組合せが、その時点で最も効率的で優れたMCUアプリケーション開発手段と言えます。
※ルネサスのCS+には、アプリケーション開発完了時の開発環境を、一括圧縮保存する便利機能があります。Eclipse IDEにもプラグインで同様の機能を追加できると思います。

ファームウェア更新リスク回避策

筆者が考えるMCUアプリケーション開発に対するファームウェア更新リスクの回避策が、下記です。

ユーザ開発アプリケーションが顧客システムで稼働中、しかもバグなどの問題が無い場合は、あえて前章リクスがあるファームウェア更新はしない
アプリケーション開発が進行中の場合は、旧版ファームウェアで開発継続し、完成後に最新版を試す
開発済みアプリケーションへ機能追加の場合は、開発時ファームウェアで機能追加し、完成後に最新版を試す
新にアプリケーション開発を始める場合は、APIバグ可能性のより少ない最新ファームウェア開発環境で着手

開発完了から時間が経ったアプリケーション改版時には、開発当時のファームウェア更新への対策時間も加味しスケジュールを作成することをお勧めします。さもないと、肝心のアプリケーション改版前の段階でつまずいてしまいます。

※弊社販売中テンプレートは、テンプレート応用例として、評価ボード実装済みSWやLEDを制御するシンプルテンプレートと、Baseboardで各種機能を追加したBaseboardテンプレートの2つを添付しています。このうちBaseboardテンプレートは機能豊富な代償として、上記ファームウェア更新リスクに出会うことが稀にあります😫。テンプレートなので、本当は原理を解っていただくシンプルテンプレートのみを添付したいのですが、Baseboardテンプレート付きの方が売れるのでやむを得ない状況です😥。

投稿その１、その２と前振りが長くなりました。次回、汎用MCUシェア第2位の販売中STM32FxテンプレートやSTM32G0xテンプレートを使って、最新開発環境への移設実例、トラブル対応を示します。

ARM Cortex-M4プロトタイプテンプレート構想

2019年11月1日2021年2月15日 WithHappy

弊社は、ARM Cortex-M4コア使用のLPC5410x（NXP）、STM32G4（STM）、PSoC 6（Cypress）、MSP432（TI）各社のMCUテンプレート開発を目指しています。本稿は、各社共通のCortex-M4プロトタイプテンプレート開発指針を示します。

MCUプロトタイプ開発ステップ

プロトタイプからMCU製品開発へのステップが上図です。

IDEと評価ボードを準備、利用MCUの開発環境構築
サンプルプロジェクトを利用し、MCUや内蔵周辺回路の特徴・使い方を具体的に理解
製品処理に近いサンプルプロジェクトなどを活用し、評価ボード上でプロトタイプ開発
プロトタイプへ保守点検などの製品化処理を追加、製品時ベアメタルかRTOS利用かを評価
ステップ04評価結果でA：ベアメタル製品開発、または、B：RTOS製品開発へ発展

更に製品化へは様々なステップも必要ですが、プロトタイプ開発に絞るとこのステップになります。

Cortex-M4プロトタイプテンプレート

弊社Cortex-M4プロトタイプテンプレートは、ステップを効率的に上るための開発支援ツールです。

販売中の弊社テンプレートと同様、複数サンプルプロジェクトや開発した処理を、RTOSを使わずに時分割で起動するマルチタスク機能を備えています。
※時分割起動マルチタスク機能：ステップ03と04の課題は、複数サンプルプロジェクトや製品化に必要となる様々な処理を、どうやって1つに組込むか（？）ということです。RTOSを利用すれば解決します。しかし、RTOS利用のためだけに別途知識や理解が必要で、RTOS活用までの階段差が非常に高いという欠点があります。弊社テンプレートは、時分割で複数処理を起動し、初心者でも仕組みが理解できる低い階段差でマルチタスク機能を実現します。詳細は、コチラなどをご覧ください。

販売中の従来テンプレートとCortex-M4プロトタイプテンプレートの違いが、以下です。

ステップ05以降の製品開発へも、ステップ01で構築したプロトタイプ環境をそのまま使える
下位Cortex-M0/M0+/M3ソフトウェアに対して、Cortex-M4プロトタイプ開発資産が流用できる

Cortex-M4の高性能を、プロトタイプ開発マージン（後述）に使うとこれらの違いが生じます。

Cortex-M4コアMCUの特徴

ARM Cortex-M4は、Cortex-M0/M0+/M3とバイナリ互換です。

簡単に言うと、Cortex-Mコア開発元ARM社が推進するCMSISに則って開発したCortex-M4ソースコードやライブラリは、再コンパイルすればCortex-M0/M0+/M3へ流用・活用ができます。
※CMSIS：Cortex Microcontroller Software Interface Standard関連投稿は、コチラの2章などを参照してください。

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

図から、Cortex-M4バイナリの全ては、下位Cortex-M0/M0+/M3に含まれてはいません。従って、効率的な処理やセキュリティ対策必須の高速演算を行うには、Cortex-M4が最適なのは言うまでもありません。

Cortex-M4を使ったMCUは、Cortex-M0/M0+/M3 MCUに比べ動作クロックが高速で内蔵Flash/RAM容量も大きいため、ベアメタル利用だけでなく、RTOS利用も可能です。

Cortex-M4がプロトタイプ開発に最適な理由：大マージン

Cortex-M4のMCUでプロトタイプ開発すれば、製品化時に必要となる処理や保守点検処理などの実装も「余裕」を持ってできます。
※製品出荷テストプログラム、自動販売機待機中のLEDデモンストレーション点灯などが製品化処理具体例です。

筆者は、このような製品化処理を、おおよそプロトタイプ処理と同程度と見積もります。つまり、製品のFlash/RAM量は、プロトタイプ時の2倍必要になります。

仮に「余裕」がありすぎオーバースペックの場合には、開発したCortex-M4プロトタイプ処理（＝開発ソフトウェア資産）を、そのまま下位Cortex-M0/M0+/M3コアMCUへ流用が可能です。

一方、処理が複雑で多い場合には、RTOSで解決できるか否かの評価もCortex-M4プロトタイプなら可能です。更にIoT製品では、セキュリティ関連の（先が見えない）処理や計算量増加にも対応しなければなりません。

安全側評価なら敢えて下位Cortex-Mコアを選ばずに、Cortex-M4をそのまま製品にも使えば、処理増加にも耐えらます。

つまり、プロトタイプ開発には、初めから容量や性能の足かせが無く、製品化移行時の開発リスクも少ない高速高性能・大容量のCortex-M4 MCUが最適なのです。

製品時の処理能力やFlash/RAM量を、Cortex-M4プロトタイプで見積もった後に、製品化にステップアップすれば、適正な製品制御Cortex-Mコアを選択できます。開発ソフトウェア資産の流用性、過負荷耐力、RTOS製品開発評価ができる高性能を兼ね備えたのが、Cortex-M4を使ったプロトタイプ開発です。

問題は、価格です。

各社のCortex-M4評価ボード価格は、Cortex-M0/M0+/M3評価ボードと大差ありません。STM32MCUの評価ボード：Nucleo32シリーズは、Cortex-Mコアが異なっても同額です。プロトタイプ開発マージンを考慮すると、たとえ評価ボードに多少の価格差があったとしても十分納得がいきます。

Cortex-M4デバイス単体価格は、Cortex-M0/M0+/M3よりは高価です。しかし、製品原価全体に占めるCortex-M4デバイス価格比は低いでしょう。IoT製品では、今後増大するセキュリティ対策や計算量増加などを考慮すると、Cortex-M4デバイスを使うメリットは大きいと思います。

Cortex-M4プロトタイプテンプレート開発指針（NXP、STM、Cypress、TI共通）

Cortex-M4の特徴を活かし、下位Cortex-M0/M0+/M3間での開発ソフトウェア資産流用を考慮したCortex-M4プロトタイプテンプレート開発指針です。

Cortex-M0/M0+/M3/M4各コアに用いるテンプレート本体の共通化
プロトタイプ開発ソフトウェア資産流用性を高めるCMSISソフトウェアでの開発
製品化時ベアメタルかRTOS利用かを評価のため、Cortex-M4最高速動作のプロトタイプ開発

現在CMSISへの対応は、各社足並みが揃っているとは言えません。もしも完全にCMSISへ対応した場合は、異なるベンダ間でも開発アプリケーション互換が実現するからです。ARMコア市場が「攻めに強く、守りに弱い」ゆえんです。そういう状況でも、各社ともCMSISへのソフトウェア対応を進行中です。
※Cortex-M33コアには、CMSISに反して、ベンダ独自のカスタム命令追加の動きも見られます。

本稿で示したCortex-M4プロトタイプテンプレートと異なり、弊社販売中のCortex-M0/M0+/M3テンプレートは、テンプレート利用コアで最適解を与えます。そのため、RTOS利用時や、製品化処理、セキュリティ対策などの処理が増えた時には、元々のコア処理性能や内蔵Flash/RAMに余裕が少ないため、適用デバイスでの製品化に対して、開発を続けにくい状況が発生することもありえます。

この点、Cortex-M4プロトタイプテンプレートなら、プロトタイプで構築した同じ開発環境で、RTOSも含めた製品開発へも余裕を持って対応できます。同時に、プロトタイプ開発資産の流用や活用により、Cortex-M0/M0+/M3ソフトウェア生産性も高めることができます（一石二鳥）。

弊社Cortex-M4プロトタイプテンプレートの発売時期、RTOSへの具体的対応方法などは、未定です。本ブログで各社毎の開発状況をお知らせする予定です。

あとがき：初心者や個人利用は、Cortex-M4テンプレートが最適

ソフトウェア開発初心者にCortex-M4プロトタイプテンプレート利用は、難しい（＝階段を上るのが困難）と考える方がいるかもしれません。筆者は、全く逆、むしろ初心者、個人利用に最適だと思います。

理由は、Cortex-M0/M0+/M3/M4と上位になるほどコア設計が新しく、処理性能も上がるからです。初心者が、あまり上手くないコード記述をしても、コア性能が高いため問題なく処理できてしまいます。詳細は、ARM Communityの“An overview of the ARM Cortex-M processor family and comparison”などが参考になります。

ごく簡単に言うと、自動車エンジンが、Cortex-Mコアに相当すると考えてください。

小排気量なCortex-M0より、大排気量のCortex-M4の方が、楽に運転でき、しかも、運転に最低限必要なハンドルやアクセル、ブレーキ操作は全く同じです。車（＝評価ボード）の価格が同じなら、殆どの方が、余裕のある大排気量のCortex-M4を選択するでしょう。

しかも、Cortex-M4評価ボード操作の技（＝開発ソフトウェア資産）は、Cortex-M0/M0+/M3へも流用できます。経済的に厳しい個人利用のプロトタイプ開発環境としては、流用範囲の広いCortex-M4 MCUテンプレートが最適と言えます。

弊社Cortex-M4プロトタイプテンプレートは、つまずき易い階段を、楽に効率的に上るための開発支援ツールです。ご期待ください。

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

2018年10月29日2021年2月15日 WithHappy

デバイスが多く選択に迷う方も多いマイコン：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比較

バイナリ上位互換性

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

Cortex-M0とCortex-M0+の比較（出典：STM32L0（Cortex-M0+）トレーニング資料）

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

Cortex-M0とCortex-M0+のブランチ動作（出典：STM32L0（Cortex-M0+）トレーニング資料）

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

共通動作モード：Sleep

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コア選択方法

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

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比較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のアンチ・タンパ機能

2018年10月21日2018年10月29日 WithHappy

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

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

タンパとは

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

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

セキュリティの重要性がユーザで認識されつつあるので、開発者としては、「タンパ保護」、「アンチ・タンパ」、「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設定ロックの理解が、サンプルソフト解読に必要だと思います。

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

2018年6月18日2018年6月18日 WithHappy

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

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

要旨

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

シンプルテンプレートをRenameし、「機能追加用テンプレートを作成」
API作成ツール、サンプルソフトやレファンレンスなどを利用し、「追加機能を理解」
「追加機能ファイルを作成」し、追加処理をプログラミング
ユーザ関数起動「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します。

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へ入力されます。

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

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

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を実行し、初期化コードを生成して下さい。

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

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

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

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

ADC_Joystickプロジェクト動作確認

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

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

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

まとめ

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

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

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

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

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

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

2018年6月3日2018年6月6日 WithHappy

マイコンテンプレートがプロトタイピング開発に適すシリーズ投稿第2回は、開発に活用流用できるソフトウェア＝ライブラリの概要を示します。説明するライブラリが下記です。詳細説明が必要になった時は、それに応じて追記するので、今回は概要を示します。

Arduinoシールド付属C++ライブラリ
SW4STM32付属デモソフト
STM32CubeMX：初期化Cコード生成ツール
HAL：Hardware Abstraction LayerとBSP：Board Support Package
Middleware Components：ミドルウェア：FatFs
STMicroelectronicsアプリケーションノート
STMicroelectronics Communityやネット情報

ソフトウェアは、ドライバーやミドルウェアなど階層構造や使い方に応じて色々な呼び方がありますが、本投稿では、開発に使える可能性のあるソフトウェアや情報を、全てライブラリと呼びます。つまり、開発者自らが開発するソフトウェアと、その開発に使えるライブラリの2つに大別して説明します。

開発着手時は、各ライブラリ概要をおおよそ把握し、自分で開発するソフトのイメージが捉えられれば十分です。後はそのイメージをソフトの形にしてテンプレートに追加すれば、プロトタイピング開発完成です。

1.Arduinoシールド付属C++ライブラリ

Arduinoは、オープンソースハードウェアのシングルボードコントローラです。Arduinoコネクタにシールド基板を実装すれば、誰でも簡単に機能追加できるのがウリです。もちろんハード制御に必須なソフトウェア＝ライブラリもシールド基板とともに提供されます。

TFTシールド基板ライブラリは、ArduinoのAPIを利用しC++で記述（左下：shieldtest参照）されています。Arduino IDEにこのライブラリを追加しさえすれば簡単に基板の動作確認ができ、ソース変更も容易です。しかし、これを対象マイコン用に変更するのは、簡単ではありません。API変更とC++が問題です。

2.SW4STM32付属デモソフト

SW4STM32には、TFTシールド基板のデモソフトが付属しています。UM1787にデモファームウェアが紹介されており、利用や変更、修正など開発者が自由に使って良いライブラリです。

TFT Shield Demonstration running (Source：UM1787)

但しこのデモソフトは、デモの表示画像やテキストの変更は簡単でも、一部機能の切出しや新機能の追加、例えばUART入出力処理の追加などは容易ではありません。また、最新の開発ツールSTM32CubeMXベースで開発されたのもでもなく、エキスパートが自作したものです。

このデモソフトのような既存ファームウェアがあっても、そのまま流用活用しにくいというのは、MCUソフトウェア開発ではよくある話です。既存ファームウェアやライブラリの解析に手間と時間がかかるため、新たな環境で新たなソフトウェアを開発したほうが早く済むこともよくあります。

ナゼか？　それは、流用性や資産とすることを念頭に置いてソフト開発をしないからです。MCU処理能力の低さやメモリ量の少なさが主な原因ですが、これらは今後改善されます。MCUソフトも流用性を重視し、ソフトウェア資産、部品化を考慮した開発が今後必要です。

3.STM32CubeMX：初期化Cコード生成ツール

STM32CubeMXは、STM32シリーズの全MCUに対して、GUIでパラメタを設定しさえすれば周辺回路の初期化Cコードを自動生成するツールです。また、SW4STM32を含め全IDE（TrueSTUDO、MDK-ARM、EWARM）で共通に使えるなど守備範囲も広く「STM32ソフトウェア開発の要」です。

UM1718に解説があります。このUM1718のTutorial 2に、MCUはSTM32F4ですが、本開発に使えるSTM32CubeMXの設定方法があります。

関連投稿：STM32CubeMX設定については、コチラの投稿も参照してください。

4.HAL：Hardware Abstraction LayerとBSP：Board Support Package

HALは、文字通りハードウェア隠蔽機能を提供する階層です。CortexコアといえどM0/M0+/M3/M4などハードウェアは異なります。この異なるハードにも関わらずHALが同じAPIを上位層に提供するので、性能不足などでコア変更が生じても同じソフトが流用できる訳です。UM1749に詳しく解説されています。

BSPは、このHALのAPIを組み合わせた評価ボード特有機能のマクロ関数です。評価ボードを制御系にそのまま利用する時に便利です。

HALやBSPを使うとオーバーヘッドも生じます。しかし、流用性向上のメリットの方が大きいと思います。

関連投稿：HALのオーバーヘッドは、コチラの投稿の、“STM32CubeMXの2種ドライバライブラリ”を参照してください。

5.Middleware Components：ミドルウェア：FatFs

FatFsは、MCU向けの汎用FATシステムモジュールでフリーソフトウェアです。MCUハードには依存しないので、どのマイコンでも使えるのが特徴です。FatFs APIを使うと、SDカードなどのファイルシステムに簡単にアクセスできます。

STM32CubeMXでは、MiddleWaresのFatFs、User-definedに☑を入れると使えようになります。

6.STMicroelectronicsアプリケーションノート

UM1721は、“Developing Applications on STM32Cube with FatFs”と本開発にはピッタリの内容です。3.3にサンプルソフトがあります。これは、FatFsを使って開発したソフトの単体テストに使えます。

7.STMicroelectronics Communityやネット情報

STMicroelectronics Communityなどのベンダーコミュニティは、開発者同士の情報交換、質問の場です。各ベンダーは、提供ツールのバグ情報や更新方針などもこのコミュニティーから収集していますので、時々閲覧すると参考になります。開発でつまずいた時など解決方法が見つかることもあります。

また、検索エンジンでは様々なネット情報が得られます。最新情報などを取集すると、開発動向の把握も可能でしょう。

開発ソフトウェア構成とイメージ

今回のソフトウェア開発に役立つライブラリ概要を示しました。

直ぐにソースコードを書きたい気持ちを少し我慢して、ほんの少し事前調査をすると、視野が広がり使えそうなライブラリの見当もつきます。使えるモノを流用すれば、より重要箇所に集中できます（前回投稿の「選択と集中」ができます）。

本開発は、SPIシールド基板で追加する3機能毎にSTM32CubeMXを用いてソフト開発し、テンプレートへ追加します。また、流用性を上げるため追加機能毎にファイル化し、単体機能の追加削除も容易な構成とします。これをまとめたのが前回投稿の開発方針図です（再掲します）。

Development policy — 初期設定生成ツール：STM32CubeMXや、評価ボード開発支援ライブラリを活用しテンプレートへ機能追加

MCUのライバル

プレッシャーをかけるつもりはありませんが、競合他社のMCUだけがライバルではありません。

ArduinoコントローラやRaspberry Pi 3などのMPUは、後発の利点を活かし、ソフトウェア/ハードウェア開発が、誰でも早く簡単にできる工夫が施されています。どちらも低価格で開発環境が整います。MCU開発者の方は、是非どちらか試して、MCUに比べ開発の簡単さを実感してください。

MCU Rivals_R1 — MCUのライバルは、競合他社だけでなく、ArduinoコントローラやRaspberry Pi 3などもある。

制御系	特徴	開発障壁	ソフトウェア流用性
MCU	低消費電力アナログ/デジタル周辺機能豊富	高い	低い
Arduino/Genuino	オープンソースハードウェア基板豊富なシールド基板で機能追加が容易	低い	高い
Raspberry Pi 3 B/B+	OS搭載シングルボードコンピュータ動画再生や複雑な技術計算も可能	とても低い	高い

最新Arduinoの動きとしては、SonyのSPERSENSEなどがあります。また、Raspberry Pi 3 B+では、コア速度やLAN高速化、PoEなどのIoTに向けた性能向上も図られています。

MCU評価ボードにArduinoコネクタの採用が増えたのは、豊富なシールドハードの簡単追加が目的です。また、ARM CMSISもMCUソフト流用性を高める方策の1つです。

関連投稿：ARM CMSISの目標については、コチラの投稿の、“CMSIS”を参照してください。

CMSIS実用化に伴い、MCUソフトウェア開発者も、個人レベルでソフト資産化と各種ライブラリ活用技術を身につけないと、先行するArduinoやRaspberry Piへ顧客が逃げてしまいます。

逆に、ArduinoやRaspberry Piのソフトウェアやライブラリを積極的にMCUへ流用するアプローチも（簡単にできれば）良いと思います。

いずれにしても、MCUソフトウェア開発は、既存ライブラリや様々な資産をより活用して、開発効率化を上げることが必要でしょう。

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

2018年5月27日2018年5月28日 WithHappy

Adafruit 1.8 Color TFT Shield with microSD and Joystick (Source: Adafruit)

前投稿で、プロトタイピング開発に、マイコンテンプレートが適すと説明しました。その理由は、テンプレートの既に出来上がった汎用処理へ、顧客要求機能を追加しさえすれば、早期に顧客ソフトウェア開発がほぼ完成するためです。つまり、顧客仕様の開発に、より集中できるのです。

働き方改革と、今後も増える仕事量、このバランスを開発者が保つには、選択と集中です。
集中すべきは顧客独自仕様、それ以外は既存資産をより流用活用するテクニックを身につけることです。

具体的にこのこと説明するため、今回から数回に分けて、マイコンテンプレートと評価ボードに、上図Arduino SPI接続シールド基板を追加する開発例を使って、プロトタイピング開発にテンプレートが適すことを説明します。

テンプレート活用開発例の前提条件

マイコン：STM32F072RB（STMicroelectronics）
マイコンテンプレート：STM32Fxテンプレート（HappyTech）
マイコン評価ボード：Nucleo-F072RB（STMicroelectronics）
Arduino SPI接続シールド基板：1.8” TFT Shield with Joystick and microSD (Adafruit)

途中、別内容の投稿もありますので、3カ月程度の期間で7～10件程度のシリーズ投稿を予定しております。

STM32F072RB/Cortex-M0コアを用いますが、STM32FxテンプレートのCortex-M3コア/STM32F103RBでも同様です。また、投稿カテゴリーはSTM32マイコンですが、他マイコンのテンプレートを使用中、検討中の方も参考にしてください。

様々なシールド基板がある中で、SPI接続シールドを選択した理由は、マイコンでも従来のGPIOによるLCD表示から、よりリッチなSPI：Serial Parallel InterfaceによるカラーLCD表示に変わりつつあることが背景です。詳細は、コチラの投稿を参照してください。

Arduino SPI接続シールド基板構成

Adafruitの1.8“カラーTFTシールド（128×160ドット）、microSDカードスロットとジョイスティック搭載基板（3,680円）は、秋月電子から入手できます。

このシールド基板は、TFT液晶出力、SDカードのデータ入出力、Joystickでの5SW入力、これら3機能を、マイコン評価ボードArduinoコネクタに装着するだけでハードウェアの追加ができます。

そこで、テンプレートへシールド3機能のソフトウェアを追加していきます。これにより、Joystickのみ、SDカードのみ、あるいは全機能の追加などいろいろなバリエーションの開発例を説明します。

サンプルソフト、レファレンスソフト構成と開発方針

本開発に使えるサンプルソフトや既存ライブラリを一覧にし、開発方針を図示しました。

Arduinoのシールド基板には、C++ライブラリが付属していますが、これはArduinoでの動作が前提なので、マイコンにはそのまま使えません。

上手いことに開発環境SW4STM32には、使用するArduino SPI接続シールド基板のデモサンプルソフトが付属しています。但し、このデモソフトは、エキスパートが自作したExamples and Demosなので、部分的に機能を切出そうとすると、解析や変更に手間取ります。

せっかく初期設定生成ツール：STM32CubeMXや、評価ボード開発支援ライブラリのBSP：Board Support Packageがあるのですから、これらツールやライブラリを活用しない手は無いでしょう。
そこで、図示したようにデモソフトは、レファレンスとして活用し、極力STM32CubeMXやBSPを使ってエキスパート自作ソフトと同じものを、初心者でも開発できることを開発方針とします。

シリーズ投稿の予定内容

実際に着手しないと投稿内容は確定しませんが、一応の目安として、下記内容の投稿を目標、予定しています。

第1回、シールド基板、サンプルソフト、レファレンスソフト構成と開発方針（←今回の投稿）
第2回、BSP、FatFs、STM32CubeMX、デモソフト、アプリケーションノートなどの活用/流用可能ソフトウェア概要
第3回、Joystick機能のテンプレート追加：Joystickのみ追加希望の方は、ココまでで開発できることを目標にします。
第4回、SDカードリード/ライト機能のテンプレート追加：SDカードのみ追加希望の方は、ココまでで開発できることを目標にします。
第5回、TFT表示機能のテンプレート追加：TFT表示のみ追加希望の方は、ココまでで開発できることを目標にします。
第6回、SPIシールドテンプレート構成：シールド3機能全てを追加する場合のテンプレート構想
第7回、SPIシールドテンプレート開発：シールド基板活用のTipsなどの資料も含むテンプレート化を目指します。

このように、現在のGPIO LCDを使ったテンプレート応用例Baseboardテンプレートに加えて、最終回にはSPIシールドテンプレートとして発売できれば完成です。ご期待ください。

Yano E plus 2018.5にHappyTech掲載

シンクタンクの矢野経済研究所様の月刊誌Yano E pulsの2018.5、注目市場フォーカス：MCU（マイコン）市場の6-7に、弊社HappyTechが掲載されました。MCUの現状、2021年までの市場予測、ベンダー各社動向などがまとめられたレポートです。お近くに冊子がある場合には、ご覧ください。

マイコンデータシートの見かた（最終回）

2017年12月15日2017年12月20日 WithHappy

現役STマイクロエレクトロニクスの「メーカエンジニアの立場」から記載された、ユーザ質問の多かった事項を中心にマイコンデータシートの見かたを解説する記事（連載3回目）の最終回を紹介します。

全3回の連載記事内容

第1回：凡例、絶対最大定格、一般動作条件、電源電圧立上り/立下り（2017年10月1日投稿済み）
第2回：消費電流、低消費電力モードからの復帰時間、発振回路特性（2017年10月29日投稿済み）
第3回：フラッシュメモリ特性、ラッチアップ/EMS/EMI/ESD、汎用IO、リセット回路（←今回の投稿）

マイコンデータシートの見かた

3回分割のマイコン個別機能データシートの見かた、最終回ではSPIとADCの記載データ見かたが当初予定に追加されました。SPIは、接続デバイスがASICやFPGAの場合の注意点、ADCは、アナログ回路なので消費電流が大きくなる点に注意すべきだと記載されています。

当然のことですがデータシートは、データ値の羅列です。従って、そのデータ値の意味と解釈の仕方は、例えば記事図9の赤囲みコメントで付記されたようにすべきです。しかし、普通は残念ながら赤囲みコメントは、データシートには付いていません。

従って、この赤囲みコメントが自然に頭に浮かぶような勉強、半導体の基礎知識がマイコンを使うには必要で、その知識を背景にデータ値を読むことを記事は求めています。

連載3回範囲のデータシート見かたまとめ

フラッシュメモリは、高温使用時、データ保持年数が短くなる。データシート記載値は、MCU内部書込み/消去時間であり、書込み開始～終了までの作業時間ではない。書き換えビットが増えると消費電流も増える。
EMS/EMI/ESDは、MCUを実装した基板や使用環境に依存。データシート記載値は、MCU「単体の能力」。
汎用IOは、電源電圧を下げると端子駆動能力も下がり、立上り/立下り時間が長くなる。しかし、STM32MCUは、駆動能力をレジスタで設定できるので遅くなることを抑えることができる。
MCUリセット回路設計時は、フィルタリング信号幅のグレーゾーンを避けることが必須。
SPIは、接続デバイスがASICやFPGAの場合、十分なタイミングマージンが必要。
ADCは、アナログ回路のバイアス電流のため消費電流が大きくなる。また電流変動で変換誤差が増える。

全て学んだ後の開発着手では遅い！

開発者に求められるのは、「開発したもの」です。

そして、多くの場合、短い期限付きです。問題は、この期限内で、なにがしかの結果、成果を出さなければ、開発者としてはNGなことです。しかし、成果を出すには勉強、知識も必要です。

初心者は、この勉強、知識の入力時間と、成果の出力時間の配分が上手くありません。ベテランになると知識も増えますが、入出力の時間配分が上手く、結局何らかの成果も生みます。特に開発者は、全行程の自己マネジメント（時間配分）にも注意を払う必要があります。

例を挙げると、夏休みの自由課題を何にし、休み中にどのように仕上げるか、です。もし提出物が無ければ、課題に取り組んでいないのと（殆ど）同じです。

残業時間制約も厳しく、開発者にとっての作業環境は厳しくなる一方です。弊社マイコンテンプレートとMCUベンダ評価ボードとの組合せは、開発者が求められる出力を早期に生み出すツールになると思います。