Cortex-M4コアアーカイブ - 8ページ目 (11ページ中)

MCUの5V耐圧ピン

2020年6月12日2020年6月19日 WithHappy

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

LPCXpresso54114 Board power diagram（出典：UM10973に加筆）

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

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

MCU動作電圧

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

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

レベルシフタ

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

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

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

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

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

MCUの５V耐圧ピン：5V Tolerant MCU Pad

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

LPCLPCXpresso54114の5V耐圧属性（出典：5411xデータシート）

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

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

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

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

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

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

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

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

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

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

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

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

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

NXPのFreeMASTER

2020年6月5日2020年7月18日 WithHappy

FreeMASTERは、NXP組込みMCUのアプリケーションのリアルタイム変数モニタと、モニタデータの可視化ツールです。関連投稿：STマイクロエレクトロニクスのSTM32CubeMoniterとほぼ同じ機能を提供します。

NXP資料FreeMASTER Run-Time Debugging Tool – Overview を使ってFreeMASTERの特徴を示します。

FreeMASTERとIDEデバッガ機能差

FreeMASTERと、開発者が普段使うIDEデバッガとの差が一目で解る図がP13にあります。

FreeMASTERとデバッガの違い（出典：FreeMASTER Run-Time Debugging Tool – Overview）

両者の機能境界が、ソースコードのデバッグ機能です。IDE（MCUXpresso IDE）でも変数ロギングやグラフ化機能はありますが、プログラム開発者向けの最低機能に絞ったものです（limited functionality）。

これに対し、FreeMASTERは、msec分解能のグラフ化と、μsec分解能のデータ取得が可能です。更に取得データを利用し、Field-tune parametersやRemote controlなど多くの機能を持つツールです。データの取得は、MCU実装のUARTやUSB、SWD経由です。

FreeMASTERを使うと、外付け制御パネルの代替やGUIアプリケーションとしても活用できます。例えば、下図のようなモータ制御パネルが、PC上でFreeMASTERソフトウェアのみで実現できる訳です。

FreeMASTERを使ったモータ制御パネル例（出典：FreeMASTER Run-Time Debugging Tool – Overview）

FreeMASTER構成

Windows PCにおけるFreeMASTER構成がP20です。詳細は、P21～25に示されています。Linux PCでの構成は、P26に示したFreeMASTER Liteが使われます。

FreeMASTER Windows PC構成（出典：FreeMASTER Run-Time Debugging Tool – Overview）

MCU開発トレンド：ビジュアル化と脱Windows

組込みアプリケーションのビジュアル化は、最近のMCU開発トレンドです。

MCU本体の性能を使わずに変数データを取出し、そのデータを高性能PCとプラグイン機能を利用し、データ可視化やリモート制御を実現します。本稿で紹介したNXPのFreeMASTERやSTのSTM32CubeMoniterがこのトレンドをけん引する技術です。

また、オープンソースLinux PCへのMCU開発環境移行や各社IDEマルチプラットフォーム化、つまり脱Windowsもトレンドの1つです。

上級開発者向けというイメージが強かったLinux PCですが、一般ユーザへも普及し始めました（Wikipediaより）。筆者も昨年から、MCU開発Main-PCのWindows 10とは別に、Backup-PCにLinux Mintを新規インストールし試用中です。

半年間の試用では、OSインストール、大型/定期更新、セキュリティに関してもLinux Mintの方が、Windows 10より安定感があります。

もはや現状のWindows 10では、信頼性があったWindows 7のレベルにはならない気がします。

既存Windows 10に手を加えるよりも、新OSを開発するほうが、早道で、安心してPCを利用したい一般ユーザ要求も同時に満たせるのではないでしょうか？　商業的理由は、セキュリティ対応強化とすれば、内容不明ながら大多数の納得も得られるでしょう。※あくまで、ソフトウェア開発経験者個人の見解です。

NXP新CEO Kurt Sievers氏

2020年5月28日、蘭）NXPのCEOがリチャード・L・クレマー（Richard L. Clemmer）氏から、カート・シーヴァーズ（Kurt Sievers）氏への交代発表がありました。こちらのEE Times記事に新CEOカート・シーヴァーズ氏の経歴や、米中貿易摩擦下でのNXP中国分析などが示されています。

欧州MCUベンダNXPのアフターCOVID-19への布石、さすがに早いです。

STM32CubeMonitor

2020年4月24日2020年5月1日 WithHappy

STマイクロエレクトロニクスのSTM32MCU純正開発環境STM32Cubeツールファミリに新に追加されたSTM32CubeMonitorを解説します。

STM32CubeMonitor特徴１：変数リアルタイムモニタ

STM32MCUアプリケーション開発フローと、純正開発環境STM32Cubeツールファミリ：STM32CubeMX、STM32CubeIDE、STM32CubeProgrammer、 STM32CubeMonitorの機能配分が下図です（以下、各ツールの頭に付くSTM32は省略して記述します）。

STM純正 4 Software Development Toolsと機能（出典：STMサイト）

この1～4段階の開発フローを繰返すことでアプリケーション完成度が上がります。CubeMX、CubeIDE、CubeProgrammerの機能には重複部分がありますが、Monitoring機能を持つのは、CubeMonitorだけです。

通常のMCU開発は、CubeMXがビルトインされた4段階全てをカバーする統合開発環境：CubeIDEを使えば事足ります（CubeMXビルトインCubeIDEの詳細は、関連投稿の3章をご覧ください）。

CubeProgrammerは、MCUオプションバイト設定などCubeIDEではできないBinary Programmingの＋α機能を提供します。例えば、STM32G0/G4のRoot of Trust(3)の投稿で示したSBSFU書込みや消去などがこの機能に相当します。

CubeIDEでも、デバッガ上でアプリケーションの変数モニタは可能です。しかし、あくまでDebugging MCUの（開発者向け）変数モニタです。CubeMonitorは、アプリケーションを通常動作させたまま、変数をリアルタイム（ライブ）モニタができる点が、CubeIDEとは異なるMonitoring機能です。

STM32CubeMonitor特徴２：データ可視化

リアルタイムで取得したデータは、下図のようにPCダッシュボードに予め準備済みのChartや円グラフにして可視化することができます。しかも、これら表示が、PCだけでなく、スマホやタブレットへも出力可能です。

つまり、CubeMonitorを使えば、開発したアプリケーションのライブ動作を、あまり手間をかけずにビジュアル化し、エンドユーザの顧客が解るように見せることができる訳です。これが、一押しの特徴です。

文章で説明するよりも、コチラの動画を見ていただくと一目瞭然です。

組込みアプリケーションのビジュアル化

