NetBSD/evbarm on Allwinner Technology SoCsのSupported SoCsではNetBSD-9.0からAllwinner A10(sun4i)に対応するとあるので、それじゃあ-currentを試してみるかという話。Example boardsにはOlimex A10-OLinuXino-LIMEとあるものの、手近にあってすぐ動かせるpcDuinoでいきます。

構築手順はCrosscompiling NetBSD with build.shにあるとおり、cd /usr/src; ./build.sh -m evbearmv7hf-el tools; ./build.sh -u -m evbearmv7hf-el kernel=GENERIC releaseで。二つに分けなくても./build.sh -m evbearmv7hf-el tools kernel=GENERIC releaseと指示することもできますし、-j 5等のオプションを付けてマルチコアを活かすことも可能です。

構築物は/usr/obj/releasedir/evbarm-earmv7hfにあります。何もかもがgzipで圧縮されてしまっていますが、pcDuinoで必要なのはbinary/gzimg/armv7.img.gzとbinary/kernel/sun4i-a10-pcduino.dtb.gz。とはいえ、OpenBSD機上でmicroSDカードを作ってしまうのでarmv7.img.gzだけあれば十分です。

microSDカードの作成は、

NetBSDイメージの書き込み

zcat armv7.img.gz | dd of=/dev/rsd1c bs=64k

Device Tree Blobの書き込み

mount /dev/sd1i /mnt; cp /usr/local/share/dtb/arm/sun4i-a10-pcduino.dtb /mnt; umount /mnt

U-Bootの書き込み

dd if=/usr/local/share/u-boot/Linksprite_pcDuino/u-boot-sunxi-with-spl.bin of=/dev/sd1c bs=1024 seek=8

こんな感じで。これを書いている時点ではBOOT/EFI/bootarm.efiは-currentで作成したものではなくNetBSD-9.0_RC1付属のものを使わないと起動しないので（とJared McNeillさんからのツイートによるアドバイス、感謝！）、入れ替えておきます。

dmesgはこんな感じ。

とりあえずNetBSD/evbarmを構築〜動作させるまでの手順は分かったので、安心して年を越せそうです。60.00kg(14:40)

本当は28-Dec-2019で今年の日記を終わらせるはずだったのですが、まさか救急車に患者として乗る事態になるとは…これも初めての経験なのですが。

とはいえ、ワンカップ大関180mL×1飲んで酔ってトイレで派手に倒れただけなのですけど、どうもしばらくの間意識を失っていたらしいんですよね（実際、倒れた前後の記憶が無い）。近隣の脳外科でCT撮って問題は無かったけどしばらく安静な、ということで今日は自宅から出られません。1759日続いたSojournerは切らすことになりそうです。

迷惑をかけた妻と両親にはこの場を借りてお詫び申し上げます。59.20kg(11:00)

祖母が亡くなったり生まれて初めて腕の骨にヒビ入れてみたり（一応骨折ということになる）、色々ありました。今月に入ってからは仕事場が変わって多少時間的な余裕ができたものの、今後どうなるかは分かりません。冬休みくらいは思いっきりのんびりさせてほしいところですが、仕事納めの直後から家の中がドタバタしている以上、難しそうです。

本音を書くなら2〜3年くらい何もしないでいたいんですよね。とはいえ、仕事に就けるだけありがたいと思え、と言われるような世代なのでそんなことできませんが。ここしばらくは随分と景気の良さそうな文字が転職サイト等に並んでいますけど、こんなのはどうせ一時的なものだし、それ以前に企業は若くて安く雇える人をお望みですからね。

正直言って、疲れています。

DMR周りのプログラム(xlxd, DMRGateway, DAPNETGateway)をIPv6対応化してみたり、JumboSPOT用に移動しない無線局を開局してみたり、Retevis RT80やRadioddity GD-73Aを増設する変更申請を書いてみたりしましたが、その先をどうしよっかなと考えていますが答えが出ません。

今年は行けそうだったハムフェアも用事で行けませんでしたし、来年こそは。

そんな訳で、クリスマスも正月も知るかそんなんという気分。子供が居るので多少の何かはしますけど。59.85kg(05:50)

構築手順書によると、以下のツールを使ったとあります。

• Pleiades All in One Eclipseの、Windows 64bit C/C++ Full Edition リリース2019-09
• GNU Arm Embedded Toolchainの、9-2019q4-major Release
• GNU MCU Eclipseの、Windows Build Tools v2.12
• GNU ARM Eclipse plug-insって書いてあるけどこれdepricatedなので多分GNU MCU Eclipse plug-insだと思う

64bitなWindowsで、EclipseとARM向けGCCを使うことを推奨しているようです。μT-Kernel 3.0のソースコードにはMakefileやスタートアップコードの類は一切入っていませんが、上記のツール側で良きに計らってくれるのでしょう。また今までのμT-Kernel 1.0/2.0と異なり、TOSHIBA TMPM367FDFG(Cortex-M3)のみが今のところターゲットとなっているため、機種依存部分は随分すっきりとしたものになっています。

試しにCMakeを使ってMakefileを作成するようにしてみましたが、これによりEclipseを使わなくてもOpenBSDやDebianのarm-none-eabi-gccでもビルドが通る感じです（ただし、出来上がったバイナリが動くかどうかは未確認です）。とりあえずGitHubにCMakeLists.txt他を置いときます。59.80kg(21:10)

SRAM PG830(11-28T)を注文しちゃったけど、トップの11Tを捨てられるならSHIMANO HG200-8という選択肢もありそうです。これは12-14-16-18-21-24-28-32Tという、PG830(11-28T)の11Tを外して代わりに32Tを入れちゃったもの。

とりあえずギア比の表を作ってみたけど、これを見るにフロントの48T/38Tをきちんと使って乗るならPG830、48T縛りで頑張るならHG200-8でしょうか。

フロントの48/38T切り替えでリア側2段分くらい変わるなーと思っていましたが、その体感は大体合っているようです。59.85kg(17:05)

所属店舗が変更になりしばらく自動車通勤をしていたのですが、自転車で行けるかどうか幾度か試してみました。帰宅時は流石に車に軍配が上がるものの、出勤時は渋滞もあり車と大差ない時間で着けるので悪くはなさそうな感じです。しかし、ESCAPE R3(2015)には少し手を入れる必要がありそうです。

31-Jan-2018にHG41(11-32T)からPG850(11-32T)に変えたスプロケット、平地はともかく坂道になるとロー側を使うことが増えるため21-26-32の辺りがかなり辛いです。11-28Tになると21-24-28となるので多少は楽になるのでしょうか（11-30Tだと21-26-30なので11-32Tと大して変わらない）。

ドロップハンドルの付いているロードバイクとか、いかにもやる気ある感じの自転車には乗りたくないなとずっと思っていたのですが、長い坂を登るにはあのハンドルが必須というのはよく分かりました。とはいえ、路面の状況を考えるに現状の28Cより細いタイヤを使うのは難しそうです。10万円以下のロードバイク…CONTEND 2でも十分すぎる気がしますが、それでもESCAPE R3よりはかなりお高いです。

だったらESCAPE R DROPはどうかと見てみたものの、これってCROSTARと同じフロントが30/46T、リアが11-34Tなんですね。ESCAPE R3は2015でも2020でも28/38/48T/11-32Tで、フロントの28Tを滅多に使わない乗り方をしていると、ESCAPE R DROP/CROSTARのあの構成はちょっとどうなのという気がします。

とりあえずスプロケットを注文して、チェーンと一緒に交換してもらおうかなあ…59.10kg(21:10)

11-Dec-2019にJARDの測定器室へ持ち込んで測定を行いました。こんな感じにアンテナ端子を付けないと測定ができないので、正直言ってこのリグを日本国内でどうにかして使おうとするのは止めた方が良いと思います。出力を引っ張り出すために細めの同軸ケーブルを用意したとはいえ、1.5D-2Vでも蓋が閉まりません。

アナログ(FM)は基準をクリアしているので、免許申請自体は可能と言われています（ただし、スプリアスレベルは許容範囲内ギリギリです）。デジタル(DMR)については不可解な動作をしているところがあり、これは現在Radioddityへ測定結果を送って返事を待っています。

FMでは問題がないことから、電子回路よりもファームウェアに原因があると推測します。ファームウェアv1.04ではhotspotとの通信時におけるBER(bit error rate)を改善したというリリースノートがありますが、DMRにおける処理にまだ問題が残っているのかもしれません。

とはいえ元のモデルとなるTYT MD-430も含めFCCの認証を取っている以上、阿呆な作りの機械ではないはずだと思うのですが…

