ラベル How to の投稿を表示しています。 すべての投稿を表示
ラベル How to の投稿を表示しています。 すべての投稿を表示

2024年9月6日金曜日

NUCLEO の USB Storage 問題

STMicroelectronicsのNUCLEOボードを試作(または趣味)で使う。
開発環境は、Cross-gcc +Eclipse +OpenOCD で用意している。

NUCLEOボードは、ST-LinkというデバッグI/Fがあり便利だ。
しかし、JTAG I/Fのみならず、USB Storageデバイスが接続されたようになる。
害がないならそれも良いのだが、Linuxでは問題になる。

OpenOCD User's guide の USB ST-LINK based に/etc/modprobe.confを書き換えることが書いてある。この文書は少し古い。
最近のUbuntuなら、/etc/modprobe.dの下にそれぞれの設定ファイルを置く。
私は /etc/modprobe.d/stlink.conf を以下の内容で作った。
# Prevent ST-LINK from showing up as a USB disk
options usb-storage quirks=483:3744:i,483:374b:i,483:374e:i
これで、ST-Linkを接続しても、自動マウントされなくなる。

解決したと思っていたが、職場のPCではおかしなことになった。
上記、/etc/modprobe.d/stlink.conf を用意しても効かない。

起動時、initrdの段階で、usb-storage.ko が読まれているのでは?と、思った。

この設定は、モジュールロード時のパラメータだ。
initrdの段階では、/etc/modprobe.d/の設定は読めない。VAIO-C1で遊んでいるときに経験していた。
職場のPCにはUSBカードリーダが常時接続されている。
bootシーケンスのinitrdの段階でそれを検出すると、usb-storage.koがロードされる。
その時点では/etc/modprobe.d/の設定はアクセスできないので、結果的にパラメータなしでロードされる。

ルートファイルシステムマウント後(/etc/modprobe.dがアクセス可能になる)、ST-Linkを挿しても、すでにusb-storage.koが読み込まれているので、再ロードは行われない。
そのため、/etc/modprobe.d/stlink.conf が、無視されたように見える。
rmmodで、アンロード(uasを先にアンロード)してNUCLEOを挿すと、再ロードが行われる。
このとき、/etc/modprobe.d/stlink.conf が適用されるため、ST-LinkのUSB Storageがマウントされない。

わざわざrmmodするのは面倒だ。
何もせずとも、ST-Link の USB Storage はマウントしないでほしい。
initrdでのモジュールのパラメータを調整するには、VAIO-C1のときのように、/etc/initramfs-tools/modules を書き換える。以下のようになる。
# List of modules that you want to include in your initramfs.
# They will be loaded at boot time in the order below.
#
# Syntax:  module_name [args ...]
#
# You must run update-initramfs(8) to effect this change.
#
# Examples:
#
# raid1
# sd_mod
usb-storage quirks=483:3744:i,483:374b:i,483:374e:i
最後の行が追加したもの。
コメントを読めばわかるが、書き換え後initrdを作り直す必要があり、update-initramfs を実行しなければならない。以下のように:
$ sudo update-initramfs -u
[sudo] <ユーザ名> のパスワード: 
パスワードを入力すれば、initrdが更新される。

これをやれば、/etc/modprobe.d/stlink.confが不要というわけではない。
起動時にUSBメモリやUSBカードリーダが接続されていない場合は、initrd内でusb-storage.koは読み込まれない。
Linuxの起動が完了した後は、/etc/modprobe.d/stlink.confが必要になるので、両方用意しておく必要がある。

最初にSTM32を使ったのは、雑誌(CQ出版 Design Wave 2008年5月号)の付録のSTM32F103VBだった。
(さっき発掘してきた)

開発環境は、cross-gcc + eclipse + OLIMEXのJTAG(千石で購入) で揃えた。

最初に開発環境を自力で揃えてしまったので、未だにSTM-STUDIOを使わない(Cubeは利用するけど)。
もしかしたら、STM-STUDIOを使っている場合はこんな問題に遭遇しないのかもしれない。

最近ではarm-none-eabi用のgccを自分でビルドしなくても良くなり、OpenOCDもUbuntuのもので十分だ。
多少楽になったが、それでも自前で揃えるには何気に大変だ。
バカバカしいかもしれないけど、何かを開発するのは苦労の連続だ。
苦労と考えず、楽しむつもりでやるのが「馬鹿の道」。ついでに、問題解決力が鍛えられる。

2023年2月19日日曜日

Type Generic Mathematics Header

仕事(組み込み)で数学的な処理が必要になった。
昔なら、整数演算して、関数の類はテーブル解決にしたりして、そして出来上がったコードは複雑怪奇で、メンテナス性が低く、作った本人もすっかり忘れて、ブラックボックスになっていく...というパターン。
最近は組み込み用のマイコンでも単精度ながら浮動小数点演算器が入っているものもある(Cortex-M4とか)。
そういうのなら、整数演算でなくても良い。メンテしやすいコードでも性能が出る。

C言語の実数型は一般的に、単精度と倍精度がある。80年代には拡張精度もあった。最近では4倍精度も使える。
処理速度や計算精度の最高のバランスを得ようとするとき、実数の型(精度)を入れ替えながら検証したいところだ。

四則演算だけなら、マクロやtypedefで変数の型を定義直すことで、一発で簡単に実数の型を変更できる。
しかし、算術ライブラリmath.h内の関数を切り替えるのは、少し面倒だ。
C言語には、C++で言うところのオーバーロードの機能が無いので、やや複雑なマクロを使って切り替えなければならない。
マクロは型を認識できないためだ(少なくとも昔ながらの標準的なCコンパイラでは)。

マクロはプリプロセッサが処理する。プリプロセッサはその名の通り、前処理をするもので字面を置き換えることしかできない。
型が意味を持つのは、パーサーやコードジェネレータの段階だ。
マクロは型を知らないので、マクロで型を何にするかを示して、その値を使って型と関数の置き換えを定義するような2段階構造にしなければならなかった。

math.hが提供する関数全てにマクロを用意するのは面倒なので、リストファイルを参照(gccなら"objdump -t")し、使用しているシンボルを確認して、使っている関数のみ定義する。
すなわち、その場しのぎのやっつけ実装。
そんな感じなので、いつもやり直すことになる。

今回、移植しようとしたコードがatan()をそのまま使っていた。
atan()と言えば、この記事に示すように、そのまま使うべきではない。
y/xが無限にならない事が解っているならそれでも良いが、不要な疑念を避けるためにもatan2()に置き換えるべきだ。

それは解っているのだが、自称「おっちょこちょいリンピック日本代表」のこの私が5年前の記事をハッキリ憶えてるわけがない。
80年代からの自分の解決方法 "atanXY()" が邪魔をして、"atan2()"の名前が出てこない。プログラミングは、名前が重要だ。

思い出そうとしても無理なので、/usr/include の下の全ヘッダファイルに対して、文字列'atan'を検索してみた。
大量の一致がみつかり、絞り込みをしている時に、"/usr/include/tgmath.h" を発見した。
"/usr/include" 直下にあることから、かなり標準的なもののようだが、これは一体なんだ?
と思って、調べ始めた。

"tgmath" = "Type Generic Mathematics" の意味で、日本語にするなら「型一般化算術」とでもいうのかな?
"math.h"の代わりに、このヘッダを使うだけで、引数の型から自動的に呼び出す関数を切り替えてくれるすぐれものだ。

ISO C標準 11 (C11)で追加され、以降標準的に使えるらしい。
型を知るためにコンパイラが強化されていて、2段階の定義は要らない。
(逆に古いコンパイラではヘッダファイルだけあっても正しく動かないだろう)

