2018マイコンベンダ最新ニュース

弊社マイコンテンプレートで扱っております主要マイコンベンダ、NXP、ルネサス、STマイクロエレクトロニクス、Cypress各社の2018最新ニュースとRTOS関連ニュースの中から、ブログ対象MCU関連の情報をピックアップしました。

NXP

MCUXpresso IDEの新バージョン10.1.1_606がリリースされました。また、LPC8xx向けのLPCOpenライブラリv3.02もリリースされましたが、リリースノートを見てもv3.01のバグ解消は未処理のようです。

そのためか、MCUXpresso IDE v10.1.1付属LPCOpenライブラリもv2.19のままで、v3.02添付はありません。近いうちにv3.02の動作を調査する予定です。

ルネサス

インターシル社と完全統合した新生ルネサス誕生(2018年1月1日)。アナログ関連で高いスキルを持つ旧インターシル技術がRL78マイコンへも導入されそうな気配があります。Cortex-M0/M0+コアとの競争に生き残るには、汎用RL78マイコンのアナログ強化、センサ内蔵が方策なのでしょう。

但し、開発環境CS+の先行きには不安要素もあります。6月末提供予定のe2 studioのAI利用無償プラグインはRL78もカバーされますが、果たしてCS+でも同機能がサポートされるのかが気掛かりです。

e2 studio新プラグイン
e2 studio新プラグイン(記事より)

STマイクロエレクトロニクス

既にEWARM、MDK-ARM、TrueSTUDIO、SW4STM32の4種IDEをSTM32マイコン向けに提供中のSTMが、TrueSTUDIOの開発元スウェーデンのAtollic社を買収しました。

現状のEclipseベースTrueSTUDIO無償版もコードサイズ制限はなく、弊社使用中のSW4STM32無償版サイズ制限なしと機能的には同じです。このTrueSTUDIOとSW4STM32を比較し、なぜAtollicを買収したのかを探りたいと思います。

Cypress

最新マイコン評価ボードで紹介しましたCY8CKIT-062-BLE PSoC 6 BLE Pioneer Kitが、サイプレスサイトからも購入できるようになりました。また、サンプルソフト(Code Examples)も豊富に提供されています。

E-ink液晶を使ったArduinoシールドは、汎用性が高そうなので興味を惹かれます。

RTOS

mbed OS 5の新しいバージョンMbed OS 5.7.2 がリリースされました。Amazon FreeRTOSなど、MCU用RTOSの普及も2018年のトレンドになりそうです。

まとめ

2017年の半導体ベンダランキング(速報値)が発表されました。NXPは第10位(前年9位)です。2016年MCUランキングは、NXP>ルネサス>STM>Cypressの順でした。NXPとルネサスがMCUシェアの1/3を占めるのは、今年も変わらないかもしれません。

例年に比べ2018年はMCU各社の動きが早いように感じます。EVや自動運転、コネクテッドカーがMCU開発の動きに拍車をかけているのは間違いと思います。

新たな動向としては、ソフトウエア開発環境の整備です。数億、数十億個とも言われるIoTマイコン時代では、現状のようにオーダーメイドでのソフト開発では時間が掛かりすぎます。より高速で効率的なソフトウエア開発ツールやライブラリ活用術が求められるような気がします。

Cortex-Mシリーズはセーフ、他はアウト

新年早々、Intel、AMD、ARMなどの制御デバイス製造各社に激震が発生しました。「CPU投機的実行機能に脆弱性発見」のニュース(Intel、AMD、ARMの対応Windowsの対応Googleの対応)です。

MeltdownとSpectre
MeltdownとSpectre(Source:記事より)

※投機的実行機能:制御を最適化するためのパイプライン化、アウトオブオーダー実行などの「現代的CPU」ハードウエアに実装済みの機能。

※脆弱性:ウイルスが入る可能性がある箇所のこと、セキュリティホールとも呼ばれる。言わばアキレス腱のような箇所。もっと知りたい方は、総務省サイトの基礎知識が良く解ります。

Cortex-Aシリーズも対象、Cortex-Mシリーズは対象外(セーフ)

パイプラインやアウトオブオーダーなどの最適化機能は、殆どの制御コアに搭載されています。従って、このニュースは深刻です。ハードウエアの深い部分の脆弱性だけに、ソフトウエアのOSやパッチなどで対応できるのか、個人的には疑問ですが、セキィリティ専門家に任せるしかないでしょう。

ARMのリアルタイム系Cortex-RやCortex-Aシリーズも対象:アウト!です。
一方、本ブログ掲載のCortex-Mシリーズマイコンは、これら投機的機能が実装されていないので今回は対象外、セーフでした。

IoT端末の脆弱性対応はOTA:Over The Air更新が必須

昨年12月3日投稿のCortex-Mを用いるIoTマイコンへも、Amazon FreeRTOSなどのRTOSが期待されています。今回のような脆弱性への対応には、無線通信によるソフトウエア更新:OTA機能が必須になるでしょう(ソフトウエアには、OSとアプリの両方を含んでほしいという願望も込みです)。

