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つは、次回解説予定。

Qualcomm/NXP合併完了は2017年末?

「Qualcomm/NXPの合併に立ちはだかる米中政府の壁(前編後編)」という記事が掲載されました。

合併が2017年末完了予定から延びる可能性があるそうです。私には記事内容は、イマイチ解らないのですが、NXPの2017年MCU開発計画に影響しないことを願っています。

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のポイントをできるだけ簡潔に説明していきます。詳しく知りたい方は、お勧め参考書などを参照してください。

NXPの新統合開発環境MCUXpresso

LPCマイコンとKinetisマイコンの2つを同時サポートする新しい統合開発環境(以下IDE)、MCUXpressoが2017年3月リリースに向けて開発中です。

LPCXpressoとKinetis Design StudioをMCUXpressoに一本化

Freescaleを買収したNXPのLPCマイコンにはLPCXpresso、旧FreescaleのKinetisマイコンにはKinetis Design Studio(以下KDS)が、それぞれの開発用IDEとして提供されてきました。どちらもEclipseベースのIDEなので、いつかは一本化されると思っていました。

新しいMCUXpressoのサポートマイコンリストは、コチラからダウンロードできます(ログイン必須)。Product Familyでフィルター操作をすると、下例のようにお使いのMCUの詳しい状況が判ります。

LPC1114/5 Support状況
LPC1114/5 Support状況

本ブログ対象のLPC1114/5とKinetis K/Lは、2017年3月にサポートされる予定です。

MCUXpressoもEclipseベースIDEで、無料版でもコードサイズ制限なしで使えるなど、数々の嬉しい特徴を備えています。LPCXpressoとKDSの最も異なる部分、API生成/提供方法がMCUXpressoでどのようになるかは、今のところ不明です。

IDEのAPI生成/提供方法

マイコンテンプレート使用中IDEのAPI生成/提供方法をまとめました。現状は3種類です。

API生成/提供方法
API生成/提供方法 概要 使用IDE
別ライブラリ IDEに別途APIライブラリを追加し利用 NXP:LPCXpresso(LPCOpen)
API生成ツール IDEで周辺回路を設定しAPI生成 Freescale:KDS

ルネサス:コード生成

SCH生成ツール IDE回路図で周辺回路を設定しAPI生成 Cypress:PSoC Creator

API生成ツールを使う方法は、周辺回路の知識が豊富でないと設定しにくいので、SCH生成ツールのCypress:PSoC方式が、動作イメージが把握し易く使い勝手が良いと個人的には思います。また、シンプルなのは、別ライブラリ提供のNXP:LPCXpresso方式ですが、MCUXpressoがこの方式になる可能性は、KDS統合も考えると少ないと思います。

いずれにしても来年は、この新しいMCUXpressoでNXPとFreescaleのマイコンテンプレートを、6月末を目途に作り直す予定です。興味がある方はすぐに現状マイコンテンプレートを購入されても、ご購入後1年以内のテンプレート更新は無償で行いますのでご安心ください。

米Qualcomm、NXPを300億ドルで買収か?

2015年、Freescaleを買収したNXPを、スマートフォンで有名なクアルコムが300億ドル以上で買収するかもしれないというニュースが飛び込んできました。

記事によると、買収目的は、スマホ市場の成長が停滞しつつあるので、組込と車載市場へ参入することで、買収が成立すれば、半導体業界史上、最大規模のM&Aになるそうです。

クアルコム製品でスマホによく用いられているSnapdragonを使ったシングルボードコンピュータ:SBCは、チップワンストップのコチラで参照できます。

個人的観測ですが、このところNXPに限らずマイコンベンダーの新製品開発が鈍っている気がします。IoT無線規格の見極めや、Eclipse Neon対応かなと思ってきましたが、業界再編の可能性も影響しているかもしれません。

新生NXPマイコンラインアップ

NXPがFreescaleを買収後、新生NXPのARMコアMCU製品ラインアップが一目で解る図を見つけたので掲載します。
出典は、組込みシステム向けコンテンツ・プロバイダ)インスケイプ様のマガジンVOLUME.13:「さらなる高みへ。新生NXPのマイコン戦略に迫る MCU約1,100ラインアップ。シナジー効果の最大化へ」です。

NXP+FreescaleのARM Cortex MCUラインアップ

NXPサイトは、NXPのLPCマイコンと旧FreescaleのKinetisマイコンがそれぞれ別ページで示されるので、経営統合後のARM Cortex MCU製品ラインアップが分かりにくいのが現状です。

既存ユーザにはページ分離記載で問題ないでしょうが、以前記載した今後を予想するには、下図が解りやすいと思います。

NXP ARM Cortex MCU Lineup
NXP ARM Cortex MCU Lineup(記事より抜粋)

左側の汎用MCUでは、Cortex-M0/M0+でLPC800、LPC1100/1200とKinetis Lシリーズが競合しています。IDEも、それぞれのMCU対応にLPCXpressoとKinetis Design Studioの2種を提供中です。
一方、右側の特定用途MCUでは、Kinetisシリーズにより製品補完がされたことが解ります。

出典記事に、各MCUの詳しい特徴が解りやすく記載されております。

統合により、NXPは、ARMコア提供数は(恐らく)世界最大で、MCUコアのデファクトスタンダードCortex MCUのリーダーです。今後の動向が気になります。

CortexーM0/M0+対応マイコンテンプレート

弊社は、コスト重視で8/16ビット市場の置換えを狙う32ビットMCUコアCortex-M0/M0+を使ったLPC8xx、LPC111x、Kinetis Eに対してマイコンテンプレートを販売中です。動向によっては、このラインアップも変わるかもしれません。

※Kinetis Lシリーズは、Kinetis Eとソフト、ピン互換性があります。Kinteis EテンプレートのLシリーズへの適用は、弊社へお問合せください。

解説:マイコン評価ボード

マイコン開発には、各社が低価格で提供している評価ボードは必須です。
弊社マイコンテンプレートも、各ベンダの評価ボードで開発しています。この評価ボードを解説します。

採算度外視の低価格、高信頼ハードウエア

ソフト開発者に「確実に動くハードウエア」を「低価格」で提供する、これが評価ボードです。

マイコン開発には、「専用」のソフトウエアと「専用」のハードウエアの両方が必要です。そして片方のデバッグには、もう片方にバグが無いことが必須です。つまり、ソフトデバッグには、バグなしのハードが必須なのです。そこで、バグなしで確実に動作する「汎用」ハード、これが各ベンダ提供の評価ボードです。

但し、専用ハードがいずれ開発されるので、汎用の評価ボードは低価格とならざるをえない運命です。高ければ誰も買ってくれないからです。しかし開発者にとっては、以下のように優れた教材と言えます。

  1. ソフト開発者が、専用ハードが出来上がる前にソフトデバッグ可能な環境を自由に構築できる
  2. ハード開発者が、そのまま専用ハードにも使える高信頼ハード設計を学べる
  3. マイコン初心~中級者が、ベンダ標準のデバッグ技術で低価格な開発環境を使って自習できる
  4. 評価ボードは、各ベンダフォーラムで多くの情報が記載されており、適用サンプルソフトも多い

ターゲットMCU、デバッグインタフェース、拡張コネクタの3構成

評価ボードは、ターゲットMCU、デバッグインタフェース、拡張コネクタの3つから構成されます。

NXPの評価ボード:LPCXpresso LPC812とルネサスのRL78G13-Stick、CypressのCY8CKIT-042 の例を示します。

LPCXpresso LPC812構成
NXP LPCXpresso LPC812構成
RL78G13-Stick構成
Runesus RL78G13-Stick構成
CY8CKIT-042構成
Cypress CY8CKIT-042構成

ターゲットMCU

ターゲットMCUとは、開発MCUそのものの部分です。残りのデバッグインタフェースと拡張コネクタは、ターゲットMCUが異なっても同一です。

拡張コネクタ

最近はArduino用シールドコネクタを拡張コネクタに用いる評価ボードが多いです。これは、市販Arduinoシールドの種類が増えたため、上手く探せれば汎用の評価ボードに複数のArduinoシールドを拡張コネクタで接続し、専用ハードに近い、いわば「疑似専用ハード」を市販品のみで作れます。ボード単位のハード部品化がもたらした結果と言えます。

個人的には、シールドよりも、mbed – Xpresso Baseboardの方がより低コストで疑似専用ハード実現ができると思っています(こちらに詳しく記載しました)。

デバッグインタフェース

デバッグインタフェースは、IDEデバッグ機能を使うために必要な部分で、ターゲットMCUのシリアル入出力とパソコンUSBを変換する機能もここに含みます。この機能専用のマイコンが実装されることが多くなりました。このマイコンでデバッガ機能も代行するので、別途デバッガを購入せずにソフトデバッグが可能です。

MCUがARM Cortex-M0/M0+の場合には、ARM標準のCMSIS-DAPでMPUコアをデバッグできるインタフェースも実装されます。CMSIS-DAPはこちらの記事も参照してください。

CMSIS-DAPは、ターゲットMCUとデバッグインタフェースを切り離した後に、ソフトデバッグする時、別途ARM専用デバッガが必要ですが使えます。このように、1つの評価ボードで複数のデバッグ方法が使えるのも特徴です。

ARM系コアの場合は、ベンダ評価ボードもほぼ同じ構成で、ARM専用デバッガを1台持っていれば、ベンダ各社の評価ボードをまたがっても使えるのがメリットです。マイコン開発のデファクトスタンダートになりつつあります。

一方、デバッグインタフェースをE1コネクタでしか持たないルネサスのCPUボードをデバッグする際は、別途E1デバッガを接続しないとデバッグができません。この点は、Cortex-M0/M0+コアのMCUと比べるとコスト的に劣ると言えるでしょう。

Runesus QB-R5F104LE-TB構成
Runesus QB-R5F104LE-TB構成

デバッガ機能なしの統合開発環境:IDEの背景

シールドなどのボード単位の部品化が進んだ結果、専用ハードは、もはや既存ハードを組み合わせて、その小型化のみを行う設計、つまり専用基板化が主な開発内容と言えるかもしれません。

同様に、ソフト開発もベンダが、多くのライブラリを提供することで、専用ソフトをライブラリの組合せで完成できるレベルを目指しているようです。IDEにデバッガ機能がないArduino IDEなどは、この現れのような気がします。

ハードとソフトのオープンソース

ハード版オープンソースとしてArduinoシールドコネクタを持つ既成基板は、増えつつあります。

オープンソースを活用したソフト開発は、Unix系では当たり前です。この流れがマイコンソフトへも徐々に浸透する可能性を感じています。この場合、ハードの専用基板化開発に相当するのは、RTOS適用や弊社のマイコンテンプレートになるかもしれません。

マイコンIDE更新

扱うMCUデバイスの追加、WindowsやiOSなどのOS変更、Eclipseそのものの変更、バグ修正など様々な要因によりマイコン開発環境:IDEの更新は発生します。今回は、マイコンIDE更新について解説します。

更新通知と更新理由

マイコンアプリケーションソフト開発中ならば、リスクが増える可能性もあるIDE更新は避けたいものです。
このため「開発者が更新をするか否かを選択」できるのがマイコンIDEの特徴です。Windowsと大きく異なる点ですね。

更新判断には、「更新が発生」したか、「更新の理由」は何か、この2つを知る必要があります。この情報をIDEのWelcome画面のWebリンクで教えてくれるのがEclipseベースのIDEです。NXPのLPCXpressoの例を示します。

LPCXpresso Welcome page
LPCXpresso Welcome page

赤矢印のリンク先をみると、最新版IDEと、変更内容などが解ります。使用中のIDEと版数が異なる場合には、この内容を読んで更新判断ができます。新旧LPCXpressoは、緑囲いで示した版数毎に別フォルダへインストールされるので、IDE更新リスクがフォルダ内に閉じ込められるので安心です。

また、NXPに買収された旧FreescaleのKinetis Design Studio: KDSの例が下図です。Welcome画面に加え、Help>Check for Updatesで更新確認と新版インストールまでバックグラウンドで可能です。この機能は、LPCXpressoにはありません。

Kinetis Design Studio Check for Updates
Kinetis Design Studio Check for Updates

但し、私の環境では、ベースとなるEclipseのメジャー更新が関係しているのかもしれませんが、KDS V3.1からV3.2への更新ができませんでした。V3.2更新は、別途インストーラで可能です。やはりIDE更新確認ツールがあっても、時々サイトでIDEの最新版確認は、必要だと思いました。

また、CypressのPSoC Creatorは、Update Managerツールで更新確認とインストールができます。旧版はアーカイブ保存されるので、万一最新版にトラブルが発生しても安心です。

Cypress Update Manager
Cypress Update Manager

以上3社のマイコンIDEは、どれもEclipseベースのIDEですが、更新方法や旧版の扱いは各社異なります。

一方、ルネサス独自仕様のIDE:CS+もアップデート・マネジャーツールで更新します。独自仕様なので、細かい更新内容確認や、一部選択更新なども可能です。ツール・ニュースなどで更新、バグ情報を知らせてくれるのも役立ちます。
また、更新前に、「開発ツールをパックして保存(K)…」を実行すると、更新トラブル対策も可能です。

Runesus CS+ Packing tool
Runesus CS+ Packing Tool

マイコンIDE更新を安全にするには

マイコンIDEの更新トラブル回避には、OS起因でない場合は、旧版のIDEへ戻せることが必要です。また、Eclipseのメジャー更新時などは、操作方法が変わることもあるので注意が必要です。
開発案件のキリが良い時期に更新するのが安全策でしょう。

マイコンIDE開発経験を活かすには

弊社マイコンテンプレートで使用中の各社IDE特徴を示します。マイコンIDEは、Eclipseベースに集約されつつあるようです。今回は、同じベースでもIDEの更新方法が異なることを示しました。

これは、EclipseベースのIDEを使う時に覚えておくと役立つのが、各社共通のエディタやデバッグなどのコア機能であることを暗示しています。他社IDE使用時に、この経験が活かせるからです。

MCU IDE Comparison
マイコンIDE比較

マイコンIDE習得のコツやTipsは、コチラのページにもまとめています。参考にしてください。

NXPとCypress動向

NXPは2015年にFreescale、Cypressは2014年にSpansionを買収しました。買収後のNXPとCypressのマイコンラインアップがどう変わるかが気になります。
日経テクノロジーOnlineで両社のマイコン新製品と今後の開発動向に関する記事がありましたので、要点をリストアップしました。

NXP: LPCとKinetisを徐々に統合

“新生NXP初のマイコン、旧NXP系で低消費電力がウリモノ” 2016/02/24より

  • NXPのマイコンシェア、車載MCUは世界第2位、車載を除くMCUは世界第1位
  • LPCマイコンと(旧Freescale)Kinetisマイコンは、徐々に統合(Geoff Lee氏談)
  • 新製品は、NXP系のLPC54000シリーズ(Cortex-M4FでコプロセサにCortex-M0+搭載可)

弊社マイコンテンプレートで使った、NXPのLPC8xx/LPC111xと旧FreescaleのKinties Eも現在NXPから全て供給中ですが、統合される可能性があることが解ります。

Cypress: PSoC 4へCortex-M0+コアを採用

“FMマイコンもPSoCも同じツールで開発、Cypressがアルファ版をデモ” 2016/02/29より

  • 新製品PSoC 4 Sは旧Spansionライセンス取得のCortex-M0+を採用。今後新開発PSoC 4もM0+を使う
  • PSoC 4 S搭載の第4世代CapSenceは、第3世代比、雑音耐性向上と低電力化
  • PSoC 4 S Pioneer Kit ($49)、PSoC 4 S Prototyping Kit ($10)発売
  • PSoC CreatorでFM0+マイコン(旧Spansion)も開発できるよう強化中

Cortex-M0+とM0を比較すれば、M0+が優れているので、新開発のPSoC 4系にM0+を採用するのは理解できます。
数あるマイコンIDEの中で私が最も使いやすいと評価するPSoC Creatorですが、PSoC 4とFM0+はアーキテクチャが異なり、さらにPSoC 4系にM0+が採用されれば、ますますFM0+を使う機会は減ると思います。
通常のマイコンソフト開発では、M0+とM0を区別することも少ないので、Creator強化は静観したいと思います。