組込みアプリケーション開発も、自動車のADAS（Advanced Driver-Assistance Systems：先進運転支援システム）のおかげでビジュアル化がトレンドです。

もちろん、超高性能MCUやデュアルコアMCUで実現するアプローチが本流です。が、本稿で示した2020年3月発表のCubeMonitorを使えば、産業用MCUでも案外簡単にビジュアル表示出力が可能になりそうです。

組込みアプリケーションは、MCUで結構大変な処理を行っていても、外（顧客）からは単にMCUデバイスしか見えません。CubeMonitorで処理データを可視化するだけでも、複雑さや大変さを顧客へ示すツールにもなります。

2020年4月7日、独）Infineon Technologies（インフィニオンテクノロジー）が、米）Cypress Semiconductor（サイプレスセミコンダクタ）の買収に必要となる規制当局の承認を得たと発表しました（EE Times Japan記事）。同じEE Timesの3月9日記事では、米国が、国家安全保障上リスクのため買収を阻止し、破断の可能性も示唆していましたが、結局、買収成立のようです。

本稿は、MCU開発者向けに欧州MCUベンダ動向と、コロナ・エフェクト記事をピックアップし、MCU開発者のリクス分散必要性を示します。

CypressとInfineon

本ブログ掲載中のCypressは、ARM Cortex-M0/M0+/M4コアと、タッチセンサ：CapSenseやオペアンプ等の独自アナログコンポーネントを1パッケージ化したPSoCマイコンが特徴です。
※本ブログ検索窓に‘CapSense’を入力するとCapSenseコンポーネント利用の関連投稿がご覧いただけます。また、CapSense利用の弊社PSoC4000S/4100S/4100PSテンプレートも販売中です。

同業のNXPやSTMが、Eclipse IDEをベースとした標準的なARMコアマイコン開発環境をユーザへ提供するのに対し、Cypressは、独自コンポーネントの特徴を活かす開発環境PSoC Creatorを提供し、洗練された高度なMCU制御技術と、解り易い資料を提供できる会社という印象を持っています。

PSoC Creatorは、ソフトウェアだけでなくハードウェア関係者にも活用して頂きたいツールで、これ1つで殆ど全てのPSoC関連リンクへ簡単にアクセスできます。ツール更新方法もEclipseベースのIDEより優れています。

このCypressを買収したInfineonは、独）シーメンスから分離・独立し、自動車用や産業用など様々な分野へパワー半導体の供給を主力とする製造、販売会社です（ウィキペディアより）。

Infineonの狙い

2019年6月10日EE Times のインフィニオンの狙いは「日本市場攻略」記事によると、主力のパワー半導体の豊富な品揃えに加え、Cypressの制御技術を獲得することで、日本半導体ベンダへ大きなインパクトを与え、日本市場攻略が、インフィニオンの狙いだそうです。

追記：買収完了で2019年売上高ランキングで見るとInfineinとCypress合わせて、7位TIと8位STMの間に入ることになるそうです（EE Times、2020年4月17日）。

コロナ・エフェクト

Cypress買収は、COVID-19前のビジネス戦略結果です。

欧州MCU各ベンダが、COVID-19パンデミック後どう変化するかは解りません。現時点での動きが下記です。

仏伊）STマイクロエレクトロニクスは、フランス生産工場出勤者を縮小、イタリアは製造継続と発表しました。また、独）Infineon工場は、全て稼働中です（EE Times、2020年4月1日）。

英）ARMは、Arm Development Studio Gold Edition評価ライセンスの有効期間を延長、MDK Professional Edition評価ライセンスのCOVID-19対策プロジェクト1年間ライセンススポンサー提供など、在宅勤務ライセンスを提供中です（ARMメールサービス）。

日本政府は、緊急事態宣言時でも半導体工場を事業継続可能に指定しました（EE Times、2020年4月10日）。

MCU開発者

欧州/米/アジアのMCUベンダにCOVID-19が与える影響は、数年前のように再びMCUベンダ間のM&Aが盛んになるのか？　それとも現状で落ち着くのか？　オープンアーキテクチャRISC-Vが勢力を伸ばすか？　今のところ、全く不透明です。

しかし、我々MCU開発者へもテレワーク化や開発MCU変更などの影響が必ず及びます。変わるところ、変わらないところを個人レベルでも見極め、今のうちに準備しリスク分散対策の必要があると思います。

筆者お気に入りのCypressらしさが、今回の買収で変わらないことを願っております。

STM32G0/G4のRoot of Trust(3)

2020年4月7日2020年4月7日 WithHappy

STM32G0/G4シリーズRoot of Trust実現(3)は、第2回で示したSTM32G4評価ボード：NUCLEO-G474RE 利用STM32G4テンプレート開発環境と、デュアルファームウェアイメージのサンプルアプリケーションを使って、セキュア・ブート（SB）、セキュア・ファームウェア更新（SFU）のための準備、その具体的動作の説明をします。

初めに本稿（3）のまとめを示し、最後の章でRoot of Trust実現(1)～(3)全体のまとめを示します。

STM32G0/G4のRoot of Trust(3)まとめ

セキュア・ブート（SB）、セキュア・ファームウェア更新（SFU）に、評価ボード毎にSTM32CubeProgrammerを使ったオプションバイト設定必要。
Root of Trust（SBSFU）実装MCUは、VCP経由アクセスのみ可能。
SBSFUローカルVCPダウンロードのために、Tera TermとYMODEM送信機能利用。
STM32G4評価ボード：NUCLEO-G474REで、SBSFU実装デュアルファームウェアイメージアプリケーション動作説明。
STM32G0評価ボード：NUCLEO-G071RBでも、STM32G4評価ボードと同じRoot of Trust（SBSFU）実装動作を確認。

STM32G4評価ボード準備

SB、SFUサンプルアプリケーションの動作確認のために評価ボード：NUCLEO-G474REの事前準備が必要です。これには、STM32CubeProgrammerを使います。STM32G4の場合は、UM2262 図18ですが、オプションバイト等の設定は不要（デバイスデフォルトOK）です。

8.1.3のFlash全消去（Full chip erase）処理をします。また、評価ボードのST-LinkファームウェアをV2J29以上に更新します。更新は、評価ボードとUSB接続後、STM32CubeProgrammerのFirmware Updateクリックで最新版ST-Linkファームウェアへ更新されます。

Root of Trust（SBSFU）準備

図17. ステップバイステップ実行から判るように、最初のStep1：SBSFUダウンロード以外は、全て評価ボードのVirtual COMポート（VCP）経由でアプリケーションをダウンロードします。STM32CubeIDEがプログラミングやデバッグで使うST-Link接続（SWD接続）は、外部からのMCU攻撃とSBSFUが解釈するからです。

