IoT MCUのHappyTech

STM32デモソフトから見える問題点

2017年6月19日2017年8月3日 WithHappy

STM32Fxシンプルテンプレート

前回記事で予告しました、弊社マイコンテンプレートを使い、STM32評価ボードのデモソフトへUART-USB通信機能を追加しました（下記仕様参照）。

デモソフトのSW押下げの代わりに、評価ボードとパソコン間のUART-USB通信コマンドでLED点滅速度を変えます。これをマイコンテンプレートのSTM32F0マイコンへのシンプルな応用例という意味で、STM32Fxシンプルテンプレートとします（年内に既存マイコンテンプレートと同様、Baseboardテンプレートと合わせSTM32Fxマイコンテンプレートとして1000円で販売予定）。

STM32Fxシンプルテンプレート仕様
・動作確認評価ボード：STM32F072RB（Cortex-M0）
・LED出力：評価ボード実装緑LED LD2点滅速度をUART-USBコマンドで変更
・SW入力：評価ボード実装青ユーザSW（ソフトチャタリング対策済み）PushをUART-USBで表示
・UART-USB通信：TeraTermなどのターミナルソフトへメッセージ入出力（19200bps 8-Non-1）
・低電力動作：Sleep処理
・使用ライブラリ：HAL

STM32評価ボードデモソフトから見えるサンプルソフトの問題点

STM32評価ボードのデモソフトは、マイコンサンプルソフトの問題点を示しています。この問題点は、マイコンサンプルソフト全般に言えます。

サンプルソフトの問題点とは、1つの機能を、初期設定と無限ループを使って説明する点です。この方法は、初心者が単独機能を理解する際には、動作が解り易く、優れています。

しかし、実際のアプリケーションでは、複数の機能が並列的に動作するのが普通です。実アプリケーションの［複数並列（的）動作］と、サンプルソフトの［無限ループ単独動作］とのギャップが大きいことが、マイコン初心者にとっての大きな障壁です。

結論から言うと、サンプルソフトの解り易さに貢献している無限ループの時間消費（浪費）が問題です。

デモソフトの具体例

具体的にSTM32評価ボードのデモソフトで説明します。無限ループ内のLED点滅処理が下図です。

LED点滅速度は、SW割込みのCallback関数で変えます。このサンプルソフトは、LED出力とSW入力が並列動作しています（サンプルソフトとしては、SW割込みを使う点で珍しい例）。

LED点滅処理を繰り返すのが、無限ループの目的です。１ループのLED処理は、500/100/50ms毎に1回トグルを実行し、その他の時間は、HAL_Delayで時間消費（浪費）です。殆どのサンプルソフトは、この構成です。

つまり、

典型的サンプルソフト ➡［単独処理＋時間浪費］の繰り返し

これにより1つの機能を説明する構成です。この方法は、説明の受け側にとっては、解り易いものです。単独処理の中身は、ポーリングが多いのも特徴です。ポーリング結果で、別処理へジャンプするなどします。

別処理の無限ループへの追加

STM32評価ボードのデモソフトは、割込みでSW入力の別処理を追加しています。しかし、無限ループへ、割込み以外で別処理を追加するのは困難です。なぜなら、［単独処理＋時間浪費］へ別処理を追加するには、時間浪費の時間を変えるしか手がないからです。

時間浪費の時間を変えたとします。すると、［単独処理＋追加処理＋変更した時間浪費］となり、既に存在したLED点滅処理の点滅間隔が変わる可能性が生じます。

つまり、処理追加により既存処理へも影響が及ぶのです。厳密には、割込みでも既存処理へ影響が及びますが、その影響は極わずかです。

処理追加で既存処理に影響が及ぶので、追加前の既存処理単独でのデバッグが無駄になります。デバッグの積み重ねができないのです。

それならば、いつも割込みで処理を追加すれば良いかというと、そうでもありません。

割込み処理は、ポーリングに比べデバッグが難しくなります。また、割込み処理のサンプルソフトは、ポーリングに比べ少数です。

サンプルソフトは、単独動作の説明に重点を置いたポーリング動作のものが多数で、実アプリケーション開発へ、そのままでは使いにくい構成、構造になっていることがお判りになったと思います。

弊社マイコンテンプレートの対策

デモソフトのLED点滅処理に着目したのが、弊社マイコンテンプレートです。500ms、100ms、50ms毎に1回処理し、その他の時間は、別処理、低電力処理（Sleep処理）を時分割で処理します。

つまり、

弊社マイコンテンプレート ➡ ①［単独処理］終わり
＿＿＿＿＿＿＿＿＿＿＿＿ ➡ ②［別処理］終わり
＿＿＿＿＿＿＿＿＿＿＿＿ ➡ ③［低電力処理］終わり
＿＿＿＿＿＿＿＿＿＿＿＿　　①～③の繰り返し

簡単に言うと、時分割の無限ループランチャーです（起動される①側からみると、単独で無限ループ内にあるのと同じ、②、③も同様）。複数処理を起動する仕組みをテンプレート自体が持っているとも言えます。

RTOS: Real Time Operating systemを使うと複数処理起動が簡単です。しかし、RTOS理解のオーバーヘッドが必要です。弊社マイコンテンプレートは、簡易的に処理を並列に起動します。

起動される側の処理は繰り返し起動されますので、ポーリング動作のサンプルソフトの多くがそのまま流用できます。数多くあるポーリングサンプルソフトを活用、流用してアプリケーションの早期開発ができるのが、弊社マイコンテンプレートの特徴です。

また、STM32Fxシンプルテンプレート仕様から解るように、実アプリケーションに最低限必要な、低電力処理、LED出力、SW入力、UART-USB通信の各処理は既にシンプルテンプレートに実装済みです。

このシンプルテンプレートへ実用アプリで必要となる処理を追加しさえすれば、直ぐに最終段階アプリとなる構成になっています。プロトタイピング開発に適し、実アプリケーションとサンプルソフトとのギャップを小さくします。

もちろん処理を追加や削除しても、既存処理への影響が小さいので、デバッグの積み重ねもできます。

STM32CubeMX生成ファイルのユーザ処理追記箇所

2017年6月12日2017年8月16日 WithHappy

STM32CubeMXが生成するプロジェクトと自動生成ファイルのユーザ処理追記箇所を解説します。STM32マイコンのソフト開発は、この出力ファイルへ、ユーザ処理コードを追記して完成しますので、どのファイルのどこに追記すれば良いかを知ることが重要です。

