LEDマトリックスとMAX7219のパーツ

Fritzingの、LEDマトリックスとMAX7219のパーツデータ
を、サイトにアップしました。

http://nekosan0.bake-neko.net/warehouse_fritzing_parts.html

DIPのMAX7219は、ランド径がノーマル設定のままで、
ちょっと大きいので、ピン間を通すのがちょっと厳しい
かもしれないので、PCBのSVGを差し替えるか、別途
作ったほうがいいかもしれません。





今日は、なんかSolive24のYoutube、いつものチャンネルが
表示されないなぁと思ったら、なんかあったみたいで、
weathernews 2ndってチャンネルが出来てた。

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

久しぶりにポン子登場。





http://radiopench.blog96.fc2.com/blog-entry-811.html

ダイソーの、500円のバッテリー、そういえば見かけた気が
するんだけど、モバブーばかり増えてもと思って、買って
なかったんだよな。結構よさげなものだなぁ。薄いし。






https://twitter.com/tokoya/status/966532405367468038

この生地、いいなぁ。パックマン。





http://www.aitendo.com/product/11968

aitendoに、例のNTSC4.3インチ液晶が出てた。1500円。

http://brown.ap.teacup.com/nekosan0/3326.html






https://twitter.com/hirakawah/status/965963100930195456

そうか。働き方改革＝STAP細胞、ってことか。なんか
すごいしっくりきたぞ。

LEDマトリックスのFritzingパーツ

http://www.sponichi.co.jp/entertainment/news/2018/02/21/kiji/20180221s00041000294000c.html

ゴジラの仕業なのかな？

合掌。





Fritzing用の、LEDマトリックスパーツデータを
作ってみた。20mm角のと、32mm角のを、それぞれ
カソードコモンとアノードコモンの、合計4つ。

ブレッドボード図。



回路図。



PCB図。



ランドは、穴径0.8mm、ランド幅（片側）0.4mmで、
ランド径1.6mmにしておいた。0.3mmならピン間1本
余裕で通る。

とりあえず、SOのMAX7219と組み合わせて、オート
ルートで引いてみて、大きさ的にも線幅的にも
それなりに大丈夫っぽいことを確認しておいた。

32mmのほうは、DIPのMAX7219でも大丈夫みたい
なんだけど、ただ、線が両端に少しはみ出る感じ
なので、DIPだと縦横をみっちり詰めて配置する
のは難しそう。まぁ、SOだな。

あとで、サイトのパーツ一覧のほうにも載せて
おきたい。

（追記：サイトのパーツ一覧にパーツデータアップ
　しました）

http://nekosan0.bake-neko.net/warehouse_fritzing_parts.html



で、パーツできたのはいいんだけど、さて、どう
やってコントロールしようかなと思って、
Arduinoならmatrixライブラリ＋spriteライブラリ
なのかなぁ？
難しいICでもないから、素の制御してもいいんだ
けど、まずはこれらのライブラリに目を通して
みる。

基本的には、8ビット幅×8行の、合計64ビットデータ
（8バイトデータ）の配列を、ビット操作したり、
それをソフト制御のSPI操作で適宜送出してMAX7219に
送り出したりしてる、想像にちかいシンプルなもの
だった。
ただ、基本はドット単位の操作なので、ものによって
かなり遅そう。
（ビットマップイメージをズドンっと表示する関数も
　あるのかな？その辺までは細かく見てなかったん
　だけど、それっぽいメソッドもあるような、ない
　ような）

まぁ、このライブラリ、あるなら使っちゃってもいいし、
いざとなればどっちでもいいし。選択肢として。



で、配線してて思ったんだけど、コモン側（MAX7219の
DIG側の端子）は、それぞれLEDのコモンに繋げばよくて、
順番も明確なんだけど、セグメント側は、MAX7219の
A～GとDPっていうピン名になってるのがちょっと困って
いるところ。

