最小限のオレオレライブラリをでっち上げる

MAX7219搭載の、4連LEDマトリックスライブラリ。
Arduino標準で入ってるMatrix/Spriteライブラリを
使ってみたら、昨日のとおり、なんか微妙な感じに
なったので、簡単なオレオレライブラリをでっち上げ
ることにしてみた。

まぁ、かなり単純なSPIなので、shiftOut関数使って
適当にデータ吐き出せばうまくいくだろうという
もくろみ。



まずは4連のうち1個だけ（8×8ドット）を使って表示
してみた。
初期化コード（といっても、ノンデコードにする
とか、画面消すとか、輝度調整するとか）をざっと
書いてみて、適当にデータを吐き出してみたら、
大体思ったような表示するみたい


ただ、x、y座標指定でドットを打つ処理を組んでみると、
なんだか昨日のMatrix/Spriteライブラリと違って、
1行目と、2～8行目が入れ替わったような表示には
ならない。どうやら、もっと素直な配線になっている
みたいだ。

あれか…。adafruitが初期にMAX7219とか使って作った
モジュール類が、A～GとDPの端子を入れ替えて作って
しまったせいなのか、わざわざライブラリ内でそれを
補正する処理してるから、逆に、素直な配線使ってる
モジュールだと、Matrix/Spriteライブラリだと、
おかしな順序で表示されちゃうんだな。




それが判ったところで、あらためて4連に拡張していく。


MAX7219を横にズラズラ並べていく場合、単純なシフト
レジスタとして扱える。
なので、根っこの処理は変える必要ないんだけど、
複数のモジュールをまたがるような信号を、どの
ようなフォーマットで吐き出せばいいのかがよく
わかってなかったせいで、とりあえず動かしてみた
ところ、思ったところに思ったように表示されない。

https://www.youtube.com/watch?v=SMH45vnRbjI

このムービーを見て、あぁ、そうか、と理解する。
LOAD端子（CS端子）をLowに落としてから、一気に
横1行32ドット分（4モジュール分）を吐き出してから、
LOAD端子をHIGHに戻す、というわけか。

この、HIGHに戻るタイミングで、各モジュールは
自分宛に届いていたデータを、フルーツバスケット
よろしく受け取って処理するというわけなのね。へぇ。
で、その位置調整用にno-opを使うと…。

というわけで、これらを踏まえて、x、y座標指定で
ドットを描いたり消したりする機能と、8×8ドット
単位のビットマップを貼り付ける処理を組んでみて、
適当に描画してみたのがこれ。



ドットで画面を埋めていく処理→ドットを消していく
処理→三角形のビットイメージを貼り付ける処理、
という繰り返し。
モーションgifはサイズ馬鹿でかくなるので、すごく
縮小したり、映像の一部分だけ切り出した版。まぁ、
処理内容は想像つくかと。


ドットは、20ミリ秒ごとに1個、ビットマップは250
ミリ秒ごとに描いたり消したり。
三角形のビットマップは、上下左右の方向がわかる
ためのテスト図形。タイミングウェイトを置いてる
ので、描画しているのが見えてるけど、実際はもっと
速い。

とりあえず動作確認用なので、shiftOut関数やdigital
Write処理を使いまくってて、SPI本来の速度ではない
と思うんだけど、この程度のデータ量なので、ぜんぜん
速度不足という感じは無さそう。
まぁ、直接ポートを叩けば、いくらでも高速化はできる。


で、やってみて見えたあたりを少し纏めておく。まず、
座標系。



左上が(0,0)の、第4象限と考えてよい。これだ。
使いやすい。


それから、表示したいデータと、ビットシフトの処理
のイメージ。



こんな具合で、コネクタがついている側のモジュール
（この場合右側）を入り口にして、4つのモジュールを
串刺しにした形で、シフトレジスタでデータを流し
込んでいくんだけど、データは、横1行32ドットの場合、
各モジュール宛に「コマンド」＋「データ」の計2バイト
が1セットになっているので、1行では合計で、64ビット
データの塊となる。

その際、一旦LOAD端子をLowにしてから、この64ビット
をごっそり流し込んで、LOADをHighに戻すと、4つの
各モジュールが受け取って、よしなに処理してくれる。

