空を見上げて
トップページ » 2012年12月

Nexus7のDock

DIYしてみたものの、あまりの不安定さに純正Dockを購入してしまった。
さすがに純正なので置くだけで動作する。(^^)

オーディオは音質は良くわからなかったが設定で音声は出てくる。外部にアクティブなアンプが必要な感じ。どうせなら光出力にするか、パッシブスピーカーでもOKにして欲しかったりする。

で、やっぱりキーボードが欲しかったりする。
BlueToothなら何もDockも買う必要がないし、今回も便利には違いないが電池か充電になる。最近は半年もつのもあるのでそのぐらいなら良いような気がするが1週間に1度だとさすがに不便に思う。
そこでUSBキーボードにする。

日本語のUSBミニキーボードを並べてみる。

ディスクトップPC風に使えそう。
今度はKBを出しっぱなすと場所が占有される。
そこでL型の金具をDockの裏に貼り付ける。

これで使わない場合はKBをたたんでおける。

どうもDock自体がV4.2以上にしないとうまく動作しないらしい。
ってことはASUSが遅れたというよりGoogleのVerUpのせいで遅くなったようだ。

Dockの充電であるが、OTGでできるのか興味があった。
というのもOTGはHost->Deviceへの流れになる。
ただPogoPinが例外というのはありえる。
USB-KBをさしたままDockにつけても動作するのだが、この時も充電されているのだろうか?

供給を見るとステータスがACからの供給になっている。Dockから外すとBATになるのでACからの供給というのはいいのだが...問題は充電しているかどうかだ。
電池マークは充電になるようだ。ただ、しばらくつけているとわずかながら電池残量が減っている。つまりはACからの給電(充電?)はするが十分ではないのかも。それにしても給電が消費に追いつかないのか...これも解せない。マイクロUSBは純正の(パワフルな?)ACアダプタにつないである。

Nexus7が電源Onだと上のようになる。一方、USB充電だと電源Offすると充電モードになってくれるので、Dockでもこれはそうなるようだ。どうも、電源Offだと確実に(急速)充電してくれるらしい。実際にそうしておくと充電された。多分KB接続でOTGになっているかどうかは関係なさそう。

XDAに似たような話が書いてある。
http://forum.xda-developers.com/showthread.php?p=29639826
IT IS CHARGING via the POGO pins! (but only when turned off)

つまり、電源On状態だと、給電(充電?)はできても十分ではない感じ。電源Offでは確実に(急速)充電できるらしい。動作もそんなような感じがする。PCのバスパワー充電もそうだが、この状態だと充電はできても不十分(低速充電)なのかも。
マイクロUSBはPCと接続できてデータ転送できないし、電源Offしか急速充電できないのなら素直にACアダプタコネクタをつけて欲しかったりする。

ずっとスリープしたらどのぐらい消費電力があるのか?と思ってワットチェッカーで見てみると、殆ど測定できないぐらい小さい(電池を使っているため?)か、これならスリープさせておけばいいのかもしれないが、上の理由で給電(充電?)はしていても充電は遅いようなので...。まじめに電源Offするのがよさそう。(これは確実に急速充電する。)

スリープ状態は時計の代わりにはなりそうだが、すると折りたたんだKBが邪魔なのでL字金具は後ろにつけたほうがいいかもしれない。でも、スリープで充電が遅いのは悲しかったりする。寝る前には消さないといけないかも。Dockの仕様にしてはおかしな感じ。いつでも急速充電(?)して欲しい。

カーネルを入れ替えるとOTGでも充電できるらしいのだが、そこまでやる気もしない。VerUpでできることを期待したいがV4.2で遅れた時間を考えると...。

OTGでも急速充電はできないようだが、給電(低速充電?)はできるようなので多分USBにいろいろつないでやってみてもそんなに電池消耗はしなくなるのかもしれない。但し状況によっては電池は減っていくと思う。

by   at 09:00  | Permalink  | Comments (0)

Nexus7のDockのDIY

Nexus7を使っていたが...
・KB入力以外は効率が悪くて使わない
・電池は持ちはよいが、それでもやがて充電が必要になる
というのでKB付ケースと充電を交互に使っている。
そうなるとマイクロUSBの抜き差し回数が半端ではなく気になってくる。
 そもそもNexus7にACアダプタ端子があれば済むような話なのだが、これがそうなっていない。(TT)

 そうこうしているうちにASUSから純正のDockはやっと出荷された。ううむDockが欲しいのだが、これだとKBケースが使えない。(TT)
 それに画面で見る限りはNexus7の角度が垂直に近いので見づらくないのだろうか?
ただ横のPinで接続するというのはなんとも捨てがたい魅力。
 これはPogoPlugと呼ばれるスプリングPinで接続するものらしい。呼称がいろいろあるが
・PogoPlug(PogoPin)
・コンタクトプローブピン
・スプリングプローブピン
...などと呼ばれている。

純正のものも捨てがたいが、価格が高い上にKBケースが使えない。
オーディオの出力は興味があるが、デジタル出力ではなさそうだし、AppleのDockは「ないほうがまし」みたいなトラウマもある。実際に調べてみると「ないほうがまし」という評価も見うけられる。
なので、オーディオはあきらめて充電機能だけでも欲しい。
DIYできないかと探していると先人がいた。(^^) 
https://plus.google.com/u/1/109241120946756113077/posts/fPV1tvd7YfX#109241120946756113077/posts/fPV1tvd7YfX
素晴らしい!!
条件としては
・Nexus7を4.2にUpDate(これはそうなっている)
・PogoPlugの1pin(中央より)がGnd、4pin(端面より)が+5Vらしい
でできる。なんとも簡単。
ただPogoPlugが問題になる。
これは
http://d.hatena.ne.jp/OkibiWorksLabo/20100626/contact_probe
に詳しかったりする。
SparkFanの他、秋葉原やストロベリーLinux、マルツパーツでも入手できる。(が高い)
それとNexus7を実測するとこのピッチは2.54mmより広かったりする。
それに短いPinが案外なかったりもする。

4本だと難しいがGNDと5Vの2本ならスポンジでもスプリングの代用になりそうな気もする。試しにDIYを試みる。

まずはPt板を細く切る。

次にPinの頭を出してACアダプタをつける。

完成して装着する。

Pt板だけだと自由度が高いので左右はACアダプタで固定。本来は前後にも何かつけたほうがいいのだがキーボードケースで挟み込んでおしまい。
Pt板そのものがバネというかたわむので接触できるのではないかと...。

まずどうなるかというと...
・+5Vを入れるとDockとして認識される
 なので音声を外部にするか?とか時計をセーバにするか?とか聞かれる。
 音声はもってないので内部を選択。
・USBのOTGをつなぐと...
 電池状態を見ると一応ACになっていた。充電はしているのかもしれないが、最悪でも電源をOffすると充電してくれるらしい。
 なのでUSBキーボードをつけたままにできる。
でここまではいいことなのだが...ちょっとずれると接触不良になる。(TT)
 そもそも固定しないで挟み込んでいるだけなのでそうなってもしょうがない気もする。
 ホットボンドで固めるなりすれば安定はすると思うがあまりやりたくない。そのぐらいならPogoPlugにハンダしちゃえばもっと安定するように思う。
 こういうアダプタが安く出ればいいのに...。

 結局は固定方法で良い方法がわからずとても不安定な感じ。そこらが解決すればなかなか使い勝手としては良いように思う。
 純正Dock+USBキーボードでもいいかもしれないが今度はしまうのが大変そう。
それに純正DockはPCとのデータ接続はできないらしい。これも残念。
 ACアダプタの口かUSBをもう1本出してくれれば...。なんだか変なところに中途半端な気がする。そのうちどこかが面白いものを出すのかもしれないが...。

by   at 09:00  | Permalink  | Comments (3)

PIC18F45K50

最近はArduinoばかり使っている。
いいところは...
・AVRなどのレジスタを意識することがない
・Writerなどの投資が別にいるわけではない
・PCとはUSB1本でつながるだけ
・ライブラリが多く自分で全部書かなくても良い
というお気軽さで、開発環境はこうでなくては...と思ったりする。
AVRはその昔はICソケットで焼いていたが、すぐに低電圧書き込みができるようになった。なのでISPmk2をもっているが、Arduinoの出現で、それを使う機会も減ってしまった。

一方PICはといえば、秋月のPICWriterをずっと使っている。高(?12Vなど)電圧なのでICソケットで焼いている。VerUPを重ねながら
AKI-PICプログラマー Ver.4
http://akizukidenshi.com/catalog/g/gK-02018/
にまでUpしてきた。PICも低電圧プログラムに対応してきてISP対応できてきた。

AVRに倒れた理由はここにもあって
・Bank概念がない
 PICも最近のものはない。
・開発環境が無料
 特にC言語は制限がない。PICは最近は無料だが制限がある。
・ISPに対応している
 PICも最近は対応。ただ不思議に思うのはPICkit2が出てPICkit3が出た。もし低電圧プログラムできるのなら自分自身も書き換え可能なのでPICkit2を買えばPICkit3にUpできそうなもの。ハードの互換性か?
 AVRのISPmk2はUpDateできてデバイスが増えても最新版にできるので経済的。
 秋月さんのも程度はあるが、自分でVerUpは(ある程度)できる。

というのでPICを使う必然性がないままだった。
で、ここへ来てPIC18F45K50をやってみようかと。(^^!
自作するというより結構人気があって
・USBBlasterもどきが作れる(CPLDややるとしたら)
http://sa89a.net/mp.cgi/ele/ub.htm
・USB-IO2.0もどきが作れる
http://homebrew.jp/show?page=1435
などで遊べそうに思ったのが動機。
しかし...PIC18F45K50は手持ちの
AKI-PICプログラマー Ver.4
では書けない。(TT)
同じ秋月さんなのでVerUpするかアダプタでも出して欲しいがそういう様子はなかったりする。
かと言ってこのためだけにPICkit3を買うのもためらわれる。まじめに使い続ける予定もなかったりするし...。
で自作することにする。

1.FTLVP
FTLVPの簡易版というのがある。以下回路図。
http://wind.ap.teacup.com/feng3/459.html
FT232に抵抗をつなげばできたりする。(^^)
書き込みは同じ作者のPICProg4uを使う。
http://feng3.nobody.jp/4u/index.html
途中をはしょると...
上にあるようにPICProg4uで「FTLVP」ではなく「ユーザ定義」を選ぶと簡易版が認識される。(DATの折り返しを見ているのか?)
そこまではいいのだが、PIC18F45K50のデバイスIDが読めない。(0xFFになっているとある。)
・MCLRのPullUp
・PGMのPullDown
・3.3V切り替え
...やってみたが症状は変わらない。挫折...。

2.HIDaspx
 FTLVPはプログラム不要なので有難いがこれはAVRのプログラマが必要。
手持ちの部品でできそうに思ったが、「青色ダイオード(または3.3Vツエナー)」と「12MHz水晶」ってのはもっている人は少ないかも。尚セラロックではうまく行かない場合がある...らしい。(千秋ゼミにそう書いてあった。)
http://hp.vector.co.jp/authors/VA000177/html/FrontPage.html
に詳しいがHIDaspxそのものはAVRのISP。ただPICspxというホストプログラムがあって、これを使うとPIC18F45K50に書き込みができるらしい。
早速作ってみるがFTLVPよりは配線も部品も多い。
まず、動作確認用にAVRのISPをやってみる。
ソフトはhidspx-GUI.exeというのがある。HIDなのでドライバ不要。
いろいろあったが、Arduinoを読んでみるとまともに読めるようになった。
で肝心のPICでPICspx.exeでやってみる。
PIC18F45K50を読むと...デバイスID=0になってErrorと出る。(TT)
LVPとかいろいろ疑うが、最終的にはMCLRをVccに10KでPullUpしないとまともに動かない。これがわかるのに半日。PicKit3の方が早かったかも。でもHIDaspxでARMのJTAGもできるらしい。
それと秋月の場合はPGMはRC3でライターの端子の同列上にはない。しょうがないので線材でつなげるようにした。
結果的には無事動作して書き込むことができた。(^^v
但し、恐ろしく時間がかかる...が様子が出るのでイライラはしない。
そもそもhexを書くだけなのでソースビルドもないし。

FTLVPも入れた記念写真。

これはここまでかな?

by   at 09:00  | Permalink  | Comments (0)

Windows8

Windows8のDL版を購入した。
¥3,300。メディアも注文できるが高くなる。

ISOでも落とせるので自分でDVDに焼いたほうが安くできる。
後で知ったが、アシスタントを使うと例えばWin7が32bitだとWin8も32bitになるらしい。32bit->64bitにしたい場合でもクリーンインストールでカスタムを選ぶとできるらしい。但し32bitの環境は引き継がれない。

それはともかく、使った印象。
スタート画面が使いにくい!!
階層もなく平板に並べられた画面で探すのはちょっと...。
そもそもこれってタッチパネル用かモバイル向けにとってつけたとしか思えない。
そこからディスクトップに入ると普通のWin7ライクな画面になるが、今度はそこにはスタートメニューがない。今度はアプリを探すためにまたスタートメニューに戻るはめになる。勢いディスクトップがショートカットの山になる。

使っているアプリが10個程度までならそれでもいいのかもしれないが、増えてくるとこれでは使いにくくてしょうがない。つまり操作が余計増えるような構造になっている。
では通常のディスクトップはと言えばデザインも平板になった。それでも高速ならいいと思うが。
多分起動が早いのもスタート画面を出すまでが早いだけで、ディスクトップは立ち上がっていないような気がする。(何も入れなければそうでもないのかもしれないが)

このスタート画面というのはアプリでも良かったのではないかと思う。
・起動時に表示させる必然性がない
 タッチパネルの場合はアプリでスタートアップに入れておけば良いようなレベル
・ディスクトップからスタートメニューを削除する必然性がない
 探すためにいちいち画面を切り替えないといけない。またはショートカットの山を作るかそういうフォルダを作っておくか...。
いずれにしても自分には改悪に見える。
Vistaほどではないにしろ使いにくいOSだし、Win7とさして変わらないような感じ。
それにディスクトップだとタッチパネルはまず使わないし、細かくて操作できない。ピンチングはあるにしろ面倒でマウス操作の方が早い。携帯とかPadではないし。
 
 というのでClassicShellをインストールして従来操作に戻してしまった。快適というか普通に戻ったというか...。Win7のエアロを外したような感じ。

 OSももう売りの目玉がないのかもしれない。タッチパネルはそうなのかもしれないが、ディスクトップではマウスもキーボードもあるし、殆どのアプリのUIがそうなっていないので使わないように思う。まあOSがサポートした方がいいとは思うが。

 そういえばWin7ではタッチPCを無償でばらまいてコンテストをしていた。その時はAPIでアプリで記述するような感じだった。Win8からはOSなので一般アプリでも例えばピンチングなどが使えるのだろう。あるべき姿というか。しかしタッチパネルユーザ以外はメリットがない。そもそも全てがマウス+キーボード操作前提なのでタッチでは小さくて触れない。余程の大画面でも難しいように思う。

 結局は従来ユーザにとってはさほどの目玉がないことになる。Officeも余分な機能だらけで不安定になってきてFreeのもので十分になってしまった。それに似たような印象を受けたりする。
 MS突然の人事も気になるし...。

 コンピュータ業界もそろそろ成熟期から衰退期に入ってきたのかも。ネタ切れ状態のような...。

by   at 09:00  | Permalink  | Comments (0)

BenchScope(その3)

BenchScopeの波形キャプチャーの続き。
これができれば結構便利。
目標としては汎用のUSB-Serialケーブルで取り込む。
片方はRS232Cのレベルコンバータが入ったものになり例えば
USB・シリアル変換ケーブル[グレー色]
http://akizukidenshi.com/catalog/g/gM-02746/
¥900
勿論純正の
BenchScope用 USBインターフェース
http://akizukidenshi.com/catalog/g/gM-00557/
でもいいが、¥15,700は本体価格に近いので...。
純正だと多分PCでリアル風に動くが、本体もあるしその方が便利なのであっても使わないと思う。欲しいのはキャプチャーのみ。

方法を調べるとやはりプリンタを利用するのが良さそうだ。
http://www.majority.nl/projects_benchscope.htm
のBENCHPRINTでいいように思う。
ただCom1-Com4というのは少ないし、記憶しないのも悲しい。そもそもまともに動かないのでそこらを作成してみる。
方式としては上と同じく
・シリアルデータをファイルに落とす(prnファイル)
・それを変換しbmpにする
とすることにする。

1.シリアルデータの取得
 便宜的にはTeraTermのLogでバイナリ保存するととれる。高解像度(Hi)と低解像度(Lo)がある。

2.シリアルデータの分析
 これが一番困った。どうもSeiko DPU-414 printerが前提らしい。そのマニュアルを探したが、和文だと登録が必要なようで英文なら見つかった。どうもEscapeでグラフィックを送信しているようだ。
 そこでまずは使用されているEscapeをDumpするものを作成した。
<解析結果>
高解像度(Hi):ESC+^,ESC+K,ESC+J
低解像度(Lo):ESC+K,ESC+J
のようだ。なのでESC+^,ESC+K,ESC+Jを作成すれば良い。(HPにも記載あり)
これをマニュアルで見ると
ESC+ ”K” +n1+n2
Set single-density bit -image graphics mode
ESC + ”^” +m+n1+n2
Set vertical double-, or quadruple-density bit-image graphics mode
ESC+ ”J” +n
Line feed in half dots
となっている。
・ESC+ ”K” +n1+n2
はESC+ ”K”の後の2Byteを読み取りn2*256+n1Byteのイメージデータがあることを示している。
・ESC + ”^” +m+n1+n2
はESC + ”^”の後の1Byteがmで、これは0x01が来るようだ。ここではまったが、その前提でn2*256+n1はByteではなくWordになっている。
・ESC+ ”J” +n
はESC+ ”J” +nの後の1ByteがLFのdot数でこれは0x10が来る。
イメージのフォーマットであるがSeiko DPU-414 printerはサーマルプリンタであり、縦列が16dotではないかと思われる。また用紙サイズのせいか270度回転されて送られてくる。つまり「縦16dot,横Byte数またはWord数」というデータ列になる。また上位bitが上に来るようだ。
ESC+ ”K”の場合、縦は1Byte=8dotしかなく、これを88,77,66...bitのように2度づつ配置する。横も半分しかないので11,22,33byte...のように2度づつ配置する。
ESC+ ”^”の場合、縦は1Worde=16dotなので、これを16,15,14...bitのように配置する。横は1,2,3byte...のように配置する。送信されてくる長さはByteではなくWordになる。
ESC+ ”J”は改行なので来る都度16dot垂直描画位置を変える。
なので横のdot数というのはESC+ ”J”が来るまでのbyte数*2かword数になる。
Byte数は512で高さは282*2=564になる。

3.以上を踏まえて作ってみる。
・RS232Cのデータをprnに保存する。これは終了がわからないので5秒ほどデータが届かなければ終了とした。なので高解像度か低解像度かはprnのデータで区別できるのでアプリで設定しなくて良い。
 後Comを羅列するのではなく使っているもののみ表示したいが、以下のコンポーネントでできた。
ComPort Library Ver 4.10 - Unicode (XE) based Ver 3.1]
http://sourceforge.net/projects/comport/
 通信は19200 baud, 8 databits, no parityでこれはプリンタの仕様のmaxらしいがさすがに遅い。でもできないよりはいい。
・そのデータを上の解析に基づいて描画し、それを270度回転してbmpに保存。

アプリ。
Startを押すとデータ待ちになるのでPrintLoやPrintHiを押すと転送がはじまる。
転送がやむと(5秒間何も来ない)描画する。

以下のようなbmpができる。(ファイル名は自動連番)

高解像度ではタイトルが来ないようだ。(多分BitDataが低解像度用のものしか用意されていない?)波形はちゃんとくる。
転送は遅い。高解像度で32k低解像度で9kある。0.2KByte/S程度の転送なので高解像度で160秒低解像度で45秒かかる。でも¥900(コンバータ価格)でUSBでキャプチャーできるのは有難い。

ちゃんとUSB-SerialのCom34とかでも動いた。(^^v
これで機能としてはかなり使えるようになったと思う。

by   at 09:00  | Permalink  | Comments (0)

BenchScope(その2)

BenchScopeだが、波形をPCに取り込みたいというのがある。
これにはCDがついていてそれを入れると本体で同じ画面が立ち上がる。
接続は添付のシリアルケーブル(片方がLAN形状の特殊なもの)で接続する。
てっきりCOMポートは指定できるものだと思っていたら指定するところがない。
古いPCのCOM1につなぐとちゃんと動いた。がCOMのないPCだって存在する。

USBで接続したいところだが...。
USB-Serialが売っている。
http://akizukidenshi.com/catalog/g/gM-00557/
価格が¥15,700と本体価格に近い。
BenchScopeの記述には
PCとUSB接続する場合、USB-RS232C変換器は使用できません。
オプションのUSBインターフェース(M-00557)が必要になります。
とあるので特殊なのかもしれない。
COM1に見えれば普通のUSB-Serialでも動くかもしれないが、どういう条件を見ているのか?が定かではない。
テクトロはPCにもUSBで取り込めるし、USBメモリにも書ける。

これでは悲しいので調べてみると
Projects: BenchScope
http://www.majority.nl/projects_benchscope.htm
BENCHPRINT (20 kb, V1.1, Last updated: 2006-04-02)
ってのがあった。
BenchScopeは印刷ボタンがあって、それを押すとSeiko DPU-414 printerみたいなシリアル接続プリンタに印刷できるらしい。
でこのソフトはその信号をbmpに変換保存してくれる。ソースはVB6のものがついてくる。
でComは1-4まで使える。(VBを改造すれば増やせる?)
USB-SerialをかませてCom2でやってみたがうまく行かなかった。ただTraTermで見ていると19200bpsで何か送ってくるのでソフトのせいに思う。
でその問題は後回しにしてCom1でやってみた。画像は出るが化けていてとてもまともな画像には見えない。(TT)
仕組みを追っていくと...
BenchScopeから送られてきたデータは.prn形式で保存され、その.prnをpbmに変換し、それをbmpにするらしい。どうもその.prnが狂っているのかpbmに変換する段階でおかしくなるようだ。
同じ作者のHPにprn2pbmというのがあり、サンプルのprnが入っている。しかしなぜかこれがうまく変換できない。
・PRN-BMP9.EXEだとサンプルはうまく行くがBechScopeのものがうまくない。
・PRNOUTでも同様。(プリンタによってはうまく行かない)
・XnViewはprnはFreeではできず、PlugInの購入画面になる
まあデータの採取からやってみたほうが良さそうな気もする。

プリンタを使う場合はComの制約はないためUSB-Serialでもなんとかなるが、そこで出てくるデータを画像にできないという...。
上のものが動けばいいのだが。(ファームをUpすると動くのかもしれないが怖くてやってない。)

by   at 09:00  | Permalink  | Comments (0)

BenchScope(その1)

興味半分でBenchScopeを買った。
秋月電子で出ているが価格は改定されて多分安くなったのではないかと思われる。
¥16,600なのでかなり安くなっている。
http://akizukidenshi.com/catalog/g/gM-00433/
発売日 2003/10/06
とありかなり古いもののようだ。
スペックは...
■2チャンネル 100Ms/sサンプリング(アナログ帯域20MHz)
■6インチ 大型モノクロ液晶(320x240ピクセル)
■薄型! 奥行き70mm
■軽量! 1.35kg
■サイズ:300x138x70mm 1.35kg
となっていて、アマチュア向けには十分ではないかと思われる。
他にもアマチュア向けには
http://akizukidenshi.com/catalog/g/gK-04279/
LCDオシロスコープキット(白抜きLCDタイプ・SMD実装済)06204KPL
があり
¥4,700でお手ごろではある。
但しスペックは
■サンプリング周波数:5MHz
■アナログ周波数帯域:1MHz
で1chというのが悲しい。でも小さいのはいい。

まあテクトロもあるので不自由はしていないが、他はPC接続タイプでPCを立ち上げるのが面倒だしコタツで測定も悪くない。この価格をどう見るかはあるが、自作してもここまでにはならないし、アマチュア工作であれば十分に思えた。

早速購入してみた。
正面から。

上面から。(薄いっていうか)

で操作はボタン+ジョグダイアルで多少面倒ではあるが慣れればどうってことはない。
設定すれば次回はそれを覚えている。(当たり前か...。)

第一印象はとにかく視野角が小さいという...。
つまり正面から見ている分にはいいが、角度をつけると途端に見づらくなる。チルトの構造もあるが、安定しないのもさることながら角度が固定になる。
それ以外は「まあまあ」というか価格からすれば「お買い得」ではあるのだろう。

小さいとか軽いのはあるが、ポケットに入るわけでもなければ電池で動くわけでもない。なので持ち運びはできるが、どこでも使えるほどでもなく、Androidのより携帯性は劣る。ただ立ち上げや性能は上だ。

by   at 09:00  | Permalink  | Comments (0)

PICあれこれ

最近はArduinoばかり使っている。
結局はシリアル、LCD、SW...書くのが面倒。
レジスタすら意識しないで済むArduinoはありがたい。
どうしてもそういうコードを書きたい場合でもIDEが使えるしHexも出せる。
bootは食われるが、Writerが不要なのも大きなポイントで余分な投資が要らない。

いろいろ考えると電子工作だと...
・簡単なIO
 USB-IO2.0でいいのかも。
http://km2net.com/usb-io2.0/index.shtml
機能は落ちるが秋月でも¥1,000である。
http://akizukidenshi.com/catalog/g/gM-05131/
コンパチなものを自作した人もいる。
http://homebrew.jp/show?page=1435
なのでPIC18F14K50とWriterをもっていればできるのかも。
Androidでも動いたりする。この場合、Hostのソフトが主体になる。
勿論Arduinoでもよく、IOというよりCDC(Serial)通信になる。

・スタンドアロン
ArduinoでいいのだがLCD、SWなどが必須になる。
シールドを買ってもできるし自作してもいいが
http://strawberry-linux.com/catalog/items?code=72002
あたりをArduinoにして使うのが安い。但し
ATMEL AVRISPインシステム・プログラマー AVRISPmkII
http://akizukidenshi.com/catalog/g/gM-02582/
みたいなISPが必要。
AVRは殆どISPでやってきてPICはWriterというかソケットで書いていた。
しかしそのAKI-PICプログラマーV4はPIC18F14K50は目下書けないようだ。(TT)
だんだんそうなるのかもしれないが、ここでISPを買うのもためらわれる。
Arduinoをやると
・Writerが不要(余分な投資が要らない)
・CPUのレジスタを覚えなくてよい
 動くライブラリがそのまま使える
・Androidなどにつなげるプロジェクトが多々ある
ので「やりたいこと」に専念できる。
 問題は処理速度ぐらいだが、もともとがアクセサリなのでそう高度なものには不向きではないかと。
つまりはAVRはたまたまかISP->USB-Boot->抽象化みたいなところに進んでいて、とっつきやすい。一方のPICは種類は豊富ではあるがWriter->ISP-->USB-Bootあたりが怪しくまだ抽象化が遅れている感じがする。ホビストにはつらいかも。
開発言語に関してもAVRのほうがOpenに思える。
なので性能云々はあるのだが、開発に重点をおくのならArduinoが最短距離に思える。

話は変わるがH8やSHだとMESというのがある。
http://mes.sourceforge.jp/mes24/
これもライブラリがあってLCDなどは簡単につながるようだ。
ただこのクラスだとLinuxってのもあるので、どこまでこだわるか?みたいなものはある。中でもRaspBerryPiが名高い。
http://jp.rs-online.com/web/generalDisplay.html?id=raspberrypi
¥2,950だし、遊ぶにはもってこい。クロス環境はいるにはいるが...。
これだとTCP/IPでつなぐほうがスマートそう。省電力サーバにいいかも。

AKI-PICプログラマーV4がある。
PIC18F14K50が書けるとUSB-IOとかUSB-Blasterもどきができて面白そう。ただ電圧のせいか書けない。このためだけにプログラマを買うのも...。
・AVRでUSB-IOをつくる
http://homepage1.nifty.com/salt/USB-IO-Mini.htm
・■Altera社のUSB-Blasterとコンパチ
http://www.csun.co.jp/SHOP/200901025.html
でも同じかも。
そういえばBJTAGUSBを使うとUSB-BlasterはXilinxでも動くらしい。
http://www.tmplex.co.jp/jp/bjtagusb.html
¥2,520のシェアウェア。

by   at 09:00  | Permalink  | Comments (0)

CPLDあれこれ

オプティマイズのカメレオンUSB FX2を使ってみた。
CPLDがあって、高速なものはこうなるのだろう。
ただ一般工作として考えると敷居が高い。
いろいろ考えると、
・昔のように小さなゲート数でDIPみたいなものがない。
 時代が変わったのか...。でもあっていいような。
 高いし面倒だし、工作がやりにくい。
・開発環境が面倒
 メーカ(XilinxとかAlteraとか)によってツールは出ていて登録は必要だが無料で使える。ただPICではないが、書き込みツール(JTAG)が必要である。
 言語もVHDLとか敷居が高く情報も多くない。
というので工作でもマニア向け。
 そもそもArduinoのようなフィジカルコンピューティングに慣れると、レジスタすら覚えたくない。そこにもってくるとCPLDというのはかなり面倒。

 まず、工作が面倒なのでそういうボードを探す。
用途が決まっていないのにボードから選ぶのはおかしいがホビー用途なので、用途は後で考えることにする。
・MAX2 CPLDボード(¥1600)
http://optimize.ath.cx/max2/index.html
これはいいのだが、JTAGの書き込み機が必要。
・カメレオンUSB FX2(¥4980)
http://optimize.ath.cx/cusb_fx2/index.html
FX2から書き込みできるのでJTAG不要。但しFX2と結線されている部分がある。
・MACHXO2-1200ZE 評価ボード(¥2600)
http://akizukidenshi.com/catalog/g/gM-06174/
USBから書き込みできるのでJTAG不要。
・CPLD/MAX II EPM240ボード(¥2800)
http://www.csun.co.jp/SHOP/200901023.html
ホビーならこの程度のように思えてきた。
それ以外にも
http://www.make21.net/products/cpldpickit/index.html
で「CPLDでPICの周辺回路を作るキット」ってのがあったらしい。
これはXilinxでプリンタポート経由の書き込みができたみたいである。
ただ秋月では(もう?)販売していない模様。
XilinxのCPLDが40pinのDIPになっているみたいなので、これだけ売っても売れそうな...。
それはともかく、こういうXilinxがなかったのは時代かしら?AlteraのMAX2が多く、Latticeが1種。

開発環境は
Xilinx:ISE Web Pack
Altera:Quartus 2
Lattice:Diamond
になる。JTAGのライターも各社のIDEでサポートが決まっている模様。
例えばAlteraのUSB-Blasterは$300もする。ホビーにとっては高すぎる。

勉強するのなら
・カメレオンUSB FX2(¥4980)

・MACHXO2-1200ZE 評価ボード(¥2600)
がよさそう。JTAGが要らないわけだし、これだけで事足りる。電源もUSBの給電でOK。

もう少し本格的なのなら
・MAX2 CPLDボード(¥1600)
ではないかと。安いし供給がよさそう。

そうなると書き込みはオプティマイズに
Byte Blaster MV互換(JTAGライター)
なるものがあってKitで¥1000。
ただ今更プリンタポートはないような気がする。

調べてみると純正のUSB-Blaster以外の互換品でTerasic USB Blasterというのがある。
以下が¥7,350だった。
http://www.azumino-denshi.com/SHOP/AZOTUSBBT00R00.html?prd=google_ps&bid=56000000
もっと調べると
■Altera社のUSB-Blasterとコンパチ
http://www.csun.co.jp/SHOP/200901025.html
ってのが¥3,750でまあ射程距離にある。
自作している人もいて
http://sa89a.net/mp.cgi/ele/ub.htm
だともっと安い。
http://akizukidenshi.com/catalog/g/gK-05499/
PIC18F14K50使用USB対応超小型マイコンボード
と抵抗ぐらいでできそうだ。(但しPICWriterをもっているのなら。AKI-PICプログラマーV4はPIC18F14K50は目下書けないので要注意)
道具の道具にも¥がかかるのは余計ネックかも。

時代は変わるのかもしれないが
・MAX2 CPLDボード(¥1600)
・Altera社のUSB-Blasterとコンパチ(¥3,750)
がいいのかな?
または
・PIC18f14K50で自作

by   at 09:00  | Permalink  | Comments (0)

Nexus7(その17)

家捜ししているとオプティマイズのカメレオンUSB FX2が出てきた。
http://optimize.ath.cx/
FX2LP、MAX2は半田実装済みなので、レベル変換用TTLとシリアルROMをハンダ付けするとできる...が細かい。
環境があったので、速度測定までやってやめたような...。(^^!
350Mbyte/sほど出るので凄いというか...。
FX2のソフトはROMに書かなくてもHostからDLできるようになっている。
前のカメレオンUSBはロジアナが目玉であったが、これは用途が不明なせいか自分もそのまま放置。
どうも地デジのTSなどをそのままとれるらしいが、そちらも知識が必要な感じ。

健全に(?)MAX2のCPLDを書き換えるとOscPrimeが使えそうに思う。
http://www.osciprime.com/

http://www.osciprime.com/index.php?p=source
からソースをもってくる。
QualtusIIがあるし、ソースがVHDLなので、なんとなくそのままコンパイルしてみる。
ワーニングは出るが、そのまま通ったりする。(^^v
でPinアサインを行う。
すると...???どうも合わない。問題はFX2のSCLとSDAで、
・カメレオンUSB FX2:i2cのシリアルROMに配線
・OscPrime:CPLDに配線
となっている。(他にもFLAG[0..2]などが使われていない模様。)
OscPrimeの説明を読むと...
Additionally the latest version also includes a port of "ezusb" to upload the firmware image of the FX2 microcontroller on the go using also the latest Android USB Host API.
とあって、どうもFX2のファームは自動UpLoadらしい。
カメレオンUSB FX2のシリアルのSDAのジャンパを外して外部でCPLDに接続することになりそう。購入したばかりならシリアルROMはハンダしなくてもOKかも。
SCLとSDAはランドにも出ているのでここは楽そう。
Pinを適当に割り付けて、なんとか論理合成までは進む。
グローバルクロックの設定も行っておく。
svf(シリアルベクターファイル)もなんとかできたような。
ちゃんと動くのかどうか疑問もある。
書き込んで、AndroidでOscPrimeが認識したらいいのかしら?
まあ元気が出そうな気がする。

Pinを配置していると製作のジャンパ本数が多いのもめげるが、この他にも部品が結構足りない。
主なものは...
・OPA2889IDSO(OPアンプ)
・MAX4522(アナログスイッチでゲイン調整用)
・ADC08100MTC24(AD)
http://akizukidenshi.com/catalog/g/gI-01526/
8ビット 80MSPS ADコンバータ AD9283BRS-80
かな?
送料なども足していくと結構になりそう。
揺れ動く心にマイナーな要素が発生するとたちまち別方向に向かう。(TT)
誰かが、
・カメレオンUSB FX2用のADボード(OscPrimeもどき)の開発
・それで動くsvfの開発
でもやってくれれば...ってそれではKitになるか...。
カメレオンUSB FX2は見た目に小さくバスパワーで動くのならOscPrimeより稼動性は高そう。

でも外観も入れてBenchScopeに負けるような...。
そう思うとBenchScopeを調べたくなる。
BenchScopeはmodel 22-300で2003/10/06の発売らしい。
メーカーのWittig Test Technology, Inc.はドイツの会社らしい。
http://www.welec.de/english/start_engl_main.htm
とまだページもあるにはあるが、上の型番は古いらしく出てこない。
電池か充電で動くといいのに。
http://akizukidenshi.com/catalog/g/gM-00172/
のもあるが、画面が狭いのでAndroidも捨てがたいような...。

しかし保守の人ならともかく出先でオシロってあるのだろうか?
季節柄コタツでArduino+オシロは捨てがたいが、それならBenchScopeがいいかも。
大型コタツの方がもっといいような気もするし...。

by   at 09:00  | Permalink  | Comments (0)

Nexus7(その16)

オシロの検討。
理想系(?)を考えてみるとやはりOscPrimeたりが近い。
http://www.osciprime.com/
オープンソースなので誰でも使えるのが凄い。

思想としてはメモリはなくCPLD+Cypress EZ-USB FX2LPで動かしている。
つまりは、USBで高速に転送しデバイスで受け取ることでメモリがない。
これは結構美しかったりする。
CPLDの先にはADがあって、
✔ 2x Analogue Input @ 8bit/6Msps
✔ 3.3 MHz - 8.0 MHz Bandwidth (gain dependant)
となっている。まあ市販のオシロから見るとちょっと劣るが実用範囲。
この速度を出すにはハードが必要で
http://www.osciprime.com/index.php?p=preorder
を見ると
Customs & Taxes 269.00 CHF
とある。スイスフランのレートを1CHF=¥85とすると、¥22,865。
微妙な価格に見える。

で、これを自作できないか考えてみる。
オープンソースなので最初から自作もできるが、ICはとてもハンダできないかも。
探すと以下を見つけた。
http://optimize.ath.cx/cusb_fx2/index.html
カメレオンUSB FX2
4980円だが、製作をお願いすると+2000円。
このボードは
Cypress EZ-USB FX2LP(CY7C68013A-56) + アルテラMAX2 CPLD(EPM570T100)
で構成されている。
一方OscPrimeは
Cypress EZ-USB FX2LP(CY7C68013A-56PVXC)+ザイリンクスXC2C128VQ100
で構成されている。
つまりCPLDが異なる。
ザイリンクスXC2C128VQ100はマクロセル128でアルテラMAX2 CPLD(EPM570T100)はマクロセル440なので入るのではないかと。
高速のADは以下が使えそう。
http://akizukidenshi.com/catalog/g/gI-01526/
・8ビット 80MSPS ADコンバータ AD9283BRS-80
¥400*2
他にもあるが1万ほどでできないことはないようだ。

作業としては
・アルテラMAX2 CPLD(EPM570T100)のOscPrimeのVHDLソースを移植する。
 CPLDは長いことやってない。
ができれば、後はADをつなげば多分動きそう。
まあアンプとかあるのでもう少しは苦労するとは思うが...。

捨てがたい案なのだが、このスペックに1万かけてそこまでやるか?というのがある。
http://akizukidenshi.com/catalog/g/gK-03144/
だって5Mだし表示機もあるし小型だし。256バイトってのはちょっと悲しかったりする。
ならばポケットには入らないが...
http://akizukidenshi.com/catalog/g/gM-00433/
デジタルオシロスコープ 「BenchScope」
¥16,600(税込)
作る気がうせてしまう。
■2チャンネル 100Ms/sサンプリング(アナログ帯域20MHz)
十分かも。

って元値は57,800円らしい。(^^!
そもそも本体とRS232Cで接続するらしいが、USBにすると...
BenchScope用 USBインターフェース
http://akizukidenshi.com/catalog/g/gM-00557/
1台 ¥15,700(税込) と本体と変わらないような。
通常のUSB-Serialでは対応できないらしい。
波形を保存したいのにこれは困ったものだ。
どうもこれだけがアウトレットのような...。
http://akizukidenshi.com/catalog/g/gM-05415/
の1台 ¥34,000が妥当なのかも。

by   at 09:00  | Permalink  | Comments (0)

Nexus7(その15)

しつこくオシロのソース修正。
どうも座標計算がおかしかったので作り直した。
やはり増築でおかしくなっていたようだ。

・Androidのソース(binにapkもあり)
条件:V3.1以上でHost機能のあるもの
ダウンロード
・Androidのapkのみ
条件:V3.1以上でHost機能のあるもの
ダウンロード
変更はないが
・Arduinoのソース
条件:FTDIでシリアル->USB変換しているもの(16MHzのもの)
ダウンロード
UnoR3はインストールできるが動かない。


・FTDI_Scope
ArduinoをオシロにしてAndroidで表示するもの。
A0がCh1、A2がCh2の入力になる。転送速度は230400bpsで周波数8kHz。
Nexus7用に決めている部分がある。他の端末でも大丈夫だと思うが、描画範囲で座標が変わる。それでフレーム数も変わったりする。
Trig部分も実装しておいたが気乗りせずDebugがいい加減。それらしく動くには動く。
まあ、「ないよりはまし」程度かも。

水平の1目盛りの時間を表示するが、結構ふらつく。これは1フレームの時間を計測してそれを目盛りで割って表示する。
なのでふらつくのは
・測定誤差
・データの取りこぼし
が主原因。主に後者ではないかと思われる。
大雑把にはわかるのでこれでいいのかな?

周波数8kHzとあるが8Kspsなので測定できるのは1KHz程度だと思う。
1chにすれば4倍近くにはなると思うが、何か相対的な信号を見たいことは良くある。
特に入力vs出力を見たいのはよくあるので周波数特性はともかく2chの方が実用性はあるように思う。

その後秋月で
FTDIインターフェースモジュールUM232H
http://akizukidenshi.com/catalog/g/gM-05273/
の存在を知る。これなら高くもないかも。
実験している人。
http://www.riric.jp/electronics/works/experiment/UM232H.html
どうも自分で方式を決めて書き込んで使うらしい。非同期FIFOがいいのかな?
3.6MByteまでは確認されたらしい。
FT245RLと似ているので、そこらのAndroidソースを修正すれば動くかも。
ただこうなるとIO接続ではなく普通にBus接続したい。TXEの監視が問題ではあるが...。
オシロに特化すればH8あたりでRAMを積んだものがいいのかもしれないが...。
http://akizukidenshi.com/catalog/g/gK-02298/
などかしら?16MHzで8.4usらしいので1ch=50KHzは出るのかも。
どうせならARMでのいいわけだし。
ただArduinoのようなフィジカルコンピューティングに慣れると
・ハードを作成し
・開発環境を作成し
・レジスタ操作を覚え
...みたいな根性がなかなかわいてこない。
mBedが比較的近いと思うが、目下オシロ以外が思いつかない。
やはり「動機」が最大の情熱になる。

転送はFT245RLとかUM232Hなどでいいのかも。

Androidで遊ぶならADKになるけど、以下が遊べるかも。
マイクロチップ Starter Kit for Android (PIC24F Version)
http://akizukidenshi.com/catalog/g/gM-05308/
やはり開発ツールがないと書き込めないのか...。ここらもArduinoはうまく出来ているように思う。
同じことをするにしてもArduinoは随分敷居が低いのは確か。

by   at 09:00  | Permalink  | Comments (0)

Arudino UNO R3(その4)

Arudino UNO R3の話ではないが
・シリアルRAMはどの程度の周波数で動くのか?
というのが残っていた。

SPI-SRAMはこちら。
http://arms22.blog91.fc2.com/blog-entry-403.html
スイッチサイエンスで購入。
電源が3.3Vなので要注意。インターフェイスはコンバータが入っている。
32Kらしいので0x7FFFまでに思うが0x8000みたいなサンプルが出てくる。
0x8000=0x0000なのかしら?

そこは気にせずベンチを書く。
1024byteの書き込みで7pinがHigh、読み込みで7pinがLowなのでオシロで観測する。

#include
#include
SPISRAM myRAM(10); // CS pin
int out_pin = 7;

void setup()
{
pinMode(out_pin, OUTPUT);
digitalWrite(out_pin, LOW);

Serial.begin(115200);

SPI.begin();
SPI.setBitOrder(MSBFIRST);
SPI.setClockDivider(SPI_CLOCK_DIV2);
SPI.setDataMode(SPI_MODE0);

}

void loop()
{
int i;
digitalWrite(out_pin, HIGH);
//Byte write...
for (i = 0; i < 1024; i++){
myRAM.write(i,(byte)(i &0x00FF));
}
digitalWrite(out_pin, LOW);
//Byte read...
for (i = 0; i < 1024; i++){
myRAM.read(i);
}
}

結果はReadもWriteも25msだった。なので1Byte=24.4us。ってことは40KHzのような。
ちょっと微妙な感じ。
まあオシロに使ったとしても、40KHz以上のものは作れない。2chとすると20KHzになる。今の倍速は出そうだが...。

何もない今の方が美しいって気もする。
ってことはそれ以外の用途になるのか...。

by   at 09:00  | Permalink  | Comments (0)

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  | Permalink  | Comments (0)

Arudino UNO R3(その3)

気を取り直して次の課題に...
・ADを含めて素のArudino UNO R3でどこまでいけるのか?
であるが115200bpsでも動かないArudino UNO R3ではどうしようもなく、結局はFTDIでやってみた。
やってみるとFTDIだとどれもアプリが落ちるということはない。ってことはドライバにどこか足りない点があるのかしら?

1.転送速度の高速化
115200bps 正常動作
230400bps 正常動作
460800bps おかしな値を示す
921600bps 上よりさらにおかしな値を示す
となっていて、230400bpsあたりが限界のようだ。
で、これでやると2.5Khzが5Khzになるか?といえばそうでもない。
そもそも460800bpsとか921600bpsでも倍々になる様子もない。

2.ADの高速化
どうもADの部分がかかっているようだ。
100us=10KHzほどなのでは?違うかな?これだとどう頑張っても5KHzだ。
Arduinoは普通だと10bit保証している時間をかけているが転送が8bitなので
例えば
ADCSRA = ((1<<ADEN) | 4); //16M/16=1Mhz(max) 13us
と1MHzのクロックにすれば...。
ADCのセットアップの後にやった。
115200bpsだと、そちらがネックになってさほど効果があるようにも見えない。
ただ倍速にすると効果が出る。

またADCも割り込みであれば転送時間に隠れさせられる可能性もある。
http://garretlab.web.fc2.com/arduino/inside/arduino/wiring_analog.c/analogRead.html
を見ると割り込みは使ってない感じ。
ここに割り込みを使う手もあるが、もっと手っ取り早くは
・AD開始
・AD完了待ち
・送信開始
・送信完了待ち
みたいにせずに
...
・AD完了待ち
・送信開始
・AD開始
・送信完了待ち
・AD完了待ち
・送信開始
・AD開始
...みたいにすれば待ち時間がかなり隠されて早くなりそう。
ただArduinoは送信も割り込みになったらしいし。
これらを自前で書くことはどうも...。
全部そうすればいいのかな?追求の余地がありそう。

3.余分な時間の短縮
Serial.flush();
のあとの
delayMicroseconds(100);
は外してもOKでこれは速度があがった。(ただ少なくして残したほうがいいのかも)
エラーはbpsをあげない限りは大丈夫のようだ。

まとめ)
速度をあげていくにつれ感じも良くなるが...それでも遅いような。根源的に桁が違うというか...。
bpsをあげると多少なりとも早くなるが、今度はADが問題になる。
あまりあげてもデータがおかしくなるだけのようで230400bpsが限界の模様。
それにAndroidの受信が追いついているのか?という疑問もある。(Thread.sleepが入っているがこれが曲者かも。)

結論としては
・Arudino UNO R3は何らかの工夫が必要
 ドライバなのかもしれないが詳細不明(とりあえずは保留)
・230400bpsならFTDIでかろうじてとれている
 焼け石に水かもしれないが倍速にはなるが信頼性は不明
・ADも工夫しないと高速にはならない
 そちらは35kHzぐらいにはなるかもしれない。
 きちんとやるならArduinoのライブラリではなく自前で記述する必要がある。

今のところは最高でも4KHzのオシロって感じ。
頑張れば倍速ぐらいまでにはできるかもしれないような印象。
ただ転送に関しては、汎用的には安全をとって115200bpsの方がいいように思う。

<その後>
・通常は115200bpsとし、
 ArduinoではdelayMicroseconds(100);
 AndroidではThread.sleep
をそれぞれ削除。これで4KHzのスコープができる。
・倍速化として
 ADの高速化。元々は125KHzなのを1MHzにする。
方法1)
 arduino\hardware\arduino\cores\arduino\wiring.c
 で308行ほどの以下の2箇所をコメントアウト。
sbi(ADCSRA, ADPS2);
//sbi(ADCSRA, ADPS1);
//sbi(ADCSRA, ADPS0);
方法2)
SetupにADの設定後以下を追加。
ADCSRA = ((1<  この方がスマートでよい。分解能は8bitになる。
・転送速度を115200bpsから230400bpsにする

 とやると8KHzほどのオシロになった。2chで8KHzなので1chだと16KHzというか転送も変えれば20KHzぐらいは出るかもしれない。
 現状:転送が5KHz/chでADが5KHz/ch。総合で2chで4KHzほど
 倍速:転送が10KHz/chでADが35KHz/ch。総合で2chで8KHzほど
というのが結果。

これ以上はbpsをあげると転送がおかしくなってしまう。
Arudino UNO R3に期待したが望むべくもないのか実力不足なのか...。
やる気が一番問題かもしれない。(TT)

このあたりで挫折して一気にRAMの情熱がうせてしまった。
そのうち気を取り直せばやるかも。

by   at 09:00  | Permalink  | Comments (0)

Arudino UNO R3(その2)

次のテーマの
・Arudino UNO R3はAndroidにつながるか?
をやってみる。
まずは、そのままさすと何か反応があるかと思ったら無反応(TT)
しょうがないので自分でやってみる。

元にしたのはFTDIのもの。
http://d.hatena.ne.jp/ksksue/20111103/1320347853
https://github.com/ksksue/FTDriver

ここには汎用的なCDCクラスがある。
なのでUSBViewなどでVIDやPIDを調べる。
VID=0x2341,PID=0x0043(手持ちのもの)
bcdDeviceは1(USBViewで見える),numOfChannelsも1(多分)。

http://digital.ni.com/public.nsf/allkb/1DEC366794E3584A862570980007A73A
それでソースを修正する。
FTDriver.javaで
new UsbId(0x0000, 0x0000, 0, 1, FTDICHIPTYPE.CDC), // CDC
の下ぐらいに以下を追加。
new UsbId(0x2341, 0x0043, 1, 1, FTDICHIPTYPE.CDC), // CDC

ついでにボーレイト部分も修正する。
public static final int BAUD230400 = 230400;
の下ぐらいに以下を追加。
public static final int BAUD460800 = 460800;
public static final int BAUD921600 = 921600;

おまけでをdevice_filter.xml修正する。(<>は全角になってます。)
<usb-device vendor-id="1027" product-id="24596" />
の下ぐらいに以下を追加。
<usb-device vendor-id="9025" product-id="67" />

以上でFTSampleTermをリコンパイル。

でやってみるとちゃんとつながる。(^^)
が...115200bpsでも文字化けする。(TT)
FDTIScopeというかオシロをやってみると115200bpsでもアプリがクラッシュして立ち上がらない。FDTIだと何事もなく立ち上がる。
これも想像だが、Arudino UNO R3はAndroidだと115200bpsはきついのかもしれない。
FTSampleTermはクラッシュしないが、FDTIScopeはバイナリのストリームのせいか非常に弱い。稀に立ち上がるが、その時でも正常に描画できずかなり取りこぼしがあるようだ。

とどのつまり、FTDIの方が安定しているような気がする。恐らく水晶を変えたほうが信頼性もあがるように感じた。
どうもUSB-Serialの処理能力のような気がする。つまりATmega16U2よりはFTDIの方が処理能力が高いような...。115200bpsでもかなりきつそうな印象がある。(バイナリの連続データの場合)

by   at 09:00  | Permalink  | Comments (0)