落ちクマ

PC から WiFi 経由で Android のファイルブラウズをしたいのだけれど，
・日本語ファイル名が化けない
・外部サーバを介さず LAN 内で完結する
・SD カードを読み書きできる
・上記の機能がすべて無料で使える
を満たす Android アプリが，何故か無い．

なので Cyanogenmod, LineageOS では内蔵の sshd を立ち上げていた (PC からは WinSCP) のだが，今のところこれが最強．
しかし Redmi Note 3 Pro を AOSP 系の Pixel Experience にしたら sshd が入っていなかった．
Android アプリにも sshd はあるけど，root じゃないので SD カードアクセスができず使えない．

仕方がないので dropbear を Android 向けに build することにした．
GitHub を漁るといろいろ Android に移植済みの dropbear があるが，最も新しそうな dropbear-android を使用することにする．

【手順】
(1) Android NDK 環境をここ見ながら構築する．
自分は↓で行けた．

/home/yoshi/android-ndk-r16b/build/tools/make-standalone-toolchain.sh --arch=arm --platform=android-21 --install-dir=/home/yoshi/android-toolchain

(2) dropbear-android のビルド

setenv TOOLCHAIN /home/yoshi/android-toolchain
./build-dropbear-android.sh

で，珍しく一発でビルドが通った．

で，RN3P に持っていって起動したら，

# /data/dropbear -r ./ssh/rsa_key_db -F -P ./ssh/pid -A -N root -T ./ssh/authorized_keys -U 0 -G 0
[23486] Dec 08 15:37:22 Not backgrounding
[23487] Dec 08 15:37:25 Child connection from 192.168.0.13:62545
[23487] Dec 08 15:37:27 Password auth succeeded for 'root' from 192.168.0.13:62545
[23487] Dec 08 15:37:27 Failed to open any /dev/pty?? devices
[23487] Dec 08 15:37:27 No pty was allocated, couldn't execute
[23487] Dec 08 15:37:27 Exit (root): Exited normally

んー，terminal の open に失敗してる? そもそも /dev/pty とか Android に無いんじゃないの?

調べてみると，Linux では openpty() で端末を open するのが一般的らしいが，Android に openpty() はない．しかし，ここで他の Android dropbear プロジェクトで，openpty() を独自実装しているものが見つかった．このコードをサクッとコピペして再ビルド．

[28075] Dec 08 21:54:33 Not backgrounding
[20372] Dec 08 22:03:01 Child connection from 192.168.0.13:55309
[20372] Dec 08 22:03:01 Password null
[20372] Dec 08 22:03:01 Password null
[20372] Dec 08 22:03:01 Password null
[20372] Dec 08 22:03:01 Pubkey auth succeeded for 'root' with key sha1!! ... from 192.168.0.13:55309

勝利ヽ(´ー｀)ノ

上記のパッチ当て済みのものを GitHub に公開したんで，欲しい人はどうど．

Xiaomi Redmi Note 3 Pro ブートローダーアンロック回避

Xiaomi Redmi Note 3Pro に Pixel Experience (Android 9.0) を入れようと思った．
TWRP から焼き直したら一発でしょ，とか思ってたらそうは問屋が卸さなかった．

「Updater process ended with ERROR: 7」
なんですと...? Σ（￣□￣ι　こうなってくるととたんにめんどくさくなってくる．

Pixel Experience を入れようとしたら TWRP を update しないといけない
→TWRP (recovery.img) を焼き直すためには unlock しないといけない
→unlock するためには Xiaomi に unlock 申請し，MIUI を焼き直さないといけない(?) これの申請に 72時間かかるとか...

やってられないので，ブートローダーアンロックなしで TWRP を焼く手順を試してみた．→参考

(1) EDL モードで MIUI 公式 ROM を書き込める準備をする，まだ焼いてはダメ→参考，参考2
自分が使った ROM は手元にあった kenzo_global_images_6.11.3_20161103.0000.00_6.0_global_f7309f8161.tgz
(2) MIUI の公式ロムを解凍した dir の images\recovery.img を，TWRP で上書きする．
(3) (1) の手順に従って MIUI を焼く．(まだリブートしてはダメ)
(4) 焼き終わったら，VolUp + 電源長押しで TWRP を起動する．ここで一回でも MIUI が立ち上がってしまうと，焼いた TWRP が元に戻されてしまうっぽいので注意．
(5) TWRP が立ち上がったら，あとはお好きなように．

←というわけで勝利ヽ(´ー｀)ノ

Android P 目玉機能の (Android 7.0 で既に載ってたのね，知らなかった) 2画面分割とか試してみたけど，多分使わないなw タブレットならともかく，6インチくらいの画面で同時作業するシーンが思い浮かばない...
あとブートが異様に速くなったけど，そんなに頻繁に再起動するもんでもないしねぇ．

逆に LineageOS から AOSP 系の ROM になったことで，いろいろと細かい便利機能がなくなったのが不便．(例えば，電源長押しでフラッシュライト ON とか)
ROM 入れ替えなくても，よかったかも．

-----
後日追記:
結局 Lineage 14.1 に戻した orz
アプリ起動時に 1秒ほど反応がなかったり，そのまま画面がフリーズする現象が出た．ROM が悪いのかと思い Liquid Remix も試してみたけど，同じ現象 orz
RAM が足りてない感じではないんだけどなぁ...

VZ Editor 復活の狼煙

テキストエディタは使い慣れたものでないと著しくコーディング効率が落ちる．MS-DOS 時代は VZ Editor を使っていたので，Windows では自ずとのその後継の WZ Editor 4 (もう 16年前のバージョンw) を使っていたが，
・Unicode 対応がプア
・正規表現がバグっている
等々，限界が近くなってきた．普通に考えれば WZ の最新版を買えばいいのだろうけど，会社で個人購入のソフトを使っているのがバレるとめんどくさいは使えないのと，十数年前と違って今ではフリーのエディタも高機能なものがあるので，WZ の代替になるかいろいろ調べてみた．

●Emacs 系
Emacs lisp が強力なので，望みのことは多分できそう．ただし Windows で Emacs インストールはかなりめんどくさいようなのでパス．あと重い．

●Mery，サクラエディタ，秀丸 (は有料だけど)
一般的にはそこそこ強力なマクロ機能を持っているんだろうけど，自分的には機能が足りず，VZ の編集機能を実装することができなさそう．

●Notepad++
プラグインを自作すればかなりのことができそうな雰囲気なので，おそらく望みのことはできるんだろうけど，プラグイン開発のための情報が少なすぎた．プラグイン開発のための学習コストを考えると，順位は下げざるを得ない．

●xyzzy
マクロ機能は文句なしに強力．実はこれが本命ということでしばらく使ってみたのだけど，Emacs 系の独特の選択方法や，マウスを使った操作があまりにも他の Windows アプリとかけ離れているので，最終的に使うのを諦めた（；´д⊂）
あと開発が止まったようなので，もう更新されないエディタにわざわざ乗り換えるのもなぁ...

とフリーソフトは全滅か，と思ったところで，サクラエディタはソースコードが公開されていることを思い出した．これって考えようによっては究極のカスタマイズ機能だよなぁ... と思って，サクラエディタ VZ 化計画をおもむろに発動．というわけで，GitHub のサクラエディタをサクッと fork して公開中→https://github.com/yoshinrt/SakuraVz

SystemC で全信号の sc_trace() をなるべく楽にする方法(2)

以前「インスタンス階層ツリーを出してくれる機能はなさげ」と書いたけど，SystemC の全信号を階層付きでリストアップする方法はあることがわかった．
Why sc_object menber function trace() deprecated?
ただしリンク先にもあるように，一発で全信号を波形ダンプする方法があるわけではない．
# 信号名の一覧が取得できるだけ
しかし階層付きの信号一覧取得できれば，ほぼ目的は達成したと言って良い．というわけでコード．

最初に -DLIST_ALL_SIGNAL 付きでコンパイルして実行すると信号一覧が取得できる．それをスクリプトで適当に sc_trace() のコードに変換して trace_all_signal.h を生成する．あとは -DLIST_ALL_SIGNAL なしでコンパイル・実行すれば全信号のトレース付きで sim 実行される．
↓取得できる信号一覧
↑生成した trace_all_signal.h

