ＰＩＣ　ＡＶＲ　工作室　掲示板

全251件の内、新着の記事から10件ずつ表示します。

Re: 受信割り込みがからない

投稿者：kuga 投稿日：2009年 7月21日(火)22時57分51秒

> No.201[元記事へ] naga64さんへのお返事です。状況がどうも掌握できません。最初「受信割り込みがかからない」とあったのがいつの間にやら「タイマー割り込みがかからない」となっていたりテスト結果が628Aでのなのか、16F88での結果なのかもわかりません。ま、この辺はさておき　まず追求するべきは nekosan の言われる通り 4800bpsでOK,9600bpsでNGの原因追求だと思います。割り込みは、この原因が明確になった後の作業です。原因が明確になり、その原因の解決に割込み利用が適切、あるいはそのほかの理由から受信を割り込みで実行する必要が出てから検討すべきです。 ==以下は 4800/9600の原因がわかった後での事柄 >ＩＮＴＣＯＮの全割り込みｂitがなぜ勝手にＯＦＦされるのか不明です。全割り込みｂitは割り込みが受け付けられた段階で自動的にOFFになります。割り込みから復帰するRETFIEによって全割り込みｂitは復帰します。割り込みルーチンから復帰していない部分で確認したのだと思います。 >ＰＩＣは割り込みに優先順位は付けられないのでしょうか？ PICのハードウエアには割り込のに優先順位という概念がありません。割り込みの優先順位という場合、２種類の意味合いがあります。ひとつは同時に２種の割込みが起こった場合どちらの割込み処理を実行するか。もうひとつは、多重割込みの概念で、ある割込み処理を実行中でもそれより高い優先順位を持った割込みが発生した場合はその割込みを実行する。といった場合です。 PICの割込みはなにかの割込み要因が発生している場合４番地をCALL するという機能しかありませんから、２つの２割込み要因が発生した場合どちらを優先するのかは、割り込み処理ルーチンのソフトウエアでの仕事となります。多重割込はPICでは事実上実行不可能でしょう。ハードウエアの補助が無い上、スタックの制限やレジスタの保存で、とてもソフトが複雑になるはずです。 > kugaさんへのお返事です。 > > kugaさん、こんばんわ。 > 返事が遅くなりすいません。 > いつも詳しい説明ありがとうございます。 > 現在、指摘された所を見直しています。 > 原因がわかったらまた回答したいと思っています。 > ちなみに、F88で実験したときは、ハード的にRX＝RB２に接続しなおして実験しています。 > OSCは４MHZに設定して実験しました。 > > タイマー割り込みを使うとシリアルが動かなくなる件は調査中です。 > ４MHZで６２８Aを動かして、４ｍｓでタイマー割り込みをかけながら、シリアルの受信割り込みをかけようとすると、なぜか割り込みかかからなくなります。そのとき、シリアル受信は出来ています。エラーフラグはオーバーランとフレーミングの両方が立ちます。 > また、割り込みは、1文字をPCから送信したとたんに、割り込みの全許可ビットがOFFされてしまいます。（7セグLEDも表示がぶっ飛びます。ぶっ飛んだ後にICD２止めてINTCONを見ると、割り込み全許可のｂｉｔがＯＦＦになってます） > 以上また進展しましたら報告いたしますのでしばらく時間をください。 > > > > naga64さんへのお返事です。 > > > > > 関連キーワードは全て同じ用に設定されています。また、fast_io（）も設定していますが、ICD２でブレークかけても飛んでこないし、ブレイクの代わりにLEDを光らせるようにしても飛んでこないので光らないのです。 > > 「全て同じ用に」とのことですが、CPUが16F628A->16F88と違うのですから > > 同じはずが無いのですが・・ 16F88はインターナルOSCは8MHzのはずですし > > USARTのピンも TX=RB5 RX=RB2 と16F628とは異なっているのですが > > ハードウェアと、#use rs232 は適切に設定されているのでしょうか > > 適切なPINでないとソフトウェアUARTになってしまいます。 > > > > > 内蔵のクロックをキャリブレーションするには、どこの値を変更すればいいのでしょうか？６２８Ａはキャリブレーションは出来るマイコンでしょうか？ > > > > 16F628Aは発振周波数を調整するレジスタは無いと思います。 > > 16F88にはOSCTUNEという調整レジスタがありますね。 > > > > ===== > > ポートの入出力がおかしい件はどうなったのでしょう？ > > 最初タイマー割り込みを使って、シリアルが動かなかった原因はなんだっのでしょう > > 「ｘｘしたら動作した」ではなく > > 「ｘｘが原因で動かなかった、その問題点を解決するためにｘｘをした」と > > 明確にしておかないと、実は本質的な解決ではなくまた別のところで > > 問題がおきかねませんよ。

Re: 受信割り込みがからない

投稿者：naga64 投稿日：2009年 7月21日(火)20時17分15秒

返信・引用