前回記事でSTM32CubeMXの使用ライブラリにHAL: Hardware Abstraction Layerを選びました。UM1718の５章に、HAL単独、LL単独とHAL/LL混合の各ライブラリ使用時のSTM32CubeMX生成ファイル詳細説明があります。本ブログ記事は、このHAL単独版に相当します。

STM32CubeMXの設定条件

STM32CubeMXは、設定により出力プロジェクトの生成ファイルが様々に異なりますので、STM32マイコンテンプレート開発で使う下記条件でコード生成します。

前提条件

評価ボード：STM32F072RB（ARM Cortex-M0）
3ウイザード：Pinout、Clock Configurationは評価ボードデフォルト設定、ConfigurationはEXTI line 4 to 15 interruptsに☑設定
使用ライブラリ：HAL

出力プロジェクトとユーザ処理追記が必要なファイル

STM32CubeMXの出力プロジェクトのうち、ユーザ処理を追記する必要があるファイルは、Inc（ヘッダーファイル）とSrc（ソースファイル）にあります。これらInc/Srcフォルダ内のファイル概要とユーザコード追記箇所の有無一覧が下記です。

USER CODE Add in for STM32CubeMX Project
フォルダ＞ファイル		概要	ユーザ処理追記箇所	STM32CubeMX再生成時
Src	main.c	main処理（動作クロックとHAL初期設定生成コード含む）	あり	ユーザ処理以外上書き
	stm32f0xx_it.c	割込み処理（EXIT1 4_15）	あり（自動割付済み）
	stm32f0xx_hal_msp.c	HAL MSP処理とエラー処理	あり（可能性は低い）
	system_stm32f0xx.c	システムクロック設定	なし
Inc	main.h	IOピンのラベル定義	あり（Pinoutウイザード設定分のみ）	完全上書き
	stm32f0xx_it.h	割込み定義	なし
	stm32f0xx_hal_conf.h	HAL構成定義	なし

Incフォルダのmain.hユーザ追記部分は、Pinoutウイザードでピン名を追加した分のみです。つまり、ウイザード出力があるだけで実質ユーザ追記は不要です。STM32CubeMXで再度コード生成した場合は、ヘッダーファイルは全て上書きされます。

従って、再生成してもユーザ追記コードが残るのは「あり」で示した、main.c、stm32f0xx_it.c、stm43f0xx_hal_msp.cのSrcフォルダ内の3ファイルです。

このうちstm43f0xx_hal_msp.cは、HALライブラリのMSP: MCU Support Package処理（≒ハード抽象化）やエラー処理ファイルですので、通常はユーザが追記する可能性は低いと思います。

結局、ユーザ処理の追記が必要なファイルは、Srcフォルダのmain.cとstm32f0xx_it.c（割込み処理）の２ファイルです。

ユーザ追記コード（割込み処理）

先ず、割込み処理を説明します。

HALライブラリを使うと、割込みの前処理（割込み要因フラグ確認、フラグリセット、ユーザ処理関数callback）は、全てSTM32CubeMXが自動生成する割込みハンドラが行います。但し、この割込みハンドラ名には、HAL_という接頭語が付いていて、コアの割込みハンドラ名と異なるため、コア割込みハンドラと生成割込みハンドラの対応付けが必要です。

このハンドラ名称の対応付けを行うのが、stm32f0xx_it.cです。評価ボードのデモソフト（STM32マイコン統合開発環境参照の5）動作検証参照）の例で示すと、stm32f0xx_it.cの下記部分です。但し、この割付は、ConfigurationウイザードでEXTI line 4 to 15 interruptsに☑設定した結果、自動割付済みです。つまり、ここもウイザード出力結果が反映されていて、実質ユーザ追記が不要です。

ハンドラがコールするユーザ処理関数は、Callback以外がハンドラ名と同じHAL_GPIO_EXIT_Callback()という関数名というSTM独自の決まりがあります。このCallback関数は、main.c内にあり下記部分です。

まとめると、割込み処理は

EXTI4_15_IRQHandler()は、　　　　コアの割込みハンドラ（startup_stm32f072xb.sに記述）
HAL_GPIO_EXTI_IRQHandler()は、　 STM32CubeMX自動生成の割込みハンドラでHAL_GPIO_EXTI_Callback()をコールバック
HAL_GPIO_EXTI_Callback()は、　　　ユーザが追記する割込み処理でmain.cに処理内容を追記

という3段構成なので、最終的にユーザが追記する割込み処理の箇所は、Callback()の中身つまりmain.cのみです。

ユーザ追記コード（割込み処理以外）

当然main.cは、割込み処理以外にも、様々なユーザ処理を追記します。STM32CubeMXが自動生成する「ナマ（生）のmain.c」を以下に示します。

ユーザ追記箇所を解り易くするために、ソースを折りたたんでいます。先に示した割込み処理HAL_GPIO_EXTI_Callback()の追記箇所は、ソース構造から、USER CODE BEGIN 4の個所であることが判ります。

/* USER CODE BEGIN xyz */から/* USER CODE END xyz */のコメント間にユーザ処理を追記すれば、STM32CubeMXで再生成しても追記部分は、そのまま残ります。

USER CODE xyzのコメントを読んで、追記が必要なユーザ処理を追加していきます。但し、GPIOやシステム動作クロックの初期設定は、STM32CubeMXが自動生成済みですので、更なる追記は、本当にユーザ処理の部分のみということが判ります。デモの場合なら、LED2の点滅速度変更処理LED2_Blink()のみです。

以上をまとめると、STM32CubeMXが自動生成するプロジェクトとファイルへは、

3ウイザードさえ間違わずに設定すれば、main.cのみの最小限ユーザ追記でアプリ完成
たとえウイザード設定に間違えても修正し再生成すれば、USER CODE xyzへ追記したユーザコードは保持され安心

STM32CubeMX自動生成の活かし方

プログラムサイズが大きい場合には、全てのユーザ追加ソースを1つのmain.cファイルに記述するのは現実的ではありません。しかし、単機能のサンプルソフト程度であれば、STM32CubeMXが自動生成するmain.cへユーザ処理を追記してもさほど可読性は悪くなりません。