とりあえず、当面はGD-73Aを受信機として使います。JumboSPOTからの電波をGD-73AとRetevis RT80で同時に受信させてみると、RT80では以下の症状が見られました。

1. Group Call(TG91)宛のものがPrivate Callになっている
2. カーチャンクが連発する状況に追従できない
3. 誰かが送信していることは認識できているが、音が出ない

念のためTYT MD-380も用意して確認してみたところ、3.についてはMD-380でも発生を確認しました。GD-73Aでのみ受信できRT80とMD-380では3.の症状が発生するというケースもあったため、この3つの無線機の中ではGD-73Aが受信機として最良と判断しています。

何故こういった違いが生じるか気になるところですが、調べるとなると…また（ベースバンドプロセッサの違う）無線機を買い足す話になるのでしばらく気にしないでおくことにします。58.80kg(18:00)

AliExpressで売っていたUART接続のTFT-LCDパネル、テストプログラムを書いて調べてみたのですが文字描画が結構遅いです。DCV16コマンドを使用して160×128の範囲を、8x16のフォントで埋め尽くすには540ms程度の時間がかかります。

BOXFコマンドで塗り潰す方が速いので画面消去はこれを使用し、文字描画は必要最小限になるよう、例のアレを直してみました。

μT-Kernel 3.0とかDMR機の測定結果とか書きたい話はあるのですが、まとめられないので後日。59.45kg(20:00)

MMDVMHost、AliExpressで売っていたUART接続のTFT-LCDパネルに情報を表示するようにするコードのpull request→mergeが終わったので、今度はこんなことをやってみました。

MMDVMHost自体には、DMR IDからコールサインと名前を表示する機能があります。このデータはDMRIds.datに格納されており、これ自体はhttp://registry.dstar.su/dmr/DMRIds.phpやhttps://ham-digital.org/status/users.csvから生成されているようです。

DMRIds.datの代わりに、https://www.radioid.net/static/user.csvをそのまま読み込ませて送信者の名前だけでなく送信機の場所(?)も表示できるようにしたらどうかという実験が、上の写真です。

現状の実装はcommit messageにあるように、CSVのロード機能（従来のDMRIds.datのロードとは分けている）とユーザ情報の参照、writeDMRUser()による表示要求とディスプレイドライバによる表示処理になっています。より賢いコードにできる余地がありそうな気がしますが、あちこちに大きく手を入れるよりかは簡単に付け足して「こんなのどーですか」と提案する目的でこうしています。

一つのコードでDMRIds.datとCSVの両形式に対応するとか、DMRだけでなくNXDNもUser DBがあるのでそちらも対応するとか、Nextion等のLCDでもユーザ情報の表示に対応するとか（でもこれは実機を持っている人に任せたい）、やることは山積みです。

明日はRadioddity GD-73Aのスプリアス測定を行うため、JARDの測定器室へ行きます。送信機の出力を測定器に接続できるよう、内蔵のアンテナを外して同軸ケーブルで引っ張り出す改造を行う必要がありました（この詳細は後日書く予定です）。

都心に出るついでに、2019 TRON Symposiumも覗ければ良いのですが、どうかなー…57.55kg(20:20)

MMDVMHost、AliExpressで売っていたUART接続のTFT-LCDパネルに情報を表示させるようにしてみました。

とりあえず情報が出るようになって便利になったなーとは思うのですが、128×160のパネルを発注したのに届いたのが240×320の物なので正直言ってでかくて邪魔です。

このLCDパネルは癖があるのか、確かにコマンド通り動くものの描画が忙しいときは送信したコマンドを無視するようです。イベントがあった都度描画コマンドを送信すると意図した通りに表示されないことが多々あったので、時計表示用に周期的に描画ルーチンを呼び出す仕掛けを利用して、コマンドの送信間隔をあけるようにしてみました（が、まだ怪しい気がします）。

通信速度が9600bpsではなく115200bpsがデフォルトなのと、ホストのTXとLCDパネルのTX、ホストのRXとLCDのRXを繋がないといけない点にもハマりました。

それにしてもこのパネル、どうしましょうか…とりあえず結線してはいるけど、本当は接続用のちゃんとしたコネクタ付きのケーブルも欲しいし…本来発注したサイズでないと困るし…

所属店舗が明日から変更になり、今後の鉄塔観察（橋本〜淵野辺エリア）が困難になりそうです。新しい店舗近くにはIngressポータルも無さそうで、どうしましょうかね。59.15kg(19:15)