RL78/G1xテンプレートのCコンパイラパッケージリビジョンアップ対応状況

2016年7月16日号RUNESAS TOOL NEWSで、RL78ファミリ用CコンパイラパッケージV1.03.00のリビジョンアップが通知されました。7月21日からCS+アップデートの確認、または、アップデート・マネジャーで更新可能です。

弊社RL78/G1xテンプレートは、2015年7月4日にRL78-S1/S2/S3コア全てに対応のVer5を発売して以降、変更を加えていません。そこで、RL78/G1xテンプレートVer5の上記CコンパイラV1.03.00対応状況を報告します。

CS+出力パネル

アップデート・マネジャーでCコンパイラアップデートを実行後、最初にCS+を起動すると、警告(W0202005)ダイアログが表示されますのでOKをクリックします。この警告は、更新など何らかの変更がCS+に加わった時に注意喚起を促すダイアログで、出力パネルに下記のような詳細内容が表示されます。

CS+出力パネル警告
CS+出力パネル警告

青字が変更箇所です。黒字は、お使いの環境設定により異なりますので、無視してください。

さて、今回のCコンパイラリビジョンアップで、RL78/G1xテンプレートVer5を再コンパイルします。方法は、ビルド(B)>クリーン・プロジェクト(C)を実行後、リビルド・プロジェクト(R)を実行します。出力パネルに下記結果が表示されます。

CS+出力パネル0エラー
CS+出力パネル0エラー

私のCS+は、評価版インストール後かなり経過していますので評価期間切れの警告が表示されますが、無視してください。

0エラーですので、今回のCコンパイラパッケージリビジョンアップに対して、RL78/G1xテンプレート付属の下記6プロジェクトに対して問題なく動作します。動作確認評価ボードは、コチラに一覧写真があります。

RL78/G1xテンプレートVer5のプロジェクトとRL78コア、評価ボード
CS+プロジェクト名 RL78対応コア 動作確認評価ボード
BB-RL78G13-64(プロジェクト) RL78-S2コア BlueBoard-RL78G13-64
RL78G13-PB(サブプロジェクト) RL78-S2コア G13スタータキット:RL78G13-Stick
RL78G14-PB(サブプロジェクト) RL78-S3コア G14スタータキット:RL78G14-Stick
QB-R5F100LE-TB(サブプロジェクト) RL78-S2コア QB-R5F100LE-TB
QB-R5F104LE-TB(サブプロジェクト) RL78-S3コア QB-R5F104LE-TB
QB-R5F10Y16-TB(サブプロジェクト) RL78-S1コア QB-R5F10Y16-TB

プロジェクト内容やマイコンテンプレート概要等は、マイコンテンプレートサイトからPDFダウンロードができますので参照ください。

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

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

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

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

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

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

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

英語環境のすすめ

ルネサス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は、圧倒的大多数を市場で占めているのでガラパゴスでも生き残れます。

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

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

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

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を早く効果的に習得するコツは、コチラのページにまとめています。

マイコンでBLE実現の3方法

レガシーなUARTは簡単に使えるマイコン開発者でも、BLE:Bluetooth Low Energyは、新しくかつ仕様も追加されつつあるので手を出しにくいものです。しかし、いざBLEを仕事で使う段になれば、いつものように、厳しいスケジュールでの開発が要求されます。

そのような開発者個人が、入手性が良いマイコン:MCUで電波法の縛りがある日本国内でBLE通信を自習する方法を3つ紹介します。

BLE習得3方法

仕事での開発と違い、個人でBLEの開発環境を整える場合は、「入手性とその金額」が問題になります。金額ベースで安い順に3方法を評価したのが下図です。

BLE実現3方法
BLE実現3方法

Cypress PSoC 4 BLE利用の方法1は、低コスト($49)で環境構築可能ですが、多少BLE仕様を理解する必要があります。しかし、BLEを習得するならお勧めの方法です。

