ルネサスエレクトロニクス、IDT買収

2018年9月11日、ルネサスエレクトロニクス(ルネサス)が米)Integrated Device Technology(IDT)を買収すると発表しました。
約67億ドル買収完了見込みの2019年前半には、IDTはルネサス完全子会社になります。

ルネサス、IDT買収の狙い

・補完性が高い製品獲得によるソリューション提供力の強化
・事業成長機会の拡大

ルネサスは、RFや各種アナログ・ミックスドシグナル機能を持つIDT製品を獲得し、これらをマイコンやパワーマネジメントICと組み合わせ、アナログフロントエンドを強化、これによりIoTや産業、自動車分野の事業領域拡大を狙うと発表しました。

2017年2月に32億1900万ドルで買収したアナログ半導体メーカの米)Inersilと今回のIDTとの事業重複は無く、ルネサス+IDT+Intersilでエンドポイントのインテリジェンスを抑え勝つ(=優勝を狙う)とルネサス)社長兼CEOの呉文精氏はコメントしています。

System on a chip(SoC)でルネサスMCUに強力なアナログ機能が実装される可能性が高まったと思います。

MicrochipのインテリジェントADC(ADCC)

同様の動向として、アナログフロントエンドに計算機能を備えたインテリジェントADCを使いAD変換結果に含まれるノイズを除去、MCU処理電力を低減するADCCデバイスをMicrochipが発表しました。

2018年9月19日水曜14時~15時に、「センサノードの低コスト設定:ADCC」と題して日本語Webinarsが予定されています。登録は必要ですが、どなたでも無料で視聴できオンライン質問にも回答してくれるそうです。興味ある方は、参加してはいかがでしょう。

QualcommのNXP買収断念とルネサスのIDT買収

Qualcomm による約470億ドルNXPセミコンダクターズ(NXP)買収は、断念という結果になりました。“NXP買収を断念したQualcommの誤算(前・後編)”によると、半導体業界はこの騒動からいろいろな教訓を学ぶべきだそうです。
また、同記事でNXP CEOのRick Clemmer氏は、

「QualcommとNXPの合併により、さらなるスマート化に向けたセキュアな接続を実現するというわれわれのビジョンに必要な、あらゆる技術を統合できる。これによって、最先端のコンピューティングやユビキタス接続を、セキュリティや、マイクロコントローラなどの高性能ミックスドシグナルソリューションと組み合わせることが可能になる。両社が協業することで、さらに完成度の高いソリューションを提供できるようになるだろう。特に、自動車やコンシューマー、産業用IoT、デバイスレベルのセキュリティなどの分野において、リーダー的地位をさらに強化し、幅広い顧客基盤との間で既に構築している強固な協業関係を、さらに拡大していくことが可能になる」

と語っています。

上記は、買収を免れたNXPにとっては実現しなかった訳です。コメント内容は、ルネサスのIDT買収狙いと重なる部分が多く、IDT買収がルネサスにとって重要であることの証拠と言えると思います。

企業買収は、巨大な初期投資が必要な半導体業界での生き残りと主要技術確保のための戦略です。
ルネサスとNXPのIoT、産業、自動車分野のMCU競争は、ますます激しくなるでしょう。

MCU統合開発環境の後方互換性検証

MCU統合開発環境は、後方互換が重要です。数年前に開発したプロジェクトを改良・改版する際には、最新の開発環境(IDE)でも開発当時と同じ動作が求められるからです。

ベンダー各社もこの点に留意してIDE改版を行っているハズです。ただ、リリースノートにも具体的な互換性説明などは見当たりません。そこで、MCU最新IDEの後方互換性を検証します。

本稿は、ルネサスエレクトロニクス(以下、ルネサス)の最新IDE:CS+に、弊社2015年開発のRL78/G1xテンプレートプロジェクトを適用し、発生するメッセージなどを示し、開発当時と同じ動作をするかを確認します。もちろん、これはあくまでも一例にすぎませんが、開発中にIDE更新に遭遇した際などの安心材料になれば幸いです。

ルネサス統合開発環境CS+

2018年9月最新ルネサスIDE CS+は、Ver.: V7.00.00(2018/07/20リリース)です。CS+は、業界標準のEclipseベースIDEではなくルネサス独自開発のIDEです。

好都合なことにWindows 10 1803をクリーンインストールしたので、まっさらなWindows 10へ最新CS+をインストールした条件で検証ができます(1803クリーンインストール顛末はコチラを参照)。

CS+ダウンロードサイトでカテゴリ:無償評価版を選び、分割ダウンロードか一括、CS+ for CCかCS+ for CA,CX のどれかのパッケージをダウンロード後、実行すれば必要なツール全てがWindowsへインストールされます。

統合開発環境CS+パッケージ
統合開発環境CS+パッケージ(一括ダウンロードの例)

関連投稿:CS+ for CCとCS+ for CA,CXの違い

既存プロジェクトを新しいCS+で開いた時のメッセージ

以下CS+ for CCの例で示しますが、CS+ for CA,CXでも同じです。

既存のプロジェクトを開く
既存のプロジェクトを開く。BB-RL78G13-64.mtpjをクリック。

CS+ for CCを起動し、既存のプロジェクトを開くでRL78/G1xテンプレートプロジェクトのCC-RLを選択すると、最初に警告メッセージが表示され、出力パネルにその内容、プロジェクト開発当時と新しいCS+での「プロジェクトの差分情報」が表示されます。

既存プロジェクトを開いた時に表示されるメッセージとその内容
既存プロジェクトを開いた時に表示されるメッセージとその内容

※“プロジェクト差分情報”は、新規CS+をインストールした時だけでなく、プロジェクト開発中にCS+更新に遭遇した際にも表示されます。

黒字の “デバイス・ファイルが更新……”は、CS+がサポートするMCUデバイスが増えたために発生します。あまり気にする必要はありません。

青字の “プロジェクト差分情報”は、新しいCS+を用いた結果、既存プロジェクトに生じた差分、影響のことです。

例えば、CS+のCC-RLコンパイラが改良・改版され、開発当時のコンパイル・オプションには無かった [間接参照を1バイト単位で行う] 選択肢が発生し、これに関しては、「いいえ」を選択したことなどが解ります。

これらの選択は、基本的に既存プロジェクトに影響が無い(少ない)方をデフォルトとしてCS+が選びます。このデフォルト選択が、CS+の後方互換を実現している鍵です。

後方互換の検証:プロジェクトビルド成功と評価ボードの動作確認

そのままビルド(B)>ビルド・プロジェクト(B)を実行すると、サブプロジェクトを含め全プロジェクトがリビルドされます。出力パネル青字は警告:Warring、赤字はエラー:Errorを示します。

全プロジェクトビルド結果
全プロジェクトビルド結果

出力パネルに赤字が出るのは問題ですが、青字内容に問題がなければ、新規CS+でもプロジェクトが正常にビルドできたことを示します。

そこで、ターゲット評価ボードへビルド出力をダウンロード、既存プロジェクト開発当時の動作確認ができ、最新CS+で後方互換が検証できました。

CS+の便利機能

ルネサスCS+には、プロジェクトと開発ツールをパックして保存する便利な機能があります。

CS+の便利機能
CS+の便利機能。プロジェクト開発時の環境を丸ごとそのまま保存できる。

この開発ツールとは、使用中の統合開発環境のことで、文字通りプロジェクトとCS+、デバイス・ファイル情報などのプロジェクト開発時の環境を丸ごとそのまま保存し、復元もできます。
但し、当然OS:Windowsまでは保存しなので、年2回の大規模OS更新やWindows 7サービス終了などには開発者自ら対応する必要があります。

後方互換とプロジェクト開発方針

IDEの後方互換は、開発者にとっては当然のことです。ただし、改良・改版された最新コンパイラ性能を、既存プロジェクトで最大限引き出しているかは疑問を持つ方もいるでしょう。個人的には、この点について以下のように考えます。

  • プロジェクト開発時、使用する統合開発環境のコンパイル・オプションは、最適化も含めてデフォルト設定で開発。
  • サイズ優先や速度優先の設定は、開発の最終段階で必要性がある時にのみ最小限設定し、その設定をソースに明記。

例えば、弊社マイコンテンプレートは、1つを除いて全て上記方針で開発しています。除いた1点とは、NXPのLPC8xxテンプレートのLPC810(ROM 4KB/RAM 1KB)の小ROMデバイスの1段最適化のみです。テンプレート(ひな形)の性質上、いろいろなプロジェクトへの適応性が高いのもこの方針の理由です。また、デフォルト設定と最小限設定なので、結果的に最新統合開発環境への後方互換も取りやすいと言えます。

経験上、コンパイル・オプションを操作して開発したトリッキーなプロジェクトは、設計段階(MCU選択やプログラム構成)の失敗だと考えています。個人的には、デフォルト設定で十分余裕(50%程度)がある設計がお勧めです。これを確かめるためにも、プロトタイプ開発は重要だというのが私の考えです。

MCU統合開発環境、後方互換のまとめ

MCU統合開発環境(IDE)とWindows環境の年間メジャー更新スケジュールは下図です(2018年7月9日投稿の再掲)。

主要開発環境の年間更新スケジュール
主要開発環境の年間更新スケジュール

プロジェクト開発中にこれら更新に遭遇することは少なくないでしょう。本稿は、ルネサスCS+を例に最新IDEの後方互換性を確認しました。EclipseベースのIDEでも同様です。まとめると、

  • IDE更新後、最初に既存プロジェクトを開く時の差分情報で、プロジェクトに生じた差分、影響を分析し、後方互換を検証
  • コンパイル・オプションはデフォルト設定が、更新された統合開発環境の後方互換を取りやすい

ことを示しました。

RL78ファミリから解る汎用MCUの変遷

汎用MCUの定義が変わりつつあります。ルネサスエレクトロニクス(以下、ルネサス)のRL78ファミリから、最近の汎用MCUの変わりつつある現状を考察します。

RL78ファミリの汎用MCUロードマップ

