μT-Kernelプログラミングコンテスト

μT-Kernalプログラミングコンテスト(出典:TRONフォーラム)
μT-Kernalプログラミングコンテスト(出典:TRONフォーラム)

2023年12月11日から、インフィニティ、STマイクロ、NXP、ルネサス、4社協賛のμT-Kernelプログラミングコンテストが開催されます。

IoT MCU世界標準RTOSのμT-Kernelを用いたアプリ、ミドルウェア、開発環境/ツールの3部門で競い、対象は国内外技術者と学生、賞金総額500万円、1次審査合格者には評価ボードが無償提供されます。

Summary:エントリ:12月11日~2024年2月29日、提出:2024年3月11日~6月30日

コンテスト詳細は、12月7日、東京ミッドタウンホールの2023 TRON Symposiumで発表されます。

賞金総額500万円のコンテスト応募期間は、2023年12月11日から2024年2月29日。1次審査合格者は、内容に応じて評価ボードが無償提供され、応募プログラムの提出期限は、2024年3月11日~6月30日です。

世界標準MCU RTOS:μT-Kernel 3.0

クラウドへ接続するIoT MCUは、RTOSが必須です。FreeRTOSやAzure RTOSが有名です。

μT-KernelもIoT MCU RTOSの1つです。μT-KernelのIEEE標準規格:IEEE2050-2018完全準拠版がμT-Kernel 3.0です。つまり、μT-Kernel 3.0は、世界標準IoT MCU RTOSです。

さらに、μT-Kernel 3.0は、GitHub公開のオープンソースソフトウェアで、協賛MCUベンダ各社のBSP(ボードサポートパッケージ)もあり、RTOS開発が容易になりました。

※評価ボード毎に異なるBSPにより、ユーザ開発アプリのハードウェア依存性を無くすことがBSPの目的。STマイクロ例が下図(説明投稿はコチラ)。

BSPとMCU Firmwareによりハードウェア依存性が無いHAL APIsが提供
BSPとMCU Firmwareによりハードウェア依存性が無いHAL APIsが提供

協賛4社:STマイクロ、NXP、ルネサス、インフィニティ

μT-Kernelプログラミングコンテスト協賛4社の評価ボードは、上記BSPが提供中です。2023 TRON Symposium会場で、各社評価ボードでμT-Kernel 3.0動作のIoT MCU実機デモが開催されるでしょう。

大手MCUベンダ4社のμT-Kernel 3.0への力の入れ方やRTOS開発のし易さが、実際に評価ボードで判ると思います。

μT-Kernel 3.0学習教材

micro:bit は、入力、出力、センサー、無線通信機能が搭載済み学習ボード(出典:micro bitサイト)
micro:bit は、入力、出力、センサー、無線通信機能が搭載済み学習ボード(出典:micro bitサイト)

英BBC開発の教育向けMCU、micro:bit上で動くリアルタイムOSマイクロ学習キットが販売中です。キットと言っても、入力センサ/スイッチ/LED搭載済みのmicro:bitとPCをUSB接続するだけでRTOS動作します。

RTOSにμT-Kernel 3.0を使用し、タスク動作をビジュアル表示できるタスクトレーサやμT-Kernel日本語解説資料付きです。μT-Kernel 3.0のスケジューリングやセマフォが、ご自分のペースで学習できます。

Afterword:今年最後の投稿、次回1月5日予定

寒暖差のせいか、このごろ体調不調です。流行中のインフルエンザかもしれません。かなり早いのですが、本稿を今年最後の投稿にしたいと思います。次回は、2024年1月5日(金)投稿予定です。

今年も本ブログをご覧いただき、ありがとうございました。皆様、よいお年をお迎えください🤞。


ベアメタルかRTOS開発か?

弊社MCUテンプレートご購入者様から、ベアメタルかRTOS、どちらの開発が良いかについてご質問がありました。
ご質問者同意を得ましたので、筆者回答を一部修正、抜粋して示します。

Summary:クラウド接続=RTOS開発、スタンドアロン=ベアメタル開発

RTOS vs. BareMetal
RTOS vs. BareMetal

AWSやAzure RTOSなどのクラウドへ接続するMCUは、RTOS(FreeRTOS/Azure RTOS)開発が必須です。クラウド接続やセキュリティ確保に、専用RTOSライブラリ利用が必要だからです。また、大規模、複数開発者の場合も、RTOS開発が向いています。

スタンドアロン動作のMCUは、ベアメタル開発をお勧めします。MCU動作を全て開発者で管理・制御できるからです。

ベンダ提供サンプルコードとMCU評価ボードを活用すると、ベアメタル/RTOSどちらの開発でも、高品質・短期間で製品のプロトタイプ開発ができます。弊社MCUテンプレートは、サンプルコード活用プロトタイプ開発に適しています。

クラウド接続MCU:割込みベースRTOSタスク開発

AWS (Amazon Web Services)やAzure (Microsoft Azure Cloud Services)へ接続するMCUは、クラウド接続用に、FreeRTOSやAzure RTOS接続ライブラリの利用が前提条件です。また、高度なセキュリティ対策が求められますので、クラウド側提供セキュリティライブラリを使うことも求められます。

従って、クラウド接続MCUは、必然的にRTOS開発となります。

通信やセキュリティ以外の処理は、タクス(スレッドとも言うが、以下タスクと略)の開発が、ユーザ開発内容です。

タスクは、移植性が高い単位に機能分割し、割込みベースで作成します。複数タスクの割込み処理や優先順位を管理・処理するのが、RTOSの役目です。

RTOSが優先順位に基づいて個々のタスクをMCUに割当てることで、複数タスクの並列処理が進みます。シングルコアMCUの場合、一度に実行するタスクは1個です。従って、タスクは時分割処理です。分割タイミングが短く、しかも優先順位に基づいたタスク処理ですので、複数タスクが並列処理しているように見えます。

タスクは、別タスクのことを考慮せず独立性、移植性高く開発可能です。その代償として、RTOSが複数タスク間優先制御を行うセマフォ/ミューテックス/イベントフラグなど、また、タスク間通信を行うメッセージバッファ/メールボックスなどのRTOS独自機能を、開発タスクに組込む必要があります。

関連投稿:RTOS習得

移植性や独立性が高い開発済タスクは、ベアメタル比、ソフトウェア資産として他プロジェクトへもそのまま使えるメリットがあります。また、ソフトウェア規模が大きく、複数開発者で共同開発する時も、機能完全分離RTOS開発の方が優れると言われます。

スタンドアロンMCU:ポーリングベースベアメタル開発

RTOSが行う周辺回路の割込み処理や優先制御を、全てユーザが行うのがベアメタル開発です。

但し、デバッグや処理開発のし易さを考慮すると、ポーリングベース開発をお勧めします。

つまり、周辺回路の割込みフラグを、一旦、割込み処理待ちフラグへ置換え、この割込み処理待ちフラグをポーリングすることで処理を実行する方法です。割込み処理待ちフラグは、RAMへ展開されますので、開発処理もRAMフラグで制御でき、割込みを直接扱うよりも単体デバッグが容易になります。

ベアメタル開発は、単体デバッグ済みの複数処理を、MCU全体で上手く実行する制御部分も必要です。弊社ベアメタルMCUテンプレート英語版MCUテンプレートは、この制御部分を提供します。

サンプルコード活用プロトタイプ開発

サンプルコード活用プロトタイプ開発
サンプルコード活用プロトタイプ開発

RTOSはタスク、ベアメタルは周辺回路制御のソフトウェア開発が必要です。

但し、ベンダは、周辺回路制御の参考となるソフトウェアを、サンプルコードとしてMCU評価ボードと共に提供します。サンプルコードは、ベンダ専門家が開発した評価ボード動作確認済み高品質コードですので、これをユーザが利用しない手はありません。

現在サンプルコードは、ベアメタル用のものが殆どです。しかし、RTOSタスク開発へも応用できます。サンプルを上手く利用することで、0から開発するよりも、短時間でソフトウェア開発ができます。

また、評価ボードMCU周りの部品配置やアートワーク配線は、処理性能過不足時のMCU交換や耐ノイズ性が高いハードウェア開発の参考書になります。

MCU開発を高品質・短期間で行うには、サンプルコードとMCU評価ボードを活用し、製品プロトタイプ開発がお勧めです。プロトタイプから製品へフィードバックをかければ、より良い製品化が可能です。

Afterword:ベアメタル開発からRTOSへステップアップ

IoT MCU開発者スキルの階層構造
IoT MCU開発者スキルの階層構造

Windowsアプリ開発時は、Windows APIの利用は当たり前です。多くの解説書もあります。