BLEモジュール追加の方法2は、マイコンUART入出力にBLEモジュールを追加する方法です。
マイコン以外にBLEモジュールが必要なため、追加コスト(図示、浅草技研BLESrialの場合4000円)が必要ですが、BLEを無線のドカン(UART over BLE)として使えるので、BLEをブラックボックスとして扱えるのが魅力です。
方法1と方法2のコスト差は、使用マイコンにも依存するので大差ありませんが、後で示す仕様変更時に差が出ます。

ルネサスRL78/G1D利用の方法3は、BLE機能を持つルネサスRL78マイコンを使うので技術資料が日本語ですが、開発には高価な有償版CS+と評価ボードが必要になります。RL78マイコンを仕事で使っている場合は、有利かもしれません。

BLE仕様が変わる現状への対処

マイコンBLEの通信相手は、前回示したMPU/SBCなどのIoT向けPCの他に、スマホが使えます。

スマホBLEには、「BLE 4.0/4.1/4.2など様々な仕様」があります。多くの通信仕様のように、下位互換性がありますが、セキュリティなどの機能強化が図られており、結果、対応マイコンにはますます大容量ROMや高性能化が要求されます。

このようなBLE仕様の変化や仕様追加に対して、PSoC 4 BLE: CY8CKIT-042-BLEは、実装CPUモジュール($15)の載せ替えで対応します(コチラの記事を参照)。一方、BLEモジュール追加の方法は、モジュール購入時で仕様が固まっているので、変更には対応モジュールの再購入が必要です。

総合評価結果

入手性とその金額、BLE仕様変更への対応から、PSoC 4 BLEを使った方法1が、コスト的にも、BLEに関するCypress日本語資料も少なからずありますので、個人でBLE習得するには最も優れた方法だと思います。

IoT時代は、UARTと同じレベルでBLEを使うことが必須です。仕事でせかされる前にBLE技術を習得しませんか? 弊社PSoC 4 BLEテンプレートもお役に立てると思います。

マイコンテンプレート利用のコツやTips:その3

マイコンテンプレートを利用するコツ/Tipsの第3回目は「時分割処理のタイミングとインタフェースRAM」について示します。
販売中のテンプレート処理起動の間隔は、250us/1ms/10ms/100ms/1s/無限ループの6種類です。この6種類の使い方を示します。

処理起動タイミング

マイコンの処理は、電源投入後、「1回のみ実行する」スタート処理と、無限ループで「繰り返し実行する処理」の2つに大別できます(ROM/RAMを初期化するなどのスタートアップ処理は、除いています)。

ここでは無限ループに代わってテンプレートが実行する、繰り返し実行する処理の間隔:「タイミング」を考察します。

テンプレートは、起動する処理が無い無限ループ:空き時間で起動するのは、Sleepなどの低消費電力処理であることは、第2回で示しました。

100msと1sの起動間隔は、マイコンにとっては「遅い処理」、例えば、LED点滅や、LCD初期設定、SWチャタリング対策の起動に適しています。
※LCD初期設定は、無限ループ前のスタート処理で実行することも可能です。

1msと10msの起動間隔は、「早い処理」、例えば、割込みの応答処理などの起動に適しています。

250us起動間隔は、「最も早い処理が必要」な、例えば、UART/I2Cなどのデータ受信処理を起動することを想定しています。

つまり、早いレスポンスが必要な処理ほど処理間隔が短く、起動される処理のソース記述位置も上側になるのです。これがテンプレート時分割起動の「基本的な使い方」です。

実例が下図です。赤/緑/青LEDを、0.5/1/2秒毎にトグル点滅する場合です。赤囲みが、テンプレートへ追加されたLEDトグル処理を表します。それ以外が、テンプレートに初めから記述済みの起動処理です。

LED点滅処理での優先順位の例
LED点滅処理での優先順位の例

起動間隔

