MCU：マイコンアーカイブ - 5ページ目 (59ページ中)

HALとMCUソフトウェア開発

2023年9月8日2023年9月12日 WithHappy

HAL：Hardware Abstraction Layer APIを使えば「MCUデバイスに依存しないソフトウェア開発」ができる。そこで、汎用MCUでプロトタイプソフトウェアを作り製品MCUを選択。これが、前投稿でした。
主題は、製品MCU選択方法です。

今回は、この方法の基になる「MCUデバイスに依存しないソフトウェア開発ができる」部分を、もっと具体的に説明します。

MCUソフトウェア開発の鍵HAL API

前投稿最後に示したSTM32デバイスとユーザアプリケーション移植性の両方を満たすHALスタック図を具体化します。

弊社STマイクロ関連テンプレートに採用したSTM32F0/F1/G0/G4デバイスとNucleo評価ボード、一般的なベアメタルソフトウェア開発を想定し作り直したHALスタック図が、下図です。UtilityやMiddlewareは使いませんので空白にしています。

User ApplicationとHAL間は、HALドライバを用います。例として、GPIO接続のLEDをトグル出力するHAL API関数：HAL_GPIO_TogglePin(LED_GPIO_Port, LED_Pin)で説明します。

HAL_GPIO_TogglePin(LED_GPIO_Port, LED_Pin)

STマイクロのHALドライバは、接頭語に必ずHAL_が付きます。ソース上も判別し易いです。

HAL_GPIO_TogglePin(xPort, yPin)は、MCU Port名xのPin番号yを使うGPIOに対して、トグル（HighからLow、またはLowからHigh）出力するドライバ関数です。

例えば、STM32G0評価ボード：Nucleo-G071RB実装ユーザLED：LD4は、PA5接続です。トグル出力は下記です。

HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_5) //物理GPIOポートＡ、5番ピンをトグル出力

STM32G4評価ボード：Nucleo-G474RE実装済みユーザLED：LD2も、同じくPA5接続ですので、全く同じHALソフトウェア記述で、ユーザLD2のトグル出力ができます。

Nucleo評価ボードBSP

Nucleo-G071RBとNucleo-G474REは、どちらも64ピンMCUパッケージで、たまたま同じ物理記述ポート名とピン番号が、ユーザLEDに接続済みでした。

しかし、一般的には開発MCUや評価ボードで異なるポートとピンへユーザLEDが接続されます。

そこで、物理記述GPIOAやGPIO_PIN_5と、評価ボードの論理記述LD2やLD4を結び付けるのが、BSP：Board Support Packageです。この結び付けにより、異なる物理記述ポート、ピン番であっても、同じ論理記述のDemonstrationやUser ApplicationでLEDを動作させることが可能になります。

具体例で示すとNucleo-G071RBのBSPは、STM32CubeIDEのmain.hに展開され、LD4関連は下記です。

#define LD4_GPIO_Port GPIOA //LD4_GPIO_Portを物理GPIOポートAと定義
#define LD4_Pin GPIO_PIN_5 //LD4_Pinを物理5番ピンと定義

Nucleo-G474REのBSPは、LD2関連main.hが下記です。

#define LD2_GPIO_Port GPIOA // LD2_GPIO_Portを物理GPIOポートAと定義
#define LD2_Pin GPIO_PIN_5 // LD2_Pinを物理5番ピンと定義

LD2とLD4の部分が異なります。BPSは、評価ボードのハードウェア毎に異なります。

各評価ボードのソースコードを読む時は、LD2やLD4と論理記述した方が、物理記述のGPIOAやGPIO_PIN_5よりも判り易いため、これらdefine文を使います。

評価ボード非依存ソフトウェアテクニック

評価ボード単位のソースコードを読む時は、実装中のLD2やLD4と論理記述した方が判り易いです。

では、様々な評価ボードで共通に動作するUser Applicationを開発する場合は、どうすれば良いのでしょうか？

答えは簡単です。論理記述をLD2やLD4から、より上位の論理記述へ結び付ければOKです。例えば、下記です。

#define BOARD_LED_PORT LD4_GPIO_Port //BOARD_LED_PORTをLD4_GPIO_Portと定義
#define BOARD_LED_PIN LD4_Pin //BOARD_LED_PINをLD4_Pinと定義

このように評価ボード単位のdefine文を、上位実装LEDや論理ピンへ再定義すれば評価ボード非依存のソフトウェアが開発できます。

define文は、開発者が、ソースコードを読み易くするための機能です。define文で再定義しても、コンパイル時に最終物理対象（GPIOAやGPIO_PIN_5）に置き換わるため、処理速度が遅くなるような弊害はありません。

STM32Cube MCU Packages Manager

さて、HALスタック図では1個のHALも、実はMCU毎に異なります。