セキュア・ブート（SB）が攻撃と判断した時は、当然、アプリケーションを起動しないためMCUは動作停止します（SB処理は、第2回2章を参照してください）。

つまり、ファームウェアイメージのアプリケーションがディアル/シングルに関係なくRoot of Trust（SBSFU）実装MCUは、VCP経由アクセスのみ可能となります。また、VCP経由でのアプリケーションデバッグは非効率なため、十分なデバッグ済みアプリケーションをダウンロードする必要もあります。

このVCP経由ダウンロードのために、Tera TermとそのYMODEM送信機能の準備が必要です。

SBSFUサンプルアプリケーション

図17. Step-by-stepを使ってデュアルファームウェアイメージのSBSFUサンプルアプリケーション動作を説明します。

Step1：Flash全消去後のNUCLEO-G474REに、STM32CubeIDEを使って第2回3章で示した順番でコンパイル済みのSBSFUプロジェクト出力（SBSFU.elf）を、STM32CubeIDEを使わずにSTM32CubeProgrammerでダウンロードします。

STM32CubeIDEでは、ダウンロード後自動的にデバッガ接続に変わるため、この時点でSBSFUが攻撃を受けたと判断し使用できません。

STM32CubeProgrammerを使うとNUCLEO-G474REのFlashに、セキュアエンジンとSBSFUが書込まれます。これ以降は、Tera TermのVCP経由MCUアクセスのみが可能です。
※従って、STM32CubeIDEを使ったST-Link経由MCUデバッグ開発へ戻る時は、STM32CubeProgrammerでSBSFUが入ったFlashを全消去する必要がありますので注意してください。

次に、パソコンとNUCLEO-G474RE接続中のUSBケーブルを、2回挿抜します。これで、ST-Linkに代わりSBSFUとTera TermのVCP通信が開始します。

Step2：NUCLEO-G474RE とTera Termは、8-Non-1 115200bpsでシリアル接続します。接続後、NUCLEO-G474REリセットボタン（黒ボタン）を押すと、SBSFUが図24（白黒反転済み）のWelcome画面をTera Termへ出力します。

Welcome画面を確認後、Tera Termのファイル(F)>転送(T)＞YMODEM＞送信(S)をクリックし、UserApp.sfb（暗号化ファームウェア）を選択します。
※UserApp.sfbは、NUCLEO-G474RE_2_Image _UserApp￥Binaryフォルダ内（UserApp オブジェクト出力先フォルダ）にあります。

プログレスバーは、1秒ほど動きません。この間は、SBSFUがダウンロードファームウエアヘッダの有効性を検証し、格納するFlashスロット＃0/#1領域を消去しているからです。

送信完了でNUCLEO-G474REのFlashが、Step2の状態になります。

Step3：NUCLEO-G474REが自動的に再起動し、SBSFUにより復号化されたUserAppが動作します。この時のTera Term出力が図27（白黒反転済み）です。NUCLEO-G474REのLD2は、ゆっくり点滅します。

画面のUser App #Aは、2_Images_UserApp＞main.cのL51：UserAppId = ‘A’の出力です。Main Menu：1/2/3は、インストールしたアプリケーションに記述されたSBSFUテスト機能です。

CN7真ん中よりやや下あたりを指で触るとTamper機能が動作し、ボードリセットが掛かります。

実際では、この段階で我々ユーザが開発したアプリケーションが動作中となります。

Step4：ユーザ開発アプリケーションに何らかのバグがあり、これをデバッグ済みの新しいアプリケーションへ更新（SFU）するのがこの段階です。

STM32CubeIDE でL51：UserAppId＝‘B’へ変更し、コンパイルします。ここでは、これをデバッグ済みの新しいアプリケーションとします。

再び、Tera Termのファイル(F)>転送(T)＞YMODEM＞送信(S)をクリックし、UserApp.sfb（UserAppId＝‘B’に変更し、コンパイルした暗号化ファームウェア）を選択し、ダウンロードします。ダウンロード完了でNUCLEO-G474REは再起動します。

Step5：再起動後の動作中アプリケーションは、図27の下線部が変更したUser App #Bに変わっていることで確認できます。

これで、新しいアプリケーションへの更新が完了しました。

＊　　＊　　＊

図17を使ってRoot of Trust実現STM32G4シリーズMCUのセキュア・ブート（SB）、セキュア・ファームウェア更新（SFU）ローカル動作例を説明しました。

実際は、この動作が図2. ②通信チャネル経由で行われます。

通信チャネル利用時は、本稿のローカル動作で使ったTera TermのYMODEM送信を誰が行うのか、鍵の管理やサーバ提供など、筆者がUM2262から読み切れない不明な部分があります。これらはいずれ、明らかにする予定です。

また、UM2262図18. 評価ボード準備とSTM32CubeProgrammer設定方法が解りづらく、単なるサンプルアプリケーション動作にかなり「苦戦」しました。この部分は、通常アプリケーション開発とRoot of Trust実現開発の切換えとなる重要ポイントです。STM32G4テンプレート発売時には、添付資料にもっと解りやすい説明を加えます。

UM2262 Rev6/5の評価ボード：NUCLEO-G474RE設定記述ミス

もう1つの「苦戦」理由は、UM2262 Rev6/5の8.1評価ボード：NUCLEO-G474RE設定記述に間違いがあるからです。

UM2262 8.1には、STM32G4のDBANKビット有効化と記述されていますが、これは「無効化が正しい」です。STM32CubeProgrammerで無効化に設定してください。

STM32G0評価ボード：NUCLEO-G071RBに関しては、記述にミスはありません。本稿の関連部分をNUCLEO-G071RBへ読替えると、全て正常動作します。

STM32G4シリーズは、STM32G0シリーズよりも約1年後に発売されました。新しいMCUのためUM2262に記述ミスがあるのだと思います。

STM32G0/G4のRoot of Trust全体まとめ

STM32G0/G4のRoot of Trust(1)～(3)、いかがでしたでしょうか？　セキュリティ機能の実装は、IoT MCUでは必須です。従来のMCU開発へ追加する機能や手間、セキュリティ知識も当然必要になります。

これら追加分は、一般的な開発者が、オリジナリティを加えるべき部分では無いと思います。そこで、これら追加分を、できるだけ簡潔に解り易く説明したつもりです。Root of Trust (1)～(3)で、下記STM32マイコンマンスリー・アップデート2020年3月号P4のX-CUBE-SBSFU説明内容が、より解り易くなれば先ずはOKとします。