時々発生する自動車リコールも、ハード起因とソフト起因の両方があります。車の場合は、ディーラーへユーザが車を持ち込めば対応できますが、組込み制御の場合は、開発者自身が動作中の現場で対応するのが現状です。今回は、Cortex-Mシリーズはたまたまセーフでしたが、同様のセキュリティ事案への対策を練る必要があると思います。

と言っても、当面できるのは、現場でIDEやUART経由の直接ソフト更新か、または、コチラの記事のような(多分高価な)パッチ配布手段しか無いかもしれません。

RTPatch適用範囲
RTPatch適用範囲(Source:記事、イーソルトリニティ)

BLEとThreadソフト開発者必見動画

IoT通信規格のBLE 4.2とThread(802.15.4)両方をサポートするNXP)Kinetis KW41Z搭載の評価ボードを使ったBEL4.2とThreadメッシュ接続の開発Video(タイトルが以下Lesson 1~10)を紹介します。

Kinetis KW41Z Video Lesson Contents
Kinetis KW41Z Video Lesson Contents

BLEやThreadソフト開発者必見のLessons

内容、質ともに優れたVideoでMCUXpressoとSDKの使い方も良く解ります。特に興味深い内容とその出所が以下です。

  1. Bluetooth ClassicとBluetooth Low Energyの本質的な違い(Lesson 3、3分ごろ)
  2. Bluetooth ClassicとBLE間を接続するBluetooth Smart Ready(Lesson 3、6分ごろ)
  3. BLE接続の具体例(Lesson 3、19分ごろ)
  4. BLE/Thread接続に必要な知識(Lesson 3, 6)
  5. Threadが生まれた背景(Lesson 6、2分ごろ)
  6. Cortex-M0+/48MHz、512MB ROM、128KB RAM、FreeRTOSで実現するBLE/Thread IoT端末(Lesson  5, 9, 10)

BLEやThreadに関する情報は多くありますが、ソフト開発者の立場からは、本Lessonsが最も要領よくポイントをまとめています。

Kinetis KW41Z

KINETIS KW MCU FAMILY BLOCK DIAGRAM
KINETIS KW MCU FAMILY BLOCK DIAGRAM

Kinetis KW41Zの評価ボードは、以下の2種(Digi-Key価格)です。

低価格で有名なFRDM評価ボードですが、さすがに両プロトコル対応のKW41Z搭載ボードとなると$100以上します。Videoで使っているR41Z-EVALは、約$60と安く入手できます。但し、Lesson 10のBLEとThreadメッシュ切り替え接続の動作確認を行うには、同時に3台の評価ボードが必要です。

ThreadのみサポートのKW21、BLEのみのKW31もありますが、無線規格が乱立していて、どれが本命かを見極めるのが困難な現状では、両プロトコルサポートのKW41が安全でしょう。

API for IoT

MCUXpressoとSDKを使って、BLEまたはThread通信機能を持つIoT端末を開発する際に、プロトコルのどの部分の変更/修正が必要で、それがソース上のどこにあるか、全体の開発手順などはVideoを観ると良く解ります。

BLE Protocol Stack
BLE Protocol Stack

また、LEDなどのGPIO制御を行うSDKデモソフトとIoT通信の並列処理は、FreeRTOSを使って実現していることも解ります。簡単なIoT端末なら、このデモソフトに、外部センサ値をAD変換し、その変換データをクラウドのサーバーへIoT経由で送信する機能を追加しさえすれば、直ぐに開発できそうです。
※簡単なIoT端末は後述

BLEやThreadは、IoT通信の有力な候補です。しかし、IoTの通信プロトコルが何になるにせよ、IoT通信向けのAPIが決まれば、あまり気にする必要がない、というのが全Lessonを通しての私の感想です。

その理由は、デモソフト実装済みのGPIO制御はそのまま使えますし、FreeRTOSを使っていますので、外部センサ入力を定期的にADCする処理(ADCスレッド)と、ADC変換データをIoT通信APIへ出力する処理(IoT出力スレッド)の2処理を追加開発すれば良いからです。

ADCスレッドは、IoT通信規格には無関係です。一方、IoT出力スレッドは、Uart出力と同様のIoT APIが使える(用意される)と思います。NXP)LPC8xxマイコンのUart APIの例で示すと、Chip_UART_SendBlocking()が、Chip_IoT_SendBlocking()に代わるイメージです。IoT API利用条件が初期設定で満たされれば、ユーザは、通信速度や、通信プロトコルを意識せずにIoT通信を使えるようになると思います。

*  *  *

IoT通信規格が不確定な状況で、少しでも早くIoTやRTOSに慣れるには、R41Z-EVALは良い評価ボードです。また、FreeRTOSを使えば、48MHz動作のCortex-M0+、512MB ROM、128KB RAMで簡単なIoT端末が開発できそうな見通しもこれらLessonは、与えてくれました。是非、ご自分でご覧になってください。

簡単なIoT端末のイメージ

データ入力とGPIO出力を行うMCU端末で、IoT無線通信機能を備える。通信セキュリティを確保できるAES-128などの機能も備え、対象機器から取得したデータを安全にクラウド内のサーバーへ送信する。
サーバーは、対象機器データを人工知能を使って予測分析し、結果を端末へ送信する。
端末は、受信結果を基にLEDなどのGPIO出力を行い、オペレータまたはロボットが対象機器メンテナンス作業の手助けをする。

