AVRマイコン総合スレ Part10

>>950
前PICで似たような外付けFPUで結局あまりに演算遅くて意味ねぇ〜ってのがあったけど・・・・
これはどうなんだろ？datasheetを見たらレジスタ転送にそれぞれ数μsec、乗算数μsec、除算18μsec、
対数や三角関数は100μsec以上かかるようだが。
プログラムメモリと高速クロックさえあれば、中で演算してもあまり変わらない予感。
対数や三角関数、FFTを扱う必要があれば少しめりっとあるのかな？

多分浮動小数点演算を高速化すると言う目的で
使うものじゃないと思う。
それよりも、実数演算が沢山必要だけどプログラムメモリは
節約したいというときに使うものじゃないかなあ。

>>953
なるほど。

AVRを２つ使って、片方には最適化した演算をさせるようにしたらけっこういけるかもね。
演算というよりパラメータがそれほど多くない、並行して演算したら便利な関数を任せちゃうとか。
うまく並列できるように最適化するとか。

>>954
SPIとかじゃ、2つのAVR間の通信に、数百μかかりそうなヨカン。それとも
共有メモリとか搭載しているAVRとかあったっけ？

共有アクセス可能なRAM領域を内蔵したマルチコアのAVRとか使うより、
そういうのが必要な用途なら、素直に32bitMCUへ移行した方がお得な
気がする。32bitでより高クロックでも、少ピンパッケージならAVRと
値段的に変わらないデバイスも増えてきているし。

計算能力が必要な用途なら、AVRで小細工したりしないでARM使うなあ。

ところで、ARMがどんどん安くなってきたせいで安価が売りだった8bitマイコンの
牙城を崩しつつある。
この先どうなるAVR？

>>955
うん、だからパラメータが多くない関数限定。
複数演算を組み合わせてデータやりとりのオーバーヘッドは極力減らして。
定数とかはあちらにもたせて送信しなくてもすむように。

でもまあそんなことするくらいなら速いMPU使え！
というのはその通りでございますm（＿　＿）m

AVRで作るスーパーコンピュータ！
とかの企画モノっぽい工作に使うのだ。

I/Oでパラレルデータで転送すれば手間も時間も掛からんと思うが？

>>959
何らかの計算をさせるとして、データが仮に倍精度浮動小数点(8バイト)
だったとして、少なくとも2つ以上の引数と1つ以上の結果を受け取るわけだ。
行きと帰りで計24バイト。

FIFO内蔵の双方向バッファがあるならともかく、パラレルだろうが、割込
使ったりフラグ見ながら、ちんたら転送してたら、転送処理だけで数百μs
かかってもおかしくない。

仮に24バイトの転送時間が合計300μsでも、1バイトあたりの転送時間は
12.5μs以下でなければならないので、割込処理してもかなり厳しいだろう。

>>960
アドレス情報をなしにしたシリアル転送で隣接チップ間とかなら問題ないのでは？
SPI準拠というかTWIで400kbpsならバイトあたり5μsecですよね？
それと、計算の方を数msecかかるようなものを任せるとか。

データ出し入れについては、多少の効率を諦めれば大丈夫じゃないかな。
相手がBUSYの間は素直に待つ、BUSY解除なら一気にTWIでデータ送っても大丈夫。
最初のデータで処理指定と続くパラメータ数を指示すればいいですよね。
読み出し時もBUSY解除確認でTWIマスター側のペースでできるし。

自分に突っ込む
アドレス省略したら占有になるだろ？
んなもんに貴重なハードウェアシリアル機構を使うな？
はい、おっしゃるとおりです・・・orz

似たような話が出たときも、結局はCPUの性能を上げたほうが
簡単だという結論だった。IOポートが足りないとかならチップを
追加でも問題は少ないが...

そうだ８０８７を繋ごう

>>961
ぼけてた。TWIって書いてるの全部SPIね・・・

SPIもTWIだからきにすんな！

全然違うような・・