> No.200[元記事へ] nekosanさんへのお返事です。こんばんわ。いつも詳しく説明していただきありがとうございます。現在、時間が取れないため少し検証が遅れていますが、検証してわかり次第報告したいと思っていますのでもう少し時間をください。今後もありますので、この件はクリアーしておきたいと思っていますのでよろしくお願いいたします。 > naga64さんへのお返事です。 > > > 色々とご指摘ありがとうございます。 > > まとめると下記のようになります。 > > ①MAINループ内でgetc（）で４MｈZの受信は出来た。 > > しかし、９６００ｂｐｓにするとデータが化ける（ビットがずれる）。 > > ４８００bpsなら正常にデータ受信できる。 > > ②受信割り込みを使った受信も４ＭＨＺで出来た。 > > ③７セグＬＥＤのダイナミック点灯も割り込み（taimer１、０）を使って表示できた。 > > ④　①が駄目なので、②＋③でやれば上手くいくと思ったが、②＋③をするとなぜかtaimer割り込みがかからなくなる（全割り込みのbitが勝手にｏｆｆされる） > > 受信割り込みでは９６００ｂｐｓでもデータは受信出来ている。 > > > > という感じです。 > > > > 受信割り込みだけかtimer割り込みのダイナミック点灯（７セグ５桁）だけのどちらかは動きますが、両方同時に動かそうとすると、taimer割り込みがかからなくってしまいます。 > > ＩＮＴＣＯＮの全割り込みｂitがなぜ勝手にＯＦＦされるのか不明です。何が悪いのでしょうか？ > > > naga64さん、お纏めありがとうございました。 > バグの原因の切り出しにはちょっと情報不足ではある > みたいですが、現状はなんとなく見えました。 > > ①がうまく行かないので、その代りに②や③を組み合わせた > 方法＝④を選んでみた、ということですね。 > > 逆にいうと、①のバグの原因も、その影響範囲も > 目下不明という状態というですね？ > > > とすると、②において４８００ｂｐｓは本当に問題なく > 動いていると断言は出来ないことになりますし、 > 結果③と組み合わせても上手く動かない可能性も > 多々あることになります。 > > もちろん、実際に４８００ｂｐｓで想定どおり動作 > しているのかも知れませんが、様々な複合条件によって > たまたま４８００ｂｐｓではバグが表面化していない > だけかもしれませんし、これを放置したまま②＋③ > という新たな条件を加えて動作させれば、それがまた > 新たな理由でバグを表面化させるということも > 考えられるかと思います。 > （現状、これを否定することはできませんよね？） > > > 一概に、原因も影響範囲も判らないバグを放置 > したまま別の方法を使って逃げようとすると、 > ますます泥沼に填まることが多いと思います。 > > それも別に悪いことばかりではなくて、かく言う > 私も８ビットＰＣで遊んでいた大昔にはしょっちゅう > やってました。それによって副産物的な予備知識が > 増えていったというのも事実です。 > なのでそれ自体は止めません。お勧めもしませんが。 > > > ただ今回のお話の流れからして、ＵＳＡＲＴ割り込み > に逃げることには私は反対なので、①の件が解決する > までは割り込み関係に関するコメントを見送ります。 > （じゃないとドンドン錯綜していくので） > > > で、あらためて４８００ｂｐｓならｏｋだけど > ９６００ｂｐｓではダメな理由について触れてみます。 > > （１）ビットレートの計算式は？ > > 　ビットレートの計算式は本当に合っているのでしょうか？ > 　設定値が「１」でもズレていれば、結構大きな誤差が > 　生じます。データシートに計算式がきちんと載っている > 　ので、一度確かめてみてください。あとBRGHビットの設定も > 　正しいですか？ > > 　また、６２８（や８８）はＵＳＡＲＴをシンクロナスモード > 　とアシンクロナスモードどちらでも使えるかと思いますが、 > 　それぞれ計算式が異なるかと思います。モードを間違えて > 　いませんか？ > > 　その他関連ビットと動作内容の対比をもう一度確認 > 　してみてください。 > > > （２）本当にビットずれ？ > > 　まず、通信条件をお確かめ下さい。８ｎ１になってますか？ > > 　で、 > 　本当にビットずれなのでしょうか？もし本当であれば、 > 　ストップビットが正常に受け取れないはずなので、 > 　FERRビットが立っているはずです。お確かめ下さい。 > > 　じつはバイトずれではないのでしょうか？ > 　バイトずれであれば、バッファオーバーランが起って > 　OERRビットが立っているかもしれません。 > > 　もしバッファオーバーランであれば、再度念を > 　押しますが、ストックとフローを設計から見直して > 　ください。 > > 　その他、送信側機器のビットレートや送信内容、 > 　もしくはバイナリデータ／アスキーデータの自動変換 > 　に引っかかってないかなども見直してみてください。 > > > まずはその辺りからだと思います。 > > あと、別件ですが、kugaさんのアドバイスなども含め、 > その内容について検証結果をフィードバックしていただけると > 助かります。 > > お伝えする側としても、的外れなことを言ってないか、 > それとも役に立ったのか、フィードバックがないと > 判断ができませんので… > > > 草葉の陰（？）から応援してますので、引き続き > 頑張って挑戦してください。

Re: 受信割り込みがからない

投稿者：naga64 投稿日：2009年 7月21日(火)20時13分0秒

返信・引用

