まず、注文していたCH552Gチップが届いたので 互換USB Blasterのチップと交換してみた。 プログラムは書き込めるが、動作しない。 交換前と全く同じ動作である。

次に、CH552GとUSBコネクタのみの回路で 動作するか実験を行うため必要な部品、 SOP16変換基板, ミニBメスUSBコネクタDIP化キットと CH552P DIP化キットをついでに購入。 ブレッドボード上で実験したところ CH552P + USBコネクタで動作、 CH552G + USBコネクタでも動作した。

そこで動作するCH552Gと互換USB BlasterのCH552Gの 各端子の電圧を比較し、 互換USB BlasterのCH552Gの電源が3.3Vであることに 気が付いた。動作する方のCH552Gは5V。 Arduinoの設定で調べると 電源が3.3Vの場合クロックは16MHzに しなければいけないらしい。 クロックを24MHzにしていたため 動作しなかったらしい。 Arduinoで16MHzに設定を変更すると 互換USB Blaster上でLED点滅プログラムが動作した。

CH552GとUSBコネクタでプログラム書込み実験	MAX2と接続、書き込みに成功した	給電用５V も取り出した

CH55x-USB-Blasterのプログラムは クロックが24MHzで5V電源用になっている。 これを16MHzに変更、端子配列も 互換USB Blaster用に変更し書き込むと Quarus Prime Liteに認識され、MAX 2に書き込むことができた。 LEDの論理が逆で常時店頭になっていたためプログラムを修正した。

変更の差分を以下に示す

diff --git a/Makefile b/Makefile --- a/Makefile +++ b/Makefile @@ -14,6 +14,7 @@ TARGET = usb_blaster XRAM_SIZE = 0x0200 XRAM_LOC = 0x0000 #FREQ_SYS = 24000000 +FREQ_SYS = 16000000 CODE_SIZE = 0x2800 EXTRA_FLAGS = --opt-code-speed diff --git a/main.c b/main.c --- a/main.c +++ b/main.c @@ -13,6 +13,7 @@ #include "ftdi.h" +#if 0 #define BTN_PIN 2 //P3.2 for bootloader entry. SBIT(BTN, 0xB0, BTN_PIN); @@ -28,6 +29,18 @@ SBIT(TMS, 0x90, 4); SBIT(TCK, 0x90, 7); SBIT(TDI, 0x90, 5); SBIT(TDO, 0x90, 6); +#else +#define BTN_PIN 0 //P3.0 for bootloader entry. +SBIT(BTN, 0xB0, BTN_PIN); + +SBIT(LED, 0x90, 1); // P1.1 + +SBIT(TMS, 0xB0, 2); // P3.2 +SBIT(TCK, 0x90, 7); // P1.7 +SBIT(TDI, 0x90, 5); // P1.5 +SBIT(TDO, 0x90, 6); // P1.6 + +#endif SBIT(P2B7, 0xA0, 7); SBIT(P2B6, 0xA0, 6); @@ -606,10 +619,19 @@ void main() USBDeviceEndPointCfg(); //端点配置 USBDeviceIntCfg(); //中断初始化 +#if 0 //P1.1 P1.4 P1.5 P1.6 output push-pull. //P1.7 input. P1_MOD_OC = 0x40; P1_DIR_PU = 0xf2; +#else + //P1.1 P1.5 P1.7 P3.2 output push-pull. + //P1.5 input. + P1_MOD_OC = 0x5d; + P1_DIR_PU = 0xff; + P3_MOD_OC = 0xfb; + P3_DIR_PU = 0xff; +#endif TDO = 1; UEP0_T_LEN = 0; @@ -623,7 +645,7 @@ void main() length = 0; send_dummy = 1; - LED = 0; + LED = 1; // LED Off while (1) { @@ -673,7 +695,7 @@ void main() } else if (read_en) { - LED = P2B5; + LED = !P2B5; TDI = P2B4; TMS = P2B1; TCK = P2B0; @@ -683,7 +705,7 @@ void main() } else { - LED = P2B5; + LED = !P2B5; TDI = P2B4; TMS = P2B1; TCK = P2B0;

今回理解していなかったCH55xの知識は

• CH55xは電源5Vでも3.3Vでも動く。 3.3VでもUSBは動作する
• 端子のHighレベルの電圧は電源電圧となる。 但し、USBの端子は常時3.3Vだと思われる
• 電源5Vの時、クロックは最大24MHzだが、3.3V時は最大16MHz
• CH552互換USB BlasterはHighレベルを3.3Vにするため電源3.3Vで動作している

安く買える互換USB Blasterが使用できるのはありがたい。

これらで試してわかったこと

• CH552 ミニコアボードに CH55x-USB-Blaster のHEXファイルを書き込むと Intel Quartus Prime Lite Editionに認識されるし MAX2ボードに書き込みもできた。
• 互換USB BlasterのCH552へのプログラム書込みはできるが 動作しない。ブートローダに手が入れられているっぽい。

買ったもの。CH552コアボード×4、互換USB Blaster×4	CH552コアボードの袋。 技術情報は gitで WeActStudio .CH552CoreBoardを検索しろと書いてある。新しい情報提供の方法だ。	CH552コアボード 199円

CH552ミニコアボードでUSB Blaster

CH552 ミニコアボードに CH55x-USB-Blaster のHEXファイルを書き込んだら Intel Quartus Prime Lite EditionにUSB-Blasterとして認識された。 期待を持たせる展開だ。 ドライバーは Intel Quartus Prime Lite Edition同梱のもの。 MAX2ボードのJTAG端子と ブレッドボードとジャンパーピンで 1KΩの抵抗を介し接続。 (TMS - P1.4, TCK - P1.7, TDI - P1.5, TDO - P1.6) 不安定ながらも、なんとか書き込みに成功した。 その後、ミニコアボードと10ピンフラットケーブルコネクタを ユニバーサル基板上に配線し直したところ 安定して書き込みができるようになった。

CH552ミニコアボードでMAX2ボードに書き込み	ユニバーサル基板上に組んだ互換USB Blaster	書込み風景、+5Vも給電

CH55x-USB-BlasterのコードではコアボードとLEDが接続されている端子が違う。 ソースを修正し書き込んだところ、CPLDにコードをダウンロードする時、LEDが点灯するようになった。 CH55x-USB-Blasterのコンパイル時の注意点。

• ch554_sdccが必要。 examplesの下に CH55x-USB-Blasterを展開するとmakeできる。 必要な環境整備については ch554_sdccの説明が詳しい。
• 私は環境整備が楽なLinux上でコンパイルしたのだが、 出来上がった usb_blaster.hexをWindows側の WCHISPTOOLで書き込もうとすると 「不正なHEXファイル」とエラーになる。 改行がLFなのがまずいらしい。CRLFに変換すると書き込める。

CH552互換USB Blasterプログラム書き込めない問題

CH552互換USB Blasterは基板にD+や3V3などの端子が出ているので これらの間を10KΩで接続しUSBケーブルを刺し込むとプログラム書込みモード になり WCHISPTOOLで認識され、プログラムを書き込めたっぽいメッセージが出る。 ところがプログラムが動かない。LED点滅のプログラムが動かない。 USBデバイスとして認識されなくなるので元のプログラムは破壊されたようだ。 LEDが接続されている端子が違うのではないかとか、 必要な初期化がされていないのではないかとか いろいろ調べるがわからない。 ArduinoでLED点滅プログラムを書き、 コアボードで動作を確認後、そのまま互換USB Blasterに 書き込んでも動かない。LEDが点滅しないのは良いとしてCOMポートとしても 認識されので、これはブートローダに手を入れられていると確信した。

CH552はD+端子をプルアップされた状態で電源投入されると ブートローダが動作するが、これは 0x3800番地からのプログラムが 動作しているだけで、しかるべき回路なりプログラムがあれば書き換え可能らしい。 このプログラムを標準のものと置き換え、 単純な暗号化を施されたコード、例えば ビット反転したコードを書き込むようにすれば そのことを知らない人はプログラムの書き換えができなくなる。 知っている人は、簡単なHEXファイル編集プログラムを介するだけで 書込みは可能だ。

そのような改造が互換USB BlasterのCH552Gチップに施されている と推測している。 そうだとすれば、CH552Gチップを市販のものに貼り変えれば ふつうにプログラム書き込み可能になるはず。 CH552Gチップを注文した。

そもそもCH552互換USB Blasterが普通に動作すれば こんなにいろいろ手間をかける必要はないのだが、 動かないから200円ぐらいで売っているという気もする。 CH552版USB Blasterが購入したまま何もせず使えたという人がいたら教えて欲しい。 外見が同じでも中身が全く違う互換USB Blasterが沢山あるから 注意が必要だ。

CH552を使用した中華USB Blasterは、まだ使用できる状態になっていない。 動かない事情を推察するに

• Win10でデバイスドライバに署名が必要になる
• Intel(Altera)製のドライバーで従来使用していなかった機能を使う
• 互換USB Blasterが動かなくなる

Win10環境で使用可能な互換USB Blasterがあれば、この説は崩れるのだがあるのかな？ この記事のWin7用ドライバーもインストールしてみたが、 動かなかった。 デバイスマネージャーで見てみると

部分一致またはあいまい一致のためデバイス USB\VID_09FB&PID_6001\FFFFFFFF は移行されませんでした。

とか言われている。

CPLDも急いて開発しなければいけないわけではないし、 CH552も面白そうなので、気長にCH552と付き合ってみようかと思う。 開発環境もわかってきた。 CH552の互換USB Blasterはソースを CH554 sdk for SDCCのexamplesの下に 展開するとコンパイルできることが分かった。 書込みは メーカー提供のツールでできる。 ブームに乗り遅れることと2,3年？ AliExpressに CH552ボードも注文してみる。

M5Stamp Dialは M5Stamp S3に 円形LCDやロータリーエンコーダを組合わせた製品で なかなかそそる。 円形LCDは気にはなっていたが 価格が若干高いのと具体的な使い道を 思いつかなかった。 今回、ロータリーエンコーダもついたので 以前作ったものを作り直したらカッコ良さそうと考え購入。

USB type-Cケーブルを刺すだけでデモのプログラムが動くが なかなかカッコ良い。開発環境はplatformioを使用し、 サンプルプログラムがあっさり動いた。 とまどったのは シリアル通信に Serialではなく USBSerialを使わないといけない点ぐらい。

これでWindowsの音量調整する奴とか作れば カッコイイのではとか思いつくが、 調べると 2,500円ぐらいで買えるらしいので コスパでは敵わない。

購入時書き込まれているデモプログラム	サンプルプログラムもあっさり動作

MAX2 EPM240ボードの購入理由は、 長く使っている部品で、だいぶ前に製造中止になり、 入手が難しく価格も高くなったものがあり、 CPLDを使えば代替品を作れるのではと思ったこと。 CPLDに入る回路の規模感がわからないので、 とりあえず開発ボードで動かしてみようと考え、 CPLDの開発ボードを探すが、安いのはこれしか見つからなかった。 プログラム書込み用にUSB Blaster(互換)ケーブルも購入。

無料の開発環境 Quarus Prime Liteをダウンロードし サンプルの回路をコンパイルしチップに書き込もうとするが 互換USB Blasterが認識されない。 いろいろ調べ、いろんなドライバーをインストールし試すが 認識されない。

USB Blasterの蓋を開け、基板をみると CH552が使用されている。 互換USB Blasterには FT245を使用するもの、PICを使用するもの、 ST32を使用するものなどいろいろあるらしい。

MAX2 EPM240ボード、いろいろ不満はあるが安い。	中華 USB Blaster 互換ケーブル。 CH552使用。CH552マイコンボードと考えても831円は安い。

USB Blaster Ch552で調べると、 CH552をUSB Blasterにするプログラムが 公開されているし、 CH552もプログラム書込み可能らしいので その辺を試そう。

とかやっているうちに、 セルダ ティアーズ オブ キングダムを またやりたくなり始めてしまった。 RTAではないが、効率の良い進め方 を探りながらプレイするのが楽しい。 正月はこれで終わってしまうかもしれない。

USB hi-speedの転送実験は 外付けPHY USB3300 を使用したものはうまくいかず、 PHY内蔵の STM32F723(以下 F723と記す) で成功したが 転送速度は 20Mbpsを超える程度であった。 USB full-speedの12Mbpsは超えているものの 速くは無い。もっと処理速度が欲しい。 性能が上がれば100MbpsのEthernetの転送速度も 上がるかもしれない。

ali-expressでF723チップを探している時 H723モジュールを目にしたのが H723に興味を持ったきっかけである。

現状

手っ取り早く使ってみたいので NUCLE-H723ZGをdigikeyで購入。 STM32CubeMXでひな型プログラムを生成し、 レジスタ定義のヘッダファイル、 リンカースクリプト等々を入手。 テストプログラムをコンパイルし ST-Linkで書き込むがエラー、 STM32CubeProgrammerを使う必要があるらしい。 NUCLEO基板上のLEDでLチカは割と簡単にできた。 次にUSARTを動かそうとするが上手くいかない。 コントロールレジスタのビット配置が変更になっていた。 その後、クロックの設定に苦労する。 なぜか550MHzまで上げられるはずが400MHzまでしか動かない。 何か見落としがあるのだろう。

今後

• 割込み、DMA等を動かす
• NUCLE基板上のEthernetとUSB(full-speed 12Mbps)を動かす
• 基板を起こして外付けPHYでUSB hi-speedを動かす

自作のライブラリ、Makefile環境が使いやすいので ついついそちらを使ってしまうが STM32CubeMXでUSBやEthernetのライブラリが提供されているので これを素直に試してみるのも良いのかもしれない。

ESP32+LCDディスプレーで、ちょいと何か作ろうという便利そうだし 安いので基板の注文のついでに購入。 似た製品として M5Stackがあるが 当初$20台で安いイメージがあった M5Stackも今は M5Stack BASICで6,800円と あまり安くない。 あとM5Stackは実際に使おうとすると 内蔵リチウム電池がジャマだったりする。 そういうわけで、このESP32 Displayの方が便利な場面もあるのではないか と思う。

回路図

あとは、デモでも動かしてみたいところだが、 まだ動かしていない。 スピーカー端子があるので 得意のBluetooth Speakerでも動かそうと思ったのだが コネクタに合うケーブルが無い。 回路図を見るとJSTのPHコネクタ相当みたいなので このケーブルが使えると思うのだが まだ買っていない。 プログラムは 公式Wikiで 提供されている。

届いたものは、コンパクトな本体と9Vの角型電池と ケースと反射テープ。コンパクトにまとまっていて好印象。

早速、反射テープを10mm程切り出しFANに貼り計測。 白いFANに反射テープって測定できるのかと危惧したが 計測できた。反射板でなくFANの羽部分で計測すると 9枚羽なので約9倍の値が計測できた。

回転数計と説明書と反射テープとケース	ケースはコンパクト。回転数計が入っていることを忘れそう。	FANに反射テープを貼る
反射テープを狙い、回転数計測。測定できた。	羽を狙い計測。約9倍の値が計測される

結果として、1回転当たりパルスが2個出力されているらしい。 FANコントローラの開発はだらだらと続く。

なるほど、 ごもっともです。

よくご存知で...

参考になります。

やっぱりそうですか...

これも参考になります。

TPD2E2U06 91円＠digikey, 在庫あり、参考になります。 別途調べたら USBLC6-2SC6, 85円@digikey,在庫あり、なども 良いらしいです。 RSや chip1stopや モノタロウでも売っています。

最後に

chatGPTは本当に何でも答えてくれる。 答えをそのまま信じるのは危険だが、 何でも答えてくれるのはありがたい。

今後、chatGPT等を活用し、いろんなことに挑戦していきたい。

STLINK-V3MODS

STLINK-V3MODSはSTMicroelectronicsの製品で NUCLEOのSTLINK部分を小型にまとめたような基板。 開発基板に(ハンダ付けして)組み込んで使用することを 意図しているようだ。 Mouserに在庫があり 価格は1,196円。 安いが貧乏性なので基板に直接ハンダ付けするのには 抵抗がある。 使用しているCPUが STM32F723で 本体基板で使用するCPU(STM32F405)より高級だ。 USB HiSpeedのPHYまで内蔵している....

ということで、必要な信号のみピンヘッダに引き出す 基板を製作し、使い回しの効く自作STLINKにすることにした。 引き出す端子は, SWCLK, SWDIO, Vcc(監視), TX, RX, GND, +5V(給電)の 7本だが市販の ケーブルを使用したいので8ピンにする。

製作

年明け前に部品と基板が届いた。 STLINK-V3MODSは想像よりも小さい。 基板に組み込んで使えそうだ。

STLINK-V3MODS 上面	STLINK-V3MODS 下面	Mouserの送料が惜しくて5枚買ってしまった。（写真は4枚）

ハンダ付けは何の問題もなく完了。 このまま使うのには抵抗を感じるのでケースを作る。 STLINK-V3MODSは3Dモデルのstepファイルが提供されている。 それらを使いケースを設計。 小型のケースは軽くてケーブルに振り回され安定しないので ネオジム磁石を組み込んだ。 STLINK-V3MODS上のLEDと基板に書いた信号名が見えるように穴を空けた。 ケース上部と下部の固定は爪を出してその嵌め合いで行った。 今回はじめての挑戦だ。 何度か修正は必要だったが嵌め合いで固定できた。

ケースCAD画面	上部を取った状態。STLINK-V3MODSのデータはSTMicro提供のもの	下面にネオジム磁石用の穴
ケース断面図	ケース上部は5回試作。前半は嵌め合いの調整。後半は穴のサイズと位置調整。	上部を開けたところ
下面の磁石	動作状態。LEDが点灯	基板に接続状態。

プログラム書込みテスト

STLINKコレクション。真ん中の中華のやつにシリアル通信機能がつけば良いのにと思う。

