目次: Arduino
以前(2024年3月24日の日記参照)発注して、全く動ないうえにNMOSが焼ける(2024年4月3日の日記参照)PCBを直してみました。
まずはミスったNMOS 8個を全部外しました。当初はNMOSをきれいに外して再利用できないか?と考えたんですが、ナメた考えだったことがすぐにわかりました。全然外れません、無理だこれ。
次善策としてNMOSの足を切り破壊しながら外しました。代わりのNMOSはOnSemi BSS138を新たに購入します(秋月で売ってる)。本当はOnSemi BSS123ですけど、高周波とか高圧電流とか厳しい信号ではないしBSS123でもBSS138でも大差ありません。
NMOSを外したら修正します。ミスした箇所はNMOSのピン配置ですから、辻褄が合うようにNMOSを付け直せば良いはずです。
PCB側が想定しているピン配置(間違い) Drain 1 | | | NMOS | 3 Source Gate 2 | | NMOS側のピン配置(正しい) Gate 1 | | | NMOS | 3 Drain Source 2 | |
NMOSを裏向きにつけたらどうかとアドバイスも頂いたんですが、ちょうど左周りに60°回転させるとGate/Source/Drainがぴったり合いますので、回転させて付けることにしました。
SOT-23のピン配置は正三角形ではない(1-2間だけ若干狭い)ため、回転させると端子がはみ出してしまいます。私はハンダ付けが上手な訳でもなく、表面実装系の細かいやつは難しいのでハンダをちょっと増やしてごまかします。
できました。斜めに付いてる違和感がすごいのと芋ハンダだらけで長持ちしなさそうです。そもそも手修理ボードは長期運用するつもりがないから今だけ動いてくれればとりあえずヨシ!!
目次: Arduino
以前(2024年3月24日の日記参照)発注したPCBが届いたので、動かしてみたら全く動きませんでした。動かないどころか通電したら通常は0.07Aくらいのはずなのに1.5A近い大電流が流れ続け、しばらくしたらNMOSが焼けて煙が出ました。1万円(部品配置込みで$67)のゴミが爆誕……。
PCのUSBを電源にしてM5Stamp C3も繋いでいたので、PCやM5Stampが壊れる可能性もありました。M5Stampはめちゃくちゃ熱くなっていましたが、幸いなことにどちらも壊れずに済みました。M5Stampは強い子ですね。
ミスした箇所を調べると、どうやらKiCadのNMOSのピン配置と、部品で使ったNMOS(Onsemi BSS-123)のピン配置が違うのが原因のようです。
KiCadは1番ピンがドレイン、BSS-123は1番ピンがゲートなのでゲートとソース/ドレインを逆接続した回路になってしまったということです。Vcc 3.3VとGPIOが短絡していて、GPIOをGNDに繋いだり、GPIOをOutput Lowレベルにすると電源とGNDがショートする危険な状態になっていました。そりゃあNMOSも焼けますよね。これは気づかなかったなあ……。
目次: Arduino
Debian Testingなマシンをapt-get upgradeしたところKiCadが動かなくなりました。正確に言うとアプリ自体は動作しますがフットプリントライブラリをロードするとエラーになります。
検索のために先頭のエラーメッセージのみ転記しておきます。
フットプリントのロード中にエラーが発生しました: KiCad は現在使っているバージョンより新しいバージョンで作られたこのファイルを開くことができません。 このファイルを開くためには KiCad を 2024年01月08日 以降のバージョンにアップグレードする必要があります。 エラー文字列全文: 予期される 'locked, placed, tedit, tstamp, at, descr, tags, path, autoplace_cost90, autoplace_cost180, solder_mask_margin, solder_paste_margin, solder_paste_ratio, clearance, zone_connect, thermal_gap, attr, fp_text, fp_arc, fp_circle, fp_curve, fp_line, fp_poly, fp_rect, pad, zone, group, generator, version or model' ソース '/usr/share/kicad/footprints//Connector_HDMI.pretty/HDMI_A_Kycon_KDMIX-SL1-NS-WS-B15_VerticalRightAngle.kicad_mod', 行 4, オフセット 3.
パッケージを見るとKiCad(kicad)のバージョンが7.0.11なのに、フットプリントライブラリ(kicad-footprints)だけ8.0.1になっています。変ですねえ。
$ dpkg -l | egrep 'kicad |kicad-footprints ' ii kicad 7.0.11+dfsg-1 amd64 Electronic schematic and PCB design software ii kicad-footprints 8.0.1-1 all Footprint symbols for KiCad's Pcbnew
放っておいてもそのうち是正されると思いますが、良い機会なのでKiCadを自分でビルドしてみたいと思います。
Ubuntu 22.04でのビルド方法を示します。
$ apt-get install git cmake gcc g++ ninja-build $ apt-get install libglew-dev libcurl4-openssl-dev libcairo2-dev \ libboost-dev libboost-locale-dev libboost-test-dev libboost-filesystem-dev \ libharfbuzz-dev libprotobuf-dev protobuf-compiler swig \ libpython3-dev python3-wxgtk4.0 libgtk-3-dev \ libglm-dev libgit2-dev libngspice0-dev \ libocct-draw-dev libocct-ocaf-dev libocct-visualization-dev \ libocct-data-exchange-dev \ wx3.0-headers libwxgtk3.0-gtk3-dev unixodbc-dev libsecret-1-dev $ git clone https://gitlab.com/kicad/code/kicad $ git reset --hard 7.0.1 $ git clone https://gitlab.com/kicad/libraries/kicad-footprints $ git reset --hard 7.0.1 $ git clone https://gitlab.com/kicad/libraries/kicad-symbols $ git reset --hard 7.0.1 $ git clone https://gitlab.com/kicad/libraries/kicad-packages3D $ git reset --hard 7.0.1 $ cd kicad $ cmake -G Ninja ./ -B build -DCMAKE_INSTALL_PREFIX="/path/to/kicad/___" $ ninja -C build $ ninja -C build install #### footprintライブラリをインストール先のshare/kicad/footprintsにコピーする #### フットプリントエディターで正しく部品がロードできればOK $ cd ../ $ cp -a kicad-footprints /path/to/kicad/___/share/kicad/footprints #### symbolsライブラリをインストール先のshare/kicad/symbolsにコピーする #### シンボルエディターで正しく部品がロードできればOK $ cd ../ $ cp -a kicad-symbols /path/to/kicad/___/share/kicad/symbols #### symbolsライブラリをインストール先のshare/kicad/3dmodelsにコピーする #### 3Dビューアーで部品が表示されればOK $ cd ../ $ cp -a kicad-packages3D /path/to/kicad/___/share/kicad/3dmodels
Debian Testingの場合はKiCad 7.0.11を使うとよいです。wx3.0ではなくwx3.2であることと、一部パッケージ名が違う場合があります。
以前(2023年9月3日の日記参照)にMight and Magic Book One TAS US版の更新版(7m 19s)のTASをTASVideosに投稿して、Acceptされました。その時に「2023年に遊んでみる人はいても、TASに挑む人はまずいないと思うので、20年くらいは記録をキープできるんじゃないですか。はっはっは。」なんてことを書きましたが、1か月くらいでTaoTaoさんが大幅に更新(JP版5m 28s、US版5m 00s)してくれました。
時間が掛かるはずのJP版と、US版がほぼ同じクリアタイムになっているのが大きな特徴です。クリアタイムの大幅短縮にはMight and Magic Book Oneのクソデカバグ「イドの迷宮はクリア不要」が大きく貢献しています。
アストラル世界の最後にイドの迷宮をクリアしたかどうか判定する床(X:7, Y:8)があり、クリアしていれば通過でき、クリアしてなければソーピガルの町に戻される仕掛けです。ところが床のイベント設定がバグっていて南向き以外で突入すると発動しません。つまり北向きのまま後ろ向きに歩けば素通りしてしまいます。とんでもないバグですね。
詳細は発見者のTaoTaoさんのサイト(マイトアンドマジック(FC)攻略/解析 - マップ - アストラル世界)を見てほしいです。
他にもいろいろと工夫されていて非常に短時間でのクリアとなっています。わかる範囲で紹介したいと思います。
これらはいずれもTaoTaoさんの詳細に渡るプログラムや乱数解析の賜物です。いやーすごい。
目次: Arduino
シューティングの練習でいつもお世話になっているTARGET-1秋葉原店に、6つの的を撃つシューティングゲームが設置されています(TSS?だったかな、名前は忘れました)。10年くらい頑張って稼働してくれたそうですが、製造元が既になくて壊れたら修理ができないんですと困っていました。
シューティングゲームのボードとターゲットの回路を見た感じ、素人の電子工作でもなんとかなりそうな作りだったので、代わりとなるおもちゃを作ることにしました。最初は簡単かなと思っていましたが、意外と時間を食ってしまって結局2か月くらい電子工作をしてました。
今日は電子工作の集大成となるPCBの発注です。発注先はJLCPCBです。ボードだけなら5枚でたったの$3、恐ろしい安さです。今回は部品も実装してもらうので合計$67(円安のせいで1万円近い)ですが、それでも安いです。便利な時代になったなあ。
KiCadのプラグインFabrication Toolkitをインストールします。
PCBエディターのツールバーの右端にアイコンが増えるはずです。
JLCPCB Fabrication Toolkitのボタン
ツールバーのボタンを押すとダイアログウインドウが出るのでGenerateボタンを押します。
JLCPCB Fabrication Toolkitのダイアログ
KiCadのプロジェクトがあるディレクトリの下にproductionディレクトリが生成されるはずです。productionディレクトリの下にある*.zipをJLCPCBのWebサイトの見積もりウインドウにドラッグ&ドロップします。
JLCPCBのウェブサイトのZipファイルをドロップする場所
見積もりページが表示されます(ボードの外観も表示されます)ので、ボードを製造する際のパラメータを選びます。右側には見積もりが表示されます。JLCPCBのシステムは非常に使いやすいですね。
目次: Arduino
古くは電話線で、今だとEthernetで良く見かけるモジュラージャックというコネクタとレセプタクルがあります。モジュラージャックの種別はRJなんとか(RJ11など)という名前で呼ばれます。数字が違うと何か違うのは知っていましたが、今まで気にしていませんでした。
最近、趣味で早打ちターゲットを作っていて電子回路&基板を書いているんですが、部品の1つにRJ14(6極4芯)を使っていて、そのときRJ11〜18までRJなんとかシリーズがたくさんあることを知りました。電子回路作成ツールのKiCadの部品リストによれば、下記の種類があるそうです。
どの規格で定められているのか?RJなんとかとは何か?RJ13とRJ14は何が違う?と気になったので規格に当たってみました。
最初のどの規格で定められているのか?ですが、RJなんとかは41 FR 28699, July 12, 1976(PDFへのリンク)にて定義されています。古そうだなとは思いましたが、まさか50年前の規格だったとは……。
FR(Federal Register)は連邦官報のことです。FRはPDF形式で配布されていますが、PDF形式と言いつつ中身はスキャン画像の羅列でした。古い文書だと仕方ないですね。ところがOCRを掛けてくれているらしく文字列検索ができます。大変ありがたい。アメリカ政府ありがとう。
次にRJなんとかとは何か?ですが、この記号はUniversal Service Order Code(USOC)です。§68.502の説明を見ると、
These USOCs are generic telephone company service ordering codes. If a telephone subscriber wishes to have the telephone company install a standard jack other than the one depicted in § 68.502(a)(1) below, he shall specify the appropriate USOC when requesting the installations. (適当訳) これらUSOCは一般的な電話会社のサービス注文コードです。電話加入者が電話会社に対し、下記の§68.502(a)(1)に 記載されているジャック以外の標準ジャックの設置を希望する場合は、設置を要求するときに適切なUSOCを指定するものとします。
とあります。§68.502(a)(1)というのはRJ11のことを指しています。RJなんとかは電話会社に設置を頼むときの注文番号だったんですね。へー……。
次はRJ13とRJ14の違いを調べます。FRからRJ14Cの規格を見つけました、こんな定義です。手書きの図が良い味出してますね。
しかしRJ13は載っていませんでした。後で追加された規格なのか?残念ながらRJ13とRJ14の違いはわからないままです……。
黄ばんだ画像のFR 28699, July 12, 1976より、CFR(Code of Federal Regulations)のTitle 47 Vol.3 1996年(PDFへのリンク)の方が見やすいかもしれません。
日本語だとFR(Federal Register)は連邦官報、CFR(Code of Federal Regulations)は連邦規則集という名前だそうで、CFRはアメリカ政府が発行している規則集です。法律に準ずるものらしいですが、法律の専門家ではないので詳しいことはわかりません。
Title 47はTelecommunicationの話題で、Vol.1からVol.5まであります。Vol.3の一部しか見てないですけど……。
目次: Linux
ROCK 3 model CのDebian bullseyeイメージは10分ほど?放置していると画面が消えてロック画面に戻る設定になっています。これはこれでありがたい動作ですが実験用に使っていてキーボードを繋いでいないことがあるので、ロック画面への移行と、画面が消える動作を無効化する方法をメモしておきます。
ロック画面を無効化するには、Xfce4の[アプリケーション] - [設定] - [スクリーンセーバー](xfce4-screensaver-preferences)の、
タブ[ロック画面] - [ロック画面を有効にする]をOFFにすれば良いみたいです。再起動後も設定を覚えてくれています。
画面が消える機能はDPMS(Display Power Management Signaling)といって、Xfce4の設定パネルからだと[アプリケーション] - [設定] - [電源管理](xfce4-power-manager-settings)の、
タブ[ディスプレイ] - [ブランク画面にするまでの時間]などから設定できます。しかしロック画面と違って設定を覚えてくれない?みたいで、再起動すると元に戻ってしまいます。理由が良くわからない……困った。
Xfce4は良くわからないので降参して、X Windowに頑張ってもらうことにします。DPMSの状態の設定と取得にはxsetを使います。リモートから実行するなら他のX Window Systemのアプリと同様にDISPLAY=:0などのように、どのディスプレイか指定する必要があります。
DPMSのStandby, Suspend, Offを一気に無効にするにはdpms 0 0 0と指定すれば良いです。DPMSの設定は最後の方に表示されます。
$ xset dpms 0 0 0 $ xset -q Keyboard Control: auto repeat: on key click percent: 0 LED mask: 00000000 XKB indicators: 00: Caps Lock: off 01: Num Lock: off 02: Scroll Lock: off 03: Compose: off 04: Kana: off 05: Sleep: off 06: Suspend: off 07: Mute: off 08: Misc: off 09: Mail: off 10: Charging: off 11: Shift Lock: off 12: Group 2: off 13: Mouse Keys: off auto repeat delay: 500 repeat rate: 20 auto repeating keys: 00ffffffdffffbbf fadfffefffedffff 9fffffffffffffff fff7ffffffffffff bell percent: 50 bell pitch: 400 bell duration: 100 Pointer Control: acceleration: 2/1 threshold: 4 Screen Saver: prefer blanking: no allow exposures: no timeout: 0 cycle: 300 Colors: default colormap: 0x20 BlackPixel: 0x0 WhitePixel: 0xffffff Font Path: /usr/share/fonts/X11/misc,/usr/share/fonts/X11/100dpi/:unscaled,/usr/share/fonts/X11/75dpi/:unscaled,/usr/share/fonts/X11/Type1,/usr/share/fonts/X11/100dpi,/usr/share/fonts/X11/75dpi,built-ins DPMS (Energy Star): Standby: 0 Suspend: 0 Off: 0 DPMS is Disabled
これだけだと再起動すると元に戻ってしまいますから、XDG autostartで毎回起動時に勝手に設定する仕掛けにします。システム全体ならば/etc/xdg/autostart/に、ユーザーごとに設定したいなら.config/autostart/に設定ファイルを作成します。ファイル名は何でも良いですが、今回はxset.desktopという名前にしました。
[Desktop Entry] Name=xset Comment=Disable DPM Type=Application Exec=/usr/bin/xset dpms 0 0 0 X-GNOME-Autostart-Phase=Initialization
ファイルを作成したら再起動して、DPMSが望み通りの設定に変わるか確かめます。
Xfce4の設定パネルからだと[アプリケーション] - [設定] - [セッションと起動](xfce4-session-settings)からも作成&設定できるはずです。たぶん。
目次: Arduino
M5Stamp C3をBluetooth LEデバイスにして、Linux PCもしくはRaspberry PiなどのLinux SBCとお話する取り組みの続編です。
今回はbluez-dbusを使ってBluetoothデバイスと通信します。
前回の話と少し重複しますが、Bluetoothデバイス特にBLEデバイスとはGATTプロファイルを使って通信します。BLEデバイスはサーバーになります。サーバーはService(=提供する機能)を1つもしくは複数持っていて、Service、Characteristic、ValueとDescriptorが入れ子の構造になっています。
GATTのデータ送受信はCharacteristicのValueを読み書きすることで実現します。まずは簡単な送信側(Write)からご紹介します。
private BluetoothGattCharacteristic GattTx;
byte[] dat = new byte[len];
//送信するデータを用意する
//...
GattTx.writeValue(bpart, null);
バイト配列を用意してwriteValue()を呼びます。書き換え属性を持っているCharacteristicでないと書き込みが失敗します。
次は受信側(Read)です。writeValue()と同様にreadValue()も用意されていて、最後にReadした値を読み出せます。しかし一度読んだ値なのか新しい値なのか区別が付きません、つまり値の更新の有無がわかりません。
BluetoothGattCharacteristic GattRx;
byte[] dat = GattRx.readValue(null);
ではこの方法はダメなのか?というとそんなことはありません。一定時間ごとに現在値を見たい場合、例えば「温度計の値を1分ごとに読み出す」といった用途で役立ちます。
一方でストリームデータを扱う場合、新しい値がきたときだけ読み出したいので更新を検出する必要があります。検出には少しややこしい処理が必要です。bluez-dbusは何かの状態変化が起きるとPropertiesChangedというイベントで知らせてくることを利用します。使い方は、
コードで書くと下記のようになります。
public class PropertiesChangedHandler extends AbstractPropertiesChangedHandler {
@Override
public void handle(Properties.PropertiesChanged props) {
}
}
BluetoothGattCharacteristic GattRx;
DeviceManager deviceManager = DeviceManager.getInstance();
PropertiesChangedHandler handler = new PropertiesChangedHandler(...);
deviceManager.registerPropertyHandler(handler);
GattRx.startNotify();
PropertiesChangedハンドラはCharacteristicsの値の更新も、別の関係ないイベントも何でも受け取るので、何のイベントが発生したか判定する必要があります。bluez-dbusのBluetoothGattCharacteristicクラスと、PropertiesChangedクラスはいずれもD-Busのパス(/org/bluez/hci0/dev_xx_xx_xx_xx_xx_xx/service0028/char0029のような文字列)を返すメソッドを持っていますので、D-Busのパスが一致するかどうかで確かめます。
変化した値と名前のMapをgetPropertiesChanged()で取得できるので、全要素を調べて名前がValueであり、バイト配列を保持していればCharacteristicの値の変化を通知するイベントのはずです。
BluetoothGattCharacteristic GattRx;
Map<String, Variant<?>> mapProp = props.getPropertiesChanged();
if (GattRx.getDbusPath().equalsIgnoreCase(props.getPath())) {
for (Map.Entry<String, Variant<?>> e : mapProp.entrySet()) {
if (e.getValue().getValue() instanceof byte[]) {
dat = (byte[])e.getValue().getValue();
}
}
}
自分でBLEデバイス側の実装をしているなら、意図しないイベントが混ざることはありません。上記のコードのように簡素なチェック(例えば単にバイト配列かどうかだけチェック)でも動作するはずです。
< | 2024 | > | ||||
<< | < | 04 | > | >> | ||
日 | 月 | 火 | 水 | 木 | 金 | 土 |
- | 1 | 2 | 3 | 4 | 5 | 6 |
7 | 8 | 9 | 10 | 11 | 12 | 13 |
14 | 15 | 16 | 17 | 18 | 19 | 20 |
21 | 22 | 23 | 24 | 25 | 26 | 27 |
28 | 29 | 30 | - | - | - | - |
合計:
本日: