カメラをいじる・下準備編

その昔手に入れて放置されてるMTV-54K0DN、これ、NTSC出力に加えてBT.656出せます。

最近、ビデオカメラ関連のお仕事が中心になってることもあり、その中でこれやっとかないとダメだよね、という技術があるんです。そこに手をかけておきたいんです。

まずはこのカメラ、とりあえずアナログビデオ系につなげば何か出る、ということで…

JP1に、モニタと電源、付属のケーブルでつなげてやります。ケーブルは切りっぱなしになってるんで、RCAとACアダプタ用のコネクタ付けてやります(右写真)。

ビデオ用の小型のLCDも、このカメラと同じくDC12Vで動いてくれるので、同時に供給してやります。

で、電源入れてやると、あっさり写ります。

右下にチョロッとカメラモジュール自体写ってます。別項NanoPIにHDDつないで試験中を写してみたものですが、ご覧のとおりでだいぶ白いので、AWBくらいは効かせてやる必要がありそうで、arduino使ってやれば、USBアナログビデオキャプチャと組み合わせるとか、色々それはそれで楽しめそうです。が、ここではもう少し先に取り組む必要があります。そうです、直接デジタルで取りこみしてその先XXX。

さて、そこに進むために、BT.656をどうキャプチャするかがなかなか悩みどころ。FPGA使えば取り込みはできそうですが、SoC内蔵品じゃないと、その後の処理系にどうやって取り込んだ絵を渡すのかで悩みます。つまり、USBで接続する事が簡単には行きません。

具合が良い?事に、STのSTM32F4xx、これ、評価用としてボードが多数出回っていて、arduino uno用のシールドを共有することもできたりするし、しかも、書き込みするためのマイコンも、のちに分割可能な形でワンボード化されていてかつ安価。ということで、F4xxで、カメラI/Fが搭載されているF446 nucleoを使ってみようと思います。

MTV-54K0DNは、BT.656は10ピンフレキで出力されているため、それをどうnucleoにつなぐかというポイントがありますが、それ用？と思うくらいちょうど良い変換基板がありますんで、それで解決。

ということで、ハードウエア的な準備は万端。

マイコンIDEですが、x86な環境は死滅状態と言っても良いくらいなので、mbedかな…。再び死蔵することになるかもしれませんが、ここから先はまたの機会に。

NanoPiでサーバー…

モチベーション　/ 2019年7月6日

結構お仕事がbusy状況になっててうちの方は放置プレイ状況が続いてますが、二ヶ月(!?)ほど前の、P4なサーバーの寿命が気になり…を放置もできず試行錯誤中です。つまり、何もしてないかというとそうでもなく、ぼちぼちやってる、というところ。

サーバーに使うにはどのボードが良さげ?

NanoPi NEO、Raspi3、rock64と転がってるったって単に転がってるわけではないんですが、この中でNanoPi NEOだけがヘッドレスでかつ複数台あるので、ファーストターゲットです。今ではラインアップからはなくなってそうですが、NanoPi NEOにはNASとして使えるタイプのボードがあったこともあり。
HDDのっける点では、rock64がUSB3対応してるんでその方が良いかもと逡巡しつつな状態ではあります。

まぁとにかく、NanoPi NEOにUSBなHDDをつなげて、モノは試し。
HDDは、使い古しですが1TなSATAがあるので、それを、外付けUSB3ケースに放り込んで使います。
NanoPiでは、直接USBからブート可能なストーリーが提供されていないようですので、microSDをすっぱり捨てることはできず、u-bootと/bootのために使うことにして、それ以外をHDDに移せれば良い、と言うことになります。

ツール

シナリオは、いっぱいになってしまったHDDのパーティション引越しするような感じではありますが、armbianを使っている場合は、armbian-configのINSTALLセクションで悩むことなく実行することができます。ただ、あらかじめパーティショニングされているHDDを流用したせいなのか、パーティショナーは起動せず、rootfs移動先のパーティションの指定→そのフォーマット→移動実施と言う具合に進みました。コピーが終わるとrebootするかと聞かれますんで、再起動してやります。

