8/16ビットMCU置換えを狙う32ビットMCU

半導体不足が続いています。対策として、8/16ビットMCU置換えを狙った、汎用低コストの新しい32ビットMCUを2種紹介します。

STマイクロ:STM32C0シリーズ

STマイクロ、2023年1月12日、低価格なSTM32C0シリーズ(Cortex-M0+:48MHz、Flash:16K/32K、RAM:6K/12K)を発表。

STM32C0とSTM32G0の位置づけ(出展:STMサイト)
STM32C0とSTM32G0の位置づけ(出展:STMサイト)

ルネサス:RA2グループ

ルネサス、2021年10月13日、省スペース低消費電力向けにRA2E2グループ(Cortex-M23:48MHz、Flash:64K、RAM:8K)を、RA2シリーズへ追加。

RA2E2評価ボードのMCU基板アートワーク
RA2E2評価ボードのMCU基板アートワーク

8/16ビットMCU置換え最新32ビットMCU特徴

  • 少数ピン/小型パッケージ
  • 小容量Flash/RAM
  • 低消費電力
  • 低価格(8/16ビットMCUと同等)

8/16ビットMCU置換えを狙う32ビットMCU特徴です。置換え32ビットMCUと言えば、古くからNXP:LPC800シリーズが有名なので、本稿は省略しました。

動作周波数が高くても、Sleepなどの超低消費電力動作時間も長く、実働消費電力は驚くほど小さくなります。また、古い8/16ビットMCUよりも入手性に優れます。

置換え32ビットMCUメリット

旧MCU開発は、周辺回路ドライバなども自主開発することが多く、ドライバとアプリケーションの境界も開発者毎にバラバラでした。最新MCU開発は、ドライバはベンダHAL API生成ツールが自動生成します。

その結果、開発者は、アプリケーション開発に集中でき、ソフトウェア開発費も安くなります。

※HAL API:MCUハードウェアに依存しない(Hardware Abstraction Layer)API。シリーズ/グループが異なっても開発アプリケーション流用が容易。

既に実装済みの旧8/16ビットMCU機能を最新32ビットMCUへ置換える時も、この最新MCU開発環境が使えるため、効率的なソフトウェア開発が可能です。更に、置換えだけでなく、新機能追加、IoTやセキュリティなど高機能アップグレートも容易です。

最新汎用32ビットMCUは、半導体不足にも有効です。紹介したSTマイクロ、ルネサスいずれも、上位MCUへの置換えが可能な基板アートワークができるピン配置を採用しています。

つまり、IoT時代に合わせた開発スキルやソフトウェア発展性があり、基板ハードウェア持続性も期待できるなど、8/16ビットMCU置換え汎用32ビットMCU採用には、多くのメリットがあります。

STM32G0テンプレート、RAベアメタルテンプレート

STM32C0シリーズ開発には、STM32G0Xテンプレート、RA2グループ開発には、RAベアメタルテンプレートがお役に立てます。



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両方で動作確認済みです。



FSP利用RAファミリUARTの使い方

RAファミリ評価ボードFPB-RA6E1PFB-RA4E1FPB-RA2E1などは、MCUのUARTとPCの接続に古いハードウェア知識が必要です。そこで、FPB-RA6E1のUARTとPC接続(USB UART Bridge)を解説し、FSPサンプルコードで動作確認しました。

FSPサンプルコード:sci_uart_fpb_ra6e1_ep

sci_uart_fpb_ra6e1_epのFSP Configuration
sci_uart_fpb_ra6e1_epのFSP Configuration

FPB-RA6E1(Cortex-M33/200MHz、Flash/1MB、RAM/256KB)のUARTとPC接続の公式サンプルコードが、sci_uart_fpb_ra6e1_epです。このFSP (Flexible Software Package)スタックConfigurationが上図です。

簡単に説明すると、FSP UARTスタックを使ってPCとUART(115200bps、8-Non-1)で接続し、Timerスタックを使ってPWMでLED1輝度を変えます。UART受信した1-100値が、PWM設定値です。

つまり、Tera Term経由でPCから1-100を入力すると、評価ボードLED1の輝度がPWM 1-100%で変わります。

sci_uart_fpb_ra6e1_epのreadme.txt
sci_uart_fpb_ra6e1_epのreadme.txt(一部抜粋)

サンプルコード付属readme.txtの上記は、MCUのUARTピンを、どうやってPCのUSBへ接続するかが、開発経験者でも解りにくい箇所です。Windows 7より前の古いMCU開発者なら解るかもしれません。

USB UART Bridge

シリアルポート(出展:ウィキペディア)
シリアルポート(出展:ウィキペディア)

Windows 7以前の古いPCには、RS-232Cコネクタ:シリアルポートが実装済みでした。シリアルポートの用途は、MCUとの通信や、特定アプリのライセンスキーなど多数ありました。

しかし、Windows 7以降、RS-232Cコネクタは消えUSBへと変わりました。