IoT MCU開発時も、FreeRTOSやAzure RTOSが当然になると思います。ただMCU開発には解説書が少なく、その理解には基礎知識が必要です。基礎がグラつくと、その上の積み重ねは非常に困難です。

MCU開発の基礎は、ベアメタル開発です。IoT普及でRTOS MCU開発も増えます。IoTに向けてRTOSを勉強しようと考える方も多いと思います。その場合は、ベアメタル開発の何をRTOSが代行し、何が得られ、何を失うか、RTOSオーバーヘッドはどの程度かを考えながら学習すると、より効率的にRTOS習得ができます。

例えば、RTOS開発には、セマフォやミューテックスなどのベアメタル開発に無い多くのRTOS機能を新に学ぶ必要があります。しかし、よく使う機能は少数です。ご自分のベアメタル手法を代行するRTOS機能から学び始め、それでも足りない機能はRTOS側に用意されていますので、順次増やしながらタスクを開発して行くと良いと思います。

ソフトウェア開発は、AI Copilot出現で激変への過渡期です。数年後には、ライブラリ組み換え作業などへ開発が変わり、不足がちなMCU開発解説もAIが代行してくれるかもしれません。

そんな全能AI過渡期でも、ご自分自身で獲得した基礎の重要性は、変わらないと筆者は考えます。


FSPベアメタルサンプルのRTOSスレッド化

前投稿FSPベアメタルサンプルコード:sci_uart_fpb_ra6e1_epを、RTOSスレッド化する方法を示します。

多くのルネサスRA公式サンプルコードを活用した効率的なRTOSスレッド開発が本方法で可能です。FreeRTOS、Azure RTOS両方に使えます。

サンプルコードベースRTOSスレッド開発

RTOS開発は、複数スレッドを組合せ全体を動作させます。ベアメタルコードに比べ、個々のスレッドは、独立性や移植性が高い特徴があります。スレッド優先度やセマフォなどのRTOSオブジェクトを適切に設定すると、複数スレッド全体処理としてユーザ所望のシステム動作をします。

スレッドは、勝手に回る歯車、優先度やRTOSオブジェクトは、各歯車をシステム全体で上手く動作させる手段と考えると解りやすいと思います。

スレッドとRTOSの役目
スレッドとRTOSの役目

スレッド設計法は、機能別や処理手順別など様々あり、唯一の方法は無さそうです。しかし、先ずは、歯車となるスレッドを開発し、次に、開発スレッド優先度やRTOSオブジェクトを調整しながら、システム全体動作を仕上げるのがRTOS開発の方法です。

本稿は、スレッド単体開発の1方法として、ルネサスRAファミリ公式FSPベアメタルサンプルコードを活用したサンプルコードベースのRTOSスレッド開発法を示します。複数スレッドを組合せたRTOSオブジェクトの適切な調整や設定に関する内容は、含みません。

公式ベアメタルサンプルコードは、各ベンダエキスパートが開発し、評価ボードで動作確認済みの高信頼ソフトウェアです。また、MCU周辺機能毎に多くのサンプルコードが提供中です。

これらベアメタルコードを活用する本方法は、FreeRTOS/Azure RTOSどちらのRTOSスレッド開発へも使えます。

RTOSスレッド化方法

詳細は、後で説明しますが、先ず、ベアメタルサンプルをスレッド化する手順を簡単に示します。方法全体像が判っていると把握しやすいからです。

  1. スレッド無しで空の新規RTOSプロジェクト作成
  2. g_ioport以外のベアメタルサンプルFSPスタックを、RTOS FSPスタックへImport
  3. hal_entry.c以外のベアメタルサンプルsrcファイルを、RTOSプロジェクトsrcフォルダへコピー
  4. 新しいスレッド:MyThreadをRTOSプロジェクトへ追加後、Gegerare Project Contentクリック
  5. MyThread_entry.cへ、初期設定と無限ループ処理を追記

1で新規作成した空のRTOSプロジェクトへ、2と3で対象ベアメタルサンプルから内容を追加、4でベアメタルmain()相当の新しいMyThreadを追加後、FSPを使ってRTOSプロジェクトを自動生成します。

生成後、5でRTOSプロジェクトのMyThread_entry.c初期設定と無限ループを追記します。追記内容は、ベアメタルサンプルの初期設定と無限ループ処理です。

つまり、1~5手順全てFSPベアメタルサンプルからの単純コピーでRTOSスレッド化が可能です。

次章から、前投稿で用いたベアメタルサンプルコード:sci_uart_fpb_ra6e1_epを、FreeRTOSスレッド化する具体例を使って、各詳細手順を示します。

1. 空の新規FSP freertos_uartプロジェクト作成

スレッド無しで空の新規FreeRTOSプロジェクト作成
スレッド無しで空の新規FreeRTOSプロジェクト作成

スレッド無し空FreeRTOSプロジェクトを新規作成します。新規RTOSプロジェクト名は、freertos_uartとでもしてください。

2. sci_uart_fpb_ra6e1_epのFSPスタックImport

sci_uart_fpb_ra6e1_epのFSPスタックImport
sci_uart_fpb_ra6e1_epのFSPスタックImport

freertos_uartプロジェクトのFSPスタックへ、sci_uart_fpb_ra6e1_epのg_ioport以外のFSPスタックを全てImportします。Importした各スタックプロパティは、オリジナルプロパティと同じに手動で設定してください。

3. sci_uart_fpb_ra6e1_epのsrcファイルコピー

sci_uart_fpb_ra6e1_epのsrcフォルダファイルコピー
sci_uart_fpb_ra6e1_epのsrcフォルダファイルコピー

sci_uart_fpb_ra6e1_epのhal_entry.c以外のsrcファイルを全て、freertos_uartのsrcへコピーします。

4. freertos_uartプロジェクトへ新しいUart Thread追加後、Generate Project

新しいUart_Thread追加
新しいUart_Thread追加

新しいスレッドのSymbolは、Uart_threadとしてください。先頭を大文字にする目的は、FSPが自動生成したファイルやスレッドが使う全小文字表記とユーザ追加のそれらを、大小文字で区別するためです。

Tips:大文字利用は、好みの問題です。RTOS開発は、多数のスレッドやオブジェクトソースが、プロジェクト・エクスプローラのsrcフォルダに表示されます。自分が追加したソース(バグ有り?)と純FSP生成ソースを、一目で区別できるメリットがあります。

最後にGenerate Project Contentをクリックし、FSPによりRTOSプロジェクトを自動生成します。

5. Uart_Thread_entry.cへ初期設定と無限ループ処理追記

RTOSプロジェクトのsrcフォルダ内に、Uart_thread_entry.cが生成されます。

先頭の#include “Uart_thread.h”に、sci_uart_fpb_ra6e1_epのsrcファイルにある#include “common_utils.h”、 #include “uart_ep.h”、 #include “timer_pwm.h”を追記します。
これら4個の#include文は、freertos_uartの全srcファイルに手動で追記します。

Uart_thread_entry.cの初期設定
Uart_thread_entry.cの初期設定

RTOS初期設定は、Uart_thread_entry.c のTODO: add your own code here以下へ、sci_uart_fpb_ra6e1_epの初期設定:hal_entry.cのL41からL93までをコピーします。

sci_uart_fpb_ra6e1_epの無限ループ処理は、コピーした初期設定の後方にあるuart_ep_demo()です。

RTOS無限ループ内には、上図でコメントアウトしたコンテキストスイッチが必要です。そこで今回は、RTOSプロジェクトuart_ep.cのuart_ep_demo()内へ、直接コメントアウトしたFreeRTOSコンテキストスイッチ:vTaskDeley(1)を追記します。

uart_ep.cのuart_ep_demo()へ追記するコンテキストスイッチ
uart_ep.cのuart_ep_demo()へ追記するコンテキストスイッチ

Tips:#include “Uart_thread.h”が、FreeRTOS関連API:コンテキストスイッチ追記を可能にします。

sci_uart_fpb_ra6e1_epとfreertos_uartスレッド同一動作確認

RTOSプロジェクトをビルドし、評価ボードへダウンロード後、実行してください。前稿のベアメタルサンプルコードと全く同じ処理が、開発したfreertos_uartスレッドで確認できます。

FreeRTOS/Azure RTOSスレッド化差

本稿で示したFreeRTOSスレッド化とAzure RTOSスレッド化の差は、コンテキストスイッチのみです。FreeRTOSならvTaskDelay(1)、Azure RTOSならtx_thread_sleep(1)が、コンテキストスイッチです。

