2018年9月のてきとーな日記

［RT-Thread: Hello package］

menuconfigから存在が分かっていても動かし方が分からなくて困っていたHello、やっと動かし方が分かりました。

cd rt-thread/bsp/allwinnter_tina; scons --menuconfig
RT-Thread online packages→miscellaneous packages→Hello: A example packageに[*]
source ~/.env/env.sh; pkgs --upgrade
pkgs --update (この操作でhello packageをダウンロードする)
sconsでビルド

ダウンロードしたhelloはrt-thread/bsp/allwinnter_tina/packages/hello-1.0.0に展開され、これを呼び出すようにrt-thread/bsp/allwinnter_tina/packages/の下に各種ファイル(SConscript, packages.dbsqlite, pkgs.json, pkgs_error.json)も生成されます。

helloの起動方法は、msh起動後にhello_funcで起動します。mshのヘルプでは「hello_func - say hello」が追加されているので、うまく組み込めたかどうかはこれで判断すると良さそうです。

なお、.configを消してしまった場合、GitHub上にあるものをベースに改造していかないとうまく動かない感じがあります（まっさらの状態からscons --menuconfigで自動生成したものを使ったらハマりました）。

さて、パッケージの追加手順は分かりましたが、起動後にそのパッケージを自動的に起動するにはどうすれば良いかという疑問が湧きますね…あと、pkgs --updateと--upgradeの順番がこれで良いのか、とか。59.05kg(11:25)

［RT-Thread on Lichee Pi nano覚え書き］

そりゃまあAllwinner tina板级支持包の手順に従えばできるよね、って話なんですが。

GNU/BSD Makeは使わず、SConsを使います。なので、gmake/gmake cleanの代わりにscons/scons --cleanです。何を呼び出してビルドしているのかを知りたければ--verboseを付けましょう。CPUコアが豊富にあるなら-j 4等の指定も有効です。

OpenBSDの場合、gitとarm-none-eabi-{binutils,gcc-linaro,gdb,newlib}のパッケージは当然入っているとして、sconsとpython, python-tkinterもインストールしておいてください。

RT-Threadをgit cloneで落としてきた後、bsp/allwinner_tina/rtconfig.pyを修正します。EXEC_PATH = r'/usr/local/bin'、LINK = PREFIX + 'gcc'で良いでしょう（LINKのデフォルトはg++を呼び出すようになっていますが、これだとlibstdc++をリンクしようとしてエラーになります）。bsp/allwinner_tina/drivers/spi/drv_spi.cについては、uint8_t, uint16_tなんか知らんというエラーが出てしまうため、include/rtdef.hの定義に従ってrt_uint8_t, rt_uint16_tに直しておく必要があります。

次にtina-splのビルド。これはMakefileのCROSS ?= arm-eabi-をCROSS ?= arm-none-eabi-に直すだけでok。sunxi-toolsもgmake一発でビルドできます。

あとは、sunxi-tools/sunxi-fel -p write 0x00000000 tina-spl/output/f1c100s.bin; sunxi-tools/sunxi-fel exec 0x00000000; sunxi-tools/sunxi-fel -p write 0x80000000 rt-thread/bsp/allwinner_tina/rtthread.bin; sunxi-tools/sunxi-fel exec 0x80000000でこんな感じに動きます。

とはいえ、sunxi-felを使って起動するのも面倒です。試しにSDカードから起動したU-boot上でrtthread.elfをloadxコマンドで流し込んでbootelfしてみましたが、これでも動いています。GPIO周りの初期化などが違うかもしれないのでtina-spl(f1c100s.bin)から起動した場合と同一の結果にならない可能性があり、転送速度も遅いですが、ちょっとした実験に使うならこの方法もアリかもしれません。58.45kg(06:45)

