Senshu LAB
サイト内検索: AND検索 OR検索  


Counter: 7870, today: 2, yesterday: 5

HIDaspxの感想などをレポートをここに集約します。

HIDaspxに関する感想や動作報告(2009-0806〜0808)

なかなか報告が増えないので、googleで拾い出したものも含みます。

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? 2009-08-07 (金) 12:42:57
案が浮びました。
既にsenshuさんが、考えられたHIDaspxの感想などをレポートする場所を分離し、
ここに集約します。マニュアル修正のPageを作成するのは、どうでしょうか?
(マニュアルには、page付けその他の変更が予想されますが?)
この場所の編集補助者を担当しても良いです。勿論、編集責任者は、senshuさんです。

  • senshu 2009-08-07 (金) 13:16:13
    重要な説明ポイントが抜けていたようです。
    私(kuga)の発言をトリガーにして、hidspxにRSTの保護機能がないことに気がつき
    何らかの対応が必要との判断とだったわけです。
    今回のは、kugaさんのご指摘のとおりです。認識していない不具合は
    改善することはできません。

    この考え方は、自己弁護している様に、私には思えます。
    kawanaさん、こうした言い回しは避けてください。懸命にコードを書いている人間に対する
    適切な言葉とは思えません。話の経過を考慮しない書き込みは、私に限らず、改良のやる気を
    削ぐものです。
    なぜ、senshuさんは、われわれが不満を述べ、senshuさんが苦労して作られた
    著作物の言い回しを修正出来ますでしょうか。読んだ感じを言ったまでです。
    修正するのではなく、利用者の視点(例えばkawanaさん)でゼロから書いて
    欲しいのです。内部を良く知る人間ではわかり易いものを書くことが難しいのです。

    最小限の使い方を説明するだけなら、10ページ程度でもOKだと思います。百科辞典では
    なく、利用の手引きのようなものを望んでいるのでは、という発想です。このサイト
    の「新掲示板」なら、一般利用者によるファイルのアップロードも可能です。

    http://www-ice.yamagata-cit.ac.jp/forum にマニュアルに関するフォーラムを
    用意しました。このフォーラムでは、更新の衝突は起きませんし、2MBまでのファイルを
    アップロードできます。なお、アップローダされたファイルは登録者しか閲覧できません。
    登録ユーザは、自分の書いたページをワープロのようなUIで修正することもできます。

    多数の参加をお待ちしております。

  • kawana? 2009-08-07 (金) 13:52:04
    表現修正させてください。
    修正するのではなく、利用者の観点(例えばkawanaさん)で書いて欲しいのです
    修正--->別の表現、言い回しの意味です。
    書いて欲しいのです?
    丸1冊の様に、全文を考えていますか?--->時間的にも無理ですし、ムダと思います。
    従って、XXXXXX------>○○○○○○となると思います。
  • kawana? 2009-08-07 (金) 14:07:44
    従って、XXXXXX------>○○○○○○となると思います。
    これで、十分言い尽くしている場合は、良いのですが、
    好きな語句コンテストになる場合も有るので、
    出来るだけ、一区切りの説明を記述したほうが良いと思います。
  • senshu 2009-08-07 (金) 14:10:08
    丸1冊の様に、全文を考えていますか?
    既にある程度の説明はあるので、時間の無駄といえるほどの手間は
    かからないと考えています。言い回しの微修正程度では劇的な改善は
    できないと思っています。

    文の構成を見直し、説明や導入方法と必要な知識を整理することが必要と
    考えています。
  • kawana? 2009-08-08 (土) 20:19:13
    内部を良く知る人間ではわかり易いものを書くことが難しいのです。
    この事は、良く知っています。設計者から、開発製品のコンセプトから新技術まで
    T.T.を受けるのですが、T.T.の上手い人、下手な人がいます。
    下手な人は、聞く人のレベル設定が出来ないのではと思う事が、たまに有りました。
    今では、何処に、何が書かれているか、理解しましたので、マニュアルは、現在の
    お考えで良いと思います。
  • senshu 2009-08-08 (土) 22:36:05
    今では、何処に、何が書かれているか、理解しましたので、マニュアルは、現在の
    お考えで良いと思います。
    hidspxに説明書類は、昨年の10月頃からほとんど変更しておりません。ほぼそのまま
    保守しています。

    全てテキストファイルなので、図や写真を添えて説明が必要なものについてはPDFファ
    イルに集約しています。HIDaspxの誕生のころに比べ、機能が充実し、柔軟な使い方が
    可能になっているとは思います。

    しかし、マニュアルの評価は利用者毎にかなりの違いがあるようです。

    不満はない、何が書いてあるか理解できない、日本語とは思えない、読む気がしない、
    どれも同じマニュアルへの感想です。

    私が難しいと感じるのは、マニュアル作成に相当の時間をかけてきたのに努力が報われない
    点なのです。
    丁寧に書けば⇒冗長
    短く書けば⇒必要なことが書いていない
    正確に書けば⇒読んでもわからない
    といった具合です。

    しかも書いている自分は、現状で満足しており、何も追加しなくとも使えるますし、
    また、同じ利用者による評価も理解が進めば評価は変動します。

    そこでマニュアルの充実の必要性を感じた方(時点)に、こうしたものなら理解できると
    いうものを提案してもらいたい、と書いているわけです。

    プログラムは書けなくともわかり易い文章は書ける、という方は多数いる、と考えています。
    Linuxなどでは、ドキュメントに関する専用プロジェクトが存在しています。
    この取り組みに参加することで、気づかなかった機能を発見できる機会になると考えます。

    協力していただける方の登場を待っています。