消えたRS-232Cの代わりにUSB経由でMCUと通信を行うのが、USB UART Bridgeです。実績あるデバイスとして、FTDI社のFT232RLが有名でした。

つまり、MCU UART入出力ピンをPCへ接続するには、USB UART Bridge(=USBシリアル変換アダプタ)が必要なことを知っている古いMCU開発者のみreadme.txtが判る訳です。

最近のMCU評価ボードは、USBシリアル変換アダプタとMCUプログラム/デバッグを、1本のUSBで共用しているものが多く、USB UART Bridgeを別途追加し開発する例は稀です。PCのUSBポート数が少なくなってきたからでしょう。

お勧めUSBシリアル変換アダプタ

「FTDI USBシリアル変換」で検索すると、USB 2/3.1や5/3.3V対応など様々なアダプタが、様々な価格で現れます。

殆どの5Vデバイスは、3.3V入力を5V High入力と認識します。それでも、MCUと接続する電圧は、5Vと3.3Vを選択できる方が無難です。High誤認識を防ぐことや、5V耐性が無いMCUピンでも接続できるからです。

低価格で入手性も良く、5/3.3V選択ができるお勧めのUSB UART Bridgeが、FTDI FT232RL USB-TTLシリアル変換アダプタ3個セットです。基板上にスルーホールがあるため、MCU UARTピンとの直接接続も簡単です。

お勧めハードウェアループバックテスト

低価格で3個入り品質に不安な方は、購入後、ハードウェアループバックテストをお勧めします。

ハードウェアループバックテストとは、デバイスの送信:TXDと受信:RXDを結線し、送信データが受信データに現れるかをハードウェア的にテストすることです。このテストにより、購入アダプタが、正常動作することを確認します。

Tera Termを接続すれば、TXD LED、RXD LED動作も確認できます。また、Windows 11 22H2は、お勧めFTDI FT232RL USB-TTLを、追加ドライバなしでUSB Serial Portと認識することも分かります。

ハードウェアループバックテスト
ハードウェアループバックテスト

sci_uart_fpb_ra6e1_ep動作確認

前章までのハードウェア知識を使って、評価ボード:FPB-RA6E1(搭載RA6E1 MCUは、VCC:2.7~3.6 V動作)とシリアル変換アダプタ:FTDI FT232RL USB-TTL(3.3V選択)、PC USBを接続しました。

サンプルコード:sci_uart_fpb_ra6e1_epが示すMCU UART入出力ピンとUSB UART Bridge TXD/RXD接続、PC Tera Termの1-100入力による評価ボードLED1の輝度変化動作が確認できます。

sci_uart_fpb_ra6e1_epの動作確認
sci_uart_fpb_ra6e1_epの動作確認
sci_uart_fpb_ra6e1_epのTera Term入力(橙)と出力(白)
sci_uart_fpb_ra6e1_epのTera Term入力(橙)と出力(白)
sci_uart_fpb_ra6e1_epのFPB-RA6E1とシリアル変換アダプタの結線
sci_uart_fpb_ra6e1_epのFPB-RA6E1とシリアル変換アダプタの結線

Tips:上記ArduinoコネクタのD1 TX (P109)、D0 RX (P110)へMCU UART使用ピンを変えるには、FSP UARTスタックの利用Channel 0をChannel 9へ変更すればOK。

ルネサスRAファミリ評価ボードは、本稿で示したMCU UART用にUSB 1本、e2 studioプログラム/デバッグ用に別のUSB 1本、合計2本のUSBが必要です(PC側もUSB 2ポート必要)。

このe2 studio プログラム/デバッグ用USBの通信ツールが、J-Link RTT Viewerです。sci_uart_fpb_ra6e1_epでは、FSPバージョンやsci_uart_fpb_ra6e1_ep操作方法が示されます。

sci_uart_fpb_ra6e1_epのJ-Link RTT Viewer
sci_uart_fpb_ra6e1_epのJ-Link RTT Viewer

次投稿:ベアメタルサンプル → RTOSタスク化

サンプルコード:sci_uart_fpb_ra6e1_epは、FSP UARTスタックのベアメタル利用例で、良くできています。ベアメタルに限らず、RTOSへの応用範囲も広いです。

そこで次回は、ベアメタルサンプルコード:sci_uart_fpb_ra6e1_epを、RTOSのタスク化する方法を投稿する予定です。この方法により、多くの公式サンプルコードを活用し、効率的にRTOS開発が行えます。

FSP利用関連投稿:FSP利用FreeRTOSアプリの作り方FSP利用FreeRTOS/ベアメタルアプリ起動方法



持続可能MCU開発

半導体不足やサプライチェーン変化など様々な外部要因により、やむをえず開発中のMCUデバイスが変わる場合があります。MCU開発を持続可能にする1案を示します。

MCUと制御対象分離

MCUデバイスが例え変わっても、MCUと制御対象間のインタフェースが同じなら開発の持続は可能です。

もちろん開発ツールや制御APIは、MCUベンダやデバイスで異なります。しかしながら、開発した制御シーケンスや注意点などの取得済み開発ノウハウは、そのまま新しいMCUデバイスへも適用できます。

簡単に言うと、頭(MCU)と手足(制御対象)、目などのセンサ入力を分離し、万一の際に、頭(MCU)交換が可能な分離インタフェースを使ってMCU開発することです。

本稿はMCU互換性に主眼を置きますが、分離インタフェース採用で制御対象やセンサも交換可能です。

つまり、機能単位の高性能化、低価格化も分離インタフェース導入で容易になります。

分離インタフェース多数派

PMODインタフェースとPMODモジュール(出展:RS DesignSpark)
PMODインタフェースとPMODモジュール(出展:RS DesignSpark)

MCUと制御対象を分離するインタフェースも色々あります。例えば、PMODです。

センサやアクチュエータから成る既製PMODモジュールを、Lego™ブロックのように連結し制御対象の機能追加ができます。連結実現のため、I2CやSPI利用が基本です。

別例が、Arduinoです。

多くの主要ベンダMCU評価ボードにArduinoコネクタが採用中です。右下に示すように、デジタル入出力ピン、アナログ入力ピンなど、ピンが物理的に機能分離しています。

ArduinoコネクタコンパチブルMCU評価ボード例
ArduinoコネクタコンパチブルMCU評価ボード例

既製Arduinoモジュールも多く、しかも安価に入手できます。また、機能別ピンのため、手持ちセンサなどを接続し動作を試すのも簡単です。

元々はArduinoやRaspberryなどのMPU(Micro Processor Unit)向け分離インタフェースでしたが、シンプルで使い易いためMCU評価ボードにもArduinoコネクタ適用例が多く、分離インタフェースの多数派となりました。

Tips:MCU端子は、複数機能から選択が可能です。そこで、Arduinoピン機能を優先して選択し、この選択した端子から先に使用すると、MCU交換時の互換性が高まります。

Arduinoプロトタイプシールド

Arduinoモジュールは、別名シールドと呼ばれます。シールドを複数スタック接続し機能追加も可能です。

MCU評価ボードのArduinoコネクタにスタック接続し、付属する小型ブレッドボード上で簡単な回路も追加できるプロトタイプ向けのシールドが、Arduinoプロトタイプシールドです。

Arduinoプロトタイプ シールド
Arduinoプロトタイプ シールド

このシールドには、2個のLEDと1個のSWが実装済みです。MCU評価ボードへ、LEDやSWを簡単に追加でき、手持ち部品などを使ってプロトタイプ開発する場合に最適だと思います。

評価ボードへArduinoプロトタイプシールドを追加しスレッド毎にLED点滅中
評価ボードへArduinoプロトタイプシールドを追加しスレッド毎にLED点滅中

まとめ:持続可能MCU開発

世界平和やサプライチェーン変化などの外部要因により、開発中のターゲットMCUデバイスやベンダが変わる場合がありえます。

万一MCUデバイスが変わっても、MCU開発を持続可能にするため、各ベンダMCU評価ボードに多数採用のArduinoコネクタを使ったMCUと制御対象分離構成を示しました。

Arduinoプロトタイプシールドを、プロトタイプMCU開発に適す使用例として示しました。



技術者と世界平和

2022年最後の投稿、つまり、週番号が追加されたMint 21.1 MATE Week 52の金曜投稿です。

Mint 21.1 MATEはカレンダに週番号が追加
Mint 21.1 MATEはカレンダに週番号が追加

ロシアのウクライナ侵略から始まった2022年は、世界平和と技術者の関連性を強く感じました。Rapidusなどの半導体新会社設立や、クリエイタ的エンジニア米中対立も根底には平和への危機感があると思います。

技術者の役割も、セキュリティやフィッシング詐欺など攻撃対策の比重が増すかもしれません。インターネットでさえ、グローバルオープンからブロック化の兆しが見えます。IoT MCUやMPU/CPU、Windowsなどの技術者開発基盤もまた、セキュリティがトリガになり発展しそうです。

個人的には、ケアレスミスの多い年でした。何らかの追加対策(?!)が必要と感じています。

さて、本年も本ブログ、および、弊社テンプレートをご利用頂きありがとうございました。
また、各位から頂いた様々なアドバイス、この場を借りてお礼申し上げます。ありがとうございました。

皆様、よいお年をお迎えください。



FSP利用FreeRTOSアプリ起動動作

ルネサスFSPの役目、RTOSアプリ起動動作
ルネサスFSPの役目、RTOSアプリ起動動作

前回FSP利用FreeRTOSアプリの作り方で、ルネサス公式サンプルコードを流用・活用した実践的RTOSアプリ開発方法を示しました。今回は、前回開発したアプリを使ってFSPの役目、RTOSアプリがどのように動作開始するかを説明します。

これからRTOS開発を始めるベアメタル開発経験者に役立つと思います。

前回のおさらい

