MCU：マイコンアーカイブ - 35ページ目 (58ページ中)

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

2017年2月15日2021年12月4日 WithHappy

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

ISDN終了とIoTキラーアプリ

2017年2月3日 WithHappy

2020年以降、現行のISDN公衆交換電話網Public Switched Telephone Network：PSTNが、Internet Protocol：IP網へ全面移行します。ISDNの次の世代はATM：Asynchronous Transfer Modeと思いその研究開発が社会人スタートだった私には隔世の感があります。データ中心のコンピュータIP網が次世代ISDNの解に決まったからです。

IoTキラーアプリ

障害予測、適応型診断、状態適用型メンテナンス、これらが産業用IoTキラーアプリ候補だという記事があります。キラーアプリとは、技術を爆発的に普及させるアプリケーションのことです。

記事の中で、“キラーアプリケーションは、新技術の普及を促進するとともに、多くの場合、基板となるコンポーネントの複雑さを覆い隠す。大多数のユーザーは、その技術から得られるメリットを求めるのであり、その内部構造には関心がない”という記述があります。

これは真理です。ATMがIPに負けたのも、キラーアプリの成せる業です。

アプリよりのIoTマイコンテンプレート

販売中のマイコンテンプレートは、汎用性を重視しています。
しかし、IoT向けのマイコンテンプレートには「汎用性よりも、よりアプリよりのテンプレート提供」が求められそうです。記事を参考にIoTマイコンテンプレートの構成を検討します。

CS+のスマート・ユーティリティ（スマート・ブラウザー編）

2017年1月23日2017年1月25日 WithHappy

2017年1月にCS+パッケージバージョンV5.00.00 [05 Dec 2016]がリリースされました。確かバージョンV4から追加された3種のスマート・ユーティリティのうち、スマート・ブラウザーを説明します。

スマート・ブラウザー

組込マイコン：MCU開発を上手く効率的にする手法は、今風に言うと“サンプルソフトファースト”です。

分厚いユーザーズ・マニュアルを、初心者が読んでも眠くなるだけで時間のムダです。開発事案に近い例や使用する周辺回路が記載されたサンプルソフト＝アプリケーション・ノートを先ず読んで、不明な箇所をユーザーズ・マニュアルの目次から拾い読みすれば十分です。

この開発例や周辺回路のサンプルソフトを見つけるのに便利なのが、CS+に追加されたスマート・ブラウザーです。

アプリケーション・ノートタブを選び、タイトルや機能で並び替えするとクイックにサンプルソフトが選定できます。ルネサスサイトでもアプリノート検索はできますが、CS+のスマート・ブラウザーの方が使い易く検索も高速です。

アプリノートは、ユーザーズ・マニュアルと比べると、一般的に内容をサラッと記述します。詳しくくどく書くこともできますが、読まれることを重視するとこの書き方になるのだと思います。サンプルソフトの読み方は、コチラも参照してください。

アプリノートの次に登場するのがユーザーズ・マニュアルです。こちらは、丁寧に記述されていますので、アプリノートの不明点を明確にし、その箇所を読めば時間節約ができます。近頃の開発は、１からディスクリートで着手する（≒オートクチュール）よりも、既にある既成品を上手く組み合わせて早期に開発する方（≒プレタポルテ）が好ましいと思います。これは、ハード/ソフトともに言えることです。

いかに既製品、この場合はアプリノートを見つけ、それを破綻なく組み合わせて顧客へ提供するのも１つの開発技術です。

複数アプリノートを簡単に組み合わせるマイコンテンプレート

1つのアプリノート流用で開発完了することは、稀です。大抵は、複数のアプリノートの部分利用、応用が必要となります。アプリノートは、内容をサラッと記述するために、初期設定＋無限ループの２構成が殆どです。複数アプリを流用するには、アプリノート記載の無限ループ内処理の取り込み方が問題です。

そこで登場するのが弊社マイコンテンプレートです。マイコンテンプレートは、1個の無限ループ内に複数の時分割アプリランチャーを備えています。そこで、このランチャーに必要となるアプリノート処理を組み込めば、簡単に複数アプリノート処理をテンプレートで起動できます。しかも、低電力動作SleepやHaltの機能も追加しています。

マイコンテンプレートの詳細は、コチラを参照してください。

MCU開発は、開発完了が見極め難い性質があります。なるべく早く1次開発物を顧客に見せ、そのうえで２次開発へと進む段階を追った開発、いわゆるプロトタイピング開発もこの性質対応の１方策です。
このプロトタイピング開発の際には、是非マイコンテンプレートを活用し早期に、しかも拡張性や応用性もある開発物提供に役立ててください。

RL78消費電流シミュレータ解説ガイド

2017年1月19日2017年1月19日 WithHappy

2016年9月の記事で、ルネサスRL78消費電流シミュレータのキャンペーンを紹介しました。2016年12月にこのシミュレータの解説ガイトがリリースされましたので、紹介します。

2種類の消費電流シミュレータ

解説ガイトから抜粋の2種類の消費電流シミュレータ比較結果を示します（本家サイト全検索も綺麗な表が見つかりませんので、低解像度はご勘弁を）。

