MCU:マイコン,LPCマイコン,Cortex-M4コアテンプレート,FreeRTOS,LPCXpreosso54114,LPCXpresso SDK,freertos_generic,FreeRTOSConfig.h,周期処理

前稿の弊社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へお寄せください。

MCU:マイコン,LPCマイコン,Cortex-M4コアテンプレート,アプリケーション,リアルタイムOS,IoTマイコン,FreeRTOS,LPCXpresso SDK,LPCXpresso54114,freertos_generic,FreeRTOSConfig.h

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かは、お好みで選択してください。

MCU:マイコン,Kinetisマイコン,STM32マイコン,Cortex-M4コアテンプレート,アプリケーション,IoTマイコン,mbed OS,FreeRTOS,Amazon Web Service,Azure,μITRON

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へお寄せください。

MCU:マイコン,Kinetisマイコン,Cortex-M0+コアテンプレート,Cortex-M0+,IoTマイコン,Kinetis L,FreeRTOS,FRDM-KL25Z,IoT汎用Baseboard

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へお寄せ頂くと参考になります。

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

RL78マイコン,MCU:マイコン,LPCマイコン,Kinetisマイコン,STM32マイコン,PSoC/PRoCマイコン,MSP432マイコン,Cortex-M0+コア,Cortex-M0コア,Cortex-M3コア,Cortex-M23コア,Cortex-M4コアARMマイコン,IoTマイコン,mbed OS,FreeRTOS,GPIO,LPCXpresso54114,5V耐圧,I2C/SPI

弊社FreeRTOS習得ページで使う評価ボード:LPCXpresso54114(Cortex-M4/100MHz、256KB Flash、192KB RAM)は、FreeRTOSだけでなく、Mbed OSZephyr OSなどオープンソース組込みRTOSにも対応しています。多くの情報がありRTOSを学ぶには適した評価ボードだと思います。

LPCXpresso54114 Board power diagram(出典:UM10973に加筆)
LPCXpresso54114 Board power diagram(出典:UM10973に加筆)

さて、このLPCXpresso54114の電圧ブロック図が上図です。MCUはデフォルト3.3V動作、低電力動作用に1.8Vも選択可能です。一方、Arduinoコネクタへは、常時5Vが供給されます。

本稿は、このMCU動作電圧とArduinoコネクタに接続するセンサなどの動作電圧が異なっても制御できる仕組みを、ソフトウェア開発者向けに説明します。

MCU動作電圧

高速化や低電力化の市場要求に沿うようにMCU動作電圧は、3.3V → 3.0V → 2.4V → 1.8Vと低下しつつあります。同時にMCUに接続するセンサやLCDなどの被制御デバイスも、低電圧化しています。しかし、多くの被制御デバイスは、未だに5V動作が多く、しかも低電圧デバイスに比べ安価です。

例えば、5V動作HD44780コンパチブルLCDは1個500円、同じ仕様で3.3V動作版になると1個550円などです。※弊社マイコンテンプレートに使用中のmbed-Xpresso Baseboardには、5V HD44780コンパチブルLCDが搭載されています。

レベルシフタ

異なる動作電圧デバイス間の最も基本的な接続が、間にレベルシフタを入れる方法です。

TI)TXS0108E:8ビットレベルシフタモジュールの例で示します。低圧A側が1.8V、高圧B側が3.3Vの動作図です。A側のH/L電圧(赤)が、B側のH/L電圧(緑)へ変換されます(双方向なので、B側からA側への変換も可能です)。

8ビットレベルシフタTXS0108Eのアプリケーション動作(出典:TI:TXS0108Eデータシート)
8ビットレベルシフタTXS0108Eのアプリケーション動作(出典:TI:TXS0108Eデータシート)

レベルシフタ利用時には、電圧レベルの変換だけでなく、データレート(スピード)も重要です。十分なデータレートがあれば、1.8VのH/L波形は、そのまま3.3VのH/L波形へ変換されますが、データレートが遅いと波形が崩れ、送り側のH/L信号が受け側へ正確に伝わりません。

例えば、LCD制御は、複数のLCDコマンドをMCUからLCDへ送信して行われます。データレートが遅い場合には、コマンドが正しく伝わらず制御ができなくなります。

MCUの5V耐圧ピン:5V Tolerant MCU Pad

LPCXpresso54114のGPIOピンには、5V耐圧という属性があります。PIO0_0の[2]が5V耐圧を示しています。

LPCLPCXpresso54114の5V耐圧属性(出典:5411xデータシート)
LPCLPCXpresso54114の5V耐圧属性(出典:5411xデータシート)

5V耐圧を簡単に説明すると、「動作電圧が3.3/1.8V MCUのPIO0_0に、5Vデバイスをレベルシフタは使わずに直接接続しても、H/L信号がデバイスへ送受信できる」ということです。または、「PIO0_0に、1ビットの5Vレベルシフタ内蔵」と解釈しても良いと思います。