色々検索してみると、DP、A、B、C、D、E、F、Gなのか、
A、B、C、D、E、F、G、DPなのか、ビシッと判る資料
があまりみあたらない。
この順序を間違えちゃうと、

https://www.mgo-tec.com/blog-entry-ada-ledmatrix01.html

（このページで触れられているのは、adafruit製のI2C
コントロールのボードだけど）こういう風に、1行だけ
順番が狂っちゃうことになるはずなんだよな。
多分、adafruitの設計で、そこを間違えているのかと。



色々調べてみて、一番信憑性ありそうなのはやっぱり
データシートで、こういう表がある。



これ見ると、DP、A、B、C、D、E、F、Gが正解みたい。
しかもよく見ると、DPが最上位ビットで、Gが最下位
ビットなの？


日の字型LEDで使う分には、このデータシートの書き方
で十分なんだけど、LEDマトリックスで使う場合だと、
データシートよく読んでみても、やっぱりDP、A、B、C、
D、E、F、G表記と、A、B、C、D、E、F、G、DP表記が
混在してて、どっちがどっちなのか、完全に自信持って
判断しかねるんだよな。

MAX7219の現物があれば、ちょっと動かして試せるん
だけど、注文したの、中国がまだ春節で動きが無い
からなぁ。


まぁ、ある程度わかったところで、特にカソードコモン
を前提に、どういう風に配線すればいいのかを整理して
メモに纏めておきたいな。

特に、複数モジュールを連ねて表示する場合に、その辺
ちゃんと整理しておかないと、作ってみたら反転して
たり、1行だけ反対側にくっついてたり…なんてことに
なっちゃうからな。

そういえば、いっぱい連ねて文章表示したりしてる作例
って、ライブラリはmatrix、spriteを使ってるのかなぁ？
それとも、独自ライブラリなのかなぁ？
1ドット単にで文字をスクロールしてるんだけど、あれ、
1行1行をドット単位でソフトスクロール処理してるのか、
それともアノードコモンで縦横逆に操って、1行単位で
データ送ってるだけなのか…

まぁ、カソードコモンでも、向きを90度変えれば同様に
出来ることは出来るんだけど。




https://twitter.com/tokoya/status/966123287322361856

3Dスキャナ万引きの話、あちこちで会話されてる。

スマホ使って云々だったら、まだカメラの性能とか
あれこれ考えると…って思ってたんだけど、

https://twitter.com/mask_3dcg/status/966134813248733184

こんなの見ちゃうと、すごいよなぁ、と思う。

https://twitter.com/Wu_Niang/status/965624872150822912

いたちごっこになるのかもな。





https://twitter.com/NatGeoMagJP/status/966087597046030336

人と羊のハイブリッド胎児。
科学は悪用されなければ、人の暮らしを安心安全快適
にしてくれるんだけど、これは諸刃の剣だし、神の
領域でもあるし、むずかしいな。

FritzingのLEDマトリックス

昨日の、Javieのフォントで塗りと線でちゃんと機能
しなくなっちゃう件、気になってるので、ダウンロード
してあったソースのアーカイブをちょっと開く。

なんか、インストールの手順メモが書かれたテキスト
ファイルがある。
ちょっと読んでみると、いきなり解らない。けど、
がんばってもうちょっと読んでみる。

最初に出てくる、「FTGL」っていうやつをコンパイル
するんだぞウンヌンってあるので、これはなんだ？
と思ったら、FreeTypeフォントをOpenGL環境で扱う
ライブラリっぽい。

おうっ。まさにこれ絡みなんじゃね？

で、この辺で使ってる機能で、フォントの縁取り機能が
うまく動かなくなってきてるんだろうと。

Javaランタイムのアップデートで、Java内部の機能が
おかしくなってきているのかな？と思ったら、どうやら
CかC++で書かれているライブラリのラップ機能周り（？）
がJavaとうまく繋げられなくなってきている感じなの
かなぁ？

まぁ、いずれにしても、Eclipseだけ用意しても、とても
リコンパイルすらオイラには難しそうなので、また
そっと蓋を閉じる。