Current Simulator Comparison — 消費電流シミュレータの比較（記事より）

比較表上側：消費電源計算ツールが9月で紹介したWebシミュレータです。弊社9月記事で懸念したシミュレータの精度は、あくまで参考値だそうです。低消費電力が売りのRL78/G10、G13、G14、G1Dで対応品種が多く、Webで手軽に使えるツールなので、どの程度の参考になるかをもう少し具体的に、技術的に示してほしいです。

もう1つの実測値の±10％程度の精度がでるシミュレータ：比較表下側は、RL78/G10とG13に対応中で、e2 studioのプラグインで機能提供するものです。将来的には、こちらもクラウド対応にする計画があるとガイドに記載されています。シミュレータで10％誤差なら、結果に十分説得力があります。

CS+で使える消費電流シミュレータは？

気になるのは、この2番目のツールが、RL78/G1x開発では圧倒的に使い易いIDE CS+を差し置いて、e2 studioでのみ提供中である点です。ルネサスはe2 studioへIDEを一元化したいのでしょうか？　それとも、CS+よりもe2 studioユーザが多い（あくまで推測ですが、その）結果が反映されたのでしょうか？　CS+ユーザの私には非常に気になりました。

Cortex-M23＋mbed OS 5＝セキュアIoT MCU

2017年1月18日 WithHappy

2017年1月13日発行“ARMの最新アーキテクチャ「ARMv8-M」が目指す「セキュアMCU」とは”の記事を読むと、ARMコアの新ラインアップCortex-M23の中身：ARMv8-Mが備えるセキュリティの概要が分かります。IoT向けマイコン：MCU実現には、Cortex-M23にARM RTOSのmbed OS 5実装が必須になりそうです。

既存MCUの脆弱箇所

IoT MCUにはセキュリティ対策が必須との記載をよく見かけます。しかし、具体的にどこが脆弱箇所で、それはなにかを目にしたにはこの記事が初めてです。Cortex-M23の謳い文句は、セキュリティに対する深い知識、経験が無くても扱えることですが、これら脆弱箇所は深くない常識？！として知らなければいけなかもしれません。

ARMv8-Mは、これら脆弱箇所に対して3段構えハードウエアで多段防御しています。詳細は、記事を読んでください。

ハード＋ソフトのARM IoTセキュリティ戦略

重要なのは、これらの防御にもかかわらず外部との通信セキィリティ、具体的には通信データの暗号化処理は、別途IP：Cryptocell-312か、または、mbed OS 5（TLS部分）が必要になる点です。低価格IoT向けMCUでは、IP追加よりもmbed OS 5実装の方が現実的ですので、結局、下記公式が成り立ちそうです。

低価格セキュアIoT MCU＝Cortex-M23＋mbed OS 5

FreeRTOSなどの他社RTOSをCortex-Mコアへ適用しようか検討している方は、要注意です。Runesasは、SynergyでThreadXを使いそうです。

また、記事にあるようにMCUコードをOTA：Over The Airで更新を行うとなると従来MCUとは別次元の開発スキルが要求されます。RTOSがサポートしてくれれば良いですが、Windowsでさえも更新失敗が（たまに）ありますから…。

セキュアIoT MCU向けハード/ソフトが揃いつつあります。中小規模の従来MCU開発を長くやってきた開発者側としては、IoT MCUの構造は、従来とかなり異なる感触を得ます。Qualcomm（NXP）あたりから、IoT MCUレファレンスデザインを早期にリリースしてくれれば、よりハッキリすると思います。

Qualcomm、10nmプロセスのSnapdragon 835発表

2017年1月7日 WithHappy

NXPを買収したQualcommがSnapdragon 835を発表しました。この発表の解説記事：“820比で消費電力25％削減、GPU性能25％向上、Windows 10へも対応”から、今後のIoTマイコン開発を予測します。

マイコン製品のロングライフ化

バッテリ機能低下のスマホは文鎮化します。3年使い続けた私のNexus5：2300mAhも、最近はどう工夫しても半日程度しかバッテリが持ちません。500回と言われるリチウムイオン電池の充電サイクルは、とうに過ぎているので仕方ないことです。

数年のライフでも許されるスマホと違って、組込用途のIoTマイコン：MCU製品は、一度設置されると10年程度はメンテなしで動作する必要があります。MCU製品のロングライフ化が、開発トレンドになると思います。（IoT端末の必須技術も参照）。

MCUハードの進化は、スマホMPUやパソコンCPUの後追いです。NXPのLPC8xxの2017年ロードマップのように、半導体プロセス進化と共に、新たな低電力マイコンが発売されます。
MCUソフトは、動作周波数を下げる、不要な周辺回路を停止するなどの定番手段がありますが、低電力化の要求は、ソフト記述テクニックそのものにも影響を与えるかもしれません。

レファレンスデサイン利用

スマホ開発は、レファレンスデザイン利用が一般的です。Nexus5もスマホOS：Androidの生みの親Google提供のレファレンスデザインの1つとも言えます。レファレンスデザインの利用目的は、独自仕様のハードや付加アプリの早期開発のためです。

