Nano Pi NEOにSPI LCD

Nano Pi NEOはarmbianをインストールしてある。なので、armbian-configで、使用するデバイスを追加する。

そのままだと、SPI (host)はoverlayに追加はされるけども有効にならないので、 /boot/armbianEnv.txtに次の行を追加してリブート。
param_spidev_spi_bus=0
param_spidev_max_freq=40000000

参考にさせていただいたサイト：
https://zigsow.jp/item/335215/review/337814
https://qiita.com/toyoshim/items/84c026e97f6be200cb19

あとでUSBも拡張しようと思ってるのでそっちもついでに有効にしておく。さてこれで準備はできた。

使おうとしているSPI LCDは、M028C9341SDと言う型番になっている。ようは、2.8inch LCDで、ILI9341を使っていてSPIで動作するようになっているもの。ILI9341は、いわゆる「スレーブバス」(マイコンなどのメモリバスにつなげて使う）用のパラレルI/Fがあり、Arduino用にそれを用いたLCDもある。そちらも持っているのだが、何せNano Pi NEOではGPIO線数が足らない（8bitパラレルデータ＋LCD制御信号）。

このLCDの裏面を見ると、端子名が表記されていて、表側にマークがある1ピン側からVcc, Gnd, SPICS, Reset, DC, MOSI, SPICK, LED, MISOとなる。このうちLEDはバックライト電源なので、+3.3Vに直結で動かす。本当は、デジトラ通して、GPIOでバックライトOn/Offを制御するべきなんだろうけど、後回し。
電源3.3VとGND、SPI系は素直につなげばよいが、それ以外については次のように接続している（参考サイトから）。
Reset -> PG11 (GPIO203)、DC -> PA1(GPIO1)

ドライバは、fbtftを使うので：
・/etc/modules-load.dにfbtft.confとして、fbtft_deviceと記したファイルを用意。
・/etc/modprobe.dにfbtft.confとして、
　options fbtft_device custom name=fb_ili9341 speed=16000000 rotate=270 gpios=reset:203,dc:1
としたファイルを用意。

シャットダウンしてLCDをつなぎ、電源投入すると、意外とすんなり動いてくれる。

さて、…


/dev/fb0で動いてくれるので、グラフィックスできるはず。
さすがにQVGA液晶でX11系のデスクトップ出しても仕方ない。
どうやって転用すっかな…。





(9/29　追記）

仕事でこれ使う計画を立てているのだけども、そちらで用意したセットはなにか具合が悪い。fbは立ち上がるがしばらくすると落ちてしまう。
原因がわからず、再度、自宅でこの構成をして確認…の状態からしばらく作業できず、3週間強も経過してしまいました。

さてさて。
再現に際して、ピン位置的な使いやすさを優先しようとして、resetとdcに、プライマリには他の機能が割り当てられている端子を使ってみようとしました。つまり、プライマリな機能を有効にしないまま使おうとしたとき、GPIOとして動作することを期待したわけです。WiringNPではoutとなっていて、出力設定されているようですが、GPIOとしては機能してくれない様子。GPIOがプライマリになっていない端子はやはりdt書かないとダメだということですね。
# おっと。ということは、BBBでうまくいってない部分もそこだ、きっと…。

ということで、上記と同じ設定になおしてみると、fps=33とレポートされます。確認を簡単にするために、キーボードとマウスをUSBにつないで、インストールしたxserverもちゃんと稼働してくれたところを見ると、どうも配線上の問題臭いですね…。そこから見直すことにします。

xserverの動作確認して、止めたところ。（xterm開いてても何だかわからないでしょ?)

(10/8追記)

　仕事で使ってる方は、何かとジャンパでは都合が悪いため、ユニバーサル基板を加工してベースボード的なものを作成し、NanoPiを搭載してあります。そもそもはSPIポートを他の目的で使うために、ピンヘッダへと引き出した上で、そこにジャンパでLCDを配線していたんです。

配線直すか…ということで、ピンヘッダおよびNanoPi端子からピンヘッダまでの配線を撤去して直接LCDモジュールへと配線して見たところ、悲しいことに状況変わらず。
上記、自宅で動いていた同じLCDを持ち込んで配線して見た結果は何時間でも動いてる。
「モジュール不良」という結論だね、こりゃorz。

あ”～、またLCD調達しにいかないと…。

ドアノブ交換

組み込みじゃなくて修理ネタだけど、風呂場のドアノブが壊れた。

プラスチック製のドアノブだったので、経年と言えば経年なのだろうが、どうも、ノブをひねった後に戻すためのバネを引っ掛けている部分が、欠けてしまったようだ。

そういえばしばらくドアノブが回り辛かった。
とうとう、ノブは外れてしまうようになってしまったし、しかし接着してしまうわけにもいかない。

仕方ないので交換しようかとおもったのだが、取り外しかたがわからない。
円筒錠(鍵不要なので空錠）だろうと思っていたのだが、チューブラタイプで、しかし円筒錠用取り付け穴に取り付ける前提の構造になっているものだった。

ところがこいつの外し方がわからない。

壊れた反対側のノブは、大抵、片側ノブを外せば引き抜けると思い込んでいたのだが、どこかで止めてあるようだ。戦っても仕方ないし所詮再利用できないので(反対側ノブのプラ破損は直せないので）、仕方ない、破壊することにする。

破壊後色々調べてみると、ノブ蓋を外すと内部に爪でかみ合わせている事がわかる。しかし、その爪、ノブの奥のほうにありかつ手で動かせるものではなく、プライヤあるいは細いヤットコでグッと開いてやらないとならない。そんな工具は持ってない。結局破壊するしかなかったようだ。

一時間は格闘の結果、円筒錠Φ54でバックセット100mm、ラッチ径Φ22のドアノブであればつかえると判明、もし円筒錠があればそれ、なければチューブラで円筒錠共用可能なものを調達にgo。

最初に行った店ではバックセット100mmのラッチがなく、別の店に。こちらには探し物のラッチがあった。円筒錠は最近の流行りではないようで、そんなに長いバックセットのラッチがない。
結果、比較的安価な円筒錠共用のチューブラタイプで、バックセット60mmのラッチがセットになっているもので、バックセット100mmのラッチを同時に調達し入れ替えて使うことにすることにする。
メーカーのwebで同じものは見つからなかったが、次の一部になるはずだ。
https://www.hinaka.co.jp/item/detail.php?id=3_4_2&cate=cate3
これのラッチだけを交換しているわけだが、どうもHILOGIKという金物商社さんが調達しているもののよう。G-285とある。

チューブラ錠は取り付け容易なので、合うものさえ見つけられれば、取り付けは30分もかからず出来上がり、すっきりしました。

Nano Pi Neo

書き溜め分はこれで最後。やってみると少ないよね…。

Nano Pi NEOは、パフォーマンス的にはラズパイ2と同じ～以上くらいある一方で、潔くビデオ系出力を省いているのでヘッドレスユースには向いてるよね、と言う感じ。なので、こいつを使ってx86なファイルサーバーを置換しようかと思っている次第。発熱つまり消費電力も、騒音も、現状比大幅減！！

自分用に一台買ったときにFB掲載、右の写真で下に見えてるBBBの1/3くらい?
この後、USB OTGじゃなくピンヘッダから電源供給するようにして、アクリルのパネル(ケース、じゃないな…）を追加購入して現在使用中。

このボードなかなかおもしろいので、この後業務用にも一台購入させてもらって展開準備中。
最初はBBBも業務向けに購入させてもらって、そこでやろうと思っていた企画があるのだけども、U-Boot overlayの余波があるうちは難しいものもあり、今後はこいつでやろうかと思っているところ。（なんせ安い。BBBの1/5程の値段だし…。)


1.ヘッドレスであるが故
　2.54ピッチヘッダを生かすと、それなりにつながるものあるんだよね…USB 2.0HS Hostが2ch、SPI、I2C、I2Sでしょ…結構いいとこ突いてると思う。

2.シリアルコンソール
　UART-USBアダプタ(PL2303)で、下界とインターフェースさせる。Nano Pi側でgetty起きてるので問題なくログインできる。
ホストとしてWindows7は問題ないが、このPL2303は古くて、Windows10用ドライバはリリースされてないバージョン。ま、Windowsには問題なくつながる。
問題はLinux。Systemdになる以前はあんまり考えずとも、コンソール側はminicom、最悪cu使えば良かったんだが、最近のDebianでは大丈夫か?と思ったら案の定minicomでは通信できない。何故??
cuでは、通信速度を合わせてやればOKだった。
cu -l /dev/ttyUSB0 -s 115200
じゃあラズパイも一緒だよね、と思ったらこれがまたあかん。電源も気になるが（HDMIアダプタを変える前の話)、minicomは言うまでもなく、cuでもちゃんと通信できてない。Webリサーチするとitplantsさんでscreenを使って成功しているじゃないか! ということで、早速screenをインストールし,
screen /dev/ttyUSB0 115200 -L
これでようやく事なき？を得た。

3.USB

　初期から使えるのは、USB2.0HSなType-Aが一つと、曰く電源供給を兼ねるUSB2.0 OTGなmicro-ABが一つ。電源はピンヘッダから供給しているので、Type-Aとmicro-AB両方共オープンなのだが、有線LANを使わない場合はこれではポートがちょっと足らない。

USBにはセルフパワーとバスパワーがあるわけで、通常、USBホストは、接続されたデバイスが、セルフなのかバスなのかを見てから電源供給するかどうか判断する。そのための電源スイッチICがある。

まぁ、ほとんどの場合バスパワーなので、専用と割り切って二段重ねのType-Aを仕入れて、仕事で使っているものには搭載してみた。手はんだケーブルなので、HSはちゃんと成立するのか?と思ったが、動いていそうなのでそのままとしてある。

仕事で使っているものは、持ち歩きする可能性も踏まえて、nano piと周辺を搭載する「ハット」を、2.54mmピッチのユニバーサル基板を使った手作りで構成しプロトタイプとしたが、この二段重ねType-Aは2.54mmピッチではなくo-2.54-o-2-o-2.54-oで並んでいてそれが標準だった。若干無理に2.54ピッチに載せてハンダ付けしたが、個人用でやるときは、基板付きの二段重ねType-Aを探そうと思う。

なお、このとき、件のU-Boot OverlayでUSBを有効にし、boot時にUSBポートが追加されていことを確認します。新しいボードは最初からこいつなので、惑わされることがない。

この辺は、現在お仕事側で、記事としてまとめながら行っている作業があるので、出来次第そちらで公開、としましょう。

4.デバドラの追加

　NanoPiはBBBやラズパイよりさらに開発ボード色が強く、カーネルモジュールの追加に若干の不安。しかし、armbianでちゃんとカーネルソース提供しているじゃん！　ということで、楽しみ甲斐のあるボード。

ようやくラズパイが(だいぶ)安定したようなので、Nano Pi他の開発時ホストとして頑張っていただこうと思っていることです。

(10/8追記)

　「可搬性」で、LANを無線にしなきゃ、と思ってたんですが、最近のLinuxはネットワーク設定系のツールがゴチャゴチャで、昔のようにinterfacesに書けばおしまい、とはなかなか行きません。今じゃifconfigもない（ことがある）ときたもんだ。

と言うわけで、備忘録的には、udevいじってるとなれば残しておかねば（笑）。

udevも、rules.dにpersistent-net.rules用意しておけば良かったのはもうちょっと前のことになっているようで、いきなりNIC差したりUSB WiFi差したりすると、ネットワークif名からわけのわからない状態になります。

そのあたりの解説が、
https://tokyodebian-team.pages.debian.net/pdf2017/debianmeetingresume201707-meetup-sapporo-presentation-yyoshino.pdf
にあるので、これを元に、systemd向けの設定と、udevの設定、両方を行い、まずデバイスが、「古き名」を使えるようにします。

なぜ『古き名』か。これやらずにOSがつけた名前そのまま使おうとすると、「そんなインターフェースねぇ!」と文句いうツールがいろいろとあります。つまり、一過性のことかもしれませんが、eth0とか、wlan0とか、レガシーな名前が必要です。それら、自分でつけられるようにしておく必要がありますが、上記pdfを見れば解決できるだろうと思います。

そこまでいけば、nmcliであろうが、connmanctlであろうが、使いやすい方をどうぞ、の世界ですね。

Raspi3

ARMのボード、と言えばラズパイ、と言うくらい、日本での比率は高そうです。
BBBを調達した時にはRaspberry Pi2がリリースされていて、値段的にも安い事は知ってましたが、そもそもがデスクトップを目指していることが当時BBBに流れた理由でもありました。

仕事上で考慮しておく必要が出た事もあり、さらに安い"3"が出た事もあり調達したのが去年の事。しかしこのボードは…。

1.電源に悩む
　起動するだけなら1Aでも起動すべ、と思ったらとんでもない。そもそも、デスクトップユースは業務上必要な解ではないので、シリアルコンソールで動作させたいんだが、ということで1.6Aの電源をつないで起動し、シリアルコンソールを使えるよう設定して再起動し、apt update -> upgradeするとクラッシュしてインストール状況を破壊あるいはファイルシステムを破壊して復旧不可能となる。このとき、aptまわりでのエラーが報告されるので検索するも該当なし。
この流れが何度か繰り替えされ、一度はギブアップしてたんです。

再度このラズパイが日の目を見ることになったのは、デスクトップPCがクラッシュしたため。
即座にx86のボード調達できる状況になかった上に、残っていたボードはすべて32bitボードでありLinuxサポートでさえ問題あるケースがある事もあり、もう一度試してみよう、と（手元に残っていた「最速」ボードがAthron 1GHzのITXだった）。

この時、ACアダプタ類は1Aのものしかなく、それではまったく起動に至らなかったが故に持ち出したのが、この5V/6Aのユニット電源（この時のことはFBに掲載。同じ写真だと思う)。
容量的にはこの電源でまったく問題ないはず（5V/3Aが推奨）なのだが、これでも起動時を含めて稲妻発生がなくなるわけではない。
このユニット電源、このままラズパイにfix出来ないので、古いノートPC用のACアダプタに、SI8050SのDC-DCを接続して使うように変更したのだけども状況に変化なく、稲妻と如何に付き合うか、という不安定な使い方を続けていました。
（電源ケーブルを指摘されるかもしれませんが、急速充電対応のものです。）

そもそも、ラズパイ3はHDMI前提だが、HDMIモニタがないためVGA変換アダプタを使用しています(ラズパイ3での使用事例がAmazonの製品紹介ページにあった事もあり）。このアダプタ、画質はまったく問題がないが電源供給は本体すなわちラズパイから受けているタイプ。
しかし、こいつをはずして(たまたま外れて)起動した時には、何ら稲妻発生なく、問題ないことが判明。
どうも臭うので、外部給電可能タイプのHDMI-VGAアダプタを改めて調達して試験しているのがまさに今。

アダプタその物の外観はまったく同一なので、誰かが先駆者で作ったボードとケースが流用しまくられているのであろうと推測(であれば、最初の奴もケース解体してしまえば、外部電源用の供給点が出てくるかもしれない)。印刷されているマーク類が異なるため、同一社が製造しているわけではないように思われる。
これに変え、かつ、オーディオ出力をHDMIにしてやるとだいぶ改善する（まったく稲妻が出ないわけではない)ので、しばらくこれで行ってみようと思う。

なお、ラズパイ本体はこのHDMI端子からも電源供給を受けるようであり、シャットダウン後、ラズパイ本体電源供給を止めても、こちらが生きていると本体にも通電したままとなってしまう。

これらから、本体に電源供給しているACアダプタの供給能力不足とは思えず、ボード上の電源設計を疑っている事もあり、SI8050Sから、別にHDMIアダプタ用の電源ラインを引っ張り出して、試してみるつもり。

2.オーディオ
　時々狂うんだよね。多分これも電源がらみ。
HDMIアダプタを変更する以前、3.5mmヘッドホン端子からオーディオを出している時では、100%音量（pulse audio音量調整)を越えると酷く歪んだ音を出すがアダプタ変更後ではそうはならない。なるほどどこか電源供給が足りてないことは間違いなさそうだ。ちなみに、オーディオ出力はHDMI側から出した方が好みの音質となっている。