STM32CubeMXは、STM32マイコンソフトを効率的に開発するツールです。なるべく小さく単機能ソフトをSTM32CubeMXで開発し、単体でバグが取れた後に、各機能を結合して目的のソフトへ仕上げるのが、STM32CubeMX自動生成出力を活かす方法です。

この活かす方法を使って次回は、評価ボードUART入出力をUSB経由でパソコンと繋げるUART-USB（VirtualUART）機能と、評価ボードデモの2つを結合し、パソコンコマンドでボードのLED点滅速度を変えるソフト開発の話をする予定です。これは実は、STM32マイコンのシンプルテンプレートに相当します。ご期待ください。

※固定ページ（本ブログの上部タブリンク）を、CurieからSTM32Fxマイコン開発へ全面変更いたしました。

STM32CubeMXの使い方

2017年6月5日2017年6月7日 WithHappy

STM32マイコンのソフト開発を早く効率的にするのが、STM32CubeMXです。コード生成ツールのSTM32CubeMXの概要、使い方を示します。

STM32CubeMXの使い方ビデオ

STMが提供するSTM32CubeMX解説ビデオは、このページの右に2つあります。STM32CubeMX – Overview (6:44)とGetting Start with STM32CubeMX (9:12)です。Overviewを見ると概要が、Getting Startを見ると、5つの使いこなしポイントが判る（かも？）という内容です。STM32CubeMXのマニュアルUM1718もページ下にあります。

この2ビデオとUM1718、その他の関連資料から、私なりにSTM32CubeMXの要点、使い方を纏めましたので以下に示します。

STM32CubeMXのウイザード

STM32CubeMXは、4IDE（SW4STM32ほか3種IDE、前回記事参照）へプロジェクトファイルと初期設定（クロック設定と周辺回路）Cソースコードを自動生成します。この生成の基になるのがPinout、Clock Tree、Peripheral & Middlewareの3ウイザードです。

Power Consumptionウイザードは、生成時の消費電力を評価する計算ツールです（使用例はコチラを参照）。

STM32CubeMXの3ウイザード設定後、コード生成（Ctrl ＋ Shift ＋ G）実行で指定先へプロジェクトファイルが出力され、これをSW4STM32でImportすれば、初期設定コード付きのプロジェクトが得られます。

従って、残りのユーザ処理をプロジェクトへ追加していけば、アプリ完成という段取りです。

STM32CubeMXの2種ドライバライブラリ

注意点は、デフォルトでSTM32CubeMXが生成するのは、HALドライバライブラリを使ったプロジェクトだということです。勿論LLドライバライブラリでの生成も可能ですが、この場合は、初期設定ソースコードが自動生成されません。LLライブラリ利用の場合は、ユーザが初期設定コードも書く必要があります。

つまり、STM32CubeMXでLLドライバを使うと、SW4STM32で、初期設定とユーザ処理の両方をプロジェクトに追記しなければならず、しかも、各LLドライバ分解能はHALに比べて低いので、より多くのLL APIを使った追記が必要です。

HALとLLは、UM1749（全1466ページ）に詳しい説明があります。
HAL: Hardware Abstraction Layerとは、文字通りハードウエアを抽象化し、より簡単に周辺回路制御ができるAPIをユーザ側へ提供します。
一方、LL: Low Layerは、速度優先でエキスパート向けのAPIですので、高速ですが移植性や可読性はHALよりも低くなります。

HALとLLのAPIを相対比較した表が下記です。

追記コードはHALの方が少なくても、実際はHALの方が抽象化オーバーヘッドの分だけコンパイル後のコードサイズは大きくなります。プログラムにもよりますが、その差は60～80％だそうです。LLを使うとこのサイズが小さい分だけ高速処理が可能ということです。

STM32CubeMXでLLを使って生成するプロジェクトファイルは、本当の意味でフレームワークのみです。

Peripheralウイザード設定の目的は、SW4STM32のAPI入力支援機能を活用するためです。例えばコード記述中、LL_DAC_まで入力後、Ctrl ＋ spaceを押すと、可能性があるLL APIがリストで選べます（HAL APIも下記のように同様）。Visual StudioのIntellisence機能のマイコン版に相当します。

Intellisence (Ctrl + Space) and USER CODE BEGIN to END

このIntellisenceが表示するAPIは、当該周辺回路の全てのAPIを示すと思います。全てのAPIから使えるAPIを選ぶには、Peripherals & Middlewareウイザードの設定意味が解っている必要があるでしょう。

再度STM32CubeMXでコード生成し、プロジェクトファイルを作り直しImportしても、ユーザ追記部分を残すためには、USER CODE BEGINからUSER CODE ENDまでのコメント間に記述します。これは、Runesas CS+のコード生成と同じです。

STM32マイコンテンプレートはHALドライバライブラリを使用

使用するドライバライブラリは、60～80%の高速性か、ポータビリティかの選択です。STM32マイコンは、ROM/RAMが大容量なこと、コア速度も速いこと、STM32CubeMXもデフォルトでHAL使用することから、STM32マイコンテンプレート開発にも、HALライブラリを使います。

これにより、当初の目的であった機種特定を避けCortex-M0/M0+コアのSTM32F0/L0や、Cortex-M3のSTM32F1などのSTM32マイコン全てに使えるベアメタルマイコンテンプレートを開発します。

＊　　＊　　＊

ここまでが、STM32CubeMXコード生成の使い方です。使用ライブラリにHALを選べば、初期設定Cソースコード付きのSW4STM32プロジェクトが作れます。

ビデオや各種資料もここで終わるものが多いのですが、ソースにユーザ処理の追加が残っています。このユーザ処理の参考にすべきなのが、STM32CubeMXのRepositoryフォルダで提供される周辺回路毎のサンプルソフトです。

STM32CubeMXサンプルソフトの使い方

前回記事Figure4に示したExampleで提供されるのが、HALライブラリ使用のサンプルソフトです。Example_LLはLLライブラリ利用サンプル、Example_MIXは、HALとLLの混合サンプルを示します。

いずれのサンプルも、4IDEで使える構成になっているのは、前回記事の通りです。

サンプルソフトがSTM32CubeMXを使って作られたものなら、そのまま利用できるのでBestですが、残念ながら専門家、人が開発したプロジェクトです。しかし有力なサンプルであることに違いはありません。

