引き続き5110液晶

ドットを描く処理をインプリメントしたので、これを
元にして、line文も作ってみた。




以前、MADさんのサイト経由で、
http://brown.ap.teacup.com/nekosan0/1940.html
DDAによるline描画処理について知ったんだけど、
昔PC-8801用に組んだline描画処理と同じ、傾きを
計算して積み上げるという処理にしてみた。

PC-8801では、640×200ドットを処理するのに、
小数桁は1バイト（8ビット）では足りなくて、
2バイト持った記憶があるんだけど、NOKIA5110液晶
は84×48と画面が小さいので、1バイトで足りる
と判断。



いざ、ロジックを組んで動かしてみても、どうやら
誤差で描画がズレるようなことはなかった。
ヨシヨシ。

問題は、ArduinoのdigitalWrite処理の遅さかな。
座標を乱数にして、300本の線を描画してみると、
およそ8秒。1本あたり、約27ミリ秒。

長さはマチマチだけど、縁取りの枠をlineで描くと、
描き終わるまでに一瞬の間があるのがわかるレベル。

うーーーーん、もうちっと速く描いてくれないかなぁ。



http://blog.galileo-7.com/?eid=86932
どうやら、digitalWriteの処理は44クロック掛かる
らしいので、これを直接ポート制御することで
高速化がはかれるだろうと思うんだけどな。

http://playground.arduino.cc/Code/PCD8544

LCDへのデータ送信処理は、参考にしたArduinoサイト
のplaygroundのスケッチで記述されているLcdWrite
関数をそのまま使っているんだけど、各信号の
上げ下げには当然digitalWriteを使ってる。

さらに、この関数で使ってるshiftOut関数も、SPI
モジュールじゃなく、ソフトウェアインプリメントで、
内部コードを見ると、データ線、クロック線ともに
digitalWriteで上げ下げしてる。

ってことは、このあたりをすべて改造したら、
結構な削減に繋がるのかな？概算はできそうだな。

まぁ、機能としてはそれなりにできてるから、速度
についてはまた後で考えようかな。先に、オシロっぽい
動きが出来ることを優先しよう。




急ぎ働き。
5110液晶がまだ在庫あるうちに補充しようと思って、
aitendoに。
http://www.aitendo.com/product/1164

在庫が結構あるっぽかったから、と思ってたん
だけど、店員さんに聞いてみたら、このキットは
どうやら店頭在庫なかたみたい。

しかたなく、
http://www.aitendo.com/product/1165
http://www.aitendo.com/product/1156
液晶モジュールとキャリー基板別々のをセットにして
買ってきた。100円高い。

100円はいいとして、基板との配線に使うゴム
みたいなやつの使い方とかが良くわかんない
から、予め取り付けてあるやつがよかったんだ
けどな。

んで、調べてみた。

http://crystal-radio.blogzine.jp/blog/2012/06/5110lcd5110av-3.html

どうやら、導体と絶縁体（ゴム？）が層状になって
いるようで、適当にそれっぽい位置にあてがえば、
それなりに配線されるっぽいなぁ。


それと、350円で3.3Vや5Vへの昇圧基板（小さくて
細い基板）のキットが売ってたので、3.3Vのを
買ってきた。



昇圧用のIC、3本足なんだけど、型番が読めない。
多分HT7733Aかなんかだろうと想像。帰って来て
から開いてみてみると、正解。

http://www.aitendo.com/product/6851
これか。

コイルがアキシャルタイプのちっちゃいヤツだから、
これだと電流は殆ど取れないだろうと思うので、
インダクタだけはもうちょっと大型のに変えておいた
方がいいかな。



ふと、あきばおーに行ったら、USB電源が売ってる
んじゃないかなぁと思って、立ち寄ってみる。



ビンゴ！

売ってたよ。売ってた。狙い通りの品が。

単3電池2本で、昇圧かけて、スイッチでオン／オフ
出来るパッケージ。まさに狙い通り。シメタ！


んで、買って帰って来て、電池を入れて動かしてみる。

…とりあえず、期待通りの5Vがでてきた。

でも、大きさとか考えると、どう見ても表示されて
いる「5V500mA出力」は無理っぽい。
っつーか、無理ゲーだろ。

んで、例によって、色々な抵抗負荷掛けて、実験を
してみた。

実験の結果はまた明日にでも。