Tips:コンテキストスイッチは、FreeRTOS/Azure RTOS開発手法のRTOS処理フローなどを参照してください。

ベアメタルサンプルコードをAzure RTOSスレッド化する時は、手順1で、新規Azure RTOSプロジェクトを作成し、手順5のvTaskDelay(1)の代わりに、tx_thread_sleep(1)を使えばOKです。

Tips:FSP生成スレッドMyThread_entry.cの無限ループ内には、作成RTOSプロジェクトに応じて初めからvTaskDelay(1)、またはtx_thread_sleep(1)が実装済みです。

本方法が、FreeRTOS/Azure RTOSどちらのRTOSスレッド開発へも使えることが分かります。

補足

2023年1月16日、e2 stidioは2022-10のまま、RAファミリFSPがv4.2.0へ更新されました。本稿は、FSP v4.2.0/4.1.0両方で動作確認済みです。



Rapidus(ラピダス)

Rapidusロゴ2022年11月11日、経産省キモ入りの日本国内8社(キオクシア、ソニー、ソフトバンク、デンソー、トヨタ自動車、NEC、NTT、三菱UFJ銀行)から成る次世代半導体(Beyond 2nm)製造会社:Rapidus設立(ITmedia)の記事は、世界と国内の半導体製造「10年遅れ、先端ロジック分野後進国」を取り戻すには、「異次元の取組みが必要」と報じています。

RapidusとLSTC体制で2030年までに市場規模100兆円目指す

次世代半導体プロジェクトはRapidusとLSTCの2本立て(出展:経産省サイト)
次世代半導体プロジェクトはRapidusとLSTCの2本立て(出展:経産省サイト)

年内に半導体技術の研究開発拠点:LSTC(Leading-edge Semiconductor Technology Center)も立上げ、研究開発はLSTC、製造はRapidusの2社体制で2030年までに市場規模100兆円を目指すそうです。

過去との差分

Rapidusが過去の半導体ファウンドリー設立と異なる点は、半導体ユーザ企業(ソフトバンク、デンソー、トヨタ自動車、NTT)が各10億円出資して参加している点と、Rapidus経営陣メンバーの本気度が高いことだそうです(2022年11月11日、日経xTECH)。

上記記事は、新会社への期待と不安も示しています。弊社も、RapidusとLSTCに注目していきたいと思います。

周回遅れの日本国内ワクチン産業との類似性

変異型COVID19と対応ワクチン
変異型COVID19と対応ワクチン

世界と国内の「10年遅れ」と類似する事象に、COVID-19国内ワクチン開発が「周回以上の遅れ」と指摘している記事があります。この記事も、対策には「抜本改革が必要」としています。

先端半導体研究開発とCOVID-19国内ワクチン開発、全く別分野ですが、両者の日本状況は良く似ています。

ワクチン不足から類推する先端半導体不足

ワクチン接種は、現在無料です。これは、政府が海外メーカからワクチンを買上げ、無料で国民に接種しているからです。

仮に、変異型ウイルス対応ワクチンが不足し、入手困難ならどうなるでしょう? 旧型ワクチンでは変異型に対して効果が期待できない場合などは、国内パニックになるでしょう。

これと同じことが、先端半導体不足でも生じます。多くの製品や車は、半導体が性能、製品差の決め手です。先端半導体を使えないことは、日本製の新製品や新車の魅力が無いのと同等になるでしょう。

この事態を避けるためRapidusとLSTCの異次元取組みに期待し、日本の10年遅れを挽回してほしいです。

海外最新半導体製造ニュース

  • TSMC米国アリゾナ工場、3nm製造の可能性(2022年11月15日、EE Times)
  • 独)Infineon、アナログ/ミックスドシグナル/パワー半導体を新工場で製造計画(2022年11月15日、EE Times)

海外半導体製造の最新ニュースを2件示します。この分野は、Rapidusの強力ライバルが着実に進出中です。

先端IoT MCUはRTOS開発

IoT MCU開発者スキルの階層構造
IoT MCU開発者スキルの階層構造

個人レベル開発スキルもまた、Rapidusや国内ワクチン産業と同様、異次元の取組みや抜本改革無しの方法では、海外との開発競争にすらなりません。

景気後退が懸念される今、個人の開発スキルを磨き、先端技術人材になりましょう!

IoT MCU分野では、RTOS開発が先端技術だと筆者は思います。JACOB’S BLOGの5 RTOS Design Best Practicesが、とても参考になります。

関連投稿:RTOSテンプレート骨格クリエイタ的エンジニア

本稿主旨は、「危機感は大切だが、あせりは禁物。お互い切磋琢磨しましょう」です。



RTOSテンプレートの骨格

IoT MCU RTOSは、FreeRTOSとAzure RTOSの2種類。接続クラウドAmazon AWSやMicrosoft Azureに応じて選択する必要があります。各RTOSそれぞれにRTOSアプリケーションを開発するのは非効率です。

そこで、アプリケーション開発の基になるRTOSテンプレートの骨格を検討しました。APIはFreeRTOSとAzure RTOSで異なるものの、同一の骨格から開発するとメリットがあるからです。

結論は、単体タスク/スレッド試験も容易なメニュー表示形式RTOSテンプレート骨格とします。

RTOSアプリケーション例

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

RTOSアプリケーション例が上図です。複数のタスク/スレッドと各タスク/スレッドを制御するアプリケーション本体から構成されます。

アプリケーション本体とタスク間は、同期(S:セマフォ)/排他(M:ミューテッスク)/メッセージキュー(Q)などのRTOS処理待ちに応じたRTOS APIが用いられます。

FreeRTOSとAzure RTOSで処理待ちRTOS API記述が異なるものの、どちらも機能的には同じです。

また、センサやタッチスクリーン、Wi-FiなどMCU内蔵/外部回路間の制御API、いわゆるドライバ部分は、各MCUベンダ提供のAPI生成ツールで開発します。このAPI生成ツールは、ベアメタル開発で使うものと同じです。RTOS開発だからと言って別のドライバAPI生成ツールがある訳ではありません。

ベアメタル開発とRTOSとの差分は、灰色部分です。1無限ループ内で全ての処理を行うのがベアメタル、RTOSアプリケーション本体と複数のRTOS処理待ちタスク/スレッドで並列多重を行うのがRTOS、ここだけです。

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

メニュー形式アプリケーション特徴

メニュー 1-5 を選択してください。
(1) Process Input処理
(2) Network Manager処理
(3) 出力処理
(4) メモリ処理
(5) 印刷
(6) 処理自動実行

最初の図のような複雑な処理をベアメタル開発する時は、例えば上のようなメニュー表示形式アプリケーションがしばしば用いられます。メニューの表示は、USART接続のPC、Tera Term利用が一般的です。

このメニュー表示形式アプリの特徴は、(1)から(5)の各処理を単体デバッグできることです。

また、単体デバッグ後、(1)から(5)の処理を自動で結合する処理(6)を開発すれば、開発が完成する点も優れています。

(6)完成後は、メニュー表示をスキップし、PCを使わずにMCU単体で(6)を実行すれば、ベアメタル組込み完了です。

メニュー形式RTOSテンプレート骨格と開発手順

RTOSアプリケーション開発でもメニュー表示形式を採用します。

メリットは、単体タスク/スレッド開発、デバッグが容易な点です。RTOS開発は、タスク/スレッドの独立性がベアメタルよりも高いため、メニュー形式で開発したタスク/スレッド流用性も高く、開発ソフトウェア資産化も可能です。

弊社RTOSテンプレートは、FreeRTOSでもAzure RTOSでもメニュー形式のテンプレート骨格とします。テンプレートが用意するデフォルトメニュー数は7個、タスク/スレッド優先度もデフォルト7レベル(1から7)設定とします。優先度初期値は、どれも同一優先度(真ん中の4)とします。

※FreeRTOSは値が大きいと高優先、Azure RTOSは値が小さいと高優先で真逆に注意

RTOSテンプレートを使って、単体のタスク/スレッドを開発し、単体タスク/スレッド完成後、並列多重の結合動作へステップアップします。多重時、各タスク/スレッドの高/低優先度変更や、タスク合併などを検討します。

メニュー形式RTOSテンプレートのデバッグ方法
メニュー形式RTOSテンプレートのデバッグ方法

もちろん、メニュー数や優先度数の増加も容易です。しかし、弊社がお勧めするIoT MCUは、低価格評価ボード搭載の汎用IoT MCUです。RTOSオーバーヘッドが少ない7程度が適当だと思います。

