タイムゴルファー(造語)

UrJTAG お仕事

コードを短くするのがコードゴルファーなら，実行時間を短くするのは，タイムゴルファー．
書込み遅いのよ．秒数を短くするのよ．帯域が狭くても，レジスタビット長が長くても．

ちなみに，本文中での秒数は65536バイト書込み時のもの．

step0 : 未修正．

89秒．ダメだ．ダメすぎる．

step1 : 書込み完了フラグ検出省略

先日のコメントにあった通り，フラッシュ書込みのmax値に近い時間が，単純なアクセスでもかかっている．ということは，書込み完了を検出するのは，かなり高い確率で無駄になっているということになる．
幸い，UrJTAGのフラッシュ書きは最後にverifyを必ず行うので，書込みに失敗してもユーザは知ることができる．

やってみた．62秒．お，かなり効いた．100回連続書込み試験でも書込みミスは無いっぽい．
ただ，これは，JTAG podの転送レートとフラッシュメモリの特性を完全に把握できるときだけ使える荒技ですなぁ．
折衷案として，数回書いてみて不要だと思ったら以降チェックしない，というのはありえるかも．お，流行りの動的再構成！(違

step2 : bus_writeの最適化

これは，コードを見たほうが判り易い．

static void
bf533_stamp_bus_write( bus_t *bus, uint32_t adr, uint32_t data )
{
        part_t *p = PART;
        chain_t *chain = CHAIN;

//      printf("Writing %04X to %08X...\n", data, adr);

        select_flash( bus );
        part_set_signal( p, ARE, 1, 1 );

        setup_address( bus, adr );
        setup_data( bus, data );

#ifndef SPEED_HACK
       chain_shift_data_registers( chain, 0 );
#endif

        part_set_signal( p, AWE, 1, 0 );
        chain_shift_data_registers( chain, 0 );
        part_set_signal( p, AWE, 1, 1 );
        unselect_flash( bus );
        chain_shift_data_registers( chain, 0 );
}

SPEED_HACK で括ったところがキモ．BF533のデータシートを見ると，一回BSRを回したほうが安全な気がするけれど，そこを敢えて抜く．
結果は，48秒．やっぱりBSRのスキャンを抜くのは，ものすごく効く．
調子に乗って関数の最後にある chain_shift_data_registers を抜いてみたところ，38秒台まで短縮された．…が，安定しない．verify error になるほうが多い．残念．

step3 : cx_cmd_t のメモリプール化

先日，あまり効果がないかもと言っていた，cx_cmd_t 構造体のメモリプール化．時短が進んだ分だけ，効果が目に見えてくるかも…と思ってやってみた．
結果は，47秒．64KiBで1秒なら，本家にパッチを投げる価値はあるかも．

結果

ちょいと危ういところはあるけれども，半分にまで時短できた．やればできるものだなぁ．
それでも，ICEbear辺りを使うよりはかなり遅い．ファーム要らず/広範なターゲットに対応可能というメリットとのトレードオフだから，仕方ないとも言えなくもないのだけれどなぁ…うーむ．