前回の方法は，全モジュールに sc_trace() を埋め込むので記述が分散してそれなりに手間だが，今回の方法は 1箇所の記述で対応できるので楽といえば楽．

ただし，信号の配列の場合やメンバイニシャライザで信号名していない場合，取得した信号名はテンポラリな名前になってしまうため C++ 上の変数名と不一致を起こしコンパイルエラーになってしまう (上の例でいうと，sim_top0.signal_0 は存在せず，そのような変数名は trace_all_sighal.h から省かなければならない)．

●各モジュールに sc_trace() 埋め込み
◎全信号をもれなくトレース可能
◎配列信号でも，正確な信号名を設定できる
×記述が分散する
×信号の増減は所詮手動で対応しなければならない

●全信号自動リストアップ
◎信号の増減に自動的に対応できる
◎1箇所にコードがまとまるのでメンテが楽
×2回コンパイルが必要
×name 設定していない (出来ない) 信号のトレース不可

楽さを取るか，もれなく信号をダンプするか．悩ましいところだなぁ．

ここがヘンだよ SystemC

SystemC は新規に設計された言語ではなく，C++ にライブラリを追加する形で実現されているため，いろいろと記述的にヘンであったり，煩雑なところがある．

(1) センシティビティリスト記述を，動作を記述している場所の近くに書けない (普通に書くと別ファイルになる)
(2) 信号を定義したら，その信号名を「文字列で」教えてやる必要がある．
(3) 前回の blog に書いた sc_trace() の問題．(2) と合わせると，信号の宣言，信号名の設定，トレースの設定，と同じような情報を 3箇所に書く必要がある．
(4) Verilog-2001 の always@(*) のようなセンシティビティリスト省略が出来ない
(5) Verilog-200x (いつの規格かわすれた) のインスタンス接続の省略表記「.*」が出来ない

こういうのって設計の頭使うところ以外で時間を食うことになるので，上記を改善するための SystemC preprocessor を作ってみた．

scpp.pl - SystemC preprocessor

我ながら SystemC のイライラポイントが大分改善されて満足ヽ(´ー｀)ノ
下記の処理前後の diff を見てもられば，処理前の記述が大分削減されていることがわかってもらえると思う．

SystemC の sc_trace() をなるべく楽にする方法

SystemC で信号ダンプをするためには，自分でダンプしたい内部信号を階層含めて一個一個指定する必要があって超めんどくさい．一個一個，は他にも似たような記述があるので諦めるにしても，階層含めて，は根気良く書くのが無理なレベル．インスタンス階層ツリーを出してくれる機能とかあればいいんだけど，そういうのもなさげ．
どこのご家庭でもお困りですよね．

sc_trace( trace_f, hoge.fuga.signal_a, "hoge.fuga.signal_a" );
sc_trace( trace_f, hoge.piyo.signal_b, "hoge.piyo.signal_b" );

で，自分で試してみて，一番マシだと思った方法は，SC_CTOR() 内で sc_trace() すること．

this->name() で，インスタンス化されたときのこのモジュール名のフルパス名が取得できるので，sc_trace() の記述自体にはフルパスを記述する必要がなくなる．
この程度の記述であれば，ポート宣言のコピペ & 置換レベルで対応できる．
めんどくさいメンバイニシャライザでの信号名設定 (上記の★不要 の箇所) も不要．

なお trace_f は このモジュールがインスタンス化される前に sc_create_vcd_trace_file() しておく必要がある．

Cadence だとナントカ wizard でこの辺を自動化してくれるんだけど，パンピーには使えないしね...

転んでもタダでは起きない

久々にエンゼルラインに登ってみようと若狭湾に向けて車を走らせていたら，途中の電光掲示板に「エンゼルライン 部分通行止め」の表示が（；´д⊂）
結構近くまで来てしまったしこのまま帰るのはなんだなぁ，と思ったところで，近くに舞鶴の海上自衛隊基地があることを思い出して行ってみた．