2016年MCUシェア1位はNXP

2016年主要マイコンシェア/販売額の記事がEE Times Japanに記載されました。2016年は、主要MCUベンダの買収が盛んでしたが、買収後で集計されているので、MCUの現状が示されています。

2016 MCU Share
2016 MCU Share(記事より)

車載半導体はNXPが2015年にルネサスを抜いて1位になっており、2016年のMCUシェア首位とともにNXPの躍進が明確になりました。

NXPの新IDE MCUXpresso

2017年4月時点の最新MCUXpressoIDE_10.0.0_344と、最終LPCXpresso_8.2.2_650の違いは、FreeRTOSタブが追加されたことのみです。残念ながらMCUXpressoのFreeRTOSもv8.0.1のままでした。

FreeRTOS V9はFreeRTOSサイトからダウンロードできます。が、これをMCUXpressoのv8へ手動で上書きインストールして問題なく動作させる自信はありません。FreeRTOS v9がNXPにより提供されるまで待つ方が、トラブルがなく得策と判断しました。
※MCUXpressoは、旧LPCXpressoプロジェクトフォルダがそのまま使えます。
※MCUXpressoに、PE: Processor Expertをアドインし旧Kinetis Design Studio代用とする方法は、調査中です。

マイコンテンプレートラインナップ

MCU Templates Lineup
MCU Templates Lineup

弊社マイコンテンプレートラインナップを、2016 MCUラインキング順に並べたのが上表です。おかげさまでテンプレートは、Runesas>NXP(Freescale含む)>Cypressの順に売れております。が、MCU順位5のSTM向けテンプレートもあれば、と思いました。

STMの場合、Cortex-M0/M0+を対象コアとすると、STM32F0/L0がテンプレートの対象です。しかし、このクラスのMCUへのRTOS適用によるROM/RAM大容量化や、IoT向けMCUの販売個数の増大などを考慮すると、より高性能なCortex-M3クラスも視野に入れた開発も必要か?と思っています。

CMSIS準拠でソフト開発すると、コア差はCMSISで隠蔽されるので、要求性能に応じたMCU選択が可能でクラス別けの必要もなくなります。また、RTOSでマイコンテンプレート相当が本当に必要か?という懸念もあります。

2016MCUシェアから、ルネサスの順位低下傾向が今後気になるところです。また、マイコンテンプレートについても、これらシェアの動きに合わせて、変わり続ける必要性を実感しました。

MCUXpresso概要と当面の開発方法

LPCXpressoとKinetis Design Studioが新しいMCUXpressoへ統合されました。Windows 10 Version 1703で動作確認したMCUXpressoの概要について示します。

MCUXpresso概要

MCUXpressoの概要は、コチラの4分程の英語Videoが良く解ります。ポイント抜粋すると以下になります。

MCUXpressoは、3つのツール:IDE、SDK、CFGから構成され、各機能が下記です。

  • IDE機能:ソースエディト、コンパイル、デバッグ。Eclipse 4.6ベース。ローカルPCで利用。
  • SDK機能:使用デバイスのAPI生成とサンプルソフト提供。クラウドで設定し、結果をIDEにダウンロードして利用。
  • CFG機能:使用ピン、動作周波数など設定。クラウドで設定し、結果をIDEにダウンロードして利用。
MCUXpresso Overview
MCUXpresso Overview

全てが1パッケージのローカルPCで機能した旧IDE(LPCXpressoやKinetis Design Studio)を、MCUXpressoで3ツール構成にしたのは、SDKとCFGをクラウド側で分離提供し、IDEを軽量化することと、CMSIS準拠の開発環境構築が目的だと思います。CMSISはコチラの記事を参照してください。

CMSIS準拠ならMCUハードとソフトの分離が容易になり、開発済みアプリケーション資産を少ない工数で別ハード移植や再利用が可能です。また、CMSIS仕様(CMSIS-COREや-DSPなど)が修正/更新されても、その内容は全てクラウド側のSDKとCFGツールに閉じ込めることができるので、常に最新CMSIS準拠のSDKとCFGを利用したソフト開発が可能です。
ARM Cortex M系のIDEは、今後この分離構成が流行するかもしれません。

注目点は、IDEではコードサイズ制限なし、SDKではFreeRTOS v9提供(LPCXpresso最終版はv8)、CFGでは電力評価やプロジェクトクローナーです。各ツールの概要を以下に示します。

MCUXpresso IDE

MCUXpresso IDE
MCUXpresso IDE

旧LPCXpressoとの差分は、FreeRTOSタブが新設されたこと位です。コードサイズ制限なしで、添付マニュアル類も判り易く、誰にでも使い勝手が良いIDEです。MCU開発は、従来のRTOSを使わないベアメタル開発から、RTOS利用ソフト開発へシフトしつつあり、このMCUXpresso IDEもこの流れに沿った機能が追加されました。

MCUXpresso SDK

MCUXpresso SDK Builder
MCUXpresso SDK Builder

SDK BuilderでBoard、Processor、Kitsなどの対象MCUパラメタを入力し、対応するSDKパッケージをクラウドで作成後、ローカルPCへダウンロードして使います。パッケージの中身は、APIとこのAPIの活用サンプル集です。但し、2017年4月現在は、FreescaleのMCUと2017年に発売されたNXPのLPC54000対応のものしか提供されていません。