起動の間隔は、第2回で示したtick interruptの発生間隔です。
1ms>10ms>100ms>1sの順にレスポンスが早くなりますが、250usだけ特別に超高速応答です。これは、UART受信などの主として「いつ発生するか判らない応答に早く即応する」ためです。

販売中のテンプレートは、全てこの250usを起動間隔として開発しておりますが、実は「250usである必要性は無い」のです。因みに、FreeRTOSなどの組込OSでもtick interruptは1msです。

250usは、経験的にこの最高速でこれまで利用に問題が無かったからです。
この起動間隔を1msにし、UART受信処理を1ms起動に変更しても、メニュードリブンテンプレート動作などには問題ありません。
メニュードリブンテンプレートは、当該マイコンのUART受信バッファが1バイトでも、UARTコマンド長も1バイトなので、受信完了確認後ゆっくりバッファからデータを取り出しても間に合うからです。

起動間隔の設定は、テンプレート購入者様が「独自判断で設定して頂いても構いません」。

但し、250usよりも高速:短くすることは無いと思います。これよりも短いと、処理分割をより細かくする必要があり、開発がより厳しくなるからです。逆に、250usよりも長くすると、処理分割は楽になります。

テンプレートは、マイコン「コア動作速度を最高速」に設定し、起動間隔も「最高速と思われる250us」でデフォルトは設定しております。これは、「最初」にマイコンの最大能力で動作するアプリケーション開発後、「次の段階」としてコア周波数を下げるなどで、低消費電力化するアプローチを想定しているからです。

インタフェースRAM

処理間のデータやり取りにインタフェースRAMを使うことは、第1回で示しました。ルネサスのRL78/G1xは、通常RAMよりも高速アクセス可能なSADDRを持つなど特殊な例もありますが、低価格マイコンではRAMが貴重なリソースであることに変わりはありません。

この貴重なRAMを使う時に、ビット単位構造体を使い、ビット単位フラグでデータをやり取りすると、1バイトRAMで最大8個のフラグを使えるので効率的です。

テンプレートでは、このビット単位アクセスを容易にするため、userdefine.hにユーザ型定義を追記しております。処理間にブラグを多用する場合などにご活用ください。

マイコンテンプレートとは?

第1~3回で示したテンプレートは、「ISRは、サンプルプログラムを一部またはそのまま流用し、その他全処理をポーリング起動するマルチタスク処理の骨組み」と説明すると理解が早いかもしれません。

割込み処理は、ISRで割込みフラグ処理のみを行い、ISR発生をポーリングし割込み実処理を起動する。
サンプルプログラムの無限ループポーリングとの差は、処理に応じた時分割ポーリングである。
骨組みのテンプレートへ、サンプルプログラム流用の処理を組込んでプロトタイピング開発をする。
この理解で良いと思います。

ポイントのまとめ

  • 処理起動間隔は、250usとしているが、変更は可能、かつ任意
  • 高速な応答が必要な処理は、短い起動間隔へ配置
  • インタフェースRAMの効率的な利用に、ビット単位構造体も有効

* * *

3回に分けてマイコンテンプレート利用のコツ/Tipsを示しました。これらは、ソフトウエア開発では当然の事柄とダブる部分も多くありますが、数値では表せないのであえてコツ/Tipsとして記載しました。

組込OSを使うよりも簡単で、サンプル流用も可能なマルチタスク実現テンプレートが、お判り頂けたと思います。

販売中のマイコンテンプレートを活用し、アプリケーションの早期開発を成功させてください。

CA78K0Rコンパイラ V1.71回避不能バグ

2月1日発行のルネサスツールニュースで、RL78/G1xの「CA78K0Rコンパイラ V1.71の回避不能なバグ」が報告されています。