※ハードウェア担当者からはクレームが来そうな説明ですが、ソフトウェア開発者向けの簡単説明です。クレームの内容は、ソフトウェア担当の同僚へ解説してください😌。

全てのGPIOピンが5V耐圧では無い点には、注意が必要です。但し、ArduinoコネクタのGPIOピンは、5V耐圧を持つものが多いハズです。接続先デバイスが5V動作の可能性があるからです。

また、I2C/SPIバスで接続するデバイスもあります。この場合でも、MCU側のI2C/SPI電圧レベルとデバイス側のI2C/SPI電圧レベルが異なる場合には、レベルシフタが必要です。MCU側I2C/SPIポートに5V耐圧属性がある場合には、GPIO同様直接接続も可能です。

I2Cバスは、SDA/SCLの2本制御(SPIなら3本)でGPIOに比べMCU使用ピン数が少ないメリットがあります。しかし、その代わりに通信速度が400KHzなど高速になるのでデータレートへの注意が必要です。

LPCXpresso54114以外にも5V耐圧ピンを持つMCUは、各社から発売中です。ちなみに、マイコンテンプレート適用のMCUは、6本の5V耐圧GPIOを使ってmbed-Xpresso Baseboard搭載5V LCDを直接制御しています。

mbed-Xpresso Baseboard搭載5V HD44780コンパチLCDの3.3V STM32G071RB直接制御例
mbed-Xpresso Baseboard搭載5V HD44780コンパチLCDの3.3V STM32G071RB直接制御例

5V耐圧MCUデータシート確認方法

MCUのGPIOやI2C/SPIを使って外部センサやLCDなどのデバイスを制御する場合、下記項目を確認する必要があります。

  1. MCU動作電圧と被制御デバイス動作電圧は同じか?
  2. MCU動作電圧と被制御デバイス動作電圧が異なる場合、外付けレベルシフタを用いるか、またはMCU内蔵5V耐圧ピンを用いるか?
  3. MCU内蔵5V耐圧GPIOやI2C/SPIを利用する場合、そのデータレートは、制御に十分高速か?

5V耐圧ピンは、使用するMCU毎に仕様が異なります。MCUデータシートは、英語版なら「tolerant」、日本語版なら「耐圧」で検索すると内容確認が素早くできます👍。

MCU動作電圧と接続デバイス動作電圧が異なっても、MCUのH/L信号が被制御デバイスへ正しく伝わればデバイスを制御できます。

MCU動作電圧に合わせたデバイス選定やレベルシフタ追加ならば話は簡単ですが、トータルコストや将来の拡張性などを検討し、5V耐圧ピンの活用も良いと思います。

MCU:マイコン,LPCマイコン,Kinetisマイコン,Cortex-M4コアARMマイコン,IoTマイコン,MCUXpresso,FreeRTOS,LPCXpresso54114,event,queue,freertos_generic

MCUXpresso54114評価ボードSDK付属FreeRTOSサンプルコード調査最終回の本稿は、タスク数=3のプロジェクト、freertos_eventとfreertos_queue、freertos_genericを説明します。

FreeRTOSサンプルコード:タスク数=3

FreeRTOSプロジェクト:タスク数=3
Project Tasks heap_ Additional FreeRTOS APIs Additional Comments
freertos_event 3 4 xEventGroupCreate xEventGroupSetBits
xEventGroupWaitBits

タスクや割込みなどのイベントをグループ化し、他タスク制御。

セマフォと似ているがイベントの論理演算可能。

freertos_queue 3 4 xQueueCreate
xQueueSend
xQueueReceive
vQueueAddToRegistry
タスク間メッセージ通信デモ。キューは、順序維持FIFO構造。
freertos_generic 3 4

キュー、ソフトウェアタイマ、セマフォの組合せデモ。

FreeRTOS.orgサンプルコードに基づき作成。

※freertos_genericのAdditional FreeRTOS APIは、これまでのサンプルAPI組合せのため追加分なし。

FreeRTOS Project:freertos_event

イベントによるタスク制御は、セマフォに似ています。複数のセマフォを1つにまとめたイベントグループを作成(xEventGroupCreate)し、このグループ化した個々のイベント間で論理演算ができることが特徴です。

xEventGroupWaitBitsの例(出典:freertos_event.c)
xEventGroupWaitBitsの例(出典:freertos_event.c)

イベント間の論理演算ができるので、シングルイベントのセマフォよりも柔軟なタスク制御ができます。

FreeRTOS Project:freertos_queue

これまで説明してきたプロジェクトのタスク間制御には、ミューテックスやセマフォ、上記イベントなど全てビット単位のシグナルを使ってきました。最後に説明するプロジェクトfreertos_queueは、タスク間でメッセージを送受信します。

