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開発（個人編）

2021年11月5日2021年12月5日 WithHappy

ARMが、2021年10月19日、IoT関連製品の開発期間を平均5年から最大2年間短縮できるクラウドベース開発環境「Arm Total Solution for IoT」発表という記事（EE Times Japan）は、以下の点で興味深いです。

・IoT製品化に平均5年もかかるのか？

・ハードウェア完成を待ちソフトウェア開発着手するのか？

但し、クラウドがMCU開発に効果的で、GitHubなどのクラウドリンクが今後増えることは、疑う余地がありません。そこで、すきま時間に個人レベルで役立つクラウドMCUリンクを3点示します。

すきま時間お役立ちクラウドMCU開発リンク

クリエイティブなMCUハードウェア/ソフトウェア開発中は、集中時間と空間が必要です。COVID-19の影響で、開発場所や通勤環境に変化はあるものの、ちょっとした待ち時間や出先での2～3分程度のすきま時間は相変わらず存在します。

個人レベルのIoT MCU開発支援が目的の弊社は、このような短いすきま時間にスマホやタブレットを使って、MCU情報を収集、閲覧するのに便利なリンクを紹介します。

すきま時間にMCU関連情報を閲覧することにより、集中時間に凝り固まった開発視点を新たな視点に変える、最新情報を収集するなどが目的です。

STマイクロMCU技術ノート

STマイクロのSTM32/STM8シリーズ別に検索できる日本語MCU開発Tips満載リンクです。ログインが必須ですが、わずか数ページで説明されたダウンロードPDF内容は濃く、STユーザに限らず全てのMCU開発者に役立つTipsが得られます。

EDN Japan Q&Aで学ぶマイコン講座

EDN JapanのMCU情報リンクです。Q&Aで学ぶマイコン講座は、最初の1ページでMCU初心者、中級者からの質問に対する回答要点が示されています。2ページ以降で回答詳細を説明するスタイルですので、短時間での内容把握に適しています。

Digi-Keyブログ

日本語タイトルで日本語へ翻訳されたブログ記事が判るリンクです。大手サプライヤーの英語ブログですのでMCUだけでなく、幅広いデバイス情報が得られます。すきま時間でも読めるように記事は短く纏まっています。最新MCU情報やハードウェア開発者向け情報が多いのも特徴です。

IoT製品とプロトタイプ開発

EE Timesの2021年10月8日、半導体製品ライフサイクルの長さと製造中止対策の記事に、20年前、1990年代の事業分野別の製品開発リードタイムとライフサイクル変化が示されています。

1998年の値ですが、重電機器を除く製品開発時間（リードタイム）が2.3年以内という数値は、現在でも納得できます（0.5年程度のプロトタイプ開発時間は含んでいない実開発時間だと思います）。

MCUベンダ各社は、10年間のMCU供給保証を毎年更新します。つまり、2021年更新ならば、2031年迄の10年間は販売MCUの供給を保証するということです。

但し、セキュリティが重視されるIoT製品では、最新セキュリティハード/ソフト内蔵IoT MCUによる製品化をエンドユーザは望みます。SoC：System on a Chipによる製造プロセス進化により、IoT関連製品の開発期間は、再開発も含めると1998年よりも更に短くなる可能性もあります。

前章リンク情報を活用し、最新セキュリティ内蔵MCU状況、セキュリティ機能のOTA更新可能性、開発製品がエンドユーザのセキュリティニーズと開発コストを満たすか、などを個人でも常時把握・評価し、万一、開発製品の成功見込みが少なくなった場合には、MCU見直しなども必要でしょう。

IoTセキュリティのライフサイクルは変動的で、かつ、IoT製品の市場獲得に支配的です。短い開発時間中であっても、状況に応じてMCUを変更することは、製品の成功と失敗に直結します。

弊社MCUテンプレートを使ったプロトタイプ開発は、このような激変IoT製品開発のMCU評価に適しています。制御系MCUと被制御系を分離、低コスト、少ない手間でプロトタイプを早期に開発し、プロトタイプ実機によりIoT製品のMCU評価、適正判断ができるからです。

