0.5.0へアップデートしました。"BlacKOZOS"の設計方針」で始めたBlacKOZOSの作業です。BlueBootを使っていたのですが、稀に書き込みに失敗する事がわかりました。なんだろうな?」と思って設計を見返したところ、手を抜いて気にしていた部分を見つけました。0.4.0までは、ターゲット上でフラッシュロムへの書き込みがまさに終わったかどうかの確認は行なわず、ターゲット上に搭載されているフラッシュロムのデータシートに規定された書き込みにかかる最大時間をホスト側で待ってから、その次の動作に移行するという設計になっていました。イメージ図にすること以下のようになります。ホスト側の処理を台詞にすると、以下のように随分と乱暴な感じ。言うと「データシートに書かれた最大時間は待ったんだから終わってんだろ?」という話ですが、これには幾つか問題があります。常に最大時間待つので、必然的に書き込みが遅くなる。ソフトウェア上で待つという事は、必然的にバラツキを生む事になる。待つ処理に対するバラツキは、実行環境によっても異なる上、それは予想し難い。目に挙げた「最大時間待つ」問題は、実はセクタ消去にも適用していたので、のっけから劇遅な状態を生んでいました。これは本来、フラッシュロムのステータスレジスタを参照して、次の処理に移行可能か確認するようにすれば高速ですし、そもそも次の処理が失敗する可能性もなくなります。二番目に挙げた「待つ処理のバラツキ」問題は、根拠としているデータシート上の最大時間を保証できない可能性もあるという意味で大問題です。これも、先のフラッシュロムのステータスレジスタを参照してから次の処理に移行する事で解決できます。0.5.0では、プロトコルバージョンを2に変更した上で、フラッシュロムのステータス取得コマンドを追加しました。これにより、ターゲット側のブートローダも更新が必要になりましたが、これによって安定動作が得られるならば何の問題もありません。新しくflash_busyというインターフェースがflash.hに追加され、各ターゲットはこの定義に対する実装を要求されるようになります。改良版のホスト側の動作をイメージ図にするとこんな感じでしょうか?ホスト側のコントローラは、ターゲットからフラッシュロムのお仕事が完了したのか、逐次必要に応じて問い合わせるようにしました。余計な待ち時間が不要となり、従来よりも動作が高速になりました。書き込み処理の安定性が向上しました。環境に依存せずに書き込みができるようになりました。