従来MCU開発は、サンプルソフトと開発ボードで行ってきました。弊社マイコンテンプレートもこれに相当します。

しかし、高度なセキュリティと無線通信が必須のIoT MCU製品開発の場合は、リアルタイムOS：RTOSの実装も（おそらく）必要となります。従来の開発方法では、本来の差別化技術開発に到達する前段階で時間が掛かると思います。さらに、無線通信規格の乱立も開発時間を増やす要因です。

これらの対応にIoTマイコン開発も、mbed OS 5やFreeRTOSなどのRTOSが実装済みのレファレンスデザインキット提供が必要だと思います。例え無線規格変更やRTOS変更が生じても、キットの基本部分は同一で、無線モジュール載せ替えとRTOS APIを利用していればアプリ側の小変更で対応できるからです。

IoTマイコンには、UARTとは比べ物にならない複雑な通信処理と高度なセキュリティが必須です。数10億個とも言われるマーケットに普及させるには、スマホ開発やWindowsアプリ開発に近い新たな開発環境が要求されると考えます。

2016年マイコン業界と超速開発

2016年12月23日2017年1月5日 WithHappy

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年ロードマップ

2016年12月18日2016年12月18日 WithHappy

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の作戦ではないでしょうか？

ARM Cortex-M23の特徴

2016年11月10日2016年11月11日 WithHappy

ARMがセキュリティ機能を統合した新プロセッサ「Cortex-M23/M33」を発表記事から、Cortex-M23とCortex-M0/M0+の相違点、開発ポイントになりそうな箇所を抜粋し、特徴を考察します。

IoTデバイスのセキュリティ

“ネットワークに繋がるIoTデバイスには、セキュリティは必須”“
”IoTデバイスにセキュリティを普及させるには、セキュリティに対する経験が全くないエンジニアでも扱うことができる「1ドル以下のセキュアなMCU設計」が必要。このソリューションがARMv8-M TrustZone。“
”ARMv8-M命令セットは、必要最小限のベースラインセットと、浮動小数点演算などの拡張メインラインセットの2階層から成り、Cortex-M23は、ベースラインセットを実装“
”Cortex-M0/M0+は、ARMv6-M命令セット。Cortex-M23は、Cortex-M0/M0+後継の位置づけ。“

整数演算プロセサのCortex-M23

“性能レンジ：0.98MIPS/MHz、2.5CoreMark/MHz、Cortex-M0+比1.6～3.2％の性能向上”

“Cortex-M23は、Cortex-M0/M0+と同じ2ステージパイプラインでミニマムパイプライニング”
“Cortex-M23は、フォンノイマンアーキテクチャ”

低コストかつ低電力にセキュリティを実装

“Cortex-MシリーズのTrustZoneは、以前からあるCortex-A向けのTrustZoneとは異なる”
“ARMv8-MのTrustZoneは、ハードウエアによるステイト遷移、セキュリティモニタソフト不要、ハードウエア遷移なのでレイテンシ少で、低速MCUでも実用的なセキュリティシステム”

※Cortex-M33に関しては、本ブログ対象ではないので、記事抜粋を割愛しております。

ハードによるセキュリティ機能実装メリット

パソコンを使う人なら、セキュリティ機能が必須で重要であることは、重々承知しています。また、その副作用として、本来の処理遂行に時たまジャマ？になることも…。性能が限られたMCUではなおさらでしょう。

イメージとしては、ウオッチドックタイマが近いと思います。開発初期やデバッグ中は機能を停止させ、最終版では、必ず動作させます。動作しても、ソフト性能がむやみに消費されることは殆どありません（というか、そのようにソフトを作ります）。

また、セキュリティに対する深い知識、経験が無くても扱えることも大歓迎です。要は、ネットワークに安全確実に繋がり、本来処理を、低価格低電力で実行できさえすれば、良いのですから。セキュリティは必須でも、あくまで付加サービスです。

Cortex-M23は、Cortex-M0/M0+の置換えヒット商品の予感がします。ARM Cortex-M0/M0+へ初挑戦する方も、既にCortex-Ｍ開発経験がある方も、楽しみなデバイスが出てきました。弊社マイコンテンプレートも現在はCortex-M0/M0+のみの対応ですが、Cortex-M23 MCU発売後は、対応する予定です。

ルネサスSynergyでCortex-M23サポート発表

2016年11月1日2017年4月7日 WithHappy

ルネサスが、SynergyにARM Cortex-M23を加える予定を発表しました。Cortex-M23は、コチラを参照してください。

Synergy

Synergyは、2015年10月に提供開始した新しいARM Cortex-M系の開発環境（2015年10月18日の記事も参照ください）。

他ベンダ―のARM Cortex-M開発環境は、EclipseベースIDEであるのに対して、少し異なる（Apple的な）アプローチを取っています。ガラパゴスと言われなければ良いな？！と思いますが…。後発なのでプラスアルファした結果だと思います。

このSynergyに先日記載したCortex-M23を将来的に加えると発表しました。IoTデバイスを狙うなら当然です。本ブログも注視していきます。