その後、シリアル通信をテストするがうまくいかない。 V3MODSの資料を見直して原因が判明。 使用している端子 T_VCP_TXが入力、T_VCP_RXが出力とある。 つまりTXは送信端子ではなく送信に繋ぐ端子(つまり受信）、 RXは受信端子ではなく受信に繋ぐ端子(つまり送信)ということだった。 この問題はマイコン基板等の端子の表記でよくおこるので、 最近はRXではなくRXO(RXだけど出力)とかTXI(TXだけど入力)などと 表記することがある。RXIやTXOは当然な気がするのでRX,TXで良いような 気がするが、 そうすると出力なのか入力なのかは資料を探さないとわからないことになる。

USB実験基板側の配線をジャンパーを飛ばし修正、シリアル通信が正常に 行えることを確認した。

最後に

次はUSB HiSpeedのプログラム作り、そして実験だ。 ゆっくり頑張ろうと思う。 しかし、STLINK-V3MODSのCPU,STM32F723はHiSpeedのPHY内蔵なのか。 欲しい。AliExpressの2,366円のやつ注文してみようか..

独自デバイスを試すには PC(Windows)側にドライバとアプリが必要だ。 ドライバが面倒でUSBはHIDデバイスばかり使っていたのだが、 汎用ドライバ(libusb)が使用できると知った。 Windowsへのインストールは Zadigでできる。簡単だ。 アプリも pyUSBがあるのでpythonで作れる。

独自デバイスの動作を確認したいが デバイス(NUCLEO)側で何か動いてくれないと面白くない。 LCDで画像などを表示すれば調度良いので LCDの乗ったArduino Shieldを装着。 この記事を書いた時に買ったものだ。

PC側のプログラムで画像を転送しデバイス側のLCDに表示させる プログラムを作成し、データの転送速度を測った。 240x240の画像の転送に0.32秒。あまり速くない。 ( 動画) LCDへの転送がネックかもしれないと疑いコメントアウトしてみたが転送時間は変わらなかった。

データ量は 240 x 240 x 4 [byte/pixel] x 8 [bit/byte] = 1,843,200 [bit]なので、 転送速度は 1,843,200[bit] ÷ 0.32 [秒] = 5.76 [Mbps] となる。 USB full-speedの12Mbpsと比較すると十分速い。 USB Hi-speedの480Mbpsに期待したい。

USB PHYモジュール

NUCLEOの出番が意外と短かった。 またの登場のために保管用Boxを3Dプリントしよう。

NUCLEO基板裏。ピンヘッダやらジャンパーピンやらが飛び出ている	そのまま置くとジャンパーピンで接地	3Dプリンタで作成した台。ネオジム磁石付き。スペーサはM2用
ST-Linkの眩しいLED。作業に差し障りがある。	設計したLEDキャップ、断面。プリント用に上下逆。	キャップ装着状態。点灯はわかる。眩しくない。

USBケーブルを接続すると基板上のいくつかのLEDが点灯する。 明るい。特にST-Link部のLED(LD4)が眩しすぎる。 電気絶縁用の白いビニールテープを貼るが 1枚では眩しい。4枚ぐらい重ねると許せるぐらいの明るさになった。 しかし、すぐに剥がれそうなので3Dプリンタでキャップを作成。 光透過用にΦ1の穴を開ける。 何回か試して満足できるものになった。

開発環境

NUCLEO-F439ZIの開発環境を探すと 基板が新しいのか、あまりみつからないが NUCLEO-F429ZIであれば見つかる。 Arduinoも stm32duinoで サポートされており、Serial.println()でシリアルポートに メッセージを出力するプログラムは、すぐに動いた。 ちなみにNUCLEO-F439ZIのUSART3はST-Link部経由で PCに接続されている。便利。

私の場合、以前使っていたstm32用の自作ライブラリが たくさんあるので、こちらを使うことにした。 ちなみにコンパイラは Arm GNU Toolchainを使用。 STM32F439固有のレジスタ定義やcrt(c runtime)のアセンブラ等は STM32CubeMXが生成してくれる。

クロック(pll)設定部のコードも生成してくれるのだが 私の嫌いなHAL(Hardware Abstract Library)を使用している。 自前のライブラリで、そのまま行けると思ったが、ちょっとハマった。 NUCLEO-F439ZIではST-Link部から8MHzのクロックがHSEの端子から 供給されるが、このためのHSEの設定を見落としていて PLLRDYにならなかった。 基板にはGPIOで駆動できるLEDが3個(LD1,LD2,LD3)ある。 このレベルのデバッグ時に役に立つ。

クロックの設定ができるとシリアル出力が使えるようになる。 割り込み周りも以前のライブラリが修正無しで使用でき、 シリアルポートからコマンドも動かすことができるようになった。 マイコンボードを使うたびに思うが、開発環境が整い、 慣れた手順でプログラム開発ができるようになった時の征服感というか、 達成感というか、お前を下僕にしてやったぜ感がすごい。

ビルド速度は arduinoよりもplatformioの方が遥かに速いが Makefile単体は更に速い。 ST-Linkの高速書き込みと相まって 理想の高速書き込み環境ができた。

次の目標

Hi-speed USB用phyモジュール

あすか修理堂の動画を見ていたら 見たことあるような プロコンの故障が写っていた。 アナログ・スティックの部品を間違えると スティックをフルに倒しても switch側でフルに動かないという現象が出るそうだ。 正常に動作するアナログスティックには印のようなものがある。 確認すると前回取り外したものには印があり、 付け替えたものには無い。 アナログスティックを書い直し、修理をやり直すことにした。 今回もアナログスティックを取り外す必要があるので 低融点半田と TP-100用のΦ2.5の替ノズルも購入した。

アナログスティックを見分ける印	TP-100	TP-100替ノズルΦ2.5

部品が届いたので修理を行う。 プロコンの分解は前回何回も行ったので 何も見ずにできた。 アナログスティックの取り外しは Φ2.5のTP-100のおかげで問題なくできた。 ただΦ2.5は大き過ぎ、Φ1.5の方が良かったかもしれない。

分解し、基板をむき出しに	アナログスティックのハンダをTP-100で吸い取る。	新しいアナログスティック取り付け

新しいアナログスティックをハンダ付けし プロコンを組立直し Switchに接続したところ 補正後、正常に使用できた。

プロコンは2017年のSwitch購入の少し後に1台目を購入。 これが数ヶ月で調子悪くなったので 2台めを購入。 その数カ月後に2代目もおかしくなったので 修理を実行 ( その1, その2) 数ヶ月毎に修理・整備が必要なのかと思ったが その後3年は故障せず動作。 意外と寿命が長い。

最近、さらにUSBケーブルが増えてきたので USBケーブルケースを作り足そうと考えたが、 こんなに長さ必要無くね？と思った。 ちなみに100mmある。 これを20mm程度にして 識別はラベルプリンタのテープで良いのではないかと 思いついたので試作したら良い感じに出来上がった。

形状は直径28mmの円に外接する6角形で厚さは0.8mm、 高さは20mm。 このサイズで、だいたいのUSBケーブルを束ねることができる。 はずれない。 細くて短いケーブルで外れて落ちそうなものがあるが 小さいザイズを作るのも面倒なので、 ビニタイでくくりつけた。 P-Touch Cubeで12mm幅の透明白文字テープにラベルを印刷する。 6面分の文字をカットせずに印刷し、まとめて巻きつける。

図面	まとめて7個印刷	テープは6面分まとめて印刷
短いケーブルでも束ねられる。	この細いケーブルは流石に外れそうなのでビニタイで固定した	USBケーブルが入っている引き出し。これで整理されたか？探すのは楽になった。

本当に便利か、しばらく使ってみようと思う。

故障の経緯

プロコンを購入したが、数ヶ月で調子が悪くなり2台目を購入。 こちらも数ヶ月で調子悪くなり、交換用のアナログスティックを購入し交換、 もう1台は、分解修理だけで調子が戻ったというのが 4年前の話。

この後、分解修理した方を主に使っていたのだが 数ヶ月前に再び調子が悪くなった。 右スティックが触らないのに動いているような入力になる。 スプラトゥーンだと操作しないのに視界が回る感じ。

もう一台のプロコン方に切り替え使っていたが、 左スティック動きがおかしくなる。 スプラトゥーンで前に進もうとして進めない現象が発生する。 スティックを押し込めば現象は消えるが、また再現する。 これではゲームにならないので Switch付属のJoy-Conグリップに Joy Conを装着しスプラトゥーン3をやっていたが ボタンの位置が微妙に違いのとボタンが小さいのが使いにくい。

仕方が無いので部品を取り寄せ交換することにした。

左からプロコン1、プロコン2、JoyCon	秋月電子のアナログスティック	分解して基板を出したところ

修理

前回の修理時は アスカ修繕堂 から交換用アナログスティックを購入した。 今回調べてみると 秋月電子でも販売しているので こちらから購入してみた。 1個190円と圧倒的に安い。

ネットでプロコンの修理方法を調べ、 そのとおり分解し、基板を取り出す。 古いアナログスティックを取り外すため TP-100でハンダを除去を行う。 細いピンは問題なく除去できるが、1.2mmぐらいの太いピンが TP-100の穴に入らず除去できない。 ハンダ吸い取り線も試すが使用した温調ハンダゴテの温度が 低いのか上手く吸い取れない。 ここで温度を上げればよかったのだろうが、 HOT AIR GUNを取り出し 熱風でハンダを溶かし アナログスティックを取り外してしまった。 アナログスティックを交換しプロコンを組み立て Switchを起動してみるとスティックの動きが不十分で 調整もできない。 その後、再分解、はんだ付けの確認等も行ったが動作は改善せず 諦めてしまった。 アナログスティックの抵抗値の違いで 同様の現象が起こることもあるという情報があるので 取り外したものと交換用新品のアナログスティックの抵抗値を確認したところ どちらも10kΩだった。 熱風を長時間かけたので、どこかの部品を飛ばしてしまったのかも しれない。

前回の修理では はんだシュッ太郎で外していた。 アスカ修理堂では、取り外し用に 低融点半田も売っているので こちらもオススメなのだろう。

もう1台のプロコンの修理は慎重に行う。 分解して様子をみたところ、アナログスティック周辺に ほこりのようなものが大量にある。 除去、清掃し組み立て直し 動作確認すると 正常に動作するので アナログスティックの交換は行わないことにした。

プロコンはアナログスティックの交換前に分解清掃を試すのが 正解なのだと思う。

ちなみに、新品のプロコン（並行輸入品）も1個注文中である。 数日中に届く予定なので、修理に失敗したプロコンは廃棄するつもり。

ゲームコントローラって凄いよね

今回、プロコンの分解・組立を何度も行い プロコンの構造に感心した。 日頃、自作基板のケースを3Dプリンタで作れたと 喜んでいるのが恥ずかしいレベルだ。 操作し易さが求められるので、多くのスイッチを 最適な場所に配置する必要がある。 強度も必要だし、複雑な構造になるわけだ。

米国の原潜の潜望鏡の操作には XBOXのコントローラが使用されているそうだ。

picoprobeの製作方法は Getting started with Paspberry Pi Picoの Appendix Aで詳しく説明されている。 ファームウェアもコンパイル済みのものを Raspberry Pi Documentation - Raspberry Pi Pico and Pico Wのページの Debugging using another Raspberry Pi Picoのところから ダウンロードできる。 使用するソフトウェアのopenocdのpicoprobe対応版の作成方法も Appendix Aに丁寧に説明されていて、 完成すれば例えば以下のようなコマンドでプログラムを書き込むことができる。

$ /c/msys64/usr/bin/openocd.exe -f interface/picoprobe.cfg -f target/rp2040.cfg -c 'program .pio/build/pico/firmware.elf verify reset exit'

AliExpressで購入したJ-Link互換品？	picoprobe使用中の様子	Seeed XIAO RP2040をpicoprobeにできれば小さくて良さそうだがファームウェアの改造が必要

サイズが小さい Seeed XIAO RP2040をpicoprobeにできれば小さくて良さそうだと 思ったがGP5が端子に出ていないのでUARTが使用できない。 ダウンロードできるファームウェアでは無理そうだ。

platformioからpicoprobeを使う

platformioのuploadコマンドでpicoprobeを使用するようにしたいが 現状では未だサポートされていない。 調べると pull requestは出ていて、 試すと確かに picoprobeでuploadできるので platformioでサポートされる日は近いのかもしれない。

但し、このpull requestの環境は github.com/earlephilhower/arduino-picoで 使用中の github.com/arduino/ArduinoCore-mbedとは 全然違う。 特にUSB関連のライブラリが全く無いので 今回のプログラムでは使用できない。

仕方が無いので vscodeの task.jsonに以下の 記述を追加し、タスクとしてプログラムの書込みを行っている。

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "Write Firmware (picoprobe/openocd)",
      "type": "shell",
      "command": "/c/msys64/usr/bin/openocd.exe -f interface/picoprobe.cfg -f target/rp2040.cfg -c 'program .pio/build/pico/firmware.elf verify reset exit'",
      "problemMatcher": []
    }
  ]
}

以下に実行結果を示す。

Open On-Chip Debugger 0.11.0-g228ede4 (2022-07-21-12:11) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html Info : only one transport option; autoselect 'swd' adapter speed: 5000 kHz Info : Hardware thread awareness created Info : Hardware thread awareness created Info : RP2040 Flash Bank Command Info : clock speed 5000 kHz Info : SWD DPIDR 0x0bc12477 Info : SWD DLPIDR 0x00000001 Info : SWD DPIDR 0x0bc12477 Info : SWD DLPIDR 0x10000001 Info : rp2040.core0: hardware has 4 breakpoints, 2 watchpoints Info : rp2040.core1: hardware has 4 breakpoints, 2 watchpoints Info : starting gdb server for rp2040.core0 on 3333 Info : Listening on port 3333 for gdb connections target halted due to debug-request, current mode: Thread xPSR: 0xf1000000 pc: 0x000000ea msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0xf1000000 pc: 0x000000ea msp: 0x20041f00 ** Programming Started ** Info : RP2040 B0 Flash Probe: 2097152 bytes @10000000, in 512 sectors target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 Info : Writing 81920 bytes starting at 0x0 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 ** Programming Finished ** ** Verify Started ** target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 ** Verified OK ** ** Resetting Target ** shutdown command invoked

gdbについて

picoprobeについてネットで検索すると gdbでデバッグするという記事を多く見るが raspberry pi picoのプログラムをgdbでデバッグしている人は多いのだろうか？ gdbはUnix上のアプリケーションを開発していた時代に愛用していたが Flashメモリ使用のマイコンの開発では使いたいと思ったことは無い。 とにかく割り込み処理との相性が悪い。 raspberry pi picoのプログラムをgdbで停止させると USB関連処理がタイムアウトし接続しているPC側でエラーが出る。

組込プログラミングではprintfデバッグが最強だと思っている。 欲しいのは超高速のプログラム書込み機能。 ST-Link2が使えるSTM32の開発環境が理想に近い。

最後に

picoprobeは Raspberry Pi Picoに5ピンのピンヘッダを 付けるだけで製作可能である。 platformioに対応し、 もう少しプログラム書込みが速くなれば 皆にお勧めできるが、現状では微妙なところである。

とりあえず、3Dプリンタでケースは作ろうと思う。

開発環境

開発完了を調べると 公式のSDKは cmakeとか使うらしい。 使い慣れた vscode + platformio で開発したいので 調べると platformioも対応している。 すんなり導入できて、LチカプログラムをBuildし、 uploadはエラーになったが BOOTSELモードでUSBメモリと認識されたPicoに ファイルをコピーしてプログラムを書込み、動作させることができた。

PicoのRUN端子(ピン30)にGNDに接続されたSWをつけるとリセットできるので、 BOOTSELモード遷移時にUSBを抜き差しする必要がなくて便利である。

プログラムのデバッグにはシリアルポートへの出力が欲しい。 picoのArduinoのSerialはUSBのシリアルポートなので プログラム書込む毎に消失して面倒。 GP0をTX, GP1をRXとするシリアルポートがSerial1に定義されている。 それ以外のピンのシリアルポートを使用したい場合は以下のようにすれば良い。

UART my_serial(8, 9);  // TX: GP8, RX:GP9

シリアルポートに使用可能なピンは(GP0,1),(GP4,5),(GP8,9),(GP12,13)の4組。

今後

platformioでuploadに失敗する原因はよくわからないが、 いずれuploadできるようにしたい。 jlinkにも対応しているそうなので AliExpressに安いコンパチ品を注文した。 Raspberry Pi Pico自身を使って 別のPicoに書き込む方法もあるらしい。 こちらも、そのうち試してみたい。

Platformioのpicoのライブラリを見ると USB keyboardやmouseがあるので 何かサポートされているようだ。 USB(HID)が簡単に実装できることを祈る。 descriptorが面倒なのよね。

PicoのCPU(RP2040)は2コアだが platformioでは1コアで動かしている気がする。 性能は求めていないので1コアの方が面倒が無くて良い。 排他制御が割込み禁止だけで済む。 2コアだと mutexとか semaphore 必要？

回路変更

電源は12Vで、これをスイッチでOn/Offしたり、 DCジャックの抜き差しなどすると 倍の24V程度の電圧が一時的に印加される。 もともとのオペアンプ NJM4580は電源耐圧が±18Vの36Vだが、 Rail-to-Railのオペアンプ NJM2746Eは15Vで足りない。 安いRail-to-Railのオペアンプで電源電圧36Vなどというものは 無いらしい。

対策は当初、電源を78L05等で5V程度に下げ、Rail-to-Railの オペアンプでPWM信号を発生、これで 2N7002等のFETを駆動し FANのPWM端子に接続することを考えたが、 最終段をFETにするのであれば Rail-To-Railのオペアンプである 必要はない、となれば電源電圧も下げる必要は無い、ということで NJM4580のPWM発生回路の出力に2N7002をつなげるだけになった。

FETの動作

長いこと電子工作で遊んできたが FETやトランジスタの動作の理解は適当だ。 On/Offだけの動作で使うことが多いので、それで済んでいる。 アナログ的な動作が必要な時はオペアンプを使う。

トランジスタはベース・エミッタ間がダイオードで 0.6Vを超えたら電流が流れる。 この電流のh_FE倍(50～400とか)の電流が コレクタ・エミッタ間に流れる。

FETはゲート・ソース間に V_GS(th)以上の 電圧をかけるとドレイン・ソース間に電流が流れる。 ゲート・ソース間の静電容量が意外と大きいので 駆動時には注意。10000pFとかあったりする。 2N7002は小型なので最大50pF。 (参考:MOSFET 電気的特性（動的特性）について　Ciss/Crss/Coss )

V_GS(TH)

データシートによると 2N7002のV_GS(th)は1.0～2.5V。 オペアンプNJM4580の出力はLowレベルでも1.3V程度あるので 直結では2N7002がOffにならない可能性がある。 Hiレベルは12V近くあるので 1/2～1/3程度に分圧し入力してやればよさそうだ。

出来上がった回路図を示す。

基板製作

回路をユニバーサル基板で試すこともなく発注してしまう。 試作が面倒だし、基板製作が早く(1週間ぐらい)て安い(2,500円ぐらい)。 気軽に注文したせいかミスしてしまった。 DCジャックの穴を長穴でないパッケージのまま注文してしまった。 長穴のパターンではDRCでエラーが出すぎてチェックできないので、 チェック終了後に長穴のパッケージに変更するということをしているのだが、 それを忘れていた。基板CADはEAGLEを使用しているが、DRCでエラーが出ない 長穴というのは未だできないのだろうか？

DCジャックは幸い 長穴でないものがあり なんとか差し込むことができる。 こちらのDCジャックを常用にすれば 基板の長穴問題は無くなるので良いのかもしれない。 組み立て後、動作を確認できた。

左、旧基板長穴有り 右、新基板長穴なし	左、旧基板 右、新基板、FETが増えてる

ケース問題

3Dプリンタでケースを作ってみたが収まりが良くない。 VRの軸を基板の長手方向に合わせたのが間違いだったのかもしれない。 こういうこともあろうかとVRとDCジャックは基板にコネクタ経由で 接続することも可能。 スイッチ付きパネル用VR を購入し組み立ててみた。 これ用のケースは未設計だが、そのうち作ってみよう。

作ってみたケース	FANに取り付け後 DCジャックの位置とか不満	SW付きVRを外付けにする

次にPWMのLowレベルの電圧が高すぎるのではないかと疑う。 普通のオペアンプ NJM4580CG を使用しているためLowレベルがGNDまで 下がりきらない。 1.3V程度ぐらいある。 回路図を以下に示す。

PWMの出力波形を以下に示す。

ブレッドボード上でトランジスタで回路を組み、 Lowレベルを下げたところ風量をコントロールできるようになった。 となれば解決方法は簡単だ。オペアンプをRail-to-Railの ものに交換してやれば良い。 幸い NJM2746Eが手持ちにあったので換装。 これで、ばっちり風量をコントロールできるようになった。

オペアンプ壊れる

これでメデタシメデタシ、PWMの出力波形をオシロでみようかと 思ったところ、オペアンプが熱い。火傷しそうなほど熱い。 風量のコントロールもできない。壊れてしまった。

原因を調べるべく NJM2746Eの電源の最大定格を見ると15V。 電源は12Vだが、DCジャックの抜き差しや、スイッチでのOn/Off で倍の電圧は出ると思ったほうが良い。 交換前のNJM4580CGは±18Vなので 36Vまでは耐えられる。 オシロで電源SWを入れたときの電源電圧を観測した波形を示す。 最大26Vぐらい印加されている。

対策

Rail-to-Railで電源耐圧30Vぐらいあるオペアンプがあれば 良いのだが、Rail-to-Railは低電圧用の技術だから そんなものは一般的でない。NJM2746Eの15Vは まだ高い方で 5.5Vなどというものも多い。 Rail-to-Railで±12Vという AD8397ARDZもあるが 単価530円で使いたくない。

みんな大好き NE555でPWM回路を組む案も検討するが 電源耐圧18Vぐらいで足りない。

レギュレータで電源を5V程度に落とし PWM信号を作り、 オペアンプの先に 2N7002Kでも つけてFANにつなげることにしよう。 レギュレータなら 78L05でも 耐圧30Vぐらいあるから大丈夫だ。

最後に

外部からくる電源に直接、普通のICをつなぐと やばいというのは知っているつもりだったが 見落としてしまった。注意しよう。

まず、本当にGPIO39にノイズが乗っているのか確認する プログラムを作成した。 以下に示す。

#include 
#include 
int pin = 39;  // ButtonA:GPIO39
// int pin = 38;  // ButtonB:GPIO38
// int pin = 37;  // ButtonC:GPIO37
void setup() {
  M5.begin();
  Serial.println("Start");
  pinMode(pin, INPUT_PULLUP);
  WiFi.mode(WIFI_STA);
  // WiFi.setSleep(false);   // 回避策!!
  WiFi.begin("your_ssid_name", "your_ssid_password");//これが無いとノイズ無し
}
int v0 = HIGH;
uint32_t tFall;
void loop() {
  int v = digitalRead(pin);
  if (v != v0) {
    if (v == LOW)
      tFall = micros();
    else
      Serial.printf("pulse %lu uSec\n", micros() - tFall);
    v0 = v;
  }
}

実行結果は以下のようになる。

pulse 1 uSec
pulse 1 uSec
pulse 1 uSec
pulse 1 uSec
pulse 2 uSec
pulse 1 uSec
pulse 1 uSec
pulse 1 uSec
...

実験の結果、複数のM5Stackでスイッチを操作しない状態で パルスが検出された。 パルス幅は1または2uSecと表示された。 但し、調べたM5Stackは古い個体なので 最近のもので改良されている可能性はある。

WiFiを使用するとパルスが出るようで、 WiFi.begin()の行をコメントアウトすると パルスはでなくなった。 また、中央と右ボタンの入力GPIO38と37では WiFi使用中であってもパルスは出なかった。

対策

M5Stackライブラリの Button.cppを使用せず、 自前のプログラムでdebounceを行ったところ ノイズでボタン操作を誤認識する現象はでなくなった。

今、調べて気が付いたが M5StackライブラリのIssue#52として上がっている。

• M5.BtnA.wasPressed() conflicts with WiFi? · Issue #52 · m5stack/M5Stack · GitHub

以下の設定を追加すると回避できるらしい。

  WiFi.setSleep(false);

発振波形の式

PWM信号発生回路を以下に示す。

コンデンサc1(1000pF)は R4(33kΩ)を介して電源電圧$V$(12V)への充電と 0Vへの放電を繰り返す。 切り替わりの電圧は$\frac{1}{3}V$の4Vと $\frac{2}{3}V$の8V。

$\frac{1}{3}V$からの立ち上がりの波形は、 経過時間を$t_1$とすると出力電圧$v$は \begin{equation} \label{v1} v = V(1 - \frac{2}{3}e^{-\frac{t_1}{T}}) \tag{1} \end{equation} ここで $V$は電源電圧、$T$は時定数で \[ T = rc \] $\frac{2}{3}V$からの立ち下がりは、 立ち下がりからの経過時間を$t_2$とすると \begin{equation} \label{v2} v = \frac{2}{3}Ve^{-\frac{t_2}{T}} \tag{2} \end{equation} 波形の周期を$T_p$とすると $t_1 = \frac{T_p}{2}$で $v = \frac{2}{3}V$となるので 式\eqref{v1}に代入すると \begin{eqnarray*} \frac{2}{3}V & = & V(1-\frac{2}{3}e^{-\frac{T_p}{2T}}) \\ e^{-\frac{T_p}{2T}} & = & \frac{1}{2}\\ \frac{-T_p}{2T} & = & \ln(\frac{1}{2})\\ \end{eqnarray*} \begin{equation} \label{tp} T_p = 2\ln 2 \; T \simeq 1.386 T \tag{3} \end{equation} これらの式から波形を計算すると 以下の図の波形が得られる。

PWM回路の直線性

発振回路の出力とVRの電圧をコンパレータで比較してPWM信号を出力する。 VRの電圧に対するPWMのパルス幅の変化、直線性を調べたい。 VRの電圧を$v_c$として 発振回路の出力電圧が$v_c$よりも大きくなる時間$T_h$を求めたい。 式\ref{v1}を $t_1$について解くと \begin{equation} \label{t1} t_1 = -T\ln( \frac{3}{2}(1-\frac{v}{V})) \tag{4} \end{equation} 式\ref{v2}を$t_2$について解くと \begin{equation} \label{t2} t_2 = -T\ln(\frac{3}{2} \cdot \frac{v}{V}) \tag{5} \end{equation} $v > v_c$となる時間 $T_h$は \begin{eqnarray*} T_h & = & \frac{T_p}{2} - t_1 + t_2 = &\frac{T_p}{2} + T \ln(\frac{3}{2}(1-\frac{v}{V})) - T\ln( \frac{3}{2}\cdot\frac{v}{V}) \\ \end{eqnarray*} 周期$T_p$中の$v > v_c$となる期間の割合$P$は \begin{eqnarray*} P & = & \frac{T_h}{T_p} & = & \frac{1}{2} + \frac{T}{T_p}(\ln(\frac{3}{2}(1-\frac{v}{V})) - \ln( \frac{3}{2}\cdot\frac{v}{V}) ) \\ \end{eqnarray*} 式\ref{tp}を代入すると \begin{equation} \label{p} P = \frac{1}{2} + \frac{1}{2\ln 2}(\ln(\frac{3}{2}(1-\frac{v}{V})) - \ln( \frac{3}{2}\cdot\frac{v}{V}) ) \tag{6} \end{equation} となる。

この式で$V$=12V, $v$を4～8Vの範囲で計算した結果のグラフを下に示す。

赤い点が計算結果で、直線は (4V,100%)と(8V,0%)を結んだもので、 点がほとんど直線状に載っていることがわかる。

直線性誤差だけグラフ化すると次のようになる

最大でも 0.8% 程度に収まっていることがわかる。 計測用ならともかく、制御用としては十分すぎる直線性である。

最後に

これまでの回路で直線性に問題ないことがわかったので 安心して簡易FANコントローラの基板を起こすことができる。

今回は式を手できれいに書く自信がなかったので LaTeXで書きながら考えた。 そして mathplotlibでグラフ化し確認した。 mathplotlibはgnuplotをpython化したようなライブラリで gnuplotに慣れたものとしては大変使いやすい。 LaTeXの数式をwebに表示するために MathJax を使用した。 数式をきれいに表示できると やる気が出る。

仕様＆回路

仕様を検討する。 手持ちの部品で簡単に作りたい。 NE555は無いがオペアンプはある。 オペアンプ＆PWMで検索し 良さそうな回路を発見。 定数等を調整し次の回路となった。

回路は矩形波の発振回路と コンパレータでPWMの波形を出力だけの 簡単なもの。 PC用のファンのPWMの規定はわからないが、 ファン用のモータドライバ DRV11873のPWMの仕様では 7～100KHzとなっているので、 この範囲の中心あたりの周波数にした。

製作

ブレッドボードで試作することも考えたが ユニバーサル基板にハンダ付けした方が楽なので いきなり作る。 基板は 秋月電子のEタイプを使用。 小さい基板が充実していて助かる。 jw_cadでユニバーサル基板の絵を書き、 拡大し印刷したものに部品と配線を書込み配置を検討。 ケースに組み込むことを考え、VRや電源コネクタは 基板には固定せず、コネクタ経由で接続する。 ほとんどの配線をスズメッキ線（ハンダメッキ線）で行い、 抵抗は 1.6 x 1.0mm のチップ抵抗を使用した。

基板おもて面	基板裏面	VRは手持ちの関係で基板取り付け用のものを使用

動作確認時、若干の修正はあったが無事完成、 動作させることができた。

最後に

ルータを始め、インターネット関係の機器は熱い。 動作保証されているとは思うが触ると心配になる。 使用説明書をよく読むと、放熱のため前後左右には一定の空間をあけ、 風通しの良い場所設置してください、などと書かれているかもしれない。 不安なのでファンで送風してやりたい。 ゲーム機も熱くて不安になる。 そもそも前のFANコントローラを作ったのは Nintendo Switchの発熱による不調や、 PS4でデス・ストランディングをやっている時に 画面が消える問題が理由だった。

こういう環境でPC用ファンは入手性も良いし、安いし、 音も静かで便利だ。今後、活用できる場面は増えてくると思う。 そこで問題になるのがPCファン用の4ピンのコネクタだ。 私は AliExpressで購入した。 50個で500円ぐらいだった。 私は、これで一生買う必要は無いが、 欲しい人は秋月電子に 取り扱い要望 を出せば良いと思う。 出せば結構簡単に通りそうな気がする。

次はケースだ。 ファンも倒れにくいよう上手く固定してやりたい。

回路図を示す。

秋月電子の Dタイプのユニバーサル基板に 部品を配置し固定。スズメッキ線(半田メッキ線)で配線する。 Groveの4本ケーブルでステッピング・モータの電源も 済ませたいので大きめのコンデンサをつける。

ESP32 Devkitでテストプログラムを作る。 MCP23017用に Adaruitのライブラリがあるが、 bit単位の操作ばかりでbyte単位の操作が できないので Wireライブラリを直接使用することにする。 MCP23017は1byteの書き込みで 出力8bitを変化させることができるので ステッピングモータの操作には都合が良い。 なんやかんやでライブラリが完成。 githubで公開した。

タイプD基板上に組んだ。	基板裏。	動作中。ごちゃごちゃ。
ESP32 Devkitが載ったFANコントローラ基板。 GroveコネクタでI2Cが出ているので使いやすい。	ステッピングモータ未回転中の電流、164mA	ステッピングモータ回転中の電流、377mA

動作させると最高速度の秒速90度(15RPM)で 2個のステッピングモータを動作させても i2cへの書き込み周期は1mS程度。 USBの電源電流も 未回転時 164mA, 15RPM回転時 377mAで モーター分は200mA程度。 USB給電でも充分動かせる。

次は、メカを作って動かしてみよう。

欠点は端子を4つも使ってしまうことだが MCP23017でI2C経由で接続、 ドライバも7回路の ULN2003ではなく 8回路の TBD62083を使えば ちょうど2個ドライブできる。 余った8bitをリミットスイッチなどに 使えばいい感じ。 基板を作ろうと思うが MCP23017のSSOPパッケージが手に入りづらい。 とりあえず AliExpressに注文するが いつ届くかわからないので ユニバーサル基板にDIPのICで作る。

まだ本格使用には至っていないが 触ってみた感じは悪くない。 ただ、付属ソフトはお薦めしない。 怪しいサイト(DropBox?)からダウンロードした ソフトをインストールするのは怖いし、 我慢してインストールしても、 画面を一度1024x768にしないと操作できない 謎仕様だし、使い物になる気がしないので 早々にアンインストールしてしまった。 表示される電圧や電流の桁数が多いが、 この値段で、そんなに高精度に制御できるはずがない ので、その辺は、まったく期待していない。

出力電圧、電流の設定とは別に 最大電圧、電流の設定ができる。 これの意味がわからなかったのだが、 パネルの操作で電圧電流等を変化させている時、 操作を間違えても、これ以上は上がらない、流れないという 保護機能らしい。 電源ではなく実験用の電圧源、電流源等で使用する場合には 便利だ。

電圧・電流をグラフ表示	設定を４セット保存	付属のケーブル。バナナーワニグチ

設定は４つ保存できて、 「memory」ボタンで表示できるのだが、 設定を呼び出す方法がわからなかった。 回転ノブで設定を切り替えられるので、 ここを押せば呼び出せそうだが、 何故か選択された設定の電圧変更モードに 入ってしまう。しばらく試して長押しで 設定を呼び出せることに気がついた。

あと、On/Offボタンで出力の接続・非接続を 切り替えられるのは便利だ。 これが無いと、一旦配線を外し、電源投入。 電圧等を確認後、配線を繋ぐことになる。 ただ、電源投入後すぐ出力というモードにも できるらしく、そのアピールのためか、 電源投入時にOn/Offボタンが 一瞬光るのが気になる。

DC310Sには 両端に バナナ・プラグとワニグチがついた 赤黒のケーブル２本が付属する。なかなか便利ではあるが、 私は電源用にはバナナ・プラグ/ 2.1mm標準DCプラグのケーブルを自作して使っている。 さらに、この先につける 中継用DCジャック付きのケーブルを必要に応じて 作っているうち、たくさん出来てしまった。 電源ケーブルは使用頻度が高いし、抜き差しも多いので、 効率化の効果は大きい。

自作バナナーDCプラグ ケーブル	自作DCジャックー各種コネクタ変換ケーブル	手持ち電源装置３台。中央のAD-8724Dは故障中。

現在持っている電源装置は３台。

AD-8724Dは、使用中に出力電圧が下がる現象が発生。 つまみで電圧を上げてやると、 電圧が5Vくらいから30V近くに急に上昇するようになった。 おそらく電解コンデンサの容量抜けで、 交換してやれば直るのではないかと思うのだが、結構面倒。 自作の電源装置を引っ張り出して使っているうち、 今回のD310Sを購入してしまった。

自作の電源装置は随分昔に作ったもの。 おそらく20世紀だと思う。 当初、12V0.6Aぐらいの トランスに秋月の可変安定化電源と 電圧計と電流計をケースに入れたもの。 非力だが、自分用には十分だった。 一度、AC100Vとの接触事故を起こし 壊れたので、トランスを 24V2Aぐらいの スイッチング電源に入れ替えた。

ケースが立派だが、 昔、別目的で 博多の カホパーツセンターで購入したもの。 金属ケースで5千円程した。 結局、使わす余ったので電源のケースに使用したもの。 ちゃんとしたケースに収めると 自作の電源でもかなりの値段になる。 そういう意味で安く電源やら オシロやら買える時代になってありがたい。

基板を組み立てると色々と設計ミスが判明。 大きなところではLCDモジュールのコネクタを180度間違えた。 でもまぁ機能の確認はできるので、 この基板でソフトの開発を行うことにする。

