touchgfx::paint::flushLine エラーの解決

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 することでビルドが通るようになりました。

STM32CubeIDE の Failed to execute MI command エラー

かねてより STM32 の開発を STM32CubeMX + STM32CubeIDE で行っていますが、どのツールでもそれなりにすんなりいかない点があります。STM32CubeIDE では、わけのわからないエラーで開発が中断することが多いので困りものです。

ときどき発生するのが、Flash 書き込み時の「Failed to execute MI command」エラーです。

1つの復帰方法は、一度 ST-Link の USB ケーブルをさしなおして、別の正常なプロジェクトのFlashを書き込んでから、戻って再度書き込むことです。そうするとなぜか書けることがあります。

他に効果があったのは、デバッガ設定のポート番号を変えることです。これで復帰できることもありました。

ST社のフォーラムを見ると、同じエラーの相談はいくつか見かけますが、いずれも解決していないようにみえます。

git clone したプロジェクトを新しいバージョンのソフトで開くと、このエラーになりがちです。あるいはファイルが不足しているのかもしれません。

わかりました。ボードとプロジェクトの組み合わせによっては、SPI Flash など、内蔵 Flash 以外の場所に書き込む必要があり、その場合 Run Configurations の External loaders の指定が必要です。TouchGFX などでプロジェクトを作るとここが指定されています。

この設定は .project ファイルではなく、IDE フォルダ内の “(プロジェクト名) Debug.launch” のような名前のファイルに格納されています。
つまり、このファイルをパッケージし忘れたり、何らかの理由でおかしくなったら、Failed to execute MI command エラーに行きつくわけです。 適切な Loader を指定したら、正しく書き込めるようになりました。

RPi Imagerで書いた WiFi 設定はどこにいった

Raspberry Pi Zero W で遊んでいます。
Raspberry Pi Imager で Raspberry Pi の SD カード書き込み時、WiFi の SSID とパスワードを設定することができます。
この状態で、従来 WiFi 設定が格納される /etc/wpa_supplicant/wpa_supplicant.conf を見ても空です。

WiFi 設定はどこにいったのでしょうか。

どこにある

https://raspberrypi.stackexchange.com/questions/145738/where-is-my-wifi-configuration-configured-in-raspberry-pi-imager
に答えがありました。wpa_supplicant ではなく、NetworkManager 側で設定を管理している
ようです。

/etc/NetworkManager/system-connections/preconfigured.nmconnection
を見ると、確かにこちらにありました。

[connection]
id=preconfigured
uuid=<UUID>
type=wifi
[wifi]
mode=infrastructure
ssid=<SSID>
hidden=false
[ipv4]
method=auto
[ipv6]
addr-gen-mode=default
method=auto
[proxy]
[wifi-security]
key-mgmt=wpa-psk
psk=<暗号化されたパスワード>

あとで接続先を追加する場合

あとで WiFi 設定に接続先を追加したい場合はどうするか。
WiFi 経由 SSH でログインしている場合は、新しい接続先に接続ではなく、
現在の接続先を保ちながら接続先を追加したいです。
NetworkManager の制御ツールである nmcli を使います。

sudo nmcli connection add type wifi ifname wlan0 ssid "<SSID>" autoconnect yes con-name "<プロファイル名>"
sudo nmcli connection modify <プロファイル名> wifi-sec.key-mgmt wpa-psk
sudo nmcli connection modify <プロファイル名> wifi-sec.psk "<パスワード>"

これで次から接続できるはずです。
パスワードを平文で入れると、先ほどのファイルに平文で保存されてしまうみたいです。うーんどうしよう。

Windows 10 のタスクバーのアクティブ色が見づらい問題

個人的に Windows 10 の UI にいろいろ文句がありますが、タスクバーのアクティブ色が見づらいのも問題の1つです。

以前の Windows では、現在アクティブのウィンドウはタスクバーでもすぐ視認できました。
Windows 10 では、アクティブと非アクティブの色がほとんど同じ色に設定されてしまいます。
下の画像では「taskbar」がアクティブなウィンドウですが、果たして目視で判別できるでしょうか。

Windows の「設定」でもこれらの色を設定するための項目は用意されていません。
役に立ったためしのない Microsoft Community によると、ハイコントラスト設定にするしか方法がないとのことです。それは解決とはいえないでしょう。

何とか見やすくできないかと調べてみると、下記のページの方法で対応できるようです。

https://superuser.com/questions/1558106/color-of-active-window-in-windows-10-taskbar