いずれ、フォント周りだけじゃなく、ほかにも色々
動かないところが出てくるんだろうなぁ？と危惧。



じゃぁってんで、NIVE2を久々に開いてみたら、なんか
コンポジションの設定周りとか、複数ファイル使って
コンポジション作って、それをさらに階層化して
親コンポジションで纏める、みたいな操作方法を
すっかり忘れてる。

mpegを読む方法自体は、プラグインがあれば読み込みが
出来るみたいな事はわかった。けど、やっぱ編集中に
急に重たくなってしばらく操作が戻ってこないときとか
あるからなぁ。Javieはその辺も軽かった。

バグの多さとかは、どっちも似たような感じなんだけど、
癖がわかれば、なんとか出来るレベルだしな。
やっぱJavieを最新版環境でリコンパイルしてくれるって
だけでうれしいんだけどな。

なにより、オイラ、Java嫌いだからな。技術的な先進性
とかは嫌いじゃないんだけど、肌に合わないんだよな。




https://allabout.co.jp/gm/gc/375416/

こないだ、Aliexで注文したものがなかなか返信かえって
こないなぁ、と思ったら、そうか、春節だったのか。





Fritzingでパーツをちょっと作る。

MAX7219は、ICの汎用パーツから簡単に作れるので、
そっちはさくっと済ます。
面倒なのはやっぱLEDマトリックス。

ブレッドボード図自体は、Inkscapeでそんなに苦労
せず描ける。こんな。



下と右が描いたやつ。とりあえず20×20mmのやつ。
左上はデフォルトで入ってるやつ。60×60mmのやつ。

https://ja.aliexpress.com/item/LED-Dot-Matrix-Display-8x8-1-9mm-Red-Common-Cathode-LED-display-788AS-10pcs/32793498201.html

こんな感じのやつ。一見2.54mmピッチに合ってないけど、
実際はブレッドボードに挿したり、もちろんFritzingでも
このパーツの寸法のままで、ブレッドボードに合う。


ちなみに今使おうかなぁと思ってるのは、この20×20mm
の方なんだけど、あと、32×32mmも使うかもしれないので、
32mmもあとで描いておきたい。
32mm方って、ピン間のピッチは2.54mmなんだけど、縦幅の
方は結構2.54mmピッチからずれてるんだよな。これ、
ブレッドボードに挿さるもののなの？ピン間24mmなんだよな。
脚の長さあるから、実際のブレッドボードには挿さるだ
ろうけど、Fritzingのブレッドボード図は、脚をまげて
挿すみたいのはできないからな。許容範囲内かどうか…
もしくは、ブレッドボード2個並べて使うかだな。


どっちにしても、ブレッドボード図自体は、描くのはそんな
に問題じゃないんだけど、面倒なのは、LEDマトリックスって、
ピンの並びがぐちゃぐちゃっていう点。
なんでLEDマトリックスって、こんなに順番無視したような
並びになってるんだろうねぇ？

その割りに、大きさとかメーカーにかかわらず、どれも
ピンの割り振りの順序は一緒なんだよな。最初にできた
製品がデファクトスタンダードになっているってこと
なのか、それとも、マトリックス形状にするには、
こういう順序のピン配置にするのが一番作りやすいから
なのか？


で、ブレッドボード図のほうは何とでもなるにして、
問題は、回路図用の、ダイオードいっぱいのやつ。
しかも、カソードコモンだけじゃなく、アノードコモン
のも描いておいて、それぞれのサイズで両方作って
おけば、まぁArduino関係ではあれこれ使いまわしが
できるかな、と。
描くのはすごいめんどい。線が多い。

出来上がったら、サイトのパーツ一覧のほうにアップ
しておきたい。





http://www.aitendo.com/product/14080

タクトスイッチのキャップって、何気に便利っぽい
よなぁ。でも、これって深さによって使えるものが
限られるよなぁ。




https://nme-jp.com/news/50466/

ギブソン、経営不振らしい。