FPB-RA6E1評価ボードのLED1点滅速度を、SW1プッシュ割込みで変える1スレッドのみを持つRTOSアプリの開発方法を、新規FreeRTOS Blinkyプロジェクトへ評価ボード実装済みベアメタルサンプルコードを移植することで説明したのが、前回のfreertos_blinkyプロジェクトでした。

※12月9日投稿時、FSP Importした割込みコントローラ初期化の記述を忘れていました。翌日10日に追記済みです。お詫びします<(_ _)>。

本稿の目的

ルネサスFSP(Flexible Software Package)は、ベアメタル、FreeRTOSとAzure RTOS、これら3者に対応した周辺回路API とMCU起動ファイルを自動生成するツールです。

※MCU起動ファイルは本稿ではstartup.c、main.c、ユーザファイルの3つを指します。

従って、初めてFSPを利用する時は、戸惑う部分もあります。例えば、ベアメタル開発には無関係のスレッドやオブジェクト設定エリアがあること、FreeRTOS開発時でもタスクではなくスレッドへ統一された説明やパラメタ設定があるなどです。

つまり、1つのFSPでベアメタル、FreeRTOS、Azure RTOSの3者に同時対応したため、FSPパラメタ設定や説明に解りにくい点があります。

※本稿も、FSPに習ってタスクではなくスレッドを用います。

また、当然ですが、ベアメタルとRTOSでは、FSP生成のMCU起動コードも異なります。何度か開発すれば、ベアメタルとRTOSでどこが違うかが判ります。しかし、初めからハッキリ区別した説明があるとFSPとRTOS理解が早くなります。

そこで本稿は、FSP生成MCU起動ファイルとベアメタル/RTOSユーザファイルまでの動作差を説明します。

FSP自動生成MCU起動ファイル(startup.cとmain.c)

startup.c:リセット後のMCU動作開始には、動作クロック設定やRAMゼロクリアなど、様々な前処理が必要です。これら前処理を行うのが、startup.cです。startup.cは、ベアメタル/RTOSともに同じ処理です。

main.c:ベアメタルでは、startup.c→main.c→user_main.cと処理が進みます。RTOSは、startup.c→main.cだけです。main.cの処理内容がベアメタルとRTOSで異なります(次章の図参)。

ベアメタルのmain.cは、実質のメイン関数であるuser_main.cへの橋渡しファイルで処理はありません。なぜ橋渡しファイルを使うかは、後で説明します。

RTOSのmain.cには、ユーザがFSP Configurationで追加したスレッドやオブジェクトの生成関数が、FSPにより自動追加されます。例えば、前回のfreertos_blinkyプロジェクトのmain.cなら、下線部分です。

freertos_blinkyプロジェクトのmain.cファイル
freertos_blinkyプロジェクトのmain.cファイル

FSP生成のmain.cは、スレッドやオブジェクトを生成し、最後に橙色で囲ったRTOSタスクスケジューラを起動してリターン(終了)します。

つまり、RTOSのmain.cは、「全てのRTOS処理を開始するための前処理、準備」を行います。

因みに、FSP生成startup.cやmain.cは、ユーザが勝手に変更を加えにくいようプロジェクトファイル階層の深い部分や、ユーザフォルダ:srcとは別フォルダ内にあります。

FSP生成ベアメタルまたはRTOSユーザファイル(user_main.cまたはuser_thread_entry.c)

ベアメタル(左)とRTOS(右)のユーザファイル:srcフォルダ内容
ベアメタル(左)とRTOS(右)のユーザファイル:srcフォルダ内容

逆にユーザファイルは、変更を加え易いよう最上位のユーザフォルダ:srcの中にFSPが生成します。ベアメタルならuser_main.c、RTOSならuser_thread_entry.cです。

ベアメタルでは、実質のメイン関数:user_main.cがmain.cから起動します。user_main.cは、周辺回路の初期設定と、無限ループの2構成から成るごく普通のメイン関数です(関連投稿:組込み開発 基本のキ 組込み処理)。

一方、RTOSは、main.c内でFSPが追加した生成関数user_thread_createによりuser_thread_entry.cが起動します。前章のfreertos_blinkyプロジェクトで示すと、blinky_thread_createとblinky_thread_entry.cです。

ユーザが複数スレッドを追加した場合は、各スレッドが下図のようにmain.c内で生成され、RTOSによる複数スレッド並列動作となります。

ルネサスFSP生成のベアメタル起動動作(右)とRTOSアプリ起動動作(左)
ルネサスFSP生成のベアメタル起動動作(右)とRTOSアプリ起動動作(左)

それぞれのスレッドは、優先度やセマフォなどのRTOSオブジェクトに従って、つまりRTOS環境で制御されます。

FSP利用のRTOS開発は、main.cまでがベアメタル動作、これ以降はRTOS動作環境になります。

ベアメタルのmain.cがuser_main.cへの橋渡しファイルなのは、右側のRTOS動作環境の形に無理やり(?)合わせたためだと思います。FSPは、Azure RTOS>FreeRTOS>ベアメタルの順位で設計されたからでしょう。