RTOSテンプレートを使って、第1段階ではタスク/スレッド分割と単体タスク/スレッド開発に集中し、第2段階でタスク/スレッド並列多重に関連する優先度などのRTOSパラメタ調整に集中します。段階を踏んだ集中開発ができるため、複雑なRTOSアプリケーションの早期開発に役立ちます。

弊社RTOSテンプレートは、FreeRTOSまたはAzure RTOS個別対応済みのバージョンを販売予定です。但し、RTOSテンプレートの骨格がFreeRTOS/Azure RTOSで同じことをご購入者がご理解済みなら、FreeRTOS APIとAzure RTOS API変換も、比較的容易だと思います。

ベアメタルテンプレートとの違い

弊社ベアメタルテンプレートは、主に開発初心者から中級者が対象です。メニュー表示形式など、複雑な構成のテンプレートを提供するよりも、シンプルで解り易いソースコードの方が適しています。

一方、RTOSテンプレートは、ベアメタル開発経験者、つまり中級以上の開発者が対象です。

テンプレート付属説明資料も異なります。ベアメタルテンプレート付属説明資料は、各ベンダのIDEやAPI開発ツールの基本的使い方、開発つまずき回避のTipsなどを記述しています。具体例は、RAベアメタルテンプレート説明資料をご覧ください。

RTOSテンプレート付属説明資料は、既知のベアメタル関連説明は省き、ベアメタルとRTOSの差分や、実践的なRTOS Tipsの説明を加えます。具体例は、NXP版FreeRTOSテンプレート説明資料をご覧ください。

まとめ

FreeRTOSとAzure RTOS同一のメニュー形式RTOSテンプレート骨格構想を示しました。

弊社RTOSテンプレートを使えば、単体タスク/スレッド開発に集中でき、効率的、段階的なRTOSアプリケーション開発が可能です。開発単体タスク/スレッドは、独立性が高いので、ソフトウェア資産化も容易です。

また、接続クラウド変更に伴うFreeRTOSとAzure RTOSのAPI変更も、同じテンプレート骨格利用のため容易です。

本構想に基づいたAzure RTOSテンプレート、FreeRTOSテンプレートは、本年度末発売予定です。現在販売中のNXP版FreeRTOSテンプレートも、本構想用に改版を予定しております。

弊社RTOSテンプレート骨格について、皆様のご意見などを現在募集中です。お気軽にinfo@happytech.jpへお寄せください。

関連投稿リンク

FreeRTOS/Azure RTOSソフトウェア開発手法

ルネサス公式センササンプルコードを使って、ベアメタル処理を起点とするRTOS(FreeRTOS/Azure RTOS)ソフトウェア開発手法を説明します。

筆者にしては、長い投稿です。要旨は、「ベアメタル処理+RTOS処理待ち=RTOS処理」です。

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

センササンプルコード

  1. FS2012 Sample application – Sample Code
  2. HS300x Sample application – Sample Code
  3. ZMOD4xxx Sample application – Sample Code

説明に用いたセンササンプルコードが、上記3種類です。ダウンロードには、ルネサスのログインが必要です。同一動作のベアメタル/FreeRTOS/Azure RTOS、3個のe2studioプロジェクトが同胞されています。動作MCUは、ルネサス)RA/RX/RE/RL78ファミリです。

サンプルコードマニュアルだけは、下記からログイン不要でダウンロードできます。本稿は、これらマニュアル情報だけで読める工夫をしました。

  1. FS2012 Sample application
  2. HS300x Sample application
  3. ZMOD4xxx Sample application

FS2012がガスフローセンサ、HS300xが湿度・温度センサ、ZMOD4xxxが高性能ガスセンサです。この順番で、サンプルコードが複雑になります。

そこで、焦点を、一番簡単なFS2012サンプルコード、動作MCUをRA6M4(Cortex-M33/200MHz/1MB Flash/256KB RAM)に絞って説明します。他サンプル/MCUでも同様の結果が得られます。

なお、3サンプルコードは、ベアメタルからRTOS開発へステップアップする時にも適したコードです。

センサとMCU間接続:I2C

PMODインタフェースによるセンサボードとMCU接続
PMODインタフェースによるセンサボードとMCU接続

センサとMCU間は、サンプルコード全てPMOD経由のI2C接続です。従って、I2C接続センサのIoT MCU制御例としても応用可能です。FreeRTOSとAzure RTOS、両方に対応した点が便利です。

PMODとは、米Digilent社規定のオープンインタフェース規格です。図示のように、複数センサボードを、レゴブロックのようにMCUへ追加接続できる特徴があります。

ベアメタルとFreeRTOS/Azure RTOSメモリ量

FS2012サンプルコードマニュアルより抜粋した使用メモリ量比較です。

ベアメタル FreeRTOS Azure RTOS
Flash 1065 bytes 1374 bytes 1342 bytes
RAM 73 bytes 249 bytes 246 bytes

RTOSは、ベアメタル比1.3倍のFlash使用量、3.4倍のRAM使用量です。但し、上表にRTOSタスク/スレッドのスタックメモリ量は含みません。

Flash/RAM使用量が増加しますが、RTOS開発ソフトウェア流用性が高まるメリットがあります。これら増加分は、ベアメタル単体処理からRTOSマルチタスク/スレッド処理のオーバーヘッドに相当すると考えて良いでしょう。

マルチタスク/スレッド以外にも、RTOS開発には、クラウド接続/セキュリティ/OTA(Over The Air)処理などのオーバーヘッドが別途必要です。

これら処理のため、IoT MCUは、ベアメタル比、Flash/RAM量の十分な余裕と高速動作が必要になります。

FS2012センサAPI使用方法

FS2012フローセンサの使用APIとその利用手順です。一般的なセンサでも同様で、特に変わった点はありません。

FS2012 APIと利用手順
FS2012 APIと利用手順

ベアメタル処理フロー

RTOS開発の起点となるベアメタル開発の処理フローです。

FS2012のベアメタル処理フロー
FS2012のベアメタル処理フロー

初期設定で、I2Cとセンサを初期化し、無限ループ内で、センサデータ取得と取得データの演算を繰返します。センサデータの連続取得に409.6ms遅延時間が必要であることも判ります。センサデータ取得完了は、センサ割込みを使って検出しています。

このベアメタル処理フローも、特に変わった点はありません。

RTOS処理フロー

ベアメタルと異なる処理だけを橙色抜粋したFreeRTOS処理フローです。

ベアメタル処理とRTOS処理のフロー差分
ベアメタル処理とRTOS処理のフロー差分

差分は、RTOS遅延:vTaskDealy()/tx_thread_sleep()で409.6msと1msが加わる点、vTaskDelete()/tx_thread_delete()でタスク削除する点です。

また、センサ制御本体は、タスク/スレッド記述へ変更し、セマフォにより別タスク/スレッドとの排他制御を行います。

1ms遅延は、別タスク/スレッド切替えに必要です(関連投稿のコチラ、6章コンテキストスイッチ参照)。FS2012サンプルは、タスク/スレッド数が1個なので切替え不要です。

しかし、例えば、HS300xセンサボードを、FS2012センサボードへレゴブロック様式で追加した時は、FS2012センサとHS300xセンサの2タスク/スレッドを、この1msスリープでRTOSが切替えます。

FS2012センサは、ベアメタル処理フローで示したデータ取得間隔に409.6ms遅延処理が必要です。この遅延中に、HS300xセンサのデータ取得を行えば、両タスク/スレッドの効率的な並列多重ができ、これにセマフォ排他制御を用います。

※RTOS遅延処理は、本稿最後の補足説明参照。RTOSメリットが具体的に判ります。

この切替え処理が、本稿最初の図で示したRTOS処理待ちに相当します。その他のRTOS処理フローは、ベアメタル処理と同じです。

つまり、RTOS処理とは、単体のベアメタル処理へ、RTOS処理待ちを加え、複数のベアメタル処理を並列処理化したものです。

数式的に表すと、「ベアメタル処理+RTOS処理待ち=RTOS処理」です。

RTOS(FreeRTOS/Azure RTOS)ソフトウェア開発手法

IoT MCU開発者スキルの階層構造
IoT MCU開発者スキルの階層構造

ベアメタル処理を、効率的に複数並列動作させるのがRTOSの目的です。

この目的のため、優先制御や排他、同期制御などの多くの機能がRTOSに備わっています。RTOSの対象は、個々のベアメタル処理です。つまり、ベアメタル開発スキルを起点・基盤としてその上層にRTOS機能がある訳です。

RTOS習得時、多くの機能に目移りします。しかし、本稿最初の図に示したように、RTOSは、複数ベアメタル処理(タスク/スレッド)を、優先度や排他・同期条件に応じて切替え並列多重化します。

