いきなり仕事部屋のシーリングライトが消えました。蛍光管の寿命にしては去年(2022年10月19日の日記参照)替えたばかりですし、もしかして本体が壊れた……?
リビングのシーリングライト(同機種)と蛍光管を入れ替えると点くので、蛍光管は生きていて本体(Panasonic HHFZ4290)が壊れたようです。去年の蛍光管交換時に「2回目交換する前にシーリングライト本体が壊れそう(本体の寿命<蛍光管2回分の寿命)」と予想していましたが、その通りになりました。悲しいね。
昨今は蛍光灯が悪者扱い(わずかに水銀を使う)で製造禁止に向かっているようです(一般照明用の蛍光ランプの製造・輸出入は2027年までに廃止されます - 環境省)。店頭にはほぼLEDのシーリングライトしか売っていません。
広範囲を照らせると触れ込みのPanasonic HH-CG1034Aを買いました。明かりの色を白くしたり黄色くしたり好きに変えられるのは、LEDならではですね。あとリモコンがでっかいです。邪魔くさい。
 この記事にコメントする
 この記事にコメントする
目次: Linux
VSCodeのPlantUML Extensionをインストールすると、MarkdownにPlantUMLの図を混ぜることができます。
何も設定しない状態だと、
このようにプレビュー画面に「No PlantUML server, specify one with "plantuml.server".」エラーが出ます。
VSCodeのSettingsの検索ボックスにplantuml.serverと入力するとPlantuml: Server項目が出るはずなので、そこにサーバーのURLを設定します。ヘルプメッセージにもあるように、自分で書いたPlantUMLのソースコードをインターネットに送ってよければhttps://www.plantuml.com/plantumlを指定するのが最も簡単です。
設定し終わったら、このようなMarkdownの文書で動作確認します。
# 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)にある通りにやりましょう。
$ 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」と書かれた横長のボタンが表示され、画像が表示されないときは、
ボタンを押し、リストに表示される「Allow insecure content Enable loading content over http」を選択します。
プレビュー画像が表示されました。生成される画像は似ていますが、私の環境だと文字の表示が変になってしまいます。なぜだろう……?それは今度調べるとして、インターネット上のサーバーに比較してレスポンスが早いです。良いですね。
これはテスト用の簡易サーバー機能なので、本格的に運用する際はアプリケーションサーバーに登録したほうが良いと思います、その設定はまた今度。
 この記事にコメントする
 この記事にコメントする
目次: 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()関数が書き換える本体のようです。
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インストール時にこんなことしてたんですね……知らんかった。
 この記事にコメントする
 この記事にコメントする
目次: 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のディレクトリごと移動してしまったので、リンカーが見当たらないと怒っているようです。
続きはまた今度にします。
 この記事にコメントする
 この記事にコメントする
ささやかではありますが台湾東部沖地震に寄付しました。日本の赤十字社→台湾の赤十字(正式名称は中華民国紅十字会)の経路で支援されるようです。
今回調べて初めて知ったのですが、台湾の赤十字社は中国との関係で微妙な位置に立たされているようです。
とまあ中国と台湾間の政治問題によるものみたいです。まあ政治問題はさておいて、私は台湾赤十字の支援活動が誠実に行われていると信じて寄付するのみです。
 この記事にコメントする
 この記事にコメントする
目次: 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です。各モジュールのバージョンは、
です。
 この記事にコメントする
 この記事にコメントする
目次: 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間だけ若干狭い)ため、回転させると端子がはみ出してしまいます。私はハンダ付けが上手な訳でもなく、表面実装系の細かいやつは難しいのでハンダをちょっと増やしてごまかします。
できました。斜めに付いてる違和感がすごいのと芋ハンダだらけで長持ちしなさそうです。そもそも手修理ボードは長期運用するつもりがないから今だけ動いてくれればとりあえずヨシ!!
 この記事にコメントする
 この記事にコメントする
| < | 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 | - | - | - | - | 
 25年10月6日
 25年10月6日
 25年10月6日
 25年10月6日
 25年9月29日
 25年9月29日
 25年9月29日
 25年9月29日
 20年8月24日
 20年8月24日
 20年8月24日
 20年8月24日
 16年2月14日
 16年2月14日
 16年2月14日
 16年2月14日
 25年7月20日
 25年7月20日
 25年7月20日
 25年7月20日
 25年7月20日
 25年7月20日
 25年7月20日
 25年7月20日
 25年7月20日
 25年7月20日
 25年7月20日
 25年7月20日
 20年8月16日
 20年8月16日
 20年8月16日
 20年8月16日
 20年8月16日
 20年8月16日
 20年8月16日
 20年8月16日
 24年6月17日
 24年6月17日
 24年6月17日
 24年6月17日
 wiki
 wiki Linux JM
 Linux JM Java API
 Java API 2002年
 2002年 2003年
 2003年 2004年
 2004年 2005年
 2005年 2006年
 2006年 2007年
 2007年 2008年
 2008年 2009年
 2009年 2010年
 2010年 2011年
 2011年 2012年
 2012年 2013年
 2013年 2014年
 2014年 2015年
 2015年 2016年
 2016年 2017年
 2017年 2018年
 2018年 2019年
 2019年 2020年
 2020年 2021年
 2021年 2022年
 2022年 2023年
 2023年 2024年
 2024年 2025年
 2025年 過去日記について
 過去日記について アクセス統計
 アクセス統計 サーバ一覧
 サーバ一覧 サイトの情報
 サイトの情報合計: 
本日: