右片麻痺のIT好き。左手で生きてます。
朝、水槽の前に置いてあるFitbit Ariaの体重計で体重を測って床に足をついたら、
びちょ
なんか濡れてますけど。
2週間前に同じ事になったエーハイムの2074。もうすぐ使い始めてから2年になるのでエーハイムタイマーだろうか。保証は3年だけど。出勤前の時間がないときなのでさくさくっと洗ってなんとか水を通して応急処置をして普段より15分遅れで出社。朝ごはんも食べられず。
短期間で水のトラブルが続くとちょっと困っちゃうな。センシングして水が漏れたらフィルターの電源をオフにして、ランプ光らせる工作でもしようかな。
とりあえず、Oリングを発注したので届いたら取り替えてみよう。
物理的にストレーナーの口より下の水位で止まりはしますけど。最悪の状態として水槽の水の2/3が出ちゃうと大変です。40リットルくらいかな。いや自分の水槽は60cm水槽だけど高さが40cmくらいあるのでもっとか。クワバラクワバラ。
アノード側の配線がなるべく楽になるようにした回路を作ってテスト。このブレッドボード上では楽になるようにはみせませんけどね。LEDの真下にシフトレジスタのICが入る予定なので。
それに合わせて、フォントデータの変換＆文字のシフトの部分のプログラムを変更しました。
多分力技。もっと良い方法ないだべか。
シフトなんぞこんな感じ。
vram[k][j] = ((vram[k][j] & 0x20) >> 2) + ((vram[k][j] & 0x10) << 1) + ((vram[k][j] & 0x02) << 3) + ((vram[k][j] & 0x01) << 1) + ((vram[k][j] & 0x04) >> 2) + ((vram[k][j] & 0x40) >> 4) + ((vram[k][j] & 0x80) >> 1) + ((vram[k+1][j] & 0x08) << 4);
シフト演算子でローテート出来るか、負数で逆シフトできれば、もう少し綺麗に出来るのだが。こういうシフト・ローテート系はアセンブラで書いたほうが合うし速いんだろうな。
動作確認が出来たので、工作に入りますかね。
ちょうど秋月さんから、切り取り可能なピンソケット(これ重宝してます。)と長めの基板対基板向けのピンヘッダが届いたですよ。
あと、スイッチサイエンスさんでmbed向けのLANコネクタブレイクボードを買った。秋月のパルストランス入りのコネクタは秋月の1.27mmピッチの蛇の目基板だとピンが入るには入るけど、その秋月の1.27mm基板が分厚くて、切り取り加工が大変なので出来合いのスイッチサイエンスさんのキットに走ってしまう。
で、そのついでに、在庫が復活していたArduino Microをついつい買ってしまったすよ。Arduino nanoより2pin分長いんですが、Leonardoと同じ様にATmega32u4のマイコンなのでUSB接続のアイテムを作ることができるのでアイデアが広がります。マウスの替りとかキーボードの替りみたいなのは簡単にできます。ATmega328PなどでもV-USBとか使えばできますけどね。
(下記配線図はてけとーなので概念の参考程度にしてください)
本番機の配線を検討中。2階建てで横方向のシフトレジスタはLEDの真下に配置。1階のマイコンからはSPI 3線でインターフェイス。縦方向のシフトレジスタとシンクドライバは1階に設置して、8本のピンで2階とつなぐ。
で、ちょっと方針変更して試してみる予定。
LEDのアノードとシフトレジスタ間をビットが連番になるように配線するのではなく、なるべく配線が楽になるように。これをソフト側で吸収してみる感じ。
どのみち、立て配列のフォントデータは横に変換する過程が必要だし。それより横スクロールのシフト動作が単純なシフト命令＋右隣のMSBを持ってくるってだけではすまなくなるなぁと。1回のシフトで済んでた前半部分が7回のビット移動になる。
人間の目の反応もあるからそれほど厳しくはないと思うけど、遅いようだったら、シフト前からシフト後に変換する256byteの変換配列使えば大丈夫かなと。フォントデータ自体を転置しても高速化できる。
ちょっとブレッドボードで試してみる予定。
で、上記の投稿画像をアップして気づいた。
シフトレジスタとLED基板のとの配線。右側より左側の方が良いなと。まだ、実物作る前で良かった。自分はなんとなく左端から揃えたがる正確なのかなｗ。実際にはもっと発想の転換の余地もあるのだろうなあ・・・と。
晩御飯食べた後見直してたら間違い発見。
これが正しいアノード接続かな。連番ではない物は落ち着いて考えないとミスしますね。
ブレッドボードでつくったミニ8×8マトリックスLED基板の段重ねPCB基板の設計をしてた。やはりブレッドボードは楽だけど、場所取るので小さくしたいかなと。合間にシフト演算のコードを書き直してたら、ツレがピアノ楽曲を聞き出してちょっと困ったけど。シフト演算みたいなのは得意では無いので出来れば静かな環境で検討したいのだが。
で、設計結果は結局上記画像のような３枚重ねの基板になってしまった。うちには、基板と基板をつなげるほどの長いピンヘッダは在庫が無くなっている。なので秋月に発注しました。
このままミニ基板を作ってもなぁという感じがするので、本基板の配線を考えます。10桁～12桁くらいの予定。美咲フォトのままで。段重ね二段にするので、最初はmbedで楽して、あとでATmega1284化かな、そこまで気力と時間が取れるだろうか？
(カクカクするのはうちの撮影してるスマフォのmicroSDの性能の所為です)
午前でスクロールが出来たので、午後はまずLANに接続。NTPで現在時刻をRTCにセットしたり。
で、プチ問題発生。最近、mbedの新しいライブラリをいじってなかったのであるが、Ethernet周りやそれに付随するプロトコル周りのドライバが新しくなってて、それの把握と対応でちと時間かかった。(mbed2.0のやつなのか？スレッドまで要らないしタイマー割り込みで良いと思ってるのだが。)
とりあえず、NTPとhttpは喋れるようになったので、自鯖の中継PHPを作成。いまのmbedのソフトはSJIS専用だし、今後もUTF8に対応する気はない。UTF8→SJISのコンバート配列かUTF8ベースのフォントデータが有れば違いますが。
google newsを拾ってきてSJIS変換するようにして完了。
mbed側も、保存バッファが1024byteだと妙なので4096byteに拡張。サイズチェックは入れてるので、はみ出したら表示されないだけで、メモリを壊す事はないだろう。ニュースは3回まわったら次を取りに行くようにしてみた。
大体こんなかんじで、あとはニュースサイトを増やしていけば良いかな。天気情報取得の為にWeather Undergroundも登録しました。
次はスイッチによる割り込みでの表示内容変更だ。ニュースとか、時刻表とか、天気とかを優先表示させるとか。でも、この辺りのソフト系は平日でもできるから、それよりハードよりの音声、音楽系を明日やろうと思う。
でも、実際にニュースとかをみてみると・・・。１文字16×16にしたい気がする。今の8x8LEDを4個使えば１文字表すことが出来る計算。行の方向の電力量がキビシーし、財布にも厳しい。8×8で100円のでも、10文字だと4,000円ですよ。無理無理。それよりSBCSを半分幅でDBCSと同時表示できるソフトにするのが先だ。
ともあれ回路も固まってきたし、ソフトの改造と並行して本番のパーツで作りはじめましょうかね？１日２こ程度で。
昨日の予定どおり、バッファ入りのスクロールにしました。
文字列は、起動時にシリアルコンソールから投入できます(但し2byteのSJISのみ。1024byteまで。)。素直にLocalFileSystemのフラッシュメモリにSJISファイルを置いて読み込んだほうが、fgetcしつつEOFになったら巻き戻せば良いので楽だったと思われる。
ベース動作が確認できたので、表示するネタ文章をネットから取ってくる部分を作成します。