終わり…？

もうちっと何かあるかなと思ってたんですが、なにもなくこれですんなりできてしまいます。後はrsync…。
NanoPIは、3種の手持ちボードの中ではもっともメモリ容量が小さく、対ディスクのトラフィックが多いと「おっとっと」な応答になってしまいます。しかしまぁ、microSDにswapがあるのよりは良いような気はするんですが、どんなですかね…。しばらく仮運用してみたいと思います。

止るのはなぜ… / 2019年7月28日

約一日稼働すると、どうもhddが止って、再度スピンアップできない模様で止ってしまう。しかしこれ、hdd側の自動停止なのか、Linux側によるUSBの自動停止なのか釈然としない。
とにかく、hdparmを確認してみると、APM levelは254が設定されているようで、offに設定を変更。
もう一つ、USB device側のautosuspendを止めておく。/sys/bus/usb見て、ドライブを探す。これ、デバイスのバスが変わるとそれに合わせて変更する必要があるので、udevで書きたいところですがとりあえず。
hdparm -B 255 /dev/sda1
cat -1 > /sys/bus/usb/drivers/usb/5-1/power/autosuspend
参照："Power Management for USB"

で、再び様子見。夏休みに入る前には終わらせたい…。けど、それ以前に、Nano Pi NEOのUSBは2.0までなので、これ以上パワー注ぐなら、はなから3.0対応してるrock64でやるべきかもしれない。

それだけではない何か / 2019年8月10日

ほらやっぱり夏休み…　激暑で冷房なしにはやってられないステータスですが、解決に至らずstrugglingな状態。関係ないけど、一昨日は使えたエアコンのリモコン、操作に突如エアコンが反応しなくなり…。応急運転でエアコン自体動くことは確認できたので、どうもリモコンがダメになった?とおもい、スマホカメラでIR発光するか見てみると、案の定ダメ（リモコンは大抵NIR - 可視光に近い近赤外を使っており、スマホのカメラでもその発光状態を確認できる。最近ではよく知られてると思いますが）。ということでamazonに駆け込んで調達しました。エアコンない部屋でこんな作業、到底やってられないです…。

肝心のHDD。
一度rock64がよぎった以上は確認、と言うことで、rootfsだけを、USB3に接続したHDDに移動して動かしてみると、どうもディスクアクセス途上でスタックを起こします。rootfsディスクアクセスに絡む様々なエラーメッセージを発して、最終的にはrebootに至ってしまいます。
この原因が判らず、webさまよっていると、いくつか原因候補がある中で、どうやらUASに起因する、ドライバレベルの問題があるケースに該当、するような動きです。UASを使わずusb storageで運用すれば、この様な問題には至らないようです、若干、hdd側の動き方には怪しい面もありますが…。armbianではusb-storageはカーネル組み込みになっている関係で、bootloaderレベルで、該当のUSB HDDコントローラのdevice ID、product IDをusbstoragequirksに付け加えてやります。

さて、NanoPIですが、linux-sunxi.orgのUSB/UASによると、今使っているUSB3-SATAケースUNI-HAL35で使われている、JMicron  TechnologyのJMS539/567は、オレパイでとはいえベンチマークに使われており、quirksには該当しないようにも思います（故のquirks？）。再起動時など勝手に電源切れてくれちゃうのがいまいち気に入らないんですがそれはさておき、むしろ使っているドライブに問題があるのかもしれません。引き続き一日で止ってしまうようであれば、やっぱりrock64で、かな～。

この暑い時期、P4ホストは室内にあるとはいえエアコンがあるところにあるわけでもなく、ファンの唸りが増してますんで、早めに切り替えたい今日この頃、です。

バトルは続くよどこまでも… / 2019年9月15日