その理由は、旧Kinetis Design Studio:KDSのProcessor Expert:PEの代替だからと推測します。MCUXpressoは、KDSのPE機能がSDKとCFGに分離してクラウドへ実装されました。PEをお気に入りだったユーザは、この点に困惑すると思います。

一方旧LPCXpressoのユーザのSDKはというと、これは従来のLPCXpressoに同胞されていたLPCOpenライブラリなどがそのままMCUXpressoにも実装されています。つまり、MCUXpressoは旧LPCOpenライブラリなどが従来同様使えます。

従って、LPC54000開発とKDSユーザ以外は、MCUXpresso SDKを使うことは、今のところありません。

MCUXpresso CFG

MCUXpresso CFG Settings
MCUXpresso CFG Settings

CFGも現状はSDKと同様、FreescaleのSDKとNXPのLPC54000対応のみが提供中です。

MCUXpressoのまとめと当面の開発方法

MCUXpressoは、旧LPCXpressoと旧Kinetis Design Studioを統合した新しいIDEで、現状「フレームワークは出来たものの、完全な移行完了とは言い難い」ものです。以下に特徴を示します。

  • IDEとSDK、CFGの3ツールに分離するフレームワークは、CMSIS準拠ソフト開発に適している。
  • KDSのPE代替機能をSDKとCFGに割振っている。2017年NXP発売のLPC54000開発にも使えるが、既存NXPのMCUはSDK、CFGともに未対応。
  • LPCXpressoとKDSの今後の更新は、期待できない。将来的には、NXP/FreescaleのMCU開発にMCUXpressoを使う必要あり。
  • LPCXpressoユーザは、当面SDKとCFGを使わずにMCUXpresso IDEを旧LPCXpressoと殆ど同じ使用法で使える。
  • KDSユーザは、MCUXpresso IDEとSDK、CFGを使い開発する方法と、当面はMCUXpressoにPEをプラグインし開発する方法の2通りの開発方法が取りえる。但し、PEの更新が期待できないので、将来はMCUXpresso SDK、CFGを使わざるをえない。

当面の目安としては、LPCXpressoユーザならば、既存MCUのSDK、CFGが提供されるまで、KDSユーザならば、PE更新が必要になるまで、でしょう。

もう1つの目安が以下です。Windows 10 1703更新に相当するIDEベースEclipse 4.6(Neon)の次版4.7(Oxygen)への更新は、2017年6月の予定です。IDEベース更新から約半年でこの4.7ベースの最新IDEが各社からリリースされるとすると、2017年末から2018年初め位にはMCUXpressoへの完全移行完了となる可能性があります。

MCUのIDEは開発スピードを左右する部分だけに、仕様変更や更新が定期的に発生する部分と、各社独自の部分を分離し、トータルでパッケージ化すると、以上で示したフレームワークが重要となります。開発者は、フレームワーク要素更新にも注意を払う必要があるでしょう。

RTOSへの備え:最終回、FreeRTOSサンプルソフト

FreeRTOSの要点を第1回~第3回でなるべく簡潔に解説してきました。簡潔にし過ぎて部分的には不正確な記述もあります。

しかし、正確さに拘って記述すると分(文)量が増え、参考書の和訳になりかねません。ポイントとなる点をざっと掴んで、開発環境で試し、参考書やマニュアルなどで開発者自ら考える、これにより新しい技術を本当に身に付けることができます。私は、これを食物の消化に例えます。

これには、出だしでつまずかず、多少間違えてもスムースに学習を進めること(=先ずは食べること)が大切です。食べたものの消化には、時間が掛かります。後で振り返ると、内容や詳細が解るということはよくあります。

開発者への「開発スピードを上げよ」というプレッシャーは、益々強まります。この状況で技術を身に付けるには、効率的に頭の中の整理、これこそが消化、が必須です。

最良の解説書は、「サンプルソフト+評価ボード」

ソフト開発は、つまるところ、ソースコード+評価ボードによる開発環境に勝る解説書は無いと思います。ソースコードを読み理解するのに最低限必要な知識と、実際のマイコンで使えるFreeRTOSサンプルソフトを示す、これが今回のRTOS関連記事の目的です。

そこで、第3回のタスク間データ通知、同期、排他制御の自作サンプルソースや、NXPオリジナルのLチカサンプルに、より解りやすい日本語コメントを付加した第1回のLチカサンプルソースを弊社サイトのRTOSページで公開します。

このサンプルソフトを使えば、より具体的に、日本語コメント付きソースコードを参照しながらRTOS習得や理解ができます。評価ボードで動作が即確認できますので、出だしのつまずき回避にも有効です。

FreeRTOSのAPIは、多くのパラメタを含みます。パラメタを変えた時に、どのように動作が変わるかをサンプルソースに修正を加え、評価ホードで試すことができます。これは、結構重要です。食べ方を自分で変えて消化することに相当するからです。また、このパラメタ変化を事細かに記述する術は(多分)ありません。

しかし実際の開発では、この事細かな事柄を知っていないと、トラブルやバグ回避ができません。このことが「サンプルソフト+評価ボード」が最上の解説書とする理由です。

