最新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アプリケーション開発へ配分する方法が適します。弊社マイコンテンプレートは、この汎用開発部分に役立ちます。ご活用ください。

RL78ファミリから解る汎用MCUの変遷

汎用MCUの定義が変わりつつあります。ルネサスエレクトロニクス(以下、ルネサス)のRL78ファミリから、最近の汎用MCUの変わりつつある現状を考察します。

RL78ファミリの汎用MCUロードマップ

2018年6月版の最新RL78ファミリMCUカタログから抜粋したRL78ファミリのロードマップです。

RL78ファミリロードマップ (出典:ルネサス汎用MCUラインアップカタログ)
RL78ファミリロードマップ (出典:ルネサス汎用MCUラインアップカタログ)

赤囲みのRL78/G1xが汎用MCU製品を示します。2014年以後は、For小型システムやForモータシステムなど、一見するとASSP:application-specific standard product、特定用途向けMCUのような製品が汎用MCUの中にあります。

これは、RL78/G1Fのコンセプトを見るとその理由が理解できます(出典:ローエンドマイコンで実現できる 高機能なブラシレスDCモータ制御

RL78_G1Fのコンセプト(出典:ローエンドマイコンで実現できる 高機能なブラシレスDCモータ制御)
RL78_G1Fのコンセプト(出典:ローエンドマイコンで実現できる 高機能なブラシレスDCモータ制御)

つまり、汎用MCU RL78/G14を、モータシステム向きに周辺機能拡張や使い勝手を向上させたのがRL78/G1Fなのです。あくまで汎用MCUがベースで、それを特定用途、この場合はモータ制御向けに調整したのです。

このメリットは、開発者、ルネサス双方にあります。開発者にとっては、使い慣れた汎用MCUの延長上に特定用途向けMCUがあるので馴染みやすく開発障壁が低くなること、ルネサスにとっては、新規ASSPを開発するよりも低コスト、低リスクなことです。

RL78ファミリの汎用MCUとは、変わる定義

RL78ファミリのMCUには、S1/S2/S3という3種類のコアがあります。数字が大きくなると高性能になります。

関連投稿:RL78 S1/S2/S3コアの分類

ルネサスの汎用MCUとは、これらS1/S2/S3コアを使ったMCU製品を指します。また、RL78/G1FのようにS3コアMCUのRL78/G14をベースとし、特定用途向け機能を付加したものも汎用MCUです。

※弊社は、S1/S2/S3コアの各汎用MCUに対してRL78/G1xテンプレートを販売中です。

販売中の汎用MCU向けテンプレートと特定アプリ向けMCUの関係
販売中の汎用MCU向けテンプレートと特定アプリ向けMCUの関係

この特定用途名が、ルネサスが考えるIoT時代にふさわしい汎用MCUと言えます。「汎用」という従来の広く漠然とした用途よりも、より「具体的な用途・応用に適す汎用MCU製品」としてRL78/G1FやRL78/G11があるのです。

特定用途向け汎用MCU開発にもRL78/G1xテンプレートが役立つ

このIoT時代の特定用途向けMCU開発でも、弊社RL78/G1xテンプレートが使えます。ベースが「汎用中の汎用」RL78/G10(S1コア)、RL78/G13(S2コア)、RL78/G14(S3コア)だからです。

例えば、RL78/G1Fのアプリケーションノートやサンプルコードは、具体的でほとんどそのまま開発製品へ適用できます。しかし、用途が限定されているだけに、逆に簡単な機能追加が難しい場合もあります。そんな時に、テンプレートが提供するサンプルコードを活かしつつ処理を追加できる機能を使うと便利です。

ここでは、ルネサス汎用MCUについて考察しましたが、NXPセミコンダクターズやSTマイクロエレクトロニクス、Cypressセミコンダクターなどの他社MCUベンダも同様です。汎用MCUの定義は、より具体的な用途・応用名が付いたIoT MCUへ変わりつつあります。しかし、基本の汎用MCUを習得していれば、より応用し発展できます。基本が重要だということです。

IoTでは、MCU開発はより複雑で高度になります。また、製品完成度の要求もさらに高まります。基本要素や技術を、(たとえブラックボックス的だとしても)積み上げられる、基礎・基本を習得した開発者のみが生き残ると思います。開発者個人で基礎を習得するために、是非弊社マイコンテンプレートをご活用ください。

MCU開発環境トラブル顛末(1803クリーンインストール後)

MCU開発環境のWindows 10 Pro Version 1803クリーンインストールに至った経緯を前稿で示しました。今回は、クリーンインストール後に改善された点、変わらなかった点、新しく気が付いた点などを記載します。

クリーンインストールで改善された点

クリーンインストール前は、110GB程度の使用量であったCシステムドライブが、同じアプリをインストールした後でも80GB程度で済みました。
この30GBの差がどうして生じたのかは、解りません。OSやアプリを使っているうちに溜まるゴミがあるとしても、30GBは大きすぎます。

差分の原因は不明ですが、意を決してクリーンインストールしたお陰(ほうび)として考えています。

クリーンインストール前後で変わらなかった点

OneDrive同期のOffice 2010サムネイル表示は、Excelのみ非表示が続いています。

もしかしたらOffice 2013以降であれば、正常にサムネイル表示されるのでは?と考えています。Office 2010延長サポートは2020年10月13日、つまりあと2年で終了します。Microsoftとしては、なるべく上位バージョンへの移行をユーザへ進めたいでしょうからその施策の1つではとの(うがった)考えからです。

私は、Office 2010の代替として、無償LibreOfficeを試用検討中です。

LibreOffice文書サムネイルは、OneDriveフォルダ内でも問題なく表示されます。

Office Word文書右とLibreOffice Writer文書左のサムネイル比較
Office Word文書(左)とLibreOffice Writer文書(右)のサムネイル比較

また、使用頻度が高いOffice Visio2010代替にDrawを使えるのもLibreOfficeのメリットです。さらに、Office文書はLibreOfficeでも編集できます。検討途中ですが今のことろLibreOfficeバージョン:6.0.5.2 (x64)に不満はありません。

クリーンインストールで新しく気が付いた点

起動不能の主因は、前投稿の前兆トラブル4「月1弱の起動失敗」であったと考えています。

しかし、この起動失敗時メッセージがBIOS関連であったため、現在のUEFI全盛環境では、たまには起こる事象だろうと安易に考えていました。また、BIOSからUEFIへいつか変更したいとも正直考えていましたので、きっかけ(トリガ)を待っていたとも言えます。

但し、BIOSからUEFIへの変更に対して、以前から使っていたTodoBackup Freeシステムバックアップでは対応できなかった可能性に気が付きました。TodoBackupは、Windows標準のバックアップソフトやシステムの復元機能よりも、個人的には信頼性が高いと評価しています。しかし、BIOSからUEFI変更時は注意が必要です。

TodoBackupで実行するタスクは、代々Cドライブ単独のシステムバックアップを行っていました。最新TodoBackup V11は、このシステムバックアップと、SSDやHDD丸ごとディスク単位のバックアップが別々のタスクで用意されています。

起動不能時に表示されたBCD関連のリカバリには、Cドライブ単独のシステムバックアップだけでは元々不可能だったのです。従って、今後はディスク単位バックアップを実行し、同様の起動不能に備えます。

また、初めてOneDriveを使うユーザには問題ない設定ダイアログが、既にOneDriveを利用中で今回のようなクリーンインストール後、再度ローカルPCと同期させる場合には注意が必要です。

サムネイル非表示問題のためにGoogle Drive同期へと1709で変更したOneDrive。クリーンインストールを機に、より使い勝手が良いOneDrive同期へ戻したところ、再同期ダイアログに設定ミスが生じやすいこと、ネット速度が遅い場合は、同期するファイルが多いだけに同期完了までに時間がかかることを実感しました。

OneDrive「再」同期の手順のまとめ

既にネットワークのOneDrive保存済みのPC同期ファイルと非同期ファイルがある場合、これらとクリーンインストールしたPCのファイルを同期させる時に、手順を間違うとPC内に全く同じファイルが同時存在したり、誤ってネットワーク内のOneDriveファイルを削除する場合があります。

これを回避するには、OneDriveを最初に起動した時に表示される「フォルダの選択」ダイアログで「非同期ファイルの☑を外す」必要があります。

OneDrive「再」同期手順
OneDrive「再」同期手順

デフォルトは、ネットワーク内の全OneDriveファイルをローカルPCへ同期する設定になっています。安易にデフォルトのままOKをクリックすると、全OneDriveファイルのダウンロードが始まります。

このOneDriveファイルは、ローカルPCのOneDriveフォルダに保存されますので、暫くすると、ローカルPCのOneDriveフォルダが、多くのネットワーク保存ファイルで溢れた状態になります。

そもそもOneDriveは、アーカイブスや普段あまりローカルで使わないファイル、また、これらに加えデスクトップ、マイドキュメント、ピクチャなど他PCとネットワーク共有すると役立つフォルダを保存する場所です。

デフォルトのままでは、全OneDriveファイルがローカルPCのOneDriveフォルダに保存されます。この状態で、アーカイブスや不要ファイルを削除すると、同時にOneDrive側も削除されてしまいます。幸い、OneDriveにもごみ箱があり、間違って削除しても復活させることができますが、手間です。

つまり、ネットワークOneDriveとローカルPCのOneDriveの制御を切り離すのが、最初に設定する「フォルダの選択」なのです。OneDriveも改版される度に設定ダイアログも変更され、従来から利用中のユーザには解りにくいことがあるので注意が必要です。

さらに、自動保存で設定できるドキュメント、ピクチャの保存先をOneDriveへ変更する場合には、事前に変更するローカルPCフォルダの場所を、OneDrive内へ移動しておくことも必要です。

私の場合は、マイドキュメントは依然として続くOfficeサムネイル非表示問題でOneDrive同期を使いません。従って、ピクチャフォルダのみをOneDriveへ移動しました。デスクトップは自動保存先の設定のみで同期します。

このように、設定順序や自動保存フォルダにより設定が異なることが現状OneDrive利用時の問題点であり注意点です。完成度は低いと言えるでしょうが、年2回の大幅更新で今後改善されるかもしれません。
※MCU開発と一番の違いは、このリリース完成度だと思います。

Windowsクリーンインストールや、OneDrive同期の方法を記載したサイトは数多くあります。
しかし、これらは新規クリーンインストールや初めてOneDriveを利用するユーザ向けなので、既存PCにトラブルが発生し、やむを得ずクリーンインストールする場合や、既存OneDriveユーザが再設定する場合とは異なる場合もあることに注意しましょう。

さらに付け加えると、Windowsクリーンインストール自体は、気を付けるのはライセンス再認証ぐらいで、アプリのカスタマイズ復活に比べ、手間も時間も数時間で済みます。
OSやユーザアプリインストール、各種カスタマイズ量が少ないなら、(クリーンインストールで半日から数日は完全に潰れますが)気軽にクリーンインストールしてもよい気もしました。

Windowsやアプリのカスタマイズ復活が未だ完全ではありませんが、MCU開発環境メインPCは復活しました。

QUALCOMM、NXP買収断念

中国当局の承認さえ得られれば買収成立という段階までこぎつけた米)QUALCOMMによるオランダ)NXP買収が、買収断念の発表となりました。

