02-Feb-2022の続き。

WinnerMicro W806に、OpenBSD上でbinutils+gcc+newlibベースのwm-sdk-w806を構築し、wm_toolを使って書き込むことができていますが…激安中華マイコンでLチカやってみたではwm-sdk-w80xが使われているので、こちらもOpenBSDとbinutils+gcc+newlibによる開発環境が構築できるか試してみることにしました。

wm-sdk-w806と同じ修正と、wm_psram.cのビルドエラーを回避するための修正を行うことでソースコードのコンパイル自体は行えるようになります。しかし、標準入出力関連のライブラリをC-SKY標準のtoolchainに依存しているせいか、lib/w800/以下にあるライブラリは基本的に使えません（リンク時に"/lib/w800/libbtcontroller.a(btc_main.o): in function `hci_dbg_hexstring': D:\work\V1.00.04\src\bt\controller\main/btc_main.c:110: undefined reference to `_printf_d'"などのエラーが発生します）。使えそうなのはせいぜいlibdsp.a（これはwm-sdk-w806と同一のものです）とlibwmsys.aくらいです。

この問題を回避するため、gmake menuconfigのCompile Configurationにあるenable use libを無効化する必要があります。それでもlib/w800/libbtcontroller.aをリンクしようとしてエラーを起こすので、include/wm_config.hにある#define TLS_CONFIG_BLEをCFG_OFFとする必要もあります。

これでgmakeでビルドが通り、bin/w800/以下に各種オブジェクトが得られるところまでは確認できているのですが、現時点ではgmake flashを行うとcan not open serialとエラーが出て書き込めません。wm-sdk-w806では書き込みができている以上、何か些細な問題に引っかかっているようです。

なお、wm-sdk-w806ではApache-2.0ライセンスである旨がきちんと示されていますが、wm-sdk-w80xではライセンスが未定義である点には注意が必要です。56.4kg(05:20)

キャタピラー上溝線→GLP相模原線/葉山線の変更に伴い、城山線8号になにか変化あったかなーと24-Mar-2022に見に行ったのですが…

変わった様子は無い気がします。

26-Mar-2022には葉山島太陽光発電所と思われる場所にも行ってみました。Googleストリートビューでは中が少し見えているものの、

入口はしっかり閉ざされており、中は分かりません。監視カメラが付いていたので、うろうろする不審者がいたことが伝わっている可能性も高そうです。56.5kg(07:05)

20-Mar-2020の続き、って二年ぶり。

最近のhttps://github.com/juribeparada/MMDVM_HSを見るに、M17のサポートが入ったのでそろそろJumboSPOTのファームウェアを入れ替えないとねーということで久々にビルドして（手順忘れてました）、そのうち書き込むかねー（ケーブル繋ぐの面倒です）と考えていたのですが。

折角なのでpicolibc突っ込んでみたらどうなるかな？と思ってstm32f10x_link.ldとMakefileを書き換えてみました。configs/MMDVM_HS_Hat.hのデフォルトをConfig.hとした状態でmake noblを行うと、オブジェクトが66kB程度に増えてしまうので、STM32F103C8T6には書き込めません。ENABLE_DEBUGを削るなどすれば収まるのかもしれませんが、そもそも動くかどうかは分かりませんので、現時点では大人しくnewlib-nanoを使う方が良さそうです。56.3kg(22:05)

28-Mar-2022補足：IOSTM.cppの修正が必要だったUSB対応版はConfig.hのSTM32_USB_HOSTに切り替えるだけで動いています。バイナリはこちら。ちゃんと追いかけていませんが、Merge pull request #107 from veraabad/master辺りのコミットで直っていると思われます。ENABLE_DEBUGを削ってpicolibc化したものを試してみましたが、動きません。

07-Mar-2022の続き。工事中の小倉開閉所（東京電力の当社における系統情報について→154kV系統の計画系統図(PDF)にある、神奈川県 2025年度（第五年度）夏期高需要期のページにこの名称が記されています）を12-Mar-2022に見てきました。

とはいえ、まだ全貌が明らかになっている訳ではなく。

現在ある都留線243号の周辺に3本の鉄塔が建つようです。既に2本は出来上がっているようですが、もう一本は組み立て途中のようです。

243号を若番側から見て、左側の鉄塔の梯子カバー(?)に242号とスタンプが押されていたのを見るに、これが都留線242号になると思われます。確か242号は欠番なので（詳しくはプラ太郎さんのblog(19-Apr-2011)などを参照）、241号→243号→245号が241号→242号→245号の並びになるのでしょうか。他の2本については、どういう名称になるか分かりません。

そういえば16-Apr-2014にまとめているのは都留線249〜255号の範囲で、これより若番側はチェックから外していました。流石にあの時の工事前の番号まではもう分かりませんが…現時点における番号くらいは調べておいた方が良いのかもしれません。川向こうは坂が多く、結構ツラいのですが…ここ一ヶ月で体重が増えている状況を見るとそうも言ってられませんし。57.0kg(06:50)

06-Mar-2022の続き。色々足掻いてみましたが、現時点だとOpenGD77.comに書いた質問にあるように、MCUXpresso上でビルドする以外に方法はありません。

これでビルドするとちゃんと無線機(DM-1801)が起動して、DMRの送信も可能になるものの…何故ビルド済みの公式バイナリでは起動できないのか、何故標準Cライブラリを変えた程度(redlib/newlib-nano)でDMRの送信に問題が起こるのか（本当にサイズの問題なのでしょうか？）、という問いに対する答えとしては不十分です。

