IoT無線規格「Thread」

Threadは、Wi-FiやBluetoothなどの既存無線通信と異なりメッシュメットワーク構成の2015年7月発表の新しいIoT無線規格です。詳しい記事はコチラ、またThread詳細はWebを参照して頂くとして、ここでは記事要旨を示します。

Threadの特徴

Thread System Messaging Model
Thread System Messaging Model(2016_05_10_ThreadPresentation.pdfより抜粋)

メッシュ網構成: Wi-FiやBluetoothの1対1(多)のスター網構成に対し、通信堅牢性と通信範囲の確保を目的にメッシュ網で通信。

ネイティブIP通信:OSIのネットワーク層とトランスポート層の仕様策定が目的で、超低消費電力で短距離通信のIP通信を行うオープン仕様。上下層は、既存レイヤー仕様をそのまま使用。

ネットワーク管理機能と高セキュリティを両立:ノードトラブルや網障害に対し、自己修復し通信継続。

長期電池駆動が可能:長期電池駆動が可能なデータ送受方法を採用。

などホームネットワーク要件を全て満たす。

主要参加メンバー

Thread Group Sponsor BoD Members
Thread Group Sponsor BoD Members(2016_05_10_ThreadPresentation.pdfより抜粋)

ホームコントロール大手Somfy、ホームセキュリティ大手Tyco、Qualcomm Technologies、照明大手OSRAMなどの企業と、マイコン大手NXP、ARMなどが主要メンバーとして参加。

以上が記事要旨にWebから得られる情報を追加したものです。以下の理由で私はThreadに期待しています。

BLEは重い

BLE: Bluetooth Low Energyは、少量データの送信には理想的ですが、アプリケーション規格などが厳格で、「スマホとウエラブルデバイス間通信」に適しています。

しかし、これをマイコンで「単に土管として無線を使いたい」場合には少し重たい気がします。例えば、マイコンUART入出力をIoTコンピュータ:MPU/SBCへ無線で接続する時などです(BLEとROM量はコチラに記載)。

※土管として無線を使うとは、例えば、UART over BLEなどです。

莫大な販売量が見込まれるとしてもIoTエンドポイントマイコンは、ROM/RAMが少なく低価格デバイスが向いていると思います。BLE機能を実装するとROM量は64KB超が予想されます。

Threadが、BLEより軽くマイコンへ実装できれば、IoTエンドポイント通信の本命になるかもしれません。

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

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

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

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

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

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

  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適用や弊社のマイコンテンプレートになるかもしれません。

Node-REDとGenuino 101

Node-RED

トラ技2016年6月号記載のNode-REDは、強力な開発ツールです。ターゲットは、本ブログのマイコンやシングルボードコンピュータなど全てを含むことができます。但し、あくまでNode-RED動作環境の下での動作が前提です。

つまり、WindowsやLinuxなどのリッチOSアプリの1つがNode-REDで、これを使えば、Raspberry Pi 3とArduino/Genuino 101両方で動作するプログラムが開発できます。マイコンの動作オブジェクトコードは(今のVersion0.13.4版では)出力されません。

今回は、このNode-REDがデバイスに依存せずにプログラミングできる仕組みとprintfデバッグについて考察します。

デバイス非依存性

マイコン開発で苦労する部分は、センサやモータなどの個別制御プログラムです。しかし、この制御プログラムが予めライブラリで提供されていて、しかも、制御する側のデバイス、マイコンかシングルボードコンピュータかもGUIで簡単に選択できれば、苦労はかなり減ります。

残りの部分は、どの順番でどのように個別制御プログラムを動かすかというフローチャートのイメージに近い部分です。このフローチャートに近い部分を、Node-REDでは「flow」と呼び、ブラウザを使ってGUIで開発します。

Node-REDのflow例
Node-REDのflow例

ChromeやFirefoxなどのお馴染みのブラウザが使えますので、Windows であってもiOSでも、Linux:Raspbianであっても開発できます。RaspbianをインストしたRaspberry Pi 3もデフォルトブラウザはEpiphanyですが問題なく動作します。

トラ技6月号のP65の図8:GPIOライブラリnode-red-contrib-gpioとJohnny-Fiveの位置づけが、「デバイス非依存性」を端的に示しています。

図8で示されたライブラリとNode-REDのFlowは、オンラインFlowライブラリで多くのサンプルが公開されており、6月4日時点で778個です。☑nodeがライブラリです。