https://www.asahi.com/articles/ASL2B6FDZL2BPLZB00B.html?

ギブソンも、これ売ってみたらいいんでは？




http://president.jp/articles/-/24409

この、大前研一氏の
「日本人エンジニアの給料が上がらない理由」
の話。

へぇ、へぇ、と読んでたんだけど、なんで英語が
完璧じゃないとだめって前提なんだろう？
って思ってたら、

https://twitter.com/notactor/status/965641648444030976

うん。そうだよねぇ。ゼロは困るだろうけど、
後からついてくるんじゃね？っておもう。道具
なんだし。





https://twitter.com/yohei_tsushima/status/965743232872099840

うそが明らかになった裁量労働制の話。無理やり詭弁に
詭弁を重ねて、なんとか通してしまおうとしている
みたいだけど…

まぁ、あれだな。まず隗より始めよ、ってやつなんじゃ
ないの？

つまり、散々選挙公約で、
　　「これを実現します。あれも実現します。」
って、
　　「管理すべき目標」
とやらを公言しているわけだから、あとはこの公約を、
政治家自身の裁量で、毎日好きなように働いて、最終的
に実現してくれればいいと。

もちろん、公約を実現できなかったら給料ゼロ。

それで成果がちゃんと上がるなら、民間で適用しても
きっとうまくいくだろう。

Javie、ちょっと怪しくなってきた

Javie、やっぱ使い始めるとすぐに使い方思い出すなぁ。

なんとなく思ったとおりに操作すれば、思ったとおりの
結果になってくる。うん。UIまわりはかなりよく出来て
いるんだよな。

ただ、ときどき、
　「こういう操作すれば、こうなるはずなんじゃないの？」

って時が出てきて困る。大体は、再起動したりすれば
うまいこと動くようになったりするんだけど、そうじゃない
場合も有って困る。

なんつっても、今回ひとつ判明したことがある。テキスト
を平面に貼って、書式とか色々設定しなおそうとすると、
そのあたりの編集機能が効かなくなる。なんでだかが
判らないので、きっと再起動だろうと思って、再起動を
噛ましてみる。だめ。

じゃぁってんで、OS再起動してみる…。だめ。

だからといって、ソフト自体がクラッシュするわけでもなく、
機能しないのはテキスト周りにからんだときだけみたい。


なんじゃこりゃ？と思って、何をしたらそういう風になる
のかを切り分けしてみる。

…どうやら、テキスト貼って「文字の縁取り」（塗りと線）
を使うと、機能がおかしくなるみたいだな。再現するし、
これを止めると機能が元に戻る。

もしかして、以前作ったプロジェクトファイルも、同じ様に
なるの？と思って、古いプロジェクトファイルを開いてみる。

…やっぱり再現する。


どうやら、フォント周りの機能が、Javie以外の要因でうまく
使えなくなっているみたいだな。

最近やったことというと、Windows Updateかなぁ？とか
思ったんだけど、もっと怪しそうなのは、こないだの
JAVAランタイムのアップデートじゃなかろうかと。多分
そっちだな。もしくは、Open-GLがらみ？

https://twitter.com/phelrot/status/295501640159600641
https://ja.osdn.net/projects/javie/forums/22961/37836/78269/

テキストとか、塗りと線では、やっぱり以前から
トラブってるみたいだな。

あぁ、NIVE2重いんだよな。機能的には似てるんだけど、
GPGPUの加速装置がない分、妙に重い処理になったりする
んだよな。

Javieのソース、公開されているものの、コンパイルの
方法もよくわからないし、中身はもっとわからない。
目下、文字の縁取り使わずに編集することにしたんだ
けども、やっぱ背景から浮かして見えるためには
縁取りないと困るもんな。

NIVE2はNIVE2で、NIVE（初代）に比べてテキスト関係
のプラグインが弱めなんだよな。あと、

http://brown.ap.teacup.com/nekosan0/2909.html