引数の型を自動認識するのは強力で、イミディエート値でも、typedefし直した型でも、正しく解決してくれる。
例えば、以下のように、atan2()を呼び出すと仮定してみよう。
void func( MY_REAL x, MY_REAL y )
{
    MY_REAL angle = atan2( y, x ); 
    :
    : (省略)
    :
このとき、MY_REAL が
typedef float  MY_REAL;
のようになっていると、生成されるコードは、atan2f()を呼び出す。また、
typedef long double  MY_REAL;
のようになっていると、生成されるコードは、atan2l()を呼び出す。
生成された.oファイルを、"objdump -t"で見てみると良い。

この問題、世界中の人がうんざりしていたのかな。
速度と精度のトレードオフのために、実装した後で、単精度、倍精度、4倍精度を切り替えて評価を行うこともあるだろう。
その作業が楽になる。

整数(固定小数点)演算に置き換えるのは、計算の桁数や精度を考え、検証しなければならなかった。
この作業は実装結果だけみても、苦労が理解されにくく、評価されない。
作業量を見積もっても「なんで?」みたいになることが多い。
うっかりBugでも出そうものなら、「簡単なのに何やってるの?」みたいな。
さらに、入出力の精度や桁数に強く依存しており、出来上がったコードは奇妙奇天烈複雑怪奇魑魅魍魎渦巻く地雷原であり、再利用が困難になる。
それが単精度浮動小数点が使えるだけで、ものすごく楽になる。言うならば「素人でも実装できる」。
メンテナス性も向上するだろう。

単精度、倍精度の切り替えは、マクロで解決できる内容ではあるが、それすら用意する必要が無くなる。
いい時代になったものだ。

2022年10月28日金曜日

Ubuntu 22.04 Gnome flash back session で、むりやりNemo RabbitVCS

少し前に、Ubuntu 22.04で「RabbitVCSが動かなかったりするので…」なんて書いていた。

少し前は、アイコンにエンブレムは表示されるが、ポップアップメニューによる操作はできなかったのでそのように書いた。
RabbitCVSが新しくなっていたので、試してみたら動くようになっていた。

昔ながらの使い方を続けているので、Ubuntu22.04といえども、Gnome Flashback session を使っている。
さらに、Compact Viewを使いたいので、ファイルマネージャをNemoに入れ替えている。

やや変な使い方なので、あまり役に立たないかもしれないけど、動かすまでを書いておく。
まず、Ubuntu22.04でも、Nemo用のRabbitVCSのパッケージはない。
このThe new home of rabbitvcsからソースを得て使うことになる。
そのため、UbuntuパッケージのRabbitVCSを入れてはいけない。「ませるな危険」の考えだ。

RabbitVCSをインストールする前に、必要なパッケージをinstallする。
installしたのはだいぶ前のことなので、細かい事は忘れてしまった。
こういう時に、必要なことをパッと示せればカッチョいいのだが…。
Ubuntuのrabbitvcs-coreパッケージのdependsや、aptのヒストリをしらべたところ、以下のものを入れていたようだ。
gedit
hicolor-icon-theme
ipython3
meld
python3-configobj
python3-dbus
python3-dulwich
python3-nautilus
python3-simplejson
python3-svn
python3-tk
subversion
nemo-python
上記をインストールすると、依存パッケージも色々入る。
最初に開発パッケージその他も色々入れていたので、事前に入れていたものもが上記には含まれていない。
そのため、たりないものもあるかもしれない。
また、あなたの環境ではすでに入っているものもあるかもしれない。
それらをわざわざインストールし直す必要はない。
インストールしても動作には問題ないが、手動でインストールされたと表示されるようになる。

依存物を入れたら、RabbitVCSを入れる。
以下のようにして、gitで取得する。
$ git clone https://github.com/rabbitvcs/rabbitvcs.git
rabbitvcsというサブディレクトリができるので、その中に入ってsetup.pyを使ってインストールする。
$ cd rabbitvcs

$ sudo python3 setup.py install --install-layout=deb

これでRabbitVCSの基本的なものは入った。
それが済んだら、Nemoのクライアントを入れる。
$ sudo mkdir -p /usr/share/nemo-python/extensions

$ sudo cp clients/nemo/RabbitVCS.py /usr/share/nemo-python/extensions/

後は、再起動すれば、Ubuntu 22.04 で Nemo RabbitVCSが動く。

まだ動かないなんて書いてしまった後で動くようになっていたので、あわてて記事を書いた。
Ubuntu 22.04 も良いかもしれない。
とはいえ、個人的には18.04をギリギリまで使うつもりだ。

関連記事: Ubuntu 18.04 で無理やりNemo RabbitVCS #2
2022/10/29 文書を少し直した。

2022年7月1日金曜日

Shotcutが動かない

ビデオ編集にShotcutを使っている(たとえば、こんな感じ)。
先週使おうとしたら動かなくなっていた。

コマンドラインから起動すると、以下のようなエラーがでて起動しない。
$ shotcut
bin/shotcut: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by bin/shotcut)
bin/shotcut: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /snap/shotcut/749/Shotcut.app/lib/libQt5Multimedia.so.5)
bin/shotcut: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /snap/shotcut/749/Shotcut.app/lib/libQt5Widgets.so.5)
bin/shotcut: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by /snap/shotcut/749/Shotcut.app/lib/libQt5Widgets.so.5)
bin/shotcut: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.28' not found (required by /snap/shotcut/749/Shotcut.app/lib/libQt5Widgets.so.5)
bin/shotcut: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.28' not found (required by /snap/shotcut/749/Shotcut.app/lib/libQt5Xml.so.5)
bin/shotcut: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by /snap/shotcut/749/Shotcut.app/lib/libQt5Xml.so.5)
bin/shotcut: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /snap/shotcut/749/Shotcut.app/lib/libfftw3.so.3)
bin/shotcut: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /snap/shotcut/749/Shotcut.app/lib/libQt5Quick.so.5)
bin/shotcut: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /snap/shotcut/749/Shotcut.app/lib/libQt5Gui.so.5)
bin/shotcut: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /snap/shotcut/749/Shotcut.app/lib/libQt5Qml.so.5)
bin/shotcut: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /snap/shotcut/749/Shotcut.app/lib/libQt5Core.so.5)
bin/shotcut: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by /snap/shotcut/749/Shotcut.app/lib/libQt5Core.so.5)
bin/shotcut: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by /snap/shotcut/749/Shotcut.app/lib/libQt5Core.so.5)
bin/shotcut: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.28' not found (required by /snap/shotcut/749/Shotcut.app/lib/libQt5Core.so.5)
bin/shotcut: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /snap/shotcut/749/Shotcut.app/lib/libpulse.so.0)
bin/shotcut: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /snap/shotcut/749/Shotcut.app/lib/libicui18n.so.66)
bin/shotcut: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /snap/shotcut/749/Shotcut.app/lib/libicuuc.so.66)
bin/shotcut: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /snap/shotcut/749/Shotcut.app/lib/libpulsecommon-13.99.so)
bin/shotcut: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by /snap/shotcut/749/Shotcut.app/lib/libsystemd.so.0)
bin/shotcut: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.30' not found (required by /snap/shotcut/749/Shotcut.app/lib/libsystemd.so.0)
bin/shotcut: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /snap/shotcut/749/Shotcut.app/lib/libsndfile.so.1)
bin/shotcut: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /snap/shotcut/749/Shotcut.app/lib/libpng16.so.16)
bin/shotcut: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /snap/shotcut/749/Shotcut.app/lib/libFLAC.so.8)
glibcのバージョンの問題。
snapでもこんなことがあるのか。
shotcutは、classicという分類になっており、snap監獄の中に完全に封じ込められているわけではないようだ。

色々調べると、このページにたどり着いた
中ぐらいに、「以降、古いUbuntuのバージョンと互換性がなくなり、ウエブサイトを更新する以外の対処をしません。OSをアップグレードできるまでは前のバージョンを使ってください。」的なことが英語で書かれている。
ウチでは、まだ Ubuntu 18.04 を使い続けているため、そのせいで動かなくなったのだろう。

また、(動いていた)前のリビジョン 692 (v22.04.25) に戻す方法も書かれている。
以下のようにするらしい。
sudo snap revert --revision=692 shotcut
実際にやってみたら、また動くようになった。

しかしながら、revertは、任意のバージョンに戻せるわけではない事も、その2つ下のリンク先に書かれている。
この方法は、前のリビジョンのShotcutをsnapでインストールしていた場合のみ、使える。

snapじゃないポータブル版もあるが、依存関係の解決を自力で行わねばならず、難しいかもしれない。
そのため、過去にsnap版shotcutをインストールしていないのなら、Ubuntuを新しいもの(20.04や、22.04)にするか、VirtualBox等で新しいUbuntuを動かして、その中でshotcutを使うほうが簡単かもしれない。

実は、先週のBIOS Flash Updateのビデオ編集のとき、shotcutが動かなくなっていることに気が付き、このVirtualBox内のBudgieのshotcutで編集した。

そろそろUbuntuを新しくすることを検討する時期かな…

2022年6月26日日曜日

DELL Optiplex BIOS update w/o Windows

自宅では、Linuxを使っている。
Turbo Linux や Vine Linux を経て、10年ぐらい前からは Ubuntuを使うようになった。

Linuxを使っていて困るのは、BIOS(UEFI)の更新だ。
多くのPCはBIOSの更新にWindowsを必要としている。
そのため、デュアルブートにして残しておいたりしている。

先日、Ubuntuパッケージの更新をしているとき、intel-microcodeの更新があった。
また同時期、職場のPCでもWindows Update があり、BIOSの更新があった。

Ubuntuのintel-microcodeと、BIOSの関係は良くわからない。 WindowsでもBIOSの更新を必要とするなら(必要ないならWindowsの更新だけでいいはず)、Linuxでも必要だろう。

実は、手間がかかるが、LinuxでもBIOSの更新ができる。
今回、自宅のLinux機 DELL Optiplex 7050 のBIOS更新に挑戦してみた。
最近は、だいぶ簡単になった。それについて書く。

検索すると、"OptiPlex 7050 Micro Owner's Manual"のUpdating the BIOS in Linux and Ubuntuが見つかった。
LinuxやUbuntuを用いたコンピュータ上で、システムBIOSを更新するなら、ナレッジベースの記事 000131486を参照せよと書かれている。

このリンクをクリックすると、Update the Dell BIOS in a Linux or Ubuntu environmentが表示される。

UEFI Capsule updatesという方法で、アップデートを行うようだ。
対応するPCは、このページに書かれている。DELL製以外のPCも多く書かれている。
OptiPlexなら、4桁番号のやつは対応しているようだ。6〜7年前よりも新しいPCなら対応してそうだ。
我が OptiPlex 7050 も対応している。

丁寧に長々と書かれているが、基本的には、
  • FATフォーマットされたUSBメモリを用意する。
  • DELLのドライバダウンロードページで、自分のPCにあったBIOSアップデートをダウンロードする。
  • ダウンロードしたBIOSアップデートを、USBメモリにコピーする。
  • PCを再起動し、F12を連打して "One-time Boot menu" (いわばBIOS設定画面)に入る。
  • カーソルキーで "BIOS Flash Update" を選んで、Enterキー。
  • "BIOS Flash Update"画面に従って、操作する。
サポートページに行くと、サービスタグやプロダクトID等の入力が求められるが、Optiplex や 7050 を入力すると、候補が表示されるので、その中から適切なものを選ぶと良い。
OptiPlex 7050 では、"Dell OptiPlex 7050システムBIOS" というものをダウンロードした。

ファイルサイズは20MBそこそこなので、USBメモリの容量を意識する必要もない。

ファイルは、Windowsの実行形式だった。これで良いのかとも思うが、Update the Dell BIOS in a Linux or Ubuntu environmentの真ん中ぐらいに、
Note: the BIOS flash ends in an .exe extension. Even though Linux cannot open it natively, the BIOS will deal with it properly.
と書かれている。BIOSはこの実行形式ファイルを適切に扱えるようだ。
UEFIには、COFFローダがあるのかな?なんか怖くなるな。

とはいえ、そういうことならUSBメモリさえ用意できれば、Linuxに限らずBIOS更新ができることになる。
以前は、FreeDOSを用意する必要があった。便利になったものだ。

実際にUEFI(BIOS)で、BIOS Flash Upadte を行う様子を撮影した。

UEFIのBIOS Flash Updateの操作方法の詳細は、上記ページにも書かれておらず、試行錯誤が必要だった。
製品毎に微妙に違うので、詳細が書けないのだろう。

Windows11難民の中には、Ubuntuに避難してきた人もいるだろう。
Windowsに慣れている人は、Linuxは難しいというが、実際にはどちらも充分に複雑だ。
英語に不慣れな人が英語は難しいと言うのと同じだ。英語ネイティブな環境なら、子供でも英語で話せる。

Linuxではできないことも多かったが、BIOSの更新も簡単にできるようになって、徐々に改善してきている。
古いPCを捨てずに、Linux機として使ってみるのも良いよ。

2022年6月25日土曜日

ダイソーの「ソーラー充電モバイルバッテリー」

ダイソーのアウトドア用品売り場に、「ソーラー充電モバイルバッテリー」があった。
買ってきた。
太陽光でも充電できるモバイルバッテリーだ。
普通のモバイルバッテリのように、USBのACアダプタがあればそれでも充電できる。
5000mAhの容量がある。

さらにLEDライトが内蔵されており、災害時にも役立ちそうだ。
ダイソーの製品の中では高めの 1,100円(税込み)。
見つけたら買っておこう。

「残量確認ボタン」にはマニアルに書いていない機能がある。