もちろん、最初に示したバーチャルなArm Total Solution for IoTとの併用も有効です。セキュリティ重視IoT製品開発の成功には、IoT MCU選択と開発期間の短さがポイントです。

総務省IoT入門オンライン講座

2020年11月19日2021年2月6日 WithHappy

総務省が、2021年3月24日まで無料IoT入門オンライン講座を開設しています。IoT基礎知識、IoT技術・関連法制度、IoT活用の全3章から成るPDF配布資料（A4/36ページ）付きで各ページ冒頭に2行程度のまとめ表記があります。

※受講方法は、コチラの記事を参照してください。

資料作成日：令和元年10月

COVID-19パンデミック前、令和元年：2019年10月作成資料に沿ったオンライン講座です。関連法の導入時期などに、COVID-19の影響があるかもしれません。

※関連投稿：総務省2020年4月以降IoT機器アップデート機能義務化予定（2019年9月13日）に関する記載は、資料内にはありません。

資料フォーマット

A4縦ページの上方にスライド、下方にテキスト、いわゆるパワーポイントノート形式の配布資料です。タイトル直下、スライド冒頭に2行程度のまとめ表記があり、このまとめでページ内容が解ります。

オンライン講座は、主にスライド部分を使います。配布資料を読めば、講座内容はほぼ取得できると思います。

IoT入門オンライン講座資料の印象点

A4パワーポイントノート形式のIoTオンライン講座配布資料、良くまとまっています。

※タイトル、まとめ表記は、配布資料を基に簡素化しています。

頁	タイトル	まとめ表記	印象点
13	IoT構成機器	IoTシステム構成は3要素	データ収集、分析結果表示がIoTデバイス
14	データ収集	センサでデータ収集	8種センサ概要説明
15	IoTデバイス通信	有線と無線の2種	有線/無線のメリット/デメリット分析
17	無線電波周波数	最適な周波数	波長/周波数/呼び名/特徴分析
18	電波法	電波利用法	無線利用時「技適マーク」必須
19	無線通信	距離・速度・消費電力	無線規格特徴一覧、選択に便利
23	セキュリティ	機密性・完全性・可用性	機密性と完全性と可用性維持がセキュリティ
24	セキュリティ対策	リスクと対策	IoT特有性質とリスク分析
25	セキュリティ対策	対策の5指針	5指針と21要点、具体例一覧
26	標準化動向	標準技術メリット	4標準化団体と最新技術動向把握重要
28	IoT進め方	アイデア → 試行錯誤	プロトタイプで試行錯誤 → 導入
29	ビジネス設定	IoT解決課題設定方法	情報整理に3C/SWOT/KPT活用
30	アイデア案出	IoT活用の3段階	アイデア案出方法
31	アイデア優先順位	効果と実現可能性	効果、実現可能性の考慮方法
32	データ留意点	利害関係調整と個人情報保護	具体的留意点説明
33	運用後の対応	想定と対応策	想定具体的トラブル説明

P28のIoTデバイスをプロトタイプで試行錯誤し開発する手法は、弊社マイコンテンプレートを利用すると、「複数デバイスで実証・比較評価できるなどより効率的・実践的」になります。

マイコンテンプレートのMCUデバイスはどれも汎用MCUですが、開発者のナレや接続センサとADCの使い方により差は生じます。さらに、デバイス消費電力も、開発ツールシミュレーションと評価ボードで評価します。最もアイデアに適し開発し易いMCUは、実はプロトタイプ化しなければ判らないと思います。

配布資料は、「IoTデバイスを中心」に基礎から導入後の運用など、IoT全般に関する幅広い内容です。IoTデバイス開発者の頭の中を整理、開発後のデバイス活用・運用などを予見する場合にも役立ちます。

資料にもCOVID-19影響？

スライド利用のプレゼンテーションは、パワーポイント/Impress（LibreOfficeパワーポイント相当）の資料作成が標準です。一方、弊社テンプレート配布資料は、A3 Visio/Draw形式で作成しています。これは、横長PCモニタ表示を前提としているからです（印刷時、70%縮小A4横出力想定）。