このMCU毎に異なるHALを、STM32CubeIDEへ実装するツールが、STM32Cube MCU Packages Managerです。

MCU毎に異なるFirmware(HAL)をSTM32CubeIDEへ実装するSTM32Cube MCU Package Maneger

STM32Cube MCU Packages Managerは、プロジェクトのハードウェア設定ファイル（icoファイル）を開いた状態で、Help>Manage Embedded Software Packagesで表示できます。上図は、STM32C0/F0/F1/G0/G4のPackage部分を抜粋しています。

このSTM32Cube MCU Packages Managerで、最新のFirmware Packageを開発に使うか、それとも、古いFirmware Packageを使うかが選択できます。上図は、STM32G0ソフトウェア開発に最新Firmware V1.6.1を開発に使うことを選択中の例です。

Firmware Package版数の訳

このMCU Firmware Packageが、HALの実体です。

例えば、STM32G0 Firmware V1.6.1は、旧Firmware V1.6.0と上位のUser Applicationに対しては同じHAL APIを提供しますが、その実体は、旧HALのバグ修正や販売中のSTM32G0 MCUに応じて中身が変わります。

つまり、このFirmware Packageが、MCU差や過去のHAL版に依存しないHAL APIを、User Applicationへ提供する仕組みそのものです。

MCU発売後、経過時間が長くなると、同一MCUでも多くのFirmware Package版が選択可能になります。

お勧めは、最新Firmwareです。

複数のFirmware版が存在する理由は、STマイクロがMCU供給を最低10年保証しているためです。新MCUパッケージ追加発売時は、新しいFirmware版で対応します。簡単に言うと、MCU開発履歴が版数に現れる訳です。

つまり、開発者が、顧客提供時Firmwareをそのまま継続開発に使いたい場合には、最新版だけでなく過去のFirmwareも選択肢になる訳です。

実際の選択は、icoファイルのProject Managerタブの一番下、Firmware Package Name and Versionで設定します。

Summary：HAL APIソフトウェア開発

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

MCUソフトウェアは、HAL APIを使うとMCUに依存しない移植性の高いUser Applicationソフトウェアの開発ができることを説明しました。

User ApplicationとHAL API間のハードウェア依存性を無くす手段として、評価ボード毎に異なるBSPや、MCU毎に異なるMCU Firmware Package（HAL）を用います。

汎用MCUを使ったHAL APIプロトタイプ開発ソフトウェアは、MCU変更に対して移植性が高いため、User Applicationソフトウェアの資産化も期待できます。

Afterword：MCU説明の難しさ

本稿の内容は、中級以上のMCU開発者にとっては、自明の理です。しかし、この自明の理を説明するのは、結構大変です。本稿も、説明不足の箇所が多々あります。

MCU開発では、この自明の理の部分が多いため、開発者レベルを上げる障壁は高くなります。例えて言うと、スマホが初めての方に、その取扱い方法を文書だけで説明するようなものです。

本稿は、STマイクロのHALを例に説明しました。これは、現在MCU毎に販売中の弊社STM32F0/F1/G0/G4テンプレートを、MCU共通のSTM32MCUテンプレートへ発展させる布石でもあります。

本稿内容が、すんなり判る開発者には、STM32共通MCUテンプレートは、多分不要（ご自分で開発できる）ですし、判らない方には、STM32共通テンプレートよりも個別STM32F0/F1/G0/G4テンプレートの方が使い易いと思っています。

今回のような長文は、筆者の苦手な分野です。が、時々は挑戦すべきと考えております。ご質問や判り難い箇所のご指摘も大歓迎です。読者の方々からのレスポンス、お待ちしております。

ソフトウェア視点のMCU選び方

2023年9月1日2023年9月1日 WithHappy

MCU選び方をソフトウェア開発視点から示します。
具体例としてSTマイクロのSTM32MCUで説明しますが、他MCUベンダでも同様です。

Summary：HALドライバ＋汎用MCUプロトタイプ開発で選定

例え同じベンダでも色々な内蔵ハードウェアと、処理性能、価格も異なるMCUは、製品MCUの選択肢が広すぎるのが難点です。

製品MCUハードウェア選定ミスを少なくし、かつ、ソフトウェア開発も効率的にできる方法として、汎用MCUを使いHALドライバで早期に製品プロトタイプ開発を行い評価する方法を示しました。

製品MCU選択肢の広さ

ベンダ例としてSTマイクロのCortex-Mコア系MCU選択肢の広さを示します。

STM32MCUポートフォリオを性能やシリーズ別に示したのが上図です。この図でターゲット製品のMCUシリーズを大まかに選定するのが、第1選定段階です。

第2段階では、各シリーズのFlash/RAM容量、内蔵ADCやUASRT数など製品時に必要になる周辺回路からハードウェア的に最適なMCUデバイスを選定します。

この選択方法は、MCU処理性能やソフトウェアを格納するFlashやRAM容量は、最終製品にならないと実際は判りません。しかし、周辺回路や動作電圧などのハードウェア条件は、明らかなのでこれらからMCU選定はできます。

但し、メインストリーム、つまり汎用MCUであっても、STM32C0、STM32F0/F1、STM32G0/G4シリーズと選択肢があり、処理性能も異なります。更に、ハイパフォーマンスSTM32H5/H7や、超低消費電力STM32U5などの汎用MCU比性能を極めたシリーズもあります。

これら多く広いMCU選択肢から、入手性やコストから製品MCUを決めるのが、一般的に用いられる「ハードウェア視点MCU選択方法」です。

HALドライバソフトウェア開発メリット

HALとは、Hardware Abstraction Layerドライバです。このハードウェアは、MCUを指します。つまり、MCU差を抽象化＝隠して開発できるAPIを上位ユーザアプリケーションへ提供するのがHALです。

例えば、STM32C0でも、STM32G4でも同じHALドライバでGPIOアクセスができます。つまり、HALドライバを利用すれば、STM32C0とSTM32G4で同じアプリケーションが使える訳です。

従って、STM32C0で性能不足の場合には、開発ソフトウェアはそのままSTM32G4へ移植ができます。逆の性能過多の場合でも同様です。ユーザ開発アプリケーションのMCU間移植性が高いのがHAL利用ソフトウェアのメリットです。

HAL＋汎用MCUプロトタイプ開発

汎用MCUを使って製品のプロトタイプ開発を行えば、製品化時、よりハイパフォーマンスMCUの必要性や、より低消費電力MCUの必要性が、使用した汎用MCUとの相対比較で可能です。

また、HALを使えば、プロトタイプ開発アプリケーションが製品MCU上でも動作します。

つまり、製品MCUのオーバー/アンダースペック選定ミスを減らす評価ができ、かつ、プロトタイプ開発アプリケーションの製品移植性も高いため、結果として効率的な製品開発が可能になるのが、「ソフトウェア視点MCU選択方法」です。

拡大MCUハードウェアとMCUソフトウェア移植性を満たすHAL

MCUベンダは、最初の図で示したように進化する半導体製造プロセスやよりアプリケーション寄りのコストパフォーマンス最適MCUデバイスを提供し続けます。

MCU製品開発側は、増え続けるMCUデバイス間のソフトウェア移植性や開発時間の短縮も必要です。

HALドライバは、これら進化・拡大するMCUハードウェアとMCUソフトウェア移植性要求を同時に満たす機能です。

HALによる汎用MCUプロトタイプ開発は、参考になるサンプルコードが多いため開発時間も少なく、開発アプリケーションがユーザ資産として多くのMCUでの活用も期待できます。

Afterword：汎用MCU選び方

汎用MCUも多くの選択肢があります。STマイクロのお勧めデバイスは、最新製造プロセスで入手性が良く低価格なSTM32G0/4シリーズ評価ボードです。

Flash/RAM容量も入手性優先で選定して構いません。容量不足時は、機能分割しプロトタイプ化すれば済むからです。

ソフトウェア視点MCU選択方法は、プロトタイプ開発が必要です。短期間で効率的に製品プロトタイプを仕上げ、このプロトタイプから製品MCU要求条件やソフトウェア動作ポイントなどを評価します。

プロトタイプと最終製品が近ければ近い程、これら評価精度は上がります。しかし、精度に拘る必要はありません。製品企画時に、とにかく製品のように動くプロトタイプを早く仕上げ、これから製品MCUを評価すれば、闇雲に選定するより良いからです。

MCU開発者は、手元にベンダ汎用MCUシリーズの評価ボードと弊社テンプレートがあれば、直ぐに製品のように動くプロトタイプが仕上がります。

パスワードとパスキー

2023年8月25日 WithHappy

最新Chrome 116は、パスワードマネジャーデザインが新しくなり、パスワードの保存と入力が容易になりました。そこで本稿では、「パスワード」と最近話題の「パスキー」の筆者現状理解を示します。

参考資料：
1. パスワードのない世界へのマイルストーン「パスキー」、2023年6月14日

2. AppleやGoogleが対応を進める「パスキー」とは、2023年8月7日

とにかくセキュリティ関連記事は、判り難いのでポイントを簡単にまとめました。

パスワード問題

どんなに複雑なパスワードでも、それを入力したのがユーザ本人かが確認できないこと、パスワードそのものがネットワーク上に流れ第3者が盗み見ることができること、この2点がパスワード問題。

パスキー解決策

