この表示を始めたのは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コネクタ抜きならラクラク抜ける。

アマゾンから購入し、 USBIOを使ってPC上のPythonプログラムで試してみたり していたのだが、USB経由なので2mS単位でしか 信号を変化させられないためか、 動作がぎこちない気がする。 プログラムが間違っていたのかもしれない。

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

AliExpressでステッピングモータを物色すると、 リードスクリュー付きの小型のものが安価に売っている。 2個で $0.62 モータとリードスクリューだけのものだと安く、 スライダー付きのものだと結構高くなる。 3Dプリンタで移動ステージ作れたら面白そう、 1が月も待ちたくないのでアマゾンで購入。 2個で489円。 スライダーを作ってみたい。

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

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

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

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

写真

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

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

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

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

今まで使っていたのは、 Agilent 54641D, 帯域350MHzのアナログ２ch＋ ロジアナ16chのMSO。

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

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

奥行きが薄かったり、USBメモリで画面コピーを 取れたりするのが嬉しい。 AligientはCRTで奥行きが厚いし、 画面コピーは3.5インチフロッピー渡し！！ あと、今度は、4chあるので、 ロジアナの登場シーンは減りそうな気がする。

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

プローブその他の付属品をいれるための、 ポーチを買わなくては行けない。 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は スイッチサイエンスで発売中。

ファンはPWMで、ある程度 強弱を調整できる。 CPUの温度もプログラムで取得できるわけだから、 いずれ放熱効果の実験をしたい。

あと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でないと動かないモジュールもある、と書いてあるので そうなのかもしれない。

ひととおり半田を吸い取ってみると、 スティックがぐらつく。 半田が残っているピンは2箇所のようだ。 そのピンを温めつつスティックを引っ張り 取り外しに成功。修理用部品に取り替える。

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

修理したのが4月半ばで、 その後3週間ほど使用しているが、 問題なく使用できている。

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

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

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

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

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

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

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

いつもの MMD Bad Apple!! Now in 3D with more Color を再生したのが下の動画。

プログラムの改造は簡単だったが、 動作の確認のため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メーカの休みが明けたら、基板設計して注文してみようかな。