FreeRTOSアプリケーションテンプレート発売

FreeRTOSアプリケーションテンプレート動作中
FreeRTOSアプリケーションテンプレート動作中

ARM Cortex-M4コア動作のFreeRTOSアプリケーションテンプレート第一弾、NXP)LPCXpresso54114対応版(税込2000円)を本日より発売します。概要、要点、FreeRTOSアプリケーションテンプレートとは、に関する説明資料は、コチラから無料ダウンロードできますのでご覧ください。

開発背景

IoT MCUのクラウド接続には、AWSならAmazon FreeRTOS、Microsoft AzureならAzure RTOSなどのRTOSが必要です。クラウド側からは、1つのRTOSライブラリを使って様々なMCUハードウェアを接続するための手段、これがRTOSです。

一方、IoT MCU側からは、接続先サービスに応じたRTOSライブラリ利用に加え、従来のベアメタル開発からRTOS上でのアプリケーション開発へ発展する必要もあります。IoT化に伴うこのような変化に対し、開発者個人が手間なく対応するためのツール、これが弊社FreeRTOSアプリケーションテンプレートです。

MCU RTOS多様化対策のFreeRTOSアプリケーションテンプレート
MCU RTOS多様化対策のFreeRTOSアプリケーションテンプレート

目的

FreeRTOSアプリケーションテンプレートの目的は、「RTOS基礎固め」と「FreeRTOSプロトタイプ開発のスタートプロジェクトとなること」の2点です。

RTOS開発は、ベアメタル開発とは異なります。

RTOS Kernelが、開発した処理(タスクやThread)と他タスクの優先順位により、処理実行/待機を決めます。開発タスク単体の流用性は高まりますが、タスク間同期や通信に、セマフォやQueueなどのRTOS独特の手段が必要です。

IoTにより全てのモノ(MCU)がクラウドへ接続する時代の基盤は、RTOSです。

ベアメタル開発経験者が、このRTOSの早期基礎固め、Kernelと自身で開発したタスクの並列処理を理解するには、個々にRTOS手段を説明するサンプルソフトよりも、具体的なRTOSアプリケーションの方が実践的で役立ちます。

RTOSアプリケーションがあれば、優先順位を変えた時のタスク動作変化や、その他経験に基づいたRTOS実務開発で知りたい事柄を手間なく試し、新たな知見・見識を得られるからです。これらは、サンプルソフトや、説明文から得ることは困難で、実際のRTOSアプリケーションで開発者自身が試行するのがベストです。

そこで、各FreeRTOS手段を説明した弊社MCU RTOS習得ページを理解した次の段階として、最初の図に示したプロトタイプ開発着手に必須となるADC/LCD/SW/LED/VCOM処理を、NXP)LPCXpresso54114(Cortex-M4/150MHz、Flash/256KB、RAM/192KB)とBaseboard、Arduinoプロトタイプシールドに実装し、動作確認済みRTOSプロジェクトが、FreeRTOSアプリケーションテンプレートです。

FreeRTOS Application Template (NXP Version)
FreeRTOS Application Template (NXP Version)

※上記プロジェクトは、クラウド接続は行っておりません。RTOS基礎固めとFreeRTOSプロトタイプ開発に適すことが目的ですので、クラウド接続RTOSライブラリは未実装です。

FreeRTOSを選んだのは、現在MCU RTOSシェア1位だからです(関連投稿はコチラ)。RTOS手段は、各RTOS共通技術であるSemaphoreとQueueの2つを用いております。LPCXpresso54114のFlashやRAM使用量にはまだ十分余裕がありますので、より高度なミューテックスやイベントグループなどの手段を適用するのも容易です。

特徴

本テンプレートには、上記FreeRTOSプロジェクトと同じ動作確認済みのベアメタル開発プロジェクトも添付しております。これは、ベアメタル開発に慣れた方が、FreeRTOSとベアメタルの差分をより明確に理解し、比較や評価をするためです(比較・評価は、ご購入者ご自身で行って頂きます)。

本テンプレート付属説明資料は、主にベアメタル開発者視点から見たFreeRTOSプロジェクトを解説しており、ベアメタルプロジェクトに関する説明は、ソースコードを読めばご理解頂けるとして省略しております。

従って、FreeRTOSアプリケーションテンプレートは、ベアメタル開発経験者を対象といたします。ベアメタル初心者の方は、先ずは各MCUベンダCortex-M0+/M3コア対応の従来マイコンテンプレートをご購入ください。従来テンプレート付属説明資料には、ベアメタル動作の詳しい説明が付いています。

※本テンプレートのベアメタルプロジェクトは、従来テンプレートCortex-M0+/M3コアをCortex-M4コア対応へ発展させたものです。ベアメタルプロトタイプ開発着手時に適すプロジェクトです。

FreeRTOSアプリケーションテンプレートは、ベアメタル開発経験者が、手間なく直にRTOSとベアメタルの差を理解・実感し、かつ、IoT基盤RTOSの効率的な基礎固めができるツールです。

なお、既に従来マイコンテンプレートご購入者様は、50%OFF特典があり、税込1000円にて本FreeRTOSアプリケーションテンプレートをご購入頂けます。弊社での確認ミスを防ぐため、ご購入時に従来テンプレート購入者様である旨、お知らせください。

勿論、従来テンプレートとFreeRTOSアプリケーションテンプレートの同時購入でも、この特典は適用されます。

まとめと今後

ベアメタル開発経験者が、IoT MCUクラウド接続に必要となるRTOSの効率的な基礎固め、FreeRTOSプロトタイプ開発着手プロジェクトとして使えることを目的に、NXP)LPCXpresso54114、Baseboard、Arduinoプロトタイプシールドを使ったFreeRTOSアプリケーションテンプレートを発売しました。

本テンプレートは、Amazon FreeRTOSのHardware Independent FreeRTOS Exampleを原本としています。第1弾はNXP)LPCXpresso54114へ適用しましたが、今後、STマイクロエレクトロニクス)STM32G4やCypress)PSoC 6など他社Cortex-M4コアの対応版も開発予定です。

組込みMCU開発お勧めブログ

組込み開発全般に参考となる英語ブログを紹介します。特にRTOS関連記事は、内容が濃く纏まっていて、実践開発時の示唆に富んでいます。

JACOB's Blog
JACOB’s Blog

RTOSカテゴリー

組込み開発コンサルティングも行うBeningo Embedded社は、高信頼の組込みシステム構築と低コスト・短時間での製品市場投入を目標としています。この目標に沿って、複雑な組込み開発概念を、シンプルに解り易く解説しているのが、同社ブログです。

特に、RTOSカテゴリーは、FreeRTOS開発方法を整理する時、参考になります。最新RTOSの3投稿をリストアップしたのが下記です。

2021年5月4日、A Simple, Scalable RTOS Initialization Design Pattern
2020年11月19日、3 Common Challenges Facing RTOS Application Developers
2020年10月29日、5 Tips for Developing an RTOS Application Software Architecture

Data flow diagram for a smart thermostat(出展:JACOB'S Blog)
Data flow diagram for a smart thermostat(出展:JACOB’S Blog)

開発中の弊社FreeRTOSアプリケーションテンプレートは、「ベアメタル開発経験者が、FreeRTOS基礎固めと、基本的FreeRTOSアプリケーション着手時のテンプレートに使えること」が目的です。従って、必ずしも上記お勧めブログ指針に沿ったものではなく、むしろ、ベアメタル開発者視点でFreeRTOSを説明しています。

弊社テンプレートを活用し、FreeRTOSを理解・習得した後には、より実践的なRTOS開発者視点で効率的にアプリケーションを開発したいと思う方もいるでしょう。もちろん、弊社FreeRTOSアプリケーションテンプレートからスタートすることを弊社は推薦しています。

しかし、Windows上でアプリケーション開発する時は、初めからWindows作法やGUIを前提として着手するように、RTOS上でMCUアプリケーションを開発する時も、従来のベアメタル開発に固執せず、RTOSオリエンテッドな手法で着手するのも1方法です(ベアメタル経験が少ないWindows/Linux世代には、親和性が高い方法かもしれません)。

推薦ブログは、この要望を満たすRTOS手法が豊富に掲載されています。

また、上記RTOS関連3ブログを(掲載図を「見るだけでも良い」ので)読んで、ピンとこなければ、RTOS理解不足であると自己判断、つまり、リトマス試験紙としても活用できます。

問題整理と再構築能力

ベアメタル開発経験者が、RTOSを使ってMCUアプリケーション開発をするには、従来のBareMetal/Serial or Sequential動作からRTOS/Parallel動作へ、考え方を変えなければなりません。弊社FreeRTOSアプリケーションテンプレートは、この考え方を変えるための橋渡しに最適なツールです。

橋を渡りきった場所が、RTOSの世界です。RTOS環境での組込み開発問題を整理し、シンプルに解決策を示すには、知識や経験だけでなく、問題再構築能力が必要です。JACOB’S Blogをご覧ください。RTOSに限らず組込み関連全般の卓越した問題再構築能力は、掲載図を見るだけでも良く解りますよ😄。

FreeRTOSアプリケーションのQueueデータ送受信

FreeRTOSアプリケーションテンプレートのQueue利用タスク間データ送受信を説明します。これは、テンプレートのベースとしたMCUXpresso SDK付属FreeRTOSサンプルプロジェクトfreertos_generic解説の後半に相当します。

FreeRTOSアプリケーションテンプレートのベースプロジェクト(まとめ図参照)は、本稿で全て説明済みとなります。下記1~3が、関連投稿です。1~3の順にお読み頂くと、内容が解り易いと思います

  1. FreeRTOSアプリケーションテンプレート構想
  2. FreeRTOS新規プロジェクト作成からアプリケーションテンプレートまで
  3. テンプレートベース:freertos_generic前半(ソフトウェアタイマ関連)

freertos_genericのQueueによるデータ送受信

freertos_genericのQによるデータ送受信
freertos_genericのQによるデータ送受信

FreeRTOSでは、送信タスクと受信タスクの2つに分離しデータ送受信処理を開発します。

送信タスクは、自分の都合の良いタイミングで、いつでもデータ送信を始めます。受信タスクは、いつ始まるか判らないデータ送信に対し、常時受信できるように待機中です。但し、受信タスクの受信開始タイミングは、その他のタスク優先度により変動します。

この受信開始変動があっても送信データを取りこぼし無く受信するために、送受タスク間で一時データを格納するFIFOバッファが必要で、これがQueue(以下Q)です。マルチタスクによる副作用と言えます。

もちろん、データ溢れが生じないようQには複数データを蓄える深さも必要です。受信タスクは、データのQ完了イベントで、FreeRTOSが受信開始を起動します。また、送信タスクよりも、受信タスクの方が優先度が高いのは、Qデータ溢れ防止策です。

1データ長、データ送信タイミング、その他のタスク数やその優先度にも影響されるQの深さは、十分な検討が必要です。

freertos_genericでは、Qの深さを1データ、送信タスク優先度を1、受信タスク優先度を2とし、データを100固定値にして1バイトデータ長の送受信を行い、送信開始タイミングは、vTaskDelayUntil(後述)で作成しています。その他のタスクが、freertos_generic前半で説明したソフトウェアタイマタスク、この優先度が4です。

同一優先度のタスクが無く、他のタスク数もタイマタスク1個で高優先、1バイトデータ長のため、深さ1のQでも送受信データは溢れません。

少ないタスク数と同一優先度無しのシンプルなサンプルプロジェクトですが、簡単に説明しても上記のように長くなります。

ベアメタル開発経験者であれば、RTOS個々の文章説明(=Serial or Sequential動作)は、理解できます。しかし、RTOSによりシングルコアMCUであっても各タスクが時分割Parallel動作しますので、途端に解り難くなります。

BareMetal/SerialからRTOS/Parallelへ、従来の設計手法をステップアップする必要がありそうです。

vTaskDelayUntil対vTaskDelay

vTaskDelayUntilとvTaskDelay比較
vTaskDelayUntilとvTaskDelay比較

freertos_genericは、データ送信タイミングの作成に、他のサンプルでよく見かける待ち処理:vTaskDelayではなく、vTaskDelayUntilを使っている点に注意が必要です。

vTaskDelayは、指定待ち「時間」後、RTOSにより優先度に応じて次処理が実行されます。ゆえに、高優先の他タスクやその状況により、次処理実行までの待ち時間が変動します。

vTaskDelayUntilは、指定待ち「周期」後、次処理が実行されます。仮に2周期よりも長い待ちが発生した時は、次処理はスキップされます。つまり、vTaskDelayよりもデータ送信の(スキップも含めると)定間隔、周期性に優れています。

サンプルプロジェクトの場合、Qの深さが最小の1のため、vTaskDelayUntilの方が、Q溢れ対策として効果があります。vTaskDelayだと、変動を考慮し、より深いQが必要になりそうです。但し、vTaskDelayUntilのRAM使用量は、vTaskDelayよりも増えます。

つまり、vTaskDelayUntil 利用か、それとも、vTaskDelayとQの深さ利用か、どちらにRAM資源を割当てる方が、よりQ溢れ対策として効果的か、これが検討ポイントの1つです。freertos_genericでは、前者を選択した、と筆者は解釈しました。

参考資料:Kernel > API Reference > Task ControlのvTaskDelayUntilとvTaskDelay

本稿まとめとFreeRTOSアプリケーションテンプレート目的

FreeRTOSアプリケーションテンプレートのQ利用タスク間データ送受信を説明しました。Qにより、送信タスクと受信タスクを分離して開発できますが、Qの深さは、送受タスク以外の他タスク優先度など多くの要因にも関係するため、設計に注意が必要です。

FreeRTOS利用メリットは、ベアメタル開発に比べ、独立性や流用性が高いタスク開発ができることです。反面、優先度に応じたマルチタスク環境では、ベアメタル開発には無かったスキルも必要になります。

本稿説明のSDK付属FreeRTOSサンプルプロジェクトfreertos_genericをベースにした、Cortex-M4コア最高速150MHz動作LPCXpresso54114対応のFreeRTOSアプリケーションテンプレートは、6E目標に開発中です。

FreeRTOS Application Template (NXP Version)
FreeRTOS Application Template (NXP Version)

同じ動作のアプリケーションを、FreeRTOSとベアメタル、それぞれで開発した2つのプロジェクトを添付します。

FreeRTOSアプリケーションテンプレートの目的は、FreeRTOS特有スキルを、ベアメタルと比較し、具体的に理解・習得すること、基本的なFreeRTOSアプリケーション開発テンプレート(=スタートプロジェクト)としても使えること、の2点です。

なお現行のLPCXpresso54114開発SDKツールデフォルトコア速度100MHzを150MHz動作へ変える方法は、前稿を参照してください。

LPCXpresso54114 150MHz動作設定方法

MCUコア動作速度設定は、一般的にプログラミングの冒頭、main関数の各種初期設定よりも前で行い方法は2つあります。

LPCXpresso54114の150MHz動作
LPCXpresso54114の150MHz動作

1つがソフトウェアで明示的にコア速度を設定する方法(左側の橙下線)、もう1つがConfig ToolsでGUIを使って設定する方法(右側の橙囲い)です。ソフトウェア設定方法は、代表的な設定値のみがAPIで提供され、GUI利用方法は、細かな速度設定や周辺回路毎へのクロック供給設定ができるなど柔軟性があります。

弊社は、アプリケーション開発後の低消費電力チューニング時にもソースコード不変で柔軟性メリットがあるConfig ToolsのGUI利用方法を推薦します。

現状の開発ツールでは、コア速度がデフォルト96MHzですので、これを150MHzへ変える方法を示します。

開発ツール

前稿最後に示したLPCXpresso54114最新データシートで発見(!)したCortex-M4コア最大動作周波数150MHzは、最新SDKの新規プロジェクト作成時でも旧データシート記載の100MHz(=96MHz)のままです。

そこで、2021年4月2日投稿の新規FreeRTOSプロジェクト作成方法のStep1~Step5に、本稿の動作クロック150MHz化をStep6として追加します。

本稿で示す開発ツールは、本日時点の最新版で以下です。

・MCUXpresso IDE v11.3.1 [Build 5262] [2021-04-02]
・LPCXpresso54114 SDK Version 2.9.0
・LPC5411x データシートRev. 2.6

これを示した理由は、今後の開発ツール更新によりデフォルト動作クロック値が150MHzへ変わる可能性もあるからです。

Config Tools利用MCU動作速度150MHz設定

新規プロジェクト作成直後のConfig Tools Clocks Diagramが下図です。コア速度のSystem clockは96MHzです。150MHzへの変更手順が以下です。

SDK新規プロジェクト作成直後のClock Diagram
SDK新規プロジェクト作成直後のClock Diagram

1. PLL Modeを、Fractional/Spread spectrumからNormalへ変更。
2. クロック選択肢をクリックすると、下図のように供給クロックのルート変更ができます。最初に示したクロックルートになるよう各選択肢やPLL設定を変更し、System clockを150MHzにします。

クロック選択肢をクリックして供給クロックルート変更
クロック選択肢をクリックして供給クロックルート変更

3. Config ToolsのUpdate Codeをクリックし、GUI変更結果をソースコードへ反映させます。

※全般的なConfig Toolsの使い方は、コチラの関連投稿を参照ください。

初期設定後に下記のようなソースコードを追加しておくと、コア動作クロックが設定値に変わったか確認ができます。

コア動作クロック速度を示すソースコード
コア動作クロック速度を示すソースコード

Config Tools MCUコア速度設定メリット

例えば、初期設定したusart通信速度115200bpsやMRT:マルチレートタイマ満了時間は、コア速度を変えたとしても不変です。各ドライバ内で、コアから独立した速度/満了時間設定を行うからです(※厳密には、設定誤差などが多少変わります)。

MCUの中で消費電力が最も大きいコアの動作速度を下げるのは、アプリケーション開発後の低電力動作チューニングに最も効果があります(※アプリケーション開発中にコア速度を下げるのは、より厳しい動作条件で開発することに相当しますのでお勧めしません)。

ソフトウェアで直接コア速度を記述した場合、この低電力化検討時に記述変更が必要になります。しかも、代表的な速度のみ設定可能なため、変更幅が大きくなる欠点があります。

一方、本稿で示したConfig Toolsによるコア速度設定の場合は、ソフトウェア設定に比べ細かな設定が可能で、記述ソフトウェアも不変です。更に、周辺回路動作も個別に制御できるため、コアだけでなく電力消費が大きい周辺回路の特定などにも役立ちます。

つまり、Config Toolsコア速度設定方法は、より効果的できめ細かいMCU低電力動作チューニングが可能でメリットが大きいと言えます。

評価ボード消費電流測定方法

評価ボードLPCXpresso54114には、0Ωチップ抵抗:JS11の取外しが必要ですが、消費電流測定用の端子:JP4が用意されています。これを使うと、前章で示したコア速度変更や周辺回路を動作停止した時の実消費電流が測れます(測定誤差ガイドラインもデータシートFig. 5に掲載中)。

LPCXpresso54114消費電流計測回路
LPCXpresso54114消費電流計測回路

あとがき

LPC5411x データシートRev. 2.6は、コア速度96MHzまでのCoreMark消費電力しか記載されておらず、しかも、96MHz以降急激な上昇傾向があるなど、気になる点もあります。

CoreMark power consumption
CoreMark power consumption

現在のSDK新規作成プロジェクトがデフォルト96MHzなのは、この辺りが妥当なクロック速度のせいかもしれません。今後のデータシート改版で状況を見たいと思います。

但し、開発中のCortex-M4 LPCXpresso54114向けFreeRTOSアプリケーションテンプレートは最高動作周波数の150MHz動作、比較用ベアメタルアプリケーションも150MHzで開発します。

FreeRTOSサンプルプロジェクトfreertos_generic詳細

前稿の弊社FreeRTOSアプリケーションテンプレートのベースとなったMCUXpresso SDK付属FreeRTOSサンプルプロジェクトfreertos_genericの詳細、主にソフトウェアタイマ関連とその用途を説明します。

freertos_genericのHook関数とFreeRTOSConfig.h

Step5:FreeRTOS低電力動作
Step5:FreeRTOS低電力動作

前稿Step5でOSアイドルタスクの「Hook関数」にWFI()を追記し、FreeRTOSに低電力動作を追加しました。ベアメタル開発者には馴染みの少ないHook関数とは、MCU開発者がOSに独自処理を追加する仕組み(Wikipedia)です。ハッカーに悪用される危険性もありますが、元のOSソースはそのままで動作を変更できる便利な機能です。

freertos_genericは、このアイドルタスクの他に、スタックオーバーフロー、マロックエラーと、ソフトウェアタイマの周期割込みに後述のHook関数を用いています。スタックオーバーフローやマロックエラー発生時は、Hook関数内でMCUが動作停止しますので、対策検討の手始めになります。

これらソースコード内に記述したHook関数を有効にするには、FreeRTOSConfig.h内のマクロ設定が必須です。試しに、Step5で追記したWFIへブレークポイントを設定し、FreeRTOSConfig.hのconfigUSE_IDLE_HOOKマクロを1以外に設定するとWFIでブレークしません。configUSE_IDLE_HOOKを1に戻すと、当然ですがブレークします。

このように、ソースファイル記述よりも「FreeRTOSConfig.hのマクロが優先」されます。これが、前稿でFreeRTOSConfig.hを最重要ファイルとした理由です。

万一FreeRTOSConfig.hに記述ミスがあると、開発者が所望処理をソースへ加えても、何も無かったかのようにFreeRTOSは処理します。

そこで前稿新規プロジェクトのStep4で示したfreertos_genericのFreeRTOSConfig.hを上書きコピー後、オリジナルと内容一致を確認するのが良いと思います。但し、MCUXpresso IDEのColors&Fontを、例えばメイリオ11Pへ変えると、インデントやタブ表示なども変わるため見易く修正を加えた場合、Consolas利用のオリジナルと完全一致では無くなります。

Notepad++のCompareプラグイン実行結果。スペースが異なっても内容同じなら黄色、異なれば赤表示。
Notepad++のCompareプラグイン実行結果。スペースが異なっても内容同じなら黄色、異なれば赤表示。

そんな時に役立つツールが、Notepad++のCompareプラグイン機能です。コード内容が一致していれば挿入スペース数などが異なっても黄色、内容自体が異なれば赤で表示されるので、一目でソースコード内容差が判ります。筆者は、この機能を使ってFreeRTOSConfig.h記述ミスを回避しています。

freertos_genericソフトウェアタイマISRのHook関数

ソフトウェアタイマは、tick間隔2msの周期割込みを発生し、このISRがvExampleTimerCallback関数、このHook関数がvApplicationTickHookです。

vApplicationTickHookで2ms割込み発生を500回カウント後、イベントセマフォをprvEventSemaphoreTaskへ送出、イベントセマフォを取得したprvEventSemaphoreTaskが1秒毎に”Event task is running”をコンソールへ出力します。

freertos_genericソフトウェアタイマ処理の流れ
freertos_genericソフトウェアタイマ処理の流れ

vExampleTimerCallbackへのコード記述を少なくするのは常套手段で、ベアメタル開発でもFreeRTOSでも同じです。通常は割込みフラグクリアなどを行いますが、リロードタイマですのでvExampleTimerCallbackはカウンタインクリメントのみを行っています。

Hook関数vApplicationTickHookの500回カウント判断を変更すれば、2ms分解能で任意間隔のイベントセマフォ送出が可能です。これは、SWチャタリングやADCノイズ対策などの周期処理同期に最適です。

イベントドリブンが基本のFreeRTOSですが、割込み処理によりSWチャタリング対策を行うよりも、ソフトウェアタイマとそのHook関数を利用した周期ポーリング処理で行う方が簡単なのが判ります。

freertos_genericの原本

freertos_genericは、FreeRTOS DemoのHardware Independent FreeRTOS exampleがその原本です。原本には、より詳しい英文解説が付いています。また、前章のイベントセマフォによるタスク同期に比べ、45%高速でRAM使用量も少ないタスク通知方法など、FreeRTOS機能強化やTipsなど開発者向け情報も満載です。

6E販売開始予定の弊社FreeRTOSアプリケーションテンプレートを入手後、この開発者向け情報を活用し、FreeRTOSの更なる基礎固めと習得をお勧めします。

なお原本とfreertos_genericには、異なる動作箇所もあります。例えば、FRO:Free Run Oscillator=12MHz、System Clock=96MHzなどです。これはHardware Independentな原本を、LPCXpresso54114動作用にポーティングした結果、生じた箇所です。この部分が、freertos_genericに明記されていない場合もありますので、参照時には注意してください。

弊社は、NXP以外のMCUベンダCortex-M4クラス向けFreeRTOSアプリケーションテンプレートにも、このベンダ非依存のHardware Independent FreeRTOS exampleをベースとして使う予定です。

同一アプリケーションによるベアメタルとFreeRTOS比較が出来る特徴に加え、同一ベース利用によりベンダ間(例えば、STマイクロエレクトロニクスやCypressとNXP)のFreeRTOSアプリケーション開発比較も可能となると考えています。

freertos_genericソフトウェアタイマまとめ

開発中のNXP)LPCXpresso54114向けFreeRTOSアプリケーションテンプレートのベース、MCUXpresso SDK付属FreeRTOSサンプルプロジェクトfreertos_genericのソフトウェアタイマを説明しました。

ソフトウェアタイマのISRフック関数により任意周期イベントセマフォ送出が可能で、イベントドリブンが基本のFreeRTOSにおいて、SWチャタリングやADCノイズ対策などの周期ポーリング処理を行うのに適しています。

ソースコードに記述したフック関数は、FreeRTOSConfig.hのマクロ設定で有効になります。設定ミスを避けるため、オリジナルとの設定内容比較にNotepad++のCompareプラグイン機能を使いました。

なお、freertos_genericのQによるデータ送受信機能は、後半部分として別稿で説明する予定です。

あとがき

MCU開発初心者~中級の方が対象の販売中Cortex-M0/M0+/M3コアMCUテンプレートとは異なり、本稿Cortex-M4コア利用FreeRTOSアプリケーションテンプレートは、ベアメタルMCU開発経験を既にお持ちの方を対象としています。
※投稿内容と対象MCUは、コチラの一覧表を参照してください。

そこで本稿は、ベアメタルとFreeRTOS開発の差分などに関する説明は加えますが、ベアメタルは既知の内容として説明を省略しています(筆不精で、すいません😌)。

投稿内容が判りにくい場合やご質問などは、customerservice@happytech.jpへお寄せください。

FreeRTOS新規プロジェクト作成方法からアプリケーションテンプレートまで