27-Sep-2018補足：Linux(Debian-9.5)上でビルドする場合、難しいことを考えなくてもRT-Threadのビルドは可能です。必要なのはrtconfig.pyのEXEC_PATHの修正くらいで、LINKはg++のまま、drv_spi.cも無修正で通ります。#include <stdint.h>抜きでuint8_t, uint16_tが使えてしまうというのがなんとも気持ちが悪いのですが（newlibのsys/types.hの違いに起因する模様）、Linux上での開発が標準である以上それを受け容れよということなのでしょうかね…

とりあえずdrv_spi.cに関してはpull requestを投げてmergeしてもらいました。

［尾根幹ヒルクライムごっこ、あげいん］

タイヤをSERFAS TUONO 32C→SECA 28C、スプロケットをSHIMANO HG41(11-32)→SRAM PG850(11-32)、ペダルを標準→RANT Shred Pedalsに変えたESCAPE R3(2015)、どの程度変わったかを試してみたかったので昨年に続き今年もやってみました。GPSロガーの設定を適当にやってしまい、今回は20m毎の記録（前回は5秒毎の記録）になっているため厳密な比較はできないのですが…

とりあえずの結果。多摩東公園交差点〜小山交差点9.7km、20分43秒。平均時速28.09km/h。56秒を短縮したと言って良いものかどうか（誤差じゃね？）。

時間はともかく、タイヤを変えた効果はかなりあると感じています。前回はフロント38T/48Tを切り替えていましたが、今回は48Tのまま走っています。25C化したらもっと楽に速く走れそうな気がするのですが、これ以上の結果を狙うならクロスバイクではなくロードレーサーに乗らないと厳しいでしょうね。

タイムはともかく走るだけでも結構楽しかったので、また何かの折に走ってみましょう。57.90kg(06:45)

［KOZOS/pcDuino］

Allwinner F1C100sとA10の割り込みコントローラが似ているので、KOZOSを手元にあるpcDuinoにも移植しちゃいました。同じAllwinner A10を載せたA10-OLinuXino-LIMEも持っていますが、こちらでの動作は未確認です（UARTが動けば動くだろうとは思うのですが）。

Allwinner A10に関してもメモリバリア命令の類は使わずに動いているので、ARMv5/ARMv7の違いというよりは、Cortex-A8/Cortex-A7(MPCore)の違いと考えるのが良さそうです。

とりあえず、U-Boot起動直後におけるページテーブルの内容を見てみました。Lichee Pi nanoではメインメモリの領域のみキャッシュとバッファが有効になっており、他は無効化されています。ARMv7なおよびOrange Pi PCではページテーブルの内容だけでなく、SCTLR(0x00c5187f), ACTLR(0x00006040), PRRR(0x00098aa4), NMRR(0x44e048e0)の値も見る必要があり、これらの内容からOrange Pi PCでもLichee Pi nanoと同様にメインメモリの領域のみキャッシュとバッファが有効になっていると判断しました（ARMv7的には厳密にはこの表記は正しくないが）。

ACTLRのSMP bit(bit6)が1になっているので、この辺りに何か問題を解く鍵があるような気がします。このビットをクリアした場合の動作を見るにしても、Cortex-A7 MPCore Technical Reference Manualを見るとちょっと面倒そうな手順なのでまだ試していません。

♪

とりあえず、KOZOS/Orange Pi PCにおいてメモリバリア命令を追加しないとまともにI/Oができない問題の原因はまだ完全には掴めていませんがあまりこればかり追っている場合でもないので（本当は良くないんですが）、Lichee Pi nanoに戻りましょうかね。

RT-ThreadなるRTOSが動くらしいので、Allwinner tina板级支持包に従ってビルドできるかどうかを試してみたいところです。59.05kg(05:45)

［KOZOS/Lichee Pi nano］