STM32マイコンマンスリー・アップデート2020年3月号P4のX-CUBE-SBSFU説明

結局、STM32G0/G4シリーズMCUの場合は、通常のMCUアプリケーション開発が第1段、次に、これをIoT MCU化し、Root of Trust機能（SBSFU）を追加実装するのが第2段という、2段階開発になりそうです。この第2段SBSFU実装時に、本稿で用いたデュアル/シングルファームウェアイメージのアプリケーションサンプルが、枠組みとして使えそうです。

STM32G4テンプレートも、弊社通常テンプレート同様、RTOSを使わない疑似マルチタスク実装用（第1段テンプレート）と、開発済みアプリケーションのRoot of Trust SBSFU実装用（第2段テンプレート）の2つに分けてパックで提供しようと考えています。

セキュリティ（盾）は、常に脅威（鉾）との競争です。STM32G0/G4シリーズよりも更にセキュリティを強化したSTM32L5シリーズ（Cortex-M33）など最新MCUの方が、IoT MCU開発には向いているのかもしれません。

この終わりなき競争が続いてセキュリティ時代遅れにならないように、開発中MCUのより早く、かつ、万一より強いセキュリティMCUが必須となった場合でも、MCUコアに依存しない流用性の高いアプリケーション開発が求められます。

STM32G0/G4のRoot of Trust(2)

2020年3月27日2020年5月31日 WithHappy

STM32G0/G4シリーズRoot of Trust実現の第2回目は、初めにRoot of Trustを実現するセキュア・ブートの説明にトライし、直にセキュア・ブートとセキュア・ファームウェア更新を実装するSTM32G4テンプレート開発環境の構築方法を示します。

セキュア・ブート説明をこまごま続けるよりも、具体的なRoot of Trust実現開発環境を示す方が、実務的（短絡的？）だからです。

セキュア・ブート

第1回紹介の日本語版UM2262、P1概要：セキュア・ブート説明を抜粋したのが以下です。

‘セキュア・ブート（信頼の起点となるサービス）は、システムリセット後に必ず実行される改変不可のコードで、無効なコードや悪意のあるコードを実行しないために、実行前に毎回STM32の静的保護を確認し、STM32実行時保護を有効化してから、ユーザアプリケーションコードの認証および整合性を検証します。’

英語直訳で難解です（各単語の事前理解が必要なセキュリティ関連説明は、殆どがこんな感じですが…）。

ただ、下線部：「必ず実行される改変不可のコード」なので、理解不足や多少間違って解釈しても、セキュア・ブートコードを実装すれば、それで十分かもしれません😅。

セキュア・ブート解釈

要は、ユーザが開発したアプリケーション実行前に、MCUが勝手に行うブート処理のセキュリティを高度にしたものがセキュア・ブート（SB）だと解釈します。

従来のブート処理は、リセット後、MCU内蔵クロック発振器の安定化待ちやRAM領域初期化などの処理を何の疑いもなく実行し、その後、ユーザ開発アプリケーションを起動していました。

セキュア・ブート処理は、前章のセキュア・ブート処理を行い（図1.①）、その結果をUM2262：9章の表6. 起動時エラーメッセージ（下表）で示すように認証し②、「エラーなし。成功。」時のみ、③ユーザ開発アプリケーションを起動します。

パソコンで例えると、従来ブートがBIOS起動、セキュア・ブートがUEFI起動に相当すると考えれば良いのかもしれません。

X-CUBE-SBSFUはHAL API補完

Root of Trust実現で使うSTM32Cube拡張パッケージ：X-CUBE-SBSFUは、STM32MCU間の移植性を重視しているためHAL（Hardware Abstraction Layer）ベースです。

弊社発売中のSTM32G0xテンプレート（Version1）は、高速性を活かすエキスパート向けLL（Low layer）APIが「主」、HAL APIは「従」としてSW4STM32で開発しました。しかし、STM32G0でのRoot of Trust実現には、HALベースのソフトウェア開発が適しています。

LL/HAL混在利用は、関連投稿：STM32CubeMXのLow-Layer API利用法 (2)の4章で示した注意が必要です。X-CUBE-SBSFUは、アプリケーション起動前のHAL利用で、起動後のユーザアプリケーションのLL利用の場合は、問題ないかもしれません。この点は、今後明らかにしていきます。

いずれにせよSTM32G0xテンプレートは、IDEをSW4STM32から新しいSTM32CubeIDEへ移設すると同時に、Root of Trust実現に向けHAL APIも「主」とし、STM32CubeIDEで「再開発」してVersion 2に改版する予定です。

セキュリティ関連の説明はここまでにして、STM32G4シリーズでRoot of Trust実現の具体的方法に移ります。

Root of Trust実現STM32G4テンプレート開発環境

Root of Trust実現にセキュア・ブート（SB）機能とセキュア・ファームウェア更新（SFU）機能を実装する汎用STM32G4シリーズのテンプレート開発環境は、以下とします。

統合開発環境：STM32CubeIDE v1.3.0、2020/02/26
STM32Cube拡張パッケージ：X-CUBE-SBSFU v2.3.0、2020/01/17
STM32G4評価ボード：NUCLEO-G474RE（Cortex-M4/170MHz、Flash/512KB、RAM/128KB）

この環境で実現するセキュリティ機能が、UM2262の6.1概要に記載されたものです。これら機能理解に不明確な部分もありますが、内容把握済み、これら機能実現ためX-CUBE-SBSFUを使うと割切ります。開発環境を使っているうちに、（多分）理解度が上がるでしょう😅。

なおUM2262日本語版は、英語版Rev5からの翻訳なのでサポートIDEにSW4STM32はありますが、新しいSTM32CubeIDEがありません。しかし、最新英語版UM2262 Rev6に、STM32CubeIDEが追加されましたので本ブログでもSTM32CubeIDEを使います。

また、セキュリティ機能をテストするNUCLEO-G474RE用サンプルアプリケーションもX-CUBE-SBSFUに添付されていますので、これを以降の説明に使います。

UM2262では、STM32CubeIDEを使ったRoot of Trust開発環境の構築手順が判りにくいので、以下に説明を加えます。

構築手順1：STM32CubeIDEへのRoot of Trust SW4STM32プロジェクトインポート

X-CUBE-SBSFU v2.3.0には、SW4STM32プロジェクトが添付されていますが、未だSTM32CubeIDEプロジェクトの添付はありません。

そこで、STM32CubeIDEのInformation CenterからImport SWSTM32 projectをクリックし、X-CUBE-SBSFU添付SW4STM32プロジェクトを変換（Import）し、STM32CubeIDEプロジェクトを新規作成します。