トラ技では、P66のArduino系ボードの中にArduino/Genuino 101は入っていませんが、Firmateプロトコルスケッチをボードへ書き込めますので記事と同様に動作します。このFirmateもCPUやマイコンボードに依存しないプロトコルなので、対象ボードがFirmateさえサポートすればNode-REDから制御できます。

Arduirno/Genuino 101でFirmateプロトコルスケッチを利用
Arduirno/Genuino 101でFirmateプロトコルスケッチを利用

このように、制御に必要なflowサンプルやnodeライブラリを部品として全てネットからダウンロードでき、この部品の加筆修正も簡単にできるNode-REDは魅力があります。ソフト開発時にハード準備が間に合わないことは良くあることですが、実ハードがなくても代替ハードで動作確認し、最後にGUIでポート番号を変更しさえすれば実ハードでも動作することが可能だからです。

printfデバッグ

Arduino IDEも同様ですが、Node-REDには、本格的なデバッガ機能が(今のところ)ありません。

プログラマがprintf(Node-REDは、デバッグ出力ノードに相当)を使って変数などを一時出力してデバッグすることはできますが、動作を一時停止しRAM内容をダンプしたり、変数を変更後に停止位置から再実行したりすることは簡単にはできません。

printfデバッグは、ダウンロードした部品が完全でバグが無いブラックボックスとして扱える場合には効果的かもしれません。例えば、ハードウエア開発で、74シリーズロジックを組み合わせて開発する場合に、ロジックにバグがあると考える開発者はいません。自ら開発したハードをデバッグする際には、プローブとオシロスコープを使って、ロジック間の信号を読み解きバグ取りをします。このプローブがprintfに相当します。

少し前は、マイコンソフト開発でもprintfデバッグが盛んでした。デバッガは高価だったからです。しかし現在は、シリアルーUSB変換機能と兼用でデバッガ機能を持たせた低価格マイコンボードが多数あります(LPC、Kinetis、Cypressマイコンボードなど弊社利用の評価ボード)。

ソフトウエアもハードウエアのように部品化が進めば、printfデバッグで完成する時代がくるかもしれません。しかし、かなり先の話だと個人的には思います。
個別マイコンボードのデバッガ機能がプラグインで追加できる開発ツールを望んでいます。EclipseベースのIDEは、この要望に最も近いのかもしれません。

Arduino/Genuino 101用マイコンテンプレート

因みに、Arduino/Genuino 101のIDEは、今のところArduino IDEです。

Intelは、デバッグ機能付きのEclipseベースIDE、Intel® System Studio for MicrocontrollersのQuark™ SE版をアナウンスしていますが、未だにリリースされていません。私は2016年版Eclipse:Neonをベースに使うと思いますので、今少し時間がかかるかもしれません。

従って、Arduino/Genuino 101用のマイコンテンプレートの発売ももう少し後になります。昔ながらのprintfデバッグには、戻りたくないというのも本音です。ご容赦ください。

計算能力とIO速度によるポジショニング・マップ

トラ技2016年6月号は、MPU/SCBデバイスのRaspberry Pi特集号でOSにLinuxのRaspbianを適用し、

  1. IoT開発環境Node-REDによるMCUとMPU/SCBの垣根を超えたブログラミング
  2. PythonによるMPU/SCBのIO制御

などが楽しめる内容です。P45にコンピュータデバイスのポジショニング・マップが記載されています。本ブログの対象デバイスMCUとMPU/SCBの特性差が解りやすいので引用させていただきました。

IoT制御デバイスの固定ページへも同図を追加しました。特性詳細は、このページをご覧ください。

MCU & MPUSBC Poisoning Map
MCU & MPUSBC Poisoning Map(トラ技2016年6月号 P45より)

英語環境のすすめ

ルネサス2015会計年度と第4四半期(2016年1月~3月期)業績の解説記事から、マイコン開発者に英語環境をすすめる理由を示します。

汎用向け売上げ2割減、日本市場比率44%へ減少

2015年半導体シェアは、先のブログのようにNXP1位、ルネサス2位が確定したようですが、解説記事によると「産業・家電」、「OA・ICT」、「汎用製品」の3分野からなる「汎用向けの売上げが2割減、売上げに占める日本比率は、54%から44%へ減少」したそうです。また、「従業員数も設立当初より4割削減」だそうです。

(日本語)ガラパゴス環境の先行き

汎用マイコンを扱う本ブログは、各社開発環境を一覧表で示しています。これを見ると、ルネサス独自開発のCS+以外は全てEclipseベースのIDEです(Arduino IDEは除外)。また、マイコン開発ボードもArduino互換が標準となりつつあります。