> No.196[元記事へ] kugaさんへのお返事です。 kugaさん、こんばんわ。返事が遅くなりすいません。いつも詳しい説明ありがとうございます。現在、指摘された所を見直しています。原因がわかったらまた回答したいと思っています。ちなみに、F88で実験したときは、ハード的にRX＝RB２に接続しなおして実験しています。 OSCは４MHZに設定して実験しました。タイマー割り込みを使うとシリアルが動かなくなる件は調査中です。４MHZで６２８Aを動かして、４ｍｓでタイマー割り込みをかけながら、シリアルの受信割り込みをかけようとすると、なぜか割り込みかかからなくなります。そのとき、シリアル受信は出来ています。エラーフラグはオーバーランとフレーミングの両方が立ちます。また、割り込みは、1文字をPCから送信したとたんに、割り込みの全許可ビットがOFFされてしまいます。（7セグLEDも表示がぶっ飛びます。ぶっ飛んだ後にICD２止めてINTCONを見ると、割り込み全許可のｂｉｔがＯＦＦになってます）以上また進展しましたら報告いたしますのでしばらく時間をください。 > naga64さんへのお返事です。 > > > 関連キーワードは全て同じ用に設定されています。また、fast_io（）も設定していますが、ICD２でブレークかけても飛んでこないし、ブレイクの代わりにLEDを光らせるようにしても飛んでこないので光らないのです。 > 「全て同じ用に」とのことですが、CPUが16F628A->16F88と違うのですから > 同じはずが無いのですが・・ 16F88はインターナルOSCは8MHzのはずですし > USARTのピンも TX=RB5 RX=RB2 と16F628とは異なっているのですが > ハードウェアと、#use rs232 は適切に設定されているのでしょうか > 適切なPINでないとソフトウェアUARTになってしまいます。 > > > 内蔵のクロックをキャリブレーションするには、どこの値を変更すればいいのでしょうか？６２８Ａはキャリブレーションは出来るマイコンでしょうか？ > > 16F628Aは発振周波数を調整するレジスタは無いと思います。 > 16F88にはOSCTUNEという調整レジスタがありますね。 > > ===== > ポートの入出力がおかしい件はどうなったのでしょう？ > 最初タイマー割り込みを使って、シリアルが動かなかった原因はなんだっのでしょう > 「ｘｘしたら動作した」ではなく > 「ｘｘが原因で動かなかった、その問題点を解決するためにｘｘをした」と > 明確にしておかないと、実は本質的な解決ではなくまた別のところで > 問題がおきかねませんよ。

Re: 受信割り込みがからない

投稿者：nekosan 投稿日：2009年 7月17日(金)21時12分0秒

返信・引用編集済

> No.198[元記事へ] naga64さんへのお返事です。 > 色々とご指摘ありがとうございます。 > まとめると下記のようになります。 > ①MAINループ内でgetc（）で４MｈZの受信は出来た。 > しかし、９６００ｂｐｓにするとデータが化ける（ビットがずれる）。 > ４８００bpsなら正常にデータ受信できる。 > ②受信割り込みを使った受信も４ＭＨＺで出来た。 > ③７セグＬＥＤのダイナミック点灯も割り込み（taimer１、０）を使って表示できた。 > ④　①が駄目なので、②＋③でやれば上手くいくと思ったが、②＋③をするとなぜかtaimer割り込みがかからなくなる（全割り込みのbitが勝手にｏｆｆされる） > 受信割り込みでは９６００ｂｐｓでもデータは受信出来ている。 > > という感じです。 > > 受信割り込みだけかtimer割り込みのダイナミック点灯（７セグ５桁）だけのどちらかは動きますが、両方同時に動かそうとすると、taimer割り込みがかからなくってしまいます。 > ＩＮＴＣＯＮの全割り込みｂitがなぜ勝手にＯＦＦされるのか不明です。何が悪いのでしょうか？ naga64さん、お纏めありがとうございました。バグの原因の切り出しにはちょっと情報不足ではあるみたいですが、現状はなんとなく見えました。 ①がうまく行かないので、その代りに②や③を組み合わせた方法＝④を選んでみた、ということですね。逆にいうと、①のバグの原因も、その影響範囲も目下不明という状態というですね？とすると、②において４８００ｂｐｓは本当に問題なく動いていると断言は出来ないことになりますし、結果③と組み合わせても上手く動かない可能性も多々あることになります。もちろん、実際に４８００ｂｐｓで想定どおり動作しているのかも知れませんが、様々な複合条件によってたまたま４８００ｂｐｓではバグが表面化していないだけかもしれませんし、これを放置したまま②＋③ という新たな条件を加えて動作させれば、それがまた新たな理由でバグを表面化させるということも考えられるかと思います。（現状、これを否定することはできませんよね？）一概に、原因も影響範囲も判らないバグを放置したまま別の方法を使って逃げようとすると、ますます泥沼に填まることが多いと思います。それも別に悪いことばかりではなくて、かく言う私も８ビットＰＣで遊んでいた大昔にはしょっちゅうやってました。それによって副産物的な予備知識が増えていったというのも事実です。なのでそれ自体は止めません。お勧めもしませんが。ただ今回のお話の流れからして、ＵＳＡＲＴ割り込みに逃げることには私は反対なので、①の件が解決するまでは割り込み関係に関するコメントを見送ります。（じゃないとドンドン錯綜していくので）で、あらためて４８００ｂｐｓならｏｋだけど９６００ｂｐｓではダメな理由について触れてみます。（１）ビットレートの計算式は？　ビットレートの計算式は本当に合っているのでしょうか？　設定値が「１」でもズレていれば、結構大きな誤差が　生じます。データシートに計算式がきちんと載っている　ので、一度確かめてみてください。あとBRGHビットの設定も　正しいですか？　また、６２８（や８８）はＵＳＡＲＴをシンクロナスモード　とアシンクロナスモードどちらでも使えるかと思いますが、　それぞれ計算式が異なるかと思います。モードを間違えて　いませんか？　その他関連ビットと動作内容の対比をもう一度確認　してみてください。（２）本当にビットずれ？　まず、通信条件をお確かめ下さい。８ｎ１になってますか？　で、　本当にビットずれなのでしょうか？もし本当であれば、　ストップビットが正常に受け取れないはずなので、　FERRビットが立っているはずです。お確かめ下さい。　じつはバイトずれではないのでしょうか？　バイトずれであれば、バッファオーバーランが起って　OERRビットが立っているかもしれません。　もしバッファオーバーランであれば、再度念を　押しますが、ストックとフローを設計から見直して　ください。　その他、送信側機器のビットレートや送信内容、　もしくはバイナリデータ／アスキーデータの自動変換　に引っかかってないかなども見直してみてください。まずはその辺りからだと思います。あと、別件ですが、kugaさんのアドバイスなども含め、その内容について検証結果をフィードバックしていただけると助かります。お伝えする側としても、的外れなことを言ってないか、それとも役に立ったのか、フィードバックがないと判断ができませんので… 草葉の陰（？）から応援してますので、引き続き頑張って挑戦してください。