FreeRTOSサンプルソフト

FreeRTOSサンプルソフトは、NXP製LPCXpresso824-MAXで動作します。RTOSへの備え:第1回に予定していたLPCXpresso812/812-MAX、LPCXpresso1114/5の動作確認結果が下表です。

FreeRTOSサンプルソフト動作確認状況
FreeRTOSサンプルソフト動作確認状況

LPCXpresso824-MAXで動作するソースを使い、IO割付と使用LPCOpenライブラリのみを変更し、他評価ボードへ適用しました。LPCXpresso812は824-MAXと同様に動作しますが、LPCXpresso1114/5は、Lチカ以外の動作確認ができません。また、LPCXpresso824-MAXもMutexは、希望の動作をしません。代用として2個のセマフォを使って疑似的に実現しました(Mutex2)。MutexとLPCXpresso1114/5の動作NG原因は不明です。原因が判明しましたら、弊社サイトへ記載します。

以上のように出来が良くありませんので、LPCXpresso824-MAXのFreeRTOSサンプルソフトのみをサイトで公開いたしました。

当初目的の全ボードでのFreeRTOS動作確認は出来ていませんが、これも、(かなり無理があることは承知の上で)評価ボード検証のあかしと考えることにします(Orz)。

※動作しない原因がお判りの方は、info@happytech.jpへまで教えていただけると助かります。

PSoC 6続報

MONOist組み込み開発ニュースに、PSoC 6と他社製品との性能、消費電力の比較が掲載されています(出典:「業界最小」の消費電力でセキュリティも、サイプレスがIoT向け「PSoC」を投入)。

PSoC 6の目標

「ある程度のシステム制御ができる性能+低消費電力+セキュリティ、これらの同時実現」というPSoC 6の目標のために採用された40nmプロセス技術とデュアルARMコアにより、PSoC 6の他社比、優れた性能が解ります。

PSoC 6 Comparison Table1
PSoC 6 Comparison Table1(記事より)
PSoC 6 Comparison Table 2
PSoC 6 Comparison Table 2(記事より)

青字が性能同等、または、より優れた項目を示しています。PSoC 4でも採用中の高性能CapSenseやアナログコンポーネント、多くのGPIO数、そして100MHz動作のCortex-M0+、ピーク時257DMIPSなど、弊社ブログ対象の従来MCUの性能枠を大きく超えるものです。

1MB ROM、288KB RAM、8KB キャッシュの意味

ディアルコアで、1MB ROM、288KB RAM、8KB キャッシュものリソースを持つPSoC 6制御には、RTOSが必要になると思います。MCU開発も、よいよOS必須時代になるのでしょうか?

PSoC Creator News and InformationにNew FreeRTOS on PSoC 4 port が掲載されています(PSoC Creator 4.0のStart Pageからもアクセス可能)。弊社マイコンテンプレートで使ったCY8CKIT-042 評価ボードへも適用できそうです。ARMコアなので、mbed OS 5も気にはなりますが、FreeRTOSですので、RTOSへの備え記事が、理解に有効に活用できるでしょう。

弊社自作FreeRTOSサンプルソフト状況

RTOSへの備え記事は、LPCXpresso 824-MAXを使ってFreeRTOSサンプルソフトを自作しています(Lチカ、Q-通信、セマフォ同期、ミューティックス排他制御の4種)。

この自作サンプルを横展開してLPCXpresso 812/812-MAX、LPCXpresso 1114/5へ適用する予定でした。しかし、LPCXpresso 824-MAXで動作するサンプル(勿論GPIOとLPCOpenライブラリのみ変更)が、Lチカを除いて他の評価ボードでは動作確認ができないのが現状です。

原因が(僅か数十行の)自作サンプルにあるのか、それとも、それ以外かの見極めも、結構大変です。FreeRTOSもv9では、スタティックなセマフォ、ミューティックス割付ができるなど改良が進んでいるのでデバッグには良さそうですが、現状のv8は未だ非対応です。

LPCXpresso 824-MAX版だけでもFreeRTOSサンプルソフトを無償リリースするか、それとも、当初の予定どおり全評価ボード対応として問題解決後リリースするか3月末を目途に検討中です。

RTOSへの備え:第3回、タスク間データ通知、同期、排他制御

各タクスが独立=バラバラで動作する場合には、第2回に示したスケジューラーのRunningの切り替えのみでもRTOSを使ったマルチタスクとしては十分機能します。実際、LPCXpresso付属のfreertos_blinkyサンプルソフトを理解するには、第2回までの説明で十分です。

しかし、あるタクスの結果を待って別タクスが動作するような場合には、結果の待ちや通知、タクス間の同期が必要です。今回は、RTOSがどのようにこれらタクス間のデータ通知、同期を行っているかを解説します。

これらの技術を習得すれば、殆ど(7割以上)のソフト開発をFreeRTOSでカバーできるようになります。つまり、ここがRTOS習得の山場と言っても良いでしょう。少し量が多いのですが、ご勘弁を…。

初めに、状態遷移図のSuspendedによるタスク間の待ちや同期を行う仕組みを説明し、次に具体的な方法を説明します。

Suspendedの役目

第2回で示した状態遷移図のSuspendedが、タスクの待ちを実現します。

