風工房日記

誘惑に耐え切れず、さしたる目的もないままArudino UNO R3とRAMを購入。
目的といえば、幾つか疑問もあった。
・Arudino UNO R3は921600bpsで動くか？
・Arudino UNO R3はAndroidにつながるか？
・ADを含めて素のArudino UNO R3でどこまでいけるのか？
と
・シリアルRAMはどの程度の周波数で動くのか？

まずは
・Arudino UNO R3は921600bpsで動くか？
をやってみる。

以下のコードを書いてみる。
void setup() {
//Serial
Serial.begin(921600);
}

void loop() {
Serial.println("1234567890abcdefg");
Serial.flush();
//delayMicroseconds(25);
}

Arudinoのターミナルは115200bpsなのでTraTermでやってみる。
結果．．．時々文字化けする。（ＴＴ）
115200bpsだと文字化けしない．．．というか見ててもわからない。
文字化けというか見ていると行が長くなったり短くなったりするのでわかったりする。
何％正しいのか？は、はっきりとはわからないが９５％は正しいのかもしれない。

原因というかどうもシリアルコンバータの能力を超えているような感じ。
上の
//delayMicroseconds(25);
をコメントを外すと文字化けは結構少なくなる。
25を減らすとエラーが増えて、増やすと減る。シリアルというよりUSBのReadか何かでオーバラン気味なのかもしれない。
パケットが64byteなので例えばデータを64byte以下にして、十分待ち時間を置いて（ここで何か処理する）また転送すれば問題ないのかもしれない。
なので使い方にもよると思われるが、オシロのようにずっと休まず転送し続けるものには不向きなようだ。（ＴＴ）

少し前にNFCPDCというライブラリでPasoriをつないで遊んでいた。

http://hiro99ma.blogspot.jp/2011/09/android-31pasori.html
https://github.com/hirokuma/NfcPcd
communicateThruExを使うことでコードは読めるようになったのだが、それを解読してみたくなった。（＾＾！

探すとＮＦＣ－Ｆｅｌｉｃａというライブラリがあった。
http://code.google.com/p/nfc-felica/
凄い。これはAndroidのNFC用に作成されているが「おまけ？」でSuicaの解読の部分が入っている。
欲しいのは１行というか１６ｂｙｔｅの解読部分だけなので
https://nfc-felica.googlecode.com/svn/nfc-felica/trunk/nfc-felica/
で
・/nfc-felica/trunk/nfc-felica/assetsからStationCode.db
https://nfc-felica.googlecode.com/svn/nfc-felica/trunk/nfc-felica/assets/
・/nfc-felica/trunk/nfc-felica/src/net/kazzz/felica/suicaからDBUtil.javaとSuica.java。
https://nfc-felica.googlecode.com/svn/nfc-felica/trunk/nfc-felica/src/net/kazzz/felica/suica/
　そこらが読んでいる
・/nfc-felica/trunk/nfc-felica-lib/src/net/kazzz/utilからUtil.java
https://nfc-felica.googlecode.com/svn/nfc-felica/trunk/nfc-felica-lib/src/net/kazzz/util/
をダウンロードして組み入れる。

最初にDBUtil.javaでＤＢを読み込む。（最後のCloseも必要）
デコードはSuica.javaで可能。素晴らしい！！
ＤＢは以下よりで商用に流用は禁止されている。
http://www014.upp.so-net.ne.jp/SFCardFan/

でやってみると、こんな感じ。（情報が多すぎてはしょっている）

結局はNFCPDCとNFC-felica（のおまけ？）をつないだような感じ。
でもおかげでここまで凄く楽ができた。

Arduinoのオシロを少し機能を追加した。
やったこと
【垂直】
垂直はアンプなどの設定になるので、この場合多くない。
・分割表示できるようにした。
・ＧＮＤと５Ｖに表示を加えた。（兼用）
【水平】
水平は間引きによって実現している。
・時間軸を＋－で変更できるようにした。
・目盛りの実時間を測定で表示した。
これで正確に出てきたが、40dotで16msなので1dot=400us。なので2.5KHzのオシロ。
なんだか目盛りが計算であわなくて結局は実機に現物あわせしてしまった。（ＴＴ）
ちゃんと計算で出したいが．．．。
Nexus7以外ではおかしくなるかも。
こんな感じ。

キャプチャーのミスで音量表示まで出てしまった。（ＴＴ）
まあ雰囲気はわかると思う。
それに従ってソースなども入れ替えた。
また
【トリガ】
・ソース：ch1/ch2
・モード：立ち上がり／立下り／なし
・レベル：０－２５５
みたいなものを作成しようとしたが、まだ未完成。
来たデータ条件から格納時点を決めればいいような感じ。

相手はFreeRunなので結構シンプルにできる。
軸がよくわからないが目盛りの水平は（区切りはよくないが）表示するし、垂直は０Ｖと５Ｖにガイドがある。ただソースで「現物あわせ」になっているのが気になる。
水平を間引きすると描画も遅くなって、この場合だとかなりストレスを感じるように思う。要は水平はｍａｘ以外はあまり芳しくない。オシロでも遅くすればスイープが見えるのでそういうものだと思うが、早いほうがないだけにつらい。
2.5KHzのオシロってのも実用的にはどうかと思ったりする。
音声帯域には使えないのでレベル確認程度なら使える。何かの動作チェックとかそういう用途ならいいが、それでも入力が0から5VなのでマイナスやAC結合が無理。過電圧だとArduinoを壊してしまう。
ここまでにしておこうか．．．。悩む．．．。

今回はNexus7のTips。

・スクリーンショット
前はddms経由でとっていた。
Nexus7はボタンでとれるらしい。

http://smartphone-zine.com/mobile/nexus-7-screensho.html
電源ボタンと音量を下げるボタンを同時押しするだけ。
撮影した画像は /storage/sdcard0/Pictures/Screenshots/に格納されていきます。

できるがよく失敗する。タイミングがシビアなのか。

・WiFiによるADB接続
普段はUSBで問題ないが、例えばHSB機器の開発をしているとUSBが埋まってしまう。
でWiFiで接続する。
以下が参考になった。
http://www.adakoda.com/android/000541.html
方法は２種類あって
【方法１：ＵＳＢ接続】
1)USB接続する
1.サーバをリスタート
adb kill-server
adb start-server
2.接続する
adb tcpip 5555
adb connect XXX.XXX.XXX.XXX:5555
3.確認
adb devices
2)USBを抜いてもOK

ここからeclipseで書き込み可能

4.切断
adb disconnect XXX.XXX.XXX.XXX:5555

【方法２：ＵＳＢ接続不要】
1.環境変数を設定
SET ADBHOST=XXX.XXX.XXX.XXX
2.サーバをリスタート
adb kill-server
adb start-server
3.確認
adb devices

4.切断
adb disconnect XXX.XXX.XXX.XXX:5555

XXX.XXX.XXX.XXXはNexus7のIPとする。

当方では【方法２：ＵＳＢ接続不要】はうまく行かなかった。
【方法１：ＵＳＢ接続】は一旦はＵＳＢ接続がいるものの外せるし、これでやるとeclipseからそのまま書き込みできて便利。
USBにはその後は、Arduinoなりをつないでおいてもいける。
ただ時々抜き差ししないとおかしくなるようなことがあったが、できないよりは遥かにいい。
この状態だとddmsでキャプチャーもできるのでボタンを押さなくてもできる。

ただ．．．Nexus7が硬いのか、/dataはパーミッションで見えない。いろいろ配置して確認したいときに不便。rootをとるしかないらしい。
問題は充電できていないので、やはりDockが欲しい。
なんだかDockをつなぐとOTGできないような話も聞こえるが．．．。

Aruduinoの高速転送について。
画像は無理にしても音声帯域ぐらいはなんとかしたい。

高速化の手段の案。

１）Arudino UNO R3にする。
https://twitter.com/seewn/statuses/177488910165872640
UARTにて921600bpsで動作可能・・・化けたりもしないし～素晴らしい
とある。
UNOはFTDIではなく．．．
USBシリアルの石がATMEGA8U2からATMEGA16U2に変更になりました。
となっている。マスターはATMEGA328P。
違うかもしれないが、FTDIは別のClock周波数（48MHzとか）で動いているのに対して、シリアル変換のATMEGA16U2もマスターと同じクロック周波数（16MHz）なのでうまく行くのかもしれない。以下の回路図をみた感じ。
http://arduino.cc/en/uploads/Main/Arduino_Uno_Rev3-schematic.pdf
だとすれば、案外921600bpsは出るのかも。
最短距離で美しいような気がする。
但し、例のAndroidのFTDriverは動作しない模様。
http://iwatanlab.blogspot.jp/2011/11/androidusbarduino.html
となると同じATMEGA16U2を採用しているAruduino Megaも同じだろう。
ソースを読むとCDCの記述もあるので、そちらに見せると動くかもしれないが不明。

２）シリアルを921600bpsにする
　単純にやるとクロック誤差の問題になる。つまりArduinoは16MHzなので正確なボーレイトがでず高速になるほどシビアになる。
　なので「ArduinoのClockを14.7456MHzにする」とやってしまうとBootから書き換えになり大変になる。そこで、水晶をソケットにしておいて、「書き込みは16M」にして、「動作時は14.7456MHz」に差し替える。
タイミング関係が全て遅くなるが、ボーレイト設定レジスタを初期化後に再設定すれば案外．．．。

３）FT232H SPI転送
前に書いたようにFT232HというのがあってUSBのハイスピード対応。
SPIなどでも接続できるのでそれでやる。ただ実効速度などは不明だが、このChipに高速で書き込みできればいいのだが．．．。
それとまだFT232Hの価格が高かったりする。

４）シリアルを同期転送にする
　TxD,RxD以外にCLKが必要になるが、これは高速になる。AVRではそういうのもある。ただFTDI（のFT232H以外）はサポートしていない模様。そもそもUSBシリアル変換器では同期転送がないのが一般的なような。であればAVRやPICでCDCを組んで、それを同期式にすればできるとは思うが道のりが大変そう。

素直に考えると
・Arudino UNO R3にする（PCで921600bpsを確認）
・FTDriverを改造して対応版を作成する
で921600bpsで通信すれば100KHzなので50KHz程度のFreeRunが可能。何か入れても転送で25KHzぐらいはいけるのかもしれない。
ADに関しては今のArudinoは10bit保証にしているが、8bit保証なら周波数をあげれば1ch=13-25usぐらいにはなりそう。2chで20KHzほど。
ただ、Arudinoのライブラリは使えないので自前で記述する必要がある。
　本当かどうかわからないが．．．。
　保険でRAMも買っておけば．．．。
http://www.switch-science.com/products/detail.php?product_id=1072
興味はあるが、オシロを作っても使わないような．．．。
アンプも作らないと実用には遠いかも。