Re: 受信割り込みがからない

投稿者：naga64 投稿日：2009年 7月17日(金)11時50分33秒

返信・引用

> No.197[元記事へ] nekosanさんへのお返事です。もう一つ質問なんですが？ＰＩＣは割り込みに優先順位は付けられないのでしょうか？マニュアルには出てこないみたいなのですが？ > naga64さんへのお返事です。 > > > 関連キーワードは全て同じ用に設定されています。また、fast_io（）も設定していますが、ICD２でブレークかけても飛んでこないし、ブレイクの代わりにLEDを光らせるようにしても飛んでこないので光らないのです。 > > それで、受信割り込みについてはまたの機会にすることにしました。 > > 結局、タイマー１とメインループ内で受信することで、なんとか出来たのですが、当初の９６００ｂＰＳにするとデータがかならずどこか数ビットずれてしまいます。 > > > > どうもお話がドンドン錯綜してしまっていて、今ひとつしっくり > 来ないのですが…。 > 以前お伺いした一時点では「４Ｍｈｚでシリアル通信が出来た」 > 状態が存在していて、そこから何か修正をしたらシリアル通信が > 出来なくなったという理解でいいのでしょうか？ > （fast_ioなどといった問題ではない気がするのですが…） > > で、多分その間に何かを修正したのだと思いますが、何をどの > ように修正したのかが今ひとつ判らないので、それを眺めている > 私はnaga64さん以上に「なにがなにやら」といった状態です。 > > また、ＵＳＡＲＴの受信処理が上手く行かないという状態とは、 > 「割り込みがかからない」なのか、それとも「割り込みは > かかるけどビットずれしている」状態なのか、この点も > かなり錯綜しているようです。修正した内容とその結果の > 因果関係が全く見えません。 > > 想定どおり動作をしているバージョン（安定バージョン） > に対して、何をどう修正したらどのように上手く動かなく > なったのか、その辺の情報が整理されないと、因果関係を > 明確にするどころか余計に混乱していく一方ではないかと > 思います。 > > > > 私のつたない実務経験を元にさせていただきますが、 > 何か上手く動作しないという時に、手当たり次第にソースに > 修正を加えてしまうと、元々のソースに原因があるのか、 > それとも後から手を加えた部分で新たにトラブルを > 作りこんでいるのか判断できないと思います。 > > 特に手当たり次第に複数の実験的な修正を入れてしまうと、 > それらの修正同士の狭間で新たに予期しないバグを作りこんで > いるということも想定できます。 > > まずお勧めしたいのは「手当たり次第に修正・実験をしない」 > ことだと思います。 > 原因究明どころではなく、新たな問題を次から次へと > 生じさせることになってしまい、収集がつきません。 > > ソースを修正するというのは、実は極めてヘビーな > 話で、バージョン管理なども実は重要なテーマの一つ > だったりします。手当たり次第修正するというのは、 > 昔怖い先輩から厳重に注意された記憶があるのですが、 > 確かに今になって思うとそのとおりだと実感しています。 > > > 少なくとも上手く動いていたバージョンと言うものは > それはそれで一旦保管しておいて、いざ不可解なことが > 起ったらその時点まで立ち戻って比較・考えることが > できる状態… > そういう「修正環境」を構築しておくことをお勧め > したいと思います。 > > そういう「元に戻れる」状態を確保しておくことで、 > 「修正した内容」と「その効果」の因果関係を > きちんと見比べられるわけです。 > （逆にそれが無ければ見比べることって不可能ですよね？） > > > > 本を読めば言語の仕様やテクニック的なことは > いくらでも手に入るのですが、この手の「品質管理」 > に関することはあまり一般図書には書かれていませんし、 > 文章化することもなかなか難しい問題でもありますが。 > （定型化することもそもそも難しい問題ですし… > 　ISO9000関係の本でも読めばある程度書いてあるのかな…？） > > > もし今お時間が少しでも取れるのであれば、ソース修正 > や実験を一切中断して、現在発覚している問題や > 過去に起ったトラブルについて一度列挙し、その一つ一つ > の原因について熟考してみるといいかといいのでは > ないかと思います。 > これ以上実験を繰り返しても、naga64さん以上に > 周りの人間は訳わからない状況ということになると > 思います。 > > > プログラミングテクニックや回路設計のテクニック > というのは、一見モノヅクリの主作業のように > 思われがちですが、私はそれは幻想だと思っていて > （そもそも本を読めばどこかしらに答えが書いてあるので > ある意味ルーチンワークの一種と思っています）、 > むしろ難しいのは「品質確保の方法」や「バグや > トラブルが起った時にそれをどのように教訓と > し、将来のトラブルを未然に防ぐのか」といった > 「管理的な要件」のほうが、モノヅクリの現場では > 重要なのだと思っています。（私個人の実感ですが） > > > 自分を省みずに凄く”偉そうなこと”を書いているのは > 自覚していますが、自分自身のその点がいつも不安に > 感じる所でもあり、いわゆる「モノヅクリにおける > 永遠のテーマ」の一つだと思っています。 > > 今回の件は私の（つたない）経験から見ると、今後 > ますます迷路にはまり込んでいくパターンの典型に > 見えてしまうので、なんとなくこのまま進めるのでは > なく、一旦立ち止まってみることをお勧めしたいと > 思います。 > > > もしその辺りに意味が無いのであれば、モノヅクリの > 「成果」というものは常に「運次第」にしかならない > 気がします。 > > アイデアを確実に「モノ」に仕上げていくためには > 単なるテクニックだけでなく、モノヅクリに関する > 哲学や思想的なものや、管理能力といったモノが > 必要不可欠だと思うのですが、これまでの会話を > 眺めていて、テクニック重視で思想的なものが > 抜け落ちている気がしてしまいます。 > > テクニックの習得に走っている時、もしくは > 手を動かしている時って、そのことだけに注力する > ことがでるので、ある意味難しい問題から目をそらす > ことができて安心が得られるのですが… > > > 私にはあまりその辺りについてきちんと説明が > 出来るほどの知識も経験もないので言葉足らずですね。 > この辺りについて、経験豊かな方に何かご助言 > いただけるとありがたいのですが… > > > > ４８００ｂｐｓにすると文字化けは起こりません。それで、４ＭＨＺを調整（公正）したら９６００でも取れるようになるのではと思いました。 > > ちなみに、４８００ｂｐｓでも９６００ｂｐｓでも、 > クロックの校正誤差は「割合」として同じように生じる > はずなので、もし４Ｍｈｚの校正が上手くいっていない > のだとすれば、４８００でも９６００でも同じ程度で > 誤差が生じなければ辻褄が合わないと思います。