基板到着	LCDモジュールと基板とESP32 devkitC	上面。LCDのコネクタの向きを間違えたので180度ずれて装着

ソフトの環境はVSCode + PlatformIO。 使い方に慣れて最近は、こればかり使用している。 特にgitのログが見易い。

まずはLCDを使えるようにしようと、 どのライブラリを使うか考え、 自作の Humblesoft_ILI9341 を使用することにする。 Adafruit_ILI9341と比べると、 fontxの漢字が使用可能、部分スクロール機能、 高速化などが違うのだが、 今回は漢字は必須ではないし部分スクロールも使わない、 高速化も5年前の話なので今となっては速いかどうかわからないが、 自作のものの方が使いやすい、たまには更新したなどの理由で こちらにした。 使用するSPIを指定する機能などを追加して 表示できるようになった。

さて次はファンや温度センサーを動かしたいのだが タッチスクリーンでファンを制御できるようにしようか、 ライブラリは昔、作ったよね、どこだっけ？ いきなりタッチスクリーン操作は面倒なので 最初はシリアルモニターからコマンドを入力して操作する CLI(Command Line Interface)の方が楽よね。 Arduino用のCLIライブラリも昔、作ったよね。 どこだ？ gitにも置いていない。

既存のものを探してみると"arduino cli"で検索すると Arduino CLIというArduinoのCLIでの開発環境のページばかり 表示される。 "arduino cli library"で SimpleCLIを知るが、 あまり使い易そうではない。 はやり自作が一番ということで CLI_Libraryという名前で 改めて作成した。 使用例は、こんな感じ。

#include <Arduino.h>
#include <cli.h>
CLI cli;
bool cmd_sum(CLI *cli, const char *arg) {
  const char *p = arg;
  int sum = 0, iVal;
  while (get_int(p, &iVal, &p)) sum += iVal;
  return cli->printf("sum = %d\n", sum);
}
bool cmd_factorize(CLI *cli, const char *arg) {
  int n, i, c = 0;
  if (!get_int(arg, &n, NULL))
    return cli->error("integer argment required");
  if (n < 2) return cli->error("bad interger %d, must be >1", n);
  cli->printf("%d =", n);
  for (i = 2; i <= n; i++) {
    while (n % i == 0) {
      cli->printf(" %s%d", c++ ? "* ": "", i);
      n /= i;
    }
  }
  return cli->printf("\n");
}
void setup(void) {
  Serial.begin(115200);
  cli.init(&Serial);
  cli.cmd("sum", "Calculate the sum of the arguments", cmd_sum);
  cli.cmd("f", "factorize the argument", cmd_factorize);
}
void loop(void) {
  cli.update();
}

結構、気に入っているがどうだろう。 ほぼ、自分専用のライブラリであっても githubに置いておいたほうが使い易い。

4千円ぐらい出せばラジコンが買えるのではないかと 調べるといろいろある。 軽トラのラジコンが面白そうなので購入。 価格は 6,009円。 届いたものを見るとカッコいいし、 当然だが普通に走る。 荷台があるので機器の積載にも便利。

ディファレンシャルギアが付いていそうだがディファレンシャルギアではない。	ダイソーの500円モバイルバッテリーを買ってしまうが、5V1AなのでRaspberry piには力不足？	軽トラなので、機材を荷台に放り込むと、それらしいのが面白い。

将来は、自動で走って色々情報を集めてもらいたいが、 まずはraspberry piにROS2を載せ、 カメラをつけて走らせたい。

raspbery pi用電源として ダイソーのモバイルバッテリーを購入したが 安さにつられて 500円のやつを買ってしまった。 こちらは 4000mAH だが1Aとある。 Raspberry Piには容量不足かもしれない。 1000円のやつだと10,000mAH ,2.1Aなので こちらも買ってみたい。

PC用FANのコネクタは2ピンでも3ピンでも4ピンでも動くようにできている。 2ピンだと電源供給だけで100％の強さで動くし、 3ピンだと回転速度検出用のパルス出力が追加され、 4ピンだと速度調整用のPWM入力が追加される。 コネクタの形状は3ピンのものに4ピン目が追加されたようなものに なっている。 FANのコネクタのピン配置は このページがわかりやすい。

仕方が無いので、3ピンで作ろうかと実験し、 電源電圧を変化させて回転数も落とせるように なったのだが、低速域の制御性がものたりない。 電源電圧が下がってしまうので低速域で不安定に なるのは仕方ない。

FANにはPWM入力があるのに...と悔しくなり、 再度4PINコネクタを探すことにする。 ふと思いついてAliExpressで探すとあっさり見つかった。

高品質黒プラスチックシェル 2.54 ミリメートル 2510 3PIN 4PIN 3 ピン 4 ピン (3 + 1) コネクタ scoket PC PC コンピュータ ATX 2540 ファン電源|Computer Cables & Connectors| - AliExpress

50個で$5, 1個10円くらい。送料無料で 1ヶ月ほどで届いた。

最近、部品を探して、AliExpressにならあるというケースが増えてきた。 AliExpressには今後も注目だ。 AliExpressから小口、高速、安価で送れる 配送方法が早くできて欲しい。

左から千石電商の3ピン、4ピン、 AliExpressで買った4ピンコネクタ

秋月から届いた部品を並べ 配置を検討する。 軸を基板と平行に取り付けられる 半固定抵抗と ロータリースイッチが 使いやすい。 適当なサイズの基板が無かったので 手持ちのものを折って使う。 基板カッターも欲しいと思うが 使う機会があるのかと思うと なかなか買えない。

部品を眺めて配置を考える	ユニバーサル基板に部品を固定	基板をモデル化

基板に部品を固定し、 基板形状をFusion360上に作成する。 基板の100mil(2.54mm)ピッチを基準に 座標を出し、各部品のデータシートで 形状を確認することで簡単に形状を作成できた。 このデータを元にパネルを試作し確認する。 このサイズのパネルであれば30分ぐらいで プリントできる。 設計ミスが2箇所あり3回目のプリントで 満足するものができた。

パネル試作中。3回目で完成？	パネル表	パネル裏

ケース下部を作成し、パネルとの結合部も 作っててケースのデータが完成。 結合は今回もネジ。 将来は嵌め合いで固定できるように なりたいが、まだ経験、試行錯誤が 足りない。

本番のパネルを作成	ナットをハンダゴテで埋め込む	組み立てて完成

組み上げると穴位置もばっちりだったので、 基板の配線を行い完成させる。 回路としては電源電圧を 10kΩの半固定抵抗で分圧し、 100Ωの抵抗を介して出力、 出力の電圧と電流を計測表示している。 ロータリーSWはテスト時に コネクタ差し替えの回数を減らすために 使用している。 ろくに電流を流せない根性なし回路だが 今回の基板テストには十分。 とりあえず、今ある基板のテストは順調に完了できた。

電流と電圧の両方を見れると安心だ。 可変電源キットと組み合わせて 実験用電源を自作するのに良さそうだ。

フジオカには当時めずらしかった TK-80BSがあり 触らせてもらったり 借りて文化祭の展示などにも使わせてもらった。 その後、PC-9801の販売で儲かったそうで 平屋の店が4階建てのビルになった。

転職で熊本に戻っり、またフジオカに寄るようになる。 展示品の殆どは昔と変わらないと何時も思っていた。 これはフジオカに限ったことではなく秋葉原でも 多くのパーツ屋の展示品は何十年も変わっていない感じがする。

フジオカは昭和34年(1959)創業だそうだから 2019年閉店で60年もったことになる。 一般企業としては立派な寿命だと思う。 戦後、ラジオ自作ブームというのがあったそうだ。 製品のラジオが高価で、バーツを自分で集めると ずいぶん安く作れたらしい。 そのころ秋葉原にパーツ屋の露天商が出たし、 全国にパーツ屋があったそうだ。 熊本にも銀座通りにマツフジという大型電気店(現マツフジ会館)があり そこの4階あたりにパーツを売るフロアがあった。 小学生の頃、そこでロッドアンテナやらバリコンやらを みつけ興奮していたのを覚えている。

その後、ラジオブームは去り、オーディオブームや アマチュア無線等はあるにせよ低調になって行き、 インターネット通販の時代になって地方パーツショップは 生き残れなくなったのだろう。 今はさらに、海外通販 RS,Digikey, AliExpressなどまである。 マルツも福井のパーツショップだったのが 生き残りをかけてインターネット通販に打って出たというところか。

40枚中1枚不良があった。 基板のETEST(電気テスト?)をすれば 見つかるはずの不良だった。 中国で基板を作ると しばしばETESTをすれば見つかるはずの 不良品に遭遇する。 そういう場合、日本人は何も言わないが 憶えている。100% ETESTを するようになれば、きっと 評判になるよ。

相手側からは陳謝と不良の写真の 要求があったので、送ったところ 最終的に以下の返事が来た。

テストマネージャーによると、デバイスがエラーを報告した際に、テスト担当者がこのボードを無視したためにテストに合格してしまったのではないかとのことです。 そのため、今後このような問題が発生しないように、ここ数日で関係者全員に研修と説明を行いました。

PCB基板を製造すると、ある程度の割合で ETESTで落ちるはずの不良基板に遭遇する。 断線なら、まだ楽だが、 ショートの場合、原因調査にかなり手間がかかし、 回路が壊れる可能性もある。 開発中の回路だと更にわけがわからなくなる。 パターンカットを繰り返しても ショート箇所がわからなかったこともある。 内層でショートしているとしか思えない。 両面基板なのに。

100% ETESTを実施しますというオプションが あれば10$ぐらい払っても良いんだが、 建前では全て無料でETESTをやってくれることに なっているので、そんなオプションは無い。 昔は基板の各端子にETESTのあとのような 傷がみられたが、最近はほとんどみられない。 テストの性能が向上し傷が残らなくなったのだろうか？

考えを変えた。 今後は、ETESTをしてないだろうというような 不良基板に遭遇したら積極的にtwitterで晒して行く。 そうすれば、中国メーカーもETESTをちゃんと実行するなり、 確実に実行する有料オプションの設定なりしてくれるだろう。

基板のETESTを知らない人のために動画を貼っておく。 Eurocircuitというメーカーの動画。 日本語自動翻訳の字幕も可能。

出来上がった基板にJTAGでのプログラム書き込みを 試すが上手く行かない。使用したJTAGアダプタは Olimex ARM-USB-OCD。 platformioを使っているので、platformio.iniに

upload_protocol = olimex-arm-usb-ocd

書けばjtagで書き込んでくれる。 表示されるエラーには

Error: JTAG scan chain interrogation failed: all zeroes

Error: IR capture error at bit 105, saw "0x4210842...

なんか、こっちはjtagが動いているし、惜しい(?)感じが する。しかし調べても原因がわからない。

実験対象をを自作の基板から ESP32-DevKitC(のコンパチ品?)に、 書き込むプログラムも単純なものに切り替え、 試行した結果 OLIMEX ARM-USB-OCDでプログラム書き込みができた。

問題の原因は2つ。1つはJTAGの接続間違いで、 もう1つはプログラムがJTAG機能を殺していたこと。 接続は このページ の表のとおりにしたら上手く行った。 失敗した時は ENをPin3(nRST)ではなくPin15(RESET)に 接続していた。 JTAGを殺す機能はESP32のeFuseにある。 このeFuseにはMACアドレスなども保存されている。 ESP32のフラッシュをクリアすると jtagで書き込めるが、 自分のプログラムを書き込んだ後だと jtagで書き込めなくなる。 プログラムで WiFiManagerライブラリを 使用しているので、このあたりが怪しいと 思っているが確認はしていない。 FT-232で上手く行かない原因はわからない。

接続	FT-232H

jtagでの書き込みができるようになったが速くない。 シリアル経由よりも遅い気がする。 プログラムの書き込みとverifyを なんの必要があるのかわからないが 4回繰り返している。 調整すれば多少速くできるのかも しれないが、期待とは程遠い。

期待したのはSTM32にST-Link2で書き込んだ時の 一瞬で書き込みが終わる感じ。 残念だがjtagでの書き込みは諦め シリアル経由での書き込みで我慢する。

そう言えば ESP32 JTAGで検索しても、 JTAGでデバッグするという話ばかりで、 書き込むという話は無かった気がする。

というわけで収まりが悪いのを我慢しつつオシロを使っていたのだが 解決方法を思いついた。 上アゴ部分に市販のL字金具を使えば長さと強度は問題ない。 締め付け方法も思いついたので ハンズマンで金具を購入し製作を開始した。

最初、支点を固定しない物を作ったが支点が滑ってしまったので 支点もネジで固定するタイプのものに変更。 これでバッチリ固定できた。 この固定方式は、なかなかのアイデアだと思うのだがどうだろう。

ネジでの固定ではナットを使っているが、 ナットを固定できると組立がやりやすい。 最初は狭めのサイズの穴にナットを ハンダゴテで加熱しながら押し込んでいたが、 作り変えたやつではハンダゴテを当てられない位置が あったので固定を諦め大きめのサイズの穴にしたが プリントするとキツキツのサイズでネジを締めて 圧入することになった。結果的には固定できてよかった。

こういう加熱固定用、圧入用、楽に入るが回転はしないなどの 条件にあったナット用穴のサイズを記録していないので 毎度悩むことになる。ちゃんと実験して記録しておこう。 ちなみにネジ等のサイズは ネジ屋さんの通販ページの表を ダウンロードし自分用の資料として使用している。 便利なのでお勧めする。

ホルダーの固定の問題が解決したので プローブを掛けるためのプレートを設計する。 プローブの先端も外した時、置き場所にこまるので それ用の穴もある。プローブと一緒に使う 小物、 ジャンパーケーブルなどを掛ける突起も ジャンパ・ワイヤ・ホルダを参考に作成。

設計完了	ナット埋め込み部	組立完成
設置	使っている様子	小物、ジャンパーケーブル保持部

出来上がりは良い感じだとおもうのだがどうだろう。 金具は150mmのものを使ったが100mmのものでよかった。

ソースの在り処

seeeduino XIAOのarduionoのソースは web上では https://github.com/Seeed-Studio/ArduinoCore-samd にある。割と見やすいので、よく利用する。 ただし tools以下のファイルは無い。 PC上では、arduinoのboardマネージャで導入した場合, C:\Users\ユーザ名\AppData\Local\Arduino15\packages\Seeeduino ディレクトリ以下に配置される。

Exploreで開けるのも面倒な場所なので C:\Users\ユーザ名\AppData\Local\Arduino15\packages フォルダを exploreで「クイックアクセスにピン留め」しておくと 各種CPUのarduinoのソースに簡単にアクセスでき 便利になる。

ついでに cygwinのchereコマンドで context menuに「Cygwin here」を追加しておくと、 cygwinを開き

$ find . -type f | xargs grep SOME_TEXT
$ find . -name '*.h' | xargs grep SOME_TEXT

などとして、任意の文字列の出現箇所を調べられるので便利。

プログラミングの雰囲気を掴む

チップのレジスタを操作するようなプログラムを いきなり書くのは敷居が高いので、 まずは簡単な機能のソースを見て 雰囲気を掴もう。

GPIOの操作の仕方は digitalWrite()のソースを見る。 wiring_digital.c にある。 PWMの使い方は wiring_analog.c のanalogWrite()を見る。

プログラムを詳しく読む

雰囲気だけではプログラムは書けないので、 真面目に XIAOで扱われているマイコン、 ATSAMD21G18に取り組もう。 データシートにざっと目を通す。

マイコンの各ブロックの制御レジスタは 型定義が

C:\Users\ユーザ名\AppData\Local\Arduino15\packages\Seeeduino\tools\CMSIS-Atmel\1.2.1\CMSIS-Atmel\CMSIS\Device\ATMEL\samd21\include\component

実態の定義は以下に有る。

C:\Users\ユーザ名\AppData\Local\Arduino15\packages\Seeeduino\tools\CMSIS-Atmel\1.2.1\CMSIS-Atmel\CMSIS\Device\ATMEL\samd21\include\samd21g18a.h

これらを参照しながら読むとプログラムの詳細な動きが 理解できる。

PWMの周期を変更

前回の報告で述べた通り、 HDDモータを制御するPWM信号の周波数は DRV11873の仕様で 7～100kHzの範囲内である 必要がある。　Seeeduino XIAOの analogWrite()のPWMの周波数は 実測で730Hzぐらいなので 仕様に合わない。

これを修正すべく wiring_analog.c を読んだところ以下のことが判明した。

• カウンタは16bitモードで動作
• 48MHzのクロックを2¹⁶=65536で分周し、 48,000,000Hz ÷ 65536 = 732.421875 Hzが出力されている。
• カウントの最大値 0xffff を設定している箇所がある。

カウントの設定値を4800に変更することで、 PWMの周波数を 48MHz ÷ 4800 = 10KHz にすることができた。

信号の周期を計測

BLDCモータドライバDRV11873は モータ駆動の1サイクルに同期した パルスがFG端子から出力される。 この何サイクルかがモータの1回転に 対応するので、この信号の周期を計測することで モータの回転数を取得することができる。 ATSAMD21G18のカウンタでFG信号の周期を 計測したので、その方法を説明する。

カウンタで信号の周期を計測するための 構成を図に示す。 外部ポートPA4から入力された信号を EIC(外部割込)に接続しイベントを発生させ、 EVSYS(イベントシステム)でタイマーに接続し 周期を計測する。タイマーはTC4とTC5を合わせて 32bitタイマーとして計測する。 クロックはシステムクロックの48Mhzを使用するので 最大 2³²[count]÷ 48M[count/秒] = 89.47[秒]周期まで計測可能 となる。

特徴的なのがEVSYS(イベントシステム)モジュール。 これは各周辺ブロック間で信号をやり取りするバスで

• 12チャンネル
• イベント・ジェネレータ74個
• イベント・ユーザ29個

EICの使い方は WInterrupt.cにある attachInterrupt()のソースを見ると 大体わかる。

EVSYSは使い方が分かりづらい。 arduinoでは全く使われていない。 ハマったのは以下の2点。

• クロックを供給する必要がある
• レジスタを部分アクセスすると失敗する

クロックの供給というのは、コードで言うと以下の部分。

PM->APBCMASK.bit.EVSYS_ = 1;

STM32とかでプログラムしていると当たり前の部分だが、 Arduinoのソースを読んでいてもあまり出てこないので 気が付かなかった。 調べると wiring.cで結構初期化されている。

Datasheetの 11章 Peripherals Configuration Summaryが参考になった。

レジスタを部分アクセスすると失敗する というのは次の部分。 まず、正常に動かないコード。

EVSYS->USER.bit.CHANNEL = 2;
EVSYS->USER.bit.USER  = 0x13;

正常に動くコード。

EVSYS->USER.reg = EVSYS_USER_USER(0x13) | EVSYS_USER_CHANNEL(2);

このコードはイベント・チャンネル1 (CHANNEL-1の値)の出力を TC(USER 0x13)に接続しているが、 上側のコードではDMAC CH0(USER 0x00)にも接続されてしまい、 DMAC側でイベントを受け入れる設定になっていないので エラーとなり、イベント・チャンネル1が動かなる模様。 正常に動くコードにたどり着くまで、かなり時間がかかった。

割込処理

これでタイマーに信号の周期が記録されるようになるが、 プログラムの処理上、周期計測後に割込を発生させる。 割込の処理も WInterrupt.cが参考になる。

タイマーのレジスタで割込を有効化し、 以下のコードでNVIC(割り込みコントローラを設定する)

IRQn_Type v = TC4_IRQn;
NVIC_DisableIRQ(v);
NVIC_ClearPendingIRQ(v);
NVIC_SetPriority(v, 0);
NVIC_EnableIRQ(v);

cortex_handlers.c にデフォルトの割込ハンドラが定義されている。 TC4関連だけ抜き出すと以下のようになる。

/* Default empty handler */
void Dummy_Handler(void)
{
#if defined DEBUG
  __BKPT(3);
#endif
  for (;;) { }
}
...
void TC4_Handler ( void ) __attribute__ ((weak, alias "Dummy_Handler")));
...

デフォルトのTC4割込ハンドラは Dummpy_Handlerという無限ループのハンドラが設定されている。 weak属性が付いているので、 TC4_Handlerという 関数を定義すれば呼び出される。

void TC4_Handler(void){
  uint8_t flags = TCx->COUNT32.INTFLAG.reg;
  if (flags & TC_INTFLAG_MC0) {
    ... 割込処理 ...
  }
  // 割込フラグクリア
  TCx->COUNT32.INTFLAG.reg = 0xff;
}

VSCodeのエラーを消す

VSCodeでArduinoのソースを編集していると intellisenseで大量のエラーが表示される。 今までは無視してきたのだが、 今回 エラーを消すべく設定を調べてみた。

intellisenseの設定は プロジェクトのフォルダーの .vscode/c_cpp_properties.json を用意すれば良いのだが、 自分で最初から書くのは大変なので VSCodeにArduino拡張を利用する。 拡張機能タブでArduinoを検索すると 3つぐらい見つかるので、その中の Microsoft製のものをインストールする。

インストール後、コマンドパレットで Arduino:initializeを実行。 Boardで　Seeduino XIAOを選択すると .vscode/c_cpp_properties.json が生成されるが、 まだ膨大にエラーが表示される。

修正が必要なのは defines と includePath。 definesの参考になるのが Seeeduino Arduinoの boards.txtファイル。 これに

seeed_XIAO_m0.build.extra_flags= -DARDUINO_SAMD_ZERO -D__SAMD21__ -D__SAMD21G18A__ -DARM_MATH_CM0PLUS -DSEEED_XIAO_M0 {build.usb_flags}

{
    "env": {
        "users": "C:/Users/ユーザ名",
        "ulib": "${users}/Documents/Arduino/libraries",
        "seeeduinoDir": "${users}/AppData/Local/Arduino15/packages/Seeeduino",
        "samd": "${seeeduinoDir}/hardware/samd/1.7.6"
    },
    "configurations": [
        {
            "name": "Win32",
            "includePath": [
                "${ulib}/Adafruit_SSD1306",
                "${ulib}/Adafruit_GFX_Library",
                "${samd}/cores/arduino",
                "${samd}/libraries/SPI",
                "${samd}/libraries/WIRE",
                "${samd}/libraries/Adafruit_ZeroDMA",
                "${samd}/libraries/TimerTCC0",
                "${samd}/variants/XIAO_m0",
                "${samd}/**",
                "${seeeduinoDir}/tools/**"
            ],
            "forcedInclude": [
                "${samd}/cores/arduino/Arduino.h"
            ],
            "intelliSenseMode": "gcc-x64",
            "compilerPath": "${seeeduinoDir}/tools/arm-none-eabi-gcc/7-2017q4/bin/arm-none-eabi-gcc.exe",
            "cStandard": "c11",
            "cppStandard": "c++17",
            "defines": [
                "ARDUINO=10813",
                "ARDUINO_SAMD_ZERO",
                "__SAMD21__",
                "__SAMD21G18A__",
                "ARM_MATH_CM0_PLUS",
                "SEEED_XIAO_M0"
            ]
        }
    ],
    "version": 4
}

includePathで、 ** でサブディレクトリとして 指定してあるのに個別のディレクトリを指定している 部分がある。これは個別指定の方を削除すると エラーになってしまうので仕方なく入れている。

intelliSenseModeとcompilerpathも デフォルトから変えている。 これはデフォルトのままだと pinMode()が未定義というようなエラーが 出るためで、原因はわからない。 intellisenseは謎が多い。

次は

HDDの出力をPWMで制御し、 回転数も検出できるようになった。 次は、フィードバックをかけて 定速制御を行えばいいのだが、 フィードバック・ゲインをどう決めるかが問題。

いつもなら、実験しながら適当に決めてしまうのだが、 ちゃんと特性を計測し、極配置とかで設計してやるのも 面白いかもとか思っている。 どうなることか。

プログラムの書き込みはUSB経由で行うが、USBの機能は CPUが提供、ArduinoのフレームワークからUSBの処理ルーチンが 呼び出されるので、ユーザプログラム中でプログラムが止まる （無限ループに入るとか）するとUSBが止まり、プログラムが 書き込めなくなる。この対策としてXIAOには基板にリセット端子が あり、 チョンチョンと2回ショートしてやると、ユーザプログラム が呼び出されない書き込み専用モードでたちあがり プログラムの書き込みが可能になる。 このモードの検出のためだと思われるが、 電源投入後、ユーザプログラムが起動するまで2秒程度待たされる。 組み込み機器を作る場合、この待ち時間はチョット嫌だ。

HDDモータの出力をPWMで制御するのだが、 analogWrite()だとPWMの周波数が 735Hzで DRV11873の仕様(7~100kHz)に合わないので 変更する必要があり、SAMD21の Datasheetを調べた。 なんとか目的は達成することができたが、 SAMD21の制御レジスタが狭苦しい。 制御レジスタの値で内部レジスタを選択し 値を書き込む感じ？ 内部レジスタに書き込めるけど読み出せないとか。 内部レジスタを表に出して、直接読み書きさせてくれよと思う。

ということで、 開発中のボードは仕方ないが 次からは別のCPUにしようかと思っている。

Seeeduino XIAOの良い点も上げる。

• 安い。 秋月で580円。
• 小さい。 20x17.5mm。
• 基板端面もメッキされているので、基板に直接はんだ付け可能。
• Arduinoで開発できる

Arduinoで開発できると、 開発環境がすぐに手に入るし、 ライブラリ、サンプルプログラムも大量に入手できる。 プログラムの公開もしやすい。

ちなみにdigikeyだと 500円/個ぐらいする。 STmicroのCPUは中国で安い。 あまり安いので中国製コンパチチップ GD32F103のリマーク偽造品ではないかと疑うが、 GD32F103の方が 若干高い。

ぼこぼこのダンボールが届く	ケース入のハンディ・オシロ	大型ハンディテスタより大きい

購入したのは Hantek 2D42帯域40MHz, シグナルジェネレータ付きのやつで 12,701円 到着まで1ヶ月もかかるのは リチウム・イオン電池内蔵のためという 説をネットで見たが真偽はわからない。 アマゾンだと 2万円ぐらいだから 待てるのであれば待つ価値はありそう。

充電用のUSB電源アダプタが付属しているが ACプラグがEUROタイプ。 注文を間違えたのかもしれないと 確認したがUSAタイプの選択肢は無し。 商品写真にEUROタイプのプラグしか 内容だ。 5V2AのUSB電源で 充電用のやつが使えるので問題はない。

USB－ACアダプタのプラグがEUROタイプ!!	5V2AのUSB電源なので他の物が使える。	立てるとコンパクト

使用説明書は Hantekの商品ページ でダウンロードできる。 英文版で41ページしかないが そのうち読んでみよう。 使用説明書以外にも ファームウェア、FPGAのデータ、ソフトウェアが ダウンロード可能。 ソフトウェアを試すと、 本体の操作をPC側から行えるようだ。 ただ、データ転送が遅く、 1秒に1回データを取ってくるような動作をする。 データの印刷やセーブもできるので 便利な場面もあるかもしれない。 実機のボタンで操作するより PC上でマウスで操作したほうが楽かもしれない。

今後、使って行って 使い心地など調べて行きたい。

その2。 Seeeduino XIAO。 ARM Cortex-M0マイコン。Flash 256K, RAM 32K。 作るものの制御用にマイコンが必要なのだが 何を使おうと考えた時に、Arduinoが使える, USBでプログラム書き込み、小さい、安い などの点でXIAOを使うことにした。

使用中のテスターとテスター棒	テスター棒の先。左金メッキ	Seeeduino XIAO

その3。 128x64ドットモノクロOLED I2C接続。 表示が細かさ、明瞭度の高さで このディスプレイが気に入っている。 SPI接続のものは売るほど持っているが、 XIAOで使うと1ピンでも少ないほうが良いので I2C接続タイプを購入。

ということで秋月電子で購入した部品を紹介した。 記事を書いているうち、 滞っていた部品の一部が到着。 届いたは リニア・ベアリング。 内径 3mm, 6mm, 8mm のもの。 シャフトはミスミで買う予定。

50mm径のサンダーセット	ダイソーで購入: 縫い付け式マジックテープ	ダイソーで購入: 2液式エポキシ接着剤

ケースの形状は 元ネタ を参考に、モータや基板、DCジャックが収まるように Fusion360で設計。 ケース各部の結合をどうするか悩んだが、 今回は埋め込みナットは使わず スペーサを使用することにした。 埋め込みナットだとケース内部に 柱を建てる必要がある。 スペーサだと、その柱の代わりになる。 ケースの外側からみえるネジが増えるのが 何だが、それを気にしなければ良い方法だと思う。 特に今回は試作1発めだったのでスペーサで楽ができるのは有り難い。

ケース底部	モータ、基板、中板	全体	基板を写真からモデル化

Fusion360で設計時、使用する部品のモデルがあると 考えやすいので最近は積極的にモデルを作るようにしている。 今回はHDDモータ、モータドライバ基板のモデルを作成。 DCジャックは円筒形で代用した。基板のモデルの作成で、 写真を取り込みを行ってみた。 寸法を合わせて、穴や主な形状(VR、コネクタ)を作成したが 作業が楽。写真が入手できる場合はアリな気がする。

スペーサを多用	組立中	完成状態

各部品、わたしの3Dプリンタには割と大きい(10cmぐらい)し、 反ってもらいたくなかったので1つづつ印刷した。 私のプリンタ(qidi X-Smart)の印刷可能領域は 140x140x140mmだが 端の20mmぐらいはヒートベッドの効果が低く反る可能性が高い ことがわかってきた。つまり反らないのは100x100mmぐらいまで。 なかなか狭い。 Ender3-V2 (印刷範囲 220x220x250)を買う理由が増えてきた。

組立は順調に進み、完了。動かすとそれなりに動いた。 アルミやPLAを削ってみる。 めちゃくちゃ削れるわけではないが、 それなりに削れる。 ものを押し付けると回転は落ちる。 最大出力だと力強いが、高速回転はちょっと怖い。

やはりマイコンで定速制御をかけてやると 楽しいのではないかという気がする。 実用品か？と考えるとちょっと疑問。 廃棄物で割と簡単に作れる 実用にもなるかもしれないもの...と言ったところか。

基板の接続を調べる。 基板裏にも書いてあるのだが AliExpressの商品写真に わかりやすいものがあった。 HDDをばらすと、モーターの端子は4つ。 センターもあるようだ。 テスターで抵抗を測りセンターを識別し、 その他の3本に配線をつなげ、 電源を入れるとHDDのモータは音もなく回りだした。 VRをヒネると停止状態から最高速度まで変化する。

この先は、 元ネタの動画のように ディスク・サンダーを作りたい。 とりあえず 直径50mmのマジック付きサンドペーパーを注文する。

基板の中身を調べる。 16pinと8pinの2つのICが乗っている。 16pinの方は Tiの DRV11873らしい。 これは ブラシレスDCモータのドライバーでFAN用。 速度調整の入力がPWMになってる。 8pinの方はNE555で、そのPWMの信号を生成している模様。

基板おもて、 DRV11873、NE555	基板裏に端子名あり	HDDにはんだ付け

DRV11873はdigikeyやmouserで200円台で買えるので NE555ではなくマイコンで制御し、回転数の表示なども すれば面白いのではないかと思うが、回すモータは HDDのモータしかないし、回してもディスク・サンダー位しか 用途を思いつかない。

3Dプリンタで静物(非メカもの)で実用品を作るのは簡単。 というか普通、実用品しか作らない。 実用品以外はテストプリントぐらい。 でも、それだけだと3Dプリンタの用途が限られるので メカものにも手を出したい。 しかしメカものの実用品はハードルが高い。 本当に実用になるものを作り上げるには 膨大な時間を投入する必要がある。 実用にならなければ作る意味は無いとか 言っていると、いつまでも作れそうにないので、 練習から始めることにした。

最初、マイクロサーボSG-90(の模造品？)で作ったのだが、 $2/個で買った模造品のせいか動作がスムーズではない。 回転角度も180度欲しいのだが、少し足りない。 静止状態でも若干動いてしまうのでサーボは諦め 以前秋月で販売していたCOPALのギア付きステッピングモータ SPG20-1331を使用することにした。 原点検出には パナソニックのAV620264を使用。 コネクタ付きケーブルも買えるのが良い感じ。

設計はステッピングモータとマイクロスイッチのモデル作成から始める。 ステッピングモータは データシートを見て図面を入力。 マイクロスイッチはメーカーのサイトから 図面のDXFファイルをダウンロードできたので、 これをFusion360のスケッチに読み込み、 適当な領域を選び押し出すとモデルができた。 各部の外観を適当に設定してやるとそれっぽい。 あとは、これらを適当に配置。間を埋めるように 部品を作成し設計は完了した。 今回作成したのは試作品。 全体の大まかな動きが確認することが目的なので、 実験のしやすさを重視している。

ステッピングモータのモデル	マイクロスイッチのモデル	全体図 ... というか半分。 これ2個で完成。

3Dプリンタでの印刷では、いろいろとトラブルに見舞われた。 主な現象はフィラメントの詰まり。数回ヘッドを分解することになり、 ヘッドの構造には詳しくなった。原因は、使っているフィラメントが ABSだと思ってたのだが実はPLAで設定温度が高すぎたこと。 ノズルより上のフィラメントを送り出すステッピングモータのあたりまで フィラメントが柔らかくなり詰まってしまいフィラメントを送り出せなく なっていた模様。

ABSのフィラメントが無いから買い足したものを使ったので、 当然ABSだと思っていたら、実は間違ってPLAを注文していた。 Amazonで購入したのだが、ABSフィラメントで検索して 注文したつもりなのに、表示される関連商品にまどわされて PLAを注文していたようだ。

前から	後ろから	自作 PIC32MX220 + A4988ステッピングモータ・ドライバーモジュール基板

プリント完了後、部品を組立てアルミフレームに固定する。 なんでも固定できるアルミフレームは試作に便利だ。 全体を固定できると実験もやりやすい。 制御に使っているボードはPIC32MX220を使用した自作ボード。 A4988ステッピングモータ・ドライバー・モジュールが乗っている。

次は全体を1パッケージに、まとめて完成させる予定。 今はチップを乗せる部分を導電性スポンジを使用しているが、 これだと 1.6x0.8mmのチップ部品などでは埋もれてしまったり 飛んで行ってしまったりする。この部分はゴムシート に変更する。 本当に実作業に使用するのであれば、ゴムシートと フィラメントは導電性のものにすると良いのかもしれない。

グラフの説明をする。

居室の温度が9個ある。 180cmの棒に4個のセンサーが固定したもの が2本で8個、 あと netamoの室内モジュールがあるので9個となる。 この8つの室温センサーの値は、通常は余り差が出ないが、エアコンをつけると如実に差が出る。 この部屋の温度が常時高めなのは パソコンのせいだと思われる。

この冬、低温で3Dプリンタの調子が悪くなった時、 3Dプリンタ周りに温度センサーを4個設置。通常は人がいない部屋なので、温度低め。 3Dプリンタを動作させると、内部の温度が少し上昇する。

屋外の温度センサーは2つあって、 1つは netatmoの屋外モジュールで、 もう一つはESP32を使用した自作センサー。 netatmoには温度以外に湿度、気圧、CO2濃度の センサーもついているので、これらの値も表示している。データは、netamoのサーバ(netatom.com)から pythonのプログラムで取得している。

温度センサーを4個取り付けた180cmの棒	netatmo室内モジュール	netatmo屋外モジュール

自作ESP32温度センサーは、 タカチの防水ボックスSPCMに 電池駆動のESP32基板を入れ、 防水のケーブルグランド経由で DS-18B20防水型温度センサー を引き出したもの。 単3電池2本で動作する。