パスワード問題解決のため、指紋認証などの本人確認機能を持つ端末（PC/スマホ）のログインにパスキーを使う。パスキーで本人認証後、ネットワークログイン時に送受する情報は、端末での本人認証結果と高度に暗号化された情報。これらは、第3者が盗み見ても本人成り済ましは不可能（に近い）。

パスキーは端末間の移行・同期可能

スマホ紛失やPC買換え時の利便性向上のため、アカウント名などのユーザ情報（クレデンシャル情報）をクラウドアカウントに紐づけることによりパスキー端末間同期が可能。現状対応クラウドは、Apple、Google、Microsoft。

クラウド利用により移行利便性も兼ね備えたパスキーは、パスワードに代わるログイン方法として有力。

パスキー運用ChatGPT回答

パスキー運用に関してEdgeのChatGPT（Bingチャット）でQ&Aを得ました。

Q1）パスキーを間違えたら？
A1）パスキーは、入力回数に制限あり。一定時間経過後、再入力可能。パスキーを忘れた時は、端末リセット必要。

Q2）複数端末で同じパスキーは使える？
A2）複数端末間で同じパスキーを使える。

Q3）パスキーを間違えてリセットした時の複数端末の影響？
A3）リセットは、その端末のみ。他の端末は影響なし。

つまり、複雑なパスワードの代りに、4桁または6桁のパスキーさえ覚えておけば、同じパスキーを複数端末で使ってもログインセキュリティは安心のようです。

Summary：パスワードからパスキーへ

例えパスワードマネジャーが使い易くなっても、パスワード自体の問題（本人未検証）解決にはなりません。

パスキーと本人認証端末、クラウドアカウントを組み合わせたパスキーログイン方式（本人検証結果＋所持情報）は、パスワードレスアクセスとして期待できそうです。

Afterword：知識情報は4/6桁が限界?

パスキーが4/6桁なのは、指紋/顔認証などの本人検証が失敗した時の代替入力のためと思います。PC/スマホログインに指紋/顔認証が「先」で、認証失敗時にパスキー入力を「代り」に求めるからです。
スマホは、認証成功時でも定期的にパスキー入力を求め、パスキー知識情報を忘れないよう保全します。

個人が無理せず覚えられる数字は、この桁位でしょうか?　IoT MCUデバイスなら桁数をもっと増やし、セキュリティレベルを上げることもできます。

パスキーの仕組みは、指紋/顔など変えようがない超重要認証データは端末のみに保存し、ネットワークログインは認証結果など漏れても支障が少ない情報で行うことでセキュリティを高く保つ、と筆者は理解しています。

但し、ネットワークログインは、当面使い慣れたパスワードも併用するでしょう。Chrome 116のパスワードマネジャーで、パスワード自体を強固にすることも必要です。

サイト多言語化完了

2023年8月18日2023年8月18日 WithHappy

弊社WordPressサイト多言語化が完了しました。

Summary：弊社Change

多言語化Changeの副作用として様々なトラブルに会いました。ブログ読者関連は、収束したと思いますので、完了宣言致します。関連投稿：Change before you have to、サイト多言語化

多言語（英語）版のMCUテンプレートは、ルネサス）RA6/4/2ベアメタルテンプレート、STマイクロ）STM32G0xテンプレート、STM32F0/F1テンプレートの現行3種です。今後、増やしていく予定です。

Changeで得たもの

Change作用は、ベアメタルテンプレートのポイントが「時分割起動」ということを再認識した点です。

また、HAL（Hardware Abstraction Layer） APIを使うと、MCUファミリ/シリーズに依存しないベアメタルテンプレートになる点です。

もちろん、ベンダが異なるとHAL APIも異なります。しかし、同じベンダのMCUならベアメタルテンプレートは基本的に同じです。STM32G0テンプレートとSTM32F0/F1テンプレートは、シリーズが異なりますが、同じHAL APIを利用するので、同じベアメタルテンプレートになります。

つまり、ユーザがHAL APIを利用するなら、MCUファミリ/シリーズで同一のベアメタルテンプレートを弊社は提供できる訳です。このことは、近く検証する予定です。

RTOSテンプレート

同様にRTOSテンプレートは、「マルチタスク（スレッド）起動」がポイントと考えます。

起動後のタスク間同期や通信に、セマフォやメッセージボックスなど様々な手段があります。しかし、弊社がRTOSテンプレート基本がタスク起動と考えると、FreeRTOS/Azure RTOS/μT-Kerneでも同じ構成でスッキリします。この方向で、RTOSテンプレートは再構築したいと考えています。

また、クラウド接続やセキュリティなどの処理以外でRTOS MCU開発者が自由に開発できるタスク数は、高々7位だと思います。タスク数が多いと、タスク流用は容易になりますが、タスク分割損（＝RTOSオーバーヘッド）も増えます。

MCUクラスの処理能力からすると、ラッキーセブンが分割タスク数として適す気がします。

7タスク優先順位を設定し起動すれば、RTOSテンプレートとして使えると考えています。これもいずれ検証します。

Afterword：Changeは痛みが伴う

当初WordPress多言語化は、8月11日から13日の3日間を予定していました。しかし、様々なトラブルが発生し、その結果、1週間を要しました。酷暑下での作業でしたが、お盆連休中であったのが不幸中の幸いでした。

MCUテンプレート海外販売開始

2023年8月11日 WithHappy

MCUテンプレート海外販売に向けWordPressサイト多言語化を行ってきました。本日より下記MCUテンプレートの海外販売を始めます。

RA BeaeMetal、STM32G0x、STM32F0/F1、3種MCUテンプレート販売開始

既存日本語テンプレート10種のうち、第一弾は、ルネサス）RA6/4/2ベアメタルテンプレート、STマイクロ）STM32G0xテンプレート、STM32F0/F1テンプレート3種のテンプレート資料を英語化し販売します。

多言語対応ページの使い方

ブログトップを示すHomeから③テンプレート購入手順は、多言語対応済みページです。従って、サイト右上のプルダウンメニューから、お好きな言語を選べば、日本語表示から選択言語へ変換されます。

①Template list掲載の3種テンプレート説明資料の冒頭3ページは、無料ダウンロード可能です。

テンプレート利点やTipsなどは、②Template Benefits & Tipsに、Template購入方法は、③Template purchase procedureをご覧ください。

お好きな言語でテンプレート概要やメリットなどをご覧になり、MCUテンプレートのご購入を検討頂ければ幸いです。

日本語テンプレート販売は従来通り

日本語MCUテンプレート10種は、従来と同じMCUテンプレートサイトから販売中です。

第一弾の多言語MCUテンプレート3種以外をご要望の方は、日本語MCUテンプレートサイトからもご購入が可能です。

但し、テンプレート説明資料は、全て日本語表記です。ご購入後、Google翻訳などを使ってご自分で翻訳してください。なお、テンプレートソースコード内の冗長な日本語コメントは、コンパイル時に全て削除されますので、制御には無関係です。

Google翻訳の感想

Google翻訳は、便利なツールです。しかし、日本語からの英語翻訳時、英単語間に余分なスペースが挿入されます。例えば、「これはペンです。」をGoogle翻訳すると、「This__is__a__pen.」となります。

この英単語間の2スペースは、Wordなどの置換ツールを使って通常の1スペースへ一括変換できます。しかし、余分なスペースがなぜ挿入されるのかが不明です。理由がお解りの方は、弊社に教えてください。

Afterword：テンプレート役割

テンプレート付属資料の英語化は、手間が掛かりました。ただ、第一弾英語化を期に、3種説明内容を横断的に見直す良い機会にもなりました。

その結果、初心者の効率的MCU習得にテンプレートが適す、テンプレート応用例SimpleテンプレートとBaseboardテンプレートは、プロトタイプ着手時のMCUプロジェクトに適す、これらを再確認しました。

MCU習得やプロトタイプ開発に、弊社テンプレートは役立ちます。是非、ご活用ください。

WordPressサイト多言語化

2023年7月28日 WithHappy

本ブログサイトは、お盆休み：8月11日～13日期間中に多言語化開始を予定しています。
背景は、コチラの投稿の弊社ChangeとMCUテンプレート販売の海外展開です。

Summaryは、読者：MCU開発者向け多言語化お知らせと使い方、Afterwordは、筆者備忘録でWordPressサイト多言語化方法を示します。備忘録は、WordPressを多言語化する方の参考になれば嬉しいです。

Summary：多言語化お知らせと使い方

多言語化の使い方は、簡単です。サイト右上表示のプルダウンメニューから、お好きな言語を選べば、サイトが日本語から選択言語へ変換されます。ブラウザによっては、使用言語への自動変換されるかもしれません。

この多言語化機能は、ブログ記事に対しては既に有効です。中国語（簡体字）、オランダ語、英語、フランス語、ドイツ語、イタリア語、スペイン語へ変換できます。

変換は、「テキストが対象」です。従って、ブログ画像内の日本語は、変換されません。画像内日本語も変換したい方は、お手数ですがGoogle翻訳を使ってください。Google翻訳は、テキスト、画像、ドキュメント、ウェブサイトの言語変換が可能です。

今後弊社は、ブログ画像も日英両表記する方針です。

なお、画像も含む多言語化済みのMCUテンプレート販売は、8月11日～13日期間中に本ブログ固定ページで始めます。

この多言語MCUテンプレート販売は、段階的に開始します。最初は、既存MCUテンプレート10種のうち、ルネサス）RA6/4/2ベアメタルテンプレート、STマイクロ）STM32F0xテンプレート、STM32G0xテンプレートの3種を予定しています。