逆に、ベアメタル側からRTOSを観ると、セマフォ/Queueなど「RTOSによる処理待ち」がベアメタル無限ループ内に入っただけに見えます。「待ち/解除の制御は、RTOS」が行います。待ち処理の種類が、セマフォ/Queue/イベントフラグ……など様々でも、「ベアメタル側からは単なる待ち」です。

筆者が、RTOS開発の起点はベアメタル処理、とした理由が上記です。

つまり、ベアメタル起点RTOSソフトウェア開発手順は、

1:単体ベアメタル処理開発。単体デバッグ後、タスク/スレッド化。
2:タスク/スレッド無限ループ内へ、RTOS処理待ち挿入。
3:複数タスク/スレッド優先度を検討し、RTOS結合デバッグ。

以上で、RTOSソフトウェア開発ができます。

処理自体は、1でデバッグ済みです。2以降は、効率的RTOS処理待ち挿入と、複数タスク/スレッド間の優先度検討が、主なデバッグ内容です。複数タスク/スレッドが想定通り並列動作すれば、第1段階のRTOSソフトウェア開発は完了です。

スタックメモリ調整やより効率的な待ち処理などのチューニングは、3以降で行います。

RTOS待ち処理は、セマフォやQueueの利用頻度が高いため、RTOS習得もセマフォ/Queueを手始めに、より高度な待ち処理機能(イベントフラグなど)へと順次ステップアップしていけば良いでしょう。

ベアメタル開発経験者が感じるRTOS障壁

ベアメタルは、開発者自身が全ての制御を行います。ところが、RTOS開発では、ソースコード内に、自分以外の第3者:RTOSが制御する部分が混在します。ここが、ベアメタル開発経験者の最初のRTOS違和感、RTOS障壁です。

前章の手法は、1でベアメタル処理を完成すれば、2以降は、RTOS処理のデバッグに集中できます。つまり、既に持っているベアメタルスキルと新しいRTOSスキルを分離できます。これで、最初に感じたRTOS障壁は小さくなります。

また、RTOS障壁は、IoT MCUクラウド接続時の通信処理やセキュリティ処理時に、MCUベアメタル開発経験者に大きく見えます。しかし、これらの処理は、決まった手順で当該ライブラリやAPIを順番に利用すれば良く、一度手順を理解すれば、本当のRTOS障壁にはなりません。

クラウド接続やセキュリティ処理サンプルコードを入手し、各API利用手順の理解後は、これら該当処理の丸ごと流用でも十分に役立ちます。

まとめ:RTOSソフトウェア開発手法

IoT MCU RTOSソフトウェア開発の3分野
IoT MCU RTOSソフトウェア開発の3分野

IoT MCUは、クラウド接続のためRTOS開発になります。IoT MCU RTOS開発は、データ収集、クラウド接続、エッジAIやIoTセキュリティなど、大別すると3分野に及びます(関連投稿:世界最大情報通信技術(ICT)サービス輸出国、アイルランドIoT事情)。

本稿は、センササンプルコードを使い、ベアメタルスキル起点・基盤としたデータ収集分野のRTOSソフトウェア開発手法を説明しました。

1:単体ベアメタル処理開発。単体デバッグ後、タスク/スレッド化。
2:タスク/スレッド無限ループ内へ、RTOS処理待ち挿入。
3:複数タスク/スレッド優先度を検討し、RTOS結合デバッグ。

数式的に示すと、「ベアメタル処理+RTOS処理待ち=RTOS処理」です。

クラウド接続とエッジAI/IoTセキュリティ分野は、決まった手順のRTOSライブラリ活用などが主な開発内容です。従って、この分野は、差別化の努力は不要です。

IoT MCU RTOS開発で、他社差別化できるデータ収集RTOSソフトウェア開発の手法を説明しました。

RAベアメタルテンプレート発売中

RAベアメタルテンプレート概要
RAベアメタルテンプレート概要

2022年5月にRAベアメタルテンプレート(1000円税込)を発売しました。本稿説明のRTOS(FreeRTOS/Azure RTOS)ソフトウェア開発には、ベアメタルスキルが必須です。

RAベアメタルテンプレートにより、開発ツール:FSP(Flexible Software Package)やe2studioの使い方、豊富なベアメタルサンプルコードを活用したベアメタル開発スキルが効率的に得られます。ご購入は、コチラから。

RA版RTOSテンプレート(仮名)は、検討中です。

NXP版FreeRTOSテンプレート発売中

NXP版FreeRTOSテンプレートも発売中です。また、本年度中には、ST版Azure RTOSテンプレートも、開発・発売予定です。

弊社ブログは、RTOS関連も多数掲載済みです。ブログ検索窓に、FreeRTOSやAzure RTOSなどのキーワードを入力すると、関連投稿がピックアップされます。

補足説明:RTOS遅延処理

RTOS遅延処理のvTaskDealy(409.6ms)/tx_thread_sleep(409.6ms)は、他タスク/スレッドの処理有無に関わらず409.6msの遅延時間を生成します。これは、ベアメタル開発者にとっては、夢のようなRTOS APIです。

このようにRTOSは、開発ソフトウェアの独立性・流用性を高めるマルチタスク/スレッド動作を実現し、ベアメタルの補完機能を提供します。

つまり、ベアメタル開発中に、他処理の影響を受けるので開発が難しいと思う部分(例えば、上記遅延処理など)があれば、RTOSのAPI中に解が見つかる可能性があります。

あとがき

長い投稿にお付き合いいただき、ありがとうございました。

ベアメタル開発経験者がRTOS習得・開発を目指す時、サンプルコード以外の情報が多すぎ、途中でくじけそうになります。本稿は、サンプルコードとベアメタルスキルを活かしRTOS開発へステップアップする手法を示しました。RTOSでも、基本はベアメタルスキルです。

RTOSサンプルコードが豊富にあれば、必要情報の絞り込み、RTOSスキル向上も容易です。掲載RTOSサンプルコードは、非常に貴重だと思いましたので、RTOSソフトウェア開発手法としてまとめました。

組込み開発 基本のキ:RTOS vs. ベアメタル

RTOS vs. BareMetal
RTOS vs. BareMetal

2022年最初の投稿は、RTOSとベアメタルを比較します。RTOSを使わないベアメタルMCU開発者が多いと思いますので、RTOS開発メリット/デメリットをベアメタル側から評価、RTOSデバッグツール紹介とベアメタル開発の意味を考えました。

RTOS目的

Flexible Software Package構成
Flexible Software Package構成

ルネサスRAファミリのFlexible Software Package構成です。左上Azure RTOSやFreeRTOSの中に、ConnectivityやUSBがあります。これらMCU共有資源を管理するシステムソフトウェアがOSで、PCのWindowsやMac、Linuxと機能的には同じです。

Real-Time性が必要な組込み用OSをRTOSと呼び、FreeRTOSやAzure RTOSが代表的です。これは、IoT MCU接続先が、Amazon Web Services(AWS)クラウドならばFreeRTOSライブラリ、Microsoft AzureクラウドならAzure RTOSライブラリ(図のConnectivity)利用が前提だからです。

※2021年のIoTクラウドシェアは、コチラの関連投稿からAWS>Azure>GCPの順です。

RAファミリに限らず、クラウド接続のIoT MCUは、これらRTOSライブラリを使ったRTOS開発になります。

RTOSメリット/デメリット

例えば、ベアメタルでUSB制御を自作する場合は、USB 2.0/3.0などの種類や速度に応じた作り分けが必要です。ライブラリがあるRTOSなら、USBポートへの入出力記述だけで利用可能です。RTOSが共有資源ハードウェア差を吸収し、アプリケーションが使い易いAPIを提供するからです。

RTOSの資源管理とは、MCUコア/Flash/RAM/周辺回路/セキュリティなどの共有資源を、アプリケーション側から隠蔽(≒ブラックボックス化)すること、とも言えます。

RTOSアプリケーションは、複数タスク(スレッドと呼ぶ場合もあり)から構成され、タスク間の優先制御もRTOSが行います。開発者は、単体処理タスクを複数開発し、それらを組み合わせてアプリケーションを構成します。RTOSアプリケーション例が下図、灰色が開発部分、コチラが関連投稿です。

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

RTOS利用メリット/デメリットをまとめます。

メリットは、

・RTOSライブラリ利用により共有資源活用タスク開発が容易
・移植性の高いタスク、RTOSアプリケーション開発が可能
・多人数開発に向いている

デメリットは、

・複数タスク分割や優先順位設定など、ベアメタルと異なる作り方が必要
・共有資源、特にRAM使用量がタスク数に応じて増える
・RTOS自身にもバグの可能性がある