STM32G4評価ボード：NUCLEO-G474REのSW4STM32プロジェクト6個を、STM32CubeIDEへインポートする時のダイアログです。

Finishクリックで、プロジェクト毎に下図2回の同意を求められますので、OKをクリックします。

構築手順2：Root of Trustサンプルアプリケーションのコンパイル

インポートした6個のプロジェクトは、シングルファームウェアイメージ：NUCLEO-G474RE_1_Imageとデュアルファームウェアイメージ：NUCLEO-G474RE_2_Imageの2種類のサンプルアプリケーションです。

シングル/デュアルファームウェアイメージの違いは、次章で説明します。

このサンプルアプリケーションは、それぞれ図15のように、_SECoreBin、_SBSFU、_UserAppの順番でプロジェクトをコンパイルする必要があります。図示のように前段コンパイル生成出力を、次段コンパイル入力に使うからです。

この順番を守ってコンパイルした時のみ_UserAppの出力オブジェクトが生成されます。

Windowsセキュリティソフト（Avastなど）によっては、コンパイル途中でワーニングを出力することがありますが、暫く待つとコンパイルを継続します。

シングルファームウェアイメージとデュアルファームウェアイメージ

図15は、SBSFU処理後のFlashメモリ配置を示しています。

図15の右側黄色部分：アクティブなイメージ領域だけをSFU処理で使うサンプルアプリケーションが、シングルファームウェアイメージです。右側黄色部分の上側、イメージのダウンロード/バックアップ領域に、図2のネットワーク（②通信チャネル）経由の新しいファームウェアを一旦入れるのが、デュアルファームウェアイメージです。

デュアルファームウェアイメージは、SFU処理中に電源断で中断しても、電源復帰後にSFU継続が可能です。また、アクティブなイメージ領域で動作中アプリケーションと並行してダウンロードが可能です。

シングルファームウェアイメージは、新しいファームウェアを、アクティブなイメージ領域上へ直接更新します。

デュアルファームウェアイメージは、フェールセーフな分、Flash容量はシングル比、倍必要になります。一方、シングルファームウェアイメージは、ユーザが使えるFlash容量が大きいので、デュアルよりも大きなアプリケーション開発ができます。

※ここで使ったセキュリティ用語：ファームウェアイメージとは、STM32CubeIDEのコード生成ツールSTM32CubeMXがデバイス毎に用いるファームウェア（弊社ならFW_F0/F1/G0/G4）とは別物です。図15の黄色部分を示します。

＊　　＊　　＊

以上で、STM32CubeIDEを使ったRoot of Trust実現のセキュア・ブート（SB）、セキュア・ファームウェア更新（SFU）機能を持つSTM32G4テンプレート開発環境の構築と、SBSFUに使うシングル/デュアルファームウェアイメージの2種サンプルアプリケーションを説明しました。

次回、このSTM32G4テンプレート開発環境とデュアルファームウェアイメージのサンプルアプリケーションを使って、Root of Trust実現の動作説明を予定しています。

STM32G0/G4のRoot of Trust(2)まとめ

信頼の起点：セキュア・ブート（SB）は、リセット後に必ず実行される改変不可能コード。
SB処理後、エラーなし認証時のみ、ユーザアプリケーション起動。
STM32Cube拡張パッケージ：X-CUBE-SBSFUは、HAL API補完。
STM32CubeIDEでRoot of Trust実現のセキュア・ブート（SB）、セキュア・ファームウェア更新（SFU）機能実装STM32G4テンプレート開発環境と構築手順説明。
SBSFUアプリケーションのデュアルファームウェアイメージとシングルファームウェアイメージの特徴説明。

SB、SFU実現には、暗号化や図1/2/15掲載の鍵、セキュアエンジンなど、本稿で説明を省いた（すっ飛ばした）様々なセキュリティ処理が必要です。UM2262付録の章に、これら詳細が記載されています。

本質的なセキュリティ理解には、これら各処理の理解積重ねが必要だと思います。付録の章を一読しておくと、今後いろいろな場面で役立ちます。

STM32G0/G4のRoot of Trust(1)

2020年3月19日2020年3月27日 WithHappy

2020年3月号STM32マンスリー・アップデートのP4に、STM32マイコンでRoot of Trustを実現するセキュリティ・ソフトウェア・パッケージ：X-CUBE-SBSFUが紹介されています。

セキュア・ブート、セキュア・ファームウェア更新、Root of Trust…などIoT MCUセキュリティ用語満載で、投稿：総務省によるIoT機器アップデート機能義務化に関連しそうな内容です。

解りにくいこれらセキュリティ関連の用語解説と、本ブログ対象STマイクロエレクトロニクスのSTM32G0/G4シリーズのRoot of Trust実現方法を、今回から数回に分けて投稿します。

Root of Trust とX-CUBE-SBSFU、STM32G0/G4

マンスリー・アップデートの説明は、エッセンスのみを抽出した代物なので、リーフレットを使って説明します。

一言で言うと、「Root of Trust実現には、X-CUBE-SBSFUが必要で、対応中STM32MCUが下表」です。

Root of Trust対応中のSTM32マイコン一覧（出典：FLXCUBESBSFU0819J）

つまり、Root of Trustは全てのSTM32MCUで実現できる訳ではなく、表中のMCU、メインストリーム（汎用）・マイコンの場合は、STM32G0とSTM32G4がセキュア・ブート（SB）とセキュア・ファームウェア更新（SFB）に対応しておりRoot of Trustを実現しています。

X-CUBE-SBSFUの下線部SBはセキュア・ブート、SFUはセキュアFW更新を示します。X-CUBEは、STM純正ソフトウェアツールの総称です。

信頼性を実現するハードウェア/ソフトウェアの根幹部分を、Root of Trustと呼びます。

汎用MCUでRoot of Trustの実現には、ハードウェア/ソフトウェア両方に相応の能力が必要で、従来からある汎用STM32Fxシリーズではなく、新しい汎用STM32G0/G4にSBとSFUが実装されたのだと思います。

ということは、総務省のIoT機器アップデート機能義務化が実施されると、IoTエッジで使う汎用MCUは、必然的にSTM32G0/G4シリーズになるかもしれません。
※X-CUBE-SBSFUは、移植性の高いHAL API利用のため、従来汎用STM32Fxへも流用可能かもしれません。しかし、現時点では、表記STM32G0/G4のみ対応と解釈しています。

STM32汎用MCUラインナップ（出典：STM32 Mainsterm MCUsに加筆）

用語を説明したのみですが、Root of Trust とX-CUBE-SBSFU、汎用マイコンSTM32G0/G4の関係が、マンスリー・アップデートエッセンスより見えてきたと思いますがいかがでしょう。