まず、マニアルに書いてあるのは、
  • 短押しで、残量がLEDで表示される。
  • 長押しで、ライトが点灯/消灯する。
だけだ。
短押しで残量が表示されるが、もう一度短押しをしても、OFFにならない。

なんとかOFFにならないものかと思って、あれこれいじっていたら見つけた。
なんと、ボタンをダブルクリックすると、OFFになる。

また、放電時(スマホ充電時)にダブルクリックをすると、放電(スマホ充電)がOFFになる。
放電OFF状態で、シングルクリックをすると放電(スマホ充電)が再開する。

やや心配なるのは、熱くなることだ。
装置の特性上、直射日光を浴びるので、どうしても熱くなる。
熱くなると、太陽電池の発電能力も落ちる。

直射日光を浴びているコンクリートや、エアコンの室外機は熱い。
それらの上に直接置くのは、むしろ温まりそうだったので、同じくアウドドア用品売り場にあった「ポケットストーブ」330円(税込み)の上に設置した。
ただし、この状態だと、ほぼほぼ空気に置いている状態なので、熱がこもりやすい(空気の熱の伝導率は低い)。
なにかいい方法ないかな。

追記: ソーラ充電で、充電できる量について。
快晴で、6月とは思えない暑さがつづく。実際に記録的な暑さだ。
暑いだけでなく、夏至にも近く、太陽光も強烈だ。

この太陽光を利用して、どれだけ充電できるか、6/25(土)、26(日)の2日で試してみた。
とは言っても、一日中陽のあたる場所がうちには無い。そのため、太陽を追いかけて、移動させなければならない。
日中の全時間、太陽光を当てたわけではないことを断っておく。

1日目終了時点で、LED1つ分充電できた。
すなわち25%だ。

2日目終了視点で、LED2つになった。
すなわち50%になった。

完全に充電できるのは、まだかかりそうだ。
かなり離散的な表示なのであてにはならないかもしれないが、表示を信じれば、ウチの環境では満充電まで最低でも3日かかりそうだ。

2022年4月9日土曜日

カーミット

Kermit(カーミット)といえば、Sesame street のキャラクタを思い出す人も多いだろう。
やたらと早口で喋るカエル(びっき)のKermit だ。時々リポーターの仕事をする。
かく言う私も、Kermitは大好きなキャラクタだ。

プログラマ、特に組み込み系の人にとって、Kermitと言えば、もう一つある。
通信ソフトウエアパッケージの Kermit だ。
私はLinux上での組み込みマイコン開発時、シリアルポートの操作のために使っている。
Kermitは膨大な機能があるため、man-pageを見ても、便利なヘルプ機能を使っても、どこに何が書いてあるかわからない。私も全てを使ったことがあるわけではない。
そのせいで敷居が高いと感じる人も少なくはないだろう。
しかし、シリアルポートでの最低限の使用に限れば、けっして難しくはない。
今回は、UbuntuでのKermitでのシリアルポートの操作について書く。

インストールしよう

UbuntuでKermitを使うなら、aptでckermitパッケージをインストールするのが手っ取り早い。
こんな感じ:
$ apt-get install ckermit

起動しよう

インストールができたら、起動しよう。
シリアルポート使うなら、起動オプションでポートのスペシャルファイルを指定して起動するのが良い。
$ kermit -l /dev/ttyUSB0
上記は、USBシリアルデバイスの0番を指定している。レガシーポートのあるPCなら、COM1は"/dev/ttyS0"、COM2は"/dev/ttyS1"を指定する。
起動後のコマンドモードでも指定できるのだが、コマンドオプションの方が短く済むし、後で示す.kermrcを使った設定のためにも、起動時に指定したほうが良い。

通信設定しよう

Kermitは起動直後、インタラクティブコマンドモードになる。
起動時に、ポートを指定していないなら、"set line"コマンドで指定する。
(/home/foo/) C-Kermit>set line /dev/ttyUSB0
起動時に入力したほうが多少短い。起動時に'-l'で指定したほうが、楽だろう。

起動時にポートを指定していれば、必要な設定は、
  • フォーマット(キャラクタ長、パリティ、ストップビット長)
  • ボーレート
  • フロー制御
  • キャリア監視
キャラクチャ長、パリティ、ストップビット長をまとめて、フォーマットと書いているが、これらをまとめてセットするのが便利なためだ。
これらは、"set serial"でまとめてセットする。
たとえば、よく使われる(であろう)「キャラクタ8bit, パリティなし、1ストップビット」なら、以下のように指定する。
(/home/foo/) C-Kermit>set serial 8n1
"8n1"の3文字のそれぞれが、キャラクタ長('8'=8bit)、パリティビット('n'=none parity)、ストップビット長('1'=1stop)を示している。
使える組み合わせは、"set serial"と入力後に'?'を打つとダダっと表示される。
このコマンドに限らず、いろいろな場面で'?'を打つと、インタラクティブなヘルプが表示される。憶えておくといい。
キャラクタ長は 7, 8 が使える。
パリティは、キャラクタ長が8bitの場合、'n'=なし、'e'=偶数パリティ、'o'=奇数パリティから選べる。7bitの場合、それに加えて、'm'=マーク、's'=スペースも選べる。
ストップビット長は、1, 2 が使える。
それぞれ個別に指定もできるのだが、この1発入力表現がとにかく便利だ。

ボーレートは、"set speed"で指定する。
115.2Kbpsなら、
(/home/foo/) C-Kermit>set speed 115200
原因不明ながら、フォーマット指定後にボーレートを指定しないと、フォーマットが無視されることがある。
そのため、後からボーレートをセットしたほうが良い。

フロー制御は、"set flow-control"で指定する。
フロー制御無しなら、
(/home/foo/) C-Kermit>set flow-control none
俗に言うハードウエアフロー制御(RTS/CTS)なら"rts/cts"を、ソフトウエアフロー制御(XON/XOFF)なら"xon/xoff"を指定する。
ここでも忘れてしまった時は'?'だ。

最後の「キャリア監視」は、ピンとこないだろう。
KermitはシリアルポートのCD(Carrier Detect)をデフォルトで監視しており、これが落ちていると接続状態にならない。
使用するクロスケーブルや、開発機のハードウエア構成にもよるのだが、CDがオープンの場合も多いだろう。
そういう時は、"set carrier-watch"を使って、
(/home/foo/) C-Kermit>set carrier-watch off
として、監視を止める。

接続・切断しよう

これで設定ができたので、接続してみよう。
接続には、"connect"コマンドを使うのだが、これは短縮形の"c"でいい。
(/home/foo/) C-Kermit>c
接続すると、以下のようになる。
(/home/foo/) C-Kermit>c
Connecting to /dev/ttyUSB0, speed 57600
 Escape character: Ctrl-\ (ASCII 28, FS): enabled
Type the escape character followed by C to get back,
or followed by ? to see other options.
----------------------------------------------------

英語が読める人はもうおわかりと思うが、インタラクティブコマンドモードに戻るには、CTRL-\押下後、'C'を入力する。
'C'の代わりに'?'を入力すると、ヘルプが表示される。
'C'の他によく使うものは、'U'と'Q'かな。
'U'は接続を切断し、コマンドモードに戻る。
'Q'は切断して、Kermitも終了する。

CTRL-\ + 'C'で戻っても、シリアルデバイスはopen状態にある。
設定を変えて接続し直す場合、'U'で終えるか、'C'で戻った後で明示的に'close'コマンドを引数無しで使う。

ファイルを垂れ流し送信しよう

マイコンでの開発をしていると、まとまったデータをマイコン側へ送りたいときがある。
Motorola-SやIntel-hex形式のファイルをROMライタへ送りたい時(いつの時代だよ!)などだ。
ROMライタに限らず、マイコン内蔵Flashの内容を書き換えるコード(ローダ)をマイコンに用意しておいて、JTAGなしでプログラムを書き換える機能を用意することもあるだろう(最近は無いのかな…)。
その場合は、インタラクティブコマンドモードで、"transmit"コマンドを使う。
(/home/foo/) C-Kermit>transmit ファイル名
これで送信できるのだが…。やってみればわかるけど、とても遅い。
実は、kermitは、行毎に待ちを挟む。
受信側に配慮したやさしい動作であるが、大量のデータをやり取りすることを目的としている場合、受信側もバリバリにチューンしているだろう。最近のRISCマイコンなら、十数MHzのマイコンでも、115.2kbpsを取りこぼすのは稀だ。
Flash消去・書き換えにはさすがに時間がかかるが、それは毎行に待ちを挟むと言うよりも、消去ブロック単位や書き込み単位で待ちを挟むべきであり、その場合はフロー制御を使うべきだ。

ちょっと脱線したけど、transmitの際に、'/NOWAIT'オプションを指定すると、待ちを除去できる。
(/home/foo/) C-Kermit>transmit /NOWAIT ファイル名
ボーレートが高いほど、待ちの影響も大きい。
バリバリチューンを無駄にしないためにも、憶えておこう。
その他にも、transmitコマンドのオプションがある。'?'で表示されるので見ておくと良い。

受信内容を記録しよう

マイコンの動作確認やDebugの際に、シリアルポートを使うことも多い。
この場合、行った作業を記録しておきたい。
インタラクティブコマンドモードで、"log session"を使う。
(/home/foo/) C-Kermit>log session ログファイル名
ログファイル記録されるのは、プレーンテキストであり、エスケープシーケンスは記録されない事に注意せよ。

BSキーとDELキーの扱い

TeraTermを使っていると、BSキーを押した時、0x08(CTRL-H)が送信される。
BSのコードは0x08なので、この動作は正しい。

しかし、Linuxの端末では、BSキーを押すとDEL(0x7F)が押されたものとして動作する。
Kermitは、通信アプリであり厳密には端末エミュレータではない。端末としての振る舞いは、それを起動した端末に依存する。
そのため、KermitもBSキーが押された場合、DEL(0x7F)を送信することになる。
すなわち、TeraTermと違う動作になる。

このねじれ現象は歴史的な経緯により生じたものだ。
そもそもDELキーはBSキーの動作をしていた時期があり、その後現在と同じような動作になるのだがBSとは違うので、0x7Fなどというコード(それ以外の制御文字はすべて0x20未満)を持つ。
この件、かなり古いもので、知る人ぞ知る情報だったのだが、最近はネット上に転がっているので検索して読んでみるのもいいだろう。
2022年4月15日 追記: DELが0x7Fなのは、紙テープを使っていた頃の影響

改めて、Wikipediaの「削除文字」の部分を読むと、全ビット穴が空いている(7bit文字なら0x7F)部分を読み飛ばすという動作になっており、それを使って修正液のように文字を消すので、0x7Fだそうだ。
それとは別に、BSとDELの混乱も書かれている。とにかく、ごちゃごちゃしている。