COVID-19の影響で、プレゼンテーションも対面からオンラインへ変わりつつあります。配布資料も従来のようにパワーポイント/ Impress形式が良いか、Visio/Draw形式か、モニタも3:4サイズが良いか、9:16かなど、配布資料フォーマットにも今後影響がでるかもしれません。

弊社テンプレート開発、配布資料のご意見、ご要望などは、info@happytech.jpへお寄せください。

Arduinoコネクタを持つMCU評価ボードが多い理由

2019年2月4日2019年2月11日 WithHappy

本稿は、Arduinoコネクタを持つMCU評価ボードが多い理由を、少し丁寧に説明します。上図は、Arduinoコネクタレベルでコンパチブル（＝置換え可能）なSTマイクロエレクトロニクス、サイプレス・セミコンダクター、NXPセミコンダクターズ各社のMCU評価ボードを示しています。

Arduinoコネクタ

イタリア発で「オープンソースハードウェア概念」の発端となったArduino（アルデュイーノ、もしくはアルドゥイーノ）。その制御系とArduinoシールドと呼ばれる被制御系ボード間の物理インタフェースがArduinoコネクタ（右下）です。
I2C（SCL/SDA）/ADEF（アナログ基準電位）/DIGITAL（PWM兼用）/ IOREF（IO基準電位）/RESET/POWER/ANALOG INのピン配置が決まっています。

Arduinoコネクタのおかげで、制御系とシールドに分離して開発でき、それぞれをArduinoコネクタで接続すれば、Arduinoボードシステムが完成します。

Wikipediaによると、2013年には制御系とシールド、公式非公式合わせて140万台ものArduinoボードが販売されていて、安価にプロトタイプシステム構築が可能となっています。

Arduinoコネクタを持つMCU評価ボードが多い理由その１：市販安価シールド資産が使える

既にこれだけの数のシールドが販売中ですので、MCU開発にそのまま流用や小変更で使えるシールドもあります。

Arduinoコネクタを持つMCU評価ボードが多い理由その１が、この既製品で安価なシールド資産が使えるからです。使用部品選定やアートワークパターンなども十分に練られた既製品が入手できるのです。しかもこれらは殆どの場合、オープンソースハードウェアなので詳細が開示済みです。

シールドは縦方向に段重ね（スタッカブル）できますので、複数段を重ね機能増加も可能です。

ハードウエア基板を0から動作するレベルにまでもっていくのは、時間もコストも掛かります。市販シールドを利用したプロトタイプ開発が可能なことが、MCU評価ボードにArduinoコネクタを持つ理由です。

Arduinoコネクタを持つMCU評価ボードが多い理由その２：MCU性能評価に使える

シールドを使ってハードウエアが用意されれば、後はソフトウェアです。

図のようにシールドは、複数ベンダーのMCU評価ボードに使えますし、同一ベンダー内の異なるMCUの性能評価にも使えます。

例えば、最も重要な処理に必要なシールドと、その制御ソフトウェアのみをプロトタイプ開発し、MCU性能が重要処理に十分か否かの評価を行います。この評価結果で、コストパフォーマンスに優れたMCU選択が可能となります。

場合によっては、ピンコンパチブル性を利用して他ベンダーのMCU選択も可能です。Cortex-M系MCUはどれも似通ってはいますが、例えば、サイプレスのPSoCシリーズはアナログブロントエンド機能内蔵など、各ベンダーでそれぞれ特徴があります。これらMCU特徴を活かした開発で競合他社との差別化もできます。

MCU評価ボードプロトタイプ開発スピードを上げるマイコンテンプレート

その１もその２もポイントは、プロトタイプ開発のスピードです。効率的に、しかも精度良くプロトタイプ構築し評価するには、MCU製品で使用頻度が高いLCD出力やアナログポテンショメータ入力、LED出力などの単機能シールドを複数使うよりも、これら機能実装済みの汎用Baseboardを使う方が、より低コストにプロトタイプハードウエアの構築ができます。

関連投稿：CY8CKIT-042とCY8CKIT-042-BLEへの機能追加、サンプルソフトが直に試せるマイコン開発環境の章

弊社マイコンテンプレートは、Baseboard動作に必要なソフトウェアをBaseboardテンプレートで提供済みです。開発要件に必要なシールドを見つけ、シールド単体でMCU性能評価を行い、さらにBaseboard実装機能を付加すれば、MCU製品完成形により近いプロトタイプシステムでの評価も可能です。

マイコンテンプレートは、MCU評価ボードプロトタイプ開発の「速さ」をより早めます。

MCU評価ボード、IDE、開発ツール、ベンダーが変わってもテンプレート本体は不変

テンプレート本体、具体的にはアプリケーションのLauncher機能は、MCU評価ボード、IDE、コード生成ツールなどの開発ツール、ベンダー各社には依存しません。つまり、単純なC言語でできています。

従いまして、開発ツールやIDEが時代により変化・更新しても、テンプレート本体は変わりません。ご購入頂いた弊社マイコンテンプレートの付属説明資料は、発売当時の環境をベースに解説しております。しかし、最新版のIDEやコード生成ツールに更新されても、このテンプレート本体は不変ですので、安心してお使いください。

まとめ

Arduinoコネクタを持つMCU評価ボードが多い理由は、市販安価シールド資産を活用し、MCU性能評価へも活用すれば、MCUプロトタイプ開発が効率的かつ容易になるからです。プロトタイプ開発スピードをさらに上げるためマイコンテンプレートが役立つことも示しました。

マイコンは種類が多く、どのベンダーの何を使って開発すれば良いかというご質問を時々頂きます。お好きなベンダーのArduinoコネクタを持つMCU評価ボードを使ってプロトタイプ開発することをお勧めしています。制御系ベンダー差は、Arduinoコネクタで消えます。先ずは着手、あえて言えば被制御系の開発着手が先決です。

マイコンテンプレート活用プロトタイピング開発(3)

2018年6月18日2018年6月18日 WithHappy

マイコンテンプレートを使ったプロトタイプ開発の第3回は、シールド基板Joystick機能のテンプレート追加です。

Joystick for HMI (Source：Adafruit) — 4方向入力とプッシュ操作ができるジョイスティック（出典：Adafruit）

要旨

STM32Fx用テンプレートを題材にしましたが、他テンプレートでも同様です。説明が長くなったので、先に本投稿の開発手順と要旨を示します。

シンプルテンプレートをRenameし、「機能追加用テンプレートを作成」
API作成ツール、サンプルソフトやレファンレンスなどを利用し、「追加機能を理解」
「追加機能ファイルを作成」し、追加処理をプログラミング
ユーザ関数起動「Launcher()で追加処理を起動し、デバッグ」

要旨：マイコンテンプレートをプロトタイプ開発に利用すると、既に基本動作する枠組みやライブラリが準備済みなので、機能追加の開発効率が上がり、追加処理が1ファイルに閉じ込められるため、ソフトウェア資産として流用性も高まる。

シールド基板構成

機能追加に使うシールド基板は、SDカードに液晶表示画像が保存されており、カードから画像を読込み、それを液晶に出力する、これにMCUのSPIインタフェースを使う構成です。Joystickは、液晶表示の選択肢を入力するためのHMI（Human Machine Interface）に使います。

Shield Fabrication Print — TFT液晶出力、SDカードのデータ入出力、Joystickでの5SW入力、これら3機能ハードウェアを追加するシールド基板(Source：Adafruit)

回路図からも解るようにJoystickは、シールド基板のSDカードやTFT液晶とは完全に別物です。1個のJoystickで「上下左右」と「プッシュ」の5入力を1本のADC入力だけで処理できますので、効率的で低価格なHMI実現手段の1つと言えます。

本投稿は、このJoystickのADC入力を弊社STM32Fxシンプルテンプレートへ追加し、ADC_Joystickプロジェクトを作り動作確認します。

関連投稿：テンプレート活用プロトタイピングの開発方針：第1回とソフトウェア概要：第2回

テンプレート変更準備

今回は、初めてですので、少し丁寧に説明を加えます。

最初に、ワークスペースへシンプルテンプレートを取込み、これに「変更を加える前」にプロジェクト名をADC_JoystickへRenameします。

Renameを選択すると、プロジェクト名の入力ダイアログが現れますのでADC_Joystickと入力します。

さらに、「手動」でcfg/ico/pdf/txtの4ファイル名をADC_Joystick. cfg/ico/pdf/txtに変更します。

最後に、ADC_JoystickをClean ProjectとBuild Projectすると、正常にコンパイルされ、シンプルテンプレートからADC_JoystickへRenameが成功したことが確認できます。

Tips：リネームプロジェクト名は、「追加周辺回路_装置」としました。プロジェクト名を見れば、時間が経過した後でも、内容が解りやすいメリットがあります。

関連投稿：Eclipse IDEプロジェクトのImportやRename方法

また、レファレンスプロジェクトとしてTFTシールドサンプルソフトもワークスペースへ取込みます。方法は、
File＞Import＞Existing Projects into Workspaceで
Repository＞STM32Cube FW F0 V1.9.0＞Project＞STM32F072RB-Nucleo＞Demonstrations＞STM32F072RB-Nucleoを選択しImportしてください。

以上で、2プロジェクトがワークスペースへ入り、ADC_Joystickに変更を加える準備ができました。

Renamed to ADC_Joystick Project — ADC_JoystickプロジェクトとTFTシールドサンプルソフト（STM32F072RB-Nucleo）がワークスペースへ入る

STM32CubeMXでADC追加

Joystickで利用するADCを、STM32CubeMX（以下CubeMX）でADC_Joystickプロジェクトへ追加します。

CubeMXを起動し前章で手動変更したADC_Joystick.icoをLoadすると、シンプルテンプレートのCubeMX設定がロードされます。これに周辺回路ADCを追加します。

ADCのIN8に☑を入れると、PB0ピン、PB.00を使うことが解ります。このPB.00がArduinoコネクタA3に接続されており、Joystickのアナログ値がADCへ入力されます。

通常は、ここでADCを利用するサンプルソフトなどを参照し、詳細設定を調べます。しかし今回は、もっと直接役立つレファレンスプロジェクトのADC関連ソースを読みます。

※レファンレンスソースは一部しか抜粋しませんので、解りにくいと思いますが、文章が分かれば十分です。

ADC関連は、最初にmain.cのL120でシールド基板の実装有無を確認し、実装（SHIELED DETECTED）ならばTFTを初期化（BSP_LCD_Init()）し、SDカードから画像読込み（SDCard_Config()）を実行します。

L116のコメントから、PB.00電圧レベルで基板有無を確認していることが解ります。そこで、ShieledDetect()を読むと、アナログ入力として使う予定のPB.00を、ここでGPIO入力＋プルダウンへ初期設定した後、電圧レベルを読込み、0以外で基板実装と判断しています。

PB.00をアナログ入力に設定しているのは、TFT_DisplayImages()の中、L304のBSP_JOY_Init()です。

つまり、最初にPB.00をGPIO入力＋プルダウンに設定し、入力が0以外で基板実装と判断し、次に同じPB.00をADCのIN8に再設定（stm32f0xx_nucleo.cのL841）します。アナログ入力では基板有無の判定ができないのです。
プルダウンが設定できるGPIO入力なら基板無し(電圧レベル＝0)の判定が可能です。また、ADC設定は、CubeMXのデフォルト設定で良いことも解ります。

Tips：「同じピン機能をADCからGPIOに切替えて実装有無を判断するテクニック」は、今回だけでなく他でも使えるので覚えておくと役立ちます。

以上、レファンレンスからADCの使い方が解りました。CubeMXへADC追加後のConfigurationタブを示します。CubeMX ProjectをセーブしGenerate Code、Generate Reportを実行し、初期化コードを生成して下さい。