それと、仮想マシン上のDebianとはいえ、make一発で30秒程度のビルドがMCUXpressoでは3分近くかかるというのも正直やってられません。Debianのgcc-arm-none-eabiパッケージと組み合わせて使えるようなredlibのみのパッケージでもあれば助かるのですが、そんなものは作られないでしょうね。

redlib/newlib-nanoの代わりに使えるものとしてpicolibc（Debianであればpicolibc-arm-none-eabiパッケージがあります）を使ってビルドすることも試しています。こちらはnewlib-nanoの派生ということもあり、状況は変わりません。無線機の動きを見るに、マイク〜ADC〜I2C〜DMA〜メモリ間のどこかで問題が起こっているように感じるのですが、深追いするだけの余裕が無いので一旦ここでぶん投げます。57.2kg(07:00)

今頃気付いたの？と言われそうですが…今頃知りました。葉山島線は太陽光のとこからだろうけどその先はGLP相模原線の1Lなのかな？というツイートを見て、風が強くて自転車漕ぐのは辛いけど早速見に行かねば…というのが06-Mar-2022の話。

キャタピラー上溝線4号は、葉山島線12号になっています。鉄塔札の取り付け位置が城山線側→GLP相模原側に変わっています。

山登りしている時間は無いので、容易に見られるキャタピラー上溝線27号〜37号を…これらは番号そのままでGLP相模原線になっています。とはいえこの区間を全部見た訳ではなく、27〜32, 36, 37号だけですが。

23-Nov-2010の表、12-Mar-2014の情報を足して書き直すと、こうなるでしょうか。

葉山線なるものが何処から来て何処へ行くのかは分からないのですが、ネットの情報を見る感じだと葉山島太陽光発電所から小倉開閉所を結ぶ路線のようです。リニア反対派がこういう情報に敏いというのは、意外ですね…55.8kg(06:50)

13-Mar-2022補足：GLP相模原線37号の鉄塔札の写真、撮り直したので差し替えています。差し替え前の写真はこちら。

17-Jul-2021の続き。releases/R2022022801が出たのでこれをVoid Linux上でビルド→書き込みしてみます。とりあえず08-Jul-2021程度の準備に加え、xbps-install python3-usb python3-urllib3を済ませておいてください。前回と比べ、大きく手順は変わりません…というか、ほとんどそのままなので今回の日記は前回の日記をコピペして修正しているだけだったりします。すみません。

ソースコードの入手

sources_and_tools/{OpenGD77_FirmwareLoaders.zip,OpenGD77_buildtools.zip,OpenGD77_sources.zip}を取得。

必要なファイル類の展開とビルド用ディレクトリの作成

unzip -x /path/to/OpenGD77_FirmwareLoaders.zip gd-77_firmware_loader.py; unzip -x /path/to/OpenGD77_buildtools.zip; unzip -x /path/to/OpenGD77_sources.zip; cd OpenGD77/firmware; mkdir build

codec_cleanerの修正（スクリプトは改行コードの問題により動かない問題が未だに発生しているため、バイナリを直接呼ぶようにする）

mv tools/codec_cleaner tools/codec_cleaner.old; ln -s codec_cleaner.Linux tools/codec_cleaner

ダミーのcodecバイナリ作成(codec_bin_section_1.bin=15360byte, codec_bin_section_2.bin=163984byte)

tools/codec_cleaner -C; mv codec_bin_section_?.bin linkerdata/

ビルド（VERBOSE, RADIO, -jオプションはお好みで、この例ではBaofeng DM-1801向けとする）

cd build; make -f ../Makefile -j5 RADIO=DM1801 VERBOSE=1

blob抽出用ファームウェアの所在を記述（gd-77_firmware_loader.pyを実行するユーザのホームディレクトリに作成すること）

printf "[GLOBAL]\nSourceFirmware=GD-77_V4.3.6.sgl\n" > ~/.gd77firmwareloader.ini

書き込み（GD-77_V4.3.6.sglはカレントディレクトリに置く）

python3 gd-77_firmware_loader.py -m DM-1801 -f /path/to/OpenDM1801.bin

codec_cleanerの文字コード問題はもうそういうもんだと諦めましょう。GitHubでやっている訳ではないために、pull-requestを投げられませんから。

オブジェクトが得られて書き込みができることまでは確認しているのですが、手元のDM-1801だと、マイクゲインをいじってもDMRの送信時に音声が乗らないという問題が起こっています。DMRの受信およびFMの送受信に問題はありません。どこの時点で問題が起こったか、色々試しているのですが

• R2021052901(DEBUG=1)
• R2021071101(DEBUG=1)
• R2022022801(DEBUG=0,1)
• OpenGD77のソースコードがGitHubで公開停止される直前のsnapshot(ajorg版)(DEBUG=1)

以上全てで発生しています。ajorg版は以前試した時に問題なかった気がするのですが…？

R2022022801/firmware/にあるOpenDM1801.zip, OpenDM1801_JA.zipから展開されたOpenDM1801.bin, OpenDM1801_JA.binについては、DMR用のcodec blobを得るためのGD-77_V4.3.6.sglを使用しない場合は無線機(DM-1801)が起動するものの、使用した場合はどちらのバイナリを書き込んでも無線機自体が起動しません。DM-1801上におけるOpenGD77の動作報告が出ている以上、おかしなバイナリを配布しているとは思えませんし、手元にあるDM-1801に何か問題があると考えるのが筋なのですが…何が起こってこうなるのか、全く見当がつきません。

当然といえば当然なのですが、本来DM-1801に書き込まれていたと思われるBF-1801_V2.2.5.sglを使用した場合はDMRの送受信を含め問題なく動作しています。CPSによる読み書きができないので、これはこれで問題なんですけどね…57.6kg(13:30)