それにしても、LED付いてるっていうのは、いざと
言うときに向けて、意外と便利かもしれないな。

いまさら5110液晶

いまさらだけど、PCD8544搭載の、NOKIA 5110液晶。
以前は3.3V版のArduinoが無くて、ほったらかしに
してあったんだけど、ふと、改めて使ってみたく
なったので、繋いでみる。


http://playground.arduino.cc/Code/PCD8544
サンプルスケッチはplaygroundにあるので、これを
元にして、文字表示＋ドット絵が描けるライブラリ
に改造しようという魂胆。


この液晶コントローラは、フォントはもちろん入って
ないのと、さらにはVRAMからの読み出しも対応して
いないので、このあたりを含めてArduino側で行う
必要がある。で、VRAMをSRAM上に確保。504バイト。


んで、文字表示はそのまま文字表示のロジックを
活かしつつ、VRAMにも転写するようにしておいて、
ドット絵を描くときに、それと重ねて表示するって
いう方式に。

とりあえず、pset、preset、xor出力が出来るような
関数を書いてみた。


配線の様子。

これでいいのかな？とりあえずは表示できてるけど。


んで、psetをforループから呼び出す形で斜め線を
描いてみたのがこれ。




グラフィックは、84×48ドット内で位置を指定して
表示するんだけど、それ以外の範囲の値を関数に
指定しても、そのまま無視して処理しちゃうとか、
あまりスマートな処理ではないので、これでいいのか
どうなのかは微妙。

まぁ、描画させてみて、それほど処理時間を食ってない
感じだったので、線引き処理もこれを使えばいいかな。
（ArduinoのデジタルI/Oは遅いから、どんなもん
かなぁと思ってたんだけど）


とりあえず、もう少しスケッチを綺麗に整理してから、
アップしたいと思います。




んで、コイツを使って、簡易的なスタンドアローン
オシロでも作りたいなぁというのが、いまさら5110
を持ち出した理由。

http://filear.com/?p=211
既に似たようなものがあるので、いまさら感はあるん
だけど、スケッチを眺めると、サンプリング速度は
タイマ管理でキチンとされていないっぽい感じがする
ので、タイマ割り込み使ってそれなりに正確な
タイミングでサンプリングしたいところ。




できれば、やっぱFFTも載せたいだけど、FFTで使う
メモリ以外にも、VRAMその他色々なところで食う
ので、どこまで載せられるのか…

せいぜい、32点FFTか、できても64点FFTまでだろうな。


一番の問題は、ADCのサンプリングレートだな。
3.3Vだと8Mhz動作だし、元々フルスペックで
サンプルしても、最大精度でサンプルすると遅い
から、精度は犠牲にしないといけないだろうな。


それにしても、Arduinoは色んな資源を利用できて、
モノをさくっと作れるのがいいな。やっぱ。

引き続きPythonでGTK

引き続き、PythonとGTKを使って、GUI画面を動かす
実験。


Ubuntu環境で、色々と実験してみて、一通り思った
ような動作をさせることが出来たので、続いて、
Windows環境でも同じスクリプトで同じ動作をさせる
ことが出来るのか、動かして確認してみる。


そういえば、VMwareのUbuntuに、VMware toolsは
入れてなかったみたいなので、インストールして、
各種実験用ファイルをWindows側に持ってこようと
画策。

…なんかエラーが出ちゃって駄目。
調べてみると、フロッピーイメージがどうのこうので、
それを外してからどうのこうのという情報が出てきた
んだけど、アレコレやってもうまくインストールが
できなかったので、とりあえず別の方法で済ました。


んで、Windows環境で実行してみる。

…あっさり動いた。サクッと動いた。画面設計のデータ
も、Ubuntu側のgladeで作ったxmlファイルそのまま
なんだけど、ちゃんとWindowsでも動いてなにより。



ただ、エクスプローラからダブルクリックで実行すると、
裏でコンソール画面が表示されちゃうんだなぁ。

んで、その辺について調べてみると、
http://stackoverflow.com/questions/9705982/pythonw-exe-or-python-exe
python.exeじゃなく、pythonw.exeで実行すれば表示
されなくて、そのためには、スクリプトファイルの
拡張子をpywってしておけばいいみたい。

拡張子を、pywって名前にしてコピーを作成→実行
してみると、確かにコンソール画面が表示されずに
実行できた。