Re: 受信割り込みがからない

投稿者：naga64 投稿日：2009年 7月17日(金)09時44分25秒

返信・引用

> No.197[元記事へ] nekosanさんへのお返事です。返事ありがとうございます。色々とご指摘ありがとうございます。まとめると下記のようになります。 ①MAINループ内でgetc（）で４MｈZの受信は出来た。しかし、９６００ｂｐｓにするとデータが化ける（ビットがずれる）。４８００bpsなら正常にデータ受信できる。 ②受信割り込みを使った受信も４ＭＨＺで出来た。 ③７セグＬＥＤのダイナミック点灯も割り込み（taimer１、０）を使って表示できた。 ④　①が駄目なので、②＋③でやれば上手くいくと思ったが、②＋③をするとなぜかtaimer割り込みがかからなくなる（全割り込みのbitが勝手にｏｆｆされる）受信割り込みでは９６００ｂｐｓでもデータは受信出来ている。という感じです。受信割り込みだけかtimer割り込みのダイナミック点灯（７セグ５桁）だけのどちらかは動きますが、両方同時に動かそうとすると、taimer割り込みがかからなくってしまいます。ＩＮＴＣＯＮの全割り込みｂitがなぜ勝手にＯＦＦされるのか不明です。何が悪いのでしょうか？ > naga64さんへのお返事です。 > > > 関連キーワードは全て同じ用に設定されています。また、fast_io（）も設定していますが、ICD２でブレークかけても飛んでこないし、ブレイクの代わりにLEDを光らせるようにしても飛んでこないので光らないのです。 > > それで、受信割り込みについてはまたの機会にすることにしました。 > > 結局、タイマー１とメインループ内で受信することで、なんとか出来たのですが、当初の９６００ｂＰＳにするとデータがかならずどこか数ビットずれてしまいます。 > > > > どうもお話がドンドン錯綜してしまっていて、今ひとつしっくり > 来ないのですが…。 > 以前お伺いした一時点では「４Ｍｈｚでシリアル通信が出来た」 > 状態が存在していて、そこから何か修正をしたらシリアル通信が > 出来なくなったという理解でいいのでしょうか？ > （fast_ioなどといった問題ではない気がするのですが…） > > で、多分その間に何かを修正したのだと思いますが、何をどの > ように修正したのかが今ひとつ判らないので、それを眺めている > 私はnaga64さん以上に「なにがなにやら」といった状態です。 > > また、ＵＳＡＲＴの受信処理が上手く行かないという状態とは、 > 「割り込みがかからない」なのか、それとも「割り込みは > かかるけどビットずれしている」状態なのか、この点も > かなり錯綜しているようです。修正した内容とその結果の > 因果関係が全く見えません。 > > 想定どおり動作をしているバージョン（安定バージョン） > に対して、何をどう修正したらどのように上手く動かなく > なったのか、その辺の情報が整理されないと、因果関係を > 明確にするどころか余計に混乱していく一方ではないかと > 思います。 > > > > 私のつたない実務経験を元にさせていただきますが、 > 何か上手く動作しないという時に、手当たり次第にソースに > 修正を加えてしまうと、元々のソースに原因があるのか、 > それとも後から手を加えた部分で新たにトラブルを > 作りこんでいるのか判断できないと思います。 > > 特に手当たり次第に複数の実験的な修正を入れてしまうと、 > それらの修正同士の狭間で新たに予期しないバグを作りこんで > いるということも想定できます。 > > まずお勧めしたいのは「手当たり次第に修正・実験をしない」 > ことだと思います。 > 原因究明どころではなく、新たな問題を次から次へと > 生じさせることになってしまい、収集がつきません。 > > ソースを修正するというのは、実は極めてヘビーな > 話で、バージョン管理なども実は重要なテーマの一つ > だったりします。手当たり次第修正するというのは、 > 昔怖い先輩から厳重に注意された記憶があるのですが、 > 確かに今になって思うとそのとおりだと実感しています。 > > > 少なくとも上手く動いていたバージョンと言うものは > それはそれで一旦保管しておいて、いざ不可解なことが > 起ったらその時点まで立ち戻って比較・考えることが > できる状態… > そういう「修正環境」を構築しておくことをお勧め > したいと思います。 > > そういう「元に戻れる」状態を確保しておくことで、 > 「修正した内容」と「その効果」の因果関係を > きちんと見比べられるわけです。 > （逆にそれが無ければ見比べることって不可能ですよね？） > > > > 本を読めば言語の仕様やテクニック的なことは > いくらでも手に入るのですが、この手の「品質管理」 > に関することはあまり一般図書には書かれていませんし、 > 文章化することもなかなか難しい問題でもありますが。 > （定型化することもそもそも難しい問題ですし… > 　ISO9000関係の本でも読めばある程度書いてあるのかな…？） > > > もし今お時間が少しでも取れるのであれば、ソース修正 > や実験を一切中断して、現在発覚している問題や > 過去に起ったトラブルについて一度列挙し、その一つ一つ > の原因について熟考してみるといいかといいのでは > ないかと思います。 > これ以上実験を繰り返しても、naga64さん以上に > 周りの人間は訳わからない状況ということになると > 思います。 > > > プログラミングテクニックや回路設計のテクニック > というのは、一見モノヅクリの主作業のように > 思われがちですが、私はそれは幻想だと思っていて > （そもそも本を読めばどこかしらに答えが書いてあるので > ある意味ルーチンワークの一種と思っています）、 > むしろ難しいのは「品質確保の方法」や「バグや > トラブルが起った時にそれをどのように教訓と > し、将来のトラブルを未然に防ぐのか」といった > 「管理的な要件」のほうが、モノヅクリの現場では > 重要なのだと思っています。（私個人の実感ですが） > > > 自分を省みずに凄く”偉そうなこと”を書いているのは > 自覚していますが、自分自身のその点がいつも不安に > 感じる所でもあり、いわゆる「モノヅクリにおける > 永遠のテーマ」の一つだと思っています。 > > 今回の件は私の（つたない）経験から見ると、今後 > ますます迷路にはまり込んでいくパターンの典型に > 見えてしまうので、なんとなくこのまま進めるのでは > なく、一旦立ち止まってみることをお勧めしたいと > 思います。 > > > もしその辺りに意味が無いのであれば、モノヅクリの > 「成果」というものは常に「運次第」にしかならない > 気がします。 > > アイデアを確実に「モノ」に仕上げていくためには > 単なるテクニックだけでなく、モノヅクリに関する > 哲学や思想的なものや、管理能力といったモノが > 必要不可欠だと思うのですが、これまでの会話を > 眺めていて、テクニック重視で思想的なものが > 抜け落ちている気がしてしまいます。 > > テクニックの習得に走っている時、もしくは > 手を動かしている時って、そのことだけに注力する > ことがでるので、ある意味難しい問題から目をそらす > ことができて安心が得られるのですが… > > > 私にはあまりその辺りについてきちんと説明が > 出来るほどの知識も経験もないので言葉足らずですね。 > この辺りについて、経験豊かな方に何かご助言 > いただけるとありがたいのですが… > > > > ４８００ｂｐｓにすると文字化けは起こりません。それで、４ＭＨＺを調整（公正）したら９６００でも取れるようになるのではと思いました。 > > ちなみに、４８００ｂｐｓでも９６００ｂｐｓでも、 > クロックの校正誤差は「割合」として同じように生じる > はずなので、もし４Ｍｈｚの校正が上手くいっていない > のだとすれば、４８００でも９６００でも同じ程度で > 誤差が生じなければ辻褄が合わないと思います。