従って、使う周辺回路が決まったら先ずこのExampleで使用例を大体でも知ったうえで、コード生成するのが本来のSTM32CubeMXの使い方手順だと思います。この前処理抜きでPinout、Clock Tree、Peripheral & Middlewareの3ウイザードを正しく設定できれば別ですが、分厚いマニュアルを読むよりは効率的だと思います。

まとめ

私は、STM32CubeMXは、コード生成とRepository内のサンプルソフトの両方を、車の両輪のように同時に使うことでSTM32マイコンのソフト開発が早く効率的になると思います。

効率的なSTM32CubeMXの使い方は以下です。

1) Repositoryフォルダから使用する周辺回路とライブラリに応じたサンプルソフトを探し、おおよその利用法、特にユーザ処理を知る（サンプルソフトファースト）
2)コード生成Pinout、Clock Tree、Peripheral & Middleware各ウイザードを出来るならサンプルソフトと同じ設定にし、コード生成を実行（デフォルトはHALライブラリを使うことに注意）
3)生成されたプロジェクトをIDEにImportし、ユーザ処理を1)のサンプルソフトを参考にUSER CODE BEGIN～ENDの間に追記し、デバッグ
4)再度コード生成しても3)で追記したユーザ処理は残る（但し、ヘッダーファイルは完全に上書きされるので注意）

STM32マイコンテンプレートは、STM32CubeMXのHALドライバを使い、MCUコア依存性が少ないベアメタルテンプレート開発にする方針を立てました。STM32マイコンテンプレートの目的を知りたい方は、弊社マイコンテンプレートサイトをご覧ください。

STM32マイコン統合開発環境：SW4STM32の構築

2017年5月28日2018年5月4日 WithHappy

STM32マイコンの統合開発環境: IDEは、EWARM、MDK-ARM、TrueSTUDIO、SW4STM32の4種類から選びます。

EWARM：IAR社Embedded Workbench for ARM。汎用IDE。無償版32KBコードサイズまで。
MDK-ARM：Keil社Microcontroller Development Kit for ARM。汎用IDE。無償版32KBコードサイズまで。
TrueSTUDIO：Atollic社Eclipse ベースSTM32専用IDE。無償版コードサイズ制限なし。
SW4STM32：仏）AC6社マルチOS EclipseベースSTM32専用IDE。無償版コードサイズ制限なし。本ブログはWindows版で説明。

STM資料は、これら4種IDEを併記していますので、英文量が増えます。4IDE同時に使う人はいませんので、自分が使うIDEの説明箇所のみを拾い読めば十分です。4IDE併記は、全てのSTM資料に共通ですので覚えておくと良いと思います。

また、コード生成ツールSTM32CubeMXも、4IDE対応で作られておりIDE名称を知らないとフォルダ名に戸惑うことになります（後で示すFigure3や4参照）。

今回は、これら資料の特徴を知ったうえで、SW4STM32へコード生成ツールSTM32CubeMXをプラグインしたSTM32マイコンテンプレート統合開発環境の構築と、評価ボードを使った構築環境の検証までを示します。

SW4STM32統合開発環境構築手順

前回記事に示したように、STM32テンプレート開発環境は、IDEにSW4STM32、評価ボードにNUCLEO STM32F072RBを使います。

1) SW4STM32インストールとUpdate
2) STM32CubeMXプラグインとUpdate
3) STM32CubeMXへ評価ボードMCUコアのライブラリダウンロード
4) ライブラリ（サンプルソフトとドライバ）のファイル構成確認
5) 評価ボードデモソフト説明と構築環境の動作検証

1)～5)がこの開発環境の構築手順です。上手く構築できたかどうかを、評価ボードデモソフトに変更を加え検証します。手順の内容を示します。

１）SW4STM32インストールとUpdate

最新版SW4STM32は、OpenSTM32 Communityページ中頃のdownload areaからダウンロードします（要ログイン）。旧版ではUpdateで最新版へ更新できる場合とできない場合がありますので、最新版のダウンロードをお勧めします。最新版へ更新できない時は、その旨の親切なメッセージが、Update実行後に出力されます。

SW4STM32のインストールは、ダウンロードインストーラの実行だけですので、特に問題ないと思います。忘れてはいけないのは、最新版（今日現在v2.0）でもインスト後、Updateが必要な事です。トラブル回避の為にも、SW4STM32のHelp>Check for UpdatesでIDE更新を実行後、次の手順へ進むようにしてください。

２）STM32CubeMXプラグインとUpdate

STM32開発で使うコード生成ツールSTM32CubeMXのプラグインインストール方法は、UM1718の3.3を参照してください。これも記載手順で行えば、問題なくできます。インストール後、3.4.3と3.5～3.5.1を参照し、STM32CubeMXのUpdateを行います。

３）STM32CubeMXへ評価ボードMCUコアのライブラリダウンロード

評価ボードMCUコアは、ARM Cortex-M0です。これをSTMは、STM32F0シリーズと呼びます。MainstreamのFx: x=0/1/2/3/4/7シリーズがCortex-M0/M3/M4/M7、ultra-Low-powerのLx: x=0/1/4シリーズがCortex-M0+/M3/M4コアを使います。F3≠M3なので注意してください。

UM1718の3.5.2のライブラリ選択で、STM32CubeF0の1.8.0版を選択し、Install Nowでサンプルソフトとドライバ等がIDEへインストールされます。最新版（STM32CubeF0の場合1.8.0）インストールで旧版分も含むので最新版のみでOKです。

今日現在は、1.8.0のパッチパッケージは無いので、以上の手順で、SW4STM32とSTM32CubeMXプラグイン設定が完了し、統合開発環境：IDEの構築は完成です。後は、UM1718の6～10に使用例がありますので、これらを習得すればSTM32開発ができます。

４）ライブラリ（サンプルソフト）の構成確認

３でインストールしたサンプルソフトやドライバは、デフォルトではドキュメントフォルダではなく、下記STM32Cubeフォルダになります。

C:\Users\ユーザ名\STM32Cube\Repository

ドキュメントフォルダ等へ変更したい方は、STM32CubeMXのUpdater Settingsで場所を変更してください。

このRepository内に、ダウンロードしたSTM32F0シリーズのZipファイルとこれを展開したファイルが同居しています。STM32CubeF0_V1.1.0の展開ファイル例が下記です。

