マイコンやIoT関連の情報、Tipsなどを記載します。

MCU:マイコン,STM32マイコン,Cortex-M0+コア,Cortex-M23コア,Cortex-M4コアIoTマイコン,STM32CubeMX,セキュリティ,STM32CubeIDE,STM32G071RB,HAL API,STM32G474RE,STM32RTOS

2021年7月19日、STマイクロエレクトロニクスのMCU統合開発環境が、STM32CubeIDE v1.7.0とSTM32CubeMX v6.3.0へ更新されました。Major releaseです。開発済みMCUのSTM32CubeMX設定を、簡単に別ターゲットMCUへ移植する機能を解説します。

Major Release

STM32CubeIDE(以下、CubeIDE)は、ベースのEclipse IDE 更新に追随し年数回更新があります。今回のCubeIDE v1.7.0更新内容に、特に気になる点はありません。

一方CubeIDE付属コード生成ツール:STM32CubeMX v6.3.0(以下、CubeMX)には、開発済みMCUのCubeMX設定を、別MCUや別シリーズMCUへ簡単に移植する機能があります。移植性の高いHAL(Hardware Abstraction Layer)APIと併用すると、開発済みソフトウェアの再利用が簡単で強力なAPI生成ツールになりました。

STM32CubeMX設定移植機能

CubeMXには詳細な英語ユーザマニュアルUM1718 Rev35(全368ページ)があり、p1に主要機能説明があります。本ブログでもCubeMXコード生成機能の使い方やその重要性、STM32F0からF1へのソフトウェア移植方法などを何度か紹介してきました(検索窓に「STM32CubeMX」と入力すると関連投稿がピックアップされます)。

従来投稿は、MCUのCubeMX設定を、ターゲットMCUへ各項目を見ながら手動移植する方法でした。この方法は、予めターゲットMCUとの互換性が解っている場合や、移植周辺回路が少ない場合には有効です。

しかし、MCUの種類が増え、別シリーズMCUへ、または多くの周辺回路設定を個別に移植したい場合は、事前チェックは面倒です。そんな時に役立つ2機能が、UM1718 p1太文字記載の下記です。

  • Easy switching to another microcontroller
  • Easy exporting of current configuration to a compatible MCU

どちらもCubeMX画面のPinout & Configurationタブ選択、Pinoutプルダウンメニュー>List Pinout Compatible MCUs (Alt-L)をクリックすると、Full Compatible/Need Hardware change MCUが一覧表で表示されます。

List pinout compatible MCUs
List pinout compatible MCUs

STM32G0xテンプレート例

販売中STM32G0xテンプレートで使用中の汎用MCU:STM32G071RB(Cortex-M0+/64MHz、Flash/128KB、RAM/36KB)の例を示します。これは、評価ボードNUCLEO-G071RB搭載MCUです。

STM32G071RB Full and Partial match MCU List
STM32G071RB Full and Partial match MCU List

評価ボード搭載のLQFP64パッケージでフィルタ設定すると、青色:完全互換の汎用STM32G0シリーズMCUが12アイテム、黄色:一部ハードウェア変更が必要な低電力STM32L0シリーズMCUが17アイテムリストアップされます。

例えば、FlashやRAMを増量したい場合には、STM32G0B1RBへ開発ソフトウェアがそのまま移植できることが解ります。また、より低電力化したい場合には、STM32L071RBへも移植可能です。あとは、ターゲットMCUを選択し、STM32G0xテンプレートのCubeMXプロジェクト設定を全て移植するか、または一部周辺回路のみを移植するかの選択も可能です。

つまり、開発済みソフトウェアを別MCUへ移植する際に、容易性(完全互換/一部HW変更)と方向性(大容量化/低電力化など他MCUシリーズ適用)を評価でき、かつ、ターゲットMCU選択後は、ダイアログに従って操作すれば、CubeMX設定全て、または周辺回路毎にターゲットMCUへ自動移植ができる訳です。

CubeMX設定の移植後は、ターゲットMCU上で通常のようにコード生成を実行すれば、周辺回路初期設定や動作に必要となる関数群の枠組みが作成されます。その枠組みへ、STM32G0xテンプレートのHAL API開発済みソフトウェアをコピー&ペーストし、ターゲットMCUへのソフトウェア移植が完了です。

汎用MCUとHAL APIプロトタイプ開発

最新メインストリーム(汎用)プロトタイプ開発イメージ
最新メインストリーム(汎用)プロトタイプ開発イメージ

CubeMX設定の自動移植が簡単なことは、前章まででご理解頂けたと思います。

前例STM32G0xテンプレート開発ソフトウェアの移植可能なMCU数が12+17=29と大きいのは、汎用MCUとHAL APIを使ったソフトウェア資産だからです。

最新IoT MCU開発でも、STM32G0/G4シリーズなどの移植性が高い汎用MCU(=メインストリームMCU)とHAL APIを使って主要機能をプロトタイプ開発し、CubeMX移植機能を使ってターゲットIoT MCUへ移植すれば、最新IoT MCUの差分機能開発に集中できます。

つまり、「汎用MCUとHAL API利用のプロトタイプ開発は、他MCUへの移植性が高く、汎用との差分開発に集中できる高い生産性」をもたらす訳です。

※STM32G0/G4シリーズは、新プロセスで従来汎用STM32F0/F1/F3シリーズを高速・低電力化・セキュリティ強化した新しい汎用MCUです。コチラの関連投稿や、STM32U5発表と最新IoT MCU動向を参照してください。

STM32G0とG4のセキュリティ対応(出展:STM32 Security対応表に加筆)
STM32G0とG4のセキュリティ対応(出展:STM32 Security対応表に加筆)

まとめ

STマイクロMCU統合開発環境が、STM32CubeIDE v1.7.0とSTM32CubeMX v6.3.0へMajor Releaseされました。

開発済みMCUのCubeMX設定を、別MCUへ簡単に移植する機能があり、移植性が高い汎用(メインストリーム)MCUとHAL APIによるプロトタイプ開発ソフトウェア資産を、効率的に他MCUへ再活用できる統合開発環境になりました。

補足:NUCLEO評価ボードのユーザLED不足対策

汎用MCUとHAL APIプロトタイプ開発には、低価格で入手性も良いNUCLEO評価ボードが適しています。

但し、NUCLEO評価ボードのユーザ緑LED(LD2)とSW(B1)が、各1個と少ない点が残念です。CubeIDEサンプルプログラムは、単機能サンプル動作なので各1個でもOKですが、少し複雑な例えばRTOS並列動作確認などには、特にLEDが不足します。

お勧めは、赤LED 2個、SW 1個が実装済みのArduinoプロトタイプシールドです。残念ながらNUCLEO評価ボードSW(B1)は操作できないのでシールドSWで代用します。評価ボードArduinoピンとの配線や、付属ブレッドボードへの回路追加も簡単です。ST以外の様々なMCUベンダのArduinoコネクタ付き評価ボードでも使えます。