2018年6月版の最新RL78ファミリMCUカタログから抜粋したRL78ファミリのロードマップです。

RL78ファミリロードマップ (出典:ルネサス汎用MCUラインアップカタログ)
RL78ファミリロードマップ (出典:ルネサス汎用MCUラインアップカタログ)

赤囲みのRL78/G1xが汎用MCU製品を示します。2014年以後は、For小型システムやForモータシステムなど、一見するとASSP:application-specific standard product、特定用途向けMCUのような製品が汎用MCUの中にあります。

これは、RL78/G1Fのコンセプトを見るとその理由が理解できます(出典:ローエンドマイコンで実現できる 高機能なブラシレスDCモータ制御

RL78_G1Fのコンセプト(出典:ローエンドマイコンで実現できる 高機能なブラシレスDCモータ制御)
RL78_G1Fのコンセプト(出典:ローエンドマイコンで実現できる 高機能なブラシレスDCモータ制御)

つまり、汎用MCU RL78/G14を、モータシステム向きに周辺機能拡張や使い勝手を向上させたのがRL78/G1Fなのです。あくまで汎用MCUがベースで、それを特定用途、この場合はモータ制御向けに調整したのです。

このメリットは、開発者、ルネサス双方にあります。開発者にとっては、使い慣れた汎用MCUの延長上に特定用途向けMCUがあるので馴染みやすく開発障壁が低くなること、ルネサスにとっては、新規ASSPを開発するよりも低コスト、低リスクなことです。

RL78ファミリの汎用MCUとは、変わる定義

RL78ファミリのMCUには、S1/S2/S3という3種類のコアがあります。数字が大きくなると高性能になります。

関連投稿:RL78 S1/S2/S3コアの分類

ルネサスの汎用MCUとは、これらS1/S2/S3コアを使ったMCU製品を指します。また、RL78/G1FのようにS3コアMCUのRL78/G14をベースとし、特定用途向け機能を付加したものも汎用MCUです。

※弊社は、S1/S2/S3コアの各汎用MCUに対してRL78/G1xテンプレートを販売中です。

販売中の汎用MCU向けテンプレートと特定アプリ向けMCUの関係
販売中の汎用MCU向けテンプレートと特定アプリ向けMCUの関係

この特定用途名が、ルネサスが考えるIoT時代にふさわしい汎用MCUと言えます。「汎用」という従来の広く漠然とした用途よりも、より「具体的な用途・応用に適す汎用MCU製品」としてRL78/G1FやRL78/G11があるのです。

特定用途向け汎用MCU開発にもRL78/G1xテンプレートが役立つ

このIoT時代の特定用途向けMCU開発でも、弊社RL78/G1xテンプレートが使えます。ベースが「汎用中の汎用」RL78/G10(S1コア)、RL78/G13(S2コア)、RL78/G14(S3コア)だからです。

例えば、RL78/G1Fのアプリケーションノートやサンプルコードは、具体的でほとんどそのまま開発製品へ適用できます。しかし、用途が限定されているだけに、逆に簡単な機能追加が難しい場合もあります。そんな時に、テンプレートが提供するサンプルコードを活かしつつ処理を追加できる機能を使うと便利です。

ここでは、ルネサス汎用MCUについて考察しましたが、NXPセミコンダクターズやSTマイクロエレクトロニクス、Cypressセミコンダクターなどの他社MCUベンダも同様です。汎用MCUの定義は、より具体的な用途・応用名が付いたIoT MCUへ変わりつつあります。しかし、基本の汎用MCUを習得していれば、より応用し発展できます。基本が重要だということです。

IoTでは、MCU開発はより複雑で高度になります。また、製品完成度の要求もさらに高まります。基本要素や技術を、(たとえブラックボックス的だとしても)積み上げられる、基礎・基本を習得した開発者のみが生き残ると思います。開発者個人で基礎を習得するために、是非弊社マイコンテンプレートをご活用ください。

2017年アナログICメーカー売上高ランキング

2017年のアナログICメーカー売上高トップ10が、5月2日EE Times Japanで発表されました。

2017年アナログICメーカー売上高ランキング(出典:記事)
2017年アナログICメーカー売上高ランキング(出典:記事)

アナログ市場全体の成長率は10%、そのうちの上位10社のみで59%ものシェアを占めます。唯一マイナス成長となったNXPは、昨年汎用ロジック/ディスクリート事業をNexperiaへ売却したためです。

MCUメーカーのアナログICシェア

2017年アナログIC売上高シェア
2017年アナログIC売上高シェア。ブログ掲載中のMCU各社もランクインしている。

本ブログで扱っているMCUベンダのSTMicroelectronics(シェア5%)、NXP Semiconductors(4%)、ルネサスエレクトロニクス(2%)などもこのトップ10に入っています。一方Cypress Semiconductors のMCU PSoC 4などは、コンパレータやアンプなどのアナログ機能が他社MCUよりも充実していますが、売上高トップ10には入っていません。ADCやDACなどのアナログ単体ICの範疇にPSoC 4が入らないためかもしれません。

これらMCU各社をハイライトして、2017年アナログIC売上高シェアをグラフにしました。Texas InstrumentsもMCUを販売していますが、ブログの対象外ですので外しています。

IoTでは、とりわけMCUのフロントエンドにアナログ機能が必要です。好調なアナログ市場の伸びに伴って、アナログ機能をMCUに搭載したデバイスが発表される可能性があると思います。

Eclipse IDEベース統合開発環境のプロジェクトImport、Renameの方法

統合開発環境のデファクトスタンダードがEclipse IDE。本ブログ対象ベンダのNXP)MCUXpresso IDE、ルネサス)e2studio、Cypress)PSoC Creator、STM)SW4STM32など全てこのEclipse IDEをベースとした統合開発環境です。

ベンダやマイコンが変わっても殆ど同じ操作でエディットやデバッグができるので、慣れが早く、本来のソフトウェア開発に集中できます。但し、オープンソース開発なので、毎年機能追加や変更があり、2018年は6月にバージョン4.8、コードネームPhoton(光子の意味)への改版が予定されています。

本投稿は、2017年版Eclipse IDEバージョン4.7、Oxygenベースの各社IDEプロジェクトインポート、リネームの方法を説明します。
弊社マイコンテンプレートを使ってソフトウェア開発をする時、これらの操作を知っているとテンプレート:ひな型活用のプロジェクト開発がより簡単です。

IDEの例としてSW4STM32を用います。IDEは、Workspace:ワークスペースと呼ぶフォルダ単位で機能します。ワークスペース内には複数プロジェクトが存在でき、2重起動ができます。

プロジェクトImport

マイコンテンプレートは、テンプレートの具体的な応用例にシンプルテンプレートプロジェクトやBaseboardテンプレートプロジェクトをArchives形式で提供します。Archives形式は、配布に都合が良くEclipse IDEの標準方法ですので、IDEダイアログに従って操作すれば「複数の方法」でプロジェクトインポートができます。

このArchiveプロジェクトの「最も簡単」なワークスペースへのインポート方法が下記です。

  • Windowsで、Archiveを適当な場所で解凍 → 事前に作成したIDEワークスペースへ解凍フォルダ毎コピー
  • IDEで、File>Import>General>Existing Projects into Workspace実行 → インポートProjects選択
Import Existing Projects into Workspace
Import Existing Projects into Workspace。プロジェクトをインポートする方法は、マルチプラットフォーム対応のEclipse IDEの場合、複数ある。

IDEで直接Archivesプロジェクトを解凍しワークスペースへインポートすることもできますが、フォルダ選択などのダイアログ操作は面倒です。マルチプラットフォーム対応のEclipse IDEたるゆえんですが、WindowsかmacOSの上で使うのであれば、この方法が簡単です。

プロジェクト名Rename

※Rename後、Renameプロジェクトの再ビルドが失敗する場合があります。Rename前に、ワークスペース毎バックアップするなどの事前対策を実施後、Renameを実行してください。

ワークスペースに複数プロジェクトが存在するには、別々のプロジェクト名が必要です。例えば、シンプルテンプレートを使って開発したプロジェクトが既にあるワークスペースへ、もう一度シンプルテンプレートを使って新たなプロジェクトを追加作成する場合を考えます。

開発したプロジェクト名は、SimpleTemplateのままです。これをRenameしないと新たにシンプルテンプレートをインポートできません。この時は、開発したプロジェクト選択後、右ボタンクリックで表示されるメニューからRenameを選択し、別プロジェクト名に変更します。

Rename Project Name
Rename Project Name。元々のEclipse IDE守備範囲外のファイル名は、手動リネームが必要。

注意点は、この操作でプロジェクト名変更をIDEは認識しますが、IDE以外のツールで作成したファイル名などは、そのままとなる点です。図はSTM)SW4STM32の場合です。Debugフィルダ下の.cfg/ioc/pdf/txtの4ファイルがそれらです。これらファイルは、手動でのRenameが必要です。これを怠るとRenameしたプロジェクトの再ビルドやデバッグが失敗します。

これら手動Renameが必要なファイルは、各社のAPI生成ツールなどに関連したファイルで、他社IDEでも同様です。元々のEclipse IDE守備範囲外のこれらファイルは、プロジェクト名Rename時、手動Renameが必要ですので注意してください。

Rename後、再ビルドが成功することを確認してください。再ビルドが失敗する場合には、プロジェクトフォルダ毎コピー&ペーストを実行し、ペースト時にRenameしたい別プロジェクト名を設定する方法でRenameを試してください。

別プロジェクトファイルのコピー、ペースト

別プロジェクトファイルを当該プロジェクトへコピー、ペーストする方法は、同じワークスペース内であれば簡単です。ファイル選択後、コピー:Ctrl+Cとペースト:Ctrl+Vでできます。

ワークスペースが異なる場合は、IDEの2重起動を使うとファイル選択ミスがありません。

IDEは、起動中でももう1つ同時起動が可能です。IDE起動時に、異なるワークスペース選択をすれば、コピー対象プロジェクトのファイルをIDEで目視しながら選択できます。もちろん、Windowsエクスプローラでファイルを直接選択しペーストも可能ですが、普段IDEで見慣れたファイル表示で選択する方がミスは少ないです。同一ファイル名の上書き前の確認も行います。

