コグノスケ

未来から過去へ表示

過去から未来へ表示(*)

もっと前

2024年3月18日 >>> 2024年4月17日

もっと後

画面のブランクを無効にする

目次: Linux

ROCK 3 model CのDebian bullseyeイメージは10分ほど？放置していると画面が消えてロック画面に戻る設定になっています。これはこれでありがたい動作ですが実験用に使っていてキーボードを繋いでいないことがあるので、ロック画面への移行と、画面が消える動作を無効化する方法をメモしておきます。

ロック画面の設定

ロック画面を無効化するには、Xfce4の[アプリケーション] - [設定] - [スクリーンセーバー]（xfce4-screensaver-preferences）の、

xfce4-screensaver-preferences

タブ[ロック画面] - [ロック画面を有効にする]をOFFにすれば良いみたいです。再起動後も設定を覚えてくれています。

画面が消える（DPMS）設定

画面が消える機能はDPMS（Display Power Management Signaling）といって、Xfce4の設定パネルからだと[アプリケーション] - [設定] - [電源管理]（xfce4-power-manager-settings）の、

xfce4-power-manager-settings

タブ[ディスプレイ] - [ブランク画面にするまでの時間]などから設定できます。しかしロック画面と違って設定を覚えてくれない？みたいで、再起動すると元に戻ってしまいます。理由が良くわからない……困った。

xsetとXDGで起動時にDPMSを設定

Xfce4は良くわからないので降参して、X Windowに頑張ってもらうことにします。DPMSの状態の設定と取得にはxsetを使います。リモートから実行するなら他のX Window Systemのアプリと同様にDISPLAY=:0などのように、どのディスプレイか指定する必要があります。

DPMSのStandby, Suspend, Offを一気に無効にするにはdpms 0 0 0と指定すれば良いです。DPMSの設定は最後の方に表示されます。

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という名前にしました。

DPMSを起動時に設定する、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）からも作成＆設定できるはずです。たぶん。

編集者:すずき(2024/03/19 11:47)

コメント一覧

コメントはありません。

この記事にコメントする

モジュラージャックの規格

目次: Arduino

古くは電話線で、今だとEthernetで良く見かけるモジュラージャックというコネクタとレセプタクルがあります。モジュラージャックの種別はRJなんとか（RJ11など）という名前で呼ばれます。数字が違うと何か違うのは知っていましたが、今まで気にしていませんでした。

最近、趣味で早打ちターゲットを作っていて電子回路＆基板を書いているんですが、部品の1つにRJ14（6極4芯）を使っていて、そのときRJ11〜18までRJなんとかシリーズがたくさんあることを知りました。電子回路作成ツールのKiCadの部品リストによれば、下記の種類があるそうです。

RJ11: 6P2C（6極2線）
RJ12: 6P6C（6極6線）
RJ13, RJ14: 6P4C（6極4線）

どの規格で定められているのか？RJなんとかとは何か？RJ13とRJ14は何が違う？と気になったので規格に当たってみました。

1976年の規格、RJなんとか＝USOCのこと

最初のどの規格で定められているのか？ですが、RJなんとかは41 FR 28699, July 12, 1976（PDFへのリンク）にて定義されています。古そうだなとは思いましたが、まさか50年前の規格だったとは……。

FR（Federal Register）は連邦官報のことです。FRはPDF形式で配布されていますが、PDF形式と言いつつ中身はスキャン画像の羅列でした。古い文書だと仕方ないですね。ところがOCRを掛けてくれているらしく文字列検索ができます。大変ありがたい。アメリカ政府ありがとう。

次にRJなんとかとは何か？ですが、この記号はUniversal Service Order Code（USOC）です。§68.502の説明を見ると、

§68.502のUSOCの説明

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なんとかは電話会社に設置を頼むときの注文番号だったんですね。へー……。

RJ14は書いてあるがRJ13は見当たらない

次はRJ13とRJ14の違いを調べます。FRからRJ14Cの規格を見つけました、こんな定義です。手書きの図が良い味出してますね。

RJ14の定義

しかしRJ13は載っていませんでした。後で追加された規格なのか？残念ながらRJ13とRJ14の違いはわからないままです……。

Code of Federal Regulationsのほうが見やすいかも

黄ばんだ画像の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の一部しか見てないですけど……。

編集者:すずき(2024/04/16 00:07)

コメント一覧

コメントはありません。

この記事にコメントする

PCBを設計して注文

目次: Arduino

シューティングの練習でいつもお世話になっているTARGET-1秋葉原店に、6つの的を撃つシューティングゲームが設置されています（TSS？だったかな、名前は忘れました）。10年くらい頑張って稼働してくれたそうですが、製造元が既になくて壊れたら修理ができないんですと困っていました。

シューティングゲームのボードとターゲットの回路を見た感じ、素人の電子工作でもなんとかなりそうな作りだったので、代わりとなるおもちゃを作ることにしました。最初は簡単かなと思っていましたが、意外と時間を食ってしまって結局2か月くらい電子工作をしてました。

今日は電子工作の集大成となるPCBの発注です。発注先はJLCPCBです。ボードだけなら5枚でたったの$3、恐ろしい安さです。今回は部品も実装してもらうので合計$67（円安のせいで1万円近い）ですが、それでも安いです。便利な時代になったなあ。

KiCadからJLCPCBに設計図を出す方法

KiCadのプラグインFabrication Toolkitをインストールします。

JLCPCB Fabrication Toolkit

PCBエディターのツールバーの右端にアイコンが増えるはずです。

JLCPCB Fabrication Toolkitのボタン

ツールバーのボタンを押すとダイアログウインドウが出るのでGenerateボタンを押します。

JLCPCB Fabrication Toolkitのダイアログ

KiCadのプロジェクトがあるディレクトリの下にproductionディレクトリが生成されるはずです。productionディレクトリの下にある*.zipをJLCPCBのWebサイトの見積もりウインドウにドラッグ＆ドロップします。

JLCPCBのウェブサイトのZipファイルをドロップする場所

見積もりページが表示されます（ボードの外観も表示されます）ので、ボードを製造する際のパラメータを選びます。右側には見積もりが表示されます。JLCPCBのシステムは非常に使いやすいですね。

編集者:すずき(2024/04/12 11:00)

コメント一覧

コメントはありません。

この記事にコメントする

Might and Magic Book One TASのその後

目次: Might and Magicファミコン版

以前（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）攻略/解析 - マップ - アストラル世界）を見てほしいです。

その他のテクニック

他にもいろいろと工夫されていて非常に短時間でのクリアとなっています。わかる範囲で紹介したいと思います。

扉の突破（JP版、盗賊への転職を不要にする）: JP版は盗賊がソーピガルの宿屋に居ない＆Lv.1の場合は盗賊以外は扉の鍵の開錠に成功しないため、誰か1人を盗賊に転職させなければなりませんでした。しかしわざと扉の罠に掛かってダメージ0の判定を引き扉の鍵を突破すると非常に早く突破できます。言うだけなら簡単なんですけど、試行錯誤だけでやろうとすると全然引けません。
そらとぶじゅうたん（JP版、魔法使いなしで「ひこう」を使う）: JP版はキーカードを手に入れる（オーラのクエストをクリアする必要がある）ため、いくつかマップをめぐる必要があり「ひこう」の魔法が欲しいところです。これを魔法使い＋魔法の泉ではなく、ポートスミスの「ひふきあり」から「そらとぶじゅうたん（使うと「ひこう」の効果）」をドロップさせタイム短縮しています。Lv.1で「ひふきあり」をワンパンKOできるんですね。知りませんでした。
エンカウンター予約: モンスターとのエンカウンターがイベント発生後にも発生するという仕様を利用して移動回数を減らす工夫です。例えば、移動→イベント→エンカウンター、という順序で発生します。動画だと火山の神と話すときがわかりやすいですね。
降参ワープ: モンスターとの戦闘を回避する方法には「逃げる」と「降参」があります。逃げる、もしくは、降参時に一定条件を満たすとマップ依存の固定座標にワープします。なぜかいくつかのマップでは逃げた後の座標と、降参した後のワープ座標が異なり、近い方にワープすればタイム短縮できます。これはバグじゃなくて仕様だと思いますけど、降参だけ特別扱いする意味はさっぱりわかりません。