NUCLEO評価ボードLED不足対策のArduinoプロトタイプシールド。付属ブレッドボードに回路追加も容易。
NUCLEO評価ボードLED不足対策のArduinoプロトタイプシールド。付属ブレッドボードに回路追加も容易。

NUCLEO-G474REとArduinoプロトタイプシールドの使用例を示します。ArduinoプロトタイプシールドのLED1は、Lpuart受信、LED2は、SW操作、評価ボードのLD2は、1s/500ms/40ms点滅の動作確認に使っています。

STM版RTOSアプリケーションテンプレート構想もこの環境で検討中です(関連投稿:STM32RTOS開発3注意点(前編)、(後編))。


MCU:マイコン,STM32マイコン,Cortex-M4コアARMマイコン,FreeRTOS,STM32CubeMX,STM32G071,STM32G4,Azure RTOS,CMSIS RTOS,CMSIS-V1

STM32MCUでRTOS開発を行う時の3注意点、前編のSTM32CubeMX、HALに続き、本稿後編でCMSIS-RTOS関連を示します。

※木曜からの東京オリンピック4連休のため、通常金曜を本日水曜日に先行して投稿します。

前編は、STM32RTOS開発実例として、NUCLEO-G474RE FreeRTOS_QueuesサンプルプロジェクトのSTM32CubeMX(以下CubeMX)コード出力を使い、HALタイムベース変更の必要性を示しました。後編は、前編と同じ実例を使ってCMSIS-RTOSの注意点を示します。

FreeRTOS_Queues STM32CubeMXファイルのTasks and Queues

NUCLEO-G474RE FreeRTOS_QueuesサンプルプロジェクトのCubeMX構成ファイル:FreeRTOS_Queues.icoを開き、Middleware>FREERTOSのTasks and Queuesタブをクリックしたのが下図です。

FreeRTOS_QueuesのSTM32CubeMXファイルTasks and Queues
FreeRTOS_QueuesのSTM32CubeMXファイルTasks and Queues

2つのタスク:MessageQueuePro(Qプロデューサ:送信タスク)とMessageQueueCon(Qコンシューマ:受信タスク)と、1つのQ:osQueue(深さ1:ワード)を、CubeMXで自動生成するパラメタが設定済みです。関連投稿:NXP版FreeRTOSのQueueデータ送受信と同じです。

全て黒文字パラメタですので、変更も可能ですが、このままソースコードを自動生成(Alt+K)してください。

CMSIS-RTOS APIからFreeRTOS API変換(wrapper)

CMSIS-RTOS APIからFreeRTOS API変換
CMSIS-RTOS APIからFreeRTOS API変換

main.cのL125に、osQueueを生成するAPI:osMessageCreateが自動生成済みです。また、L134とL138に、MessageQueueProとMessageQueueConのタスク(Thread)を生成するAPI:osThreadCreateも自動生成済みなのが判ります。

ここで、API先頭にosが付くのは、CMSIS-RTOSのAPIだからです(L145のosKernelStartも同様)。詳細は、次章で説明します。

さて、L125のosMessageCreateへカーソル移動し、F3をクリックすると、cmsis-os.cのL1040へジャンプし、CMSIS-RTOS APIのosMessageCreateの中身が見えます。その中身が、L1055のxQueueCreateで、これはFreeRTOSのAPIです。

つまり、CubeMXが自動生成したのは、CMSIS-RTOS APIですが、その実体は、FreeRTOS APIであることが判ります。
この例のように、CubeMXが生成したCMSIS-RTOS APIは、cmsis_os.cで全てFreeRTOS APIへ変換されます。

CMSIS-RTOS

CMSIS-RTOSは、Cortex-Mコア開発元ARM社が定めたRTOS APIの規格です。
※CMSIS:Cortex Microcontroller Software Interface Standard

Cortex-Mコアには、FreeRTOS/Azure RTOS/mbed OSなど様々なRTOSが使えます。下層のRTOSが変わるとAPIも変わりますが、そのAPIを変換し、上層アプリケーションへ共通なRTOS APIを提供する、これにより、

  1. RTOSが異なっても、同じ開発アプリケーションが使えること
  2. Cortex-Mコアが異なっても、開発アプリケーション移植を容易にすること

これらがCMSIS-RTOSの目的です。

これをラップ(wrap=…を包む)と呼ぶことがあります。ラップ関数(wrapper)とは、下層API差を隠蔽し、上層アプリケーションへ同一APIを提供する関数のことです。STM32RTOS開発でのCubeMXの役目の1つは、使用するRTOSに応じたwrapperを提供することです。

現在、STM32RTOS開発のCubeMXがラップしているのは、FreeRTOSだけです。今後、FreeRTOSがAzure RTOSなどへ変わっても、開発アプリケーションをそのまま活用するために、今の時点からCMSIS-RTOS APIを使っている訳です。

Cortex-M0/M0+/M3/M4/M7コア向けの共通RTOS APIがCMSIS V1、Cortex-A5/A7/A9と全Cortex-Mコア向けの共通RTOS APIがCMSIS V2です。STM32RTOS開発では、CMSIS V1を用います。

CMSIS-RTOS とFreeRTOSのAPI

UM1722にCMSIS-RTOS APIとFreeRTOS APIの一覧が示されています。抜粋したのが下表です。

FreeRTOSとCMSIS-RTOSのAPI
FreeRTOSとCMSIS-RTOSのAPI

接頭語にx/vなどが付くのがFreeRTOS API、osが付くのがCMSIS-RTOS APIです。

CubeMXが生成するコードは、常にCMSIS-RTOS APIですが、実体はFreeRTOS APIです。FreeRTOSが別のRTOSへ変わっても、CMSIS-RTOS APIは同じです。CMSIS-RTOS APIとFreeRTOS APIのwrapper分のオーバーヘッドは生じますが、下層RTOSに依存しない点は、先進的で優れています。

なおUM1722 Rev3には、単にAPI列記とwrapper、RTOSサンプルプロジェクトの簡単な説明が記載されているだけです。

まとめ

STM32MCUでRTOS開発を行う時の3注意点(前編:STM32CubeMX、HAL)に続き、本稿後編で3つ目のCMSIS-RTOSを示しました。

STM32RTOS開発のSTM32CubeMXが扱うRTOSは、現在FreeRTOSだけです。FreeRTOSが別のRTOSへ変わっても、CubeMXは、開発アプリケーション流用性を高めるためにFreeRTOS APIの代わりにRTOS共通CMSIS-RTOS APIを出力します。

CMSIS-RTOS APIには、Cortex-M0/M0+/M3/M4/M7コア間で開発アプリケーション移植性が高いCMSIS V1を使います。

CMSIS-RTOS API変換オーバーヘッドがありますが、流用性、移植性に優れたRTOSアプリケーション開発ができる点は、優れています。

あとがき

残念ながらCMSIS-RTOS情報は、シェア1位AWSのFreeRTOSに比べ少なく、この少ない情報を使ってSTM32RTOS開発を行うのは、大変です。
※2位がAzureのAzure RTOS、3位がGCP(Google Cloud Platform)のmbed OS。関連投稿はコチラ

例えば、最初の図:CubeMXのTasks and QueuesのGUI設定パラメタが多いにもかかわらず、UM1722サンプルプロジェクト説明が少ない点などです。

RTOSは、複数タスク(CMSIS-RTOSではThread)間の優先順位差とRTOS自身の動作により、開発タスク処理状態が変わります。ベアメタル視点に加え、RTOS視点でのタスク開発と経験が求められます。QueueなどRTOS単独手段理解が目的のサンプルプロジェクトだけでは、RTOS開発経験は積めません。

弊社はこれらの対策として、効率的なRTOS基礎固め、STM32RTOSアプリケーションのプロトタイプ開発早期着手を目的としたSTM版RTOSアプリケーションテンプレート(仮名)を検討中です。その構想は、固まり次第、別稿にて示す予定です。

なお、NXP版FreeRTOSアプリケーションテンプレートは、コチラで販売中です。

RL78マイコン,MCU:マイコン,LPCマイコン,Kinetisマイコン,STM32マイコン,PSoC/PRoCマイコン,MSP432マイコンARMマイコン,IoTマイコン,半導体,半導体不足

経産省が2021年6月4日に発表した「半導体・デジタル産業戦略」について、専門家の評価は悲観的です。

我々IoT MCU開発者は、ホノルル便パイロットを見習い、対応策を持つべきだと思います。

経産省半導体・デジタル戦略の評価

今こそ日本の大手電機各社は半導体技術の重要性に気付くべき、EE Times Japan、2021年6月15日

日本の半導体戦略は“絵に描いた餅”、TechFactory、2021年6月16日

日本の半導体ブームは“偽物”、再生には学校教育の改革が必要だ、EE Times Japan、2021年6月22日

専門家が日本政府や経産省の方針を批判するのは、コロナ対策と同様、当然です。また下記、英)Financial Times評価を紹介した記事からも、専門家評価と同様、概ね懐疑的であることが判ります。

半導体製造業の日本の取組みに対する海外メディア評価、Gigazine、2021年7月6日

この戦略結果として生じる半導体・デジタル産業の市場変化の影響を直接受けるのは、我々IoT MCU開発者です。しかも、結果がでるまでの時間は、ますます短くなっています。この分野が、自動車や次世代通信などを含む「全ての産業の要」だからです。

経産省戦略資料は、コチラからダウンロードできます。概要・概略だけでも相当な量があり、対象がMCU技術者ならまだしも、マネジメントや一般技術者が、本当に要点を把握できるか、筆者でも疑問に感じます。

ホノルル便緊急事態対策

かつて護送船団方式ともいわれた日本産業の舵取りは、成功もありますが失敗も多いです。同調圧力に弱い日本人には、この方式が向いていたのかもしれません。

問題は、舵取りの結果生じる市場変化に、どう対応するかです。

対応策ヒントの1つになるのが下記記事です。

太平洋の真ん中でエンジン停止したらどうなるか、東洋経済、2021年6月27日

パイロットは、太平洋上での緊急事態対応のため、60分毎に東京/ミッドウェー/ホノルルの天候情報を集め、燃料残量や対地速度などの機体状況を確認し、180分以内に着陸できる空港を検討するのです。しかも、この緊急事態は、パイロットが入社し定年退職するまでに一度も経験することの無い0.024%の発生確率でもです。

ホノルル便パイロットの緊急事態対応(出展:記事)
ホノルル便パイロットの緊急事態対応(出展:記事)

この東京~ホノルル便エンジン停止などの緊急事態発生確率に比べると、半導体・デジタル産業の国による舵取り失敗確率は、高いと思います。

我々MCU開発者も、ホノルル便パイロット並みとはいかなくても、せめて開発が一段落付く毎に、最新IoT MCU状況を確認し対応を検討することは重要です。一段落が付いた時は、開発に使ったMCUの利点欠点を把握直後なので、他MCUとの比較も精度良くできるからです。

この検討結果をどのように反映するかは、開発者次第です。

お勧めは、もしもの時の「第2候補IoT MCU案:Plan Bを、開発者個人で持つこと」です。Plan Bは、たとえ同じARM Cortex-Mコア利用であっても、ベンダ毎に手間やAPIが異なるIoT MCU開発に、心理的余裕を与えます。Non ARMコア利用ならなおさらです。

個人でなら、同調圧力に関係なく、自分の開発経験や勘を使ってPlan Bを検討できます。

まとめ

2021年6月経産省が発表した半導体・デジタル産業戦略の専門家評価は、悲観的です。国の舵取りが失敗した例は、過去の電機や半導体企業の衰退が物語っています。巨額投資と市場シェアの両方が必要な半導体・デジタル分野は、既に弱体化した国内企業の巻返しにも期待はできません。

舵取り失敗確率は、現役ホノルル便パイロットが、太平洋上で緊急事態に出会う確率よりも高いでしょう。

最先端デバイスを利用するIoT MCU開発者の対応策の1つは、開発が一段落付く毎に、最新半導体・デジタル市場を確認し、もしもの時の第2 IoT MCU利用案:Plan Bを開発者個人で持つことです。

個人で安価にPlan Bを持つため、評価ボード動作確認済み各種マイコンテンプレートはお役に立てると思います。関連投稿:半導体不足とMCU開発案に、Plan B構成案もあります。

MCU:マイコン,STM32マイコン,Cortex-M0+コア,Cortex-M4コアARMマイコン,IoTマイコン,FreeRTOS,STM32CubeMX,HAL,NUCLEO-G071RB,NUCLEO-G474RE,API生成ツール,CMSIS RTOS

STマイクロエレクトロニクス)STM32MCUを使ってRTOS開発時のSTM32CubeMX、HAL、CMSIS RTOSの3注意点について示します。前編が、STM32CubeMXとHALについてです。CMSIS RTOSは、別途後編で示します。

STM32CubeMXとHAL の注意点を解説した後、サンプルプロジェクトで実例を示すという順番で説明します。

ソースコード生成ツール:STM32CubeMX

STマイクロのソースコード生成ツール:STM32CubeMX(以下CubeMX)は、MCU内蔵周辺回路の初期設定やAPIを、GUIベースで自動生成する非常に便利なツールです。

※MCUベンダのAPI生成ツールを比較した関連投稿は、コチラをご覧ください。

CubeMX生成APIは、ハードウェアを抽象化し、STM32MCU間で最大限の高いソフトウェア移植性を狙ったHAL (Hardware Abstraction Layer)と、よりハードウェアに近くHALよりも高速・軽量なエキスパート向けLL(Low-layer)の2種類から選択可能です。