エクスプローラでファイル表示をすると、普段IDEで見慣れないファイルなども見られます。これらが選択のミスを生みます。IDEは、必要最低限のファイルのみ表示しているのです。

IDE画面のリセット

デバッグやコンソールなど複数Perspectiveを表示するIDE画面は、時に隠したPerspectiveを表示したくなります。PerspectiveをIDE初期状態に戻すのが、Window>Perspective>Reset Perspectiveです。

Reset Window Perspective
Reset Window Perspective。IDEの初期状態ウインド表示に簡単に戻せる。

この方法を知っていると、使わないPerspectiveを気軽に非表示にできるので、画面の有効活用ができます。

まとめ

Eclipse IDEベースの各社開発環境で知っていると便利な使い方をまとめます。

  • プロジェクトインポート:IDEのExisting Projects into Workspaceを使うと簡単
  • プロジェクト名リネーム:自動リネームはEclipse IDE関連のみ。API生成ツール関連ファイルは手動リネーム要。
  • 別プロジェクトファイルのコピー&ペースト:IDE2重起動を使い、ファイル選択ミスを防ぐ
  • IDE画面リセット:利用頻度の低いPerspectiveを非表示にし、画面有効活用
Eclipse Base IDE Project Import and Rename
Eclipse Base IDE Project Import and Rename

マイコンテンプレート活用の最初の段階が、テンプレートプロジェクトのワークスペースへのインポートです。これらインポートしたテンプレートへ変更を加え、開発プロジェクトにします。

この開発プロジェクト名をリネームし、同じワークスペースへ、再びテンプレートプロジェクトをインポートします。ワークスペース内は、リネームした色々な既成開発プロジェクトから成り、様々なプロトタイピング開発へも応用できるでしょう。

ワークスペースが異なるファイル操作には、IDE2重起動でファイル選択のミスを防ぎます。

これらのTipsを知っていれば、既存資産を流用、活用し、本来のソフトウェアに集中しミスなくプロトタイピング開発ができます。

ルネサス世界初28nm車載マイコンサンプル出荷

ルネサスエレクトロニクスは2018年3月28日、車載マイコンRHファミリに28nmプロセス採用マイコンのサンプル出荷を開始しました。従来の40nmに比べ、高性能、低消費電力で大容量フラッシュメモリ内蔵の世界初、世界最高性能のルネサスオリジナルコアマイコンです。

ルネサスマイコンの命名則

車載マイコンRHファミリは本ブログ対象外です。しかし、車載マイコンが、全てのマイコンを引っ張って発展させているので、注目しています。ここでは、ルネサスマイコンの名前の付け方を簡単に説明します。

先頭に「R」が付くのが新生ルネサス誕生後に発売のマイコンです。汎用マイコンが、図のRL78、RX、RZの3ファミリ、車載アプリケーション特化マイコンが今回発表のRHファミリです。

一部例外はあるものの、殆どがルネサスオリジナルのNon ARMコアマイコンです。

ルネサス汎用マイコン
ルネサス汎用マイコンファミリ。用途、性能に応じてRL78、RX、RZと3ファミリある。(出典:汎用マイクロコンピュータラインアップカタログ)

汎用マイコンだけでも、用途や性能(ルネサスはソリューションと呼ぶ)に応じてRL78、RX、RZと3ファミリあり、さらにそのファミリの中で、RL78/G1x、RL78/F12など細かくシリーズに分かれた名前構造なので、解り難いです。

ちなみに本ブログ対象はRL78ファミリですが、RXも対象に入れるか検討中です。個人レベルでも開発環境を整え易いか否かが基準です。RXファミリの場合、実装メモリが大きいのに無償Cコンパイラの容量制限≦128KBがネックになっています。

他のH8や78K0Rなどは、日立やNEC、三菱電機などルネサスに統合前の各社マイコンの名称です。簡単に旧マイコン名が消える海外ベンダと異なり、旧会社のマイコン名をいつまでもカタログに記載するのも善し悪しです。

ルネサスSynergyは、これらNon ARMコアとは別に他社に遅ればせながら開発したARMコアマイコンファミリです。遅れた分、他社同様の売り方はせず、ルネサスSynergy Software Packageというルネサスが動作保証する専用ライブラリを提供し、開発者がアプリケーションのみを開発する方法で販売中です。個人レベルでは、特に価格で手を出しにくいと思っています。

28nmプロセス、大容量メモリの用途

ルネサスRHファミリで向上された性能を、具体的にどこで使うのかが解る図が、記事にありました。

大容量メモリの利用割合
大容量メモリの利用割合。アプリ増加比率よりも、データ、Safety、Security、Driversの増加比率が大きい。OTA利用により最低2面構成のメモリが必要の可能性もある。(出典:記事)

左側の色分けメモリマップから、アプリケーションのメモリ比率の増加よりも、Data、Safety、Security、Driversの増加比率が大きいことが判ります。つまり、開発するアプリケーションよりも、アプリが使うデータや安全性確保、ドライバーの増加がメモリ増大要因です。このドライバーの中にアプリが使うライブラリなども含まれると思います。