メッセージは、キュー=有限長FIFO(First In First Out)経由で送受信されますので、メッセージの順番は維持されますが、キューが溢れないような使い方が必要です。深すぎるキューはメモリ効率が悪く、浅いキューではメッセージが溢れます。深さ見積もりなどのためにプロトタイプ開発が必要でしょう。

例えば、複数センサ出力をMCUでまとめ、定期的にクラウドへ送信するようなFreeRTOSアプリケーションソフトの素になりそうなプロジェクトです。クラウドサービスにAmazon Web Service(AWS)を使う時には、専用のネットワーク接続ライブラリもFreeRTOSで提供されますので、このアプリケーションとの親和性も良いと思います。

FreeRTOS Project:freertos_generic

MCUXpresso54114評価ボードSDK付属FreeRTOSサンプルコード11個の説明の最後が、このfreertos_genericプロジェクトです。これまで説明してきた10個のサンプルコードを総合的にまとめたプロジェクトで、出典はhttp://www.freertos.org/Hardware-independent-RTOS-example.htmlです。

筆者の下手な説明よりも、実際にソースコードを見て頂くと丁寧なコメント付きです。このソースコードを読んでFreeRTOSの仕組みがすんなりと理解できれば、ベアメタルからFreeRTOSソフトウェア開発へのステップアップ初期段階は完了と言えるでしょう。つまり、10個サンプルコード習得度の自己評価に使えます。

FreeRTOSサンプルコード:タスク数=3の調査結果

  • 複数セマフォを1つにまとめたイベントグループタスク制御は、イベント間の論理演算が可能
  • キュー利用のタスク間メッセージ通信は、深さ設定にプロトタイプ開発が有効
  • freertos_genericは、SDK付属サンプルコード10個の習得度評価に使える
  • メモリ使用法は、heap_4を利用

まとめ:MCUXpresso54114評価ボードSDK付属FreeRTOSサンプルコード調査

5回に渡ってMCUXpresso54114評価ボードSDK付属FreeRTOSサンプルコードをタスク数が少ない順に調査しました。基本的なFreeRTOS機能は、解説済み11個のサンプルプロジェクトでカバーされています。

各プロジェクトの追加分FreeRTOS APIのみを表で示し、しかも弊社サイトマイコンRTOS習得2017の内容は既にご存じという前提で説明したので、解りにくい部分もあったかもしれません。
要するに、ベアメタル開発にFreeRTOS APIを追加すればRTOSソフトウェア開発ができることを強調したかったからです。

FreeRTOSのマルチタスク並列動作、タスク間同期/競合回避手段、これらのFreeRTOS APIのみを理解すれば、ベアメタル開発経験がそのまま活かせます。

今回の1~5回の解説は、マイコンRTOS習得2020年版として2017年版サイトへ改版する予定です。改版後にご覧になれば解りにくさが改善されるかもしれません。

調査目的は、開発予定のベアメタルCortex-M4テンプレートへのRTOS機能応用でした。現時点で、応用内容は不明確です。しばらく時間を頂いて明確化します。

ただ、マルチタスクFreeRTOSと異なり、ベアメタルテンプレートは、全て自分の制御下タスクです。タスク間同期やメッセージ送受信も、特別な工夫なく簡単に実現できます。

FreeRTOS利用MCUのAWS接続(出典:Amazon FreeRTOSの開始方法に加筆)
FreeRTOS利用MCUのAWS接続(出典:Amazon FreeRTOSの開始方法に加筆)

上図のように、AWSへの接続やIoTセキュリティ機能追加など今後必須になるIoT MCUの機能実装は、専用ライブラリベース、特にFreeRTOSライブラリで提供される可能性が高いと予想できます。

これらライブラリは、ベアメタル開発でも利用可能ですが、FreeRTOSソフトウェアの方が親和性も高く開発が容易なことも事実です。

しかも、これら専用ライブラリで実行される処理内容は、本来我々開発者が変更を加えるべきでない定型処理です(もちろんプロパティなどのパラメタは、開発者依存です)。

いずれにしても、MCUXpresso54114を使ったFreeRTOSソフトウェア開発環境と基本機能は習得できたので、ベアメタルCortex-M4テンプレート開発へ活かしていきます。

MCU:マイコン,LPCマイコン,Kinetisマイコン,Cortex-M4コアARMマイコン,IoTマイコン,MCUXpresso,semaphore,mutex,FreeRTOS,LPCXpresso54114,ランデブーモデル

タスク数=2のMCUXpresso54114評価ボードSDK付属FreeRTOSサンプルコードの後半2プロジェクト、MutexとSemaphoreを説明します(前半は、前稿参照)。

FreeRTOSサンプルコード:タスク数=2