これらはいずれもTaoTaoさんの詳細に渡るプログラムや乱数解析の賜物です。いやーすごい。

編集者:すずき(2024/03/26 03:20)

コメント一覧

コメントはありません。

この記事にコメントする

2024年4月2日

permalink

編集する

KiCadが動かなくなったのでビルド

目次: 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になっています。変ですねえ。

kicadとkicad-footprintsのバージョン

$ 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を自分でビルドしてみたいと思います。

KiCadのビルド方法

Ubuntu 22.04でのビルド方法を示します。

KiCadのビルド方法

$ 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であることと、一部パッケージ名が違う場合があります。

編集者:すずき(2024/04/12 11:00)

コメント一覧

コメントはありません。

この記事にコメントする

2024年4月3日

permalink

編集する

初めて作ったボード動作せず（燃えた）

目次: 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のNMOS(形状SOT-23)のピン配置

Onsemi BSS-123のピン配置

KiCadは1番ピンがドレイン、BSS-123は1番ピンがゲートなのでゲートとソース/ドレインを逆接続した回路になってしまったということです。Vcc 3.3VとGPIOが短絡していて、GPIOをGNDに繋いだり、GPIOをOutput Lowレベルにすると電源とGNDがショートする危険な状態になっていました。そりゃあNMOSも焼けますよね。これは気づかなかったなあ……。

編集者:すずき(2024/04/12 11:00)

コメント一覧

コメントはありません。

この記事にコメントする

2024年4月9日

permalink

編集する

初めて作ったボード動作せず（手で直した）

目次: Arduino

以前（2024年3月24日の日記参照）発注して、全く動ないうえにNMOSが焼ける（2024年4月3日の日記参照）PCBを直してみました。

まずはミスったNMOS 8個を全部外しました。当初はNMOSをきれいに外して再利用できないか？と考えたんですが、ナメた考えだったことがすぐにわかりました。全然外れません、無理だこれ。

次善策としてNMOSの足を切り破壊しながら外しました。代わりのNMOSはOnSemi BSS138を新たに購入します（秋月で売ってる）。本当はOnSemi BSS123ですけど、高周波とか高圧電流とか厳しい信号ではないしBSS123でもBSS138でも大差ありません。

NMOSを外したら修正します。ミスした箇所はNMOSのピン配置ですから、辻褄が合うようにNMOSを付け直せば良いはずです。

PCB側と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間だけ若干狭い）ため、回転させると端子がはみ出してしまいます。私はハンダ付けが上手な訳でもなく、表面実装系の細かいやつは難しいのでハンダをちょっと増やしてごまかします。

ハンダ付け後のPCB

できました。斜めに付いてる違和感がすごいのと芋ハンダだらけで長持ちしなさそうです。そもそも手修理ボードは長期運用するつもりがないから今だけ動いてくれればとりあえずヨシ！！

編集者:すずき(2024/04/12 12:44)

コメント一覧

コメントはありません。

この記事にコメントする

2024年4月11日

permalink

編集する

VScodeとAsciiDocとKrokiローカルサーバー

目次: Linux

AsciiDoc ExtensionはAsciiDocのプレビューはもちろんのこと、AsciiDoc文書に埋め込んだMermaidやPlantUMLのような図形作成用言語の画像もプレビュー可能です。

以前のバージョンではローカルにツールをインストールしてプレビュー画像を生成できました（2022年9月4日の日記参照）が、最近のバージョン（おそらく3.1.0以降？）はKroki（Krokiのサイト）による図形描画に変更されたようです。