ただ、
http://d.hatena.ne.jp/jkani4/20080122/1201003104
バッファサイズ（？）に制限があるみたいなので注意
が必要みたい。



さて、windows環境では動いたので、調子に乗って
Raspberry Piでも動かしてみる。

Raspberry Piには、Python2とPython3の環境は入って
いるので、とりあえずは、Python2を使いつつ、まだ
インストールしてなかったGTK2をインストール。

関連ファイル一式は、さっきwindowsで使ったものを
そのままsambaで取り込んで、VNC Server画面上で
実行してみる。

…動いた。普通に動いた。




しめしめ。



一通り思い通りに動いたので、一度リファレンスを
しっかり目を通して、細かいところを理解したい
ところ。
あと、シリアル周りについても組み合わせて動かして
見たいところ。




simさんのツイッターから、
https://twitter.com/Sim0000/status/456657136991207424
Kinetisマイクロコントローラ統合開発環境 (IDE)。
http://www.freescale.com/ja/webapp/sps/site/overview.jsp?code=KINETIS_IDES

コード制限なしで、libcは「newlib」を使うみたい。
うん。ナカナカイイカンジだな。



http://response.jp/article/2014/03/13/219069.html
JAXA、D-SEND#2飛行試験の失敗の原因を究明、だって。
へぇ。
これで、次はうまく行くといいねぇ。



http://blog.livedoor.jp/kaigainoomaera/archives/36713216.html
BABYMETAL。なんじゃ、このメタルは！
2曲目の「メギツネ」っていうのがイイカンジだな。
まぁ、デスメタじゃぁないな。

引き続きPythonとgladeでgtk

引き続き、PythonでGUIを弄る。


GUI画面でボタンクリックしたシグナルを受けて、
Python側で処理を行うという流れを試す。

最初、ナニをどうやっても、なぜかシグナルが
受け流されちゃって、GUI側の設定が悪いのか、
プログラム側が悪いのか判んなかったんだけど、
どうやらプログラム側でシグナルを受けた後の
設定が悪かったことがわかった。

直して実行してみると、うまいこと動いてくれて
なにより。思ったとおりの処理してくれる。


http://guitoka.blogspot.jp/2011/12/gladegtkbuildergtk3.html
c言語だと、gladeで生成したxmlとgtkが連動する
ための設定周りが結構大変なんだなぁ。

ちなみに、このc言語のプログラムも入力して、
コンパイル掛けてみると、なぜかpathが見つからず、
コンパイルに失敗しちゃう。

http://stackoverflow.com/questions/1041059/header-files-in-subdirectories-e-g-gtk-gtk-h-vs-gtk-2-0-gtk-gtk-h

どうやら、gtkを再インストールしないと駄目っぽい
なぁ。なんかへんなことしちゃったのかなぁ？

まぁ、Pythonで使う分には困らないから、とりあえず
放置でいいや。



https://www.youtube.com/watch?v=SGcHNMFQxFM
なんと、こんなモノでコーヒー豆の焙煎ができるのか。
意外だった。ポップコーンメーカーとかならわかる
んだけど。

火力と温度調整がうまく行くなら、確かにこれでも
いけるかもしれない。
ただ、チャフが大量に出る豆の場合はどうなるん
だろうなぁ？

オイラは、グァテマラを少し深めに煎るのが好き
なんだけど、結構チャフが出るんだよな。

香ばしさよりも、焦げ臭さが出ちゃいそうな気がする。




http://nlab.itmedia.co.jp/nl/articles/1404/07/news118.html

例の、技術者にしわ寄せが来る…のお話。技術者の
端くれとして、実現方法を意地になって考えてみた。



まず、赤以外のインクで赤い線を描く方法。

簡単。何色でもいいけど、まずは線を書いて、それを
ものすごいスピードですっ飛ばす。すると、何色で
描いてもいいけど、いずれもドップラー効果によって、
赤方偏移で赤い線になる。バッチリ！

ただし、宇宙開発レベルかそれ以上の莫大な予算要。

　　　→すんごい金額を見積書に計上。

7本の直線を、お互いすべて直角にする方法。これも
FFTの計算方法を思い浮かべれば簡単。7次元以上の
空間を用意して、それぞれの直線が直角になるように
直線を描く。バッチリ！