また、図では判りませんがOTA:Over-The-Airには、同じメモリが最低2面必要になるかもしれません(関連投稿は、コチラのIoT端末の脆弱性対応はOTA更新が必須を参照)。OTAに万一失敗しても、最悪更新前に戻るには、更新前と更新後のメモリが必要なのがその理由です。

いずれにしても大容量メモリは必須です。また、プロセス細分化でより低消費電力で高速動作を実現しています。
大容量メモリ実装、プロセス細分化は、車載マイコンに限った話ではありません。汎用マイコンでも同じです。

製造は、世界最大の半導体製造ファウンダリである台湾)TSMCが行うので、パソコンのCPU同様、マイコン:MCUも28nmプロセスへ一気に変わる可能性もあります。

半導体プロセス微細化の懸念

一方で、半導体プロセスの微細化は利益につながるのか2018年3月28日、EE Times Japanという記事もあります。28nmよりも先、10nm以下のモバイルプロセサでの話ですが、マイコンでもいずれ同じ時代が来るでしょう。

汎用マイコン技術は、先行する車載マイコンやモバイル半導体技術をベースに発展します。

先行の動向を知ることは、無駄ではありません。少し先を見越して、隠しコマンドなど遊び心がある工夫をソフトウェア、ハードウェアにこっそり入れておくのも開発者の数少ない楽しみの1つだと思います。

マイコン評価ボード2018

マイコン装置を開発する時、ベンダ提供のマイコン評価ボードは重要です。良いハードウェア、良いソフトウェアは、評価ボードをレファンレンスとして活用した結果生まれるからです。

今回は、ARMコア対Non ARMコアという視点で最新マイコン評価ボードを分析します。掲載マイコン評価ボードは下記です(価格は、調査時点の参考値)。

デバッガの2機能

ベンダ評価ボードには、デバッガ付属とデバッガ無しの2タイプがあります。デバッガは、

  1. デバッグ機能:ソースコードのダウンロード、ソースコード実行とブレークを行う
  2. トレース機能:プログラムカウンタ実行履歴を記録する

の2機能を提供します。

トレース機能は、プログラムカウンタ遷移を記録し、ハード/ソフトの微妙なタイミングで発生するバグ取りなどに威力を発揮します。が、本ブログで扱うマイコンでは利用頻度が低く、サポートされない場合もありますので、デバッグ機能に絞って話を進めます。

各社が独自コアマイコンを供給していた頃は、各社各様のデバッガが必要でした。しかし現在は、ARMコアマイコンとNon ARMコアマイコンの2つに大別できます。

ARMコアマイコンの評価ボード

ARMコア評価ボードは、ARM CMSIS規定のSWD:Serial Wire Debugというデバッグインタフェースでコアに接続します。SWDを使うと、他社ARMコアとも接続できます。このため、評価ボードのデバッガ部分と対象マイコンを切り離し、デバッガ単独でも使えるように工夫したものもあります。

ARMコア評価ボードの多くは、対象マイコンにSWDインターフェイスのデバッガが付属しています。これは、対象マイコンが変わってもデバッガは全く同じものが使えるので、量産効果の結果、デバッガ付き評価ボードでも比較的安価に提供できるからです。

CY8CKIT-146
SWDデバッガ付属評価ボードCY8CKIT-146 (出典:CY8CKIT-146 PSoC® 4200DS Prototyping Kit Guide)

また、統合開発環境:IDEもEclipseベースを採用すれば、実行やブレークのデバッガ操作方法も同じになり、例え異なるベンダのARMコアでも同じようにデバッグできるので開発者にも好評です。

以上が、マイコンのデファクトスタンダードとなったARMコアとEclipseベースIDEを多くのベンダが採用する理由の1つです。

Non ARMコアマイコンの評価ボード

一方、Non ARMコアマイコン評価ボードは、本来コア毎に異なるデバッガが必要です。そこで、評価ボードには対象マイコンのみを実装し、その購入価格は安くして、別途デバッガを用意する方法が多数派です。

機能的には同じでもコア毎に異なるデバッガは、サポートするコアによりデバッガ価格が様々です。例えば、ルネサスのE1デバッガは、RL78、RX、RH850、V850の4コアカバーで12600円ですが、RL78とRXコアのサポートに限定したE2 Liteデバッガなら、7980円で購入できます(2018年3月の秋月電子価格)。

RL78/G11評価ボードとE1
RL78/G11評価ボードとE1

ルネサスもE1/E2 Liteデバッガ付きのRX用低価格評価ボード2980円を2018年3月に発表しました(マルツエレック価格)。

E1、E2 Liteデバッガ付きRX評価ボード
E1、E2 Liteデバッガ付きRX評価ボード (出典:Runesasサイト)

※RX評価ボードは、無償CコンパイラROM容量制限(≦128KB)に注意が必要です。入手性は良いので容量制限を撤廃してほしいです。