FreeRTOSプロジェクト:タスク数=2(後半)
Project Tasks heap_ Additional FreeRTOS APIs Additional Comments
freertos_mutex 2 4

xSemaphoreCreateMutex
xSemaphoreGive

並列動作の共有リソース同期/競合制御。taskYIELDは要注意!

Mutexのセマフォ作成は、   xSemaphoreCreateMutex。

Semaphoreのセマフォ作成は、xSemaphoreCreateBinary。

freertos_sem 1+3 4

xSemaphoreGive

※Freertos_semはタスク数4個。実質はproducer_taskとconsumer_taskの2個。

FreeRTOS Project:freertos_mutex

RTOSソフトウェアのメリットは、複数タスクが「完全に並列動作」することです。ただし、副作用として、共有リソースのアクセス競合が生じます。サンプルコードの場合はIDE Console出力で、その他にUARTやIOポートなど多くの共有リソースがMCUにはあります。

この共有リソースへのセクセス競合を防ぐ手段がミューテックスです。共有リソース使用前に他タスクの使用/未使用を検出し、未使用時のみ利用、利用後は、使用権を戻す操作(xSemaphoreGive)をします。

仮にミューテックス機能が無ければ、英字と数字が混ざった出力になり、使い物になりません。
並列動作のRTOSに、Mutexは必須機能です。

注意点は、Consoleへ部分出力後のtaskYIELDです。

F3クリックで調べましたがtaskYIELDの理由は、筆者には不明です。だだし、コメントを読むとFreeRTOSインプリメント依存部分なので、そのまま弄らない方が良さそうです。共有リソース利用中には、taskYIELDが必要と覚えておけば(とりあえず)良いとします。
※本調査の目的は、ベアメタルCortex-M4テンプレート開発へのRTOS機能応用であって、FreeRTOS自身ではないので、この程度で留めていきます👍。

共有リソース使用検出APIは、xSemaphoreTakeです。前稿freertos_ticklessプロジェクトの割込みISRと処理タスク同期に用いたAPIと同一です。差分は、セマフォ自体の作り方が異なります。ミューテックスの場合は、xSemaphoreCreateMutex、セマフォの場合は、xSemaphoreCreateBinaryです。

違いは、初期値です。ミューテックスは、初期値が使用可能(pdTRUE)になりますが、セマフォは、初期値が使用不可です。どちらも、並列動作タスク間の同期/競合制御として、同じAPI:xSemaphoreTakeを使っているということです。

FreeRTOS Project:freertos_sem

前稿freertos_ticklessで示したISRと処理タスクのセマフォ同期とは別の使用例が、freertos_ semプロジェクトです。同期というより、むしろ排他制御にセマフォを使った例です。

このプロジェクトは、これまでのサンプルコードで最も多い4タスク:1(producer_task)+3(consumer_task)を生成し、2個のセマフォ(xSemaphore_producerとxSemaphore_consumer)を使い、1個のアイテムを4タスク間で利用する例です(Doc>freertos_sem_example.txtによるとランデブーモデル同期と言うようです)。

2セマフォで1共有アイテム利用のランデブーモデル同期
2セマフォで1共有アイテム利用のランデブーモデル同期

1個の(共有)アイテムは、元々produser_taskが持っており、cunsumer_taskへその使用権を与えます(L119:xSemaphoreGive→xSemaphore_consumer)。

並列動作中の3個cumsumer_taskのどれかがこの使用権を取得します(L143:xSemaphoreTaka←xSemaphore_consumer)。使用後は、produser_taskへ使用権を返却します(L141:xSemaphoreGige→xSemaphore_producer)。

produser_taskは、cunsumer_taskの使用権返却を待っており(L121: xSemaphoreTaka←xSemaphore_producer)、返却後、再び最初に戻ってcunsumer_taskへ使用権を与えます。

cunsumer専用セマフォがxSemaphore_consumer、producer専用セマフォがxSemaphore_producerで、それぞれを図示したようにやり取りしながら4タスクが動作します。

ベアメタル風に、ランデブーモデル同期:synchronized in bilateral rendezvous modelを解説すると上記のようになります。

ソースコード上では、どのcumsumer_taskが共有アイテムを獲得するかは不明ですが、評価ボード実行結果は、常にConsumer 0→1→2→0・・・の順番でした。3個のcumsumer_taskプライオリティが同一の時は、生成順に1個のアイテム共有ができるようです。

FreeRTOSサンプルコード:タスク数=2(後半)の調査結果

  • FreeRTOSタスク並列動作副作用の共有リソースアクセス競合回避手段に、ミューテックスがある
  • MCUXpresso54114 のFreeRTOS共有リソース利用途中には、taskYIELDが必要
  • 初期値(pdTRUE)の有無が、ミューテックス作成とセマフォ作成で異なる
  • バイナリセマフォの排他制御利用例に、ランデブーモデル同期がある
  • メモリ使用法は、heap_4を利用