異次元空間は納品物に含まれてないので、数式で納品
とする。7次元空間で展開してね、とメモを添えて。

　　　→数式を練って紙に書く費用を計上。

線で猫を描く方法。オイラの関係筋であるベムラーゼ
首相にお願いして、ブラックホール砲をぶっ放して
もらって、空間をゆがめてもらう。これにより、
直線は、重力に沿って曲がりながら進んでいくこと
が可能。これを使って子猫を描く。バッチリ！

当然、ヤマトの開発と、それを運営するだけの人員
が必要なのは当然として、ガミラス帝国と白色彗星
に勝つだけの戦争費用も必要。

　　　→すべて計上。

風船を子猫の形に膨らませる方法。これはさすがに
なんとでもなるだろう。ついでのおまけ。


というわけで、地球上の国家予算をはるかに上回る
費用が必要になるだろうけど、できないことは無い
はずだ。

まぁ、予算の話については、真田さんと相談すれば、
もっとディスカウントできるかもしれない。あと
180年くらい経ったら相談だな。

間違えてた

月食、東京でも見れたらしいんだけど、やっぱ、
昇ってきてすぐに終わっちゃうとねぇ…。

次回を調べてみる。
http://www.nao.ac.jp/astro/sky/2014/lunar-eclipse.html

10月8日だねぇ。かなりいい条件で見れるみたい。
皆既の時間が約1時間と、結構長め。良いな。
なんとかしたいところ。準備と調整だな。あと、
天気か。



昨日の、PythonとGTKをGladeで画面設計して動かす
っていう実験。なんでエラーになったかわかった。

プログラムのミスでも、生成したxmlファイルの
間違えでもなかった。
まさか、Ubuntuのコマンドラインで動かすスクリプト
なのに、shebang付け忘れてたとか、恥ずかしくて
人に言えない。Pythonのエラーメッセージって、
不親切で意味わかんねーよとか言ってたのも
恥ずかしくていえない。内緒内緒だ。

ここのところ、Windwos環境のIDLEばかり使ってた
からなぁ。



というわけで、shebangをつけて実行したら、
ひとまず動いた。何の問題もなく、GUI画面が
表示されてヨシヨシ。

ちなみに、UbuntuでGladeをインストールしようと
おもって、ソフトウェアセンターで検索かける
と、三角定規のアイコンが「黄色」のと「黄緑」と、
2つ表示されて、片方がGTK+2版、もう片方が
GTK+3版で、それぞれ黄色と黄緑が相等するみたい。


んで、GTK+2とGTK+3の各バージョンへの対応が
気になるところ。

http://d.hatena.ne.jp/saket/20120514/1336997531
ここを見るに、どうやらPyGTKはGTK+2までの
サポートになってて、GTK3はやっぱり対応外
になっちゃうので、GObject（Python-GI）を
使う必要があるみたい。

とりあえず、GTK+2で動かしてみることを優先
することにしてみる。
すると、自然とGladeのバージョンは「黄色」の
方をチョイスすることになる。

ちなみに、黄緑の方で出力したXMLを読み込ませて
見ると、見事エラーになっちゃう。要注意。
とりあえず、GUI画面が無事出てきたところで、
また今度。




クロスプラットホームのGUI開発環境といえば、
http://ja.wikipedia.org/wiki/Lazarus

Pascal系のLazarusっていうのがあるんだなぁ。へぇ。

Windows、MAC、Linuxで動いて、開発環境はGPL
だけど、生成した実行ファイルに取り込まれる
ライブラリはLGPLらしい。

GTKやQtもつかえるっぽい。ただ、文字コードも
そうだけど、モロモロ動作安定性とかの熟成が
気になるところだな。まぁ、楽しみ。




そういえば、GTKにしても、Lazarusにしても…と、
ライセンス関係が気になって、AVR用のtoolchain
関係について改めて調べなおす。

http://www.nongnu.org/avr-libc/

ずいぶん昔に調べたときに、コンパイラがgccって
ことで、そしたらlibcもGPLかLGPL（スタティック
リンクだからどっちでも大体同じ）なんだろうと
思っていたんだけど、違ってた。

avr-Libcは、修正BSDライセンスなんだな。



さらにmbed～ARMについて調べてみる。
http://www41050u.sakura.ne.jp/blog/index.php?/archives/5-LinuxSTM32F4-VM-advent-calendar-2012.html

