Luckfox

 V3sを見つけたときに、カメラモジュールを使ってなにか作ろうとしたときに面白そうだな…と思っていじってきてみていたものの、残念ながら過程で壊してしまったのでストーリーは一旦お蔵入り。Lichee Zeroを先に調達しても良かったのだけど、dockとはコネクタ配置が違うし、ちょうどMilk-VとかLuckFoxとか出てきたこともあってそれを先に眺めてみることにした。

両方、入手してはいるけど、問題は、Lichee Zeroとは世代的に違いどちらのボードもMIPIサポート主眼のようであること。MIPIは、解像度などによって使用するレーン数は違うし、信号レベル的規格は共通とはいえ使用するコネクタは統一されていないので、ラズパイでさえ1mmピッチ15pinと、0.5mmピッチ22pinの2種の実装がある。流石に1mmピッチはコネクタサイズが大きくなる関係で、Luckfox、Milk含め0.5mmピッチ品が主流になってきているみたいだけど、ピン数は15、22、24といったところで、ラズパイ用のカメラモジュールが入手しやすいとは言っても、ほぼ間違いなく「ピッチ・ピン数変換コネクタ」が必要になる。

変換コネクタさえ作れてしまえればどちらのボードでも良いのではあるけど、LuckFoxのほうであれば、BT.656を含めCMOS parallelを実装しようとする動きがあるように思えた（あくまでも検索できた範疇で）。

環境づくり

　LuckfoxでもMilkでも、結構webを使って一通りの情報が出されてるんじゃないかと思う。Licheeでは中国語主体記事が多くgoogle翻訳使って読む、みたいなケースがあったけど、Luckfox、Milk共英語で書いてくれているのでなんとかならないわけではない。

カメラ（モジュール）を使おうとすると、デバイスドライバをビルドしないとならないとか起こるので、buildrootやらyoctoやらを使ったSDKを、最低一度は通しておく必要がある。LuckfoxにしてもMilkにしても、実際に活用するかどうかは別として、ヘテロなマルチコアSoCを使っている関係で、汎用的に入手できるコンパイラを使えばビルドできるとは限らず、SDKが提供されているならまずそれを使うことになる。必要な情報はwikiにあるのでその内容をたどればよいのだが。ヘテロマルチコアであっても負荷分散とか機能してくれると良いのだけど、どちらも２つコアが入ってまっせーという構成らしい。タスク分けみたいなことができてくれたら良いのにな。

ハマった？

　wiki掲載の開発用推奨環境はubuntu Jammy (22.04)ということになっているのだけど、不幸にも？自宅ではDebian使いでtrixieになっている。親戚とはいえ基礎としているツールバージョンが異なることには注意が必要になる。結果として、２つ問題発生。

一つはSDKで使用しているlibffiが若干古いバージョンであることで、そのbuildに失敗する。内容としては　https://github.com/mxe/mxe/issues/3082　に記載されているものと同一で、libffiのバージョンを3.4.6にしてしまえばよい。libffi.mk内で、使用するバージョン（＝ダウンロードしてくるソース）が指定されているのでそれを書き換えるとともに。予めlibffiソースtgzのsha256を確認し、合わせてlibffi.hashの内容も書き換えてやる必要がある。

もう一つはatmb-wifiドライバのビルド部分で、これ、特にコンパイラなどがリソース食い合いしているとかということが起こっているわけではなく、単にmakeが進まない。一連のbuild script (build.sh)を確認して見ても、特に問題はなさそうに思われるのだけど。

スクリプトを部分実行などしながら確認してみると、trixieとjammyでは、gnutoolsバージョンが違っていると思うけどgccバージョンは関係なく、makeのバージョンが問題であった。

trixieはmake4.4、jammyはmake4.3なのだけど、trixieのmakeを入れ替えるためにbookwormから持ってくるのはリスクがあるように思い、ソースからmakeしてしまう方を選んだ。つまりtrixieデフォルトのmake4.4は/usr/bin/makeのまま、/usr/local/bin/makeにmake4.3を置くことにして、後々alternativesを使って切り替える、か、な…。

atbm-wifiは、make4.3を使えばbuildできたので、全体をビルドし直すことで整った。

とりあえず。

　で、こいつをインストールするのか？というと、まだそこまでは試してない。とにかく、開発環境サイドで、必要ならデバドラのビルドなど可能になったので、この先順を追って試していきたい。

Lichee Zero Dock その２

 忘れてたわけじゃないんですがちょいと手を付けられずでいたLichee Zero Dock。改め、カメラを動かそうと、持ち出して、buildrootで再始動、したのは実は２年ちょっと前で、その後の紆余曲折。

