ＨＩＤａｓｐ高速化
Ｆｒｏｍ：2008-09?
Ｆｒｏｍ：ＨＩＤａｓｐ
このページは、瓶詰堂さんのＨＩＤａｓｐで実装されているＨＩＤ Ｒｅｐｏｒｔの転送速度向上について考察したものです
- 時間軸が逆になっていて、上の情報のほうが新しいです。
- 最新版アーカイブと、制作に関する説明は、ＨＩＤａｓｐのページをご覧ください。
ＨＩＤａｓｐ速度比較
- ＨＩＤａｓｐ速度比較のページをご覧ください。
AVRUSB FLOW_CONTROLの追加
AMDマザーで計測.(SiSではこれより遅いです.)
| 8kB | -d0 | read | 1.453 sec (5.637kB/s) |
| 8kB | -d0 | write & verify | 3.157 sec (2.594kB/s) |
bash-3.2$ time ./hidspx.exe -ph -d0 8kB.hex Detected device is ATmega88. Erase Flash memory. Write Flash: 8192/8192 B Verify Flash: 8192/8192 B Passed. real 0m3.157s user 0m0.015s sys 0m0.015s
bash-3.2$ time ./hidspx.exe -ph -d0 -rp >rom.hex Detected device is ATmega88. Read Flash: 8192/8192 B Passed. real 0m1.453s user 0m0.047s sys 0m0.000s
ＨＩＤ Ｒｅｐｏｒｔ送信の遅延評価
- HID Reportのパケットを受け取った後、isp書き込み時間がどの程度許されるのかを評価してみた。
- 結果
- bench2コマンドは第一引数が試行回数、第二引数が遅延係数（単位は１０μ秒）
- ＨＩＤパケットサイズは３９バイト固定。送信（ホストからデバイス宛）のみ。
- Low Speed USBパケットを８バイト受け取る毎に待ちループを呼び出している。
X:UHCI(intel i815e)>hidmon -i script AVR> bench2 100 1 hid delay write start hid delay write end, 3900 bytes/801 ms, 4868 bytes/s AVR> bench2 100 2 hid delay write start hid delay write end, 3900 bytes/791 ms, 4930 bytes/s AVR> bench2 100 3 hid delay write start hid delay write end, 3900 bytes/801 ms, 4868 bytes/s AVR> bench2 100 4 hid delay write start hid delay write end, 3900 bytes/811 ms, 4808 bytes/s AVR> bench2 100 5 hid delay write start hid delay write end, 3900 bytes/801 ms, 4868 bytes/s AVR> bench2 100 6 hid delay write start hid delay write end, 3900 bytes/801 ms, 4868 bytes/s AVR> bench2 100 7 hid delay write start hid delay write end, 3900 bytes/801 ms, 4868 bytes/s AVR> bench2 100 8 hid delay write start hid delay write end, 3900 bytes/801 ms, 4868 bytes/s AVR> bench2 100 9 hid delay write start hid delay write end, 3900 bytes/791 ms, 4930 bytes/s AVR> bench2 100 10 hid delay write start hid delay write end, 3900 bytes/802 ms, 4862 bytes/s AVR> bench2 100 20 hid delay write start hid delay write end, 3900 bytes/801 ms, 4868 bytes/s AVR> bench2 100 30 hid delay write start hid delay write end, 3900 bytes/801 ms, 4868 bytes/s AVR> bench2 100 40 hid delay write start hid delay write end, 3900 bytes/801 ms, 4868 bytes/s AVR> bench2 100 50 hid delay write start hid delay write end, 3900 bytes/801 ms, 4868 bytes/s AVR> bench2 100 60 hid delay write start hid delay write end, 3900 bytes/801 ms, 4868 bytes/s AVR> bench2 100 70 hid delay write start hid delay write end, 3900 bytes/802 ms, 4862 bytes/s AVR> bench2 100 80 hid delay write start hid delay write end, 3900 bytes/801 ms, 4868 bytes/s AVR> bench2 100 90 hid delay write start hid delay write end, 3900 bytes/1302 ms, 2995 bytes/s AVR> bench2 100 110 hid delay write start hid delay write end, 3900 bytes/1302 ms, 2995 bytes/s AVR> bench2 100 120 hid delay write start hid delay write end, 3900 bytes/1301 ms, 2997 bytes/s AVR> bench2 100 130 hid delay write start hid delay write end, 3900 bytes/1301 ms, 2997 bytes/s AVR> bench2 100 140 hid delay write start hid delay write end, 3900 bytes/1302 ms, 2995 bytes/s AVR> bench2 100 150 hid delay write start hid delay write end, 3900 bytes/1292 ms, 3018 bytes/s AVR> bench2 100 160 hid delay write start hid delay write end, 3900 bytes/1402 ms, 2781 bytes/s AVR> bench2 100 170 hid delay write start hid delay write end, 3900 bytes/1803 ms, 2163 bytes/s AVR> bench2 100 180 hid delay write start hid delay write end, 3900 bytes/1792 ms, 2176 bytes/s AVR> bench2 100 190 hid delay write start hid delay write end, 3900 bytes/1803 ms, 2163 bytes/s AVR> q Bye.
X:OHCI(SiS M671T)>hidmon -i script
AVR> bench2 100 1
hid delay write start
hid delay write end, 3900 bytes/203 ms, 19211 bytes/s
AVR> bench2 100 2
hid delay write start
hid delay write end, 3900 bytes/297 ms, 13131 bytes/s
AVR> bench2 100 3
hid delay write start
hid delay write end, 3900 bytes/296 ms, 13175 bytes/s
AVR> bench2 100 4
hid delay write start
hid delay write end, 3900 bytes/329 ms, 11854 bytes/s
AVR> bench2 100 5
hid delay write start
hid delay write end, 3900 bytes/391 ms, 9974 bytes/s
AVR> bench2 100 6
hid delay write start
hid delay write end, 3900 bytes/406 ms, 9605 bytes/s
AVR> bench2 100 7
hid delay write start
hid delay write end, 3900 bytes/453 ms, 8609 bytes/s
AVR> bench2 100 8
hid delay write start
hid delay write end, 3900 bytes/485 ms, 8041 bytes/s
AVR> bench2 100 9
hid delay write start
hid delay write end, 3900 bytes/500 ms, 7800 bytes/s
AVR> bench2 100 10
hid delay write start
hid delay write end, 3900 bytes/500 ms, 7800 bytes/s
AVR> bench2 100 20
hid delay write start
hid delay write end, 3900 bytes/797 ms, 4893 bytes/s
AVR> bench2 100 30
hid delay write start
hid delay write end, 3900 bytes/1188 ms, 3282 bytes/s
AVR> bench2 100 40
hid delay write start
hid delay write end, 3900 bytes/1563 ms, 2495 bytes/s
AVR> bench2 100 50
hid delay write start
hid delay write end, 3900 bytes/1828 ms, 2133 bytes/s
AVR> bench2 100 60
hid delay write start
hid delay write end, 3900 bytes/2203 ms, 1770 bytes/s
AVR> bench2 100 70
hid delay write start
hid delay write end, 3900 bytes/2515 ms, 1550 bytes/s
AVR> bench2 100 80
hid delay write start
hid delay write end, 3900 bytes/2844 ms, 1371 bytes/s
AVR> bench2 100 90
hid delay write start
hid delay write end, 3900 bytes/3203 ms, 1217 bytes/s
AVR> bench2 100 110
hid delay write start
hid delay write end, 3900 bytes/3875 ms, 1006 bytes/s
AVR> bench2 100 120
hid delay write start
hid delay write end, 3900 bytes/4172 ms, 934 bytes/s
AVR> bench2 100 130
hid delay write start
hid delay write end, 3900 bytes/4500 ms, 866 bytes/s
AVR> bench2 100 140
hid delay write start
hid delay write end, 3900 bytes/4796 ms, 813 bytes/s
AVR> bench2 100 150
hid delay write start
hid delay write end, 3900 bytes/5188 ms, 751 bytes/s
AVR> bench2 100 160
hid delay write start
hid delay write end, 3900 bytes/5562 ms, 701 bytes/s
AVR> bench2 100 170
hid delay write start
hid delay write end, 3900 bytes/5828 ms, 669 bytes/s
AVR> bench2 100 180
hid delay write start
hid delay write end, 3900 bytes/6188 ms, 630 bytes/s
AVR> bench2 100 190
hid delay write start
hid delay write end, 3900 bytes/6531 ms, 597 bytes/s
AVR> q
Bye.
- 結果、なんとＵＨＣＩでは１パケット毎に直後８００μ秒のＩＳＰコマンド処理時間があったとしても、コンスタントに４.８ｋＢ/秒の転送速度を保っている！
- つまり、ＨＩＤでもインターリーブの効果はあるということだ。
- 逆に、ＯＨＣＩでは８００μ秒のＩＳＰコマンド処理時間があった場合、１.３ｋＢ/秒にまで転送速度が落ちている。
- これは謎だ。
ちなみに '-d3'オプションを指定した場合のSCLKは３７５ｋＨｚなので、
- ８ビットのＳＰＩを送るのに必要な時間は２１.３３μ秒。
- ８バイトのファームウェアをページバッファにセットアップする時間はその３２倍の６８３μ秒あれば良い。
- （ＳＰＩコマンドは常に４バイト単位になっていて、１コマンドで正味データ１バイト分しか転送できない）
ファームウェアの容量削減
- senshuさんにより取り纏め頂いたhidspx-0928b.zipに対して、firmware容量の削減を 行いました。
- 機能やコンフィギュレーションは同一です。
avr-objcopy -j .text -j .data -O ihex main.elf main.hex avr-size --mcu=attiny2313 main.elf text data bss dec hex filename 2014 4 88 2106 83a main.elf
- 1988バイトは気の迷いでした。（とあるコーディングミスで最適化され機能削除されていました。）
- WinAVRのバージョンは2006-0421でビルドしていますので、最新のWinAVRではサイズが変わる（増える）かもしれません。
おまけソフト
ＳＣＫ、ＭＯＳＩのＨｉ−Ｚ化改良
- senshuさんにより取り纏め頂いたhidspx-0928.zipに対して、ＳＣＫ、ＭＯＳＩのＨｉ−Ｚ化を 行いました。
- ライターが書き込み動作を行っていないときはＳＣＫ、ＭＯＳＩをＨｉ−Ｚにします。
高速化改良その６
- address_set , page_write , isp_command を全部含んだ融合コマンドを実装しました。
- tiny2313では、かなり有効かと思われます。
- それに伴って命令セット体系に少し変更が生じました。
ソースは現在整理中です。乞うご期待。任務完了！
おまけソフト
注意
ＨＩＤｍｏｎを使用される場合は命令Fusionが使えませんので、--使えるようにしました。#define INCLUDE_FUSION 0 #define INCLUDE_MONITOR_CMD 1
でファームを作成しなおしてください。- ポートの方向初期値を適切に設定してあげてください。
たぶん、ここらで打ち止めです。
- 残りはＨＩＤｍｏｎの若干の機能強化と、汎用ＵＳＢ Ｉ/Ｏ ＤＬＬもどきの作成。
高速化改良その５
変更内容（わりと堅実路線）
- '-d<delay>' オプションのクロックをＵＳＢａｓｐに近づけるように努力しました。
- 詳細は firmware/main.c にあります。
- hidasp.c を少しリライトしました。
- デバッグ文が多くて見づらかったためです。
- メモリーを減らしました。
- -d<delay> で思いのほかメモリー使用量が増えたので、ダイエットです。
- タイマー０によるＵＳＩクロック生成は諦めました。
- うまくいく方法が見つかったらこっそり教えてください。
高速化改良その４
- 紆余曲折の末、８バイト単位でのインターリーブ転送を実施することに決定しました。
- つまり、図で書くとこんな感じ
時間軸 0mS 1mS 2mS +--------------------------+-----------------------------+------------------ ... |USB転送| |USB転送| |USB転送| +--------------------------+-----------------------------+------------------ ... |<=ISP書き込み===>| |<=ISP書き込み======>| |<=ISP書き込み
- 目標では５ｋＢ/Ｓ（但しＳＣＬＫ１ＭＨｚ弱程度を想定）
- ＳＣＬＫはタイマー０で与える。
- タイマー０のプリスケーラと分周比のペアを専用のコマンドで与える。
- ディレイオプション -d<delay> からペア値への変換表はホストＰＣ側が担当する。
さて、うまくいきますやら・・・
結論
- 駄目でした。（テストマシンはintel UHCI）
8kB -d0 read 1.862 sec (4.4kB/s) 8kB -d0 write & verify 5.368 sec (1.5kB/s)
ちなみにfirmのサイズは2048きっかりでした。
- LED,MONITORの両方削除
- アンロール削除
- vendor,productIDを１字に。
- HID Reportディスクリプタは最小限の３個(6,38,70)
そもそも５ｋＢ/Ｓは読みか書きのどちらかの速度です。
- 転送ベンチが５ｋだったので、書き＆ベリファイで５ｋも出るわけないです。
- あと、現在の実装は書き込みパケットにかなり無駄があります。（page_writeの前後の２パケットは内包可能）
コードエリアが足りません。（これは深刻・・・）
avr-size --mcu=attiny2313 main.elf text data bss dec hex filename 2034 4 59 2097 831 main.elf
- 100mSのディレイが残っていたので、差し引くと1.762 sec
- 書き込み時には無駄パケットが少し多いので、パケットをうまく統合するとreadの倍の3.6 sec 程度まで行くかもしれません。
- でも、どう頑張っても５Ｋの半分(2.5k/s)よりは出ないでしょう。
- だったら、今の最速（Ｗ＆Ｖで２Ｋ弱）をキープして、コード保守するほうが堅実なのかもしれません。
実計測結果
テストアーカイブ：hidspx-test-0925.zip
- マシン＝Athlon64 USBホスト＝VIAチップPCIカード(UHCI)
- delayループ取り払い状態（1.5MHz SCLK)
- ATmega88へ8192バイトのHEXを書き込み＆ベリファイ
bash-3.2$ time ./hidspx.exe -ph -d0 xx.hex Detected device is ATmega88. Erase Flash memory. Write Flash: 8192/8192 B Verify Flash: 8192/8192 B Passed. real 0m3.859s user 0m0.031s sys 0m0.015s
- ATmega88から8192バイトのHEXを読み込み
bash-3.2$ time ./hidspx.exe -ph -d0 -rp >a.hex Detected device is ATmega88. Read Flash: 8192/8192 B Passed. real 0m1.438s user 0m0.015s sys 0m0.000s bash-3.2$
- まとめ（テストマシンはAMD + UHCI）
- delay()ループ完全取り払い（SCLK=1.5MHz）
8kB -d0 read 1.438 sec (5.696kB/s) 8kB -d0 write & verify 3.859 sec (2.122kB/s) - 書き込みパケット数を減量（統合）すれば、write & verifyはもうすこし速くなりますので、2.5kB/sも夢ではないかもしれませんが、そのまえにコードサイズのスリム化が必要です。（どなたか挑戦しませんか、アーカイブは上記のhidspx-test-0925.zipです）
とりあえず、いい夢を見させてくれました。ありがとう＞ＵＳＢａｓｐ
ＡＶＲｂｅｎｃｈ
usbFunctionWrite()の性能テスト.
- usbFunctionWrite()内に遅延関数の呼び出しを入れる。
- どのくらい遅延すると、ホスト側の速度に影響するかのテスト.
- 0060 番地が遅延係数で 1 増えるごとに100uS
- 使い方は win32/ で
term -iscript
高速化改良その３
- たいした変更ではありませんので、ここに差分を書きます。
static uint8_t usi_trans(uint8_t data){
USIDR=data;
USISR=(1<<USIOIF);
+ if(wait==0) {
+ uchar CR0=(1<<USIWM0)|(1<<USICS1)|(1<<USITC);
+ uchar CR1=(1<<USIWM0)|(1<<USICS1)|(1<<USITC)|(1<<USICLK);
+ {
+ USICR=CR0; asm("nop"); USICR=CR1; asm("nop");
+ USICR=CR0; asm("nop"); USICR=CR1; asm("nop");
+ USICR=CR0; asm("nop"); USICR=CR1; asm("nop");
+ USICR=CR0; asm("nop"); USICR=CR1; asm("nop");
+ USICR=CR0; asm("nop"); USICR=CR1; asm("nop");
+ USICR=CR0; asm("nop"); USICR=CR1; asm("nop");
+ USICR=CR0; asm("nop"); USICR=CR1; asm("nop");
+ USICR=CR0; asm("nop"); USICR=CR1; asm("nop");
+ }
+ return USIDR;
+ }else{
do{
delay(wait);
USICR=(1<<USIWM0)|(1<<USICS1)|(1<<USICLK)|(1<<USITC);
} while(!(USISR&(1<<USIOIF)));
+ }
return USIDR;
}
bash-2.02$ time ./hidspx.exe -rp >1 Detected device is ATmega88. Read Flash: 8192/8192 B Passed. real 0m1.915s user 0m0.015s sys 0m0.000s bash-2.02$ time ./hidspx.exe 8K.hex Detected device is ATmega88. Erase Flash memory. Write Flash: 8192/8192 B Verify Flash: 8192/8192 B Passed. real 0m4.247s user 0m0.015s sys 0m0.000s
高速化改良（案のみ）
- 書き込みのみですが、３２バイトのＨＩＤ Ｒｅｐｏｒｔを送りつけられている間もＳＰＩ転送するような ソリューションが考えられます。
- 具体的には、usbFunctionWrite()で全部貯めてからＳＰＩ書き込みではなくて、８バイト貯まったＨＥＸをそのつどＳＰＩで送るといった方法です。
- 読み出しは今のところAVRUSB側にポインタと長さを渡してそれっきり、という方法でやってますのでこれも、usbFunctionReadに引っ掛けて、ちまちま読み出す、というところでしょうか。
- ただし、delayオプションが長い場合はＵＳＢ転送の足を思いっきり引っ張るような気もしています。
- readに対してだけ実際に試してみましたが、8Kのreadに1.4秒が限界でした.
高速化改良その２
- たいした変更ではありませんので、ここに差分を書きます。
static uint8_t usi_trans(uint8_t data){ USIDR=data; USISR=(1<<USIOIF); + if(wait==0) { + do{ + USICR=(1<<USIWM0)|(1<<USICS1)|(1<<USICLK)|(1<<USITC); + } while(!(USISR&(1<<USIOIF))); + return USIDR; + }else{ do{ delay(wait); USICR=(1<<USIWM0)|(1<<USICS1)|(1<<USICLK)|(1<<USITC); } while(!(USISR&(1<<USIOIF))); + } return USIDR; }
avr-objcopy -j .text -j .data -O ihex main.elf main.hex bash checksize main.elf 2048 128 ROM: 2010 bytes (data=4) RAM: 93 bytes
残りあと３８バイトとなりました。
６ＫＢ書き込み＆ベリファイ時間計測
HIDspx -ph -d<Delay> test.hex
| Delay | Time |
| -d0 | ４秒 |
| -d1 | ５秒 |
| -d4 | ８秒 |
- 計測に使用したマザーボードはSiS製です。
- マザーとHIDaspの間にはELECOM製のＵＳＢ１.１ハブが挟まっています。
ToDo:
- 時間計測コマンド(unixのtime相当)をちゃんと作る。
- 今使っているのは自作ツールで 16bit MSDOSのコード。
1993/07/09 02:33 11,682 WATCH.EXE
- 今使っているのは自作ツールで 16bit MSDOSのコード。
- そろそろＡＴｍｅｇａ８８では限界なのでＡＴｍｅｇａ６４４のボードを（書き込み時間計測のためだけに）制作する。
- Ｓｎｏｏｐｙ−Ｐｒｏを使ってＵＳＢ転送の様子を観察し、パケット送信間隔等を評価する。
なんかこう、ＡＶＲに高速に書き込むことが目的化してしまいました。笑っちゃいます。
高速化改良その１
内容
- パケットサイズのバリエーションをさらに増やしてみました。
- usbHidReportDescriptorを６種類用意して、サイズをそれぞれ、6,14,22,30,38,46 にしました。
- 但し、読み込みパケットサイズは38に留めています。（現在のところ固定）
- waitのループを瓶詰堂さんのオリジナルに戻しています(nopを消してしまいました：実は書き込み速度向上にはこれ＋オプション「-d0」が一番効きます。)
- さらに速くするには、-d0のときはdelay()を外したusi_trans()を用意するか、あるいはＨＩＤａｓｐを２０ＭＨｚ動作させる等が考えられますが、ターゲットデバイスが遅い場合は意味がありません。
ダウンロードはこちらです：hidspx-src-0920.zip
- 書き込み速度の実測値ですが、ATmega88に６ｋＢの書き込み＆ベリファイで約５秒に短縮しました。
- CMD_PEEKとCMD_POKEを追加してあります。（未デバッグ）
- また、サイズは以下の通りです。
avr-objcopy -j .text -j .data -O ihex main.elf main.hex bash checksize main.elf 2048 128 ROM: 1992 bytes (data=4) RAM: 93 bytes
追加：
- HIDsphの '-d4'オプションのほうが、こちらの '-d0'書き込みより速いのではないか疑惑
- 上記調査中です。
HIDasp高速化完了
senshu様から頂いたソースと、瓶詰堂さんのHIDaspソースをもとに 作成しました。
ディレクトリ構成
| hidspx-src/ HIDspx.exe とそのソースです。 | firmware/ AVR側のファームウェアHEXとそのソースです。
変更内容:
- HID Reportの転送をHidD_GetFeature()/HidD_SetFeature()で行うようにしました。
- usbHidReportDescriptorを４種類用意して、サイズをそれぞれ、6,14,22,30にしました。
- 変更点はたったそれだけです。
- 上位プロトコルは瓶詰堂さんのHIDaspと同じままです。
- 配線はUSBのD+,D-だけを PORTD,3,2 に変えて、他は瓶詰堂さんのHIDaspと同じです。
- usbHidReportDescriptorが異なりますので、上記exeとファームはペアでないと動作しません。
ダウンロードはこちらです：hidspx-src-0919.zip
- 期待したほど速くはなりませんでした。
- ATmega88に６ＫＢのHEXを書き込み＆ベリファイにて、所要時間６秒（ＡＭＤマザーボード）
- （後でＰｅｎｔｉｕｍ４マシンで追試しましたところ９秒でしたので、実は遅くなっただけかも・・・）
- ＵＳＢの挿抜に対しては安定です。
- コードサイズは以下のとおりです。特に縮める作業はやっていません。
avr-objcopy -j .text -j .data -O ihex main.elf main.hex bash checksize main.elf 8192 1024 ROM: 1962 bytes (data=4) RAM: 86 bytes
考察
- HID Report３０バイトの書き込みと読み出しを交互に１０００回実行してみます。
- 実行方法は、hidasp.cのソースにて、最初に４回testパケットを送る部分を改造して、３０バイトのHID Reportを送るようにします。
- ループ回数を１０００に増やします。
- hidspx.exe -ph -r を実行します。（書き込みデバイスは無くてよい）
- ＯＨＣＩのＵＳＢ付きマザーで試したところ、１０００回の試行に６秒掛かりましたが、ＵＨＣＩではその倍の１２秒でした。
- すなわち、３０バイトのＨＩＤ Ｒｅｐｏｒｔを送るのに３フレーム(OHCI)もしくは６フレーム(UHCI)掛かる計算になります。
- より正確な時間の推移を知りたい場合はSnoopy-proというＷｉｎｄｏｗｓ上のＵＳＢスニッファーを入れて、パケットをキャプチャーすると良いです。
- ３０バイト単位でただひたすら読むだけなら、10kB/s もしくは 5kB/s くらいの速度が出るはずなのに、実際にＳＰＩ転送が入るとその1/10あるいは1/5になるのは、なにか要因があるのだと思いますが、まだ追求できていません。
落穂拾い
- 配線は森芳電子さんの方法が洗練されているので、それに合わせたい。
- クロック出力をターゲットに与えることが可能になっている。
- LEDをPB2,PB3に移してあるので、TxD,RxDを使用可能になっている。（実際tiny2313ではコードを入れる空きがないけれど、同じ基板を別の用途に転用しやすい）
- 但し、D+,D-の配置がさらに変わるので、usbdrv/以下のいくつかのソースにまで手を入れなければならない。
- さらに、INT0がINT1に変わるので、最小限必要な割り込みベクタが２バイト増加する。
- AVRmonitの一部の機能(RAMやI/Oに対するPEEK/POKE命令)を組み込んで、代わりにLED制御はそっちでやる。
- すると、余ったポートにPWMを設定して昇圧回路をドライブするとか、変な付加機能をＰＣ側から好きなように実装できる。
- ＡＶＲを焼かないときでも汎用ＩＯ代わりに流用できるようになる。
- ＡＶＲを焼いた直後にターゲットをリセット起動させたり、ターゲットとＳＰＩクロス接続になっているので通信(printfデバッグ)したり出来るようになる（かも）
- 高速化したいけれど・・・。（無理かなぁ）
- すzさんの考察されているように、ＨＩＤデバイスに見せかけておいて、libusb経由でバルク転送とか。
- ファーム容量的に無理っぽいのと、けっきょくそうういったことは別のＡＶＲライターでやり尽くされているような気もする
- 自分はATtiny2313しか知らないので、そんな世界も知らない。でも見てみたいかも。
こうやって、ＡＶＲライターの種類だけが増えていくのは、なんだかむなしいなぁ
HIDasp高速化検討中
光が見えてきたので、作業記録を書いてみる。
現状
- HIDaspはWindowsAPIのReadFile()/WriteFile()によってHID Reportを転送している。
- HID Reportというのは、たとえばマウスならボタン情報、座標などを含む、固定サイズのデータだ。
- そのReportの１パケットは８バイトになっている。ReadFile()/WriteFile()に与える転送長は＋１した９を与える。
- Report_IDは０になっている。ReadFile()/WriteFile()のバッファ先頭にReport_IDを置く。
- 他の例(AVR-DoperやHIDsph)を見るとReportIDは１〜のようだ。
問題点
- Windows2000では、起動時のハンドシェークでやりとりがうまく行かず、ハングする。
- WindowsXPではＵＳＢ挿入直後だけハンドシェークをミスるが、一応無視して継続する。
- 転送速度は約１ｋＢ/秒なので、ATmega644では１分弱掛かり実用的でない。
- ATtiny2313では４秒程度なので問題なし。
改善策（案）
- まず、HID Reportの転送単位を変更する（３２バイト程度にすると効果あり）
- HIDaspのusbHidReportDescriptorをAVR-Doperベースのものに差し替える。
- これは、HID Report ID 1〜5までが定義されていて、転送サイズ(REPORT_COUNT)はそれぞれ
- (16-2),(32-2),(64-2),(128-2),(64-2) のようになっている。
- なぜ２のべき-2なのかというと、パケットの先頭にReport ID(1〜5のどれか)を入れる必要があるからだ。
- (でもそれは-1である理由にしかなってないんだけど)
- 実はキリの良い値でなければならないという理由はないがLowSpeed USBのパケット長上限は８バイトなので、総転送サイズが８の倍数になっているほうが効率が良い。
- 最後のやつだけ数列から外れているが、これはデバッグパケットらしい。
そして、HID Reportの転送にはHidD_GetFeature()/HidD_SetFeature() を使う。
- 転送サイズはREPORT_COUNT+1を与え、バッファの先頭にはReport_IDを書き込んで使う。
今日やったこと
- AVR-DoperのHidReportDescriptorを移植したAVR-USBのフレームワークを用意して、 ３２バイトパケットを単純にエコーバックするだけのファームを書く。
- そして、ホストＰＣ側から、接続を試みる。
- （senshuさんのHIDspx-srcをありがたく使わせて頂いております）
- ３１バイトのHID Reportを適当にでっちあげて Report_ID=2で送信し、そのエコーが戻ってくるのを確認。<===今日はここまで
とりあえず現状報告
avr-objcopy -j .text -j .data -O ihex main.elf main.hex bash checksize main.elf 8192 1024 ROM: 1968 bytes (data=4) RAM: 87 bytes
- 一応isp_commandまで入れた。
- AVRmonitは入れていない。
明日以降の予定
- AVRmonitをHIDベースにして、デバイスドライバ不要のやつを作ってみる。
- ベンチマーク機能があるので、ベンチマークしてみる。
- 予想では4kB/s程度。根拠は32バイトまとめて送るので。
コードサイズが余れば瓶詰さんのプロトコルを乗せてみる。すでに入っているつもり
下記の記述はＨＩＤクラスの制約を無視した考察ですので、多分に間違いを含んでおります。 （libusbを使用する場合はＯＫかもしれません。）
現在再検討中です。
千秋さんのサイトでの話題
可能性を探ってみた。
- まず、ＬｏｗＳｐｅｅｄの転送速度は、理論値１.５Ｍｂｐｓあるように見えるけれどこれは気の迷い。
- 基本、コントロール転送を使うと仮定。
- ＵＳＢでは１フレーム（１ｍＳ）に８バイトのパケットが１回送れる（あるいは受け取れる）だけなのだ。
- じゃあ８ｋＢ/秒かというと微妙なところで、コントロール転送を用いて８バイトのベンダーコマンドを送り、デバイスから８バイトのリターンを返してもらうという１回のトランザクションの時間を計測してみると、
- ＯＨＣＩでは１ｍＳで完結するがＵＨＣＩでは４ｍＳ掛かる。
- つまり、ＯＨＣＩでは１秒に８ｋＢ送って８ｋＢのリターンが得られるが、
- ＵＨＣＩではその１/４の速度（２ｋＢ/秒）まで落ちる。
- もうひとつやっかいなのがコントロール転送では８バイトの内容のうち、先頭１バイトがbmRequestTypeであり、お尻の２バイトがwLength（後続データのサイズ指定子）となっていて自由に使えない。
- つまり送出できる正味データ量は８ｋＢ/Ｓではなく５ｋＢ/Ｓになってしまうわけだ。（ＵＨＣＩではさらにその１/４）
- ＨＩＤａｓｐに限った話をすると、５バイトのうち最初の１バイトがコマンドバイトとして使われていて、正味のＳＰＩデータ送出は４バイト／フレームである。
- 但し、ＡＶＲ書き込みターゲットに対するページリードがサポートされていて、４バイトのファームウェアデータを１トランザクションで転送しているようなので、書き込み速度としては４バイト／４ｍＳ＝毎秒１ｋＢとなる。
- これを打破する手としては、１トランザクションに後続データを１６〜３２バイト付加してやって、１回のコントロール転送で１６〜３２バイト分のファームウェアデータを送りつけてやる方法だ。
- 仮に３２バイト送るとするとＵＨＣＩでは４＋４＝８フレームでおそらく完結するので、
- ３２バイト/８ｍＳ＝４ｋＢ／秒になる計算だ。
- 問題はそれらの処理を含めて２ｋＢに入るかどうかなんだな。
- かなり難しいと思う。ＧＣＣ４ではバイナリコードが肥大化する傾向があるのでＧＣＣ３ベースのＷｉｎＡＶＲを使うしかないかも。
- むしろ、千秋さんのサイトで指摘されているとおり、ｔｉｎｙ２３１３に固執するのをやめて、ＡＴｍｅｇａ８８あたりでゆったりとコードを組んだほうが正解なのかもしれない。
- でも、当サイトでは無理やりコードを縮めて２３１３に詰め込む方向にむしろ快感を感じるので、ｍｅｇａ８８は使わないだろうと思う。（嘘。手持ちのｍｅｇａ８８が少なくて、２３１３ばかりが余っているので、２３１３を使い切る方向で考えている。）
