秋葉原で安く拾ってきたWindowsタブレット(おそらく何かの教育用途の放出品)にLMDEを入れて使っている。冷却ファンがないので埃っぽい自室でも安心して使えるのと、音声出力がそれなりにあるのでもっぱらラジオとして使っている。
問題はOSをLinuxにしたことで(なお、このタブレットを買った時にインストールされていたのはWindows8.1だった)数少ないボタンのうち電源ボタンしか認識しなくなった事。おかげで音量を少し変えるにもスクリーンにタッチしなくてはならず、手抜きでタッチ向けのウィジェットを書かないでデスクトップのそれを流用している事から扱いにくいことこの上ないのですね。自分が悪いんだけどさ。
マルチメディアキーを繋いでやれば何とかなるか、と思っていたのですがいろいろあって手を付けずにいました。
で、ようやく作り始めたのですね。
当初、RaspiPICOを使おうと思っていたのですがやろうとする事の割に高性能すぎてもったいなくなって、手元に余っていたUSBマイコン、LPC11U35(401)を使うことにしました。だいぶ以前に秋月の店頭で買ったものです。mbed readyなボードで、当時は「なんて便利なんだろう」と感動したもんですが、しかし時は流れ、今では後発でより高機能なPICO(RP2040)のほうが少し安く買えるようになってしまいました。
消費電力の点ではまだアドバンテージがあると思いますが、11U35(401)はどうも終売のようです。mbedのサポートも打ち切られているし、早めに使ってしまったほうがいいでしょう。
という事で、開発環境の再整備から始めたのですがこれが思いの外難航しました。なんせこのボードはmbed2までしか対応しておらず、そのmbed2はとっくの昔に廃止になっているのですね。それでも Keil Studio Cloudでは未だ使えるようでした。問題はユーザーが書いたライブラリのインポートで、探しにくくて苦労しました。Keilはよくできていると思いますが、ライブラリの参照やインポートは以前のツールのほうが使いやすいと思います。
一点注意が必要なのがツールチェーンのバージョン(リビジョン?)で、mbed.bldを書き換えないとビルドが通らない場合があるとか。今回は時間がなかったので詳しく検証せずにネットの記事に従いましたが、よく考えると変な話ではあります。mbed自体、一時期(今でも、か)armのお家事情のおかげで怪しい時期がありましたのでその辺も影響しているのかも。
使ったコンパイラはこちら。
https://os.mbed.com/users/mbed_official/code/mbed/builds/65be27845400
コードはこんな感じです。繋いだキー(ボタン)が少ないので安直に割り込みで済ませています。待ちループはsleep()を挟むと動作しなくなったので、残念ながら空回し状態です。
#include "mbed.h"
#include "USBKeyboard.h"
USBKeyboard key;
DigitalOut myled(LED1);
InterruptIn pushsw_1(p16);
InterruptIn pushsw_2(p17);
InterruptIn pushsw_3(p18);
InterruptIn pushsw_4(p20);
void hoge(void)
{
//key.printf("hoge¥r¥n");
key.mediaControl(KEY_VOLUME_UP);
myled = !myled;
}
void fuga(void)
{
//key.printf("fuga¥r¥n");
key.mediaControl(KEY_VOLUME_DOWN);
myled = !myled;
}
void piyo(void)
{
//key.printf("piyo¥r¥n");
key.mediaControl(KEY_NEXT_TRACK);
myled = !myled;
}
void nano(void)
{
//key.printf("nano¥r¥n");
key.mediaControl(KEY_PREVIOUS_TRACK);
myled = !myled;
}
int main(void)
{
pushsw_1.mode(PullUp);
pushsw_2.mode(PullUp);
pushsw_3.mode(PullUp);
pushsw_4.mode(PullUp);pushsw_1.rise(&hoge);
pushsw_2.rise(&fuga);
pushsw_3.rise(&piyo);
pushsw_4.rise(&nano);
myled = 0;
while (1) {
}
}
回路図は省略。試作中の外観はこちら。
早速繋いで使ってみました。音量調整キーはxfce4 のpulseaudioが持っていきましたので当初の目的はあっさりクリアしたのですが、問題はここから。曲や局の変更に使おうとしたNEXT_TRACKとPREVIOUS_TRACKが思うように扱えません。
Audaciousはプラグインで対応できましたが、Lollipopはダメのようです。自作のラジオのほうはgtkのイベント処理を攻略できていません。gtk_flow_boxではカーソルキー及びTABキーで要素の移動ができるので、key-press-eventでTRACKキーをトラップしてTABキーに差し替えてemitしたのですが、移動してくれないんですね。
先は長いな。
]]>
昔からある定番のセンサーで、秋月電子などでモジュールとして売っている。センサーとしては高価な部類と思うが、扱いやすいのと取得できる情報が多いせいか、ロングセラーのようだ。(秋月電子のサイトでは「ベストセラー」と表示されている。)
どういう仕組みで計測しているのかほとんど理解しないまま自室でも使っているが、特筆すべきは気圧の正確さで、天気予報とほぼ同じ値が得られる。
3月10日6時の実況天気図(気象庁のホームページより)
関東平野は1024hPaから1020hPaの間に収まっているのが判る。
自室での気圧の様子。6時頃は1022hPaで気象庁の実況と概ね一致する。
自室での計測では海面校正をやっている。海抜は国土地理院発行のちょっと詳しい地図を見ればでている。自室(埼玉県和光市)の場合は概ね35mである。
]]>
デスクトップの付箋を整理していて見つけたので。読んでいて少し前に実験していたのを思い出した。
参考URL
https://wiki.alpinelinux.org/wiki/Raspberry_Pi
https://0sn.net/posts/20211127/raspberrypi-alpine/
バージョンは3.19 aarch64を使った。
注意点
何も考えずにインストールするとディスクレスモードとなる。この状態で保存されるのは
/etc
$HOME
だけ。しかも /etc/以下すべてが保存される訳ではない、らしい。
参照URL
https://wiki.alpinelinux.org/wiki/Alpine_local_backup
結局、他のLinuxPCで*.apkvol.tar.gz を編集するのが一番確実と思われる。
/usr/bin等、/etc以外の任意のディレクトリを追加できる。
その際、追加するファイル(ディレクトリ)のUID,GIDはrootにしておく。
参照URL
https://wiki.alpinelinux.org/wiki/Manually_editing_a_existing_apkovl
zeroconf 問題
リポジトリにavahiがあるので適当に入れれば、domain.localでアクセスできるようになる。
しかしresolvにはひと工夫必要である。
wiki.alpinelinux.orgの記事にあるように、avahiからdnsに投げるプログラムをインストール
しなくてはならない。問題は、ディスクレスモードだとこのインストール内容が保存されない
という事。プログラム本体(avahi2dns)は勿論、/etc/init.dにインストールするスクリプトも
保存されない。
/etc/resolv.conf
wiki.alpinelinux.orgのmDNSの記事の通りに作業すると、LAN内と外部(ほとんどがインター
ネット)に同時にアクセスできない。対策は簡単で、/etc/resolv.confのnameserver を
127.0.0.1 のほかに外部のアドレス(LAN内のゲートウェイとか)を書けば良い。
例)
nameserver 192.168.hoge.1
nameserver ::1
nameserver 127.0.0.1
WebブラウザのMidoriについて調べていたら、現在は floorp の派生になってしまっていた。元々はWebkitとGtkだったのだが。
で floorp は Firefox由来とか。
floorpをインストールして動かしてみた。レスポンスは悪くないが、YouTubeで動画を再生した時のCPU負荷がChromeの倍(初代Corei5のノートPCだとほぼ100%)に達してしまったので、アンインストールした。最新のコア数の多いCPUであれば状況は変わるのかも知れない。
]]>
参考URLの記事を元に接続先URLを得るスクリプトを書いた。
#! /bin/sh
ST=$1
echo "{¥"command¥": [¥"loadfile¥", ¥"https://`wget -q -O - "https://playerservices.streamtheworld.com/api/livestream?station=${ST}&transports=http,hls&version=1.8"|grep "<ip>"|head -n 1|sed -e 's/ //g' -e 's/<ip>//' -e 's/<¥/ip>//'`/${ST}.mp3¥"]}"| socat /run/user/1000/mpvsocket -
常駐している mpv にソケット経由でコマンドを渡している。
鳴り出すまでの待ち時間が長い。pythonとかで「最初の<ip></ip>を検出した時点でダウンロードを打切ってURLを得る」ようなスクリプトを書けば少しは速くなるかも知れない。
毎回xmlファイルをダウンロードする必要はないと思うが、そうすると既知の接続先が有効かどうか、逐次確認しなくてはならない。そのためには、mpv からエラー情報を貰ってきてスクリプト側でURL生成をリトライするという処理を書かなくてはならず、面倒なのでそのままにしている。
参考URL
]]>
LinuxMint 付属のテキストエディタ xed (version 3.2.2)にてメニューバーを非表示にする
ショートカットキーが割り当てられておらず、コンテキストメニューにもないので元に戻せなくなる。
dconfエディターを使って元に戻す
/org/x/editor/preferences/ui/ に設定箇所がある。
dconf-editor は初期状態ではインストールされていないようなので、リポジトリから取得する。
]]>
xfce4起動時の様子。テーマ変更や日本語入力、conkyを起動して使用メモリは183MiB/974MiBである。音周りがalsaなのでpulseaudio/pipewire関連がないぶん省メモリかも知れない。conkyで時刻が表示されない。フォントサイズ変更の処理がうまくいっていないようだ。
audacious 4.3.1をGTKでビルドしてみた。リポジトリにあるものはGTKを切っているので。とりあえずflacとaacとmp3が鳴れば良いのでビルドは簡単に済んだ。
mpvをバックエンドに使った自作のラジオチューナ。リポジトリにはxappも収録されているのでLinuxMintからの移植も大丈夫だった。
別のデスクトップはどうかしらん、と思ってリポジトリを漁ったらwindowmakerがあったので入れてみた。とりあえずアプリケーションソフトを動かすだけならこれで充分かも知れない。
まあ、当然といえば当然だが他のリナックスディストリビューションでできることはだいたいできるようだ。しかし一方、日本語の資料が少ない等扱いにくい面もあり、LinuxMintやdebianが動く環境でこれを選ぶ理由が見当たらないのであった。
/etc/profile.d/20locale.sh.sh
export LC_MESSAGES='ja_JP.UTF-8'
とりあえず、メッセージに対してだけ指定すれば良いようだ。
翻訳ファイルはひとつひとつインストールすることもできるが、メタパッケージ lang を入れるのが確実。
]]>
で、元日は近所で数コマ、2日は雨降りだったので中止、3日の今日になってようやく本格的(?)に撮ろうとして出かけたのですね。
しかし。
ひっさしぶりに35mm一眼レフ使ってわかったのだが、「眼」が終わってました。ファインダーの視度に合わせてメガネを作り直すか、もはや絶滅したニコン一眼レフ用の視度補正レンズを探さなくてはならないようです。
35mmで撮る時は必ず2本差しにするのですが、気がついたらFのウエストレベルファインダーばかり覗いていました。
2時間強で36コマ撮りを2本費消するのがやっと。カラダが120フィルム(6x6及び6x9)の撮影リズムに馴染んでしまっているので、思った以上にはかどりません。
加えて。
撮っているのが雑踏写真なので仕方ないのですが、「カメラだ!」と鋭い声が飛んできて流石に怯んで(ひるんで)しまいました。以前はこんなことなかったんですけどね。スマフォで隠し取りするよりいいだろ、というのは撮る側の理屈で、レンズアレルギーの人にしてみれば違いはないんでしょうな。
だいじょうぶ、有効期限切れのネガ使ってますから。写っているかどうかすら怪しいので。
って、そういう問題ではないですね。すみません。
新宿2023
露出計代わりのPowershot S95で撮影。久しく行っていなかった箇所なのだが、露店が全て取り壊されていて驚いた。
]]>
localeが切り替わらない事については、設定記事が見つかった。
https://wiki.alpinelinux.org/wiki/Post_installation#Language_support
確かに切り替わるのだが、今度はIME(ibus)が使えない。ctrl-jや半角/全角を押しても入力できない。しかし、ibus自体は起動している。
localeをCに切り替えると治る。
うーむ、わからん。先は長いな。
]]>
とはいえ、debian派生が全て候補から外れるので選択肢は限られてくる。で、今回はAlpineLinuxを試すことにしたのですね。
どちらかといえば、サーバーや組み込み向けでデスクトップ用途はオマケみたいな感じがしますが、リポジトリにはxfce4も用意されているので実用になると思いました。
現実はなかなか厳しくてそう簡単には行かなかったのですが。
現状の問題点
というか、どこで設定すればよいのか今ひとつ分かっていない。とりあえず~/.ashrcには書いた。
LinuxUser(の誰か)でログインし、呼び出すとセグってコケる。このため、自動開始アプリケーションの登録ができなくなってしまった。最初からこの状態ではなく、イジっているうちにおかしくなったので、何か触ってはいけない箇所があったのかも知れない。
当面の方便として、rootでログインし、スイッチユーザーで任意のLinuxUserに切り替えると回避できる。
今どきibus-anthyはないよね。まあ、x86(本物の32bitCPU)を積んだPCでガシガシ日本語入力する事はないのかも知れないけどさ。
xfce4のインポートが余り重要視されていない為かも知れない。あるいはバグが生じたか、そもそもビルドできないとかかしらん。
仮想環境(Virtualbox)での動作状況。ダークテーマをLinuxMintから借りてきてインストール済である。確かに省メモリではあるのだが、systemdでないとか、gvfs一式が動いていないとか、いろいろとタネも仕掛けもあるのであった。
いや、今でも趣味の一つだけどさ。流石にアクティビティ低すぎでしょ、ということで封印状態だったりする訳です。
ずいぶん前のことになるが、青春18きっぷの発売に合わせて離京し、西日本方面で写真を撮っていた事があった。最初の頃は35mmで撮っていて、2〜3日の旅程のノルマはモノクロネガ20本、カラーネガ少々というものだった。モノクロネガ20本というのは100ft巻から36コマ撮りで切り出すと20本(正確には19本と少々)になるためである。撮影時はボディ2本差しでそのうち1台はモードラ内蔵なので、使い切るにはちょうど良いくらいだった。
部屋の冷蔵庫に1巻だけ温存していた400TMY。有効期限はかなり以前に切れている。
100ft巻を切り出す際に必要になるのがフィルムローダー(ディロール)。四半世紀に渡って愛用しているが、流石に調子が悪い。
症状はフィルムゲートが閉じない、という致命的なもの。フィルム巻きとりハンドルを差し込むと連動して開閉するようになっているのだけれど、経時劣化で動作が渋くなって閉じなくなったのですね。
分解した様子。仕組みは簡単で、カンヌキが2重に施されておりパトローネ室の蓋を閉じ、巻取りハンドルを差し込むとゲートが開くようになっている。
ゲートの開閉状態は巻取りハンドルを取り外すと外部からでも確認できる。開いてしまっていたら、カンヌキ部分にショックを与えることで所定の動作をするようになった。
来年は少し撮ろうかと思う。
]]>
例によってすぐになくなる訳ではないし、oldstableのリポジトリを閉じてしまうとかでもない(と思う)ので、今すぐに使えなくなる、とかでは無いのだけれど。
この部屋のPCの中で、32ビット(i386)のdebianベースを入れているマシンは5台もある。そのうち2台は常用中である。
まあ、Linux自体がIA32を切った訳ではない(未だi486対応だったはず)から必要なら自分でビルドすればいいだけ、なのだが。
]]>
一人で作る場合でもgitは便利である。
昔と違ってマイコンのプログラム開発に使う言語は既にいろいろあるから処理系を自作する意味は余りないのだけれど。
それでも趣味でやる分には簡単なインタープリタがあると重宝する場合もある。シリアルターミナルさえ繋げば何かできる、という形式であればなおさら。
という理由でちょっと昔にBASICインタープリタを書いたのだが、最近はマイコンのスペックが上がってきたので、その辺も踏まえてイチから書き直そうと思い立ったのですね。
で、手を付けてから半年も放り出してあったのを今月に入ってからやおら書き進めて、取り敢えずPCでは所定の動作をするところまで仕上げました。
なにせプロジェクト名がBASIC2023なので。年越すわけには行かなかったのですね。
最近のマイコンを踏まえて、と書いたけれど精度は16ビットのままにしました。16ビットあればほとんどのペリフェラルを捌けるだろう、というのが理由です。マイコンの銘柄によってはプログラムテキストをRAM上に展開して使う場合もあるのでメモリ消費量を節約する点でも重要かと思います。
printf のtiny版を書いたのだけれど、BASICのPRINT文にそのまま流用できないので似たような処理が重複するとか、見積もりの甘かった部分も多いので、マイコンで動かす際は結構な修正を迫られそうです。
]]>
部屋住みの身分なので大音量でスピーカーを鳴らすとかはできない。
ちょっと前まではイヤフォンユーザーだった。部屋にいる時はシャワーを浴びる時以外は装着している、という使い方をしていたのが、耳の中が黴びる、というので使うのを止めたのだった。確かに耳垢が増えたような気がするが、黴びたためなのか、それとも単に加齢によるものだけなのかはわからない。
イヤフォンが使えないならヘッドフォンしかないのだが、長時間使っていると頭が痛くなってくるのが難点なのだった。しかたないので、できるだけ軽量かつ安価で丈夫な製品を、ということでSONYの下から2番め位のものを選んでつかっていた。高域がまったく伸びず、かつ低域がこもる、といったいかにも安物という音で、イコライザ必須なのだがどうせPCやラジオにしか繋がないので割り切って使っていた。
2つ使ったところで流石に飽きてしまった事もあってオーテクのちょっとよさそうなものを買い足した。確かに音は良くなったが、ヘッドバンドが固くて側圧が強すぎて、アルバム1枚を聴くのが我慢の限界だった。
次に買うのは、音はともかく装着感の良いものを、ということで店頭で実際に耳に当ててみて選んだのが、同じくオーテクのATH-M50xという製品だったのですね。
値段は2万円と個人的には高額の部類に入ります。位置付けはモニター用ヘッドフォンというもので、オーテクの製品ではハイエンドモデルだとか。ちなみに同じシリーズでM70xというのがあってこちらはフラッグシップモデルだそうだ。うーむ、よくわからん。ニコンのF4とF-801,F5とF100、あるいはTRIOのTS-9xx系とTS-8xx(4xx)の関係みたいなものかしらん。
コジンテキに耳が腐っているので音質についてどうこう言えないのですが、SONYの安物と比べれば確かに解像感は感じられます。無駄にフカしてもっともらしい音にしている、という感じではなく、低域も高域も丁寧に再生しているなあ、という印象ですね。
値段は高いけれど、コードは脱着可能(用途別に3本も付属してきた)だし、耳あても交換できるので、過入力でボイスコイルを切ったり、踏んづけて機械的に壊したりしなければ長く使えそうです。
肝心の装着感は耳全体を覆うため、個人的には痛くならずに使えています。付けたまま朝まで寝たりしたけれど頭が痛くてつらい、等ということにはなりませんでした。
ノートPCに繋いで使っているだけですが、ドライブ能力が気になってきたのでそのうちアンプでも組んで遊んでみようと考えています。
LinuxMint 21.2 にssh でログインしたらメッセージが表示されなかったので。
/etc/ssh/sshd_config をチェックして、
#Banner none
だったらコメントを解除して、表示したい内容の書かれたファイルパスを書く。
例えば、Bannuer /etc/issue など。
]]>
isHidden = (hidden != NULL && !g_strcmp0 (hidden, "true")) ? TRUE:FALSE;
こんなコードを書いていて、自分でもゾッとしたのですね。
&&演算子の結合規則は、左から右、なので大丈夫とは思いますが。
]]>
原因はsystem()を呼んでいた事だった。
旧作ではexeclpだったが今回は.desktopを参照して実行するため、引数の扱いが煩わしくて横着したのだった。
対策は分かってみれば簡単で、execlpの最初の引数に
/bin/shを、続いて-c、.desktopから取り出した実行文を引いて呼べば良い。
]]>
アプリケーションランチャを作っている。
タブレットPC上でLMDE6(デスクトップはxfce4に換装)を使っているのだが、whiskermenuを始めとするメニューアプレット/プラグインの類がどうにも使いにくい。
それもそのはず、これらアプレットはマウスやタッチパッドでの使用を前提に設計されているので、そもそもタブレットのタッチパネルから使おうという事に無理があるのですね。
無いなら作ってしまえば良い、ということで作っているのですが。
見かけはこんな感じ。stack や stackswitcher、flowbox等GTK3.0のWidgetをフル活用(?)している。
これが上手く行かないのですね。
メニュー項目 (.desktopファイルから作成)をタップするとダブルフォークして当該アプリケーションを起動するようにしているのですが、XCBがエラーを吐くのです。
子プロセス 24907 を起動しました。
孫プロセス 24908 を起動しました。
[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
menutool: ../../src/xcb_io.c:260: poll_for_event: アサーション `!xcb_xlib_threads_sequence_lost' に失敗しました。
Google翻訳によれば
キューの処理中にシーケンス番号が不明です。おそらく、これはマルチスレッド クライアントであり、XInitThreads が呼び出されていません。中止しています。申し訳ありません。
だそうです。
なるほど、よくわからん。確かにマルチスレッドではあるけどね。このほか、子プロセスの終了にて exit(0)を _exit(0)に変えてみたりしているが状況は変わらない。
原因について一つ心当たりを上げると、
本作を作成する前に、統合環境(Geany)で作ったプロジェクトファイルを一覧表示するツールを作った。アプリケーションプログラムの起動ルーチンはこのツールからの流用である。勿論、旧作では特に問題なく期待通りの動作をしている。
新作と旧作との違いは、ダブルフォークをどこから仕掛けているかで、旧作はGtkWidget の GtkTreeViewからだった。新作では自作の複合ウィジェットから起動している。
ということで、問題がありそうなのは自作ウィジェットであるのは間違いないと思われるのだが。
先は長い。
VH-3 で LinuxMint 21 を動作させたときに遭遇したバグ
xfce4-notifyd-plugin
g_str_tokenize_and_fold ()がcritalを返してきてコケる。
この状況に陥ると、panelプラグインが動作しないのはもちろん、通知の設定ダイアログも開けない。
通知ログ(~/.cache/xfce4/notifyd/)をクリアすると治るので、クライアントが送ってきた文字列をうまく扱えなくてクラッシュしているものと推測される。
plank
bamf関連で通信がうまくいかず、起動に時間がかかってしまう。また、起動中のプログラムを認識できなくなり、ランチャをクリックした時のshow/hideのトグルが動作せず、新しいインスタンスを起動してしまう。
もっぱら使用しているのは20.3なので、21.2の挙動にはわからないことも多い。
]]>
NEC VersaPro VH-3 2017年頃の製品かしらん。ネットを漁っても詳細なマニュアルを見つけられなかったので法人向けモデルなのかも知れない。ヒンジが180度まで開かないのが残念。重量は測っていないが持ってみると軽く感じられ、持ち歩いて使おうという気になる。RAM 4GB(on board), SSD 128GBでWindows10を動かす最低限のスペック。ちなみにファンレスである。
ストレージが128GBしかなかった。WIndows10を捨てるのがもったいなかったので、換装して温存することも考えたのだけれど、簡単に交換できる構造ではないのでLinux用に48GBを削り取ってマルチブートにしてみた。
インストールしたのはいつものLinuxMint(21, Xfce4)、wifiを認識したので有線LAN接続無しでインストールを完了した。内蔵カメラはUSB接続なので、アプリケーション(cheese)から使うことができた。但し、動作中はCPU温度がかなり上昇したので余り実用的とは言えないようだ。タッチパッドは大きめのものが付いているのでtoucheggを入れてみたが、chromeでのピンチングは滑らかとはいえない。
この筐体にしては音が良い、と思う。スピーカー出力及びヘッドフォン共に左右の分離が良く、audaciousにてalsa出力すると解像感のある音が出てきた。
ファンレスなので動作温度が気になるところだが、mp3ファイル再生中のCPU温度をモニタしてみると室温24℃で40℃程度である。youtube で1080pを再生すると70℃を超えるが、フレーム落ちする事は少ない。これらはLinuxでの挙動なのでWindows10ではもう少しマシになるかも知れない。
最初から分かっていたことだが、動作そのものはWindowsのほうがわずかに速く感じられる。特に動画再生ははっきりと差が判る。言い換えればその程度の差でLinuxデスクトップが動作するという事で、Windows10のサポート切れ後も一安心と言えるかも知れない。
ストレージの容量に余裕がないこと、smartで調べたら稼働時間2年半との事で寿命も気になるので、オンラインストレージ主体の使い方を考えてみようと思う。
いわゆるグローバルメニューっぽいやつ
リポジトリからプラグインを入れる。
xfce4-appmenu-plugin
設定エディタでxsettingsに次を追加する。
/Gtk/ShellShowsAppmenu Boolean True
/Gtk/ShellShowsMenubar Boolean True
パネルを画面上端へ移動し、
パネル分のスペースを確保しない(R)をチェックする。
行サイズは使っているテーマにもよるが、概ね32程度にしておく。
パネルにAppmenuを追加する。
これでアプリケーションのメニューがパネルに表示されるようになり、また、ウィンドウ最大化時にはパネルと一体化したような見た目が得られる。
問題点
このネットブックはwifiモジュールを内蔵しているのだけれど遅くて使いにくいので、5GHz帯対応のUSBドングルを差している。で、今回のアップデートではこいつのドライバの更新で無限ループに突入する異常が生じたのですね。
ドライバの更新はdkmsで行うようにしてあった。ひょっとしたらソースが旧くてカーネルについてこれなかったのかも知れないが、放置しておけばSSDの書き換え寿命を使い切ってしまうので緊急停止をかけたのですよ。
timeshiftで巻き戻すことも考えましたが、どうせ大した用途には使っていないのでLMDE6をクリーンインストールすることにしました。問題のドライバもgithubから改めてcloneしてインストールしたところ正常に動作しました。
で、素直にCinnamonで使えばよいものを、未練がましくxfce4を入れて、先日から問題になっている「フォント選択ダイアログ操作時のクラッシュ」が再現しないか確かめたのですね。
結果は案の定、再現しませんでした。ということで、core2duoを使っているThinkpadR500固有の問題、で決着です。昔ならここからしつこく原因追求するところだけれど、メインPCではないしCinnamonなら問題なく使えるしで、このまま終了ですな。
LMDE6ですが、結構いろいろ動かしてくれるのでメモリがいくらあっても足りないといった印象です。pipewireとか必要かしらん。まあ、pulseaudioが出た時も似たような事を考えましたが。
今どきのPCはリースアップした実働中古品でもRAM4GBは積んでいるので問題ないですが、ちょっと古めのRAM2GBくらいのPC(冒頭のネットブックがまさにそれ)で使おうとする場合は注意が必要でしょう。
]]>デスクトップの様子。conkyを廃してCPU負荷やACPIなどをアプレットで代替したのでパネルが窮屈である。アプレットについてはxfce4で使っていたものと同様のものを探したが完全な互換品は少ない。特に天気予報が昔ながらの空港タイプなのは気が遠くなった。メニューは標準のものではない方に換装した。xfce4のwhiskermenuから移行するにはこちらのほうが良い。
承前。
xfce4にてフォント選択ダイアログを操作するとデスクトップごとクラッシュする(再起動ではなくログイン画面になる)問題は、未だ解決できていない。
同じLMDE6(但し32bit, CPUは4コアatom)を積んだもの、debian12にxfce4を入れたもの(こちらも32bit, CPUはpentium-m)で試してみたが再現しないので、64ビット版とcore2duoの組み合わせによるのかも知れない。同じPCでCinnamonやMATEでは再現しないので、xfce4が原因なのは間違いないと思われる。
いくら予備機とはいえ危なっかしいデスクトップは使いたくないのでCinnamonを使うことにして、いろいろ弄って起動時の専有メモリが800MBを切るようになったところで一段落つけた。
Cinnamonは今まで使ってこなかったのだが、よくも悪くも昔のUIで使っていて面白くない。それはxfce4も同じなのだけれど、xfce4はモジュール交換しまくって原型を留めなくする事もできる。しかしCinnamonでそれをやるのは、なんとなく気が引けるのだった。
]]>
結構エグい、かも。
]]>
アイコンに必要なファイルが全てインストールされているにも関わらず、特定のアイコンが表示されない時の対処方法
sudo gtk-update-icon-cache -f -t /usr/local/share/icons/hicolor
既存のパッケージの置換を試みる場合、インストール先を /usr/local 等とすることが多い。そのまま置換して使うなら問題ないが、失敗してアンインストールした時にキャッシュだけが取り残される事があるのが原因である。
]]>
アップデート手順
sudo apt update
sudo apt install mintupgrade
sudo mintupgrade
LMDE6 beta (amd64, ThinkPad R500, デスクトップをxfce4に換装済)
特に問題なく終了した。使用しない cupsとtoucheggを止めた。
LMDE5 (i686, Arrows tab, デスクトップを xfce4に換装済)
前バージョンからのアップデートであり、作業中にパッケージの削除や巻き戻しの警告が表示された。
再起動後、次の症状がでた。
xfce4から再設定した。
pipewireとの関係からか音切れが生じた。
mpvにて
mpv --audio-device=help とやって使えるデバイスを調べて使えそうな設定を選び、
~/.config/mpv/mpv.conf に
audio-device=pulse/alsa_output.platform-bytcr_rt5640.HiFi__hw_bytcrrt5640__sink
と書いて解決した。
なお、chromiumでは問題なかった。
プラグインのロードに失敗するので、再度ビルドし直した。
その他
LMDE5の時からcupsは外していたが、その設定は引き継がれていた。
LinuxMintではバージョンチェンジの場合はクリーンインストールを推奨している。LMDEはdebianベースだからなのか上書きアップデートが用意されているが、今後使っている間に新たな問題が生じるかもしれない。
参考URL
https://web.sfc.wide.ad.jp/~sagawa/gnujdoc/automake-1.8/automake-ja_23.html
例えばインストール先のファイルのパーミッションを変更したい場合、インストール後に chmod a+x target とか実行したい。
automakeでは、一連のデフォルトの処理が終わった後に、任意の処理を実行できるようフックが用意されている。
フックできるのは、
install-data
install-exec
uninstall
dist
distcheck
例として data としてインストールしたプラグインファイルのパーミッションを変更したい場合は
data/Makefile.am の最後に
install-data-hook:
chmod a+x $(hogefugadir)/$(hogefuga_DATA)
等と書く。
これらは単純にMakefileにコピーされて実行される。
気づいたこと
make DESTDIR=/home/hoge/fuga install とやって、任意のディレクトリにファイルをインストールした場合、上記のままでは「任意のディレクトリ」を認識してくれない。
剃り味にこだわる、等ということはないのだけれど。
替刃がなくなってしまったので、まだ動くシェーバーを廃棄することになった。
長年日立を使ってきたのだが、もうほとんど商売にしていないようでヨドバシの店頭にもなかったので、パナソニックの安物(但し下から2番め)を選んだのだった。
しかし。
安物、と書いておいてなんだが、本当に安っぽいのですね。豊富なラインナップの中で差別化しなくてはならないから仕方ないのかも知れないですが。
]]>
本当は撮影に出たかったのだけれど、快晴で撮りにくいのと暑いのとで中止にした。代わりと言ってはなんだが、ネガを2本現像した。
蛇口の水道水は28℃もあった。しかし氷が不足していて希釈した現像液は22℃までしか下がらず。しかたないのでビーカーごと冷蔵庫に入れて20℃まで下げた。ついでに現像タンクも冷蔵庫に入れた。
それでも現像終了時には22℃迄上がってしまった。このくらいなら暗室でもスキャナでもフォローできる範囲ではある、撮影時に失敗さえしていなければ。
ACROS(旧バージョン)、T-MAXデベロッパー 5分30秒
カメラは写真左側がイコンタで右側のネガがネッター。ネガを見ただけでネッターのコントラストが不足しているのが判る。レンズが曇っているので仕方ないのだけれど。
]]>
個人的には最近ようやくGTK3に慣れてきたところなので「もうGTK4かよ」という気持ちである。
で、移行に備えるべくマニュアル https://docs.gtk.org/gtk4/migrating-3to4.html を見ていたのだが、
「3と4ってほとんど別物じゃね?」
と思ったくらいに違っていた。
GTK+2 と GTK3 でも、違うところは違っていた。しかしGTK+2が長く使われており、その中でいろいろ取り込まれてきた要素をGTK3で整理統合した、みたいなところがあったので、移行は然程難しくはなかった。
GTK4には、GTK+2およびGTK3における「泥臭さ」を一掃しようとしている気配がある。
GtkBinやGtkContainer、GtkEventBoxは廃止された。GTK+2では個人的に最難関だったGtkTreeViewも過去のものになるらしい。
変更点が大きいこと、GTK3の開発が終了し仕様の変更が無いこと、GTK4の開発が終わっていないこと(仕様の追加がありうる事)等から当分の間はGTK3を使っていて良いような気がする。
等というのはCで書く場合の話であって、メジャーな言語で強力なラッパーがあればそちらで開発する人が増えるだろうから、変わる時はあっという間なんだろう、と思う。
]]>
その最新バージョン(LMDE6)のベータリリースが出たので試してみたのですね。
いつもは仮想環境を使うのですが、今回は廃棄待ちのノートPCにインストールしてみることにしました。
このPCのスペックはこんな感じです。
ThinkPad R500
CPU core2duo P8400 2.24GHz
RAM 4GB
HDD 160GB
LCD 1280x800
数年前までメインPCとして使っていたものです。CPUこそ古いのですがグラフィックス周りがそれなりで、普通に使う場合は初期のCorei5や第3世代Celeronを使ったノートPCと同等の処理能力がありました。差がつくのはコア数がものをいうパッケージビルドの時くらいでした。
廃棄待ちにしたのはFanErrorが止まらなくなり、正常起動しなくなったためです。エラー発生時にESCキーを押すことで強制起動しますが、安全性を考えて使用中止にしたのですね。なにより面倒だし、うるさいし(※1)。
インストールに先立ち、ダメ元でファンを分解し清掃してみましたが治りませんでした。回転そのものに問題はないので、回転数の検出部分がどうかしているようです。
コイル側に差し込んであるだけなので、簡単に分解できる。思ったより羽は汚れていなかった。
コイル側の様子。埃を取り払った後の写真。分解時に小指の先の半分ほどの毛玉が出てきたが、あんな大きなものが挟まった状態でよく回転していたものである。
部品が実装されている部分がせまく、埃がぎっしり詰まっていた。
ヒートパイプ及びヒートシンク。この後、水洗いしてから無水アルコールで脱脂した。
ヒートシンクには組み立て時に隙間を埋めるスポンジが貼られていたが、ベタついていたのですべて取り除いた。カメラ用のモルトプレーンでも貼ろうかと思ったのだが、かなりの高温になる箇所であり耐久性がわからなかったので止めた。
画面中央がCPUでその右下がグラフィックス関係かなにか。ヒートパイプはこの2つに付くようになっている。グリスを塗り替えたので、少しは冷えるようになったはず。
CMOSバックアップ用の電池だが、多分このPCが製造されてから一度も交換されていないと思われる。分解時に取り外したのだが、基板側のコネクタ(樹脂部分のみ)まで一緒に抜けてしまって焦った。
LMDE起動後、xsensorsで監視してみたのですがFanの回転数は0のままでした。OS側処理に抜けがある可能性は捨てきれませんが、起動時の事と合わせて故障確定としました。
その後、xsensorsに代えて Cinnamonのアプレット(CPU Temperature Indicator (temperature@fevimu))で監視してみたところ、
室温30度にて
待機時 42度前後
音楽再生時 45.5度
youtube再生(480px) 57度前後
となったので、実用上問題ないレベルに冷却されているものとしました。
さて、LMDE6ですがインストールそのものは特に問題なく終了したものの、次の問題が生じました。
1については、このPCにbluetoothが乗っている事自体よく覚えていなかったので詳細不明。現状では実用上問題ないので特に追求しません。
2はちょっと不便なので他のOS(Puppylinux4系)をCDから起動して試したが同様でした。いつだったかのようにPCを組み立てる際に断線した可能性もあるのでチェックしたが特に異常は認められませんでした。古いPCなので故障していてもおかしくないので、これも後回しです。
3が大問題で、結局手動で
fcitx5
fcitx5-mozc
をインストールし、im-configで設定を通しました。この辺はいかにもベータ版といった感じです。
主な追加設定
LANへの接続は、インストール時は有線を使用し、その後 PCカードの無線LAN(2.4GHz)を増設してfirmware-b43-installer をインストールしました。
UIのフォントがUbuntu Regular だったので Noto Sans CJK JPに変更しました。但し、MonospaceだけはNotoでは細すぎるためMonospace Regularを採用しました。
スワップ領域をRAM上に取ることにしてインストール時からHDDにスワップ領域は作成しませんでした。zram-toolsをインストールし、/etc/default/zramswap の設定で zstd, 25%としました。
その他の問題(多分、LMDE6は無罪)
audaciousで音楽ファイルを再生していると頻繁に音切れが生じました。圧縮音源(mp3やaac)よりflacで顕著でした。
音源ファイルはLAN上にあるので iperf3 で速度を測ったところ、senderとreceiverともに13Mbits/sec でした。
ちなみに同じ室内で5GHz帯で接続しているタブレットPC(LMDE5)は50Mbits/sec程度、有線接続しているメインPCは100Mbits/secでしたから、結構遅いと思います。
PCカードの無線LAN子機は言うまでもなく2.4GHzを使う旧式のものです。
今チェックしたところ34ものIDを拾っており、うち1つの信号レベルはこの部屋のルーターよりも強いです。この混雑さ加減が速度がでない原因と思います。
※1 エラーゆえの消音不可なBEEP音がフルボリュームで鳴り響きます。
]]>10年ぶりにコンパクトカメラを買った、と思ったのだが、よく考えたら
Powershotを1台買っていた。非沈胴式レンズのカメラはOlympus μ1050SW以来で通算4台目だが、全てリタイアしている。
(この写真はPowershot A20で撮影した。)
稼業で記録写真を撮ることが多い。勿論、プロカメラマンではない。
今どきコンデジなんて流行らなくて、スマフォのカメラを使うのが常識と思うがいわゆる「カメラ」でないと困る場合もあるのですね。
それはセキュリティが厳しい場合。
スマフォだとどこに飛んでいっているか解らないので。かと言って、「カメラ」で撮った画像をいちいち検閲する訳でもないのが謎。
コジンテキにはスマフォカメラの操作が悶え死ぬくらいやりにくいので、どうしても「カメラ」が必要ではあります。
で、買ってきたのはRICOHのWG-80。防水防滴だとこれ以外は同じくRICOHの業務機と、OMに1機種あるくらい。この3機種の中だと(多分)一番安い。Kodakも出しているけど、動作がかったるいのでボツ。
ちょっと使ってみた感じ、カードスロットやUSBポートへのアクセスが(その防水性能ゆえの)煩わしいのが気になりました。
顕微鏡モードを試してみた。ピントが後ろに抜けている。使いこなすにはコツが必要なのかも知れない。
ハードはちょっと前までRaspberry Pi Zero Wだった。これはOLEDを繋いで時計と温度計も兼ねさせた多機能なもので、それなりに重宝していた。しかし先日、Raspberry Pi Pico で温度計付き時計を作ったことから一時引退にしてしまった。
代わりに使っているのが、Atom時代のタブレットPCで、LMDE(32bit)に自作のネットラジオ(アプリケーションソフト)を入れて鳴らしている。
この自作アプリはmpvをバックエンドにしたフロントエンドで、GTKとCで書いたなんの変哲もないものである。
mpv はsystemdにてデーモンにしておいて、UNIX Socket でフロントエンドと通信して動かしている。
mpv はそのままでもストリーミングに対応しているので、普通の(?)ネットストリーミングならURLを渡せばすぐに音が出てくる。
しかし、日本国内で使われているradikoは、フリーであるにもかかわらず地域判定の必要性からか認証が必要で簡単にはいかない。
といっても、然程難しいものでもないので、ネットを漁ればradiko聴取用のスクリプトはいくらでも出てくるのであった。
今まで使っていたのは
NanoPi NEOにインストールしたMPDでradikoを聞く
https://burro.hatenablog.com/entry/2019/02/16/175836
で紹介されている中継サーバーだった。これはサーバーなので、ストリーミングを解するソフトであれば何でもクライアントになれる利点がある。
その一方、ラジオとして使わない時も一定量のメモリを消費する(はず)というデメリットもあった。
一定量のメモリ、などと言っても昨今のハード事情であれば然程問題になることもなく、実際、上記のRaspiZeroWでも使っていたくらいである。
ところが、そのRaspiZeroWの挙動を見ていておかしな事に気づいたのですね。それは1日中Radikoを鳴らしておくとメモリの消費量がすごいというものです。RAMで不足してSWAPし始める程でした。
以前はこんな事はなかったと思うのですが。まあ、PCで使っていた時はデスクトップは1日に1回は再起動する(あるいは電源を切る)ので気づかなかったのかも知れません。中継サーバーそのものはスクリプトもフレームワークも旧いままですが、RaspiのOSは都度新しいものを使うようにしていたので、その辺りでリグレッションが生じたのかも知れません。
いずれにせよ、この中継サーバーをこれ以上使い続けるのは困難であるのは変わらない(実はこれもRaspiZeroWを一時引退させた理由の一つ)ので、代替手段を講じなくてはなりませんでした。
radikoが認証後に返してくるのはHLSなのでmpvで扱うことができます。であれば、認証部分だけ書いて自作ネットラジオに実装すれば良いのですが、地味に面倒なので手を付けてませんでした。
しかし、ネットを漁っていて見つけたスクリプトがとても使いやすそうだったので、借用して取り組んでみることにしました。
radikoの再生や録音をツールで自動化
https://kakurasan.tk/raspberrypi/raspberrypi-automate-playing-and-recording-radiko/
上記スクリプトでは再生にffplayを使っていますが、mpvで同様のことを行うには次の様にします。
os.system( f"mpv -http-header-fields='X-Radiko-Authtoken:{token}' '{m3u8}'")
しかし、これだとデーモナイズされているmpvと通信して再生、ということができません。
なので、このようにしました。
s0 = f"http-header-fields='X-Radiko-Authtoken:{token}'"
s1 = f"{m3u8}"
s2="{%s}¥n" % '"command": ["loadfile", "{0}"]'.format(s1)s = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
s.connect("/run/user/1000/mpvsocket") # mpvとの通信ソケット
s.send(s2.encode())
d = s.recv(1024)
s.close()
変数s0にhttpヘッダを入れていますが使っていません。mpvでJSON IPCを使って渡す方法を見つけられなかった(探し方が悪いのかも知れない)からです。とりあえず無くても音は出ますが、ひょっとしたら何か不具合があるかも知れません(長時間接続していると切断される、とか)。
次にこのスクリプトを自作ネットラジオにどのように渡すか、です。埋め込んでしまう事も考えたのですが、後々のメンテナンスを考えてボツにしました。
いろいろ考えてプレイリスト側に細工することにしました。
通常、プレイリストはこのように書きます。(m3uの場合)
#EXTINF:-1,radioparadise.com(main mix) / radioparadaise.com(main mix,320k,aac)
http://stream.radioparadise.com/aac-320
radikoの場合はこんな風に書くことにしました。
#EXTINF:-1,Tokyo / 文化放送
plugin:/radiko.py/QRR
自作ネットラジオ側でプレイリストを読んで、スキーム部分が「plugin」なら続く部分をスクリプト名とみなして処理する、という、自分勝手なものです。自分で作って自分で使うのでこれで充分です。なお、スキームの「:」の後ろのスラッシュが一つ少ないのは、pathを作る際の手間を減らす工夫(単なる手抜き)です。
コード(抜粋)はこんな感じです
gchar *scheme = g_uri_parse_scheme (url);
if (!strcmp (scheme, "plugin")) {
// url の先頭がpluginであれば呼び出しにかかる
gchar *station = g_path_get_basename (url); // basename をplugin の引数にするgchar *p_path = g_path_get_dirname (url);
gchar **plugin = g_strsplit (p_path, ":", 2);
if (plugin != NULL) {
gchar *command = g_strdup_printf ("%s/mpvradio/plugins%s %s",
DATADIR, plugin[1], station);
system (command);
g_free (command);
g_strfreev (plugin);
}g_free (p_path);
g_free (station);}
else {
// url や playlist であればそのまま mpv に送る
mpvradio_ipc_send ("{¥"command¥": [¥"set_property¥", ¥"pause¥", false]}¥x0a");
message = g_strdup_printf ("{¥"command¥": [¥"loadfile¥",¥"%s¥"]}¥x0a", url);
mpvradio_ipc_send (message);
g_free (message);
}
プラグインスクリプトの格納先が固定だったり、処理の呼び出しが system にそのまま投げたりとαバージョン感が色濃く漂ってますね。
使い勝手ですが、遅いハードだとどうしてもpythonのロード待ちが生じて選局の時に一瞬の間が空いてしまいます。OS側でキャッシュしてくれているはず、と思うのですが。
しばらく使い込んでヘッダを渡していない事なんかの不具合を見極めたいと思います。
既知の問題点
参考URL
NanoPi NEOにインストールしたMPDでradikoを聞く
https://burro.hatenablog.com/entry/2019/02/16/175836
radikoの再生や録音をツールで自動化
https://kakurasan.tk/raspberrypi/raspberrypi-automate-playing-and-recording-radiko/
]]>
smtpではダメで、tlsでDialすること。
参考URL
https://gist.github.com/chrisgillis/10888032
]]>
間に合せで100円ショップで買った蓋付きのプラケースに入れたのだが、熱がこもって正確な測定ができず蓋を半開きにして使うことになってしまった。
なお、消費電力は5V 37.5mA程度だった。pico単体の消費分は測っていないが表示器とは半々位ではなかろうか。
raspberry pi pico と tinygo を使った温度計付き時計ですが、製作に一区切りつけることにしました。
現在の機能は
です。
時計としての精度ですが、今のところ、数日動かしていても分レベルでずれる事はないので実用になると思います。
室内サーバーとして使っているPCのUSBポートに接続して使う事にしたので、このPCから制御するためのツールをgoで書きました。
ツールには時刻設定や文字列の送り込みに加え、温度や湿度を受け取って以前から使っている記録サーバにPOSTする機能も持たせました。この手のプログラムは今までpythonで書いていたのですが、goでも簡単に書けました。マイコン側の開発にtinygoを使うことで全てgo言語で賄うことができるので、後々のメンテナンスもしやすいのではないかと思います。
tinygo を使う、と書いたが単にデバッグコンソールをuartに出すだけ。
標準出力をUSBシリアルから uart (ピン1,2)に変更してビルドする
tinygo build -target=pico -print-allocs=main -size short -serial uart main.go
プログラムの書き込み
openocd -f interface/cmsis-dap.cfg -f target/rp2040.cfg -c "program ./main.elf verify reset exit"
これで書き込みの際、いちいちBOOTSELを押さえてUSBを抜き差しする手間から開放された。
ターゲットへの電源供給をpicoprobeから行えば、USBポートも1つで済む。但し、ポートの供給電力の上限に注意しなくてはならない。
tinygo (go)における、時刻の取扱い方法に関して。
time.Local
time.Local は zoneinfo.go (package time)にて定義されている。
var Local *Location = &localLoc
type Location も定義されている。
]]>type Location struct {
name string
zone []zone
tx []zoneTrans// The tzdata information can be followed by a string that describes
// how to handle DST transitions not recorded in zoneTrans.
// The format is the TZ environment variable without a colon; see
// https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html.
// Example string, for America/Los_Angeles: PST8PDT,M3.2.0,M11.1.0
extend string// Most lookups will be for the current time.
// To avoid the binary search through tx, keep a
// static one-element cache that gives the correct
// zone for the time when the Location was created.
// if cacheStart <= t < cacheEnd,
// lookup can return cacheZone.
// The units for cacheStart and cacheEnd are seconds
// since January 1, 1970 UTC, to match the argument
// to lookup.
cacheStart int64
cacheEnd int64
cacheZone *zone
}
とりあえず、oled をアクセスする時に sync.Mutexでロックしたところ、何とかなりそうでした。
なりそうでした、というのは11時間程動かして問題ない、というレベルなので。年単位で動かしたらどうなるかは未知、という事です。
それと時計としての精度がイマイチ。11時間31分動かして1,2秒ずれます。Ticker 自体の精度によるものか、室温の変動など外的要因によるものなのか。
こうなると、pico のRTCがどういうものか確かめたくなります。
PCに繋いで使う分には、定期的に時刻設定をし直せば良いので実用上は問題ありませんが。
]]>OLEDを接続して温度計測している様子
Raspberry pi pico で時計を作る話の続き。
取り敢えず意図した動作は得られました。tinygo のコンパイル結果は次の通りです。
code data bss | flash ram
95532 1784 3624 | 97316 5408
プログラムサイズ 97k というのが、やっていることの割にやたら大きくて「牛刀を持って鶏の首を刎ねる」といった感じですが、まあ、こんなもんでしょう。
Ticker のチャネルが返すのは Time なので、Ticker作成時に実時刻に設定できれば時計処理がもう少し簡単になるのになあ、と思いました。裏技的な何かがあるのかも知れませんが。
今後追加したい機能はアラームと時刻の手動設定です。アラームはともかく、手動設定はよく考えて望まないと嵌りそうではあります。
消費電力は計っていませんが、OLEDが50mA以上消費するのでバッテリー動作は最初から考えていません。サーバー代わりのPCに繋いで使うつもりです。
メインルーチンの抜粋を載せます。
go bme280_measure ()
for {
select {
case <-bme280_measure_ch:
bt.Reset(1e9*60)
case <-tokei_display_ch:
dt.Reset(1e9/2)
case <-ticker.C:
mu.Lock()
unixtime += 1
mu.Unlock()
case c:= <-linein_ch:
switch c {
case 0x00:
break
case 0x11:
// DC1 時刻補正
linein_command = c
case 0x12:
// DC2 シリアルにbme280の計測結果を返す
fmt.Printf("%f %f %f", temp_f, press_f, hum_f)
default:
switch linein_command {
case 0x11: // DC1 時刻設定
linebuf[linebuf_pos] = c
if c == 0x0a {
// 引数の終わりを検出
linein_command = 0
tmp := atoi_linebuf()
mu.Lock()
unixtime = tmp
mu.Unlock()
} else {
linebuf_pos++
if linebuf_pos >= linebufsize {
// バッファオーバーフロー
// 命令を無効として廃棄
linein_command = 0
linebuf_pos = 0
}
}
default:
println("Invalid command")
}
}
lt.Reset(1e9/100)
}
}
bme280による計測は1分毎、OLEDの表示更新は0.5秒、時刻更新は1秒毎、USBシリアルのポーリングは10msです。これが1番無駄使いですね。
bme280による計測結果は大域変数に保存しています。電源投入直後にに0.0C 0.0%とか表示されると格好悪いので最初に1回計測しています。
このbme280_measure ()はチャネルを返すので go routine として呼ばないといけません。最初、この事に気づかず暴走してしまいしばらく悩みました。
既知の問題点
OLEDの更新が止まる
数時間動かしていると止まる。表示更新ルーチンにボード上のLチカを残していて、そちらは点滅しつづけるので全体で暴走している訳ではなさそう。
一番あやしいのがI2C周りで、プログラムはraspi zero用にCで書いたものをそのまま移植している(こちらは数ヶ月レベルで問題なく動く)。一応、命令書き込み後のディレイも残してある。設定はraspiと同じ100kHzだがそれでも早いのかも知れない。なお、raspi のI2Cの速度は額面割れしているらしい。
先は長いな。
]]>
最近の、というか go modules 有効後のgoではローカルパッケージのimportに
import "./hoge"
を使うことができない。(エラーメッセージを吐いて終わる。)
対策
ソースには仮のインポート先を書いて、go mod に置換定義を書く。
import "huga.piyo/hoge"
go mod
module fugafuga
go 1.18
replace huga.piyo/hoge => ./hoge
localhostや自宅サーバーを参照すれば良いのでは、というのは試していない。
]]>
このうち、1と2はタイマで実行できるので良いとして、問題は3のUSBシリアルなのですね。
当初、単純にループで入力待ちを組んだのですが、タイマ側のルーチン(いわゆるgoroutine)が動作しませんでした。tinygoについていろいろググって探したところ、現状ではこれが仕様のようです。
pythonなんかだと、ループ内に yield を置いて一時離脱できます。go はループ処理についてはシンプルにforだけにしているのだから、yieldもあって良いと思うのですが。私が知らないだけかしらん。
今回はUSBシリアルの読み取りもタイマ任せにしました。処理がちょっと煩雑で注意して書かないと読みにくくなりそうです。うーむ、シリアルからのイベント割り込みが使えると良いのですが。
まあ、それなりに正確そうなタイマが使えるので今回は深く追求しない事にしましたよ。
時計関係は time パッケージにまとめられています。Unix秒から時刻を計算する機能があるので、秒カウンタを自分で管理すれば簡単に実現できそうです。
当然ロケールを設定すればUTCとの時差も直してくれるのだろう、と思っていたのですが。
動かないんですね、これが。
PC上でgo で同様のコードを試すとちゃんと反映されます。どういうことかというと、本来ロケール情報などというものは、OSから貰ってくるもので言語側で管理するものではない、という事なのですね。PCではLinuxやWindowsで管理していますが、マイコンボードにはそんな便利な機能はないという、考えてみれば当然の事でした。
で、どうするか。
ひたすらググった結果、何とか対策を得ました。それは、
time.Local = time.FixedZone("Local", 9*60*60) // JST
time.LoadLocation("Local")
という具合に、自分で"Local"を設定するというもの。納得。
いやちょっと待て。time.Localって何?
例えばI2Cは
const (
I2C0_SDA_PIN = GP4
I2C0_SCL_PIN = GP5I2C1_SDA_PIN = GP2
I2C1_SCL_PIN = GP3
)
と定義されていますが、I2C0もI2C1もこの定義以外の他のピンで使うことができます。I2Cの初期化時には必要なピンを「GPn」で指定すればそのピンで使えるようになります。
公式サイトには「ある機能が全てのピンで使える訳ではありません」的な事が書かれていて、それはまったくその通りなのですが、もう一言足りないのでは、と思います。
プロトタイピング向けには、機能限定で臨むのは理解を速める点で有効だとは思いますが。
]]>
まず、意外だったのはきちんとしたリファレンスが「ありそうでない」という事。公式のマニュアルを読めば大丈夫だろう、と思っていたのですが、細かい部分で分からない事に遭遇した時、対策を見つけ出すのが一苦労です。
オープンソースなんだからソース読め、ということなんでしょうが、いかに学習コストが低いとはいえここ1,2年程の経験しか無い身としては、Cのソースを読むようには行かないのでした。
次にプログラミングスタイルですが、日頃gtkやglibを使っているのでコールバックスタイルや、イベントループ投げ込みスタイルが染み付いており、チャネルを使っての同期スタイルに馴染むまでちょっとかかりました。勿論、Linuxでもチャネル(及びソケット)を扱うことはありますが、根本的に慣れていないのですね。
それとpicoprobeと互換性がないのも面倒です。picoprobeを使うといちいちボード上のbootselを押して電源を入れ直す事をせずに、プログラムの書換とシリアルポートによるモニターが使えます。tinygoでも勿論使えるだろう、と思っていたのですが、シリアルポートはUSBシリアル限定のようでfmt.Printfや(組み込みの)println はそちらに出力されます。USB以外にシリアルポートを選べれば良かったのですが。プログラムの書き換えはpicoprobeで引き続き可能ですが、USBケーブルを2本使うという大げさ加減に嫌気して外してしまいました。この辺は工夫すれば何とかなりそうな気がするので、いずれ調べてみたいと思います。
2年ほど動かしたのだが、作った3台が次々に故障してしまうトラブルが発生した。詳しい原因は調べなかったのだが、自作したコードにサーバーからの応答がない場合に連続送信状態に陥ってしまうバグがあり、発熱による経時劣化ではないかと考えている。また、電圧低下時に見切りシャットダウンするようにしていなかったのも、CPUの動作的にはうまくなかったはずだ。
住んでいる部屋は狭いので、まあ1箇所測ればいいよね、ということでそれ以降はraspberry pi zero にBME280を移植して測定を続けていたのですね。
で、このzeroですが一つ問題があってラジオを聴いている時に温度や湿度を見ることができません。というのは、局情報や曲情報を表示しているからです。まあ、プログラムを直して割り込んで表示できるようにすれば良いのですが、何か面倒だし(※1)、BME280が1つ遊んでいるので、ならばもう1台温度計を作ろう、と思ったわけです。
zeroの手持ちは後1台しかありません。最近の円安でzeroも安くないし、温度計測だけにLinuxを持ち出すのもどうかと思いました。「積みマイコン」はいろいろあったのですが、今回は同じraspiということでpicoを使うことにしました。
開発は最初Cでやる予定でした。というのは、zeroのプログラムをCで書いた(最初はpythonだったのをCで書き直した)ので、移植しやすいかも、と考えたからです。
しかし、zeroはLinuxということもあり、glibを使いまくっていたのでそのままpicoに持ってくる訳にはいかず、BME280の読み書きあたりは問題ないものの、メインルーチンあたりはまるまる新規開発しなくてはならない感じでした。
うーむ、picoに慣れる意味でもCで書いたほうがいいんだがなあ、と思いつつ、他の開発環境を物色(?)し始めたのですね。
まず、公式のMicroPython 及び 派生のCircuitPython (逆だったかも知れない)は、ありふれているのとコジンテキにpythonが余り好きでない事から真っ先にボツにしました。
次に eLua の移植があることを知って検討しました。というのは、ESP-WROOM-02の時の開発環境がNodeMcuで、その時の言語がLuaだったからです。
しかし残念ながら利用者が余りいないようだったので今回は見送りました。
最後に、以前から気になっていたtinygoを試すことにしました。go はPC上で簡単なコードをいくつか書いた経験があり、単純なCプログラマの私としては書きやすさ(学習コストの低さ)と目的への速達性とで魅力的だったのですね。
ということで tinygo on raspberry pi pico で、温度計を作ることにしたのですが。
これが思いの外、手間でした。
※1
ソフト側を直す前に、長らくバラック配線のままなのでケースも作らなくてはならず、やることがまとまり過ぎて萎えるのですな。
]]>縦長で使っているところ。xfce4を流用する上で一番の問題は実行中のアプリケーション一覧(キーボード操作でいうところのalt+tab)を出せない事で、滅多に使わない「ウィンドウメニュー」プラグインで凌いでいる。
atom を積んだタブレットPCをLMDEで使っている。
ファンレスで埃の吸い込みを気にしなくて良いことから、枕元に置いて寝床PCにしています。それなりに使えますが、UIがデスクトップの流用(Xfce4)なので本物(?)のタブレットに比べると使い勝手はよくありません。
ハード的にはwacomの感圧と電磁誘導を積んでおりLinuxから使えるようになっているので、アプリケーション層までの間に何か挟めば、使えるジェスチャーが増えるはずです。
ネットを漁ったところ、touchegg というデーモンを見つけたので試してみました。
https://github.com/JoseExposito/touchegg#installation
LMDEではppaの追加ができなかったので(余談だがLinuxMint20.3ではリポジトリに収録されている)ソースファイルをダウンロードして自前でビルドしました。というより、ppaで扱うのはamd64だけのようで、今回のタブレットPCはi686で動いているのでどのみち自前ビルドしなくてはならないようです。
ビルド環境はcmakeになっていたので、cmakeをインストールして
mkdir build; cd $_ 等としてから
cmake .. です。
ランタイムライブラリは1つ不足していただけで他はdevファイルの不足だったので、OS(debian)やデスクトップで標準的に使用されているライブラリで構築されているようです。
終わったら、
sudo make install
sudo systemctl enable touchegg
sudo systemctl start touchegg
このままではダメで、クライアントが必要なので端末から
touchegg &
xfce4の場合は、「設定」→「セッションと起動」→「自動開始アプリケーション」でtouchegg を新規に設定すれば、次回ログインから使えるようになります。
さっそくいろいろと試したところ、chromium で(ハードが遅いためレスポンスが悪く実用的でないものの)ピンチングが使えるようになりました。また、デスクトップでは3本指でウィンドウの左右タイリングや、5本指(4本指かも知れない)での画面回転(注1)が動作しました。
2本指スクロールは使い勝手が悪くて廃止したそうです。gtk3が対応しているのでほとんどのアプリケーションでは動いているように見えます。しかしgtk3での実装が今ひとつオカシイ(2本めの指が着地する前に、1本目の指が押さえたハイパーリンクやボタンのクリックが動く)ので、やはり使い勝手はよくありません。
参考URL
https://wiki.archlinux.jp/index.php/Touchegg
注1
デフォルトの設定で、4本指のIN動作に SuperL+A が割り当てられていたためでした。SuperL(タブレットのベゼル上のWindowsボタンを押すとこのコードが生じる)に自作のrotateプログラムを割り当てていたため、画面回転していました。
<gesture type="PINCH" fingers="4" direction="IN">
<action type="SEND_KEYS">
<repeat>false</repeat>
<modifiers>Super_L</modifiers>
<keys>A</keys>
<on>begin</on>
</action>
</gesture>
2022年8月11日16時追記
]]>
Raspberry Pi Pico C/C++ SDK の機械翻訳。
2.7.2. Floating-point Support
SDK は、高度に最適化された単精度および倍精度浮動小数点実装を提供します。 高速であることに加えて、多くの機能は実際に RP2040 ブート ROM で提供されるサポートを使用して実装されています。 これは、コードから ROM 浮動小数点ライブラリへのインターフェイスがプログラム サイズに与える影響が非常に少なく、コンパイラに付属の標準浮動小数点ルーチンを含めるよりも確実にフラッシュ ストレージの使用量が大幅に少なくなることを意味します。
RP2040 上の物理 ROM ストレージにはシングル サイクル アクセスがあり (RP2040 バスファブリック上の専用アービタを使用)、ここに格納されているコードにアクセスしてもフラッシュ キャッシュに圧力をかけたり、メモリ内のスペースを占有したりすることがないため、ルーチンが高速であるだけでなく、 コードの残りの部分は ROM に常駐するため、より高速に実行されます。
この実装は、ほとんどの場合に最適な選択であるため、デフォルトで使用されますが、通常のコンパイラのソフト浮動小数点サポートの使用に切り替えることもできます。
2.7.2.1. Functions
SDK は、 math.h のすべての標準関数の実装を提供します。 追加の関数は pico/float.h および pico/double.h にあります。
2.7.2.2. Speed/Tradeoffs
bootrom 浮動小数点ルーチンの全体的な目標は、小さなフットプリントで良好なパフォーマンスを達成することであり、基本的な演算 (加算、減算、乗算、除算、平方根、およびすべての変換関数) のパフォーマンスの向上に重点が置かれています。 科学関数 (三角関数、対数、指数関数) のフットプリントの削減について詳しく説明します。
IEEE の単精度および倍精度データ形式が全体で使用されますが、コード サイズを削減するために、入力デノーマル値はゼロとして扱われ、出力デノーマル値はゼロにフラッシュされ、出力 NaN は無限大としてレンダリングされます。
最近位への丸め、偶数同位丸めモードのみがサポートされます。 トラップはサポートされていません。 入力 NaN を無限として扱うか伝播するかは構成可能です。
5 つの基本演算 (加算、減算、乗算、除算、平方根) は、常に正しく丸められた (最近似への丸め) 結果を返します。
科学関数は常に、正確な結果から 1 ULP (最後の位の単位) 以内の結果を返します。 多くの場合、結果は良くなります。
科学関数は内部固定小数点表現を使用して計算されるため、結果を浮動小数点に戻す際に大きな正規化シフトが必要となる状況では、精度 (絶対値ではなく ULP 誤差で測定) が低下します。 これは、たとえば、pi の倍数に近い値のサイン、pi/2 の奇数倍に近い値のコサイン、または 1 に近い値の対数を計算するときに発生します。結果が非常に大きい場合、正接関数の精度も低くなります。 これらのケースをカバーすることは可能ですが、コードのフットプリントが大幅に増加するため、これらの状況での正確さが不可欠なプログラムの種類はほとんどありません。
次の表は、ベンチマークの結果を示しています。
ノート
SDK 浮動小数点サポートは RP2040 ブートROMのルーチンを利用しますが、コンパイラが提供する機能とほとんど区別できないように、生の ROM 関数の制限の一部 (制限された sin/cos 範囲など) を隠しています。 限られたブートローム領域の外でさらに高速化するために、特定の小さな機能も再実装されています。
2.7.2.3. 構成と代替実装
3 つの異なる浮動小数点実装が提供されています
名称 | 説明 |
---|---|
default | デフォルト;picoと同等 |
pico | 高速/コンパクトな SDK/ブートローム実装を使用する |
compiler | 標準コンパイラが提供するソフト浮動小数点実装を使用する |
none | すべての関数をランタイム アサーションにマップします。 何らかのライブラリによって誤って取り込まれないようにするために、浮動小数点サポートが不要であることがわかっている場合に、これを使用できます。 |
これらの設定は、「float」と「double」の両方に対して個別に設定できます。
「float」の場合、CMakeLists.txt で pico_set_float_implementation(TARGET NAME) を呼び出して特定のターゲットの特定の実装を選択するか、CMake 変数 PICO_DEFAULT_FLOAT_IMPL を pico_float_NAME に設定してデフォルトを設定できます。
「double」の場合、CMakeLists.txt で pico_set_double_implementation(TARGET NAME) を呼び出して特定のターゲットの特定の実装を選択するか、CMake 変数 PICO_DEFAULT_DOUBLE_IMPL を pico_double_NAME に設定してデフォルトを設定できます。
ヒント
pico 浮動小数点ライブラリによってバイナリ サイズが増加することはほとんどありませんが、初期の Raspberry Pi Pico ボードに存在するブート ROM の V1 に存在しない、使用される関数の実装を含める必要があります。 ブート ROM の V2 で RP2040 のみを使用していることがわかっている場合は、PICO_FLOAT_SUPPORT_ROM_V1=0 および PICO_DOUBLE_SUPPORT_ROM_V1=0 の定義を指定して、余分なコードが含まれないようにすることができます。 V1 ブートROMを備えた RP2040 でこれらの関数を使用すると、実行時にパニックが発生します。 ブートロム機能の具体的な詳細については、RP2040 データシートを参照してください。
2.7.2.3.1。 NaN の伝播
SDK 実装はデフォルトで入力 NaN を無限として扱います。 NaN 入力を出力に伝播し、ドメイン エラーに対して NaN 出力を伝播する必要がある場合は、実行時のオーバーヘッドを少し犠牲にして、コンパイル定義 PICO_FLOAT_PROPAGATE_NAANS および PICO_DOUBLE_PROPAGATE_NAANS を 1 に設定できます。
2.7.3. ハードウェアディバイダー
SDK には、RP2040 ハードウェア除算器によって高速化される、最適化された 32 ビットおよび 64 ビット除算関数が含まれています。
C の / および % 演算子とシームレスに統合されています。 SDK は、32 ビットと 64 ビットの商関数と剰余関数を組み合わせた高レベル API も提供しており、これもハードウェア除算器によって高速化されます。
32 ビットと 64 ビットの整数除算器の比較については、図 1 と図 2 を参照してください。
datasheetの機械翻訳
2.6.1. ROM
16kB の読み取り専用メモリ (ROM) はアドレス 0x00000000 にあります。 ROM の内容はシリコンの製造時に固定されます。
次の内容が含まれます。
• 初期起動ルーチン
• フラッシュブートシーケンス
• フラッシュプログラミングルーチン
• UF2 をサポートする USB 大容量ストレージ デバイス
• 高速浮動小数点などのユーティリティ ライブラリ
チップのブート シーケンスはセクション 2.8.1 で定義されており、ROM の内容についてはセクション 2.8 で詳しく説明されています。 RP2040 ブートROMの完全なソース コードは、次の場所から入手できます。
ピコブートローム
ROM はシングルサイクル読み取り専用バス アクセスを提供し、専用の AHB-Lite アービタ上にあるため、他のメモリ デバイスと同時にアクセスできます。 ROM への書き込みを試みても効果はありません (バス障害は生成されません)。
2.6.2. SRAM
合計 264kB のオンチップ SRAM があります。 これにより複数のマスターのメモリ帯域幅が大幅に向上するため、物理的には 6 つのバンクに分割されますが、ソフトウェアでは単一の 264kB メモリ領域として扱われる場合があります。 各バンクに格納されるもの (プロセッサー コード、データ バッファー、またはそれらの混合物) には制限はありません。 4 つの 16k x 32 ビット バンク (各 64kB) と 2 つの 1k x 32 ビット バンク (各 4kB) があります。
バンキングは SRAM の物理的な分割であり、複数の同時アクセスを可能にすることでパフォーマンスを向上させます。 論理的には、264kB の連続したメモリが 1 つあります。
各 SRAM バンクは、専用の AHB-Lite アービターを介してアクセスされます。 これは、異なるバス マスターが異なる SRAM バンクに並行してアクセスできることを意味し、システム クロック サイクルごとに最大 4 つの 32 ビット SRAM アクセス (マスターごとに 1 つ) を実行できます。
SRAM は、0x20000000 から始まるシステム アドレスにマップされます。 最初の 256kB アドレス領域は 4 つの大きなバンクにわたってワードストライプされており、ほとんどの使用例でメモリ並列処理に大きな利点が得られます。
システム アドレス空間内の連続するワードは、表 153 に示すように、異なる RAM バンクにルーティングされます。
次の 2 つの 4kB 領域 (0x20040000 と 0x20041000 で始まる) は、より小さな 4kB メモリ バンクに直接マッピングされます。
ソフトウェアは、コアごとの目的でこれらを使用することを選択する場合があります。 スタックと頻繁に実行されるコードを処理し、これらのアクセスでプロセッサが停止しないことを保証します。 ただし、RP2040 上のすべての SRAM と同様、これらのバンクは、同じサイクルで他のマスターがバンクにアクセスしていない限り、すべてのマスターからシングル サイクル アクセスを行うため、メモリを単一の 264kB デバイスとして扱うのが合理的です。
4 つの 64kB バンクは非ストライプミラーでも使用できます。 0x21000000 、 0x21010000 、0x21020000 、 0x21030000 で始まる 4 つの 64kB 領域は、それぞれ 4 つの 64kB SRAM バンクの 1 つに直接マッピングされます。 ソフトウェアは物理メモリ バンク全体にデータとコードを明示的に割り当てることができるため、要求が非常に厳しい場合のメモリ パフォーマンスが向上します。 メモリ ストライピングは通常、ソフトウェアの複雑さを軽減しながら十分な並列処理を提供するため、これは多くの場合不要です。
非ストライプミラーは、SRAM ベースの +16MB 上のオフセットから始まります。これは、より小さなバンクと非ストライプのより大きなバンクの間で ARMv6M サブルーチン呼び出しを許可する最大オフセットであるためです。
2.6.2.1. その他のオンチップメモリ
264kB メイン メモリの他に、状況によっては使用できる専用 RAM ブロックが 2 つあります。
• フラッシュ XIP キャッシュが無効になっている場合、キャッシュは 0x15000000 から始まる 16kB メモリとして利用可能になります。
• USB を使用しない場合、USB データ DPRAM は 0x50100000 から始まる 4kB メモリとして使用できます。
これにより、合計 284kB のオンチップ SRAM が得られます。 これらのメモリの使用方法には制限はありません。 必要に応じて、USB データ RAM からコードを実行することができます。
openocd を使ってデバッグする際、ターゲットとなるpico に接続するプローブが必要になる。
一番カンタンで安上がりなのは、もう1枚picoを用意する方法である。
雑誌やネット上でいろいろ散見するが、一番確実なのは公式サイトの記事、のはずなのだが。
openocd -f interface/cmsis-dap.cfg -f target/rp2040.cfg -s tcl
この記事を書いている時点では、interface/picoprobe.cfg ではなくてcmsis-dap.cfg が正解らしい。
ところが、このcmsis-dap.cfg をそのまま使うと接続できないので以下を加筆する。
adapter speed 5000
ビルド時に変更していなければ、ファイルは次の箇所にある。
/usr/local/share/openocd/scripts/interface/
しかし、これだけメジャーなマイコンボードで情報が溢れているにも関わらず、本件の解決方法を探すのに1日を費やしてしまった。openocdを自前環境でビルドしたこと(※)、プローブがブレッドボードを用いた自作品な事から、ハード・ソフトともに確実性を欠いてしまったため、問題の切り分けを難しくした。
比較のため、手元にあったraspi 3B+ をプローブにしてテストし取り敢えず動作したので、「openocd は良さそう」と判断したのが、状況悪化にさらに拍車をかけてしまった。
※picoprobe.uf2 は公式の既成品をダウンロードした。
]]>
先日からLinux(debian 12)をインストールしているが、最後まで動作しない部分について。
PCMCIA
lspci
06:07.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b1)
Subsystem: NEC Corporation RL5c476 II
Flags: bus master, medium devsel, latency 168, IRQ 11
Memory at b0141000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=06, secondary=07, subordinate=07, sec-latency=176
Memory window 0: 54000000-57ffffff (prefetchable)
Memory window 1: 58000000-5bffffff
I/O window 0: 00006400-000064ff
I/O window 1: 00006800-000068ff
16-bit legacy interface ports at 0001
Capabilities: <access denied>
Kernel driver in use: yenta_cardbus
Kernel modules: yenta_socket
なお、このPCにはCFカードスロットも搭載されているが、こちらは正常に動作する。
バッテリーの情報が取得できない。
/sys/class/power_supply/ に ACAD は出現するが、BAT0 等が存在しない。
]]>
使えるウェブブラウザがない!のですね。
firefox-esr は動作はするが、ublock を入れようとアドインの管理画面を開こうとすると100%クラッシュします。
それでは、とxpiファイルを直接入れようとしてもクラッシュしたので、おそらくPentiumMでは使えない命令でも実行しているのでしょう。
chromium はSSE3がどうのこうの、というエラーを表示して起動すらしないし、最後の手段としてseamonkey を使う事にしたのでした。
問題はseamonkey では ublock が動作しない(らしい)事で、それでもgithub には対応したソースらしきものもあるのですが、流石に面倒なので見送っていました。
要は広告を表示しなければ良いので、昔ながらのhosts でやろう、ということでネットを漁って見つけたリストを入れました。
hostsで対策するならfirefoxでも良いのでは?という気もしてきました。seamonkey だから軽い、等と言うことはなく、メールサーバーにアクセスしたりするのでむしろ重くなるケースもあるのでは、と思います。
まあ、ウェブブラウザとメーラー2つをインストールするよりはストレージを圧迫しない(と言われている)利点はあるのですが。
うーむ、今ひとつ決定打に欠けます。
]]>
適当に公開するディレクトリを決めて、パーミッションを777にしておく。
リポジトリからsambaをインストールする
設定ファイルを調整する
/etc/samba.smb.conf
末尾に公開するディレクトリに付いて書く
[hoge]
path = /hoge/fuga // 適当に決めた公開ディレクトリのパス
read only = no
guset ok = yes
設定の点検は testparm を実行する。
ポートを開ける
sudo ufw allow 445/tcp
※再起動して設定を有効にする sudo ufw reload
ユーザーの追加
例えば useradd -s /bin/bash -m hoge
passwd hoge
※ゲストのみや、(サーバー側の)既存のユーザーを流用するなら不要
sambaパスワード (ubuntu, debianの場合、らしい)
smbpasswd -a samba
samba再起動
sudo systemctl restart smbd
クライアント側の準備
Windowsの場合は特に必要ない
Linuxの場合
ファイルマネージャから smb://サーバーのIPアドレス(zeroconfが使えるならhoge.local)
これでアクセスできなければ、
レポジトリからgvfs-backends をインストール (debianの場合)
注意点
/etc/samba/smb.conf の中の、IP割り当て箇所は不用意に触らない事。
ファイルマネージャからsambaサーバーにアクセスする
リポジトリからgvfs-backendsをインストールする。
アイコンはリポジトリにある
Mint-Y
スタイルがないので、LMDEからもらってくる。
/usr/share/themes/Mint-Y-Dark
フォントはとりあえずリポジトリから fonts-noto-cjk を入れる。
同じく libxapp-dev をインストールする。LinuxMint 向けに書いたアプリケーションをビルドするのに必要。
2023年7月15日追記
リポジトリより bibata-cursor-theme をインストールする。これってplasmaのデフォルトテーマだったんだ、知らなかった...
2023年7月16日追記
下記忘れていたが IM を変更。fcitx5およびfcitx-mozcをインストールした後、uimとuim-mozcを削除。
fcitx5はmetaらしく、必要なものを入れてくれる。gtk3及びgtk4のfrontendも入れてくれるが、 gtk2用はインストールされない。
]]>
他のPCのOSはLinuxで、もっぱらsshfsを使っているので。Windowsでも可能なのかも知れないが、やはりsambaでアクセスすべきでしょう。
ということで、既設のファイルサーバーにsambaを立てたのですね。
windowsからのアクセスは当然として、Linux(LinuxMint)からでもファイルマネージャ経由で当たり前のようにアクセスできたのには驚きました。
確か昔はsmbclientか何かの世話になったはずですが。ps してみたらgvfsが頑張ってくれているようです。
楽な世の中になりました。
いろいろいじっていて、Windows10側にsshが入っていることに気づきました。買ってきて直ぐに初期化してアップデートしているので、標準装備なんだと思います。sshがあれば当然ssh-keygenもあるわけで、相手方にpubキーを登録すれば Linuxの時と同じようにサーバーアクセスできます。
そのほか、Windows10にはセキュリティ対策も標準で入っているんですね。どこまで当てになるか判りませんが。とりあえずは安心して良いのでしょう。
稼業の勤務先ではオフィスに半固定のノートPC及びそれのリモートアクセス用にSurface Proを貸与されていて、Windowsは日常的に使っている訳ですが仕事道具となれば自分勝手にシステム周りを弄るわけにもいかず、何かあれば総務のPC係に丸投げなので余り気にしていなかったのですね。
実にXP以来、vista, 7, 8, 8.1, と4世代の時を超えてのWindows体験は結構面白いです。
]]>
写真の処理(フィルムスキャン)に長らく WindowsXPを使ってきたのだが、動作の遅さとセキュリティ問題でLANも含めてネットから隔離している事による使い勝手の悪さに耐えかねたのですね。
で、秋葉原の中古屋の店頭にて一番安かったノートPC(第6世代CPUでメモリ4GB、mSATA)を13000円程で買ってきました。スペックが旧いのは勿論、外見が打痕だらけだったのでこの値段です。
部屋に戻ってきて初めて分かったのだけれど、180度折り返してタブレットとして使えるというものでした。けど、ヒンジ部分がいかにも華奢で折り返す気が起きないです。
さて。
用済みになったWindowsXPノートですが、当然のことながらLinuxを入れることにしました。32ビット機なのでdebian一択です。
まず最初にストレージを交換しました。XPにおける動作の遅さはHDDも原因の一つだったので。とはいえ、新しいIDEHDDなんてないので、IDE-SD変換基板をかまして手持ちの8GB SDで代用しました。
インストーラのブートは当初ネットワークブート(PXE)にしようとしたのですが、このPCを買った時に純正の外付CD-ROMやFDDがおまけに付いてきたのを思い出し、引っ張り出して繋いだところ正常に動作したのでCDからインストールすることにしました。
debian12に先立って取り敢えずハードの旧さにあわせたOSを、とPuppyLinux431JPを試したのですが正常に動作しました。このまま使おうかと思ったくらいです。今になって思うと本当にそうすれば良かったのかも知れません。
次にdebianですが、本当は debian 10にしたかったのですが、何故か インストールイメージが最新の12しか見つけられず。このあと、新しいのが原因なのか、いろいろ問題が発生するのですね。
インストールイメージが700MBなので「本当の」ブランクCDが必要なのですが手元にはCD-RW(650MB)とDVDしかありません。
直接debianを起動させるのは早々に諦めて、plop bootを使うことにしました。早速メインPCで焼こうと思ったのですが、意外にもライタソフトがインストールされていませんでした。まあ、確かに使わないしね、今どき。リポジトリからxfburnを入れて解決。
同様にdebianはUSBメモリへ書き込んで、目論見通り plop からUSBメモリのdebianを起動させることに成功しました。plop側でUSBの設定が必要で一瞬焦ったりもしましたが。
debianはストレージの容量が小さいことからスワップなしでLXDEをインストールしました。RAMが1GBあるのでスワップ無しでも行けると踏んだ訳ですが、無事最後まで完走しましたよ。
ひとまず順調。いよいよここからヤラカシます。
LXDEを使ってみたが、日頃xfec4なので今ひとつ使いにくいことと、何故か lxtermが起動しなくなるという謎挙動にも遭遇したのでxfce4に変えることにしました。
ここでxfce4を追加インストールすればよかったのですが、ストレージの空き容量(この時点で2GB強)が心もとなかったので、別コンソール(ctrl+alt+f5とか)でログインしてLXDEをremoveし、xfce4を入れようとしたのですね。
LXDEを削った途端、何故かネットワークに繋げなくなりました。原因究明とか途中で面倒くさくなったので最初から全部やり直しましたよ。いやはや。
xfce4の設定を終え、次に無線LANを導入しようとしました。手元にはUSBドングルもありましたが、このPCにはPCMCIAがあるのでそちらでやろうとして、リポジトリからb43のファームを入れた(※)のですがウントモスントモいいません。
まあ、PCカードの無線LANなんてもはや骨董品だから動かなくて当然か、とUSBドングルで行くことにしました。しかしこちらも問題があって、何故かドライバは自分でビルドしなくてはならないのですね。ライセンスの問題かなにか知らんけど。dkmsがあるので一度入れてしまえば後は大した手間ではないですが、今回はストレージが容量の小さいSDカードなのでちょっとだけ気になります。
で、無線LANを通してからふと気になって件のPCMCIAに、手持ちの他のカード(有線LANとかUSB2.0の増設カードとか)差してみたらどれも認識しません。ファームが不足しているのはこっちだったんですね。メインPCにもPCMCIAはあって、こちらは特に問題なく動作するので「LinuxってまだPCMCIAの面倒見てくれてるんだなあ」くらいの認識でした。
それと、タッチパッドを認識しません。libxinputだからかしらん、とSynapticsを入れてもダメ。これはちょっと難しいかも。
2023年7月16日追記
タッチパッドへの配線が外れていただけでした。このPCはストレージ交換の際パームレストを外す構造になっているのですが、その時にヤラカシたらしい。やれやれ。
しばらく動かしていて感じたのは冷却ファンがほぼ常時フル回転している事。WinXPの時はこんなことはなかったです。conkyいれてCPU負荷と温度をモニタしていると、負荷の軽い時でだいたい50℃くらい。室温が30℃前後なのでこんなものかも知れませんが少しうるさい。
次にソフト。
まず使えるウェブブラウザがないです。Firefox-esrは正常に動作しますがメモリ食いすぎる。(書き忘れたがzram-toolsを入れてzram0にスワップを取りました。)
webkit系はluakitを試したのですが、mesaがどうとかというメッセージを吐きまくって動作不安定に陥ること度々。しかたないのでnetsurfを入れましたが、こちらはjavascriptが使えないのでwikipedia閲覧くらいしか使えません。
どうせメモリ喰うなら使い慣れたchromiumを、と試したら sse3が何とか、といって起動すらしませんでした。流石chromium、コンソールへのエラーメッセージじゃなくてxdialogを開いて止まるあたり、きちんと作ってありますね。
メーラーの問題もあったので、いっそseamonkeyどうよ、と思って入れたのですがこっちはublockが使えないっぽい。アドオン一覧を見ると他のアドオンも2017年頃で更新が止まっているようでした。
メーラーもthunderbirdなんか使う気しないです。そうするとsylpheedしかないのですが、こちらは未だにgtk+2のまま。そういえばgmailは使えるようになったのかしらん。
うーむ。苦労した割には実用にならないですねえ。でも、折角なのでもうちょっと調べてみましょう。
※debianのインストーラはmain と Non-freeしか入れないので手動でcontribを追加した。
]]>
https://github.com/aircrack-ng/rtl8812au
LinuxMint20.3 (カーネルは5.15)で確認
7月4日追記
LinuxMint21(カーネルは5.15)で確認
]]>
設定ファイル(/etc/default/zramswap)で指定した圧縮アルゴリズムが反映されない。
関係するファイル
/etc/systemd/system/multi-user.target.wants/zramswap.service
/etc/default/zramswap
/usr/sbin/zramswap
/sys/block/zram$CORE
LMDEでは、
/usr/bin/zramswap の中で、modprobe した後、/sys/block/zram0に設定を送り込んでいる。
それを参考に、LinuxMint20.3の/usr/sbin/zramswapを改変する。
echo $ALGO > /sys/block/zram$CORE/comp_algorithm
ディスクサイズを設定する直前に置くと良い。反対だと失敗する。
エラーは sudo systemctl status zramswap で確認できる。
カーネル 5.4 及び 5.15で確認。
]]>
以前も記事にしていたが、積極的に使ってこなかったので。
debian 系ならパッケージを導入するだけで簡単に使える。(buster以降)
パッケージの導入
sudo apt install zram-tools
設定
/etc/default/zramswap
ALGO=zstd
PERCENT=50
再起動
sudo service zramswap reload
systemd 関係のファイルはここにある
/etc/systemd/system/multi-user.target.wants/zramswap.service
ブロックデバイスの確認
lsblk
swappiness は 60 のまま。PERCENTとの兼ね合いがどうなるか、使いながら確認したい。
raspiやネットブックで有効なのは勿論、然程メモリを使い切っていないような環境でもRAM上にswapを移す事でSSDやeMMCの延命に繋がると考えられる。
]]>
方法
mpvは動作時に生じるイベントをapiに開放しているのでそれを使ってフラグファイルを作成・消去する。
注意点
イベント file-loaded が生じない(他のイベントと合一化される)事があるので、曲名変更時にもフラグを立てるようにしておく。
~/.config/mpv/scripts/myscript.lua(抜粋)
function set_flag_file()
a = io.open("/run/user/1000/mpvflag","w")
if a ~= nil then
a:write("test")
a:close()
end
end
function on_file_loaded(event)
set_flag_file()
end
mp.register_event("file-loaded", on_file_loaded)
function on_end_file(event)
os.remove("/run/user/1000/mpvflag")
end
mp.register_event("end-file", on_end_file)
function on_media_title_change(name, value)
--~ 中略
set_flag_file()
end
mp.observe_property("media-title", "string", on_media_title_change)
用途
ラズパイにキャラクタ表示器を繋いでいろいろ表示させる場合、曲名表示を他の処理から邪魔されたくないような時に使う。
]]>