マイコンソフト 悩み事相談室 3 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
.
∧ ∧
( ´・ω・) < コンフィグって何? 昆布なら知ってる。 ボラチルって何? ボラは魚だよ。
( ∪ ∪ ,.-、 ,.-、 ,.-、 ,.-、
と__)__) (,,■) (,,■) (,,■) (,,■)
PIC AVR H8 ARM
学校でC言語を習ったことがあるので「楽勝でしょ」って、マイコンを始めたけど、
わからないことだらけ。誰か教えて!
PCとは別世界の、マイコンのソフト。難しいよね。
ツールの使い方、ツールの設定、マイコン特有のC言語の書き方、
「デバッグモードにプログラミングモード。何?」 Eclips, Emacs って何?
VBAしか知らないよぉ、という人まで、
各社マイコンに関するマイコンソフト相談室です。
質問者は、「初心者質問スレ」の>>1を見て、分かり易く質問を書いてね。
回答者は、威張らない、バカにしない、言葉使い注意で、親切に教えてあげてね。
あっ、そうそう。
ハードウェアに関する質問は、それぞれのマイコンのスレに、達人がいるから。
過去スレ
1 2014/09/11〜
2 2016/07/31〜 http://rio2016.2ch.net/test/read.cgi/denki/1469905691/l50
では、質問、ドゾ〜 >>338, >>340
だからググれば色々出てくるだろ
自分がよいと思う奴を採用すればいい
俺のところのやり方がお前に合うかどうかは知らんし、下らんいちゃもんつけられても困るし >だからググれば色々出てくるだろ
>自分がよいと思う奴を採用すればいい
>>338、>>340を読んでないな。
読めばそのレスが的外れなのはわかるだろう。
>>342ではなく、>>322のやり方を聞いているって書いてあるのに。
>>322がなんなりと書けば、それなりにいちゃもんが付く可能性もある。
そりゃそうだ。他人の流儀を「老害の典型」なんて批判するぐらいだ。
よほど立派な流儀でなければ、お前が言うか、って言われて当然だと>>342だって思うだろ?
しかし、こういうことは回避策もあるのにな…。 よほど立派な流儀でなければ、お前が言うか、って言われて当然だと ID:Ra0M84o4 だって思うだろ? いちゃもん付けるだけで、自分の意見があるわけじゃなさそう。
追い詰めても、何も出まい。 老害はしつこい w
そんなアホレス返す前にググって自分に合うコメントの入れ方見つけりゃいいのに >>322
では、どのようなコメントの入れ方なら良いのでしょうか?
教えてください 自ら、何も出せない事を肯定する書き込みしなくても良いのにね。 >>350
>>322の手法を聞いているのに、ググってもでてこないでしょう。
>>322に回答して欲しいんだ
もしかして>>350=>>322なのか? >>350
ご紹介のページのソースは、ソースと同じ左右位置にコメントが書いてあるね。
しかもソースの間に。
その方法を推薦するの? 判読性が悪くない? >>352
> ソースと同じ左右位置
インデントと言う用語も知らんのかよ...
さすが老害 w >>353
インデントと左右の位置は、違うけどね。 違うと言うならその意味を説明しないと君だけのオレオレ用語なんて誰にもわからんよ ケツの青いバカ造の得意な言葉:「老害」
「老害」で全てを片付ける、ってのは、見ていて精神の貧困さが感じられて痛々しいな。 >>350のリンク先はコメントに何を書くべきかを論じているのであって、記法についてはつっこんだ話は書いてないように見える。
ルールが定められているときはそれに従うとして、自分で自由に書ける場合の話。
行間に入れる書き方は、ソースコードとコメントを同じ流れで書き連ねるのにあたって、
思考がブツ切れにならないので好きだけど、こういう考えるプロセスそのものは個人によって異なるので、
一般論として「行間に記入する方が思考がブツ切れにならない」とは言えない。
それと、行間に入れる記法だと、行数がどんどん増えてしまう。
また、何年もたってから、ソースコードだけを読みたいときに、最初に書いたときの思考のプロセスとは裏腹に、コメントが読み取りの邪魔になることがある。
行末に入れる方がその点では良いはずなんだけど、どうも変数関数の名前が長くなりがちで、プログラム自体の1行の文字数も多くなっているものだから
横スクロールが苦痛になってしまう。
ところで、>>322はどんな書き方をしているのだろうね。 >>360
それはインデントって言葉を知らなかったか使わなかっただけのことじゃないの? >>359
ソースは、その形で流れや動作がわかるという面があるので、
その行間にコメントがあっては、流れや動作がわならない。
とかく変数名は長くなりがち。一行は100文字以下にしているけど
行末のコメントに工夫がいるね。 行末でには書かない322は、どんな書き方しているのか、知りたい。
画面の左半分はソース、右半分はコメント、
と言うのが僕の書き方。 各行末にコメント
だから全部の行に意味のないコメントを書いてるようなのを老害って言ってんだろ
意味のあるところに意味のあるコメントを書かないとな
行末はその行に関するコメントになるが
そういう小さな単位のコメントは規模が大きくなると邪魔になる
意味のあるものに絞らないと
まとまったブロックに対するコメントは行末には書かないよな
一行〜数行、コードのインデントで書いたり
関数ヘッダやファイルヘッダは普通は複数行で
インデント無し
時と場合によってそれぞれの適した書き方がある >>364
別にお前のコメントの書き方に興味はないしボッチ開発なら好きに書けばいい
ただ少しはオープンソースとかソースを公開してる製品のソースコードを見た方がいいぞ
そうすれば今時そんな書き方してる奴は少数派ってわかるはず >>363
それは苦し紛れに言い訳けしただけじゃないの? 個人の流儀で良いというのであれば、多数派か少数派かで価値に対する色付けをするのはおかしいな。 >>366
そうですか。
では、大多数は、どのような書き方をしているのでしょうか?
ぜひ教えて下さい。 >>367
そう言うのを俺に言われても困るよ
>>355に聞いてくれ
まあガン無視してるからあんたの想像が合ってるかもね >>368
別に価値があるとかないとかを言ってる訳じゃないよ
>>321 > 行末にコメントを入れている場合
みたいなのは昔よく見たって話で、例えばアセンブラ言語なら今でも(全ての行には入れないけど)行コメントはアリだろうとは思う
また、自分一人しか使ってないスタイルでもそいつが便利に使ってるなら(少なくともそいつにとっては)価値がある 調べるヒントを書いてあるのにも関わらず自分で調べようともしない>>369みたいなのも老害の特徴だな なんか話が違わくね?
毎行末にコメント入れるようなスタイルと
要所で行末にコメント入れるスタイルの話が混ざってる気がする。
前者は明らかに時代遅れってかおかしいけど
後者は普通にやってるけど。
もちろんブロックごとのコメントも入れるけどねー 「各行末にコメントを入れている場合、」
要所ではないよな
テーブル的なものなら別に時代遅れでもない
構造体や変数宣言やenumでもまあ普通
普通のコード部分なら時代遅れ 各行末にコメントを入れるってアセンブラのソースじゃないの? ちょっとズレた話だが、むかーし、クライアントから機械語でプログラムを書いてくれって依頼があったのを思いだした。
で、コメントを細かく入れてくれって言われたよ。
ハンドアセンブルした機械語のダンプに、どうやってコメント入れろと…
クライアントのスキルも色々とあるんだよ、きっと。 今はマイコン=組み込みですかね
ArduinoとかmbedとかPICみたいな
OS使わないやつ(RTOS除) マイコンを使った機械制御はリアルタイム性が要求されることが多い。
私はエントリレベルのATtiny2313でさえディスパッチャを自作して並列処理にするときがある。
ポーリングに比べるとプログラムがスッキリ、クッキリ、ハッキリする(場合が多い)。 ユニークで個性的な確実稼げるガイダンス
暇な人は見てみるといいかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
W57NZ タスクスイッチャ
普通にできあいのRTOS使えばいいと思うけど 素人はLED1個に対してスレッド1個作るとかアホな事をするからなあ
規模が小さければ通常処理&割り込みが良いよ
OSなんかのせて無駄にオーバーヘッド増やさなくても
Windows規模ですら3.1までは協調型マルチスレッドだった位だし Lチカの話にWindows3.1とか頭わいてるのか? L地下にOSとかバカジャネーノと言ってるんでしょ。
PCですら、プリエンプティブじゃなかったくらい大げさだということ 私がtiny2313のtimer0_CompA用に作ったタスクディスパッチャは13命令でオーバーヘッドは2.5uS(クロック8MHz時)、
セットアップ(タイマ起動やスタックのセットなど)は25命令程度。
もちろんいっぱい制約や注意すべき点があるが、それでもシングルタスクとは大違い。
…と書いたけど、いつでも役に立つというわけではないし、私もシングルタスクで処理する方が多い。 どんなに軽くてもタスク切り替えに数十命令
割り込みだけの方がはるかに速い
リアルタイム性が重要なら割り込み以外はあり得ない
特に極小規模マイコンの場合は
また、OSを作るなら
ディスパッチャだけあってもしょうがない
優先順位付きタスクスケジューラー
イベント
セマフォ
スリープ
最低でもこれらの機能が無いと使い物にならない
信頼性や実績や互換性を考えると
世の中に既にあるOSを使うのが普通
OSごっこして一人で遊ぶだけなら問題ないが
何度も書かれるとこちらも意見を言いたくなる >>390
この手のマイコン用のRTOSの話にWindows3.1持ってくるのがバカだって話なんだが
OSならなんでも一緒だとでも思ってるのか?
あと>>392とか勘違いしてるけどリアルタイムって応答が早けりゃいいんじゃなくて応答の最悪値を保証することが重要 Windows3.1を出したのは>>390の言う通り
まさか日本語がそこまで不自由とは思わなかった
普通応答性能って言えば最悪値がまず使われる
平均ももちろん使うことはあるが >>392が勘違いをしているのではなくて、
>>392はできるだけ速い応答を望むのなら、という観点が大きくて
>>393はOSに応答のカツカツの速さとは別の価値を見出した上で、最悪値を保証できれば、という話。
一方は速さ、一方は別の価値。求めるものが違うのに、同じ価値観で話をしたら合わない。 >>383はリアルタイム性を強調した上で自作OSもどきを使うと言ってるんだが
1行目と2行目以降は別の話題だと?
まあこの人は何かにつけて自作ディスパッチャの話題を書きたがるので
本当に別の話題の可能性も無いことは無いけど 「リアルタイム性」と「速さ」をごちゃ混ぜにして論じない方がよろしいかと・・・ >>392 >ディスパッチャだけあってもしょうがない
例えば、アセンブラを必要としているが入手できない場合(Cにする、は無しで)
A:そのCPUの使用を諦める
B:最低限の機能を持ったアセンブラを自作する
どっちにする?
私だったらBで、大急ぎで下記の機能を持ったプログラムを作る。
数値(実行番地も含む)にラベル(文字列)を割り当てられる。
特定の文字列(ニーモニック)を16進数にコード変換できる。
そしたら下記のような文字列のアセンブルが可能になる
Mask .equ $FF
LDI R16,Mask
jump L1
L1 .equ $
macroやif、リロケータブルが必要なら、後で時間がある時に追加、変更すればいい。
条件成立判断の多い複雑なプログラムなら、
タスクを分離できるディスパッチャだけでも十分に役に立ちます。
役に立たないというなら、作っているプログラムが簡単か、
CPUを使いこなせていないせいだと思う。(失礼!)
>何度も書かれるとこちらも意見を言いたくなる
あのネ、それはネ、仲間が一人も居なくて寂しいんですぅ、天涯孤独なんですぅw
ほとんどのCPUに適用できるし、とても簡単なのでどなたかやってみませんか?
小さなワンチップCPUを動かす楽しさが増えると思うんだけどな。 そもそも小さなAVRにフル機能のマルチタスクなんか実装できるわけがない。 時分割マルチタスクとかRTOSとか
大昔の8ビットマイコンですら普通にやってたんですが・・・ (スマヌ、送信してしまった)
で、A:諦めるか、B:小さなものを作るか、の選択になる。
私はB:を選んで活用している、という事です。
>>400
そうなんですよね、何で今はやらないんだろ? マイコンが遅いからこそ、そんな工夫が必要だったんじゃないですかね?
今は「間に合わんなら速いマイコン持ってこよう」って力技感覚ですし、
それに答え得るARMなんてありますし。 Z80で500体のごちゃキャラゲームやれてるくらいだし
500個の並列処理も余裕ってことだ どっちがマイコンを使いこなしているか、みたいな話になったらつまらないですね。
「マイコンを使いこなす」いうこと自体が普遍的な価値観じゃないですよね?
高速割り込みが必要な処理を実装することと、RTOSを載せることは別のベクトルだし。
>>398
昔はマイコンそのものが楽しくて仕方がなくてBだったなあ。今はAだ。
もし、昔ほどのマイコン好きのまま今に至っていたら、あなたとは別の愛し方をしてたと思う。 >>402
俺個人でいえばはデバック環境の違いだな >>398
普通に自作アセンブラでCの関数を作れば良いだけでは? アセンブラが無いのにディスパッチャだけ作れるってのもよくわからん >>403
それクロック1GHzのパチンコ専用品だったりしませんかw 車輪の再発明が趣味だというのも勝手だけどな
切れるナイフが安価に売ってるのに
黒曜石ナイフが趣味だという人も居るし
蓼食う虫も好きずき >>395
できるだけ早い応答とか実務ではほとんど意味ない
ハードリアルタイムとか知らないの? >>399
フル機能が何を指してるのか知らんけどこの手のマイコン向けRTOSってフットプリント数KBとかだよ?
ディスパッチャーとか言ってるけど次に実行するタスク決めて環境切り替えるだけ、そんなにでかくないよ >>412
ごめん、何を言いたいのかさっぱりわからん
とにかくレスしたいだけならそれでいいんだけど 今の8bit CPUの規模なら、
許容遅延が厳しい要因の数など知れてる
だからそれを割り込みにすればいい
マルチタスクよりもずっと遅延の最大値を見積るのが簡単
もっと大きな規模であれば
今なら普通は既製のOSを使う
いちいちOSから開発するようなスローな時代じゃないので 既製品よりとにかく軽くコンパクトに作れる技術があるというなら
こんなスレじゃなくて組み込み用OSのスレを立てて語れば良いと思うよ >>414
>>383の文章から、
リアルタイム性のためにリアルタイムOSもどきを使う
という主張だと思ったわけだ
それに対して、
リアルタイム性を追及するならOSレスの方が良い
という主張をしたわけ >>402
割り込み応答だけなら、8bitマイコンの方が速かったりもする。 「リアルタイム性」という言葉を「すばやい応答」と思う人と、
「リアルタイムOS」という文脈での「リアルタイム」を想定して話す人だと食い違う。
>>396はリアルタイム性を前者で解釈しているから>>383が矛盾したことを言ってるように見えてるのだと思う。
このことは>>397も指摘しているよね。 そう、つまり>>418は「遅い」の意味を根本的に勘違いしてる。 >>419
> 「リアルタイム性」という言葉を「すばやい応答」と思う人
コンピューター関連の用語としては間違い
せめてWikipediaぐらいは読んでから出直してこい
https://ja.m.wikipedia.org/wiki/リアルタイムシステム >>418
PICスレでそんな事をいう人がいたから実際測ってみたけどそうでもなかったよ
その時測ったのはPICの8bit, 16bit, 32bitだけだけど
クロック数で数えて同じくらい
実際の時間はクロックが速いほど速い >>421
OSのリアルタイム性と言えば
応答性能を指標にするのが普通なわけだけど
割り込みであったりタスク切り替えだったり
キーを押した時の反応であったり
機械制御のリアルタイム性は
そういう応答性能と処理時間で決まる
処理時間はOSを何にしようが関係ないので
項目的には応答性能以外語る事は無いと思うのだが
それとも1個のタスクで複数の処理を行うといった
ソフトの基本的な作りを知らないとか?
これはマルチタスクだろうが知っておかないとダメだぞ
LEDの単なる点滅でタスクを作ることになる >>423
だからリンク先読んでこいよ...
お前、ハードリアルタイムの意味もわかってないだろ 普通のリアルタイムの分類が書いてあるだけだが
人の書き込みを否定するだけじゃなくて
具体的に>>383の「リアルタイム性」の内容を書けば良いのでは?
>>383がどういう意味で使っているかを知っているなら >>423
>OSのリアルタイム性と言えば
>応答性能を指標にするのが普通なわけだけど
様々な要素の中でそういうことも含まれてくるかもしれないけどそれが指標というのはおかしいと思う。
「リアルタイム性」という言葉を、「リアルタイムOS」の「リアルタイム」から離れて辞書的に解釈しているような気がする。
たとえばマスメディアが「リアルタイムに情報をおとどけします」といえば「即座にニュースが届けられる」と思う人が多い。
>>423は「リアルタイム」をこれと同じように解釈しているのではないだろか。
http://www.m-system.co.jp/mstoday/plan/mame/b_network/0702/index.html
「リアルタイムというと応答速度が速いことと誤解される場合が多いですが、」
>>423に質問なんだけど、
「リアルタイム」という言葉をどちらの意味で使っていますか?
・即時応答すること
・「リアルタイムOS」の概念の中での「リアルタイム」 >>427
えーっと、こんなことを言いたくないですが、日本語はわかりますか?
どちらの意味で使ってますか?という質問に答えるなら、どちらかを選ぶものだと思います。
日本語がわかっているのに、そのような答え方をしないのは、その答え方をすると都合が悪いとお考えになったからですかね。 マイコンの役割は
ADCやポートや通信やタイマーなどのトリガーに対し
規定時間以内に適切な内容にして
DAC、ポート、通信などの形でアウトプットする事 >>429
マイコンで実現するシステムに求められるさまざまな要素のひとつではありますけど、全てではないですね。 入力、演算、出力
これら全てを含めてリアルタイム性 >>430
>>427において>>429以外の要素って何ですか?
別に>>427に限らずとも
入力===>演算===>出力
CPUの一般的な機能です ID:YbkoUkq7さん。
「リアルタイム性とは即時応答すること」と解釈している、と書かれても不都合はないような気がします。
業務の中でリアルタイムOSを議論しているときに、その解釈で話に混ざったらまずいですけど。 >>425には答えないのですかね?
あなたなりの解釈
あなたのリアルタイム機械制御のイメージ
処理の具体例
そもそもあなたはリアルタイム機械制御をマイコンでやったことがありますか? あなたの
「リアルタイムOS」の概念の中での「リアルタイム」
を解説していただいてもいいですが
一般的なリアルタイムOSのリアルタイム性能とは違うようなので >>432
>小規模マイコンを使ったリアルタイム機械制御
そもそも、これが微妙な表現だと思うのです。
「機械の制御」という言葉と並んで「リアルタイム」という言葉がでてきたら、
システムをやっている人は「リアルタイムOS」の線での解釈での「リアルタイム」を前提にしてしまいます。
でも>>432ではできるだけ早く応答する、の意味ですよね。 >>432を見て「出来るだけ早く」に見えますか?
日本語力ヤバいですよ 「特定のイベントに対して、一定時間内に定められた処理を行う」
>>429の内容そのままですね >>438
すみません。たしかに行き過ぎた解釈です。 であれば>>383に書かれていることに矛盾はないってことになりますね。
戻ってきた。 ■ このスレッドは過去ログ倉庫に格納されています