NXP)LPCXpresso54114(Cortex-M4/100MHz、Flash/256KB、RAM/192KB)で動作するFreeRTOSアプリケーションテンプレート開発に着手しました(関連投稿:FreeRTOSアプリケーションテンプレート構想)。

FreeRTOS Application Template (NXP Version)
FreeRTOS Application Template (NXP Version)

この開発で用いる新規FreeRTOSプロジェクト作成方法、新規作成プロジェクトとMCUXpresso SDK付属FreeRTOSサンプルプロジェクトとの違いを示し、FreeRTOSアプリケーションテンプレートのベースプロジェクトを解説します。

まとめ:新規FreeRTOSプロジェクト作成方法とFreeRTOSベースプロジェクト

新規NXP FreeRTOSプロジェクト作成方法をまとめました(詳細は、次章サンプルプロジェクト留意点の後に説明)。

Step1:MCUXpresso SDKで評価ボード選択
Step2:FreeRTOS選択(デフォルト:ベアメタル)
Step3:FreeRTOSドライバ選択(デフォルト+ユーザ追加ドライバ)し、新規プロジェクト作成
Step4:新規プロジェクトへ、サンプルプロジェクトのfreertos_generic.cとFreeRTOSConfig.hを上書き
Step5:アイドルタスクへ低電力動作WFI()を追記し、FreeRTOSベースプロジェクト完成

Step3までが、一般的なFreeRTOSプロジェクト作成方法、Step4と5が、弊社FreeRTOSアプリケーションテンプレート向け工夫箇所です。

