目次: 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の一部しか見てないですけど……。
目次: 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のシステムは非常に使いやすいですね。
以前(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
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であることと、一部パッケージ名が違う場合があります。
目次: 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
以前(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間だけ若干狭い)ため、回転させると端子がはみ出してしまいます。私はハンダ付けが上手な訳でもなく、表面実装系の細かいやつは難しいのでハンダをちょっと増やしてごまかします。
できました。斜めに付いてる違和感がすごいのと芋ハンダだらけで長持ちしなさそうです。そもそも手修理ボードは長期運用するつもりがないから今だけ動いてくれればとりあえずヨシ!!
目次: Linux
AsciiDoc ExtensionはAsciiDocのプレビューはもちろんのこと、AsciiDoc文書に埋め込んだMermaidやPlantUMLのような図形作成用言語の画像もプレビュー可能です。
以前のバージョンではローカルにツールをインストールしてプレビュー画像を生成できました(2022年9月4日の日記参照)が、最近のバージョン(おそらく3.1.0以降?)はKroki(Krokiのサイト)による図形描画に変更されたようです。
AsciiDoc Extensionのデフォルト設定だとhttps://kroki.ioにMermaidやPlantUMLのソースコードを送って、画像を受け取る設定になっています。これで問題なければそのまま使用すれば良いですが、外部のサーバーにソースコードを送りたくない場合はローカルにKrokiサーバーを立ち上げることでローカルネットワーク環境で完結することもできます。素晴らしいですね。
Krokiのローカルサーバー立ち上げについてはDockerが便利なようです。Dockerが良い方はそちらを検索してみてください。
今回はKrokiを単体で立ち上げてみます。……と言ってもKroki自体に特に難しいことはなく、公式サイト(Manual Install :: Kroki Documentation)の説明の通りにやればよいです。PlantUMLを表示させたければGraphvizとPlantUMLをインストールした上で、
$ which dot /usr/bin/dot $ which plantuml /usr/bin/plantuml
GitHub ReleaseページからダウンロードしたKrokiのJARファイルを起動するだけでサーバーとして機能します。Krokiはサーバー機能を持っていて、動作テストにちょうど良いです。
$ java -jar kroki-standalone-server-v0.25.0.jar \ -DKROKI_LISTEN=0.0.0.0:5000
KROKI_LISTENはどのポートで待ち受けるか?の設定です。PlantUML系の設定は特に何も追加しなくてもPlantUMLを認識していました。これはテスト用の簡易サーバー機能なので、本格的に運用する際はアプリケーションサーバーに登録したほうが良いと思います、その設定はまた今度。
Krokiローカルサーバーを立ち上げたら、VSCodeを設定する必要があります。まずAsciiDoc Extensionの設定を開きます。
Asciidoc > Preview: Asciidoctor Attributesの項目にある[Edit in setting.json]のリンクを開きます。
設定の最後辺りに、
"asciidoc.preview.asciidoctorAttributes": {
"kroki-server-url": "http://192.168.1.1:5000"
}
を追加するとローカルサーバーに切り替わるはずです。192.168.1.1の部分はKrokiのローカルサーバーを動作させているIPアドレスを指定します。
ローカルサーバーにて画像生成すると見た目が少し変わります。おそらくですが、インターネット側のKrokiサーバーはデフォルトのデザインを変えていると思われます。下記のAsciidoc文書を入力として確かめます。
This is a sample of PlantUML diagram.
[plantuml]
----
@startuml
box "Box"
participant "App" as app
participant "Library" as lib
endbox
activate app
activate lib
app -> lib : Something()
@enduml
----
デフォルトつまりインターネット上のKrokiサーバーを使用する場合、このような結果になります。
ローカルサーバーを使用する場合、このような結果になります。グレーっぽいデザインから黄色のデザインに変わりました。
Krokiはkroki-standalone-server-v0.25.0.jarで、Krokiを動作させている環境はDebian Testingです。各モジュールのバージョンは、
です。
ささやかではありますが台湾東部沖地震に寄付しました。日本の赤十字社→台湾の赤十字(正式名称は中華民国紅十字会)の経路で支援されるようです。
今回調べて初めて知ったのですが、台湾の赤十字社は中国との関係で微妙な位置に立たされているようです。
とまあ中国と台湾間の政治問題によるものみたいです。まあ政治問題はさておいて、私は台湾赤十字の支援活動が誠実に行われていると信じて寄付するのみです。
目次: Zephyr
Zephyr SDKのhosttoolsを移動したらハマったので、メモしておきます。
Zephyr SDKは自前のhosttools(dtcやopenocd、qemuなど)のバイナリを持っていてシステム側のバイナリのバージョンによる不具合などを避けて必要なツールを使うことができます。直接呼び出すことはなくても、westを使っている人は間接的に使っているはずです。
そんな便利なhosttoolsなんですけど、インストールしたパスに強く依存していてディレクトリを移動させると動かなくなります。何が起きるか順に見ましょう。初めにhosttoolsのみをインストールし、dtcを実行します。
$ mkdir test $ cd ~/test $ wget https://github.com/zephyrproject-rtos/sdk-ng/releases/download/v0.16.5-1/zephyr-sdk-0.16.5-1_linux-x86_64_minimal.tar.xz $ tar xf zephyr-sdk-0.16.5-1_linux-x86_64_minimal.tar.xz $ cd ~/test/zephyr-sdk-0.16.5-1 $ ./zephyr-sdk-x86_64-hosttools-standalone-0.9.sh -y -d ~/test/zephyr-sdk-0.16.5-1 $ ./sysroots/x86_64-pokysdk-linux/usr/bin/dtc --version Version: DTC 1.6.0-dirty
正常動作しました。次にディレクトリを移動して、もう一度dtcを実行します。
$ cd ~/test $ mv zephyr-sdk-0.16.5-1 aaa $ cd ~/test/aaa $ ./sysroots/x86_64-pokysdk-linux/usr/bin/dtc --version bash: ./sysroots/x86_64-pokysdk-linux/usr/bin/dtc: 実行できません: 必要なファイルがありません
バイナリは一切変更していないのに動かなくなってしまいました……。バイナリは同一ですから設定もしくはダイナミックリンク周りが怪しそうです。まずはlddでライブラリ参照パスを見ます。
$ ldd ./sysroots/x86_64-pokysdk-linux/usr/bin/dtc linux-vdso.so.1 (0x00007ffd3e302000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fbd136b2000) /home/katsuhiro/test/zephyr-sdk-0.16.5-1/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007fbd138d9000)
ダイナミックリンカー(ld-linux.so)のパスにhosttoolsをインストールしたパスが含まれています。先ほどhosttoolsのディレクトリごと移動してしまったので、リンカーが見当たらないと怒っているようです。
続きはまた今度にします。
< | 2024 | > | ||||
<< | < | 03 | > | >> | ||
日 | 月 | 火 | 水 | 木 | 金 | 土 |
- | - | - | - | - | 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 |
31 | - | - | - | - | - | - |
合計:
本日: