フラッシュROMへの書き込みOK。

いよいよh8writeを使用してフラッシュROMへの書き込みです。

ここで懸念すべきはUSBシリアル・アダプタが正常に使えるかです。
シリアル・コネクタのあるPCを１台用意するべきと紹介されているくらい。
書き込めるか不安です。

①マイコンボード上のディップスイッチを書き込みモードに変更
マイコンボード上に4連のハードのスイッチがありディップスイッチと呼んでいるようです。
以下のように設定。
1 ON
2 ON
3 OFF
4 ON

②make write
フラッシュROMへの書き込みで以下のコマンドを実施するに相当。
h8write -3069 -f20 kzload.mot Com4
結論、問題なく書き込めました。

③TeraTerm用意
今回作成した「Hello World」は文字列をシリアル出力するので、動作の確認にはシリアル・ポートでの入出力を行う端末エミュレータが必要です。TeraTermをCom4で立ち上げました。

④マイコンボード上のディップスイッチをブートモードに変更
ディップスイッチを以下のように設定。
1 ON
2 OFF
3 ON
4 OFF

⑤マイコンボード上のリセットボタン押下
無事TeraTermに文字列が出ました。

h8writeで書き込むためのフォーマット変換（坂井さん推測編）

ここで公開してくれていることはとってもためになります。
http://www.saturn.dti.ne.jp/~hsakai/kozos/h8_04.html
筆者の試行錯誤の連続の様子が伺えます。

いろいろ分からないことがありますが、ここで１つ記憶しておくとしたら以下です。
（以下抜粋）
モトローラSフォーマットについて調べてみたのだけど， 実は以下のような利点がある．(uuencode形式を選択したのは，単に実装がラクそう だったから)

テキスト形式なので，回線が7bitだったらどうとかフロー制御のコードがあったら どうとか余計なことを考えなくていい．
データを受信しながらそのままメモリ上に展開する，という処理に向いている．



それと筆者坂井さんの２つのファイルフォーマットの解釈の記述は印象に残ります。
このようなことまで記述してくれることはありがたいことです。

●モトローラＳレコード形式の特徴について。
（以下抜粋）
今回ブートローダーを作っていて， 「データをバッファ上に一度読み込んでからロードアドレスに展開するのではなく， データを読み込みながら展開先を調べて直接ロードできないか？」 という疑問があった．というのは，いったんどこかのバッファに置いてから ロード先にコピーするような動作だと，処理自体は楽なのだけど，まあワーク領域と して倍のメモリを使うことになるので，今回のマイコンボードのようにRAMが少ない 場合には，問題となるからだ．(結局，今はいったんバッファに置く実装になっている ので，これは将来課題ではある)
で，上のような問題意識があったうえでフォーマットを調べていたからこそ今回 気がついたことなのだが，モトローラSフォーマットというのは，データを読み込み ながらロード先のメモリ上に直接展開するのに非常に向いている． というのは，ロード先のアドレスが先頭にあるので，まずアドレスを読んで， 後続のデータをそのアドレスの指す先に配置していけばいいからだ．うーん， きっとこういうことを考えた上で作られたフォーマットなんだろうなあ．


●ELF形式の特徴について。
（以下抜粋）
ELF形式というのも，まあモトローラSフォーマットほどやりやすくは無いが， プログラムヘッダが先頭付近にあるため，読み込みながら直接展開，ということは 原理的にはできる(プログラムヘッダがファイルの終端にあったりすると，最後まで 読まないとロード先がわからないので，直接展開は原理的に不可能)．
この記事からもわかるのだけど， ELF形式は先頭付近にプログラムヘッダ，末尾にセクションヘッダが配置されており， プログラムのロードはプログラムヘッダを参照して行われるが、リンク作業はセクションヘッダを参照して行われる． なぜこのような配置になっているのか今までとっても疑問だったのだけど， おそらくプログラムヘッダが先頭付近にあるのは上記のようにプログラムを読み込みしながら展開先に直接展開するためだ．あとセクションヘッダが終端にあるのは， これもおそらくだけど，プログラムのロード＆実行にはセクションヘッダは 必要無いので，サイズ節約のために実行形式から取り除きたい場合がある． この場合，ファイルの先頭付近にあると，そこを削除すると後続のデータの オフセットが変わってしまうため，様々なオフセット計算をやり直さなければ ならなくなってこれはそうとう面倒臭い．しかし終端にあれば，単にそれを 取り除くだけでいいからだ，と思う．





ところで、ELF形式の特徴を知った後、あるロジックを思い出した。
あそこ作った人、ELF形式を知ってそれをそのまま流用したんだろうなぁ（笑）。

h8writeで書き込むためのフォーマット変換（osstudy推測編）

「kzload」というファイルは、ELF形式というフォーマット。
クロスコンパイルや動的リンクなどに、対応するためにより良い形式を模索してELF(Executable and Linking Format)が作られたとのこと。
ELF形式の詳細は以下を参照。
http://caspar.hazymoon.jp/OpenBSD/annex/elf.html

さらに周辺知識を増やすにはこの本が評判良さそう。
http://www.amazon.co.jp/Binary-Hacks-%E2%80%95%E3%83%8F%E3%83%83%E3%82%AB%E3%83%BC%E7%A7%98%E4%BC%9D%E3%81%AE%E3%83%86%E3%82%AF%E3%83%8B%E3%83%83%E3%82%AF100%E9%81%B8-%E9%AB%98%E6%9E%97-%E5%93%B2/dp/4873112885/ref=sr_11_1?ie=UTF8&qid=1232959949&sr=11-1



h8writeはこのELF形式フォーマットは扱えないという（なんか面倒）。

そもそもh8writeでなにやるんだっけというと、H8/3069Fマイコン・ボードのフラッシュROMにファームウェアの書き込み実施。
ハードについてしっかり押さえたうえでh8writeは作られたのだろう。
http://mes.sourceforge.jp/h8/h8write.c


それじゃどうすればいいのっていうと、h8writeを使わないで他のツールを使うという展開ではなく、ELF形式フォーマットをモトローラSレコード・フォーマットというかなり長い名前のフォーマットへの変換をするとのこと。


モトローラSレコード・フォーマットを突っ込んで知りたければここを参照。
http://www.geocities.jp/chako_ratta/micon/s_format.html
「データの書き込み位置をアドレスで指定」というのがキーワードのようなのでマイコンにプログラムを書き込む位置を定義してあげる必要がありその情報を定義したファイルが必要なのだろう。
ELF形式にはフォーマットにはデータの書き込み位置をアドレスで指定するための情報はないのだろうか？


作業としては、objcopyというコマンドを利用してモトローラSレコード・フォーマットへと変換完了。(Makefile中に定義済)
objcopy -O srec kzload kzload.mot




他にもフラッシュROMにファームウェアを書き込むためのフォーマットがあるでしょと浮かんだ方にはここを参照するのがよさそう。
http://www.pastelmagic.com/tips/hexform/hexform.html
（要約）
各社いろいろなものがあったが、大御所はやはりインテルHEX形式とモトローラＳレコード形式の二つ。他にもあるけども、この二つを押さえておけばだいたい不自由しないと思う。

なんかいろいろあるようだけど、他のファームウエアに書き込むためのフォーマットではだめなのかなぁ。。


本やサイトからいろいろ推測してみましたが、そもそも本を書いた筆者はどのような試行錯誤を重ねていたのかサイトから伺うことができました。（つづく）