HALとLL比較(出典:STM32 Embedded Software Overvire)
HALとLL比較(※説明のため着色しています。出典:STM32 Embedded Software Overvire)

一般的に、HAL APIが好まれます。というのは、このLL APIを利用し開発した2019年6月発売のSTM32G0xテンプレートV1の売上げはゼロでした。対策に、LL APIからHAL APIに変更し再開発した2020年6月発売のSTM32G0xテンプレートV2は、人気があるからです。

これらCubeMXの各種GUI設定や選択APIは、CubeMXファイル(.ico)に構成ファイルとして纏められます。

STM32MCU新規プロジェクト開発時に、この既成CubeMXファイル(.ico)を利用すると、ゼロから着手するのに比べ、効率的かつ間違いなく周辺回路や初期設定ができるため、利用価値の高いファイルです。

特に、ベアメタル比、さらに多くのCubeMX設定が必要となるRTOS開発では、既成CubeMXファイルを再利用するメリットがより高まります。同時に、生成コードの意味も理解しておく必要があります。

HALタイムベース

HALには、他ベンダにない便利なAPI:HAL_Delayがあります。

例えば、10msの待ち処理を行う場合、他ベンダなら、MCUコア速度に応じて適当にループ回数を調整したループ処理で10ms相当の遅延を自作します。しかし、HAL APIならば、HAL_Delay(10)の記述だけで、MCUコア速度に依存しない正確な10ms遅延が実現できます。

これは、HAL自身が、MCU内蔵タイマ:SysTickの利用を前提に設計されているからです。遅延処理を例に説明しましたが、STM32のHAL APIsは、SysTickと強く結びついています。

もちろん、HAL APIをベアメタル開発で利用する場合は、この結びつきに何ら問題はありません。

RTOSタイムベース

FreeRTOSも、タスク(スレッド)状態遷移タイムベースに、SysTickを使います。

これは、FreeRTOSだけでなく他のRTOSでも同じです。SysTickは、その名称が示すようにMCUシステムレベルのタイムベース専用タイマです。

従って、STM32MCUでRTOS開発を行い、かつHAL APIを利用する場合には、RTOS側でSysTickを使うのが、名称に基づいた本来の使い方です。

HALタイムベース変更

そこで、STM32RTOS開発でHAL利用の場合は、HALのタイムベースを、デフォルト使用のSysTickから別のタイマへ変更する必要が生じます。この変更に伴う手動設定も当然必要となります。

*  *  *

ここまでが、STM32RTOS開発におけるSTM32CubeMXとHALに関する注意点です。
これらの注意点が解っていると、次章で示すRTOSサンプルプロジェクトのCubeMXファイルの意味と生成コードが理解できます。

STM32RTOS開発実例

STM32RTOS開発実例に、評価ボード:NUCLEO-G474RE(Cortex-M4/170MHz、Flash/512KB、RAM/96KB)でRTOS開発する場合を示します。

NUCLEO-G071RB(Cortex-M0+/64MHz、Flash/128KB、RAM/32KB)でRTOS開発する時でも同様です。しかも、RTOSサンプルプロジェクトは、STM32G071RBの方が(発売が古いためか?)多いので、NUCLEO-G071RBをお持ちの方は、是非ご自身で試してみてください。

FreeRTOS Example Selector

STM32CubeIDEのFile>STM32 Projectで、新規プロジェクト作成パネルを表示します(最新情報更新のため、表示に少し時間がかかる場合があります)。Example Selectorタブを選択、Middleware>FreeRTOSにチェックを入れ、NUCLEO-G474REのFreeRTOS_Queuesを選択したのが下図です。

NUCLEO-G474REのFreeRTOS_Queues
NUCLEO-G474REのFreeRTOS_Queues

右上欄、Noteの内容が、前半までに示した注意点のことです。参照先UM1722 Rev3は、CMSIS RTOSとFreeRTOSの関係があるのみです。このCMSIS RTOSについては、別途後編で説明します。

Nextをクリックし、FreeRTOS_Queuesサンプルプロジェクトを新規作成します。

さて、FreeRTOS Examples Listが318アイテム(STM32CubeIDE v1.6.1時)もあるので、Exportをクリックし、出力されたExcelファイルをBoardでフィルタリング、NUCLEO-G071RBとNUCLEO-G474REを抽出したのが下図です。

FreeRTOS Example List
FreeRTOS Example List

緑に色付けしたNUCLEO-G071RBの方が、FreeRTOSサンプルプロジェクト数が多いことが判ります。開発予定のSTM版FreeRTOSアプリケーションテンプレートは、Cortex-M4コアが対象ですので、本稿ではNUCLEO-G474REのFreeRTOS_Queuesを実例として使いました。

FreeRTOS_QueuesのSTM32CubeMXファイル

FreeRTOS_QueuesサンプルプロジェクトのCubeMX構成ファイル:FreeRTOS_Queues.icoが下図です。グレー文字は変更不可、黒文字は変更可能を示します。

FreeRTOS_Queues.ico
FreeRTOS_Queues.ico

TIM6がグレーなのは、HALタイムベース変更先がTIM6だからです。Kernel settings CPU CLOCK HZのSystemCoreClockがグレーなのは、RTOSタイムベースがSysTickだからです。つまり、本来の名称に基づいたSysTickがRTOS側で使われ、HALの新タイムベースにTIM6が割当済みであることが解ります。

FreeRTOS APIは、変更不可のグレーCMSIS V1です。ここは、後編で説明します。

デフォルトDisabledのUSE IDEL HOOKを、Enabledに変更し、ソースコード自動生成のGenerate Code(Alt+K)を実行してください。

HALタイムベースTIM6変更結果

FreeRTOS_QueseのTIM6とHook関数
FreeRTOS_QueseのTIM6とHook関数

app_freertos.cのL62に、Hook関数:vApplicationIdleHoolのひな型が自動生成済みです。ここへWFIを追記すれば、FreeRTOSアイドル時に低電力動作ができます。コチラのNXP版関連投稿Step5: FreeRTOS低電力動作追記と同じです。

main.cのL289は、TIM6満了時動作です。HAL_IncTick()が自動生成済みです。ベアメタル開発のSysTickからTIM6へHALタイムベースが変更されたことが解ります。

そのTIM6は、stm32g4xx_hal_timebase_tim.cで、1MHz=1ms満了に初期設定済みです。

つまり、STM32RTOS開発でHAL利用時に必要となる変更が、「全てCubeMXで自動生成済み」なのが解ります。

※上図は、USE_TICK_HOOKもEnabledへ変更した例です。Disabledへ戻すなどして、CubeMX自動生成ファイルが変化することを確かめてください。

