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

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

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

その4。 CDS。 LEDマトリックス・モジュールに RSSを24時間表示させているが 夜中、かなり眩しい。 対策をせねばと思っていたが、 照度センサでLEDの光量を調整するという記事を ネットでみかけ、同じことをしようとセンサーとしてCDSを購入。

ということで秋月電子で購入した部品を紹介した。 記事を書いているうち、 滞っていた部品の一部が到着。 届いたは リニア・ベアリング。 内径 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コネクタ抜きならラクラク抜ける。

アマゾンから購入し、 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メーカの休みが明けたら、基板設計して注文してみようかな。