「Qualcomm/NXPの合併に立ちはだかる米中政府の壁（前編、後編）」という記事が掲載されました。
合併が2017年末完了予定から延びる可能性があるそうです。私には記事内容は、イマイチ解らないのですが、NXPの2017年MCU開発計画に影響しないことを願っています。
カテゴリー: LPCマイコン
NXP社のLPCマイコンに関する情報、Tipsなどをまとめています。
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、FreeRTOSやmbed 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評価ボードで動作確認できることが選定理由です。
因みに、LPCXpresso812/1114/1115評価ボードで動作する弊社マイコンテンプレートも販売中です。このマイコンテンプレートによる従来ソフト開発と、FreeRTOSによるソフト開発の違いなどでRTOSの特徴を浮き彫りにします。
RTOSの必要性
評価ボード実装済みのLEDを点滅させるいわゆる「Lチカ」サンプルソフトを、FreeRTOS利用時のソースの一部（左側）と、RTOS未使用の通常ソフト記述（右側）を示します。最大の違いは、無限ループの数です。
FreeRTOS記述の場合、1個のタスク（≒ユーザ処理単位）で1個の無限ループを持ちます。一方、通常ソフト記述の場合は、全体で1個の無限ループのみです。1個の無限ループ内で様々なユーザ処理を行うため、ループ内の１処理時間の長さ、短さ、待ちがその他の処理へ影響を与えます。
RTOSを使う最大の利点は、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のポイントをできるだけ簡潔に説明していきます。詳しく知りたい方は、お勧め参考書などを参照してください。
2016年マイコン業界と超速開発
2016年マイコン業界
Qualcomm ← NXP ← Freescale、買収先の企業へ矢印を付けるとこのようになります。
QualcommはSnapdragonなどのスマホチップセットを供給する半導体ベンダーです。車載を得意とするNXPの社名は残りそうですが、買収後のNXP/旧FreescaleのCortex-M系マイコンラインアップは気になります。
さらに、Windows 10がこのQualcommのSoCで動作するというニュースは、IoT向けPCやスマホにMicrosoftが参入し、数多くある無線規格の収束を早めるかもしれません。
先ず2017年3月、開発環境LPCXpressoとKinetis Design Studioが新しいMCUXpressoに統合されます。また、先日発表の2017ロードマップによると、スイッチマトリクスを持つLPC8xxシリーズが充実します。QualcommとのシナジーによりIoT無線規格のIoTマイコン発売が期待できます。
一方、RunesasもSynergyで遅ればせながらARM Cortex-Mマイコン開発に乗り出し、従来からある独自コアを持つRL78の16ビットマイコンやIDE：CS+は肩身が狭くなった気がします。既存マーケットにはRL78、IoTにはSynergyのCortex-M23/M33という住み分けを意識したかのようです。
Cypressは、Spansion買収によりCortex-M0+コアを入手し、PSoC4へ適用し始めました。アナログ技術が豊富なPSoC4/PRoC/PSoC4 BLEマイコンが更に強化されました。私はCortex-M0/M0+開発では、最も使いやすいIDE：PSoC CreatorとPSoC4/PRoC/PSoC4 BLEの組合せがピカ一だと評価しています。Cortex-M23のラインアップ追加が待ち遠しいです。
※上記は、下記個人レベルで準備できる「入手性が良く、低コストマイコン」の選択基準に合致する半導体ベンダーに限定して分析しております。
超速開発環境
顧客が許容するマイコンソフト/ハード開発時間は、ますます短くなります。
顧客側の技術理解レベルが追い付かないのも原因の1つですが、状況変化が激しいので即開発し、市場でのフィードバック、改良などを繰り返しながら製品化が必要なことが大きな要因です。
短い開発時間は、マイコン開発者にプレッシャーや焦りを生じさせます。しかし、焦りは禁物です。
良い成果物を効率的に出力できるワザ、これがマイコン開発者には必要です。
このワザ習得には、時間を気にせずに没頭できる環境、例えば自宅などで、新しいマイコンや現状マイコンを、身銭を使うので低コストで、しかも短時間で習得できる方法が必要です。
技術は、食べ物と同じで自分で習得（食べ物なら消化）してこそ身に付きます。食べ過ぎて消化不良になるのを避ける手段/方法があります。
この習得方法が超速開発環境、マイコン評価ボード（＝スターターキット）＋拡張ボード（＝mbed-Xpresso Baseboard）＋そして弊社マイコンテンプレートです。
マイコンテンプレート（税込1000円）は、懇切丁寧な添付資料や多くの（冗長な！？）コメントをソースに付加しています。従って、初心者が陥りがちな初期トラブルを避けることができ、ベンダー提供のサンプルソフトを活用したマルチタスクで、評価ボードと拡張ボードを動かせます。
ソフト担当者は、マイコンを自分で動かせれば、安心して厳しい状況でも開発できます。
また、基板開発時に問題となるアートワーク（配線引き回し）に配慮したIO割付を実ボードで検証できるので、基板化障壁も下がります。
ハードのみの担当者であっても、この超速開発環境はマイコン回りのベンダー推薦配線チェック、アートワークに適したIO割付をソフト開発者へ提案、基板テストプログラム開発時などにも役立ちます。
＊ ＊ ＊
「入手性が良く、低コストマイコン」という基準で、現在5種マイコンをピックアップし、そのマイコンテンプレートを開発/販売することで、超速開発をサポートするのが本サイトの目的です。ご要望により新たなマイコンを追加する可能性もあります。
サイトに対するご意見、ご要望、追加マイコンなどお気軽にinfo@happytech.jpへお寄せください。
本年もありがとうございました。来年も引き続き弊社サイト、どうぞよろしくお願い申し上げます。
NXP LPC8xxの2017年ロードマップ
ARM Cortex-M0+で8/16ビットマイコン置換え市場を狙ったNXP LPC8xxの2017年ロードマップが公開されました。LPC1700の後継機LPC54000のロードマップと共に下記に示します。
※LPC1700とLPC54000は本ブログ対象外ですので、説明は割愛します。
2017年のLPC8xx
現在LPC8xxシリーズラインアップが下記です。
ピン数が少なくても多様なIOを構成できるスイッチマトリクスを持つCortex-M0+マイコンです（スイッチマトリクスについては、過去のLPC8xxブログ記事などを参照してください）。
ロードマップを見ると、ROMを増やす方向のLPC84xと、動作速度を下げる方向のLPC80xが2017年に発表されます（他のLPC8xxシリーズは、1.8V-3.6Vで30MHz動作）。速度低下に伴って、動作電圧も下がるかは不明です。
NXPは、QUALCOMMに買収されましたが、2017年ロードマップにLPC8xxが示されたことは、スイッチマトリクスが好きな私にとって好材料です。
掲載サイトには、2017年3月リリース予定のMCUXpressoのことも掲載されていますが、特に新しい情報はありませんでした。
Cortex-M0/M0+/M23
11月10日の記事記載のように、IoTデバイス向けに「セキュリティ強化のCortex-M23」と、従来「8/16ビットマイコン置換えのCortex-M0/M0+」の2つにCortex-M系の低コストマイコンも使い分けが必要な気がします。
IoTデバイスは、今のところ無線通信方式に決めてが見つかりません。そこで、適用市場が明確なCortex-M0+の新製品を先行して投入するのがNXPの作戦ではないでしょうか？
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とKinetis K/Lは、2017年3月にサポートされる予定です。
MCUXpressoもEclipseベースIDEで、無料版でもコードサイズ制限なしで使えるなど、数々の嬉しい特徴を備えています。LPCXpressoとKDSの最も異なる部分、API生成/提供方法がMCUXpressoでどのようになるかは、今のところ不明です。
IDEのAPI生成/提供方法
マイコンテンプレート使用中IDEのAPI生成/提供方法をまとめました。現状は3種類です。
| 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対応かなと思ってきましたが、業界再編の可能性も影響しているかもしれません。
ARMコアが業界標準になった時の差別化技術
9月23日の日経テクノロジーOnlineに“技術も市場も混沌としたIoT、ソフトバンクだけが視界明瞭”という記事で、興味深い内容を2つ見つけたので抜粋します。
記事は、ソフトバンクのARM買収の意味と影響を分析しています。
差別化はアナログ技術
“IoTマイコンに於けるARM優位性がこのまま維持され事実上の業界標準になれば、MCU各社の差別化技術はアナログ分野になる。”
本ブログで扱う低価格MCUコアは、ARM Cortex-M0/M0+がデファクトスタンダードで、Runesas 1社のみが独自RL78-S1/S2/S3コアです。そのRunesasも9月13日に、電圧制御やのアナログ分野に強みがある米インターシルの買収を発表しました。記事の予想は、正しいと思います。
センサー、通信マイコン、電源ICがIoT端末必須技術
“IoT端末の必須技術は、センサー、通信マイコン、電源ICの3つ。”
弊社が言うIoTマイコン各社が、アナログ技術を強化すれば、センサーインタフェースへ適用するでしょう。
例えば、オペアンプ実装などです。また、MCUとMPU/SCB間無線技術も、仕様が固まれば、当然実装されます。
これらが実装済みのIoTマイコンが、待ち遠しいです。ROMやRAMの容量次第では、マイコンテンプレートの活きる場所もありそうです。また、ARMと親和性が高いEclipseベースのIDEであっても、その使い勝手や、アナログ技術の取り込み方法の上手さもMCU選択の重要な基準となると思います。
追記：Cypress PSoC Creator 3.42.4が、3.25.0に更新されています。更新は、Update Managerから簡単に実行できます。
新生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製品ラインアップが分かりにくいのが現状です。
既存ユーザにはページ分離記載で問題ないでしょうが、以前記載した今後を予想するには、下図が解りやすいと思います。
左側の汎用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シリーズへの適用は、弊社へお問合せください。
速報：Windows10 1607のマイコンIDE動作確認
Windows 10 Anniversary Update、Red Stone 1（RS1）のリリースが8月2日実施されました。
弊社マイコンテンプレート使用中のマイコンIDEを、このWindows 10 RS1、1607で動作確認しましたのでお知らせします。
IDEは、全て8月3日時点最新版です。マイコンテンプレートソフトのコンパイルと評価ボードへのダウンロード動作を確認しました。
マイコンIDEの詳細はコチラ、評価ボードはコチラに一覧表を掲載しております。
※Windows10 1511で動作していたものは、今のところ1607でも問題なく動作します。
※Windows 7時代に購入した評価ボードは、一部Windows 10で動作しない場合があります。この場合は、ボードドライバ（USBドライバ）の更新で動作するようになります。
| マイコンIDE（ベンダ名） | Windows 10 1607動作確認バージョン |
| CS+ for CC（ルネサス） | V4.00.00 [15 Mar 2016] |
| e2 studio（ルネサス） | Version: 5.1.0.022 |
| LPCXpresso（NXP） | v8.2.0 [Build 647] [2016-07-18] |
| Kinetis Design Studio（NXP） | Version: 3.2.0 |
| PSoC Creator（Cypress） | PSoC Creator 3.3 CP3 (3.3.0.9604) |
| Arduino IDE（Intel） | 1.6.10 Hourly Build 2016/07/26 |
解説：マイコン評価ボード
マイコン開発には、各社が低価格で提供している評価ボードは必須です。
弊社マイコンテンプレートも、各ベンダの評価ボードで開発しています。この評価ボードを解説します。
採算度外視の低価格、高信頼ハードウエア
ソフト開発者に「確実に動くハードウエア」を「低価格」で提供する、これが評価ボードです。
マイコン開発には、「専用」のソフトウエアと「専用」のハードウエアの両方が必要です。そして片方のデバッグには、もう片方にバグが無いことが必須です。つまり、ソフトデバッグには、バグなしのハードが必須なのです。そこで、バグなしで確実に動作する「汎用」ハード、これが各ベンダ提供の評価ボードです。
但し、専用ハードがいずれ開発されるので、汎用の評価ボードは低価格とならざるをえない運命です。高ければ誰も買ってくれないからです。しかし開発者にとっては、以下のように優れた教材と言えます。
- ソフト開発者が、専用ハードが出来上がる前にソフトデバッグ可能な環境を自由に構築できる
- ハード開発者が、そのまま専用ハードにも使える高信頼ハード設計を学べる
- マイコン初心～中級者が、ベンダ標準のデバッグ技術で低価格な開発環境を使って自習できる
- 評価ボードは、各ベンダフォーラムで多くの情報が記載されており、適用サンプルソフトも多い
ターゲットMCU、デバッグインタフェース、拡張コネクタの３構成
評価ボードは、ターゲットMCU、デバッグインタフェース、拡張コネクタの３つから構成されます。
NXPの評価ボード：LPCXpresso LPC812とルネサスのRL78G13-Stick、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と比べるとコスト的に劣ると言えるでしょう。
デバッガ機能なしの統合開発環境：IDEの背景
シールドなどのボード単位の部品化が進んだ結果、専用ハードは、もはや既存ハードを組み合わせて、その小型化のみを行う設計、つまり専用基板化が主な開発内容と言えるかもしれません。
同様に、ソフト開発もベンダが、多くのライブラリを提供することで、専用ソフトをライブラリの組合せで完成できるレベルを目指しているようです。IDEにデバッガ機能がないArduino IDEなどは、この現れのような気がします。
ハードとソフトのオープンソース
ハード版オープンソースとしてArduinoシールドコネクタを持つ既成基板は、増えつつあります。
オープンソースを活用したソフト開発は、Unix系では当たり前です。この流れがマイコンソフトへも徐々に浸透する可能性を感じています。この場合、ハードの専用基板化開発に相当するのは、RTOS適用や弊社のマイコンテンプレートになるかもしれません。