弊社FreeRTOSアプリケーションテンプレートは、Step5で作成したFreeRTOSベースプロジェクトへ、例えばADC.cやLCD.cなど制御対象毎のソースファイルを追加して開発します(最初の図)。LCDを使わないアプリケーションの場合は、LCD.cをベースプロジェクトから除外すればそのまま使えるなどポータビリティも考慮しています。

Step3で、ユーザ未追加ドライバ、例えばFreeRTOSメールボックスドライバを、SDKを使わずにベースプロジェクトへ手動で追加するのは、手間やケアレスミスが発生します。

最初から全てのドライバをベースプロジェクトへ追加しておくのも1つの方法ですが、弊社は、必須ドライバでアプリケーションを開発し、追加が必要な時には、再度SDK新規プロジェクト作成からドライバを追加する方法を推薦します。

必須ドライバは、SDKサンプルプロジェクト:freertos_genericで使用中のドライバとADC、VCOMです。これらドライバを追加したベースプロジェクトであれば、FreeRTOSアプリケーションテンプレート構想3章で示したアプリケーション動作に必要十分だと現時点では考えています。

※サンプルプロジェクト:freertos_genericの詳細は、後日、別途投稿を予定しています。freertos_generic名称から判るように、キューやセマフォなど汎用FreeRTOS処理実装のサンプルプロジェクトです。サンプルプロジェクトの概略は、関連投稿を参照してください。

SDK FreeRTOSサンプルプロジェクトと新規作成プロジェクトの違い

MCUXpresso SDK付属のFreeRTOSサンプルプロジェクトと、前章の新規作成FreeRTOSプロジェクトは、ファイル構成が異なります。

FreeRTOSサンプルプロジェクトと新規作成プロジェクトの構成差(FreeRTOSConfig.hの場所が異なる)
FreeRTOSサンプルプロジェクトと新規作成プロジェクトの構成差(FreeRTOSConfig.hの場所が異なる)

構成が異なる理由は、サンプルプロジェクトがFreeRTOS個別技術の説明に重点を置いており、これに都合が良いファイル構成になっているからです。

つまり、左側のsourceフォルダ内にあるfreertos_サンプル.c とFreeRTOSConfig.hの2ソースコードさえ読めば、提供処理が判るように全てのサンプルプロジェクトが作成されています。
※FreeRTOSConfig.h は、FreeRTOS全体動作を決める最重要ファイルです。後日freertos_generic投稿時に説明を加えます。

右側新規作成FreeRTOSプロジェクトと比べると、ポータビリティなどは犠牲になっています。SDKやFreeRTOS自身もバージョンアップしますので、開発済みアプリケーションのポータビリティは重要です。

新規作成ファイル構成で開発したアプリケーションであれば、バージョンアップした環境でも開発済みアプリケーションの移設は容易です。

FreeRTOSサンプルプロジェクトは、機能理解専用と考えれば良いでしょう。なお、FreeRTOS基本機能は、弊社特集サイトを参照ください。

Step1:評価ボード選択

以降は、1章:まとめで示した新規FreeRTOSプロジェクト作成方法とFreeRTOSベースプロジェクトの詳細を示します。

Step1:評価ボード選択
Step1:評価ボード選択

MCUXpresso IDEのNew projectをクリックし、SDK Wizardで評価ボード:lpcxpresso54114を選択、Nextをクリックします。

Step2:FreeRTOS選択

Step2:FreeRTOS選択
Step2:FreeRTOS選択

ComponentsウインドのOperating Systemタブで、デフォルトbaremetalをFreeRTOS kernelへ変更します。

Step3:FreeRTOSドライバ選択

Step3:FreeRTOSドライバ選択
Step3:FreeRTOSドライバ選択

Driversタブでデフォルトドライバに加えadcとusart_freertosを追加します。Components selection summaryウインドのDriversを開くと、実装ドライバが一覧表示されます。Finishクリックで新規FreeRTOSプロジェクトを作成します。

Step4:freertos_generic.cとFreeRTOSConfig.h上書きコピー

Step4:FreeRTOS_generic.cとFreeRTOSConfig.hの上書きコピー
Step4:FreeRTOS_generic.cとFreeRTOSConfig.hの上書きコピー

作成した新規FreeRTOSプロジェクト(Project0)のsource>Project0.cとfreertos>template>ARM_CM4F>FreeRTOSConfig.hを、サンプルプロジェクトlpcxpresso54114_freertos_genericのsource>freertos_generic.cとFreeRTOSConfig.hで上書きします。

Step5:FreeRTOS低電力動作追記

Step5:FreeRTOS低電力動作
Step5:FreeRTOS低電力動作

FreeRTOSアイドル時に低電力動作させるため、上書きしたProject0.cのvApplicationIdelHook()へ、WFI()を追記します。BuildしFreeRTOSベースプロジェクトが完成です。

あとがき:ダークモードと日本語コメント

Step4と5の図は、MCUXpresso IDEのAppearanceをデフォルト:ClassicからDarkに変更しています。

流行のDarkの方が、コード自体は見易いがコメントの方は今一歩に感じます。弊社FreeRTOSアプリケーションテンプレートは、Colors and Fontsにメイリオ11Pを使い、追記日本語コメントを文字化け無しに表示する方針で開発します。ClassicかDarkかは、お好みで選択してください。

FreeRTOSアプリケーションテンプレート構想

2021年6E目標に、FreeRTOSアプリケーションテンプレート新発売(税込価格2000円予定)を目指しています。このFreeRTOSアプリケーションテンプレート構想を示します。

FreeRTOSアプリケーションテンプレート構想骨子

FreeRTOSアプリケーションテンプレート構成ボード
FreeRTOSアプリケーションテンプレート構成ボード
  • 実務利用可能なFreeRTOSアプリケーションテンプレート提供
  • FreeRTOS開発とベアメタル開発のアプリケーション直接比較可能
  • 第1弾はNXP)LPCXpresso54114のSDK(Software Development Kit)で開発、次回STMのコード生成ツールなど利用予定

FreeRTOSソフトウェア開発は面白いです。従来ベアメタル開発手法が使える部分と、新たにFreeRTOS向きの工夫が必要な部分、つまり差分があるからです。

弊社FreeRTOSアプリケーションテンプレートは、この面白さや差分を開発者に味わって頂き、IoT MCUのRTOS普及期に備えることを目的に開発しようと考えています。

対象者は、既にMCUベアメタル開発ができ、新たにFreeRTOSを習得したい開発者とします。過去に弊社テンプレートのご購入者様は、50%割引特典の1000円で購入できます。MCUコアは、FreeRTOS能力を十分引き出すCortex-M4クラスを利用します。

FreeRTOS講座問題点

MCUベンダによるFreeRTOS講座は、①FreeRTOS基礎知識、②FreeRTOSのIDE利用方法、③クラウド接続例など盛りだくさんの内容です。

  1. FreeRTOS基礎知識で、セマフォなどのFreeRTOS関連技術やタクス分割、ユーザタスクプライオリティ、RAM使用量増加などが理解できますが、サンプルコード以外の具体的なアプリケーションでもFreeRTOSを動作させたいと欲求不満になります。
  2. FreeRTOSのIDE利用時、特にコード生成ツールをIDEと併用する場合、①で使ったFreeRTOSサンプルソースコードに、更にベアメタル開発が前提のコード生成ツール出力コードも加わるため、追加分がFreeRTOS理解の邪魔になります。
  3. IoTクラウド接続にFreeRTOSは必須です。しかし、主流のAWS(Amazon Web Services)以外にもMicrosoftのAzureなどもあり、FreeRTOS以外の様々な知識(例えばMQTTプロトコルなど)がクラウド接続のためだけに必要です。