タスクAとタスクB間の通知や同期には、タスク実行中に別タスクの結果を待つことが必要となります。タスクAに待ちが発生した時は、vTaskSuspened()のAPIを使ってSuspendedへ移行し、タスクBの結果を受け取ると、RTOSがvTaskResume()のAPIを使ってタスクAをReadyへ戻します。Suspended中も第2回で示したBlocked同様、MCU能力を消費しませんので、待ち期間中も他のタスクがRunningすることができます。

以上がSuspendedによるタスクの待ちや同期を行う仕組みの簡単な説明です。Blockedと似ていることが解ると思います。違いは、BlockedがRunningからのみ遷移するのに対し、どの状態からでもSuspendedへ遷移できる点です。次にRTOSでの具体的な方法を示します。

FreeRTOSのタスク間データ通信、同期、排他制御の方法

RTOSを使わない通常ソフトの場合は、ユーザが定義するメモリ経由で、変数や結果の通知をユーザ自身が行います。また、割込みにより同期が可能です。弊社マイコンテンプレートもこの方法を使っています。

FreeRTOSを使うソフト開発の場合は、
タスク間のデータ通信は、           Queues:キュー、
タスク間の同期は、                      Semaphore:セマフォ、
タスク間の排他制御は、               Mutex(=mutual exclusion):ミューティックス、
を使います。

Queues:キューによるタスク間データ通信

FreeRTOSは、Operating SystemですのでMCU資源のユーザによる直接アクセスを嫌います。メモリなどの直接表現ではなく、論理的にメモリを繋げたQueues:キューという手段で、通信という方法によりタスク間データ送受信を行います。FreeRTOSのタスク間通信Queues:キューは、FIFO:First In First Outとして使います。

FreeRTOS Task Communication
FreeRTOS Task Communication

タスクAからタスクBへキュー経由でデータ通信する例です。受信タスクBは、xQueueReceive()でキューからのデータを受信します。このキューにデータが無い時のみSuspendedへ移行します。Suspended中は、キューデータ有無をRTOSが監視し、データが生じた時はタスクBのxQueueReceive()以降の処理が実行されます。

つまりタスクBは、xQueseReceive()の記述のみでデータ受信処理が実現できます。データ有無による待ち制御は全てRTOS側で行いますので、タスクBは受信処理のみの簡単記述ができます。

キューにより送受信タスクの処理は完全に分離されますが、処理結果のデータは、FIFOなので順序が保たれて通信されます。

Semaphore:セマフォによる同期

FreeRTOSのSemaphore:セマフォは、バイナリセマフォです。割込みによる同期を図示します。

FreeRTOS Semaphore
FreeRTOS Semaphore

割込み処理は、割込みハンドラーと割込みサービスルーティン:ISRの2つで構成します。割込み発生時、優先順位に応じてMCUハードウエアが自動的にCallするのが割込みハンドラー、実際の割込み処理を記述する部分がISRです。※図では、Interrupt!がハンドラー、TaskがISRです。

FreeRTOSの割込み同期は、ISRで割込み発生をxSemaphoreTake()で待ちます。割込み発生時、ハンドラーで割込みフラグクリアなどの処理後、xSemaphoreGiveFromISR()で動作許可(図赤丸)を与えます。この動作許可によりISRのxSemaphoreTake()以降の割り込み処理が実行されます。これが割込み同期の実現方法です。

ISR処理後、動作許可は消えます。再びハンドラーが動作許可を生成するまでISRはSuspendedになります。

Mutex:ミューティックスによる排他制御

FreeRTOSのMutex:ミューティックス排他制御を図示します。

FreeRTOS Mutex
FreeRTOS Mutex

ミューティックスの場合は、セマフォと異なり初めから動作許可(図赤丸)があります。この動作許可を初めにTakeしたタスクAのみが共有リソースへアクセスできます。タスクAのアクセス中は、動作許可がないタスクBはxSemaphoreTake()でSuspendedになります。タスクAのアクセス終了後、動作許可をxSemaphoreGive()で放棄するので、今度はタスクBが共有リソースへアクセスできます。これが排他制御の実現方法です。

つまり、動作の許可を示すバイナリセマフォを同期で使う時はセマフォ、排他制御で使う時はミューティックスと呼ぶだけで、使用するAPIは、どちらもxSemaphoreGive()とxSemaphoreTake()です。
違いは、セマフォ同期のvSemaphoreCreateBinary()では、初期値:動作許可が無いこと、ミューティックス排他制御のxSemaphoreCreateMutex()では、初期値:動作許可が有ることです。

まとめ

FreeRTOSのタスク間データ通信、同期、排他制御の方法を示しました。これら待ちの制御は、スケジューラーのタスク管理Suspendedが重要な役割を果たします。

データ通信は、Queue:キュー作成後、このキューへタスクからデータSend/Receiveという通信で実現します。同期と排他制御は、Semaphore:セマフォ作成後、このセマフォへタスクから動作許可Give/Takeにより実現します。

タスク側の記述は、データのキューSend/Receive、セマフォの動作許可Give/Takeという単純なFreeRTOSのAPIのみで良く、関係タスクの状況に応じて即Runningにするか、あるいはSuspended→Ready→Runningにするかの面倒な制御は、全てRTOS側が行います。従って、ユーザタスクは、必要処理の簡単記述ができます。