このビットイメージのうち、no-opっていうコマンドに
ついて解ってなかったので、最初ぐちゃぐちゃの表示に
なっちゃったんだけど、その辺をもう少し詳しくする。



例えば、上から3番目の行の、左から2番目のモジュール
に「01010101」っていうビットパターンを書き込みたい
という場合、のこりの3つのモジュールの表示には影響
を及ぼしたくないわけ。そういうことを踏まえて、
残りの3つはno-opっていうコード（16個の0）を使えば
よいということみたい。最初、そこがよくわかって
なくて、表示がぐちゃぐちゃになった。

言い換えると、どこか１箇所に表示するデータを書き込む
場合も、no-opも含めて横1行全部のデータ量を転送する
必要があるので、処理効率的には正直よくない。

特に、4モジュールといわず、横にもっとたくさんデイジー
チェーン接続していくと、その分だけ大量のデータ
（特にno-op）を付随して流す必要があって、少し非効率。
8×8ドットのビットマップを特定のモジュールに表示
したい場合でも、実質的には全画面書き換えるのと同量
のデータを流し込んでいるわけ。
（データの3/4はno－opとなって、無駄になる）

まぁ、横に長いシフトレジスタ構造なわけだし、それを
大量に繋いでも、常に配線3本で済ますっていう意味
では仕方ないのかもしれない。


ちなみに、初期化で使う輝度調整とか、「日の字型」LED
へのデコード有無とかも、同じように「コマンド」＋
「データ」の16ビットデータを、モジュール数分だけ
繋いだデータとして渡すっていう点ではまったく一緒。
データシートの、この表を眺めればすぐにわかるかと。



ちなみに、「コマンド」にDigit0～Digit7を指定する
場合にビットイメージの書き込み処理になって、それ
以外の場合はそれなりのコマンドとして機能するという
具合。

（4線SPIのLCDモジュールとかだと、データ/コマンドを
　制御線1つ割り当てて制御したりするけど、これは
　そういうの無くて、データ内にコマンド情報を含めて
　送っているわけ）

ちなみに、0x00だと「no-op」、0x0Aだと輝度といった
具合。なお、各コマンドともビット15～12は、設定して
も無視されるので、基本はゼロで埋めておけばいい。

あと、Digit番号は0～7だけど、コマンドは0x1～0x8
といった具合に、1個ずれてるのも要注意。0はno-op
で使われている。


初期化処理は、横4つそろえて行うものだろうと思う
ので、この場合はno-op使わずに、同じコマンドデータ
を4個連ねて送ればいい。




とりあえず、オレオレライブラリをさくっと書いてみて、
使い方とか、構造とかは解った。LEDマトリックス自体
は、部品名に「1088AS」って書いてあるから、多分
カソードコモン。
配線順も素直だし、LEDマトリックスもカソードコモン
だし、すごい素直なつくりをしていることが判った。
これはなかなか。配線追わなくても、これなら中身が
透けて見える。
扱いやすいモジュールで、やっぱこれいいな。max7219。


（追記）
http://brown.ap.teacup.com/nekosan0/3508.html

テスト用スケッチをzipファイルでアップしました。





https://twitter.com/aroerina2/status/970540768321417216

帯広。





https://twitter.com/tamagosan32768/status/963123249759469568

大きい555は、なんかロマンがあるんだよな。前から。





https://twitter.com/qx5k_iskw/status/970412886941028352

micro:bitは、RADIO機能が「発明」って言ってもいい
ほど使いやすいんだよな。2個あると、それだけで
すごい遊べる。
もともとは子供の学習用とかを意識してそういう風に
作ったんだろうけど、これ、ほんと色々使えてすごい
よく出来てると思う。2個あれば、あっという間に
ラジコンとか作れる。




https://twitter.com/degochi/status/970469061837537280
http://nomolk.hatenablog.com/entry/2017/07/05/223000

ヒートベッドにしても、エクストルーダーにしても、
熱を出すものだから、ちゃんと組み立てないと怖い
ってことなんだな。そりゃそうだな。気をつける
必要あるねぇ。いつか買ったときのために。





https://twitter.com/sampleaccount0/status/969697056750108672

ねぇ。




https://twitter.com/kinzok/status/970039437596942336

モンテネグロ。





https://twitter.com/felis_silv/status/970886675965464576

ダライアスだな。