tiny45やtiny26で可能な、高周波数のPWM出力(250kHz PWM出力)が可能なmegaシリーズってありますか？
乗算命令と高周波数PWM出力の両方が欲しいのです…

>>967
megaでtiny45とかを制御しちゃえばいいじゃん

>>961
これなんてどうよ
ttp://www.sparkfun.com/commerce/product_info.php?products_id=8129

>>969
話の始まりはそもそも>>950

>969
Noの通りループしているなw

>>951
ちょこっと勝手にイジってみた。

もうちょっとやりたかったけど
認証エラーになって新しいファイルを作れない。

トップがごちゃごちゃしすぎているから、
古い最新情報を別ファイルに持っていきたかったんだけど。
2006年の最新情報とか誰も見てないと思うんだよね。

>>972
だな。
Getting start noteとlibcをメニューに持ってきて、後は砂箱の中のAVRspxをメニューに持ってくれば
だいぶ使いやすい感じになる気がするがどうだろうか。

早く！早く次のスレを！

次スレ

よろしくお願いします・・・

>>976
１つ１つデータシート見て確認しろ。
それで解決できるものを他人に聞くんじゃない。

AVRとPIC、初めて始めるならどちらから？

>>978
難しいね。書籍でもネットでも応用例が多く手に入りやすいのはPIC。
でも動作が理解しやすいのはAVR。
これはPIC16系とAVRの話ね。PIC18系はわからん。

マルチだな

趣味で使うだけならAVR+BASCOMが簡単で、ネットで詳しく解説してあるのでお勧め。
ライタもPICと違ってUSBインターフェースのが容易に自作できる。

と、PICアセンブラから乗り換えた俺が言ってみる

>>978
MSP430

>>978
Cで書きたいなら（っていうか、PICのアセンブラ体系は苦行でしかないので
パズル感覚でやるならともかく、オススメしない）PIC18系がいいと思う。
Cコンパイラあるし、PICKIT2あるし。

PIC18はPIC16と基本的に変わらない。Cにまで及ぶ制限も健在。

これからPIC始めるなら24系がいいよ。無料で使えるC30(gcc)もあるし。

PIC使うなら半年待ってPIC32がいいんじゃないか

ってか、もうARM系で良いだろ…

ARMでDIPあればいいな

>>978
MC6808がいいぞ。

おまいら段々「初心者に適したマイコン」から「最強最高のマイコン」話になってるぞ（ｗ

初心者にARMとかMIPSとかってどんだけー。
素直にAVRでいいとは思うぞ。

初期投資だけならHC*08とかMSP430も向いてるし（純正プログラマが~3000円）
ありだけど、チップコストとバリエーションまで含めるとPIC/AVRに結局なるかな。
そんでもってPICの「バリエーション」は悪名高い16F/18Fまで含めての話だから
AVRがお勧め、ってことになる。

ﾜﾗﾀ

ネタなのにー

>>984
C18は、最適化（あんまり気にならない）が60日で外れるけど、FREEでしょ。
PIC16系で、MicrochipのCコンパイラのフリーなやつって無いんじゃ？
HITECCは、種類が非常に限られるし。
SDCCっていうのはあるけどｗ

最適化なしのC18はちょっとねえ…
関数呼び出しがちょっと多くなるともう全然だめ。

SDCCに期待かな。

AVRでいいじゃん。

>>993
その「最適化」なんだが、「最適化無し」じゃなくて「最適化レベル１のみ」なんだよ。
だから全く気にしなくてよい、っていうか、最初から最適化レベル１で作っておけば
60日後も結局変わらない。

AVRでいいじゃんっていうのは、全くもってそのとおり。

新スレ立ててみます

AVRマイコン総合スレ Part11
http://science6.2ch.net/test/read.cgi/denki/1212840469/

立てました

いますぐPICをやめてAVRに移行すべき10の理由
ttp://d.hatena.ne.jp/yaneurao/20080228

>>997
スレ建て乙

0x1000

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。