折角なので15-Oct-2017に作ったKOZOS/Orange Pi PCを改造してKOZOS/Lichee Pi nanoを作ってみました。Lichee Pi nano版では特にメモリバリア命令の類は使わずともきちんと動いているのですが、ARMv7/ARMv5の違いなのか、この挙動の違いが一体どこから来るのかは謎です（それを調べてみたいという理由でこのボードに手を出しているのですが）。

Lichee Pi nano向けにKOZOSを移植する上で、何故かU-Bootのloadxコマンドが使えないという問題に遭遇しました。これはcmd/Kconfig側で殺されていたので、直してpull requestを投げてみたらマージされちゃったので驚いています。併せて08-Sep-2018のMakefileの修正も投げており、こちらもマージされています。

F1C100sの割り込みコントローラ周りのコードはF1C600 User Manual（型番違うけどこれを見ろって書いてあるので）の他にLinuxのソースやAllwinner A10 User Manualも見てなんとなくで書いて一応動いてはいるのですが、あれで良いのかちょっと不安だったりします。

Interrupt Source Priority Registerによって割り込みに優先順位を設定した場合、割り込み処理開始時にInterrupt Response Register（の処理中の割り込み要因のビット）をセットし、割り込み処理終了時にクリアする手順が必要なように見えるのですが、この理解で合っているでしょうか…？（今回は優先順位の設定は使っていないので何もしていません）58.95kg(16:15)

［変更申請：途中経過(4)］

じゃーん。

26-Aug-2018に書いた変更申請書で、無事DMR対応の免許状になりました。これでTYT MD-380を安心して使うことができます。

とはいえ、通信相手がいない…？59.70kg(17:45)

［Lichee Pi nano動作確認］

08-Sep-2018の手順でLichee Pi nano向けのU-bootをビルドし、得られたu-boot-sunxi-with-spl.binをSDカードに書き込んで起動するかどうかを試してみます。PCとLichee Pi nanoとを繋ぐ方法は結構悩んだのですが、ブレッドボードを使ってこんな風にしてみました。

しかし本格的にコードを書くのであれば、もう少し何とかした方が良い気はします。せめてリセットボタン代わりに電源のon/offをきちんと制御するような何かを付けてみるとか。

とりあえずSDカードに書き込んだU-bootはこんな感じに起動できているので、次のステップへ進むことはできそうです。58.95kg(23:05)

［FONTX2覚え書き］

FONTX2用JIS X 0213フォントを25-Mar-2016のfontx2pbmで画像化してみました。public domain扱いのフォントなので、変換後の画像は無加工です。

別にここまで詳細なものは要らないのですが、ちょっとこの手の画像が必要になったので作ったという話です。58.50kg(25:10)

［Lichee Pi nano覚え書き］

Lichee Pi nanoなるボード、Cortex-A全盛のこのご時世にARM926EJ-S(Allwinner F1C100s)を載せているというのでちょっと発注してみました。

ボードが届くまでに時間がかかるので、その間に编译和配置uboot — 荔枝派Nano 全流程指南を参考にU-Bootのビルドを試しています。しかしこの方法ではうまくいかなかったので、自分なりの方法で通してみます。基本的には03-Jun-2016の手順、つまり


git clone https://github.com/Lichee-Pi/u-boot.git -b nano-v2018.01
cd u-boot
gmake CROSS_COMPILE=arm-none-eabi- licheepi_nano_defconfig
gmake CROSS_COMPILE=arm-none-eabi-

となる訳ですが、ビルドの最後にこんなエラーがでます。


  LD      spl/u-boot-spl
  OBJCOPY spl/u-boot-spl-nodtb.bin
  COPY    spl/u-boot-spl.bin
  MKSUNXI spl/sunxi-spl.bin
  OBJCOPY u-boot-nodtb.bin
  CAT     u-boot-dtb.bin
  COPY    u-boot.bin
  MKIMAGE u-boot.img
  COPY    u-boot.dtb
  BINMAN  u-boot-sunxi-with-spl.bin
  OBJCOPY u-boot.srec
  SYM     u-boot.sym
  MKIMAGE u-boot-dtb.img
  CHK     include/config.h
  CFG     u-boot.cfg
  CFGCHK  u-boot.cfg