Figure 4は、Figure 3のProjects/STM32F072RB-Nucleo下の構成を示します。Figure 3のドライバ（＝Drivers）やFigure 4のサンプルソフト（＝Examples）を活用すれば、アプリケーションの早期開発ができます。弊社STMテンプレートもこれらを使います。

注意点として、評価ボードNUCLEO STM32F072RB 以外のボードや、SW4STM32以外のIDE、つまりEWARMやMDK-ARMやTrueSTUDIOのUtilities等も含まれていることです。これらは、NUCLEO STM32F072RB（STM32F072RB-NucleoとFigure3表記）とSW4STM32を使う限りは不要です。
※STM資料もそうでしたが、STMソフトもまた4つのIDEや動作する全評価ボードに1ソフトで対応するように作られているので、上記のように使わないものが含まれています。

サンプルソフトの使い方は、UM1779の4.1にSW4STM32の記載があります。

５）評価ボードデモソフト説明と構築環境の動作検証

評価ボード購入直後、電源を入れると収納ケース裏GETTING STARTED記載の緑LED LD2が点滅し、その点滅間隔がB1ボタンを押す度に50/100/500msと変わるデモソフトが起動します。このデモソフトソースが、Figure 4のDemonstrations内にあります。そこで、このデモソフトを構築した環境へImportし、点滅間隔を変えることで環境が正しく構築されたかを検証します。

UM1787: STM32CubeF0 Nucleo demonstration firmwareにデモソフトの詳細が示されています。評価ボードに下図Arduinoシールドを装着すると、ジョイスティックやLCD表示も可能です。

デモソフト緑LED LD2の点滅箇所を抜粋したソースを示します。

簡単に説明すると、シールド未実装の場合はLED2_Blink()が実行され、BSP_PB_Init()で設定された割込みでHAL_GPIO_EXTI_Callback()が実行されBlinkSpeedをインクリメント、HAL_Delay()で点滅間隔が変わる、となります。

そこで、main.cのL574のHAL_Delay(500)をHAL_Delay(1000)などへ変更し、ビルド→デバッグでLD2の点滅間隔が変われば、構築した開発環境が正しく構築できたことを、評価ボードを使って検証できます。perspectiveをデバッグに切換えた画面を示します。

デバッガ接続に万一トラブルが発生した場合には、Run>Debug Configurations…で、STM32F072B0-Nuclei.elfを見つけてください。他の設定は、デフォルトで問題ありません。

デバッグ中は、評価ボードST-Link部実装の2色LED（赤緑）がキラキラして眩しいです。

SW4STM32の使い勝手は、画面切り替えにperspectiveクリックが必要など、NXPのMCUXpressoと比較すると、やや劣る操作性です。素のEclipse IDEに近いのだと思います。

さいごに

STMマイコンは、他社比ROM/RAM容量が大きいわりに低価格です。CMSISやHALを使うと、これぐらいの大きさが必要になるのだと思います。CMSISやRTOSが普及し始めると、Cortex M系コア性能に依存しないソフト開発ができるので、既に第5位ですが更に脚光を浴び始めるベンダかもしれません。

mbedでも使える評価ボードの入手性も良いので、今のうちに個人レベルで習得すると、慌てずに済むお勧めMCUです。

STM32評価ボードNUCLEO-F072RB選定理由

2017年5月25日2017年5月29日 WithHappy

STM32マイコンテンプレートを開発するにあたり、秋月電子さん販売中の多くのSTM32評価ボードのうち、Cortex-M0のNUCLEO-F072RBとCortex-M3のNUCLEO-F103RBを選びました。今回は、この選定理由を示します。

STM Evaluation Boards and MCUs Performance

NUCLEO-F072RB選定の理由（ARM Cortex-M0）

STMサイトに散りばめられたSTM32 MCU情報から、NUCLEO-F072RB選定の決め手となった資料が下記4つです。UM: User Manual、AN: Application Noteです。

1) UM1779          Getting started with STM32CubeF0 for STM32F0 Series
2) AN4735           STM32Cube firmware examples for STM32F0 Series
3) UM1718          STM32CubeMX for STM32 configuration and initialization C code generation
4) UM1727          Getting started with STM32 Nucleo board software development tools

1)はボード毎に提供されるサンプルソフト数を記載し、STM32F072RBが134個と断トツに多いことが判ります。STM32F072RBとは、NUCLEO-F072RB実装MCUです。MCU/ボードの混在表記なので注意が必要です。2)は、1)のサンプルソフト詳細内容が示されています。

3)は、2)のサンプルソフトを生成するコード生成ツールSTM32CubeMXのユーザマニュアルで、スタンドアロンやEclipse IDEプラグインなどの3動作モードと使用法が書かれています。4)は、STM32MCU開発に使える4IDEの紹介です。

これら資料から、STM32マイコンテンプレートの開発環境を以下としました。

・評価ボード：　NUCLEO-F072RB（64ピンSTM32F072RBT6実装、ROM 128KB/RAM 16MB、DAC/CAN/USB等）
・統合開発環境：SW4STM32（無償版コード生成サイズ制限なし）＋STM32CubeMxプラグイン

※KeilのuVision（MDK-Lite）は、STM32F0/L0専用ライセンスを使うとコードサイズ256KBまで利用可能です。しかし、F0/L0専用となりSTM32F1開発（NUCLEO-F103RB選定理由参照）には残念ながら使えませんのでやめました。F0/L0のみ開発をする方は、2018年2月までの期間限定のようですが、無料で全機能使えます（少し使ってみた感想はエディタが貧弱ですがまあまあという感じです）。

数種類の評価ボードが簡単に入手できても、STM提供サンプルソフト数が少ないものもあります。弊社マイコンテンプレートは、これらサンプルソフトが簡単に組込めることを特徴としますので、サンプル数の多さは、テンプレート活用機会も多くします。

以上のことから、STM32マイコンテンプレート開発環境を決めました。

STM32マイコンテンプレート開発方針

これら4つ以外にも、様々な有用資料（例えばAN4617：Migrating between STM32F0 and STM32L0 microcontrollersなど）がサイト内に散りばめられていて、ハッキリ言ってCypressサイトなどと比較すると、平面的で資料が見つけにくいサイト構成です。応答速度も遅いです。
しかし、掲載資料は、いずれも優秀なエンジニアが書いたものと思われ、英文量は多いものの中身は良好です。

