この間の、SPI通信を高速化する関数、
http://brown.ap.teacup.com/nekosan0/2248.html
SSD1306 OLED用の実験プログラムからこの関数を
抜き出して、5110液晶のプログラムにも適用して
みた。
当たり前だけど、表示が一気に高速化できた。
line描画もサックサクに速くなったので、シメシメ
と調子にのって、もうちょっと弄ってみる。
なんとなくオシロっぽい動きをさせてみる。
既に、タイマ割り込み処理も、FFTライブラリも、
高速ADC（単なるアナログ入力じゃなく、高速化した
ADC入力処理）も、メモリ使用量調査のために組込ん
であるので、これを連動させて、サンプリングした
データを画面にプロットしたり、FFT表示させてみる。
と言っても、単位とかはいい加減なまま、とりあえず
画面に収まる範囲にレンジを調整して、それなりに
波形が出てくることを見てみたいな、と。
まず、オシロの入力波形表示イメージ。
こんなんだったり、
こんなんだったり。
単位とかは、固定文言決め打ちなので、現状ではまだ
全くのウソ。単位とかはあとでUIを詰めるときにまた。
サンプリングした値をドットで表示しているだけなので、
振幅が大きくなると、こんな風に点々になっちゃって、
イマイチ分りにくいかなぁ。線で繋ぎたいところ。
次、FFT画面。
こっちは、xorのline表示で繋いでみた。
グラフ領域が横64ドットなのに対し、64点FFTの
実数化（スカラー化）データは32点なので、
1つ飛びだから、うまいこと簡単に表示できた。
オシロの波形表示も線で繋ぐとすると、横64ドット
のところ、64点を線で繋いで描画する必要がある
から、ちょっと厄介かもしれないな。
画面全体を再表示しなくても済むように、わざわざ
xor表示出来るようにしてあるので、オシロ波形
だけpset条件のlineで描くのは、処理負荷的に困る
のだ。
ちなみに、入力波形は、アナログ入力端子を
オープンにしたときに拾ってるノイズ波形
なので、特に意味のあるデータでは無し。
なんとなく、FFTの表示、40dbほど小さく出ちゃう
感じだなぁ。っていうか、半分の長さで表示され
ちゃってる感じ。
例えば、この写真のDC成分は、ほぼフルスケール
（一番上まで）表示されるであろう入力データなの
に、そこまで届いてないんだよな。
FFTの窓関数によるエンベロープの広がりも、
そんなに小さくするほどの影響はないはずだし、
どこか計算式が勘違いしてるんだろうな。
まぁ、以前考えておいた計算式を組み込んでいる
訳じゃないから、あれを組み込んだらそれなりに
動くんじゃないかなぁと。
なんにしても、それっぽく動いているのを眺めると、
なんかちょっとタノシイ。
ちゃんと動くようになったら、専用基板が欲しく
なるよなぁ。
http://p.twipple.jp/rJeTv
話題になってる漫画。
不思議なことに、オイラもこの漫画読むと、なぜか
鼻血が出ちゃうんだよね。不思議不思議。
200回くらい確認してるから、間違えないと思う。
昔はまぁ面白かったんだけど、オイラはオカルトや
迷信には興味がないから、もう永遠に読むことは無い
だろうな。
綿密な取材に基づいて云々って話らしいけど、
取材のノートには、
「鼻血かくにん！よかった。」
とでもメモってあるのかな。不謹慎だよな。
せめて「この話はフィクションです」って書いておけば
よかったんじゃないのかな。
オイラは元々鼻の内部が弱いからだけど、普通の人
だったら、低線量の被爆したくらいじゃぁ、そんな
症状が出るって、科学的には考えられないけどな。
むしろ、鼻血出るほどの被爆してたら、もっと他の
症状がいっぱい出てるはず。
その程度の線量で云々いうなら、大理石の生産地域
とかでは、もっとたくさんの人が色んな症状に悩ま
されてないとおかしいはずなんだけどな。
まぁ、もう忘れよう。
https://twitter.com/GOLBY_TRINITY/status/464712212607553536
エレベーター。
https://twitter.com/matsumoto0007/status/465510217954779136
またしても武蔵野線。
伊東四朗、小松政夫もびっくりだな。
http://www.aitendo.com/product/7458
そこそこのお値段だけど、aitendoのタッチセンサー
基板。なかなか使い勝手良さそう。
http://cherio199.blog120.fc2.com/blog-entry-8365.html
テルマエ・ロマエの原作！
|
おすすめブログ
@goo_blog