AsciiDoc Extensionのデフォルト設定だとhttps://kroki.ioにMermaidやPlantUMLのソースコードを送って、画像を受け取る設定になっています。これで問題なければそのまま使用すれば良いですが、外部のサーバーにソースコードを送りたくない場合はローカルにKrokiサーバーを立ち上げることでローカルネットワーク環境で完結することもできます。素晴らしいですね。

Krokiローカルサーバーの設定

Krokiのローカルサーバー立ち上げについてはDockerが便利なようです。Dockerが良い方はそちらを検索してみてください。

今回はKrokiを単体で立ち上げてみます。……と言ってもKroki自体に特に難しいことはなく、公式サイト（Manual Install :: Kroki Documentation）の説明の通りにやればよいです。PlantUMLを表示させたければGraphvizとPlantUMLをインストールした上で、

GraphvizとPlantUMLがインストールされていることの確認

$ which dot
/usr/bin/dot

$ which plantuml
/usr/bin/plantuml

GitHub ReleaseページからダウンロードしたKrokiのJARファイルを起動するだけでサーバーとして機能します。Krokiはサーバー機能を持っていて、動作テストにちょうど良いです。

Krokiの簡易サーバー機能を使う

$ java -jar kroki-standalone-server-v0.25.0.jar \
  -DKROKI_LISTEN=0.0.0.0:5000

KROKI_LISTENはどのポートで待ち受けるか？の設定です。PlantUML系の設定は特に何も追加しなくてもPlantUMLを認識していました。これはテスト用の簡易サーバー機能なので、本格的に運用する際はアプリケーションサーバーに登録したほうが良いと思います、その設定はまた今度。

VSCodeの設定

Krokiローカルサーバーを立ち上げたら、VSCodeを設定する必要があります。まずAsciiDoc Extensionの設定を開きます。

AsciiDoc Extensionの設定

Asciidoc > Preview: Asciidoctor Attributesの項目にある[Edit in setting.json]のリンクを開きます。

Asciidoctor Attributesの設定

設定の最後辺りに、

setting.jsonに追加する設定


    "asciidoc.preview.asciidoctorAttributes": {
            "kroki-server-url": "http://192.168.1.1:5000"
    }

を追加するとローカルサーバーに切り替わるはずです。192.168.1.1の部分はKrokiのローカルサーバーを動作させているIPアドレスを指定します。

見た目が少し違う

ローカルサーバーにて画像生成すると見た目が少し変わります。おそらくですが、インターネット側のKrokiサーバーはデフォルトのデザインを変えていると思われます。下記のAsciidoc文書を入力として確かめます。

動作テストに使った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.ioの出力結果

ローカルサーバーを使用する場合、このような結果になります。グレーっぽいデザインから黄色のデザインに変わりました。

ローカルサーバーの出力結果

Krokiはkroki-standalone-server-v0.25.0.jarで、Krokiを動作させている環境はDebian Testingです。各モジュールのバージョンは、

plantuml: 1.2020.2
Graphviz: 2.42.2-8

です。

編集者:すずき(2024/04/17 00:37)

コメント一覧

コメントはありません。

この記事にコメントする

2024年4月12日

permalink

編集する

台湾東部沖地震に寄付

ささやかではありますが台湾東部沖地震に寄付しました。日本の赤十字社→台湾の赤十字（正式名称は中華民国紅十字会）という経路で支援されるようです。

台湾東部沖地震に寄付

今回調べて初めて知ったのですが、台湾の赤十字社は中国との関係で微妙な位置に立たされているようです。

各国の赤十字社、赤新月社は国際赤十字赤新月社連盟（IFRC、平時の支援活動）に加盟し、赤十字国際委員会（ICRC、戦時の支援活動）の統括で活動している
ICRCの7原則（赤十字の7原則）により、赤十字社は一国に一社と決まっている
ICRCが台湾の赤十字を承認すると、ICRCが台湾＝国と暗に認めることになる
台湾は中国の一部と主張する中国にとって大問題