自作 防水温度センサー	タカチの防水SPCMケース使用

防水性は完璧で気に入ったのだが、 実際に動作させると電池の寿命が1ヶ月も無い。 TPS61291昇圧コンバータの使用を止め、 電池の直接駆動に切り替えるが、 あまり変化は無く。 WiFi接続を止め、Bluetooth接続に 切り替えたら、3ヶ月程度持つようになったので、 そのまま運用している。 温度と一緒に電池電圧の変化も記録している。 グラフを以下に示す。

netatmo屋外モジュールは単4電池4本使用だが、 なかなか寿命が長い。1年以上持つのではなかろうか。 省電力運用には、まだまだ修行が必要そうだ。

とりあえずデータをdatabaseに放り込んでおけば grafanaでグラフ表示できるので、なかなか便利だ。 グラフ表示の機能を改善したいところもある。 grafanaの改造で対応できるのか、 自分で独自に作ったほうが楽なのか、 悩んでいる。

プログラムを以下に示す。

import os
os.environ['BLINKA_FT232H'] = '1'
import time
from random import randrange
import adafruit_ssd1306
import busio
from board import SCL, SDA
i2c = busio.I2C(SCL, SDA)
t0 = time.time()
w,h = 128,64
oled = adafruit_ssd1306.SSD1306_I2C(w, h, i2c)
oled.fill(0)
for i in range(1000):
    x0 = randrange(w)
    y0 = randrange(h)
    x1 = randrange(w)
    y1 = randrange(h)
    oled.line(x0, y0, x1, y1, 1)
    t1 = time.time()
    oled.show()
    t2 = time.time()
    print("%4d %.0fms" % (i, 1000*(t2-t1)))

しかし、表示が遅い。 計測するとが128x64dotの 画面更新に 250mSぐらいかかっている。 FT232Hは Hispeed (480Mbps)接続。 4KのFifoを持ち、 MPSSE(Multi-Protocol Synchronous Serial Engine)という専用ハードウェアを搭載しているので、 I2Cの 400Kbpsなんて楽勝だろうと思っていたのだが そうではなかったようだ。

I2Cの波形をオシロスコープで確認する。 確かに 400Kbpsで通信しているが、 バイトが連続しない。 300us毎に1byte通信している感じ。

通信の全体像、上SCL,下SDA。	通信密集部分で見ても、バイトの送信が連続しない。300uSに1byteぐらい。	1byteの通信を詳しく見ると、400KHzで動いている。

MPSSEについて調べると、 I2CやSPI,JTAGのプロトコルを 直接扱えるのかと思っていたが そうではなく、データをコマンドとして 解釈実行することで、さまざまなシリアル 通信を行えるというハードウェアらしい。 I2Cで1byte送信するにも数byteのコマンド＋データを 送る必要があるようだ。

それでも,もっとI2Cを高速化できるのでは ないかという思いはあるのだが、 I2Cは、速度を追求するようなプロトコルではないし、 自分の用途的にも速度はいらないので、 動作が安定しているこの FT232Hを使って行こうかと思う。

調べていてわかったのだが、 このボードはI2Cのclock stretchingには対応していない。 FT232H自体は対応可能なのだが、それには追加の配線が 必要で、このボードでは行われていない。 自分としてはclock strechingは必要ないので問題ない。

秋月の奴の方が実験しやすいのではないか、などと 書いていたが、sparkfunの奴だと実際に使う場面でも コンパクトで、そのまま使えそうなのでこっちにした。 Qwiicケーブル関連も色々購入することになった。

Qwiicケーブル類	USB Type-C / Micro-Bアダプタ	3Dプリンタの交換ノズルも届く。 パイプが5mm程短いが大丈夫か？

実験を始める前に、基板を固定する台を3Dプリンタで製作した。 当然、磁石付き。将来、ケースに作り変える予定。

2mmのネジで固定	裏面には磁石	アダプタ経由でUSBケーブルをつなぐと、 コネクタに力が加わりそうで心配。

USB Type-C変換アダプタ経由で接続すると コネクタに負荷がかかりそうで不安だ。 USBケーブルを支えるような仕組みも考えたい。

PyMCP2221Aを試す

PyMCP2221Aというライブラリを試す。 MCP2221Aの機能(ADC,DAC,GPIO,CLK,I2C)を全て サポートしているようだ。

I2C接続のセンサーを試すと、簡単に値の読み取りなど できるようになった。もう少し派手なデモも欲しいので、 I2C接続のOLEDディスプレイ(128x64モノクロ)も試すが、 うまくいかない。 調べると PyMCP2221Aは 60byteまでの書き込みにしか対応していないことが判明。 そこで 60byte超のデータにも対応できるよう改造してみるが うまくいかない。

Circuit Python Libraryを試す

Adafruitも MCP2221AのUSB-I2Cボードを出しているので、 それ用のPythonライブラリを試してみる。 すると描画はできるが、繰り返すとエラーになる。 試したプログラムを以下に示す。

import os
os.environ['BLINKA_MCP2221'] = '1'
from board import SCL, SDA
import busio
import adafruit_ssd1306
from random import randint
i2c = busio.I2C(SCL, SDA)
oled = adafruit_ssd1306.SSD1306_I2C(128, 64, i2c)
oled.fill(0)
for i in range(1000):
    print(i)
    x0 = randint(0,128)
    y0 = randint(0,64)
    x1 = randint(0,128)
    y1 = randint(0,64)
    oled.line(x0,y0,x1,y1,1)
    oled.show()

実行結果も下に示す。

$ C:/Users/nari/AppData/Local/Programs/Python/Python36-32/python.exe c:/01proj/v385_USB_I2C/python/blinka_test.py
0
1
 ... 中略 ...
86
87
Traceback (most recent call last):
  File "c:/01proj/v385_USB_I2C/python/blinka_test.py", line 19, in 
    oled.show()
  File "C:\Users\nari\AppData\Local\Programs\Python\Python36-32\lib\site-packages\adafruit_ssd1306.py", line 185, in show
    self.write_framebuf()
  File "C:\Users\nari\AppData\Local\Programs\Python\Python36-32\lib\site-packages\adafruit_ssd1306.py", line 232, in write_framebuf
    self.i2c_device.write(self.buffer)
  File "C:\Users\nari\AppData\Local\Programs\Python\Python36-32\lib\site-packages\adafruit_bus_device\i2c_device.py", line 104, in write
    self.i2c.writeto(self.device_address, buf, start=start, end=end, stop=stop)
  File "C:\Users\nari\AppData\Local\Programs\Python\Python36-32\lib\site-packages\busio.py", line 94, in writeto
    address, memoryview(buffer)[start:end], stop=stop
  File "C:\Users\nari\AppData\Local\Programs\Python\Python36-32\lib\site-packages\adafruit_blinka\microcontroller\mcp2221\i2c.py", line 19, in writeto
    self._mcp2221.i2c_writeto(address, buffer, start=start, end=end)
  File "C:\Users\nari\AppData\Local\Programs\Python\Python36-32\lib\site-packages\adafruit_blinka\microcontroller\mcp2221\mcp2221.py", line 298, in i2c_writeto
    self._i2c_write(0x90, address, buffer, start, end)
  File "C:\Users\nari\AppData\Local\Programs\Python\Python36-32\lib\site-packages\adafruit_blinka\microcontroller\mcp2221\mcp2221.py", line 202, in _i2c_write
    raise RuntimeError("Unrecoverable I2C state failure")
RuntimeError: Unrecoverable I2C state failure
$

その他の試み

MicroChip社提供の MCP2111A用DLLを Pythonから使ってみようとするが、 うまくいかず、 Linux用DriverをRaspberry Piで試すが OLEDへの表示はできない。

現象としては、MCP2221Aへ書き込み(USBパケットの送出)を 繰り返していると、コマンドが受け入れられませんでした という状態になり、リトライを繰り返すうち、 復旧不可能な状態になってしまう感じ。

結論

MCP2221のI2Cは、短いパケットであれば 使えているようであるが、 (現状のソフトウェアでは？) 長いデータの書き込み などを安定して行えないようである。

自分の用途では、短いデータのやりとりで 充分な気もするが、動作のわけのわからない 感じが気持ち悪いし USB-I2Cの転送速度の遅さも気に入らないので MCP2221Aの使用は諦めることにする。

次

次は FT232Hを試そうかと思う。 これだと I2Cに加えてSPIも使用可能。 Adafruitの奴はカッコいいのだが、 カッコ良すぎて実験用にピンヘッダをハンダ付け するのもためらわれてしまう。 秋月の奴だと気軽に実験できそう。

こんな簡単な回路なのに間違うはずはない。 部品か基板の製造不良を疑い 2枚めの基板にMCP2221AとUSBコネクタのみ 実装し USBケーブルを接続するが 現象変わらず。

改めて、回路を見直したところ、ミスを発見。 MCP2221Aの11番ピンVUSBを USBコネクタのVbusに 接続していた。　どうも、このピンはIC内部の電源(3.3V)で、 高品質なセラミック・コンデンサでバイパスしろ と書いてある。　Microchip製のbreakout boardの 回路図では　0.47uFのコンデンサ経由でGNDに接続されている。 名前がまぎわらしいんだよ。 ちなみに電源端子は別にあり、電源範囲は 3～5V。

パターン・カットで基板を修正しようと検討したが 11番ピンの下をガッチリ 5Vの配線が通っている。 パターンカットだと面倒だと判明したので 方針を変更。 11番ピンを浮かし、5Vとの間に 1610サイズ1uFの チップコンデンサを実装し、回路修正を行ったところ、 無事、PCにCOMポートとして認識されることになった。

回路修正: 11ピンを浮かし、間にチップコンデンサをはんだ付け

この先は、自分でプログラムを作る必要がある ... と思っていたが、念の為 「MCP2221A python」で検索 すると、いろいろあるようだ。

私のMCP2221A基板の特徴は４つ

• GROVEコネクタ装備
• I2C信号がピンヘッダにも出てる
• I2C動作LED
• GROVE Wrapper対応

GROVEコネクタ

GROVEは、 seeed社が提案する 4本線でマイコンとセンサー等の周辺回路を 接続する規格。 2本の電源ラインと2本の信号線からなる。 seeedはGROVEコネクタが搭載された マイコンボードやセンサーなどの基板をたくさん販売 している。 信号線の使い方はI2Cに限らないが、 I2Cのものが多い。

昔、自分の製作物のi2cのコネクタの規格を統一したいと 考え、適当な4ピン有極の入手製の良いコネクタを探した時、 Groveコネクタの存在を知り、使用するようになった。 Groveだとケーブルも各種安価で手に入るのも良い。

同様のものとして SparkFun の Qwiic があるが、 こちらはJSTのSHコネクタ(1mmピッチ)を 使っていて、小さすぎるし高そうで 食指が動かない。

I2C信号のピンヘッダ

GROVEコネクタが実装されていない基板への接続に 使用するかと思いきや、 GROVE-QIコネクタなどというケーブルがあるので必要ない。 このピンヘッダの目的は、オシロスコープでの観測用。

I2C動作のLED

MCP2221AのGP3にLEDを接続すると、 I2Cの通信時に点灯してくれる。 なかなか良いではないか。

GROVE Wrapper対応

Grove Wrapperは センサー等の小さい基板を固定する プラスチック製品で seeedが販売している。 固定方法はレゴブロック、ネジ等。 私はネジで磁石を固定し使用している。

私は、Grove Wrapperを知った時から 大変気に入って、大いに宣伝しているのだが、 まったく広がらない。 そもそも国内では売ってるところが無い。 共立エレショップは 在庫無しの入荷時期未定だし、 マルツは、納期お問い合わせ下さい。 ということで弊社で 販売を始めた。

小型基板は悲しい。 特に電池を内蔵せず、外部電源が必要だと悲しい。 接続するケーブルのほうが重いので、 ケーブルに引きずり落とされてしまう。 居場所が安定しない。

そこでGrove Wrapper+ネオジム磁石に に装着すると、バッチリ固定される。 USBケーブルなんて楽勝。 オシロのプローブを2本ぶら下げても平気である。 使わない時は適当なところに貼り付けておけば良いので 保管にも便利。

Grove Wrapperと皿穴付きネオジム磁石とM3x10のネジ	磁石装着状態	装着した基板と割れた磁石

ということで、今回のUSB-I2C基板は Grove Wrapperに取り付けられる形状にしてある。 将来、3Dプリンタで専用ケースを作るつもりだったが、 Grove Wrapperで充分かもしれない。 専用ケースを作るとしても磁石は必須だ。

磁石は皿穴付きネオジム磁石。 国内製も買えるが、AliExpressで 安く買うこともできる。 ただし、Aliのやつは割れやすい印象がある。 今回も、近くにおいた磁石同士がくっ付いただけで 割れてしまった。製品として売るものには使えないが、 自分で使う分には問題ない。

Grove Wrapperが電子工作界に普及することを祈念し、 私がノギスで実測し作成した図面と、今回の基板の外形図を 公開する。　自己責任で御使用下さい。

実測して描いたGrove Wrapper図面	Grove Wrapperにハマル基板のサイズ

これでhttpsのRSSが読み込めるようになったので、 読み込み先も更新するのだが、 なんかYahoo!ニュース - RSSにあるものから適当に選べば十分ではないか、 という気がしてきた。そうすれば、このサイトのfingerprintだけ あれば十分なので更新も年1回すれば済む。

ということで、 このページから、ネットやTVであまり見かけなさそうな ニュースソースを意識しながら、海外ニュース（BBC,CNN)とか、 ローカルニュース(熊本日日新聞)とか、お笑いナタリーとかを選ぶ。

しかし このページは、何のために存在しているのだろうか？ RSSでニュースを読む人のために存在しているの？ よくわからない。

更新したプログラムを githubにアップロードした。 これは LCDマトリックスコントローラ用の Arduino Library, Humblesoft_LedMatの サンプルプログラムの一つで esp8266(ESP-WROOM-02)上で動作する。 この コントローラと LEDマトリックス・モジュール と 5V1Aの電源 があれば動作させることができる。

改良点は、以下の通り。

• httpsサイトへの対応
• サイトごとのRSS最大表示数の設定
• その他、表示が不自然なところを減らす

esp8266 Arduinoだと、 httpsサイトへのアクセスも可能だが、 サイトの指紋/fingerprintも指定してやらなければならない。 このfingerprintはchrome等でアクセスし証明書を表示させれば わかるのだが、証明書が変わるたび更新しないといけない。 ということで、これまでhttpsへの対応は行っていなかった。

以前は、httpで提供されているRSSも多かったのだが、 殆どのサイトでhttpsでしかRSSが提供されなくなってきた。 Yahoo ニュースのRSS も httpsでしか提供されない。

ということで、とりあえず fingerprintで httpsへの 接続を行うことにした。

サイトごとの最大表示記事数は、 Make:のRSSが50記事あり、 かなり古い記事まで含んでいるので、その対策。

その他の表示の改良は、RSSの取得に時間がかかる場合、 表示が止まっていたのを、それなりの表示が継続するするよう 改造した。

今回の改良で、以前のように　多くのサイトのRSSを表示できるようになり満足している。 次は LEDに表示している奴 にも同様の改良を施したい。 その次に、fingerprintを使わない httpsへの接続の実験か。

この表示を始めたのは3年ぐらい前なので、 OLEDの寿命は3年程度ということになる。 字が流れる部分などでは、全く暗くなっていないので、 表示の仕方を工夫すれば10年ぐらい使えるものは作れそうだ。

OLEDアップ、ところどころ暗くなっているのがわかる。	このカラーLCDも3年ほど点きっぱなしだが、輝度の低下は起こっていない。	ディスプレイ下にOLEDとカラーLCD

HSES-NODE-OLEDの場合、OLEDモジュールは交換可能で、 300円ぐらいのものなので、モジュールタイプのものを使用する という手もある。

動いている様子。

3年前の動画。

元々、スポンジにたっぷり水を含ませ、 コテ先で盛大に蒸発させるのが好きだったので、 水分が多すぎるのが問題なのかもしれない。 でも、そんなことしてて平気だったということは、 温調式でないハンダゴテはどんだけ温度が高いのか、という話でもある。 そういえば、以前は熱収縮チューブもハンダゴテで処理できていたが、 温調式だとなかなか縮まない。

では、替りにどうしているかというと 「もじゃもじゃ」こと 真鍮製のワイヤー式コテ先クリーナーと メモ帳できれいにしている。

もじゃもじゃ、だけではどうしても コテ先に若干ハンダが残ってしまう。 そこで、コテ先の平らな部分をメモ帳に擦りつけて きれいにしている。 コテ先に 円錐斜めカットタイプ を使用しているからできることかもしれない。 これでハンダは全く残らない。 もじゃもじゃを使わず、メモ帳で拭くだけだと 側面にハンダが残ってしまう。 もじゃもじゃは必須。

メモ帳を使用している理由は、 適当な厚みがあり使いやすい、 汚れたら1枚つづ廃棄できる、 コンパクトで場所を取らない、 不要なものが大体その辺に転がっている、 などである。

ハンダゴテ、コテ台、もじゃもじゃ、メモ帳にスポンジ	もじゃもじゃで拭く	メモ帳で拭く

たまにスポンジでコテ先を拭くと、 キレイだな、と思うので メモ帳方式は、キレイさでは負けるかもしれない。 しかし、はんだ付け作業の前後に水を扱わないで済むという メリットは大きい。 お勧めする。

温度センサーは、Amazon等で安く売っている ステンレス管入り防水DS18B20を使用する。5個で1050円。 マイコンは手持ちの関係で OLED付きESP-WROOM-02(ESP8266)マイコン HSES-NODE-OLED。 で、ステンレス管入りのDS18B20を見ているうち、 ホルダーを作ったら便利だし、カッコいいのではないかと 思いつき、作ったらやっぱりカッコよかったという話。

今回のホルダーはサポートなしで印刷。 穴は若干の対策を施し問題なし。 PLAだとサポートの取り外しに苦労していたので、 サポート無しでプリントできるのはありがたい。 作り直しは1回。隙間の大きさを見誤った。 拘束が(たぶん)適切に入っているので 寸法の修正だけで修正できた。