今回の機能追加の経過を考える

senshu 2009-08-06 (木) 23:51:02
実は、このページに開発の進捗を書くほうが、実際の開発よりも多くの時間を占めています。

kawanaさんも書いていましたが、ある程度の成果を出してから書いた方がブレが少なく
スムーズに開発が進んだような気もします。

このようなスタイルで進めたのは、多くの利用者の声を集約したいと思った為です。しかし、
ここに書いたことで自分の考え方を整理することができ、大いに有益でした。

  • kawana? 2009-08-07 (金) 06:28:04
    昨日とは論調が逆で興味深いです
    私は、何時も、二面性で考えています。私のクレペリンテストの分析は、相反並存性に
    なっています。良く言えば、両面的に考えられる。悪く言えば、迷い易いです。
    基本的には、救済を51%で支持しますが、今回は、見ない方が悪いを51%にしました。
    理想的には、99%救済が良いと思います。
  • senshu 2009-08-07 (金) 06:34:29
    基本的には、救済を51%で支持しますが、今回は、見ない方が悪いを51%にしました。
    理想的には、99%救済が良いと思います。
    ご自由に。この手の議論の良し悪しを論ずる暇ははありません。でも開発ツールを利用する
    目的からすれば、自助努力が重要です。また、自助努力で得た成果があればぜひ公表ください。

    Give & Takeは、Takeではなく、Give が最初と考えています。
  • kawana? 2009-08-07 (金) 06:45:24
    成果を出してから書いた方が??
    先に、書いたように、hidspxを使用するのが、精一杯で、とても、プログラム修正など
    出来るレベルに達していません。ただ、私でしたら、開発に何を、どの様に考えるかを
    言いましたが、あくまでプログラムを想像出来た上での話では有りません。決して
    senshuさんの考えを左右するものでは無いので、切り捨てて下さい。
  • senshu 2009-08-07 (金) 07:01:11
    成果を出してから書いた方が??
    これは、私自身に対するものです。kawanaさんがモールス信号の解読に関する書き込みの
    時を思い出し、引き合いに出しました。どのような方法が苦労を最小限にし、成果を最大
    にできるかを考えて着手します。無理な注文を受けることは無いのでご心配なく。
    一方、解説書の作成は私以外でも可能(その方が望ましい)と考えており、私が書くのは
    相当先のことだと思っています。(やるべきことが山積みですので)

    でも、目的なくしてはDelphiなどを身に付ける事はできませんので、kanawnaさん好みの
    GUIを自分でしあげるのはよい課題になると思います。やってみてはいかがですか?

  • kawana? 2009-08-08 (土) 20:09:10
    GUIが有る事は、プログラムの見栄え、操作性を格段に向上させる手段だと思います。
    私も、GUIが作成出来るレベルに成りたいと思いkumanさんのGUIを勉強しようと思い
    Delphiの本を購入し、やつとkumanさんのGUIプログラムを見ることが出来る様になり
    ました。(kumanさんの多大なケアを頂きまして出来ました。有難うございます。)

    しかし、senshuさんが、さらに素晴らしいGUIを作成された事を知り、hidspx-GUIの知識
    を少し深める事が出来ました。
    正直な現在の感じは、コマンドラインを多く使用してきたので、いまいち、GUIの素晴ら
    しさが実感出来ていません。hidspx-GUIの操作を学び、良く理解してから、
    自分でチャレンジしてみます。

    RSTDSBLの機能追加に際しては、参加すべきでなかったと思いました。
    私と、そらさんとの件を逆の立場でしていたのかと、少し反省しました。
    人間と言う者は、分かっている事をやんや言われると嫌なものなのですね。
    私と、そらさんの場合、私は、そんなに気分を悪くしてはいません。ただ、負荷抵抗
    製作で、LEDはどうして付けるのか分からないとの書き込みが有りました事、大変悲しく
    思いました。モ−ルス通信のプログラム作成に邪魔になるとは、思っていず、記事を書く
    必要が無い事に気が付いた事、すんさんの助言が有りましたので、中止しました。
  • kawana? 2009-08-08 (土) 21:42:01
    私は、GUI上の機能追加は、望んでいませんでした。
    GUIのメンテナンスを考えると大変な事知りませんでした。

    私の書き込み時に、kugaさんと投稿の衝突がたびたび起きていました。
    この事が、私の考えのごり押しに繋がった節が有ります。出来たら
    この事も、少し、留意して頂けたらと思います。
    今回の、コマンドラインのOption記述で誤書き込み防止、許可書き込みを可能にし
    問題をクリアされた事は、最善で有ったと思います。さすが、senshuさんの見識、
    プログラム技術の高さを伺う事が出来ました。素晴らしい、贈り物、有難うございます。
  • kawana? 2009-08-09 (日) 06:14:08
    RSTDSBLの機能追加の処置をhidspx.exeのみで行う理由
    RESETpinをIOとして使用する方は、一般か、上級者かを区分する事は、出来ませんが、
    上級者と解釈すれば、hidspx.exeのみの変更で十分と思います。(書き込む方法が有る
    事を考えても)
    この点からも、hidspx.exeのみ?の変更で実現された事は、最善と思います。
    後で、Command line Optionでも変更可能かどうか試してみようと思います。
    多分、Command line Optionでも -f#??????を入力すれば、Write可と考えています。
    素晴らしいです。近いうちに、GUIを研究してみようと思っています。
  • senshu 2009-08-09 (日) 09:01:03
    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は、多くの利用者に、その使い方を
    配慮して利用環境を提供する一つの工夫と考えています。そしてこれが最善だとも思って
    いません。個々人が望むものを実現するには、利用者側での工夫が重要と考えます。