今回登場したFreeRTOSのAPIが以下です。

キューデータ通信:          xQueueCreate()、xQueueSend()、xQueueReceive()
セマフォ同期:                  xSemaphoreCreateBinary()、xSemaphoreGiveFromISR()、xSemaphoreTake()
ミューティックス排他制御:xSemaphoreCreateMutex()、xSemaphoreGive()、xSemaphoreTake()

上記と、第2回で示したFreeRTOSのAPIとを加えても20個弱のAPIでFreeRTOSが使えます。これらのAPIとFreeRTOSスケジューラーを理解していれば、FreeRTOS以外でも慌てずにRTOSソフト開発に着手できると思います。

最終回の次回は、ソースコード+評価ボードの開発環境に勝る解説書はない、という話をする予定です。

RTOSへの備え:第2回、タスク管理

RTOSが複数ユーザタクスの無限ループを回し、タクスの優先順位に応じてMCU実行時間を振り分けること、その利点を第1回で示しました。RTOSは、タスクを処理単位として扱います。今回は、RTOSがユーザタスクをどのように扱うかを解説します。タスク自身は既に出来上がったものと仮定します。

FreeRTOSによるユーザタスクの扱い方

ユーザタスクをFreeRTOSで処理してもらうには、最初にタスク登録が必要です。登録済みの複数タスクは、RTOSにより以下のように4つの状態で管理されます。

FreeRTOSへのタスク登録APIが、vTaskCreate()、登録済みタスクの削除APIがvTaskDelete()です。FreeRTOSは、優先順位の高いタスクをRunningにします。従って、登録後、タスクを即実行するのではなく、他タスクとの優先順位判定をReadyで行い、その結果で実行状態にします(図示の太線部分)。

FreeRTOS Task States
FreeRTOS Task States

優先順位は、登録APIのvTaskCreate()パラメタで指定できますが、デフォルトは全て同順位です。同順位タスクは、TICK_RATE(タスク切換え時間)単位に実行状態を切り替えるラウンドロビン方式です。実行後は、再びReadyに戻されます。

例えば2タスクのみが登録された場合、LPCXpresso824ボードなら2タスクを1ms毎に交互に切り替えながら実行します。ユーザ側からは、2つのタスクが並列動作したように見えます。これが最も簡単なRTOSマルチタスク処理の説明です。

デフォルト優先順位の変更に使うAPIがvTaskPrioritySet()、vTaskPriorityGet()です。更にReadyやRunningのタスクに対して、図示のAPIでSuspendedやBlockedへも遷移可能です。

これら制御を行うのがスケジューラー、スケジューラーが行う制御をタスク管理と呼びます。スケジューラーをRTOSカーネルと呼ぶこともあります。FreeRTOSスケジューラーは、4個の状態でタスクを管理しますが、数がもっと多いRTOSの例もあります。
※例えば、RL78用のRTOS:RI78V4は、6個の状態遷移を持ちます。

Blockedの役目

さてここで、第1回で示したLED点滅タスクの無限ループ内にあるvTaskDelay()を解説します。

vTaskDealy()は、タスクをBlockedへ遷移させます。そして設定時間の停止後、Readyへ戻します。つまりBlockedの間は、MCUを使わないため他タスクがRunningになりうるのです。これが、RTOSを使っても、各タスクに通常ソフトと同じように無限ループを記述できる非常に重要な仕組みです。

RTOSを使わない通常ソフト記述の場合、無限ループは、文字通りそのループ内に留まりMCU能力を使い続けます。しかしRTOSは、vTaskDelay()によりソース上は無限ループでも、MCUを使いません。これによりマルチタスク処理ができるのです。

RTOSにより再びRunningに戻ったタスクは、vTaskDealy()の後の処理から実行されます。タスク側からは、指定時間の停止後に継続して実行しているように見えます。

スケジューラーの状態遷移図は、ユーザタスク側からみた状態です。Running以外はMCUを使わないNot Running (super state)ですが、スケジューラー自身のために(ほんの少し!)MCUを使います。このスケジューラーを起動するAPIが、RTOSのmain()最後にあるvTaskStartScheduler()です。

スケジューラー自身は、実は最高プライオリティを持つタスクです。従ってユーザタスクよりも優先的に処理されますが、実態はユーザタスクと変わりません。

まとめ

今回はRTOSのタスク管理を説明しました。スケジューラーの優先順位判定により複数のタスクRunningが切り替わりマルチタスクを実現すること、BlockedによりRTOSでのタスク記述に通常ソフト記述と同様の無限ループを使えることを示しました。

この回までに登場したFreeRTOSのAPIが下記です。FreeRTOS APIレファレンスマニュアルで詳細が解ります。
vTaskCreate()、vTaskDelete()、uxTaskPriorityGet()、 vTaskPrioritySet()、vTaskDelay()、vTaskStartScheduler()、
vTaskSuspend()、 vTaskResume()。
vTaskSuspend()、 vTaskResume()の2つは、次回解説予定。

RTOSへの備え:第1回、RTOSの必要性