そして、Linuxではこのねじれに対して、VT100のキー配列とLinus氏の判断により、BSキーはDEL(0x7F)を発行する。
詳しくは、Linuxの文書、"The Linux Keyboard and console HOWTO"の、"5.2 How to tell Linux what code to generate when a key is pressed"のあたりにチラッと書いてある。

色々対処方法はあるが、私はKermitでコードを変換するようにしている。
以下のようにすると、BSキーがBS(0x08)を送信するようになる。
(/home/foo/) C-Kermit>set key \127 \8
これで、他のアプリに影響を与えず、TeraTermと相互運用しやすくなる。

自動設定しよう

Kermitのインタラクティブコマンドモードのコマンドを、${HOME}/.kermrcに書いておくこと、起動時にそれが実行され、設定される。
私の.kermrcは以下のようになっている。
$ cat .kermrc 
set line /dev/ttyUSB0
set speed 57600
set serial 8N1
set flow-control none
set carrier-watch off
set key \127 \8
ボーレートが57.6kbpsになっているのは、例のマイコンボードを使ってるためだ。
こうしておけば起動すればすぐに使えるし、コマンドを忘れたとしてもこの.kermrcを見れば思い出すだろう。

エスケープシーケンスとキー入力

ここからは、kermitと言うよりもマイコン側の話だ。
エスケープシーケンスは、端末ごとに微妙に違っており、マイコン側で全てに対応するのは無駄だろう。
基本的にはANSIエスケープシーケンスに対応すればいい。
しかしながら、PC-98(だから、いつの時代だよ!)で、デバッグしていたコードを移植する場合、カーソルON/OFFのコードが違う。
意味PC-98ANSI
カーソルON ESC [>5lESC [?25h
カーソルOFFESC [>5hESC [?25l
また、LinuxではDELキーは(0x7FがBSなので)、エスケープシーケンスで表現される。
さらにこのへんにも書いてあるが、 キー入力のスキームはいくつも存在し、残念なことに多くの端末は異なるスキームのシーケンスを混ぜているので、ホストソフトウエアはあらゆるスキームを使った入力シーケンスが扱えなければならないのだ。
すなわち、DELキーは、0x7Fのみならず、エスケープシーケンス表現でも扱えるように実装しておくべきだ。

一通り使えるであろう方法を示した。

kermitは、Windows以前の'80年代から存在しているので、「あー、あれね。」と思う人もいるだろう。
昔からパソコンをいじっている人の中には特に。

厳密には端末エミュレータではないが、端末上で動作し、その端末の機能を利用することで、端末エミュレータのように使うこともできる。

しかしながら、日本ではPC-9801のDOS上で、CCT-98など高速動作する端末エミュレータが使われることが増え、さらにWindows後ではTeraTermに移行していった。

私は、'90年代末頃からPC Linuxを使うようになった。
そのころからGCCが日立SuperHを扱えるようになったので、それを使うようになった。
端末エミュレータとしては、当初はWindowsのTeraTermを使っていたものの、「今でもKermitがあるんじゃね?」と思って探すとすぐに見つかった。
そのため、またLinux上でKermitを使うようになった。
使わなくなってから数年経過していたため、使い方をかなり忘れていたが、使い始めればすぐに思い出していった。

Kermitをまた使うようになってから20年ぐらいになるだろう。途中、使わなかった時期があったことも最近では忘れていた。

ずっと使っているし、昔から存在しているので誰でも知っていると思っていた。
若手はKermitを知らない場合もあるが、若者は経験がまだ少ないのだからそういう事もあると、思っていた。
最近になって、色々見てみると意外にみんなKermitを知らないようだ。

考えてみれば'80年代では広く使われていたが、現在と比べ'80年代は、PCを使う人そのものが少なかっただろう。
Windows以降、大量の人の流入により、Kermitを知っている人は少数派になっているようだ。

いつの間にやら、世界は変わっていた。

2022年2月13日日曜日

ディスプレイアーム

デスクトップPCのディスプレイを、ディスプレイアームで固定することにした。
地震にも強いし、ディスプレイをサッと移動できれば、裏側のスペースを小物置きに使えると考えたからだ。

昨日買ってきて、今日の朝から設置しようとした。
買ってきたディスプレイアームの取り付け方式は2つある。「机の縁にクランプのように締めて固定する方式」と、「天板に穴を空けてネジで締め付ける方式」だ。
アームを初めて使うのに、天板に穴を開けるのは怖い。
そもそもアームを本当に使い続けるかどうかもまだ解らない。
そのため、クランプ方式でとりつけることにした。

昔から使っている机、この机の天板の縁の飛び出している部分は、3.5〜4.0cmぐらいしかない。縁がr=15ぐらいでベベルされているので、しっかり掴めるのはせいぜい2.0〜2.5cm。
そこにアームのクランプをはめようとしたが、しっかりと挟めない。
下側の押さえ金具(?)の幅が5cmもあり、力の入る部分が机の縁ギリギリになるのだ。

色々試行錯誤したが、どうしてもしっかりと固定できない。
アームごと倒れてしまったら本末転倒だ。

下側の押さえ金具が大きすぎて、力の入る場所が縁ギリギリなのが良くない。
このクランプを使うのを諦め、うちにあったダイソーのCクランプ(たしか10cmのやつ)2つで金具を締め付けることにした。
抑え金具は小さいので、しっかりと挟み込める。
写真では見えないが、クッションパッドの貼り付け位置も工夫し、縁ギリギリ、クランプで力の入る部分よりも少し外にクッションパッドが3つ並んでいるような状態になっている。
しっかりとクランプを締め上げると、がっちり固定された。
抑え金具は小さくなったけど、2つで締めているので、外れることは無いだろう。

半年ぐらい使って使って良さそうなら、天板に穴を空けて固定しようかな。

2022年2月5日土曜日

New Normal

COVID-19の流行が始まった頃から「新しい世界」へ移行することの重要性を時々書いてきた。

交通網や物流網の発達と効率化により、人の行き来が増えた。
それにより、世の中は便利になり、商業活動も活発になった。
しかし、感染症が一気に広がるパンデミックも、交通網の発達が原因だ。

発展のためには「つながり」を切るわけには行かない。逆に増やしていく必要がある。
そうであれば、パンデミックの危機はどんどん身近になる。
だから、感染症の流行を抑えつつ、活動をする方法が求められる。

世界に先駆けて、それを達成できたところが発展していくことになるだろう。
数年前は、それを「新しい世界」と読んでいた。
しかし、最近では"New Normal"と呼ぶようになったようだ。

保守的な臆病な人にしたら「新しい世界」という言葉は、「なんじゃ、そりゃ!😱」だったのかもしれない。
「New normal= 新しい普通」なら、なんか受け入れやすそう。

オミクロン株、感染者数がどんどん増えているが、New Normalの練習のつもりでやっていこう。
いいやり方があるなら、どんどん試していこう。怖がることはない。
久しぶりにコロにゃんを描いた。
アマビエの絵を描いてしまったので、召喚したことになるのかな。
タブレット画面に映っている絵だから、直接アマビエではないから、召喚にならないかな。

2022年1月9日日曜日

冷凍たこ焼き

関東在住のためか、「たこ焼き」をあまり食べない。
50年以上生きているが、5回も食べてないだろう。

お祭りで売られているのは、6個入りで600円。なんとなく納得できない値段設定。
だからと言って、おうちで作るかと言えば、たこ焼き用鉄板も無い。
わざわざ鉄板を買うか?そこまでするか?
敷居が高いと言わざるを得ない。

ところが、TVで「冷凍たこ焼き」の事を話していた。
レンジでチンすればいいなら、変な鉄板は必要ない。

今日、近所のBig-Aの冷凍食品を見ている時に、冷凍たこ焼きが目についた。
40個入り467円。1個あたり11.7円。納得の値段。
早速買ってきた。

買ってきたはいいけど、どうやって食べたらいいんだろう?
ソース? ポン酢醤油? ケチャップ? マヨネーズ? よくわからない。
とりあえず、とんかつソース + ケチャップ + マヨネーズ を適当にかけて食べた。
出汁の味とタコの味がして美味しかった。
なにもかけなくても、そこそこ美味しくできている。

食べた後で、撮影しておけばよかったと思い、冷蔵庫から出してきて、残りを撮影した。

やっぱり簡単にできるっていいよね。
関西の人は、ひとこと、ふたこと、あるだろうけど。

2021年12月30日木曜日

コンパクトフラッシュ(CF)のピン折れ防止カードリーダ

Compact Flash(以下、"CF"と省略)カードのスロットは、ピン折れの事故が多い。
スロットの遊びが大きく、ずれたり、斜めになったりしながら挿入され、一部のピンが引っかかり、曲がってしまうのだ。
この問題に対する最高の解決策は、CFカードを使わないということだ。

しかしながらどうしても使わなければならない人もいる。
この場合、できる限りまっすぐ挿入されるCFカードリーダを使うべきだ。
というわけで昔から、できるだけ深くしっかり挿さるカードリーダを使ってきた。

しばらく、CFカードを使う機会が無かったので、ずっとUSB 2.0のものを使い続けてきた。
しかし、最近になって、またCFカードを扱わなければならなくなってきた。
最近のCFカードは256GBのものもあり、昔と比べてかなり大容量化が進んだ。
大量のデータを扱うなら、高速なUSB 3.1のものを使うべきだろう。

データ転送速度はカタログに書かれている事も多いが、「ピン折れのしやすさ」はカタログには書かれない。
多少無駄だけど、いくつか良さそうなものを買って、比べてみることにした。
左端は、ELECOM MR-A006BK。以前から使っているUSB 2.0のもの。貼ってあるシールは無視して。
真ん中は、新たに買ったBUFFALO BSCR108U3。
右端は、サンワサプライの ADR-CFU3H。

ELECOMの新しいやつも書いたかったのだが、売り場に無かった。

それぞれのカードの入り具合を見るため、CFカードにマスキングテープを貼って、ボールペンで印を付けていこう。
それにしても、30MBっていつの時代のCFカードだよ。

まずは、BUFFALO。 CF以外にもいろいろなスロットがあるが、同時に使えるのは1つだけ。
CF専用として使うつもりなので、それでも良い。
パッケージのウラ面に、「コンパクトフラッシュのピン折れを防ぐ」と書かれている。

しかし、挿して見るとあまり深くない。
これは多くのカードリーダの中で、浅い部類になる。

次に、サンワサプライ。
蓋がついていてカッチョいいが、CF専用。
BUFFALOよりも深い。
上の写真では、もう一本線がひいてあるが、それはELECOMのものだ。
実は、先にELECOMの方を見ていたので、線が書いてある。

最後にELECOMの古いやつ。
一番深い。
これを買う時も、深いものを選んで買ったのだ。
そのためかなり深い。

新しいものはどれも、これより浅い。
なんだか残念な感じだが、深い事が全てではない。
遊びやガタつきが少なく、安定していることが大事だ。

挿しながら、安定感を見てみた。


なんと、一番浅い BUFFALO BSCR108U3 が一番良かった。
キチキチ過ぎる感じもするが、ピン折れを防止するなら、それくらいじゃないと。
前から使っているのよりも、いい感じがする。

安さや小ささにこだわり過ぎず、安全に使えるものを継続的に作って欲しい。

以下は、なぜいまさらCompactFlashを使っているのかを書いたもの。
わざわざ読まなくても良い。

もう25年ぐらい前、仕事でCFカードにデータを記録する地震観測装置を作った。

20世紀末、リムーバブルメディアといえば、Floppy Diskの独壇場であり、それ以外にはありえない感じだった。
(Floppy Diskに記録するデシカメもあったほどだ)
USB規格は発表されてはいたが、USB I/Fを持つPCがまだ存在していない時代だった。

そんな時、ノートPC用の拡張カードの規格、PCMCIAを小さくしたようなCFが誕生した。
デジカメの普及と共にCFもどんどん普及した。

Floppy Diskよりも容量が大きく、しかも可動部がない。
大量生産され、容量の割には値段も比較的安い(とはいえ、高かったけど)。
地震の記録にぴったりだったので、CFを使った地震観測装置を作った。

それから数年後、Windows98が出たことで、PCでもUSBが使えるようになった。
USB接続のCFカードリーダも様々なメーカから出荷され、デスクトップPCでもそれらリムーバブルメディアが使われるようになった。
千年王国とも思われていたFloppy Diskはみるみるうちに衰退していき、若者からは「なぜ、PCはC:ドライブから始まるんですか?」と質問されるまでになった(A:とB:はFloppy Diskで、昔はHDD(C:)は無かった)。

その頃から、CFで事故が起こるようになった。
USB接続のカードリーダは、価格競争や小型化のために、カードが部分的に入るスロットのものが多い。
そのため、雑に扱うと、カードが斜めに差し込まれ、ピンが折れ曲がるのだ。
昔のCFスロットは、かなりしっかりとした作りで、カード全体がすっぽりと入るようなものも多かった。
(取り出しのための、イジェクトボタンを持つものもあった)
そういう深いスロットなら、差し込まれていくうちに真っ直ぐになり、ピンが折れることは少ない。

自分で作った装置の動作確認のために、CFを読み書きする必要もある。
Flashメモリは寿命のある記録媒体なので、長年使っていれば壊れる。
お客さんから、壊れたメディアからのデータのサルベージを依頼されることもある。
サルベージ依頼したお客さんのCFを壊してしまうのは問題なので、私はできるだけしっかりとしたスロットのカードリーダを使ってきた。
多少遅くても、壊すよりはマシだ。

ピン折れを意識しない人は多い。
職場でも、安いカードリーダでCFを雑に扱い、ピンを曲げる事故が数年に一度発生している。
ピンが曲がるだけならカードにダメージはないが、曲げ伸ばしを何度もやっていると、金属疲労によりピンが破断し、カードの中に残ってしまうことがある。そうなるとピンはまず取り出せず、使えないカードになってしまう。

そんなこともあり、十数年前からは、装置にSDカードを使うようにしていた。
SDカードは、細いピンで接続するわけではないので、雑に扱っても簡単には壊れない。
もう扱うのにヒヤヒヤしないでいい。問題は解決されたかに思っていたが…。

次の装置もSDカード(SDXC)にしようと考えていたのだが、お客さんからの強い要望でCFカードにすることになった。
どうしても使いたくなかったのだが、営業は説得しきれなかったようだ。
悪夢の再来だ。
現場の人間、技官と技術者だけが、精神的な苦労をする。

というわけで、少しでも安全なCFカードリーダを探した。
この記事が、同じような苦労をする人の助けになれば幸いだ。

2021年11月7日日曜日

長靴+ブーツ干しハンガーを作ろう

先日書いたこの記事で紹介しているブーツ干しハンガーについて、もう少し書いておく。

ビバホームで買ったものを以下に示す。
名前個数単価
VPパイプ VP13x1M1188188
TS継手チーズ TS-T13(CS)14444
TS継手エルボ TS-L13(CS)23876
TS継手45エルボ TS-45L13278156
TS継手キャップ TS-C13 344132
合計596

消費税込みでも700円以下。

VPパイプは1mの長さのものだ。それで充分に足りる。
このパイプを以下の長さで切る。
長さ[単位mm]個数
1501
1304
502
塩ビパイプは、100円均一の安いノコギリでも簡単に切れる。

これで部品は揃った。
以下の図を参考に塩化ビニール用接着剤で貼り合わせる。
(寸法は、私の足の大きさに合わせている。子供や小柄な女性の場合、大きすぎるかもしれない。)
接着剤は、継手側とパイプ側にたっぷり塗ると、ヌルっとして入りやすくなる。
しかしながら、数秒でくっついてしまうので、挿す前に頭の中でシミュレーションしておくと良い。
本格的水道工事では無いので、接着剤が多すぎても気にするな。固定できれば良いのだ。

ブーツを干すハンガーを検索すると、1,000円以上、2,000円近いものも見つかる。
長靴を長時間履いていれば、洗いたくなる人もいるだろう。洗ったら干さないといけないが、これがなかなか乾かず、余計ひどいことになり、高価でも飛びついてしまうのかもしれない。

2重の意味で、足元を見られていると言える。

しかし、この塩ビパイプのブーツハンガーは安く、何よりカスタマイズ可能だ。
私のような標準サイズではない体を持つ人々には、最高のソリューションと言える。

実はすでに、フックを付ける改造をしている。
ダイソーで、以下の「ハンガーフック」を買ってきて、それを加工して無理やり自家製ブーツ干しハンガーに付けた。 (この記事の動画では針金を使っているけど)
それについても書く予定。
つづく

2021年11月6日土曜日

マリンブーツは乾きにくい

マリンブーツを干すための治具を作った。

ダイビングをするとき、様々な機器(「ダイビング・ギア」とも呼ばれる)を使う。
呼吸のため、浮力を補償するするため、体を保護するため等の機器だ。

水の熱伝導率は、空気よりも20倍も高い。
体温を奪われると、体力が消耗する(すごく痩せるし、すごく眠くなる)。
体温を失わないように、保温性の高い素材が使われており、さらにウエットスーツといえども、スーツ内と外の水がなるべく入れ替わらないようになっている。

マリンブーツも、ウエットスーツのような素材でできており(厚さは違う)、水が入れ替わらない。
ネオプレーンゴムを接着剤で貼り合わせて作られており、水は通らない。しかしながら、表面にジャージ生地が貼られている。
ジャージ生地は水を蓄えるため、洗ったあとでも表面に水を保持する。
足首まですっぽりと包む構造のため、生地の面積は普通の靴より多い。

そして、芯のネオプレーンゴムは水を通さないため、靴の内部に溜まった水が染み出す事は基本的に無い。
この状態で、靴を壁に立てかけて干そうとしても、かかとに水が溜まってなかなか乾かない。

普通の靴と違って保温性も高いため、直射日光が当たっても中まで熱が伝わらず、水が気化しにくいのだ。
保温性は重要な特性なので、これを失うわけにはいかない。
特に冬は乾きにくい。いつまでもギアを片付けることができず、散らかったまま過ごすことになる。

この問題に対処するため、色々手を尽くしてきた。
言葉で説明するのは、難しいので以下にイラストを書いた。
最後の1つは、大瀬崎のダイビングショップ「COCOMO」さんの干場にあったものを真似たものだ。
これが、今回作成した治具の元になっている。

ビバホームの塩ビパイプ売り場で、部品を買ってきて作った。全部で¥700以下だった。
接着剤は、この記事で使ったものを用いた。
パイプはギチギチで入れにくいが、接着剤をたっぷり塗ると、ヌルヌル感で入りやすくなる。
塩化ビニールなので、濡れても錆びたり、腐ったりすることは無い。
ブーツをさげるだけなら、充分に強い。

物干し竿にかけやすくするため、アルミの針金でS字フックをかける輪っかを付けた。
これで、乾きやすくなるだろう。

2021年7月17日土曜日

VirtualboxでUSBが接続できないとき

今年の1月の緊急事態宣言のとき、去年買ったPCのVirtalBox上にWindows10をインストールして仕事用の環境を構築した。

VirtualBox内のWindows10で、以前から使っているARM用JTAG"J-link"は動くが、最新のIARの"I-Jet"は動かなかった。
通常動作時に頻繁にマイコンの電源が切れる装置の開発をしているため、最終製品段階でJTAGはほぼ使えないので、JTAGを使った開発はサブルーチン単位の動作確認になる。この場合、JTAGに高速性はほぼ必要ないので"J-link"で充分だ(どうしてもI-Jetが必要と感じたことはない)。
そのため、"J-link"を使って開発していた(更に昔からOpenOCDで使っているブルガリアのやつでも速度的にはいいのだが、マイコン電源電圧が合わない)。
何故"I-Jet"は動かないんだろう?と思いながらも、困らないので放置していた。

Windowsで記録メディアを読みたいときもある。
USBカードリーダをVirtualBoxにつなごうとすると、エラーになってつながらなかった。
この場合も、\\vboxsrv\xxxxを使って誤魔化していたので、問題にならなかった。
「Windowsゲストでは、ダメなデバイスがあるんだな」みたいに考えて、調べもしなかった。

ところが Ubuntu Budgie 20.04 ゲストでもカードリーダが認識できなかった。
それどころかUSB BOM(Bulk Only Mass strage)デバイス、すなわちUSBメモリも認識できない。

これはなにかおかしい。調べはじめた。

色々見ていくと、USB1.1のデバイスはつながる。
しかし、USB2.0やUSB3.0デバイスはつながらない、という事がわかった。

考えてみれば、VirtualBoxのUSBコントローラはUSB1.1をエミュレーションしている。
USB2.0やUSB3.0を使うには「VirtualBox Extention Pack」をインストールする必要がある。

使用しているVirtualBoxのバージョンに合ったExtention Packが必要だ。
私は、OraclのVirtualBoxのダウンロードページから得た6.1系のVirtualboxを使っているので、そのExtention Packが必要になる。
ダウンロードページの先頭付近の少し下、VirtualBox 6.1.22 Oracle VM VirtualBox Extention Packと書かれたところにある"All supported platforms"と書かれたリンクをクリックする。
これをクリックすると、Virtualboxが立ち上がってきて、Extention Packのインストール確認のメッセージが表示される。
使用許諾その他の質問に適切に答えてインストールを行う。

Extention Packインストール後に、仮想マシンのUSB設定の画面を表示すると(仮想マシンは停止している状態)、USB2.0とUSB3.0が現れる。
USB3.0を選択して、仮想マシン(この場合はWindows10)を動かせば、つながらなかったUSBデバイスがつながるようになる。

解ってしまえば、簡単な事だ。

2021年6月19日土曜日

Ubuntu18.04 で動画にモザイクをかける

誰もが何気なくスマホで動画を撮影する。
スマホ(携帯やガラケーも含めて)にカメラが付くようになったのは、auが最初だったと記憶している。
(あの頃のauは、なんかワクワクした)
今では、カメラが無かったなんて信じられないくらい、当たり前になっている。

人が多いところで動画を撮影すると、後ろに人が写り込んでしまう。
個人で鑑賞するぶんには問題ないが、それを公開するのは個人情報の保護の観点から注意するべきだろう。

というわけで、TVの映像のようにモザイクをかけたい。
Ubuntu 18.04(未だにBionicかよ!)でも、動画編集アプリshotcutを使って動画にモザイクをかけることができる。
たとえば、このブログの「武蔵浦和西口駅前K's電気跡地の再開発工事#2」などでそのようにしている。
その方法を説明する。

ちなみに、ここで紹介している方法の多くはfocal(20.04)でも使えるだろう。
ShotCutを入手する

Ubuntu 18.04 では、snapを使って入手する。
ソースからのビルドも試みたが、難しかったので諦めた。
focalでは、apt-getでも入手できるようだ(このBudgie 20.04で確認)。
ただし、apt-getで入手できるのは、現時点では少し古いようだった。これは時間経過と共に徐々に変化していくだろう。

snapでshotcutをインストールするには以下のようにする。
$ snap install shotcut
これでshotcutが使えるようになった。

モザイク適用の概要

モザイクの適用は、「モザイク」フィルタにより行う。
動画に単純にモザイクを適用すると、動画全体に、時間的にも画面領域的にも全体にモザイクがかかってしまう。
そのため、モザイクの適用範囲を制限しなければならない。
  • 時間的には、タイムライン上で動画を分割する。

  • 画面領域的には「切り抜き」フィルタを使う。

切り抜きフィルタを使うと新たな問題が生じる。
動画が一部だけになり、他の部分が表示されない。
これに対処するために、動画をコピーしておいて、元の画像の上に切り抜いたモザイク画像を重ねるようにする。

「なんだ簡単じゃん。」と思っても、言うは易し、行うは難し。
例として、「Kalitaコーヒーミルを電動工具で駆動する方法」で使った動画の1/4"のナットを、モザイクにしてみよう。
以下で説明していく。

ブロジェクトを作る

shotcutで動画を編集するには、プロジェクトを作って行う。
こだわり度にもよるが、やり直すかもしれないし、使ったフィルタ等の設定を後から見直すかもしれない。
とにかくプロジェクトを作ろう。
shotcutを起動すると、以下のような画面が表示される。
起動時、画面の中心のペインが「新規プロジェクト」になっている。
「プロジェクトのフォルダ」で、プロジェクトフォルダを作るダイアログが表示される。そこで、フォルダを作る。すでにフォルダがあるなら、それを選択する。
「プロジェクト名」を"CoffeeMill_mosaic"とした。
その下の「開始」ボタンをクリックすれば、プロジェクトでの作業が始まる。


元動画ファイルを開く

画面左上の「ファイルを開く(O)」をクリックする。
ファイルダイアログが表示されるので、元の動画を開く。
上記例では、"CoffeeMill2.mp4"を選んでいる。
ファイルを選択して、「開く」をクリックする。

以下のように、中央のペインで動画の再生が勝手に始まる。
動画の下の「||」ボタンで止める。


タイムラインに動画の一部を取り込む

中央のペインで、取り込む動画の範囲を調整する。
動画の下のバーの両端の「▶|」と「|◀」 を調整して範囲を決める。
調整したら、下の方にある大きな「+」記号をクリックして、取り込む。
下の「タイムライン」に動画が取り込まれる。


トラックをコピーする

概要で述べたように、モザイク処理は、元の動画にモザイク化した画像の一部を重ねることで行う。
そのため、まず同じ動画のコピーを作成する。
トラックの左端のカラムを右クリックするとポップアップが現れる。
「トラックの操作」→「映像トラックを追加」をクリックする。
新たな空っぽのトラック「V2」が作られる。

トラック「V1」の動画部分をクリックして、選択されている状態(細い赤枠で縁取り表示される)にする。
この状態で右クリックして「コピー」を選ぶ。

次に先程追加した「V2」の何もないところをクリックする。 この状態で、中央の動画の「|◀」ボタンをクリックし、「再生ヘッド」を先頭に戻しておく。
メニューから、「編集」→「貼り付け」を選ぶ。
これでV2にコーピーが入る。
トラックの表示をみてもピッタリあっている。

うっかり、再生ヘッドを先頭にせずに「貼り付け」をすると、ずれた位置に貼り付けられてしまう。
この場合、動画をクリック&ドラックして前にもってくればいい。

説明が妙に長いが、やっていることはトラックのコピーだ
それを意識してやれば、そんなに難しいことでもない。


V2の音声をミュート

このままでは音声まで2重に入る。
不要なので、ミュートする。
V2のスピーカー アイコンをクリックする。


モザイクをかける時間範囲を切る

V2上で再生ヘッドを移動させながら、モザイクの範囲の最初と最後で、分割する。
以下は、モザイクの開始部分で分割をしているところ。
1/4"ナットが現れる先頭に再生ヘッドを移動して、「再生ヘッドで分割」ボタンをクリックすると、上記のようになる。

それ以外の部分は残しておいてもいいが、削除してしまっても良い。
私は削除している。


モザイクの画像範囲を切り抜く


画像の一部を切り抜くには、「切り抜き」フィルターを使う。
画面左側のペインのフィルタタブをクリックして、「フィルター」を表示させる。
その後、上記「+」をクリックするとフィルタの追加になる。

上の「映像」ボタンをクリックして、その下の一覧から、「切り抜き:四角形」をクリックする。
これで切り抜きができる。

フィルタをかける動画の先頭を表示させると、中央の動画表示に白い四角い枠が表示される。
この四角い枠は、四隅の白い部分をクリック&ドラッグすると範囲を調整できる。
調整して、ナットをつまむ指だけにした状態。
下のタイムラインもよく見てほしい。この操作は動画の先頭で行っている
以降、ナットの移動に合わせて、モザイクの範囲をずらしていく。

また、切り抜き範囲外が真っ黒になっている。
これは「内部余白の色」が黒になっているためだ。
以下のように、切り抜きフィルタの「内部余白の色」の「透明」ボタンをクリックする。
これで、V1の画像が透けて見える。


モザイクをかける

モザイクフィルタを追加する。
まず、再度フィルタの「+」ボタンを押す。

今度は「映像」「モザイク」とクリックする。
「切り抜き:四角形」フィルタに加えて、「モザイク」フィルタも適用される。


ナットを追跡する

動画の中のナットは動いているが、モザイクの範囲は動いていない。
そのため、このままではナットが見えてしまう。
時間と共にモザイクの範囲を動かすには、キーフレームの機能を使う
「切り抜き:四角形」フィルタを選択し直し、「位置」と「サイズ」の右にある「ストップウオッチ」アイコンをクリックする。
これで、キーフレームの設定モードになる。

動画を少し進めてナットが切り抜きの範囲からはみ出たら、動画の白枠内の中心にある「●」をドラッグして、ナットにかぶせるようにする。

途中はリニア補間されるので、飛び飛びの位置を指定していけばいい。
設定できたら、再生してモザイクが正しくかかっていることを確認しよう。

この再生処理は重い。
2重に動画を読むし、加工もしているのだ。Full-Spec Hi-Vision動画の場合、このFolio13はギリギリだ。
簡易表示は実際の動画と違うかもしれないので、何度か確認したほうが良い。


モザイク入り動画を生成する

ここまでくれば、shotcutで動画編集をしたことのある人なら、誰でも解るだろう。
左のペインで、「書き出し」タブをクリックし、「ファイルの書き出し」ボタンをクリックする。
ファイルダイアログが表示されるので、適切に名前を入力して、「保存」ボタンをクリックすると、動画の生成が始まる。
右端のジョブの表示のアイコンが緑のチェックマークになったら、動画が完成している。


出来上がった動画がこんな感じ。

元の動画(全体)は、こんな感じ。


Ubuntu18.04で説明したが、Ubuntu20.04でも大した違いはないだろう。
ついでに、shotcutはWindowsでも使えるマルチプラットホームアプリだ(そのせいでビルドが面倒くさい)。
基本が解れば、どのプラットホームでも使えると思う。

簡単な内容だと思って書き始めて、大作になっちゃったな。なんでこうなっちゃうんだろう?
なるべく簡単に書こうとして、あえて細かい部分を省略した。それらを箇条書きで示す。
  • フィルタは数が多いので、目的のフィルタを選ぶのが大変だ。その時のために「お気に入り」機能がある。
  • 切り抜きフィルタは、位置だけではなくサイズ(っていうか形)を変えることもできる。
  • 切り抜きには「切り抜き:四角形」以外もある。
  • キーフレームの修正や削除もできる。
  • キーボードショートカットを覚えれば、作業効率が上がる。

細かな部分については、試しに色々やって、体で覚えるのが良い。
Hi-Vision動画は情報量が多く扱いにくい。この10年選手では、できなくはないが、色々きつい。
5年くらい前のPCなら、M.2スロットがある。Core -i7等を使ったフラグシップ機ならM.2 SSDとの組み合わせて、使いやすい環境を作ることができる(電源がダメになっていなければ)。

履歴:
2021/06/20 全体的に見直した。簡単な事でも文書で書くのは難しい。文才がある人がうらやましい。

2021年6月6日日曜日

RaspberryPi3 Ubuntu 20.04 で EPSON EW-M752T スキャナドライバ

しばらくRaspberryPI3をほったらかしにしていた。
久しぶりに起動して、apt-get update して、apt-get upgrade した。
ついでに、自宅のプリンタ複合機 EW-M725Tのスキャナドライバも更新した。

EPSONのドライバページでは、Ubuntu armhf用のバイナリパッケージを提供していないので、ソースパッケージからビルドする必要がある。
さらに以前ビルドした時、RaspberryPI3でセルフビルドできなかった。
同時に起動されるJOB数が多すぎて、メモリ不足になるのだ。swapを2GBぐらいにしてもダメだった(スラッシングになってもビルドできるなら待ったのだが、どうにもダメだった)。

結局、ビルドのためにchrootとqemu-user-staticを使った仮想環境でビルドした。
今回も、同じようにPC上に仮想環境を用意してビルドした。
今年のはじめに母艦のストレージをM.2 SSDに載せ替えていたので、以前作った環境は無くなっており、作り直した。
それらを順番に説明していく。

簡単に説明すると、chrootはルートディレクトリを変えて別のファイルツリー環境(chroot監獄)に封じ込めるのに使う。
USB bootable Ubuntu を作って遊んでいた頃に、squashfs圧縮イメージの環境を更新する時に使っていた。

qemu-user-staticは、qemuを使ったユーザ環境のエミュレーションで、システムコールをネイティブのものに置き換えて実行する。
つまり、armhf用のバイナリをamd64上で実行したとき、armhfのシステムコールをamd64カーネルのシステムコールに置き換えて呼び出す。
そのためユーザ空間のみのエミュレーションであり、カーネルやハードウエアのエミュレーションをしないので、性能が落ちにくい。

とても便利なのだが、これらを自力で組み合わせてエミュレーション環境を作るのは、ナニゲにしんどい。
(以前は自力でコツコツやっていた)
しかし、debootstrapとschrootを使うととても簡単にできる。
以下のページでそのやり方が紹介されている。
Introduction to qemu-debootstrap
このページでは、arm64 の xenial の環境を作っているが、私はRaspberryPI3 なので、armhf になり、Ubuntu 20.04 なので、focalになる。
それらを読み直して、実行する必要がある。
例えば、armhf-focalの作成は、
$ sudo qemu-debootstrap --arch=armhf focal armhf-ubuntu
schrootコンフィグレーションの作成は、
$ echo "[armhf-ubuntu]
description=Ubuntu 20.04 Focal (armhf)
directory=$(pwd)/armhf-ubuntu
root-users=$(whoami)
users=$(whoami)
type=directory" | sudo tee /etc/schroot/chroot.d/armhf-ubuntu
上記は例だ。元のページをよく読んで、作業をせよ。
インストールには、ネットワーク接続が必要だ。さらに時間もかかる。

しばらく待つと、armhf focalの環境ができるので、その中に入って作業をする。
$ schroot -c armhf-ubuntu
(armhf-ubuntu)xxx@yyy:$
上記のxxxはユーザ名、yyyはホスト名。
プロンプトの先頭が"(armhf-ubuntu)"になっていれば、エミュレーション環境に入っている。
試しに'uname -m'を実行してみると、
(armhf-ubuntu)xxx@yyy:$ uname -m
armv7l
chroot監獄内の環境だが、ホームディレクトリなどは、ホストと同じものがマウントされている。
便利といえば便利だが、ホスト環境を壊す可能性もあり、注意が必要だ。

armhf実行環境が作れたら、ビルドツールその他必要なものをインストールしなければならないのだが、必要なパッケージの一部がmainリポジトリ内にないので、リポジトリ設定を書き換える必要がある。
やり方はどうでも良いが、/etc/apt/sources.listを以下のような内容に書き換える。
deb http://ports.ubuntu.com/ubuntu-ports focal main restricted universe multiverse
書き換えたら、apt-get updateをしておく。

そうしておいて、必要なパッケージをインストールする。
$ sudo -S apt-get install build-essential devscripts wget debhelper pkg-config liibltdl-dev libudev-dev libusb-1.0-0-dev libgtkmm-2.4-dev libsane-dev libjpeg-dev libtiff-dev graphicsmagick libgraphicsmagick++-dev libboost-filesystem-dev libbooost-iostreams-dev libboost-program-options-dev libboost-regex-dev libboost-test--dev libboost-thread-dev
上記は、build-essential devscript wget と、EPSON EW-M752T用スキャナドライバのソースパッケージが必要とするパッケージを全部指定している。

ビルドに必要なものは用意できた。次にソースパッケージを入手する。
EPSONのドライバダウンロードページに行って、"EW-M752T"を入力、OSに"Linux"を選んで、虫眼鏡アイコンをクリックすると、以下のようなページになる。
一番下の行「EW-M752T Scanner Driver Linux 3.65.0 All-in-one package All language 01-05-2021」の[Download]ボタンをクリックする。
以下のようなページになる。
ここで、[Accept]ボタンをクリックする。
ページが下に延長されて、以下のようになる。
一番下の、"Source File Download Page"をクリックすると、以下のようなページになる。
ここで"Ubuntu"をクリックする。
やっと、ソースパッケージが現れた(なんと説明が面倒なのだろう)。
この中で、以下の3つをダウンロードする。
さっき、armhf-ubuntu環境にもwgetをインストールしておいたので、それでダウンロードすればいい。
適当なディレクトリを作って、そこに3つのファイルをダウンロードせよ。

ダウンロード後、早速ビルドしたい所だが、このままではfakerootでエラーになる。
以下のようにして、fakerootをfakeroot-tcpにする。
$ cd /etc/alternatives

$ sudo rm fakeroot

$ sudo ln -s /usr/bin/fakeroot-tcp fakeroot

やっと、ビルドするための準備が全て整った。
3つのファイルをダウンロードしたディレクトリへ移動して、以下のようにして、ソースパッケージを展開せよ。
$ dpkg-source -x imagescan_3.65.0-1epson4ubuntu20.04.dsc
ふつうのやり方だ。サブディレクトリ"imagescan-3.65.0/"ができているので、その中に入って、バイナリパッケージをビルドする。
$ dpkg-buildpackage -us -uc -b
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
	LANGUAGE = (unset),
	LC_ALL = (unset),
	LANG = "ja_JP.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
qemu: Unsupported syscall: 403
dpkg-buildpackage: warning:     debian/changelog(l7): badly formatted trailer line
LINE:  -- Seiko Epson <linux-printer@epson.jp>  Thu, 22 Dec 2020 11:01: +0900
dpkg-buildpackage: warning:     debian/changelog(l7): found end of file where expected more change data or trailer
dpkg-buildpackage: info: source package imagescan
dpkg-buildpackage: info: source version 3.65.0-1epson4ubuntu20.04
dpkg-buildpackage: info: source distribution RELEASED
dpkg-buildpackage: info: source changed by 
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
	LANGUAGE = (unset),
	LC_ALL = (unset),
 :
 : (省略)
 :
dpkg-genchanges: info: binary-only upload (no source code included)
 dpkg-source --after-build .
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
	LANGUAGE = (unset),
	LC_ALL = (unset),
	LANG = "ja_JP.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
qemu: Unsupported syscall: 403
dpkg-source: warning: imagescan-3.65.0/debian/changelog(l7): badly formatted trailer line
LINE:  -- Seiko Epson <linux-printer@epson.jp>  Thu, 22 Dec 2020 11:01: +0900
dpkg-source: warning: imagescan-3.65.0/debian/changelog(l7): found end of file where expected more change data or trailer
dpkg-buildpackage: info: binary-only upload (no source included)
$
およそ6年前のcore-i7だからか、なんだかんだ時間がかかる。
1つ上のディレクトリに戻ってみると、バイナリパッケージができている。
$ ls
imagescan-3.65.0
imagescan-dbg_3.65.0-1epson4ubuntu20.04_armhf.deb
imagescan_3.65.0-1epson4ubuntu20.04.debian.tar.xz
imagescan_3.65.0-1epson4ubuntu20.04.dsc
imagescan_3.65.0-1epson4ubuntu20.04_armhf.buildinfo
imagescan_3.65.0-1epson4ubuntu20.04_armhf.changes
imagescan_3.65.0-1epson4ubuntu20.04_armhf.deb
imagescan_3.65.0.orig.tar.gz
上記ファイルのうち、2つの.debファイルをRaspberryPI3(Ubuntu20.04が動いている)にコピーして、dpkg -i でインストールする。
なんか依存物があったようにも思うが、最初にインストールした時に足りないものはインストールしていて、もうエラーにならない。

PCの場合と同様に、/etc/imagescan/imagescan.confを適切に書き換える。
# /etc/imagescan/imagescan.conf -- Image Scan configuration
# Refer to the documentation for details on the configuration options
# for the software.  Plugins should come with their own documentation
# if they have configuration options.
#
# Lines starting with a # or a ; are comments.  Comments must be on a
# line of their own.  End-of-line comments are not supported.

[devices]

myscanner.udi    = esci:networkscan://XXX.XXX.XXX.XXX:1865
myscanner.vendor = EPSON
myscanner.model  = EW-M752T
XXX.XXX.XXX.XXXは、プリンタのIPアドレス。適切に置き換えよ。
うちでは、プリンタを固定IP(ルータで固定IP化している)で運用しているので、これだけでいい。

imagescanを実行すると、見慣れたイメージスキャンアプリが立ち上がる。使い方はもちろんPCと同じだ。
RaspberryPIでも、スキャンができる。
便利になったもんだ。

なるべくわかりやすく、短く書くつもりが、妙に長くなった。

2021年5月8日土曜日

Ubuntu 18.04 で nbdkit

「いまさら18.04かよ!」って、思う人も多いだろう。
OSの入れ替えはなるべくやりたくないので、ギリギリまで使い続ける。

zestiyでもdiscoでも nbdkitはオフィシャルのパッケージがあるのに、bionicだけは無いのだ。
そのため、nbdkitを手っ取り早く、簡単に使いたいなら、今ならbionic(18.04)ではなく、focal(20.04)を使うのが良い

私は、12.04のサポート終了後、1年ぐらい16.04を使ったが、すぐに18.04に移った。
Precise(12.04)のころも nbdkitのオフィシャルパッケージが無く、ソースを入手して、ビルドして使っていた。 そのためnbdkitは自分でビルドすると、私は自然に考えていたので、18.04に移行した後もすぐに自分でビルドした。
(うっかりこのBudgieでも、最初は自分でビルドしてしまっていた)

もう一度いうが、nbdkitを簡単に使いたいなら、自分でbionic(18.04)でビルドせずに、focal(20.04)に移行するのがいい。
focalもだいぶ安定してきているだろうから。

bionicを使い続けなければならない人もいるだろうし、私のような馬鹿野郎も少なからずいるだろう。
今年の3月に、M.2 SSDに移行&インストールし直したこのPC用にもビルドし直したので、ついでにメモを書いておく。

最後にビルドしたのはもう1ヶ月以上前なので細かいことは忘れている。
何か足りないものもあるかもしれない。面倒なことになるかもしれない。それが嫌ならfocalに移行せよ。

まずは、ビルドに必要なものをインストールする。
gitやbuild-essential等の最低限のツール類は入っているものとする。

いきなりビルドに必要なものと言われても、さっぱりわからない。
後でgit cloneするが、その中のreadmeを読んでも必要なものの雰囲気ぐらいしか解らない。
そもそもnbdはどっちかっていうとRedHat系が中心で、Debian系ではない。そのためDebian系のパッケージで何を用意すれば良いのかがよくわからないのだ。
しかし、今ならお手本がある。focalのBuild-Dependsを見れば良いのだ。
ソースパッケージの一部である.dscファイルを入手して、その中の "Build-Depends:"にかかれているパッケージをinstallすればいい。
実際には、bionicには存在しないものなども含まれていたりして調整も必要だが、大変参考になる。
まずは、.dscファイルをダウンロードしておこう。
wget http://archive.ubuntu.com/ubuntu/pool/universe/n/nbdkit/nbdkit_1.16.2-1ubuntu3.dsc
以下のようにすると、Build-Dependsのパッケージがわかる。
$ cat nbdkit_1.16.2-1ubuntu3.dsc | grep '^Build-Depends:' | sed -e 's/^Build-Depends: \+//g' | sed -e 's/, \+/\n/g'
debhelper (>= 12)
dh-python
perl
pkg-config
bash-completion
genisoimage
comerr-dev
libcurl4-gnutls-dev | libcurl-dev
libext2fs-dev
libgnutls28-dev (>= 3.3)
gnutls-bin
libguestfs-dev (>= 1:1.36.11-3)
liblzma-dev
liblua5.3-dev
libperl-dev
python3-dev
ruby
ruby-dev
tcl-dev
libselinux1-dev
libssh-dev
libvirt-dev
zlib1g-dev
busybox <!nocheck>
iproute2 <!nocheck>
jq <!nocheck>
socat <!nocheck>
libguestfs-tools <!nocheck>
libnbd-dev
python3-libnbd <!nocheck>
このうち、<!nocheck> はテストで必要としているものだ。
テストは重要ではあるが、解決が難しくなるかもしれないので、とりあえず除去しておく(「まずはビルド」を優先する)。
また、バージョン番号も邪魔だし、libcurlは2つ(libcurl4-gnutls-dev か libcurl-dev)のうちどちらかが入っていればいい。
さらに、libnbd-devはbionicには存在しないので、除外する。

これらを整理するには、以下のようにする。
$ cat nbdkit_1.16.2-1ubuntu3.dsc | grep '^Build-Depends:' | sed -e 's/^Build-Depends: \+//g' | sed -e 's/, \+/\n/g' | grep -v -e '<!nocheck>' -e 'libcurl-dev' | sed -e 's/ \+([^)].\+) *$//g'
debhelper
dh-python
perl
pkg-config
bash-completion
genisoimage
comerr-dev
libext2fs-dev
libgnutls28-dev
gnutls-bin
libguestfs-dev
liblzma-dev
liblua5.3-dev
libperl-dev
python3-dev
ruby
ruby-dev
tcl-dev
libselinux1-dev
libssh-dev
libvirt-dev
zlib1g-dev
libnbd-dev
これらのうちまだinstallされていないものをinstallする。
以下のようにして、installされていないパッケージ(すでにインストールされているパッケージ)を確認する。
$ dpkg -l $(cat nbdkit_1.16.2-1ubuntu3.dsc | grep '^Build-Depends:' | sed -e 's/^Build-Depends: \+//g' | sed -e 's/, \+/\n/g' | grep -v -e '<!nocheck>' -e 'libcurl-dev' -e 'libnbd-dev'| sed -e 's/ \+([^)].\+) *$//g')
18.04を今まで使い続けていたのなら、すでにいろいろなパッケージが入っているだろう。
何が足りないかは人それぞれだ。
表示された内容のうち足りないものを、"sudo apt-get install"の後ろにコピペしてinstallしよう。

次にソースを入手する。
以前はtar.gzを使っていたが、gitで入手すれば更新も簡単なのでgitで入手しよう。
リポジトリはhttps://github.com/libguestfs/nbdkit にある。
git clone https://github.com/libguestfs/nbdkit
cloneしたら、nbdkitに移動して作業する。

gitで入手した場合、最初に"autoreconf -i"を行わなければならない。
$ cd nbdkit
$ autoreconf -i
(なんか色々表示される)
次に"./configure"を実行するのだが、なんかオプションを付けた記憶がある。
config.logを見直してみたら、ウチの場合は以下のようになっていた。
$ ./configure --no-create --no-recursion
"git pull"で更新して、改めて上記configure後にmakeを実行してみるとエラーになった。
make[3]: ディレクトリ '/home/shin/dvlp/nbdkit/nbdkit/plugins/ssh' に入ります
/bin/bash ../../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I../..  -I../../include -I../../common/include -I../../common/utils      -g -O2 -MT nbdkit_ssh_plugin_la-ssh.lo -MD -MP -MF .deps/nbdkit_ssh_plugin_la-ssh.Tpo -c -o nbdkit_ssh_plugin_la-ssh.lo `test -f 'ssh.c' || echo './'`ssh.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../.. -I../../include -I../../common/include -I../../common/utils -g -O2 -MT nbdkit_ssh_plugin_la-ssh.lo -MD -MP -MF .deps/nbdkit_ssh_plugin_la-ssh.Tpo -c ssh.c  -fPIC -DPIC -o .libs/nbdkit_ssh_plugin_la-ssh.o
ssh.c: In function ‘do_verify_remote_host’:
ssh.c:220:26: error: storage size of ‘state’ isn’t known
   enum ssh_known_hosts_e state;
                          ^~~~~
ssh.c:240:11: warning: implicit declaration of function ‘ssh_session_is_known_server’ [-Wimplicit-function-declaration]
   state = ssh_session_is_known_server (h->session);
           ^~~~~~~~~~~~~~~~~~~~~~~~~~~
ssh.c:242:8: error: SSH_KNOWN_HOSTS_OK’ undeclared (first use in this function); did you mean ‘SSH_OPTIONS_HOSTKEYS’?
   case SSH_KNOWN_HOSTS_OK:
        ^~~~~~~~~~~~~~~~~~
        SSH_OPTIONS_HOSTKEYS
ssh.c:242:8: note: each undeclared identifier is reported only once for each function it appears in
ssh.c:246:8: error: SSH_KNOWN_HOSTS_CHANGED’ undeclared (first use in this function); did you mean ‘SSH_KNOWN_HOSTS_OK’?
   case SSH_KNOWN_HOSTS_CHANGED:
        ^~~~~~~~~~~~~~~~~~~~~~~
        SSH_KNOWN_HOSTS_OK
ssh.c:251:8: error: SSH_KNOWN_HOSTS_OTHER’ undeclared (first use in this function); did you mean ‘SSH_KNOWN_HOSTS_OK’?
   case SSH_KNOWN_HOSTS_OTHER:
        ^~~~~~~~~~~~~~~~~~~~~
        SSH_KNOWN_HOSTS_OK
ssh.c:257:8: error: SSH_KNOWN_HOSTS_NOT_FOUND’ undeclared (first use in this function); did you mean ‘SSH_KNOWN_HOSTS_OTHER’?
   case SSH_KNOWN_HOSTS_NOT_FOUND:
        ^~~~~~~~~~~~~~~~~~~~~~~~~
        SSH_KNOWN_HOSTS_OTHER
ssh.c:265:8: error: SSH_KNOWN_HOSTS_UNKNOWN’ undeclared (first use in this function); did you mean ‘SSH_KNOWN_HOSTS_CHANGED’?
   case SSH_KNOWN_HOSTS_UNKNOWN:
        ^~~~~~~~~~~~~~~~~~~~~~~
        SSH_KNOWN_HOSTS_CHANGED
ssh.c:271:8: error: SSH_KNOWN_HOSTS_ERROR’ undeclared (first use in this function); did you mean ‘SSH_KNOWN_HOSTS_OTHER’?
   case SSH_KNOWN_HOSTS_ERROR:
        ^~~~~~~~~~~~~~~~~~~~~
        SSH_KNOWN_HOSTS_OTHER
ssh.c: In function ‘ssh_open’:
ssh.c:388:32: error: SSH_OPTIONS_NODELAY’ undeclared (first use in this function); did you mean ‘SSH_OPTIONS_HOSTKEYS’?
   ssh_options_set (h->session, SSH_OPTIONS_NODELAY, &set);
                                ^~~~~~~~~~~~~~~~~~~
                                SSH_OPTIONS_HOSTKEYS
Makefile:639: recipe for target 'nbdkit_ssh_plugin_la-ssh.lo' failed
make[3]: *** [nbdkit_ssh_plugin_la-ssh.lo] Error 1
make[3]: ディレクトリ '/home/shin/dvlp/nbdkit/nbdkit/plugins/ssh' から出ます
Makefile:520: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: ディレクトリ '/home/shin/dvlp/nbdkit/nbdkit/plugins' から出ます
Makefile:708: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: ディレクトリ '/home/shin/dvlp/nbdkit/nbdkit' から出ます
Makefile:578: recipe for target 'all' failed
make: *** [all] Error 2
sshプラグインのビルド時にエラーになっているようだ。
nbdkitが新しくなりすぎたな?
私は、xzイメージのマウントがしたいだけなので、sshプラグインは必要ない。
使わないものは除外してしまおう。"./configure --help"で除外方法が解る。

結果的にconfigureの方法は、以下のようになった。
$ ./configure --no-create --no-recursion --without-ssh 
 : (色々表示される)
$ make
 : (色々表示される)
ビルドできたら、インストールする。
$ sudo make install
 : (色々表示される)
新しくなって(少なくともVersion 1.15.1では)、使い方も少し変わってしまった。
xz圧縮されたイメージをnbdで提供するには、元々はこんな感じだった。
sudo nbdkit -n -e <export_name> -u <user> -g <group> -i <ipaddr> xz file=<xz-filename>
新しいものでは、たとえば、以下のようになる。
sudo nbdkit -n -e <export_name> -u <user> -g <group> -i <ipaddr> --filter=xz file <xz-filename>

ビルドを通すためにsshプラグインを除外してしまったが、前のバージョンや別のブランチをcheckoutして試すのも良いかもしれない。
(私は使わないので、そこまではやらない)

git pullで更新も比較的簡単にできる。
しかし、上記のように時々ビルドできなくなることもある。
自分でソースコードを入手してビルドする行為は、自由がある反面、荒野を彷徨うようなものだ。

その覚悟が無いなら、やはりfocalに移行してnbdkitを使うのが良いだろう。

関連記事:
圧縮イメージをマウントする
Lubuntu 16.04でxz圧縮イメージをマウントする