このボードを手に入れた直後ではまだカメラサポートも怪しく、その後MIPIサポートが出来上がったのなんの、という記事は見たりしていたのだけど、これはLinxu5.19改め6.0で取り込まれているようです。前回は5.10あたりで足踏みしたので、今回は6.0で見ていこう、と思っていたら、もう6.1に移りそうですんで、書いている時点での最新6.1.4で行こうとおもいます。

buildroot

buildroot.orgから新しいものを持ってきて、一旦ビルドを試してみると、ubootをビルドする際、sun8iサポートのethernetを有効にするとエラーになってしまうのでそれは追求せず、一旦その前の版で(2022.02.8)、エラーなくbuildできることを確認。この版のデフォルトのLinuxカーネルは5.3。しかしdevice treeをいじってないので、このままでは「動いてますねー」とシリアルコンソールで見えてるだけなので、本番に取り掛かることにします。Ethernetのdevice treeについては、こちらのサイトを参照しています、翻訳なしには到底読めませんが、googleのおかげで翻訳でき、このようにドキュメント化してくれているのは助かります。そのサイトの記述の通りu-bootのdevice treeを修正します。Kernelの方は、それより進んでいるため、少し調整が必要です。他に必要なこととして、うちではdhcpでアドレス割当しているのでdhcpcdをbuildするように設定しました。buildは問題なく進み、75Mbytesほどのイメージが出来上がります。これをmicroSDに書いて、ブートしてみると、ちゃんと動いて、ネットワークにもぶら下がってくれました。しかしusbが、ドライバは読まれているものの動いてくれません。

その後。Buildroot-2022.11に含まれるuboot-2022.01では、device tree修正無しでethernet動きましたので、上記は、逆に、行うべきではない修正をdevice treeに行っていた、ということになります。しかし、依然としてusbは動かず‥。

カメラ

手元に、昔秋月で調達したMTV-54K0DNがあります。これ、息が長くて、今でも販売しているようですが、CCDだけに？それともアナログビデオがあるから？電源として12V必要なのが少々ネックです。

このカメラモジュールには、アナログビデオ出力以外にBT.656があるし、AWBなどスイッチもついているのでこういうボードでの制御は面白みがあると思うのだけども、V3s自体、デバイスとしてBT.656への対応はあるものの、デバドラ事例がまだ見つからないこともあり、このボードでカメラを使うには、CMOSパラレルがまず先決、だよね。

カメラモジュールとして安価で手に入りやすかったのは次の２種、一つはov7670、もう一つはov2640。ov7670の方は、Arduino向けにレートを落として使う事例が見つかりますが、手に入れたモジュールは故に3.3V単一動作になるよう構成されていてかつフラットケーブルでつなぐようになっている関係で、Lichee zero側がフレキコネクタになっている以上中継用のボードを作る必要がある。その関係で、フレキ上に実装されていてかつ信号配置を変更する必要がないov2640のほうが楽なので、ov2640をまず動かそう。なお、ov7670は、FIFO載ってないやつなので、Arduinoなボードでは、多分低フレームレートにしか対応できません。まとにかく、3.3v → 3.0vと1.8vだったかに落とすLDOが搭載されているだけなので、LDOを取っ払って、LDO出力端子に必要な電源を配線してやれば良さげです。

Build & test...　

　で、ov2640を使うようbuildrootをconfigし、device treeを作って動かしてみると、実のところ結構すんなり動いてくれたんですが、あれこれ試したり整理したりしているうちに、Lichee zeroがフリーズするようになり、その際V3sがチンチンになるように…　カメラドライバをロードしなければLinuxは動いているので、ISPが壊れてしまったようだ。

さいごに

　というわけで、残念ながらこの記事は完成できず…。記録を残せてないので、動いた、という証拠がなく申し訳ない。

なお、Lichee Zero Dockでは、ボードマニュアル上CMOS parallelとMIPIがどちらも使えそうに見えるのだけど、MIPIにはコネクタは載っておらず、1mmピッチ15pinフレキコネクタを搭載してやれば使えるのではないかとは思いますが、回路図面見ればCMOS他と共用ピンがあるため、device tree含めての見直しが必要になるだろうと思います。流石にMIPIのカメラモジュールまでは入手してなかったんですが、いずれLichee Zeroを使って監視カメラ的なことは試したいと思っているので、そのときに再戦したいと思います。