?(疑問符)に疑問

  • senshu 2009-08-10 (月) 05:22:10
    この点からも、hidspx.exeのみ?の変更で実現された事は、最善と思います。
    私は今回の改訂ではhidspxコマンドのみを修正したと明言しています。
    ↑の文では、なぜ?が付いているのでしょうか。

  • kawana? 2009-08-10 (月) 06:19:00
    S>hidspx.exeのみ?
    K>すみませんでした。誤解を生む?でした。今後は、?を使用しないようにします。
    K>の変更で実現された事は、最善と思います。
    この事は、私が、GUIの変更を強く要求していると、senshuさんが考えられたと思いま
    したから、述べています。衝突の件も、衝突時は、投稿の順番が代わり、senshuさんが
    しつこいと考えられる要因になっているのではとの思いからです。決してシステムを問題に
    していません。
    私も、hidspx.exeとGUIの関係を知っていたならば、senshuさんのとられた修正をしたと
    思います。最善と思いますと言いました。のみ?は、のみかどうかは、解らないがの意味に
    解釈して頂ければ幸いです。今後は、のみ?を省略します。

    この件は、senshuさんが言われている、GUIの変更は良い方法でないと言われておりました。
    その事を考えて言いました。
    また、WARN Messageは、GUIの変更では無く、Program上のMessage変更と考えていました。
    この辺に、GUIの私の考え方の認識がズレていたと思います。大変気分を悪くさせ、申し訳ありません。
  • kawana? 2009-08-10 (月) 06:26:20
    hidspx.exeのみ?の変更でを
    hidspx.exeの変更で処置された事は、最善の処置と思います。にすべきでした。
  • senshu 2009-08-10 (月) 06:39:10
    私も、hidspx.exeとGUIの関係を知っていたならば、senshuさんのとられた修正をした
    と思います。最善と思いますと言いました。
    この件に限らず、システムを理解している開発側の意見を尊重していただければ幸いです。
    利用者の希望と、その希望を実現する方法論は別物です。しかも今回は、早期に・具体的に
    その実現方法を提示しているのです。
    のみ?は、のみかどうかは、解らないがの意味に解釈して頂ければ幸いです。
    今後は、のみ?を省略します。
    一連のkawanaさんが用いてきた疑問符の意味をようやく理解しました。しかしこれは誤解の元
    と考えます。疑問を持ったのなら正確に調べてから書けばよいし、調べてもわからなければ、
    その旨書くべきだと思います。

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窓でこの書き込みを実行してください。

hidspxG-RST.png

hidspx-GUI-RST.png


  • senshu 2009-08-07 (金) 09:55:22
    この変更の際に、いくつかのコードを修正したので副作用が心配です。

    テストに協力していただける方には、できるだけ過酷な評価試験を行っていただきたいと
    思います。

  • kawana? 2009-08-07 (金) 13:33:24
    パッチ処理が、解らないので、実行モジュ−ルをお待ちしています。
    パッチ処理で、OK見通しの後、実行モジュ−ルが作成されるのか、少し休憩に入ります
  • senshu 2009-08-07 (金) 13:44:02
    この書き込みの直後(今朝の10時頃)に、hidspx-20090807.zipを公開しています。
    ご利用ください。

  • kawana? 2009-08-07 (金) 14:10:55
    すみません、(今朝の10時頃)に、hidspx-20090807.zipを公開をcheckしに行きませんでした。

動作を確認したチップ名

  • senshu 2009-08-07 (金) 15:04:58
    「エラーチェックの為にRSTピンのIO化を指定するのが怖い」、という声がありました。

    私は、ATtiny2313, tiny26, mega168, mega88で機能することを確認しました。これ
    以外の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

ATtiny2313で動作を確認しました

  • kuman? 2009-08-07 (金) 15:05:00
    ご連絡ありがとうございました。
    hidspx.exeを0807版に入れ換えて(恐る恐る)試してみました。Tiny2313に -fh0xdf
    を指定しましたが、警告のコメントがでてリセット無効化のfuseは書けませんでした。

    今までは細心の注意を払っていたので間違いはありませんでしたが、これからは神経を
    使わずに済みます。コマンドラインはもちろん自作のGUIでも正しく動作しています。
    ありがとうございました。
  • senshu 2009-08-07 (金) 15:11:41
    kumanさん、早速評価テストを行っていただき、感謝いたします。

    このように最も基本的なhidspx.exeにこの機能を実装したことでGUIを全く変更しな
    くともこのチェック機能が有効になるという利点が確認できました。複数の方から
    GUIによる変更提案もありましたが、最小限の修正で最大の効果を実現する取り組みは
    正しかったことが証明できました。もしGUI側で対処したのであれば、数種類のGUIを
    修正する作業が必要になったのです。これは膨大なコスト(手間)です。

    こうした改善の都度、思うのですが、自分の考えを伝えるのは実に難しいです。

    今後も宜しくお願いいたします。

hidspx.exeのバージョンに注意が必要

  • kuman? 2009-08-07 (金) 16:57:12
    コマンドラインの時は hidspx[enter] でバージョンがわかるので安心ですが、
    私のGUIではわからないので古いhidspxは削除して置かねばなりません。
    (幾つもが場所を変えて存在するようです。要注意)
  • senshu 2009-08-07 (金) 17:12:21
    私の作成したGUIでは、起動時に必ずバージョン表示を行うようになっています。
    今回の機能を利用するには、hidspx のAug 7 2009版以降を使う必要があります。
    hidspx (b11.2) by t.k & senshu, Borland C++ 5.5.1, Aug  7 2009
    ----
    参考まで。

  • senshu 2009-08-07 (金) 17:49:47
    kumanさんの報告にもありましたが、複数のhidspx.exeを設置している方は、
    バージョン b11.2 を利用するように徹底してください。

    b11.1以前の版では、RSTピンのチェックは行われません。