NIVE2はフリーズ状態が長いんだよな。処理が重く
なると、なんかもう待ってられない感じになるん
だよな。

http://brown.ap.teacup.com/nekosan0/2349.html

それと、ビデオフォーマットによっては、途中に
黒いフレームがパカパカ入ることがあるんだよな。
.aviでh.264だとそのパターンが多い感じ。h.264が
全部だめってわけじゃなくて、画像サイズがでかい
場合に、黒い画面が入っちゃうんだよな。
（1280×720くらいでアウトだったような）

記憶では.mpegは使えないし、あれこれ試してみて、
入力にmjpeg使えば回避できるけど、そうすると、
映像のソースデータ容量が馬鹿でかくなるんだよな。

最近のNIVE2の仕様押さえてないんだけど、mpegは
使えるようにならないのかなぁ？もしくは、h.264
でバグらないようになってくれないとな。





https://twitter.com/arakencloud/status/965524029099597824
https://twitter.com/okasanman/status/965472536061292544
https://twitter.com/411Army/status/965480788203487232

インドネシアのシナブン山。すっごいな。

http://himawari8.nict.go.jp/ja/himawari8-image.htm

ひまわり8号の映像確かめてみたら、日本時間10:50まで
は確かに何も無いのに、11:00から急に、トバ湖の左上
に煙が出てくる。





ふと気になって、Linux環境のベンチを掛けてみる。
といっても、グラフィック周りウンヌンじゃなくて、
サーバ機能として使ったときの。

UnixBenchで、メインPC上のVirtualBoxに入れたUbuntu16
をベンチ掛けてみると、1コア、768MBメモリの条件で、
総合92.5と出てくる。

Raspberry Pi（初代512MB）で100くらいらしいので、
初代Raspberry Piに少し負けちゃうくらいのスペック
しか出てない。まぁ、裏でWindows7のプログラムを
がんがん動かして…って言う状態だから、多少は
これよりよくなるかもしれないけど、VirtualBoxとか
VMware上でベンチ掛けると、そんなにいい数値は
出てこないみたい。こんなもんか。

あと、Let's Note CF-T9のLinux Mintでも動かして
みた。2コア、3GB、SSDを占有しているOSなので、
こっちは条件いいだろうと予測。
結果：1110.8と出た。やっぱ、ネイティブ環境だと
そこそこいけてる感じだな。実用上問題なさそう。


ネット上で、色々なレンタルサーバとかを見てみる。

http://intothevoid.hatenablog.com/entry/20160417/1460904307
http://naoberry.com/tech/unixbench/
https://qiita.com/TatsuyaYamaguci/items/bc058bd055fe0b229d50
https://junkhack.wordpress.com/2016/02/14/orangepi-one-%E3%81%ABfan-%E3%82%92%E4%BB%98%E3%81%91%E3%81%A6%E5%85%A8%E9%96%8B%E3%83%99%E3%83%B3%E3%83%81%E3%83%9E%E3%83%BC%E3%82%AF/

レンタルサーバも、やっぱ2コアくらいだと、オイラの
古っるいLet's Noteの倍くらい（2コアで2000前後）とか
なので、開発環境として、そんなに悪いもんじゃない
気はする。
というか、このあたりでまともな負荷を捌けるなら、
そこらのレンタルサーバ1コア、2コアでもなんとか
なるくらいって算段は立ちそう。






秋月に、ピッコロボIoT入ってる。

http://akizukidenshi.com/catalog/g/gM-12995/






それにしても、Orange Pi One、安いのに499.1だって。
Raspberry Pi3と同じくらいのスペックだな。値段は
かなり安いのに。
開発環境用にこれを使うっていうのも悪くない気も
している。お手軽に、スクラップアンドビルドでき
つつ、トラブりにくいのって、何がいいんだろうねぇ？




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

PCBWay、よさげなのか。使ってみたい気がする。




https://twitter.com/s_osafune/status/965222757616070656

歳とってからもDIY精神、いいねぇ。