とまあ中国と台湾間の政治問題によるものみたいです。まあ政治問題はさておいて、私は台湾赤十字の支援活動が誠実に行われていると信じて寄付するのみです。

編集者:すずき(2024/04/16 00:12)

コメント一覧

コメントはありません。

この記事にコメントする

2024年4月15日

permalink

編集する

Zephyr SDKのhosttoolsは移動してはいけない、その1 - 移動させると動かなくなる

目次: Zephyr

Zephyr SDKのhosttoolsを移動したらハマったので、メモしておきます。

Zephyr SDKは自前のhosttools（dtcやopenocd、qemuなど）のバイナリを持っていてシステム側のバイナリのバージョンによる不具合などを避けて必要なツールを使うことができます。直接呼び出すことはなくても、westを使っている人は間接的に使っているはずです。

そんな便利なhosttoolsなんですけど、インストールしたパスに強く依存していてディレクトリを移動させると動かなくなります。何が起きるか順に見ましょう。初めにhosttoolsのみをインストールし、dtcを実行します。

hosttoolsをインストール＆実行

$ 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/04/17 01:47)

コメント一覧

コメントはありません。

この記事にコメントする

2024年4月16日

permalink

編集する

Zephyr SDKのhosttoolsは移動してはいけない、その2 - インストール時のバイナリ書き換え

目次: Zephyr

Zephyr SDKのhosttoolsを移動したらハマったので、メモしておきます。

Zephyr SDKは自前のhosttools（dtcやopenocd、qemuなど）のバイナリを持っていてシステム側のバイナリのバージョンによる不具合などを避けて必要なツールを使うことができます。が、インストールしたパスに強く依存していてディレクトリを移動させると動かなくなります。

今回は動かないバイナリを観察してなぜ動かないのか調べます。

バイナリを観察する

ダイナミックリンカーのパスは実行バイナリに含まれています。

実行バイナリ内のダイナミックリンカーパス

$ readelf -S ./sysroots/x86_64-pokysdk-linux/usr/bin/dtc

There are 29 section headers, starting at offset 0x1e7b8:

Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
  [ 0]                   NULL             0000000000000000  00000000
       0000000000000000  0000000000000000           0     0     0
  [ 1] .interp           PROGBITS         00000000000002a8  000002a8  ★これ★
       0000000000001000  0000000000000000   A       0     0     1
  [ 2] .note.gnu.bu[...] NOTE             00000000000012a8  000012a8
       0000000000000024  0000000000000000   A       0     0     4


$ hexdump -C ./sysroots/x86_64-pokysdk-linux/usr/bin/dtc

...略...

00000290  10 09 00 00 00 00 00 00  10 09 00 00 00 00 00 00  |................|
000002a0  01 00 00 00 00 00 00 00  2f 68 6f 6d 65 2f 6b 61  |......../home/ka| ★.interpセクションヘッダ★
000002b0  74 73 75 68 69 72 6f 2f  74 65 73 74 2f 7a 65 70  |tsuhiro/test/zep| ★環境依存のパスがある★
000002c0  68 79 72 2d 73 64 6b 2d  30 2e 31 36 2e 35 2d 31  |hyr-sdk-0.16.5-1|
000002d0  2f 73 79 73 72 6f 6f 74  73 2f 78 38 36 5f 36 34  |/sysroots/x86_64|
000002e0  2d 70 6f 6b 79 73 64 6b  2d 6c 69 6e 75 78 2f 6c  |-pokysdk-linux/l|
000002f0  69 62 2f 6c 64 2d 6c 69  6e 75 78 2d 78 38 36 2d  |ib/ld-linux-x86-|
00000300  36 34 2e 73 6f 2e 32 00  00 00 00 00 00 00 00 00  |64.so.2.........|
00000310  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

Zephyrの公式サイトで配布しているバイナリに、私のホームディレクトリを含むパスが入っている訳がありません。おそらくインストール時に書き換えているのでしょう。