簡単に言うと、RTOSとベアメタルは、「開発作法が異なり」ます。

ソフトウェア開発者は、RTOS利用と引換えに、自己流ベアメタル作法を、RTOS作法へ変えることが求められます。RTOS作法は、標準的なので多人数での共同開発が可能です。もちろん、ベアメタルよりもオーバーヘッドは増えます。このため、RTOS利用に相応しい十分なMCUコア能力も必要です。

RTOSタスク開発 vs. ベアメタルアプリケーション開発

最も効果的なRTOS作法の習得は、評価ボードを使って実際にRTOSタスク開発をすることです。弊社FreeRTOSアプリケーションテンプレートは、この例です。

それでも、RTOSタスク開発作法を文章で記述すると、以下のようになります。

開発対象がアプリケーションからタスク(スレッド)へ変わることが、ベアメタルとの一番の違いです。Windowsタスクバーにあるフィルダ表示や、ペイントなどと同様、タスクは、単機能の小さいアプリケーションとも言えます。

このタスクを複数開発し、複数タスクを使ってRTOSアプリケーションを開発します。タスクには、それぞれ優先順位があり、他のタスクとの相対順位で実行タスクがRTOSにより決まります。タスクの状態遷移が、RTOSへの備え:第2回、タスク管理で示した下図です。

FreeRTOS Task States
FreeRTOS Task States

ベアメタルアプリケーションとは異なり、優先順位に応じてタスクが実行(Running)され、その実行も、定期的に実行可能状態(Ready)や待ち状態(Suspended)、停止状態(Blocked)へRTOSが変えます。これは、リアルタイムかつマルチタスク処理が、RTOSの役目だからです。遷移間隔などは、RTOS動作パラメタが決めます。

ベアメタル開発は、開発者が記述した通りに処理が実行されますが、RTOS開発のタスク実行は、RTOS任せです。RTOS開発難易度の上がる点が、ここです。

一般的なIoT MCUは、シングルコアですので、実行タスク数は1個、多くの他タスクは、Not Running(super state)状態です。RTOSがタスクを実行/停止/復活させるため、スタックやRAM使用量が急増します。

これら文章を、頭の中だけで理解できる開発者は、天才でしょう。やはり、実際にRTOSタスクを開発し、頭の中と実動作の一致/不一致、タスク優先順位やRTOS動作パラメタ変更結果の評価を繰返すことで、RTOS理解ができると凡人筆者は思います。

ベアメタル開発者が手早くRTOSを理解するには、既にデバッグ済みの複数RTOSタスク活用が便利で、FreeRTOSアプリケーションテンプレートは、この要求を満たしています。概要は、リンク先から無料ダウンロードできます。

文章でまとめたFreeRTOS解説が、コチラの弊社専用ページにあります。また、本ブログ検索窓にFreeRTOSと入力すると、タスク開発例などが参照できます。

RTOSデバッグツール

percepio tracealyzer
percepio tracealyzer

さて、RTOS作法に則ってタスク開発し、RTOS動作パラメタも適切に設定しても、思ったように開発タスクが動作しない時は、ブラックボックスRTOS自身のバグを疑う開発者も多いでしょう。RTOSのバグ可能性もありえます。

この疑問に対して強力にRTOS動作を解析できるFreeRTOSデバッグツールがあります。資料が無料でダウンロードできますので、紹介します。

※このツールを使うまでもなく、弊社FreeRTOSアプリケーションテンプレートは、正常動作を確認済みです。

まとめ:RTOS vs. ベアメタル

IoT MCUのクラウド接続 → 接続クラウド先のRTOSライブラリ必要 → RTOSライブラリ利用のRTOS開発が必要、という関係です。

RTOS開発は、ベアメタルと開発作法が異なる複数タスク開発です。タスクは、優先順位に応じてRTOSがMCU処理を割当てます。また、MCU共有資源がRTOSアプリケーションから隠蔽されるため、移植性が高く多人数での大規模開発にも向いています。

一方で、RTOSオーバーヘッドのため、ベアメタルよりも高いMCU能力が必要です。

シングルコアMCUでは、RTOSとベアメタルのハイブリッド開発は困難です。開発者がRTOSを利用するなら、慣れたベアメタル開発から、RTOSタスク開発への移行が必要です。

ベアメタル開発経験者が、効果的にRTOSタスク開発を習得するには、評価ボードと複数RTOSタスクが実装済みの弊社RTOSアプリケーションテンプレートの活用をお勧めします。

ベアメタル開発意味

RTOSのタスク処理待ち(セマフォ/Queue)を使うと、ベアメタルよりも排他/同期制御が簡単に記述できます。それでも、全てのMCU開発がRTOSへ移行することは無いと思います。様々なセンサデータをAD変換するエッジMCUは、ベアメタル開発、エッジMCUを複数個束ねクラウドへ接続するIoT MCUは、RTOS開発などがその例です。

MCU開発の基本は、やはりRTOS無しの「ベアメタル開発」です。

IoT MCU開発者スキルの階層構造
IoT MCU開発者スキルの階層構造

ベアメタル開発スキルを基にRTOSを利用してこそ、RTOSメリットを活かしたタスクやアプリケーション開発ができます。共有資源ブラックボック化、多人数開発のReal-Time OSは、「ベアメタル開発の補完」が起源です。

PC OSとは全く逆のこの生い立ちを理解していないと、効果的なRTOS利用はできません。近年MCU性能向上は著しいのですが、向上分をRTOSだけに振り分けられる程余裕はなく、IoTセキュリティなどへも配分する必要があります。

この難しい配分やRTOS起因トラブルを解決するのが、ベアメタル開発スキルです。弊社マイコンテンプレートは、主要ベンダのベアメタル開発テンプレートも販売中、概要ダウンロード可能です。

組込み開発 基本のキ:バックナンバー

2022年最初の投稿に、筆者にしては長文すぎる(!?)のRTOS vs. ベアメタルを投稿したのは、今年以降、RTOS開発が急速に普及する可能性があるからです。

クラウド接続からRTOS必要性を示しましたが、セキュリティなど高度化・大規模化するIoT MCU開発には、移植性の高さや多人数開発のRTOSメリットが効いてきます。

また、半導体不足が落ち着けば、RTOS向き高性能MCUの新しいデバイスが、各ベンダから一気に発売される可能性もあります。スマホ → 車載 → IoT MCUが、半導体製造トレンドです。

※現状のMCUコア関連投稿が下記です。
Cortex-M33とCortex-M0+/M4の差分
Cortex-M0からCortex-M0+変化
Cortex-M0/M0+/M3比較とコア選択

IoT MCU開発が複雑化、高度化すればする程、前章のベアメタル開発や、組込み開発の基礎技術:基本のキの把握が、開発者にとって益々重要になります。

組込み開発、基本のキ:バックナンバーを示します。年頭、基本を再確認するのはいかがでしょう?
組込み開発 基本のキ:組込み処理
組込み開発 基本のキ:IoT MCUセキュリティ



組込み開発 基本のキ:組込み処理

IoT MCUソフトウェア/ハードウェア開発者向け基本のキ、今回は、組込み処理の「ポーリング」、「割込み」、「低消費電力動作」とMCU開発の秘訣(コツ)を示します。ベアメタル開発でもRTOS開発でもこれらは同じです。これら基本を知ると、サンプルコードの読み方、利用法も解ります。

ポーリング と 割込み

「ポーリング」とは、無限ループを周る度に例えばSWが押されたかどうかのフラグ相当をポーリング(polling)し、フラグが立ったら、その処理を実行することです。

ポーリング
ポーリング

「割込み」は、割込み発生時に周辺回路が自動で呼出すISR(Interrupt Service Routine)を開発します。

ISRは、出来るだけ軽く(小さく)することが重要です。別周辺回路の割込みもできるだけ取込むためです。そこでISRでは、周辺回路が割込み発生時に立てた割込み発生フラグをリセット、このフラグとは別の割込み処理待ちフラグを立ててコード化するのが常套手段です。

この割込み処理待ちフラグを無限ループでポーリング、ブラグが立っていれば実際の割込み処理を実行します。

つまり、割込み処理の前段階にISRがあり、ポーリングのフラグ相当が割込み処理待ちフラグに変るだけ、結局、ポーリングに帰着します。

割込み
割込み

ベアメタル開発でもRTOS開発でも上記は同じです。RTOS時は、タスク間のセマフォ/Queueによる処理待ちが差分として追加されます(これら以外にも処理待ちはありますが、セマフォ/Queueで当面賄えます)。

低消費電力動作