個人でマイコン開発環境を整える時は、購入価格は重要な要素です。マイコンがARMコアかNon ARMコアか、デバッガ搭載かなどにより、評価ボード価格がこのように異なります。

標準インターフェイスを持つマイコン評価ボードの狙い:プロトタイピング開発

最近の傾向として評価ボードの機能拡張に、Arduinoコネクタのシールド基板を利用するものが多くなりました。様々な機能のシールド基板とその専用ライブラリが、安く入手できることが背景にあります。

ARMコア、Arduinoコネクタ、EclipseベースIDEなどの標準的インターフェイスを持つマイコン評価ボードの狙いは、色々なマイコン装置の開発を、低価格で早期に着手することです。既存で低価格なハード/ソフト資産の入手性が良いのが後押しします。

中心となるマイコン評価ボードへ、機能に応じたシールド基板を実装し、早期にデバッグしてプロトタイピング開発し製品化が目指せます。

CY8CKIT-046
Arduinoコネクタを2個持つCY8CKIT-046、緑線がArduinoコネクタ (出典:CY8CKIT-046 Qiuck Start Guide)

ルネサスもEclipseベースのIDE:e2Studioを提供中ですが、これは世界中のEclipse IDEに慣れた開発者が、ルネサスマイコンを開発する時に違和感を少なくするのが主な狙いだと思います。Non ARMルネサスマイコン開発の不利な点を、少しでも補う方策だと推測します。

関連する過去のマイコン評価ボード投稿

あとがき

ルネサス最新汎用マイコンRL78/G11は気になります。従来のRL78/G1xに比べアナログ機能を大幅に強化し、ローパワーと4μsの高速ウェイクアップを実現しています(詳細情報は、コチラ)。開発資料の多くがe2Studioで、CS+ではありません。Non ARMコアなので他社ARM比、特に優れたマイコンの可能性もあります。

 

マイコンソフトウェア開発の基礎知識と開発方法、配布開始

1月末に3回に分けて投稿した「マイコンソフトウェア開発の基礎知識と開発方法」を1つのpdf資料にまとめました。弊社マイコンテンプレートサイトのアプリケーション開発手順のページから、どなたでも無料ダウンロードが可能です。

Sample Software First and MCU Template
Sample Software First and MCU Template

この資料は、Sample Software Firstについて説明しています。マイコンテンプレートを使ったアプリケーション開発手順と合わせて読んで頂くと、マイコンソフトウェアの開発方法がより解り易くなると思います。

今後、ご購入頂いたマイコンテンプレートの付属資料としてこの資料も添付する予定です。

マイコンテンプレート購入検討中の方、既に購入された方でも、ご活用ください。

NXPとルネサスのMCU開発動向

NXPとルネサス、両社幹部が語ったMCU開発動向記事から、弊社ブログARM Cortex-Mシリーズ、16ビットMCU RL78関連部分をピックアップしました。動向記事は下記です。

NXPのMCU開発動向

記事によると車載MCUは、製品群をS32 Automotive PlatformでARMアーキテクチャ(Cortex-A、Cortex-R、 Cortex-M)に全て統一し、基本的なペリフェラル、メモリインタフェースを共通化、S32デバイス間ならソフトウェアの90%を再利用できるそうです。

同時にS32 MCUは、自動車用機能安全規格である「ASIL-D」に対応し高度セキュリティを担保、また完全なOTA(Over the Air)機能もサポート予定です(OTAはコチラの投稿参照)。

S32製品は、2018年1Qサンプル出荷、2019年から量産予定です。

Common Hardware Architecture Platform (Source: NXP)
Common Hardware Architecture Platform (Source: NXP)

この車載MCU開発動向は、本ブログ対象の家庭や個人向けCortex-MコアMCUへも影響を与えると思います。NXPはFreescale買収後、LPCとKinetisの2つのCortex-Mシリーズ製品を提供中です。

ARM Cortex-M Core Kinetis and LPC
ARM Cortex-M Core Kinetis and LPC

S32製品の強み、ハードウェア共通化、ソフトウェア再利用、セキュリティ確保、OTAは、そのまま現状NXPの 2製品並立Cortex-Mシリーズへも適用される可能性が高いと思います。その方がNXP、新規ユーザ双方にとって開発リソースを集中し易いからです(現行ユーザには多少インパクトがありますが、Cortex-Mコアは同じなので、SDKなどが変わるかも?!しれません…)。

ペリフェラルが共通化されれば、サンプルソフトも同じになるでしょう。ソフトウェア90%再利用は、ライブラリ充実化も見込めます。差分の10%は、Cortex-コア差、セキュリティレベル差、応用範囲などになる可能性があり、期待できそうです。

ルネサスのMCU開発動向

ルネサスは、2018年夏発売予定のRZファミリで、組込みAIによる推論モデル処理能力を10倍、2019年末までに更に10倍、2021年で10倍にし、推論処理能力を1000倍にするそうです。このために動的に再構成可能なプロセサ技術「DRP(Dynamically Reconfigurable Processor)」を汎用MCU製品へ取り込んでいくそうです。