インストーラがバイナリを書き換える仕組み

解析のためhosttoolsのインストーラを改造し、バイナリを書き換える前（292行目辺り）に入力待ちで止まるコマンド（catとか）を入れて実行を止めます。インストーラ改造の際の注意点として、インストーラ末尾にあるバイナリを壊さないように編集してください（例えばVimのバイナリモードvim -bなどを使う）。

インストーラの改造


## zephyr-sdk-x86_64-hosttools-standalone-0.9.sh: 290行目付近

...

executable_files=$($SUDO_EXEC find $native_sysroot -type f \
	\( -perm -0100 -o -perm -0010 -o -perm -0001 \) -printf "'%h/%f' ")
if [ "x$executable_files" = "x" ]; then
   echo "SDK relocate failed, could not get executalbe files"
   exit 1
fi

cat    ★この後で書き換えているようなので、ここで止める★
tdir=`mktemp -d`
if [ x$tdir = x ] ; then
   echo "SDK relocate failed, could not create a temporary directory"
   exit 1
fi

...

改造したインストーラを実行

$ ./zephyr-sdk-x86_64-hosttools-standalone-0.9.sh -y -d ~/test/aaa

Zephyr Yocto Toolchain SDK installer version 0.9
================================================
You are about to install the SDK to "/home/katsuhiro/test/aaa". Proceed [Y/n]? Y
Extracting SDK..................done
Setting it up...^Z
[1]+  停止                  ./zephyr-sdk-x86_64-hosttools-standalone-0.9.sh -y -d ~/test/aaa

バイナリの書き換えが起こる前に止めました。この状態でダイナミックリンカーのパスを見ます。

書き換える前のダイナミックリンカーのパス

$ ldd ./sysroots/x86_64-pokysdk-linux/usr/bin/dtc
        linux-vdso.so.1 (0x00007ffd5d74f000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa4d5e8e000)
        /opt/zephyr-sdk/0.9/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007fa4d60b5000)

書き換える前は/opt/zephyr-sdk/0.9というパスで、インストーラのデフォルトインストール先と同じパスです。

ダイナミックリンカーのパスを書き換えるのは誰か？というと、ディレクトリにあるrelocate_sdk.pyというスクリプトです。このスクリプトはhosttoolsインストール終了後に消されるので、インストーラを改造して途中で止めないと中身を拝むことができません。

バイナリ書き換えスクリプト

$ ls

environment-setup-x86_64-pokysdk-linux
relocate_sdk.py    ★このスクリプト★
sysroots
version-x86_64-pokysdk-linux
zephyr-sdk-x86_64-hosttools-standalone-0.9.sh

詳しく追っていませんが、change_interpreter()関数が書き換える本体のようです。

relocate_sdk.pyのchange_interpreter()関数


def change_interpreter(elf_file_name):
    if arch == 32:
        ph_fmt = "<IIIIIIII"
    else:
        ph_fmt = "<IIQQQQQQ"

    """ look for PT_INTERP section """
    for i in range(0,e_phnum):
        f.seek(e_phoff + i * e_phentsize)
        ph_hdr = f.read(e_phentsize)
        if arch == 32:
            # 32bit
            p_type, p_offset, p_vaddr, p_paddr, p_filesz,\
                p_memsz, p_flags, p_align = struct.unpack(ph_fmt, ph_hdr)
        else:
            # 64bit
            p_type, p_flags, p_offset, p_vaddr, p_paddr, \
            p_filesz, p_memsz, p_align = struct.unpack(ph_fmt, ph_hdr)

        """ change interpreter """
        if p_type == 3:
            # PT_INTERP section
            f.seek(p_offset)
            # External SDKs with mixed pre-compiled binaries should not get
            # relocated so look for some variant of /lib
            fname = f.read(11)
            if fname.startswith(b("/lib/")) or fname.startswith(b("/lib64/")) or \
               fname.startswith(b("/lib32/")) or fname.startswith(b("/usr/lib32/")) or \
               fname.startswith(b("/usr/lib32/")) or fname.startswith(b("/usr/lib64/")):
                break
            if p_filesz == 0:
                break
            if (len(new_dl_path) >= p_filesz):
                print("ERROR: could not relocate %s, interp size = %i and %i is needed." \
                    % (elf_file_name, p_memsz, len(new_dl_path) + 1))
                break
            dl_path = new_dl_path + b("\0") * (p_filesz - len(new_dl_path))
            f.seek(p_offset)
            f.write(dl_path)    #★新たなパスに書き換え★
            break