・Arudino UNO R3は921600bpsで動くか？
・Arudino UNO R3をAndroidにつなげてみる
・ADを含めて素のArudino UNO R3でどこまでいけるのか？
．．．興味があるにはある。
まあ転送が早くてRAMもあれば何か使えるような気がするが．．．。
デジタルは早いので8chのロジアナとか．．．。
・シリアルRAMはどの程度の周波数で動くのか？
も興味がある。
遅い感じもあるし、8KでいいのならArudino Megaって手もある。

v3.1以上になってUSBまわりのソフトもいろいろ出てきた。
ソースがあるのは有難い。
以下はADKやADBではなくUSBを直接制御するもの。

自分用のメモ。
１）RS232C
　FTDIのChip。有難い。これでArdinoがAndroidに労せずしてつながる。
http://d.hatena.ne.jp/ksksue/20111103/1320347853
https://github.com/ksksue/FTDriver

２）同じくBitBang
　BitBangを使うとUSB-IO風にポートにもなる。
http://projectc3.seesaa.net/article/252898870.html
https://github.com/yishii/FTDriver

３）USB-IO
まさにUSB-IOそのもの。スレーブはPIC18F14K50でHIDで動いている模様。
秋月のより直接購入した方が機能が高いらしい。
http://km2net.com/mobile/usbiof_io_sample/index.shtml
HIDの参考になるかも。

４）Pasori
　Nexus7だとNFCもあるがやはり存在感のあるPasoriをつなぐ場合。
http://hiro99ma.blogspot.jp/2011/09/android-31pasori.html
https://github.com/hirokuma/NfcPcd
最初に読み方がわからなかったが、試行錯誤で解決。
参考になるかもしれないのでコメントに記述しておいた。

communicateThruExを使ってlibpasoriを参考に
・servicecodeを取得
・felica_read_without_encryption02を作成し、上で取得したサービスの読み込み
で読み込みができました。
communicateThruExがあるのでlibpasoriのコマンド移植をして、それでやるんですね。

http://libpasori.sourceforge.jp/
からソースをもってきてlpdumpあたりから追いかけていくとできる。

５）PIC18F/PIC24F
　USBをもっているChipがある。PICといえば、おなじみ、後閑さんのサイト。
PIC18FのUSBは
http://www.picfun.com/usb20frame.html
のあたりにある。製作が面倒な場合は秋月で．．．
PIC18F2550
http://akizukidenshi.com/catalog/g/gI-02161/
PIC18F2553
http://akizukidenshi.com/catalog/g/gI-05410/
PIC18F4550（純正Ver1.2のサンプルがこれ）
http://akizukidenshi.com/catalog/g/gM-03147/
PIC18F14K50
http://akizukidenshi.com/catalog/g/gK-05499/
などを買う手がある。ただ
http://akizukidenshi.com/catalog/g/gM-02495/
のようなボードも必要。
PIC24FのUSBとAndroidは
http://www.picfun.com/android/androidframe.html
ADKもあるが、オシロはUSB制御。
http://www.picfun.com/android/android12.html
ざざっとソースを見るとGenericらしく多分Bulkで64Byte転送のようだ。
Hostも
送信：
mConnection.bulkTransfer(mEndpointOut, message, 64, 0);
受信：
result = mConnection.bulkTransfer(mEndpointIn, buffer, 64, 0);
とある。
device_filter.xmlを変更すれば汎用的なBulkのHostソースにできるかもしれない。
ハードはマイクロファンの
http://www.microfan.jp/pic24f-mod-ga002u
あたり？同社にはPICSYSというArduinoもどきもあるらしい。とにかくレジスタを覚えるのは本筋以外になるので余程最適化したものにしないのならフィジカルコンピューティングの方が楽チン。

６）ATMEGA32U4
AVRにもUSB付があって、AT90USB162というのがある。ただJTAG書き込み（でなくてもFlipでできるが）なせいかとっつきが悪いよう。
今ならATMEGA32U4のダヴィンチか？
http://strawberry-linux.com/catalog/items?code=25001
BootLoader変更でArudinoにもなる。価格は同じ。
http://strawberry-linux.com/catalog/items?code=25005
これでHIDとかCDCとかBulkにすれば多分上のソースから頑張れば動くはず。

８）FT245RL パラレル転送
FTDIのDriver作者が作成されている。
http://d.hatena.ne.jp/ksksue/20120508/1336497436
https://github.com/ksksue/Android-FPGA-FIFO-Transfer
700KHz出るらしい。AVRでもパラレルをIO接続すれば使えそう。
ただFIFOなので相手次第なのでRAMがいるかも。
FreeRunで作るほうがどうかしているが、FreeRunで20KHzほど出て欲しいもの。

９）FT232H SPI転送
FT232HというのがあってUSBのハイスピード対応。
AVRだとボーレイト制約が出るのでSPIなどでも接続できるらしい。
AVRを使った例はなかなかないがＰＣだと以下など。
http://blogs.yahoo.co.jp/d061333/29280180.html
以下を見ると12Mbps出るらしい。
CDCクラスのせいかFTDIのDriver作者のもので動くリストにある。（設定がないので増やせばいいのか？）

１０）EZ-USB FX2
OSCPrimeのサイト。
http://www.osciprime.com/index.php?p=source
にAndroidのソースがある。他はCPLDなのでさっぱり。（＾＾！
ソースを見るとライブラリっぽくなっていてかなり複雑。
日本でもなひたふさんが．．．
http://nahitafu.cocolog-nifty.com/nahitafu/2012/04/index.html
http://nahitafu.cocolog-nifty.com/nahitafu/2012/10/jtag-1d5f.html
Airなのかしら？
そういえばProcessinngも、そのまま放置してある。

まあ、ざっと見ても随分増えたものだ。
で、「何を作るか？」が一番問題だったりする。（＾＾！

お遊びのついでに、ワンセグチューナーを買ってみた。

Logitec Androidタブレット用ワンセグチューナー LDT-1SA01

というものでAmazonで￥７９５だった。というかそれより高いと買わなかったかも。
但し送料が￥５００と微妙。

起動した画面。選局を兼ねている。


試聴画面。

室内では電波で殆ど受信できないが、窓際だとかろうじてＯＫ。
そもそも屋外でも太陽の下だと反射がきつくて画面がわからない。
窓際もそういう傾向はあるが、まだまし。
気持ちとしてはコタツで見たいとかそういうのになるが、アンテナ線にクリップで接続するのならともかく、このロッドアンテナではきつそう。
レビューを見ても「感度が悪い」とあり、アンテナなのか回路なのか携帯よりも悪いようだ。

USBとしてはデバイスに見えており、ADKのようなHostではないようだ。なのでケーブルはあるものの充電はできない。
ここのコネクタが１つしかないのは痛い。
窓際であっても充電しながら見られない。
結局は純正Ｄｏｃｋを買うしかないのか．．．。

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

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

リアルタイム描画は限界がある。
例えば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あたりが対応してきそうな予感がする。

作りかけではあるが、一応ソースを置いておくことにする。
参考サイトのソースをつなげただけというか。（＾＾！

・Arduinoのソース
条件：FTDIでシリアル->USB変換しているもの（なるべく16MHzのもの）
ダウンロード
Ａ０がＣｈ１、Ａ１がＣｈ２の入力になる。
小型のものを使えば格好はいいが、オシロとしては周波数が低すぎ。

・Androidのソース（binにapkもあり）
条件：V3.1以上でHost機能のあるもの
ダウンロード

・Androidのapkのみ
条件：V3.1以上でHost機能のあるもの
ダウンロード

これは完全に途中状態。動作中の回転などには対応していない。
オシロだと「水平時間」「垂直拡大（8bitなので無理？）」「トリガ」「波形位置」．．．つけたいものは沢山あるが全くついていない。
波形は止められるので、Nexus7だと「電源＋音量小」を押すとスクリーンショトがとれる。役に立つ．．．かもしれない。

やっていて思ったのは．．．

多分、市販のオシロは望むべくもないと思うので割り切ったほうがいいと思われる。
そもそも１ｃｈなら￥４０００－４７００で売っている。
http://akizukidenshi.com/catalog/g/gK-04279/
しかもサンプリングは５ＭＨｚ。（１Ｍほどが実用範囲？）
でも２ｃｈは欲しい気がする。

１０ｂｉｔあれば垂直拡大もできそうだが、バスパワーなのでノイズ影響もありシビアな測定は難しいかもしれない。それよりシリアル転送速度が問題になりそう。
Arduino以外を素材にしてFTDI245で転送すれば描画や速度はあげられるが、価格的にはかかってしまう。
それなら、やはりUSB-Audioを使いたい。Line入力なら２ｃｈだし、４８Ｋあたりまでは測定できそう。使わない場合は音楽も聞けるし．．．。光出力があれば高級オーディオになるのかも。

再度になるが、以下のライブラリやソースを継ぎ足している。ｍ（＿＿）ｍ
・USBの制御部分
https://github.com/ksksue/FTDriver
・Androidの描画部分
高速なのでSerfaceViewを使う参考サイト
http://bbs.flatworld.jp/node/1456
重ねあわせ（目盛りと波形）の参考サイト
http://labs.appshelf.info/2011/06/02/268/

adbで書けば、V1.6以上なら動くのでHarpyあたりに入れて遊ぶのもいいかもしれない。
ただ（どのぐらいか別にして）転送速度が遅くなるのは間違いない。同じAVRでやればサンプリング速度が下がる。多分、レベルがレベルなので気にするほどでもないかも。
確認レベルには使えても実用には遠いかも。

このまま放置しておくと、埋もれていくので一応配布はしちゃおうかと。誰かなおしてくれるかもしれないし。
無保証だしサポートもないと思うけど。