STM32マイコンテンプレート開発では、このSTMサイトリンクもブログ記事に積極的に掲載しようと思います。私の下手なブログ記事を読むより、STMサイトへ直接アクセスする方が良い読者も多いと思うからです。その結果、2016年マイコン売上5位の実力を持つSTM MCUを使う弊社STMマイコンテンプレートのご購入者が増えることも期待もしております。

NUCLEO-F103RB選定の理由（ARM Cortex-M3）

これまで弊社テンプレート対象MCUは、Cortex-M0/M0+クラスでした。しかし、前回記事に記載したようにRTOSやCMSIS普及を考慮すると、このクラスに拘る必要が薄くなってきました。

MCU価格では、Cortex-M4のSTM32F303K8T6が410円、Cortex-M0のSTM32F042K6T6が250円とややM4が高いものの、ここで使うM0/M3評価ボード価格は、どちらも1500円で同じです（2017年5月秋月販売価格）。

製品の大きさが許せば、評価ボードをそのまま製品へ実装するというのは、いつも私が考える製品構想です。評価ボードが同価格なので、コア性能が不足しても、ホードごと載せ替え可能で安心です。STM32評価ボードは、UM1724: STM32 Nucleo-64 boardで詳細が解ります。

しかも、STM32ソフトウエアスタック（UM1779掲載）から、コアクラスの依存性が低いテンプレート作りも可能だと思います。つまり、LL: Low Layerの代わりにHAL: Hardware Abstraction Layerを使ってテンプレート開発すれば、STM32F0（Cortex-M0）以外にSTM32F1（Cortex-M3）、他のコアへも適用できると考えるからです。

この可能性を検証するために選んだCortex-M3評価ボードが、NUCLEO-F103RB（64ピンSTM32F103RBT6実装、ROM 128KB/RAM 20MB、CAN/USB等）です。勿論、LLの方が高速処理可能でしょうが、HALの移植性の高さも捨てがたい利点があります。

そこで、STM32マイコンテンプレートでは、あえてF0やF1などと対象コアを明記せず、両方に対応できる（と今は思っている）HAL版テンプレートと、速度重視のLL版テンプレートの両方を開発する予定です。HALで共通化できない場合には、LL版のみをリリースします。この開発経緯などもブログに記載していきます。

＊　　＊　　＊

STMのMCUが、2016年マイコン売上5位というのは驚きでした。少なくとも私の周りにはSTMマイコンを使う人がいなかったからです。入手性も良く評価ボードも低価格です。STMサイトの情報がもう少し解り易く整理されれば、日本でも人気がでるMCUだと思います。また、HALやCMSIS対応も他社に比べて早そうなので、今後の発展性も期待できます。

まとめると、STM評価ボードは、サンプル数の多さからCortex-M0のNUCLEO-F072RBを選び、M0/M0+とM3とのテンプレート共通化検証のためCortex-M3のNUCLEO-F103RBを選びました。IDEは、Eclipse IDEベースのSW4STM32へSTM32CubeMXをプラグインしてテンプレート開発に使います。

私は、STMサイト構成が、平面的、網羅的で情報検索しにくいと思うので、ブログに関連資料などへのリンクを掲載し、テンプレート開発経緯を記載していきます。

MCU開発におけるベンダ専用IDEと汎用IDE

2017年5月20日2017年5月29日 WithHappy

ARM Cortex-M系（M0、M0+、M3、M4…）のMCUを開発する時のIDEは、Eclipse IDEベースが一般的です。同じEclipseを使って各ベンダ専用IDEが開発されますので、ウインド構成や操作性（F5やF7の機能など）は同じです。

MCUXpresso IDE Perspective — NXPのMCUXpresso IDE画面（ユーザカイドより）

今回は、MCU開発スピードを左右する、専用IDEと汎用IDEの差と将来性を考察します。

ARM Cortex-M系のIDE

弊社マイコンテンプレートで使用中の専用IDE（ベンダ）が下記です。いずれもコードサイズ制限はありません。

・MCUXpresso（NXP）
・SW4STM32（STM）
・PSoC Creator（Cypress）
・CS+ for CC/CA,CX（Runesas）、64KBコードサイズ制限あり

このうち、CS+ for CC/CA,CXは、ルネサスRL78系MCUなので除外します。今回から、2016年MCUベンダ売上5位のSTM32のマイコンテンプレートも開発しますので、追加しました。

一方、MCUベンダに依存しない汎用IDEで有名なのが、下記です。

・IAR Embedded Workbench for ARM（IAR）　（＝EWARM）、無償版32KBコードサイズ制限
・uVision（Keil）　（＝MDK-ARM）、無償版32KBコードサイズ制限
・mbed（ARM）、コードサイズ制限なし

残念ながら汎用IDE無償版はコードサイズ制限があります。勿論、商用版は制限なしですが1ライセンスあたり数十万円程度もします。

mbed（ARM）は、サイズ制限なしでベンダにも依存しませんが、ブラウザでコンパイルとダウンロード（＝書込み）はできても、デバッグ機能がありませんので、今回は汎用IDEから除外しました。
※IDEへエクスポート（下図）すればデバッグ可能との記載はありますが、今のところ私は成功していません。

汎用IDEのメリットは、ベンダが変わっても同じIDEが使えること、開発したソフトのベンダ間流用障壁が専用IDEよりも低い（可能性がある）こと、技術サポートがあることなどです。

Eclipse IDEのプラグイン機能とCMSIS

オープンソースのEclipse IDEは、プラグインで機能を追加できます。もしベンダ専用機能が、全てプラグインで提供されれば、毎年更新される生のEclipse IDEへ、これらを追加すればIDEが出来上がります。これが一番低価格で良いのですが、Unixならともかく、Windowsでの実現性は低いと思います。

一方、CMSISが普及すると、開発ソフトのベンダ間流用問題はいずれ解決します。従って結局、ベンダ専用IDEで最後まで残る差は、コード生成機能になると思います。

同じCortex-M系MCUであっても、周辺回路はベンダ毎に異なる差別化部分です。コード生成機能は、汎用IDEの弱点でもあります。使いやすコード生成を提供できるMCUベンダが、生き残るでしょう。

一長一短があるChrome、Firefox、IE、Edgeなどのブラウザ同様、Cortex-M系MCU開発は、ベンダ専用IDEを使うのが良さそうだと思いました。