Afterword：WordPressサイト多言語化備忘録

様々なWordPressサイト多言語化方法の中で、手間とコストのかからないプラグイン：G-Translateを使う方法採用。

G-Translateで、テキストの多言語翻訳は可能。問題は、画像内の多言語化。暫定対策として日本語テンプレート販売と、多言語（英語）テンプレート販売の2本立てで対応。1本化を目指し、新に販売するテンプレート資料は、日英両表記で対応。

日本語テンプレート販売サイトは、当面そのまま残す。多言語（日本語含む）テンプレート販売サイトは、WordPress固定ページ経由で新規作成。

多言語MCUテンプレート販売は、段階的に開始。8月盆休みまでに、第一弾日本語テンプレート3資料のGoogle翻訳による英語化と新規固定ページ作成が目標。

過酷高温のMCU変化

2023年7月14日 WithHappy

最高気温が35°Cを超える猛暑日が多発しています。IoT MCU装置の動作環境も、過酷な高温になることもあるでしょう。

そこで、過酷な高温環境で、MCUの何が、どのように変わるかをソフトウェア開発者向けにまとめます。

Summary：限界温度以下のMCU運用必須

過酷な高温でMCUが動作すると、半導体MCU自体が部分的に破壊され、常温に復帰しても元に戻りません。その結果、MCU論理やアナログ処理の異常、消費電流過大/過少などの症状が現れることがあります。

ソフトウェア開発者が、これら見つけにくい症状をデバッグするのは困難です。フェールセーフ観点から、ADCでMCU心臓部温度をモニタし、限界温度まで十分な余裕のあるうちに動作停止などのMCU運用が必要でしょう。

参考資料

Notes on RA6E1 Group High-Temperature Operation、2023年7月10日
マイコンの仕様を超える条件で使ったら、何が起きる（前後編）、2022年8月12日、9月2日

RA6E1アプリケーションノート：Notes on RA6E1 Group High-Temperature Operationは、ルネサスRA6E1（Cortex-M33コア、IoT向きMCU）を使った8個のアプリケーションで、信頼性劣化を防ぐMCU心臓部限界温度の実験結果を示しています。

※本稿は、Tj：ジャンクション温度を、MCU心臓部温度と略記します。

何が起きる（前後編）は、STマイクロの技術資料です。高温、高湿、高電圧ストレスが、一般的なMCUに与える影響と、その可逆性（常温で正常に戻るかどうか）を詳しく説明しています。

過酷高温でMCUの何がどう変わるか

どちらの参考資料も、デバイス開発者向けとしては良く出来ています。

特に1は、具体的アプリケーションでの周囲温度（Ta：-40℃～105℃）とMCU動作時ジャンクション温度（Tj）の許容範囲を示しており、2の高温ストレス限界の具体例です。

しかし、ソフトウェア開発者にとっては、そのメカニズムよりも過酷高温動作の結果、MCUの何がどう変わるかをもっと端的に知りたいハズです。

過酷な高温でMCUが動作すると、半導体MCU自体が物理的、部分的に破壊され、常温に復帰しても元に戻りません。その結果、論理処理やアナログ処理の異常、消費電流過大/過少などの症状が現れることがあります。これらは、常に現れる症状ではないと筆者は思います。

ソフトウェア開発者が、通常のソフトウェアバグとは異なるこれら症状をデバッグするのは、困難です。

例えば、高温限界を超えたMCUと新品MCUとを並行動作し、たまに発生する異常症状から間接的に判断する程度でしょう。結局、新品MCUとの交換が必要です。

フェールセーフ

自動車は、制御系が異常を検出するとリンプモード（limp mode）、つまり、エンジン/モータやその他部品などの追加損傷をおさえつつ、最低限の走行で乗員を帰宅させるモードへ移行します。

MCU装置の場合は、先ず過酷な高温場所に設置しないこと、それでもやむを得ず限界高温に近づいた場合は、MCU破壊を避けるため動作停止などのフェールセーフが必要でしょう。

最近のMCUは、温度計を内蔵しています。ADCで自身の温度を測り、「限界温度前の十分な余裕あるうち」にフェールセーフ処理実行が可能です。

ディレーティング、10℃2倍則

高温状態で信頼性が劣化するのは、MCUだけではなく、抵抗、コンデンサ、基板などの装置デバイス全てに及びます。装置内で消費電力が最も大きいMCUに高温影響が顕著に表れ、その異常症状が他のデバイスに比べ検出し易いだけです。

そこで、多くのデバイスから構成される装置を安全に運用するには、各デバイス最大定格の50%以下で使うのが良いとされ、これをディレーティング（derating）と言います。

