AVRマイコン総合スレ Part46
■ このスレッドは過去ログ倉庫に格納されています
AVR ISP mkIIってXMega書き込めないのか。 , -‐−-､ ヽ∧∧∧ // |
. /////_ﾊ ヽ＜ 釣れた！＞ ハ
ﾚ//ｊ け ,fjlﾘ / ∨∨V ヽ h. ﾟl; ← >>6
ﾊｲｲﾄ､"ヮノﾊ // |::: ｊ ｡
/⌒ヽヾ'ﾘ、 // ヾ､≦ '
. { j｀ｰ' ﾊ // ヽ∧∧∧∧∧∧∨/
ｋ〜'ｌ ﾚﾍ. ,r'ス ＜ 初めてなのに ＞
| ヽ ＼ ト､ ヽ-kヾｿ ＜ 釣れちゃった！＞
. l ＼ ｀ｰ‐ゝ-〈/´ / ∨∨∨∨∨∨ヽ
l `ー-､___ﾉ
ﾊ ´￣｀ 〈/‐-､
↑
>>5 スレと関係ないんだけどさ、俺「釣り」とか「釣り師」っていうのは、
釣り師 ↓
. ／| ←竿
○ ／ |
. （Vヽ／ |
＜＞ |
ﾞ'ﾞ":"''"''':'';;':,':;.:.,.,＿_|＿＿＿＿＿＿＿＿＿
|
餌（疑似餌）→.§ >ﾟ++< 〜
の組み合わせだと思ってたんだけど、
最近自称釣り師がダイレクトで自分の本音を攻撃されて「釣れた！」とか
言ってるの多いよね。
これは、どっちかというと、
,〜〜〜〜〜〜 、
|＼ （ 釣れたよ〜・・・）
| ＼ ｀〜〜〜v〜〜〜´
し ＼
ﾞ'ﾞ":"''"''':'';;':,':;.:.,., ヽ○ノ
~~~~~|~~~~~~~￣￣￣￣￣￣￣
ト>ﾟ++<
ノ）
かと思うんだけど、どうよ？ >>6
書けるけどAtmel Studioでは書き込めないってことね >>10
はて？
何年間もAtmel Studioでxmega128A1Uやxmega32E5に数えきれないほど書いてる俺ガイル。 ISP mkIIはUPDIに対応してくれないからクビにしたけど、
xmegaのPDIで書き込むのは何も問題なかった。よく働いてくれた。 SNAP+AVRDUDEだとインストールすら要らないし全てのAVRに書き込める >>14
しかしsnapのファーム更新とAVRモードへの切り替えにMPLAB X IDEが必要という罠が。
UPDIで使うなら小改造も必要。 割り算やら掛け算やらさせてUSBで取りたいんですが乗算命令のないAT90USB162じゃ無理ですか？
おうちにいっぱい余ってるのでできれば使いたいのですがATmega32U4買わないと厳しいですかね AT90USB162で乗除算が無理かって？
そんなわけあるか！
乗算器があれば高速ってだけだ 私は昔、「アセンブラによる高速演算技法」（Don Morgan著、アスキー出版局）という本で
数演算を勉強して、例題として使用しているCPUの演算パッケージを作ったことがある。
この本の各章の内容は
数字、整数、実数、浮動小数点計算、入出力と変換、
初等関数、疑似乱数テーブル、数値データテーブル
古本屋にいけば見つかるかもしれない。もちろん別の本でも構わない。 整数ならなんとかなる。
掛け算は結構簡単。
仮に R16 x R17 を R18 に求めるなら、
LDI R18, 0 ; 答えを初期化
LP1:
SBRC R17, 0 ; 掛ける数の 1bit目 が 0 なら次をスキップ
ADD R18, R16 ; 答えに掛けられる数を加算
LSL R16 ; 掛けられる数を 2倍に
LSR R17 ; 掛ける数を半分に(2進数で桁をずらして 1bit目に次の桁を持ってくる)
BRNE LP1 ; R17 が 0 じゃなったら繰り返し
みたいな感じ。
2進数で筆算をしてる感じ。
R16 と R17 は壊れる。
↑はロジックを示すため答えが 8bit に収まる場合のみのコードだけど、多バイトになっても考え方は一緒。
割り算も筆算式でやることになると思うけど、もうちょっと面倒。 Cで書けばいいだけだろ。
XXX * YYYとか
XXX / YYYとか
だれでもやってるわ。 必用な桁数（ビット数）の演算をアセンブラで作れば、小さくて早い演算ルーチンが出来る。
場合によってはBCDで演算するのも、メモリが少ないCPU、制御用のCPUには有効。 思い出したけど、残念ながらAVRにはBCD演算（補助）命令が無いんだよね。
たとえばADD(バイナリ加算）とDADJ（10進補正）の2命令で済む2桁の10進加算が、
なんとAVRでは19命令（AVR204:BCD Arithmetics)も必用になる。
ツライ・・・ｗ ど〜でもいい。
AVRでキツイならARMでも何でも行け。
そんなスペックの要らない用途もいっぱいある。
フルアセンブラじゃないと処理速度やメモリが足りないんなら選定時点ですでに間違ってる。 なんかあっちこっちのスレでルネサスマニアが荒らしてる気がしてならない だいたい、今時10進演算なんてするのか？
表示装置なんて遅いんだから
2進で計算して、表示するときに10で割って各桁計算すればいいだけだろ 10なんて定数で割るのも乗算器があれば高速だしな
最近のtinyは乗算器積んでるし いろいろ間違ってる点
・そもそも乗除算器の無いコアでの話をしている
・計算アルゴリズムの話に C だのアセンブラだのの話は本質ではない
・ポテンシャルを引き出せずにスペックを上げるのは勝手だがポテンシャルを活かす話を否定することはナンセンス
・小さなアプリケーションだからこそフルアセンブラでも手に負える
・そしてフルアセンブラで書けという話でもない
んまあ一番目の出発点から間違ってるんだからなんともってところだな。 間違ってない点
・Cで書けば必要なコードが組み込まれ結果的に乗除算できるんだからそれでやれや >>36
そういうときに ARM に行けというやつと、計算方法を工夫して対応しようというやつがいるだけのことだよ へ〜floatが計算できないコンパイラがあるんだ。
世界は広いなあ FPUあるからと安易に浮動小数点を使うと遅くなるまである
加減算や乗算でも2〜3サイクルを消費するからな >>37
> 計算方法を工夫して対応しようというやつがいるだけ
そうだね、BCD計算なんか専用命令なくたってちょっとした工夫でどうとでもなるよね。
>>38
AVRにFPUなんか無いよ？ >>41
お前って何と闘ってるの？
ぼくちんの使えないあせんぶら使うとかなまいきなんだよー
みたいな？ 10進演算は遅い、特に乗除算は時間かかりそう
計算は2進演算で行い表示するときだけ10進に直した方が速いのでは？
小数点を使うなら100倍、1000倍、10000倍して計算すればいいだけ >>37
まあ、Cortex-Mくらいだと安いのもあるしな。
ARMな環境を作っておけば将来共々御役立ちではあるだろう。 Cotex-MつってもM0+/M23とM3とM4F/M33とM7じゃ全然違う M4Fは身近になったよな
STM32Nucleoでもラインナップ多いし
Arduino公式でもArduino Nano33BLEがM4F >>43
金計算とかするじゃなければ固定小数のバイナリ演算で十分だしね >>43
入力時の10進→2進、出力時の2進→10進変換作業が不要になるけど、
AVRには10進演算命令が無いから、最終的には遅くなると思う。
ま、演算内容によるか。10倍するのに×10の数値計算をする人は居ないだろうし。
疑問に思ったのだが、10進の4則演算命令を持つCPUなんて存在するのかな？
速度はともかく、データメモリ効率は確実に悪くなる。
ところでAVR使うならフルアセンブラをマスターしておいたほうがいいだろうな。
フルアセンブラなら書けるけどCでは書けないような仕様もある事だし。
色々と意見の食い違いはあるだろうけど、
「AVRは楽しい、面白い」では一致しているよね？ｗ
仲良くやっていきましょう。 >>49
IBMのpowerとか10進計算できるよ！ BCD演算のサポートなんて無かろうとファミコンはちゃんと10進数で数字を表示してたんだから 10進演算機能って2進や16進が理解できない低能向けゴマスリ機能じゃないの？
高級言語でサポートされる？ >>53
16進は十進の0.1すら表現出来ないから計算を繰り返すと誤差が蓄積する
一般的な使用なら16進でも大抵は問題ないけど一切の誤差を許さない金融計算とかは10進を使う ごめん、金融系の話は知ってる。
最近の8ビットワンチップマイコンでってこと。
まあ昔は8ビットマシンで運用してたからそのころのにはあるんだろうけど、
組み込み制御向けマイコンで必要なん？ うん、その具体的な用途を一つでも知りたいなあと思ったの。
BCD演算機能が無くてツライとか言ってる人がいるからさ、
なんでツライのか理解できる人がいるかと思ってね。 それも期待していないが期待している（どゆこと？）
だれかツライ実例教えてよ >>61 クロック数もバイト数も余計にかかるんだから、ある場合に比べれば無いのはつらいんじゃないの？できるかできないかの話ではないんだし。
BCDサポートがあれば簡単にできることでも、無いなら代わりのロジックでBCD計算するかバイナリで計算して割り算するわけでしょ。
単純に面倒じゃない？
何故BCDを使わなければならないかというか、それは手段であって目的ではないでしね。 x86 での話だけど、BCD補正命令を本来の用途で使ったことは無いけど、特定の値を得るために単に短い命令として使ったことはあるな。
ちょっと特殊なことしてて、プリンタブルなマシンコードだけを使ってできるだけ短いコードを作る必要があった。
このケースでは無いとつらかったかもw ・同じチップ
・既製のライブラリ等を使わずフルスクラッチ
・フルアセンブラ
みたいな条件限定じゃね？
面倒なだけでCortex-M7やRXv3みたいな多段パイプライン&スーパースカラで
武装し高クロックで回る最新のコア相手に性能面の優位性を示せるとは思えないわ >>67
んなことは百も承知だけど、そういう使い方を念頭に置いたものであっても中身は特定の条件で値を加工してるだけだから、たまたまその加工で欲しい値が得られるなら全然関係無いことに使うことだってできるって話ね。
>>65 のケースでは、x86 プロセッサで例えば AX レジスタの値が 0xEBAA だったのを 0xEC00 にするために AAA を使った。
見ての通り BCD と関係無い処理だけど、目標の値の 0xEC も 0x00 もそのまま即値代入するとマシンコードがプリンタブルにならないから何らかの演算によって目的の値を得る必要があった。
そんな時 x86 の AAA はマシンコード 0x37 で "7" だから選択肢として都合が良かった。
ということを、BCD補正命令が無いとつらかったこととして挙げてたのね。 そんな事言い出したら掛け算も割り算もいらない
足し算あれば引き算もいらないなってなるだろう >>68
４bitの16進を
daa
sub al,10h
cmc
adc al.40h
ってやるとASCIIになる >>69
あるものなら何でも使えばいいし、無ければ他の方法でやればいいんじゃね？
命令セットだけじゃなく内蔵ハードウェアについてもそうだよね。
ADC が無い製品でも条件によっては少しの外付け部品とソフトウェアで二重積分型ADCを構成できるかもしれないし、USART無くてもソフトウェアで書いたりするしね。
それを、そこまでして使うかと思うのも間違ってないし、それでやれてるなら充分と思うのも間違ってない。 さて、そろそろ「BCD演算機能なんて無くても特にツラくない」ってことでよろしいか？
おかしいなあ・・・ツライって言ってた人がいたのに・・・・ >>72
おれは USART 無くてつらいって思ったこと無いけど、辛いと言うやつがいても何とも思わんよ。
お前は BCDサポート無くても辛くないなら、それで良くね？ >>73
>>57の意図と違うな。
スレが伸びると本題忘れるものだね。 >>74
意図は単なる難癖だろ？
何のコンプレックスに触れたのか知らんが、くだらん コンプレックスか・・・
Bかっぷ
Cかっぷ
Dかっぷと、成長に伴いみなさまサポートが必要になるなか、
A「サポートなんて必要ない！(；∀；)」という悲痛な叫びだったのかもしれませんな(違 私は数値データをバイナリにするかBCDにするかパックするかしないか等は
プログラム設計時にデータ構造をどうするか検討して決めている。
この前、過去のAVRのプログラムを調べたら、BCD採用は10本に1本程度で少なかった。
理由として、多分、AVRには10進演算命令が無いせいもあると思う。
10進演算命令はキャリー／ボロー・フラグを3個も追加しなきゃいけないし、
コアを設計したニーチャン達に切り捨てられても仕方がないｗ 自分の無知ゆえに有効な使い方を知らないだけかもと思ったのに冷たいなあ。
テクニック教えてくださいってのがくだらんか。
やっぱここには有能な人はいないんだね。
盛り上がらなくて申し訳ない。おしまい 常にバイナリ演算のほうがサイズが小さくて処理速度が早いなら、
BCD演算命令なんか残っていない。
BCD演算の方が早い場合もあるからこそ、
主に制御用に使われることが多い、BCD演算命令が無かった8ビットPICにも
上位CPUで追加されたのだろう。
バイナリ／BCD演算の比較の実例になるかどうか分らないけど、
まだAVRを始める前の大昔、
PCからRS232Cで4桁の数値を受信したら、
操作パネルの4桁のサミールスイッチの数値を加算して送信する、
というプログラムでBCD演算を採用したことがある。
（ASCIIコードのままで1バイト1桁づつ加算したので、 正確に言えばASCII演算か？）ｗ
2進演算のプログラムを書いて両者の速度やサイズを比較、というのはしなかったけど、
多分、BCD演算命令を使った方が小さくて早いと思う。 BCD演算命令なんてARMにもRXにもRISC-Vにもない。これが答え AVRはRISCなんですけどね
RISCの設計思想を考えればBCD演算が搭載される訳がない >>85
徐算命令があってしかも1クロックでやれちゃうならBCD専用命令などいらんってだけだろ。 つうかなんでBCDでこんなに燃え上がってるの？
BCD命令なんてアセンブラでしか使わないから、アセンブラアレルギーのやつがヒステリー起こしてる感じ？ BCD命令が無いってヒステリー起こしてるやつにみんながやさしく付き合ってる。 そう言えば、前にどこかで「プログラムが小さいとか早いとか何の興味も無い」とレスされて
エーッ！と驚いた事があったｗ
ま、プログラミングで何を大事にするか、人それぞれか。
ところでAVRに対する要望として＜レジスタ群を複数組み欲しい＞というのもある。
ソフトは上位コンパチに出来ると思うけど、これも見果てぬ夢だな。 >>91
自分は1クロック 1バイトに心血注ぎたい方だけど、
んまあ焼いてしまえば中は見えないから、Lチカを 1KB で書いても数十B で書いても結局 Lチカするワンチップマイコンがそこにあるということに何の変わりも無いよね。
でも例えばワンチップでオルゴール作ったとして、同じマイコンで単音ビープで精一杯の人とPWM で音色や和音再現できる人とじゃ、やっぱ後者の方がすげーって俺は思うよ。 程度問題とは言え、桁レベルで冗長なのは開発者の怠慢だと思う
他人に使ってもらう物ならなおさら ＞Lチカするワンチップマイコンがそこにあるということに何の変わりも無いよね。
その通り。
あるとしたら、「これよりも小さい（早い）プログラムを書ける人は他にいないだろうな｣
という自負、プライドかな。
ホントに最速（最小）かどうかは、調べたことが無いので分らんけどｗ
AVRに関して自信を持って言える事は、AVRのプログラミングは楽しい、だ。
AVRのレジスタは命令によって色々と使用上の制限があるので、
プログラム設計時にレジスタをどう使うか考えないと、後で困ることになる。。
レジスタで思い出したけど、AVRを始めたばかりの頃、
複数のレジスタでUARTのリングバッファを作ったことがある。
最高通信速度が9600から38.4kまでアップした。
面白いCPUだなと感心した。
長文、多投、まことに失礼しました。
これで終わりにします。では皆様おやすみなさい。 AVR128DA/DB使ってる人おるいんか？
なんか中途半端なんやけど １．ベアメタル＋ワンチップ
２．Arduino IDE＋Arduino board
３．Python＋Raspberry Pi board
どれもLチカに違いはないが応用(実用性と置き換えても良い)を考えるなら無視できない差がある
１ならプラモデルに組み込んで電飾に応用できるが、３はサイズ的にも電力的にもかなり厳しい
２でNanoを前提としても１と比べたらサイズや電力面の差はかなりある
「Arduinoしか書けません」とかだと応用の範囲は当然制限される
>>96
デジキーでボード買ってみたけど積んでいる >>97
ここってID勝手に変わらない？
ちょっと時間が経つだけで勝手に変わっちゃう DA/DB使ってるけど何が中途半端なん？
mega128より安くて速いだけでも十分メリットあるやん？ ■ このスレッドは過去ログ倉庫に格納されています
