右片麻痺のIT好き。左手で生きてます。
Adafruitの製品は日本にも入っては来てますが、今回気になったイカの製品は国内販売店では見つからなかったので直買い付け。
ブツは「Adafruit RGB Matrix HAT + RTC for Raspberry Pi – Mini Kit」。
Adafruitはニューヨークなので送料がこの商品と同額かかるのが難点。中国メーカーだと不思議な安い送料で届くのだけどｗ。
国内Amazonだとこの商品をAdafruitsから買う時の商品代金＋送料の２倍で売ってる業者があって、納期は１〜３週間。これは単なる輸入代行ではないかな。
UPS配送にしたのでFEDEXみたいな日本までは早く届くけど国内配達がダメダメでいつまでたっても受け取れないということは無いとは思う。
危機ってか、もうやっちゃった系ですけどね。
5V 3AのACアダプタが届いたので繋げてたのですが、何回か差し換えるうちにGNDとVCCを逆に刺してたりして。
74HC138か74HC595が逝ったかも。一番左のモジュールしか表示しなくなってしまった。aitendoのモジュールって回路的には直結過ぎて、ノイズ対策のコンデンサなんて1つもなかったしなぁ。
595は以前にレールで買ったのでたくさん手持ち在庫があるのだけども、138なんて要らないから持ってないし。
ここでマトリックス系LED表示器の開発をやめたら2年前と同じなので、配線の工数をお金で片付けるべく、AdafruitのRGB LED マトリックスを2つ発注。3つ欲しいのだが、2つで安定動作してから。
こいつはRGBなので天気予報情報表示とかで傘マークをBlue。太陽マークをRedとかできますね。とりあえず朝起きてきたら今日の天気予報を表示できるようにしたい。
C/C++用の美咲フォントのconst配列定義のヘッダファイル。mbed系で拾ったものを持っている。
けれども、これGLCD向けなので8バイトのフォントデータが縦8ドットで1バイトそれが8個で1文字分になっている。
横長のシフトレジスタを使ったLEDマトリックスで表示させるとなると横8ドットで1バイトで、上から下へ8個で一文字のほうが使いやすい。
以前マトリックスLEDの掲示板プロトタイプを作った時は、せいぜい8×40ドット位だったので、この縦データを使用して、表示する際に変換かけてても間に合ってはいた。
今回16×80なので4倍のLED量ってか文字量。スクロール表示を考慮するとその時間も増える。
なので、縦になってるconst配列定義のヘッダファイルから横変換したヘッダファイルを作成しようとしている。
さらにi2c EEPROMに横状態のデータで焼いてしまおうかと。そうすれば、LPC1114の様な小型mbedでも漢字第一水準＆第二水準の表示に対応できるし。
プラバンが届いたので、連結基板がバラバラにならなよいように枠組みをした。上にスモークのアクリルとかつければ良さそう。
さすがに80×16だと電源が厳しい模様。なーんか不可思議な表示になったりします。
昨日mbedだと３行目が出ずに４行目になってた件。単に行選択のswitch文のcase３行目の最後にbreak;書き忘れてて4行目の処理が動いてただけでした。まぁ、なんというかｗ。
というわけで、5V 3AのACアダプタを発注。
aitendoの8×8マトリックスLED4個載せ基板を5連結して80×16になりました。
そしてマイコンはArduin系からmbed系に変更。とりあえずLPC1114で、
mbed単独でやるかRaspberryPiをかますかは未定。でも、ネットから文字列を持ってきて加工してとかだとPi使ったほうが簡単だよね。
無事に届いてます、ESR-ES1。
まだ、動作確認はできてません。W5500なのでMACアドレスは入ってるのかな？
よくよく見たらWIZ820ioとピンコンパチなので、動作確認してみた。載せ替えてコード焼いたらDHCPでアドレスとれた。
けど、eth.init(MAC_Addr)で設定してみても、eth.getMACAddress()で帰ってくるMACアドレスが00:00:00:00:00:00。要調査だな。ライブラリのコードの中に結構 不思議な#ifdefがあってコードの統制が取れてないように見える。パケットアナライズしてみるのが吉か。
でも、無駄にはならないモジュールではあった、良かった。Wiz820ioの方は環境を選ぶので、こっちがもっと出回ってくれるといいなぁ。