FreeRTOS本体とユーザ追加タスク、この「両方の動作」をしっかりと把握しないとFreeRTOS開発のメリットが享受できないこと、これがベアメタル開発との最大の差です。

FreeRTOSとベアメタルとの違いを理解することが最優先、2. はSDK利用で回避、3. は時期尚早です。

ベンダ講座の主旨は、①FreeRTOS基礎知識に加え、自社製品へのユーザ囲い込みも目的のため、②や③は必然です。しかし、現段階ではFreeRTOSそのものを知り、IoT MCUのRTOS普及期(FreeRTOS、Mbed OS、μITRONなど)に備えるためのツールが欲しいと思い、ネット検索しましたが見当たりません。

そこで、開発するのが弊社FreeRTOSアプリケーションテンプレートです。

FreeRTOSアプリケーションとベアメタル比較

FreeRTOSサンプルコードは、セマフォなどのFreeRTOSで使う技術解説が目的です。従って、サンプル付属タスクはシンプルで解り易く作られています。

サンプルコードは、実務アプリケーションとは乖離しており、タスク分割やユーザタスクが複数ある時の優先順位設定、RAM使用量がベアメタル比どれ程増加するかなど肝心のFreeRTOS実務利用時ノウハウは、サンプルコードからは判りません。

そこで、弊社が過去提供してきたベアメタル開発のIoT Baseboardテンプレートと同じ動作のアプリケーションを、FreeRTOSを使って開発します。つまり、同じ評価ボードで同じアプリケーション動作を、FreeRTOSとベアメタルの両方で開発します。

ベアメタル開発IoT Baseboardテンプレート(評価ボードはFRDM-KL25Z、これがLPCXpresso54114に変る)
ベアメタル開発IoT Baseboardテンプレート(評価ボードはFRDM-KL25Z、これがLPCXpresso54114に変る)

FreeRTOS/ベアメタル両アプリケーションの比較により、複数実務タスクでの優先順位設定やRAM増加量が具体的に判ります。また、優先順位やRAM使用法などのFreeRTOS重要パラメタを変えた時の動作変化も判ります。

もちろん一例にすぎませんが、FreeRTOS/ベアメタルのアプリケーション差、開発困難/容易、消費電力差など、実務開発時に知りたい事柄を評価でき、かつ、基本的なFreeRTOSアプリケーションのテンプレートとしても利用可能です。
※FreeRTOS/ベアメタル評価は、ご購入者様ご自身で行ってください。

FreeRTOSアプリケーションテンプレートは、下記動作を予定しています。

  • 評価ボード搭載LED周期点滅とVCOMメッセージ入出力
  • Arduinoプロトタイプシールド搭載ユーザSWプッシュによる搭載LED点滅
  • Baseboard搭載LCDメッセージ出力とポテンショメータADC変換値のLCD出力

FreeRTOS/ベアメタル両アプリケーションは、評価ボード+Arduinoプロトタイプシールド+Baseboardで動作確認済みです。FreeRTOSアプリケーションテンプレートには、FreeRTOS/ベアメタルそれぞれの動作プロジェクトファイルがあり、FreeRTOSアプリケーション詳細説明を付属資料へ添付します。
※ベアメタルアプリケーションの説明は、紙面が多くなり、過去弊社テンプレートご購入者様には不要ですので省略予定です。

SDKとコード生成ツールのAPI比較

FreeRTOSアプリケーションテンプレートの第一弾評価ボードは、NXPのLPCXpresso54114 (Cortex-M4/100MHz、256KB/Flash、192KB/RAM)を使います。

弊社MCU RTOS習得(2020年版)の解説にも使っていること、FreeRTOSサンプルコードが11種類と多く、かつSDKで提供されていることが理由です。

SDKとコード生成ツールのAPI比較は、コチラの関連投稿の3章をご覧ください。SDK利用を、関連投稿ではMCU設定タイプと記載しています。

APIパラメタが多いのがSDKです。このパラメタをFreeRTOS側でも使う可能性があること、コード生成ツールの使い方を別途説明しなくてもFreeRTOSサンプルコードのみに集中できること、これらも第一弾評価ボードにLPCXpresso54114を選定した理由です。

STマイクロエレクトロニクスのコード生成ツール:STM32CubeMXも、FreeRTOSアプリケーション開発に適応済です。第1弾はSDK利用ですが、STM32G4(Cortex-M4/170MHz、512KB/Flash、96KB/RAM)評価ボードなど、コード生成ツール利用のCortex-M4クラスMCUも、順次FreeRTOSアプリケーションテンプレートを開発したいと考えています。

クラウド接続はブラックボックスライブラリ利用

IoT MCUと接続するクラウドは、無償ではありません。接続には、クラウド側から有償接続ライブラリを取得し、これをIoT MCUのFreeRTOSへ組込んだ後、必要な接続APIを利用します。

有償ライブラリ自身は、ユーザがその内容を変える必要は無く、ブラックボックスとして利用するだけです。IoTクラウド接続時には必須ですが、FreeRTOS理解・習得時には不要です。

まとめ

Cortex-M4クラスのIoT MCUへFreeRTOSを利用するメリットは、独立の単体タクス設計ができ開発タスク資産化も容易なことです。

しかし、複数タスクをFreeRTOSで上手く動作させるには、タスク間の優先順位設計やRAMメモリ使用法などベアメタル開発には無かったFreeRTOS向けの新スキルが必要になります。

これらスキル習得とFreeRTOS基礎固め、FreeRTOS/ベアメタル比較評価のため、開発者個人で低価格購入できるFreeRTOSアプリケーションテンプレートを6E目標に開発予定です。これは、基本的なFreeRTOSアプリケーションのテンプレートとしても利用可能です。

発売時には、FreeRTOSアプリケーションで実際に使用した実務FreeRTOS技術、優先順位設計結果なども付属資料で示します。

本FreeRTOSアプリケーションテンプレートに関するご意見などは、info@happytech.jpへお寄せください。

Kinetis Lテンプレート発売

FRDM-KL25ZとIoT汎用Baseboardを使った、NXP Kinetis Lシリーズ向けテンプレートを1000円(税込)で発売します。

IoT Baseboardテンプレート
IoT Baseboardテンプレート
IoT BaseboardテンプレートのVCOM
IoT BaseboardテンプレートのVCOM
IoT Baseboardテンプレート右横から
IoT Baseboardテンプレート右横から

Kinetis LシリーズとFRDM-KL25Z

超低消費電力と高性能を特徴とするNXPのKinetis Lシリーズは、2013年旧Freescale発売のCortex-M0+コア汎用マイコンです。FRDM-KL25Z(Cortex-M0+:48MHz、Flash:128KB、RAM:16KB)は、このKinetis Lシリーズ汎用マイコン習得ができる低コスト評価ボードです。