無限ループをそのまま連続で回し続けると消費電力が増加します。そこで、間欠的にループを回し、ループを回さない時間は、最も電力を消費するMCUを停止するのが「低消費電力動作」です。

低消費電力動作
低消費電力動作

例えば1秒毎に1回ループを回すなど、低電力化を図りつつループ連続回しの時と大差なく処理する、つまり、どの程度間欠動作させるかが開発者の腕の見せ所です。

まとめ:ポーリング、割込み、低消費電力動作の3Tipsと開発秘訣

IoT MCUで開発するのは、MCUを含む周辺回路の初期設定と、無限ループ内の処理です。

初期設定とは、内蔵周辺回路を動作させるための設定です。周辺回路は、初期設定が終わると直に動作を開始します。そこでMCUは、動作中の周辺回路を監視し、必要に応じて処理を行います。このMCU監視が、無限ループ内の処理です。「組込み処理の中身」は、このように初期設定とループ内処理の2種類です。

初期設定の前にRAMクリアなどのスタートアップ処理もありますが、ここはIDEが自動生成し、通常、開発者が手を加えることは殆どありません。

初期設定は、サンプルコードの初期設定をそのまま流用する部分です。サンプルコードに使用例がない特殊(!?)な周辺回路の使い方をする時は、データシートやユーザマニュアルの当該周辺回路部分を熟読すればコード化できます。

次の開発部分が、無限ループ内です。ループ内処理をまとめた本稿の3Tipsが下記です

  1. 無限ループ内は、「ポーリング」か「割込み」のどちらか
  2. 割込みは、ISRで「割込み発生フラグ」を「割込み処理待ちフラグ」へ事前変換しポーリングへ帰着
  3. 無限ループの間欠動作と、間欠中のMCU停止が、「低消費電力動作」
組込み処理の3Tips、ポーリング、割込み、低消費電力動作
組込み処理の3Tips、ポーリング、割込み、低消費電力動作

組込み処理の中身とこれら3Tipsを知らずに組込み開発を始めるは、非効率です。中身と3Tipsを習得するには、紆余曲折、結構な時間と実務(失敗)経験が必要だからです。

例を挙げると、技術背景が少ない初心者にとっては、関連情報が多いため消化不良を起こします。また、初心者でなくても、開発自由度が高い(≒無いに等しい)ので、開発を上手く収束させには、Tipsやコツが必要になるなどです。

全てを網羅的に記述しているデータシートやユーザマニュアルは、既にこれらコツや技術背景を習得済みの中級者以上には役立ちますが、それ以外の人が読んでも実質の理解はできません。いきなり六法全書を読んで弁護士をする様なものです😂。

MCU開発の秘訣(コツ)は、先ず、3Tipsを基にプロトタイプを開発し、次に、実際に動作するプロトタイプを使って、開発自由度の高さを活かし動作チューニングすることです。

実働プロトタイプがあれば、データシート実質理解も進みますし、チューニング結果で変な動作になっても元のプロトタイプへ戻れますので、安心して色々な試行錯誤ができ、開発者スキルアップも容易です。

サンプルコード利用法

主要MCUベンダは、多くのサンプルコードを提供中です。

サンプルコードの目的は、“1つ”の周辺回路の基本動作を解り易く示すことです。基本動作は、初期設定と無限ループ内の2つに分けて読みます。無限ループ内は、Tips1/2から処理内容が理解できます。割込みの時は、ISRがあります。

初期設定は、開発に使う使用例と同じかどうかを添付コメントなどから判断します。使用例が同じ、または、近いなら、そのままコピーして流用します。内容を理解したい時は、”その周辺回路のデータシートのみ”を読めば十分です。

もちろん、サンプルコード無限ループ内のポーリング/割込み処理もそのままコピーして流用可能です。

但し、サンプルコードは、一般的にTips3:低消費電力動作への配慮がありません。また、サンプルコードを、“複数”集めて動作させる作り方ではありません。1周辺回路の動作コードを、シンプルに解り易く示すためです。

弊社マイコンテンプレートは、複数サンプルコードを利用する仕組みを予め持っています。また、無限ループの間欠動作と停止MCUを復帰させる仕組みも、テンプレートへ組込み済みです。

テンプレートのサンプルコード利用法
テンプレートのサンプルコード利用法

つまり、初めから複数サンプルコードの活用・流用が即座に出来るようテンプレート化、主要ベンダの汎用MCUに対応し、適用例と詳しい説明資料付き(一部ダウンロード可)で販売中です(ベアメタル開発用:1000円、RTOS開発用:2000円、テンプレート一覧と価格はコチラ)。

本稿3Tipsを知っていれば、サンプルコードを分析しながら読むことができ、必要に応じて各部分を自分のソフトウェアや弊社テンプレートへ組込むことも可能です。

プロトタイプ開発に最適なのが、弊社テンプレートです。テンプレートを使って早期にプロトタイプ開発を実現すれば、開発者の効率的スキルアップ、要求仕様に対するMCU性能過不足なども明らかとなり、お役に立てると思います。

テンプレートご購入、お待ちしております。

Windows 10と11、Linux Mint、IoT MCU開発

2021年10月5日(米国時間)、次期Windows 11リリース、Windows 10 21H2リリースも10月5日前後と見込まれています。2025年迄の期間で、今後のPCとIoT MCU開発環境、開発者要件を考えてみました。

PCとIoT MCU開発環境まとめ

Windows 10、Windows 11、Linux MintとIoT MCU開発環境(2025年までの範囲)
Windows 10、Windows 11、Linux MintとIoT MCU開発環境(2025年までの範囲)

Windows 10 21H2小規模更新

年2回あるWindows 10大型更新、今秋のバージョン21H2更新も小規模更新です。

20H1から4回連続の小規模更新で、バージョンサポート期間も1.5年とこれまでと同じです。Windows 10サポート終了は、延長無しの場合2025年10月14日です。

Microsoftは、Windows 10の新規開発を終息し、次期Windows 11へ注力したいハズです。これは、サポート終了2025年までは小規模更新を繰返し、PCユーザ側は、逆に安定した最新Windows 10が使えるメリットを生みます。

なおWindows 10の更新方法は、コチラの投稿記事を参考にしてください。

Windows 11へのアップグレード要件緩和は幾分発表されましたが、セキュリティTPM2.0は相変わらずで、Windows 10から従来のような安易な11アップグレートをMicrosoftは許しません。従って、11要件が現状のままなら、Windows 10 PCの使い道は2025年以降無くなる運命です。

11化できない、または、10サポート終了後のWindows 10 PCをどう運用するかは問題です。解決策は、後で示します。

Windows 11プレビュー版評価

「Windows 11 もっさり」で検索すると、多くの記事がヒットします。もちろん、Windows 11プレビュー版試用感想です。Windows 10比、動作が遅く感じる人が多いのは確かなようです。

これは、CPU能力を、従来よりもグラフィックとセキュリティへ配分した結果だと推測します。

ビジネスユースの場合、Windowsグラフィック能力が生産性を向上させることはありません(Mac PCは別です)。一方、セキュリティ能力は、重要ではあるものの、しばしば開発作業の邪魔になります。開発ツールインストールや更新時、セキュリティソフトが不要な警告を出すことを経験された方は多いでしょう。

セキュリティは、「安全側マージンを大きく保って動作」します。存在意義を示すためやむを得ないのは理解できますが、開発の邪魔になるのは間違いありません。

Windows 11は、Apple製M1チップ搭載の新Mac PC対抗手段なのか、初めから高性能グラフィックと新セキュティ対応の新しいCPUチップ利用を想定している気がします。Windows 11リリース後、製品版やプレインストールPCなどからMicrosoftの意図や本当の目的も明らかになるでしょう。

Windows 11は、年1回の大型更新と、2年間のバージョンサポート運用です。今秋リリースから1年経過後に初期トラブルを回避した大型更新バージョンがリリースされます。リリース後1年は、製品版11評価期間と考えても良さそうです。

結局、Windows 11アップグレート要件を満たすPCであっても、1年評価期間後、初期トラブル回避版でアップグレートしても遅くはないと思っています。

※「Windows 11 TPM 回避 インストール」の検索結果からTPM回避11化は可能のようです。本稿は、公式11アップグレート要件を満たすWindows 10 PCのみを対象とします。

Windows 10問題解決Linux Mint

Windows 11化できないPCの活用方法としてお勧めするのが、Linux Mintです(但し64ビットCPU必須)。その理由が下記2つです。

  1. Windowsに比べハードウェア仕様が低くてもLinux Mintは快適動作
  2. Windows GUIに慣れたユーザにはLinuxコマンド操作に違和感があるが、Linux Mintは、殆どの操作がWindowsとよく似たGUIで可能