2016年MCUシェア1位はNXP

2017年5月9日2017年5月10日 WithHappy

2016年主要マイコンシェア/販売額の記事がEE Times Japanに記載されました。2016年は、主要MCUベンダの買収が盛んでしたが、買収後で集計されているので、MCUの現状が示されています。

車載半導体はNXPが2015年にルネサスを抜いて1位になっており、2016年のMCUシェア首位とともにNXPの躍進が明確になりました。

NXPの新IDE MCUXpresso

2017年4月時点の最新MCUXpressoIDE_10.0.0_344と、最終LPCXpresso_8.2.2_650の違いは、FreeRTOSタブが追加されたことのみです。残念ながらMCUXpressoのFreeRTOSもv8.0.1のままでした。

FreeRTOS V9はFreeRTOSサイトからダウンロードできます。が、これをMCUXpressoのv8へ手動で上書きインストールして問題なく動作させる自信はありません。FreeRTOS v9がNXPにより提供されるまで待つ方が、トラブルがなく得策と判断しました。
※MCUXpressoは、旧LPCXpressoプロジェクトフォルダがそのまま使えます。
※MCUXpressoに、PE: Processor Expertをアドインし旧Kinetis Design Studio代用とする方法は、調査中です。

マイコンテンプレートラインナップ

弊社マイコンテンプレートラインナップを、2016 MCUラインキング順に並べたのが上表です。おかげさまでテンプレートは、Runesas＞NXP（Freescale含む）＞Cypressの順に売れております。が、MCU順位5のSTM向けテンプレートもあれば、と思いました。

STMの場合、Cortex-M0/M0+を対象コアとすると、STM32F0/L0がテンプレートの対象です。しかし、このクラスのMCUへのRTOS適用によるROM/RAM大容量化や、IoT向けMCUの販売個数の増大などを考慮すると、より高性能なCortex-M3クラスも視野に入れた開発も必要か？と思っています。

CMSIS準拠でソフト開発すると、コア差はCMSISで隠蔽されるので、要求性能に応じたMCU選択が可能でクラス別けの必要もなくなります。また、RTOSでマイコンテンプレート相当が本当に必要か？という懸念もあります。

2016MCUシェアから、ルネサスの順位低下傾向が今後気になるところです。また、マイコンテンプレートについても、これらシェアの動きに合わせて、変わり続ける必要性を実感しました。

MCUXpresso概要と当面の開発方法

2017年4月18日2017年4月18日 WithHappy

LPCXpressoとKinetis Design Studioが新しいMCUXpressoへ統合されました。Windows 10 Version 1703で動作確認したMCUXpressoの概要について示します。

MCUXpresso概要

MCUXpressoの概要は、コチラの4分程の英語Videoが良く解ります。ポイント抜粋すると以下になります。

MCUXpressoは、3つのツール：IDE、SDK、CFGから構成され、各機能が下記です。

IDE機能：ソースエディト、コンパイル、デバッグ。Eclipse 4.6ベース。ローカルPCで利用。
SDK機能：使用デバイスのAPI生成とサンプルソフト提供。クラウドで設定し、結果をIDEにダウンロードして利用。
CFG機能：使用ピン、動作周波数など設定。クラウドで設定し、結果をIDEにダウンロードして利用。

全てが1パッケージのローカルPCで機能した旧IDE（LPCXpressoやKinetis Design Studio）を、MCUXpressoで３ツール構成にしたのは、SDKとCFGをクラウド側で分離提供し、IDEを軽量化することと、CMSIS準拠の開発環境構築が目的だと思います。CMSISはコチラの記事を参照してください。

CMSIS準拠ならMCUハードとソフトの分離が容易になり、開発済みアプリケーション資産を少ない工数で別ハード移植や再利用が可能です。また、CMSIS仕様（CMSIS-COREや-DSPなど）が修正/更新されても、その内容は全てクラウド側のSDKとCFGツールに閉じ込めることができるので、常に最新CMSIS準拠のSDKとCFGを利用したソフト開発が可能です。
ARM Cortex M系のIDEは、今後この分離構成が流行するかもしれません。

注目点は、IDEではコードサイズ制限なし、SDKではFreeRTOS v9提供（LPCXpresso最終版はv8）、CFGでは電力評価やプロジェクトクローナーです。各ツールの概要を以下に示します。

MCUXpresso IDE

旧LPCXpressoとの差分は、FreeRTOSタブが新設されたこと位です。コードサイズ制限なしで、添付マニュアル類も判り易く、誰にでも使い勝手が良いIDEです。MCU開発は、従来のRTOSを使わないベアメタル開発から、RTOS利用ソフト開発へシフトしつつあり、このMCUXpresso IDEもこの流れに沿った機能が追加されました。

MCUXpresso SDK

SDK BuilderでBoard、Processor、Kitsなどの対象MCUパラメタを入力し、対応するSDKパッケージをクラウドで作成後、ローカルPCへダウンロードして使います。パッケージの中身は、APIとこのAPIの活用サンプル集です。但し、2017年4月現在は、FreescaleのMCUと2017年に発売されたNXPのLPC54000対応のものしか提供されていません。

その理由は、旧Kinetis Design Studio：KDSのProcessor Expert：PEの代替だからと推測します。MCUXpressoは、KDSのPE機能がSDKとCFGに分離してクラウドへ実装されました。PEをお気に入りだったユーザは、この点に困惑すると思います。

一方旧LPCXpressoのユーザのSDKはというと、これは従来のLPCXpressoに同胞されていたLPCOpenライブラリなどがそのままMCUXpressoにも実装されています。つまり、MCUXpressoは旧LPCOpenライブラリなどが従来同様使えます。

従って、LPC54000開発とKDSユーザ以外は、MCUXpresso SDKを使うことは、今のところありません。

MCUXpresso CFG

CFGも現状はSDKと同様、FreescaleのSDKとNXPのLPC54000対応のみが提供中です。

MCUXpressoのまとめと当面の開発方法

MCUXpressoは、旧LPCXpressoと旧Kinetis Design Studioを統合した新しいIDEで、現状「フレームワークは出来たものの、完全な移行完了とは言い難い」ものです。以下に特徴を示します。