RZファミリ:現状ARM Cortex-A9 400MHz採用の家電、カーオーディオなどが対象のMCU。

Cortex-AコアのRZファミリとRL78の比較(Source: Runesas)
Cortex-AコアのRZファミリとRL78の比較(Source: Runesas)

能力向上したAI推論により、振動などの画像データを扱えるようになり、さらにはそのフレームレートも高められ、例えば、熟練工のノウハウをエンドポイントで自動化できるようになる。1000倍ともなれば、現在はエンドポイントでは難しいとされる学習も行えるようになるそうです。

産業機器分野では、自動化やロボット化の実現に関わる異常検知、予知保全、認知検査などにAI処理能力を適用予定です。

1月14日投稿のルネサスe2 studioのAI利用無償プラグインで開発環境を提供しますが、弊社対象のRL78ファミリでどの様に実現されるかは不明です。

AI処理能力を1000倍化(Source: Runesas)
AI処理能力を1000倍化(Source: Runesas)

正常進化のNXPと差別化のルネサス

NXP、ルネサスともにARMコアMCUの開発動向は似ています。ルネサス幹部が、汎用MCU統括のため、あえて産業分野にフォーカスして語っただけと思います。

差分は、NXPがARMアーキテクチャの正常進化とも言えるソフトウェア資産の共通化を全面に推しているのに対し、ルネサスは、差別化DPR技術で推論機能の1000倍化を目指す点です。
※正常進化の根拠は、コチラの投稿のCMSIS参照

この差別化がガラパゴスになるのか、それとも光る技術になるか、今年夏頃の新製品RZファミリに注目します。

マイコンソフト開発の基礎知識と初心者、中級者向け開発方法(最終回)

前回までで初心者、中級者向けマイコンソフトの基礎知識と開発方法に、俯瞰視野でサンプルソフトを選び、サンプルソフト初期設定とループ内処理をライブラリとして評価ボードで動作確認しながら開発するサンプルソフトファーストの方法を述べました。

この方法は、サンプルソフトをジグソーパズルのピースとし、各ピースを弊社マイコンテンプレートへ入れさえすれば開発できるので、楽しくラクにマイコンソフトウェア開発ができます。

サンプルソフトを組合せるマイコンソフトウェア開発
サンプルソフトを組合せるマイコンソフトウェア開発

日本人は、サンプルソフトのコメントや概要記述の英語が苦手です。最終回は、ソフトウェアに使われる英語、特にサンプルソフト英語の扱い方を示し、本開発方法を総括します。

マイコンサンプルソフトの英語コメントは重要

初期設定+無限ループ内の1周辺回路制御という構造:フォーマットが決まっているマイコンサンプルソフトは、英語圏開発者によるものが殆どです。

彼ら彼女らにとって母国語英語ベースのC言語サンプルソフトは、ソースコードだけでも理解に支障はありません。また、関数をモニタ1画面(80字x 25行)以内の行数で記述する傾向もあります。ページスクロールせずに関数全体が見渡せるからです。

C関数の行数
C関数の行数

このような英語圏開発者があえて追記するコメントは、重要事項のみです。数行にまたがるコメントならなおさらです。つまり、なぜコメントしているかを理解することが大切です。といってもソースコードのコメント英語は、解り難いのも事実です。

英語コメントはブラウザ翻訳で日本語化

ブラウザアドレス窓に「翻訳」と入力すると、ブラウザ上で翻訳ができます。長い数行の英文でも瞬時に日本語になります。

ブラウザ翻訳
ブラウザ翻訳

サンプルソフトの英語コメントが解り難い時は、ブラウザ翻訳を使い日本語で読むと内容理解に効果的です。

マイコンソフト開発の基礎知識と初心者、中級者向け開発方法(総括)

従来のマイコンソフトウェア開発は、マイコンデータシートなど理解が先、次に理解した情報のプログラミングという順番でした。この方法は正攻法ですが、初心者、中級開発者には、限られた開発期間で理解対象が多いため開発障壁が高く、プログラミングの時間も相対的に短くなります。

マイコン応用製品の早期開発には、プログラミングを先にする方法へ見直すことが必要です。

それには、初心者、中級開発者が元々持つ俯瞰視野とサンプルソフト、ライブラリ、評価ボード、ブラウザ翻訳などの既存資産を上手く利用すれば良いのです。Arduinoシールドを使えば評価ボードへの機能追加も簡単で、製品版に近い開発環境でのプログラミングも可能です。

本投稿は、初心者、中級者向けのマイコンソフト開発の基礎知識として、サンプルソフト資産が多数あること、多くのサンプルの中から対象を絞り、一種のライブラリとして動作確認しながらソフト開発をするサンプルソフトファーストの方法を示しました。

IoT時代は、RTOSやセキュリティ知識など、より多くの情報を取り込んだマイコンソフトウェア開発になります。個々の情報の相対的な重要性さえ理解していれば、情報内容の理解よりも開発するソフトウェアへ組込む能力の比重が、ますます高まるでしょう。

開発者がこだわるべきは、短い期間内で開発するソフトウェア出力です。情報理解は、開発後でもOKです。