さらに、一歩踏み込んで、STM32G0/G4のセキュア・ブート、セキュア・ファームウェア更新方法やセキュリティの背景などの詳細は、次回以降説明します。

X-CUBE-SBSFUユーザマニュアル：UM2262

次回以降の説明は、X-CUBE-SBSFUユーザマニュアル日本語版（2019 年 11 月14日）：UM2262を基に行います。

UM2262は、X-CUBE-SBSFU対応中の全てのSTM32マイコン（ハイパフォーマンス/超低消費電力/メインストリーム（汎用）/ワイヤレス）が併記されています。

そこで、STM32G0とSTM32G4関連のみを抜粋し、特にセキュア・ブート（SB）とセキュア・ファームウェア更新（SFU）の設定方法と背景を中心に説明します。販売中のSTM32G0xテンプレートと、開発予定のSTM32G4テンプレートに関連するからです。

本稿で示したRoot of Trustを、STM32G4テンプレートに実装するかは未定です。しかし、IoTエッジマイコンのSTM32G4らしさを出すには、Root of Trust実現は必須だと思います。

また、STM32G0xテンプレートは、まずVersion 2改版で新統合環境：STM32CubeIDE v1.3.0への対応を予定しております（現行版は、SW4STM32開発のVersion 1）。
※STM32G0関連の投稿は、本ブログ右上のSearch窓へ、“STM32G0”と入力すると、効率よく投稿が集まります。新汎用STM32G0の特徴、STM32G0xテンプレートのことが解ります。

STM32G0へのRoot of Trust実装も未定ですが、対応する場合でもVersion 2より後にするつもりです。

従って、具体的なRoot of Trust実現方法は、STM32G4シリーズで先行、その後にSTM32G0シリーズが続くという順番になります。

TrustZone対応STM32マイコン体験セミナー（セキュリティ編）

5月22日（品川）と7月31日（大阪）に、2020年2月発売STM32L5マイコン（Cortex-M33/110MHz）を使ったSTM主催、定員30名、4時間半のTrustZone対応STMマイコン体験セミナー（セキュリティ編）が開催されます。

STM32L5は、PSA Certifiedレベル2認証を取得済みのTrustZoneマイコンです。PSA認証は、関連投稿：ARM MCU変化の背景の2章の3：セキュリティ対応をご覧ください。STM32L5のTrustZone実現は、専用のSTM32Cube拡張パッケージ：STM32CubeL5を使っています。

セミナー概要の冒頭に、「IoTセキュリティに関する法令やガイドラインの整備が進んでいます」とあり、具体的にIoTセキュリティ機能のSTM32L5への実装と必要性が解ると思います。セミナーに参加し、エキスパートから色々な情報を仕入れたいのですが、COVIC-19の影響で出張ができるか？…、Webinarなら嬉しいのですがね😅。

評価ボード付き無料セミナーです。ご興味がある方は、参加してはいかがでしょう。

STM32G0/G4のRoot of Trust(1)まとめ

Root of Trust実現に、STM32Cube拡張パッケージ：X-CUBE-SBSFUが必要。Root of Trust対応中の汎用マイコンは、STM32G0/G4シリーズ。
信頼性実現のハードウェア/ソフトウェア根幹部分をRoot of Trustと呼ぶ。
IoT機器アップデート機能義務化なら、IoTエッジ汎用MCUは、STM32G0/G4シリーズになる可能性あり。
STM32G0/G4シリーズのRoot of Trust実現方法、SB（セキュア・ブート）とSFU（セキュア・ファームウェア更新）は、UM2262を使い次回以降説明。

ここまでは、比較的簡単にRoot of Trust、X-CUBE-SBSFU、STM32G0/G4が説明できたと思います。ここからが、セキュリティの難解なところで、SBだけでも次回上手く説明できるか自信がありません。結果は、次回のブログ更新で判ります。

TI.comの新しい購入機能

2020年3月13日2020年4月30日 WithHappy

米）半導体大手テキサスインスツルメンツのサイト：TI.comに追加された新しい製品購入機能を紹介します。

TIは、アナログICやDSP（Digital Signal Processor）、本ブログ掲載の低電力動作Cortex-M4マイコンMSP432など多くの半導体デバイスや製品を開発・販売しています。ただ、競合他社と比べると、従来は個人調達に便利な通販のDigiKeyやMouserの取扱いTI製品品揃えが少ない傾向がありました。新しいTi.com購入機能は、これを改善できます。

TI.comの新しい購入機能

DigiKeyやMouserと同じように、TI.comで直接TI製品やデバイスを購入できます。違いは、TI製品のみを扱う点。もちろん価格は多少違いますが、品揃えは豊富です。下図のように、試作から生産に至るまで調達できます。

他社MCUベンダサイトのカートは、DigiKeyやMouserなどの外部通販へのリンクが一般的です。TIは、一律配送などのサービスも含めてTI自らが通販を行うという点が他社と異なる新しい機能です。

最大30個までという制限は設けていますが、個人購入や試作レベルの調達なら十分利用できます。通販会社にとっては脅威でしょう。TIは、手数料を通販会社に払うよりも、全製品の通販を自社で行う方法を選択したのだと思います。

MSP432デバイス品揃え豊富、低価格

本ブログ掲載の低電力動作MSP432評価ボード：MSP-EXP432P401R（ARM Cortex-M4F/48MHz、256KB/Flash、64KB/RAM、浮動小数点ユニット、DSPアクセラレーション）も、もちろんTI.comから購入できます。

さらに、評価ボードでの開発後、実機で利用するFlash/RAM容量が異なる様々なMSP432デバイスも購入できます。

評価ボード：MSP-EXP432P401Rは、CCS Cloud IDEやArduino IDEに似たEnergia IDEが使えるなど、他社MCU開発にないユニークなソフトウェア開発環境が特徴です。

CCS DesktopとCCS Cloud、Energia IDE比較（出典：TIサイト）

※Energia IDEの詳細は、関連投稿：MSP432オープンプラットフォーム開発環境を参照してください。
※CCS Cloud IDEの使い方は、関連投稿：CCS Cloud IDEを参照してください。

Energia IDEは初めてソフトウェアを開発する方に、CCS Cloud IDEはいつでも何処でも場所を選ばずにブサウザだけでソフトウェアを開発したい方に向いています。

また、パンデミック表明となったCOVID-19収束宣言がWHOからでるまでは当分の間、在宅勤務やMCU開発の自己研鑽時間、または数人でのテレワークMCU開発などの機会も増えるでしょう。これらにもCCS Cloud IDEは、活用できると思います。