Arduinoからのデータは115200bpsで
0xFF(Sync)
0xXX(1ch目のデータ8bitで0xFFは0xFEに変換）
0xXX(2ch目のデータ8bitで0xFFは0xFEに変換）
1ch分（100us）休止
になっていて、これを繰り返している。なのでFTDIでそういう感じで送信すればArduinoでなくても動作する。

感覚的には
・USBはもう少し早いと格好良く思える。FTDI245などだが、あまり無理しなくてもストレスがひどいわけでもない。10bitなどにすると転送にかかりそう。
・キャプチャーは、AD+メモリにすれば￥の分よくなる。ただ市販のオシロを目指すとそれなりの価格になり、ソフトもそれなりにしないといけなくなる。
　なんとなくフレームの概念を持たせてＨ８＋FTDI232なりFTDI245あたりまでがアマチュアっぽい。

と思ったら５００ＫＨｚのを見つけた。
http://www.picfun.com/android/android12.html
ＰＩＣの大鋸所、後閑さんではないか！！
PIC24だと５００ＫＨｚ出るらしい。２ｃｈ使うと２５０Ｈｚなのかしら？
それでもＵＳＢ直接で凄いかも。
Androidソフトはキャンバスにベタ書きなのでオシロっぽくはないかも。
ドライバも書いてあるのでこれがいいかも。

で今のところ．．．（２ｃｈの前提で）
１．２．５ＫＨｚまでなら
　ＦＴＤＩのシリアルでやる
128bitでいいのならch1の0bit=0 ch2の0bit=1にすればチャネルの区別がつくので、データ数は半減できる。多分5Khz程度は2chで出せるように思うがバッファレスでは限界かも。
２．４８ＫＨｚまでなら
　AndroidがUSB-Audioをサポートしてとれるようになるのを待つ
３．２５０ＫＨｚまでなら
　PIC24を使う。まあバッファすれば転送速度は考えなくてもシリアルでもいいかも。
　1024*2byteなら我慢できないこともない。クロックを変えれば115200bps以上出るらしいが．．．。
４．それ以上
　フレームの概念をもたせRAMに入れてゆっくり（？）転送する。
　なんかいきなりこうした方が実用的かも。
かな？

ＰＩＣ２４でＵＳＢなら
http://www.microfan.jp/shop/97_182.html
かな？遊ぶには高いかも。１ｃｈで我慢して表示付の秋月Kitにしたくなる。

ArduinoはともかくAndroidは結構大変。

以下、はまったところ。
・背景はそのままに描画だけを消す
canvas.drawColor(Color.TRANSPARENT, android.graphics.PorterDuff.Mode.CLEAR);
モードをandroid.graphics.PorterDuff.Mode.CLEARにしないとうまく行かない。
・ちらつき防止
　適当に作ってみるとどうもちらつく。（ＴＴ）
　考えると最後まで行くと全部クリアしているが、これだと最後は一瞬。なので書く部分のみ消して書き直す。こうやると残像部分が見えて波形も見やすい。
　ただＳｔｏｐしたときは途中で止めずに１画面描画する。

そのほかにもNexus7はコネクタが１つなので都度つなぎ変えで、これが一番面倒だったかもしれない。

つないで見たところ。

つなぐとアプリの選択になる。

実際の波形。手で触っているので恐らく60Hz。情けない。（ＴＴ）

雰囲気的には、転送速度は実用範囲内に思える。（限度付近？）
オシロは観測部分以外はどうせ捨てるので、キャプチャー速度さえ速ければメモリに入れておいてシリアル転送させれば使える。
Ｈ８－３６６４だと320K/ch程度でできる。しかしシリアルでリアルタイム転送は無理なのでやるとしてもフレームの概念がいる。ただそういうのを考えるならUSB-Audioで48K*2chというのもありに思う。
そもそもV4.1でUSB-Audioといいながら動かない。（カーネルを変えると動くらしい。）
Arduinoでお気軽に遊べるのはここまでか．．．。

せっかくなので何か自作してみることにした。
ArduinoではArduinoScopeなるオシロもどきがある。
http://code.google.com/p/arduinoscope/
Processingでも書かれているのでADBやADKでも動くらしい。

以下にAndroidでやっている人がいた。
http://nznavyblue.blog.fc2.com/blog-date-20120429.html
「arduino　+　android(processing）　でオシロスコープつくろう」
ADKってのは凄い。ちゃんととれているみたい。
ここがどうもわかっていない。まだ取りこぼししてしまう。

同じことをしてもしょうがないのでUSB直接でやってみた。
・USBの制御部分
https://github.com/ksksue/FTDriver
・Androidの描画部分
高速なのでSerfaceViewを使う参考サイト
http://bbs.flatworld.jp/node/1456
重ねあわせ（目盛りと波形）の参考サイト
http://labs.appshelf.info/2011/06/02/268/
動作としては、
・USBからバッファに取り込み
・そのバッファを描画する
ことになる。
データはArduinoから115200bpsでADしたものを転送する。
転送速度が問題なので8bitのバイナリにした。
それでも2chあるのでSyncByteを入れて１パケットは3Byteになる。
Serial.flush();
delayMicroseconds(100);
を入れないと通信ミスが発生しやすいようだ。
Arudino側は以下のようになっている。
// Pin
int analogPin0 = 0;
int analogPin1 = 1;

void setup() {
//AD
analogReference(DEFAULT);
//Serial
Serial.begin(115200);
}

void loop() {
int val;
byte bt;
//Send Sync
Serial.write(0xFF);
//Send Ch1
val = analogRead(analogPin0);
bt = (byte)(val >> 2);
if (bt == 0xFF) bt = 0xFE;
Serial.write(bt);
//Send Ch2
val = analogRead(analogPin1);
bt = (byte)(val >> 2);
if (bt == 0xFF) bt = 0xFE;
Serial.write(bt);
//Frame gap
Serial.flush();
delayMicroseconds(100);
}
わざわざ10bitを8bitにしているので、ArudinoではなくWinAVRで組めばもう少し高速になると思われる。
ただネックになっているのは通信速度で、115200bpsだと10KByte/s程度。4byte（Gap1Byte相当）で1パケットなので2.5KHz程度。
これで横1000dot=1000pointとすると描画に0.5秒程度かかる。
1chにするとSyncByteが要らなくなり、倍速になりGapも無視すればさらに倍速になる。
テキスト送信もあるが、これはソフトは簡単になるが転送速度は半減以下になる。
なんとなく、お勧めとは言えない。

オシロなので転送速度は実用範囲であればよく、例えばAD+メモリ(2Kほど）で格納しておいてシリアル転送すれば、対応周波数はあげられる。
但しAD+メモリにすると連続転送ができずフレームの概念が必要になる。
　例えば00 00 00となるとフレームの終了にするなど。（必ず0xFFが3Byteに１つあるので区別できる）
　フレームサイズはAndroidで決まるので描画以降のものは捨て、次のフレームから再描画させることになる。ただ、捨てるものが多い場合は、描画間隔が長くなり間が抜けた表示になるように思う。

　また転送だけに関して言えば、FTDIでもパラレルのFTDI245を使えば700KHzぐらいは出るらしい。同じ作者のここ。
http://d.hatena.ne.jp/ksksue/searchdiary?word=%2A%5BFTDI%5D
　なので多分方向としては
１．２．５ＫＨｚまでなら
　ＦＴＤＩのシリアルでやる
２．４８ＫＨｚまでなら
　AndroidがUSB-Audioをサポートしてとれるようになるのを待つ
３．３５０ＫＨｚまでなら
　CPUをH8なりARMなりADが高速でパラレルIOをつなげるものにしてFTDI245で転送する。
４．それ以上
　フレームの概念をもたせRAMに入れてゆっくり（？）転送する。
ではないかと。

さっそくＮｅｘｕｓ７にＵＳＢをつなぐ検討。

　Ｎｅｘｕｓ７はＨｏｓｔにもＤｅｖｉｃｅにもなる。但しＨｏｓｔにするにはＯＴＧケーブルを別途購入の必要がある。どうも海外製らしくＡｍａｚｏｎで購入したが、時間がかかりすぎ。しょうがないので￥１００ショップのマイクロＵＳＢアダプタを改造して使用した。
　目標としてＡｒｄｕｉｎｏをつなぐことを考える。これが自由にできれば後は発展形でいろいろ自作が可能になるように思う。
　大雑把にはＵＳＢで制御するには４つの方法がある。

方式１）ＵＳＢデバイスドライバを入れる
　Ａｎｄｒｏｉｄではドライバをインスト－ルできない。これは権限の問題でｒｏｏｔをとれば可能になる。大半のＣＰＵはＡＲＭなのでＡＲＭのＬｉｎｕｘドライバがあればいいが、カーネルのＶｅｒなどで入らないこともある。
　ＦＴＤＩなどはメジャーなＣｈｉｐなのでドライバは探せばあると思う。後はアプリを書けばよいが、これも小さなネイティブアプリを書いてそれをＡｎｄｒｏｉｄのアプリと通信するような書き方になる。
＊V1.6ではこの方式をやっていた。しかし「ｒｏｏｔをとるのが一般的ではない」「とれても設置が面倒」「アプリはクロス環境を構築しないとできない」など欠点としては敷居が高すぎるし作業に危険もある。
　条件さえ満足すれば、Ｖ１．５でも動くし、ネイティブコードなので実行も高速。

方式２）ＭｉｃｒｏＢｒｉｄｇｅによる接続
　これは考え方としてはAndroidのADB（Debug）コネクタを通じて通信させるもの。AndroidからはＩＰポートに見える。「非ADK」とも呼ばれている。
　特徴としては、ADBが使えればAndroidのVerは問わないのが特徴。
http://code.google.com/p/microbridge/
　Arudinoでやる場合Arudino側がHostになるのでUSB Host Sieldなどが必要になる。そちらを購入しなくてもHarpyという一体化されたKitもあるので、こちらなどを利用する方が良いように思われる。
http://www.harpyhack.com/
ただNexus7側がデバイスに見えるので、これなら相手から充電させられそう。
＊比較的、安定しているようでNexus7でもスンナリ動いた。MicroBridgeはAndroidの上ではTCP/IPに見えるのでIPのソフトを書けばＰＣと通信もできる。
これなら（Arduinoは関係なく）ワイアレスでPCと接続できる．．．があまり思いつかない。ＰＣで入れた語句をNexus7で検索させるようなものを作ればＰＣの画面が多少は広く使えるが、これを使わなくてもＷｉＦｉＫｅｙｂｏａｒｄとかＥｚＫｅｙｂｏａｒｄを入れればＰＣでキー入力ができる。
https://play.google.com/store/apps/details?id=org.jakky1.ezKeyboard&hl=ja
ブラウザから入力するならＰＣでやった方が早いので、作っても使うかどうか疑問もある。

方式３）ＡＤＫによる接続
　これはＶ２．３からサポートされている。（ＡＤＫＶ１．０）Ｇｏｏｇｌｅの正当なやり方だが、不安定との悪評も多い。上と同じく、Arudinoでやる場合Arudino側がHostになりUSB Host SieldやHaarpyなどが必要になる。
　現在はＡＤＫ２０１２というかプロトコルがＵｐ（Ｖ２．０）したようで、ＵＳＢ以外でも使える。（ＢｌｕｅＴｏｏｔｈなど）
　Nexus7を購入してやっとここにたどり着いた。その間にArduinoのＵＳＢもＶ２．０となり、ＡＤＫをサポートしはじめた。いろいろやっていると、このＵＳＢＶ２の最新版が一番筋がいい。そもそも不思議なことに全部動くわけでもない。動かないサンプルもある。
　例えばＴｅｒｍはあるのだが、Androidのアプリが落ちる（起動できない。）しょうがないので自作してみた。できるには出来たが、何が悪いのか取りこぼしがある。
＊Ｇｏｏｇｌｅの純正はいいのだが、これなら形態としてMicroBridgeと変わらないし、さほどメリットが感じられなかった。Ｇｏｏｇｌｅの提供しているサンプルの画面はやたら凝っているが、やっていることパケット内容で切り替えている。（ＬＥＤや温度センサなどがあるが、データ構造の形式で区別している）ＡＤＫ　２０１２ともなると、サンプルでArduinoの旧型は見捨ててしまったような印象もある。
　これはＵＳＢのアクセサリをつなぐと対応したアプリを自動的に立ち上げることができる。

方式４）ＵＳＢデバイスを直接制御する
　Ｖ３．１より直接ＵＳＢの制御を記述できるようになった。これを行うには一般的にはドライバ層で行われるようなやり取りをアプリケーション側で記述する必要がある。
　例えばＡｒｄｕｉｎｏではＦＴＤＩなどのＣｈｉｐでＵＳＢからシリアル変換制御させるが、これをアプリで記述する必要がある。とは言っても汎用的なターミナルは既に存在しており、「Android USB Serial Monitor Lite」でできる。
https://play.google.com/store/apps/details?id=jp.ksksue.app.terminal
このソースも提供されていた。
他にも、
FTSampleTerminal
がオープンソースでライブラリ化されており、使いやすい。
https://github.com/ksksue/FTDriver
＊Ａｒｄｕｉｎｏに限れば、これが一番形態として良いように感じた。
しかしＮｅｘｕｓ７に関して言えば電源はＮｅｘｕｓ７側から供給されるため内蔵電池で動いていることになる。この状態では充電できないので長時間駆動ができない。クレイドルが発売されてそれをつければ解決できるかもしれない。
　これはそういうＵＳＢのアクセサリをつなぐと対応したアプリを立ち上げることができる。

結局は４種の開発をやってみたが、４）が筋が良いように感じた。（Ｎｅｘｕ７ではＤｏｃｋが必要。一応側面にＤｏｃｋ用のＰｉｎがある。）但しVer依存するのでそれを嫌うのであれば２）のADBが向いている。
やってみると（115200bps）ADB,USB直接は比較的取りこぼしがないがADKは何が悪いのか取りこぼしが発生する。通信速度というより、パケット間隔をあければよいようだが、制限がわからず使いにくい。

まとめると以下のような感じになる。
AndroidVer Android 利点 欠点
方法１：root 1.5より Host 高速 難易度高（一般向きではない）
方法２：ADB 1.5より Device 汎用性 USB-Hostの必要性あり
方法３：ADK 2.3より Device ？ USB-Hostの必要性あり
方法４：USB 3.1より Host 安価

２）や３）をやる場合は、ＦＴＤＩを外して単なるシリアルブリッジにしてしまった方がＡｒｕｄｉｎｏでは使いやすい。

使いやすそうな素材。
・Harpy
http://www.harpyhack.com/
　一応オープンソースであり小型にできている。Ｎａｎｏで￥２８８０なのでＡｒｄｕｉｎｏ＋ＵＳＢ　Ｈｏｓｔシールドよりは安い。ＡＤＢでもＡＤＫでもできる。
・AGB65　Android
http://www.robotsfx.com/robot/AGB65_ANDROID.html
　シリアルブリッジになっている。Harpyよりさらに小型になる。中身はBlackBoxなのでサンプルソフトを改造するような形になる。（ファームのソースは開示されていない。）￥６３００なので、ブリッジにしてはかなり高くついてしまう。
これはデバイスのファームが不明なのでADKでしか動かない。

殆どは手持ちの中華パッドよりはいいのだが、微妙に劣る点もある。

１）ＳＤカードが使えない
　ＯＴＧのＵＳＢ－ＨｏｓｔがあるのでＵＳＢ経由でできると言えばできる。しかし、
・ＯＴＧ用のケーブルは標準では添付されておらず、別途購入の必要がある（輸入になるので価格より時間がかかった）
・マスストレージクラスは実装されておらず、ＮｅｘｕｓＭｅｄｉａＩｍｐｏｒｔｅｒ（￥２３４）を購入する必要がある。ただしこのソフトは書き込みには対応していない。Ｒｏｏｔ化するとStickMountなどを入れれば可能になる。
＊ＳＤカードは必須というわけでもなくネットドライブがあればそれを使えばできないわけでもない。（アプリのインストールなど）しかし音楽・動画に関しては外部メモリにいれていたので不便になった。
　カードリーダでGH-CRAD-SUAKという製品があり、これだとスマート。

２）ＡＣアダプタの接続コネクタがない
　ＵＳＢ経由の充電のみで単独充電できない。どうもＮｅｘｕｓＤｏｃｋというのが発売されるらしくアナウンスはあるが目下発売が遅れている。（１１／中？）３ｒｄが発売しているのはＵＳＢ接続なので抜き差しで不安が残る。これはＰｉｎ（Ｐｏｇｏと呼ばれる）接続なので置くだけでよいらしい。横置き専用になっている。
「置くだけ」というのは有難い。発売が遅れているのが不安。

３）ＵＳＢコネクタが１つしかない
　ＵＳＢコネクタは１つでデバイス／ホストを兼用している。
そのため６ｐｉｎのマイクロＵＳＢ端子になっていて、ＩＤ－ＰｉｎをＧＮＤに接続するとＯＴＧでＨｏｓｔ側になる。
コネクタが１つなので、例えばＵＳＢ－ＨｏｓｔのアプリケーションをＡＤＢで実機Ｄｅｂｕｇはできない。強いて行う場合はＩＰ接続になる。開発者でなくても、デバイスモードでないと充電できないので、ＵＳＢキーボードなどをつなぎながら使うにはつらい。先のＤｏｃｋを買うか、ＢｌｕｔｅＴｏｏｔｈのキーボードにするかの選択になる。但しＢｌｕｅＴｏｏｔｈにすると今度はそちらの充電が問題になる。
調べてみるとＯＴＧ－Ｈｏｓｔモードでも充電できる機種もあるらしい。Ｌｉｎｕｘのカーネルを変えるとＮｅｘｕｓ７での成功例もあったが一般向きではなさそう。

４）ＨＤＭＩ端子がない
　プレゼに使う場合はちょっと．．．であるが、まあ致命的でもない。
　元々、マイクロＵＳＢではMHLという規格があって、ＨＤＭＩ変換もできるものがある。BSMPC09BKはそういう用途であるが、目下最新のファームでも動作しないという書き込みがある。将来は不明。

５）Ｈｏｍｅ画面が横にならない。
　上のＤｏｃｋを見るとＰｉｎの位置から「横置き」も視野に入れられている。しかしＨｏｍｅ画面はなんと縦型のみで横にならない。（ｒｏｏｔになって書き換えすれば別。）Ｈｏｍｅで本体を回転させるのは不便でしょうがない。「最高のローテーション制御 (Ultimate Rotation Control)」219円を使うと強制的に統一できる。これ以外にも無料のものはあるが、起動時に常駐させたいので、これが一番優れていた。
　そうこうしていると１０月の１２日にＵｐＤａｔｅが来て、ＵｐＤａｔｅしたら４．１．２になった。
http://gpad.tv/develop/google-nexus7-android412-jzo54k/
「ホーム画面回転対応」とあるので対応した模様。これだけのためにアプリを購入してしまった。（ＴＴ）ただ￥２０００の期限付きクーポンはついている。
常識的にＤｏｃｋが横向き前提に対して、これはないと思う。
横にした画面。
あこがれのＨｏｍｅ。

メディアプレヤー．．．は当然か．．．。

　総じて優れてはいるが、個人的にはＡＣアダプタ端子がないのが非常に残念。それ以外は、多少は不便ではあるが我慢できないわけでもない。
　自宅にいる場合はＤｏｃｋで充電し、持ち運ぶ場合はキーボード付カバーが良さそう。キーボード付カバーはマイクロＵＳＢなので買いなおし。ＯＴＧ接続されているらしくちゃんと動いた。
ソフトは幾つか購入したが、Ｎｅｘｕｓ７を購入すると￥２０００のＧｏｏｌｅＰｌａｙの購入ポイントがあるのでそこから支払えば済む。（但し、有効期限がある。）

遅ればせながらNexus7を購入した。
GooglePlayから購入したら期限付きで2000pointついた。

これでPadは３台になる。
中華パッドはV1.6とV3.0でこれはV4.1になる。

V1.6はFlyPadでこれは初代なのでさすがに今は古くなった。抵抗膜方式だし、すべてがもっさりしているのでブラウザとしてもいまひとつ。
マイク端子でオシロを動作させたものの、それほど使わない。後はネットラジオかmp3プレヤーならまだ活用できるかもしれないが、これも頻度が高そうではないので廃品寸前になっている。

V3.0はhipadm7sというものだが、DroPadやHeroPadという名称もある。ただm7sというのはマイナー。USBに期待もあったが、結局はAPIが古く、ADKなどはうまく行かず。root化してもシリアルは全滅し、かろうじてADBなら動作した。
GPSもNFCもないので、パッドとしてはいまひとつ。おまけでGayo!も低画質でも止まりまくる。
ブラウザはかろうじて実用的なレベルだし、静電型なので操作も悪くはない。
V4.0にできるが、操作性がいまいちなのでV3.0に戻して使っている。

というので、
・USBで遊びたい
・GPSやNFCを使って遊びたい
・Googleの純正というのに興味があった（動かない場合はアプリが悪い？）
ということからNexus7に手出しした。
16Gで￥１９，８００とかなりお買い得な設定。（日本では8Gはないのか？）
シンガポールからの発送（送料は無料）で時間はかかったが無事到着。

早速、遊んでみることにする。