AVRマイコン総合スレ Part41
■ このスレッドは過去ログ倉庫に格納されています
>>710
>>711
そういうことなのね
コンパイルしてメモリ使用量が100%未満だからといって安心しちゃいけないのか
>>713
volatile unsigned char x;
だけmain関数の真上のグローバル変数領域に移設してみたけど
エラーが出るようになっちゃった
>>716
一応"uart.h"の前でavr/interrupt.hは宣言してあったわ
ヘッダーファイルに割り込み処理を押し込もうとしたのはそもそもの間違いか
下手に楽しようとせずmain関数の上に書くようにするわ
ありがとう >>717
ヘッダーに関数その物を書くのが作法違反っすよ >>717
volatile unsigned char x;
の前で uart.h をインクルードしているのでは？
uart.h の中で変数 x を使うコードが書かれていると、そんな変数知らないとコンパイラに叱られる
一見、すっきりした様に見えるけど、uart,h の中にプログラムコードを書くのは違うような気がする
ISR() を外に出したいのなら uart.c のような別の *.c ファイルに記述して、 必要な定義類を uart.h に記載するのが良いでしょう Cがアホ言語かどうかはともかく、
なんでこんなにMCU向けにCがはやるようになったんだろ？
FORTHなんか機械制御用として作られたユニークな言語だし、
小さなMCU向けにはVTLみたいなものでも十分だと思うけどな。
だれかアッと驚くようなD言語処理系でも作っておくれでないかえ。 >>723
いまさらテープドライブ？
まあMCUならいいのかもね。 当時はさ
CPU速度が遅くメモリも潤沢ではなかったが為に
インタプリタ系言語が敬遠されたってだけだと思う
PASCALもpコードの奴はトロいしw Cの設計思想はコンパイラ開発者に楽させるためだから、Cはあほ言語なんだよ。
プログラマに楽させるためのJavaとは真逆の設計思想。 Cはあほ言語なんだよ、だってさ。あの人いつも極論言ってカッコイイって思ってるのかな。クスクス。 なに使ってもダメな人はダメ
アホなのは言語じゃなくて
その言語の思想を理解できずに
「あほ」って言っちゃう方
所詮、道具なんだから気に入らなきゃ
スルーして別の道具を選択するなり、
自分で道具から作りゃいいのに… >>718
>>719
反省しとります
ヘッダーに記述するのやめておきますm(_ _)m >>730
自分でコンパイラ作るの？
しかもアセンブラで？ >>732
ツールってのはそうやって出来てきたんだよ
既存のツールにどうしても馴染めなきゃ、
諦めるか、自分でツールを作るしかないだろうが 今からC言語を学習する人は可哀想だね。
大抵の場合、組込みでしか役に立たないし…、しかも給与高く無いという。
まあ、趣味で使うなら作法とかそんなのは気にせずとりあえず動けば良いと思います。 食うために言語をマスターするという発想しか浮かばない境遇そのものが可哀相 C使ってても給料高い人はいくらでもいるけどな。
別に組み込み以外でも、ドライバ開発だったり、ライブラリの高速化とかで需要はあるだろう。
ドライバ開発とか、毎回とんでもない金がかかる。。。
自分でやれればいいんだけど、あれは無理。 何か一つの言語を深くマスターできていれば
他の言語もすぐにマスター出来る
逆も真で、ダメな奴はどんな言語を選んでも
ものに出来ない C言語は習得が難しい割には、一般的には収入低いのは確か。
簡単な組み込みが多いからかな？
OS周辺や、ドライバ開発となると、C言語出来るというより、単純に能力が高くないと無理なので、
収入高そうですね。
C言語出来るというだけでは、コピペできるか、ある程度スクラッチできるか、
ライブラリ作れるか、ドライバ作れるか、ＯＳ作れるか、言語そのもの作れるか、
と範囲が広すぎて、能力を把握できませんね。 「プログラミング言語別年収ランキング 2018」を見ると
Cプログラマは最下位(10位)で可哀想にプログラマ業界のワーキングプアだ
https://tech-camp.in/note/careerchange/49077/
俺はMCUに関してはフルアセンブラ派なので競争相手が全く不在で
こんな言語を超越して稼ぎまくっているから関係無いけどｗ >>744
クイックソートの例を見てみたけどCより遥かにスッキリ書けるね
AVR用のコンパイラとデバッガは存在するの？ Haskll てH言語？
「頻繁に IO を行うプログラム: IO などの不純な行為は Haskell は苦手。」
http://www.shido.info/hs/haskell1.html 自分は組込み屋ではないですし、Cは1年に1回程度チラッと仕様確認で見る程度ですね。あとは趣味のAVRで利用する程度です。
ただ、IT土方で薄給なのは事実ですが…。
ただ、どうせやるなら趣味でも仕事でも新しい方が“何となく“良い気がしませんか？(錯覚かも知れませんが)
まあ、C以前の低級言語は、コンピュータの動作がどうなってるか学習も出来るので、やって損は無いとも思います。でも、やっぱり今更感が強いですね。 言語よりも、成果物だもんなぁ・・・・
自分が成果物を出しやすい言語を使えばそれでいいわけで。
もちろん、職場とか取引先で指定もあるけど、ライブラリにして投げ渡すという手もあるし。 昔はみんなコツコツ薪を集めてお風呂を沸かしてたのに
最近の若い奴はボタン一つで風呂沸かしやがって ゆとり元年のガキが2010年入社だったが
最近のは更にゆとり教育期間が長くてもうえげつない動物みたいな奴ばっかだな >>751
ゆとりだけが原因じゃないんだぜ。
採用活動の制約のせいで経団連加入の企業は、
それ以外の企業が採った後の残りかすしか採用できてない現状。 >>751
それはご愁傷様。
こちらの観測範囲だと若い子ほど優秀な印象。
内向的ゆえかコミュニケーション能力高いし。
並みの子が来たがらない環境なんじゃない。
最近はそう言う情報も流れてるし。 最近のゆとりは魚が切り身で泳いでると思ってるとかどうたらこうたら 同じ処理の繰り返しって積極的に関数化した方がいい？
プログラムメモリ的にも関数化した方がコンパクトになるのかな？ 関数コールする度にスタックを食い潰して行くからなぁ
ATtinyとかはSRAMがすくないので、極力関数化せずに、
マクロを多用している >>756
基本は、関数だけど。
スタック消費を避けたいときと、処理速度を上げたいときは、マクロも検討します。
ただ、デバッグが面倒になるときと、マクロの副作用もあるので慎重に。 とりあえず関数で書いて完成したらROMの許す限り展開するだけだな俺は メモリにも処理速度にも問題が無いならそんな余計なことはしないな俺は >>761
コンパイラの吐いたコード見て、思わずマクロにすることはありますね。
パラメタの数だけ、スタック退避されてビビル。
コンパイラの最適化によるけど、参照だけなら const つけるとか、
あえて、パラメタ変数をグローバルで宣言するとかもあるけど
メモリ許せば、マクロかな〜
ケースバイケースで、指示が無い限りは、センスに任せるっていったところか。 スタック無しでもそこそこのパラメータ渡せるのに、
スタックにまでパラメータ積む様なコードって汚そうだなぁ。
ポインタ渡しとかにしときなよ。 >>763
avrgccに限らずって話ですよ。
コンパイラの最適化もあるし、
ポインタ渡しにしたら、変数アクセスごとに、インデクスレジスタを
更新しますからね、当たり前の話ですけど。
そのオーバーヘッドとコード領域の増加を避けたいこともあるのです。 AVRライターに純正のAVRISPMK2ってのがあるけど、これって何か特別優れた点があるの？
純正だから安心的な話じゃなくて機能的に。
と、言うのも中華な激安AVR(と比べると失礼かもしれないが)とくらべると明らかに基板の密集度が違う。
ほかの多くは電源供給できるが、この製品はそれもできない。
何か優れた点があるのかなのと気になって・・・ アトメル純正はどれも電源供給はできない。
『純正である』信用以外のメリットはこれと言って無いと言っていい。
しかも本家ISPmk2はとっくの昔に販売終了していて、あっても店頭の売れ残りだけ。
最新のデバッグインタ−フェースであるUPDIにも対応していない。 >>768
世の中にあふれるどのライターよりも複雑なんでなんかすごいのかと思ってたけどそんなことはなかったんですね。
つか、販売終了してたとは知らなかったです。
ポチる前に聞いておいてよかった。
他の物色します。これ結構いいお値段するんで・・・
回答どもでした。 ライターでしかないISPmk2買う勇気があるなら、
デバッグもできるAtmel ICE買う方を勧めますよ。 attiny202/402/212/412の4種類あるね。DIPは無いけど。 mega808なんて出すのか。
120円くらいと予想。 USIはI2Cで使ってるので
ソフトだと速度出ないし tiny3216が便利すぎてまとめ買いしたこればっか使っとるわ 速度出すなら水晶欲しいな…？
VCC！GND！XTAL1！XTAL2！SDA！SCL！TXD！RXD！
リセット殺しても他になんも付かねぇ!!
どうでもいいけど8ピンのDIPかわいいよね >>776
3216が出る前に1616をまとめ買いしてめっちゃ使ってるｗ
ICE使っても1ピン喰われるだけだし、デバッグは安定してるし、いい子だよ。
mega3208もお気に入り。 tiniy0/1シリーズなら内部20MHz有るんだから水晶要らないっしょ。
クロックの出荷時誤差書き込んでくれてるし、オートボーレート機能有るし。
てかそもそも水晶付けらんないし・・・ 代表特性だと全動作温度範囲で0.5%くらいに収まってるから大丈夫なんじゃない？
クロックをオシロで見ながらドライヤー当てて見たけど全然動かん。 最近のは水晶付けられないんで音程狂って使えないんだよなー。
外付け発振器だと高くつくし >>776
おすすめのライター教えて
ATtiny416-xnanoの半分使っても書けそうだけど… >>782
「デバッガ」だよ。Atmel ICE↓
http://akizukidenshi.com/catalog/g/gM-08285/
使ってみないと良さは伝わらんと思うけど、
一度使うとこれ無しにデバッグする気になれないと思うよ。 あ、最近のデバイスならPICKit4でもデバッグできるんだっけ↓
http://akizukidenshi.com/catalog/g/gM-13337/
電源も供給できるし、誰か人柱になってくれｗ >>781
最初の頃UARTが全然届かなくて水晶にしたら解決して以来、
基本内蔵は使ってないんだけど、
そこら辺どう？ >>787
屋内使用限定で通信エラーが重要じゃない売り物でそこそこの数出てるけど、文字化けの報告は一度もない。
一応20台くらい-20〜50度の環境試験かけたけど、文字化けは1台も無かった。
社内用のちょっとした治具でもUARTは当たり前のように使うけど、xmegaや今のtinyに水晶を積んだことは無いな。
もちろんトラブル無し。
tiny2313やmega328はダメダメだったなあ。 経年劣化は知らんよ。
言い訳のできない産業用途なら俺でも水晶発振器積む。
用途とコスト次第ってことよね。 Atmel STARTじゃtiny3216なんかのボーレート補正コード吐いてくれないんだよな。
水晶付けられなくしたんならその辺ちゃんとしろよって思う。
プログラムで補正したボーレートレジスタ設定値を計算させたらコード量が膨大になったよ。
inline関数にして可能な限りプリプロセッサ任せにしたら激減したけど。 ここ何日か、tiny2313+内蔵OSC8MHz+19.2Kボーで
UARTをデバッグ用に使っているけど、文字化けは経験していない。
ただし仕事（金を貰う）の仕様として使うUARTなら水晶を使う。 室内じゃたいした温度変化ないからそんなもんよ。
ドライヤー当ててみな。 19200じゃどうでもええやろ
250000とか115200のハナシ クロック精度の話してんだからボーレート関係ないな。
精度が悪けりゃ300bpsであろうとも化けるさ。 >>788
使い始めてダメだったの丁度その二つだ。
xmega系使うときあったら内蔵試そうかな。
むしろどんな仕事なのかが気になった。
XMEGA32って安いのね 同じQFP32ピンならmega3208はもっと安いよ。
こいつも内部クロックが最近のタイプの隠れxmega系列。 厳密にはコアや命令セット上の分類だよ。
DFLLなんて周辺機能の一部でしかないし。
xmegaより後に出たtiny0,tiny1,mega0シリーズはgccでの分類上もxmega。
まあ製品名にちゃんと「x」がついてるものより機能低下してるのは確かだけどね。
DMA無くなったのは痛いしタイマーの機能もしょぼい。
しかし安い！ そこじゃなくて、>>800の、mega3208の内部クロックがxmega系、って所。
正直なところ、mega0シリーズはクロックだめだめで、
音系のもの作る私に取ってはちーとも使いモノにならない。 外部クロック使えばいいのに
今時MEMS発振器使えば安上がり >>803
UARTが使えるかどうかの流れからいきなり音系基準に変えられてもw
mega0系はクロックの調整幅が荒いからね。
シグネチャのOSC20ERR5Vとか使ってタイマー側で校正してる？
音関係なら0.5%のズレでもきついのかな？
DFLLも内蔵32Kでの補償なら精度は似たようなものだと感じたけど。 音楽系なら0.5%の誤差はたぶん許されないでしょうね。「440Hzが438Hzに聞こえる場合があります」と言われてOKって言う人少なそう。
事務用のカセットレコーダーだとパーセントオーダーの誤差は許容されていたはずだけど。
UARTなら、相手も同じように誤差があるとしても2%ぐらいは大丈夫では。 >>806
音楽系では、精度が高くても、ジッタで周波数が特徴的にずれるのはＮＧですね。
水晶にしても、ノウハウがないかぎり
精度の保証された、外部発信器かなーー と思ってるけど、どうなんでしょ。 水晶発振器を外部トリガに渡して内蔵RCでカウントさせると周期的にうねってるのが判る >>807
精度、正確度あたりの言葉を狭義、広義で使う人とで混乱しそう。
あと、機器の物語やココロで音楽を聴く人と、まあこれで普通は十分だなという立場で聴く人とでも違ってきそう。
私は後者。水晶だったら、普通にそれで組んであったら、もうそれで十分すぎるほど十分だと思う方です。 >>809
普段は、効果音、程度なので、レゾネータで十分です。
楽器と、云ったとたん難しくなるでしょうね。
水晶は、RTC作ろうと思って、32768の水晶使ってみたら、
結構時間精度が出せなくて、キャパシタの選択等、簡単な話ではないな〜と思った次第です。 RTCはぶら下げるコンデンサでめちゃ変わりますね。
特別32.768kHzの水晶だから変化するのではなくて、RTCが要求する精度が高いわけですけど。
高精度なRTCが欲しかったらTCXO入りRTCに逃げています。機会があれば、SiTIMEのMEMS TCXOも試してみたい。 マイコン内蔵のRTCに精度求めたらつらかった経験あるわ。
専用ICのPCF2129に落ち着いてから変える気無いなあ。 誰もが頭が良くなる、プログラムが書けるようになる方法が発見される 50545
https://you-can-program.hatenablog.jp うちじゅうどこでもWi-Fiが拾えてESP8266から時刻サーバへアクセスできるから、
RTCモジュールなんかみんなお蔵入りしてるわ。 フィールドに出るとネットにつなぐだけで一苦労だからなぁ。。。 ■ このスレッドは過去ログ倉庫に格納されています