summon-arm-toolchainっていうのを使うと、Linux上
で、STM Cortex-M4の、ARMの素の開発ができる
っぽい。その場合のライブラリnewlibは、基本的に
フリーライセンスのつぎはぎでできている
っぽいんだけど、そのライセンスを眺めて
みると、GPLはないものの、LGPLが入っている
んだなぁ。


Linuxみたいに、カーネルやドライバと、ユーザ
プログラムの境目が明確ならナニなんだけど、マイコン
のプログラムって、通常はスタティックリンクに
なっちゃうんじゃないのかな？
そうすると、色々使いにくいかもしれない…

でも、
http://ja.wikipedia.org/wiki/Newlib
DSとかGBアドバンスとかに使われてるって書いてあるなぁ。
どんな条件になってるんだ？
DSとかGBアドバンスは、LinuxとかBSDとかで動いて
いるのか？ダイナミックリンクなのか？




あらためて、GPLについてちょっと調べなおす。
https://github.com/x19290/think-gnu-distribution/tree/master/cmp/html

ここに、絶版になってる「Think GNU -
プロジェクト GNU 日記とソフトウェアの憂鬱」
のhtml版が公開されてた。
あとでじっくり読もう。


オイラは、リチャード・ストールマンさんのいう
コピーレフトの考え方については、社会の効率を
高めるって意味では大枠賛成で、実際Linux系の
モロモロは、社会を支えてて、無くてはならない
モノだなぁと思うんだけど、すべてのソフトを
公開するべしっていう原理主義的なコピーレフト
までは賛成しがたいんだよな。

まぁ、ここを触れ始めると、色々と纏まらない
議論が始まりそうなので触れないけど。



http://d.hatena.ne.jp/wagavulin/20110910/1315620620
やっぱ、FreeBSDのlibcとかLLVMの進み具合
とかは、気になっちゃうよなぁ。




マイコン関係に戻って、

http://toybox.cubejam.jp/makers/?p=743
Raspberry Pi用の液晶LCDを使ったシリアル
コンソール画面。

これ、いいな！！


GPIOのシリアル出力を受けて、LCDに表示して
いるみたい。
使っているLCDモジュールは、秋月の
http://akizukidenshi.com/catalog/g/gK-07007/
ST7565Rコントローラ搭載液晶みたい。
これで、21×6行表示。へぇ。

ってことは、同じ制御系を搭載している
http://www.aitendo.com/product/5466
これや
http://www.aitendo.com/product/1622
これとかを使えば、ファームは殆どそのままで、
あと2行ほど表示を増やせそうだなぁ。



処理内容自体はそれほど複雑じゃないはず
だから、適当なマイコンを1個つかえば、
表示自体は簡単に実現できそう。
（極端な話、3.3V版のArduinoでも）

問題は、狭い画面ゆえ、バックスクロールが
できないと、ディレクトリリスト取って見る
のもつらいかなぁ。
そうすると、バックスクロールが出来る程度
のバッファを搭載したマイコンが必要って
感じになるのかな。スクロールの操作方法が
ちょっと知恵要りそうだな。

http://akizukidenshi.com/catalog/g/gP-04944/
制御方法は変わっちゃうけど、これもいいかも。


かと思えば、ドライバ周りまで整備して、
http://www3.cnet.ne.jp/yokomizu/rpilcd/rpilcd_hw.html
GUI画面をカラー表示しちゃうものまで。へぇ。

ただ、640×480より大きくないと、コンポジット
に対してメリットが見出せないかもしれないな。




不思議遊星ギヤっていう、聞きなれないものが。
http://www.nicovideo.jp/watch/sm12579213

へぇ。こんな仕組みがあるのか。面白い。

http://www.nicovideo.jp/watch/sm12841047
ハーモニックドライブは
http://8528.teacup.com/nekosan0/bbs/608
以前掲示板で教えてもらったときに調べてみて、
へぇ、と思ったんだけど、この不思議遊星ギヤ
っていうのも、見事な仕組みで大きな減速が
出来るものなんだなぁ。


赤道儀の場合、ウォームギヤと不思議遊星ギヤ
ではどっちが有利なんだろう？

やっぱ、仕組みが単純なウォームギヤなのか
なぁ。多段階減速だと、それぞれの段階で、
ピリオディックモーションが発生しそうだ
もんなぁ。