いろいろなメーカからマイコンが出ていますが、いまは C コンパイラや IDE が無料で使えるのが当然で、
アーキテクチャのよしあしでマイコンを吟味することは減りました。
メーカの統合や日本メーカの衰退により以前に比べて選択肢も絞られていますから、
あるものを実装しようとすると、どのメーカのマイコンでも実現可能なことがほとんどです。

何により使用マイコンを決めるかというと、政治的理由がなければ
コードジェネレータの有無とか開発環境の使いやすさとか、
要するに快適に開発ができるか、だと思っています。

快適に開発できるかという観点で言えば、いつも思うのが STM32 マイコンを作っている
ST 社の Web ページの作りです。Documentation のページを開いたところが下の画像です。

アプリケーションノートなどの資料を探そうとすると、資料の選択画面は画面の下部 1/3 だけしかなく
常に表示される絞り込み画面が画面の多くを占め、ユーザの邪魔をしてくれます。
Minify を押すと1/3 程度に小さくなりますが、常に表示する必要があるんでしょうか。
さらにそのうえ、上部には 2つのツールバーが表示されています。

1つのツールバーは、日本語ページに移行するかどうかを聞いてきます。
ST の日本語ページはリンク切れが放置されていたり、英語に比べて情報が乏しかったりして
欠陥があります。私は英語ページを見たいのですが、毎回日本語ページにするか聞かれて煩わしいです。

もう1つはページ遷移のツールバーです。これは下にスクロールすると非表示、上にスクロールすると
表示になるのですが、アニメーションつきで切り替わるのでうざったいのです。
常に表示されているほうがマシです。

比較対象として Microchip の Web ページを表示しました。
Microchip のページが特別使いやすいとは思いませんが、ツールバーは上部のわずかな領域だけなので
資料を探すうえで不便に思うことはないですね。
（MCU セレクタは改善の余地があると思います）

少なくとも私にとって、こういうところはけっこう大事な MCU の選択要素です。諸行無常。

もっとも UI については Windows も大概ひどいので、ユーザビリティを無視した UI になるのは時代の流れといえるかもしれません。

STM32 の TouchGFX アプリケーションを作っていて、よく発生するのは
あるプロジェクトをもって別のプロジェクトに流用したとき、ビルドが通らなくなることです。

TouchGFX アプリケーションのファイルの依存性は

[TouchGFX Generator] --(Generate)--> [STM32CubeIDE プロジェクト], [STM32CubeMX ファイル], [ソースコード]
[STM32CubeMX] --(Generate)--> [STM32CubeIDE プロジェクト], [ソースコード]

となっています。

既存プロジェクトから TouchGFX Generator および STM32CubeMX で再度 Generate する際、
プロジェクト中のファイルを読み込んで使用します。
プロジェクト中のファイルが期待通りでないと、Generate が正しく完了しないが
エラーは表示されないことがあります。
そういった場合、Build Error ではじめてエラーになるので、ユーザはどこが問題なのか
デバッグに時間がとられます。

たとえば、マイコンによっては
IDE のプロジェクト名を変えると、それ以降の STM32CubeMX の Generate が
成功しなくなります。これは Generate でエラーが出ないので、必要なファイルが生成されず
ビルドが通らなくなります。この場合 IDE プロジェクトファイル自体が壊れてしまうので
バックアップを取っていない場合、復旧は面倒です。
そして、TouchGFX Generator が生成する IDE プロジェクト名は固定なので
結果として運用上「プロジェクト名は変えられない」という結論になります。これは困ります。

今日は以前のプロジェクトを編集していたところ、下記のエラーが出ました。

flushLine 関数の実体がないというエラーですが、原因は TouchGFX のバージョンが
上がったことによります。ライブラリのバージョンが上がり(4.23 -> 4.24)、必要な関数が増えたにもかかわらず、TouchGFX Generator の Generate Code だけでは .cpp ファイルが更新されていませんでした。

STM32CubeMX のほうでも .ioc ファイルを開き、Generate Code することでビルドが通るようになりました。

最近は STM32G071 をいじっていて、USB-PD デバイスを作っています。

STM32 は 12bit ADC を搭載しているのですが、
変換値が実際の値からかなりずれてしまい、しばらく困りました。

ADC の初期化後、変換前に ADC のオフセットの Calibration が必要です。
STM32G071 の ADC モジュールは ハードウェアによるキャリブレーションが実装されていて、完了後に ADC_CALFACT レジスタに値が書き込まれます。
次回変換から、CALFACT で補正された変換値が ADC_DR レジスタによって取得されます。

HAL では HAL_ADCEx_Calibration_Start という関数を呼べば、キャリブレーションを実行してくれます。
STM32CubeMX のコードでは以下のように書けばよいですね。

MX_ADC1_Init();
// 中略
// call before ADC conversion has started
HAL_ADCEx_Calibration_Start(&hadc1);
// HAL_ADC_Start(); を呼び出し可能

注意点は、ADC 初期化した後、ADC 変換停止状態で Calibration_Start 関数を呼ばなければいけないということで、作成したコードではタイマ割り込みから ADC_Start() していたので、タイミングによってはその制約が守られていませんでした。
Calibration に失敗すると、CALFACT は更新されず、0 のままになります。

HAL_ADCEx_Calibration_Start のコードにもその注意が書いてあるので、まあちゃんとコメントを読めばこんなところで引っかからないはずですね。

さて、実際に Calibration させてみると、CALFACT = 69 という値が読めます。
VREF = 3.3V, 12bit なのでオフセット電圧は 69×3.3/4096 = 55mV という計算になります。ちょっと大きいですね。CALFACT は 7bit なので、最上位 bit まで使っています。
（QFP32 パッケージだと VREF = VDD）
STM32G071 のデータシートによるとオフセット誤差 EO = 4.5LSB (max) ですが、これはキャリブレーション実行後の測定値と書かれています。

実際エラッタシートを見ると、VREF が 3V 以下のとき、個体によってはオフセット誤差がキャリブレーションの CALFACT (0-127) を上回ってしまうようです。VREF = 1.65 – 3V のとき、ワーストケースの EO = 50LSB となっています。ちょっとだめですね。

何にしても、Calibration は必須であり、ADC 停止中に行う必要があり、また、Calibration_Start は手動でコードを挿入する必要があるということに注意すればよいでしょう。