また、周囲温度が10℃上がると、材料寿命が半分になる10℃2倍則（10℃半減則）もあります。

これらを考慮すると、人間同様IoT MCU装置も、十分な余裕がある適温で運用してこそ本来の機能を発揮し、かつ、装置寿命も保てると言えます。適温とは、参考資料1 Table 4.1 No.3の最も厳しいTj≤85℃の50%、つまり45℃～50℃位でしょうか？

筆者は、Windowsタスクマネージャーのパフォーマンスモニタで、半導体CPU/GPU温度が50℃を超えると、処理負荷を減らすかシャットダウンするようPC運用を心がけています。

RA用FSP v4.5.0リリース

2023年7月7日 WithHappy

2023年6月28日、RA用FSP v4.5.0同梱e2 studio 2023-04がリリースされました。FSPのみがv4.4.0からv4.5.0へ更新され、e2 studioは、前回更新2023-04と同じです。FSP追加機能が下記です。

Reality AIサポート

API自動生成ツール：FSP v4.5.0追加機能で目新しいのが、Reality AIサポートです。

Reality AIは、ルネサスRAファミリ用のAI開発ツールで、AI処理にはCortex-M7クラスMPUが必要と思われていたのを、低コスト、低消費電力なMCUでも人物検出やモータ故障検出などのAI処理を実現できる特徴があります。

e2 studio 2023-04

IDE本体：e2 studio 2023-04は、更新無しです。

従って、前回更新で驚かされたユーザインタフェース：「消えたプロジェクト選択リスト」も不変です。下記の通りFSP v4.5.0インストール直後のダイアログで全ての内容に✅を入れて確認しました。

FSP v4.5.0 AI Data Collector/Shipper API

FSP v4.5.0 User’s Manual（英文）は、コチラからダウンロードできます。FSP v4.5.0追加Reality AI機能は、AI Data Collector/Shipperの2個のミドルウェアAPIです。

FSPのNew Stackを展開すると、新たにData Collector/Shipperの2個Stackが追加されました。Arm CMCIS5 NN Library Sourceは、前版からありました。

具体的にこのミドルウェアAPIとAI関連StackでどうやってAI処理を実現するかは、e2 studio FSP Summaryタグのフクロウアイコンクリックで表示されるData Shipper Basic ExampleやData Collector Basic Exampleを見ても筆者には、良く判りません。

FSPの極簡単な利用方法は、1)Stack配置、2)Property設定、3)Generate Project Content、4)Basic Example流用です。しかし、AI処理は、この方法では判らないAI学習などがありそうです。別途アプリケーションノート参照が必要でしょう。

だた、これらAI関連は、現在未発売のRAファミリ最上位RA8シリーズ（Cortex-M85+Helium）用の先行サポートだと筆者は思います。

Summary：RA2/4/6プロジェクトFSP v4.5.0アップグレードOK

RA用FSP v4.5.0同梱e2 studio 2023-04がリリースされました。FSP のみv4.4.0からv4.5.0へ更新、e2 studioは2023-04のままです。

FSP v4.5.0追加機能は、最初に図示したReality AIなどですので、RA2/4/6シリーズには当面無関係、今後発売されるRA8シリーズ用だと思います。

従って、旧FSP開発RA2/4/6プロジェクトをFSP v4.5.0へ更新すると、下記ワーニング表示がありますが、問題なくビルド、デバッグができます。

ルネサスArduinoボードへRA4M1供給

2023年6月30日 WithHappy

Renesas RA4M1搭載Arduino UNO R4 Minimaボード（出展：スイッチサイエンスサイト）

ルネサスが、Arduinoへ出資後、初めてのArduino最新版UNO R4仕様RA4M1（Cortex-M4/48MHz、Flash/256KB、RAM/32KB）搭載Arduinoボード：Arduino UNO R4 Minima販売が始まりました（2023年6月27日）。

ルネサスArduino出資

ルネサスが、Arduinoへ出資したのは1年前の2022年6月14日。出資額は、10百万⽶ドル（1⽶ドル130円換算で約13億円）です。

その狙いは、オープンソースハードウェアArduinoボードへのルネサスMCU搭載です。

ルネサスRA4M1

ルネサスRA4は、RAファミリRA2/4/6シリーズの真中性能に位置し、RA2の低消費電力性とRA6のパフォーマンス性を兼ね備えたシリーズです。RA4M1は、静電容量タッチセンサやLCDコントローラのHMIが搭載済みです。

Summary：全方位供給ルネサス

普及版Arduino UNO R3のMCUは、16ビット以下、ここに32ビットCortex-M4のRA4M1を搭載し、最新版UNO R4仕様として発表したルネサスの狙いが成功するかは、少し時間が必要と思います。RA4M1ソフトウェア開発は、UNO R3のそれとかなり異なるからです。

従来ルネサスビジネスとは異なる動向であることは、コチラの記事が明らかにしています。筆者も、記事と同感です。

ルネサスが、従来ビジネスに拘らずArduinoやRISC-Vなど、全方位でMCUを供給しようとする体制へ変化しつつある兆しだと思います。

ニッポン固執Change

2023年6月23日 WithHappy

“Change before you have to” 、Jack Welch氏（米GE：CEO、1981年から2001年）の名言です。日本スマホメーカ破綻とRapidus記事、グローバル市場必須の日本製造業と技術者の今をJack Welch氏の名言から考えてみました。

Rapidus記事

Rapidusロゴ

2023年6月12日から始まった日経クロステック「半導体立国ニッポンの逆襲」、Rapidus特集記事の昨日までの目次です。

第1回：日本で先端半導体をつくるだって?! 突然の記者会見、6月12日
第2回：20年前にラピダスの原点、小池社長の苦い過去、6月13日
第3回：ラピダス設立に動いた経産省の青写真、6月14日
第4回：ラピダス設立に透ける米国の影、6月15日
第5回：IBMからの電話で始まったラピダスへの道、6月16日
第6回：難関とともに終わったラピダス設立会見、6月19日
第7回：ニッポン半導体再起動へ、3つのラストチャンス、6月20日
第8回：⽇本半導体復活戦略の出発点「熊本」、6月21日
第9回：経産省が⽬指す半導体復活への3ステップ、6月22日

毎日追記され、各2000文字前後の文字数です。気分転換や隙間時間に読むのに適した量ですので、是非ご自身でお読みください。

AI要約ではありませんが、筆者が昨日迄の全記事をまとめたのが下記です。

全体トーンは、経産省主導Beyond 2nmを目指す次世代半導体会社Rapidus成功に懐疑的。2030年市場規模100兆円達成には、人材確保・育成や製造・量産ノウハウなど課題クリア必須。過去の政府主導失敗経験を活かしたのは、半導体ユーザ製造業（トヨタ、NTT、Sonyなど）を加えた点。但し、政府700億円拠出に対し、ユーザ10億円以下で温度差あり。Rapidus成功の道は険しいが、半導体立国ニッポン最後で最大のチャンス。

関連投稿：Rapidus（ラピダス）

日本スマホメーカ破綻

デジタル弱者、特に中高年層に人気があり販売実績数も多い「らくらくスマートフォン」メーカのFCNTが、経営破綻しました。

破綻要因は、半導体不足による調達価格高騰、スマホ不況など色々あると思います。言えるのは、ニッポンに拘った製品は、日本市場Shrinkと共に消える可能性大と言うことです。もはや、日本市場だけで存続できる製造業はあるのでしょうか？

例えば、前章Rapidus出資のトヨタ、Sonyは、グローバル市場でも稼いでいます。NTTもKDDIとタッグを組んでIWON（Innovative Optical and Wireless Network）を研究開発し、狙いはワールドワイド通信キャリア市場です。

関連投稿：世界規模の宇宙センシングIOWN

つまり、日本製造業が生残るには、ニッポン国内の稼ぎだけでは少なすぎる訳です。この対策の1つが、かつてのライバルKDDIと共同で光電融合デバイスを開発するNTTの動きにも現れています。

民間企業だけでなく、人口減少が進む地方自治体でさえ、従来のやり方では破綻危機が予想されています。

Summary：Change Now

Change before you have to

日本製造業は、高性能、高品質、低価格なニッポン製品を世界中へ輸出、販売し稼いできました。この稼ぎ方は、製品性能を左右する高性能半導体や円安が前提です。円安は、逆に海外製半導体の購入には不利です。

※円安＝輸出日本製品が、海外で比較的安く買える

Rapidusが、次世代半導体のニッポン製造に拘る理由は、円安・円高の為替相場に依存しない高性能半導体の国内安定・安価提供が目的だからです。

同様の動きは、欧州半導体法、米国CHIPS法にも見られます。ローカライゼーション動向に見えますが、これら諸法に後押しされる欧米製造業は、元々グローバル市場が狙いの猛者たちです（←誉め言葉です）。

日本製造業と日本技術者が生残るには、Rapidus成功・失敗にかかわらず、グローバル市場への “Change before you have to” が今必要、と名言は警鐘を鳴らしていると思います。

Afterword：弊社Change

WordPressの本サイトは、多言語対応済みです。しかし、MCUテンプレートサイトは、日本語のみ、ここも多言語化したいと考えています。

それにしても、本稿投稿のきっかけになった、ガラパゴス携帯に続く人口比多数派中高年対応らくらくスマホ破綻、単にスマホ不況だけでは考えられません。日本≠弱者≠ビジネス切捨対象なら良いのですが…。
Change必要です！