26-Feb-2022の仕事帰りに水が抜けているのを見かけたので、27-Feb-2022にコンデジで撮ってきました。

一時期他の地域で暮らしていたことがあるとはいえ、人生のほとんどの時間をこれがある地域で暮らしていた身としては、こんな光景を見るのは初めてで驚いています。とはいえ、実は過去に幾度かこうやって水を抜いて工事していたことがあり、それに気づいていなかっただけなのかもしれませんが。

なお、下九沢分水池周辺に工事のお知らせなどの看板が無いか見てみましたが、特にそれらしき物は見当たりません。浄水場に並ぶ重要な水道施設であるが故に、情報を秘匿しているのかもしれません（だったら工事が終わるまでweb日記のネタにするなと怒られそう…）。

Twitterで下九沢分水池をキーワードに検索してみると、15-Feb-2022の時点では既に水が抜かれていたようです。

おまけ。

行きがけに、近所の鳩川に取り付けられた水位計（上山谷橋水位計）を見てきました。

あんな電源の取れない場所によく水位計を…と思っていたのですが、M2B Communicationsによる危機管理型水位計(MW-001)のようです。内蔵されたバッテリーで5年程度動作し、測定したデータは携帯電話網を経由してサーバへ送られるようです。水位計の詳細は危機管理型水位計に関するポータルサイトにまとまっています。

15-Aug-2021の秋雨前線による大雨の時の水位グラフのスクリーンショットが残っていたので、折角なので上げておきます。56.3kg(07:35)

06-Feb-2022の続き。OpenBSDでのWSJT-Xのビルド、通るけどjt9が動かないという問題が未だに解決できていません。JTDXと比較するに、WSJT-Xのlib/decoder.f90をコンパイルする際にtrampolineを生成してしまい、これがSIGABRTを起こして動かなくなってしまう…ということが分かっています。また、gfortranに-fno-trampolinesを付けても状況が変わらないということも。

…って、Trampolines (GNU Compiler Collection (GCC) Internals)に"For languages other than Ada, the -ftrampolines and -fno-trampolines options currently have no effect, and trampolines are always generated on platforms that need them for nested functions."なんて書かれている以上、-fno-trampolinesを書いても無駄だったということですね。

そもそもどういう条件でtrampolineが作られるか分からないのでTrampolines for Nested Functions in GCCの記事にあるtest1, test2をOpenBSD-7.0/amd64のportsに入っているgcc-8.4.0で試してみましたが、test1（関数a()の中にある関数b()を呼ぶだけ）はtrampolineを作らないため問題なく動作し、test2（関数a()の中にある関数b()を、関数b()のポインタ経由で呼ぶ）はtrampolineを作るためにSIGABRTで止まります。-fno-trampolinesは、gfortran同様に効果がありません。その一方、cc(clang-11)では関数の入れ子を認めないようで、test1, test2ともにコンパイルエラーとなります。

プログラムの構造を見直し、-Wtrampolinesを指定してtrampolineが作られないことを確認する、くらいの対策しか思いつかないのですが、他に何かありますかね…？

gfortranがどうメモリ確保するのかなーというのが気になったので、Cray pointersやMALLOC、C_LOCを使ってこういうコードを書いてみたのですが、Cだと苦労せずにやれることをFortranでやろうとすると本当に難しいです。単に慣れていないのでそう感じるだけなのかもしれませんが。55.9kg(05:05)

USB非対応のJumboSPOTを、USB-UARTアダプタ経由でPCに繋げるための変換基板みたいなやつ。

USB-UARTアダプタのTXD/RXD/5V/GNDを結線し、TXD/RXDの信号レベルは3.3Vとします。JumboSPOT+bluetooth(JG3EBB)に倣い、3.3Vは基板に載せたLDO(DD0403MA)で生成させます。

あんまり参考にならない配線図。ちゃんと読めるのは部品面、鏡像になって読みづらいのは半田面。配線図にあるTXD/RXDはRaspberry PiのTXD/RXDに対応するため、USB-UARTアダプタのTXD/RXDもこれに合わせます。

実際の基板はこんな感じ。

BrandMeisterのTG91に繋いで2時間程度動かした感じでは、問題なさそうです。Raspberry Pi(Zero)サイズのPCBにまとまった変換基板があれば、PCでホットスポットを構築しやすくなるのではないかと考えます。56.4kg(14:35)

EdgeRouter LITE-3、動かなくなったのでOpenWrt化していますがまた動かなくなってしまいました。動かなくなった原因を探っても良いのですが、そこまでしなくてももう十分でしょう。とりあえず、予備機材として用意したpcDuino＋Wii向けのUSB-LANで対応しているものの、あくまでも非常用なのであまり長期間は使いたくありません。