FreeRTOSデバイス依存開発ノウハウ

筆者のOS:Operating System利用アプリケーションソフト開発経験は、Windows PCのみです。Windows OSは、リアルタイム性はありません。そのおかげで、PCアプリケーションソフト開発時に、他タスクへの影響、プライオリティなどは考慮せずに比較的簡単に開発ができました。

ミューテックスやセマフォを利用した覚えもありません。もちろんファイルなどの共有リソースには、それなりのアクセス手順があり、それに従って開発すれば特に問題はありません。

一方MCUでOS利用の場合は、リアルタイム性は無視できません。限られたMCU能力を上手く利用するためのデバイス依存開発ノウハウが、メモリ使用法:heap_4やtaskYIELDだと思います。

これらノウハウは、ソースコード上では解りにくい代物です。また、文章記述できる量も限られます。

これには、評価ボード上でソースコードのパラメタを変えた時の挙動変化を開発者自身がつかんで習得する方法が効率的です。LPCXpresso54114(Cortex-M4/M0+ 100MHz、256KB Flash、192KB RAM)評価ボードは、入手性もよく低価格(約3400円)です。無償LPCXpresso IDEとともにご利用いただければ、本稿やFreeRTOSがより解り易くなります。

PS:FreeRTOSの最新版V10.3.0が2020年2月7日に公開されました。詳細は、リリースノートをご覧ください。

MCU:マイコン,LPCマイコン,Kinetisマイコン,Cortex-M4コアARMマイコン,IoTマイコン,MCUXpresso,semaphore,FreeRTOS,LPCXpresso54114,ISR

タスク数=1の前稿FreeRTOSサンプルコード(2)に続き、本稿は、タスク数=2のMCUXpresso54114評価ボードSDK付属FreeRTOSサンプルコードの前半3プロジェクトを説明します。

FreeRTOSサンプルコード:タスク数=2

FreeRTOSプロジェクト:タスク数=2(前半)
Project Tasks heap_ Additional FreeRTOS APIs Additional Comments
freertos_tickless 2 4

vTaskDelay
xTaskGetTickCount
xSemaphoreCreateBinary
xSemaphoreGiveFromISR
xSemaphoreTake

FreeRTOS低電力動作とSW_taskの2タスク並列動作説明。

Tickless_taskは、vTaskDelay、前稿hello_taskは、vTaskSuspend。

SW_taskは、Tickless_taskに何ら影響を与えない。

freertos_i2c 2 4

xSemaphoreCreateBinary
xSemaphoreGiveFromISR
xSemaphoreTake

master_taskとslave_taskの2タスク構成。正常動作結果は、Console窓出力。DoC>readme.txtでも結果が判る。

freertos_spi 2 4

xSemaphoreCreateBinary
xSemaphoreGiveFromISR
xSemaphoreTake

同上

タスク数=2のサンプルコードは、上記以外にもFreeRTOS特徴のミューテックスとセマフォ利用例がありますが、これらは次回説明します。

FreeRTOS Project:freertos_ tickles

前稿説明のhello_taskは、Console窓に文字を1回出力し、「待ち状態」になりました。
hello_task とよく似たTickless_taskは、文字の代わりにxTaskGetTickCountで得た数字を1回出力し、vTaskDelayで5秒間の「停止状態(=低電力動作:Sleep)」になります。

低電力動作からの復帰Eventで、Tickless_taskは停止状態から実行可能状態へ移行し、スケジューラによって再実行されます。停止時間5秒間のtick回数がConsole窓に出力されます。
※FreeRTOSタスクの状態遷移図は、マイコンRTOS習得2017の第2部を参照。

このプロジェクトは、Tickless_task が、SW_task動作に全く影響を受けないFreeRTOSの特徴を説明しています。

つまり、Tickless_taskと、SW_taskは、それぞれ別々にあたかも自分のタスクがMCUを占有するように記述されており、かつその通り並列動作します。これがFreeRTOS利用ソフトウェア開発の最大メリットです。タスク開発は、ベアメタルソフトウェア開発に比べ簡単に、かつ流用性も大きくなるでしょう。

※SW3プッシュは、ソフトウェア、ハードウェアで何もチャタリッグ防止策をしていない処理の検証にも使えます。試しにSW3を長く押してチャタリッグが発生することを確かめてください。チャタリッグ防止策の必要性が解ります。

FreeRTOS Project:freertos_ i2cとfreertos_ spi

freertos_ i2cとfreertos_spiプロジェクトは、どちらもMCU内蔵I2C、またはSPIを使った外部デバイスとの通信サンプルコードです。どちらもmaster_taskとslave_taskの2タスクから構成されています。

main.cでslave_taskのみをタスク登録し、slave_task内でmaster_taskを登録しています。このように、FreeRTOSスケジューラ起動後でも、任意の場所で新たなタスク登録が可能です。

動作は、最初master_taskでデータ送信し、それをslave_taskで受信、次にslave_taskがデータ送信し、それをmaster_taskで受信し、両タスクとも正常終了します。

この動作シナリオは、slave_taskに記述されており、master_taskのデータ送信開始は、slave_taskのmaster_task登録の結果、並列実行されます。slave_taskのデータ受信と送信完了は、i2c_slave_callbackからのセマフォを使って判断しています。

評価ボード実装Arduinoコネクタ上の配線で、送受信データをループバック接続しますので、評価ボード1台のみで両タクス動作結果が、IDEのConsole窓に出力されます。

MCUXpresso54114評価ボードをお持ちでない方は、両プロジェクトのDoc>readme.txtのRunning the demoにConsole窓出力と同じ結果があるので解ります。

I2C/SPI通信対象のデバイスは、従来からの外付けEEPROMに加え、最近ではIoTセキュティデバイスなどがあります。

IoTセキュティデバイスは例えば、NXPのEdgeLookやMicrochipのCryptoAuthenticationファミリなどがあり、IoT MCUのクラウド接続には、これらデバイス利用が必須になりそうです。

I2C通信のIoTセキュリティデバイス接続例(出典:NXP SE050データシート)
I2C通信のIoTセキュリティデバイス接続例(出典:NXP SE050データシート)

FreeRTOSサンプルコード:タスク数=2(前半)の調査結果

  • FreeRTOS低電力動作(Sleep)は、vTaskDelay(msec)で低電力動作開始と復帰
  • タスク数が2と少ないので、タスク並列動作が解り易く、プライオリティ設定とその意味も理解容易
  • I2C/SPI割込みISRとのタスク同期に、バイナリセマフォ利用
  • 割込みcallback関数でセマフォをgive → 割込み処理タスクでセマフォをtake → セマフォ消滅
  • IoT MCUは、セキュティデバイスとのI2C接続可能性大
  • メモリ使用法は、heap_4を利用

セマフォ(Semaphore)同期は、マイコンRTOS習得2017の第3部:Semaphoreによるタスク同期の章に、図入り解説していますのでご参照ください。

FreeRTOSサンプルソースコードは、MCUXpresso IDEのみでも御覧頂けます。是非、PCへインストールし本稿をご参照ください。

MCU:マイコン,LPCマイコン,Kinetisマイコン,Cortex-M4コアARMマイコン,LPCXpresso,FreeRTOS,LPCXpresso SDK,LPCXpresso54114

FreeRTOSデバッグは、ベアメタルソフトウェアデバッグと異なる準備が必要です。

幸いなことに、前稿で示したMCUXpresso54114評価ボードとSDK付属FreeRTOSサンプルコードを使ってMCUXpresso IDEでFreeRTOSデバッグを行う場合は、この準備がサンプルコードやIDEデバッガに予め設定済みです。何もせずに直にデバッグができます。

FreeRTOSデバッグ準備

但し、LPCOpenライブラリFreeRTOSサンプルコードを利用する場合や、FreeRTOSソフトウェアを自作する場合には、この事前準備を知らないとFreeRTOSデバッグができません。
※LPCOpenライブラリと下記MCUXpresso IDE FreeRTOS Debug Guideも前稿参照。

MCUXpresso IDE FreeRTOS Debug Guideの2章に、準備理由や追加設定個所が詳細に記載されています。

  • デバッグリンクサーバー(CMSIS-DAP)のAll-Stopモードへ切り替え ※デフォルトはNon-Stopモード
  • FreeRTOSカーネルソースコード修正 ※SDK付属サンプルコードは修正済み
  • メモリ使用法の設定

上2つは、IDEでFreeRTOS本体動作確認のための設定、メモリ設定は、限られたMCUメモリの活用方法でheap_1~5まで5種類あります。

これらは、ベアメタル開発とは異なるFreeRTOS利用オーバーヘッドで、メモリ使用法は、動作するMCU毎に異なりノウハウが必要になると思います。MCUXpresso54114評価ボードSDK付属FreeRTOSサンプルコードのメモリ使用法は、調査します。

FreeRTOSサンプルコード:タスク数=1

MCUXpresso54114 SDK v2.7.0の11個あるFreeRTOSサンプルコードを、タスク数で並び換えたのが下表です。本稿は、タスク数=1のFreeRTOSプロジェクトを調査します。

FreeRTOSソフトウェア開発は、タスク数が少ない方が理解し易くタスクプライオリティ設定も不要です。この中では、freertos_swtimerが一番簡単、下方につれて複雑なプロジェクトになります。