ATtiny45でも動作を確認

  • kawana? 2009-08-07 (金) 18:05:22
    ATtiny45でBASCOMで選択したProgrammer 
    hidspx-GUIのCommand BOXで
    -ph -d1 -fh01011101入力し、Enterで WARN Message出てWriteできない
    -f#H0x05でRSTbitに0をWrite出来ました。
    DOS窓で
    hidspx -ph -d1 -rf で、Device Connection Error (PE)を確認しました。
    -f#H0x05の05は、tiny45グル−プ?
  • senshu 2009-08-07 (金) 18:14:02
    -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を早番、回復してあげてください。
    どうもお疲れ様でした。
  • kuga? 2009-08-07 (金) 18:40:25
    -ph -d1 -fH01011101入力し、Enterで
    最上位のRSTDISBLが0なので WARN が出るのは正しい。
    正常に機能してるって事ですよ。
  • kawana? 2009-08-07 (金) 19:49:25
    また、私好みの記述です。うるせいやと思わないで下さい。
    0xxxxxxx --- bit7に0を書くことで、RESET Pinは、
    RESET機能からPORT Pinに切り替わります。(IO Pinとして動作します。)
  • senshu 2009-08-07 (金) 20:58:39
    kawanaさんからの報告で、混乱があったので文面を整理しました。
    コピー&ペースト機能を利用して、正確な報告をお願いいたします。

  • kawana? 2009-08-08 (土) 06:28:48
    コピー&ペースト機能の利用と再読checkします。お手間おかけ致しました。

高電圧プログラミング環境を持たない方へ(お願い)

  • senshu 2009-08-08 (土) 07:30:56
    今回の追加機能をテストされる方で、高電圧書込みが可能なライタをお持ちで無い方は、
    書込みで警告を受け、拒否される
    を確認していただければOKです。

    強制書込み機能については、従来から機能する(ISPが無効になる書き込み)ことが確認
    できていますので、それを実施する必要はありません。

    実行してISPを無効にした場合、ISPを有効にするには高電圧書き込みを利用し、
    RSTDISBLのビットを無効化する必要があります。

    今回の改定は、意図しないISPの無効化を避けるために機能強化を行っているので、
    正しく理解したうえでテストを行ってください。
  • senshu 2009-08-09 (日) 10:49:08
    kawanaさんのATtiny45もISP機能を復活できたようです。(安心しました)

    この機能追加は、不具合の発生を抑止するためのものです。リセットピン無効化が
    正しく機能するかの確認を行うことでISP機能が失われるのは本末転倒です。
  • kawana? 2009-08-09 (日) 20:04:59
    機能するかの確認を行うことでISP機能が失われるのは本末転倒です。
    K>意味理解できません。
    機能チェックは、誰がしているのでしょう。RSTDISBL=0書き込みは、不注意ミス
    or承知で書き換えだと思います(ISP機能が失われるなんて知らなかったと言う事
    は有るでしょう)
  • kuga? 2009-08-09 (日) 20:14:06
    高電圧書き込み環境を持たないユーザーが、改版プログラムの動作テストに協力し
    その結果、ISP機能が失われたAVRを作り出してしまうこと。
  • senshu 2009-08-09 (日) 21:37:47
    kugaさん、コメントをありがとうございます。
    機能チェックは、誰がしているのでしょう。
    私は正しく動作することを目指してコードを書いています。でも、ちょっとしたミスで
    動作しないこともあるかもしれません。そこで機能することを確認して欲しいという依頼を
    しました。

    ただ、kawanaさんの報告から、「テスト方法を誤解し、強制書き込みを実行しAVRをISP
    不能にする危険性がある」と感じました。(うまく説明するのは難しいものです)

    kawanaさんへ、
    私の杞憂であればよいのですが、ATtiny45をISP不能にしてからHVP環境を整備する
    のは、危険かなと思ったのです。今は無事にHVPの環境が整ったようですね。

  • kawana? 2009-08-10 (月) 02:32:14
    S>機能するかの確認を行うことでISP機能が失われるのは本末転倒です。
    K>この機能チェック確認で、AVRのISP機能を失わせるのは本末転倒です。
    ( *注意* 回復手段をお持ちでない方は、禁止解除の書き込みは、しないで下さい。)
    受身表現では、意味が通りにくくなる事が有ります。

    S>整備するのは、危険かなと思ったのです。今は無事にHVPの環境が整ったようですね
    K>整備するのは、危険じゃ無くて、無理、無駄と解釈すれば、問題ないのですが。
  • senshu 2009-08-10 (月) 04:20:16
    書き手の意図を理解していただけたようです。なお、私はこの程度の違いは書き手の個性と
    理解します。

    受身の表現は日本語の丁寧形の一つですが、もっと直接的に書かないと伝わらない方もいる
    ことを発見しました。

    アドバイスに感謝します。

  • senshu 2009-08-10 (月) 04:44:45
    kawanaさんへ、

    hidspx-GUIの問い合わせに対し回答を書きましたので、それに関するコメントを
    お願いします。

    AVR/HID_reports07です。


  • kawana? 2009-08-10 (月) 08:18:44
    機能チェックは、誰がしているのでしょう。
    ここで、使用した、誰は、機能チェックに協力している人を意味しています。
    senshuさんでは、有りません。

    これだけ、説明しているのですから、目的、RSTDSBL=0書き込みする事は、ISP機能不可
    に成る事は、予想しなければならないと思います。
    なんだか、今までの、論調の反転がある様に思えてきました。やはり、知らない事、
    解らない事が、心配が有るものの実行してしまうのが心理の一つと思います。

    蛇足ですが、ISPENbit=1を書き込み、AVRのISP機能を殺しました。ISP機能が使えない
    ので、HVPPを製作しました。(この文による、意思表示は、有りません、蛇足ゆえ、
    読み飛ばして下さい。知らずして、ISP機能不可の方が、ショックは大です。)
  • senshu 2009-08-10 (月) 09:08:34
    ここで、使用した、誰は、機能チェックに協力している人を意味しています。
    senshuさんでは、有りません。
    はい、そのつもりでコメントを書いています。何よりも、ISPを無効にしない
    ために今回の改定を行っています。これが逆の影響があるなら、繰り返し警告
    する必要があります。

    強制的なFUSE書き込みは、容易にはできないようにすべきである、という
    考えを再認識していただければ幸いです。

    以前から繰り返し書いている、[GUIで簡単にチェックできるBOXなどは付けたくない」と
    いう私の主張を理解していただけたでしょうか。

  • kawana? 2009-08-10 (月) 09:41:27
    勿論理解しております。GUIのメンテナンス上、勝手に押してしまうの意見が、有った
    時点で。

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マイコンの入門的な利用を含めると、さらに良いのかもしれません。既にあるよ、
という場合も予想できますが、ぜひ公開をお願いいたします。


  • kawana? 2009-08-07 (金) 06:00:30
    他のサイトでは、要求を書いてもこのような展開は期待できないと思います。??
    je1htmさんは、他のサイト内で要望を書いてはいますが、senshuさんとLink出来たから
    要望をsenshuさんに述べています。この経過を厳密に理解してください。

    私は、senshuさんのhidspxの仕様等、話す意図は無く、単に導入方法を聞きたかったので、
    たまたま、O-Familyさんのサイトでje1htmさんが快調に動作している様子でしたので、
    お聞きしました。この様な時の教えては、許して下さい。
    je1htmさんの回答でもsenshuさんのhidspxに書いて有りましたよの回答かも知れません。
    XXX-PDFに嫌気は、私の、怠慢と今は、思っています。
  • senshu 2009-08-07 (金) 06:20:41
    kawanaさん、おはようございます。

    この経過を厳密に理解してください。
    改良の発端は導入の話ではなく、je1htmさんからのhidspxに対する要望がキッカケに
    なった生まれたと理解しています。そして今回の改良の決定は、kugaさんの書き込み
    時点です。kugaさんの書込みが無ければ、私はこの改定を行うには至らならなかった
    と考えています。kugaさんの書込みにより問題点が明らかになり、複数の利用者が望む
    ならと何とかしたい考えたのです。

    もっと正確に書くなら、この要望が、利用者が不満を感じた時点でこのサイトに書かれたなら、
    ずっと早期に実現できたと考えます。利用者にも行動が必要と書いているのはその為です。
    願い思うだけでは伝わらないのです。

    私は、このサイト上では、多少の誤字も気にせずに、技術的なことを気兼ねなく書き込
    めるので、迅速な展開ができるのです。また、ファイル添付も可能なサイトなのでパッチ
    の迅速な公開もできたわけです。

    いろいろなサイトでの議論がきっかけにはなると思いますが、ここに集約することで私の
    手による改良が進むことをご理解いただけると思います。
    je1htmさんの回答でもsenshuさんのhidspxに書いて有りましたよの回答かも知れません。
    もっと気軽にこのサイトに書き込んでいただけたのなら、↑でも十分に機能すると思い
    ます。利用者の多くが同梱の資料を読んでくれることを期待して説明書を書いています。
    利用者の行動が即反映できるサイトであることをご理解ください。

    XXX-PDFに嫌気は、私の、怠慢と今は、思っています。
    私の提供しているPDFはハイパーテキストではなく、限りなく紙に近いものです。
    紙はクリックしても、該当ページに飛ぶことはありません。しかし、不満を持つのは
    改良のきっかけになります。ぜひ自らの手で改善を行ってきてください。

    たとえば読みにくさを感じたら、自分でリライトしてみましょう。(書き手の苦労も
    多少は理解してもらえるかもしれません)

    そして成果が得られたら、公開していただければと思います。不満を述べるだけでは、
    改善は進まないと考えています。

je1htmさんの希望がTriggerにはならかった理由

  • kawana? 2009-08-07 (金) 12:17:25
    kugaさんの書込みが無ければ、私はこの改定を行うには至らなかった..
    この考え方は、自己弁護している様に、私には思えます。
    je1htmさんの希望のRST Pin変更に際の警告Messageが出力されたら良いと思います。
    は、je1htmさんの希望です。これをTriggerとして検討はされなかったのですか?
  • kuga? 2009-08-07 (金) 12:29:45
    発言を時系列で追っていくと分かりますが、je1htmさんが希望を出されたとき、
    senshuさんは勘違いをしていて、RSTの保護はすでにhidspx(avrsp)に組み込まれて
    いると思っていたのです。
    私(kuga)の発言をトリガーにして、hidspxにRSTの保護機能がないことに気がつき、
    何らかの対応が必要との判断とだったわけです。
  • kawana? 2009-08-07 (金) 12:42:57
    不満を述べるだけでは、改善は進まないと考えています。
    なぜ、senshuさんは、われわれが不満を述べ、senshuさんが苦労して作られた
    著作物の言い回しを修正出来ますでしょうか。読んだ感じを言ったまでです。
  • senshu 2009-08-09 (日) 10:04:34
    senshuさんが苦労して作られた著作物の言い回しを修正出来ますでしょうか。
    読んだ感じを言ったまでです。
    それ(↑)を私は説明書に関する要望と考えますが、それは全ての利用者に共通するとは
    考えていないのです。

    ぜひ、本当に必要なものが何かを検討したいと思います。

利用者の視点(初心者にも安全に利用できる仕組み)

senshu (2009-08-07 (金) 05:16:03)

今回のje1htmさんの要望は、hidspxをより安全・確実に利用できるものへと進化させる
きっかけになりました。

HIDaspxには 1MHzのクロック出力機能もあるので、HIDaspxとhidspxを組み合わせて
利用する限り、高電圧パラレルライタにお世話になることはほぼなくなった
考えます。

こうした考え方は、何度も失敗をした利用者側から出てくる自然な発想だと思います。
失敗を経験しすぎた兵(つわもの)は地雷を避ける方法を知っており、この発想は生まれ
にくいのです。

Google:


今後も利用者の視点で考えることの重要性を理解し、優れたツールに成長させたいと
思っています。

どうぞ、よろしくお願いいたします。


RSTDSBLに関するパッチを公開(添削依頼)

senshu (2009-08-06 (木) 17:22:45)

リセットピンのI/O変更に対する警告を行うhidspxへのパッチを作成しました。
hidspx-2009-0623/src にて、WinAVRに付属する patchコマンドで以下のように
パッチを当ててください。評価用なので、パッチのみ公開します。
私の書いたコード20090623との差分ファイルです。コンパイルできなくとも、テキスト
ファイルですから、エディタなどで内容をチェックしていただければ幸いです。
filehidspx-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)



  • kuga? 2009-08-06 (木) 20:20:52
    "RSTDSBLのprogramを検出したのでキャンセルした。"
    "強制的に書き込むなら -f#H0x07 のコマンドとせよ"
    というよう感じで、強制書込み手段をメッセージに入れられませんか
    めったに使わない機能でしょうから、きっとコマンドは忘れています。
  • senshu 2009-08-06 (木) 20:28:43
    この手のメッセージの追加なら数分の作業で可能です。ご指摘の通り、このオプションは
    年に一度使うかどうかの頻度だと思いますので、表示メッセージには十分考慮したいと
    思います。

    ところで、RSTDSBLのチェックロジックには漏れは無いでしょうか。

  • kuga? 2009-08-06 (木) 21:20:06
    ところで、RSTDSBLのチェックロジックには漏れは無いでしょうか。
    私の発見できるレベルでは問題ないように見えます。
    DEVICEごとのテーブルの正しさは確認していません。
  • senshu 2009-08-06 (木) 21:28:48
    このテーブルの作成が全所要時間(2時間)の7割程度を占めています。これを2種類のGUIにも
    適用するのは眩暈がします(笑)。

    ということで、明日にでもメッセージの見直しを行い、公開したいと思います。
  • kuga? 2009-08-06 (木) 22:15:50
    このテーブルの作成が全所要時間(2時間)の7割程度を占めています。
    分かります。気を使いますよね。

    私はAVRISPのユーザーですが、純正ツールでさえ 書込み条件を記載したxmlファイルの
    AT90S4414にバグがありました。 AT90S8515の設定で書き込むことで回避しましたが
    AVRstudioがバージョンアップしてもバグは解消していませんでした。
    確認はしていませんが、最新verでもバグったままかも知れません。
    ディスコンのクラシックデバイスですから、だれもチェックしていないんでしょうね。

  • senshu 2009-08-06 (木) 22:22:06
    私はAVRISPのユーザーですが、純正ツールでさえ 書込み条件を記載したxmlファイルの
    AT90S4414にバグがありました。 AT90S8515の設定で書き込むことで回避しましたが
    AVRstudioがバージョンアップしてもバグは解消していませんでした。
    回避方法を見つけられたことに感心します。XMLファイルのようなテキストファイルを
    ベースにするのも修正が容易だとは思うのですが、hidspxのように簡単にコンパイルでき
    るなら、これも高速かつシンプルな解決策だと感じます。kugaさんはどう評価しますか?
  • kuga? 2009-08-06 (木) 22:30:26
    アトメル提供のXMLファイルをそのままの形で取り込めるなら話は別ですが
    (最新デバイスに迅速に対応できる可能性がある)
    そうでないなら、現在のソース埋め込みで問題ないように思います。
  • senshu 2009-08-06 (木) 22:45:01
    audinさんが、rubyでAtmel社のXMLファイルから希望するテーブルを自動生成するコードを
    作成されています。そのままでは hidspxには使えませんが、微修正で何とかなる感じでした。

    しかし入手できるチップの関係で検証ができないので、テーブルの大幅変更は見合わせて
    います。

  • je1htm? 2009-08-06 (木) 23:15:54
    ご検討案で必要十分と思います。16進の特定ビットの1,0を判定するのは素人には無理な話
    で、運を天でやっていましたが、一段と完成度の高いユーザフレンドリーなライタになりそう
    で楽しみです。

    AVRも使いこなしてくるとヒューズ設定の機会も多くなると思いますので、警告が出てオヨヨ!!
    というケースも多いのではないでしょうか。ありがとうございます。
  • senshu 2009-08-06 (木) 23:31:08
    je1htmさん、こんばんは。

    16進の特定ビットの1,0を判定するのは素人には無理な話で
    Fuse Calc の機能や -rf オプションで表示される値を有効に使ってください。
    冷静に進めれば、それほど恐れることでは有りませんが、16進数に不慣れな方には、
    面倒な作業かもしれません。(十分理解できます)

    このサイトでは、こうした要望も(作者側の気分次第で?)短期間で実現される可能性が
    あります。他のサイトでは、要求を書いてもこのような展開は期待できないと思います。

    ということで、今後はこのサイトにも感想や要望を書き込みください。時にはこちらからの
    お願いもあると思いますが、「協力して改善する」のがこのプロジェクトの基本姿勢です。

リセットピンのI/O変更に対する警告

kuga? (2009-08-06 (木) 10:13:23)

O-Family さんの掲示板で「リセットピンをI/OにするFuse変更で警告があるといい」という
希望がありました。
hidspxでガードしているはず との回答でしたが hidspxではガードしていないはずです。
hidspxでは SPIEN(直列プログラミング許可)をガードしていますが、これの勘違いではない
でしょうか?

  • senshu 2009-08-06 (木) 10:43:02
    私も回答を書き込み後、気になり調べようと思っていました。

    SPIENと同様に、RSRDISBL(RSTピンの無効化)にすると、hidspxでのISP書き込みが
    不可能になるので注意が必要な重要項目ですね。再度、ソースを確認してみます。
  • kuga? 2009-08-06 (木) 11:00:19
    書込み前に、ザックリとですがソースは確認済みです。

    SPIEN をガードするのにFuseMasksを利用しています。
    意味のないFuseとして表示マスクとともに、書込み時は andを取ってSPIENを強制 LOWと
    しています。
    自作ではSPIENを禁止するメリットはないのでこれでいいと思いますがRSTをI/Oにするのは、
    PINが不足した場合はありえるでしょう、単純に禁止はできません。

senshuの考える改善策

  • senshu 2009-08-06 (木) 11:17:26
    私も avrspx.c のFusemaskの値を確認していました。

    ソースでは、kugaさんの説明にある方法で「SPIENへの指定を無効」にしていますが、
    RSTDSBLについては、特別な処理はなく、指定された値をそのまま書き込んでいます。

    kugaさんの指摘のように、一度だけなら、こうした指定を行う可能性もあると思い
    ますが、後戻りができない設定になるのを理解し、この操作を行う必要があります。
    GUIツールでは、hispxを介しての対話処理は困難であり、対策はやや面倒です。

    熟考していませんが、-f#H0xdf のように、意図した指定の時にのみRSTDSBLビットに書き
    込みを行ない、通常指定の場合には、書込み時は RSTDSBL ビットを1(RST有効)にし、
    強制 Highとするのも一案と考えています。

    あるいは、こうした操作は、GUIで簡単に行う場合に誤りが起き易いと考えられることから、
    GUI側でガードする方法も考えられます。でも、この方法だとサポートマイコンが増える度に
    保守が必要になる欠点があります。

    どういう改良が望ましいかを十分に検討する必要がありますね。

    幸い、手元にSTK500があるので、RSTDSBLビットをProgramしても、復活可能です。
  • kawana? 2009-08-06 (木) 14:46:13
    とりあえずは、第一警告Messageを出しStopさせ、再コマンド入力に行かせる。
    RSTDSBL変更したばあい、SW等で急場しのぎはできないですね。Writeモ−ド上か?
    でんし研さん、アイデアお持ちかも?(AVRの重ね+RST回路一部断)
    RSTDSBL変更要求の有るCHIPのみ選択変更可能とする。
  • kuga? 2009-08-06 (木) 15:22:58
    プログラムの構造は無視して、操作性のみから考えます。

    GUIの場合 RST無効のFUSE書込み操作をしようとした場合、ダイアログボックスが現れ、
    警告、書込み or キャンセル選択。

    コマンドラインの場合 RST無効のFUSE書込みの場合は 警告を表示して書込み実行しない。
    -f#H0xdfのような特殊なコマンドで警告なしの強制書込みとする。
  • senshu 2009-08-06 (木) 15:40:17
    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? 2009-08-06 (木) 15:44:09
    通常は書き込み禁止状態とし、RSTDSBは、書き込み禁止状態を表示、
    (表示=停止に成るので別の方法)
    どうしても書きたい人のため、Write許可BOXにレ点記入させる。
  • senshu 2009-08-06 (木) 15:48:24
    通常は書き込み禁止状態とし、RSTDSBは、書き込み禁止状態を表示、
    (表示=停止に成るので別の方法)
    GUI側は変更する予定がありません。意図しない書き込みは、hidspx側で拒否し、書き込み
    は特殊な指定を行ったときのみ書き込む、という仕様の実現を目指しています。

    どうしても書きたい人のため、Write許可BOXにレ点記入させる。
    Write許可BOXの説明が難しく、うまく説明しないとこの機能を誤解する恐れがあります。
    また常時チェックすればガードの意味が薄れるので、私がBOXを追加する予定はありません。
  • kuga? 2009-08-06 (木) 16:24:32
    Write許可BOXにレ点記入させる。
    常時チェックすればガードの意味が薄れる
    FUSE書込み前1回のみ有効で、FUSE書込み終了や他の操作で、レ点が外れて
    しまえば、ガードの意味は維持できるように思います。
  • senshu 2009-08-06 (木) 16:54:55
    操作が若干複雑になり、実現も容易ではないので、私はGUIの修正を予定しておりません。
    修正を行わなくとも、任意のオプションを指定しhidspxを起動できるので、-f#H0xd9の意味
    がわかる方はGUIからも操作できます。

    hidspxコマンドを改良し、RSTDSBLガードの機能を持たせ、手入力/GUIのどちらでも
    正しく機能するパッチを作成しましたので、可能なら使ってみてください。

  • kawana? 2009-08-06 (木) 18:36:39
    FUSE書込み前1回のみ有効で、FUSE書込み終了や他の操作で、レ点が外れ
    Write許可BOXは、目立たないところに配置、マニュアルに小さく記載(きちん
    と読まないと実行不可、Write許可keyword入力(RSTDSBL)後1回のみ実行で
    心配はクリア出来ると思います。
  • senshu 2009-08-06 (木) 18:40:41
    当然、時間をかければ作成可能ですので、GUIでこの操作を行いたいと感じたのであれば、
    ぜひ、kawanaさんにこの機能を追加していただきたいと思います。

    繰り返しますが、私はこの機能(年に1度、使うかどうかの機能です)の必要性を感じません。
    それどころか、無い方がトラブルを防止できると考えています。また、この書き込みが必要な
    方はCMD窓での作業が可能な方と考えます。

  • kawana? 2009-08-06 (木) 18:48:42
    WRITEしてしまうと、ISPが機能しなくなるという事は、
    Write禁止処理されていれば、90%でWriterが機能している事と
    考えられないでしょうか?
    xxxさんは、Writeの警告Messageが欲しいとの意と解釈しましたが。
  • senshu 2009-08-06 (木) 18:55:05
    WRITEしてしまうと、ISPが機能しなくなるという事は、
    Write禁止処理されていれば、90%でWriterが機能している事と
    考えられないでしょうか?
    ちょっと意味が理解できませんが、ISP不能になるのは危険な仕様と感じる、という
    意味でしょうか。これはFUSEビットにそういう機能がある以上、避けられないことです。
    指定された値を忠実に書くのがライタの仕事であり、その結果ISPが無効になるのも利用者の
    指示により生じた結果です。しかし、今回作成したパッチにより、ISPが不能になる書き込み
    は一旦は拒否されます。これが意図したものであれば、強制書き込み(#の追加)の指定により、
    書き込みを実行できます。

    xxxさんは、Writeの警告Messageが欲しいとの意と解釈しましたが。
    先ほど公開したパッチで、これらの問題は解決しています。Writeの警告は
    私の場合ですが、無意識にOKを押してしまう傾向があり、この機能は追加には
    ためらいがあります。私は混乱を防ぐ意味でも機能追加は不要と考えています。

    他の利用者の意見もお聞きしたいと思います。

無い方が良い機能

  • kawana? 2009-08-06 (木) 19:32:27
    無意識にOKを押してしまう傾向があり、この機能は追加には
    Messageの追加は、機能追加では無いと考えますが。良く読まないで仕事をする人こそ
    失敗を一度経験してもらうと言うのは、今後のために有益と考えるのですが。
    この変更が、一番変更が少ないのでは、ないでしょうか?
  • senshu 2009-08-06 (木) 19:46:22
    良く読まないで仕事をする人こそ失敗を一度経験してもらうと言うのは、
    今後のために有益と考えるのですが。
    昨日とは論調が逆で興味深いです。なお、無意識でOKボタンを押してしまうのは、説明書
    を読んだ/読まないとは無関係です。仕様を熟知している作成者でも間違えるのですから。
    瞬時の判断ミスでISP不能になるのは痛手です。(恥ずかしながら、何度もこのミスで泣い
    たことがあります。)
    また、私はCMD窓からhidspxを常用しているので、GUIだけを修正しても幸せになれません。
    この変更が、一番変更が少ないのでは、ないでしょうか?
    実は、GUI側にRSTDSBLの検出機能を追加するのは、それほど簡単ではないのです。ターゲット
    マイコンを認識する機能はGUI側にはありませんので、マイコンのスペックデータもGUI側には
    存在しないのです。この状態でRSTDSBLを検出することは不可能なので、独自にRSTDSBL機能
    の判定機能を実装して書き込みデータとつき合わせチェックを行い、書き込み時に警告を発する
    機能を追加する必要があります。

    しかも、hidspx-GUIとhidspxGの2種類を保守しています。更にサポートマイコンが追加された
    場合には、2種類のGUIの修正も必要になるのです。私は、できるだけ一箇所の変更で対応したい
    と思っています。

    一方、hidspx側で対応するのに要した時間は2時間程度でした。しかも、hidspx-GUIの
    エキスパート向けのコマンド窓を使えば、修正無しで強制ライトも可能です。
    hidspxで検出したエラーコードはGUI側で正しく捕捉でき、メッセージも表示されるので、
    GUI側で何も修正を行わなくとも、結果として「希望の警告表示機能」も実現できるのです。
  • senshu 2009-08-06 (木) 21:00:52
    今思いついたのですが、「SHIFTキー」+「Writeボタン」で強制ライトなら、チェックが
    付いたままになる心配は かなり減ります。

    私が実装するなら、こうした仕様で作成します。しかし、やるべきことが山積みなので
    当分作成することはないと思います。

Readme-jの記述の修正(提案)

kawana? 2009-08-06 (木) 12:32:38

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 (木) 13:36:02
    Web上の記述は修正しました。

    Redame-j.txtの内容は修正してみましたが、プレーンなテキストファイルなので、
    朱書きができません。とりあえずの見直しを行いました。

    RSTDSBLビットの扱いに妙案は無いでしょうか。私は机上で十分に検討した実績のある
    データを使いますが、気軽に色々なFUSEデータを書く方もいらっしゃるようです。

    何らかの対策が欲しいところですね。

  • kawana? 2009-08-06 (木) 14:46:13
    プレーンなテキストファイルなので、朱書きができません。
    wordかと思っていました。文字修飾は一切不可能ですね。

新規掲示板を開始します

senshu (2009-08-06 (木) 06:00:42)

話題を切り替えるため、板を刷新しました。