FRDM-KL25Zは、MCUXpresso SDK内にFreeRTOSとUSBのサンプルプロジェクトもあり、またmbed開発も可能です。様々なMCUアプリケーション開発に汎用的に使え、初心者から中級レベル以上の方でも満足できる仕様を持っています。

今年で発売から8年経過したKinetis Lシリーズは、最新のNXP開発環境MCUXpresso IDE/SDK/CFGでサポートされており、弊社Kinetis Lテンプレートもこの最新開発環境で開発しました。

Kinetis Lテンプレート

FRDM-KL25Z評価ボードのVCOMGPIOタッチスライダなどの基本的な使い方は、本ブログで既に説明してきました。

問題は、これら使い方を複数組み合わせてアプリケーションを開発する段階になった時、具体的にどうすれば開発できるかがマイコン初心者には解りにくく、つまずき易い点です。

Kinetis Lテンプレートは、この問題に対して1つの解決策を示します。詳細は、Kinetis Lテンプレートサイトと、付属説明資料のもくじ(一部ダウンロード可能)を参照ください。

FRDM-KL25Zで動作確認済みのKinetis Lテンプレートには、FRDM-KL25Z単体動作のシンプルなテンプレート応用例(Simpleテンプレート:下図)と、LCDやポテンショメータが動作し、様々なArduinoシールド追加も簡単にできるIoT汎用Baseboardとを併用したテンプレート応用例(IoT Baseboardテンプレート:最初の図)の2種類を添付しています。

Simpleテンプレート
Simpleテンプレート
SimpleテンプレートのVCOM
SimpleテンプレートのVCOM

マイコン初心者や中級レベル開発者の方が、テンプレート付属説明資料とSimpleテンプレートを利用するとKinetis Lシリーズの効率的習得、IoT Baseboardテンプレートを利用するとLCD/ADC動作済みでシールド追加も容易な段階からアプリケーション開発やIoTプロトタイプ開発が直に着手できるツールです。

これらテンプレートに、もくじ内容の付属説明資料を付けて1000円(税込)で販売中です。購入方法は、コチラを参照ください。

FRDM-KL25ZのFreeRTOSとUSB

MCUXpresso SDKが提供するFRDM-KL25Z評価ボードFreeRTOSサンプルプロジェクトは、弊社MCU RTOS習得(2020年版)で解説したNXP LPCXpresso54114 (Cortex-M4:100MHz、Flash:256KB、RAM:192KB)と同じ内容です。このRTOS習得ページを参照すれば、FRDM-KL25ZによるFreeRTOS理解も容易です。

また、難易度は高くなりますがUSBサンプルプロジェクトも、参考になる情報満載です。これらFreeRTOS、USBサンプルプロジェクトは、中級レベル以上のマイコン開発者に適しています。

初心者、中級レベル向け弊社Kinetis Lテンプレート付属説明資料には、FreeRTOS、USB関連情報は情報過多になるため含んでおりません。

テンプレート付属説明資料の範囲
テンプレート付属説明資料の範囲

しかし、テンプレートを使ってKinetis Lシリーズマイコン開発を習得すれば、スキルを効率的にレベルアップでき、難易度が高いFreeRTOSやUSB開発へも挑戦できます。

つまり、Kinetis Lテンプレートは、初心者、中級レベルの上級マイコン開発者への近道とも言えます。

あとがき

年末年始休暇中に、Cortex-M0+コアのKinetis Lテンプレート発売に何とかたどり着きました。

2021年は、Cortex-M4コアテンプレート化、無線やセキュリティなどのIoT MCU重要課題に対してサイト/ブログを見直すか?とも考えております。皆様のご意見、ご要望などをinfo@happytech.jpへお寄せ頂くと参考になります。

本年も引き続き、弊社マイコンテンプレートサイトと金曜ブログ、よろしくお願いいたします。

IoT MCU汎用Baseboard

弊社が考えるIoT MCU向き汎用Baseboardを示します。要件は、(1)IoT MCU向き、(2)低価格、(3)入手性の良さです。

Arduino UNOプロトタイプシールド ブレッドボード付き(¥480)と、従来から使ってきたBaseboardを併用した汎用Baseboardの特徴、FRDM-KL25Zを使った3.3V MCUと5V LCDのCMOSデバイス直結適用例を示します。

図1 Arduino UNO プロトタイプ シールド ブレッドボード 付き
図1 Arduino UNO プロトタイプ シールド ブレッドボード 付き

NXP IoT Module Baseboard

“IoT Baseboard”で検索すると、NXPのIoT Module Baseboard($160)が現れます。これは、右下にLPC54018(Cortex-M4/180MHz)をAdd-onし、EthernetやSD Card等の機能追加を行う「専用」Baseboardです。Baseboardに加え、ArduinoコネクタでもLPC54108へ機能追加できることが判ります。

図2 IoT Module Baseboard(UM11079に加筆)
図2 IoT Module Baseboard(UM11079に加筆)

LPC54018専用Baseboardで$160と高価ですが、Arduinoシールドが追加できる点が重要です。つまり、IoT Module Baseboardで基本機能追加、開発用途に応じた機能追加はArduinoシールドやPmodで行うという2通りの機能追加方式です。

Arduinoシールドで、様々なプロトタイピング開発に対応できる訳です。

Arduinoシールド

多くのMCU評価ボードは、上記LPC54018専用Baseboardと同様、Arduinoコネクタで機能追加が可能です。安価で豊富な種類のArduinoセンサシールドが販売中であることがその理由です。

弊社IoT MCU汎用Baseboardも、Arduinoシールドで機能追加できることをポイントと考えました。FRDM-KL25Zを例に説明します。

FRDM-KL25Zは、Arduinoコネクタが未実装ですのでコネクタを追加したのが図3です。Arduinoコネクタは、複数シールドをスタッカブルに装着するため、上側がメス、下側がオスの貫通ピンで構成されます。

図3 Arduinoコネクタ追加のFRDM-KL25Z
図3 Arduinoコネクタ追加のFRDM-KL25Z

Arduinoコネクタピン(青色)と、FRDM-KL25Zピン(赤色)の対応表です。例えば、右下のPTA1は、D0に対応するなど、MCU評価ボード開発時は赤色ピン、これがArduinoコネクタ利用時は青色ピンへ変わります。

図4 Arduinoコネクタピン(青色)とFRDM-KL25Zピン(赤色)対応表
図4 Arduinoコネクタピン(青色)とFRDM-KL25Zピン(赤色)対応表

MCU評価ボードにはArduinoピンのシルク印刷はありません。開発するMCU評価ボードのArduinoコネクタ対応表をよく見て、MCU評価ボードピンとArduinoピンマッピングを間違わないように注意する必要があります。

Arduino UNOプロトタイプシールド プレッドボード付き

図1のArduino UNOプロトタイプシールドは、MCUボード上に装着してもFRDM-KL25Zのタッチセンススライダの操作はできます。また、評価ボード上のLED動作は、プロトタイプシールドのスルーホールから目視できます。

さらに、プロトタイプシールドには、評価ボードRESETに並列接続済みリセットボタンと2個のLED、1個のSWが実装されています(図1回路図参照)。

プロトタイプシールドのLEDとSWは、評価ボードとは未接続ですが、付属のブレッドボードを使って配線すれば、LチカなどのMCU動作確認にも便利に使えます。