Windows 10サポート終了まで4年あります。Linux Mint操作に慣れ、代替利用上の問題有無を評価するには、十分な期間だと思います。

マルチプラットフォームIoT MCU開発環境

IoT MCU開発環境も、Windowsのみの動作から、Windows/Mac/Linuxマルチプラットフォームへ移行しつつあります。例えば、NXP)MCUXpresso IDE、STマイクロ)STM32CubeIDE、Cypress)ModusToolboxなどは、OSが異なっても同じ動作をします。

MCUXpresso IDEやSTM32CubeIDEのLinux Mint版インストール方法は、コチラの関連投稿5章を参照してください。

個人向けWindows 365

発表済みの企業向けプラン価格よりかなり安くなることが必要ですが、個人向けWindows 365プランの価格次第では、セキュリティ/保守運用面でメリットがあるWindows 365 Cloud PCは魅力的です。

仮に、スマホと同程度、つまり月額1000円以下、5年間利用してもトータル6万円程度でWindows 365が利用できれば、個人ビジネスにも十分使えます。過剰期待かもしれませんが…。

世界的半導体不足

経年変化などを考慮し、Windows 11プレインストールPCを新規購入するのも変化への対処方法の1つです。但し、昨今の世界的な半導体不足は、PC調達価格上昇をもたらし、購入逆風の状況です。この逆風は、Windows 10サポート終了に向けて新規PC需要が高まるため、さらに強くなるハズです。

IoT MCU開発者要件

以上のような2025年までの激しいPC環境変化に対し、IoT MCU開発環境は、Windows/Mac/Linuxマルチプラットフォーム化で対応します。

IoT MCU開発者は、従来のような単純なMCU処理開発だけでなく、クラウド接続RTOS、セキュリティ、OTA(Over The Air)、エッジAIなど様々なIoT付加サービスの追加が顧客に応じて必要になります。また、これら付加サービス規模や技術背景も複雑です。

これら付加サービスは、既にLinux上で開発済みのものも多く、IoT MCU開発者は、Linux環境に慣れていくことが必要だと思います。更に、顧客毎に異なるIoT付加サービスを、ある意味ブラックボックス的に取捨選択し、従来のMCU開発へ短期で追加/削除できるテクニックを身に着けておくことも必要です。

つまり、Windows利用に慣れたIoT MCU開発者でも、Linux要素技術を持つ必要があります。

IoT MCU開発者「個人レベル」で、これらLinux技術習得やIoT MCU技術を効率的に習得する手段として本ブログ投稿や弊社マイコンテンプレートがお役に立てるように開発していきます。

Cortex-M4評価ボードRTOSまとめ

低価格(4000円以下)、個人での入手性も良い32ビットARM Cortex-M4コア評価ボードのRTOS状況を示します。超低価格で最近話題の32ビット独自Xtensa LX6ディアルコアESP32も加えました。

Vendor NXP STマイクロ Cypress Espressif Systems
RTOS FreeRTOS
Azure RTOS
CMSIS-RTOS FreeRTOS
Mbed OS
FreeRTOS
Eva. Board LPCXpresso54114 NUCLEO-G474RE CY8CPROTO-063-BLE ESP32-DevKitC
Series LPC54110 STM32G4 PSoC 6 ESP32
Core Cortex-M4/150MHz Cortex-M4/170MHz Cortex-M4/150MHz
Cortex-M0+/100MHz
Xtensa LX6/240MHz
Xtensa LX6/240MHz
Flash 256KB 512KB 1024KB 480KB
RAM 192KB 96KB 288KB 520KB
弊社対応 テンプレート販売中 テンプレート開発中 テンプレート検討中 未着手

※8月31日、Cypress PSoC 6のRTOSへ、MbedOSを追加しました。

主流FreeRTOS

どのベンダも、FreeRTOSが使えます。NXPは、Azure接続用のAzure RTOSも選択できますが、現状はCortex-M33コアが対応します。ディアルコア採用CypressのRTOS動作はM4側で、M0+は、ベアメタル動作のBLE通信を担います。STマイクロのCMSIS-RTOSは、現状FreeRTOSをラップ関数で変換したもので実質は、FreeRTOSです(コチラの関連投稿3章を参照してください)。

同じくディアルコアのEspressifは、どちらもRTOS動作可能ですが、片方がメインアプリケーション、もう片方が通信処理を担当するのが標準的な使い方です。

価格が上がりますがルネサス独自32ビットコアRX65N Cloud Kitは、FreeRTOSとAzure RTOSの選択が可能です。但し、無償版コンパイラは容量制限があり、高価な有償版を使わなければ開発できないため、個人向けとは言えません。

※無償版でも容量分割と書込みエリア指定など無理やり開発するトリッキーな方法があるそうです。

クラウドサービスシェア1位のAWS(Amazon Web Services)接続用FreeRTOSが主流であること、通信関連は、ディアルコア化し分離処理する傾向があることが解ります。

ディアルコア

ディアルコアで通信関連を分離する方式は、接続クラウドや接続規格に応じて通信ライブラリやプロトコルを変えれば、メイン処理側へ影響を及ぼさないメリットがあります。

例えば、STマイクロのCortex-M4/M0+ディアルコアMCU:STM32WBは、通信処理を担うM0+コアにBLEやZigBee、OpenThreadのバイナリコードをSTが無償提供し、これらを入れ替えることでマルチプロトコルの無線通信に対応するMCUです。

メイン処理を担うM4コアは、ユーザインタフェースやセンサ対応の処理に加え、セキュティ機能、上位通信アプリケーション処理を行います。

通信処理は、クラウド接続用とセンサや末端デバイス接続用に大別できます。

STM32WBやCY8CPROTO-063-BLEが採用した末端接続用のBLE通信処理を担うディアルコアのCortex-M0+には、敢えてRTOSを使う必要は無く、むしろベアメタル動作の方が応答性や低消費電力性も良さそうです。

一方、クラウド接続用の通信処理は、暗号化処理などの高度なセキュティ実装や、アプリケーションの移植性・生産性を上げるため、Cortex-M4クラスのコア能力とRTOSが必要です。

デュアルコアPSoC 6のFreeRTOS LED点滅

デュアルコアPSoC 6対応FreeRTOSテンプレートは、現在検討中です。手始めに表中のCY8CPROTO-063-BLEのメイン処理Cortex-M4コアへ、FreeRTOSを使ってLED点滅を行います。

と言っても、少し高価なCY8CKIT-062-BLEを使ったFreeRTOS LED点滅プログラムは、コチラの動画で紹介済みですので、詳細は動画をご覧ください。本稿は、CY8CPROTO-063-BLEと動画の差分を示します。

CY8CPROTO-063-BLE のCortex-M4とM0+のmain_cm4.c、main_cm0p.cとFreeRTOSConfig.hが下図です。

PSoC 6 CY8CPROTO-063-BLE FreeRTOS LED点滅のmain_cm4.cとmain_cm0.c
PSoC 6 CY8CPROTO-063-BLE FreeRTOS LED点滅のmain_cm4.cとmain_cm0.c
PSoC 6 CY8CPROTO-063-BLEのFreeRTOSConfig.h
PSoC 6 CY8CPROTO-063-BLEのFreeRTOSConfig.h

日本語コメント追記部分が、オリジナル動画と異なる箇所です。

RED LEDは、P6[3]ポートへ割付けました。M0+が起動後、main_cm0p.cのL18でM4システムを起動していることが判ります。これらの変更を加えると、動画利用時のワーニングが消えCY8CPROTO-063-BLE でFreeRTOS LED点滅動作を確認できます。

PSoCの優れた点は、コンポーネント単位でプログラミングができることです(コチラの関連投稿:PSoCプログラミング要点章を参照してください)。

PSoCコンポーネント単位プログラミング特徴を示すCreator起動時の図
PSoCコンポーネント単位プログラミング特徴を示すCreator起動時の図

PSoC Creator起動時の上図が示すように、Cypressが想定したアプリケーション開発に必要なコンポーネントの集合体が、MCUデバイスと言い換えれば解り易いでしょう。つまり、評価ボードやMCUデバイスが異なっても、使用コンポーネントが同じなら、本稿のように殆ど同じ制御プログラムが使えます。

PSoC 6 FreeRTOSテンプレートも、単に設定はこうです…ではなく、様々な情報のCY8CPROTO-063-BLE利用時ポイントを中心に、開発・資料化したいと考えています。PSoCプログラミングの特徴やノウハウを説明することで、ご購入者様がテンプレートの応用範囲を広げることができるからです。