マイコンソフト 悩み事相談室 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
では、質問、ドゾ〜 >>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使わずスクラッチでカリカリ書けば性能上がって
使用リソースは減るかもしれないが、保守性は下がるだろう
小さいシステムではそうせざるを得ないときもあるだろうし
早い話、
好きな風にやればいいと思うよ ま、皆様方には色々と御意見や御批判もお有りでしょうがw
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載せてた記憶。 タスク化すると、流れの中で「待ち」を気軽に記述できるので、ループをたくさん書けるのが楽。
キー入力待ち、トリガー信号待ち、シリアル受信待ち、xx待ちをバラバラに別ループで記述 1品物だと、富豪でやっつけちゃった方が楽に早く仕上がる >>462
そうやって
LED 1個キー1個でタスクを作るような間抜けなコードが出来るわけだな 解は無数にあるんだから一概に間抜けなコードとか言えないだろ。
与えられたリソースを使って仕様を十分に満たしていればとりあえず
ケチを付けられる理由はない。
「俺のコードは美しいぜ」とか「移植性が」なんて所詮自己満足の世界。 >>465
移植性とか美しいとか言ってるって事は
なにが問題点かわからないってことだな ポーリングで並行処理を行うようなプログラムを組んだことある奴ってあまりいないんだな
>>445と>>463ぐらいか
そう言う経験がないと>>383の言ってることは理解しづらいかもな わざわざ行儀の悪いプログラム自慢をしなくても良いよ >>469
理解できてない奴の筆頭乙 w
あと>>468のアンカー間違えてた
>>463 ⇒ >>462 マルチタスクいいよ楽だよと書いといてなんだけど、最近はとんと使ってない。
次々来る新規CPUにいちいち作ってらんないし、出来合いのを入れるのも
それはそれで面倒だしで使わなくなってしまった。
メインループ一個で、順番にポーリングしていくのばかり >>462
並列処理をやった事のない奴に、簡単なプログラムしか書けない奴に
いくら並列処理のメリットを説いてもムダだよ
シングルタスクのポーリングだらけのグチャグチャプログラムを死ぬまで書いてろ
たとえ小さなAVRであってもマルチタスクで書きたいって気持ちはよく分る >>472
使いにくさとのトレードオフになるけど、シンプルなものにすればいい
どちらにするかは人それぞれ、適用するプログラムそれぞれで
もちろん使わないという選択肢もある >>473
> たとえ小さなAVRであってもマルチタスクで書きたいって気持ちはよく分る
ソフトからスタックがさわれないPIC厨には無縁 >>475
たしかPIC18はOKでしょ?
でも >もちろん使わないという選択肢もある です
どんなCPUを使うかもあなたの自由ですよ
雑談になるけど
昔、シーケンサ(PLC)のプログラムを書いていた人とPCの事務処理プログラムを書いていた人に
機械制御の簡単なプログラム(もちろんシングルタスク)を書いてもらった事がある
PLCあがりは条件が成立しなければすぐにそのチェックルーチンから抜けてくるような
リアルタイム処理風に書いていたが
PCあがりはクセになっているのか、何回か注意したのに
ローカルの条件成立ループ待ちをしてしまう
PLC上がりの人に、リアルタイム処理になってますねと言ったら
「え、今までこうやってましたし、これが普通だと思っていました」
と言われて、そうだよなと納得した >>476
> PCあがりはクセになっているのか、何回か注意したのに
> ローカルの条件成立ループ待ちをしてしまう
windows3.1あがりならそんなことしないのだが。 >>473
普通CPUて色々な処理を行うのが普通なわけで
1つの仕事しかしない方が珍しいかと
私自身の経験を言うと
RAMが数十バイトの8bitマイコンの世界から
8コアSoCまで業務で扱うし
PCやLinux上のプログラムも扱う
RAMが128バイトレベルのマイコンで
せいぜいUART通信、キー、LED、リモコン、簡単なフィードバック制御くらいな簡単な処理
わざわざ複雑にしなくても
RAM/ROM/CPUパワーも余分にいるし RAM128バイトで何個のタスクにわけるつもり?
どう考えても>>479みたいな処理は無理だろ >>472
> メインループ一個で、順番にポーリングしていくのばかり
ないわー、テレビのリモコンみたいに単機能で基本ひとつのことしかしないようなやつならまだしも >>481
平行とか並列と言ったってしょせんシングルコアなんだから順番にやるしかないでしょに。
俺が対象にしてるのはシリアルやいくつかの接点入力、SPI、I2C、A/D、
OUTはモーターONOFF、PWM、たまに音声出力、そういうものなんだけど、
ループはなるべく一個でやる。
タイミングはタイマー割込みで正確に取るぞ。 >>478
その辺がどの辺を指してるのかよくわからんけど、マルチタスク/マルチスレッドをサポートしてる環境は普通にあるでしょ
>>383とかが言ってるのはもっと小規模な奴のこと もちろんタイマー以外の割り込みも使えるものは使って、バッファに取り込んでから
ループ中でポーリング >>482
別に好きにやればいいと思うが、今時面倒なことをよくやるよな
って感じ >>472
自分もマルチタスクのフレームワーク作ってるけど、個人の研究用だな。
同じマイコン使ってても、仕事では使わない。なんか問題起きると厄介だし。 マルチコアシングルタスクの実装を見たときの衝撃を皆に分けてあげたい。 >>481
良くある普通のシングルタスク処理
タイムクリティカルな処理は割り込みでやる
超小規模であればシングルタスクとシングル割り込みで十分
もうちょっと大きくなるとシングルタスクと多重割り込みで良い
多重割り込みとマルチタスクはもっと規模が大きい時に使う
そもそも
プライオリティもイベントもセマフォも無いプリエンプティブなマルチタスクなんてどうやって使うんだ?
それこそ各タスクでポーリングするしか無いのでは? >>487
OpenMPで使うとかじゃなくて?
ISR専用でISRに重い処理をさせるとか 非対称デュアルコアで、
サブコアはISRの形でしか動けないマイコンがあったような
今のGPUにちょっと似てるかも
あと、
マルチコア(8コア)のマイコン用OSなのに
各コア独立に動くってのもあったな
PCが普通だと思ってると色々と驚く >>476
ループ待ちは非常に短い時間なら普通にやる
最近多くのCPUに載ってるLL/SC命令なんかはループ前提だし
セマフォやミューテックスもループではないけど条件が整うまで待つ為の物
通信もブロッキングの方が圧倒的に楽に作れる場合が多い >>486
個人の研究用にOSを書くのは勉強にもなるしオススメなんだけど
>>383の場合は「簡単だし楽だからみんなも作れ」としつこく書いた前科がある
機能がほとんどないOSもどきを作っただけで >>488
> プライオリティもイベントもセマフォも無い
なに勝手に妄想してディスってるんだよ...
タスクスイッチ作るならプライオリティはともかく待ち合わせ機能を実装するのは当たり前、でないとほぼ意味ないし
>>492
> 機能がほとんどないOSもどきを作っただけで
OSってなんかよくわからんけどすごく難しいもんだって思ってないか? w
ちょうど>>493があげてる本の著者が書いてるWebがあるからこれでも読んどけ
ソースも公開してくれてる
http://monoist.atmarkit.co.jp/mn/spv/1107/25/news004.html 欲しいものが無ければ諦めるか、自作するかの選択で
諦める人と自作する人がいるって簡単な話だよ
自作する人は役に立つから自作するって言ってる
自作した事が無い人がそんなもの役に立たないなどととやかく言ってもしょうが無い >>495
>欲しいものが無ければ諦めるか、自作するかの選択で
>諦める人と自作する人がいるって簡単な話だよ
そんなことは役に立たないだろう、金銭的にペイしない、って周りから批判的に言われるようなことを
グダグダやっている人の存在を許す組織と、許さない組織があります。
変則的な事態に強いのは前者だと思います。 タスクリスト、イベントリスト、セマフォリスト、メールリスト
こんくらいあればだいたい間に合うよね。
チェーンリストじゃなくて配列にして、ヒープはめんどいからやらないことにすれば
実装は簡単か どこから組織的な話になるんだろう?
前提がおかしすぎる >>498
すみません。端折ってしまいました。
>欲しいものが無ければ諦めるか、自作するかの選択で
>諦める人と自作する人がいるって簡単な話だよ
後者みたいなことをする人が存在できる組織は変則的な事態に対応する力があるって話です。
あたりまえながら、俺の見聞きした範囲ですが。
自作OSは業務に使わない・使えない、という結論と
自作OSを作る行為が業務の役に立つ・立たないということとは別だし、
そこを混ぜて話をしたらお互いに接点も見いだせないと思うのです。 だれも組織的にやろうなんて話題は出してないから混ざりようもないでしょ。
まあ時分割くらい昔から業務でも使われてるんだけどね。 >>489の最後の3行の「話が混ざる」ということは組織の話はしてないですよ。 >>496
個人のスキルアップなら業務外にやってね
あと製品に搭載するとか言い出さないように >>502
少なくとも業務の話は出てたはずだし>>499の主張の意味もわかる
それぞれの3回の書き込みだけみれはきみの方が変なヤツ >あと製品に搭載するとか言い出さないように
それをうまく抑える常識派 (というと、とても語弊がありますが) がいないと組織が成り立たないですね。
昔いたところに、日がな役に立たなさそうな実験とか設計とかしてる人が何人かいて、
トップの人も普通にプロジェウトに組み込まれた俺も同僚も、あいつらそれでいいんだと考えていました。
小さい組織じゃそんな余裕はないですが。 少なくとも俺には>>501はさっぱりわからんが... 言った言わないの話は、森友と日大で良いよ。
俺は今まで会社と無関係な勉強や実験を散々したが、
しばらくすると、業務でその知識を使う場面が生じ、仕事に使う羽目になる経験を沢山してる。
電子工作だろうと、株取引だろうと、園芸だろうと、
自分で考え苦労して工夫した事は応用が効く。 業務中に勉強しちゃダメ
業務外で習得したスキルは業務で使っちゃダメ
なんだろ? >業務中に勉強しちゃダメ
>業務外で習得したスキルは業務で使っちゃダメ
そんなこと言う人いるかな? 人と同じ事をやっているだけでは人より先に進むことは出来ない
誰もがやれる事をやっていたら納期と価格の勝負になってしまう
……なんてこんな所で書いてもしょうがないか >>511
プリミティブなことを追体験することや、既存のものを自分で作ることを、
「車輪の再発明」「先に進む行為ではなく後ろ向けに進む行為」と考える人もいる、
ということでしょね。
どんどん進歩してる世の中だし、その時間を新しいことを取り入れることにむけるべき、
という考え方もわかります。
幅の広い電子やITというジャンルの中だと、小さい組織も個人もできることは限られてて
「仮想の他の人」にできることを、一通り自分もできるようにすること自体ほぼ不可能です。
それゆえに、急き立てられるようなプレッシャーの中で好む好まざるにかかわらず
ブラックボックスを受け入れつつ新しいことを取り込んでいこうとしている人からすれば、
原理的な部分に取り組むのはかったるいことに見えても仕方がありません。
もしそれが組織なら、誰かが新しいことをやって、誰かが足元のことを固めていく、というような
差配を上の人がすればいいのですが。
あと、自分が向いてる方向が正しいことを認識するために、他の人も同じ方向を向くべき、って
考え方になるとぎくしゃくします。
自分が向くべきでないと考える方向に他の人が向いていても、自分の正しさと他の人の正しさは
両立することが少なくないのにね。
5chのような場所で、ほか人のやり方が間違っている、と感情的になってしまうのはヘンな話です。
たぶん、組織や個人の中で同じような議論や葛藤があって、それがここで出てしまうのだと思います。 そんなつまらないこと外注しろとか、
オフショア開発で安くしろとか言ってたら、
何も作れなくなっていたと言うオチ。
様々な車輪の再発明をしてると、
ロケットとか宇宙船を発明するようになってくんだ。 >とか言ってたら、
ここに来ている人の多くは言われてる立場だったりして。
言われてる立場だからこそ、そこからフリーでいられる人が疎ましいのかも。 >>508
業務中に勉強することも当然あるが、
業務で勉強する以上は勉強の効率や成果が期待される
普通はもっと業務に直結する効率の良い学習をする
下っ端であれば無許可でやるのもまずい
普通は業務で使わないコードを書いていたら
遊んでいると思われる
暇で仕事がない期間にこっそりやるのがせいぜい 別にOSを自分で作ること自体を私は否定していないし、
個人的には非常に楽しいと思う
他人に強制する
OSを作った事がない人を見下す
こんなヤツが問題だってこと 自作OSに限らずマルチタスクやマルチスレッドは罠がたくさんある
ベテランエンジニアでもミスすることもある
業務でも趣味でも、
使うときは以下のような項目を学んでおいた方が良い
同期、排他制御、イベントドリブン、様々なロック現象、アトミック処理、マルチコアの注意点、アウトオブオーダーの注意点 >>516
> 他人に強制する
> 個人のスキルアップなら業務外にやってね
> あと製品に搭載するとか言い出さないように
とか強制してる奴が何を言ってるんだか w >>518
>>516は「他人に強制すること」を問題だと言ってるのではないでしょね。
「他人に自分が作ったOSを使うことを強制すること」を問題だと言ってるのだと思いますよ 当然その通り
わざわざ書かないとわからなかった?
それは失礼 >>520
で?
対象はなんであれ匿名掲示板で他人に強制するなんて意味ないって嘲笑してるんだが
ってところまで説明しないとダメなの? >>518の書き込みで>>522の意味だと?
それは無理がありすぎる >ってところまで説明しないとダメなの?
そうでしょね。>>520が誤解だと言うぐらいなら、ですけど。 >>523
ああごめん、理解力無さすぎる奴もいたのね w >>525
つきあいが長くてだいたい考える傾向がわかっている相手とのSNSでのメッセージ交換とか
対面していて顔色、身振り手振り、声色を把握できる相手とのコミュニケートと
一緒してちゃ駄目だと思います。
文字と説明を尽くしましょうよ。 >>526
別に全員にわかってもらおうとは思ってないのでわからないならそのままでいいよ ■ このスレッドは過去ログ倉庫に格納されています