AVRマイコン総合スレ Part38©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
>>139 元々ロジックIC の代用、見たいなコンセプトのマイコンに負けてるのがAVR >>155 Pinguinoについてはそうだけど、chipKITの方は、 Arduino IDE に chipKIT core というプラグインを 導入して使う形に変わった。 本家IDEがARMやインテルなどAVR以外のアーキテクチャに 対応するようになったので、その仕組みを利用しているらしい。 現在AVRmkUとAtmelStudio7.0で開発を行っているものです。 秋月で売られているICE-BASICの導入を考えているのですが、 これはattiny,atmega,atxmegaといったAVRシリーズ全てのマイコンのデバックができるのでしょうか? 逆に、これがないとデバック(ステップ実行や実行中にレジスタの中身を覗く等)は出来ないのですよね? 秋月にはbasicしかないですが、いろいろ種類が有るみたいで。 どなたかICE BASICで出来ること、出来ないことを教えていただけませんか? 使ったことがある方がいましたら、使用感なども教えていただきたいです。 >>158 デバックするなら、atmel iceやavr dragon等が必要 atmel iceには基板のみ、ケース付き、変換基板付きと数種類ある ピンがハーフピッチなので1.27mmから2.56mmに変換する必要がある ベーシックにはその変換ケーブルが付属する avr dragonは更に高電圧ppなどの書き込みができる ネット上では、電源用icとバッファが弱いとなっていて、usbから直接5vをとる 方法や、isp、jtagを強化する方法が公開されていて、ドラゴンレイヤー2と言われている 誤配線に注意し、ターゲットは必ず別電源を使用していれば心配ない >>158 arduinoをデバッグするときは、リセット端子のコンデンサを切断する デジキーも送料無料になれば、秋月より安い場合があるかな 毎度¥7500以上買えばいいじゃないか古事記 >>157 >Arduino IDE に chipKIT core というプラグインを >導入して使う形に変わった。 それはいいな。 デバッガを自作すれば最強だよ。 まぁそれなりの別の問題が発生するけどw ATATMEL-ICE(フルキット)とATATMEL-ICE-BASICの違いは オプションのケーブルや変換コネクタが含まれているかどうかだけで機能に違いはない。 ユーザーマニュアルに写真付きで説明がある。 まあ、BASICで十分。 ICEもドラゴンも長いこと使ってるが壊れたことないなあ。 オシロあれば十分デバッグできるでしょ PWMの出方とかステップ実行なんてやっても判らないし そりゃあんたがデバッガを必要とするような事をして無いからでしょ。 世の中にはもっと難しい事してる人がいっぱいいるんだ。 すまん、ちょっと勘違いがあったようなので修正する。 そりゃあんたがデバッガを使いこなせないからでしょ。 PWM出力の遷移にブレークポイントしかけりゃどんなタイミングの波形になってるか分かるし。 それにオシロの方が高価なんだが。 外部との通信やI/O制御やるならオシロがあったほうがいい。 デバッガはどうかな?仕事だとブレークポイント設定して放っておくとかあるけど、趣味ではそこまで必要としない。 FFTとかファイルシステム組み込んだりフィードバック制御とか色々あるでしょ ソースコードデバックってアンブラの場合は凄く強力なツールだと思うけどC言語の場合は微妙じゃない? >>172 アンブラって何だよ・・・ アセンブラの間違いね なんだ、AVRとPICってもうちょっと拮抗してるのかと思ったら8bitの製品に関して言えば 話にならない位PICのほうが圧勝してんのか >>176 マイコンのコアとしては必要最低限を狙ったPIC に、性能で戦いを挑んだAVR 。 性能がとんとんしか無い上にIOが貧弱で勝負にならんかったw 次は、【PIC】Microchipマイコン総合スレ【AVR】かな アセンブラでAVRと8ビットのPICとAVRのプログラムを組んでみ コアの違いがよ〜く分かって面白いぞ DIOの処理をさせると処理速度の差が出すぎて・・・(PIC厨が発作を起こすので謹んで略) もっとも実際に仕事をするのはもっと複雑な周辺I/O処理なので PICが周辺処理専用機種=多機種の方向を目指したのは正しい選択だろうな AtmelがYmegaやZmegaを出せば話は変わるかもしれないが、買収されてしまったし 将来のことなんて神様でも無い限り誰にも分からない ただ一つ確実に言える事はいつかはPICもAVRもARMも、そして君も僕も終るってことだけだ アセンブラで書くとPICでなんの不自由もないのがよくわかる。 3桁とか6桁の速度差があるなら話は別だが、所詮どんぐりの背比べ程度の 差しか無い。その程度の速度で頑張ってソフトでUSBを実装しても、安定性が無いし 他の処理がまともに出来ないんじゃ意味がない。学生のオナニーみたいなもん。 インテルVSモトローラの時もそうだったが、頭でっかちでは生き残れないって事だな。 趣味で使っている人には分からないんだろうけど PICの強みは 「デイスコンしない」 これに尽きる ディスコンにかこつけて他の軽い変更もやっちゃうから 一概に悪とも言えない。 >>183 お前wそんなこと書くとwAVR厨様がw 「買い溜めしてあるからディスコンになっても別に困らないし(キリッ」 ってw言い始めるぞwww 「ディスコンしない」ということと 「いつまでも趣味レベルに人にも供給する」ということは違うよ。 製造業としては古すぎるものは適度にディスコンして欲しい。 メーカーとしても生産量縮小とかで原価アップされても困るからやっぱりディスコンしてくれた方がいい。 取り巻く環境で「ディスコン」の良し悪しもいろいろだ。 で、ここはAVRスレだが誰かAVRで困ったディスコンがあったか教えてくれないか。 未だに16F84とかの作例がWebにあるし、 16F88で今年書かれた作例見たときはびっくりした どうしてもAVRでなきゃってユーザーはPICほどにはいない印象 ここにいるのはアンチAVRだけで、当のAVRユーザーはもう他に行ってたりしてw 確かに、ディスコンではないが、性能比でずいぶんと割高にはなる。 にしても、入手できないよりはずいぶん助かる。 くっそ高い84Aが、1827のすぐ後につけてるという事実は否定できない。 http://akizukidenshi.com/catalog/c/cpicr_spop/ 累計販売数順に並べれば昔から扱ってる品種が上位に来るのは当然だと思うが? たとえ最近の売り上げがそんなにないとしても むしろまだ取り扱いを初めて日が浅い16F1827や12F1822が早々に上位に来てる ことを見ても、この人気順ソートが殆ど意味が無い事は確定的に明らか >>192 1827や1822が売れてるってこと。 現に、最近84Aは1827に抜かれた。 何も矛盾点は無いし、意味が無いことはない。 >>183 お前ホントにプロか? CPUボードをユーザーに提供しているなら 適当な間隔で世代交代してくれないと困るだろ? CPUボードはCPUだけで出来ているわけでは無い うちの客に困ったチャンがいてな・・・(前にも書いたので省略) >>118 製造業としては古すぎるものは適度にディスコンして欲しい。 の言う通り いや製品の能力がバラつく事の方が困るだろ。 設計製造、いや一番困るのはサービス部門かも 客も用途によってはそんなの嫌がるよ。 プロなら製品の能力がバラついたりはしない 要求される仕様は必ず継承する 追加した便利な機能に客も泣いて喜ぶw 脳内プロは黙ってて あんたの製品ってMCUが一つポツンと載ってるだけなんだろ? やだ、お父さんの長さ16cm太さ5cmのズルムケチンポ 小学4年生の血のつながった娘のお膣のなかでザーメンドプュゥッって出したいって PICPIC言ってるw 商品世代交代にCPUを絡めるなんて、、、アホと違うの? >>197 プロはバラツキを考慮して、仕様内に納まるように設計するってだけで、実在の部品を使う限り、バラツキは必ず発生する。 また、発作を起こしたのか、困った奴だな 「小学生の娘〜父さん」シリーズは飽きた いいかげん心療内科へ行けよ atmel studio 7 のdebugですが 例えば、5秒ごとに自動でステップする設定ないですか? 新石の情報探してたら、0.7V動作の石があるって知ったけど DIPが300milで はぁ? それなに? CPUが0.7Vで動いても、周辺が動かないような気がするし 用途って何ですかね? >>211 レスありがと でもLEDさえ光らないよ そんなことより、 >DIPが300milで はぁ? それなに? ってどういう意味? >>213 20pin300milと読んで、脳内に600milのイメージが浮かんで、何だこのデブって思ってしまった >>212 周辺まで0.7Vで動かすわけじゃないから・・・・ コアとIOは1.8V以上だし。 GCCだと64KB越えの外部メモリアクセスってまともには扱えないのね・・・・ あ、そうなんだ。 GCCでアドレス拡張レジスタ操作してくれる命令教えて。 やり方わからんからアセンブラでサブルーチン作ってアクセスしてる。 8bitCPUで64KBオーバをまともに扱えるようにしろと言われもな >>219 処理単位とアドレスの違いも判らんのか。 その理屈なら8ビットマイコンでは256バイトしか扱えんな。 データバスとアドレスバスという言葉も知らん奴に言われもな キミの理屈で彼に64kbOverを8bitCPUでGCCでまともに扱える方法を教えてやれよ 256KBのROMや24bitアドレスバス持ってるAVRの話をしてるんだがな・・・ アセンブラでは普通にアクセスできるものをGCCではどう書くのかって話であって、 バスがどうしたって話じゃないんだよ。 >>222 フラッシュ上の話なら far ポインタが扱えるマクロを使用すると思うけど pgm_read_byte_far()とか それにしても far なんてMS-DOS時代のCコンパイラを思い出すなぁ あ、話の分かる人がいた。よかった。 そう、farポインタを使いたいんですが、XYZレジスタに拡張アドレスレジスタを連結した後、 別の用途にそのレジスタを割り当てる場合に拡張レジスタをリセットしてくれないので、 とんでもないアドレスをアクセスしてしまいます。 ポインタを使ったCのコードだとレジスタなんて意識しないので制御のしようが有りません。 AVRlibcのドキュメントを漁ってるんですが、64KB越えの書き方とか見つけられなくって・・ atmegaで電子工作をしているものです。 uint8_t型の変数をインクリメントし続けて、オーバーフローした場合、0に戻ると思いますが、 その際uint8_t型で確保した部分以外のメモリに影響は出てしまうのでしょうか? >>216 は曖昧すぎて、何を意図してるのか不明なんだよ もし、64KB越えのFlash-ROM上のデータを得たいと言う事なら↓でどうだ data = pgm_read_byte_far(GET_FAR_ADDRESS(v)); >>224 ごめんなさい。これ以上の情報は持ち合わせていないのですよ… そこまで込み入ったプログラムを書いた事が無くて 興味がある話なので少し調べてみます。有力な情報が入ったらここに書き込ませて貰いますね。 >>225 その変数が割り当てられてる1バイトのメモリだけが変化しますよ >>226 あっ! GET_FAR_ADDRESS() 完全に忘れてました。横からですがありがとうございました。 当時、糞と言われたfarが使いたいと言ってるんだから 8086でいうラージモデルで組みたいってことだろう。 >>225 例えばこんなアセンブラコード lds r0,X+ これをXが0にオーバーフローするまで回すと拡張アドレスレジスタが+1されます。 次に別のコードでXレジスタに0x2000(内部RAMの先頭アドレス)を入れ直して同じコードを実行したとしましょう。 その時、レジスタr0には0x012000(外部メモリアドレス)のデータが転送されます。 CPUはアドレスの第3バイトである拡張アドレスレジスタを必ず使用するのに、 コンパイラの出力したコードはXHとXLのみの16bitしかセットしてしません。 DMAドライバとかはアドレスの第3バイトまで意識したコードで作られているので、 アドレス空間が24bitでも正常に動くコンパイルオプションがあるのかなと思うのですが、 それがわからんのです。 マクロやサブルーチンでアクセスしようにも、割り込み処理でnearポインタを使った転送をされると、 拡張アドレスレジスタのおかげで結果がおかしくなるため、いちいち割り込み禁止をかけなければなりません。 ただ1MbitのSRAMをバッファに使いたいだけなんだけどなあ。 >>230 AVRの外部メモリアドレスポインタって24bitのものが有るのですか? データシート読んでみたいので具体的な型式を教えて下さい 確かに >>216 で外部メモリって表現されていますね 勝手に内部フラッシュの事だと思い込んでレスしてました。重ね重ね申し訳ござません >>233 AVR=8bitってイメージが強すぎてAVR32の事は全く考えてませんでしたよw AVR32使うならARMコア搭載のマイコンの方が良いっていう声が多いですよね >>231 xmegaA1Uです。 基板作っちゃったけど、外部メモリ用のアドレスラッチをソフトで制御して、 内部空間64KBでやれば私の場合は何とか問題解決なんですけどね。あ〜めんどくさい。 PICでもR8でも問題は同じだけどどうやってるんだろう・・・ ARM使えとか言われそうだけど、バッファが要るだけで処理はしょーもないものなんで、 回路設計段階ではこんな苦労全く予想してなかった。 > ?RAM larger than 64 KiB is not supported by GCC for AVR targets. ドキュメントに書いてあるな。ご苦労さん。 8bitCPUのアドレスバスが基本16bitということ知ってたら苦労しなくて済んだのになwww 馬鹿めw >>235 xmegaですか。なるほど確かに仕様で24bitの外部アドレス空間をもっていますね ですがGCCが16bit超えの外部メモリアドレスには未対応みたいです https://gcc.gnu.org/onlinedocs/gcc/AVR-Options.html 既にご自分で対応策を施しているようなので、このまま開発を続けて良いと思いますよ 今回は私も色々と勉強になりました。逆にありがとうございました >>236 ああ、わざわざ調べてくれてありがとう。 なんだかんだ言って優しいんだね。その1行が見つけられなかったんだ。 “XMEGA” devices with more than 128 KiB of program memory and more than 64 KiB of RAM. mcu = atxmega128a1, atxmega128a1u, atxmega128a4u. とか書いてあったけどその下とはね。 IARではできるらしいんだけど残念。 >>237 もありがとう。 あ、だけど>>236 さ 『基本16bit』って自分で書いてるんだから『絶対16bit』なんて思い込みで書いちゃいけないよ。 xmegaは24bitアドレスサポートしてるけど、GCCは未対応だからごめんねって書いてるんだ。 そんなことわかりきってるから調べたけど、見つけられなかったのは私の間抜けw avr-gccは色々おかしいからあんま期待してはいけない 要望出すぐらいはした方がいいんだろうけど AtmelStudioでBuildするときに出るメッセージのDataMemoryUsageがSRAMの領域ですよね? スタックオーバーフローってSRAM領域に十分な空きがあったとしても起こりますか? とある関数を呼んでreturnするときに、異常動作が起こります。 その関数内では比較的大きな配列を宣言しており、この配列の要素数を減らすと正常動作しました。 したがってスタックオーバーフローが起こっていると予想しているのですが、DataMemoryUsageでは相当余裕があります。 スタックオーバーフローが起こる原因、またその対策をよろしければ教えてください。 そのDataMemoryUsageは関数内の変数は見積に入ってない 例えば関数が再帰呼び出しされていた場合、実行前に正確に見積もれるだろうか ちょっと考えれば判ることだと思うが >>243 すみません、言い方が悪かったようです。 SRAMの空きが2kバイト程度あります。(DataMemoryUsage) その関数ではchar c[256]と宣言しています。 このようにSRAMの空きが十分であると予想される(自分はそう思っています)にも関わらず、 スタックオーバーフローが起こるのはなぜか、ということでした。 再帰呼び出しは行っていません。配列の要素数を例えば64にすると正常動作となります。 ローカル変数で確保できる領域等がレジスタで設定出来たりするのでしょうか。 データシートを眺めた感じではスタックポインタを設定するレジスタはありましたが・・・。 >>244 関数呼ぶとき戻り番地をスタックにセーブするし、呼び元で変数として使っているレジスターを関数内で使っていればそれもセーブする。コンパイルのあとにできるアセンブラリスト見ればどうなってるかみられるからみてみれば。 > xmegaは24bitアドレスサポートしてるけど、GCCは未対応だからごめんねって書いてるんだ。 馬鹿かこいつ。 >>244 リンカ設定でheap領域が確保されてて、c[256]のときはそこに スタックが食い込んでるってことない? それなりに期待できそうな事が書いてある…が 安心するには程遠いという感触 あのロゴが有るだけでPICにしか見えなくなるってのに… だいぶ侵食されてきたな >>244 オプションとかで、スタック領域の割り当て増やすとか出来ないの? ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる