空を見上げて
トップページ » ソフト » スマートフォン » Nexus7(その14)

Nexus7(その14)

オシロで挫折もあってそこまでのAndroid関係の自作ソースのを置いておくことにする。
参考サイトのソースをつなげただけというか。(^^!

1.FTDI_Scope
ArduinoをオシロにしてAndroidで表示するもの。
A0がCh1、A2がCh2の入力になる。転送速度は230400bpsで周波数8kHz。
Nexus7用に決めている部分があるので他の端末では座標がおかしい可能性あり。
Trig部分は未実装。オシロとしては周波数が低すぎ。
・Arduinoのソース
条件:FTDIでシリアル->USB変換しているもの(16MHzのもの)
ダウンロード
UnoR3はインストールできるが動かない。
・Androidのソース(binにapkもあり)
条件:V3.1以上でHost機能のあるもの
ダウンロード
・Androidのapkのみ
条件:V3.1以上でHost機能のあるもの
ダウンロード
<参考サイト>
・USBの制御部分
http://d.hatena.ne.jp/ksksue/20111103/1320347853
https://github.com/ksksue/FTDriver
・Androidの描画部分
高速なのでSerfaceViewを使う参考サイト
http://bbs.flatworld.jp/node/1456
重ねあわせ(目盛りと波形)の参考サイト
http://labs.appshelf.info/2011/06/02/268/

2.UnoR3Driver(おまけ)
ArduinoUnoR3のドライバを手直ししたもの。
https://github.com/ksksue/FTDriver
の対応部分を書き換えたもの。
ダウンロード
1箇所267行付近でCDCの場合、下のコードを通らず、下にもCDC条件がある。
なのでそこを修正してある。
動作はするが凄く不安定な印象。原因不明。
FTSampleTermに組み込むと動作する。

UnoR3はいろいろやってみたがどうも安定しない。
FTSampleTermだと動作するには動作するが115200bpsでも文字化けが発生する。
まあ9600bpsで事足りることもあるわけでないよりはいいのかな?というレベル。
USBViewで調べると
idVendor: 0x2341
idProduct: 0x0043
bcdDevice: 0x0001
なのでそこはまず問題がない。
numOfChannelsは他を見ると以下になっていて、搭載されているCDCのチャネルの数。
FT232RL 1ch
FT232H 1ch
FT2232C 2ch
FT2232D 2ch
FT4232HL 4ch
FT230X 1ch
なのでここは1chだろう。(WinでもComポートは1つだけになる。)
bDeviceClass: 0x02
で、これは
#define, USB_CLASS_COMM 2
となっていて
if (mDevice.getDeviceClass() == UsbConstants.USB_CLASS_COMM) {
isCDC = true;
} else {
isCDC = false;
}
はisCDC=trueになる。
不思議なのは267行付近に以下の記述がある。
if (isCDC) {
int len = mDeviceConnection.bulkTransfer(mFTDIEndpointIN[channel],
buf, buf.length, 0); // RX
if (len < 0) {
len = 0;
}
return len;
}
これだとこれisCDC=trueではこれ以下は通らない。しかし333行付近に
if (isCDC) {
for (int i = 0; i < mPacketSize; i++) {
...みたいな記述があってどうも辻褄があわない。なので
if (isCDC) {
int len = mDeviceConnection.bulkTransfer(mFTDIEndpointIN[channel],
buf, buf.length, 0); // RX
if (len < 0) {
len = 0;
//????
return len;
}
//????
//return len;
}
としてある。結果は大差ないような感じだけど。
後、呼び出し側でThead.sleep(100)みたいなのがあるが、完全に削除するとよくないようで小さくすれば良いようだ。

思うに...ArduinoUnoR3ではないが...
AVRでいろいろやると場合によっては遅いのではないかと思ったりする。
ちなみに
・ADBは軽くてATmega168でも収まるし取りこぼしが少ない。(適用範囲も広い)
・ADKになるとATmega328でないと入らないし取りこぼしが多い。
ADBもADKもSerialではないがUSBHostSieldを使うためやはり処理時間の問題があるような気がする。
なのでADKにしても高速なものはAVRではない方がいいかもしれない。AVRはPICとは違って16bitとかそういう方向には進まなかった。
LEDのOn/Offとかセンサー読み取りぐらいなら問題はないと思うが、高速を期待するのならADKもそれなりのものにしないといけないような気がする。
浅草ギ研の以下はそういうものなのか?
ANDROIDシリアルインターフェイス AGB65-ANDROID
http://www.robotsfx.com/robot/AGB65_ANDROID.html
これでもつらそうだが...。
ADKボードもいろいろあるが、注意した方がよさそう...。
高いのはそれなりなのだろうけど、本体より高いのはいただけない。
Googleが高性能で安いADKボードを出してくれないかな?
ってArduino Mega ADK R3なのかしら?
プログラムサイズとかRAMとかIOは増えているが高速でもないような...。
これならATMage328で動くのだけ動かせばいいような...。
USB-Host部分をASIC化しちゃって高速だといいのだが...。

by   at 09:00
コメント

コメントはありません

コメントを書く




保存しますか?


(書式を変更するような一部のHTMLタグを使うことができます)


Please enter the security code you see here