ラッキーなことに，土日祝日は基地敷地内の艦を係留している岸壁まで行けて，間近で艦を見れるらしい．
いきなり目の前にイージス艦でテンションが上がるwww

どれくらい近いって言うと，これくらい寄れてしまうわけですよ．
艦の舳先のほぼ真下から見上げるってそうそう無い気がする．

いま話題の「いずも」... ではなく，それより小さいヘリ空母らしいのだが，それでもでかい．

ミサイル艇，のウォータージェット排出口．なんでこれを撮ったかというと，何故か三菱のマークが赤く塗装してあったからw
こういう兵器で，特定のメーカーのマークが目立つようにしているのは珍しいと思うけど，なんでここだけ塗ったんだろう．

で，しばらく見ていたら，艦によっては乗艦して見学できるらしい．マジデスカ!!

主砲w
よくありがちな「近くに寄るな」的な柵も「触るな」的な立て札もなく，寄り放題触り放題なんだけど，いいんでしょうかw
退役してオブジェと化している砲ならまだしも，現役艦なんだけどな…

ﾐｯｿｰﾗﾝﾁｬｰ!!!

ミサイルも入っていますw
まぁ模擬弾だろうけど，でも安定翼が折り畳まれているのまでよく見える．


久々にすごいものが見れて大満足．しかもタダだしwww (と言っても元は我々の税金か)
GW だけど駐車場も並んだりしなくて済んで，まぁ楽に見て回れるので，こういうのに興味がある人にはおすすめ．


ここまでおおっぴらに見せてくれるのは嬉しいけど，逆に警備大丈夫なん? とちょっと心配になった．
一般道から艦までは数十メートルしか離れてなくて，敷地の塀は特別頑丈そうには見えないし．たとえば某国の工作員がダンプに爆薬満載して艦に特攻すれば簡単に艦が無力化されそうな気がするけど，どうなんだろう．

エンジン不調

先日の鈴鹿ツインサーキット，アクセル全開時にマフラーからパンパン音が鳴って加速も鈍るトラブル発生．ついでにエンジンチェックランプも点灯した．アクセル ON→OFF 時に音鳴るのならわからんでもないけど，全開時に鳴るのは壊れてる以外の何物でもないw

なので OBD ドングルでエラーコード読み出してみたら，

P14xx → いつものリレーの謎エラーなので無視
P0301 → Cylinder 1 Misfire Detected
P1301 → Misfire level causing emissions increase

案の定失火してる orz

自分ではどうしようもないので，TK スポーツに車持っていって見てもらったところ，

TKS サン (以下，T)「プラグキャップ抜けかけてます」
T「プラグとプラグキャップの接点が溶けかけてます」
T「プラグのねじ込みが緩みかけです」
T「プラグの電極がなくなりかけてます」
T「タペットカバーパッキン終わって，プラグがオイルで濡れてます」
T「オイルキャップのパッキンなくなってます」(まぁこれは関係ないが)
T「冷却水リザーバータンクのパッキンなくなってます」(これも関係ないが)

と，これでもかというくらい失火の原因らしきものがわんさかとw 普段の自分の整備ではこんなとこまで見ないもんなー．
まぁ，失火に関してはプラグ交換くらいで済みそうだ，と安心してたら，

T「プラグ交換して，あとセンサー類も変えてみても治りません」
T「最悪 ECU 壊れてるかもです (訳:10万円とかじゃ済まないよ)」

工工エエェェェェｪｪｪ(ﾟДﾟ)ｪｪｪェェエエエ工工

と死刑 (散財) 宣告を受けつつ，一旦車預けることに．

ドキドキしながら結果を待っていたけど，結局イグニッションコイルの不良だったようで，点火系はイグニッションコイル・プラグ・プラグコードを交換して完治ヽ(´ー｀)ノ

10年も経つとヤバいトラブルがちらほら出てくるね…orz

10年間の成長

いつものメンバーで鈴鹿ツインサーキットに行ってきた．

雁が原ではいつも昼過ぎに来る 9 サンはいつものように遅刻気味(笑) K サンも渋滞に巻き込まれたようで 1枠には間に合わず．

