Counter: 5482,
today: 5,
yesterday: 4
HIDaspxの感想などをレポートをここに集約します。
HIDaspxに関する感想や動作報告（2009-0806〜0808） †
なかなか報告が増えないので、googleで拾い出したものも含みます。
一つのスレッドに多数のコメントが書き込まれたため、内容を理解するのが
難しくなっていましたので、タイトルを追加し、分割を行いました。
書き込まれた方々、どうぞ、ご確認ください。
hidspxでFUSEビットを16進数で表示する方法 †
senshu (2009-08-07 (金) 15:37:07)
avrspからの利用者は、FUSEの確認に以下のコマンドをよく利用します。
> hidspx -rf
Low: 1110010
||||++++-- CKSEL[3:0] システムクロック選択
||++-- SUT[1:0] 起動時間
|+-- CKOUT (0:PB0にシステムクロックを出力)
+-- CKDIV8 クロック分周初期値 (1:1/1, 0:1/8)
High:11-11111
|||||+++-- BODLEVEL[2:0] (111:無, 110:1.8V, 101:2.7V, 100:4.3V)
||||+-- EESAVE (消去でEEPROMを 1:消去, 0:保持)
|||+-- WDTON (1:WDT通常動作, 0:WDT常時ON)
||+-- SPIEN (1:ISP禁止, 0:ISP許可) ※Parallel時のみ
|+-- DWEN (On-Chipデバッグ 1:無効, 0:有効)
+-- RSTDISBL (RESETピン 1:有効, 0:無効(PC6))
Ext: -----001
||+-- BOOTRST ※データシート参照
++-- BOOTSZ[1:0] ※データシート参照
Cal: 156
これはわかりやすいのですが、16進数への変換には不便です。なお、SPIENビットが-と
表示されているのは変更不能を意味しています。さらにhidspxでは、以下のコマンドが利用
できます。この表示行をコピー＆ペーストすれば、FUSEデータを容易に複製できます。
> hidspx -rF
DEVICE=ATmega168
### hidspx command line example ###
hidspx -qmega168 -d10 -fL0xE2 -fH0xDF -fX0xF9 ← コマンド行が表示できます。
### avrdude command line example ### ← avrdude用のコマンド行が表示できます。
avrdude -c avrdoper -P stk500v2 -p m168 -U flash:w:main.hex:i \
-u -U lfuse:w:0xe2:m -U hfuse:w:0xdf:m -U efuse:w:0xf9:m
GUIを作成することを考えている方には、以下の表示も有用です。
>hidspx -rl
Detected device is ATmega168.
ATmega168 E2:FF DF:DF F9:07 FF
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
chip名 LOW HIGH EXT LOCK の順に並び、：の右はマスク値です。
これは、GUIを作成する方には非常に便利な情報だと思います。該当のデータが
無い場合には、'--' が表示され、列の位置は固定です。
hidspxGやhidspx-GUIはこの結果を元に、動作を行っています。
マニュアル検討フォーラム †
kawana?
案が浮びました。
既にsenshuさんが、考えられたHIDaspxの感想などをレポートする場所を分離し、
ここに集約します。マニュアル修正のPageを作成するのは、どうでしょうか？
（マニュアルには、page付けその他の変更が予想されますが？）
この場所の編集補助者を担当しても良いです。勿論、編集責任者は、senshuさんです。
- senshu
重要な説明ポイントが抜けていたようです。
私(kuga)の発言をトリガーにして、hidspxにRSTの保護機能がないことに気がつき
何らかの対応が必要との判断とだったわけです。
今回のは、kugaさんのご指摘のとおりです。認識していない不具合は
改善することはできません。
この考え方は、自己弁護している様に、私には思えます。
kawanaさん、こうした言い回しは避けてください。懸命にコードを書いている人間に対する
適切な言葉とは思えません。話の経過を考慮しない書き込みは、私に限らず、改良のやる気を
削ぐものです。
なぜ、senshuさんは、われわれが不満を述べ、senshuさんが苦労して作られた
著作物の言い回しを修正出来ますでしょうか。読んだ感じを言ったまでです。
修正するのではなく、利用者の視点（例えばkawanaさん）でゼロから書いて
欲しいのです。内部を良く知る人間ではわかり易いものを書くことが難しいのです。
最小限の使い方を説明するだけなら、10ページ程度でもOKだと思います。百科辞典では
なく、利用の手引きのようなものを望んでいるのでは、という発想です。このサイト
の「新掲示板」なら、一般利用者によるファイルのアップロードも可能です。
http://www-ice.yamagata-cit.ac.jp/forum にマニュアルに関するフォーラムを
用意しました。このフォーラムでは、更新の衝突は起きませんし、2MBまでのファイルを
アップロードできます。なお、アップローダされたファイルは登録者しか閲覧できません。
登録ユーザは、自分の書いたページをワープロのようなUIで修正することもできます。
多数の参加をお待ちしております。
- kawana?
表現修正させてください。
修正するのではなく、利用者の観点（例えばkawanaさん）で書いて欲しいのです
修正---＞別の表現、言い回しの意味です。
書いて欲しいのです？
丸１冊の様に、全文を考えていますか？---＞時間的にも無理ですし、ムダと思います。
従って、ＸＸＸＸＸＸ------＞○○○○○○となると思います。
- senshu
丸１冊の様に、全文を考えていますか？
既にある程度の説明はあるので、時間の無駄といえるほどの手間は
かからないと考えています。言い回しの微修正程度では劇的な改善は
できないと思っています。
文の構成を見直し、説明や導入方法と必要な知識を整理することが必要と
考えています。
今回の機能追加の経過を考える †
senshu
実は、このページに開発の進捗を書くほうが、実際の開発よりも多くの時間を占めています。
kawanaさんも書いていましたが、ある程度の成果を出してから書いた方がブレが少なく
スムーズに開発が進んだような気もします。
このようなスタイルで進めたのは、多くの利用者の声を集約したいと思った為です。しかし、
ここに書いたことで自分の考え方を整理することができ、大いに有益でした。
- kawana?
昨日とは論調が逆で興味深いです
私は、何時も、二面性で考えています。私のクレペリンテストの分析は、相反並存性に
なっています。良く言えば、両面的に考えられる。悪く言えば、迷い易いです。
基本的には、救済を51％で支持しますが、今回は、見ない方が悪いを51％にしました。
理想的には、99％救済が良いと思います。
- kawana?
成果を出してから書いた方が？？
先に、書いたように、hidspxを使用するのが、精一杯で、とても、プログラム修正など
出来るレベルに達していません。ただ、私でしたら、開発に何を、どの様に考えるかを
言いましたが、あくまでプログラムを想像出来た上での話では有りません。決して
senshuさんの考えを左右するものでは無いので、切り捨てて下さい。
- senshu
成果を出してから書いた方が？？
これは、私自身に対するものです。kawanaさんがモールス信号の解読に関する書き込みの
時を思い出し、引き合いに出しました。どのような方法が苦労を最小限にし、成果を最大
にできるかを考えて着手します。無理な注文を受けることは無いのでご心配なく。
一方、解説書の作成は私以外でも可能（その方が望ましい）と考えており、私が書くのは
相当先のことだと思っています。（やるべきことが山積みですので）
でも、目的なくしてはDelphiなどを身に付ける事はできませんので、kanawnaさん好みの
GUIを自分でしあげるのはよい課題になると思います。やってみてはいかがですか？
- kawana?
GUIが有る事は、プログラムの見栄え、操作性を格段に向上させる手段だと思います。
私も、GUIが作成出来るレベルに成りたいと思いkumanさんのGUIを勉強しようと思い
Delphiの本を購入し、やつとkumanさんのGUIプログラムを見ることが出来る様になり
ました。（kumanさんの多大なケアを頂きまして出来ました。有難うございます。）
しかし、senshuさんが、さらに素晴らしいGUIを作成された事を知り、hidspx-GUIの知識
を少し深める事が出来ました。
正直な現在の感じは、コマンドラインを多く使用してきたので、いまいち、GUIの素晴ら
しさが実感出来ていません。hidspx-GUIの操作を学び、良く理解してから、
自分でチャレンジしてみます。
RSTDSBLの機能追加に際しては、参加すべきでなかったと思いました。
私と、そらさんとの件を逆の立場でしていたのかと、少し反省しました。
人間と言う者は、分かっている事をやんや言われると嫌なものなのですね。
私と、そらさんの場合、私は、そんなに気分を悪くしてはいません。ただ、負荷抵抗
製作で、LEDはどうして付けるのか分からないとの書き込みが有りました事、大変悲しく
思いました。モ−ルス通信のプログラム作成に邪魔になるとは、思っていず、記事を書く
必要が無い事に気が付いた事、すんさんの助言が有りましたので、中止しました。
- kawana?
私は、GUI上の機能追加は、望んでいませんでした。
GUIのメンテナンスを考えると大変な事知りませんでした。
私の書き込み時に、kugaさんと投稿の衝突がたびたび起きていました。
この事が、私の考えのごり押しに繋がった節が有ります。出来たら
この事も、少し、留意して頂けたらと思います。
今回の、コマンドラインのOption記述で誤書き込み防止、許可書き込みを可能にし
問題をクリアされた事は、最善で有ったと思います。さすが、senshuさんの見識、
プログラム技術の高さを伺う事が出来ました。素晴らしい、贈り物、有難うございます。
- senshu
GUIが有る事は、プログラムの見栄え、操作性を格段に向上させる手段だと思います。
私は、GUIに過大な期待をしておりません。今までhidspx用のGUIを用意しなかったのも
そうした理由からです。でも、基本的な使い方にも悩む書き込みが多く、その認識を
改める必要があると考えました。GUIの作成に要した時間は、hidspx自体の改良の1％
程度だと思います。このレベルのGUIの作成は、それほど難しいとは感じません。
（もちろん、avrdude-GUIが初めにあったからです。原作者のゆきのさんには大変感謝し
ています）
私は、GUI上の機能追加は、望んでいませんでした。
GUIのメンテナンスを考えると大変な事知りませんでした。
kawanaさんの一連の書き込みから、このことを読み取るのは困難です。当初に想定して
いない機能を盛り込むのはいつも場合でも大きな変更が必要です。RSTDISBLの変更に
関するものは、それに該当する変更点です。
何度も書いていますが、自分で経験してみると良く理解できます。それはプログラムで
も説明書でも同様です。要求する側ではなく、提供側になってみれば、その痛みは嫌と
いうほど実感できます。
コマンドラインを多く使用してきたので、いまいち、GUIの素晴らしさが実感出来て
いません。hidspx-GUIの操作を学び、良く理解してから、自分でチャレンジしてみます。
hidspx-GUIは、hidspxを直接、不自由なく使える人には特に必要なわけではありません。
しかし、Flashの読み出しに悩むことはありません。その為の[Save]ボタンがあるのです。
最低限の利用なら、ほとんど学習の必要がないのはhidspx-GUIの大きな利点です。
また、展開した hidspx-GUIをクリックするだけで全ての機能が利用できるという点は、
このツールの最大の利点です。USBメモリでの利用を想像してください。
私の書き込み時に、kugaさんと投稿の衝突がたびたび起きていました。
この事が、私の考えのごり押しに繋がった節が有ります。出来たら
この事も、少し、留意して頂けたらと思います。
この掲示板は、複数の書き込みが同時に発生するような、熱い議論には不向きです。
新掲示板にはこの問題はありません。そこで、熱い議論に発展するような話題は、
新掲示板で行いましょうと提案しているのです。ご検討ください。
多分、Command line Optionでも -f#??????を入力すれば、Write可と考えています。
Command Executeを使ってください。Command line Optionで指定すると、多くのボタン
操作でFUSEを書き換えてしまい、極めて危険なことになります。
今回の、コマンドラインのOption記述で誤書き込み防止、許可書き込みを可能にし
問題をクリアされた事は、最善で有ったと思います。さすが、senshuさんの見識、
プログラム技術の高さを伺う事が出来ました。素晴らしい、贈り物、有難うございます。
ご理解いただき、一安心です。最初にje1htm氏からの要望とkugaさんからの指摘を理解
した時点の数秒後に考えた内容です。その時の考えに基づいて改良作業を続けました。
多少のブレもありましたが、GUIでの手間を考えるとそれを行う気にはなりませんでした。
私はほとんどの場合、hidspxを直接使ったほうが快適です。でも、CMD利用に不慣れな
方は全く異なる印象を持つと思います。hidspx-GUIは、多くの利用者に、その使い方を
配慮して利用環境を提供する一つの工夫と考えています。そしてこれが最善だとも思って
いません。個々人が望むものを実現するには、利用者側での工夫が重要と考えます。
?（疑問符）に疑問 †
- kawana?
hidspx.exeのみ？の変更でを
hidspx.exeの変更で処置された事は、最善の処置と思います。にすべきでした。
hidpsxにRSTピン無効化チェック機能を追加 †
senshu (2009-08-07 (金) 09:11:20)
本日、hidspxコマンドにFUSE書き込み時にRSTピンを無効化する場合に確認を行う機能を
追加しました。この機能により、ISPを無効化の操作には2段階の手順が必要になります。
やや手間ですが、これにより、操作ミスによるISPの無効化を防ぐことができます。
Atmel社のAVRISPにも、同様の警告を表示する機能があるようです。
http://homepage2.nifty.com/denshiken/AVR004.html
ISPを無効にする原因のひとつに、FUSEのLow と High の勘違い、書き込みデータの
ミスタイプなどが挙げられ、手持ちに替えの無い時などに限って発生し、泣く事が多いのです。
今まで指定ミスで使えなくなったAVRマイコンは数知れず？（相当数ある）と思います。
この機構により、いくらかでも改善できれば幸いに思います。
なお、2進数による指定はわかりやすいようにみえますが、文字数が多いためにミスタイプを
起こしやすいようです。
私は、2進-16進変換は一目で変換できますが、一般の方はFuse Calcなどを併用し、16進数
表記に変換して入力するのがミスを減らす方法のひとつです。16進数表記は、元々この手の
ミスを減らすために考案された表記法です。
また、hidspxでは、従来からSPIENビットの無効化はできない仕様になっています。
使用例
> hidspx -d10 -fL0xE1 -fH0x07
Detected device is ATtiny26.
Fuse Low byte was programmed (0xE1).
WARN: RST PIN disable detected. If you hope for the writing,
Enter the -f#H0x07 option.
この時、ISPが使えなくなることを理解した上で無効化したい場合は、-f#H0x07の
オプション指定を行います。この仕組みにより、最悪の事態に陥ることなく、FUSE操作が
可能になりました。なお、クロック指定の誤りでもISP不能になりますが、HIDaspxでは
救済用の1MHzクロックを出力しているので、これをターゲットマイコンに接続すれば
ISPは可能です。
GUIでもチェックは有効 †
hidspx.exeにチェック機構を実装したので、hidspxGやhidspx-GUIからの操作時も
このチェックは有効です。書き込みを拒否したことがログ窓に表示されますので
内容を確認し、書き込み情報に誤りが無ければ、このオプション指定をコピーし、
エキスパート用のコマンド入力BOX、あるいはCMD窓でこの書き込みを実行してください。
- senshu
この変更の際に、いくつかのコードを修正したので副作用が心配です。
テストに協力していただける方には、できるだけ過酷な評価試験を行っていただきたいと
思います。
- kawana?
パッチ処理が、解らないので、実行モジュ−ルをお待ちしています。
パッチ処理で、OK見通しの後、実行モジュ−ルが作成されるのか、少し休憩に入ります
- senshu
この書き込みの直後（今朝の10時頃）に、hidspx-20090807.zipを公開しています。
ご利用ください。
- kawana?
すみません、（今朝の10時頃）に、hidspx-20090807.zipを公開をcheckしに行きませんでした。
動作を確認したチップ名 †
ATtiny2313で動作を確認しました †
- kuman?
ご連絡ありがとうございました。
hidspx.exeを0807版に入れ換えて（恐る恐る）試してみました。Tiny2313に -fh0xdf
を指定しましたが、警告のコメントがでてリセット無効化のfuseは書けませんでした。
今までは細心の注意を払っていたので間違いはありませんでしたが、これからは神経を
使わずに済みます。コマンドラインはもちろん自作のGUIでも正しく動作しています。
ありがとうございました。
- senshu
kumanさん、早速評価テストを行っていただき、感謝いたします。
このように最も基本的なhidspx.exeにこの機能を実装したことでGUIを全く変更しな
くともこのチェック機能が有効になるという利点が確認できました。複数の方から
GUIによる変更提案もありましたが、最小限の修正で最大の効果を実現する取り組みは
正しかったことが証明できました。もしGUI側で対処したのであれば、数種類のGUIを
修正する作業が必要になったのです。これは膨大なコスト（手間）です。
こうした改善の都度、思うのですが、自分の考えを伝えるのは実に難しいです。
今後も宜しくお願いいたします。
hidspx.exeのバージョンに注意が必要 †
- kuman?
コマンドラインの時は hidspx[enter] でバージョンがわかるので安心ですが、
私のGUIではわからないので古いhidspxは削除して置かねばなりません。
（幾つもが場所を変えて存在するようです。要注意）
ATtiny45でも動作を確認 †
- senshu
-ph -d1 -fh01011101入力し、Enterで WARN Message出てWriteできない
-f#H0x05でRSTbitに0をWrite出来ました。
ということで、チェックが機能しているわけですね。
ATtiny45のFUSEは以下の割り当てになっています。
01011101
Low: 76543210
||||++++-- CKSEL[3:0] システムクロック選択
||++-- SUT[1:0] 起動時間
|+-- CKOUT (0:CLKOにシステムクロックを出力)
+-- CKDIV8 クロック分周初期値 (1:1/1, 0:1/8)
00000101 --- 0x05 を書いた場合
High:76543210
|||||+++-- BODLEVEL[2:0] (111:Off, 110:1.8, 101:2.7, ...
||||+-- EESAVE (Chip消去でEEPROMを 0:保持, 1:消去)
|||+-- WDTON (WDT 0:常時ON, 1:通常)
||+-- SPIEN (1:ISP禁止, 0:ISP許可) ※HVS時のみ
|+-- DWEN (On-Chipデバッグ 1:無効, 0:有効)
+-- RSTDISBL (RESETピン 1:有効, 0:無効(PORT))
0x05を書けば、RST pinはIOに割り当てられます。
ところで、高電圧パラレルライタ(tiny45は高電圧シリアルかな？)はお持ちですね？
ISP不能になった ATtiny45を早番、回復してあげてください。
どうもお疲れ様でした。
- senshu
kawanaさんからの報告で、混乱があったので文面を整理しました。
コピー&ペースト機能を利用して、正確な報告をお願いいたします。
- kawana?
コピー&ペースト機能の利用と再読checkします。お手間おかけ致しました。
高電圧プログラミング環境を持たない方へ（お願い） †
- senshu
今回の追加機能をテストされる方で、高電圧書込みが可能なライタをお持ちで無い方は、
書込みで警告を受け、拒否される
を確認していただければOKです。
強制書込み機能については、従来から機能する（ISPが無効になる書き込み）ことが確認
できていますので、それを実施する必要はありません。
実行してISPを無効にした場合、ISPを有効にするには高電圧書き込みを利用し、
RSTDISBLのビットを無効化する必要があります。
今回の改定は、意図しないISPの無効化を避けるために機能強化を行っているので、
正しく理解したうえでテストを行ってください。
- senshu
kawanaさんのATtiny45もISP機能を復活できたようです。（安心しました）
この機能追加は、不具合の発生を抑止するためのものです。リセットピン無効化が
正しく機能するかの確認を行うことでISP機能が失われるのは本末転倒です。
- kuga?
高電圧書き込み環境を持たないユーザーが、改版プログラムの動作テストに協力し
その結果、ISP機能が失われたAVRを作り出してしまうこと。
- senshu
kugaさん、コメントをありがとうございます。
機能チェックは、誰がしているのでしょう。
私は正しく動作することを目指してコードを書いています。でも、ちょっとしたミスで
動作しないこともあるかもしれません。そこで機能することを確認して欲しいという依頼を
しました。
ただ、kawanaさんの報告から、「テスト方法を誤解し、強制書き込みを実行しAVRをISP
不能にする危険性がある」と感じました。（うまく説明するのは難しいものです）
kawanaさんへ、
私の杞憂であればよいのですが、ATtiny45をISP不能にしてからHVP環境を整備する
のは、危険かなと思ったのです。今は無事にHVPの環境が整ったようですね。
- kawana?
Ｓ＞機能するかの確認を行うことでISP機能が失われるのは本末転倒です。
Ｋ＞この機能チェック確認で、AVRのISP機能を失わせるのは本末転倒です。
（ *注意* 回復手段をお持ちでない方は、禁止解除の書き込みは、しないで下さい。）
受身表現では、意味が通りにくくなる事が有ります。
Ｓ＞整備するのは、危険かなと思ったのです。今は無事にHVPの環境が整ったようですね
Ｋ＞整備するのは、危険じゃ無くて、無理、無駄と解釈すれば、問題ないのですが。
- senshu
書き手の意図を理解していただけたようです。なお、私はこの程度の違いは書き手の個性と
理解します。
受身の表現は日本語の丁寧形の一つですが、もっと直接的に書かないと伝わらない方もいる
ことを発見しました。
アドバイスに感謝します。
- senshu
kawanaさんへ、
hidspx-GUIの問い合わせに対し回答を書きましたので、それに関するコメントを
お願いします。
AVR/HID_reports07です。
- kawana?
機能チェックは、誰がしているのでしょう。
ここで、使用した、誰は、機能チェックに協力している人を意味しています。
senshuさんでは、有りません。
これだけ、説明しているのですから、目的、RSTDSBL=0書き込みする事は、ISP機能不可
に成る事は、予想しなければならないと思います。
なんだか、今までの、論調の反転がある様に思えてきました。やはり、知らない事、
解らない事が、心配が有るものの実行してしまうのが心理の一つと思います。
蛇足ですが、ISPENbit=1を書き込み、AVRのISP機能を殺しました。ISP機能が使えない
ので、HVPPを製作しました。（この文による、意思表示は、有りません、蛇足ゆえ、
読み飛ばして下さい。知らずして、ISP機能不可の方が、ショックは大です。）
Linux, Mac版の修正計画 †
senshu (2009-08-07 (金) 05:36:22)
hidspxはWindows用とLinux, Mac OS用は異なるソースで書かれています。
つまり、Windows用を修正してもLinux用には反映されないのです。GNUなどでは
メンテナーを決めて、担当者がその対応を行うのですが、私は全てを一人で賄う
必要があります。
学生が夏季休業中とはいえ、仕事は変わりません。時間をみて、Linux版の修正に
取り組むことになりますので、ご理解をお願いいたします。
HIDaspx+hidspxのわかり易い説明書を求む †
senshu (2009-08-07 (金) 05:26:07)
HIDaspxとhidspxは組み合わせて利用するわけですが、これらを解説する文書が
不足しています。断片的な解説文書はアーカイブに含めていますが、必ずしも
読み易くないのか、上手く利用されていないと感じることも多いのです。
今までの経験から、開発者の書いた文書よりも一般の利用者が書いたものの方が
わかりやすいものになると考えます。その理由は、開発に手間取った部分の解説が
主となり、理解に時間の必要な部分を把握しにくいところが漏れやすいからです。
そこで、どなたかに「HIDaspx+hidspxの使い方」といった解説文書を作成してもらい
たいのです。自分の利用法をまとめたものと考えれば、利用者のどなたにも書いていた
だける可能性があると思っています。
AVRマイコンの入門的な利用を含めると、さらに良いのかもしれません。既にあるよ、
という場合も予想できますが、ぜひ公開をお願いいたします。
je1htmさんの希望がTriggerにはならかった理由 †
- kuga?
発言を時系列で追っていくと分かりますが、je1htmさんが希望を出されたとき、
senshuさんは勘違いをしていて、RSTの保護はすでにhidspx(avrsp)に組み込まれて
いると思っていたのです。
私(kuga)の発言をトリガーにして、hidspxにRSTの保護機能がないことに気がつき、
何らかの対応が必要との判断とだったわけです。
利用者の視点（初心者にも安全に利用できる仕組み） †
senshu (2009-08-07 (金) 05:16:03)
今回のje1htmさんの要望は、hidspxをより安全・確実に利用できるものへと進化させる
きっかけになりました。
HIDaspxには 1MHzのクロック出力機能もあるので、HIDaspxとhidspxを組み合わせて
利用する限り、高電圧パラレルライタにお世話になることはほぼなくなったと
考えます。
こうした考え方は、何度も失敗をした利用者側から出てくる自然な発想だと思います。
失敗を経験しすぎた兵（つわもの）は地雷を避ける方法を知っており、この発想は生まれ
にくいのです。
今後も利用者の視点で考えることの重要性を理解し、優れたツールに成長させたいと
思っています。
どうぞ、よろしくお願いいたします。
RSTDSBLに関するパッチを公開（添削依頼） †
senshu (2009-08-06 (木) 17:22:45)
リセットピンのI/O変更に対する警告を行うhidspxへのパッチを作成しました。
hidspx-2009-0623/src にて、WinAVRに付属する patchコマンドで以下のように
パッチを当ててください。評価用なので、パッチのみ公開します。
私の書いたコード20090623との差分ファイルです。コンパイルできなくとも、テキスト
ファイルですから、エディタなどで内容をチェックしていただければ幸いです。
hidspx-0806.zip
patch -p2 < hidspx-0806.diff
なお、RSTDSBLへの書き込みを検出した時の挙動は、スキップし他の指示を実行するのが
良いのか、その時点で即中断が良いのかについても、ご意見をいただければ幸いです。
テストの様子(ATtiny26でチェック)
>hidspx -rf
Detected device is ATtiny26.
Low: 11100001
||||++++-- CKSEL[3:0] システムクロック選択
||++-- SUT[1:0] 起動時間
|+-- CKOPT (内蔵CAP 1:なし, 0:XTAL1/XTAL2-GNDに36pF)
+-- PLLCK ※データシート参照
High:---1-111
||||+-- BODEN (1:BOD無効, 0:BOD有効)
|||+-- BODLEVEL (1:2.7V, 0:4.0V)
||+-- EESAVE (消去でEEPROMを 1:消去, 0:保持)
|+-- SPIEN (1:ISP禁止, 0:ISP許可) ※Parallel時のみ
+-- RSTDISBL (RESETピン 1:有効, 0:無効(PB7))
Cal: 161 165 155 158
基本的な使い方は変わりませんが、以下のようにRSTDSBLのプログラム指示を検出すると
以下の表示を行い、High FUSEのプログラムをスキップし、処理を終えます。
>hidspx -fH0x07
Detected device is ATtiny26.
High Fuse RSTDSBL bit program detected.
強制的にRSTDSBLのプログラムしたい場合には、以下の様に -f#Hのように#を追加す
ればHigh FUSEへのプログラムを実行します。
>hidspx -f#H0x07
Detected device is ATtiny26.
Fuse High byte was programmed (0x07).
この後は以下のようにISP不能となり、変更には高電圧パラレルライタが必要となります。
>hidspx -rf
Device connection failed.(PE)
- senshu
このテーブルの作成が全所要時間（2時間）の7割程度を占めています。これを2種類のGUIにも
適用するのは眩暈がします（笑）。
ということで、明日にでもメッセージの見直しを行い、公開したいと思います。
- kuga?
アトメル提供のXMLファイルをそのままの形で取り込めるなら話は別ですが
(最新デバイスに迅速に対応できる可能性がある）
そうでないなら、現在のソース埋め込みで問題ないように思います。
- senshu
audinさんが、rubyでAtmel社のXMLファイルから希望するテーブルを自動生成するコードを
作成されています。そのままでは hidspxには使えませんが、微修正で何とかなる感じでした。
しかし入手できるチップの関係で検証ができないので、テーブルの大幅変更は見合わせて
います。
- je1htm?
ご検討案で必要十分と思います。16進の特定ビットの1,0を判定するのは素人には無理な話
で、運を天でやっていましたが、一段と完成度の高いユーザフレンドリーなライタになりそう
で楽しみです。
AVRも使いこなしてくるとヒューズ設定の機会も多くなると思いますので、警告が出てオヨヨ!!
というケースも多いのではないでしょうか。ありがとうございます。
リセットピンのI/O変更に対する警告 †
kuga? (2009-08-06 (木) 10:13:23)
O-Family さんの掲示板で「リセットピンをI/OにするFuse変更で警告があるといい」という
希望がありました。
hidspxでガードしているはず との回答でしたが hidspxではガードしていないはずです。
hidspxでは SPIEN(直列ﾌﾟﾛｸﾞﾗﾐﾝｸﾞ許可)をガードしていますが、これの勘違いではない
でしょうか？
- senshu
私も回答を書き込み後、気になり調べようと思っていました。
SPIENと同様に、RSRDISBL(RSTピンの無効化)にすると、hidspxでのISP書き込みが
不可能になるので注意が必要な重要項目ですね。再度、ソースを確認してみます。
- kuga?
書込み前に、ザックリとですがソースは確認済みです。
SPIEN をガードするのにFuseMasksを利用しています。
意味のないFuseとして表示マスクとともに、書込み時は andを取ってSPIENを強制 LOWと
しています。
自作ではSPIENを禁止するメリットはないのでこれでいいと思いますがRSTをI/Oにするのは、
PINが不足した場合はありえるでしょう、単純に禁止はできません。
senshuの考える改善策 †
- senshu
私も avrspx.c のFusemaskの値を確認していました。
ソースでは、kugaさんの説明にある方法で「SPIENへの指定を無効」にしていますが、
RSTDSBLについては、特別な処理はなく、指定された値をそのまま書き込んでいます。
kugaさんの指摘のように、一度だけなら、こうした指定を行う可能性もあると思い
ますが、後戻りができない設定になるのを理解し、この操作を行う必要があります。
GUIツールでは、hispxを介しての対話処理は困難であり、対策はやや面倒です。
熟考していませんが、-f#H0xdf のように、意図した指定の時にのみRSTDSBLビットに書き
込みを行ない、通常指定の場合には、書込み時は RSTDSBL ビットを１（RST有効）にし、
強制 Highとするのも一案と考えています。
あるいは、こうした操作は、GUIで簡単に行う場合に誤りが起き易いと考えられることから、
GUI側でガードする方法も考えられます。でも、この方法だとサポートマイコンが増える度に
保守が必要になる欠点があります。
どういう改良が望ましいかを十分に検討する必要がありますね。
幸い、手元にSTK500があるので、RSTDSBLビットをProgramしても、復活可能です。
- kawana?
とりあえずは、第一警告Messageを出しStopさせ、再コマンド入力に行かせる。
RSTDSBL変更したばあい、SW等で急場しのぎはできないですね。Writeモ−ド上か？
でんし研さん、アイデアお持ちかも？（AVRの重ね＋RST回路一部断）
RSTDSBL変更要求の有るCHIPのみ選択変更可能とする。
- kuga?
プログラムの構造は無視して、操作性のみから考えます。
GUIの場合 RST無効のFUSE書込み操作をしようとした場合、ダイアログボックスが現れ、
警告、書込み or キャンセル選択。
コマンドラインの場合 RST無効のFUSE書込みの場合は 警告を表示して書込み実行しない。
-f#H0xdfのような特殊なコマンドで警告なしの強制書込みとする。
- senshu
GUIを変更するだけでは本質的な安全性は確保できないので、hidspx側で対処します。また、
現状のGUI側にはマイコンのデータは一切無いので、GUI側で実現するにはかなりの変更が必要
になります。
コマンドラインの場合 RST無効のFUSE書込みの場合は 警告を表示して書込み実行しない。
-f#H0xdfのような特殊なコマンドで警告なしの強制書込みとする。
この仕様なら修正は容易ですが、うまく機能するかのチェックが大変です。差分のコードを読ん
でもらって、評価するのがよいと思います。
チップデータのテーブルを再点検しましたが、RSTDSBLビットは全てのAVRマイコンにあるので
なく、比較的少ピンのマイコンに限られます。以下の約半数のAVRマイコンが対象です。
ATtiny10/11/12/15/26/261/461/861
ATtiny13/25/45/85/24/44/84/2313
ATmega8/48/48P/88/88P/168/168P/328P/325/329/3250/3290
ATmega645/649/6450/6490
ATmega325P/ATmega3250P
AT90CAN32/AT90CAN64/AT90CAN128
AT90PWM2/AT90PWM3/AT90PWM216/AT90PWM316
そこで、hidspxでは意図しないRSTDSBLの変更時はエラー検出し書き込みを行わずに終了する
仕様にします。この変更により、GUI側でも失敗の検出と表示メッセージにて誤った書き込みを
確認できます。その時、強制的に書き込む仕組みを組み込むかどうかは検討します。
通常はミスオペのことが多いので、これは行わなくともOKだと思います。
修正完了まで、今しばらくお待ちください。
GUI側の変更は考えません †
- kawana?
通常は書き込み禁止状態とし、RSTDSBは、書き込み禁止状態を表示、
（表示＝停止に成るので別の方法）
どうしても書きたい人のため、Write許可BOXにレ点記入させる。
- senshu
操作が若干複雑になり、実現も容易ではないので、私はGUIの修正を予定しておりません。
修正を行わなくとも、任意のオプションを指定しhidspxを起動できるので、-f#H0xd9の意味
がわかる方はGUIからも操作できます。
hidspxコマンドを改良し、RSTDSBLガードの機能を持たせ、手入力/GUIのどちらでも
正しく機能するパッチを作成しましたので、可能なら使ってみてください。
- kawana?
FUSE書込み前１回のみ有効で、FUSE書込み終了や他の操作で、レ点が外れ
Write許可BOXは、目立たないところに配置、マニュアルに小さく記載（きちん
と読まないと実行不可、Write許可keyword入力（RSTDSBL）後１回のみ実行で
心配はクリア出来ると思います。
- senshu
当然、時間をかければ作成可能ですので、GUIでこの操作を行いたいと感じたのであれば、
ぜひ、kawanaさんにこの機能を追加していただきたいと思います。
繰り返しますが、私はこの機能（年に1度、使うかどうかの機能です）の必要性を感じません。
それどころか、無い方がトラブルを防止できると考えています。また、この書き込みが必要な
方はCMD窓での作業が可能な方と考えます。
- kawana?
WRITEしてしまうと、ISPが機能しなくなるという事は、
Write禁止処理されていれば、90％でWriterが機能している事と
考えられないでしょうか？
ｘｘｘさんは、Writeの警告Messageが欲しいとの意と解釈しましたが。
無い方が良い機能 †
- senshu
今思いついたのですが、「SHIFTキー」+「Writeボタン」で強制ライトなら、チェックが
付いたままになる心配は かなり減ります。
私が実装するなら、こうした仕様で作成します。しかし、やるべきことが山積みなので
当分作成することはないと思います。
Readme-jの記述の修正（提案） †
kawana?
Readme-jの記述を少し修正するのは、どうでしょうか。既に検討中と思いますが。
修正出来るなら、下記も赤字記述の方が良いと思います。
1.Fuse設定の項目
ただし、外部に発振器を接続していない時にこの設定を行うと、発振器を接続するまで
ISP 方式のライタによる読み書きが出来なくなりますので、ご注意ください。
2.ISP禁止bit
このbitを変更するとISPが使用できなくなるため、Writeが禁止されています。
3.RSTDSBL
4.Fileの説明
hidspx.exe Boland C++ Ver 5.5.1でコンパイル
hidspx-GUI hidspx用のGUIフロントエンド（Visual C#で作成,*実行には、
Microsoft .NETworkFrameが必要です）
新規掲示板を開始します †
senshu (2009-08-06 (木) 06:00:42)
話題を切り替えるため、板を刷新しました。