IDEとSDK、CFGの3ツールに分離するフレームワークは、CMSIS準拠ソフト開発に適している。
KDSのPE代替機能をSDKとCFGに割振っている。2017年NXP発売のLPC54000開発にも使えるが、既存NXPのMCUはSDK、CFGともに未対応。
LPCXpressoとKDSの今後の更新は、期待できない。将来的には、NXP/FreescaleのMCU開発にMCUXpressoを使う必要あり。
LPCXpressoユーザは、当面SDKとCFGを使わずにMCUXpresso IDEを旧LPCXpressoと殆ど同じ使用法で使える。
KDSユーザは、MCUXpresso IDEとSDK、CFGを使い開発する方法と、当面はMCUXpressoにPEをプラグインし開発する方法の２通りの開発方法が取りえる。但し、PEの更新が期待できないので、将来はMCUXpresso SDK、CFGを使わざるをえない。

当面の目安としては、LPCXpressoユーザならば、既存MCUのSDK、CFGが提供されるまで、KDSユーザならば、PE更新が必要になるまで、でしょう。

もう1つの目安が以下です。Windows 10 1703更新に相当するIDEベースEclipse 4.6（Neon）の次版4.7（Oxygen）への更新は、2017年6月の予定です。IDEベース更新から約半年でこの4.7ベースの最新IDEが各社からリリースされるとすると、2017年末から2018年初め位にはMCUXpressoへの完全移行完了となる可能性があります。

MCUのIDEは開発スピードを左右する部分だけに、仕様変更や更新が定期的に発生する部分と、各社独自の部分を分離し、トータルでパッケージ化すると、以上で示したフレームワークが重要となります。開発者は、フレームワーク要素更新にも注意を払う必要があるでしょう。

ルネサスSynergyロードマップ2017 and 2018

2017年4月7日2017年4月7日 WithHappy

3月29日、ルネサス発表の“Renesas Synergy™プラットフォームに新たに３つのマイクロコントローラグループを追加、業界初の組み込み開発向け統合プラットフォームをさらに拡充”に、SynergyのS1グループのロードマップが示されました。

Cortex-M0+ 32MHzのS1グループはROM/RAM増量

弊社対象MCUのCortex-M0/M0+クラスは、S1グループです。ROM/RAMが増量されることが解ります。無線機能は、未実装です。

Cortex-M23もこのグループに属すと思いますが、S128データシートでは、ARM v6-M採用となっており、Cortex-M23のv8-Mとは異なります。昨年のSynergyでM23サポート発表とどのようにリンクするかは、不明です。

それにしても、MCU名が、以前のR8CやRL78と同様複雑と感じるのは、私だけでしょうか？Synergyのスケーラブルなマイクロコントローラという特徴や優位点からすると、MCU選定はアプリ開発と同時で良いので、名前が複雑でも関係ないのかもしれません。

RTOSへの備え：最終回、FreeRTOSサンプルソフト

2017年4月1日2020年2月27日 WithHappy

FreeRTOSの要点を第1回～第3回でなるべく簡潔に解説してきました。簡潔にし過ぎて部分的には不正確な記述もあります。

しかし、正確さに拘って記述すると分（文）量が増え、参考書の和訳になりかねません。ポイントとなる点をざっと掴んで、開発環境で試し、参考書やマニュアルなどで開発者自ら考える、これにより新しい技術を本当に身に付けることができます。私は、これを食物の消化に例えます。

これには、出だしでつまずかず、多少間違えてもスムースに学習を進めること（＝先ずは食べること）が大切です。食べたものの消化には、時間が掛かります。後で振り返ると、内容や詳細が解るということはよくあります。

開発者への「開発スピードを上げよ」というプレッシャーは、益々強まります。この状況で技術を身に付けるには、効率的に頭の中の整理、これこそが消化、が必須です。

最良の解説書は、「サンプルソフト＋評価ボード」

ソフト開発は、つまるところ、ソースコード＋評価ボードによる開発環境に勝る解説書は無いと思います。ソースコードを読み理解するのに最低限必要な知識と、実際のマイコンで使えるFreeRTOSサンプルソフトを示す、これが今回のRTOS関連記事の目的です。

そこで、第3回のタスク間データ通知、同期、排他制御の自作サンプルソースや、NXPオリジナルのＬチカサンプルに、より解りやすい日本語コメントを付加した第1回のLチカサンプルソースを弊社サイトのRTOSページで公開します。

このサンプルソフトを使えば、より具体的に、日本語コメント付きソースコードを参照しながらRTOS習得や理解ができます。評価ボードで動作が即確認できますので、出だしのつまずき回避にも有効です。

FreeRTOSのAPIは、多くのパラメタを含みます。パラメタを変えた時に、どのように動作が変わるかをサンプルソースに修正を加え、評価ホードで試すことができます。これは、結構重要です。食べ方を自分で変えて消化することに相当するからです。また、このパラメタ変化を事細かに記述する術は（多分）ありません。

しかし実際の開発では、この事細かな事柄を知っていないと、トラブルやバグ回避ができません。このことが「サンプルソフト＋評価ボード」が最上の解説書とする理由です。

FreeRTOSサンプルソフト

FreeRTOSサンプルソフトは、NXP製LPCXpresso824-MAXで動作します。
RTOSへの備え：第1回に予定していたLPCXpresso812/812-MAX、LPCXpresso1114/5の動作確認結果が下表です。

LPCXpresso824-MAXで動作するソースを使い、IO割付と使用LPCOpenライブラリのみを変更し、他評価ボードへ適用しました。LPCXpresso812は824-MAXと同様に動作しますが、LPCXpresso1114/5は、Lチカ以外の動作確認ができません。また、LPCXpresso824-MAXもMutexは、希望の動作をしません。代用として2個のセマフォを使って疑似的に実現しました（Mutex2）。MutexとLPCXpresso1114/5の動作NG原因は不明です。原因が判明しましたら、弊社サイトへ記載します。

以上のように出来が良くありませんので、LPCXpresso824-MAXのFreeRTOSサンプルソフトのみをサイトで公開いたしました。
※2020年3月、このFreeRTOSサンプルソフトをLPCXpresso54114対応へ更新し、LPCXpresso824-MAXサンプルソフトは削除しました。

当初目的の全ボードでのFreeRTOS動作確認は出来ていませんが、これも、（かなり無理があることは承知の上で）評価ボード検証のあかしと考えることにします（Orz）。

※動作しない原因がお判りの方は、info@happytech.jpへまで教えていただけると助かります。