FreeRTOSプロジェクト:タスク数=1
Project Tasks heap_ Additional FreeRTOS APIs (Bold) Additional Comments
freertos_swtimer 1 4

xTaskCreate
vTaskStartScheduler
xTimerStart

IDE Console出力
ユーザ作成Software Timerデモ

freertos_hello 1 4

xTaskCreate
vTaskStartScheduler
vTaskSuspend

IDE Console出力

freertos_usart 1 4

xTaskCreate
vTaskStartScheduler
vTaskSuspend

Usart 115200bps 8-Non-1送受信
4B受信後エコーバック

※heap_4:断片化を避けるため、隣接する空きブロックを結合。絶対アドレス配置オプション含む。
※FreeRTOS API接頭語x/v:API戻り値型を示し「v」がvoidを、「x」が結果コードまたはハンドルを返す。

サンプルコード利用FreeRTOS APIと、Doc>readme.txtのProject説明へ付け加える内容をAdditional Commentsに記載しました。太字以外のFreeRTOS APIは、マイコンRTOS習得2017で説明済みのため、本稿では省略します。

xTimerStartは、ユーザ作成ソフトウェアタイマの動作開始FreeRTOS APIです。

IDE Consoleは、ソースコード内へマクロ:PRINTFを挿入すると、IDE下段Console窓へ数値や文字列などの入出力が簡単にできる機能です。

FreeRTOS Project:main()

ベアメタルmain()と同様、初期設定+無限ループの構造です。
差分は、タスク登録とスケジューラー起動から成るFreeRTOS初期設定が、評価ボード初期設定後に加わることです。

FreeRTOS Project main()構造(freertos_helloにコメント加筆)
FreeRTOS Project main()構造(freertos_helloにコメント加筆)

FreeRTOS Project:freertos_swtimer

ユーザ作成の1秒ソフトウェアタイマ割込み(SwTimerCallback)を使って、Console窓にTick文字を出力します。タスク登録直後、xTimerStartでユーザタイマをスタートしています。

例えば、ユーザ入力待ちの開始時にxTimerStartし、ユーザ反応が何もない時のタイムアップ処理などに使うと便利です。

FreeRTOS Project:freertos_hello

タイトル出力など1回限りのConsole窓出力に便利です。hello_taskは、出力後、vTaskSuspendで待ち状態になります。タスク正常終了後は、vTaskSuspend処理が一般的なようです。

FreeRTOS Project:freertos_usart

UART0の115200bps 8-Non-1を使ったVirtual COMポート送受信タスクです。受信リングバッファ利用で4B受信後に受信文字をエコーバックします。4Bまとめてのエコーバックは、1B毎よりも効率的です。

例えば、処理途中で割込みなどの他処理が入っても、受信リングバッファ利用で取りこぼしデータがなく、かつ、RTOSが処理中断/再開を行うので、このような記述がFreeRTOSマルチタスク動作に好都合かもしれません。
ベアメタル開発にはないRTOSソフトウェア開発ノウハウの可能性があります。

※筆者自身RTOSは初心者です。本調査結果は、FreeRTOS APIレファレンス等も参照して記述しておりますが、多分に上記のような推測の域があることはご容赦ください。

FreeRTOSサンプルコード:タスク数=1の調査結果

  • FreeRTOS初期設定(タスク登録とスケジューラー起動)が、評価ボード初期設定後に追加
  • PRINTFを活用したFreeRTOSタスク単体デバッグの手本
  • タスク正常終了後は、vTaskSuspend処理
  • UART0利用VCOM送受信タスク(uart_task)は、移植性が高く、流用・応用が容易
  • メモリ使用法は、heap_4を利用

ここで示したFreeRTOSサンプルコードは、MCUXpresso54114評価ボードがあると動作確認が可能ですが、無くてもMCUXpresso IDEをPCへインストールすれば、どなたでもコストがかからず参照頂けます(インストール方法は、関連投稿:NXPマイコン開発環境更新を参照)。

普段NXPマイコンをお使いでない方も、MCUXpresso IDEをインストールしFreeRTOSサンプルコードをご覧ください。不要になった後は、IDEアンインストールも簡単です。

以降のFreeRTOSサンプルコード関連投稿は、お手元に上記開発環境があるものとして説明いたしますので、よろしくお願いいたします。



MCU:マイコン,LPCマイコン,Kinetisマイコン,Cortex-M4コアテンプレート,ARMマイコン,LPCOpen,IoTマイコン,FreeRTOS,SDK,Cortex-M4,LPCXpresso54114,サンプルコード,ベアメタル,MCUXpresso IDE

NXPのCortex-M4/M0+ディアルコアLPCXpresso54114のFreeRTOSサンプルコードを数回に分けて調査します。Cortex-M4クラスのMCUは、処理は高速で大容量Flash、RAMを持つので、ベアメタル利用だけでなくRTOS利用ソフトウェア開発にも適します。

