マイコンソフト 悩み事相談室 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
では、質問、ドゾ〜 各行末にコメント
だから全部の行に意味のないコメントを書いてるようなのを老害って言ってんだろ
意味のあるところに意味のあるコメントを書かないとな
行末はその行に関するコメントになるが
そういう小さな単位のコメントは規模が大きくなると邪魔になる
意味のあるものに絞らないと
まとまったブロックに対するコメントは行末には書かないよな
一行〜数行、コードのインデントで書いたり
関数ヘッダやファイルヘッダは普通は複数行で
インデント無し
時と場合によってそれぞれの適した書き方がある >>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を使いこなせていないせいだと思う。（失礼！）
＞何度も書かれるとこちらも意見を言いたくなる
あのネ、それはネ、仲間が一人も居なくて寂しいんですぅ、天涯孤独なんですぅｗ
ほとんどの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に書かれていることに矛盾はないってことになりますね。
戻ってきた。 >>425
機械制御 リアルタイム
って書いてあればこのスレ見てる奴の大半はハードリアルタイムなんだろうなって想定する
そもそも>>383はポーリングでも書けるけどディスパッチャーを使った方がプログラムがスッキリすると書いてて、応答速度の話はしてない
無駄に速度を追い求めるのは素人のやること 無駄に自作ディスパッチャとか無駄にアセンブラとかは趣味の世界の話で
今時の業務だとやらんな
移植性も問題点の発見のしやすさや性能の見積り性も劣る
超小規模マイコンではデメリットの方が多い
OSが必要であれば、
当然ちゃんとした機能や信頼性や性能や実績が必要
IDEで扱えることも判断の材料
まともな判断をするなら自作が候補に上がることは無い ははは
機械に特化したPLCだって
一見リアルタイムでマルチタスクやってるように見えるが
中身は普通のマイコンだぜ
入力と出力のタイミングだって、スキャンされてストックしたデータを使ってるだけだし
リアルタイム入力のために専用のハードをつけて対応したりしてるだけだ
そういう場合にはスキャン途中であっても割込みで現在値に置き換わる
大筋で大したことをしていない 否定的なことだけだと良くないな
具体的に
コードがきれいになったとか
工数が減ったとか
性能が上がったとか
使用リソースが減ったとか
そういう例を上げてくれれば良いのだよ
>>398みたいなまずあり得ない例じゃなくて (RT)OSの役割は基本的には標準化(隠蔽)だからな
工数が減ってコードは綺麗になるかもしれないなが
性能は落ちて使用リソースは増える(こともある)
それでもデメリット < メリットなら使う意味がある
RTOS使わずスクラッチでカリカリ書けば性能上がって
使用リソースは減るかもしれないが、保守性は下がるだろう
小さいシステムではそうせざるを得ないときもあるだろうし
早い話、
好きな風にやればいいと思うよ ま、皆様方には色々と御意見や御批判もお有りでしょうがｗ
tiny2313のような小さなMCUをマルチタスクで動かしますと、
新たな世界＝プログラミングって楽しいな、MCUって楽しいな＝が
開けるものと信じておりますです、ハイ。
ディスパッチャはとても短くて、ほとんどのCPUに移植できます。
難しいお考えはひとまず置いといて、まだの方は是非お試しを。
>>383 以降の貴重な御意見の数々、誠に誠に有り難うございました。
皆様方のなお一層のご繁栄を願っております。 今はもう旬じゃないけど、ITRONもどきの小さいマルチタスク作って使っていたわ。
多重割込みのタスクスイッチをやめちゃえばすごく簡単になるんだよね。
タイムスライスでゆっくりやるタスクと、高速応答部分を分けて、とにかく最小時間で
割込みを返せば多重割込みしなくてもOKな場合がほとんど。 多重割り込みを許可するタスクスイッチ、を端折ったかな？ 多重割り込みの各ISRをタスクと名付けて
それの切り替わりをタスクスイッチと言ってるのかな？
リアルタイムOSを使うと多重割り込みを使わなくて良いように書いてる人がいるけど
そんな事は無いよな
主張がいまいちよくわからん >>450 ＞タイムスライスでゆっくりやるタスクと、高速応答部分を分けて、
そだねー、タイムスライスでも割り込み処理は必須だよね
たとえばUART関連処理を別タスクに分離しても、よほど低速通信でない限り
UART受信割り込みを使わざるを得ない場合がほとんど
タイムスライスの主な目的はタスク分離だよね
もっともI/O処理ならDMAが最強だと思う
DMA付きCPUをもっと増やしてくれー 8bitCPUにOSとかDMAとか
なんだかなあ
UARTの受信なんか普通に割り込みで使えるように出来てるんだから素直にそうすれば良い
キューに1バイトコピーするだけなら非常に軽いんだから
少なくともタスクスイッチなんかするよりも DMAなんか
ちょっと高機能なのだと普通に8bitCPUよりも多くのトランジスタを使う
マイコンの規模に見合ったペリフェラルにしないとね
UARTだとまずはFIFO
これだけで割り込み回数も減らせるし
割り込みの遅延スペックも緩く出来る
16bitクラスのマイコンのUARTだと大抵はFIFOがある ISRはタスクじゃなかったか。 ISR実行中は他のISRを一律全部抑止してタスクスイッチャを
簡単にするの意。
最近ごぶさたなのでいいかげんな物言いしてもうたかも RAMが128バイトじゃ
マルチタスクにしたらタスク1個あたりのスタックは少なくて、
割り込み分のスタック分を各タスクから引いたらほとんど残らないのでは？ 30年近く前使ってたマイコンがRAMが512バイトだったかな。
これくらいあると結構いける。
GUI付で作った奴は62256載せてた記憶。 タスク化すると、流れの中で「待ち」を気軽に記述できるので、ループをたくさん書けるのが楽。
キー入力待ち、トリガー信号待ち、シリアル受信待ち、ｘｘ待ちをバラバラに別ループで記述 1品物だと、富豪でやっつけちゃった方が楽に早く仕上がる >>462
そうやって
LED 1個キー1個でタスクを作るような間抜けなコードが出来るわけだな ■ このスレッドは過去ログ倉庫に格納されています