Error: You must add new CONFIG options using Kconfig
The following new ad-hoc CONFIG options were detected:
CONFIG_SYS_MALLOC_CLEAR_ON_INIT
CONFIG_SYS_USB_EVENT_POLL

Please add these via Kconfig instead. Find a suitable Kconfig
file and add a 'config' or 'menuconfig' option.
gmake: *** [Makefile:870: all] Error 1

一応u-boot-sunxi-with-spl.binは得られているものの、何かが気に入らないようです。scripts/check-config.sh, scripts/config_whitelist.txtによるu-boot.cfgのチェックでエラーを起こして止まっていることまでは分かりましたが、根本的に直すのも大変そうなのでMakefileをこんな風にいじって逃げることにします。


--- Makefile~   Sat Sep  8 20:05:09 2018
+++ Makefile    Sat Sep  8 20:15:44 2018
@@ -867,7 +867,7 @@
        @# Check that this build does not use CONFIG options that we do not
        @# know about unless they are in Kconfig. All the existing CONFIG
        @# options are whitelisted, so new ones should not be added.
-       $(call cmd,cfgcheck,u-boot.cfg)
+#      $(call cmd,cfgcheck,u-boot.cfg)

 PHONY += dtbs
 dtbs: dts/dt.dtb

とりあえずこれで、ビルドは完了します（というかエラーを黙らせただけなのだが…）。

得られたU-Bootが動くかどうかはまだ分かりません。動けば良いなとは思うのですが、現時点ではボードが届いていないのでなんとも。59.10kg(21:15)

［DMR覚え書き］

PCとの接続方法と、アナログ(FM)時に選択可能なバンド幅は知っておいた方がいいかなということでちょっとまとめてみる。列挙した機種はRadiosificationのComparison of DMR radiosから、RecommendedがYesのもの。Retevis RT80は個人的に気になっていたのでこれも追加している。

TYT MD-380/Retevis RT3, TYT MD-390/Retevis RT8: DFU, 12.5kHz/20kHz/25kHz
Ailunce HD1: UART, 12.5kHz/25.0kHz
Connect Systems CS580: UART, 12.5kHz/25.0kHz
AnyTone AT-D868UV: UART, 12.5kHz/25.0kHz
Retevis RT80: UART, 12.5kHz/25.0kHz

DMR機同士でアナログ通信を行うなら別に12.5kHzだろうが25kHzだろうが問題にならないとして、フツー(?)のアマチュア無線機とアナログ通信をする場合は（MD-380の場合）バンド幅の設定を20kHz/25kHzのどちらにするかがよー分からんというのが今日の日記の趣旨。でもRT80のマニュアルを見るとModulation limit ±2.5@12.5KHz; ±5.0@25KHzと書いてあるので実は20kHz/25kHzのどちらでも良かったりするのかもしれない。局免がおりてから実際に試してみれば分かるのだろうけどまだおりてないし…

DMR機はアナログ→デジタルへの移行を緩やかに行えるのがウリと聞いているので、アナログでの通信がどの程度使えるかも見ておきたいんだけど、実際のところどうなんだろう（自分が調べた範囲ではアナログでの使用実績は見かけないような）。

MD-380 CPSで設定する各種項目の説明、ARRL Ohio Section Digital Mobile Radio - DMRのHow to write a Code Plug Video and PowerPoint presentationの一番下にあるPowerPoint slideに詳しく書かれているのでこれを一読しておくと良さそうな感じ。CPSの操作概要はDMR Code Plugs ExplainedのPDF。ARRL Ohio Sectionのサイトに限った話ではないけど、出回っている情報の量と無線機を使う人の数を見るに、DMRを始めるならMD-380(UHF)が最良という感じ。安いのとFMラジオが聞けるという理由でRT80欲しかったんだけどね。58.45kg(23:20)

