AVRマイコン総合スレ Part43
■ このスレッドは過去ログ倉庫に格納されています
fuse間違えて文鎮、安価に作れそうなパラレルライターの定番ある？ 大量に文鎮にしたの？
そうでなけれは買い直ししたほうが安いと思う。 >>226です。
皆さん、ありがとう。
>>227, >>230
週末になっちゃうかもしれないけど、
Zadigも試してみます。
>>231
デバイスマネージャに何も表示され
ないので、ドライバというよりも、
AVR ISPやUSBケーブル側の問題の
気がします。
AVRライタとして買ったんだけど...
ファーム書き込むのに、他にライタ
必要ですよね...Raspberry Pieでの
書き込みを試してみようかな。
ちょっと考えてみます。 それ、異様に安いよな 正規品なのになんでだろ
ココまで安いと、中華の連中もやる気なくすだろな、それが狙いかな？
けど、あまりに安いのも考えモンだよな
ここまで安いと、自分で作るのがアホらしくなってくる
まぁ、既にPICKIT3（中華品)を 手持ちの俺には関係無いが・・・
＊安いからスグ壊れるだろう 考えてたが、 結構仕事してくれてる 自分で作らないだろ。
ライター作るのが趣味か？
ってか、ライターしか作らないやつだろ。 対応/非対応はソフトだけの話だからな
まぁそれが重要なわけだが
個人で使う分には、使うデバイが対応できればそれで十分
そして、ソフトは探せば見つかる（やはりと言うか、やってるヤツは居るんだよな） >>244
確かシリアル(ISP)とJATGのみかな
パラレルも高電圧もVDD供給も出来ない >>245
そっか、tiny44のライターのライターの人に勧めてるんだよな。リセッターの人にではなかったな。
ターゲットVDDはusbからジャンパ飛ばせば良いかな。
ところで！ジャンパ飛ばすと言うけど、頭痛が痛いみたいだな。 >>246
SNAPには3V3,5V0,GNDとシルク印刷されてるスルーホールが有るのでそこからVDD用の供給取れますね ジャンパ飛ばすも抵抗挟むも普通に通じる。
もういいよそのネタ。 昔、AVRを初めてからしばらくして、必要に迫られて大急ぎで作ったリセット用パラレルライタ
https://i.imgur.com/qcvUhUm.jpg
CPUの説明書を読んで、手持の材料だけで（基板なんて再使用品）mega328、tiny2313用として作った。
その後、対応CPU機種を増やしていったのだが、拡張性なんか考慮してなかったので、
接続がICソケット経由という情け無い状況になっているｗ
使用方法で工夫したのは、スタンドアロンでも(CPUを実装してSWを押すだけでリセット完了）
PCと通信して複雑な設定も出来るようにした事（PC側のグラフィカルなソフトも作った）
最近はAVRそのものをあまり使っていないので、これの出番も無い。
しかしATMELはなんでシリアル高圧ライタに対応しなかったんだろ？（8ピン以外の）
より使いやすくなったと思うのだが・・・ 今までatmel ice使ってきたけど最近のお薦めの市販デバッガはどんなのがある？ >>251
最近のものは高圧シリアル対応
これをオンボードで出来るとなるとボード燃やす奴が大量発生するから良し悪し。
>>252
Atmel ICE
PICKIT4
SNAP
どれも大差無し（電源供給能力は俺は求めてない） >>253＞ 最近のものは高圧シリアル対応
遅すぎるっつうの、初め（AT90S2313）から、せめてtiny2313の時に実現して欲しかった。
そしたらリセット対応ライタも増えて、「より使いやすいAVR」になっただろうに。
＜ボード燃やす奴が大量発生する＞点については、う〜ん、私には分らない。 高圧シリアル書き込み以外の、市販のライタに対するもう一つの不満点は
I/O自動切り替え方式を販売して欲しかった事。
ターゲットの書き込み用I/Oピンに接続されている回路を（リセット回路も）気にしなくて済む。
両者ともに過ぎ去ったの昔の話で、今となってはもうどうでもいいけど。 こんなのにああしろこうしろと言われも、メーカーも困るわなw AVRを使いは始めた時、感心した点と不満な点が共にいくつかあったが、
ライタに関しても、
・ターゲットボードの回路に影響されない
（たとえばリセットピンに大きなCがプルダウンされていても書き込める）
・シリアルでリセットできる
なら使いやすいのにな、と思った。
鈍感な人は何も感じないかもしれない。
＞ こんなのにああしろこうしろと言われも、メーカーも困るわなw
普通、メーカーはユーザーからのフィードバック情報を大切にする。
キヤノンのクレーム処理担当者が書いた本には、
「ユーザーからのクレーム情報は製品を改良するための宝の山だ」
とあった。
もっとも私はATMELにクレームを付けたことは一度も無い。
私はさっさと望む機能を持つライタを自作した。
なのでメーカーも困ってはいないわなｗ 誤解されるといけないので念のため書いておきますが、
私はAVRを大いに気に入ってます。 初期のPICを教育用で使った某高専が諸悪の根元
あんなキッタナイアーキテクチャで教育された生徒が災難 >>262
なんて話を真に受けて信じ込んだまま過ごしてきたあんたは自業自得 CとかArduino使えば気にならない。
asmで書く気はしない。 初めて知った時、4クロックサイクルが1マシンサイクルだなんて詐欺かよ！って思ったなあ。 8051も6809もそんな感じだったから気にならない。 >>270
まさか、PICをRISCと思ってた？
無知は恥じることないんだよ。 命令体系だけ見ればAVRもとてもRISCではないね。
キャリーフラグあるし、8bitCPUでは断トツに命令数は多い。
PICこそ理想的にRISCだよ。 RISCだってキャリーフラグくらいあるだろ
ARMとかPOWERとかPA-RISCとかSuperHとか そっとしといてやれよ
いろいろ何言ってんだかわかんないんだから 多くのRISCでキャリーフラグがあるのだからそうでもないんだろう
>>274にある通り、キャリーフラグを使ってるRISCも多いんだから キャリーフラグのあるARMが実際のCPUの性能も高いわけだから
悪の権化とまで言われるほどのことはないのでは？
AppleのAシリーズなんて同クロックのx86並みの性能になってきてるよね RISCカッコイイCISCダセぇというイメージから自称の似非RISCだろう。
そもそもRISC哲学を何も守ってないんだから。
みんなで守ろうRISC哲学。
・命令数を減らしてシンプルに(名前の由来。これは破ったアーキテクチャはRISCを名乗るな!!)
・複雑な命令はダメ。演算はレジスタのみ。
・キャリーフラグはストールするからダメ
・豊富なアドレッシングは複雑になるからダメ AtmelはMicrochipに買収されて同じ会社になったわけだが
今の大学や専門学校では8bitマイコンを教えるとしたらAVRとPICどっちを教えてるんだろうね
以前はPICを教えてるところが多かったけど今は同じ会社になってるからどうなんだろうね
教育機関で何を教えてるかの影響はかなり大きいと思う >>279
MIPS32R6やMIPS64R6なんて整数命令だけで300個くらいあるぞｗ >>279
キャリーフラグはストールするからダメ
今の高性能CPUは内部命令に変換してから実行してるからな
マイクロフュージョン、マクロフュージョンでひとつの命令に変換すればいい
RISC-Vだってマイクロフィユージョン前提で命令セットが考案されてる模様 https://eetimes.jp/ee/articles/1801/16/news109_2.html
> ただ面白いというか割り切ったな、という感じなのは、
> 例えばこのadd命令、ISAのレベルではオーバーフローチェックは行わない事になっている。
> オーバーフローチェックは条件分岐で代替できる（から命令セットではサポートしない）
> というのがRISC-Vのコンセプトなので、実際にはきちんとadd命令を実行する場合、
>
> add t0, t1, t2
> slti t3, t2, 0
> slt t4, t0, t1
> bne t3, t4, overflow
>
> という4命令を実行してoverflowチェックを行う必要がある。
> これはどう考えても遅くなりそうなものだが、実はこの辺りもちゃんと抜け道がある。
> いわゆるMicro-ops Fusion／Macro-Op Fusionの活用だ（写真9）。
> このケースで言えば、適切な内部アーキテクチャであればこれをMacro-Op Fusionでまとめられる事を前提に（写真10）、
> 「Macro-Opで高速化が可能なものについては命令セットレベルでは何もしない」という割り切りを見せている。 同じページにx86のcmpとジャンプ命令でのマクロフュージョンの例が載ってるね
https://image.itmedia.co.jp/ee/articles/1801/16/l_mm3017_180116_risc9.jpg
左＝写真9：IntelがBanias（Micro-Ops Fusion）やMerom（Macro-Op Fusion）で
実装したことで有名になったが、技法そのものはそれ以前から存在している。
基本的には内部で一度命令変換を掛けるのが前提 >>279
シンプルとか複雑とか気持ちの問題じゃねぇか。 機械制御用のCPUなんて値段が安くて、プログラムサイズが小さくて、
ビット単位の処理速度が早いプログラムを書けるなら、
RISCだろうがCISCだろうが8ビットだろうが32ﾋﾞｯﾄだろうが何でもいい。
（もちろんシーケンサーでもいい） 個々のCPUはいろいろクセがあるので慣れてるもの、熟知してるものを採用するのがまともなリスク管理。
言語をコロコロ変える奴、CPUをコロコロ変える奴は技術者潰しのクズ。 CPUは***しかできません、とか食いはぐれる奴、甘え。 無能思いつき丸投げ経営者のために自分の技術を安売りする必要はない。プライド持て、家畜ども。 >個々のCPUはいろいろクセがあるので慣れてるもの、熟知してるものを採用するのがまともなリスク管理。
それもまともなリスク管理の一つなのは間違いない。
しかし、必要に応じていろいろなCPUを選択して採用できるようにしておくこともまた、まともなリスク管理。
「まとも」もいろいろだしね。 仕事を発注する側から見れば信頼性を左右する要因は
(CPUの違いによる信頼性の揺れ)＜(プログラムやハードウェアを実装する人による信頼性の揺れ)
だと思う。 何のための比較かさっぱり分からん。
AVR開発案件にコボラー使うようなアホなことはするなという単純な話。 >>280
工学部電気工学系の大学生だけど実験で使うのはPICだよ
PIC16 CPUの命令セットなんてアセンブラで組まない限りあまり関係ないよね
まだ大学や専門学校では8bitマイコンのアセンブラとかやってるのかな？
8bitだと簡単なことやるにしてもコンパイラがものすごい数の命令吐き出すよね
コンパイラが吐き出すアセンブラリストを理解しやすいのはPICよりもAVRの方がわかりやすいよね
PICのコンパイラが吐き出すアセンブラリスト見ると何やってるのかわけわからん そもそも8bitでアセンブラでゴリゴリ書くくらいなら16bitや32bitマイコン使った方がいい気がする 昔は今みたいに気軽に16bitマイコンや32bitマイコンを使えなかったから
8bitマイコンでアセンブラ使ってただろうけど
今は、16bitマイコン、32bitマイコンも安いの選べばかなり安いよね >>294
自分ところはSTM32 Nucleoだな
簡単なロボット制御から相当高度なセンサ信号処理までできる 特定マイコンのスレで、嫌がられるのをわかっててて他のマイコンの話題をふっかけるのって止めたらいいのに。
技術論として比較をしたいなら、マイコン比較スレでやればいいんだし。 >>298
STM32でMicropythonで書いたけどI/O一つ変えるのに10uSくらいかかるから
AVRでCで書いた。 学術巨大掲示板群: アルファ・ラボ ttp://x0000.net
物理学 化学 数学 生物学 天文学 地理地学
電子 IT 工学 国語 方言 言語学 など >>300
STM32って32bitでしょ
馬鹿なの？ 大学の場合、32bitマイコン扱うところも多いのでは？
専門学校が8bitマイコン使うのは時間数が限られてるからじゃないの？
8bitマイコンだと命令数が少なく、割り込みの仕組みも単純
完全に教える側の都合
ただ、アセンブラで組む場合、8bitが楽とは限らない
専門学校の授業ではたいしたもの作らないだろうけど いまどき授業でCPUで8bitだの32bitだの気にしないって、C言語でコピペして動けばいいんだから >>307
と言う実学特化型も有るけど、
CPUの動作原理を教えるので
8bit アセンブラもやる
AVRは比較的きれいなので授業で使ってる そういう台詞はコンパイラより賢いコードを吐いてから言ってもらおうかｗ AVR＋フルASMの組み合わせでCPU電子工作を楽しんでいる。
AVRは頭の中に浮かぶフローを脳内アセンブルで、どんどんキーボードから打ち込んでいけるし、
ビット単位のI/O処理も速いし、
tiny2313などの初心者入門用CPUでも高速のタスクディスパッチャを作れる。
もちろん不満点もいくつかある。
レジスタセットを複数組持ってくれたらとか、BCD演算補助命令があればとか・・・ あ〜あ、最悪の存在フルアセ爺を召喚しちゃったじゃないか 前に自分でBCD加減算ルーチンを作ったら結構面倒でサイズも大きくなった。
あのPIC18でさえBCD演算補助命令を持っているのに、と思ってしまった。
ア、「あのPIC18でさえ」はここでは差別用語の禁止用語か？ｗ ゆとりはアセンブラ恐怖症みたいだな。
個々の命令は理解できるけど何かの処理を書けというと何も書けない人多いね。
そんな奴はたいていCでもJavaでもコピペばかり。
仕様を聞いてもアルゴリズムが頭にイメージできないダメな子。 >>313
できれば「召喚」じゃなくて「降臨」と言ってもらえると嬉しいです、ハイｗ アセンブラも書けない、Cも書けない子がなんでこのスレで喧嘩売りまくってんの?
単位落としたの？ 使いたい言語で使えればそれでいい話。
プログラムの組手の優劣のベクトルは一本じゃないんだし、なにより優劣を競う必要さえない。 逆に変な言語とかあるのかな？
亀を動かしたりするのはマイコンじゃ厳しそう >>320
おまえのレスはどれも非論理的でベクトルがバラバラだな。
すべての言語は機械語に翻訳されて実行される以上、アセンブラを知らなきゃどの言語スキルのベクトルも伸びやしない。
どの言語であれ、速度重視か、メモリ効率重視か、機能性重視か、その見積もりが正しくできない。
コピペしただけのコードを自分の成果だと自慢するのが精一杯。
若者はアセンブラを操る老害に自分の無能が見透かされるのが我慢ならないのだろう。 >すべての言語は機械語に翻訳されて実行される以上、アセンブラを知らなきゃどの言語スキルのベクトルも伸びやしない。
>どの言語であれ、速度重視か、メモリ効率重視か、機能性重視か、その見積もりが正しくできない。
考え方が古い。 「アセンブリ言語を知っている状態」ではない状態の想定が
「コピペしただけのコードを自分の成果だと自慢するのが精一杯」という価値観。
狭いな。 まぁ、CPUを「使うだけ」なら余程の事がない限り
アセンブラは不要だな
ただし、ツールを作ったりCPUその物を作るお仕事に
付くなら必須のスキル 非論理的な文系思考のレスを続ける奴に何言っても理解できないのは仕方ない。
>>すべての言語は機械語に翻訳されて実行される以上、アセンブラを知らなきゃどの言語スキルのベクトルも伸びやしない。
>>どの言語であれ、速度重視か、メモリ効率重視か、機能性重視か、その見積もりが正しくできない。
>考え方が古い。
まさに宮台と同じ論理だ。 自分と異なる考え方は非論理的に見えるものですよ。論理の基準が少ない人から見れば。 実際、速度でもメモリ効率でも何でもいいけど極めようとしたら
ハードウェアに近いところが気になってくるでしょ
アセンブラを操りたいわけではないけど、結果として知ることになるというか
それがいらないってのはそういう範囲の使い方しかしてないってことだよ
個人的にはそれでわかった気になってるのかよとは思うが、人それぞれなので放っておけばとも思う >>328
>それがいらないってのはそういう範囲の使い方しかしてないってことだよ
その「そういう」は「速度でもメモリ効率でも何でもいいけど極めようとしない範囲」だよね。
今はそういうのは割と多いのでは。それ以外でもプログラミングに携わる人の価値っていろいろあるしね。
バイト単位、クロック単位で突き詰めるのってすべての若い人に必須だとは思わない。
自分が良く知っていることがある、ということは、他人の方がよく知っている分野がある、ってことだし
価値観が違う人と仲良くできたら世界が広がるね。 3Dゲームをライブラリ使って開発するってのなら何も言わないけど
マイコンを使う開発なのにアセンブラは知りません、必要ありませんって言われたら
トラブる将来が見えて、仕事を頼む立場だったら躊躇するかも
もとよりAVRスレだからそうおかしな前提じゃないでしょ？ >>330
AVRにとどまって仕事で極めるスレでもないしね。
AVR+Cでぎりぎりになったときには、別のマイコンに行ってもいいわけだし。
アセンブリ言語に関心がない人は最初からAVRは使うべからず！ ってことはないよね、 AVR+Cでぎりぎりになったときには、あきらめてもいいわけだし。 ■ このスレッドは過去ログ倉庫に格納されています