まず、Windows の「設定」「個人用設定」「色」から、「以下の場所にアクセント カラーを表示します」の「スタート メニュー、タスクバー、…」 にチェックを入れます。これで、アクセントカラーとして設定した色がタスクバーに適用されます。

この状態で、色設定はレジストリのある値が参照されるので、直接レジストリを書き換えることで色の変更が可能です。

AccentPalette Tool というツールでレジストリの設定が可能です。下の赤枠がタスクバーのアクティブ・非アクティブで使われる 2 色なので、適当な色に置き換えます。

(変更前)

(変更後)

あとは Windows を再起動すると、変更が反映されます。以前より見やすくなりました。

  • Windows 11 では「以下の場所にアクセント カラーを表示します」が選択できませんでした。24H2 から ExplorerPatcher も使えなくなりますし、Linux や ChromeBook などに乗り換えたほうが幸せなのかもしれません。

CH224K を使って ACアダプタ動作の機器をUSB PD 動作にする

機器ごとに AC アダプタが違うとなにかと煩わしいものです。
たまにラベルライタ(カシオのネームランド)を使うのですが、+12V 動作かつ最近珍しい極性統一プラグのため、いちいち専用の AC アダプタを持ってきてコンセントに差し込む必要があります。
しかも AC アダプタは横長なので幅を取ります。

私の環境では USB type-C コネクタ PD アダプタが常につながっているので、
USB PD で給電できるようになると便利です。そこで、PD に対応させるための簡単なアダプタを作ります。

(5V からステップアップコンバータとしてもいいのですが、一応 10W 定格なので PD の方が安全といえますし、小型にできます)

アダプタ差込口

ACアダプタ

CH224K とDCプラグ

USB PD によって ソース (AC アダプタ) から適当な電圧を出させるには、ソース内の IC と通信を行う必要があります。詳しくはトランジスタ技術 23/6月号 あたりを見ると良いかもしれません。
WCH 社の CH224K は USB-PD シンクに対応したワンチップのコントローラ IC で、少しの外付け部品を組み合わせることで手軽に使用できます。
今回はこの CH224K と DC プラグを使って、USB-PD から 12V を出力させ、ラベルライタの DC ジャックに接続させる基板を作ります。

回路図

回路図はこのような感じになります。CFG1 ピンのプルダウン抵抗値で出力電圧を設定します。C はシャントレギュレータの安定化に必要で、付け忘れると発振します。なお IC の 11 ピンは底面パッドです。USB コネクタの D+/D- が使用できる場合、接続しておくと USB BC にも対応するのでベターかもしれません。


作成した基板

IC は 1.27 mm ピッチなのでユニバーサル基板でも簡単に作れますが、別プロジェクトで作成した基板があったので、それを流用しました。

ラベルライタに差し込んだら問題なく動きましたが、このままでは機械的強度に問題があります。
3D プリンタで適当なケースを作ります。

ケース概要

ケース組み込み状態

 

ねじ止めで取り付け

ラベルライタ内部に入れた方がすっきりしますが、本体にあまり手を入れたくないのと
穴開けが面倒だったので外側にねじ止めしてしまいました。
あんまりスマートとは言えないですが、まあ自分しかつかわないからいいでしょう。

AVR のヒューズ設定を hex ファイルに入れる方法 (Microchip Studio)

ATtiny202 は使いやすいマイコンで、8 ピンでやりたいようなことはだいたい何でもできるので、他の8ピンマイコンは不要と言っても過言ではないというのはやはり言い過ぎでしょうか(?)。
8ピンに 32bit マイコンなんて初期化が面倒なだけで、そんなものは 8bit で十分なんです。クロックも 20MHz, 20MIPS で動けば十分です。そう思います。まあもうちょっとアナログ系が充実したら言うことないのですが。

ところで、プロジェクトジェネレータの Atmel Start を使うために Microchip Studio でプロジェクトを作っているわけですが、
* Microchip は Studio の開発凍結と MPLAB X IDE への統一を明言していますが、MPLAB はいろいろダメなので、Studio が使えるうちは Studio で開発する所存です。
ヒューズ設定は自動で作ってくれないため、デフォルト値から変える場合は
ユーザが指定する必要があります。

Microchip 製のデバッガを使う場合、メニューの Tools -> Device Programming で
ヒューズを手動で書き換えることができます。
しかし、頒布や量産を考えると、プログラムファイルにヒューズ設定を入れることが望ましいです。
pymcuprog なんかでも、hex ファイルの中で指定しないとヒューズが書き換えられなさそうです。

tiny202 のヒューズ設定が必要になるとき

tiny202/402 のヒューズ設定が必要になるときは、例えば
– CPU クロックを 16MHz に設定する
(これは Start から設定できますが、そのままではクロックのキャリブレーション設定が 20MHz のままなので、正確な周波数にするためには Fuse の FREQSEL 設定が必要)
– BOD, WDT の初期設定を変える
– UPDI のプログラム書き換えで EEPROM の内容を書き換えないようにする
– スタートアップ時間を変える(出荷時は最大値 64ms)
などが挙げられます。

ヒューズ設定をプログラム中に書く

avr/io.h をインクルードして、avr/fuse.h (これは io.h からインクルードされる) の説明に従って
ヒューズの設定値をソースコード中に記述します。tiny202 なら、たとえば下記のように。
使わないヒューズ部分は _DEFAULT を指定しないと、0x00 になってしまいます。
avr/io.h をインクルードしないと、fuse なしの .elf が出来上がります。

#include <avr/io.h>
FUSES =
{
.WDTCFG = FUSE_WDTCFG_DEFAULT,
.BODCFG = FUSE_BODCFG_DEFAULT,
.OSCCFG = FUSE_OSCCFG_DEFAULT,
.TCD0CFG = FUSE_TCD0CFG_DEFAULT,
.SYSCFG0 = FUSE_SYSCFG0_DEFAULT,
.SYSCFG1 = 0x01, // SUT = 1ms
.APPEND = FUSE_APPEND_DEFAULT,
.BOOTEND = FUSE_BOOTEND_DEFAULT,
};

FUSES の中身はデバイスごとに異なるため、デバイス定義 (iotn202.h)ファイルを参照します。(tiny202 ならば下記のような感じ)

/* Fuses */
typedef struct FUSE_struct
{
register8_t WDTCFG; /* Watchdog Configuration */
register8_t BODCFG; /* BOD Configuration */
register8_t OSCCFG; /* Oscillator Configuration */
register8_t reserved_1[1];
register8_t TCD0CFG; /* TCD0 Configuration */
register8_t SYSCFG0; /* System Configuration 0 */
register8_t SYSCFG1; /* System Configuration 1 */
register8_t APPEND; /* Application Code Section End */
register8_t BOOTEND; /* Boot Section End */
} FUSE_t;

これでビルドすると、コンパイル結果の .elf ファイル中に fuse セクションが入るようになります。
たとえば

avr-objdump --section-headers ~~~.elf

で確認できます。

hex ファイルにヒューズ設定を入れる

AVR マイコンのプログラマには .hex ファイルでバイナリを渡すことが一般的ですが、まだ .hex ファイル中にヒューズビットは入っていません。

Makefile から実行される objcopy で、fuse や lockbit などを無視して hex ファイルを作るオプションが指定されています。
これはプロジェクトのビルド設定で変更できないので、(参考資料) のようにプロジェクトの Post-build event で下記のように指定して、hex ファイルを作成します。この場合、(プロジェクト名)_with_fuse.hex というファイルが生成されます。

"$(ToolchainDir)\avr-objcopy.exe" -O ihex -R .eeprom -R .lock -R .signature -R user_signatures "$(OutputDirectory)\$(OutDir)\$(OutputFileName)$(OutputFileExtension)" "$(OutputDirectory)\$(OutputFileName)_with_fuse.hex"

これで、pymcuprog でもヒューズビットが書けるようになりました。

参考資料

https://microchipdeveloper.com/8avr:avrfuses

UPDI Programmer を作る

今更も今更ですが、現在の 8bit AVR シリーズのプログラミング方法は 3線式 ISP から 1線式の UPDI へと切り替わっています。かつて AT90S 時代からお世話になった ISP プログラマでは書きこめず、1万円近くする PICkit 4 のようなデバッガが必要な気がして、最初は敷居が高く感じました。

実際には、UPDI プログラマは USB-シリアル IC を使って非常に簡単に作成できます。pyupdi がそのようなプログラマの例です。ISP プログラマの作成は一般的にマイコンが必要だったため、”卵と鶏の問題”がありましたが、その意味でも UPDI の方が敷居は低くなっていると言えます。私はいろいろあって普段は PICkit 4 を使っているのですが、安価なプログラマがあると活用の幅が広がります。


今回製作した UPDI プログラマ
の写真は上記です。特に意図はなかったのですが、ケースに UPDI と書くのは既存のケースと似てしまいました。

複数電圧に対応する回路を追加する

USB シリアル IC の CH340N を使用して作成します。オリジナルの回路では、USB-シリアル側の IO 電圧と AVR の電源電圧を合わせなければいけません。AVR はトレラント IO (VDD より高い入力電圧の対応) ではないので、広い電圧範囲に対応するためには、中間にレベルコンバータを入れる必要があります。