色々試し始めてからはや2ヶ月すぎ、なところですが、安定した結果を得られないままです。この間に、本家Debianがstretchからbusterへとバージョンアップし、armbianもraspbianも同じく更新されました。現行サーバー自身はまだjessieです。それで状況が解決に向かうなら良いんですが、特に変化なし。Nanopi→rock64でUSB3を使ってもUSB2を使っても、UASを使おうがusb_storageを使おうが、スタックしてリブートかかるときもあれば単にプロセスが死ぬ、ロックするときもあれば、という状態で、一歩も進みません。
HDD相性問題だとしても、商売でやってるのではないのでHDDあるいはUSB-SATAブリッジしかもケース付きを湯水のごとく買うわけにも行かず。

このエリア、ゲームでもしない限り、パフォーマンスにそれほど難点はなくなったとはいえ、armプラットではまだ無理で、x86いやx64に戻ってくるしかないのか…　あるいは、その中でも安定度が比較的高いraspi3Bで妥協するか、と言うのが今日までのところです。

そしてどうなった… / 2019年11月9日

あれこれ試行錯誤をしている内に、本当にHDDの方が寿命となってしまいました(つまりエラー多発してろくに動作確認もできない）。
昔のHDDてば、最後にスピンドル方面が「ぎゃっ…」と悲鳴をあげて（いや本当に音がするんです。多分ベアリングが逝っちゃうんだよね、あれ）うんともすんとも動かなくなることがよくあったんです。最近のHDDはこそこそっとエラーを発しては、どっちかというと、「仕事するの疲れたからもう寝る…起こさないでZzzz」みたいな動かなくなり方をしてくれます。結果、本当に使えないのかまだ試験用程度なら使えるのか、判らないまま深くハマっていってしまう、その泥沼の中にいた、という感じですね。

で、新に1TのHDDを調達しまして、また頭からやってる、と、そんなところです。
一時期uasに不信感があったんですが、HDD新調してからはUSB3でもUSB2でも問題なく動いてくれます。
当初rock64で動かしていたのですが、どうもzram絡みでエラーログが残るしカーネルレベルの問題の様子（本家Debianカーネルではなくubuntuカーネルでは対応がされているようないないような記述があるんですが…）であるため、インターフェースはUSB3 -> USB2ではあるもののNanoPiで現在作業中です。
時々クラッシュする(黙ってリブートする)ため、熱対策か電源対策か、その辺で何か問題があるのは間違いないのですが、32bit core processorが終息していく中、H3なNanoPiにはもうしばらく頑張っていただければと思う次第です。

LDAPサーバーの引越し準備/ 2019年12月1日

早いものでもう12月。悩み始めてもう5ヶ月も経ってしまいました。
紆余曲折のあったファイルサーバーですが、概ね一週間単位では止らず動いており、懸念があったClamAVも512Mbytesでやりくりできているようでクラッシュしないようなので、いよいよ本格的に長期間…と言う前に、もう一つ、日頃そんなに触ってないが故に問題になるところをやっておく必要がありました。
うちでは複数のLinux端末やら何やらが動いている関係で、誰がどの端末にでもログインできて使えるようにしています、当人達がそうしたいかどうかはさておき。
一時NISでやってたんですが、数年前に、何かが原因(もう忘れた…）でLDAPに移行している関係で、そいつも引っ越さないとなりません。
ということで、NaniPi NEOにopenldapをパッケージインストールして設定して…さて、引越しってどうやったら良いの?と、ググらせていただいた結果としては、単に旧サーバーでslapcatしてそいつを新しいサーバーでslapaddせい、という簡単な解。大体、そんなに日頃っからそんなところ大していじらないわけで、覚えらんねっす、というのが本音です。

というわけで、忘れていた初期設定値など現在のサーバーでslapcatした内容で確認しつつですが、大きな問題がひとつ。

LDAPはでぇたべぇすなわけで、最初に設定したjessieの時には、Berkeley DBがバックエンドのHDBで設定してました。それが最近はMDB推奨ということで、何か変更しないとならなそうです。
slapcatしたもの見ると、所々HDBというキーワードが出てきますが、そいつはMDBと書きなおしてやるだけで良いようで、かつ、MDBでサポートしないキーワードがあるがそれは削除して大丈夫、しかしslapaddしてやると何か文句言ってる。そうかそうか、初期設定した段階でslapd動いてるしデータ握られてんだからいろいろ不都合だよね、ということで、slapdを止めて、管理されてた初期設定データを削除してやります(/etc/ldap/slapd.d以下は削除してしまう）。
改めてslapaddしてやると、configデータはOKですが、ホスト、アカウントなどのデータはまだ文句言われます。いろいろググった結果としては、「重複している設定がある、と言う文句なら"-c"使え、それで大丈夫」、とのこと。
slapdを改めて動かして、slapcatしてみると、ちゃんと引越しできました！

ということで、着々と引越し準備は進んでます。　どうやら最後に残る問題は、NanoPi NEOにはアクリル板でできてるケース未満の上下ガードを付けてあるんですが、ほぼむき出しなわけです。HDDは外付けケースに入ってるとはいえそのまんま置いとくの??ということになりそうな状況です…。

最後に(?) / 2019年12月31日

のんびり？やってきたこの整備、概ね落ち着いたので最後、メイル関連の設定をして完了です。メイルったって、以前はちゃんとISPのMTAとコミュニケーションできるようにしなきゃってやってましたが、今やweb基盤のツールがほとんどなので、セットアップしなくても済んでしまう状況でもあるわけで、昔の名残り、ですね。
今まではDebian defaultなexim4を使ってきてたんですが、そもそもjessieのままで長らく運用してしまった関係で、今のパッケージについていけない状況(笑)で、SMTP AUTHでひとしきり悩むことに。思い切ってpostfixに入れ替えてしまいました。もうほぼいじらない領域の事なので、先人の知恵をそのまま使わせていただくことにして、スマートホストを使用するよう初期設定しSMTP AUTHを追加することで、すんなりセットアップは終了と相成りました。ISPからの取り出しは、fetchmailしてきます。

さぁ、以上でセットアップ関係は終了です。年内に終わらせたかったんですがとうとう間に合わず、年明けにホームディレクトリの引越しをして、サービスインです！

後日譚 / 2020年1月26日

このNanoPiサーバーですが、年明けに実運用始めて見たところ、やはりClamAVが実メモリ不足で、頻繁にクラッシュしていることが観測されてしまいました(再起動するわけではない)。試験時点では間に合ってたようなんですがね…。
それ以外は順調に動いていると思うのですが、しかたがないのでClamAVは停止させました。

ということで、今現在rock64へ再度移動の準備中です。

後日譚その2 / 2020年3月31日

rock64化したサーバーは順調に稼働しています。
ひょんなことからRaspi3Bでubuntu bionic 64bitを試してみておりますが、その際にHDD起動にしてみました。全体に重いことは重いんですが、加えて悪いことにはUSBが飽和してしまうのか、USB audioから流れる音はブツブツ切れてしまいます。

ん〜、これでは…。こいつをサーバーにしなくてよかった…。

思考散漫

　せっかく十連休ということで、いくつかやっておこうと思ったことのリストはあれども、かんっぺきに思考散漫な状態です…。なんか、「ゴールに向かおう！」という気力に欠けてる感じ。しばらく更新してないのは、スタック中、と言うわけです。

そのうち、解消しないとね…。なにせ備忘録なので、書いておいてみる次第。

りすと)
・サウンド環境整理したいな…
　デジタル化した音楽データを再生する環境用意したいんです。これ、ぐぐたす使ってたころにx86でやってるんだけど、{ディスプレイ付けてない|アナログビデオ出力にしてた}し案の定パラレルATAが死んで代役がないし(SDを挿すCFアダプタ使う!?)、ケースにも収めてなかったんで、その辺にむき出して置いておくわけにもいかずで頓挫中。
ARM系のボードは基本的に外にアンプおかないとまともな出力出ないので（ヘッドホンジャックついてる場合でも、その程度のドライブがターゲット）、その昔作った真空管アンプをハムノイズ覚悟で引っ張り出すか、それとも、まだ在庫してる球で新たに作ろうか(トランスどうしよう??)と逡巡してもはや数ヶ月。プラットも、Pi ZeroのPWMを使うか、nanopiのI2S使うかなどもあり…
Pi2とかPi3で、ボード起こしてやってる人もいるものでもあり。

これ、実は他にも大きな問題があって、つまり、スマホに音楽再生させて、そのためにWi-Fi外で「ギガを消費」してる人(家族)がいるんで、それへの対策も意図のうちではあるんです。とりあえずはUSBのDACつないでごまかしてる状態です。いやまぁ、そういう家電、売ってなくはないんですがね…。


・どれかのボード、宅内で自由に移動できる端末にしておきたいな…
　RPiかrock64、どっちもHDMIだけどそういうディスプレイを持ってなく、デスクトップ用には昔ながらのVGAか、せいぜいDVIを使ってるくらいなんで、新しく調達しないとならない…ということで、古ノートPCのLCDに目を付けてるんですが、これがまたね、古ノートだけに…。
PCB00099調達してみたものの、LCDコネクタ形状は汎用じゃなかったし(1.25mmピッチだったが標準より薄いコネクタ使ってる）、一発認識しなかったんで多分ファーム書き変えが必要、それにはx86が必要で、引っ張り出して電源入れてみたらSocket478クーラーを留めているプラ部品が経年で劣化してて、と、別のトラブルにも遭遇してモチベ低下中。ごまかし復旧はさせたもののいつ他の部分が破損するかは判らず、しかし新しくx86買う気はないし。

・カメラ、カメラ、…
　まぁ、半分は仕事なので、自宅で何とかしないとならない類じゃないんですが、キャプチャして画像・オブジェクト認識というのはもう大抵のアプリで使われているので、「ハード屋なんでさわりくらいしか判りません～」てのはもはや通用しません。
そういうわけで、なぜか持ってるカメラモジュールを使うことを考えてるんですが、それはUVCカメラではなくBT.656カメラ。
UVCなら良かったんですが、好き勝手なカメラをつなげられるボードって、実は存在してないんで、どうすっか思案中。BT.656をFPGAで取り込むとかもありえそうですが、そこから先も考えないとなんないんで。

・そろそろファイルサーバーが壊れる時期に入ってきそうな予感…
　結構もう長らくx86は調達してないし、今サーバーやってるのはSocket478なPentium4なので、そろそろヤバい。HDD自体はSATAではあるものの、もう2年近く走らせっぱなしなので、何らかのはずみで止まると復旧しないかも、と、ヒヤヒヤ運用。
これ、Pi3とかrock64に移そうか、と、思っちゃいるんですがね。

さて、まとめてみるとこの4つ、どーやるかな…(いやいや連休中にやってれば、一つくらいできたでしょ)。

Pi3BにArduino LCDつけて(1)

Pi3Bで何やろう?

　無事が確認されたPi3Bですが、既にデスクトップはrock64がやっているので、別のことを割り当てます。死んだままになってるproxyとか、ストレージにたまってる音楽再生機とか、手をつけられてないものを少しずつでも実現したいな。そろそろファイルサーバーも心配…。

ディスプレイ

　デスクトップ的な構成の装置をずらずら用意したくないので、ハンドヘルド的な使い方ができるようにしたいなと思っちゃいるんですが…。まぁ、以上のような使い方だと、電源ケーブルから逃れることまでは考えません。

手元に、既に紹介したArduino用のタッチパネル付き2.8" LCDがあるので、それ使えるように、まず、してみたいと思います。主に表示を目的としているので、よくこういう用途にはキャラクタLCDが使われることが多いかと思いますが、mpdクライアントを動かす事が視野にあるので、行数を稼ぎたく、QVGA LCDです。

このLCDは、以前、BBBにつなげて、BBBのGPIO使う上での勘違いを諭してくれた奴ですが、シングルコアBBBではちょっととろくて、5fps程度しか出ないようなので、活用するにはもう少しパワーがあるSoCが必要かな、ということでお蔵入していたものです。もう一つ同じ奴があるんですが、それはArduino UNO互換機と出番待ちしてます。

タッチパネル付き2.8" LCD

　この、Arduino用のLCDと言う奴は、大抵データが8bitパラレルで、それにLCD制御用の信号が5本必要、すなわち、13本GPIOを使います。それに、Arduinoなので5V電源。
ラズパイに、同じようなLCDをつなぐ事例がありますが、今使いたいLCDは、SPI接続のタッチパネルコントローラが載っているので、ラズパイ側もSPIを使えるように配置しなければなりません。ついでに、IPアドレスが固定じゃないので、シリアルコンソールがあった方が問題対応が容易です。

それを考慮してGPIOを眺めると、なんとぴったり13本。
このLCDには「温度計」も付いていて、LCD背面についてる温度計じゃ装置内温度みるためにしか使えないなとは思っていたんですが、そのためのI2Cを有効にする余裕はなさそうです。
BBBじゃないとこのLCDは活用できないな…。

ラズパイとの接続

　BBBやArduinoをみると、ボード側のコネクタは「メス」なんですよね。一方、ラズパイを起点とする40pin GPIOポートを持っているボードは「オス」になっているわけで、ときにジャンパケーブルに難点があったりします。ということで、外に一枚ユニバ基板入れることにしました。
結果はこんな感じです。

con2fbmapで切り替えられる、ということなんですが、何も起こらないので確認が必要です。
この砂嵐は/dev/urandomから/dev/fb1にランダム値を送り込んだ結果ですので、書き込みはできている、と言うことかと思います。


…、とりあえず、つながった、ということで、今日はここまで。

HDMIを止めるように設定してみてあるんですが(本当に止まってるか、見てないんですが）、そのおかげか?スマホ充電用の比較的容量が小さい電源でも動いています、ときにunder-voltageといわれますが。なんにせよ、ちょっと時代物の6Aの電源でもそう文句いうということは、相当ハイスピードな電源じゃないとイカンよ、と言われているわけで、最終的には新しい電源を調達するんだろうな、とは思っています。

本当に壊れた？ Pi3B

Pi3Bは本当に壊れたのか?

　どうも壊れたようだ、として一旦離脱させたPi 3B。本当に壊れたのか？

むかしFBに写真載せたのだけど、このPi 3Bにはsmrazaというメーカー?の、加工済みアクリル板を9枚積み重ね、間にラズパイを挟み込むタイプのケースを使っています。右はその時の写真。

Pi3Bでは、緑LEDがいわゆるact LED(microSDへのアクセスやネットワークアクセスなどで点灯）で、赤LEDが電源ということになっているようですが、raspbian stretchでは、赤は常に点灯しているわけではありません。
不具合の状態ですが、電源を接続するとまず緑LEDが少しフラッシュした後に赤LEDがフラッシュして緑LEDがフラッシュ後、消灯して再び赤LEDが点灯します。以後この繰り返し。

ブート用のメディアは、元々使っていた32GのmicroSDは既にrock64に流用してしまったのでありません。Pi Zero Wで使っているものを利用します。そちらでは確実にブートするので、破損してはいませんし、32bitプラットホームと64bitプラットホームでバイナリを分けていませんので、カスタムしてない限りどちらでも同じイメージで起動できます。

シリアルコンソールを接続するよう設定していない状況だったので、この間何が起こっていたか確認することはできませんが、明らかに起動には至っていません。（例えて言うならgrubがOSロードしようとすると落ちて再起動しているような雰囲気。あくまでも雰囲気。）

この時点で「壊れたようだ」判断をして、rock64を調達することになるわけですが…

ケースをばらす

rock64が無事に動き出したので、Pi 3Bに戻り、基板状況確認のためケースをばらします。基板には焼けこげなど、何かが起こったような跡はありません。この状態で、5V/1.2Aの電源を接続して起動してみます（ディスプレイてかHDMI使わなければ、この位で十分動くはず）。

特に異常発熱もなく～…！、起動するじゃん????

電源投入時の緑→赤→緑で以後緑LEDがアクセスランプとしてmicroSDアクセスの様子を示しているので、しばらく後、DHCPクライアントIPを探してsshかけてみるとログインできます。
あれー。

改めてケースに組み付けて、同じ電源接続してみると、以前と同じ繰り返しリブートシチュエーションで起動しません。ケースには上の写真のとおりクーリングファンが搭載されていますが、それに電源は入れていないため消費電力観点では変化はないはずです。

再びばらして電源入れると動作します。何じゃそりゃ。

起こっているらしいこと

　ケースに入れたり外したりして様子をみた限りでは、どうやら電源用USBコネクタにかかる機械的負担(応力、ですかね)の違いによる、接触の違いに基づくようです。一旦起動してしまった後では、コネクタぐりぐりしても止まらないんですが（瞬停でも問題ないようにコンデンサ積んでるってのもあり、ラズパイが消費する電力が、接触不良発生と同時に増えたりしない限り、その程度でみつからなくても当然ではあります)、ケースに入れているときは、差し込み状況が起動に影響があるレベル、ということのようです。
スマホのおかげで非常にお手軽になったため、多くのボードでUSB microBを電源端子として使っていますが、やっぱ心配だな…。

と、いうことで、1Gもメモリ積んでるPi 3Bにそのまま遊んでもらうのは惜しいので、遠からず復帰してもらうことにして、ただ電源は、rock64同様40pin側から供給するようなケーブルなどを作ることにします。しかしそれだと、電源逆差しや過電流保護などの回路を通さずに、ボード全体に電源を供給することになるので、当然本当に壊れる(さらに火を吹くことになるかも）可能性が高くなりますんで、お勧めはできないのですけども。
それでやるならダイオードの一本くらい、入れておくことにしましょうね(その分の電圧ドロップには要注意ですが）。

結果として

　結果として、Pi3Bは自体が壊れていたわけではなく、トータルとしてはボードが一枚増えることになるという、喜んでよいのやら、余計な金を使ったと嘆くべきか、な状況となりました。
以前こけたままのwebフィルタ+ウイルスチェッカも、ClamAVがメモリを食う関係で、まだそのまま手当てできてないので、Pi3Bでやってみますかね。

rock64

ラズパイ3B壊れる

　いわゆる「ハズレ」を引いていたのかもしれないけど、一年くらい前に入手しほぼ半年前から連続稼働状況にしていたRaspberry Pi 3 Bには、電源面で色々泣かされました。12V/3A電源からDC/DC通して5V(もちろん3A以上ドライブできる)を供給しているのだけども、どうにもラズパイはHDMIまわりの電源設計が良くないのではないかと思われ…
うちにはTV以外にはHDMI入力可能なモニタが存在しないので、電源付きのHDMI-VGAアダプタを通してVGAモニタに接続しているのだけども、それを接続したままで再起動すると数回に一度しかちゃんと立ち上がらない。つまり、なるべく確実に起動させるためには、リブートしたい事象であっても、止めて、HDMIケーブルを外して、電源再投入する必要がありました。
年末に、「あ”、何かスタックしてる…」と思って、その手順で起動かけたのだけども、事情でそのまま数日放っておくことになってしまっていました。

年末年始休暇に入って、「さて」、と様子を見ると起動していない。「む、ファイルシステム壊れた?」と思い他のイメージを試すがやはり起動しないので、完全に壊れたか？　しかし今それを追求し出すと、年末でもあるのでしばらく端末が無いことになってしまいます（まぁ、結果的にはそうなるんですが)。

残りのボードは BBB、Pi Zero WH、NanoPi NEOなわけで、辛うじてBBB、Pi Zero WHはmicroHDMIもしくはminiHDMI-HDMIアダプタがあれば使えそうではあるけども、デスクトップパフォーマンスはガタ落ち確定になってしまいます。

次のボードは…

　ラズパイには3B+がリリースされていて、それにしようかとも思ったのだけども、上述のとおり電源に不安があります。そもそも、こういうボードを試しているのは、連続稼働できて仕事にも使えるボードを探している面もあるわけで、確かにGPU性能など必要な使い方をそこでするわけではないのだけども、ミソが付いてしまったと言ってよい状態のラズパイを再び試すの?という思いもあります。

候補になり得るのは、高くて手を出し辛い96boards系、他にもNanoPi系、OrangePi系などとありそうではありますが、Wi-Fi搭載となっているケースがかなりあり、かつ、中国にオーダーとなるケースが多いようです。国内販売があって、ことWi-Fi搭載のボードで国内使用に問題ないのはラズパイしかないと言っても良いくらいです（偉大なり…）。この中で、パフォーマンス的、価格的に、Pine64のrock64 が目に止まりました。なんといっても、メモリが2Gまたは4Gをチョイスできるってのええじゃない、サイズもPi3Bと同じようだし、秋月で手に入るって。

と言うわけで、アキバにgo。

rock64

　Pi3Bをそもそもデスクトップで使っている人がどのくらいいるか判りませんが、調べ物のためchromiumでタブをたくさん開くなどすると、メモリ1Gだと結構苦しい局面があって、raspbianデフォルトのswap 100Mでは足らずに拡張しておく必要がありました。じゃぁswapに1G必要かというと、そこまでは必要ない、というのが実感レベルです。rock64では1G/2G/4Gのconfigを選択できるようですが、そういったメモリ事情を踏まえ、この時秋月店頭に並んでいた2G/4Gのうち、2Gを選びました。2GでほぼPi3B+と同価格。
動画再生でSoC結構発熱するとの情報がありましたので、放熱器も調達しておきました。

…、と、ここまでで年越ししてしまい、実際に火入れに至れたのは年明けです。

電源には、Pi3Bに使っていたものと同一のものを試します。OSはarmbian stretchを選択。
Pi3BはUSB microBが電源端子に使われていますが、rock64では馴染みの薄いサイズのプラグが必要で、秋月webにも対応方法が掲載されていたりしますが、なんのことはない40pinコネクタには電源入出力となっているピンがある(2,4pin=+5V)わけで、かつ、ラズパイがデファクト化しているので、のちにラズパイに入れ替えても良いよう、そこから供給してやります。

rock64のほうが、若干、仕様として記載の推奨電源容量が大きいのですが（Pi3B=2.5A vs. rock64=3A)、同じようにHDMI - VGAアダプタの電源を供給しつつもまったく問題なくこちらは立ち上がります。Pi3Bでは、GUI(display manager)が立ち上がったときに稲妻が出る、描画（display managerからdesktopへ切り替える、など）を始めるとクラッシュするのが典型的なシチュエーションでした。

そういうわけで、拍子抜けなほどあっさり立ち上がってしまいました。日本語関係、ldapなどネットワークデータベース関係のセットアップを行って、こうしてrock64でブログを作成しております。

なお、youtube動画を再生してみている過程でSoCに触ったところ、かなり熱いため放熱器を搭載しました。搭載が必要かどうか、はっきりしてなかったんですが、用意しておいて良かった～、です。

かまぼこ？みたいに、板に釘で仮止め中。

Pi3BではHDMIオーディオ使ってたんですが、何かのはずみに音が歪み出して元に戻らなくなります。どうも音圧依存なようで、Pulse Audio volume controlのような、レベルメータ付きボリュームコントロールでみていると、再生中にゲージ右側を指している、右に張り付く時間が長いようなソースでよく発生していました。こうなると、ほぼ再起動しかなかったんですが、rock64ではそのような歪みも起こらず、かなり快適です。メモリ使用量も結構フリーエリアが残っていて、2G品で問題なかったね、と言うところでしょうか。個人的にはなかなか良いお買い物だった、Wi-Fi後付けでよければお勧めかなと思いますが、あとはケースと寿命、か。