まとめ:FSP利用FreeRTOSアプリ起動動作

ユーザ設定のFSP Configurationを基にFSPは、周辺回路APIを生成し、同時に、MCU起動ファイル(startup.cとmain.c)とユーザファイルを分離して生成します。

FSP自動生成ファイルやAPIには、ユーザが手動変更しないようわざわざ下記注意コメントが先頭に付いています。

/* generated XYZ source file – do not edit */

また、FSP生成ユーザファイルにも下記コメントが付いています。

/* TODO: add your own code here */

これらFSPコメントに従って、ユーザがコメントの後へユーザコードを追加すればアプリが開発できます。ただ、開発にはFSPが生成するファイル内容や、FSPが想定しているベアメタル/RTOSアプリ動作の理解が必須です。

そこで本稿は、FPB-RA6E1 FreeRTOSアプリ(freertos_blinky)を使ってFSPが生成したMCU起動ファイルとRTOSユーザファイル動作を説明しました。

その結果、ベアメタルでは橋渡し役のmain.cが、RTOSでは全てのRTOS動作開始の前処理、準備を行うことを示しました。

ルネサスMCU開発は、FSP理解が鍵です。FSPが自動生成するベアメタルとRTOSユーザファイルまでの起動動作が判ると、FSP理解とベアメタル開発経験者のRTOS開発が容易になります。



FSP利用FreeRTOSアプリの作り方

ルネサスFSP(Flexible Software Package)とサンプルコード利用の「実践的FreeRTOSアプリの作り方」を示します。下記の最新開発環境を用いました。古い環境や別評価ボードでも同じ結果が得られると思います。

 全体流れ説明

先ず本FreeRTOSアプリ開発の全体の流れを説明します。というのは、組込み開発で良くあるサンプルコード付属説明:readme.txtとソースコード動作が不一致など、少々込み入った内容を含むからです。

  1. FPB-RA6E1購入時インストール済みサンプルコード:qiuckstart_fpb_ra6e1_epは、ベアメタルソフト。readme.txt記載のSW1プッシュでLED1/2点滅速度変化とは不一致。
  2. SW1プッシュでLED1/2点滅速度変化へFSP改造(1と2は、ベアメタル開発)。
  3. FPB-RA6E1で、新規LED1/2点滅FreeRTOSアプリ作成(3以降は、FreeRTOS開発)。
  4. 作成FreeRTOSアプリのLEDスレッドへ、2.のベアメタルのSW1プッシュLED1/2点滅速度変化改造FSPと、ソースコード移植。
  5. LED2は、FreeRTOSアプリエラー表示用とするため、点滅処理から削除。

本稿の背景

ベアメタル開発者は1と2、RTOS開発者は3以降が実行できれば、SW1プッシュでLED1点滅速度変更の1スレッドのみを持つFreeRTOSアプリを開発できます。

「実践的FreeRTOSアプリ開発」としたのは、0からアプリを開発するのではなく、豊富に提供される公式サンプルコードを流用・活用し、所望アプリを早く効果的に開発する例を示したかったからです。

RTOSのメリットを説明した資料は多く見かけます。しかし、具体的なRTOSアプリ開発方法を示す資料が少ないことも背景にあります。

以下、1~5の説明を加えます。細かい説明は後回しにし、まとめ章を先に読むとより全体が解り易いと思います。従って、まとめ章を先に記述します。また、最後の章に、RTOS開発の基盤となるRAベアメタルテンプレート宣伝(?)もあります。

まとめ:実践的RTOSアプリ開発方法

評価ボード実装済みLED1とSW1は、いわば開発アプリ正常動作中を示すインジケータです。開発したFreeRTOSアプリをテンプレートとし、所望機能のスレッドを追加していけば、最終的に様々なFreeRTOSアプリを早期に開発できます。

FreeRTOSをRAファミリFSP利用例としましたが、Azure RTOSでも同様です。

つまり、本稿のアプリは、RTOSテンプレート骨格で説明した内容を、より具体化したものです。

もちろん複数スレッド追加時は、スレッド優先度やスレッド間制御(セマフォ/キュー/ミューティックスなど)の検討も必要になります。これらは、追加スレッドがほぼ完成した後の検討項目です。

先ずは、必要な個々のスレッドを単体・単独で開発し、その後、複数スレッド結合へと段階的に進める方法がRTOS開発には適していると考えます(関連投稿:FreeRTOS/Azure RTOSソフトウェア開発手法)。

複数スレッドの検討方法は、文章量が増えるため割愛しました。別途改めて、投稿する予定です。

1:qiuckstart_fpb_ra6e1_ep動作とreadme.txt

サンプルコードzip内のqiuckstart_fpb_ra6e1_ep
サンプルコードzip内のqiuckstart_fpb_ra6e1_ep

評価ボードに初めからインストール済みのサンプルコードが、quickstart_fpb_ra6e1_epです。zip内に収められています。e2 studioは、zip内にあるサンプルコード説明書:readme.txtをIDE内にインポートしません。