まえここに来たのいつだっけ，と思って blog 見直してみたらほぼ 10年前．あれから美浜や鈴鹿南などいろんなコースも経験したし，カートも経験したし，へっぽこドライバーなりにそれなりに上達しているはず．ま，1秒くらいは更新できるんじゃね?
（ ゜Д゜)y─┛~~~
と余裕かましつつ，めちゃめちゃ寒い中 1枠目走行開始．その結果は...

10年前のベスト 41.214
↓
今回ベスト: 41.519

遅なっとるやん… 10年間の経験って一体 orz

こりゃいかんと思って 2枠め，ライン変えたりブレーキ頑張ってみたりいろいろしてたらコースアウト 4回くらい + エンジンチェックランプ点灯で THE END．
ハザードつけっぱなしなのに気づかんくらいw 頑張ったのにタイムは 41.683．さらに遅くwww

午後からも走る予定していたけど，5台中 3台が何らかのトラブルを抱え(笑)，満身創痍でサーキット走行は終了．

そのあと鈴鹿サーキットでやっていたファン感謝デーに行ってきた．
自分的には TS050 の実車が見れたので満足ヽ(´ー｀)ノ
そのあと観戦スタンドに行っていろいろな茶番イベントを見たけど，寒い!! 完全冬仕様の自分でも寒かったので，隣の N サンの小春日和的な服装は見てるだけでも寒い(笑)

最後は冷え切った体を亀八食堂の味噌焼きうどんで温めて，解散．

久々に車づくしな一日で楽しかった
ヽ(´ー｀)ノ

バリバリからの脱却

エリのバッテリーがヘタってきたので，バッテリーを交換した．今回も LONG WP22-12N．前回交換は 2013年だからなんと 5年も持ったことになる．型番も WP22-12 → WP22-12N と微妙に変わり，端子が変わったので接続の方法を変えなければならなかった．

で，古いバッテリーを外そうとしてびっくり．マジックテープの糊の部分が溶けるようにずれていて，バッテリーが移動していた．幸いタイラップで止めていたので完全には外れなかったようだ ((((;ﾟдﾟ))))ガクガクブルブル
マジックテープの糊は常温では強力で車の加速度ごときでは外れそうにないんだけど，エンジンルーム近いトランクの温度が上がって糊が溶けたところで G がかかったっぽい．

なので今回はマジックテープで固定するのはやめることにした．
ステーは純正バッテリーの大きさの枠になっているので，そこに家にあった木の端材で WP22-12N との大きさの差を埋めるような枠を作る．

これでバッテリーは水平方向には動かないので，あとは荷物を縛る用のバンドで固定した．

これでバッテリーのバリバリ やめて! からも脱却ヽ(´ー｀)ノ


古いバッテリーはイエローハットで「車のバッテリー引き取ってもらえます?」って聞いて OK だったので，タダで引き取ってもらえた．WP22-12 は UPS 用のバッテリーだけど，車で使ってたから嘘じゃないよねw

以下覚書:
端子間電圧: 12.7V

ふゆやすみのこうさく

家族から WiFi のつながりが悪いとクレームが入った．WiFi 親機は 2F 東の端にあって，居間は 1F 西になるので，ちょうど立方体で言うところの対角になって条件としては確かに悪い．

ということでかねてから計画していたリフレクタを作ることにした．ダンボールにアルミフォイルを貼って，またデムパなものを創ってしまった... ダンボールで工作とか小学校以来ではなかろうか．けどここにもあるように，ある程度効果はあるはず．

で，効果の程はというと，
# android アプリの WiFi ミレルで測定，単位不明だが数値が大きい方がデムパが強い．
# あとオレオレ平均値，値は リフレクタ無し→有り

無線規格	居間	台所
11n/a	14→17	36→34
11n/g	34→39	57→56

ん～微妙!!www
一番なんとかしたかった居間のデムパ強度は，少なくとも数値上は上がってるっちゃ上がってるが，(11n/a の) 絶対値が低いので安定して接続できるかは謎．
台所はちょうど WiFi ルータの真下にあり，またリフレクタは西に向けて設置しているのでそこへのデムパ強度は下がったのかなぁ?
あとでリフレクタの向きとか調整してみよう．