QUALCOMM、NXP買収断念
QUALCOMM、NXP買収断念

米国と中国間の貿易紛争の影響です。先の投稿で示した7月25日買収期限を過ぎても、中国側の承認を得られなかった結果です。

買収破断の結果、NXPは、自動車やセキュリティ分野の強化を、QUALCOMMは、5Gなどの無線通信事業を柱にすることを発表したそうです。

我々MCU開発者にこの結果がどう影響するか、本ブログで扱うLPC8xxやLPC111x、Kinetisデバイスにどう影響するか、数年後には明らかになるかもしれません。

組込み開発環境(IDE)更新と留意点

開発環境、特にマイコンソフトウェアの統合開発環境(IDE)は、Eclipseベースが主流です。Eclipseは、年1回6月にメジャー更新され、2018年はPhoton(光子)がリリースされました。本投稿は、開発環境の更新時期と留意点、対策などを示します。

主要開発環境の更新時期

主要開発環境の更新スケジュール
主要開発環境の更新スケジュール。Windows起動不能トラブルなどはいつでも起こりうる!。

主要開発環境の、メジャー更新時期を一覧にしました。1開発期間が3カ月~6カ月とすると、なにがしかの更新に出会うことは確実です。期間中は開発者なら、できれば環境更新などのトラブルの種を避けたいのが願いですが、現状は難しい状況です。

更新トラブルを避ける対策

これらの各種更新による色々なトラブルを避ける最も簡単な方法は、更新を一時的にせよ停止/延期することです。Windows更新を停止/延期するには、コチラに方法が示されています。

EclipseベースのIDEやルネサスCS+の場合には、更新通知があっても、開発者が許可しない限り自動的に更新しないので、Windowsに比べ安心です。但し、開発中の案件が直面しているバグや問題が、更新で解決される場合もありますので、直面問題が開発環境起因かどうかの判断が重要です。

また、Windowsは、SSD/HDDの故障などにより、いとも簡単に起動不能になります。これら更新トラブルや起動不能に対処するには、メイン開発環境とは別に、もう1つ別のバックアップ開発環境があるのが理想的です。

但し、この場合でも、メイン開発環境とバックアップ開発環境のデータ同期に注意を払わないと、折角のバックアップ環境もムダになります。

※弊社開発環境もWindows起動不能に陥り、自動修復やbootrecコマンドで「全く楽しくない修復」を試みていますが、未だ解決していません。

EclipseベースIDEの日本語化

EclipseベースIDEで日本語化を望む場合には、Pleiades(プレアデス)というプラグインが使える可能性があります。個人的には、開発時に使うコマンドやボタンはF5やF8など決まっているので、英語版でも問題は無いと思っていますが、気になる方は、バックアップ環境で試すのも一案でしょう。