IoT MCUのソフト開発は、RTOS:Real Time Operation Systemが必要になると思います。IoT向けでない通常のMCU開発でも通信UART制御は鬼門です。IoT MCUの通信プロトコルが何に決まるかは今のところ不透明ですが、UARTに比べて複雑な通信処理になることは明らかです。

この対策として、IoT向けMCUのRTOSを数回に分けて解説していきます。連載記事を読めば、RTOSが理解でき、いざIoT MCUで実際にRTOSを使わなければならなくなった時にも慌てずに対処することができます。

背景

本ブログは、IoT向けMCUのRTOS、FreeRTOSmbed OS 5を記載してきました。これらRTOS関連の資料は、少なからずあります。しかし、1から10まで書いている教科書的な内容で、参考書としては優れていますが、残業時間の制限が厳しい昨今、実務的にはもっと効率的に習得したいのが本音です。

そこで、最低限のRTOS知識とMCU評価ボードを使って、手っ取り早くお金をかけずにRTOSを習得することを目標とします。この目標に沿ってブログ記事を作成します。このための開発環境が下記です。

使用RTOS:FreeRTOS(NXPのIDE:LPCXpresso無料版に付属)
MCU評価ボード:NXP LPCXpresso812またはLPCXpresso812/824-MAXまたはLPCXpresso1114/5
※記事ではFreeRTOS v8.0.1、LPCXpresso v8.2.2、LPCOpen v2.19(いずれも2017年2月最新のLPCXpresso無償版に付属)とLPCxpresso824-MAXを使います。
FreeRTOS Documentationにある“Mastering the FreeRTOS Real Time Kernel – a Hands On Tutorial Guide”が参考書としてお勧めです。

MCUのLPC812/824、LPC1114/5で動作するFreeRTOSがポーティング済みで、かつ秋月電子などで低価格で入手性が良いMCU評価ボードで動作確認できることが選定理由です。

LPCXpresso824-MAX
LPCXpresso824-MAX

因みに、LPCXpresso812/1114/1115評価ボードで動作する弊社マイコンテンプレートも販売中です。このマイコンテンプレートによる従来ソフト開発と、FreeRTOSによるソフト開発の違いなどでRTOSの特徴を浮き彫りにします。

RTOSの必要性

評価ボード実装済みのLEDを点滅させるいわゆる「Lチカ」サンプルソフトを、FreeRTOS利用時のソースの一部(左側)と、RTOS未使用の通常ソフト記述(右側)を示します。最大の違いは、無限ループの数です。

RTOS LED sample
RTOS LED sample(2タスクのみ抜粋)

FreeRTOS記述の場合、1個のタクス(≒ユーザ処理単位)で1個の無限ループを持ちます。一方、通常ソフト記述の場合は、全体で1個の無限ループのみです。1個の無限ループ内で様々なユーザ処理を行うため、ループ内の1処理時間の長さ、短さ、待ちがその他の処理へ影響を与えます。

RTOSを使う最大の利点は、1つのタクス実行時間の影響が、他のタクスへ及ばないことです。

このおかげで、あたかも1つのMCUを占有するかのようにユーザタスク記述ができます。従って、1個のタクスが、1個の無限ループを持つのです。複数のタクスへ優先順位に応じて実行時間を振り分けるのは、RTOSの役目です。

ユーザタクスは、他のタクスのことを気にせずに記述できるため、シンプルな処理になりタクス単位の可搬性も向上します。

RTOSでのユーザタクス記述は、通常ソフト記述と何ら変わることはありません。1無限ループ内にシンプルな処理を記述すれば良いのです。ただし、RTOS利用のオーバーヘッドとして、タクスの登録や優先順位の設定は別途必要となります。

要はRTOS APIを追加するだけ!

RTOSのLチカサンプルソースは、FreeRTOS APIとLPCXpresso API、残りがC言語の3構成です。

LPCXpresso APIとC言語は、通常ソフト記述時に使うものと同じです。FreeRTOS APIは、APIの頭に必ずx…、v…、ux…などが付いています。これらの接頭語は、FreeRTOS以外のRTOSでも同様です。RTOSユーザタスクの記述は、通常ソフトの記述に、これらRTOS APIが加わったのみです。

従ってFreeRTOS APIの使い方を理解すれば、FreeRTOSに限らず他のRTOSへも応用可能です。使用頻度が高いFreeRTOS APIの使い方を習得すれば、基本的なRTOSユーザタスク開発ができると思います。この方法でIoT MCUにRTOSが適用された時でも、慌てずに備えることができます。

まとめ

今回は、RTOSの利点を説明しました。RTOSが複数ユーザタスクの優先順位に応じてMCU実行時間を振り分けるので、個々のユーザタスクはシンプルで可搬性に優れた記述ができます。

IoT MCUの通信処理はUARTに比べ複雑です。この複雑さは、再送データ数や外来ノイズなどの通信環境により様々に変化します。RTOS無しの通常ソフトでこれらに対応するには複雑すぎると思います。

この対応には、RTOSが期待できます。しかし、RTOS習得には初期段階で手間と時間が掛かるため、実務的で手軽に習得できると筆者が思う1習得方法を示しました。

今後も、FreeRTOSのポイントをできるだけ簡潔に説明していきます。詳しく知りたい方は、お勧め参考書などを参照してください。