という訳で、買っておいたNanoPi R2Cを投入します。最初に書いてしまいますが、現時点ではお金積んででもR2Sの方が絶対に良いです。FriendlyWrtは動作が怪しい感じがありますし（dockerを無効化するとNATが使えなくなるとか、起動してもLuCI側からmasqueradeを有効にする操作を行うまでNATが使えないとか）、OpenWrtも21.02.1および現時点のsnapshot共にMotorcomm YT8521に対応していないので、R2S用のものを使用するとWAN側のポートが動きません。

じゃあどうするか。普通ならおそらくOpenWrtのソースを用意して、YT8521用のパッチを当ててビルドするのでしょうけど…やり方がよく分からないので、NanoPi R2S用のOpenWrt＋RTL8152を載せたUSB-LANアダプタを付けてお茶を濁すことにしました。100Mbps動作になるとはいえ、オンボードのRTL8153と同じr8152ドライバで動くので面倒がありません。USBストレージ経由でドライバを入れることができればRTL8152以外でも動くのでしょうが、これについては未確認です。

ディスクイメージの書き込み

OpenBSD上で、zcat openwrt-21.02.1-rockchip-armv8-friendlyarm_nanopi-r2s-ext4-sysupgrade.img.gz | dd of=/dev/rsd1c bs=1m

起動とパスワードの設定

OpenBSDマシンとNanoPiをLANケーブルで接続（NanoPiとは別に、USB-LANアダプタを使うと楽なのでそうしている）。microSDをNanoPiにセットし、NanoPiに電源を繋いでしばらく放置。dhclient <LANアダプタに対応するデバイス名>でIPアドレスをもらって、ssh root@192.168.1.1でログイン。passwdコマンドでパスワードを適宜設定。

USB-LANアダプタの確認

USB-LANアダプタを接続し、ip addr show。eth2として認識されていればok。

firewallの設定

デフォルトの/etc/config/firewallで問題ないはず（zone wanの、input=REJECT, output=ACCEPT, forward=REJECT, masq=1であれば良い）。

WANポートの切替 (eth0→eth2)

uci set network.@device[2].name='eth2'; uci set network.wan.device='eth2'; uci set network.wan6.device='eth2'; uci commit 。uci showで、変更前のポートがeth0であることを確認してから修正すると良いかも。

DHCPの設定

uci set dhcp.@dnsmasq[0].domain='<ドメイン名>'; uci set dhcp.lan.startとlimitを適宜設定; uci set dhcp.lan.dhcp_option='6,8.8.8.8,8.8.4,4'; uci commit

LANポートの設定

uci set network.lan.ipaddr='<このルータが使用するIPアドレス>'; uci set network.globals.ula_prefix='<ULA prefix>'; uci commit

googleのスピードテストで速度を測ったところ、80Mbpsは出ています。pcDuinoの時とそんなに変わらないのを見るに、CPUではなく100MbpsのUSB-LANアダプタを使っていることが遅さの原因と言えそうです。

本題と全然関係ない話になりますが、所属店舗が明日から厚木市から相模原市の店舗に変わります。今までのお店は配属後少しの間は自転車通勤していたものの、COVID-19に絡む諸々により自動車通勤に切り替えて2年程度の時間が経ってしまいました。これからのお店は自転車で通勤することになりますが、そんな事情で筋力がかなり落ちているために自転車にうまく乗れるかちょっと心配です。

ESCAPE R 3(2015)を導入したのが26-Jun-2016、今年で6年になるとはいえ実際に乗っている期間は4年程度ということになるでしょうか。ちょっとくたびれた感じはありますが、昨今の自転車パーツ不足（による自転車自体の品薄）を考えるに、もうしばらくこれに乗り続けることになります。日頃お世話になっている自転車屋さんがGIANTの取り扱いを止めてしまったので、次はBRIDGESTONE XB1（CYLVA F24の後継）になるのでしょうか。

チェーン以外にスプロケット・クランク・BBを交換していますが、乗り換える前に、クランク・BBの再交換とホイールの交換を試したいと考えています。とはいえ、実際にやるかどうかは分かりません。55.5kg(21:50)

16-Feb-2022補足：RTL8153搭載のUSB-GbEアダプタに換えてみましたが、90Mbps…交換前(RTL8152)よりちょっと速いかなーという程度しか速度が出ません。1000Mbpsでリンクしていることは確認できているので、EHCI(USB2.0)接続であることが災いしてそうです（オンボードのRTL8153はxHCI(USB3.0)につながっています）。速度が出ないのにGbEのアダプタを使うのは勿体ないので、元のアダプタに戻しておくことにします。

27-Jan-2023補足：RTL8152搭載のUSB-LANアダプタ、不調です。一旦抜いて繋ぎ直すとしばらくの間はちゃんと動くのですが、その後止まってしまう（dmesgを見るとUSB関連のエラーメッセージだらけになる）という症状が見られたため、このアダプタは捨てて別のRTL8152搭載品に交換しましたというのが26-Jan-2023の話。1年経たずに壊れてませんかコレ…