この実例のように、CubeMX付属RTOSサンプルプロジェクトのCubeMXファイル(*.ico)を再利用すれば、周辺回路や初期設定ミスを防ぎ、RTOS新規アプリケーション開発が容易になることが解ります。

まとめ

STM32MCUでRTOS開発を行う時の3注意点、STM32CubeMX、HAL、CMSIS RTOSのうち、前編としてSTM32CubeMX、HALの2注意点とサンプルプロジェクトを使ってその実例を示しました。

RTOS開発では、既成STM32CubeMXファイル再利用価値が高まること、HALタイムベース変更の必要性がご理解頂けたと思います。3つ目のCMSIS RTOS関連は後編で示します。

あとがき

ベアメタル開発経験者であっても、STM32RTOS開発時、CubeMXのNoteを読むだけで、ベアメタル開発では何の問題も無かったHAL タイムベース変更理由が解り、その結果生じるCubeMXファイルや自動生成ソースコードの中身が理解できる方は、少ないと思います。本稿は、この変更理由と生成コードに説明を加えました。

STM32CubeMXは、STM32MCU開発に必須で強力なAPI生成ツールです。が、時々、説明不足を感じます。問題は、どのレベル読者を相手にするかです。エキスパートなら説明不要ですが、初心者ならゼロから説明しても解らないかもしれません。文章による組込み技術説明が、難しいのが根本原因でしょう😂。

そんな組込み開発ですが、文章だけでなく、「実際に評価ボードと手足を使って慣れてくると、案外すんなり簡単に理解、習得できる方が多いのも組込み開発」です。

販売中のNXP版FreeRTOSアプリケーションテンプレートにも、本稿同様、詳しいFreeRTOS解説を付けています(一部ダウンロード可能)。FreeRTOS開発を手軽に試せ、習得を支援するツールです。

MCU:マイコン,LPCマイコン,Cortex-M4コアテンプレート,アプリケーション,ARMマイコン,PSoC 6,FreeRTOS,Cortex-M4,Amazon FreeRTOS,STM32G4,LPCXpresso54114

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コアの対応版も開発予定です。

RL78マイコン,MCU:マイコンIoTマイコン,RL78/G1x,RL78/G23,Webシミュレータ,消費電流波形,平均消費電流,RL78/G2x,Fast Prototyping Board

今年4月に発表されたばかりのルネサスIoT向き新汎用RL78/G23が、RL78 Webシミュレータを使うと手間暇かけずに開発できます。このWebシミュレータの使い方と、RL78/G23シミュレーション結果を示します。

IoT新汎用RL78/G23特徴は、コチラの関連投稿を参照してください。

RL78 Webシミュレータとは?

評価ボードやIDE無しに、Webブラウザだけで対象MCUのアプリケーションを開発でき、その消費電流が判ります。バッテリー寿命予測などに好都合です。

対象MCUは、RL78/G1xシリーズでしたが、早くもG1x後継MCUのIoT向き新汎用RL78/G23が追加されました。ログイン必須ですが、無料で利用できます。

また、Webシミュレータ上で開発したソフトウェアは、CS+やe2 studioとも互換性があるので、そのまま実際のIDE/評価ボードへエクスポートして使うこともできます。

つまり、初期費用ゼロでRL78/G23が開発でき、その開発資産も活かせます。コロナ過の今こそ役立つツールと言えます。

競合他社32ビットCortex-M0+クラスのeclipseベースIDEにも、消費電流シミュレータが付属しています。RL78/G13比、30%低消費電力化したRL78/G23の低い消費電流と比較可能です。

RL78/G23 Webシミュレーション結果

RL78/G23の評価ボード:Fast Prototyping Boardを使って、基本的なA/D変換アプリケーションをシミュレーションする例で、Webシミュレータの使い方を示します。

MCU Simulator Online (Web IDE)

Webシミュレータ初期画面のアプリケーションから選択メニューのA/D変換機能をクリックし、対象デバイスRL78/G23のMCU Simulator Online起動をクリックします。ガイドツアー利用有無を聞いてきますが、後回しOKです。

Webシミュレータ初期画面からA/D変換機能をクリックした画面
Webシミュレータ初期画面からA/D変換機能をクリックした画面

RL78/G23 Fast Prototyping Board上で、A/D変換アプリケーション(サンプルアプリケーション)がインポートされたMCU Simulator Online画面が表示されます。

RL78/G23 A/D変換アプリケーションのMCU Simulation Online画面(Web IDE)
RL78/G23 A/D変換アプリケーションのMCU Simulation Online画面(Web IDE)

ビルド、リセットや実行などアプリケーション開発に最低限必要となるボタンが用意されたWeb IDEがMCU Simulator Onlineです。

ビルドをクリックするとConsole窓にビルド結果が表示されます。オリジナルサンプルアプリケーションのまま無変更なので、ビルドは成功します。

RL78/G23 Fast Prototyping Board

左端Boardクリックで、RL78/G23 Fast Prototyping Boardが表示されます。アプリケーション動作確認に必要な外部部品:ポテンショメータは、P22/ANI2に接続済みです。

RL78/G23 A/D変換アプリケーションのFasr Prototyping Board画面
RL78/G23 A/D変換アプリケーションのFasr Prototyping Board画面

実行をクリックすると、ポテンショメータのスライドバーに連動して、赤7セグ表示(変数値表示パネル)が変わります。これが、アプリケーション実行時のFast Prototyping Board動作状態です。

RL78/G23 A/D変換アプリケーション消費電流

左端Reportクリックで、アプリケーション動作時の消費電流シミュレーション波形と平均値が表示されます。ピーク時3mA、平均600μA程度でA/D変換を実行することが判ります。

RL78/G23 A/D変換アプリケーションの消費電流画面
RL78/G23 A/D変換アプリケーションの消費電流画面

Webシミュレータ終了

Webシミュレータで、RL78/G23とA/D変換アプリケーションを選んでビルド、評価ボードで動作確認、消費電流シミュレーション波形とその平均値を得るまで、わずか2~3分です(ガイドツアーは除く)。

実機で同じことを行えば、半日~1日は掛かります。しかも、実際のIDE設定や評価ボードとの接続、測定装置準備など全てが上手く出来た上での話です。実機ではこの段階で、つまずきを経験した方も多いでしょう。

手間暇かけずにWebシミュレータ上でRL78/G23開発を試すことができることがお解り頂けたと思います。

また、Web IDEでサンプルアプリケーションに変更を加えステップ実行、SWやLEDなどの外部部品をBoardへ追加することもできます。詳しくは、左下Info.クリックで表示されるガイドツアー、オリジナルプロジェクト作成を試すクリックで判ります。

ガイドツアー開始画面
ガイドツアー開始画面

Webシミュレータ終了は、MCU Simulator Online右上ハンバーガーメニューのサインアウトクリックです。プロジェクトは、90日間自動保存されますので、途中から開発継続することも容易です。