スチール製のケースに入った3Dプリンタ周りに取り付けるため、 ホルダーには皿穴付きネオジム磁石が取り付けてある。 マイコンを固定する Grove Wrapperにも 磁石が取り付けてある。

Fusion360で設計	センサー5本 ホルダーがカッコいいと思う。	DS18B20のケーブルには3PのQIコネクタを取り付け 基板に接続
ホルダー背面には皿穴付きネオジム磁石	HSES-NODE-OLED	こちらの背面にも磁石

プログラムはds18B20で温度を計測できるところまで作ったところで、 未完成。プログラムの進みが遅い理由を挙げると

• 何度も作ったことがあるプログラムなので、新味が無く、面倒
• platformIOを初めて使った。いろいろ引っかかる。

Arduinoのプログラミング環境として platformIOの名前は前から聞いていたが 食わず嫌いで全く調べていなかった。 で、なんか VSCodeで使える。 pythonで書かれているとか聞いて 試してみたら、コンパイルはMakefile並に早い。 プログラムの書き込みもできるし、シリアル端末も使える。 そこまでは良いのだが、VScodeのc++環境(intelliSense?)の 設定がよくわからない。 ソースファイルを開けませんとかエラーが出る。

c_cpp_properties.jsonの設定が必要だということが判明し、 さらに PlatformIOのPROJECT TASKSのRebuild IntelliSense Indexで このファイルを設定してくれることがわかった。 いいかげん、ちゃんとプログラムを完成させ温度を計測しよう。

このホルダーを作った後に HSES-NODE-OLED + HSTS-ATD7410 x 4個の構成でも 温度計測できることに気がついた。 こちらの構成だとGrove Wrapperで全部固定できるので、 新たにホルダーを作る必要はなかった。

磁化の問題だけでも無くなれば、結構楽になるかもしれない と考えて エンジニアのPTN-02を アマゾンで購入。2,690円。 他のピンセットと見分けやすいよう、 先細タイプを選択。 目に優しいと書いてあったが本当だろうか。

PTN-02は革ケース付き。 識別に便利か？ じゃまなだけか？	手持ちのピンセット。上から チタンピンセット 3000円くらい、 鉄腕ピンセット 1000円ぐらい, goot TS-10, 秋月で300円、 HOZAN P-87, 100円ぐらい、 あとHOZAN P-891 1000円ぐらのもあるはずだがみつからない。	上 チタンピンセットPTN-02 下 鉄腕ピンセット PT-17 PT-17の先平形状は気に入っている。

本当に使いやすいのか、耐久性は大丈夫か？などの話は 使用経験を積んだ後、書いてみたい。

先週、３Dプリンタを移動した際に 小型のパーツケース（HOZAN B-103)を 机の横に移動したので、こいつに入らないかと 試すと、サイズ感が丁度いい。

パーツケースの仕切りをいれるスリットで 間隔調整ができるように設計をし直し、 さらにジャンパワイヤの種類・色を明示できる ラベルを貼るパネルを追加したり、 して完成。 パーツケースのスリットに微妙なテーパーがついていることに 気が付かず試作回数が増えた。

ThingiverseにあったDupont Cable Organizer Cusomizable, Thingiverse上で寸法等を変更可能。	設計データ。これを2組つくる。	パーツケースに入れてみる。　反対側にもラベルがないとケーブルを指す場所が分かりづらいと気付き、このあと追加。
櫛２つにパネル1、プリントアウトしたラベル1。パネルとレベルはこのあと追加。	手持ちのケーブルを入れてみました。

手持ちのジャンパ・ワイヤを入れてみる。 長さが揃っていないといけないので、 ジャンパ・ワイヤを選ぶ。 今回は、 スイッチ・サイエンスで売ってあるQIコネクタが付いた 長さ155mmの奴に合わせている。 各スロットに4本挿入可能。 パーツケースの高さには余裕があるので、設計しなおせば 倍ぐらいまでは増やせそう。

データは Thingiverseで公開。

電源を繋ぐは面倒。 電池式にしたいが、何本も 使いたくない。１本からの昇圧タイプにしたい。 秋月の1.5V電池☆白色LED投光キット を使うと楽そう。購入し組み立て。 現物の顕微鏡にあてて、配置を検討すると 鏡胴の奥にぶら下げると良さそうに見える。 そのためのフックを３Dプリンタで作成する。

出来上がったものを組み立て、 組み合わせてみると、計測抜けで 干渉する部分もあるが、取り付けは可能。 完成ということにする。 １灯式だし、これで良いかわからないが、 しばらく使ってみて、具合が悪かったら、 また作り直すとしよう。

Fusion360で設計	秋月のLED投光キットと取り付けフック	顕微鏡に取り付けた状態。斜めになったのは設計ミス。

Fusion360で設計。３つの部品になりました。	1Kgの透明のフィラメントを使い切り、赤いフィラメントに交換。	赤いフィラメントでプリントすると何か新鮮に感じる（当社比）
こんな感じです。フタにM2の埋め込みナット。底面に磁石を装着。	ダイソーの13mmネオジム磁石	裏からM2の皿ネジで固定
USB端子	USB端子の穴。もっと塞ぐべきだった。	磁石で固定

形が変なのは、モジュールをピンヘッダで取り付けたたのと スイッチ・LEDの配置をちゃんと考えていなかったせい。 全体を小さく作り直したい気持ちもある。

ダイソーの直径13mmのネオジム磁石を埋め込んだので、 邪魔にならない位置に常時置いておける。予想以上に 便利だ。

Adafruitのケースの作り方の動画とか見て 今は普通に３Dプリンタでケースを作る時代なのだと 実感する。

急に基板の３Dデータを出力できる基板CADに 魅力を感じ始める。 KiCAD ? DesignSpark PCB？ 使い慣れたEAGLEから移るのツライのよねぇ。

ヤバイので３Dプリンタで XHコネクタ抜きを作成することにした。 JSTのサイトからXHコネクタの３Dデータを ダウンロード。 Fusion360で読み込み、それに合わせて 形状データを作成、プリントアウトすると 一発で使えるものができた。

はめ込んで、軽くひねるだけで外せる。ケーブルには一切負担がかからない。 いろんなピン数に対応できる 汎用品を作るのは難しいが、 これなら、必要になった都度、 プリントして使っても良さそうだ。

JST提供３Dデータ	設計したXHコネクタ抜き	噛み合せたところ
指で外すのはツライ。ついケーブルに力をかけてしまう。	XHコネクタ、赤いケーブルがヤバイ	XHコネクタ抜きならラクラク抜ける。

その後、PIC32MX220でコントローラを製作し、 ステッピングモータを なんとか期待通りに動かすことができた。 しかし、PIC32MX220だと端子が足りない。 ステッピングモータ3個ぐらいは接続したいし、 リミットスイッチ等も接続したい。 ということで、 stm32f205あたりを使って基板を起こそうかと検討中。 ３Dプリンタまで、なかなかたどり着きそうにない。

ということで、 ３Dプリンタを使いたいがために ステッピングモータで いろいろやっている。 ３Dプリンタで、実際に使うフック等の 生活ネタを作成するのも 実利もあるし楽しいのだが、 どうしてもネタが限られる。 面白いメカモノを作るために 動力源を確保しようとしているわけだ。

設計時考慮したのは、以下の3点。

• 保管時の基板・端子保護のため、フタが必要。
• 測定時はフタは外せる。
• スイッチと端子の説明をつけたいので、 基板周りにスペースが欲しい。

試行錯誤の結果、こんな形に出来上がった。

写真

部品一式	合わせてみる	底にネジ
キャップ装着状態	ラベル	使用時、 キャップは後部に装着可

データは Thingiverseで公開中。 fusion360のデータも付けてます。

実用に耐えるものができたと思う。 で、実際に使ったかというと、 まだ使っていない。

ケース作りたいから買ったのではないかという疑惑が残る。

2002年に、100万円ぐらいするのを ６年リースで導入。 ６年経ったら、リース料が 2万円/年ぐらいに 下がったが、それを10年ぐらい払ってしまった。 ものは良いのだが、今後も2万円/年を払い続けるのは、 どうよ、と思い始め、リース会社に買い取ったら幾らか 聞いたら、２年分といわれたので、返却し、 新たに購入することにした。

帯域も 350MHzまではいらないが、 ロジアナ機能は欲しい、ということで いろいろ検討後、 RIGOLがよさそうだという ことになった。

右に、内容物の写真を示す。 マニュアルは中国語と英語。 電源ケーブルは、中国用？

プローブその他の付属品をいれるための、 ポーチを買わなくては行けない。 Aligientは、ポーチが付属し、 オシロに背負う形になってたのよね、 そこは良かった。

最後に、USBメモリで取った、画面コピーを貼る。

テストプログラム

使用したライブラリは Adafruit_Python_SSD1306。 グラフィック・ライブラリ Pillowのimageのデータを、そのまま表示できる 使い易いライブラリだ。 以下のプログラムを動かしてみた。

import Adafruit_SSD1306,time
from PIL import Image,ImageDraw,ImageFont
disp = Adafruit_SSD1306.SSD1306_128_64(rst=None,i2c_address=0x3C)
disp.begin()
image = Image.new('1',(disp.width,disp.height))
draw = ImageDraw.Draw(image)
font = ImageFont.truetype(
    font='/usr/share/fonts/truetype/freefont/FreeMono.ttf',
    size=50)
t0 = time.time()
draw.text((0, 0), 'Test', font=font, fill=1)
t1 = time.time()
disp.image(image)
t2 = time.time()
disp.display()
t3 = time.time()
print('draw text : %f' % (t1-t0))
print("disp image: %f" % (t2-t1))
print("display   : %f" % (t3-t2))

実行結果は次のようになった。

pi@raspberrypi$ python speed_test.py
draw text : 0.001905
disp image: 0.033468
display   : 0.116709
pi@raspberrypi$

データ転送に 0.116秒かかっているが、計算の 0.08秒とは さほど違わない。次に /boot/config.txtに以下の行を追加後 rebootし、 i2cを400kbpsにして試してみる。

dtparam=i2c_baudrate=400000

実行結果

pi@raspberrypi$ python speed_test.py
draw text : 0.002004
disp image: 0.033668
display   : 0.036361
pi@raspberrypi$

データ転送は期待通り約4倍高速化されたが、 disp imageの 0.033秒が大きい。 これはPillowのImageのデータをOLEDのバッファの フォーマットに変換する処理で、ソースを見ると Pythonで1bitづつ処理している。 この処理に時間が掛るとデータ転送を 早くしても、表示はあまり速くならない。

ライブラリ作成

ということで、 ラズパイ i2c接続OLED用に Pythonのライブラリを作ってしまった。 githubで公開している。

i2cの操作は直接 /dev/i2c-1とかをオープンして行っている。 ここの資料を見ながらプログラムしたら、 特に問題もなく出来た。

テストプログラムで確認

新しいテストプログラムで処理時間を調る。 テストプログラムを新しいライブラリ用に若干修正した。

import time
from PIL import Image,ImageDraw,ImageFont
from RaspiOled import oled
oled.begin()
image = Image.new('1',oled.size)
draw = ImageDraw.Draw(image)
font = ImageFont.truetype(
    font='/usr/share/fonts/truetype/freefont/FreeMono.ttf',
    size=50)
t0 = time.time()
draw.text((0, 0), 'Test', font=font, fill=1)
t1 = time.time()
oled.image(image)
t2 = time.time()
oled.vsync()
t3 = time.time()
print('draw text : %f' % (t1-t0))
print("disp image: %f" % (t2-t1))
print("sync      : %f" % (t3-t2))

実行結果は次のようになった。 ちなみにi2sの速度は400kbps

pi@raspberrypi$ python3 speed_test2.py
draw text : 0.001897
disp image: 0.000538
sync      : 0.023852
pi@raspberrypi$

OLEDバッファへの書き込み(disp image)は0.0005秒になり、 データ転送も 0.023秒と高速化された。

で、やっぱり Bad Apple

ここまでやると、当然やるのはBad Apple。 Bad Appleの動画をffmpegでフレームごとに bmpのファイルに変換し、 画像表示プログラム( image.py)で 再生している。今回は音もwavファイルに変換したものを ラズパイのaplayコマンドで同時に再生している。 ちなみに 画像表示プログラムとaplayを同時に走らせると、 画像が遅れるので、sleepコマンドで1.6秒後にaplayを起動している。

RssDisp

動画 BadAppleを再生できるのは良いのだが、まだなんか不満。 Oledでグリグリヌメヌメ表示できることを示したい。 HSES-NODE-OLEDで動かした RssDispを動かしたい。

で、実装したのだが、予想外に手間がかかった。 文字のスクロール表示は、当初Pillow側でやろうかと思って いたのだが、あまり効率よくできそうな気がせず、 ライブラリに表示イメージをずらす機能を追加。 更にテキストをスクロール表示させるクラスも ライブラリに追加。 これでやっと RSSの表示プログラム rssDisp.pyが完成した。

HSES-NODE-OLED版とほぼ同じ動作が実現できた。 こちらの方が https サイトにも対応しているので、 表示できるRSSサイトが多い。 ESP8266/Arduinoでも httpsサイトへのアクセスはできるのだが、fingerprintを 入力する必要があり、面倒なので使っていない。

でもまぁ、HSES-NODE-OLEDの方が表示しっぱなしでも 惜しくないので良いかもしれない。 HSES-NODE-OLEDは スイッチサイエンスで発売中。

あとOLEDは、とりあえず、Adafruitのpythonライブラリ で試しただけだが、スクロールのデモとかみると 表示が遅い。I2Cだから仕方がないのかもしれないが、 高速化ができないか、試してみたい。

• シリアルコンソール接続用コネクタ
• RTC(リアルタイムクロック)
• I2C接続OLED
• 押しボタンSW×4
• FAN ON/OFF回路
• I2C用Groveコネクタ

使わなければ実装しなければ良いのだ。 若干のフリー配線領域もあるので 2.54mmピッチのコネクタであれば 取り付け可能かもしれない。

今後、動作の確認、資料の準備などの後、 ハンブルソフト WebShopにて 基板のみで販売する予定。

乞うご期待。

Windows上の上のemacsといえば、 昔はmeadowとか使って不満は無かったのだが、 更新されなくなり、 gnupack の emacs だとIMEパッチが当たっていて 良いのだが、 makeコマンドが無い？ 導入方法がわからないため、 導入が楽なcygwinのemasを使用し、 日本語はだましだまし使っていた。

今回、stm32のプログラムを開発するに当たって、 日本語のメモをたくさん書いていきたいと考えたため emacsに我慢できなくなり、vscodeの 環境構築にトライしてみた。 electronのプログラムで VS Codeに慣れてきたというのもある。

makeの実行

まず、vscodeからmakeコマンドの起動。 タスクの構成で、 tasks.jsonファイルを 以下のように設定することで何とかなった。

    // See https://go.microsoft.com/fwlink/?LinkId=733558
    // for the documentation about the tasks.json format
    "version": "2.0.0",
    "tasks": [
        {
            "label": "make",
            "type": "shell",
            "command": "/c/MinGW/msys/1.0/bin/make.exe write ",
            "options": {
                "cwd": "${workspaceFolder}/src"
            },
            "group": {
                "kind": "build",
                "isDefault": true
            },
            "presentation": {
                "echo": true,
                "reveal": "always",
                "focus": false,
                "panel": "new",
                "showReuseMessage": true
            },
            "problemMatcher": {
                "owner": "gcc",
                "fileLocation": [
                    "relative",
                    "${workspaceRoot}/src"
                ],
                "pattern": {
                    "regexp": "^(.*):(\\d+):(\\d+):\\s+(.*):\\s+(.*)$",
                    "file": 1,
                    "line": 2,
                    "column": 3,
                    "endLine": 2,
                    "endColumn": 3,
                    "severity": 4,
                    "message": 5
                }
            }
        }
    ]
}

problemMatcherも定義しているので、 コンパイル時のエラーも「問題」パネルを 開けば、クリック一発で問題箇所を開くことができる。

emacsのnext-errorコマンドみたいに、 1コマンドで「問題」パネルを開き、最初の問題を選択してくれると 嬉しいのだが、そのようなコマンドを未だ発見できていない。

プログラムの自動フォーマット

keybinds.jsonで ctrl+I を押した時 editor.action.formatが呼び出され インデントの修正等、自動で行われるようにしているのだが、 Cのプログラムを編集しているときctrl+Iを押しても、 Cのフォーマッタが無いというようなエラーが表示されるだけで、 フォーマットされない。

そこで、 拡張機能 Microsoft C/C++ for VS Codeを導入。 無事、フォーマットされるようになった。

includePathの設定

しかし、使っていると includePathの設定がされていない、 というメッセージが出るようになる。 面倒で無視していたのだが、 C/C++拡張機能のお蔭で、高度な機能（intelliSenseとか 定義に移動とか）使えるようなので、 真面目に設定してみた所、 設定ファイルc_cpp_properties.jsonは 次のようになった。

{
    "configurations": [
        {
            "name": "Win32",
            "includePath": [
                "C:\\cygwin64\\usr\\include",
                "C:\\cygwin64\\usr\\include\\w32api",
                "C:\\gnu_tools_arm_embedded\\6-2017-q2-update\\arm-none-eabi\\include",
                "C:\\gnu_tools_arm_embedded\\6-2017-q2-update\\lib\\gcc\\arm-none-eabi\\6.3.1\\include",
                "${workspaceFolder}\\src"
            ],
            "defines": ["__CYGWIN__"],
            "intelliSenseMode": "clang-x64",
            "compilerPath": "/c/gnu_tools_arm_embedded/6-2017-q2-update/bin/arm-none-eabi-gcc.exe",
            "cStandard": "c11",
            "cppStandard": "c++17"
        }
    ],
    "version": 4
}