ベアメタルCortex-M0/M0+/M3に適用済み弊社テンプレートを、そのままCortex-M4 MCUに使うのは、テンプレートがMCU非依存なので簡単です。ですが、先ずFreeRTOSソフトウェアをよく知り、新開発ベアメタルCortex-M4テンプレートへ応用できる機能があるか判断するのが調査の目的です。

RTOS習得2017

2017年3月にLPCXpresso824-MAX(Cortex-M0+ 30MHz、32KB Flash、8KB RAM)を使ってFreeRTOSのポイントを調査し、結果をマイコンRTOS習得ページにまとめました。

第1部から第3部で、最低限のFreeRTOSと使用APIを解説し、第4部で、最も優れた解説書と筆者が考えるソースコードと評価ボードを使ってFreeRTOS動作解析と習得を行うという内容です。

ただ、自作FreeRTOSサンプルコードの出来が悪く、第4部の動作解析は不十分でした。

そこで、RTOS利用がより現実的なLPCXpresso54114(Cortex-M4/M0+ 100MHz、256KB Flash、192KB RAM)評価ボードとSDK付属FreeRTOSサンプルコードを用いて、不十分だった第4部FreeRTOS動作解析に再挑戦します。平たく言えば、NXP公式FreeRTOSサンプルコードを、不出来な自作コードの代わりに利用します😅。

第1回目は、FreeRTOSサンプルコードの出所、FreeRTOS動作を調べる4ツールを説明します。

LPCXpresso54114 SDK付属FreeRTOSサンプルコード

NXPマイコンの公式サンプルコード取得方法は、3つあります。最も新しいのがSDK:Software Development Kitから、2つ目がLPCOpenライブラリから、3つ目がPE:Processor Expertからの取得です。

NXP社が古くから用いてきたサンプルコード提供方法が、LPCOpenライブラリです。
NXPに買収された旧Freescale社のKinetis MCUなどは、PEと呼ばれるGUIベースAPI生成ツールでサンプルコードを提供していました。同じMCUでも提供方法によりAPIは異なり、サンプルコード互換性はありません。
※ベンダ毎に異なるAPI提供方法やその違い、サンプルコードとの関係は、別投稿で説明する予定です。

Freescale買収後のNXPは、SDKで全MCU(=新旧NXP+買収FreescaleのMCU)のAPIとサンプルコードを提供する方法に統一したようです。その根拠は、最新MCUXpresso IDEユーザインタフェースが、SDKの利用前提でできているからです。

現在も提供中のLPCOpenライブラリ内にあるLPCXpresso54114 FreeRTOSサンプルコードは2個、一方、SDK内のFreeRTOSサンプルコードは11個あります。PE提供はありません。

調査対象としては、FreeRTOSサンプルコード数が最多のSDKが適しています。

LPCXpresso54114 FreeRTOS examples in SDK
LPCXpresso54114 FreeRTOS examples in SDK

FreeRTOS実動作解析ツール

MCUXpresso IDE v11.1.0のHelp>Help Contentsに、MCUXpresso IDE FreeRTOS Debug Guideがあります(PDF文書がMCUXpresso IDEインストールフォルダ内にも有り) 。この中に、FreeRTOSサンプルコードデバッグのみに使えるタスク対応デバッガ4ツール(Task List/Queue List/Timer List/Heap Usage)があります。

MCUXpresso IDE Help ContentsのFreeRTOS Debug GuideのShowing FreeRTOS TAD Views
MCUXpresso IDE Help ContentsのFreeRTOS Debug GuideのShowing FreeRTOS TAD Views
  • Task List:タスク毎のプライオリティ、スタック使用量、動作時間表示
  • Queue List:アクティブキュー、セマフォ、ミューテックス利用時のリソース表示
  • Timer List:RTOSタイマー表示
  • Heap Usage:ヒープ使用量、メモリブロック割当て表示

これらFreeRTOS専用ツールは、FreeRTOSサンプルコードの評価ボード動作後、デバッガ停止中に表示されます。シミュレーションではなく、評価ボードでの「実動作結果」が判ります。開発ソフトウェアだけでなくRTOS使用量が判るので、デバイスにどれ程リソース余裕があるかが判断できます。

RTOSソフトウェアは、ユーザが開発するタスクの単体、結合デバッグに加え、RTOS動作の確認事項が増えます。FreeRTOS実動作解析4ツールは、これらの確認ができます。評価ボードを使ったプロトタイプ開発の重要度は、ベアメタル開発比より大きくなると言えるでしょう。

次回以降、LPCXpresso54114のSDK付属FreeRTOSサンプルコードを、MCUXpresso IDEのFreeRTOS Debug Guideに沿って調査します。