ちょうどいいレベルコンバータが手元になかったので、4-Input AND の日立 HD74LV21A をレベルコンバータのように使いました。CH340 を VCC = 5V で動かす場合、VOH = 5V, VIH = 2.3V となっています。HD74LV-A は 2-5.5V 動作、入力 5V トレラントなので、これを AVR 側の電源で動かすことで、2.3-5V 程度の電源範囲に対応します。(VBUS の誤差を許容する場合は、およそ 2.5V – 5.5V になるでしょう。

ついでに、プログラマとして使わないときは UART モニタとして使えるよう、スイッチでプログラマ、モニタを切り替えられるようにしました。ただしこの機能は今のところあまり使っていません。頻繁にプログラム書き換えを行うとき、PC 側のターミナルの接続、切断操作が煩わしいことが理由です。

作成した回路図を下記に示します。D1 はシリコンダイオードではだめで、小信号用 SBD を使用します。D2は直接 VTG で駆動せず、Tr で受けて 5V 側で駆動した方がよかったですね。

ロジックは 74LV21 でなくても、論理が反転しなければ何でもいいです。接続が少し妙ですが TSSOP をユニバーサル基板に手配線する都合でこのようになっています。


UPDI_schematics_PDF

実際に動かした限りでは、AVR の VDD = 1.8V 付近でも動作するようです。一応、USB 未接続の状態で VTG を入れることはできません。直ちに壊れることはないでしょうが。いろいろ考えると、レベルコンバータとして設計された IC を使用する方がよいかもしれません。私の使用状態ではこの回路で十分です。

回路の実装

マイコンの書き込み

プログラマは Python ベースの pymcuprog を使用します。python がインストールされている環境で、

pip install pymcuprog

とやればインストールできます。実行には Windows 7 以降が必要で、試した限り Windows XP 環境では動かないようです。

マイコンの接続チェックは、プログラマを接続して電源が入った状態で

pymcuprog ping -t uart -u com7 -d attiny202

のようにすれば、正しく動作しているかどうかわかります。-u で USB-シリアルに割り当てられた COM ポートを指定します。-d のデバイス指定はどうも必須のようです。

書き込みは、-f オプションで hex ファイルを指定して

pymcuprog write -t uart -u com7 -d attiny202 -f UPDI_Test.hex --erase --verify

のようにすれば OK です。

Microchip Studio から使う

Microchip Studio の場合、Project Property の Tool で Custom Programming Tool を選択してコマンドを入れれば、IDE から書き込みができると思います。

pymcuprog write -t uart -u com7 -d attiny202 -f "$(OutputDirectory)\$(OutputFileName).hex" --erase --verify

(実行結果)

LibreOfficeのデフォルトフォントを変更する

いつからか LibreOffice の日本語デフォルトフォントが 游ゴシックになっていますが
游ゴシックのフォントがあまり好きじゃないので、新規セットアップの度に変更しています。

Calc の場合

新規ドキュ メントを作成して、F11 を押してスタイルを出し、「標準」を右クリック->編集

フォントタブから、好きなフォントに変更します。

セルのフォントしか変わらないので、ついでに図形描画の既定のスタイルも変更したいのですが、Calc だと手順がないです。
Excel だとスタイルの編集で一気にできたと思います。

Calc とか Excel のような表計算ソフトの図形描画で図表を描くのはどうかと思うので、
(Excel で巨大なセルに文章を書いたり、図形描画でフローチャートを描くのは読みづらいのでやめてほしいと思っています)
図形を描くときは Draw や Impress を使ってということでしょう。
実際、図形描画のバーも標準で非表示になっています。

これでそのドキュメントのセルの標準フォントは変更できたので、このファイルをデフォルトのテンプレートに設定します。
メニューからファイル->テンプレート->テンプレートとして保存をクリック

テンプレート名を入力して、「既定のテンプレートにする」にチェックを入れて保存します。

次回新規作成から、そのテンプレートが適用されます。

ファイルは %APPDATA%/LibreOffice/4/user/template に保存されます。

Writer の場合

同じように、スタイルからフォントなどを変更して、テンプレートとして保存します。

注意しないといけないのは、LibreOffice のバグのように見えるのですが、
Calc, Writer, Impress などでテンプレートを作成する際は、別々の名前を指定しないと
すでに保存したテンプレートが消えてしまいます。
ここでは、Calc のテンプレートに「Default」という名前をつけたので、Writer では「Default_Writer」という名前にしておきます。

Impress の場合

Impress の場合、スタイルの「標準図形スタイル」で図形描画のフォントや色(OpenOffice, LibreOffice のデフォルトは変な色になっている)を変えられます。
スライドのデフォルトフォントやそのサイズは、スタイルもしくはスライドマスターで設定します。

PowerPoint ではスライドマスターのフォントを変更するだけでよいのですが、
Libreoffice 7.5 の時点では、スライドマスターのフォントなどを変更してもスタイルに反映されず、直接スタイルを変更するしかないようです。

これまでと同じように、テンプレートとして保存すれば次回からの新規作成でも反映されます。

そのへんにある部品で非接触給電(1)

コネクタや端子で接続することなく電源供給する非接触(ワイヤレス)給電が普及してきています。
非接触給電にはスマートフォンの充電ができる Qi などの規格がありますが、
そこまでの電力でなくても、LED やマイコンが動く mW レベルの
給電で十分なアプリケーションは考えられます。

そのへんにある部品で実現できないでしょうか。実験してみます。

NE555 で適当な発振器を作って、直接磁気シールドのないコイルを駆動します。
2つの D は NE555 の Tr の電流バイパス用ですが、SBD の方がよさそうです。
電源は 5V から 15V までテストできます。電圧を上げると送電電力も大きくなりますが、 9V 以上にすると発熱が気になりました。

ふつうワイヤレス給電では、磁束を確保するため送電側に空芯コイルをつかいますが
安く手に入るフェライトコアを使ったインダクタで実験してみます。
今回は小型に作りたかったのと、ちょうどたくさんあった NEC の SSB44-680 という型番のチップインダクタを使用しました。
その分送受信コイルの位置はずれが許されなくなります。
インダクタンスは大きい方が良いのか小さい方が良いのかよくわかりません。

送電側は LC で直列共振回路を構成します。
発振周波数と共振回路の fC と合わせることで、コイルに大きな電圧が発生します。
Qi が 100-200kHz らしいので、それにあわせて発振周波数は 160kHz としました。

受電側はラジオと同じ LC 並列回路を構成します。
給電状態を確認するため、負荷として LED を接続しました。
ダイオードで半波整流していますが、平滑する場合は D の後に C を追加できます。

L=0mm /  L=10mmL=20mm

VCC=5V では、写真のように 10mm 離しても LED が点灯しています。
20mm 離すと LED は消えます。
10mm 間隔で数mW 給電できるのであれば、プラスチックケースに入れた状態のマイコンを動作させることができそうです。


インダクタの波形は正弦波になるはずですが、ピーク部分がいびつな形になっています。
これは D の trr の影響だと思います。
NE555 ドライバ段の BJT の逆耐圧 (5V) を超えてしまうと故障に繋がるので、このままでは問題かもしれません。

インダクタに加わる電圧は VCC=5V のとき 26V p-p となっています。送電側の消費電流は 60mA 程度です。


VCC=9V まで上げると、インダクタの電流は 62Vp-p まで増加します。

保管用のICレールの止め具を作る

いまどきの製品で DIP IC を使うことは少ないでしょうが、
DIP IC はレール(あるいはマガジンと呼ばれる)に入ってメーカから出荷されていました。

IC レール

レールの両端はプラスチック製の止め具(エンドピンと呼ばれる)や、上の写真のような塩化ビニルやシリコンゴム製の止め具(エンドプラグと呼ばれる)で固定されます。
東芝とか沖電気は黄色、三菱やTI はグレーと、メーカによって色はさまざまでした。

IC レールのいろいろな止め具

私はレールのまま IC をたくさん保管していますが、
日本の高温多湿の環境では、レールを長期保管するとエンドプラグの劣化が問題になります。

劣化したストッパの例

製造から 10年、20年経過すると、エンドプラグは硬い樹脂と液体に分解してしまいます。
液体は油分なので、水分のように金属をさびさせることはありませんが、
もちろん蒸発することもなく、IC は油でべたべたになってしまい、
止め具としての機能もなくなってしまいます。

そこで、軟質のエンドプラグをプラスチックのエンドピンに置き換えるべく、
3D プリンタで止め具を作ることにしました。
φ3.2 の穴にはまるような形状で止め具を作成します。

止め具を3Dプリンタで作る

たくさんプリントアウト

作成した止め具に変えたICレール

IC レールにドリルで穴を開け、もとの止め具の代わりに作成した止め具を差し込みます。
PLA が何年持つかわかりませんが、20年もののエンドプラグよりは安心して保管できますね。
通常の止め具と違い、薄いので裏から差し込むこともできます。

モデルデータ