シールド基板実装判定GPIOとADCの切り替え

ADC_Joystickのmain.cには、PB.00のADC初期化コードMX_ADC_Init()がCubeMXにより自動追加されます。では、どこで基板実装有無を確認するかというと、L232のUserInit()で行います。

UserInit()は、無限ループ実行直前に、何らかの独自設定をユーザが行うための関数です。テンプレートには初めからこの関数が準備されています。

UserInit()のL128で基板実装判定のため、PB.00を再度GPIOに設定し直します。そして、判定結果をUSB経由のCOMポートへ出力します。テンプレートには、COMポート出力機能がありますので、簡単に判定結果が出力できます。

基板実装を確認したら、L146でPB.00を再再度ADCに設定します。

つまり、PB.00はCubeMXでADCとして初期設定しますが、UserInit()で基板実装判定のためGPIOに再設定し、実装済みならもう1度ADC初期設定をします。ADC初期設定コードは、CubeMX自動生成コードですので、将来ADC設定に変更が生じたとしてもCubeMXを変えれば良いだけで、ソースはそのまま使えます。

後は、ADCの値を読んで、stick位置を判断し、その結果も基板実装結果と同様、COMポートへ出力すればJoystick関連の追加処理は完成です。

STM32F0とSTM32F1のBSP

BSPはBoard Support Packageのことで、評価ボード用のライブラリです。
STM32F0用は、Drivers＞BSP＞stm32f0xx_nucleo.c/hです。STM32F1用は、stm32f1xx_nucleo.c/hです。

関連投稿：BSP解説は、コチラの投稿のSTM32Fxファームウエア構成やHAL Examplesの章を参照。

Joystickのstick位置判断関数BSP_JOY_GetState()もこのBSPで提供されますが、面白いことに、F0用とF1用のBSP_JOY_GetState()の閾値が異なります。どちらも同一条件で動作するので異なる必要はありません。また、if～else if～else文で分岐するのも、処理時間が長くなります。

Difference Between F0 BSP_JOY_GetState() and F1

そこで、F0用のより広い判断閾値を使い、if文とgoto文で分岐する方法を用いました。

ADC_Joystickプロジェクト動作確認

Joystickのみ機能追加する場合に備え、stick位置のCOMポート出力、STM32F0xとF1xで共用のための#ifdef～#endifなどの関連処理を新規追加のJoystick.cファイルに集め、ADC_Joystickプロジェクトへ加えました。

シールド基板を実装すると評価ボード上の青SWが操作できませんので、ユーザ関数を起動するLauncher()のSwScan()はコメントアウトし、代わりに40ms周期起動にstick位置の取得判断関数：JoystickSacn()を入れました。

完成したADC_Joystickプロジェクト動作中のCOMポート出力例を示します。

まとめ

STM32Fxシンプルテンプレートを使って、シールド基板のJoystick機能のみを追加しました。

長文説明になりましたが、実際に行った処理は、下記のようにとても簡単で単純です。

テンプレートプロジェクトをRenameし、ADC_Joystickプロジェクト作成
STM32CubeMXで、作成プロジェクトへADC機能を追加
レファレンスプロジェクトのADC関連部分を読み、使い方と設定理解
機能追加/削除を容易にするため、Joystick.cファイルを新規追加し、ADC関連処理記述
Launcher()で起動し、必要に応じて処理結果をCOMポートへ出力し、追加処理の動作確認

テンプレートには、COMポート出力やUserInit()などの基本的な処理と枠組み、BSPなど開発に必要となるライブラリが既に準備済みなので、「追加する処理にのみ集中して開発できる」ことがお判り頂けたと思います。

Joystickファイルを新規追加すると、機能の追加/削除、他プロジェクトへの応用も簡単です。ユーザが手動で変更する箇所は、ユーザ関数を起動するLauncher()やUserInit()、COMポートへの出力メッセージ程度で、初期化コードなどはAPI作成ツールSTM32CubeMXが自動的に生成します。