Web Simulator Online終了ダイアログ
Web Simulator Online終了ダイアログ

まとめ

RL78 Webシミュレータは、ブラウザだけを使って、誰でも簡単に初期費用ゼロでRL78/G1x/G2x開発が試せます。予め多くのサンプルアプリケーションがWeb IDEに用意済みで、仮想評価ボード上でアプリケーション動作確認、消費電流波形、平均消費電流計算が、僅か数分でシミュレーションできます。

Webシミュレータで開発したソフトウェアは、CS+やe2 studioへエクスポートできます。実機開発前、または、開発中であっても並行利用によりRL78/G1x/G2x開発に役立つツールです。

汎用RL78/G1x後継となったIoT向き新汎用RL78/G23のFast Prototyping Board上で、A/D変換アプリケーションシミュレーション例を示し、Webシミュレータ使用法、平均600μA低消費電流計算結果を得ました。

MCU:マイコン,LPCマイコン,Cortex-M4コアmbed OS,RTOS,semaphore,Amazon Web Service,Amazon FreeRTOS,IoT,IoTエッジMCU,queue,Azure RTOS

IoT MCUクラウド市場は、AWSとMicrosoft Azureがリードしており世界収益の半分以上を占めるという記事に掲載されたのが下図です(EE Times 2021年6月7日、横軸:市場シェア、縦軸:年平均成長率)。Microsoftは徐々にAmazonに迫っており、市場シェア差は、過去1年で2ポイント縮まったそうです。

クラウトプロバイダの市場シェア(出典:記事)
クラウトプロバイダの市場シェア(出典:記事)

多様化MCU RTOS

AWSへの接続にはAmazon FreeRTOS、Microsoft AzureにはAzure RTOSを用います。IoTクラウド接続ウェビナーでは、どのMCUベンダでも先行しているAmazon FreeRTOSを使った接続例が主流です。しかし、最近は、Azure RTOS利用の接続資料やウェビナーも見られます。AWSとMicrosoft Azureの差が縮まりつつある証左でしょう。

また、第3勢力として急成長中のGoogleクラウド接続にはARM mbed OSが使われます。IoT MCUに実装するRTOSは多様化してきました。

IoT MCU RTOSとPCブラウザ

IoT MCU RTOSとPCブラウザ比較
IoT MCU RTOSとPCブラウザ比較

この状況は、PCブラウザが現状、複数共存しているのに似ています。

機能的には同じブラウザですが、表示/印刷/広告などの使い勝手が少しずつ異なるため、必要に応じて複数ブラウザを使い分ける方も多いでしょう。記憶容量の大きいPCでは、ブラウザ併用・共存も簡単です。

しかし、限られた容量しか持たないMCUの場合は、複数RTOSの中からMCU搭載RTOSは1つに絞られると思います。

例えば、AmazonやMicrosoft、Google各社の強み(販売/文書/広告)や特徴を活かし、IoT機器制御サービスやAI活用サービスなど魅力的クラウドサービスを各社各様で提供し、その価格、顧客との結びつきの強さなどがサービス選択の決め手となるでしょう。

いずれにせよ顧客が、利用するクラウドサービスを決め、その接続手段として各社RTOS接続ライブラリの使用、加えてRTOS環境での上層MCUソフトウェア開発を行うことになります。

問題は、RTOS環境のMCUソフトウェア開発手法がベアメタルと異なること、各社RTOS仕様が少しずつ異なることです。

多様化RTOS対策

仮に、Cortex-M4/M0+ディアルコアMCUで、クラウド通信処理全てを、Cortex-M0+コア側のRTOSライブラリで行い、通信とアプリケーションが完全分離された構成であれば、問題は解決します。接続サービス毎にRTOS通信ライブラリを変えさえすれば、対応できるからです。

BluetoothやThreadなど複数無線通信規格から1つを選んで処理するなど、この構成に近いベアメタルソフトウェア対応のMCUが既にあります。

しかし、主流ウェビナーで用いられる高性能Cortex-M4シングルコアを使って、クラウド通信とアプリケーションの両方を処理する場合には、接続先のクラウドに応じて「FreeRTOS/Azure RTOS/Mbed OSなど様々なRTOS環境の上層アプリケーション開発」になります。

RTOSの目的は、MCUハードウェア隠蔽と開発ソフトウェア流用性向上なのに、複数RTOS存在で開発アプリケーションが異なるとは、皮肉な結果です。

最初の図は、IoT MCU開発者が、今後急増するクラウド接続IoT MCU開発に、これら複数RTOSを効率的に習得し、かつ、顧客が選ぶ1個のRTOSアプリケーションを早期に開発できるスキルを獲得しなければならない現状や将来を示しているとも言えます。

こういう状況での常套手段は、共通部分と個別部分の分離、共通部分からの段階的習得です。

どのRTOSでもSemaphoreやQueueは、ほぼ共通の基本機能です。先ずは、この2機能をしっかり把握し、より高度なミューテックスやイベントグループなどRTOS毎に特徴があり機能も異なる対象へ発展するのが効率的でしょう。

※RTOSは、複数タスク(AzureはThread)を、優先順位に応じてリアルタイムに実行/待機/状態保存復帰の切替えを行います。タスク間同期手段がSemaphore、データ送受手段がQueueで、この2つはどのRTOSでも共通の基本機能です。

まとめ

IoT MCUクラウド市場シェアから、クラウド接続IoT MCU RTOSもPCブラウザ同様、様々な仕様併存の可能性があります。

顧客が選ぶRTOSに柔軟対応し、そのRTOS上層の様々なRTOSアプリケーションを早期開発するには、先ず、各RTOS共通機能のSemaphoreとQueueを把握し、より高度でRTOS毎に異なる個別機能へ発展する習得アプローチが効率的です。

6Eリリース予定の弊社FreeRTOSアプリケーションテンプレート(税込2000円)は、主流のAmazon FreeRTOSを用い、NXP)LPCXpresso54114(Cortex-M4/150MHz、Flash/256KB、RAM/192KB)にて動作確認済みです。

添付するRTOSプロジェクトは、各RTOS共通機能SemaphoreとQueueを利用しており、上記習得アプローチを満たすツールとして、また、全ての物をつなげる主役IoT MCU RTOS基礎固めに最適です。

MCU:マイコン,LPCマイコン,STM32マイコン,Cortex-M4コアIoTマイコン,FreeRTOS,Amazon FreeRTOS,LPCXpresso SDK,LPCXpresso54114,freertos_generic,Azure,ユーザタスク

ベアメタルサンプルソフトを活用したFreeRTOSユーザタスクの作り方を示します。先に結論を言うと、ベアメタルサンプルソフト無限ループ内に、RTOS待ち処理を挿入するだけでFreeRTOSタスク開発ができます。

図1 ベアメタル処理とFreeRTOSタスク処理並列多重
図1 ベアメタル処理とFreeRTOSタスク処理並列多重

