このツールについて
入れ物は 4 種類、中身は同じ「番地つきのバイト列」
Intel HEX も Motorola S-record も UF2 も、言っていることは同じで *このバイトをこの番地へ* だけです。生の .bin はその前半しか持っていません。番地を捨てた状態なので、BIN 単体ではどこへ置けばいいのか誰にも分かりません。4 つのうちどれを投げ込んでも、判別はファイルの中身だけで行います。先頭 4 バイトが UF2 と改行かどうか、行頭の :、S の直後に数字が続くかどうか。拡張子は一切見ません。S-record を .hex と名づける人もいれば .s19、.s28、.srec、.mot と名づける人もいるからです。ヘッダが欠けているなどで判別を外した場合は、ファイルごとに手で指定できますし、こちらが何だと思ったかも表示します。
チェックサムが合わないときは、数字が 2 つ要る
Intel HEX を読むツールなら「この行は壊れています」まではどれも言います。*どう* 壊れているかまで言うものはほとんどありません。ここでは 2 つのバイトを並べます。行に書いてあるチェックサムと、そのレコードの中身から計算したチェックサムです。1 ビットしか違わなければ転送中に化けた線を疑えばよく、バイト数のぶんだけずれていれば手で書き換えて再計算を忘れたファイルであることがほとんどです。壊れた行が後続の行を巻き込むこともありません。5 行目が落ちても 6 行目には何の影響もないので、20 万行の中の 1 レコードが壊れても失うのはその 1 レコードだけです。構造的におかしいものにも全部名前を付けます。EOF レコードより後ろのデータ、長さの合わない番地レコード、定義されていないレコード種別。
セグメント、すき間、そして 2 つのファイルが取り合うバイト
レコードを読み終えるとセグメント、つまり開始番地と長さを持つ連続した塊にまとまり、その間の穴はサイズつきのすき間として並びます。書き込む前に見たいのはまさにこの絵です。0x0000 にブートローダ、0x8000 にアプリ、その間に 30 KB の空白があり、平坦な BIN にするならそこを何かで埋めなければならない、という絵です。1 つのファイルが同じバイトに二度書いている場合は、その範囲を黙って解決せず一覧に出します。*2 つの* ファイルが取り合っている場合は結合そのものを拒否し、衝突した範囲を両方のファイル名つきで見せます。後から読み込んだほうを勝たせる、という代替案こそが、ブートローダが黙って消えて基板が起動しなくなるまで誰も気づかない道だからです。
書き戻す
入力がどれであっても、出力はどれにでもできます。Intel HEX は 1 行あたりのバイト数を指定でき、type-04 の拡張リニアアドレスレコードを付けるかどうかも選べます。S-record は番地幅を固定できます（16 ビットなら S1/S9、24 ビットなら S2/S8、32 ビットなら S3/S7）。指定しなければ、実際に書かれる最上位のバイトが収まる一番狭い形を選びます。UF2 はペイロードサイズと family id を取り、id は公開されている family 表と突き合わせるので、打ち間違いは「基板がドラッグ&ドロップを黙って無視する」ではなく「未知の id」として出てきます。平坦な BIN はすき間を埋めるバイトを取り、既定は 0xFF です。消去済みフラッシュがそう読めるからです。処理は全部このタブの Web Worker の中で、どこにもアップロードされません。