ああもう! 11件の返信 かなり簡単なプログラムを組んでいるのに、各所でデータ破壊が起きておおあばれ ああもうああもう、わけがわからん。中はどうなっているんじゃ~ 覗くには JTAGICE なるものが必要らしい。 要るかな、要るかな デバッガのない今、一から組みなおしたほうが早くないかこのじゃじゃ馬プログラム? 普段の UNIX プログラミングがどれぐらい手厚く OS に守られているかよくわかりました。
Gan 投稿作成者4月 18, 2009 2:39 PM 一番うまく行かないのは、スタティック変数経由で割り込みハンドラとそうでない関数間で値の受け渡しをするところです。何かクセがあるのだろうか?データ破壊の過程が追跡できれば何とかなりそうなのですけれどもね。今は推測するしかなくて、大変な手間です。
Gan 投稿作成者4月 20, 2009 8:00 PM 1週間ぐらいマイコンに翻弄されて、やっと少しずつクセがわかってきました。 volatile は、さすがにやってありましたが、AVR ではまったのが – プログラム中で大きな配列を使うと、何故かスタティック変数が壊れたりする – eeprom のデータは、プログラムを書き換えると一緒にクリアされてしまう この二点が、考えていたものと実際と動きの違ったところで、状況がわからなくなって混乱していました。 ここがわかってプログラムが暴れなくなったのと、GIT を導入して安心してプログラムを「壊せる」ようになって、作業が大分楽になりました。 でも、やっぱりマイコン内でブレークポイントを設定できたり、1クロックずつ実行できたりするとうれしい気がします。デバッガの使い方も覚えてゆきたいと思います。
アルゴ算法堂 4月 20, 2009 10:17 PM 解決されて、何よりですね。さすがに、volatileは無かったですね。 大きな配列というのは、制御用の小さいシステムだと、結構、色々あるようです。 シミュレータは、あまり、うまくありませんか?(AVRのシム、本気で使ったことが無いので)
Chuck 4月 28, 2009 4:42 AM > – プログラム中で大きな配列を使うと、何故かスタティック変数が壊れたりする これは経験がないですが、どういう現象ですか? AVRのシミュレータは、デバイス品種によって実装されていないペリフェラルがあります。ヘルプに書いてあります。
Gan 投稿作成者4月 28, 2009 8:17 AM ええと、これは、長さが100を超えるような配列を使って、プログラム中のデータ領域を90% 以上使ってしまうと、割り込みハンドラとメインプログラムの間で値を受け渡しする変数が壊れてしまい渡らない、という現象です。宣言は static volatile にしてありました。volatile を外すと挙動は変わるがそれもまた誤動作、ということでかなり苦労しました。
Chuck 4月 28, 2009 10:12 AM ああ… SRAMが128byteしかないので、100ワードも .data や .bss セクションにとってしまうと、heap や stack が足りなくなってプログラムの挙動がおかしくなることは往々にしてある話です。stack overflow とかを吐いてくれませんので… http://www.nongnu.org/avr-libc/user-manual/malloc.html ROMテーブルだったら、.text セクションに置いて使うようにすれば SRAM使用を節約できます。
Chuck 4月 28, 2009 10:21 AM > 一番うまく行かないのは、スタティック変数経由で割り込みハンドラとそうでない関数間で値の受け渡しをするところです。 関数コールで戻りアドレスをスタックに積んだら、そこは .data/.bssセクションとして静的変数をマップした領域だった。それゆえ参照したかった値を壊してしまった ということでしょうね。
Gan 投稿作成者4月 28, 2009 3:50 PM なるほど、WinAVR のメモリのマッピング方針、マニュアルに出ていたのですね。 マニュアルにもお互いの領域を侵さないように気をつけてプログラミングしろ、と書いてありますね。 ロジックだけのプログラミングにない難しさなのであります。大変だあとは思いますが、考えてみると、こんなスペックのマイコンが100円で使えるというのは、Z80 の時代などから比べるととんでもないシアワセなはずなのです。
一番うまく行かないのは、スタティック変数経由で割り込みハンドラとそうでない関数間で値の受け渡しをするところです。何かクセがあるのだろうか?データ破壊の過程が追跡できれば何とかなりそうなのですけれどもね。今は推測するしかなくて、大変な手間です。
Cで組まれているのだと、変数にvolatile修飾が無いとか?
そんな単純な問題ではないのかな。
1週間ぐらいマイコンに翻弄されて、やっと少しずつクセがわかってきました。
volatile は、さすがにやってありましたが、AVR ではまったのが
– プログラム中で大きな配列を使うと、何故かスタティック変数が壊れたりする
– eeprom のデータは、プログラムを書き換えると一緒にクリアされてしまう
この二点が、考えていたものと実際と動きの違ったところで、状況がわからなくなって混乱していました。
ここがわかってプログラムが暴れなくなったのと、GIT を導入して安心してプログラムを「壊せる」ようになって、作業が大分楽になりました。
でも、やっぱりマイコン内でブレークポイントを設定できたり、1クロックずつ実行できたりするとうれしい気がします。デバッガの使い方も覚えてゆきたいと思います。
解決されて、何よりですね。さすがに、volatileは無かったですね。
大きな配列というのは、制御用の小さいシステムだと、結構、色々あるようです。
シミュレータは、あまり、うまくありませんか?(AVRのシム、本気で使ったことが無いので)
AVRStudio に付属しているシミュレータは、割り込みを使うとあまりうまく動いてくれません。私の使い方がまずいのかもしれませんが。
> – プログラム中で大きな配列を使うと、何故かスタティック変数が壊れたりする
これは経験がないですが、どういう現象ですか?
AVRのシミュレータは、デバイス品種によって実装されていないペリフェラルがあります。ヘルプに書いてあります。
ええと、これは、長さが100を超えるような配列を使って、プログラム中のデータ領域を90% 以上使ってしまうと、割り込みハンドラとメインプログラムの間で値を受け渡しする変数が壊れてしまい渡らない、という現象です。宣言は static volatile にしてありました。volatile を外すと挙動は変わるがそれもまた誤動作、ということでかなり苦労しました。
ああ…
SRAMが128byteしかないので、100ワードも .data や .bss セクションにとってしまうと、heap や stack が足りなくなってプログラムの挙動がおかしくなることは往々にしてある話です。stack overflow とかを吐いてくれませんので…
http://www.nongnu.org/avr-libc/user-manual/malloc.html
ROMテーブルだったら、.text セクションに置いて使うようにすれば SRAM使用を節約できます。
> 一番うまく行かないのは、スタティック変数経由で割り込みハンドラとそうでない関数間で値の受け渡しをするところです。
関数コールで戻りアドレスをスタックに積んだら、そこは .data/.bssセクションとして静的変数をマップした領域だった。それゆえ参照したかった値を壊してしまった ということでしょうね。
あ、「SRAMが128byteしかない」は、前後の記事から ATtiny2313 でのトライアルと考えてそう書きました。
なるほど、WinAVR のメモリのマッピング方針、マニュアルに出ていたのですね。
マニュアルにもお互いの領域を侵さないように気をつけてプログラミングしろ、と書いてありますね。
ロジックだけのプログラミングにない難しさなのであります。大変だあとは思いますが、考えてみると、こんなスペックのマイコンが100円で使えるというのは、Z80 の時代などから比べるととんでもないシアワセなはずなのです。