Darkside（https対応しました）

　ＳＰＩが使えるかどうか確認するために、まずループバックテストしてみる。１９番ピンと２１番ピンを短絡させて準備。

 だが、テストプログラムを動かすとエラーが続出。一部は、python2 ではなくpython3 をデフォルトにしたのが影響しているようだ。だが、それだけではない。何とかエラーを殺したところ、import spidev が失敗した。あ、入れてなかったのか。
　py-spidev をインストールし、再び実行。すると今度は、spi.open() が失敗した。ＵＳＢカメラの接続試験で cam.read() が失敗したときと同種の、嫌な汗が流れる。

　もしやと思って ls /dev/ したら、どこにもSPIが無い。SPIがデバイスとして存在していないので、そりゃあ spi.open できる訳がない。
　慌てて Jetson-IO を実行すると、ＳＰIはしっかり有効になっている。

　念のため、ＳＰＩが有効になっているかどうかを以前の方法でも調べる。

　すると、やはり有効になっていることが確認できた。

　となると、明らかにＳＰＩは有効になっているのに、なぜ /dev/spi が存在しないのか？という問題になる。
　ここで、Jetson-IO が登場する以前にＳＰＩを有効化するため参考にしたサイトを、改めて覗いてみる。すると、ＳＰＩが有効になったことを確認後、ＳＰＩ用のカーネルモジュールが存在するかどうか確認している。同じように modinfo spidev を実行すると、存在することが確認できた。その次に、デバイスツリーの再構築だ。

　このデバイスツリーの再構築は Jetson Nano 単独では実行できず、リナックスが入っている母艦ＰＣを別に用意しなくてはならない。たかがＳＰＩを有効にするだけのために酷過ぎるということで、Jetson-IO が登場したと思っていた。
　だが下手すると、ＳＰＩを有効にすることが Jetson-IO だけで可能でも、/dev/spi を有効にするにはデバイスツリーの再構築が相変わらず必要だったりして・・・それじゃ意味ね〜よ！

　先日マルチブート環境を作って ubuntu 母艦ＰＣがいつでも使えるようになっているので、面倒だがデバイスツリーの再構築を実行してみる。既にＳＰＩは有効になっているのに大丈夫か不安だったが、結果は膨大な警告を出した挙げ句に終了。
　ls /dev/ してもＳＰＩは出現していないので、失敗したと断ぜざるを得ない。

　Jetson Nano の環境設定では壮絶な死闘を強いられて来たので、もう嫌だ。ＳＰＩは使用せず、パラレル３ビット送信で済ませることにする。