Tips:zip解凍後のreadme.txtを、サンプルコードプロジェクト内へ手動でコピーしておくと、いろいろ便利。
Tips:quickstart _fpb_ra6e1_epのfpb_ra6e1が評価ボード名、epはexample projectの略。別評価ボード利用時は、fpb_ra6e1部分が異なる。

quickstart_fpb_ra6e1_epのreadme.txtが下記です。

quickstart動作とreadme.txtの不一致箇所
quickstart動作とreadme.txtの不一致箇所

下線部:評価ボードSW1でユーザLED1/2点滅制御とありますが、この動作はFPB-RA6E1にはありません。しかし、quickstart_fpb_ra6e1_epソースコードには、SW1割込み処理:callback_irq1ds_buttonでLED1/2点滅delay変更処理が記述済みです。

これは、RAファミリのソースコードがHAL(Hardware Abstraction Layer)記述で、MCUが変わっても同じソースコードを使えるからです。別評価ボードのソースコードとreadme.txtを、そのままFPB-RA6E1へコピー流用している訳です。

組込み開発ではMCUの種類が多いため、このように既存資産をコピーして当該MCUコードや資料を作ることは良くあります。その結果、今回のようにreadme記述内容とサンプルコード動作が不一致なことも多々あります。

Tips:逆に上記は、MCUソフトウェア開発の本質が「サンプルコードやFSPなどの既存資産を上手くコピー活用すること」を示しているとも言えます!

2:SW1プッシュ割込みでLED1/2点滅速度変化へFSP改造

readme.txt記述とサンプルコード動作不一致の原因が、FSPです。

そのままコピーできるreadmeやサンプルコードと異なり、FSPは、当該MCU毎に設定が必要です。不一致の原因は、FPB-RA6E1のFSP設定にミス(忘れ)があるからです。

動作一致のためには、外部割込みコントローラ(External IRQ)とFPB-RA6E1のSW1(P205)の接続が必要です。下記のようにP205ピン設定を変更後、Generate Project Contentをクリックします。

quickstart_fpb_ra6e1_epを再ビルドし、評価ボードへダウンロードすれば、readme内容と同じSW1プッシュでLED1/2点滅速度が変わります。

外部割込みコントローラ(External IRQ)とS1(P205)を接続するピン設定
外部割込みコントローラ(External IRQ)とS1(P205)を接続するピン設定

3:LED1/2点滅新規FreeRTOSアプリ作成

新規FreeRTOSアプリ作成は、ベアメタルアプリ作成と同じ方法です。そこで、本稿は、ベアメタル作成との差分のみを示します。

LED点滅の新規FreeRTOSアプリ作成(ベアメタル作成との差分)
LED点滅の新規FreeRTOSアプリ作成(ベアメタル作成との差分)

新規作成FreeRTOSプロジェクト名は、freertos_blinkyとでもしてください。FSP Summaryが下記です。

FSP Summary
FSP Summary

このfreertos_blinkyを評価ボードへダウンロードすると、LED1/2が1秒毎に点滅します。生成したLEDスレッド:blinky_thread_entry.cのvTaskDelay(configTICK_RATE_HZ)が、1秒点滅の仕組みです。

4:LEDスレッドへ、2:SW1プッシュLED1/2点滅速度変化改造FSP移植

2:で改造したSW1割込みでLED1/2点滅速度を変える機能を、3の新規FreeRTOSアプリへ移植します。

freertos_blinkyのFSP Stacksタブを選び、画面上で左クリックしImportを選択します。From fileにquickstart_fpb_ra6e1_epを選び、configuration.xmlを開きます。Stack ImportでExternal IRQを選ぶとquickstart_fpb_ra6e1_epの割込みコントローラ設定がfreertos_blinkyへ移植できます。

Tips:移植するFSPスタック数が多い時は、Import機能が便利。

FSP Import
FSP Import

しかし、割込みコントローラとSW1(P205)間の接続はImportできません。そこで、1:と同様にP205ピン設定を割込みコントローラと接続し、Generate Project ContentクリックでFSP移植は完了です。

Tips:FSP Importは簡単便利だが、上記のように同一MCUであっても、ピン設定はImportされない。また、ピン設定が無くてもエラー表示もない。代替方法に、New Stackクリックでスタック群から追加機能を選ぶ方が、ピン設定忘れが少ないかもしれない。

次に、SW1割込み処理:callback_irq1ds_buttonを移植します。

callback_irq1ds_button処理は、e2studioのDeveloper Assistanceを開き、callback_function_definitionをクリックし、blinky_thread_entryの後へペーストで追記します。今回は、TODO:add your own code hereコメント後へ、quickstart_fpb_ra6e1_epのSW1割込み処理をコピー&ペーストし移植します。

コピー後エラーが表示される箇所は、全て定数未定義部分ですので、quickstart_fpb_ra6e1_ep定数部分もコピー&ペーストします。