プログラムヘッダのPT_INTERPセクションを探して、/libや/usr/libから始まるパス以外であれば書き換える仕組みです。バイナリにデフォルトで含まれているパスは/optから始まっていましたから、書き換え対象になるというわけです。

Zephyr SDKのhosttoolsインストール時にこんなことしてたんですね……知らんかった。

編集者:すずき(2024/04/17 02:05)

コメント一覧

コメントはありません。

この記事にコメントする

2024年4月17日

permalink

編集する

VSCodeとMarkdownとPlantUMLのローカルサーバー

目次: Linux

VSCodeのPlantUML Extensionをインストールすると、MarkdownにPlantUMLの図を混ぜることができます。

何も設定しない状態だと、

PlantUMLのサーバー設定がないときのエラー

このようにプレビュー画面に「No PlantUML server, specify one with "plantuml.server".」というエラーが出ます。

設定方法（インターネットにコードを送って良い場合）

VSCodeのSettingsの検索ボックスにplantuml.serverと入力するとPlantuml: Serverという項目が出るはずなので、そこにサーバーのURLを設定します。ヘルプメッセージにもあるように、自分で書いたPlantUMLのソースコードをインターネットに送ってよければhttps://www.plantuml.com/plantumlを指定するのが最も簡単です。

www.plantuml.comサーバーを使用する設定

設定し終わったら、このようなMarkdownの文書で動作確認します。

動作確認用のMarkdown + PlantUML


# Title 1

This is body.

## Title 2

- aaa
  - aaa is AAA
  - bbb is BBB

```plantuml
node "PC" as pc {
  node "CPU" as cpu
  node "OS" as os
}

cpu -> os: boot
```

プレビュー画面にこのような画像が出るはずです。

www.plantuml.comサーバーを使用したときの表示例

表示されました、簡単ですね。しかし外部にソースコードを送りたくない場合もあります。

設定方法（ローカルサーバー）

インターネットに自分で書いたPlantUMLのソースコードを送信されると困る場合は、PlantUMLのサーバーをローカルで起動すると良いです。PlantUMLのサイト（PlantUML Downloads and Source Code）から、PlantUMLのJARファイルをダウンロードします。今回はバージョン1.2024.4を使用しました。

起動方法は公式サイト（PlantUML PicoWeb Server）にある通りにやりましょう。

PlantUML PicoWeb Serverの起動方法

$ java -jar ./plantuml-mit-1.2024.4.jar -picoweb:5000:0.0.0.0

オプション-picowebにてサーバーが待ち受けに使うポートとアドレスを指定します。

VSCodeのPlantuml: Serverには、PlantUMLのローカルサーバーを動作させているマシンのIPアドレスと、PlantUMLを起動するときに指定したポートを指定します（例えば、http://192.168.1.2:5000など）。設定し終わったら先ほどと同じMarkdownの文書を用いて動作確認します。一度プレビュー画面を閉じてもう一度開いてください。

Insecure contentを表示させない設定になっているときの表示

VSCodeはhttpつまり暗号化されていないサーバーとの通信を拒否する設定になっています（改ざんが可能なので）。しかしローカルLANで実験する場合はこの制限は不要ですので、プレビュー画面に「Some content has been disabled in this document」という横長のボタンが表示され、画像が表示されないときは、

Insecure contentを表示させる設定に変更