つまり、マイコン開発環境のデファクトスタンダードは、「ARMコア+Eclipse+Arduino+英語」です。開発者の情報交換コミュニティも英語です。

デファクトスタンダードが最適とは言いませんが、特に「汎用の分野」では、ガラパゴスよりもスタンダードが良であることは間違いありません。

Apple iPhoneは、圧倒的大多数を市場で占めているのでガラパゴスでも生き残れます。

地震国日本の部品生産工場が停止した際、連動して製品生産も停止する自動車は、他社流用や使いまわしができない専用品を使っているからです。

コスト重視のマイコン制御系もまた自動車のように最終的には製品専用品になるかもしれません。しかし、マイコン開発者は、少なくとも日本語に拘らず「英語の開発環境に慣れていく」必要があると思います。記事から抜粋したルネサス売上高推移の青部分(日本市場比率)が示す今後を予想してみてください。

日本市場比率の推移(解説記事の図に加筆)
日本市場比率の推移(解説記事の図に加筆)

記載IoTデバイス、IDE、テンプレート動作ボード一覧追加

ブログ記載の「IoT制御デバイス」、「マイコンIDE」、「テンプレート動作ボード」が一目で解る表を追加しました。記載IoTデバイスのプルダウンメニューで表示します。

ブログ記載IoTデバイスのプルダウン表示
ブログ記載IoTデバイスのプルダウン表示

これらは、Wordpress固定ページ機能を使っていますので、通常ブログ記事よりも大きな範囲で表示します。

今後、デバイス追加や対象IDEが変化した時、テンプレート動作確認ボードを追加した時は、この表を随時更新していきます。最新のブログ対応状況をチェックする時などにご利用ください。

EclipseベースのマイコンIDE

4月はマイコンIDE関連のブログ記事を3件記載しました。まとめにEclipseベースのマイコンIDEを概説します。

統合開発環境:Integrated Development Environment, IDE

ソフトウエアを開発するには、ソースを記述する「エディタ」、記述ソースをターゲットコードへ変換する「コンパイラ」、コードをターゲットへダウンロードしデバッグする「デバッガ」…など色々なツールが必要です。これらツールをひとまとめにパックしたのが、統合開発環境:IDEです。

Eclipse

Eclipse(「イクリプス」または「エクリプス」)は、IBMによって開発された統合開発環境の一つ。高機能ながらオープンソースであり、Javaをはじめとするいくつかの言語に対応(Wikipediaより抜粋)。

オープンソース、OS非依存、多言語対応、プラグインによる機能追加などの特徴を持つEclipseは、マイコン開発のみならず様々な「ソフト開発環境のフレームワーク」として世界中に普及しています。

V4.5が現在の最新版で、コードネームはMars(火星)。今後のリリース予定が下表です。

eclipse schedule (Wikipediaより抜粋)
バージョン リリース日 コードネーム コードネームの由来
4.4 2014/06/25 Luna 月を意味。
4.5 2015/06/24 Mars 火星を意味。
4.6 2016/06予定 Neon 元素の一つ、ネオンを意味。
4.7 2017/06予定 Oxygen 元素の一つ、酸素を意味。

多様性と差別化、OS非依存

多種多様なマイコンをベンダ各社は供給中です。

EclipseベースのIDEは、フレームワークはそのままで、自社の多様なマイコン毎に異なる「APIコード生成ツール」や「コンパイラ」の、その部分のみをプラグインで追加/交換できますので、マイコンベンダにとって好都合です。

さらに、他社との差別化機能になるプラグインの開発に労力を集中できます。APIコード生成ツールでは、NXP(旧Freescale)のProcessor ExpertやCypressのGenerate Application、ルネサスのコード生成などがその例です。

MCUコアがARM Cortex-M0/M0+で同じでもマイコンの周辺回路は各社異なります。この異なる周辺回路を活かすAPIコード生成ツールとその使いやすさが差別化ポイントです。

また、WindowsやiOSへも使えるOS非依存性も開発者に歓迎されています。

e2 studioの例

以上のことを知ったうえでEclipseベースのIDEの1つルネサスのe2 studioのソフトウエア構成図を見ると、内容がよく理解できます。

e2 studio plugin
e2 studio plugin(ルネサスe2 studio説明より抜粋)

マイコンIDEの主流はEclipseベースのIDEですが、マイコンIDE早期習得のコツ、ポイントのページで示したように、IDEで本質的に差が生じるのは「マイコン機種依存のAPI生成ツール」とした根拠をここでは示しました。

CS+ V4、e2 studio V5へ更新