［MD-380、触ってみる］

MD-380、まずはAdafruitの記事にあるように無線機の設定を何も変更しない状態でCPS(Customer Programming Software)から無線機の情報をダウンロードして保存しておき、万一に備えて保存しておきます。

無線機自体の操作方法を調べるため、設定メニュー一覧を探索してみました。大体こんな感じの階層構造になっているようです。ざっと触った感触としては、

IC-P7よりも重くずっしりした感じがある
ボリュームはアナログつまみのように見えるが実際はデジタル制御(0〜9)
起動音やキーパッド操作音はボリュームに関係なくうるさい
周波数の選択つまみはVFOではなく、あらかじめプリセットした周波数(Channel1〜16)を選択する
1000件分のメモリは、16チャネル×250ゾーンで管理する
CPSから設定を変更しない場合、何も操作しなければ10秒でメインメニューへ戻される
キーパッドの操作はオートリピートが無い
メニューの操作は▲/▼/Confirm/Backボタンしか使えない（メニューの項目に数字があるもの、たとえばUtilities→1 Radio Settingsを選ぶ際は1のボタンを押してもRadio Settingsを選択できない）
Program Radioは現在選択されているChannelの内容を一部編集する
Utilities→1 Radio Settings→12 Mode、CH Modeは現在のチャネル名が表示されるのに対し、MR Modeは現在の周波数が表示される
Date/Timeを設定しても、電源offでリセットされてしまう（そういうものみたいです、とYouTubeに動画あり）

なんというか、フツー(?)の無線機というよりはガラケーに近い感覚があります。で、MD-380単体ではほとんど何もできず、CPSでがしがし設定しないとどーにもならないです。

併せて、MD-380のファームウェアのバージョンも確認しておきます。手元にあるのはD014.004となっているので、FAQを見るにD002/D003(old vocoder)ではないと判断できます。しかし、現時点では最新のファームウェアが載っているからでしょうか、Google Groupsのmd380toolsにあるこの書き込みがちょっと気になります…このファームウェアだとmd380toolsが使えないように読み取れます。58.80kg(10:40)

［変更申請：途中経過(3)］

JARDからアマチュア局の保証通知書が届きました。保証願書は適合し、申請書類は所轄の総合通信局宛に提出したこと、免許状は約一ヶ月後に送付されることが書かれています。保証番号の他、調査報告書とこれを送るための返信用封筒も入っていました。

工事設計書に送信機の諸元（占有周波数帯幅や符号化方式・使用するCODECの名称等）を書かなかったのでどうなるんだろうかと気になったのですが、ここでは問題にされないようですね。総合通信局の判断を待ちましょう。

♪

MD-380が届いているので、アンテナは付けない状態で、とりあえずUSBデバイスとしていじってみることにします。

まずはお約束のdescriptor読み出しから。プログラミングケーブルは単にMD-380をPC等に接続するだけの機能しかなく、MD-380の電源を入れることでMD-380自体がUSBデバイスとして認識されています。とりあえず、USB2.0についてlsusbをしてみます。その辺のUSB serialの類とは同じようには見えていないので、CHIRPでの対応は難しいかもしれません。

次に、TYTのダウンロードページからMD-380 SOFTWARE 0321に加えてUSB Driver for digital radioもダウンロードしてWindowsマシンにインストールします。ドライバのインストーラーにはSTMicroelectronics DfuSe v3.0.3と表示されているので、おそらくDfuSe USB device firmware upgrade STMicroelectronics extension: contains the demo GUI, debugging GUI, all sources files and the protocol layer (UM0412)に類するものが使われていると推測します。dfu-util（OpenBSDのportsにも入っています）とReverse Engineering the Tytera MD380を参考に、SPI Flashの中身を吸えるかどうかを見てみたいところです。58.80kg(18:25)