JTDXおよびWSJT-XのビルドをOpenBSD上で試みているのですが、表題の通りということで。

とりあえずJTDXのビルドから始めていますが、CMakeLists.txtとdecoder.f90がOpenMP非対応な環境でのビルドに対応していない箇所があるのでその修正が必要だったり、127.0.0.1に対するUDPパケットの送信にIPv4-mapped IPv6 addressを使ってくるのでそれを使わないようにする対策が必要だったり、他にもまだまだ修正箇所がありそうな感じです。ビルドに必要なgfortran(egfortran)も自動検出できないので、cmake .. -DCMAKE_Fortran_COMPILER=egfortran -DQt5_DIR=/usr/local/lib/qt5/cmake/Qt5 のように指定する必要があります。

WSJT-Xのビルドも似たような感じで、OpenMP非対応な部分についての対策はJTDXと同様です。これに加え、std::numeric_limits<Frequency>::max()やlibmの取り扱いに違いがあるのか、うまくいきません。こちらは cmake .. -DCMAKE_Fortran_COMPILER=egfortran -DQt5_DIR=/usr/local/lib/qt5/cmake/Qt5 -DQt5Test_DIR=/usr/local/lib/qt5/cmake/Qt5Test のように、Qt5Testについても指示が必要です。

JTDX/WSJT-X、どちらも手強そうなので、まずはJTDXをきちんと動かせるようにしてみたいと考えています。54.5kg(22:15)

08-Dec-2021の続き。

OpenBSD/Linux上でbinutils+gcc+newlibを使用したwm-sdk-w806を構築し、Linux上から書き込むことはできていたのですが、OpenBSDもuchcom.cの更新に加えwm_tool他の修正を行うことで書き込めるようになりました。

ASCIIアートベンチマークによる速度の測定を行うべく、タイマーの使い方をサンプルプログラム(demo/tim)を参考にあれこれ調べていたのですが、どうも割り込みハンドラ内からprintf()を動かすと意図したように動いてくれないようです。UARTレジスタを直接叩くなり、wm_printf()なりを使う方が良さそうです。

また、HALを呼び出すことでユーザプログラム内に定義した以下のコードを実行するため、この部分に然るべきものを記述しないと全く動きません。

HAL_Init() (drivers/wm_hal.c)

→ HAL_MspInit()

HAL_TIM_Base_Init() (drivers/wm_tim.c)

→ HAL_TIM_Base_MspInit()

HAL_TIM_Base_DeInit() (drivers/wm_tim.c)

→ HAL_TIM_Base_MspDeInit()

サンプルプログラムを見るに、HAL_TIM_Base_MspInit()/MspDeInit()には割り込みの設定やクロックの供給を制御するコードを書くようです。今回は割り込みは使用せず、タイマーも一つしか使用していないので、クロックのon/offを行うコードだけ入れています。

タイマ割り込みハンドラの記述もちょっと面倒で、

• ユーザプログラム側に割り込みハンドラ__attribute__((isr)) void TIM0_5_IRQHandler(void)を記述
• 割り込みハンドラからHAL_TIM_IRQHandler(TIM_HandleTypeDef *)を呼び出す
• HALがユーザプログラム内のHAL_TIM_Callback(TIM_HandleTypeDef *)を呼び出す

という作りになっています。drivers/wm_tim.cやdemo/timの中身を読めばすぐ分かるという話でしょうけど…

W806内蔵タイマーのユニークな点として、1μsもしくは1ms単位でカウントしていく点が挙げられます。それ故に、APB clockの周波数(MHz)を設定するレジスタを装備しています（デフォルトの40MHz向け設定値で問題ないはずです）。なお、CPUクロックがAPB clockの倍数である必要があるのか、SystemClock_Config()には何でもかんでも設定できる訳ではないことが分かっています。

…という、一体誰の役に立つんだかという話は置いといて。

時間測定付きのASCIIアートベンチマークのソースコードと、そのログを転がしておきます。CPUが40MHz動作時は50121μs、240MHz動作時は8471μsということになるでしょうか。

折角なので、FPUを使わない状態での動作速度も見てみます。システムライブラリがFPUを前提とするコードを含んでいるためにtools/W806/conf.mkにある-mhard-floatを-msoft-floatに置き換えてしまうとビルドできなくなってしまうので、ベンチマークのソースコードを置いてあるところにあるapp/src/MakefileにCFLAGS += -msoft-floatを追加して試します。

FPUを使わない状態のログはこちら。40MHz動作時は797724μs、240MHz動作時は135073μsと、16倍程度遅くなっています。マンデルブロベンチマーク測定結果の一覧表と比較するに、このマイコンはFPUを活用できるアプリケーションだと活躍できるのかなと考えています。53.7kg(05:45)