.
∧ ∧
( ´・ω・) ＜ コンフィグって何? 昆布なら知ってる。 ボラチルって何? ボラは魚だよ。
（ ∪ ∪ ,.-、 ,.-、 ,.-、 ,.-、
と＿_）__） (,,■) (,,■) (,,■) (,,■)
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
では、質問、ドゾ～ )())))(((()))((((((())(()()()(())())()(((()(())()())())()(())(()))())(()))()
()(()))()((()())(())))()())()))())))()(())(((()()(())((()())()((()()())((()(
))())()())))))(())))(()((()((()))(()()))()()((()()()()()))((()()()(((((())((
((())(())))()(())))()))(()((((()()()((()())(()))))(()()())((()(()))()())()((
((()()(((()))((()((()(()(((())(()()()))()()()))))))()()()(()))))((()()(())))
()))(((((())((()(((())())(())))())())(((())(()))()())()()()())(((()())(())))
)(()(()())(())()()(((())))())))))())))())()()(((((((((()))())((())(()())(()(
))()((()()()((())(((()(()))((())(()()(()()))((()))()()))))(((((()))))(()))()
)((()(())()()))((()))()()((()()))())((()(((())(()))(()))((()())(()))(())())(
((())))((((((()(((()())()()())()())((()()(())))())())()())(((()()))))())(())
)))())()(()()))((((())))((()())()((()()(())()(()()))()((()()(()))((((()))())
))((()))))((()()))())((((()((()()(((()))((((()))))(()()(()()))))(()(())())()
(())()))))))))()()((((((()))()())((()((()))((()))((()()(()(()()()((()))())()
(()()((((()(((()()()))))()()()))()()()(()((())())))))())))(()))))((())((((((
((()))()(()))))((()((()()))()(()()()))((()))())()))()))()((()(()(())(((()()(
(()(()()()))()(()))(((())((()()())())(())))))())()())((()((())()((()()(()())
())))(())))((()(()))()(()(())()((((()())((())))))((()))))()(((())())(()((()(
((())(()()(()(((()))))())(()()(()())))))((()(()()())))))(()(()((()))()((())(
()()())))(()))(()())(()((()))()))()(()(((((()((()))(((()()()))((())()(()))))
()())((()()()()())()())())()(())()(()(())()(())()()())(((()()()(()))()())()(
(((())()(((()))((()((())()))())((()()))))())())())(()()))()(())()()((())()((
)((()()())()(()(()))))())(())))(((()()())(())(()()()))(())))()((())()((()(((
)))(())(())())(((())((((((())(()))(())()((((()(())((())(()(()))))(()))()))))
)))(()))((((((((()())((()()()((())(((()(())())()()()()((()))))))()()))()()))
))(()(())))(()()(((()()(()(((()()((((())))()())))(()(()))))()))((()))(()()()
()()(()(())()())))()()))))(((()((())())())()))(())(())))(()((())(((())(()(((
)(()(()(()()((()()))))()())))))()))))((())((())())()())(()((()())(()(()(((((
())()()())()(()()()()))()(((()(((()(()(())))))))))(((())))(()((()())()())(((
))()()(()()(()))(()(((())()(()))))))))((()(()))()(((()))))()((((())()))(((((
(((())))))))()))))(((()(()((())(()())((())(((()))()((((()))))()()(()()()())(
()(()(())()(())))()())))())))()))(())()))()((())()(((()))((((((()()((()()()(
)(()(()()()(()()((()))())(()()()()(()())))))((()))(((((()))(())((()))())()()
))())((()(()()((()()())()(()())())())))(()))))(()(()((()())(((()())))()((()(
)))))()())(((((()()()))((())()((()()((((((())()((()))(()))((()))())))))((())
)((()()((((())()())(()(((((()))(((()(())()))))())()()()))(((()))((())())))))
()())((()(())(()(((())((()))(())(())))((())()()))(())(())((()()))()(()())())
)(()))(()))()()(()((())))()()))())()()(()))))(())(()(()()(((())(((((()(()())
())((((((()()()()()()(()()(())))()))()))()(())))(()((()()())(())())))(((())(
))()(()()))))())())()()(())))()((()()((()()(())(((()))(((()()))(((()))((())(
)()))()(())(())((()()((()()((((((())))(()()))((()())()))))())()()))(((((()))
)((())()())))((()())))(()(()(()())))(()(())((()()))((()(()))())()()))((((()(
))(()))))((())()(()()())()(())()(()()()()()(()(((((((())))())))(()())())()((
((()(((()()))((()))))()(()))()(()))(()())())((()(()())()())(())()()()(()))((
)(())(())(()(()(((()))(((((((()()()(()))()()))))(()))())())(())))))(((())()(
()(((())))()((())()()((()())))()))()(((())))()))))()(((((())))(())((()()((()
(()()))())()()(())((()()))(())()()(()(()()(((()))))((((()(()(()(()))))()()))
())))(())())))(()((()((())()())))()(()((((()))))()(()(()))(()()()()(((()())(
((()())(((()()))((()()))()())))))))))()(()((((()(())))(()))(((((((())())(())
))()()(((()()))((())())))((((()())(())(()()()(())(()(()(()()((())())(())))))
))))))(((((())()((()((()((((()(())))))))))))()())(()())(())((((((())())))(((
間もなく、終点 東京です。
18番線 お出口右側です。
どこで聞いていいのかわからないので、ここでお尋ねします。
マイコンにはRAMとEEPROMがありますが、
EEPROMには書き込み回数の限界があるようですが、
RAMには、書き換え回数の限界があるのでしょうか?
ドライブレコーダーのように、記録し続けて、何かあったときには、その前後を記録保存するとき
常にEEPROMに書き込んでおけば、楽だと思うのです。
しかしEEPROMに書き換え回数があるので、まずはRAMに書き続けて、
何かのトリガーでEEPROMにコピーすることになると思います。
はたしてRAMにも書き換え回数があるのかしら、と思いました。
RAMに書き換え上限はありません。
あと、EEPROMは「電気消去可能な書き込み専用メモリ」ですが、単にEEPROMというと狭義のEEPROMを指すことが多いのです。
大雑把に言えば、電気消去可能な書き込み専用メモリには、FLASHメモリ と EEPROM があります。
マイコンのプログラムの記録に使われているのはたいていがFLASHメモリです。
FRAM、MRAMというものもありまして、RAMのように書き換えができて、電源がおちても消えません。
>>5
ありがとうございました。
分かり易い説明ありがとうございました。
>FRAM、MRAMというものもありまして、RAMのように書き換えができて、電源がおちても消えません。
いいですね。これを少し調べてみます。
アドレス、データは、RAMと同じようにパラレルで、RAMを剥がして、そこに貼り付けられれば
最高ですね。(動作速度が遅いかも、ですね) すみません hexデータをマイコンに入れたいのですが
The target circuit may require more power than the debug tool can provide. An external power supply might be necessary.
Connection Failed.
と出てしまいます。
翻訳にかけると
目標回路は、デバッグツールが提供できるより多いパワーを必要とするかもしれない。外部の電源が必要であるかもしれない。
接続失敗する。
てなって意味がわかりません(T_T)
どうしたらいいですか
>>7
見たところPICで、PICkit3だよね？
USB抜き差し
IDEで電源にチェック入ってるか確認
まずやってみて。 全く電源がないと、そういうエラーメッセージになるよ
だから文面の通りかと
ざっと見た感じ電源にはチェックがついていました。
あと僕が使っているのはpickit3です。
あとご指摘ありがとうございます。
やっぱり電圧をいじってもできません。
やっぱりpicライターを変えたほうがいいのでしょうか。(;_;)ガクガク
このメッセージは、供給電圧をモニタしたときに規定値になっていない時に出るのだと思う。
文言通り書き込み回路自体の消費電流が大きいか、
ＰＣ側の供給電圧が低い、
ＵＳＢケーブルによる電圧降下もあり得る。
俺の場合、外付けＨＤＤ用の２股の電源強化ＵＳＢケーブルを使ったらメッセージが消えたという経験がある。
>>16
書き込み回路自体の消費電流
は、
書き込み対象回路の消費電流
です。 pickit3の供給電力はすごく小さいんだから
USBケーブルとかPCの電源とかは関係ないよ
問題はターゲット側
pickit3が供給できるのは30mAまで
ターゲットの消費電流がそれを超えている
これが一番普通に考えられる原因
事実として起きたことを書いただけ。
対象回路の消費電流は、数ｍＡだった。
そもそもＰＩＣ以外ほとんど回路ついてなかった。
PicKit3付属の硬い赤いケーブルが見当たらなくて100円ショップのケーブルを使ったら
このメッセージが出たからケーブルを取り換えたら動いた。
>>23
俺は「ＰＣ側の電源供給」って書いたんで
「ＰＣの電源」なんて書いてないからね。
前後から読めばわかる通り、Ｐｉｃｋitに対するＵＳＢからの
電源供給の話してるのだから、
誤解した上に噛みつかないようにね。
> USBケーブルとかPCの電源とかは関係ないよ
は、そもそも認識間違いってことで。 500mA流せる規格の物に30mA+α供給できないPCやケーブルねえ
ご指摘ありがとうございます。
色々とやってみます。
本当にありがとうございます。
>>27
これまでの回答で解決したかもしれませんが・・・
以下のことを知っておく必要があります。
・書込対象のPICには電源が供給されている必要がある
・PICKit3は、対象のPICの乗った基板に、電源を供給する能力がある。
です。
PICKit3には、書き込むPICの乗った相手回路に、
「少しくらいの電源なら、PICKit3から供給してあげられるよ」という親切な(?)機能があります。
でも、この「供給できる電気」の量には限界があり、そんなに多くは供給できません。
PICKIt3は、PICに書き込む前に自分が供給できる電気を超えないかを調べる能力があり、
この調査で「やばい、電気多すぎだぁ」と判断されると、そのエラーメッセージが出ます。
ではどうするのか、というと簡単で、
書き込むPICの乗った基板は、別の電源で ちゃんと電気を供給させてあげれば良いのです。
つまりPIC基板は、PICKIt3からは書込む信号だけをもらって、
PICKit3から電気をもらわなければ良いのです。
しかし考えてみると、
相手の基板がどれだけ電気がいるのかわからないのに、
「親切に」電気を供給できる機能があることが、今回のような誤解を招いていると思います。
MPLABのエラーメッセージが「PICと通信できません。PICに電気を入れていますか?」と言えばいいのです。
PICKit3から電気を供給できることを知らないユーザーに「電力不足だ」と言っても混乱するだけです。
私も昔、同様にケーブルを、取っ替えひっかえして書き込むことができました。でもそれは、
PICKit3に電源供給機能があることが原因であり、
USBケープルが細いとだめ、ハブを通すとだめ、ノートPCだとだめ、などの伝説が生まれます。 回路上にPICだけしかなく
PICkit3とPICの一騎打ちの状態でもこのエラーは出る
その場合外部電源をつないでもエラーは出る
経験が少ないくせにエラーメッセージそのままのオウム返しの回答してる人は
意味無いから黙った方がいい
あなたの回答で解決するなら誰も騒がない
>>29
それ、俺も同意。
エラーメッセージの内容と目の前の回路の状態が合ってない場合があるのは
PICkit3使いなら周知の事実。
ハッキリ言うと>>ID:KO/+DQKwの線が正しく、>>ID:UmD4ojnAは見当違い。
だいたい>>26を読めばどういう人間かわかる。
こういう人間の言うことはだいたいあてにならない。 人格云々は別にして、
それが事実だとして、USBのケーブルを変えたら状態が変わったのはなんでなんだろね。
データ通信が不安定なのが解消されたのかな？
>>16の言う
＞外付けＨＤＤ用の２股の電源強化ＵＳＢケーブルを使ったらメッセージが消えた
がホントなら、PICkit3の基板から5Vのライン引きだして外部から5V補強するかなあ…。 PICkit3の回路図眺めてた。
ターゲットPICのVddはPickit3の電源(=USB供給)以下の電圧しか出せないように見える。
一方、プログラミング電圧Vppは昇圧SWレギュレータが組まれている(当たり前)
大雑把にいうと、VddはUSB電圧をMOS+OpAmpで定電圧化し逆流防止のShotkeyを通ってVddに出る。
基準電圧はPICkit3のメインコントローラ(PIC24F3256)が出す。
このコントローラは6ピン出力コネクタ上のVdd電圧を読むパスを持っている。
と言うことで、5.0Ｖ出すにはUSBがそれ以上あることが前提っぽい。
実際には出力が5VピッタリでなくてもNGにならないだろうけど。USBの電圧低下には極めて脆弱。
PICkit3へのUSB電源供給電圧を上げれば良いけどHub使って5.5Vぐらい食わせちゃうとかかな。
#念のため、規格では最大5.25Ｖですよ。
USのフォーラムを見たら、このメッセージへの対処として、
PICへの供給電圧設定を4.7Vにしろと言う回答があった。(4.75ってことだろうけど)
まあ、多少マシにはなるか。
USB規格が500mA供給できるとか無関係だし、
USB規格は受電側が4.4Vで動くことを要求してるけどPICkit3は守ってないんじゃないか。
>>33
それやるんなら、回路図ちゃんと読んだ方が良いよ。
USBの5Vラインは、入口直後にPNP ＴｒでＳｗｉｔｃｈされてるので良く考えて繋いだりパタン切ったりしないとまずいと思うから。 初心者なので助かりました。
本当にありがとうございました。
質問お願いします。
C言語で、メイン関数 mai() は、どのくらいの長さがいっは゜んてきなのでしょうか?
といか、どのように書くのがよいのでしょうか
main(){
key_check();
LCD_disp();
IO?syori();
}
のように書くという人もいると思いますが、これでは簡潔すぎて、何をしているのかわかりません。
かといって
maij(){
if( SW==1 ){
count++
if( count<500 ){
LED=on;
} else {
if( SW2==1 ){
LED=off;
} else {
LED=on;
}
これでは細かすぎると思いますし。
}
}
>>38
というか、上も下も1回やったら終わり。
形にこだわる前に動くプログラムをどんどん書く方が良いような気もする。
なんだかんだ言っても、関数に分けていくルールは所属組織に合わせることになる。
そのあたりも含めて記述のパターンの見やすさや感覚的な受け入れやすさは人によっても
同じ人でも時期によっても違う。
実際、上の記述について
>これでは簡潔すぎて、何をしているのかわかりません。
と考える人と
>簡潔で良い
と考える人がいる。
個人でなら。
自分だけで書いて使うプログラムなら、自分が理解しやすいのが一番。
100人のうち90人が良いと思う方法でも、あなたが残り10人のグループに入るような人なら、
90人の方法に合わせる必要もない。 mainの見た目より個々の関数の再利用性を重視したら？
今回専用の関数になってない？次回以降使いやすい関数になってる？
>>42
そういう話でないとしても、結論の出ないとりとめない話ではあるよな。
>>38がどういう立場と目的でこんな質問をしたのかがわかると話もしやすいはず。 >>45
・絶対的な正解はない。
・でも傾倒している人は自分が傾倒しているものが唯一絶対だと考える。
ってところだと思うが、プログラムに限ったことでもなくて、
「～は宗教」は色々な分野使われる、手垢のついた言い回しだよな。 実行速度を重視するか、メンテナンス性を重視か、サイズを重視か、
なんて所で適当に決るんじゃ無いか。
買ってよかったをすべての人に。
どこよりも安くどこよりも良いものを。
開いたページの検索項目に商品名や品物の名前などを
入力して検索。価格の安い順、よく見られている順で検索可能。
お気に入りの商品が決まったら、ショップへ。数量（個数）を
選択し、カートに入れるを選択。ご注文手続きへを選択。
住所や支払い方法を選択。最後に確定を押すと、入力したメール
アドレスに商品を購入した証拠のメールが届いて完了。会社によって
佐川急便やヤマト運輸などの配送状況を確認できます。
買ってよかったを痛感して下さい。
「価格ドットコム」（価格.com）です。
http://kakaku.com/
お気に入りにまずは、追加して下さい。 >>38
１行ごとに横にコメント入れて、何をしているのか説明してみるといい。
説明文だけを見て、全体の動きがすぐ把握できるならそれでいい。
何度も読み返さないといけないようなら、もっと簡潔にまとめる手段を
考えたほうが良い。 >>49
標準的には、画面何ページ分くらいの長さが良いでしょうか? >>50
今は画面の文字の桁数、行数に主流といえるようなものがなくて、いろいろなので、そういう規範を設ける意味がない。 >>50
80桁24行の画面で、2～3ページだと先輩が言っていた。
コメントは勘定に入れない プログラムの中でコメントをアスタリスクで区切って
/**********************
・・・
・・・
***********************/
などと書く人もいますよね。
あるいはイコール記号やマイナス記号を使う人もいますが。
皆さんどんな書き方してますか？
参考にしたいので教えてください。
僕の場合は、
// -----------------------------------------------------------------
//
// ネギ振り制御プログラム Ver0.9
//
// -----------------------------------------------------------------
/*****************************/
こ れ は ま ち が い
/*****************************/
#if 0
ほうらなんでも書けるんだよ～～～
#endif
i++; // これも間違いだったっけ。 \
if(i==3) i=0;
//////////////////////////////////////////////////////
// スラッシュ押しっぱでいいからこうしてる
////////////////////////////////////////////////////// 👀
Rock54: Caution(BBR-MD5:0be15ced7fbdb9fdb4d0ce1929c1b82f)
//////////////////////////////////////////////////////
// 右下の目玉はなんだ？
////////////////////////////////////////////////////// 👀
Rock54: Caution(BBR-MD5:0be15ced7fbdb9fdb4d0ce1929c1b82f)
私は重要度、頻度、レベル（深さ）などによって自分なりの規則を決めて、
タイトルを =====、-----、***** などで2行で挟む、1行だけにして挟まない、
とかやってる。
>>61
それは やるね。
/* --------------
/* --------------
/*
/*
/* --------------
/* --------------
と、繰り返す人もいる >>56
これは、ソースのコメントアウトしたり、２つの方法を切り替えたり
するのには一番いい方法だと思う
意外に使ってない（知らない？）人が多くて
「ちょっと、この部分コメントアウトして見たら」って言うと
エディタで//しちゃって、後でどの範囲をコメントアウトしたか分からなく
なって困ってるの見たことがある
但し、本来のコメントに使うのはどうも #if 0の話のついでに
#if 0って行頭に書くのが殆どだと思うけど
#if 0のネストの必要が発生した場合、中の#if 0インデントする？
最近の頭のいいIDEだと条件見て色分けしてくれるけど、
そうでもない場合も結構あり…
>>65
この板でなくても良いかもしれないけれど、この板でも良いのではない？
スレに関係なくもない微量脱線が少しぐらい続くぐらい、
エログロインモラルヘイトみたいな激烈逸脱が1レス入るよりずっとマシだと思うんだ。 >>63
//の後に日付入れてる。
その困ってたやつほどアホではないんで。 >>67
よく分からないけど、各行の//の後に日付入れてるの？
それよか、#if 0 // date-time のほうがよくない？
#if 1 ってすれば簡単に元に戻せるし どこがどういいのかな？
#if 0
#endif
どう見ても煩雑じゃん。
みなさんは関数名の後に続く中括弧の前に改行を入れますか？入れませんか？
例えば、
int main(void) {
/* 処理 */
}
のようにするか、
int main(void)
{
/* 処理 */
}
のように書くのか、どちらが多いのか気になります。
>>71
あのさー、どちらが多いのか気になるのはわかるけど、
僕は
main(){
} >>70
同意。
俺は全部//
そんなことに凝らなくてもいいと思う。
>>71
自分は上のように書いてきたけど、
最近良く使うMicrochipのCode Configuratorが吐くのは下の方だな。
混在してるけど、別に気にしないのでそのままだ。 >>73
でも、そっちの方は、行数が増えるばかりで、
いいと思えない。 >>71 mbedで整形すると
int main(void)
{
/* 処理 */
}
とされちまぅ >>70
10行コメントアウトする場合は#if 0の方が早い
1行なら//
行の１部なら /* */
臨機応変に色々と使えるようになっておいた方が良い >>77
/*
10行
*/
エディタがやってくれるだろ。
#if 0 はコメントじゃないし。 >>77
単に人と変わったことやりたいだけだろｗ
何も奇をてらう必要ないんだよ、馬鹿馬鹿しい。
>>78
それな。 >>77
これはコメントだと明示的に示すことが大切であり、誰にでもそれがコメントだと分かることが重要。
#if 0
#endif
は本来コメントではないから誤解の元となる。
臨機応変という無意味な四字熟語は何の免罪符にもならない。 なんか自分が書いたのにすごいレスがついてるようでｗ
>>63で書いてるけど、「本来のコメント」に "#if 0 ～ #endif" 使えってことじゃないです
だから、「#if 0をコメントに使うな」っていうレスはその通りだと同意するし、批判は見当違い
で、本来の趣旨は、一時的なソース（プログラム）の変更・切り替えには
// とか /* */ よりも "#if 0 #else #endif" のほうがいいんじゃない？ って話なんだけど ついでに書くけど、一時的にソースの変更する場合、コメントアウトとか
じゃなくて、関数丸ごと書き換える方法もある
その場合、元の関数は削除せずに、関数名だけ書き換えて実質的に
呼び出されないようにしておく（fname → fname1)
新しく作るほうは、元の関数をコピペなりしてどんどん書き換えてやればいい
（fname1 → fname)してやれば最悪でも元に戻すことは簡単だから
大胆なこともできる
もっとも今は、ファームの世界でも（インチキ）ウォーターフォールモデル全盛で
一度コーディングしたソースをテストステージで思いつきでいじっちゃいかんだろうからこういうことは、派遣とかで行ってるんだと出来にくくなってるかも･･･だけど
もういい。
誰も気にしてないし、誰も
#if 0
#endif
何て使わないし、誰もお前のチンケな小技語り聞きたくない。
なぜレスに感情を刺激するようなトゲを潜ませる必要があるんだろうね。
> 誰もお前のチンケな小技語り聞きたくない。
これは同意
ケンチを評価するのはID:AC5iuXLgさまの思召し
ある種のコンパイルスイッチのように使うなら、#if 0 は悪くないけど情報をもっと詰め込みたくなるな
コンパイルスイッチに、#if（何たら式）使うとかは常識だよね
そんで、コンパイルオプション変更するまでもない一時的なスイッチに
#if 0 とか #if 0～#else とか使うのも常識だと思ってたんだけど
違うのかな？
今は //厨が主流なの？
「コメントアウトした範囲明確でないと困らない？」と言う疑問にも
「憶えとけばいい」「//毎に日付書いとけばいい」ってこと？
世の中、頭のいい人ばっかりになって結構、結構
日本の将来も安泰ですねｗ
コメントの話だったのが、いつの間にかコンパイルスイッチの話になってしまったでござる。
こうなるともう何でも言いたい放題でござる。
そして、とうとう日本の将来まで心配してしまうでござる。
常識かどうかは、その人が暮らしているエリアで判断すれば良いのではないですか。
ずっと決まった人だけでプログラムを書いて製品づくりをしているグループ内で、
他の世間とちょっと違う記述ルールが存在する場合でも、その記述ルールもそのグループの中では常識ですし。
逆に言えば、自分が感じている常識なんて脆いものだと思っていてもいいぐらいで、
匿名掲示板のメリットは、常識の多様性を感じられることでもあります。
このコメントの方法が適切かどうかも、まとめきることは難しくて、
どこかで諦めたり引いたりして収拾しないと仕方がないものです。
>常識だと思ってたんだけど 違うのかな？
違うのかな？に対して同意する人は、あなたと同じ常識で暮らしている人、ってことに過ぎないんじゃないですかね。
それとも、一般論としての常識として押し通すような話なんでしょうか。
たとえば「常識とはこの世界の8割～9割がそうしていること」と定義するのであれば、
ここで多数意見をまとめたところで、意味ないですよね。
>>53は「コメント」についてたずねてるのに、
勝手に拡大解釈してまで#if 0～#elseをブッ込んでくるヤツがひとりいる。
「世の中」とか「常識」とか「日本の将来」まで引っ張り出してきて…。
「子供たちの未来」とか「北朝鮮の脅威」を持ち出すのも時間の問題かと。 まあ、排除に重きを置かなくても、違う発想があるんだって視点で見れば面白いんじゃないですかね。
俺は使ったことがなかったのですが、#if 0 もコメントアウトには便利に使えそうですし。
ああ。「排除」は政治的キーワードだったか。すまんこって。
通り道に枝がかかってたから手で掃っただけ。
排除されたくなきゃかからないようにしとけよ。
前スレか前々スレか忘れたけどtiny2313用の並列処理プログラムは
リストも掲載してあって再現性があり興味深かった
>>108
こんなところでレベルの高い話を望むなんて、
そりゃ無い物ねだりというもんですぜ、ダンナｗ ここはマイコンだぞ。
PC-8001とかMZ-80Bの話題だろ？
オラの認識では「マイコン」は変わった。
昔 マイ・コンピュータ (パソコンに近し）
今 マイクロ・コントローラ (MCUに近し)
（115のボケにマジレス）
末尾の\記号で行連結されるから次の行の改行文字までコメントアウトされてしまう
という事が言いたいんだと推測した
当時LKit-16 というのが欲しかった。
地元では見たくても一度も見えなかった。TK-80, TLCS-80, H68/TR とかばっかりだった。
>>114
旧新マイコンシリーズ毎のビットエンディアン、バイトエンデァンは、纏めたいと思っていた。
いちいちコンパイラマニュアルしらべればわかるのだけれど。
移植しようと思って、H8ってビッグエンディアンだったの？！と思った。
H8意地でも使わなかったので、いまさら
H8(BYTEビッグエンディアン)->PIC24(BYTEリトルエンデァン)
あと、ARMも手をつけ始めて、・・・。 >>119
Lkit16のCPUは今でいう「16ﾋﾞｯﾄのRISC」のオリジナルで、
I/Oも専用のコントローラを持つバス形式だった。（USBとは異なりパラレル）
40年前に販売され消えて行ったけど、登場が早すぎたのかな？ 少意味不明瞭なので修正を
Lkit16のCPUは今でいう「16ﾋﾞｯﾄのRISC」のオリジナルで、
→Lkit16のCPUはメーカーオリジナルの、今でいう「16ﾋﾞｯﾄのRISC」で、
RISC とか 8bit とか定義が曖昧すぎる。
LSI の VLSI とか ULSI とか言うのも何だったのか？
定義を知らないくせに「曖昧」とかｗ
勉強してから家ｗｗｗ
アキュムレータに相当するレジスタ長NがNビットマイコンの定義と考えればほぼ間違いない。
例があるかどうかは自分で調べろ。
http://www.weblio.jp/content/VLSI
>超LSIとは、1チップに搭載される素子数が従来を大幅に上回る大規模集積回路について名付けた、1980年代の呼称である。
>当初は搭載される素子数が1万素子以上の場合でも、超LSI（またはVLSI）と呼んでいたが、1990年代にかけては100万素子以上を搭載したLSIを指すようになった。また、チッ
別に専門家の話しじゃ無く、ニュース等でも超LSI＆VLSIは使われてたし、
>エンジニアはそれを全て無視
とか意味不明ｗｗｗ
挙句の果てに
>マキシム製品は、一般のアナログ製品よりも多くのデバイスを持つMAXQマイクロコントローラコアのような、複雑な制御を備えているものが多い。
とかなんとかｗそんなソースしか見れないのかよｗｗｗ >>129をULSIの定義のソースを紹介してるものと読んだのだとしたら単純にもほどがある。 >>130
68000を16ビットCPUだと言う人も少なくなかったけれど、俺には32ビットCPUにしか見えなかった。
16ビットというのは外部バス幅のせいなんかな。
その基準だと、68008とか、8088とかV20は何ビットになるんだろう。 32ビットで良いだろ。Very low Speed Integration
マイコンを勉強するのに今はハードは何がいいのでしょうか。
一昔前はH8で勉強していたそうですか。
何かの勉強するのに、今はセミナーとか雑誌とか本やネットなど、いろいろな情報源があるけど、
LKit16などを設計した人たちは、何を見て勉強したんだろうか。
マイコンはアメリカ発祥なので、そのハードウェアマニュアルを見て、マイコン技術を覚えたのかな。
それとも、M360などの大型コンピュータを設計する人には、マイコンの設計なんて朝飯前なのか。
マイコンは、最初はキットだったと思う。TK-80だって自分で半田付けしたらしい。
そもそも論だけど、なんでマイコンボードが作られたのだろうか。
社員教育用とか?
>>136
何を勉強したいかによるんだけど
C言語+ハード学習ならPICがネット上に豊富だね。
アセンブラを理解したいなら16bitクラスの例えばR8Cがおすすめかなあ。
32bit以上のアセンブラはやっぱり分かりづらいよ。初心者向けではない。
メモリー管理とか後回しでいいし。 I/Oやメモリを外部に作らなくて済む今のワンチップCPUは夢みたいだな。
電源さえつなげばCPUとして＜必ず＞動くんだぜ。
俺はもう若くないけど、もっと遅く生まれたかった。
出来ればあと50～100年ほど遅く生まれたかった。
その頃にはハードウェアのAIが実用化されているかもしれん。
（チラ裏日記）
アドレスバス、データバス、コントローラバスの手配線なんて悪夢だった。
電源を入れて動かない時は、ソフトが走らないので原因追及がそれなりに大変だった。
デバッガはなんて無いし、書込はワンタイムか窓付きEEPROM
メールでプログラム遅れないから、佐川の営業所に発送時刻に駆け込み
>窓付きEEPROM
そんなのあるのか、すごいな。窓付きEPROMなら知ってるけど。
マイクロチップテクノロジがPICにAI機能を載せるのはいつ頃になるんだろ？
（未来話だよ～ん）ｗ
ppaのintel HDA のドライバ入れようとしてるんだけどDKMSでのコンパイルで弾かれる。
ひょっとして16.04.3Ltsに16.04.1ってドライバパッケージ入れようとしてるのが間違い？
>窓付きEEPROM
窓無しEPROMに書き込む時はそれなりに緊張した。
失敗するとそのままゴミ箱直行になるので。
>>151
書き込みは一度だけで（one time program)、消去できないので、
世間的にはそういう呼び方になりますね。
(説明するのは恥ずかしいのですが150はウケ狙いですよ、念のため） >>152
one time なんて言い方はない。
once だ。って習うよね。
不思議でならない。 >>155
そうか、申しわけ無い。
英語をちゃんと勉強しなかったのがこんな所でバレちまったｗ
OTPは「Once Tondemonai Program」でいいのかな？
そういえば「OUT ： once upon a time」なんて言い回しもあったな。
・・・
あるか！ （一人ボケ突っ込み) >>155
>one time なんて言い方はない。
>once だ。って習うよね。
中学生から勉強してないのかＷ >>157
one-time か onetime はあるな。 >>160
そこは日本語の資料だと説得力に欠けると思わないか？
One Time なんたらが有るのは知ってるけどさ。
>>158 が言うように、辞書引いたほうがいい。 >>161
>そこは日本語の資料だと説得力に欠けると思わないか？
思わないな。海外メーカの出してる資料だし、英文の資料でも部品名としてOnceなんて書いてあるのは見た記憶が無い。
勿論、文章中には有っても可笑しくはないが、ROMの頭にOnceなんて付けるかよ。 そもそもOTPのOがOnceって主張している人を説得する必要もない。
間違ってるよ、と言われれば、馬鹿みたいにすぐにわかるようなことなんだし
まともな人なら反論する前に自分で調べる。
賢いのは >>162 だけだった。
DVD は、Write Once だよ？ >>166
>DVD は、Write Once だよ？
それがOTPとなんの関係があるんだ？
大原節子のビキニ姿の話をしてる時に、>>166の母ちゃんデベソって言われるのと
同じくらい意味が無いと思うぞ。ほんとにデベソかも試練が。 何の関係があるのか？
と尋ねられて、ちゃんとその関係を説明するだけの誠実さがあるかな。
もうその件は置いておいて、他の事例を出してくるような気がする。
他の事例を出すこと自体が意味がないことをわからずに。
一回こっきりというのを強調するためじゃないかな。
同じOTPだけどone time passwordってのも普通に使われるよ。
日本の自動車関係が、
ARMをメインで使わないのは何故なんでしょうね。
>>176
比較の問題ですが、自動車会社が求める品質保証やサポートへの対応の違いだとは聞いたことがあります。 自動車関係のCPUというときに、それに載せるアクセサリも含むのか、エンジン周りの
ヘビーデューティなものを指すのか。
電子部品で「車載対応」というと後者ですけど。
EUCとかパワートレインとか。
なんで車なのにトレインなんだよ？
トレインは、連なっている様子をイメージするコトバで、列車もその流れでつかわている。
パワートレインは、パワー伝達の一連の構造を表現しているのでは。
>>180
もちろん、後者です。
やっぱり、日本のメーカーの方が、何かと対応がいいんでしょうか？ >>183
電話口で叫べば担当が来る、叩けば無償対応するから。
日本のメーカーは昔から開発ツールやマイコンに関してはこれ。 そんな対応してくれるのは客が大手メーカーの場合だけでは？
万単位の月産が継続する場合だな、そんなの。
片手がやっとのウチとは大違い。
万単位の生産になると製造コストが効いてくるから、そっちの問題で
安物外国産に走るしかなくなる。
大手自動車関連は障壁高いからそう簡単に変わらないだろうけど
それ以外駄目なんじゃない？＞ルネとか
国内だけの話なら「日本語障壁」っていうのもあるからね
ある程度の規模以上の会社なら、ソフト開発は派遣を集めて
やってる所がほとんどだろうけど、そういう所で
日本語ドキュメントのないデバイス使うのは至難の業じゃないかな
>>188
英語赤点だった俺でも、データシート読むのは難なく出来る。 >>189
「オレ英語得意だから海外デバイスでも全然オッケーです！」
「そうか、たのもしいな！じゃ今度の開発はSTMのCortex-A7で
やってもらおうか」
･･･っていうような世界ばかりじゃないのよ
もしそういう世界にいるとしたら、それは（皮肉とかじゃなく）
幸せなことだと思うけど >>192
データシート読むのに必要な英語力なんて知れてる。
技術者としての能力が大事。
どんなに英語得意でも、文章能力無かったら英語で小説書けないのと同じ。 英語できます、って言う人でもコトの内容がわかっていないと読んでも滑る。
英語できます、って言う人が英語ができる程度に、日本ができる日本人はたくさんいるけど
日本語のデータシートを読めるかなんて別問題だものね。
英語データシートはスラスラ読めるけど小説や新聞は無理。
>>195
文章単純だし、想いを汲み取る 見たいな能力必要ないし。 >>196
いやいや、設計思想みたいなものは考えないと。 そういうのはブローシャにでも書いて貰って本体には不要
最近、中華データシートに苦しむわ。
しかも丁寧に書いてないしサンプルもない。
おまけに仕様書通りに動かないｗｗｗ
中華しか無いって半導体でか？
機械部品なら見た事あるが。
>>196
そもそも使われる単語も文体もちがうから
日常の述語力がないやつは小説は無理 家で不労所得的に稼げる方法など
参考までに、
⇒ 『武藤のムロイエウレ』 というHPで見ることができるらしいです。
グーグル検索⇒『武藤のムロイエウレ』"
QOYV9Y1F5E
質問てす
組み込みマイコンで使用されている開発言語は何が多いのでしょうか?
やはりアセンブラでやってるのでしょうか? それともC、あるいはもっと高級言語でしょうか?
例えば、
電子レンジ、冷蔵庫などの白物家電。
自動車のエンジンコンピュータ
自動販売機、コンビニのレジスター
白物家電：4～8bit アセンブラ、C
ECU:32～64bit C,C++
他は知らね。
白物家電専門でやってる人がいたけど
アセンブラのみ納期1週間程度だそうで。
まあ類似のものからカスタマイズだけらしいけど。
VCU(車体制御)の方は自分も10年前にやったけどC指定だったな。
フェールセーフが厳しいだけであとは結構普通だった。
コンビニレジは今や殆どwindows embedded
ＭＩＳＲＡに悩まされた人ってあんまり居ないのか。
何でも書けてしまう便利なＣ、Ｃ＋＋に禁止事項、確認事項等々色々な制約を決めたもの。
まあ、可読性をあげるとかバグの可能性を極力減らすとかが目的のものだから車の動きに関係するものに必須とされるのは当然か。
そういう規約(?)の本が、FPGAにもあったよね。1万円くらいするやつ
MISRA C って C を COBOL 相当に退化させるだけの代物、という気もしたりする
CやC++のシステム記述言語としての万能性まで失うようなものじゃないからね。
MISRA = Motor Industry Software Reliability Association
協会のAssociationって、 ss だったんだね。いままで s だと思ってた。
ありがとう
組み込み用でフォントを探しているのですが何か情報があれば・・・
・無償で使える
・再配布に関する制約が緩い。ライセンスが他のライブラリ類と衝突しない
・一般的な日本語文書を表示できること。Unicode限定の特殊文字は含まなくても構わない
・ビットマップフォントでサイズは20dot、24dot、28dot、32dotあたり
・視認性に優れドット欠けに強い
・出力はモノクロ二値で最終的には紙へ印刷
今はIPAゴシックをレンダリングして使用していますが単純に二値化すると線が痩せたり太くなったりして
不自然に見えます。またディザを掛けると見た目が甘くなりイマイチです
10dot前後のビットマップフォントは結構あるみたいなのですが豊富なのはせいぜい16dotくらいまでで
20dotを越える物はなかなか見つかりません
もしくはアプローチを変えてTrueTypeフォントを品質の低下を抑えたまま二値化する方法とか・・・
jiskanとかパブリックドメインじゃなかったっけ
自分が調べた範囲ではjiskanは16dotと24dotしか見つからない・・・
IPAゴシック 20dot スレッショルド50% ![マイコンソフト 悩み事相談室 3 [無断転載禁止]©2ch.net YouTube動画>1本 ->画像>18枚](http://uploader.purinka.work/src/5310.png)
IPAゴシック 24dot スレッショルド50% ![マイコンソフト 悩み事相談室 3 [無断転載禁止]©2ch.net YouTube動画>1本 ->画像>18枚](http://uploader.purinka.work/src/5311.png)
IPAゴシック 28dot スレッショルド50% ![マイコンソフト 悩み事相談室 3 [無断転載禁止]©2ch.net YouTube動画>1本 ->画像>18枚](http://uploader.purinka.work/src/5312.png)
IPAゴシック 32dot スレッショルド50% ![マイコンソフト 悩み事相談室 3 [無断転載禁止]©2ch.net YouTube動画>1本 ->画像>18枚](http://uploader.purinka.work/src/5313.png)
32dotはともかく他は線が細い
IPAゴシック 20dot スレッショルド10% ![マイコンソフト 悩み事相談室 3 [無断転載禁止]©2ch.net YouTube動画>1本 ->画像>18枚](http://uploader.purinka.work/src/5314.png)
IPAゴシック 24dot スレッショルド10% ![マイコンソフト 悩み事相談室 3 [無断転載禁止]©2ch.net YouTube動画>1本 ->画像>18枚](http://uploader.purinka.work/src/5315.png)
IPAゴシック 28dot スレッショルド10% ![マイコンソフト 悩み事相談室 3 [無断転載禁止]©2ch.net YouTube動画>1本 ->画像>18枚](http://uploader.purinka.work/src/5316.png)
IPAゴシック 32dot スレッショルド10% ![マイコンソフト 悩み事相談室 3 [無断転載禁止]©2ch.net YouTube動画>1本 ->画像>18枚](http://uploader.purinka.work/src/5317.png)
上よりはマシになる
スレッショルドによらない共通する欠点として線の太さが不均一なのと潰れ方が不自然な所がある
jiskan24 ![マイコンソフト 悩み事相談室 3 [無断転載禁止]©2ch.net YouTube動画>1本 ->画像>18枚](http://uploader.purinka.work/src/5318.png)
jiskan24h ![マイコンソフト 悩み事相談室 3 [無断転載禁止]©2ch.net YouTube動画>1本 ->画像>18枚](http://uploader.purinka.work/src/5319.png)
無駄なく綺麗だけど明朝系故に1dotの線が多くドットの欠落に弱いのと24dotしかない
う～む Ayuゴシックは良い感じ
Ayuゴシック 20dot ![マイコンソフト 悩み事相談室 3 [無断転載禁止]©2ch.net YouTube動画>1本 ->画像>18枚](http://uploader.purinka.work/src/5332.png)
これだと1dotで細いので無理矢理倍幅にすると
Ayuゴシック 20dot なんちゃって倍幅 ![マイコンソフト 悩み事相談室 3 [無断転載禁止]©2ch.net YouTube動画>1本 ->画像>18枚](http://uploader.purinka.work/src/5333.png)
潰れはあるけどIPAゴシック 20dotよりかなり良い。16dotと20dotしか無いのが難か
昔は低画素・低階調出力用の素材やアルゴリズムってあった気がするんだけど気のせいだったのかな
今探しても見あたらないや 今時のマイコンは機能てんこ盛りで、configレジスタを設定するのも大変です。
メーカーは自動生成機能でconfigの面倒臭さを軽減してくれています。
結構なことだと思います。
このことは、
メーカーがマイコン内部の機能モジュールをドンドン追加しても、
自動生成機能を使ってconfigしてくれれば、ユーザーにレジスタ詳細なんて
見せなくてももいいだろう、ということになってくるんでしょうかね?
そりゃなるだろうねえ
実際USBなんかは詳細は書いてなくて
サンプルや自動生成コードを参照
って事になってたりするし
フラッシュ書き込みもライブラリで包まれていて
自力コードで書けないのもあるし
そうなったらなったで違うマイコンを選ぶんでしょ君ら
フルスクラッチ
フルアセンブラ
これはこれで面白いけど
そういう時代じゃないよ
標準ライブラリ
割り込みベクタ
ヒープ
ISRのプロローク、エピローグ
RAMの初期データ
毎回こんなのをゼロから作りたくない
1回くらいならそういうのも良いけど
そうするとやっぱり、
「皆さーん、メインはここに書いてくださいね。タイマー割込でやりたいことは、ここに書いてくださいね。
あとは、当社の優秀なコンパイラーが全～部やりますから、ダウンロードの準備していてください」
「あっ、但し、エラーはしっかり出しますからね。自力で解決してくださいね」
って感じですね。
>>226
「ダウンロード」はマイコンへの書込みの意味ですかね。
でも>>226で書かれているような感じが今ふうなのだと思います。
マイコンにかぎらず「プログラムが走るもの」全般に複雑化してますし、
ある程度のところまではウィザードみたいなので作っておこうってことじゃないでしょうか。 >>226
（スタートアップを含む）ライブラリを提供するだけだろ
別に組み込みに限らずWindowsのソフトでもmain( )を呼び出すコードを書く奴なんて極希にしかいないだろうし 最近プログラムもあんまり書かなくなったけど、
・データシート読んで configレジスタの説明読んで
・レジスタ値を決定して
・#include "...h" から始まって、config、グローバル変数、外部関数、main()とか
毎回全部手で打っていた。
面倒なので、使い回しするために、同じマイコン品番を使ったものですが。
自動生成ができると、殿マイコン出もプログラムできるような気がする。
今日はAVR, 明日はPIC、明後日はRX360という
configはPIC用語
他じゃ通じない
RXだとオプションメモリだったかな
AVRは知らん
自動生成するドライバの仕様や機能がバラバラだから
上の変更も必要
ドライバから自作すれば上の変更はちょっとでよかったり
ラッパーでも良いけど、小規模だとあまり大げさにはしたくない
>>227
前後の文脈読めば、ダウンロードが何の意味かなんて
いちいち揚げ足取らんでもいいよ、余分。
そもそも、書き込みの主旨に無関係。
>>229
あー、そこまではならないかなあ。
同じMicrochipさんでPIC32なのにMMCとHarmonyでインターフェイスが違って
私なんか混乱したりさせられてるもんね。
Arduino系に仲間入りできたチップはいいけど
マイコン単体の物は結局のところpdf見ながらごそごそ…。 >前後の文脈読めば、ダウンロードが何の意味かなんて
>>226 を読めば、クラウドでのコンパイル結果をローカルにダウンロード、とも取れるし、
マイコンへのダウンロードとも取れる。
揚げ足取りしてるわけじゃありません。
変わりゆく開発環境のイメージについて語っておられるのかなあと感心した次第ですよ。 まあまあ、それは良いですよ。
マイコンに書込のつもりで書きました。すみません。
そのうち、Eclips使って Cができれば、
FPGAもマイコンも、ARMもPICも知らないうちにできてしまう、という世の中になるのかな、って。
時代は変わるんだし。
ホイップアンテナ付き辞書のような携帯電話機が、
25年したらiphoneのようにペラペラになったんだから、
もう25年もすると、
「ヘイ、コンパイラ!
SW1が押されたら、画像1を出して、
SW2が押されたら、画像2を出して。」 と依頼すると、
「同時押しの時はどうしますか?」
「それよりも、どのデバイス使うんですか?」とか聞いてきて
「お任せでいいよ」
そんなやりとりでソースが完成。タイピングなんて、しなくなるのかも知れないですね。
>>233
＞クラウドでのコンパイル結果をローカルにダウンロード、
いちいちダウンロードの準備してって言ってくるクライアントがあるのね。
何というクラウドか教えください。 ＞FPGAもマイコンも、ARMもPICも知らないうちにできてしまう、という世の中になるのかな、って
私は趣味のプログラミングだけど、
プログラミングが共通化、単純化、ブラックボックス化していくのはイヤだな、
CPUの個性も楽しめなくなるし、作れるものも限定される。
それともいっそ開発環境の操作や高級言語処理を楽しむようにすれば良いのかｗ
>>236
>>233に書いたとおりです。
俺自身は「>>226さんが『変わりゆく開発環境のイメージについて語っておられる』と考えた」わけで
実在の環境を想定していないですよ。
と思ったのですが、「イメージ」の解釈で行き違いがでて来るかもしれません。
・画像
・複製
・想像、印象、心象
後出しで申し訳けないですが、俺は、>>233では「想像、印象、心象」の意味で使いました。
ただ、「イメージ」の解釈によらず、俺は総合的には>>226での「ダウンロード」を「マイコンへの書込み」の
方かなあと考えたわけですが。 >>237
規模が大きくなってくると、だんだんそういう傾向になってきますね。
WEBで動くアプリなんて、ハードが何かなんてあまり意識しませんし。
マイコンメーカーも開発者よりエンドユーザー(とエンドユーザーに近い企画や営業)の方を向いて
作ってるはず。
趣味的な方向に行くなら、FPGAでCPUを作るとか、ですかね。 >>237
自分でCPUとかコンパイラとか作ればいいだけ 222が書いてるような事がまだ起こる気配すらないのに先回りして心配してるとか暇な人たちですね。
>>241
コードの自動生成は、ルネサスの開発環境でもガンガン行われているけど、
「気配もない」んですか? >>238
何の前触れもなくいきなり冒頭で
＞>>226
＞「ダウンロード」はマイコンへの書込みの意味ですかね。
とレスしておきながら、
＞「想像、印象、心象」の意味で使いました。
と言い訳して済まされるなら、何書いてもOKってことになる。
それがあなたのよく言う、IDを連続させる意義、ですかね？ 嫁を全力で叩こうとする信者たちｗｗ
みっとも無いな
>>242
気配を感じることが出来ない人は「気配がない」んだろうね。 >>244
そもそもレスを読めていない。部分引用して曲解する悪意はないと信じてる。出直してきて。
ただし、ここは国語のスレじゃないから、俺がその部分に付き合うかどうかは俺が決めます。
付き合わない。 >>248
ま、自分がそれで気が済むならいいんじゃないかな。
見ている他人が、あなたのIDに何か語りかけようとは思わないだろうってだけ。
とても嫌な感じだから。
気づいてるだろうけど、各所のあなたのレス、現に全く他人から引用されてないよね。
内容が陳腐なせいもあるかもしれないけど。 >>76
昔の書き方だと { の前に引数の変数宣言入れる。 マイコンってCでしかメモリ容量的に無理だとおもってたんだが、もっぱらC++使って
る人いる？
メモリーの問題だと思うが、どの程度メモリー積んでればC++使った方がいいんだろ。
C++で書けたら楽だものな。
>>251
「動的にオブジェクトのnew/deleteをしないとC++じゃない」という前提でもなくて、
静的にクラスを使うだけでも記述する上で便利だ、ということなら、ArduinoだってC++使ってますし。 そういうことなんだね。例えば関数内でNewする場合（動的）にはやはり普通の変数と同じで
スタックに積むのだろうね。そうするとコツとしてはスタックエリアをかなり確保しておくべきなんだろうね。
８ｋｂのラムの場合はスタチック変数１ｋｂ＋スタック８ｋｂとかにするんだろうか？
mbed
M0 ３２Kb,８Kb
M3 ５１２ｋB,３２ｋB
M0はC++できる？（無理っぽい気がする。）
M3でもRamが少ないよな。こんなしょぼいのでC++つかえるのか？
>>254
>例えば関数内でNewする場合（動的）にはやはり普通の変数と同じでスタックに積むのだろうね。
ClassAクラスのコンストラクタで中で、動的メモリの確保はしていないという条件で。
(1)はオブジェクトの実体がスタックに置かれる。
(2)のようにnewしたら、スタックにはオブジェクトのポインタだけが置かれる
オブジェクトの実体はヒープに置かれる。この場合は(3)のようにdeleteしないとメモリリークする。
じゃなかったっけ。今はスマートポインタを使うのかな。
void foo(void)
{
ClassA a; //(1)
ClassA* pa = new ClassA; //(2)
:
:
delete pa; //(3)
}
メモリ管理の実装で違ってくるのかな？ >>255の続き
(1)のように、クラスの実体をスタックに置く(置いているのかな)とか、
(2)(3)の場合でもnew-deleteがそのときどきできっちり対になってるとか、
プログラムの最初の方に、EEPROMから得た設定データをもとに、
どかんとクラスの配列をnewしてあとはそのまま使うような場合なら
C言語で構造体を扱うのと、さほど変わらんのではないかと思います。
でも、C++の匠は、いろいろなサイズのクラスをnewしたりdeleteしたり、またnewしたりと
ガンガンやりますよね。虫食いだらけになって辛いかな。
そういえば、昔の携帯のJavaのプログラミングで、同僚から、
「オブジェクトは最初に確保してそのあとはずっとそれを使う。メモリ貧弱だし」
って聞いたことがあります。似ているかも。 >>251
コンパイルはパソコンでやるから、問題ない。
ただし、小規模のソフトをC++化しても、めんどくさいだけな気がする。 >>251
コンストラクタ、デストラクタ、テンプレート、デフォルト引数
これだけでも使う価値がある
new / delete はアドレス変換の無い小規模マイコンでは基本使わない
使うとしたら起動時にnewだけ 組み込みだと、グローバルなクラスのコンストラクタが呼ばれるように自分でしなきゃならないことがあるので注意
Cからも呼ばれる事がある関数のヘッダをC/C++両対応にするのがちょっと面倒
Cが絶滅出来れば良いけど、なかなかそうも行かない
教えてください。
#define LED_ON 1
#define LED_OFF 0
上記は、
#define で、1つの単語
LED_ON で1つの単語
1 で1つの単語だと思います。
本の雑誌などのサンプルプログラムで、
#define AAA BBB CCC というのを見ました。
この場合、「AAA」 を「BBB CCC」に置き換える
ということでしょうか?
つまり、
置き換えられる1つ目は「必ず1ワード」だけですが、
置き換える文字は「2つ目以降改行までスペースを含めて全部」
という理解で正しいでしょうか?
>>261
処理系によって違うかもしれない
試して見りゃいいじゃんか目の前に箱あるんだろ?
1.AAAがBBB CCCに変換される
2.プリプロセッサがエラー吐く
3.CCCが無視される(warningが出る)
さあ、どれだった? そもそも複数行に展開されるマクロとかも定義できるから
> 置き換える文字は「2つ目以降改行までスペースを含めて全部」
と言う理解は正しくない
>>264
基本は行末まで。
￥で連結すれば、複数行にまたがって記述可能だが。 >>266
連結するということは、一行扱いにすると言うこと。 >>267
￥があっても行末は行末
それをどう解釈するかはプロセッサの仕様の話 > 置き換える文字は「2つ目以降改行までスペースを含めて全部」
の中の「改行」は末尾の「\」による「テキストファイル上の改行」を「ソースの解釈の上での改行」に含まない表現ではないの？
その解釈で>>267の発言だと思う。
「\」を含めた話をするときは、行末、改行は混乱を招きやすい。相手がどっちの意味で話をしているかはわかると思う。 >>269
> の中の「改行」は末尾の「\」による「テキストファイル上の改行」を「ソースの解釈の上での改行」に含まない表現
とか言うオレオレ解釈を力説されてもな w >>268
#define 自体がプリプロセッサの機能だし。
それを言い出したら、
やってみなければわからん
としか言えない。 >>271
特定の環境の話でないなら規格準拠が前提だと思うが？ >>271はプリプロセッサは規格にのっとった動作するのだから、と>>268に批判的に見える。
>>272は>>268は規格準拠を前提にした話であるような言いかた。
「それをどう解釈するかはプロセッサの仕様の話」
とだけ聞けば、客観的には「プロセッサの動作にはいろいろあって解釈もまちまち」が前提になるだろね。
>>268が規格準拠を前提にした発言だとしたら、意図が読めない。
「それをどう感じるかは人次第」なんて話で、「誰もが同じ解釈をすることが前提」とは普通は考えないよね。 >>273
> 「それをどう解釈するかはプロセッサの仕様の話」
「ソースの行」の話と「行を連結して一行に解釈」話を分けて考えろ
って話
> 「それをどう感じるかは人次第」なんて話で、「誰もが同じ解釈をすることが前提」とは普通は考えないよね。
そりゃ
> 「それをどう解釈するかはプロセッサの仕様の話」
って書いてあって「それをどう解釈するかはプロセッサ次第」って書いてないからな
これが同じ文だと思うならちょっと注意力が無さすぎ >>274
>「ソースの行」の話と「行を連結して一行に解釈」話を分けて考えろ
その表現でいいと思います。 今のは知らないですが、「プログラミング言語C 第2版」(古い)では、
\での連結のことを「行の併合」って表現してますね。
>>275
なるほど、壊滅的に話の流れを読む能力がないのな w >>277
無用に相手を挑発せずに、すりあわせて意見の一致を探す方が有益ですよね？ やって見りゃすぐ済む話を延々と・・・
不毛な非生産的な話が続くなぁ
最初の質問者は試しにやってみたのかよ
使った処理系と、結果書けよ
まあでも自分には、丸々行末までと置き換えるっていう知識はなかったから
参考にはなったかな
コメントは除去される
（空白1個が残るかのごとく、コメントの前後は連結はされない。
大昔は連結され…るような処理系もあった）
>>283
言えてる。
#defineなんて、ON 1 とか true 1 とかしか知らなかったよね。 ABS(x) ((x)>=0?(x):(-(x))) くらいは知ってるやろ
安易にSWAP(x,y)を作ってはまるのは、定番の教科書ネタですね。
y = ABS(x++)
とかやってはまるのも追加で
#define hoge(X) X
と
#define hoge(X)
とを切り替えて、デバッグ用の文を入れ外しするよ。
例えば、
hoge(printf("DEBUG\n"));
とかやれば、#ifdefで書くよりも行数少なくエレガント
define いいけど、行末の ; を付けてしまうとエラーにならない?
if(0){}ってのを見てなるほどといたく感心したことがある。
do{ }while(0)やif(0){}でくくるのは
構文解析されるがそれはメリットデメリット両面ある
あまり入り組んだことせずに#if 0～#endif 使った方が意図が明瞭でいいな
>>292と>>293は目的が違うんだが
if (0)
#if 0
この2個は場合によって使い分ける マクロ展開して結果的にif (0)になるケースがあるねん
コンパイルのチェックを通したい場合と通したくない場合
今時、こういう事を言う人がいるかどうか分からないけど
/* */とか#if0でコメントアウトすると、元のコードとオブジェクトの出力が違うから
新たなバグ発生（というか、本当は元々あったバグの生じる現象が違うだけだが）
する可能性があるから、ダメだと言う人がいる
if (0) でも、コンパイラ＆最適化設定によっては同じなんだけど
バカと議論しても時間のムダなんで、そうしろって言うんだったらそうするしかないよな
で、もう少し前向きの話をすると、if(0)とかするからコンパイラが最適化しちゃうんで
if(var1)としておいて、main()かどこかで var1=0; ってしておけば、今のところ
それに気づいて最適化するようなコンパイラはいないと思う
マイコンじゃないけどVC++6.0で
int i;
…
for (int i = 0; ; ) { }
とやるとiが二重定義エラーになるのを避けるためにファイルの先頭に
#define for if(0); else for
と書いてたのを思い出した。
そういや組込みソフト屋のここの人達はエディタ何使ってる？
俺は秀丸で、職場の周りの人も秀丸ばかりｗ
大昔はMIFES、windowsになって似た感覚で使えるの探して秀丸購入。
MIFESの値上がりに愛想つかしてそれっきり。
秀丸はユーザーの声を反映したバージョンアップがうまいと個人的に思う。
20年前に買ったライセンスで動かす秀丸手放せないな
ただバイナリモードはスターリングに慣れてるので使ったことないw
いいきっかけ貰った。使い心地試してみるよ。
秀丸今も儲かってんのかな
どっかの法人が定期的に買ってるとか？
私はWZ。
DOS時代にMIFESからVZに移行して、以後、何となぁくの流れでWZに。
IDEエディタだと狭くない? カスタマイズもできないし
おせっかい機能は便利かウザいか人それぞれだが
自分は以前MIFES、今sakura
秀丸は何となく好きになれない
>>311
昔、Sakuraエディタを好きで使ってたけど、内部Shift-JISだったせいで、
Unicode編集が必要になったときに離れてしまっていた。
Wikipedia を見たら、2011年に Unicode版が出てたのですね。
コーディングは各社IDEですけど、それ以外でテキストファイルを扱うことは多いので、
Sakuraエディタもチェックしてみよう。 やっぱり秀丸でしょう
検索文字列のハイライトが、ずっと消えずに残っていてくれるのは、たまらない。
ただ、矩形カット&ペーストなど 矩形領域で編集出来ないのが残念。
MIFESは出来た(と記憶)
>>314
秀丸で矩形コピーできるよ。あんまり使わないけど。 多くのIDEでそれができないから秀丸をサブエディタとして使っている俺
MIFES時代から矩形編集使いまくってた
秀丸自体にファンクションキーをMIFES風にする定義ファイル入ってるよ
そういえばWZエディタのキー入力定義ファイルをVZ風からWindows風に変えたら、
スムーズに操作できなくなってビックリしたことがあった。
テキスト入力中のキー操作なんてほぼ無意識のうちにやってるんだね。
IDEっていえばなんらかのプログラミングの話だと思うのですが、
どんな場合に矩形編集が便利に使えるのですかね…。
>>320
各行末にコメントを入れている場合、
コメント以外を選択したとき
コメント位置にタブを挿入したい時 >>321
> 各行末にコメントを入れている場合、
老害の典型 インデント揃えるために100行くらいまとめてタブ挿入するとか
改行入れたテーブルデータをブロックで抜き出すとか
ぱっと出てこないけど、使いこなしているが故に出来ないとストレスなんだよね。
思い付きの一例だから突っ込まんでくれｗ
要望がそれなりにあるからこそ、そんな機能が有るんだろうくらいで。
>>322
全ての行に意味のないコメントを書くヤツがいたなあ
普通にテーブルとかで複数行揃えてコメント書く場合はあるよな
複雑な編集だと秀丸を使ったり、
場合によってはエクセルとかツール作ったりとか マイコン関係のIDEがだいたいWindowsだから
>>323
整形ツールあるよね。客先の指定で使ったり使わなかったりで、使わないことのほうが多いけど。 めんどいからforの中とかifブロックの中で揃ってればいいや
>>322
普通は、どうやってコメントを入れるの？ >>331
ボッチでプログラム書いてるなら
プログラム コメント 書き方
とかでググってテキトーに決めればいい
チームでプログラム作ってるならそのチームのやり方に従え >>332
>>331はコメントの入れ方の一般論を尋ねているのではなかろ。
各行末にコメントを入れることについて「老害の典型」と言ってる>>322に実践している方法を尋ねているのではないか？ >>333
ひょっとして「普通は」の意味がわかってないの？ >>335
「普通」を個人に対して尋ねているときは、「その個人が普通だと思っていること」を尋ねているだろね。 納品するプログラムだと未だにステップ数換算とかあるから、コメントも1ステップ扱いされるんで、全行末にコメントあったりするねぇ。
そんな時は、矩形選択が便利やねぇ。
それにしても、納品先はどう考えてるのやら…
>>333
はい、その通りです。
言い方を変えると「じやあ、どんな入れ方が良いと言うんだ？」ということです。 欲しいのはコメントでもプログラムそのものでもねーよ
とか思ってたりしてｗ
>>337
いまだにコメントまでお金を取る所があるのか
契約内容を見直した方が良いんじゃない？ >>338, >>340
だからググれば色々出てくるだろ
自分がよいと思う奴を採用すればいい
俺のところのやり方がお前に合うかどうかは知らんし、下らんいちゃもんつけられても困るし >だからググれば色々出てくるだろ
>自分がよいと思う奴を採用すればいい
>>338、>>340を読んでないな。
読めばそのレスが的外れなのはわかるだろう。
>>342ではなく、>>322のやり方を聞いているって書いてあるのに。
>>322がなんなりと書けば、それなりにいちゃもんが付く可能性もある。
そりゃそうだ。他人の流儀を「老害の典型」なんて批判するぐらいだ。
よほど立派な流儀でなければ、お前が言うか、って言われて当然だと>>342だって思うだろ?
しかし、こういうことは回避策もあるのにな…。 よほど立派な流儀でなければ、お前が言うか、って言われて当然だと ID:Ra0M84o4 だって思うだろ?
いちゃもん付けるだけで、自分の意見があるわけじゃなさそう。
追い詰めても、何も出まい。
老害はしつこい w
そんなアホレス返す前にググって自分に合うコメントの入れ方見つけりゃいいのに
>>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を使いこなせていないせいだと思う。（失礼！）
＞何度も書かれるとこちらも意見を言いたくなる
あのネ、それはネ、仲間が一人も居なくて寂しいんですぅ、天涯孤独なんですぅｗ
ほとんどの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は「遅い」の意味を根本的に勘違いしてる。 >>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
マイコンで実現するシステムに求められるさまざまな要素のひとつではありますけど、全てではないですね。 入力、演算、出力
これら全てを含めてリアルタイム性
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個でタスクを作るような間抜けなコードが出来るわけだな 解は無数にあるんだから一概に間抜けなコードとか言えないだろ。
与えられたリソースを使って仕様を十分に満たしていればとりあえず
ケチを付けられる理由はない。
「俺のコードは美しいぜ」とか「移植性が」なんて所詮自己満足の世界。
>>465
移植性とか美しいとか言ってるって事は
なにが問題点かわからないってことだな ポーリングで並行処理を行うようなプログラムを組んだことある奴ってあまりいないんだな
>>445と>>463ぐらいか
そう言う経験がないと>>383の言ってることは理解しづらいかもな わざわざ行儀の悪いプログラム自慢をしなくても良いよ
マルチタスクいいよ楽だよと書いといてなんだけど、最近はとんと使ってない。
次々来る新規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もどきを作っただけで 欲しいものが無ければ諦めるか、自作するかの選択で
諦める人と自作する人がいるって簡単な話だよ
自作する人は役に立つから自作するって言ってる
自作した事が無い人がそんなもの役に立たないなどととやかく言ってもしょうが無い
>>495
>欲しいものが無ければ諦めるか、自作するかの選択で
>諦める人と自作する人がいるって簡単な話だよ
そんなことは役に立たないだろう、金銭的にペイしない、って周りから批判的に言われるようなことを
グダグダやっている人の存在を許す組織と、許さない組織があります。
変則的な事態に強いのは前者だと思います。 タスクリスト、イベントリスト、セマフォリスト、メールリスト
こんくらいあればだいたい間に合うよね。
チェーンリストじゃなくて配列にして、ヒープはめんどいからやらないことにすれば
実装は簡単か
どこから組織的な話になるんだろう？
前提がおかしすぎる
>>498
すみません。端折ってしまいました。
>欲しいものが無ければ諦めるか、自作するかの選択で
>諦める人と自作する人がいるって簡単な話だよ
後者みたいなことをする人が存在できる組織は変則的な事態に対応する力があるって話です。
あたりまえながら、俺の見聞きした範囲ですが。
自作OSは業務に使わない・使えない、という結論と
自作OSを作る行為が業務の役に立つ・立たないということとは別だし、
そこを混ぜて話をしたらお互いに接点も見いだせないと思うのです。 だれも組織的にやろうなんて話題は出してないから混ざりようもないでしょ。
まあ時分割くらい昔から業務でも使われてるんだけどね。
>>489の最後の3行の「話が混ざる」ということは組織の話はしてないですよ。 >>496
個人のスキルアップなら業務外にやってね
あと製品に搭載するとか言い出さないように >>502
少なくとも業務の話は出てたはずだし>>499の主張の意味もわかる
それぞれの3回の書き込みだけみれはきみの方が変なヤツ >あと製品に搭載するとか言い出さないように
それをうまく抑える常識派 (というと、とても語弊がありますが) がいないと組織が成り立たないですね。
昔いたところに、日がな役に立たなさそうな実験とか設計とかしてる人が何人かいて、
トップの人も普通にプロジェウトに組み込まれた俺も同僚も、あいつらそれでいいんだと考えていました。
小さい組織じゃそんな余裕はないですが。
少なくとも俺には>>501はさっぱりわからんが... 言った言わないの話は、森友と日大で良いよ。
俺は今まで会社と無関係な勉強や実験を散々したが、
しばらくすると、業務でその知識を使う場面が生じ、仕事に使う羽目になる経験を沢山してる。
電子工作だろうと、株取引だろうと、園芸だろうと、
自分で考え苦労して工夫した事は応用が効く。
業務中に勉強しちゃダメ
業務外で習得したスキルは業務で使っちゃダメ
なんだろ？
>業務中に勉強しちゃダメ
>業務外で習得したスキルは業務で使っちゃダメ
そんなこと言う人いるかな？
人と同じ事をやっているだけでは人より先に進むことは出来ない
誰もがやれる事をやっていたら納期と価格の勝負になってしまう
……なんてこんな所で書いてもしょうがないか
>>511
プリミティブなことを追体験することや、既存のものを自分で作ることを、
「車輪の再発明」「先に進む行為ではなく後ろ向けに進む行為」と考える人もいる、
ということでしょね。
どんどん進歩してる世の中だし、その時間を新しいことを取り入れることにむけるべき、
という考え方もわかります。
幅の広い電子やITというジャンルの中だと、小さい組織も個人もできることは限られてて
「仮想の他の人」にできることを、一通り自分もできるようにすること自体ほぼ不可能です。
それゆえに、急き立てられるようなプレッシャーの中で好む好まざるにかかわらず
ブラックボックスを受け入れつつ新しいことを取り込んでいこうとしている人からすれば、
原理的な部分に取り組むのはかったるいことに見えても仕方がありません。
もしそれが組織なら、誰かが新しいことをやって、誰かが足元のことを固めていく、というような
差配を上の人がすればいいのですが。
あと、自分が向いてる方向が正しいことを認識するために、他の人も同じ方向を向くべき、って
考え方になるとぎくしゃくします。
自分が向くべきでないと考える方向に他の人が向いていても、自分の正しさと他の人の正しさは
両立することが少なくないのにね。
5chのような場所で、ほか人のやり方が間違っている、と感情的になってしまうのはヘンな話です。
たぶん、組織や個人の中で同じような議論や葛藤があって、それがここで出てしまうのだと思います。 そんなつまらないこと外注しろとか、
オフショア開発で安くしろとか言ってたら、
何も作れなくなっていたと言うオチ。
様々な車輪の再発明をしてると、
ロケットとか宇宙船を発明するようになってくんだ。
>とか言ってたら、
ここに来ている人の多くは言われてる立場だったりして。
言われてる立場だからこそ、そこからフリーでいられる人が疎ましいのかも。
>>508
業務中に勉強することも当然あるが、
業務で勉強する以上は勉強の効率や成果が期待される
普通はもっと業務に直結する効率の良い学習をする
下っ端であれば無許可でやるのもまずい
普通は業務で使わないコードを書いていたら
遊んでいると思われる
暇で仕事がない期間にこっそりやるのがせいぜい 別にOSを自分で作ること自体を私は否定していないし、
個人的には非常に楽しいと思う
他人に強制する
OSを作った事がない人を見下す
こんなヤツが問題だってこと
自作OSに限らずマルチタスクやマルチスレッドは罠がたくさんある
ベテランエンジニアでもミスすることもある
業務でも趣味でも、
使うときは以下のような項目を学んでおいた方が良い
同期、排他制御、イベントドリブン、様々なロック現象、アトミック処理、マルチコアの注意点、アウトオブオーダーの注意点
>>516
> 他人に強制する
> 個人のスキルアップなら業務外にやってね
> あと製品に搭載するとか言い出さないように
とか強制してる奴が何を言ってるんだか w >>518
>>516は「他人に強制すること」を問題だと言ってるのではないでしょね。
「他人に自分が作ったOSを使うことを強制すること」を問題だと言ってるのだと思いますよ 当然その通り
わざわざ書かないとわからなかった？
それは失礼
>>520
で？
対象はなんであれ匿名掲示板で他人に強制するなんて意味ないって嘲笑してるんだが
ってところまで説明しないとダメなの？ >ってところまで説明しないとダメなの？
そうでしょね。>>520が誤解だと言うぐらいなら、ですけど。 >>523
ああごめん、理解力無さすぎる奴もいたのね w >>525
つきあいが長くてだいたい考える傾向がわかっている相手とのSNSでのメッセージ交換とか
対面していて顔色、身振り手振り、声色を把握できる相手とのコミュニケートと
一緒してちゃ駄目だと思います。
文字と説明を尽くしましょうよ。 >>526
別に全員にわかってもらおうとは思ってないのでわからないならそのままでいいよ >>527
リアルな会話なら、>>527を聞けば「いじけてヘソを曲げてるな、かまってあげないと」と気遣うものです。
「そんな、キミ、まちなよ」とか言って、ハンカチを差し出したりするところです。
そういう気遣いがほしいですか?
書かれたそのままではなく、書かれていないことまで理解を求める人なので忖度してみました。
それとも今回はそのまま理解してよろしいですか? 俺が同じことを言うときはそのまま理解して欲しいですけど。 自作ディスパッチャ君が暴れてる
そろそろスレタイ読め
昔、とあるニッチ製品メーカーの機械制御はリレーシーケンスだった。
ある日、一人のマニアがマイコン制御化した。
会社は成長し、製品に対するニーズは高まり、より多くの機能・性能が求められた。
多重割り込み程度ではバグだらけでデバッグも難しく、市販OSもニッチ商品故に手が出せなかった。
社で定期購読させてもらっていた専門誌やフリーランスからのアドバイスなどを手掛かりに
自作マルチタスクを標準化し、人員を増し、手分けしてソフトを作れる環境を構築した。
自社製品・他社委託品を生み出しながら、8bit、16bitを経て、今では32bitマイコンで
ライセンスフリーなRTOSを標準とするようにまでなった。
その技術者が定年するときに苦労をねぎらうと、
「趣味を好き勝手にやらせてもらって楽しかった」と笑っていた。
>>528
頓珍漢な気遣いとかリアルにいたら相当うざいだろうなw volatile って、なんと発音すれば良いでしょうか？
ボラティル？
>>530
たかが機械制御にマルチタスク？
頭悪すぎ
あんなのは単に定期割込みですべての内部リレーの
変数を更新掛けてやってるだけで
メインループ1個だけのシングルタスクだ
オブジェクト処理に近いことをやってる
そのループが高速だから、マルチタスクのようにふるまって
多数の機械が同時に動いてるだけ
多重割込みとかバグとか、その時点でアホ丸出し マイコンがやっているのがリレー制御だけだと思っているのか
こいつは
頭悪すぎ アホ丸出し
>>535
最新の機械に頼らず生きろよ
たかが電話機にマイコン積むなんてアホ丸出しって言ってるのと変わらんのだから >>534
普通はボラタイルだろう。
名詞形はボラティリティ。金融系でよく使う言葉
意味は変わりやすいとか、変わりやすさとか。 機械制御って
単にスイッチを切り替えるだけの簡単な物から
ロボット制御みたいな非常に大規模な物まで
まあ普通は単にスイッチを切り替えるだけの簡単な物は機械制御とは言わないような気もするが
嗚呼、マイコンエンジニアがもう定年退職するような時代になったんやねぇ・・・
むかしはマルチタスクとかマルチスレッドとかとは言わずにリアルタイムモニタっていったよねぇ・・・
>>535
機械制御の手段をを固定化して考えていないか？
あんたが書いていることはPLCの動作そのものだな。
PLCは1スキャンで必要なI/O全てを1点づつ処理するので
あくまでも＜スキャンタイム内＞でリアルタイム処理になっている。
CPUを使ってPLCと同じスキャン制御させたとしても、
確かにあんたの言う通り、これをマルチタスク処理とは言わない。
でも >>530 はPLCと同じスキャン制御、とは書いてないぞ。
機械制御はスキャン制御だけではない。
私は昔、機械制御に特化した並列処理のインタープリタを書いたことがある。
PLCに慣れた人からは、使いにくいと悪評だったがｗ
でももう20年以上、全国の工場の何台もの機械で使われ続けている。 >>524
最近のニーチャン達は昔と違ってマルチタスクを自分で作れないんじゃないか？
だから、落語の「饅頭怖い」と同じで、
そんなものは必要ない、役に立たないなどと言ってるのでは？
tiny2313用のディスパッチャなんて想像もつかないんだろうな。
落ちぶれていく日本が悲しいけど仕方が無い。
「老兵は死なずただ消え去るのみ」 >>543
PLCはそれより歴史古いし
マイコンで機械制御で同じことも出来る
それなのにそうしないで
自己満な自称機械制御に特化した並列処理してるアホ >>546
ウーム、意味不明で論評できないｗ
ちゃんと読んだ？
でも、もう時間切れで終わりだからね、残念！ カミサンの晩ご飯を作らないといけないんだよ、悪いね。
>>547
ぷっ
ではご自慢の並列処理で処理待ちしてる10個の処理
同時に5個の入力が入った後に残りの5個が5ms後に同時に入った場合に
出力はそれぞれ何ms後に出る？ >>544
お得意の「見下す」ですか
RAM128バイトで色々なことをやる場合
マルチタスクなんかにRAMを割くのはアホだ
ってことがわからんのか
シングルタスクと多重割り込みでスタックを使い回す
非常に良くできた仕組み もっと規模の大きなCPUでまともなOSを作りなさい
最低限以下の機能がある物を
プライオリティ付きタスク
優先度継承ミューテックス
イベント
>>551
多分やりたくてやってんだからほっとけよw
釣りが趣味なんだよw LED 1個を点滅させる為のタスク
do {
led_on();
sleep(500);
led_off();
sleep(500);
} while (1);
贅沢～ (アホ)
いや別に多重じゃない割り込みでも良いけど
単に十分という意味だよ
>>488 ATtinyは多重割り込みが使えるので
RAM量とタイムクリティカル度で決めれば良い
>>556も>>488も
アホの典型
入出力10点だろうが100点だろうが同じ作り方で出来るものを
規模の大小で作り方変える？
変えてもメリット無い
>>543のバカと同じ
入出力10点の機械10台のために、クソ恥ずかしい自作インタプリタ？
マイコンから見れば機械の台数に意味はない
どちらも入出力100点でしかない
わざわざ低速化、難読化してまさにアホの極み 何でこんなに荒れてんのよ
別に各自好きにすればエエやん
アホくさｗ
>>558
RAM 128バイトと32bit CPUのソフトが同じ作りになるわけがない 自作ディスパッチャが低速化難読化の極みと思うが
8bitは8bitに適した作りって物がある
じゃあ共通化の為に8bitにもWindowsやLinux APIが使えるようにしてくださいな (アホ)
>>559
自分と異なる意見は何が何でも否定しないと気が済まない、
言葉遣いが下品なアホが一人いるんだよ。
他のスレでもこのアホのせいでトゲトゲしい雰囲気になる。
偏執狂だと思う。 マイコンの開発も敷居が下がったからなぁ
昔はそれである程度篩になったもんだが
仕事が上位にシフトしてるからね
下は機械がやればいい
機械がやることは今後増え続ける
>>558の考え方では
「入出力10点だろうが100点だろうが同じ作り方で出来る」という前提があって、
その前提であれば
「10点から100点程度の規模の大小で作り方変えることにメリットはない」
と、至極当たり前のことを言ってるに過ぎない。
なので、
>RAM 128バイトと32bit CPUのソフトが同じ作りになるわけがない
これは別の話ですね。
もっとも、RAM128バイトでできることだけを前提とするなら、
32bitでもたいして作りは違わないと思いますが。
対立する人をいてこますより、お互い、違う考え方の人から自分が知らない観点を
見出すようにすればいいのに。
接点をさがそうよ。 今時>>488とかあり得んわ
それしかできないならそのままほろびてくれいいよ いくら大規模でも多重割込みはねーわ
割込みを多重に使う思想な時点で、頭悪い
だから多重で解決しようとする
単に頭が悪い
多重割り込みが必要な時点で、保守性を考えたらマイコン分けるし、大規模ならミニコン系サーバを採用して冗長性とか、無停止保守とか確保したいよなー。
とか思った。
いや、たしかに俺が新人の頃はメインメモリ512バイトでOSとか乗ってたけどさ、今は時代が違うと思うんだ。
多重割り込みってそんな大袈裟なものじゃないぞ
今時のCPUなら普通に機能が付いてる
意識しなくても勝手に多重割り込みが有効になる環境の方が多いくらい
OS搭載とは全くレベルが違う話
機能が無いのは8bit PICとかごく一部だけ
2人連続で変な思い込み
不思議だね
ARM : デフォルト有効
MIPS : 通常デフォルト有効 (コンパイラが有効にするコードを生成する)
RL78, RX, AVR : ISRの先頭で割り込み許可命令
PIC16 : ISR自体が1個のみ
RAMが128バイトだとRAMをケチる為にわざわざシングルにすることが多いかもしれない
でもまあその程度
普通は有効に活用すると思う
『割り込み』はデフォで使えるとは思うが、『多重割り込み』はデフォで禁止になってないの？
勝手に有効にされたら困るぞ、普通は。
タスクに絡まない多重（レベル）割込みはやればいいと思うが、ISRの多重実行はスイッチャが
複雑になってスタックも余分に要るからたいへんですよ。
スタックは使うが大変ではない
と思うが
何が大変？
割り込み処理中に、さらに割り込みを許可させるには、改めて割り込み許可命令を実行しないといけないんじゃないの？
それとも、逆に割り込み中断命令を実行しないと割り込みかけたい放題なのが今のCPUのトレンドなの？
なんか、よくわからなくなってきた。
俺のまわりの環境が特殊だったのかな…
>>582
俺が気になったのは、割り込み処理が始まったら
・大事な処理を行った後に割り込み許可命令
なのか、それとも割り込み処理が始まったら、
・割り込み禁止命令、大事な処理、割り込み許可命令
この順番でやるの、どちらなんだろ？と、思ったのよ。
割り込み禁止時間が短い方が良いのはわかるが、それは仕様次第じゃね？ マルチレベル割込みと単純な多重割込みを混同しないようにね
>>583
割り込み有効がデフォ
割り込み禁止が必要なら期間は最短で
これが常識的な設計ポリシー
ISRの先頭で禁止なら真っ先に有効にする
これが普通の考え方 多重とかスタックとか
そのせいで四苦八苦してるくせに
その頭しかない連投バカ
そうしなくても十分使えるシンプルな処理でよいし
それが主流でPLC製品が普及してる
で、その多重バカの作ったインタプリタで
機械を数10台動かせば、動きがちぐはぐで反応遅くて他所の機械の終了待ちしてるさまが
想像できる
最初に学んだ所の手法を世の中の常識と思っちゃってそれ以外は邪道としか考えられないんでしょうね…
反面教師だな…
>>585
いくら割込み禁止区間を都合よく短くしても
重要な割込み来てる瞬間にぶち当たった時に
間抜けになりさがる インタプリタ？
誰と勘違いしてるんだ？
シングルタスク＋多重割り込み
小規模マイコンではかなりの率だと思うよ
普通に自動コード生成しても普通はそういうコードが吐かれるし
知らないうちに使ってたりするんじゃないの？
ホビーな人は世の中の常識とは異なる設計が普通だと思ってる人が多くて面白いね
超小規模マイコンでもマルチタスクOSが普通と思ってる人
標準で使える多重割り込みを使わない人
割り込み自体全く使わない人
LED 1個でタスクを作る人
割り込み禁止に抵抗が無い人
アセンブラで書くのが偉いと思ってる人
自作のOSもどきを自慢する人
PLCの常識を押し付ける人
マイコンに割込み禁止命令がわざわざあるのは
多重割込みのためではなく、自己の割込みを防ぐためだ
自己の割込みなら堂々と禁止にしてよいが
自己割込みさせない前提で設計するのがスジ
多重割込みかけておいて他所の割込み禁止とか
何様だよ？ってくらいアホ
>>592
＞マイコンに割込み禁止命令がわざわざあるのは
＞多重割込みのためではなく、自己の割込みを防ぐためだ
の「自己の割込みを防ぐため」の正確な意味がよく分らないけど、
ディスパッチャを動かしているときに、
今ハード・ディスパッチ割込みされたら困るから、
割込み禁止命令を実行してハード・ディスパッチ割込みを禁止する。
はよく使う。
もちろん、
今ディスパッチ割込みして欲しいから、ソフト・ディスパッチ割込みを実行する。
もよく使う。
いやぁそれにしてもこのスレの打って変わった進行速度はスゴイ！ あらあら
ゲームなどでフレーム落ちって
どういう時に発生するか、理屈わかってないバカがいるんだね
割込み処理中に同じ割込み（自己）をさせないから、フレーム落ちになってエラーにならずに処理進むってのに
まぁこの馬鹿>>595がゲーム作れば
割込み処理の後半全部終わる前に、次フレーム始めちゃって
データがしっちゃかめっちゃか
アホなデータ参照して処理して、問題抱えてるのにいつまでも気付けない無能 思い出したｗ
某DMMゲーで、戦闘5倍速とか、クソスペックPCでプレイすると
敵のターンがパスされまくりで超難度も糞も関係なく勝てちゃうって奴
結局直す術知らんから、ターン制限とか明後日の方向で調整してるとか
ほんと、バカがプログラム組むとろくでもないものになる
バカには触らせたくないから去ってほしいわな
>>598
ゲームではそうだろうけど、たとえば自動倉庫のコントローラなら割り込みは取りこぼしちゃならんし、たとえ処理落ちしてもスタック全部処理せにゃならんだろう。
それにゲームの画面処理と違って、自動倉庫なら多重に割り込むのも一過性で終わるから、データ参照先をレジスタとかで賄えば、スタックが許す限りは問題抱えないんじゃね？
マイコンの使い方にも色々なシチュエーションがあるのに、『これじゃなきゃダメ！』という硬い意見が混じってる気がするわ。 >>598
小規模マイコンの話で突然フレーム落ち？
いみわからん
シングルコアの普通のマイコンは
同じ優先度の割り込みが多重にかからないようになってるよ
割り込みがかかるのは処理中の割り込みより優先度が高いものだけ 普通のシングルコアのマイコンの多重割り込みといえば
最大でも各優先度1個ずつだけしか処理中にならない
優先順位を同じにすればシングル割り込みだし
優先度を3個だけにすれば最大でも同時に3個しか処理中にならない
PCのゲームプログラム？
普通ISRをユーザーが直接コーディングなんか出来ないぞ
何の環境の話？
コールバックとISRを混同してるのかな？
PCゲームの人
ひとを貶すために、広義と狭義を恣意的にふりまわすのって良くない。
>>604
コールバックで実行される内容まで含んで、割り込み発生からリターンまでをISRと呼ぶ
習慣の人たちがいることはわかってるよね？
自分が断固としてその流儀の定義を否定する、ということとは別だよ。 >>606
広義を含めISR内じゃないぞ
少なくともWindowsやLinuxでは
そんなのをアプリに解放するわけがない
ちょっと行儀の悪いアプリがいただけでアウトだ
ちょっとは勉強してから書きなさい 取りこぼしてはいけない割り込みは、ISRが処理中でも禁止しないのは当然。
でもそれをISRとして実装するなら面倒だ。
タスクに絡まない処理として実装すべし
たとえばシリアル通信をタイマで波形作ってやるような場合、次のデータを
バッファから取り出してタイマのレジスタに書き出すとかはタスクに関係ない形で
遅れなく応答する形で書く。クリチカルセクションとか使わずに、メモリをいじるときだけ
（タスクのほうも）DI、EIで済ます。
>>608
どの辺が面倒？
普通の多重割り込みの仕組みだけど ふつーは要求フラグ立ったまま保留されるよね
禁止されていたら。
で、解除したら割り込みされる。
禁止時に同じのが多重に入ったら一つ抜けるが
意図していないなら(そんな例は知らんが)それは多分バグだ
尤も、保留用のフラグなんてない石もあるのかもしれないが
それなら自前でやるまでだが
ああ、>>589の意味がわかった
割り込みが保留にならずに
割り込みがすっぽぬけると思ってたのか
普通割り込み禁止期間といえば割り込みが保留される期間だと思うが >>611
そりゃあスタンバイ制御回路でも実装しない限り、割り込みフラグは1bitしかねーんだから、同じ割り込みが何回発生されても1回しか認識できねーだろ。 >>582
ベクターが少なくて多機能だと、割り込み要因の判別に処理時間取られてしまう。 こいつらレベル割り込みとかエッジ割り込みとか知らんのか？
やはり割込み保留を許容するほどのろまな用途なんだね
バカが作る制御は気楽でいいよな
だから不評なんだよ
自分で言っといて、ここで愚痴言ったって好評に変わるわけないじゃん
不評な物はどこの世界でも不評なんだよ
>>615
イベントを待つ為の割り込みなら、応答遅くても問題無いだろ。 わはは
イベントドリブンなループを並べといて割込みで開始してんの？
平和な世界だねぇ
>>614
割り込み要因の判別に割り込み禁止が必要な理由は？ シングルタスク、シングル割り込み
シングルタスク、多重割り込み
シングルコア、マルチタスク
マルチコア
環境の前提がごちゃまぜになってきた
前提を書いてから語ろうよ
>>617はアンカーミスか
シングルタスク、多重割り込みの環境だと、
最低プライオリティ割り込みなんかかなりスローな処理だったりするぞ
この辺はマルチタスクと大きく違う アンカー打ってないレスにアンカーミスって書いてる。ややこしい。
>>621自体がアンカーミス？
それとも、広義のmissなら、アンカーを打つべきところを打ってないケースもアンカーミスに含まれるかな？ あれ、レス番号がズレて表示されてる
キャッシュをクリアしたらなおった
専ブラのバグか？
>>621は>>615宛で、1行目は無視して ID:S5C1oC7d
ID:G+mPw1KW
この２つ、ずっとアンカーが1個ずつずれてました
ワケわからん書き込みが多いとおもったら、
自分がワケわからん書き込みでした
ずれてるのはアンカーだけじゃないだろ w
とりあえずちょっとROMっとけ
流れ無視ですまんが、ボタンのダブルクリックの検出って
ボタン押し下げ毎の時間間隔を測っといて
Nミリ以上ならシングル、それ下回ったらダブルって判断が
一般的かな？
いみわからんのは>>619くらいだね
あとは意味がわかる
>>619は>>617に対してのレス
ISRでイベントをセットするのは普通だと言った
>>617はISRからタスクを起動するのはどうやってるだ？謎 意見の交換じゃなく煽り合いになってる
不毛なスレだな
>>627
ON/OFF/ON
1個目のONがダブルクリックではない
1個目と2個目のONの間に特定のアクションが入らない
とかも条件になるかも 一般的なマウスならONで確定だけど
他のデバイスならOFFで確定ということもあるかも
やはり頭悪い
ONで確定したらどうやってシングルとダブルを見分けるのだね？
得意の「遅延」使うのかね？
>>624
しかも自演自分でばらしてるし
頭悪いし必死 ダブルクリックがOFF確定のマウスは見たことがないな
>>633
場所でIDが変わるんだよ
自分が自演してるからって他の人もしてると思わないでね プログラム実行中にハードウェア割込みの禁止・許可、ソフトウェア割込みをやるようになれば、
小さな8ビットMCUの初級者レベルを卒業、と言えるのではなかろうか？
中級者レベルの卒業は（ ）かな。
>>637
ん？
こんな簡単な文章も理解できないの？
大丈夫？ スクラッチで
ブートローダー、スタートアップコード、
一通りのペリフェラルの制御、
を書けること
上級になると
・誰かに仕事を丸投げする能力
・困ってるときだけ助けて「あの人はすごい」と言わせる能力
・納期遅れになりそうな場合、それをほったらかしにして長期出張できる能力
が必要になる。
・誰かに責任を丸投げする能力
・困ってるときに助けてもらって「あの人が悪い」と言う能力
・責任を追及されそうな場合、トカゲの尻尾切りにして長期在任できる能力
>>651
そうなんですか？
民間でも多いですよ。>>650みたいな人。
公務員と民間の違いってあまりないよね。
(場合によっては他の人の足を引っ張ってでも)うまく立ち回らないと
職を失うリスクが高いのは民間かな。 大容量RAMとか高速ADCとか、尖がった性能のマイコンって無いのかなぁ
何十ピンもある高級チップって、お手軽電子工作には使いにくい。。。
>>654
何十ピンだったら、マイコンのピン数としては少ない方だと思う。
前に調べたことがある
PIC24FJ128GC010
12ビット 10Ms/s
STM32F303
32ピン版がある。少ピン。
12ビット 5Ms/s で2個のA/Dコンバータが載ってる。(マルチプレクサが2ch入力じゃないよ) 16bitAD内蔵のPICもあったよね
マイコンからのノイズが気になって採用しないけど
昔、12ビットの外付けADCをフィードバック制御に使った事があるけど、
結局、ノイズや精度を考慮して上位10ビット（最少5mV）で制御した。
CPU内蔵の16ビットADCなんて私には使いこなせそうに無いな。
下位ビットなんてただの飾りｄｅｔｈ 工口いひとにわ（ｒｙ
>>661
そうだよ、電源ラインやら信号ラインやらに色々ノイズ対策したうえで、2ビット捨てた……
制御相手はプラズマ溶射用のMax100KWの電源の電圧と電流。 捨てる意味がよくわからん
例えノイズに埋もれてようが使った方が精度は良いはずなんだけど
普通は何回かのサンプルの平均をとるとか、移動平均を使うとかすると思うけど
目的を達すればいいわけで、他人がどうこう言うことではないかも
他人に指示してるわけじゃなくて
単純にわからないと言ってるの
ノイズや精度を考慮してわざわざ2bit削る理由が
捨てるだけのほうが簡単だ（と思った）からじゃないの
制御系だと、測定値のサンプルだけだけ精度上げてもしょうがないから
10bitだろうが12bitだろうが処理が1発なら
捨てる処理の方が無駄って事かな？
例えばなんかの表示に使ってたらノイズで表示がチラチラ変わるのがウザいとか理由はいくらでもあると思う
勢いでよく考えずに作り話を書いてしまった
ってとこだろう
>>673
わざわざ理解してないことをアピールしなくてもいいんだよ
説明はしないから自分で考えてね 下位ビットを捨ててる例なんて巷にゴロゴロあるのに…。
他人からは何も学ばない人がいるようだね。
それは処理量の削減とかデータ量の削減とかが目的であって
>>674
？？？
説明できないなら黙ってりゃいいのに w 煽れば説明してもらえると思ってるんだろうけど
おれには通じないから
説明してほしければそれ相応の態度を示せ
溶接と微粒子を吹き付けるプラズマ溶射とは「似て非なるもの」ではあるまいか。
PDP-1は1バイトが6ビットの(今から見ると)変態だった
1バイト=8ビット以外のマシンは使ったことないけど
ああ、PICは変態だっけ?
バイトはIEC80000-13で8bitと定義された
charが16bitな環境はちょっと前に使ってた
基数が違っただけでで変態とはな…
専門時代16進数の問題で追試が大勢でたのを思い出したよ
charのサイズを基数とは普通言わないし
charのサイズをバイトとも(最近は)言わない
>>686
決まったの2008かよ
昨日じゃねぇか タイムトラベラースレかよ。しかも過去から来ますた！
宇野壽倫（葛飾区青戸6）の告発
宇野壽倫「文句があったらいつでも俺にサリンをかけに来やがれっ!! そんな野郎は俺様がぶちのめしてやるぜっ!!
賞金をやるからいつでもかかって来いっ!! 待ってるぜっ!!」 (挑戦状)
■ 地下鉄サリン事件
オウム真理教は当時「サリン」を作ることはできなかった。
正確に言えば 「作る設備」を持っていなかった。
神区一色村の設備で作れば 全員死んでいる。「ガラクタな設備」である。
神区一色の設備を捜査したのが「警視庁」であるが さっさと「解体撤去」している。
サリンは天皇権力から与えられた。
正確に言えば オウム真理教に潜入した工作員が 「サリン」をオウムに与えた。
オウム真理教には 多数の創価学会信者と公安警察が入り込んでいた。
地下鉄サリン事件を起こせば オウムへの強制捜査が「遅れる」という策を授け「地下鉄サリン事件」を誘導したのは
天皇公安警察と創価学会である。
天皇は その体質上 大きな「事件」を欲している。
オウム科学省のトップは 日本刀で殺された「村井」という人物だ。
村井は「サリン」授受の経緯を知る人物なので 「日本刀」で殺された。
http://d.hatena.ne.jp/kouhou999/20150224 C++ってどんな業界で使われてるの？
開発規模がでかい車載とか？
ドキュメントとかしっかりしてるんだろうな・・・
どんな業界でも使うだろう
CもC++も大して変わらんけど
Cのほうがコンパクトだし実行コードが想像しやすいから
好まれるかも
トラブった時の解析がC++は大変なのよ
抽象化とかされると
C++のどの機能までを使うかによるんだろうけど、
案外気づかない部分でC++ならではの機能を使っているものだけどね。
//コメントってC99で正式にサポートされたから(それ以前にメーカー独自でサポートしてたけど)
C++の機能ではないですよ
C++は細々と便利な機能がある
Cでも使えるのもあるけど互換性の問題があるので積極的には使わない
>>697
でも、多バイト文字を使う時は、従来形式が無難。 >>700
「なんとか問題」ってくだらない名前が付いてたけど忘れた。 namespace とかも使えるようになったらいいんだけど･･･
>>701
￥に相当するコードがあると、意図しない事が起きる S-JISに対応してないコンパイラは
C形式コメントでもダメだから
>>695
おらの界隈は継承とか多重継承とかネームスペースとかバリバリやで。時々Cに戻りたくなるわ。 >>701
ファイブチャーリー(0x5c)のことかね >>700
それ従来形式なら対応してない環境でもたまたま問題にならないケースが多いと言うだけのバッドノウハウだろ
今時そんなものに頼るのはバカでしかない なぜ多バイト文字の時/* の方が// より良いの？
Keilとか、最近のバージョンでも日本語コメントがまともに表示できない
PCで日本語表示するようになって30年以上経つけど、やっぱ全角はつかっちゃ
ダメですよ
>>715
SJISだと2バイト目に\が来ることがあるから、その文字が最後になると次の行をつなげる処理が入っておかしいことになる コンパイラがエラー出すから
そうなったら悩めばいいよ
そうなるまで気にする必要はない
>>719
sjis使うのが悪いってのは置いといて、
//の前に2バイト文字が来るってどう言う使い方？
>>700 は間違ってる気がするけど？ //の前に2バイト文字が来るなんて話はどこにも無いような気がするんだが。
// 可能
とかでしょ
S-JISに対応してない環境ではS-JISは使わない
CとかC++とか関係ない
>>721
>>722 の言うとおり、//コメントの行の最後が意図せず\になるってこと
行末\は次の行とつなげて処理されるからな >>724
なるほど。俺が勘違いしてた。
//の行が\で継続するのが悪いんだな。
//は何があっても一行にしとけばよかったのに。 それをすると利便性が失われる。
安易な解決ができないからいまだに引きずってるんだ。
コメントの最後にスペース付けるとか習慣にすれば防げるのかな
S-JISに対応してない環境でS-JISを使うなって
コメントじゃなくても化けるから
>>727
オレその習慣あるわw
もうそんな環境で書いてないからいらないんだがな スペースでひとつで行連結止められたら大問題なんだがな・・・・
ってか、「能」の字でエラー出たって「ああそっか」で済む程度の問題じゃないの？
>>728
そういえば
「リテラル文字列の中で、2バイト目が\になる文字は、直後に\を付けておけ」
ってのもありました。 一覧表でも貼っておけって？
そんな環境で組みたくない
衛星、ＣＳ放送見るなら！こんな便利な機器（チューナー）があるんだ！
satch.tv/review/satella2review/?mref=445
SJISで、こんな感じのコード書かれたら死ぬ。
for (;;) {
// 脱出不可能
break;
}
SJIS使うのが悪いとはいえ、
// の継続行を作れる仕様がおかしい。
簡単に解決する方法がないから、昔から話題になってるんだなぁ
そう、そして運用次第でどうにでもなるので対策しないコンパイラが存在し続けているのかもしれない。
ちなみに>>734の方法もダメなものはダメ。 >>737
特殊な文字コードを優先して規格を作らないからね
// TEST(a);
TESTが複数行からなるマクロだったら 英語圏の連中は全く困らないんだろうね 直そうという気が感じられない
#defineの行に//コメントの方がよっぽどだめだよね。
>>740
>ちなみに>>734の方法もダメなものはダメ。
SJIS対応コンパイラに>>734の対策を施したソースを読ませて悩む、という話は割とありました。
今ならUTF-8が無難な選択ですかね。 SJISしか対応してないコンパイラにUTF-8入れたらどうなるんだろ
UTF8の2バイト文字、3バイト文字の最終文字を、SJISの2バイト文字の1バイト目だと
認識したらまずいかも。
SJISしか対応してないコンパイラはないと思うけれど、
コンパイルオプションで、文字コードをSJIS指定して、UTF8を食わせたらまずいのでしょうね。
>>741
マクロ展開される前にコメントアウトされるから何も起きないでしょ。 >>741
コメントアウトはマクロ展開より先に行われるので
#define stasla */
/* stasla
上のようなコメントの終わり方は出来ないし、
次のコード書くと
#define slasta /*
int aho;
slasta */
aho定義は残らない。 >>725
C言語には、行末という概念が無い のが問題な気がする。 行末の概念はプリプロセッサにはある。
マクロ定義も一行
//コメントも一行
お前さん、コメントの無いソースコード見なかったかい？
ノーコメント
やべぇ、『きぬ』に乗ったつもりが『りょうもう』だった…
>>761
[グンマー] やぁ、焼きまんじゅうでも食べて行って呉れ給え ワン！バターン！！
大丈夫、上の文字列には¥マーク入ってないよ。
16F1827を使って水平義を作ってるのですが、センサーとPICのAD変換、LEDで形は出来たものの、音を鳴らすのが良い方法が解らず苦労しています。
角度が大きい時はピッ、ピッとゆっくり鳴らし、水平に近づくとピピピと早く、水平でピーと連続音にしたいのですが、良い方法は無いでしょうか？
タイマーの使い方 ブザーをどう実現するか、とか。
書くと長いよ
>>768
例えばタイマーで割り込ませてブザーの繋がっているポートを常に反転させる。
音を出すときだけ、TRISAで入出力設定を出力にする。出力にしている時間はもう一つのタイマーで制御して、ピッと言う音を出す。
このような方法で出来る物でしょうか？ （水平を零度として）角度のN倍サイクルは音を出さない、みたいなのはどうだい
3の倍数と3のつく角度の時だけﾌｧﾆｰ音が鳴りまつ
データ1個8bit使って常時インクリ
その7～0bit目を参照すれば、すべてデューティ1：1の波形になる
センサー値を8bitにデコードし
その最上位bitを拾ってそれとand取れば
勝手にデータ量が多ければゆっくり、データ量が少なければ早く鳴る
>>772
なるほどシンプルなアルゴリズムで面白い。
+1の速度を変えれば音の高さも変えられる。
8段階に変えるための「その最上位bitを拾って」が少し手間かな。
あと、各音の周波数の増減が1オクターブに限定される点はどうなんだろ。
（私が誤解していなければの話しだけど） オクターブ？
音の高さを変えるほどの周波数でインクリすんのか？
ただのピピピの間隔だろｗ
全音符から64分音符とかの範囲で考えろｗ
>>776
あっち荒れてるからこっち来たんじゃね？ 仕様を変えて低い連続音から高い連続音へPWMだとコードは短いけど、水平か分かりにくいか
PWMで音演奏
エンベロープできて一人前
昔、PC88でやってたなぁ
switch文の中の casesは、1段インデント付けますか？ それともおなじ位置でしょうか？
{ } の中に入るごとにインデントを1段増やす
ラベルは1段減らす
これが基本
スタイルは人それぞれ
だけど、ソース整形ツールがある
ルールをファイル定義しておいて一気に修正してくれるもの(Cuty)とか
コマンド指定するastyleとか。
astyle --style=1tbs -s4 -S -N -Y -M80 -p -j -k1 -U -H foo.c
人のソースが読みづらい時にも。
静電容量型の接触検出(STM32 のTSC,PICのmTouchなど)を使った方にお尋ねします。
アクリル板越しでも接触検出できますか？
>>785
別に正解じゃねーだろ
合わせた方が楽なだけだろｗ Windowsで使えるARM7TDMI向けのコードを吐けるclang/LLVMのビルド済みパッケージって無いのかな？
自分でビルドしようにもWindows環境向けの情報が少ないしそんな古いCPU向けの奴なんて見あたらない
lldがらみのチュートリアルも欲しいけど組み込み向け乗ってどこにあるのか・・・
>>47
最初は、見やすさ優先で良いだろ。
無駄な処理有っても、ある程度は最適化かかるし。 教えてください。
ノイズの多い環境でのシリアル通信は、通信上どんな工夫をして良いか考えています。
まず考えたのは、パリティを付加することですが、ノイズが2回来ると検出できない思います。
次に考えたのが、同じ文字を何回か送って、何度か一致したら、それは合格とすることです。
前者も後者も、確率の問題かなと思いました。
以上です。
>>793
CRC も RS も LDPC も確率の問題 >>793
1文字中2回もノイズでやられてるってんなら物理層の対策の方が先だろう。 >>793
1 速度を落として、ノイズフィルターをガッツリ入れる
2 誤り訂正符号追加する
好きな方を 調歩同期だろ
スタートビットダメだったら文字丸ごとダメ
そんなに伝送路悪いのだったら
拡散符号にでもするかw
>>798
いやいやはやぶさとかの通信担当者かも知れんぞ w >>802
宇宙通信の同期機構はもっとしっかりしているしデータの保護もリードソロモン符号で堅牢っすよ >>803
> データの保護もリードソロモン符号で堅牢っすよ
物理層って意味わかる？ w マジレスすると宇宙通信の成立性は事前に証明した上で打ち上げるから
機器が故障したり予定外の軌道を飛んだりしない限りしないかぎり
物理層のエラーが多くて運用に支障をきたすなんて事はあり得ない
生まれた子の性別を伝えたいなら
赤・青の狼煙爆破させればいいじゃん
>>805
マジレスとかいう前になんのために３系統も通信手段を持ってるかを調べた方がいいぞ w
![マイコンソフト 悩み事相談室 3 [無断転載禁止]©2ch.net YouTube動画>1本 ->画像>18枚](http://fanfun.jaxa.jp/countdown/hayabusa2/images/hayabusa2_inst_16.jpg)
というかどのレベルで話せばいいわけ？ｗ
１．一般人
２．高周波通信は判っている
３．人工衛星や探査機のシステムについて理解がある
>>809
>はやぶさ２ではＸ帯での通信機能も備え、天候が良ければＫａ帯、悪ければＸ帯を使うなど２種類の電波を使い分け、効率的に運用する。
らしいけど、何が3系統？ >>810
お前のレベルで話せばいいよ
>>811
ああ、はやぶさ2はKaバンドも使うんだったな、忘れてたわ
それ入れれば4系統か
ただ、物理層って周波数だけじゃ無いぞ
アンテナ4系統ある意味を考えなよ
>>812
はいはい、俺のことはどうでもいいからお前のレベルで話せよ >>804
極近距離の有線ならともかく、
通信ではエラーが出る前提で設計しないと駄目だろ。 >>813
『オレは知ってるぜ」じゃなくて答えてくんない？本当はわかってないんだろ。
4系統って何だよ？ そういえば、超低速通信でポチポチやってたりしたっけね。
JAXAが日本語の資料を作っていたわ
http://sma.jaxa.jp/TechDoc/Docs/JAXA-JERG-2-400A.pdf
物理層は日本語の資料が作られているようだ。論理層以上はCCSDSの英語版しかないっぽい
多少なりとも通信の理解があれば眺めるだけでだいたい判ると思う
物理層の時点で誤り率が～以下になる・・・みたいに設計されているんで通常の運用で同期が取れないほど
ビットが化けるなんて事はない
またCCSDSの資料によれば同期コードはBCHで符号化されているらしい。1～2ビット化けたくらいではびくともしないだろう
はやぶさ2に関してはJAXAのはやぶさ2 Fact Sheetが良くまとまっている
搭載している通信系はXバンドとKaバンドの2種類
Xバンドはアンテナがローゲイン、ミドルゲイン、ハイゲインと3種類ある。Kaバンドはハイゲインのみ
運用はXバンド、観測データを下ろすのは速度を稼ぎやすいKaかXバンドかな
>>817
機上の自律化機能を使ってFM変調、地上のスペアナを使って復調って奴ですな
1ビットが8秒、実効ビットレートは0.0625bpsだったらしい
ソースは第9回宇宙科学シンポジウムのはやぶさセッションの発表とその講演集
以前はWebでpdfが公開されていたんだが残念ながら消滅したようだ
って組み込みである以外マイコン関係ねぇ・・・ >>819
> またCCSDSの資料によれば同期コードはBCHで符号化されているらしい。1～2ビット化けたくらいではびくともしないだろう
BCHの復号モードのSECの意味ぐらい理解してから書けよ
マジで恥ずかしいぞ w 自分はエラー訂正符号に詳しい訳じゃないしBCH符号はRS符号より訂正能力が高いくらいの認識しかない
誤っているならそれで良いけど煽るんじゃなくソースを提示して論理的に説明してくれませんかね？
マイコンのシリアル通信だろ
UART介在してるのに同期も取れなくてエラー訂正もへったくれもない
同期からやるんだったら信号をADでサンプリングしてetcからの話になる
糸口が見つからなきゃ同期も取れないのだから相関取って最尤推定とか
本格的にやるならね
>>823
パイオニアの事も忘れないで・・・(´・ω・｀) >>821
だから自分が上げた資料ぐらい理解しろよ
SEC=Single Error Correction
の意味もわかってないのか？ 標準ライブラリのソース探してきて
それを使え
ツウはスタートアップから一通り自分でチェックするものだ
このマイコンを最低限動作させるのに必須の設定内容は？
たったこれだけの情報も明文化されておらずサンプルコードと格闘せざるを得ないマイコンは多い
ペリフェラルの初期化なんかも同様。マニュアルにレジスタ操作のフローチャートが記載されているマイコンは少ない
初めてそのCPUに触れる人でも、読んで「理解すれば」プログラムを書けるように
マニュアルには必要な事項が記載されている。
また要所にアセンブラとCのプログラム例も記載されている（少なくともAVRのマニュアルには）
マニュアルを読んでもプログラムが書けないなら、
まだまだプログラミングの実力が足りないという事だから
マニュアルの内容に文句を言う前に本やネットで勉強した方が良い。
CPU製作会社のドキュメント製作部門の担当者が怒るぞｗ
むかつくのは昔ならハード屋の領分がすべてソフトでレジスタ設定しろって流れなことだよ。
今のハード屋なんて線つなげときゃ終わりじゃん。せいぜいアナログ回路くらい。
>>831
てめーのカスみたいに浅い経験だけで偉そうに語ってんじゃねえよ。 昨今の高機能なペリフェラルがいっぱい付いていてフレームワークの使用が前提のマイコンのマニュアルはそこまで書いてあるようには見えないな
ペリフェラルの機能上は出来るはずだがフレームワークでは出来ないようなことをしたい場合大体ソースコードとにらめっこになる
あと8bit世代ならROM数KB/RAM数百Bですむような内容なのにフレームワークだけでROM数十KB/RAM数KBとか
ペリフェラルはデータシートだけでは説明不足なのが多くてアプリケーションノートの
サンプルプログラムを読むしかないのが多い気がする
順番があったりタイミングがあったりするからねえ
つらつらとレジスタの説明があるだけじゃわからない
糞なマニュアルしかない、ふざけたサンプルしかない、てのもあるからね
あたまいてーよ
仕事だと分厚いデータシート読む余裕もないこと多いしな
斜め読みくらいしないと「この機能とこの機能は排他です」とか落とし穴ある。
>>840
斜め読みだと絶対見落とす。
RX621 の IO ポートの入力バッファを On にする設定は、まさか SPI の設定にまで効いてるとは思わずハマった。 言ってることが現実に合わない。現実を知らないな。さてはニワカだろう。
という論法は必ずしも合ってないよな。
指導者の、励ましとか方法論とか教訓とかは、往々にして現実には合わないことが多いけれど、
それをもってその指導者がニワカだとは言えないよな。
>>834
そのフレームワーク作成者は何を見て書いてるんだろうね。メーカー内部には懇切丁寧なマニュアルがあるのかな。
そのマニュアル開示すればみんな助かるし、cpu選定に有利だろうにね。
cpu開発者がコード書いてる？んな事ないだろうし。 今はネットで検索してコピペのスピード時代だぞ
いちいちマニュアルなんて読んでられねぇよ
俺以外の誰か一人ががんばればいいんだよ
>>845
ニワカとか罵倒してたのが居たが
本音はそれだよな。 最低限の何が自分のコードに必要か何が不要がくらいは判らないとコピペプログラマーにもなれない。
マルチタスキングする場合はコピペだけじゃうまくいかなくね？
>>848
ソースで提供されているライブラリを組み込むときに、端から端まで理解して使うことも少ないかも。
結果的に自分が使っていないものとかも入っているだろうし、書いた人には恐らくわかっていることでも、
自分にとってはオマジナイであることも。
というか過去に自分のソースを組み込むときにも、すでにオマジナイ化している部分もあったりして。 仕事なら「time is money」だから、
コピペで工数(納期)が短くなるなら、コピペを採用するのは当然だと思う。
私はプログラミングが余暇の趣味なので、
「他人が書いたプログラムは出来るだけ採用しない」
という方針でやっている。(その分、楽しみが減るので）
この前、tiny2313用のI2Cマスター制御プログラムを、
（ターゲットは秋月のAQM0802A-FLW-GBWという液晶表示器）
マニュアルだけを見ながらアセンブラで書いたら何時間も掛かってしまった。
でも苦労した分、完成時の喜びも大きい。
自分で書いた後、メーカー発表のサンプルと比較する時もあるけど、
なぁるほどぉ、とすごく勉強になる。
>>849
小さなCPUでマルチタスクする時は、
個別案件ごとに細部を色々と工夫しなければいけないからでは？ 割り込みとポーリング時分割の考え方で何の問題もない
arduinoのスケッチと同じ
プログラム以外も含んでしまうのですがディスクリートに相互容量方式のタッチセンサーを実装している資料ってありませんかね
アマチュアのタッチセンサーの作例は自己容量方式ばかりのようですし、アプリケーションマニュアルを見るとタッチセンサーペリフェラル付きの
マイコンとそれ用のライブラリが前提になっていたりして、センサーからどのように読み出すのかを書いている資料が見つかりません
簡単な自己容量方式ではなく手間のかかる相互容量方式にしたい理由は検出したい面積がかなり広いためです
ここで良いのか分かりませんが、質問させてください。
その昔、コンピューターの読み取り装置として紙テープリーダーというのがあったと聞きました。
紙テープに穴が開いたり空いてなかったりで1と0を判別すると思うのですが、
8ビットで穴がパラレルで8個空いてるとすると、
リード信号はどこから得られるのでしょうか?
それとも回路の読み込み速度が 、テープが送られる速度より十分早いので、どれか1つの穴からの信号がくれば、もうリードしてしまうと言うことでしょうか
>>856
ありがとうございました。
5bit 3bit の間にある小さい穴がそれですね。
ありがとうございました。
テープが途中で切れた時は、ラブアウトしたテープとともに、糊でつければ良いんですね。
頭いいと思いました。 光学式の紙テープリーダーはそのスプロケット穴を基準に読み取ってるから
パンチ屑が取れてないとデータを読み飛ばすんだよ
>>858
なるほど。
リード信号と同時に、紙テープの駆動用のギアが噛む穴なんですね。
穿孔するのは機械的に難しいですが、
リーダーなら光センサーで作れそうな気がします。
紙テープの駆動は手で引っ張るということで。 ルネサスのマイコンを使おうとしたら、やめろと言われた。
入手性の問題らしい。自動車関係しか売る気ないんだって。
残念だわ。
日本のメーカーは商社と手を組んで、
大手にはペコペコ頭を下げるけど、
中小企業にはフンゾリ返って偉そうな態度で接してくる。
いわんや趣味の電子工作においておや。
>中小企業にはフンゾリ返って偉そうな態度で接してくる。
これ、むかつくね。
安倍君の言う「サラリーマンの平均給与が上がった」とかいう話と似てる。
調査する対象が大企業ばっかり。中小企業は対象外なら、
そりゃ上がったと言えるかも知れない。
>>863
あと、今のサラリーマンに、企業内にいる非正規の人がふくまれてなさそう。 >>865
それで問題ないと思いますよ。
ただスイッチが遠いところにあるとするとあなたの回路では電源、グランド、アナログ入力
と配線が3本必要になるけど、リンクの回路ではグランドとアナログ入力の2本で済むという
違いはある。
あと、オープンになる可能性があるなら入力の電位を確定させる対策が必要かな。 基本的な組込みの設計の仕方でメインでやらせること、タイマ割り込みでやらせることの切り分けが分かりません。処理内容は以下の通りです。arduinoUNOを使っています。
·IOポート読出し(digital*7 adc*2)
·IOポート状態による状態分岐
·adc値ldfフィルタ、演算
·IOポート出力
·一定処理回数毎のEEPROM書き込み
·エラー判定
·エラー処理
·LED表示
·LCD表示
EEPROMとエラー処理をメインで、他はタイマ割込かなと思っているのですが。
また、割込周期の見積方がわかりません、1ms程度でできるものなのでしょうか？
確かに、難しいところがありますよね。
以下の3つに分けて考えましょう。
1. main()
2. タイマー割込
3. 関数
1. main()は、細かいことは書かないで「装置全体の動作の流れ」がわかるように書くと良いです。
2. タイマー割り込みは、いろいろできますが、多重割り込みになると面倒ですので、
サッと抜けるような処理だけ書きましょう。
時間は、1msで行けると思います。(PICは楽勝。アルデーノは知らない)
3. 関数
main()で使用する関数の中身を書きましょう。
こんな感じです。
interrupt_timer....(){
count++
}
void main(){
st = 0;
while(1){
if( st==0 ){ // 0のとき
init(); st=1; // 初期化して、1へ
} else if( st==1 ){ // 1のとき
if( SW1==on ){ // SW1が押されたら
LED1=on; LED2=off; LED2=off; // LEDをセットして
fprintf(xx, "Get1 \r\n"); // シリアルで送信して
st = 2; // 次へ
} else if( SW2==on ){ // SW2が押されたら、
LED1=off; LED2=on; LED2=off; // LEDセットして
Mootor_L( on ); // モーター回転on
count = 0; // 時間カウンタreset
st = 3; // 次へ
}
} else if( st==2 ){ // 2のとき
if( count > 800 ){ // 800ms経ったら
st = 3; // 次へ
}
} else if( st==3 ){ // 3のとき
if( SW_stop==on ){ // StopSWが押されたら
fprintf(xx,"STOP....\r\n"); // シリアル送信して
Mootor_L( off ); // モーター回転off
st = 1; // 1へ戻る
}
}
}
}
arduino でやるって言ってるのに、なんでmain（）とか書いてんだよ。
ありがとうございます
IOだけタイマで同期させて監視しようかと思います
>>870
loop() と見てくれればいいじゃんか。 時間見るのはmillis()見ればいい。 割り込み要らん。
>>86
まとめてコメントアウトしたい時に、#if 0 は便利。 >>867
全ての入力をタイマ割り込みで変数にセット
それから各種タイマーカウンターも全部インクリメント
他は全部メインで、変数とカウンターの値見て分岐と処理
メインで入力を直接見て処理を占有する手法は初心者しかやらん millisでtick見てりゃ割り込み全く要らないなあ。
割込みは使えるようにしておいたほうがよいが、実務ではなるべく避けるのが身のため。
どうしても必要な時だけ使うのが吉。
カウンタしか使わないなら、そもそも割込み要らない。Arduinoだと裏でやってるかもだけど。
逆に、RTOS実装するなら、使うCPUの割り込みのすべてに精通要
この業界n十年いるが割り込みの必要ない実務案件に遭遇した事無いよ。
Arduinoで時間見ること限定で割り込みがいらないと言ってる人と
一般論として「カウンタしか使わないなら、そもそも割込み要らない」と言ってる人がいるような。
カウンタであっても割り込みを無理して避けるより、使うほうが簡単なことが多いような。
>>875
頭いいですね。
>全ての入力をタイマ割り込みで変数にセット
この場合、チャタリングのフィルターは、どこでやりますか？
割り込み内部、メイン？ 言葉足らずみたいだったし書き足しておこうかな。
（>>867の内容ならArduinoなんだし）millisでtick見てりゃ
（自分でわざわざ書き起こす）割り込み全く要らないなあ。 今なにげに>>869のコード見てたら気づいた。ものすごい初歩的なバグが紛れてる。
> if( count > 800 ){ // 800ms経ったら
768msくらいのタイミングで条件成立してしまうことがあるよ。 ちゃんと突っ込んどかないと、このレベルのゴミ情報をブログで拡散させちゃう人いるじゃない。
>>880
そもそも割り込み中に、入力を変数にセットするんだから
割り込み処理前後でハード的なチャタリングあっても
onしたらon
offしたらoffのどちらかの処理を1回しかしないんだから
メインでその情報使って処理したって誤作動するようなものになりようがない
フィルタ掛かってるようなものだからな デジタル入力のチャタリング除去例
まずは、ある時間(start)から指定時間(pass)が経過しているか判断する関数。
時間単位はmsで、経過していればtrue、そうでなければfalseを返す。
uint8_t pass_chk(uint16_t start, uint16_t pass){
if (millis() - start < pass) return false;
return true;
}
チャタリング除去結果と監視時間用の変数を用意&初期化
uint8_t inbuf = 0xff;
uint16_t chatt_start = millis();
10ms毎にPINDをサンプリングして、4回一致したビットのみを更新。
最小30msのチャタリングフィルタとなる。
if (pass_chk(chatt_start, 10){
static uint8_t a = 0xff, b = 0xff, c = 0xff;
uint8_t d = PIND;
chatt_start += 10; // start更新
inbuf |= a & b & c & d; // 全OFF反映
inbuf &= a | b | c | d; // 全ON反映
a = b; b = c; c = d; // サンプルデータシフト
}
ほかの処理はinbufを入力と見なして動けばいい。
負論理に脳がついていけないならここで反転してもいい。
インターバルとサンプリング数は個人の好みでご自由に。
Arduinoじゃないならmillis()相当を自分で作るべし。
>>887
頭悪い奴
そんな「遅延ありき糞処理関数」誰が使うんだね？
フラグをビット反転させる処理で
頭に、前回ビット反転させてから○ms経過した場合だけ受け付けるようにするだけでいい
○ms経過してりゃ入力した瞬間に処理が始まるし
チャタリング中には反転処理に進まない だからー スイッチ入力なんざ100msに一回読んでりゃあ、他になんもやることなんぞ無いわな。
>>887は産業プログラマかな？
とても常識的な内容でチャタリング除去だけじゃなくて不完全入力のフィルタも兼ねてる。
>>888はノイズ試験ってやったことない？ ポートを適切な間隔で2回以上読んで一致を取るのはデバウンスの基本だが、
それすら知らない人のいかに多いことか。
2回の間隔は何msくらいが良いのでしょうか?
0.5secだとスイッチ応答が変な感じだし、
0.1sec暗いでしょうか?
>>894
王道な方法を示してくれよ。俺も知りたい。 >>893
どれほどチャタリングが継続するスイッチなのかによるけど、
デフォは30～50msくらいでいいと思う。
自動販売機が100～200msくらいかな。チョンと押したくらいじゃ反応してくれんし。 >>895
オンディレイタイマーで済むことを
なんでわざわざ2回以上読んだり一致処理しなきゃならんの？
頭悪い え？1回だけなら意図した信号かインパルスノイズか判断つかないじゃない。
頭悪い・・・・
あ、「チャタリング」しか考えてないからそういう思考になるのか。
「デバウンス」はそれ以外の要因も含んでるんだからそりゃ話がすれ違うわな。
君のマイコンはスイッチ入力しか仕事がないんだろうけど、他の人のマイコンはもっと仕事がある
そうそう、長く引き回したオープンコレクタ信号なんかは
チャタリングはないがノイズが乗ったりするからね。
いちいち個別のピンを2回読みなんて時間のかかることはやってられないし、
スキマ時間で全ピンのデバウンスやっとけばいい。
10msに1回程度のポーリングもできないなら割り込みでもいいさ。
>>898
オンディレイタイマーすら知らんのか
どうりで2回入力して一致確認するようなアホ処理を思いつくわけだわｗ えーっと、ハードウェアによるオンディレーの事言ってるなら16キーには16個いるよね。1個いくら？
ソフトによるディレーならデバウンス処理の方が軽いよ。
あなたにとってはアホ処理なんだね。了解した。
そんなアホが世界に何人いるか検索してみても楽しいかもよ。
飲み会があるので名残惜しいけどネタに付き合うのは終わりだ。すまん。
>>902
世界中のマイコン技術者はほぼほぼアホ、という事か >>905
良いこと言ってるんだけど、
for(;;) { を平気で使っているのが嫌い。
while(1){ だろう。 ダメだな。
マジでノイズで誤動作防止するなら、ノイズがスレッショルド超えるような事態そのものを
起こさない回路にすべき。
二回読み一致したらオーケーとか、マジでやばいもんには危なすぎる。
でもお前ら趣味でも仕事でもそのレベルのもの作ったこと無いんだろ？
このスレにChaNさん以上のエンジニアはいるのか？
昔モータドライバの組込みやってたときは1ms周期でポートレジスタ読んで10連続一致で確定としてた
EMG入力だけはエッジ割込一発確定
RX62Tとか出始めの頃のRenesasサンプルコードも似たような感じだった
まぁ1msはサーボループに同期させてるだけ
>>906
コンパイラによるけど大抵のコンパイラはwhile(1)は警告を出すので俺も無限ループはfor(;;)を使う 組み込み用途で無限ループに警告を出されるのは難儀だな
>>913
そうなんですか。勉強になりました。
慣れの問題だろうけど、
For(;;)は、読んでも何をしているのかサッパリわからない。
そこ行くと、while(1)は、英文の意味通り、よくわかる。 >>915
> For(;;)は、読んでも何をしているのかサッパリわからない。
条件節を省略したら常に真とみなすことすら覚えられないならまあしょうがないんじゃねw for(;;)とwhile(1)だと、どちらが高速なのでしょうか。
>条件節を省略したら常に真とみなす よりも
>終了条件が無いんだから、永久ループ。 のほうが、しっくり来るね。