これで、だいたい、使えるようになったのだが、まだ問題がある。 なんか includePathに定義していないPath C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\includeが含まれているようなのである。 stdint.hで「定義へ移動」とすると、このフォルダーのstdint.hが 表示されてしまう。これはどうしたら良いのだろうか。

インストール方法・使い方は GitHubのWikiに書いたので 一度、見てみて欲しい。

表示できるメッセージは、

• スタティック・テキスト: 文字列を内蔵Fontで描画、動きなし
• スクロール・テキスト：文字列をスクロール表示
• 画像（静止、スクロールとも）
• 動画（未リリース）

などがあるが、使い方を説明しているのは、上２つまで。 画像はリリースしているが、説明が未だ。 動画は、完成しているが、変換プログラム(FFmpeg)の 説明を検討中で未リリース。

あと、メッセージをzipファイルでアップロード/ダウンロード する機能もある。

今はブラウザ・Javscriptの各種ライブラリが凄いので、 Webインターフェースをつけると、高機能なUIを 簡単に作れてしまう。

AliExpressや他のものも、恐らく動くとは思うが、 動作保証はできない。理由は、試せないし、 種類が多いし、なんかすぐ変わるから。

うちで仕入れたLEDモジュールも、信号配置が違っていた。 RGBがGBRにずれている感じ。驚いたが、他の人が開発した ソフトを調べたら、そのような違いに対応できる機能が 入っていたので、よくあることなのだろう。 うちでもソフトで対応した。

あと、HSES-LMC1は、信号レベルが3.3V。 私は、これで動作しないLEDモジュールに 未だ出会ったことはないが、 他の人のLEDモジュールの記事を見ると、 5Vでないと動かないモジュールもある、と書いてあるので そうなのかもしれない。

もとどおりに組み立て、修理は完了した。

部品を交換せず、分解&ブロー した方と交互に使用しているのだが、 こちらも、まだ、問題なく使用できている。

交換しない方も、意外と長く使用できている。 どれくらいまでしようできるか、 今後も試していく予定。

結構オリジナル。 FTDIのコンパチ品かと思っていたのだが、 実際に調べてみるとFTDIとは全然ちがう。 入出力は5V一択だし、 送受信でLEDを光らせる機能もない。なんか、自分たちがUSBシリアルアダプタを作るのに 必要なものを作ったように見える。

R232という入力ピンがあり、 適当に処理していたら、 なんとTX/RXの信号レベルを反転させるピンではまった。 どうも RS232用の簡易レベルコンバータ (トランジスタ1個でつくるようなやつ） を使用するためにあるらしい。

データシートが中国語の奴しかみつからない。 メーカーのホームページで探しても、中国語のものばかり。 CH340Cを使用したのだが、 aitendoのCH340Tのページにある 英文データシートを参考にした。

ドライバーは、Windows10には含まれているようで、 接続するだけで使用できた。

中国製ということで抵抗はあったが、安いは正義。 今後、どんどん使っていくことになると思う。

プログラムの改造は簡単だったが、 動作の確認のためRaspberry-Piから 音を出すのに手間取った。

まず hzeller/rpi-rgb-led-matrixを動かすには /boot/config.txtで dtparam=audio=off しなければいけないので、 Raspberry Piのaudio出力は使用できなし、 HDMIへの音声出力も使えなくなる。

USB-speakerやbluetoothへの出力は可能なので、 まず手持ちのbluetoothスピーカで試すと、 音は出たが、厳しい条件の動画(60fpsのやつとか）を 再生させると音が出なくなり、復旧できなくて あきらめた。

USBスピーカを購入し試すと、音は出るが 最大音量で、音量調節が効かない。スピーカ側に ボリュームやミュートのスイッチはあるのだが、 どうもソフトウェアでコントロールするタイプのようで、 Windowsでは機能したがRaspberry Piでは動かない。 amixerコマンドで音量調節を試みるが、 あまり音量が変化しなかったり、無音になったりと 極端でうまく音量調節できない。 無音になる寸前の数値で、ある程度音量調整できたので、 そこで動画を撮影した。 アナログのボリュームつまみがついたUSBスピーカが欲しい。

まず、LAN8720モジュールのクロックを止める必要がある。 パターンカットでいけるかと思ったが、パターンが見えない。 回路図を見て、 R12,R14から追っていけばわかりそうだが、 部品名が書いてないのでどれがR12,14だかわからない。

あきらめて発振器を取り外すことにする。 はんだごて2本あれば行けそうだが、 何故か1本しか無い。 仕方が無いので SMD Rework Stationを引っ張り出して、取り外した。 Rework Stationは、半田ごての方はFX-888を購入したので 使わなくなったが、 Hot Airの方はよく使う。便利だ。

スケッチの例「ETH_LAN8720_internal_clock」を呼出し、 コンパイルする。何故か ETH_CLK_MODEの定義が ETH.hと重複し、コンパイルエラーとなるので、 setup()で呼び出している ETH.beginの引数で 直接ETH_CLOCK_GPIO17_OUTを指定。

その後、試行錯誤のあと、回路などを修正し、 無事 Ethernet経由でインターネットから情報を取得できた。 最終的な回路、というか LAN8720 PHYモジュールとESP32の 接続は次のようになった。

MDCとMDIOに接続しているIOは変更可能、他は変更不可。 IO25とIO26が使用されているのでDACが使えないのが残念。

LAN8720はAliExpresで買えば$2程度。 発振器を外すだけで ESP32のEthernetの実験ができるのは、 悪くないと思うのだが、どうだろう。

動かしてみようとして 初めて miniHDMI変換アダプタとUSB-microB OTGケーブル が必要なことに気がつく。 スイッチサイエンスの Raspberry Pi Zero W ケースキット を書い直そうかとも思ったが、 余分な基板を持っていても碌なことがないので、 アマゾンに miniHDMI変換アダプタとUSB-microB OTGケーブル を注文した。合わせて1,100円ぐらい。 スイッチサイエンスのを買っておくんだった。

ケース付きを買った理由は、ケース無しが売っていない、 在庫が無いから。抱き合わせ販売か？とも思うが、 在庫があるだけありがたいのかも。

ケースは思ったよりかっこよいが、 実際に使う時は、ケーブル刺しまくりになるので、 固定能力は無いに等しい。 ケースというより基板カバーと読んだほうが 実態を表すように思う。

プログラムの仕組は、まだ理解していない。 サウンド出力ハードウェアを使用しているそうで、 同時に音を出力することは出来ないらしい。

LEDとRaspberry Piの電源を完全に分離したのは良かった。 おなじ５Vの電源を２つ用意するのは面倒だが、 LED側電源が容量不足で電圧低下が起こっても、 RasPi側には影響ないのは安心だ。 動画では 64x64dot, 1/16スキャン、 LEDの消費電流は20mAなので、 全点灯時は 64 x 64 x 3 / 16 x 20 [mA] = 15.36[A]の電流が 流れる。これだとACアダプタでは間に合わない。配線も大変だ。

動画では2.5Aの実験用電源を使用しているが、電流超過で しばしば電圧が下がって、表示が赤っぽくなっているのがわかる。 電圧が下がると赤っぽくなるのは、赤色LEDのVfが2V程度で 青色、緑色の4V程度と比べると低いため、電圧が下がると 赤色のみ明るく光るため。

今回のプログラムは、思ったほど消費電流が多くない。 LEDをフルに光らせることができていないのかもしれない。

hzeller/rpi-rgb-led-matrix は、相当、良く出来ていると思うのだが 不満な点もある。

オプションが面倒。 LEDの構成に関する長いオプションを毎回入力する 必要があるのが不満。 ドットファイルでオプションを指定できるように して欲しい。

video-viewerのフレームレートがデタラメ。 音が出力できないので、必要性を感じていない のだと思うが、動画再生のフレームレートの 処理が手抜きだ。プログラムを見たら、 各フレームの処理後に 1/fps秒のディレイを 入れているだけ。フレームの処理時間分だけ ずれていく。

Qiitaに書いた 同期処理 の 方法でやれば、簡単にフレームレートを 合わせることができるはずなので、試してみたい。

実際に使おうとすると、raspberry-piは面倒。 実験している分には面白いが、 機器に組み込んで実際に使おうとすると raspberry-piは面倒だと思ってしまう。 理由は fsprotectの組込みと ファイルシステム(SDcard)のバックアップが 面倒だから。

fsprotectというのは、SDcardのファイルシステムを ReadOnlyで運用し、それにRAM-Diskを被せ、 通常の読み書きできるファイルシステムに見せかける システム。　電源を落とせば、変更された内容は すべて消えるかわりに、いつ電源を落としても問題ない。 これ無しにRaspberry-Piを連続運転させると shutdownせずに電源を落としたときに SDCardの内容が壊れる可能性があるし、 そうでなくても (swap等で）書き込み過ぎでSDCardが壊れると言われている。

fsprotect自体はapt-getで導入可能だが、 kernelにaufsを組み込む必要があり、 自分でソースをダウンロードし、パッチを当て カーネルを作り直さないといけない。 先人たちの情報がいろいろあるとはいえ、 なかなか面倒。 これをdistributionで面倒見てほしいと 常々思っている。

あと、いろいろやっているうち、SDCardが壊れる可能性は 高いので、バックアップの必要がある。SDCardのイメージ毎 保存しておけば良いのだが、4Gとか8Gとかのファイルを 残すのに、効率の悪さを感じる。といっても、コマンド一発だし、 ちょっとした動画のファイル程度の大きさなので、 単に慣れの問題かもしれない。

次は、Raspberry-Pi Zeroでも動くか試してみたい。 プログラムの仕組も理解したい。 ESP32CompositeVideoの仕組も調べてないし、 宿題がたまる一方だ。

詳しい話は、まだ調べていない。 表示可能なドット数とか階調とか、あとでちゃんと調べたい。

ビデオ出力: PIC16のPongのプログラム以来、 マイコンでビデオ出力ができるようになったが、 今回の衝撃的な点は、付加回路が全く必要ないこと。 DAC出力だから可能なのはわかるが驚いた。

I2S+DMA: ESP32のI2S+DMAは、いろいろ応用が利いて、 なかなかのアイデアだと思う。 I2Sだけでなく、AD,DAでも使えるし、パラレルでも 使えてOV7670（カメラ）のデータを読んだり、 LCDにデータを出力したりもできる。 他のマイコンでも真似して欲しい。

ビデオ出力(2): でもあまり、ビデオ出力に魅力を感じない。 ビデオの出力装置（TV,モニタ）は結構大きいし、 すでに十分魅力的な機器（パソコン、TV,ゲーム機）が 接続されている。中途半端な性能なものをつなぐ気に なれない。低価格なマイコンには、小型で安価なLCDやOLEDが バランスが良いように思う。

USBホスト機能がESP32に必要ではないか？ 私は凄く欲しい。 USBホストがあり、キーボードやマウスを接続できれば、 ESP32を昔のパソコンみたいに使える。 SPI経由でUSBホストICを繋ぐのは、ちょっとやだ。

デモ内容に興味: ESP32CompositeVideoは、デモプログラムで ポリゴンで構成された立体物（ビーナス像、骸骨、ドラゴン、ロゴ） を回転させながら表示させているのだが、 ESP32で、こんなことができるのだと感心。 勉強して、ESP32+LCDなどに表示させてみたい。

最新の esp-idf環境でESP32_bt_speakerをコンパイルしてみるとエラーが沢山発生。 ひとつづつ対応するのも大変なんで、元となったサンプルプログラム bluetooth/a2dp_sinkから再び作り直すつもりで、a2dp_sinkを コンパイルしてみると、I2Sと内蔵DACへの出力機能が 追加されていることが判明した。

これが動くのであれば私のESP32_bt_speakerは、お役御免。 今後、私が面倒を見なくても良くなる、と思って プログラムをESP32開発ボードに書き込むも 音が出る様子は無い。

わたしのプログラムと見比べながら、修正と試行を繰り返し、 音が出るようになった。I2S出力側は、実験できないので わからないが、内蔵DAC出力側は、テストされていないような 感じがする。

修正は pull requestを出して esp-idf側に反映してもらいたい ところだが、やり方がよくわからないので、 とりあえず ESP32_bt_speaker側を更新しておいた。

変更点を以下に示すので、これを見て a2dp_sinkの ソースを変更してもらっても良いと思う。

diff --git a/examples/bluetooth/a2dp_sink/main/bt_app_av.c b/examples/bluetooth/a2dp_sink/main/bt_app_av.c
index 289c1f16..4958e3d9 100644
--- a/examples/bluetooth/a2dp_sink/main/bt_app_av.c
+++ b/examples/bluetooth/a2dp_sink/main/bt_app_av.c
@@ -53,7 +53,27 @@ void bt_app_a2d_cb(esp_a2d_cb_event_t event, esp_a2d_cb_param_t *param)
 void bt_app_a2d_data_cb(const uint8_t *data, uint32_t len)
 {
-    i2s_write_bytes(0, (const char *)data, len, portMAX_DELAY);
+    TickType_t delay = 50 / portTICK_PERIOD_MS;
+    if(len % 8){
+      ESP_LOGE(BT_AV_TAG,"unexpected data len:%u",len);
+      return;
+    }
+
+    for(int i=0; i<len; i+= 4){
+      uint16_t d[2];
+
+      d[0] = data[i+0]|(data[i+1] << 8);
+      d[0] ^= (1 << 11);
+      d[0] <<= 4;
+      d[1] = data[i+2]|(data[i+3] << 8);
+      d[1] ^= (1 << 11);
+      d[1] <<= 4;
+
+      int n = i2s_push_sample(0, (const char *)d, delay);
+      if(n < 0)
+	ESP_LOGE(BT_AV_TAG, "i2s_write_bytes error:%d",n);
+    }
+
     if (++m_pkt_cnt % 100 == 0) {
         ESP_LOGI(BT_AV_TAG, "Audio packet count %u", m_pkt_cnt);
     }
diff --git a/examples/bluetooth/a2dp_sink/main/main.c b/examples/bluetooth/a2dp_sink/main/main.c
index a6093386..30ee28a2 100644
--- a/examples/bluetooth/a2dp_sink/main/main.c
+++ b/examples/bluetooth/a2dp_sink/main/main.c
@@ -54,14 +54,14 @@ void app_main()
     i2s_config_t i2s_config = {
 #ifdef CONFIG_A2DP_SINK_OUTPUT_INTERNAL_DAC
-        .mode = I2S_MODE_DAC_BUILT_IN,
+        .mode = I2S_MODE_DAC_BUILT_IN | I2S_MODE_MASTER | I2S_MODE_TX,
 #else
         .mode = I2S_MODE_MASTER | I2S_MODE_TX,                                  // Only TX
 #endif
         .sample_rate = 44100,
         .bits_per_sample = 16,
         .channel_format = I2S_CHANNEL_FMT_RIGHT_LEFT,                           //2-channels
-        .communication_format = I2S_COMM_FORMAT_I2S | I2S_COMM_FORMAT_I2S_MSB,
+        .communication_format = I2S_COMM_FORMAT_I2S_MSB,
         .dma_buf_count = 6,
         .dma_buf_len = 60,                                                      //
         .intr_alloc_flags = ESP_INTR_FLAG_LEVEL1                                //Interrupt level 1

このプログラムには、まだ問題が残されている。 １つは音量を上げた時、音割れする問題で、 もう一つは 通信を中断させた場合DMAバッファに 音データが残り、鳴り続けてしまう問題である。

音割れの方は、DACが8bit, Bluetooth上のデータも12bitなので、 ボリュームを上げていけば音割れするのは仕方ないような 気もするが、 iPhone単体や、他のbluetoothスピーカーで試すと ボリュームを上げても音割れしない。

データ操作のバグも疑い、いろいろ試すがわからない。 仕様なのではないかという気もするのだが、 どうなのだろう。

切断後、音が鳴る問題は、音の出力先を切り替えるなどすると、 発生させることができる。通信の切断の検出はできるので、 ここでDMAバッファをクリアする処理を書いてみたのだが うまくいかなかった。やりかたがまずかったのかもしれない。

Bluetoothについての知識が乏しいので、 ちゃんと対策しようとすると、 なかなか苦しい。

現物が届いて、両面テープで固定するタイプであることに気付いた。 あまり机に両面テープで固定したりしたくない。 しばらく考えて、手持ちのネオジム磁石を2個両面テープ貼り付け、 これで固定することにする。良い感じだ。

結局、これで何のケーブルを固定するかというと、 オシロスコープのプローブのケーブルを固定することになりそうだ。

先人たちの足跡を検索してみると IDF環境でOV7725を接続した例や、 Arduino環境でOV7670を接続した例が見つかる。

とりあえずブレッドボードで後者を試してみる。

回路図は、こんな感じ (前述の記事の回路図です）。

LCDは接続しないので、プログラムを適当に修正しESP32に書込み試してみるが、ブラウザに画像が表示されない。 いろいろ試すとジャンパー・ケーブル（ブレッドボード上の配線）を 動かすと、表示されることがある。 ジャンパー・ケーブルがWiFiの通信を邪魔していると考え、ユニバーサル基板上でUEWケーブルを使って配線し直す。

プログラムを動かすと、多少は改善されたが、表示されないことが多い。Wiresharkで見ると、パケットが欠落している感じ。電源の容量不足を疑い、5Vのラインや3.3Vのラインを強化してみたところ、改善は見られるが、基板の位置、角度によって通信できたり出来なかったりする感じ。

i2sのプログラムとWiFiの通信が干渉している可能性はないか検討してみる。i2sを動かさなければ問題ない。 WiFiで通信する時だけOV7670に供給する20MHzのクロックを止めてみると、OV7670から読み出される画像は変。当然だろう。

Errataも調べるが、該当しそうな項目はない。

この辺で万策尽きた感じがする。 原因は何だろう？　電源容量、ノイズ的な問題？ ESP32側の問題？　わからない。

つながる時は、大変スムーズにブラウザに画像が表示されるので 諦めるもの惜しい。 中華PCBメーカの休みが明けたら、基板設計して注文してみようかな。