ルネサスツールニュース2016年4月16日号でIDEのCS+がV4、e2 studioがV5の更新が発表されました。
更新は、通常手順で問題ありません。しかしCS+は、セキュリティソフトAvastとの相性問題か、脅威検出が発生しました。

更新方法

CS+は、アップデートマネジャの起動で更新されます。但し、ラピッドスタート有効時は、一旦CS+を終了しアップデートマネジャ単独での処理が必要です。

e2 studio V5(Eclipse 4.5:Marsベース)は、V5のインストーラをダウンロードし、新規インストールが必要です。前版からは、V5へ更新できません。

これはEclipseベースのIDEでは周知のことで他社、例えば旧FreescaleのKinetis Design Studioも同様でした。

更新結果

CS+は、Windows 8サポートが終了し、Windows 10または8.1利用が必須となりました。
また、CS+起動時にMy Runesasへのログインダイアログが表示されるようになりました。ログインすると、同意確認ダイアログが表示されます。Windows 10の情報収集と同じような機能だと思います。

MyRunesas Login and Confirmation
MyRunesasログインと同意確認

気持ちが悪い人は、CS+起動後にヘルプ>プライバシー設定(Y)…で同意の変更が可能です。

Privacy Setting
プライバシー設定変更

e2 studioは、V5インストーラ起動後、アップグレードか別フォルダへのインストかを選択し実行します。追加ソフトウエアで、CC-RLコンパイラやKPIT GNU RL78コンパイラが選択インスト可能です。

e2 studio v5 setup
e2 studio v5セットアップ

更新完了で下図となります。

e2 studio v5
e2 studio v5

AvastとCS+の相性

旧CS+では生じなかったセキュリティソフトAvastから脅威検出が発生しました。この現象は、過去のCS+更新時にも生じた経験があります。

Avast Block Report
Avastがブロックした脅威

今回は、「スキャンから除外するリストに追加」で対処しました。Avast以外のセキュリティソフトでも発生する可能性がありますので、参考にしてください。

e2 studio所感

e2 studioをCS+の代わりにRL78/G1xマイコン開発で使う必要性は、「今のところ無い」と思います。

「なれ」の問題もありますが、コード生成ツールや、デバッガの基本的な使い方などは、CS+と同じであることが理由です。敢えて差分を示すと、今回のツール更新方法やCコンパイラが選択できること、デバッガ接続方法などです。
また、他社と比べベースとなったEclipse IDE更新が数か月遅れなのも気になります。

最近のルネサスサンプルコードは、CS+とe2 studioの両プロジェクトが一緒に提供されます。狙いはe2 studioの普及だと思います。

汎用のIDEであるEclipseになれるという目的でe2 studioを使うのは良いかもしれませんが、ルネサスMCU専用のIDEであるCS+よりも使いやすいとは言えません。

いずれにせよ、e2 studioは、要観察を続ける予定です。

マイコン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は、コチラのページにもまとめています。参考にしてください。

CS+のCS78K0Rコンパイラ消える?

ルネサスツールニュース2016年4月1日号で、CcnvCA78K0Rが発表されました。

これは、RL78の統合開発環境CS+のCA78K0RコンパイラCソースを、CC-RLコンパイラCソースへ変換するツールです。58ページからなるユーザーズマニュアルも公開中です。

コンパイラ一本化への布石

統合開発環境:IDEのコンパイラが2本あるのは、使う側、提供する側双方にとってメリットはありません。

まして、CC-RLが性能では優れているので、CA78K0Rを使い続けるのは既に顧客へ提供済みのCソースを使うからでしょう。

本ツールは、そんなCソースをCC-RL Cソースへ変換します。CA78K0Rコンパイラは、半導体デバイスでは良くあるディスコン(discontinue)にして、CC-RLコンパイラへ一本化するための布石だと思います。

IDE

ルネサスは、統合開発環境IDEも独自開発のCS+と、ワールドワイドで一般的なEclipseベースのe2 studio、さらにRenesas Synergy™ 開発環境(ISDE)やHewなども提供中です。

要は、デバイス開発に使いやすいIDEが良いのですが、誰とどのように開発するか等の条件によりルネサスは、様々な解を提供しているのです。Synergyは別物としても、何種類も提供するのは大変でしょう。他ベンダがEclipseベースで一本化されているのとは、対照的です。

ベースとなるのがEclipseでも、各社IDEのAPI関数を生成するツールは全く異なります。ルネサスのAPI生成ツールが慣れもあって使いやすいので、この特徴を活かした発展を望んでいます。

マイコンIDEを早く効果的に習得するコツは、コチラのページにまとめています。