はじめに
こんにちは、Google Cloud Operations担当者です。Stackdriverという名前はもう忘れてください。先日foobarを作りましたが、そのときにはまだ発注していたテープLEDが届いていなかったのでアンダーグローの実装はしていませんでした。
やっとテープLEDが到着したのでアンダーグロー化しようと思います。
LEDのはんだ付け
配線が見られる写真やビルドログがあまり見つからなかったのでとりあえず本家の写真を参考に配線をしました。
QMK Firmwareでの書き方によっては左右同じはんだ付けでいいのかもしれませんが、今回は本家のビルドログと同様にマスター側（左手）ですべて制御するような形にしました。
点灯しないのでデバッグ
全部配線を終えてファームウェアを焼いてみたものの、光らない。まずもう一度テスターでいろいろと導通チェックをしてみました。
まず導通チェックですが、上の図で同じ色の丸同士のどこを確認してもブザーが鳴り、導通していることの確認が取れました。
TRRSケーブルをつないで左手側のDOUTから右手側のDINまでTRRSケーブルを通じて導通していることも確認。導通は問題なさそうなので、今度は電圧を確認します。
左手側を確認するとどうも電圧が取れていない。右手側を確認すると正しく電圧が出ている。さてこれはどうしたものかなあと考えていたのですが、LEDが壊れているのかどうかが確証が取れず、方法もわからなかったのでSMKIJの皆さんにまたもや相談。*1
原因
甘いはんだ付け
症状を共有するとa_p_u_r_oさんから早速次のようなアドバイスをいただきました。
左手側のLEDストリップのVCCがPro MicroのVCCと導通しているかもう一度確認したいです。
この部分は最初に導通を確認したはずなんだけれども、なにか変わっているのかもしれないので念の為導通確認。黒のプローブをProMicroのVCCのピンヘッダに、赤のプローブをテープLEDの始端のVCCのランドにつけると、ブザーが....鳴らない...。もう一度配線をよくよく見てみると、ビニル線のスルーホールへのはんだ付けが甘くなっていました。
はんだの様子を見てはんだ付け時にビニル線の被覆の部分が当たっていてうまくハンダが乗らなかったのだと推測しました。最初に導通チェックしたときはたまたまうまく接触していたので鳴っただけでした。
ファームウェアでの関数の間違い
はんだ付けが無事に修正されると、左手側のテープLEDが点灯したのですが、右手側が引き続き点灯しません。しかしPCに接続した状態で再度右手のテープLEDのGNDとVCCの電圧を測ると4.66Vになっているし、中のWS2812B自体のDINとDOUTの部分の導通を見ても問題ないので、これはファームウェア側の問題と推測。しかしおかしな部分がどこか、勘所がわからないので見様見真似でいじっていると@mteiさんからアドバイスを頂けました。
修正点1: RGBLIGHT_SPLITやRGBLED_SPLITを使わない
これまで作ってきたキーボードでバックライト、アンダーグロー含めLED付けたのはHelixだけなんですが、Helixの場合左右で同じようにはんだ付けしていて、ファームウェア側で左右の基板にいくつずつLEDがあるかなどを制御してましたが、今回の配線ではマスター側でLED制御するようにしています。
そのためHelixを真似て書いていた RGBLIGHT_SPLIT や RGBLED_SPLIT があることで逆に制御ができなくなってしまいます。公式ドキュメントを確認するとちゃんと書いてありました。
RGBLIGHT_SPLIT: This option enables synchronization of the RGB Light modes between the controllers of the split keyboard. This is for keyboards that have RGB LEDs that are directly wired to the controller (that is, they are not using the "extra data" option on the TRRS cable).
RGBLED_SPLIT: This sets how many LEDs are directly connected to each controller. The first number is the left side, and the second number is the right side.
これらのオプションはTRRSケーブル経由でデータを送っていない場合でProMicroに直接LEDが配線されている場合に使う、と書いてありますね。完全にRTFM*2案件です。
修正点2: keyboard_post_init_user()内でrgblight_* 系の関数を呼ぶ
QMKのfoobarのデフォルトのkeymap.cをコピーしたら初期化系の関数が matrix_init_user() しか書かれていなかったので、雰囲気でそのままそこにLEDの初期化とアニメーションの設定を書いていました。
void matrix_init_user(void) { rgblight_enable_noeeprom(); rgblight_mode_noeeprom(RGBLIGHT_MODE_RAINBOW_MOOD); }
しかし公式ドキュメントによれば、これではなく keyboard_post_init_user を使うべきだそう。
These are the three main initialization functions, listed in the order that they're called.
- keyboard_pre_init_* - Happens before most anything is started. Good for hardware setup that you want running very early.
- matrix_init_* - Happens midway through the firmware's startup process. Hardware is initialized, but features may not be yet.
- keyboard_post_init_* - Happens at the end of the firmware's startup process. This is where you'd want to put "customization" code, for the most part.
Note: For most people, the keyboard_post_init_user function is what you want to call. For instance, this is where you want to set up things for RGB Underglow.
他にもドキュメントを細かく見ると、直接は書いていないものの、ファームウェアの起動が終わった後にすべきようなことはすべて keyboard_post_init_user で行うべき、と書いてあります。LEDはまさにそうですね。したがって次のように書き換えました。
void keyboard_post_init_user(void) { rgblight_enable_noeeprom(); rgblight_mode_noeeprom(RGBLIGHT_MODE_RAINBOW_MOOD); } void matrix_init_user(void) { }
完成
以上の変更や修正を加えると無事にLEDが動作しました！
反省点
- ビニル線をハンダ付けをする際は、被覆のビニルをしっかり剥がして余裕を持ってはんだ付けできる程度に中の線を出す
- 導通確認は短い距離から増やして最大限まで長い距離まで複数回導通を見る。特にケーブルやジャンプしたハンダ付けに注意。
- RTFM
おわりに
トラブルはあったものの、今回の実装でLEDに関してまた理解が深まったので、積みキーボードのもう1セットのfoobarやMinidox、また過去に作ったGherkinとLet's Splitに関してもアンダーグロー化したいと思います。
*1:相談する側から解決策を提示できる側に早く回れるようにしたいものです