なお、CMOS parallelを搭載しているデバイス、ひいてはボードは減ってきていて、MIPIに移ってきているので、ov2640を活かすためにはLichee Zeroを少し押さえておかんといかんなー。

Time server, reloaded

 前回書いてから、家のリフォームがあったり、Jetson Nanoでarmbianがどうにもうまく動かないとかLichee Zero DockでDVPなカメラ(モジュール)を動かすためにbuildrootするとか結局DVP I/F周りが壊れてしまったらしくV3Sがチンチンになっちまう（Linux自体は走行している）、みたいな、ネタになりそうなことはそれなりに無くはなかったのだけど、まとめるモチベはちょっと無かった。

とはいえ、ぼーっとPrimeVideoばっかり眺めてても仕方ない。

GPSとgpsd

昔制作したtime server、Trimbleの古いGPSを使っているのだけどもバックアップバッテリが切れてしまっていて、再起動が必要になるたびに、NMEAモード及び通信モード切り替え（Trimbleなのでデフォルトは、TSIPでかつUARTによるシリアル通信モードは9600bps 8O1であるため、NMEAモード切替と通信モード9600N1への設定変更を、Windowsを使って実施）をしてやらないとならない。最初に製作したときは、テキストでgpsデータを読むことができるNMEAモードを使ってちゃんと衛星掴めているかどうかなど目視していたのだけど、実際、gpsdとクライアントが使えていれば、ASCIIテキストである必要はもうない。通信モード（パリティ設定）を変えないとならないのは、Jammyに含まれているgpsdが、8N1じゃないと通信できないためで、バッテリが切れてしまったとき、初期状態のgpsを使えないが故だった。

systemd

gpsdのクライアントであるcgpsでは、NMEAじゃなくともTSIPをハンドリングできるので（gpsmonはだめだが）、Linuxサイドで起動時にUARTの通信モードを8N1から8O1へ変更してやればよい。それをやるにはsystemdを使って、gpsdが立ち上がる前にsttyしてやれば良い（のだけど、gpsdは、nobleのものならparityを自動判別しているようには思うので、仮にgpsモジュールのデフォルトが8N1ではないとしても、何もしなくても動くかもしれない…）。

gpsは、Nanopi NeoのttyS2に接続、ppsはPA6に接続しているので、armbianEnv.txtに

param_pps_pin=PA6

追加し、gpsdを起動するgpsd.serviceに：

ExecStartPre=/bin/stty speed 9600 parenb parodd cs8 -cstopb -F /dev/ttyS2

を追加してリロードさせてやれば良いことになる。

pps

念の為（…）、Windows用の設定ツールを使ってgpsのpps出力が有効であることを確認、armbian側で設定が認識されているようではあるのだけど、ppstestではなかなかうまくfetchできていない。

$ sudo ppstest /dev/pps0

trying PPS source "/dev/pps0"

found PPS source "/dev/pps0"

ok, found 1 source(s), now start fetching data...

time_pps_fetch() error -1 (Connection timed out)

...

PPS信号の立ち上がりを使うのか立ち下がりを使うのか？デフォルトは立ち上がりのはず。

$ sudo cat /sys/kernel/debug/gpio

gpiochip0: GPIOs 0-223, parent: platform/1c20800.pinctrl, 1c20800.pinctrl:

 gpio-6   (                    |pps@0               ) in  lo IRQ 

 gpio-166 (                    |cd                  ) in  lo ACTIVE LOW

 gpio-204 (                    |usb0_id_det         ) in  hi IRQ 

立ち下がりで割り込み検出？

なら、armbianEnv.txtにparam_pps_falling_edge=1を追加して立ち下がりにしてみると、ppstest上は検出できるようになる。

$ sudo ppstest /dev/pps0

trying PPS source "/dev/pps0"

found PPS source "/dev/pps0"

ok, found 1 source(s), now start fetching data...

source 0 - assert 1775693725.000138656, sequence: 55 - clear  0.000000000, sequence: 0

chrony

NTPサーバーとしてはchronyが最近はよく使われるようで、使ってみることにする。よくGPSとの組み合わせではNMEAメッセージも使うように設定されているようだけど、ppsだけ使えれば良いので、次の一行をchrony.confの最後に追加。

refclock PPS /dev/pps0 refid PPS

次の状況。

$ chronyc sources

MS Name/IP address         Stratum Poll Reach LastRx Last sample               

===============================================================================

#* PPS                           0   4   377    16   +737ns[+1442ns] +/- 1891ns

^- alphyn.canonical.com          2   6   337    45  +3332us[+3329us] +/-  120ms

...

ということで、ppsがソースとして使われるようになりました。