Nexus7（その７）

せっかくなのでもう少しオシロについて考えてみた。

お遊びとは言えオーディオ信号程度は見たいように思う。

リアルタイム描画は限界がある。
例えば30fpsにしても33ms分で、1KByteあったとしても33usなので30KHz程度。
丁度、オーディオ程度ともいえるが、それ以上高速になると描画が追いつかない。
なので、それ以上を目指すのならRAMを積んだバッファが必要になる。
一方、どのぐらい必要か？というと、2ch*1K=2Kなのだが、例えばダブルバッファにすると、この２倍になる。
AD変換の速度もあるのだが、小型のマイコンではここがまずネックになってしまう。（2kあればいいほうなので）
Arduinoも例外ではない。
話はそれるが、PICなどでも実現できるがISPかWriterを購入することになる。それにレジスタの使い方から覚えることになるので、フィジカルコンピューティング（Arduino）ほど敷居が低くない。つまり「お手軽」からかなり遠ざかる。

・ArduinoにRAMをつける
で、Arduinoで探すと
http://www.switch-science.com/products/detail.php?product_id=1072
というSPIの32KのシリアルRAMがある。速度が良くわからないがそれなりに高速という前提にする。
するとATMage168で76.9kSPSとあるので、2chでも38KHzでサンプリングして格納できる。
こういう方式にする場合の欠点として相手の画面サイズで格納サイズが変わる。
Nexus7は1280*800なので1024より大きかったりする。 Nexus10ともなると2560*1600と2K以上あったりする。沢山見られて便利ともいえるが．．．。
一般的には1024もあればオシロより多分広いような気がする。

・転送の高速化
　シリアルをやめてしまえばいいが、Arduinoだとそうも行かない。FTDIではSPI対応のものChipもあるのでそういうのもありだがどんどん金額があがっていく。
　FTDIは115200bps以上も出るらしいがクロックを変更する必要があるらしい。14.4756MHzとかとにかくボーレトが割り切れるものにするとできるらしい。但し、そうやるとbootからリコンパイルになり、IPSがないと書けなくなる。
　115200bpsより高速に越したことないが、多分工夫で早くした方がいいかもしれない。
115200bpsでも2kByte転送するのは、5KHz=200msなので描画待ちストレスというのはさほどないような気がする。そもそも描画速度と取り込み速度は上のRAMで無関係になる。
シリアルなので、１つ狂うと間違えてしまう危険性は回避する必要がある。
　案としては
１）256->255にして0xFF->0xFEにし、0XFFをSyncにして同期する（現状）
２）256->128にして最下位の1bitで1chか2chかを識別する
３）細かく同期させずにsyncは（例えば）64Byteに1度とかにする
みたいにして余分なデータを減らせば高速になる。ただ現状でも2.5KHzぐらいで転送はできている。

これをやれば多分、38K/chとは言わないまでも30K/chぐらいは出そうに思われる。
ただ、こうやると現状のようにデータが流れ続けている制御ではなく、パケットとして考えた方がよいと思われる。
後閑さんのソース(PICF18のもの）を見ると、描画が終わると次の取り込みはHostから指示している。確かにその方が合理的に思われる。
最低で水平方向だけでも以下のような通信が必要になる。

Ａ）スイープ開始
Ｂ）スイープ時間
　タイマーの値を変更する。Deviceはタイマの一定周期でADして格納し、終わると転送する。
Ｃ）トリガ
　Deviceは指定chの条件をデータから探し、あればタイマ周期でADして格納し、終わると転送する。

みたいな感じが必要。
垂直方向はアンプというかそういうもの依存するのでハードっぽくなる。
そうなるとDevice->Hostの通信だけでもいいかもしれない。

RAMだけでできそうに思うが、どうも食指がわかない。
というのもできてもオーディオレベルで、それならUSBオーディオがサポートされればOscPrimeあたりが対応してきそうな予感がする。