RL78/G1xテンプレートVer5のCA78K0Rコンパイラ版でも、報告記載の「volatile」や「前置インクリメント」を使っていますが、こられバグに該当しませんので安心してください。
但し、テンプレートを使ってアプリを開発された方は、ニュース内容に目を通し確認することをお勧めします。

RL78_G1xテンプレートの動作コンパイラP3より抜粋
RL78_G1xテンプレートの動作コンパイラP3より抜粋

ニュース最後に、「次期バージョンで改修する予定」と記載されていますので、ディスコンを懸念したCA78K0Rも改版されるかもしれません。しかし個人的には、CC-RLコンパイラへの乗換えをお勧めします。

マイコンテンプレート利用のコツやTips:その2

マイコンテンプレートを利用するコツ/Tipsの第2回目はテンプレートの「マルチタスク処理の実現方法」を示します。

組込OSの分割起動

シングルコアのマイコンで、マルチタスク処理の実現方法が、「処理の分割起動」です。
組込OSは、この分割処理=タスクの起動をOSが行います。FreeRTOSの“USING THE FREERTOS REAL TIME KERNEL”から抜粋したFigure 4は、このことを解り易く示しています。

OSのKernelは、tick interrupt毎にタスク切り替えを行います。t2でTask1は「強制的に中断」され、Task2へ切り替わります。t3では、Task2が強制中断され、Task1が「中断処理から再開」されます。

FreeRTOSの分割起動
FreeRTOSの分割起動

ある時刻で動作する処理は、Kernelを含めて1個ですが、tick interrupt毎に処理を切り替えてマルチタスク処理を実現します。

テンプレートの分割起動

分割起動は、テンプレートでも同じです。テンプレートは、第1回目で説明した「細かく分割した処理」をtick interrupt毎に時分割で起動します。組込OSとの差は、(簡単に説明すると)起動処理を強制的に中断したり、再開したりする機能が無いことです。

マイコンテンプレートの分割起動
マイコンテンプレートの分割起動

起動処理1の中断機能が無いので、t2のタイミングまでに「処理1が終了」していることが必要になります。

処理終了のための分割

この「処理終了」は、どうすれば得られるのでしょうか?

第1回説明の「細かい処理の分割」は、結果として処理時間も短くなり、この処理終了をもたらします。

マイコン処理分類(注意点)
マイコン処理分類(注意点)

注意すべきは、赤丸の処理の完了確認が必要な入出力処理です。しかし、ここを「完了確認の処理」と、「その結果で動作する処理」の2つに分けて開発すれば、問題解決です。それぞれの処理が短時間で終了するからです。

同じように割込み処理も、基本的にISR: Interrupt Service Routine内では、「割込み発生確認と割込み要因のクリア」のみを行い、「割込みの結果で動作する処理は別処理」として分割して処理化します。

このような処理分割により、デバッグが容易となり、別アプリへ流用/応用性、部品化も高まります。

勿論、サンプルプログラムのISR処理を「そのまま流用」してもテンプレートへ組込んでもOKです。サンプルプログラムが提供する典型的なISRは、処理時間が短い場合が殆どでだからです。

分割起動後の処理

起動処理で起動される側の処理時間が短くなると、起動処理へ戻る時間が増えます(上図ピンク)。この戻った時の処理が、無限ループの処理です。

テンプレートでは、無限ループ内で起動する処理は、低電力処理のSleep(またはDeep Sleep)です。
この結果、高速マイコンであればある程この「無限ループ:空き時間」が長くなり、マイコン消費電力の大部分を占めるコア動作を停止するSleepを効果的に使えます。

ポイントのまとめ

  • 処理時間を短くするため、「確認処理」と「その結果の処理」を分離
  • 起動処理無しの「空き時間」は、低消費電力処理を起動(SleepとDeep Sleepの差には注意)

次回予告

テンプレートが処理を分割し、これを分割起動するマルチタスク処理の実現方法を示し、処理分割のコツ/Tipsを示しました。次回は、「時分割のタイミング」について説明する予定です。