評価ボードを使ったプロトタイプ開発は、最終的に実機で使うMCUデバイスの選択が的確にできます。つまり、実機でよりFlash/RAM容量が必要になるか、それともより低価格デバイスで製品や製品改良などにも十分賄えるかなど、製品実装MCUの選択が、プロトタイプ結果に基づいて具体的にできる訳です。

新しいTI.com購入機能は、MSP432デバイスの品揃えが豊富です。プロトタイプ開発の選択結果を反映した実機MCUデバイス調達が、直接Ti.comから低価格で可能です。通販DigiKeyやMouserの代替になりえます。

STM32CubeIDE更新、文字化け解決

2020年3月6日2020年7月18日 WithHappy

STマイクロエレクトロニクスの統合開発環境：STM32CubeIDEがv1.3.0に更新されました（2月28日、更新自動通知メールにて把握）。デフォルト設定のWindows版STM32CubeIDEは、エディタで追記した日本語コメントに文字化けが発生します。これは、昨年投稿したSTM32CubeIDE v1.1.0やv1.2.0と同じで、最新版でも解決されません。

そこで、対策にデフォルト設定を2か所変え、日本語文字化け解決を確認しました。また、Linux Debian版STM32CubeIDEとSW4STM32は、最新環境でもデフォルトで文字化けが無いことも確認しました。

Windows版STM32CubeIDE日本語文字化け発生箇所

2019年4月新登場STマイクロエレクトロニクス統合開発環境：STM32CubeIDE-Winの日本語コメント文字化けは、

SW4STM32プロジェクトのSTM32CubeIDEインポート後
プラグイン版STM32CubeMXでのコード再生成時

に、エディタでソースコードに追記した日本語コメントに文字化けが発生します。
※Windows版は、Windows 10 Pro 1909の話です。

STM32CubeIDE-Win v1.3.0日本語文字化け対策

数回のメジャー更新を経て登場後約1年のv1.3.0でも、この文字化けはデフォルトのままでは未解決です。そこで、ネット検索したところ、コチラの対策を得ました。

STM32CubeIDEのデフォルト設定を、2か所変更します。

フォント設定を、デフォルトConsolasからメイリオなどの日本語文字セットへ変更（ワークスペース毎）
Text file encoding設定を、デフォルトUTF-8からShift-JISへ変更（プロジェクト毎）

※1は、STM32CubeIDEのWindowタブ＞Preferenceダイアログ検索窓へ”font”入力＞Colors and Font選択>C/C++選択＞Editor選択＞C/C++ Editor Text Fontを選択し、Edit…クリックで左図表示
※2は、プロジェクト選択＞Propertiesクリックで右図表示

右図のようにプルダウンメニューにShift-JIS選択肢が無い時は、Shift-JISと直接入力し、Apply and Closeをクリックします。

1はワークスペース毎、2はプロジェクト毎に設定が必要です。

これら2か所の変更で、SW4STM32プロジェクトインポート後とSTM32CubeMXコード再生成時、どちらもエディタ追記日本語コメント文字化けは解決できました。

以上で、従来のSW4STM32から新しいSTM32CubeIDEへ、日本語コメント文字化け無しにSTM32MCU開発環境を移行できます。

STM32CubeIDE特徴

STM32CubeIDEは、コード生成ツール：STM32CubeMX、開発デバイスファームウェア（弊社ならFW_F0/F1/G0/G4）全てを1パッケージ化し、全て最新版のみを提供する特徴があります。投稿時のSTM32CubeIDE v1.3.0が下図です。

簡単に言うと、開発ソフトウェアが全てSTM32CubeIDEへプラグインされた形式です。

STM32CubeIDE起動時、またはCheck for Updatesにより、IDEを含めた各プラグイン更新を確認し、常に最新開発環境となります（悪名高いWindows Updateに似ているような…😅）。

これは、プラグイン版STM32CubeMX v5.6.0に、旧ファームウェア選択機能が無いことからも解ります。

最新ファームウェアを使うSTM32CubeMXプラグイン版（左）とファームウェア選択可能なスタンドアロン版（右）

例えば、顧客先で稼働中ソフトウェアへ変更を加えるなど旧ファームウェアのまま開発希望の場合は、スタンドアロン版STM32CubeMX v5.6.0を使えば、右図のように旧ファームウェア選択も可能です（関連投稿：v1.2.0の開発環境更新リスク、ファームウェア更新リスク回避策の章に背景説明があります）。

純正STM32Cubeツール

STM32MCUソフトウェア開発に使えるIDEは、下図中央のようにIAR：Embedded Workbench、ARM：Keil、AC6：SW4STM32、etc.などサードパーティ製も数多くあります。しかし、純正STM32CubeツールのSTM32CubeIDEが、STマイクロエレクトロニクス一押しの統合開発環境だと思います。

STM32 Software Development Tools（出典：STMサイトに加筆）

もちろん、従来からあるSW4STM32もまだ現役（Active）です。ST Communityには、今も多くのSW4STM32事例があります。

そこで、Windows版STM32CubeIDE以外の、SW4STM32とLinux Debian版STM32CubeIDEの現状を調べました。

STM32CubeIDE-DEB

64ビット版のみですが、STM32CubeIDE v1.3.0のLinux Debian版インストーラが、Windows版STM32CubeIDEと同じ純正ソフトウェア入手サイトにあります。

筆者は、DebianよりもMintが好きなので、STM32CubeIDE-DEBをLinux Mint 19.3 MATE (64-bit)へインストールし、デフォルト設定でも日本語文字化け無し、評価ボードで正常動作することを確認しました。

Mintへのインストール方法が下記です。途中で長いライセンス同意を求められます。

chmod +x st-stm32cubeide_1.3.0….sh
sudo ./st-stm32cubeide_1.3.0….sh、または、sudo bash st-stm32cubeide_1.3.0….sh
※NXP：MCUXpresso IDE v11.1.0のInstallation Guide, Appendix A – Linux Installationを参考にしました。

STM32CubeMXやデバイスファームウェアは、Windows版と同様全てプラグインです。Linux版SW4STM32既成プロジェクトが手元に無いのでインポートは試せませんが、問題無いと思います。

リリースノート：RN0114のLinux動作テスト環境にMintは有りません。自己責任でNXP：MCUXpresso IDE v11.1.0 Linux版ともども、Mint上でSTM32CubeIDE-DEBが正常動作したことをお知らせします。

SW4STM32とスタンドアロン版STM32CubeMX v5.6.0

SW4STM32とスタンドアロン版STM32CubeMX v5.6.0で開発環境を構築する場合は、デフォルトでも日本語文字化けは発生しません。従来環境に慣れた方は、SW4STM32もそのまま使えると思います。