Tips:e2 studioは、デフォルトではソースコード変更後、このように即コンパイルエラーを表示。

最後に、vTaskDelay(configTICK_RATE_HZ)のconfigTICK_RATE_HZ を、割込み処理で作成したg_delayへ変更します。

以上で、割込み処理の移植完了です。ビルドし、SW1でLED1/2点滅速度が変わることが確認できます。

SW1割込み処理:callback_irq1ds_buttonの移植
SW1割込み処理:callback_irq1ds_buttonの移植

12月10日追記:FSP Importした割込みコントローラ初期化の移植記述を忘れていました。追記します。

Importした割込みコントローラの初期化:icu_initializeも、下図のようにblinky_thread_entry.cへ移植します。

割込みコントローラの初期化処理の移植
割込みコントローラの初期化処理の移植

5:LED2点滅処理削除

LED2は、FreeRTOSアプリのエラー表示に使います。例えば、追加したスレッド初期設定に失敗した時のインジケータなどです。そこで、下記のようにLED2をLEDスレッドの点滅処理から外します。

LED2点滅処理削除
LED2点滅処理削除

以上で、SW1プッシュでLED1点滅速度変更の1スレッドのみを持つFreeRTOSアプリ完成です。

このFreeRTOSアプリへRTOSテンプレート骨格で投稿した7メニュー形式表示、LED2エラー表示などの機能を更に追加しFreeRTOSテンプレートとします。

FreeRTOSテンプレートは、全てのFreeRTOSアプリ開発の出発点となり、所望スレッド機能を追加していけば、効率的に様々なRTOSアプリ開発が可能です。

Tips:本稿はFreeRTOSテンプレート開発方法に重点を置き投稿。実FreeRTOSテンプレートは、もっと解り易い構造とソースコードで提供。

RTOS開発はベアメタル開発スキル必須

前章1~5から「RTOS開発には、ベアメタル開発スキルが必須」であることがお解り頂けたと思います。

組込み開発は、説明不足の事柄が非常に多いです。また、サンプルソフトとreadme.txtなどの説明不一致も多々あります。説明対象を初心者/中級者の誰にするか、どこまで説明するか、などなど読者を絞り難いこと、説明側にとっては、自明の理の内容が多いことがその理由です。

本稿で追記したTipsや背景となる技術スキルが無いと効率的に先へ進めないと思います。ベアメタルを補う目的のRTOS開発ではなおさらです。

RAファミリで、FSP利用の効率的なベアメタル開発スキルを身に付けるには、弊社RAベアメタルテンプレートがお勧めです。ソースコードに豊富な日本語コメントを付加し、付属説明資料にはTipsやFSPノウハウなども記載しています。RAベアメタルテンプレート説明サイトは、コチラをご覧ください。

ルネサス以外のベアメタル用テンプレートも多数ご用意しております。また、NXPのFreeRTOSアプリケーションテンプレートも販売中です。



次世代ネットワークIOWN(アイオン)

What's IWON(出展:NTTサイト)
What’s IOWN(出展:NTTサイト)

IOWN(Innovative Optical and Wireless Network)は、2030年実現を目指すNTTの次世代ネットワークです。

IOWN技術

大容量、低遅延の光伝送路。ネットワーク遅延や揺らぎ無し。データドリブン将来社会のデータ量や消費電力増加を解決。キーテクノロジが「光電融合デバイス」、などなど実現技術に興味がある方は、コチラの記事で解ります。

IOWNサービス

IOWNが提供するサービスの一例が、コチラの遠隔医療記事です。IOWNは、ネットワーク本来の目的、離れた場所との距離を感じさせない通信を提供します。

既存ネットワークで遅延や揺らぎが生じるのは、電気信号と光信号の変換回数が多いためです。電気に比べ減衰が少ない光伝送と、光と電気を融合した光電融合デバイス、これらにより電気と光の変換回数を減らし、IOWNのオールフォトニックス・ネットワーク(APN)を実現します。

APNは、低消費電力で大容量、高品質、低遅延で揺らぎの無い理想的な伝送サービスを提供します。

さらに、WirelessのIOWNは、宇宙空間や海中でも接続します。低軌道人工衛星を用いた宇宙RAN(Radio Access Network)や、地上IoT端末と衛星を接続する宇宙センシング、さらに、海中での高速無線通信による水中ドローンなども2030年頃のIOWN 4.0で可能になります。

早くもAMDは、宇宙空間でAI処理ができる宇宙グレードSoCの信頼性評価を完了しました。

宇宙統合コンピューティング・ネットワーク(出展:SKY Perfect JSATサイト)
宇宙統合コンピューティング・ネットワーク(出展:SKY Perfect JSATサイト)

TRONプロジェクトリーダ:坂村健氏も注目

2022年11月25日の記事では、TRONプロジェクトリーダ:坂村健氏が、多くのIoTセンサを組込んだスマートホームなどのICTインフラに、電力効率100倍、伝送容量125倍、レイテンシ200分の1のIOWNが大きなインパクトを与えると語ったことが記載されています。