いまのところ、改めてx86なボードを調達するつもりはないので、ラズパイ3にはデスクトップPCとして頑張って頂かないとね。こいつでうまくいけば、うちではWindows以外は、サーバーをのぞきすべてラズパイ化して、大幅コストダウン、だな。(サーバーには別のボードを当てる予定。）


(2018.12.28.)
む、この年末も押し迫ったところで、どうやら壊れた？　起動しなくなりましたね。ブートイメージ変えてもディスプレイ出力しない、HDMI外して起動してしばらく放置しても、ネットにぶら下がらないということは多分起動してない。
もうちょっと調べてみようとは思いますが、6月ころからほぼ連続稼働させてみて半年すか。ん～。
某案件で使うこと（3Bじゃなくて3B+ですが）考えてみてますが、当たり外れはあるとしても、ちょち厳しいやも…。

BBB

・事始め（2018年6月9日）

BBBはG+にもポストしましたが、一番最初に手を出したARM SoC搭載のボード。

ふと思えばLinux歴もだいぶ長いですが（NT3.5がリリースされた前後）、ARM7が組み込み用途で主力化した頃に少しかじって以後（「組み込みLINUXシステム構築」、読みました…）、組み込みは勉強したことがあまりなく、しかしこれほどのパフォーマンスがあるボードで色々つなげられるならと、当時は思って購入したものでした。

今、他のボードで起こっている事と同じ悩みだったのだな、と、当時抱えた問題を、思い返せばわかるんですが、このボードには今でもいろいろと勉強させてもらう機会が多くあります。

このボードを使って、某カメラ画像をストリーミングする記事を作成しました。

1.電源の問題

　この手のボードを購入した頃はIoTが知られ始めた頃で、『線』が付いてるのはかっこ悪い、と言う意識が(世間的にも）蔓延しており当然ネットワークにもWiLANでぶら下げたかったんです。

しかし、USBにWi-Fiドングルつけると起動しない、セルフパワーのUSBハブが必要、というのが当時通説で、否定する情報を見つけることはありませんでした。

この認識を改めたのは実はつい最近。ようは、当時一般流通が多かった5V/1AクラスのACアダプタ（携帯の充電器とも言う）では、容量が不足していた、ということ。

現在では2A以上供給できるものが容易に手に入るので、バスパワーのハブでWi-Fiドングル使っても、ちゃんと動きます。この辺はこのボードは素直。

2.組み込みボードとしての本領と容易さの両立って…。

　BBBは、ユーザーが触れる「端子」が、88本も出ており様々拡張できる（であろう）ことが、このボードの売りだったはずです。

結果として、OSサイドでの一環サポートが困難でgive upとなったのが一昨年くらい、なのでしょうか?以後、U-Boot Overlayに移行し現在に至る、と。すなわち、BBBに関する、2017年3月以前の組み込み記事はほぼ使えない。How-To記事を多数掲載している欧米系半導体商社などのweb記事もさほど更新されておらず、参考にならない。

そのことを知ったのは、去年、業務上の必要でこのボードにLCDを載せようと思ったことがきっかけ。なにせweb探し回って出てくるknow-howが通用しない。標準系のI/F(SPIとかI2Cとか)は使えているようだがGPIO系を動かすことができてない。

プログラムで使いたい端子をトグルさせることはできているので、使う方法はあるのだろうし使っている人もいるのだろけど、fbtftは終了して次世代に行っていることもあり、使えるようになるにはまだしばらく時間がかかりそうだ。

この件は、今後もフォローしていくつもり。パラレル系のLCDは他にも試しておきたいことがあるし、多分、BBBではまずはSPI LCDを動かすのが良いのだろう。(調達してあるけど、他のボード用に先に使いたい事情がある。)

なお、「業務上の必要」については優先順位を下げてある状態で、まだ実現するには手が足りてない、ときてる。それ実現できてないせいで、口頭説明が必要な事例が多くて結構大変なんですが…。




・半歩前進（2018年10月20日）

8bit I/Fの、ArduioシールドタイプのLCDをつなげようとしてうまくいかず、何が悪いのかすら判らずで寝かしてあった。

google groupsで質問した事もあったけど、解決に至らず。

そもそも、購入した時は、その品名ラベルからili9325を使ってると思っていたのだけども(UL028C9325D8)、Arduinoにつなげて動かしてみると、ili9341(つまりUL028C9341D8)だと言う。既にそこで混乱していたわけだけども、どっちにしろドライバ読み込みの際に：
[11230.365899] fb_ili9325 fb_ili9325.0: fbtft_request_gpios_match('reset')
[11230.365925] fb_ili9325 fb_ili9325.0: fbtft_request_gpios: gpio_request_one('reset'=48) failed with -16
[11230.383400] fb_ili9325: probe of fb_ili9325.0 failed with error -16

その他のピンもこうだったわけで（上記は当時google groupsに投稿した記事から）、デバイスをili9341に修正してもfailで、どうしてこうなるのか理解できずにいた。

6月の時点で書いたことではあるけど、BeagleBoneはdevice treeの洗礼で、いまgoogleの助けを求めても、dt以前以後の情報が混在しており、どちらを使った情報であるか確認しないと、使うことができる情報が揃ってない状況だし、dt以後ではBBBにnewbieは非常に少ないのが現状だろうと思います。なにせ今となってはBBBは高い。

仕事上の必要で、NanoPiでLCDを使い始め、M028C9341SDを使ってデモセットを構成できたところで、同じLCDならBBBでだって動くでしょう、ということで、戻ってきたのがつい最近。

SPIdevのdtをロード。LCD制御には、データを流すSPIだけではなく、GPIOも使う。ここでGPIO使えなきゃ以前と状況は変わらないわけだが、今度はしっかり使うことができる…　そこで気づいた。つまり、なにもdevice treeを有効にしないと、どのピンもGPIOとしても機能しないのね、と…。何もロードしないと、88pinすべてがGPIOとして使えると思い込んでたんです（実際に、ピンコントロールでは反応していた)。

再び、UL028C9341D8をつなげて、残しておいてよかった以前の設定のまま、SPIdevのdtをロードしたまま、ili9341ドライバをロードさせて見ると、ちゃんとピン設定できるじゃないかっ!

[   64.420757] fb_ili9341 fb_ili9341.0: fbtft_request_gpios_match('reset')
[   64.420854] fb_ili9341 fb_ili9341.0: fbtft_request_gpios: 'reset' = GPIO81
[   64.420866] fb_ili9341 fb_ili9341.0: fbtft_request_gpios_match('dc')
[   64.420881] fb_ili9341 fb_ili9341.0: fbtft_request_gpios: 'dc' = GPIO86　（以後略）

…、そういうことだったんだね、BBB…。

さて、肝心のLCDですが、まだ表示には至っていません。すなわち、ドライバデフォルトのinitコードでは動かない、と言うことなので、用意しなきゃね…。

この先、8bit I/FのQVGAじゃなくて、16bit I/Fの320x480解像度のLCDを使えるようにしたいんですが、そこにはまだ、しばらくかかりそうですね…。


・もう半歩前進(2018年10月22日）

　諸事情でちょっと早く帰宅できたので、早速initコード追加して…　ほーら、ちゃんと動いた。
はぁ～。ここに来るまでの道のりは、長かったわね～。シミジミ。

いろいろと、「戦った」記録を残しておこうかと思い、始めてみた次第。