RTOS環境のユーザタスク開発

IoT MCUをAWSやAzureなどのクラウドへ接続する時には、FreeRTOSやAzure RTOSなどのRTOSが必須です。クラウド接続用のRTOSタスク集が入ったライブラリを利用するからです。もちろん、このライブラリ内のタスク開発は必要ありません。

問題は、このIoT MCU RTOS環境で、ユーザタスクをどのように開発するかです。

RTOSの目的は、タスク独立性とリアルタイムなタスク並列多重、MCUハードウェア隠蔽です。ベアメタル開発経験者にとっては、ソフトウェア動作環境が著しく異なることが解ります。

RTOS開発障壁を下げるアプローチ

そこで、ベアメタル開発経験者は、先ずこのRTOS環境の理解に努めます。

セマフォやミューテックス、QueueなどRTOS特有の手段を理解します。弊社も各種FreeRTOS機能を説明しましたし、ウェビナー等でも同様です。但し、このアプローチAは、「RTOSの手段」理解が最初に来ますので、障壁が高いと感じる方も多いでしょう。筆者はそうでした。

そこで、お勧めするのは、RTOS手段をざっと読んだら、今度は逆に「RTOSの目的」からRTOS環境で、複数ユーザタスクを並列多重するアプローチBです。

複数ユーザタクスを、どうすればRTOSへ組込むかを検討するこの逆アプローチBは、Aよりもベアメタル開発経験者向きで、しかもRTOS手段は後回しですので障壁が低く感じられます。

ベアメタル処理のFreeRTOSタスク化と並列多重

2個のベアメタル処理をタスク化し、RTOSで並列多重処理する例で考えます。

・処理#1:緑LEDを、1秒毎にトグル点灯
・処理#2:赤LEDを、SW押下げでトグル点灯

ベアメタル開発経験者なら、どちらの処理も簡単に開発できます。処理概要は、最初図1の左側になります。

違いは判断内容で、処理#1が1秒経過、処理#2がSW割込みです。もちろん、両処理を並列に多重するのは、ベアメタル開発では工夫が必要です。処理#1と#2は、別々のプロジェクト、例えば2個のサンプルプロジェクトとして提供されるのが一般的です。

両処理をタスク化して組込むRTOSには、LPCXpresso54114のSDK付属generic_freertosプロジェクトを用います。“generic”が示すように、ハードウェアに依存しない汎用的なFreeRTOSプロジェクトです(generic_freertosの詳細は、コチラの関連投稿を参照してください)。

RTOSへ組込んだ時のタスク処理概要が、図1の右側です。ベアメタルとの違いは、タスク#1は、遅延処理vTaskDelayを無限ループに加えること、タスク#2は、割込みISRからの同期セマフォ受信を無限ループに加えることだけです。

両処理へ追加したのは、どちらも「RTOS処理待ち」です。この処理待ちを、RTOSが解除/待ちに切替えることで、複数タスクが並列に動作します。

RTOSは、複数タスクを処理待ち状態にし、処理待ちタスクの中から優先順位に応じて1個のタスクを実行状態に割当てます。RTOS(Kernel)自身が、順位判断や実行タスクの切替え、タスク実行状態の保存/リカバリのためスタックプッシュ/ポップ処理を行い、それらの処理間隔がTICK_RATEです。

リアルタイムでタスクを切替えるには、高速なKernel動作(AWSによると25MHz以上)と短期間のTICK_RATE(通常1ms)が必要で、タスク数に応じてスタック使用量(AWS RAM 64KB以上)は急増します。
※数値で示したAWS FreeRTOS必須条件の詳細は、コチラのハードウェア最小仕様要件を参照してください。

要するに、RTOSへユーザタスクを追加するには、ベアメタルでユーザ処理を開発し、その無限ループ内にRTOS処理待ちを加えさえすれば、RTOSユーザタスクになります。

ベアメタル開発経験者がデバッグし慣れた処理がそのままRTOSユーザタスク開発にも使え、RTOS処理待ちは、generic_freertosに実装済みのセマフォとQueueのRTOS手段だけでも、リアルタイムタスク並列多重のRTOSアプリケーション開発ができます。

まとめ

本稿は、IoT MCU RTOS環境でユーザタスクを開発し、FreeRTOSへ実装する方法として、ユーザ処理をベアメタルで開発し、無限ループ内へRTOS処理待ちを加えタスク化する方法を説明しました。

RTOS処理待ちは、セマフォとQueueのRTOS手段を理解していれば、プロトタイプ段階のFreeRTOSアプリケーションとしては十分です。ユーザ処理を自主開発する代わりに、ベンダ提供のベアメタルサンプルソフトを活用すれば、豊富なサンプル処理のFreeRTOSタスク化も簡単です。

タスク化処理を組込むRTOSには、NXP)LPCXpresso54114 SDK付属のgeneric_freertosプロジェクトを使います。このプロジェクトは、ハードウェア非依存の汎用FreeRTOSプロジェクトで、セマフォとQueueを実装済みです。そこで、これら2つのRTOS手段を手始めに理解すれば、RTOS開発障壁も低くなります。

あとがき

本稿で示したユーザタスク追加方法により開発したNXP)LPCXpresso54114(Cortex-M4/150MHz、Flash/256KB、RAM/192KB)で動作確認済みのFreeRTOSアプリケーションテンプレートは、6Eにリリース予定です(ADC入力とLCD出力、VCOM入出力処理も追加済み)。

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

このテンプレートには、FreeRTOSプロジェクトに加え、同じアプリケーション動作のベアメタルプロジェクトも添付します。ベアメタル処理に処理多重の工夫を加えた弊社Cortex-M0+/M3コア向けBaseboardテンプレートを、Cortex-M4コアへも適用したベアメタルプロジェクトです。

FreeRTOS開発とベアメタル開発の、Flash/RAM使用量差、開発難易度、消費電力差などCortex-M4コアMCU開発で実務上知りたい事柄を直接比較・評価することが可能です。また、どちらのプロジェクトも、基本的アプリケーションのテンプレート(=スタートプロジェクト)としても活用でき、プロトタイプ開発に最適です(FreeRTOS/ベアメタルの2プロジェクト+説明資料、税込2000円)。

また、STマイクロエレクトロニクス)STM32G4(Cortex-M4/170MHz、Flash/512KB、RAM/96KB)対応版も開発を予定しています。

FreeRTOSアプリケーションテンプレートを使ったプロトタイプ開発の次の段階としては、セマフォやQueue以外のミューテックスやイベントグループなどのより高度なRTOS手段の利用や、高速でRAM使用量も少ないタスク通知手段などのチューニング開発へとステップアップすることです。

RL78マイコン,MCU:マイコン,LPCマイコン,Kinetisマイコン,STM32マイコン,PSoC/PRoCマイコン,MSP432マイコン,Cortex-M0+コア,Cortex-M0コア,Cortex-M3コア,Cortex-M23コア,Cortex-M4コアテンプレート,アプリケーション,IoTマイコン,FreeRTOS,LPCXpresso54114

組込み開発全般に参考となる英語ブログを紹介します。特に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に限らず組込み関連全般の卓越した問題再構築能力は、掲載図を見るだけでも良く解りますよ😄。

RL78マイコン,MCU:マイコンRL78/G13,RL78/G14,IoTマイコン,RL78/G10,RL78/G1x,IoTエッジMCU,セキュア・ファームウェア更新,RL78/G23,Snoozeモード・シーケンサ,RL78/G2x

ルネサスエレクトロニクスが、2021年4月13日、新世代の汎用MCU RL78/G23を発表しました。RL78/G23は、弊社RL78/G1xテンプレートデバイスRL78/G13やRL78/G14の製造プロセスを改良し、IoT向き機能を強化した汎用MCUです。

新しいRL78/G23と従来RL78/G13を比較し、ルネサスIoT Edge MCU機能強化点と評価ボードを調べました。

新汎用RL78/G2xシリーズ位置づけ

汎用RL78MCU変遷(出展:RL78 ファミリパンフレットに加筆)
汎用RL78MCU変遷(出展:RL78 ファミリパンフレットに加筆)

ルネサスRL78ファミリパンフレット2021.04のp1記載RL78ロードマップから汎用MCUファミリを抜粋し、加筆したのが上図です。RL78/G23は、RL78/G13とG14性能の大部分をカバーした新しい汎用MCUであることが判ります(縦軸:性能、横軸:年代、橙色囲み:テンプレート対象RL78/G1xシリーズ)。

新汎用RL78/G23は、従来汎用RL78/G1xシリーズへIoTエッジ向き機能(製造プロセス、Snoozeモード・シーケンサ、高速オンチップオシレータ高速起動、中速オンチップオシレータ搭載など)を追加し、RL78/G1xシリーズと互換性があります。

RL78/G23のIoT Edge MCU機能強化点

RL78/G23は、RL78/G1x比、主に下記機能が強化されています。

  • Snoozeモード・シーケンサ搭載
  • RL78/G13比、30%低消費電力化
  • IoTエッジMCUセキュリティ強化

Snoozeモード・シーケンサ

Snoozeモード・シーケンサ(SMS)は、Snooze中のMCUを起動することなく、演算、分岐、周辺回路制御の順次処理が可能なMCU内蔵ハードウェアです。SMSはMCUよりも動作電流が少ないため、低電力動作になります。

Snoozeモード・シーケンサによる低電力動作効果(出展:ルネサスRL78ファミリ)
Snoozeモード・シーケンサによる低電力動作効果(出展:ルネサスRL78ファミリ)

従来のRL78/G13も、低電力動作用Snoozeモード(上図)を持っていました。Snoozeモード・シーケンサ(下図)は、周辺回路制御(Analog/Port settings)や、データ・トランスファー・コントローラ(DTC)の直接起動(USRT transmission)など、従来MCUの代わりに、予め設定した最大32個のシーケンシャル処理実行が可能です。

このSMSを活用すると、点線部分のMCU動作が不要となり、従来のRL78/G13よりも更に低電力処理が可能です。

30%低消費電力化

RL78/G13比、30%少ない低消費電力動作のRL78/G23(出展:ルネサスサイト)
RL78/G13比、30%少ない低消費電力動作のRL78/G23(出展:ルネサスサイト)

前述のSMSや新製造プロセスなどにより、RL78/G13(64KB)比、30%の低消費電力化を達成しています。ROM容量が128KBと2倍での比較になる理由は、次章セキュリティ強化で説明します。

なお、RL78/G23最高動作周波数は32MHzで、従来RL78/G13と同じです。

IoTセキュリティ強化

RL78/G23新追加のSecure update and secure boot(出展:ルネサスRL78ファミリ)

IoTエッジMCUセキュリティ強化のため、RL78/G23には、RL78/G1xには無かったセキュア・ブートとセキュア・アップデート機能が実装されています。セキュア・アップデートには、実行中ROM領域に加え、書換え用ROM保存領域も必要になるため、従来比2倍のROM容量が必要です。

2倍詳細は、関連投稿:STM32G0/G4のRoot of Trust (1)~(3)、または、セキュア・ファームウェア更新:タグなどを参照してください。

RL78/G23 Fast Prototyping Board

RL78/G23 Fast Prototyping Board(出展:ユーザーズマニュアル)
RL78/G23 Fast Prototyping Board(出展:ユーザーズマニュアル)

従来のルネサス評価ボード(QB-R5F100LE-TBなど)は、開発時、別途E1/E2エミュレータが必須でした。新しいRL78/G23(32MHz、64ピン、ROM/128KB、RAM/16KB) Fast Prototyping Board(2590円)は、USB-シリアル変換器が搭載され、USB経由でデバッグとプログラミングが可能です。

RL78/G23 Fast Prototyping Board(出展:ユーザーズマニュアル)
RL78/G23 Fast Prototyping Board(出展:ユーザーズマニュアル)

従って、micro USBケーブルでPCと接続しさえすれば、エミュレータ無しでもプロトタイプ開発に着手できます。また、Arduinoコネクタも実装済みで、各種Arduinoシールドをスタック装着できる評価ボード形状になりました。

まとめ

RL78/G23は、RL78/G13互換性を重視し、IoTエッジ向き低電力性とセキュリティを強化した新世代の16ビット汎用MCUです。

エミュレータ不要でArduinoコネクタ実装済みRL78/G23評価ボード(32MHz、ROM/128KB、RAM/16KB)は、制御系載せ替えモジュール化が可能となり、競合他社MCUとの比較も容易です。

載せ替え制御系モジュールの詳細は、コチラの関連投稿3章:半導体不足時のMCU開発対策案を参照してください。

あとがき

久しぶりのRL78マイコンカテゴリ投稿でした。32ビットARM Cortex-M0+コア対抗のため、低消費電力化と評価ボード改善を図ったのが、RL78/G2xシリーズ第一弾:RL78/G23です。

その特徴を活かすには、新追加Snoozeモード・シーケンサ活用、つまり、ルネサスSxコア動作の休止に磨きをかけたソフトウェア開発(従来ソフトの一部SMSハード化)が必須です。

これは、Cortex-Mxコア低消費電力アプローチ:より高周波数の動作+コア休止時間幅拡大とは、方向性が異なると感じました。ルネサスは、RL78/G1x顧客サーベイの結果、製造プロセス進化アドバンテージを、高周波数動作よりも、SMS追加や2倍メモリ増量へ配分したのでしょう。

このSMSを、ルネサス供給中のCortex-MxコアMCUへも搭載すると、差別化できるかもしれません。