お知らせ：STM32FxテンプレートとSTM32G0xテンプレート改版予定

STM32CubeIDE-Win v1.3.0に加えた本稿2か所変更が、次版以降のSTM32CubeIDEにも必要かは判りません。ただ、いまさらShift-JIS設定？という気はします。WindowsでShift-JIS継続利用の弊害は、コチラの記事がよく解ります。

しかし、懸案であった日本語コメント文字化けが解決、新登場後1年経過しv1.3.0となったこのタイミングで、従来SW4STM32から新しいSTM32CubeIDEへ開発環境を乗換えるのもチャンスだと思います。SW4STM32更新頻度が減ったことや、他の純正STM32Cubeツールとの相性良さも期待できるからです。

そこで、SW4STM32で開発・販売したSTM32FxテンプレートとSTM32G0xテンプレートを、STM32CubeIDE-Winを使って再開発に着手し、新にVersion 2として販売する予定です。進行状況などは、本ブログでお知らせします。

MCUベンダAPI生成ツール比較

2020年2月28日2020年3月6日 WithHappy

お知らせ

弊社サイト：マイコンRTOS習得を2020年版へ改版しました。前稿までのFreeRTOSサンプルコード(1)～(5)結果を、2017年版へ反映させた結果です。是非、ご覧ください。

MCUベンダAPI生成ツール一覧

FreeRTOSサンプルコード(1)で予告したベンダ毎に異なるAPI生成ツールやその違い、サンプルコードとの関係を説明します。本ブロブ掲載MCUベンダ5社のAPI生成ツール一覧が下表です。

MCUベンダトップシェア5社のMCU API生成ツール一覧
ベンダ	API生成ツール	ブログ掲載MCU	API生成方法
Runesas	CS+	RL78/G1x	個別ハードウェア設定
NXP	SDK	LPC111x/LPC8xx/Kinetis E/LPC5411x	MCU設定
STM	STM32CubeMX	STM32Fx/STM32Gx	個別ハードウェア設定
Cypress	PSoC Creator	PSoC4/PSoC4 BLE/PSoC4000/PSoC6	個別ハードウェア設定
TI	CCS	STM432	MCU設定

IDEとは別のAPI生成ツール専用名があり、ツール単独で更新するのが、NXP）SDK、STM）STM32CubeMXです。Runesas）CS+、Cypress）PSoC Creator、TI）CCSは、IDEにAPI生成ツールが組込まれていますので、IDE名称をAPI生成ツール欄に記載しています。
※CS+のAPI生成ツールは、単独でコード生成と呼ぶこともあります。

さて、これらAPI生成ツールには、2種類のAPI生成方法があります。

MCU設定：利用MCUを設定し、内蔵ハードウェアAPIを一括生成…NXP）SDK、TI）CCS
個別ハードウェア設定：利用内蔵ハードウェアを個別設定し、APIを生成…Runesas）CS+、STM）STM32CubeMX、Cypress）PSoC Creator

MCU設定タイプのAPI生成ツールは、全内蔵ハードウェアAPIを、ユーザ利用の有無に係わらず一括生成するため、規模が大きく、SDK（Software Development Kit）などパッケージ化してIDEへ提供されます。但し、コンパイル時に利用ハードウェアのみをリンクしてMCUへダウンロードするので、少Flashサイズでも問題はありません。

MCU設定タイプの特徴は、例えば、UART速度設定などのハードウェア動作パラメタは、APIパラメタとしてMCUソースコードにユーザが記述します。

一方、個別ハードウェア設定タイプは、UARTなどのハードウェア動作パラメタは、API生成前にGUI（Graphical User Interface）で設定し、設定後にAPIを生成します。このためユーザが、MCUソースコードのAPIに動作パラメタを追記することはありません。

API生成ツール比較

MCU設定タイプのAPI生成ツールは、使い方がMCU設定のみで簡単です。また、ハードウェア動作パラメタがMCUソースコード内にあるため、動作変更や修正もIDE上で行えますが、人手によるバグ混入の可能性も高まります。

個別ハードウェアタイプAPI生成ツールは、MCUソースコード内のAPI記述が簡素です。生成されたAPI内部に動作パラメタが含まれているからです。但し、ハードウェア動作変更には、IDEから一旦API生成ツールに戻り、APIの再生成が必要です。この場合でも、MCUソースコードは不変ですので、GUI設定にミスが無ければバグ混入は少ないでしょう。

どちらにも、一長一短があります。敢えて分類すると、ソフトウェア開発者向きが、MCU設定タイプ、ハードウェア開発者向きでTP：Test Program応用も容易なのが、個別ハードウェア設定タイプです。

個別ハードウェア設定タイプであっても、Cypress）PSoC Creatorなどは、通常パラメタはBasicタブ、詳細パラメタはAdvanceタブで分け、誰でも設定を容易にしたツールもあります。

MCUソフトウェアは、C言語によるMCU API制御です。MCU API生成ツールの使い勝手が、ソフトウェア生産性の半分程度を占めていると個人的には思います。

サンプルコード/サンプルソフトウェア

各社のサンプルコード/サンプルソフトウェアは、上記API生成ツールのMCUソースコード出力例です。

従って、サンプルコードには、出力例と明示的に判るよう多くのコメントが付加されています。初めてサンプルコードを見る開発者は、注意深くコメントを読んで、そのMCU開発の全体像を理解することが重要です。

全体像が理解済みであれば、より効率的な開発手法、例えば、（推薦はしませんが）個別ハードウェア設定タイプであっても、IDEからAPI生成ツールに戻らずに、直接MCUソースコードでハードウェア動作パラメタを変更するなどのトリッキーな使い方も可能です。

MCU開発とCOVID-19

新型コロナウイルス：COVID-19が世界的に流行しつつあり、工場閉鎖や物流への影響も出始めています。現状は治療薬が無いので、「個人の免疫力と体力」が生死の決め手です。

同時にMCU供給不足/停止など、開発への波及も懸念されます。これに対し「個人で第2のMCU開発力」を持つことが解決策を与えます。

本稿は、MCUベンダトップシェア5社のMCU API生成ツールを比較しました。MCUシェア、評価ボード価格や入手性、個人の好みなど、是非ご自分にあった比較項目で、現在利用中のMCUに代わる第2のMCU開発力を持つことをお勧めします。

第2のMCU開発力は、現行と視点が変わり利用中MCUスキルも同時に磨くことができ、様々な開発リスクに耐力（体力）が付きます。短期で効果的な第2のMCU開発力の取得に、弊社マイコンテンプレートがお役に立てると思います。