https://mainichi.jp/articles/20180220/k00/00m/040/077000c

＞南相馬中２自殺
＞「複数男子生徒の継続的いじめが主原因」

「これぞ、日本の国技」ってやつに見える。
いじめる側は攻められることなく擁護されて、
まずいことは隠蔽する。

「国技だからしかたないよね」ってことでいいん
だっけ？

久々にJavie

久々に、Javieを起動して、ちょっと映像の編集しよう
と思ったんだけど、時々起動するたびに、だいたい
細かい操作忘れてるんだよな。

フォルダの作り方とか使い道とか、コンポジションの
使い方とか、いろいろ。


ちょこっと映像編集するだけなら、ほかのツールを
使ったほうがらくなんだけど、色々細かいところまで
手が届くのって、これとかNIVE2とかなんだよな。

JavieとかNIVE2とかの、3D機能をとっぱらったような
簡単なツール、ないのかなぁ？とか思っちゃうん
だけど、こういう事いうと、無いものは作るんだろ？
と言われちゃうので言わない。

でも、ちょっとしたビデオ編集機能くらいなら、
pythonで色々ライブラリを弄り回せば、出来なくは
ないのかな。
問題は、GUI画面上に色々配置したギミックを
マウス操作して動かしたり、値を操作したり、
そういう類の機能って、どういう風に書いたら
よいものかがよくわからんのよねぇ…

その辺のことが解るような、チュートリアル本とか
あるといいんだけどな。
なにか、その手のプログラムのソースを一度じっくり
読んでみたらいいのかな。オープンソースのやつ。

短いの、何か無いかな？





https://twitter.com/ATF_RS2/status/964504172576976899

生レバー。これはやばいやつだ。
ぼたん鍋もやばそうだ。





https://twitter.com/Nabe_RMC/status/965204335285100545

へぇ。
今度の子供の科学、読んでみたいなぁ。面白そう。

それにしても、LM386のアンプ回路とか3Dプリンタ
なんてもんまで載ってるのか。

オイラ子供のころ読んだ子科って、トランジスタを
使った回路がいっぱい載ってたけど、多分今読んでも、
あの回路って解読できないと思うんだよな。





昨日の、MAX7219ウンヌンは届くまで待つとして、内部
の処理について色々もやもや考える。

ふと、調べ物してみると、FSKについて色々実験して
みないと、先に進めにくいような気もする。

http://www.interq.or.jp/blue/rhf333/modulation.htm


簡単に済ますなら、

https://www.njr.co.jp/products/semicon/PDF/NJM2211_J.pdf

NJM2211がよさそうなんだけど、ノイズが載ったとき
にどんなエラーになるのかが、いまいちピンときて
ないんだよな。


FSKのデコードって、なにが最適解なんだろうなぁ？
規模とか処理能力とかをあれこれ無尽蔵に使った
としたら。まぁ、さすがに無尽蔵なリソースなんて
ものは無いんだけど（Arduino使おうと思ってる
くらだし）、ノイズとかひずみに強い処理方法を
考えたいんだよな。

ちょっと考えているのは、FFTの中身の一部を応用して
しまうことなんだけどな。

　・入力した信号に適度なバンドパスフィルタ掛ける
　・ADCで適当なサンプルレートで入力
　・サンプルしたデータの振幅を正規化する
　・しかるタイミングで入力波形と想定波形の内積を求める
　・2つの波長のどっちにより近いかを数値化する

みたいな感じで、単なるゼロクロスの回数数えるよりも、
ノイズにも、信号タイミングのずれとか伸び縮みとか
にも、「人の目で波形を眺めて判断する」のと同じくらい
に柔軟に波形を評価できるといいなと思ってるんだけどな。

もんだいは、「しかるタイミング」ってところで、これは
やっぱゼロクロスのタイミングでトリガ引くっていうのが
一番簡単なんだろうなぁ。

あとは、色々やり方は有ると思うんだけど、そのへんは
実際の処理眺めながら、実験しながら考えるかなぁ…