※Arduino UNOプロトタイプシールド プレッドボード付きの動作は、5章:3.3V MCUと3.3V LCD接続で示します。

IoT MCU汎用Baseboardと適用例

以上のようにArduino UNOプロトタイプシールドは、Arduinoコネクタを持つMCU評価ボードの機能追加や動作テストに便利に出来ています。

そこで、このプロトタイプシールドを、弊社が従来から使ってきた5V動作Baseboardと併用します。

MCU評価ボードへのIoTセンサやセキュリティ機能などはArduinoシールドで追加、LCDやポテンショメータなどの機能は5V動作Baseboardにより追加、この2通り機能追加で「汎用開発」に使えるIoT MCU Baseboardになります。

MCU評価ボードとして3.3V動作FRDM-KL25Zと、Baseboard実装の「5V動作LCD」とをCMOSデバイス直結で接続した適用例を示します(CMOSデバイス直結は、関連投稿を参照してください)。

図5 IoT MCU汎用BaseboardのFRDM-KL25Z適用例
図5 IoT MCU汎用BaseboardのFRDM-KL25Z適用例

※IoTセンサシールド等を追加する場合は、MCU評価ボード(FRDM-KL25Z)の直上、または直下へスタック装着を想定しています。図5は、IoTセンサシールド等を省略した例と考えてください。

3.3V MCUと3.3V LCD接続

プロトタイプシールドを装着したFRDM-KL25Zへ、前章の「5V動作LCD」の代わりに「3.3V動作LCD」を接続した例も示します。FRDM-KL25Zソフトウェアは、どちらも同じものです。

関連投稿では未検証であった3.3V MCU開発ソフトウェア動作確認に、CMOSデバイス直結を利用し5V動作Baseboardが利用できることが、LCD表示が同じであることにより実証できました。

図6 プロトタイプシールド利用の3.3V MCU評価ボードと3.3V LCD接続例
図6 プロトタイプシールド利用の3.3V MCU評価ボードと3.3V LCD接続例

ブレッドボードに実装したのは、LCD表示コントラスト調整用スライド抵抗です。5V系センサ等と3.3V MCU評価ボードをCMOSデバイス直結時に必須となるMCU入力電流保護抵抗は、ブレッドボードへ実装し対応できます。

まとめ

Arduinoプロトタイプシールドと、従来から弊社が使ってきた5V Baseboard併用の、IoT MCU汎用 Baseboardを示しました。IoT関連の機能追加はArduinoシールドで、LCD等の機能追加は5V Baseboardで行い、低価格、入手性が良く、様々なIoT MCUプロトタイピングに使えます。

最低限必要なロジックをプロトタイプシールド付属ブレッドボードへ実装すれば、3.3V系MCU評価ボードと5V系ハードウェアの制御ソフトウェア開発に、CMOSデバイス直結が使えることを実証しました。

本稿で示したFRDM-KL25Z とIoT MCU汎用Baseboardを使ったKinetis Lテンプレートは、年内に発売予定です。ご期待ください。

Firefox Send終了

クラウドファイル共有サービス:Firefox Sendが2020年9月17日終了となりました。弊社テンプレート配布に最適なFirefox Send終了、残念です。代替にGoogle Driveを使いますが、送受双方に手間が1つ増えます。

本稿は、この増えた手間を説明し、セキュリティと利便性が相反することを示します。

Firefox SendからGoogle Driveへクラウドファイル共有サービス変更
Firefox SendからGoogle Driveへクラウドファイル共有サービス変更

Firefox SendとGoogle Drive比較

Firefox Sendは「ファイル共有」専門サービス。共有ファイル保存期間はアップロード後最大7日、または、ダウンロード1回で共有ファイルがオンライン上から自動的に消去されるなど、「ファイル保存」が主目的のGoogle Driveにない使い勝手がありました。

ファイル共有Firefox Sendとファイル保存Google Drive比較
Firefox Send Google Drive
ファイル共有期間 最大7日 設定不可
受信側ダウンロード回数 1回 設定不可
利用料金 無料(最大2.5GB) 無料(最大15GB)
ダウンロード側ログイン 不要 不要
パスワード保護 可能 可能
特徴 ファイル共有に最適 ファイル保存に最適

共有ファイルダウンロードリンクを送信側から受信側へメール通知、受信側がFirefox/Chrome/Edgeなどのモダンブラウザを使って共有ファイルダウンロードに成功しさえすれば、ファイル共有は終了です。ここまでは、Firefox SendとGoogle Drive全く同じです。Firefox Sendは処理完了です。

違いは、Google Driveがファイルの共有期間やダウンロード回数の制限を設けることができない点です。また、受信側が共有ファイルをダウンロードしたことを、送信側が知る手段もありません。

Google Driveでのダウンロード成功後、受信側に成功通知メールをお願いするのは、Firefox Sendでは自動で行われる共有ファイル削除、または、共有停止を送信側が手動にて行うためです。

Firefox Sendに比べ、Google Driveでは送受双方に処理完了までにこの手間が1つ余分に掛かる訳です。

Firefox Send終了理由

Firefox Sendサービス終了の理由は、マルウェア配布手段として悪用されるケースが増え、開発元Mozillaがサービスラインナップ全体コスト、戦略的焦点を見直した結果と発表されています。

高度な暗号化とファイル自動消去のFirefox Send共有サービスは、Firefoxという誰にでも知られた信頼性の高いダウンロードリンククリックだけで簡単にマルウェアをデバイスへ送れます。一般のユーザだけでなく、ハッカーにとっても便利なツールとして悪用されたのでしょう。

無料一時保存ファイルのマルウェア排除を実施することは、無理だとMozillaがあきらめたのだと思います。ただ、次々に生まれるマルウェア排除は、たとえ有料でも困難かもしれませんが…。

セキュリティと利便性の相反例です。また、セキュリティとその対価:費用対効果を考えさせる例でもあります。

企業が自社クローズドサーバーでのみ社員ファイル共有を許可するのは、費用対効果の実現解なのでしょう。
※同様に、IoT MCU開発でもセキュリティ実現解検討が必須です。

Google Drive代替理由

Firefox Send代替にGoogle Driveを選んだ理由は、ファイルの「ダウンロード前や共有前」に、ウィルススキャンが自動的に行われるからです。ウィルス検出時は、警告表示があります。

※ウィルススキャンは圧縮ファイルでも実施されます。但し、パスワード保護を行うとスキャン不可能になりますのでパスワードは設定しません。Firefox Sendでもこれら処理は実施されていたと思いますが…、ハッカーはパスワード保護でスキャンをかわしたのだと思います😥。

無償、セキュリティ、信頼度の高さ、モダンブラウザで利用できる点、これらからGoogle Driveを代替として弊社は選びました。

全テンプレート継続販売

販売中の弊社テンプレートは、戦略的焦点(???)から販売継続いたします。販売中止のサイト変更手間と消えるリンク対応などを考慮すると、そのまま継続販売する費用対効果が高いからです。

本ブログでは、その時々に応じてテンプレート販売中止・終了予定なども記載しますが、マイコンテンプレート名が購入サイトに掲載している限り販売は継続いたしますので安心(?)してご購入ください😌。