updaterの機能を確認してみました。
１．bootloaderを別のプログラマで書き込む。すでに書き込まれています。
２．bootloaderのversionを上げる（つまり再コンパイル）準備が必要。
usbconfig.hの中味を少し替えます。
#define USB_CFG_DEVICE_NAME 'U', 'S', 'B', 'a', 'a', 'a' ＜ーーーー替える前は”USBasp”
#define USB_CFG_DEVICE_NAME_LEN 6
これを上書きします。
３．この状態でmakeで再コンパイルします。
４．avrdude-GUIを開いてusbasp=loader:にしてDevice read をします。そして、F6でusb device listを表示させます。
# 1 : bus-0:\\.\libusb0-0001--0x058f-0x6362 Desc="Generic","Mass Storage Device" serial="058F312D81B"
# 2 : bus-0:\\.\libusb0-0002--0x16c0-0x05dc Desc="www.fischl.de","USBasp" serial="7777"
５．次に再コンパイル後のupdater.hexをavrdude-GUIにドラッグして書き込みます。
６．PD7のjumperを外してresetを押し書き込んだupdaterを実行します。
７．再びjumperを付けresetを押しboot modeにします。
８．avrdude-GUIでDevice readを行い、F6でusblistをだします。
# 1 : bus-0:\\.\libusb0-0001--0x058f-0x6362 Desc="Generic","Mass Storage Device" serial="058F312D81B"
# 2 : bus-0:\\.\libusb0-0002--0x16c0-0x05dc Desc="www.fischl.de","USBaaa" serial="7777"
USBasp ーーーーー＞ USBaaa に変わりました。
この時、avrdude-GUIのProgrammer(-C)はusbasp: USBasp,を選ぶ、usbasp=loader:では Device readができません。
どうやらupdater.hexはちゃんと機能している様です。
２０１３／１／１３（日) 16:20
updater.hexの確認方法に不完全な所が有りましたのでもう一度やり直しです。
１．usbconfig.hのserial no.を ７７７７ から ７７８８ にしてコンパイル。（usbaspからusbaaaの変更はやらない）
２．コンパイル後のupdater.hexをmega168Pへbootloaderから書き込む。
３．updater.hex実行。
４．resetを押してboot modeに入りusblistで変更の確認。
bus-0:\\.\libusb0-0002--0x16c0-0x05dc Desc="www.fischl.de","USBasp" serial="7788"
serial no.は7788に変わっています。
５．avrdude-GUIのProgurammer(-C)の欄に ”usbasp=loader:”を選択します。そしてLOG窓のbus-0:\\.\libusb0-0002--0x16c0-0x05dcをコピーしてCommand line Optionに貼り付けます。下記の様に貼り付けます。
-P usb:bus-0:\\.\libusb0-0002--0x16c0-0x05dc
Device readでmega168が上記画像の様に表示されることを確認する。
５．この状態（boot mode)でled_blink.hexを書き込みます。
６．jumperを外しresetを押すとboot modeからアプリケーション実行modeになりLEDが点滅を始めます。
これでOK、updater.hexに依るboot loaderの変更が出来ました。
baerwolf san、 than you for your kindness advise and useful information.
I will review this matter.
Thanks so much.
"firmare/main.hex" is the normal bootloader, which can be uploaded via external programmer.
If you already have some working USBaspLoader on your controller, you can
use "make update" to flash the "updater"-firmware to it.
After starting this firmware on the microcontroller it will replace the
old bootloader with the new one just compiled.
The update-feature can be used on boards, where HVPP or ISP is not possible
after production anymore. (Or you just want to save trouble laying out ISP.)
Therefore you also could implement the "HAVE_SPMINTEREFACE_MAGICVALUE"-
feature, protecting your board from wrong updates for other boards.
If you have further questions, plese contact me: matrixstorm@gmx.de
はい、近々まとめを書きたいと考えております。
指定が可能になりました。
ラジオ少年さんのブログでも、補足していただければ幸いです。
＞ （updater.hex）を bootloader で書き込み後に updater を起動して自分自身の
＞ bootloader を更新する仕組みがどうしても必要になるのではないでしょうか。
これはその通りですが、その実現にはいくつかの選択肢があります。
＞ bootloader のデバッグは別次元になると考えます、デバッグになると当然、別プログラ
＞ マも必要になってくると思います。updater はデバッグの終わった bootloader の変更
＞ 内容を既存の bootloader に反映させることが目的ではないかなと感じています。
現在の実装では、動作を確認したものを書き換える機能があるだけです。完全にデバッグ
可能にすることは出来ませんが、機能の拡張などをテスト的に実装することは可能と考え
ます。
事実、irukaさんが作成された pic18spxのブートローダは、デバッグ用に利用することが
可能です。（AVRマイコンとPICマイコン、ソフトUSB、内蔵USB I/Fの違いは大きいですが）
地自信ではなく自分自身の です。
bootloaderが使われる場合は単独でセルフプログラミングを可能にする事が目的だと思います。bootloaderの更新が必要に成ったときにはboot領域にアクセスが出来るプログラム（updater.hex）をbootloaderで書き込み後にupdaterを起動して地自信のbootloaderを更新する仕組みがどうしても必要になるのではないでしょうか。
bootloaderのデバッグは別次元になると考えます、デバッグになると当然、別プログラマも必要になってくると思います。
updaterはデバッグの終わったbootloaderの変更内容を既存のbootloaderに反映させることが目的ではないかなと感じています。
そうですね、確認しました。その通りです。
他に USBaspが存在しない限り、-P によるPort指定で bus:deviceの
指定は不要で、単に 「-P usb」でOKです。
updater.hexは、以下のように通常のapplication領域で動作する一般的なプログラム
です。しかし内部コードを工夫し、実行すると内蔵のBootLoaderコードを書き換える
ようになっているようです。
BootLoaderの書き換え用のアプリですが、一度だけ実行すればBootLoader領域は
新しくなっている、という理解で間違いないようです。
＞srec_info update_usbasploader.hex -i
Format: Intel Hexadecimal (MCS-86)
Format: Intel Hexadecimal (MCS-86)
Data: 0000 - 0C0D
こうした仕組みはかなり大胆で便利に見えますが、updater.hexはBootLoaderのデバッグ
用には使えないという欠点があります。
必要があると思います。
0.. bootloader用のhex
1. updater.hex
2. 更新用のbootloader用のhex
シリアル番号を変える理由は、updater.hex は BootLoaderを書き換える専用の
アプリであり、その書き換えの成否を確認するために、動作している BootLoader
を区別する必要があるのです。
また、blink_led.hexのような一般的なアプリを書き込むのは、更新したシリアル番号
を持つBootLoaderが動作した後の作業です。
整理すると、以下の手順が必要です。
1. updater.hexを書き込む
2. updater.hexを使って、更新用の Bootloader.hexを書き込む
3. 更新した Bootloader.hexを使って、テスト用のアプリを書き込む
＞更新されたbootでアプリを書き込むとupdater.hexは消えてしまい新しく書き込んだ
＞アプリが起動する、こんな感じでは無いかと思っていますが、、、
いずれにせよ、updater.hexでは、一般的なアプリを書き込むのは厳禁です。
自分自身を書き換える事になるので、消えてしまうという単純なものではなく、どんな
内容に書き換わるかは予測できません。
私はupdater.hexはboot loaderを更新するときに１度だけ使われると考えています。
bootのファームを更新するときにupdater.hexも同時に新しくなりそれを使うことでbootのupdateが可能と云うことではないでしょうか。
更新されたbootでアプリを書き込むとupdater.hexは消えてしまい新しく書き込んだアプリが起動する、こんな感じでは無いかと思っていますが、、、
これはF6でのdeviceの確認（この場合はserial番号が変わった）とそれをコマンド ラインへコピーする行程が抜けていると云うことだと思いますが？如何ですか。
＞通常のプログラムを書き換えできるかを確認しても、updater.hexの動作を確認したことにはならないと思います。
これは前述と関わりのあることだと思います。
つまり、F6でboot loader領域の変更が実際にboot loaderに反映された上で、アプリの書き込みが出来る事を確認する必要が有ると云うことですね。
通常のアプリケーションと同一の領域に配置されるため、BLINKなどの
アプリを書き込むと、何が起きるかはわかりません。
書き込んだアプリケーションのサイズが小さければ、アプリケーションは
動作する可能性はありますが、それを書き込んだは、二度とupdater は
機能しないはずです。
ご確認ください。
＞５．この状態でled_blink.hexを書き込みます。今度はusbasp=loader:で
＞Device readが出来ます。
この状態で、通常は書き換えできないBootLoader領域を更新できるかを
確認してください。
通常のプログラムを書き換えできるかを確認しても、updater.hexの動作を
確認したことにはならないと思います。
なるほど、そう言う事ですか。それなら分かりました。シリアルを変更して同じことをやり、別アプリケーションが動作することを確認してみます。
＞上記変化では駄目ですか？下記の問題がありますから駄目は分かっているのですが。
USBaaaに変化したのは、updater.hex が動作し、updater.hex内に設定した
デバイスとして機能していることを意味します。updaterの目的は、BootLoaderを
更新することですから、これだけでは機能を確認したことにはなりません。
＞＞(2) リストされる USBasp を指定し、任意のアプリケーションを書き込み、 （更新
＞＞ された） BootLoader の動作を検証します。
＞ここで問題が出てきました。と言うのは updater で update した bootloader では
＞usbasp=loader:の Device read ができません。と言うことは新たなアプリケーション
＞が書き込めない状態です。
＞
＞別のプログラマで bootloader を書き込みどちらが悪いのか切り分ける必要があります
＞が、多分 updater に問題があるのではと思います。
USBaaaに変更すると、USBaspとは異なるデバイスとして認識されるため、USBaspとして
利用することはできません。
動作確認のためには、USBaspとして機能する updater.hexを用意し、シリアル番号を
変更した、Bootloaderファームを用意して書き込み、正常にbootloaderとして動作する
かを確認する必要があると思います。
そのためにも、[Device Read]はF6キーでデバイスを確認した後に実行する必要があります。
上記変化では駄目ですか？下記の問題がありますから駄目は分かっているのですが。
＞(2) リストされる USBaspを指定し、任意のアプリケーションを書き込み、 （更新された）BootLoaderの動作を検証します。
ここで問題が出てきました。と言うのはupdaterでupdateしたbootloaderではusbasp=loader:<Bloader>の Device readができません。
と言うことは新たなアプリケーションが書き込めない状態です。
別のプログラマでbootloaderを書き込みどちらが悪いのか切り分ける必要がありますが、多分updaterに問題があるのではと思います。
動作の確認には、直ぐに avrdude-GUIでDevice readをするのではなく、
書き込んだ BootLoaderが機能することを確認します。
(1) F6キーでUSBデバイスをリストし、USBaspの機能を確認します。
(2) リストされる USBaspを指定し、任意のアプリケーションを書き込み、
（更新された）BootLoaderの動作を検証します。
updater.hex が動作していることを確認しただけでは、動作確認したことに
はなりません。
updter.hex を書き込んで、書き込んだファームウエアでBootLoader領域
の書き換え（更新）が出来ることを確認してください。
私なら、シリアル番号を変更した ファームウェアを用意しておき、書き込み
たいと思います。