マイコンテンプレート活用プロトタイピング開発(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が自動的に生成します。

NXP LPC80xの新しい動き

NXPからNFC機能搭載LPC8N04発表に続き、新たにLPC802とLPC804がLPC800 MCUファミリに追加されました。従来LPC8xxファミリのLPC810やLPC824から仕様の新しい変化が感じられます。

わずか30秒のLPC802評価ボードLPC804評価ボードの綺麗な動画を見るだけでもキーポイントが解ります。

LPC80x評価ボード価格(価格は全てDigiKey調べ)

仕様の変化

LPC8xxファミリのラインアップが下記です。

LPC8xx Family (Source:NXP)
LPC8xxファミリラインアップと新規追加LPC80x (Source:NXP)

15MHzコア速度

LPC8xxファミリは、32ビット ARM Cortex-M0+コアを用います。Cortex-M0+は、8/16ビットMCUの置換えが目的の低消費電力コアです。従来は最大動作周波数30MHzでしたが、LPC80xはこれが15MHzになっています。

最大動作のスペックで、運用時は必要に応じ消費電力を抑えため動作周波数を下げるのが常套手段ですが、LPC80xではこの最大スペックが初めから15MHzになっています。これは、性能と電力消費のバランスを見直し、32ビットコアならばこのスペックでも8/16ビットMCUに十分対抗できると判断したためと思われます。

8/16ビットMCU市場を32ビットMCUで獲得するには、「従来以上に消費電力の低さが必要」なのです。

EEPROM based Flash

従来はFlashと記述されたユーザプログラム領域が、EEPROM Flashに変わっています。
※LPC8xxファミリは、Flashがユーザプログラム領域、SRAMはユーザデータ領域、ROMはデバイスに始めから実装済みのNXP提供プログラム領域(簡単に言うとライブラリ)です。弊社LPC8xxテンプレートに使用例があります。
※LPC8N04の4KB EEPROMは文字通りデータ保存用のEEPROMデバイスをSoCでMCUへ内蔵したものです。LPC8N04はコチラの投稿を参照してください。

LPC802 and LPC804 Block (Source:Mouser Electorinics Japan)
LPC802 and LPC804 Block (Source:Mouser Electorinics Japan)

このEEPROM based Flashと明示の意味するところ、従来との差、目的など、現時点ではよく解りません。しかし、明示する訳があるハズです。判明次第、投稿予定です。

Programmable Logic Unit(PLU)内蔵

LPC804ブロック図では、ピンク色のProgrammable Logic Unit(PLU)、ユーザ変更可能なディスクリートロジック機能も内蔵しています(簡単に言うとPLD:Programmable Logic Deviceです)。

PLU Tool Schematic design (Stource:Part 3 PLU Tool Schematic design Video)
PLU利用のロジック例 (Stource:Part 3 PLU Tool Schematic design Video)

このPLUを使うと、WS2812 LEDやDCモータ制御、パターンジェネレータなどが簡単に実装できるようです。

レジスタプログラミング方式のサンプルソフト提供

ARMコアのソフトウェア開発は、CMSIS:Cortex Microcontroller Software Interface Standardで流用性を高める記述が標準的です。しかし、8/16ビットMCUのソフトウェアは、ハードウェアレジスタを直接アクセスするレジスタプログラミングが主流でした。このレジスタプログラミングを好む開発者も多いと聞いています。

LPC80xのサンプルソフトは、このレジスタプログラミング方式のCode Bundleで提供されます。

関連投稿:CMSIS構造や目的は、コチラの投稿の、“CMSIS”章を参照してください。

8/16ビットMCU市場置換えと開発者ニーズへの最適化LPC80xデバイス

8/16ビットMCUの市場置換えとその開発者ニーズを満たすという目的に、従来LPC8xxファミリよりもさらに最適化した32ビットMCU、これがLPC80xだと思います。評価ボードも低価格で提供中です。

また、日本時間、金曜午前0時~午前1時の1時間に、全4回のWebinarが予定されております。本投稿以降は、6月15日(金)と6月22日(金)の午前0時からです。英語ですが、使用スライドは4回全てダウンロードできますので興味がある方は登録し御覧ください。