スマートホームでこれほど高速、大容量の公衆ネットワークが安価に使えると、個人のPCストレージは、もはや全てクラウド上に置くことも可能な気もします。

IWON特徴(出展:NTTサイト)
IOWN特徴(出展:NTTサイト)

IOWNと2030年

2030年まであと8年。リモートワークや移動時、遠距離でも低電力、大容量、低遅延、遅延揺らぎ無しの通信ニーズは、今後益々高まります。

IOWNが、これらニーズを満たし現状ネットワークの様々なボトルネックを解消した新たなサービスの実現、開発インフラになりそうです。IoT MCU開発者もまた、IOWNと2030年に向けた進化が必要です。

関連投稿:2030年のエンジニア



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テンプレート骨格クリエイタ的エンジニア

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



64ビットMCU得失

RZファミリ位置付け(出展:ルネサスサイト)
RZファミリ位置付け(出展:ルネサスサイト)

今年春の3月2日、ルネサスが64ビットRISC-Vコア搭載の汎用MPU:RZ-Fiveを発表しました(!=MCU)。

本稿は、RISC-Vの簡単な紹介と、MCUの64ビット化得失についてまとめました。

RISC-V

リスク ファイブ(RISC-V)は、2010年にカルフォルニア大学バークレイ校(2022年世界大学ランキング第4位)で開始されたプロジェクト。オープン標準命令セットアーキテクチャ(ISA)でオープンソースライセンス。使用料無料。用途に応じた32/64/128ビット対応アーキテクチャで、RISC-Vチップや派生成果物の作成も許可。(Wikipediaより)。

Cortex-M代替として急浮上のRISC-V
Cortex-M代替として急浮上のRISC-V

ルネサスなどのMPU/MCUチップ製造側にとっては、ARMコアベースに比べ、ライセンス料が無く競合他社差別化や独自性も出し易いのがRISC-Vコアと言えそうです。※RZファミリには、ARMコア(Cortex-A55とCortex-M33ディアルコア)のRZ/G2ULもあるため、ArmベースMPUが最初の右グラフに記載。

日経xTECH記事(2022-09-13)によると、ルネサス以外にも、既に多くのRISC-V利用MPUや32ビットMCUが発表されています。RISC-V CPU搭載ノートPCも販売中です。

関連投稿:Cortex-MとRISC-V1GHz 64ビットMPUのRZ/A3UL

IoT MCU要件

CPUやMPUは、64ビット化が進んでいます。Windows 11は、32ビット対応版がありません。また、ルネサスRZ-Five同様、NXPやSTマイクロでもMPUは全て64ビットです。

これは、CPU/MPUに要求されるセキュリティ機能や性能を満たすには、先行するサーバやデータセンタで開発したソフトウェア資産の移植が、64ビットの方が容易だからです。

一方、MCUは、性能・機能の向上と消費電力増加のバランスが、MPUに比べ重視されます。MCU設置個数は、MPUよりも桁違いに多いため既存MCU資産を活かすバイアスが働くためです。最初の右側グラフで、16ビットRL78が低消費電力の代表として表示されていることからも解ります。

このバランスのため現状のIoT MCU主流は、32ビットMCUです。

しかし、MCU製造プロセス改良や、電力供給の世界情勢、自動車ADASと半導体供給状況などにより、IoTセキュリティ機能への要求や、低消費電力への要求バランスは大きく変わる可能性もあります。場合よっては、CPU/MPU同様、64ビットMCUがIoTに適すかもしれません。

アクティブ消費電力とスリープ消費電力両方を減らせるSOTBプロセス(出典:ルネサスサイト)
アクティブ消費電力とスリープ消費電力両方を減らせるSOTBプロセス(出典:ルネサスサイト)

関連投稿:ルネサスのMCU新製造プロセス SOTB

また、IoT必須のRTOSをMCUへ適用する場合には、32ビットカウンタでは、タイマー満了周期が短い問題も指摘されています。

結論:64ビットMCU見通し

既存MCU資産(特にソフトウェア)をそのまま活かしMCU性能を上げるには、同一コア高速化が適します。一方、サーバやデータセンタのセキュリティ機能移植を考えると、64ビットMCUも有力です。また、IoT MCUのRTOS開発時は、32ビットカウンタの短さに注意が必要かもしれません。

ビット幅を意識することは、Cなどの高級言語でMCU開発する限り稀です。しかし、RTOS開発時や更なる性能・機能向上(例えばエッジAI)、効率的セキュリティ導入を求める時は、32ビットMCU限界が現れることもあり得ます。

アーキテクチャ変更で得るものと失うものバランス、トータル開発コスト、これらが次世代IoT MCUを決めます。今後主流のIoT MCUが32/64ビットいずれになるかは、流動的です。だからこそ、最新IoT MCUやMPU、RISC-V動向を注意深く観察する必要があるというのが結論です。