Re: 受信割り込みがからない

投稿者：nekosan 投稿日：2009年 7月15日(水)00時57分10秒

返信・引用

> No.195[元記事へ] naga64さんへのお返事です。 > 関連キーワードは全て同じ用に設定されています。また、fast_io（）も設定していますが、ICD２でブレークかけても飛んでこないし、ブレイクの代わりにLEDを光らせるようにしても飛んでこないので光らないのです。 > それで、受信割り込みについてはまたの機会にすることにしました。 > 結局、タイマー１とメインループ内で受信することで、なんとか出来たのですが、当初の９６００ｂＰＳにするとデータがかならずどこか数ビットずれてしまいます。どうもお話がドンドン錯綜してしまっていて、今ひとつしっくり来ないのですが…。以前お伺いした一時点では「４Ｍｈｚでシリアル通信が出来た」状態が存在していて、そこから何か修正をしたらシリアル通信が出来なくなったという理解でいいのでしょうか？（fast_ioなどといった問題ではない気がするのですが…）で、多分その間に何かを修正したのだと思いますが、何をどのように修正したのかが今ひとつ判らないので、それを眺めている私はnaga64さん以上に「なにがなにやら」といった状態です。また、ＵＳＡＲＴの受信処理が上手く行かないという状態とは、「割り込みがかからない」なのか、それとも「割り込みはかかるけどビットずれしている」状態なのか、この点もかなり錯綜しているようです。修正した内容とその結果の因果関係が全く見えません。想定どおり動作をしているバージョン（安定バージョン）に対して、何をどう修正したらどのように上手く動かなくなったのか、その辺の情報が整理されないと、因果関係を明確にするどころか余計に混乱していく一方ではないかと思います。私のつたない実務経験を元にさせていただきますが、何か上手く動作しないという時に、手当たり次第にソースに修正を加えてしまうと、元々のソースに原因があるのか、それとも後から手を加えた部分で新たにトラブルを作りこんでいるのか判断できないと思います。特に手当たり次第に複数の実験的な修正を入れてしまうと、それらの修正同士の狭間で新たに予期しないバグを作りこんでいるということも想定できます。まずお勧めしたいのは「手当たり次第に修正・実験をしない」ことだと思います。原因究明どころではなく、新たな問題を次から次へと生じさせることになってしまい、収集がつきません。ソースを修正するというのは、実は極めてヘビーな話で、バージョン管理なども実は重要なテーマの一つだったりします。手当たり次第修正するというのは、昔怖い先輩から厳重に注意された記憶があるのですが、確かに今になって思うとそのとおりだと実感しています。少なくとも上手く動いていたバージョンと言うものはそれはそれで一旦保管しておいて、いざ不可解なことが起ったらその時点まで立ち戻って比較・考えることができる状態… そういう「修正環境」を構築しておくことをお勧めしたいと思います。そういう「元に戻れる」状態を確保しておくことで、「修正した内容」と「その効果」の因果関係をきちんと見比べられるわけです。（逆にそれが無ければ見比べることって不可能ですよね？）本を読めば言語の仕様やテクニック的なことはいくらでも手に入るのですが、この手の「品質管理」に関することはあまり一般図書には書かれていませんし、文章化することもなかなか難しい問題でもありますが。（定型化することもそもそも難しい問題ですし… 　ISO9000関係の本でも読めばある程度書いてあるのかな…？）もし今お時間が少しでも取れるのであれば、ソース修正や実験を一切中断して、現在発覚している問題や過去に起ったトラブルについて一度列挙し、その一つ一つの原因について熟考してみるといいかといいのではないかと思います。これ以上実験を繰り返しても、naga64さん以上に周りの人間は訳わからない状況ということになると思います。プログラミングテクニックや回路設計のテクニックというのは、一見モノヅクリの主作業のように思われがちですが、私はそれは幻想だと思っていて（そもそも本を読めばどこかしらに答えが書いてあるのである意味ルーチンワークの一種と思っています）、むしろ難しいのは「品質確保の方法」や「バグやトラブルが起った時にそれをどのように教訓とし、将来のトラブルを未然に防ぐのか」といった「管理的な要件」のほうが、モノヅクリの現場では重要なのだと思っています。（私個人の実感ですが）自分を省みずに凄く”偉そうなこと”を書いているのは自覚していますが、自分自身のその点がいつも不安に感じる所でもあり、いわゆる「モノヅクリにおける永遠のテーマ」の一つだと思っています。今回の件は私の（つたない）経験から見ると、今後ますます迷路にはまり込んでいくパターンの典型に見えてしまうので、なんとなくこのまま進めるのではなく、一旦立ち止まってみることをお勧めしたいと思います。もしその辺りに意味が無いのであれば、モノヅクリの「成果」というものは常に「運次第」にしかならない気がします。アイデアを確実に「モノ」に仕上げていくためには単なるテクニックだけでなく、モノヅクリに関する哲学や思想的なものや、管理能力といったモノが必要不可欠だと思うのですが、これまでの会話を眺めていて、テクニック重視で思想的なものが抜け落ちている気がしてしまいます。テクニックの習得に走っている時、もしくは手を動かしている時って、そのことだけに注力することがでるので、ある意味難しい問題から目をそらすことができて安心が得られるのですが… 私にはあまりその辺りについてきちんと説明が出来るほどの知識も経験もないので言葉足らずですね。この辺りについて、経験豊かな方に何かご助言いただけるとありがたいのですが… > ４８００ｂｐｓにすると文字化けは起こりません。それで、４ＭＨＺを調整（公正）したら９６００でも取れるようになるのではと思いました。ちなみに、４８００ｂｐｓでも９６００ｂｐｓでも、クロックの校正誤差は「割合」として同じように生じるはずなので、もし４Ｍｈｚの校正が上手くいっていないのだとすれば、４８００でも９６００でも同じ程度で誤差が生じなければ辻褄が合わないと思います。

Re: 受信割り込みがからない

投稿者：kuga 投稿日：2009年 7月14日(火)21時35分9秒

返信・引用

> No.195[元記事へ] naga64さんへのお返事です。 > 関連キーワードは全て同じ用に設定されています。また、fast_io（）も設定していますが、ICD２でブレークかけても飛んでこないし、ブレイクの代わりにLEDを光らせるようにしても飛んでこないので光らないのです。「全て同じ用に」とのことですが、CPUが16F628A->16F88と違うのですから同じはずが無いのですが・・ 16F88はインターナルOSCは8MHzのはずですし USARTのピンも TX=RB5 RX=RB2 と16F628とは異なっているのですがハードウェアと、#use rs232 は適切に設定されているのでしょうか適切なPINでないとソフトウェアUARTになってしまいます。 > 内蔵のクロックをキャリブレーションするには、どこの値を変更すればいいのでしょうか？６２８Ａはキャリブレーションは出来るマイコンでしょうか？ 16F628Aは発振周波数を調整するレジスタは無いと思います。 16F88にはOSCTUNEという調整レジスタがありますね。 ===== ポートの入出力がおかしい件はどうなったのでしょう？最初タイマー割り込みを使って、シリアルが動かなかった原因はなんだっのでしょう「ｘｘしたら動作した」ではなく「ｘｘが原因で動かなかった、その問題点を解決するためにｘｘをした」と明確にしておかないと、実は本質的な解決ではなくまた別のところで問題がおきかねませんよ。

Re: 受信割り込みがからない

投稿者：naga64 投稿日：2009年 7月14日(火)20時24分48秒

返信・引用

> No.194[元記事へ] kugaさんへのお返事です。こんばんわ。回答ありがとうございます。関連キーワードは全て同じ用に設定されています。また、fast_io（）も設定していますが、ICD２でブレークかけても飛んでこないし、ブレイクの代わりにLEDを光らせるようにしても飛んでこないので光らないのです。それで、受信割り込みについてはまたの機会にすることにしました。結局、タイマー１とメインループ内で受信することで、なんとか出来たのですが、当初の９６００ｂＰＳにするとデータがかならずどこか数ビットずれてしまいます。４８００ｂｐｓにすると文字化けは起こりません。それで、４ＭＨＺを調整（公正）したら９６００でも取れるようになるのではと思いました。内蔵のクロックをキャリブレーションするには、どこの値を変更すればいいのでしょうか？６２８Ａはキャリブレーションは出来るマイコンでしょうか？また、教えていただけると嬉しいです。 > naga64さんへのお返事です。 > > > nekosanさんへのお返事です。 > > こんばんわ。返事ありがとうございます。 > > 色々やっていて気が付いたのですが、コンパイルされた内容に誤りがあることがわかりした。ＣＣＳ－Ｃのコンパイラがおかしくなってるのかわかりませんが、たとえば、ポートの入出力の設定がＩＣＤ２で見るとソースと違ってたりします。もしかしたらＩＣＤ２が壊れてるのかもしれません。ただ？秋月のライタで焼いても換わらないので、Ｃコンパイラが間違ったコードを出してるような気がします。 > > 友達に聞いたら「最適化」されてないのではないかと言われたのですが？ＣＣＳ－Ｃコンパイラではそのような設定があるのでしょうか？ > > > 過去に CCS-C V3.174 と 16F628 で UARTの受信割り込みを利用した装置を作りました。 > > ==関連キーワードです > #use delay (CLOCK=4000000) //内蔵クロック 4MHz > #use rs232(BAUD=19200,XMIT=PIN_B2,RCV=PIN_B1)　//USARTの使用宣言 > #int_rda //受信割り込み関数エントリー指示 > enable_interrupts(INT_RDA); //受信割り込みの許可 > enable_interrupts(GLOBAL);　//グローバル割り込み許可 > > ポートの入出力がソースと違う件ですが > #use fast_io(B) > でポートの制御条件を設定していますか？ > デフォルトでは、input,output命令で自動的入出力方向を設定する(TRISを制御)コードが生成されます。 > 私は、この処理を「余計なお世話」と感じるので、いつもポート全部に#use fast_io()設定し、set_tris_で入出力設定しています。

Re: 受信割り込みがからない

投稿者：kuga 投稿日：2009年 7月12日(日)18時30分13秒

返信・引用

> No.192[元記事へ] naga64さんへのお返事です。 > nekosanさんへのお返事です。 > こんばんわ。返事ありがとうございます。 > 色々やっていて気が付いたのですが、コンパイルされた内容に誤りがあることがわかりした。ＣＣＳ－Ｃのコンパイラがおかしくなってるのかわかりませんが、たとえば、ポートの入出力の設定がＩＣＤ２で見るとソースと違ってたりします。もしかしたらＩＣＤ２が壊れてるのかもしれません。ただ？秋月のライタで焼いても換わらないので、Ｃコンパイラが間違ったコードを出してるような気がします。 > 友達に聞いたら「最適化」されてないのではないかと言われたのですが？ＣＣＳ－Ｃコンパイラではそのような設定があるのでしょうか？過去に CCS-C V3.174 と 16F628 で UARTの受信割り込みを利用した装置を作りました。 ==関連キーワードです #use delay (CLOCK=4000000) //内蔵クロック 4MHz #use rs232(BAUD=19200,XMIT=PIN_B2,RCV=PIN_B1)　//USARTの使用宣言 #int_rda //受信割り込み関数エントリー指示 enable_interrupts(INT_RDA); //受信割り込みの許可 enable_interrupts(GLOBAL);　//グローバル割り込み許可ポートの入出力がソースと違う件ですが #use fast_io(B) でポートの制御条件を設定していますか？デフォルトでは、input,output命令で自動的入出力方向を設定する(TRISを制御)コードが生成されます。私は、この処理を「余計なお世話」と感じるので、いつもポート全部に#use fast_io()設定し、set_tris_で入出力設定しています。

以上は、新着順51番目から60番目までの記事です。

2 3 4 5 6 7 8 9 10 11 | 《前のページ | 次のページ》