制御系なら俺に聞いて ..
607:デフォルトの名無しさん
05/01/16 19:46:19
「画面屋」にされると悲惨。なにもわかってないアホの出来上がり
608:デフォルトの名無しさん
05/01/16 21:48:18
>>607
ユーザーインターフェイスの部分は割りとスキルの面ではコアな部分じゃないからな
609:デフォルトの名無しさん
05/01/16 22:27:35
>>608
あら、ヒューマンインターフェースはそれだけで研究価値があるものだよ。
610:デフォルトの名無しさん
05/01/16 22:36:16
>>609
研究するならいいんだけど
ただ仕様に沿って実装するだけってなると
得るモノが少ない鴨。
611:デフォルトの名無しさん
05/01/16 23:00:29
>>609-610
どっちも言えてる
ヒューマンインターフェイスと言っても、自動車の制御などのように
人間の感性に関わるようなところは一つの研究テーマになる
しかし、普通の仕事をしていると、お客様苦情受け付け窓口になるｗ
612:デフォルトの名無しさん
05/01/17 13:52:19
>>597
バグと言うよりも最初の設計が間違ってたんだな。
>>595
＞次の取引で「上書きされるだろう」とのことで・・・（処理時間を気にした結果、消さなかった）
「〜だろう」ってのが技術屋として失格。ハードだろうがソフトだろうが
検証してない事を仕様にしちゃあかんよ。だから今回のような問題が
起きちゃう訳で。
613:601
05/01/17 20:53:13
みなさんご意見ありがとうございます。
明日、工場へ行ってレビューらしいので先輩についてレビューに参加します。
あと・・・やっぱり、アセンブラの知識は持っていたほうが良いのでしょうか？
一応ICE上でデバッグするとき、たまに見たりはします。SHのマニュアル見ながら。
あと春に無謀ですがエンベを受けようと思っています。
もし、新人（理系以外の人）に対して、これは知っておけ!!みたいなものがありましたらご教授お願いします。
614:デフォルトの名無しさん
05/01/18 00:06:57
>>613
エンベは無謀
午前で足切りされるぞ
615:デフォルトの名無しさん
05/01/18 00:22:53
>>614
・アセンブラがわかる ..... 言わずもがな
・データシートが読める ... 必須
・回路図が読める ......... 当然
なんてのは普通でしょ?
と言い放つもラダーチャート組めとか云われた日にゃ四苦八苦
まぁあれだ、制御系にも色々あるってこった
616:615
05/01/18 00:25:51
あぁ、すまん
>>614 は >>613 の間違いです
617:379
05/01/18 08:22:20
>>613
アセンブラは、できればこしたことはないが必須ではないと思う
ICEでデバッグするときにマニュアルをみながらわかるなら十分じゃないだろうか？
機械語によって動くという仕組みだけは理解しいればいいと思う
つねに他の方法でできないだろうかと考えることが大事
上の方でパソコンでという話もあったが、なにかにとらわれずに
SHでやるか、ＰＩＣでやるか、パソコンでやるか、ＰＬＣでやるか。。。
頭の体操にもなるし、たくさんの札があったほうがいい
618:デフォルトの名無しさん
05/01/18 13:39:05
ハードをソフトで置き換えてうまくいった例を教えてくれ。
619:デフォルトの名無しさん
05/01/18 16:17:50
シュミットトリガーが付いてたのを、代わりにＣＲにしてもらってソフトで実現するとか？
620:339
05/01/18 19:13:56
以前ＵＳＢの通信について質問したものです。（キーボード）
LED状態は、Set_Report(Output)Request経由でセットされるそうですが、
エンドポイントに意図するデータがセットされません。
Set_Report(Output)Requestは来るので、
ディスクリプタの設定は問題無いと思うのですがなぜでしょう。
よろしくお願いします。
www.usb.org
621:デフォルトの名無しさん
05/01/18 20:32:09
>>619
んだなぁ。うちもチャタリング除去はソフトでやる事が多いわ。
622:デフォルトの名無しさん
05/01/18 20:48:28
シュミットでチャタリングが除去できるわけではないが
623:デフォルトの名無しさん
05/01/18 22:02:34
LPFだろ。
アナログフィルタからディジタルフィルタに変えたわけだ。
624:デフォルトの名無しさん
05/01/19 06:58:22
フォトカプラのような実際はアナログな信号の場合、デジタルポートで受けるけど
途中にＲ−Ｃ−Ｒと入れておいて、読む直前まで出力ポートにして、
実際のスレッショルドを変化させるというテクニックは使うね。
出力ポートを入力ポートに変更してから実際に読むまでの時間で調整出来る
625:デフォルトの名無しさん
05/01/19 12:58:05
>>621
だから計算中はキーの入りが悪いのね。
626:デフォルトの名無しさん
05/01/19 12:59:49
チャタリング除去するとき、
サンプリング２回一致したら、２回目を取り込む？
それとも１回目を取り込んで、２回目はキャンセル？
627:デフォルトの名無しさん
05/01/19 13:27:56
>>626
「サンプリング２回一致したら」って前提なんだから
どっちでも同じじゃないの？
それとも入力された時間情報も取り込むのかな？
628:デフォルトの名無しさん
05/01/19 14:04:09
>>626
スペックは
(1)30ms以上同じ正常なキーデータが継続したら有効キーと認める
(2)15ms以上(1)と異なるキーデータが継続したら無効キーとみなす。
合ってますか？
629:379
05/01/19 23:45:34
>>628
以上となっていますが、何msごとに取り込む？
15msごとでしたら、以上ではないのでは
630:デフォルトの名無しさん
05/01/20 23:59:04
>>625
計算中にキー入力の反応が悪くなる原因の全てが
チャタリング除去にあるとは限らないけどな。
631:デフォルトの名無しさん
05/01/21 03:00:22
オブジェクト指向は制御系の仕事に役に立ちますか？
632:デフォルトの名無しさん
05/01/21 03:13:32
>>631
オブジェクト指向的考え方はそれなりに役に立つことも多いが、オブジェクト指向しか知らない奴は役に立たない
633:デフォルトの名無しさん
05/01/21 06:43:45
オブジェクト指向的考え方で作るとデカくなるので、メモリに制約がある場合は
知っていても使えない場合がある。未だにROM2K,RAM256ﾊﾞｲﾄとか平気であるからね
634:デフォルトの名無しさん
05/01/21 07:50:08
>>633
ROMとRAMのサイズが逆じゃない？
635:デフォルトの名無しさん
05/01/21 07:56:21
>>634
636:デフォルトの名無しさん
05/01/21 08:17:12
>>634
637:633
05/01/21 08:24:28
RAM256Ｋじゃないよ。RAM ２ ５ ６ バ イ ト スタックも通信バッファも制御用変数も全部この中
638:634
05/01/21 08:58:57
>>637
あ、思いっきりその勘違い(^^;)
ｽﾏｿ
639:デフォルトの名無しさん
05/01/21 09:43:26
＞オブジェクト指向的考え方で作るとデカくなるので
ｵｲｵｲ
640:デフォルトの名無しさん
05/01/21 11:59:17
>>633
そこまで小さいとCで組むのも大変だと思うが
641:デフォルトの名無しさん
05/01/21 12:13:25
>>640
Cの方が楽だよ。
それにどういう風にコンパイルされるか想像できる人なら極力高級言語で書くべきだと思う。
642:デフォルトの名無しさん
05/01/21 13:18:29
想像だけで確認しないような奴は困る。
643:デフォルトの名無しさん
05/01/21 13:33:31
まぁ、コンパイルっていうのは演繹的に考えられるので想像だけで良いと言えば良いの
かもしれないが、人間、間違えることもあるもので、確認するのは当然だろうね。
644:デフォルトの名無しさん
05/01/21 17:53:04
アセンブラソースをC言語を使って書いたらＣ言語で書いたことになるんでは
ないか？
645:デフォルトの名無しさん
05/01/21 17:57:44
>>644
いいえ。
646:デフォルトの名無しさん
05/01/22 02:42:53
ラダーはのんびり描くに限るよ
ラダーラダーダラダラ
647:デフォルトの名無しさん
05/01/22 02:54:44
>>646
お前は生きる価値が無い人間だ
648:デフォルトの名無しさん
05/01/22 02:55:40
>>647
カチンと来たね。価値だけに。
649:デフォルトの名無しさん
05/01/22 03:00:20
シャキーンと来たよ(`・ω・´)
650:デフォルトの名無しさん
05/01/22 04:38:35
分割によるオーバーヘッドと関数入口出口のオーバーヘッドぐらいなら許容できてｃで書く。
資源を抱え込んでそれにアクセスする手続きだけを公開する手法を持ち込むとさすがにきつい。
そこで妥協してRAMを外部参照して変更したりする。
651:デフォルトの名無しさん
05/01/22 17:26:10
もうROMのサイズとかRAMのサイズとか気にしてプログラム組むの嫌だ〜
652:デフォルトの名無しさん
05/01/22 17:32:37
それより内蔵Flashの書き込み回数気にしながら
デバッグする方が嫌だ〜
653:デフォルトの名無しさん
05/01/22 18:46:24
>>652
チップ面積どんどん小さくなってるんだから、RAM 16kくらい標準にして欲しいよね
これくらいあれば使う関数のエントリーをRAMにおいてそっから分岐させれれば
RAMデバッグ出来る
654:デフォルトの名無しさん
05/01/22 19:24:31
>>652
Flashに直接書き込んでいたら100回くらいであぼ〜んじゃない？
逝ってしまったら基板ごと廃棄してるの？
655:デフォルトの名無しさん
05/01/22 21:24:54
>>652
内臓RAMのマイコンがあるからそれを使え。
656:デフォルトの名無しさん
05/01/22 22:48:39
>>550
> 書き込み可能なデバイスで、書き込み中に電源断しても、デバイスのその後の動作に問題が
> 発生しないことを保証するものはあまりない。
そのレベルはハードで書込み禁止すればいいだけだろ。
まさかそんなことは考えてないのか ?
657:デフォルトの名無しさん
05/01/22 22:49:54
デバッグ方法考えて設計してないの？じゃ、ICE買え。
658:デフォルトの名無しさん
05/01/22 23:15:56
>>655
サイバーパンクだな。
659:デフォルトの名無しさん
05/01/22 23:23:28
ICEがあればデバッグも楽々〜
ハーゲンダッツじゃないぞ
660:デフォルトの名無しさん
05/01/23 00:01:56
みなさんはICEに何を使っていらっしゃいますか？
私たち（といっても、所有者は工場でうちらでない）はソフィアを使ってます。
661:デフォルトの名無しさん
05/01/23 03:20:05
開発するターゲットによるだろ。
662:デフォルトの名無しさん
05/01/23 03:57:54
マ板とマルチになっちゃってすいません
就活中の理系院学生なんだけど
組み込み系ソフト作っている大手会社でいいところってどこ？
部品メーカー？大手電機メーカー？精密機器メーカー？他ある？
やはりハードに立脚しているところがいいですよね？
とするとメーカーですかね？
成長性あるものがいいです
あとなるべく高度（数理、物理的）な仕事ができるところ
あと、なにか参考になる
いい本ないですか？
あまり知らないもので・・・
663:デフォルトの名無しさん
05/01/23 04:00:02
>>662
ここで聞く内容じゃありません
氏ね。
664:662
05/01/23 05:09:55
>>663
？？？
665:662
05/01/23 05:11:08
一応組み込み・制御ということで
（２つの違いはあまりよくわかりません）
666:デフォルトの名無しさん
05/01/23 06:19:00
>>662 作るのはみんな「下請け」だよ。作る上でのハウツー的なごたごたが好きならいいけど、
メーカーに入ったら、「何を」作れば売れる／儲かるを企画しては下請けに出すのが仕事になる。
数理・物理的な仕事がしたかったら研究所みたいなとこ行かなきゃね。
ソフトで重要なのは数理・物理よりコミュニケ−ション能力だよ。木村泉の翻訳書でゴースとか
ワインバーグの本でも読んでみれ。面白いよ。
667:デフォルトの名無しさん
05/01/23 07:49:11
>>660
ただの奴
668:デフォルトの名無しさん
05/01/23 18:36:29
>>628付近
スイッチのチャタリングキャンセルするのに２回読んでAND取る、
なんて操作は全然必要ないよ。
チャタの最大継続時間より長い周期でサンプリングすればいいだけの話。
ちょっと前に電気電子板でも話題になってたし、コレ実際勘違いしてる人が多くて
苦笑させられることが多いんだけど。
こんなの理解するのに別に難しい数学モデルなんて必要ない、というか
よく考えれば小学生でもわかるはずだと思うんだけどねえ。
669:デフォルトの名無しさん
05/01/23 19:04:32
チャタが長い短いで語れるならいいけど
たまにそれじゃ語れないときもある
最大継続時間が1秒とか。その間微妙にON/OFFの繰り返しが
670:デフォルトの名無しさん
05/01/23 19:10:01
>>669
意味わかりません。
それすでにチャタリングと違うと思うんだが。。
671:デフォルトの名無しさん
05/01/23 19:11:48
インターロックをはずしたパイプラインプロッセサ
を使う気力はありますか？
672:デフォルトの名無しさん
05/01/23 19:12:42
チャタリングスペシャル
673:デフォルトの名無しさん
05/01/23 19:43:52
>>671
意味わかりません。酔っ払い？
674:デフォルトの名無しさん
05/01/23 21:20:18
>>668
> チャタの最大継続時間より長い周期でサンプリングすればいいだけの話。
そうすると、最大継続時間×２ (＋マージン) の遅れが生ずる場合がある。
これが許容されない場合もある。
そもそも、使ってるリレーが衰退部品になったので交換したらチャタの最大継続時間が変わっててソフトも見直しが必要と言うのはあまり賢いやり方とはいえない。
(複数読みなら反応が遅れるだけだけど、>>668 の方法だと御検出につながるからな。)
> よく考えれば小学生でもわかるはずだと思うんだけどねえ。
確かに >>668 が小学生並みによく考えないと言うことがわかったよ。(藁
675:デフォルトの名無しさん
05/01/23 21:34:37
チャタリングの持続時間より長い周期でサンプルするのは当然だけど
「すればいいだけ」 って部分にひっかかるね。
いわゆるチャタリング取りの処理は、単にチャタリングだけを取ってるわけじゃなく
サージとか、瞬間入ってくる短いパルスノイズも取っているんだよ。
例えばリレー接点から少し長い配線なら、隣のリレーが動く事で電磁誘導されて短いパルスが入ってくる。
操作スイッチにも、冬場は操作する人から静電気火花が飛んで短いパルスが入ってくる。
こういうノイズも取る処理を総称してチャタ取りと称してるんだと思うのだが？
676:デフォルトの名無しさん
05/01/23 21:51:47
ノイズについては確率的に誤検知を減らせる効果はあるけど、誤検知を0にはできない
サンプリングしたときにたまたまノイズが乗れば、誤検知になるから
677:デフォルトの名無しさん
05/01/23 22:16:45
>>676
もうっ！だから複数回サンプリングするんでしょ！
サンプリングはパルス幅の半分の周期でやるって
高校で教わったでしょ！ 授業で何聞いてたのよ！
678:デフォルトの名無しさん
05/01/23 22:25:57
>>675
> チャタリングの持続時間より長い周期でサンプルするのは当然だけど
はぁ ? >>668 の仲間なの ?
679:668
05/01/23 22:43:29
電気電子板では私の言ってることが理解できない人が「高卒」扱いされてたけど
ここだと正しいこと言ってる私のほうが小学生扱いか(w
なんてこったい。（笑）
まあ、小学生でいいけど物事論理的・定量的に考えたほうがいいよ。
論理的・定量的に、っていっても小学校の算数レベルの話だし。
しかし、チャタリングキャンセルを複数回AND取って行うってヨタ話を
最初に考え出したのは一体誰なんだろうか？
>>674
＞使ってるリレーが衰退部品になったので交換したらチャタの最大継続時間が変わってて
そういう場合問題が発生するのは複数回スキャンしてAND取る場合だって同じこと。
複数回スキャン方式（？）とスキャン周期を十分長くとる方式の違いは、
ただ複数回スキャン方式の方が立ち下がりエッジ（？）が検出されるまでの平均時間を
短く出来るって点だけ。
>>675
普通そういうのはチャタリングキャンセルとは言わない気がする。
680:デフォルトの名無しさん
05/01/23 23:57:45
>>677
アホだな
複数回やっても何回やっても同じだろ
確率的にしか減らせないんだよ
チャタリングはスイッチングのときにしか発生しない
発生しても一定時間で落ち着く
それがわかっているから、一定時間以上でサンプリングすれば、
ソフトでも除去できる
ノイズはランダムに発生するだろ
ランダムに発生するものをどうやって一定周期のサンプリングで完全に除去するんだ？
681:デフォルトの名無しさん
05/01/24 00:01:06
そもそもスパイク状のノイズをソフトで取り除けると思う方がおかしい
usecオーダーのノイズをソフトで除去しようとしたら、
それだけで処理時間が終わるだろ
682:デフォルトの名無しさん
05/01/24 06:20:22
>>679
> そういう場合問題が発生するのは複数回スキャンしてAND取る場合だって同じこと。
はぁ ?
わざわざ「(複数読みなら反応が遅れるだけだけど、>>668 の方法だと(御→誤)検出につながるからな。) 」ト書いてやってるのに理解できてないのか ?
さすが小学生レベルだな。
683:デフォルトの名無しさん
05/01/24 06:23:37
>>680
> 確率的にしか減らせないんだよ
確率的でいいんだよ。
俺たちは算数やってるんじゃなくて物作ってるんだからな。
684:デフォルトの名無しさん
05/01/24 06:39:08
>>668
制御系は、人によって状況が様々だからね。
RTOSとか、入力スキャン専用にタイマ割り込みが使えて、
スキャンタスクが他の処理と独立したサンプリング周期で
実行できるってな環境ばかりではないとおもわれ。
非リアルタイム系で、ハードのリソースが乏しい場合、
（たとえば、2行LCD程度の情報表示とスイッチ数個のインターフェースとか）
処理によって周期不定なループ内で
キーの状態も読み込むってなこともあると思う。
少なくとも、昔は多かった。
こういう場合に複数回読み込みって処理は
普通に使われるのでは？
685:デフォルトの名無しさん
05/01/24 07:51:53
>>677
サンプリングした時点にたまたまスパイクが連続ヒットするんだなこれが
わざとやれることは必ず起こるこれ現場の常識
686:デフォルトの名無しさん
05/01/24 07:53:30
ANDよりEXNORが良いよ。
687:668
05/01/24 08:25:05
>>682
しょうがないですな。
実際現場でもこういう馬鹿なクセに頑固で、
物事を数学的に考えずに昔々聞いた話を訓詁学よろしく「馬鹿の一つ覚え」
している人が多くて困ったりあきれたり。。。
＞複数読みなら反応が遅れるだけだけど、>>668 の方法だと(御→誤)検出につながるからな。)
SVOが不明確ななんだか酷い文章だけど、まあそれはいい。
これ、間違ってますよ。
チャタを確実にキャンセルできるかどうかはチャタが持続する時間より
サンプリングの周期が長いかどうか、それだけで決まる。
10回スキャンしようが100回スキャンしようがN回スキャンしようが、
N*T(Tは一回のスキャンの間隔）がチャタの最大の持続時間より短ければ
やはりチャタを拾ってしまうの。
と、まあ一応反論したけど、君はきっと理解しようともしないでしょうな。
そうでなければ既に自分の愚かさを悟っているはず。
688:デフォルトの名無しさん
05/01/24 08:32:37
>>683
いったい何を保証したことになると思ってるんだ？
確率的に誤動作することを保証したソフト
そんなもの誰が受け取るんだ？
689:デフォルトの名無しさん
05/01/24 08:39:39
>>687
＞チャタを確実にキャンセルできるかどうかはチャタが持続する時間より
＞サンプリングの周期が長いかどうか、それだけで決まる。
正解
690:デフォルトの名無しさん
05/01/24 10:02:10
安物のプッシュボタンを押し続けた状態で
指をグリグリ動かしたらどうなるかとか考えたらいいんじゃない？
>>675の書いてることを踏まえた上で
691:675
05/01/24 11:49:38
少し引き伸ばした信号線に、ノイズが入ってくるのは避けられない。
当然、それを回避するＣＲ＋シュミットのような処理は必要だが、それで完全というわけにはゆかない。
隣のモータが配線の切れかけて連続して物凄いノイズを発生してくる可能性だってある。
そういう突発的な状況の悪化で１００サンプルに1回ノイズが入るような状況でも
2度サンプルし、比較すれば1万回に1回に誤判断を減らせる。
ソフトで、何の対策もしない隣の装置が1分に1回誤動作しまくりの中、片方はチャント動くわけだ。
また、テンキーのようなダイナミックスキャンされる信号線では、ハードでＣＲ＋シュミットを入れられない。
ノイズによる誤動作を軽減するには、必ずソフトで2度比較する処理が必要だ。
もちろんこれはノイズ取りであり、チャタリング取りではない。
チャタリング取りは、>>687が書いた通り、チャタリング周期よりも長くサンプルする必要がある。
ただ、チャタリング現象は確率的現象だから、では絶対これ以上の長さでは起きないという長さというのは存在しない。
しかし、確率的に接点寿命回数で1回しか起きない長さは規定出来る。
しかし、その長さでも、確率的には、2台に1度は平均的に寿命内で起きるわけだ。
その長さを2倍にしても、せいぜい1/10、1/100に改善されるだけだろう。
しかし、その長さでサンプリングしてなお、2度サンプルして比較する手法で、その確率がありえない程小さいと、保証出来る。
692:675
05/01/24 11:58:28
つまり>>668の言うことは理論的には正しい。
しかし実用的ではない。
チャタの最大継続時間を規定できないならだ。
どの程度の頻度で発生するかは規定出来るが、絶対に発生しない時間を規定するのは現実的には不可能だ。
例えばリレーなら、数万台並べて寿命回数まで動かして最大値を求める事は出来るが、それは最大継続時間ではない。
そして、その最大値は、異常に長い時間になる可能性がある。
であれば、発生頻度をコントロール出来る時間でサンプリングして、2度採用することで確率を2乗分の１に下げる方が余程実用的で
なおかつ実際に問題が発生しない実装になるわけだ
693:675
05/01/24 12:17:17
あっと、
×2度採用することで確率を2乗分の１に下げる方が余程実用的で
この部分は、もっと考察が必要だな。 2乗分の１になるかどうかは実験してみないと判らない。
694:690
05/01/24 19:19:02
Highが５回続いたらONにする
Lowが５回続いたらOFFにする
バタついてる間はON/OFFは変化させない。
ようは簡易LPFを作りたいんだよ。
複数回サンプリングってのはそういう事でしょ。
>>668みたいな単純な処理で済んじゃうことがほとんどだし
俺自身もそうしてる事が多いけど。
電気・電子版のスレは見てないけどヨタ話扱いになっちまってんの？
695:デフォルトの名無しさん
05/01/24 20:39:46
>>685
サンプリングの1/2以上の周期の成分はLPFで取っておかないといけない。
サンプリングってのはそういう物だ。(分かって言っていると思うけど)
とはいうもの、色の付いたノイズでないとそういうことにはなりそうもないな。
白色ノイズなら平均化で確率的に消せる???
まあ、ノイズとチャタリングの話は分けて考えよう。
696:デフォルトの名無しさん
05/01/24 21:00:07
>>695
サンプリングも無限小周期でやれば、どんなノイズが来ても取り除ける
それかノイズが純白超真っ白けならサンプリングでも可
697:デフォルトの名無しさん
05/01/24 21:15:54
>>692
＞チャタの最大継続時間を規定できないならだ。
スイッチメーカが出してるチャタ収束最大時間を
目安にするってのじゃだめなのか？
チャタ取りはチャタ収束最大時間以上でサンプリング，
ノイズ取りは２回同データだったら確定ってやってるんだが．
698:デフォルトの名無しさん
05/01/24 21:27:15
>>697
リレー回路で、たとえば2段にリレーが入ってたりすると、色々考えないといけないね
699:デフォルトの名無しさん
05/01/24 22:14:50
現在はチャタリング除去をソフトで行っている事例が大半だと言うことが分かった。
700:デフォルトの名無しさん
05/01/24 22:19:39
ーＲ−Ｃ−Ｒ−を入れて、ソフトでシュミットを実現するのも含めてね
701:デフォルトの名無しさん
05/01/24 23:05:58
>>687-688
> 確率的に誤動作することを保証したソフト
> そんなもの誰が受け取るんだ？
君の使ってる HDD も確率的に誤動作するんだけど、まさかそんなことも知らないの ?
例)
URLﾘﾝｸ(www.hitachigst.com)
Reliability
Error rate (non-recoverable) 1 in 10E14
702:デフォルトの名無しさん
05/01/24 23:15:52
ECCがあるさ
703:デフォルトの名無しさん
05/01/24 23:16:42
>>701
おつ！
一生懸命確率的に誤動作するものを探してきたんだね
で、ソフトでノイズ取りすると、1 in 10E14までノイズが取れるのかい？
それと、これこそハード的な破壊で、ソフトで手の打ちようがない好例じゃないのか？
704:デフォルトの名無しさん
05/01/24 23:20:49
数学的・論理的に物事考えられない奴がエンジニアやって
給料もらうのは泥棒に近いな。
大槻教授だったらここで「そんなこといったらあーたトンネル効果で……」
と始まるところだ。
705:デフォルトの名無しさん
05/01/24 23:42:13
まだやってたの？
>>695で結論に一票。
706:デフォルトの名無しさん
05/01/25 00:04:03
>>703
> 一生懸命確率的に誤動作するものを探してきたんだね
あのね、通信回線とかストレージデバイスなんかだと常識なの。
君が知らないだけの話。
(と言っても、俺もスペックとしてすぐに出せるのはこの二種類ぐらいしか知らんけどな。)
> で、ソフトでノイズ取りすると、1 in 10E14までノイズが取れるのかい？
用途によって、10E-14 が必要なものもあるし、10E-3 ぐらいでいい奴もあるだろ。
リモコンのキーが千回に一回入力ミスしても問題ないだろ。
> それと、これこそハード的な破壊で、ソフトで手の打ちようがない好例じゃないのか？
はぁ ? ECC かけまくってこの値にしてるんだぞ。
生のディスクのエラーレートはもっと高いよ。
で、君が得意げに書いてた
>>688
> 確率的に誤動作することを保証したソフト
> そんなもの誰が受け取るんだ？
はどうなったんだ ? (藁
707:デフォルトの名無しさん
05/01/25 00:35:06
>>706
あのね、それ知ってて言ってるの
悪いけど
根本的にノイズの話と合わないんだけど
これ、定量的に確率が出せてるじゃない？
なぜか？
ハードで誤りの確率が決まっていて、それをソフトで除去できる確率もわかっているからだろ？
それをやらなければ、ソフト屋の怠慢だよ
で、ノイズはどうなんだよ？
ノイズ除去は、ハード屋の仕事だろ
ハード屋の仕事までソフト屋が無理にやろうとするのがおかしいんだよ
708:デフォルトの名無しさん
05/01/25 00:51:34
>>707は定量的な確率が明らかじゃなければソフトは書けないと言う事が
明らかになってしまいましたね。
訳の分からない事象は全てハード屋任せですか。楽でいいですね。
709:デフォルトの名無しさん
05/01/25 01:18:58
>>708
何を寝ぼけたこと言ってるんだ？
ノイズの問題はハード屋に任せるしかないだろ？
入力ポートに入ってきたものはチャタリングを除けば「信号」として扱うしかないんだよ
710:デフォルトの名無しさん
05/01/25 01:23:25
ハードかソフトかは、どちらが安く上がるか等で考えるなあ
711:デフォルトの名無しさん
05/01/25 01:32:27
>>708
君の負けだと思うよ。
文脈を忘れて、そもそもの議論の前提をすりかえようとしてないか？
再送とかエラー訂正スキームの話なんてしてなかったでしょ？
そういう「仕組み」がない前提で、純粋に数値的な処理で
ノイズを完全に除去できるかどうかって話だったはず。
数学的にはそれはありえないのは君にも分るでしょ？
ていうか何ボルトのシステムを前提としているにしろ、
ゲートが誤動作するような外来ノイズ拾っちゃうハードって問題あるだろ（笑）
712:デフォルトの名無しさん
05/01/25 02:50:39
>>711 はチャタリングを知らんのか？
713:デフォルトの名無しさん
05/01/25 06:46:17
>>711
基板上のパターン配線でさえ、ノイズをゼロには出来ないし、
ましてや配線として外部から引き込んだらノイズは必ず入るものと考えないと。
静電気や電磁誘導、切れかけた配線から連続して出てくるノイズ・・・
完全に除去は理論的に出来ないけどさ、ようは、キミが作ったソフトの入った装置が
1分に1回誤動作するのに、同じハードでソフトの違う片方が平気で動いてる状態だと
どうなるかって事さ。
714:デフォルトの名無しさん
05/01/25 07:01:18
>>712
チャタリングとノイズは別問題
715:デフォルトの名無しさん
05/01/25 07:08:08
＞ノイズ除去は、ハード屋の仕事だろ
最近は、ハードは
in--Ｒ-Ｃ-Ｒ----CPU
｜
///
だけつけて、後はソフトでコントロールしてねって場合も多いよ。
716:デフォルトの名無しさん
05/01/25 07:39:57
話についていけない・・・勉強することが多すぎる。_|￣|○
やはり理系大学出てないとこの仕事はつらいのかな？
717:デフォルトの名無しさん
05/01/25 07:48:07
>>716
別にいいんじゃない？プログラムするダケならさ。
近くに詳しい人間がいないのならダメだろうけど。
718:デフォルトの名無しさん
05/01/25 09:16:37
>>716
大丈夫、理系出てもついていけない香具師はごろごろしている。
719:690
05/01/25 10:12:40
ノイズと一口に言っても実際はいろんな要因があるわけで。
それに対してハード／ソフトどちらで対処するかなんてケースバイケースだと思うんだけど。
処理する必要のない場合もあるだろし。
大体チャタリングだってノイズの一種なんだから、それがソフトで対処できてるのに
他のノイズはソフトじゃ無理だっていうのはおかしいよ。
720:デフォルトの名無しさん
05/01/25 10:43:35
CPUの気持になって考えろ！
721:デフォルトの名無しさん
05/01/25 11:43:40
CPUの立場としてはヒステリシス特性持ったバッファ通して欲しいな。
722:デフォルトの名無しさん
05/01/25 12:00:31
>>715の方法は、まさにソレをソフトでやる方法
ＣＰＵが出力ポートでＨ／Ｌを出力した後で入力ポートにして暫くしてから読み出す。
すると、時定数で決まる値だけスレッショルドをコントロール出来る。
つまり、
ＣＰＵが現在Ｌと認識してるなら、出力時にＨを出して スレッショルドを持ち上げ
ＣＰＵが現在Ｈと認識してるなら、出力時にＬを出して スレッショルドを下げて ヒステリシスを実現出来るわけだ。
723:722
05/01/25 12:08:08
ゴメン 逆書いた
724:デフォルトの名無しさん
05/01/25 12:10:03
>>719
たしかにチャタリングもノイズの一種だけど、
チャタリングはいつ発生していつ収束するか読めるから、
ソフトだけでも対処できる。
でも、いわゆるノイズはいつ発生するかは読めないところが違うよ。
725:デフォルトの名無しさん
05/01/25 12:20:03
>>715
>最近は、ハードは
>in--Ｒ-Ｃ-Ｒ----CPU
> ｜
> ///
>だけつけて、後はソフトでコントロールしてねって場合も多いよ。
これでノイズ除去が出来て、さらに
チャタリングはソフトで除去出来るってこと？
726:デフォルトの名無しさん
05/01/25 12:37:23
>>725
出来る環境にあるなら出来る
出来ない環境なら出来ない
でしょ
727:デフォルトの名無しさん
05/01/25 12:45:08
話の腰を折ってしまいそうなんだが、
そういうCやRの大きさってどうやってきめてるんだろう
ハードは門外漢なのでいつも不思議に思ってるよ
728:デフォルトの名無しさん
05/01/25 12:50:45
(√CR)とCPUの特性から流したい電流で鸚鵡の法則
729:デフォルトの名無しさん
05/01/25 12:55:00
>>727
これ読んでみ
URLﾘﾝｸ(www.cqpub.co.jp)
730:デフォルトの名無しさん
05/01/25 12:55:15
>>728
嗚呼、なんとなーくイメージできました。サンクス
731:690
05/01/25 12:56:40
>>724
違うから対処できないという結論は導かれないよね（論理学）
チャタリングがいつ発生するか読めるってのもツッコミたいけど・・・
とにかくノイズでも対処できる物があることを分かって欲しいです。
理由もなく「出来ないんだ」の一点張りではソフト屋のプライドが。。。
インパルスノイズみたいな高周波ノイズだと単純にローパスフィルタを通してやるだけで
除去できる事もあるけど、その場合それがハードである必要は別にない。
ソフトでもフィルタとか書けますからね。簡単な例は既に示したし。
#とりあえず>>668さんが理解してくれたらそれでいいや^^;これで終わりにしよう
732:デフォルトの名無しさん
05/01/25 12:57:24
>>729
おお、こりゃおもしろい。これまたサンクス
733:デフォルトの名無しさん
05/01/25 13:14:18
>>725
ＣＲの値を最適にすれば、ノイズと同時にチャタリングも取ってしまう事も出来るよ。
これは一見タダのＣＲフィルタのようだけど、実はスレッショルド可変ポートや簡易ＡＤＣ
入出力切り替え可能なポートの特性を使って、時間軸で制御するわけ
734:デフォルトの名無しさん
05/01/25 14:22:17
ハードって面白そう
735:デフォルトの名無しさん
05/01/25 16:20:40
>>729
シンク電流、ソース電流はPICマイコンの消費電流になりますか？
736:デフォルトの名無しさん
05/01/25 17:14:04
＞７３５
なりません。
737:デフォルトの名無しさん
05/01/25 17:36:28
>>733
メタステーブルも取れますか？
738:デフォルトの名無しさん
05/01/25 18:10:37
>>735
電流計をＰＩＣの電源ピンに直列に入れたら、片方は針はふれないけど、片方はふれる。
ＧＮＤ側で計るかどうかで反転するけどね
739:デフォルトの名無しさん
05/01/25 20:15:15
>>731
……なんか釣りっぽくない気がするんだけどひょっとしてマジで書いてる？
論理学ってどこの星の論理学だよ。
前提が違えば結論は違いうる、これが論理だよ。
ていうかこれまでの議論は何（以下略
740:デフォルトの名無しさん
05/01/25 20:34:51
>>739
>ていうかこれまでの議論は何
=chatteringむだ話
741:デフォルトの名無しさん
05/01/25 20:38:13
>>739
ていうかこれまでの議論は何
=noise雑音
742:690
05/01/25 20:43:24
>>739
はい大マジですけどね・・・
仮に「いつ発生していつ収束するか読める場合はソフトで対処できる」という
条件が与えられた場合、「いつ発生するか分からない」物に対しては
「ソフトで対処できるか出来ないかは分からない」であって「ソフトでは対処できない」では
ありません。。。という意味のことを書いたのです。
もっとも「いつ発生していつ収束するか読める場合はソフトで対処できる」の条件は
>>724さんが勝手に持ち出しただけでそれが正しいという保証もありませんが。
まぁ横道にそれた感があるし、ノイズの議論を続けてくださいな。
743:デフォルトの名無しさん
05/01/25 20:53:06
>>715の回路はノイズ取りだけじゃなく、他にも面白い事が色々出来るよ
例：一つのポートにスイッチを２個つないでしまう。
+-s2---R2-+
+-s1---R1-Ｃ-R3----CPU
| ｜
/// ///
R1！=R2
R3＜R1+R3にして、 CPUからHを出しておいて 入力ポートに変更してGNDに落ちるまでの時間で
どっちがONなのか、2個共オンなのか判る。
744:デフォルトの名無しさん
05/01/25 20:54:22
｢動作するかしないか分からない｣ものは｢動作しない｣ものではありません
だから出荷してもいいんです
745:デフォルトの名無しさん
05/01/25 21:05:30
いままでのまとめ
・チャタリングを取るにはその最大持続時間より長いサンプル周期でサンプルするのが必要十分条件である
└ただし、真の最大持続時間は規定しえない
└よって管理された頻度のサンプリング間隔で２度採取し比較する方法は実用的には優れた手法である
・滅多に入って来ないノイズを取るのにも２度採取し比較する方法は優れた方法である
└理論的には確率に頼った方法であり、確実でないのではないか？
└正しく考察すれば2度採取する事で実用的に問題無いレベルに抑える事は可能
746:デフォルトの名無しさん
05/01/25 21:14:57
もう一個あるんじゃない
・ノイズ処理はハードでしか出来ない
└ソフトで出来るものもある
└どっちでやった方がいいかはケースバイケース
747:デフォルトの名無しさん
05/01/25 21:50:24
＞正しく考察すれば2度採取する事で実用的に問題無いレベルに抑える事は可能
すでに書いたけどこれに関してはそもそも議論の前提がおかしい。
ゲートの論理ひっくり返すような外来ノイズが乗るハードなんて腐ってるでしょ。
なんか学校の実習かなんかのでやったADC使ったLPFの実験かなんかの話と
混同してる学生さんがいるとしか思えない。
748:デフォルトの名無しさん
05/01/25 21:52:05
＞・ノイズ処理はハードでしか出来ない
これはそもそも正しくないでしょ。
ハードでしか出来ないのは、サージ等からCPUを保護する事。
実際に処理したい信号の周期よりも早いサンプリング＝オーバサンプリングさえすれば幾らでもノイズは減らせられる。
749:デフォルトの名無しさん
05/01/25 21:57:28
＞ゲートの論理ひっくり返すような外来ノイズが乗るハードなんて腐ってるでしょ。
ゲートの論理ひっくり返すようなのをノイズと呼んでは可哀想だよ。
現実はそういうのを理論的に防ぐ事は出来ない。
可能なのは「このノイズ試験をして大丈夫」 というレベルのみ。
では、それで大丈夫だからOKなのか？
まあ、基板のレイアウトで、CPUのすぐ横にリレーおいて、リレーが動く都度CPUが暴走するなんてのは
良くある話だけど、それはソレ。 一緒くたに考えるのはどうかと思うよ
750:デフォルトの名無しさん
05/01/25 21:59:31
>>749
だから「議論の前提がおかしい」といっているんですが。。
751:デフォルトの名無しさん
05/01/25 22:03:26
CR組んである入力にノイズ対策のために何回もサンプリングかける意味がわからない。
CRで取り切れてなければ時定数が間違えているか、信号の周波数領域までノイズが侵入しているかだと思うが。
いずれにせよハードに問題ありと言うことになる。
752:デフォルトの名無しさん
05/01/25 22:07:11
>>751
CR＋シュミットトリガならその通りだけど
CRが入ってるだけだと、それは意味がないよ
753:デフォルトの名無しさん
05/01/25 22:11:27
もうやめようかとも思ったけど、
＞実際に処理したい信号の周期よりも早いサンプリング＝オーバサンプリングさえすれば幾らでもノイズは減らせられる。
だからこれデジタル信号に関しては間違ってますよ。
754:デフォルトの名無しさん
05/01/25 22:15:40
CR＋シュミット というのが理想的なのは間違いないけど、やっぱり実用的じゃない。
装置が完成してから、細かな仕様が決まったり、
そもそも相手の仕様が設計時には判らない事も多いからだ。
実際につないでみてから、C/Rを調整なんて現場でやるわけにはゆかないだろう。
そういう時にCR+シュミットをやる手法として>>715 の方法がある。
CPU側から時間をコントロールすれば好きな特性が作れる
といっても、これをヤレといわれてすぐにやれる奴は少ないのが問題。
だから、バカチョン式に、CR+シュミットをある程度甘く設計しておいて
それ以上のノイズはソフトで取るという方式には十分実用的なメリットがある
755:デフォルトの名無しさん
05/01/25 22:18:22
>>753
どうして間違ってるの？
信号が0,1だろうがアナログだろうが、デジタルフィルタを設計すれば
ソフトで処理しようがアナログで処理しようが同じですよ。
実際は、ノイズ取りにIIRフィルタやFIRフィルタをわざわざ使うメリットはないでしょうけど
考え方も、理論面も同じですよ
756:デフォルトの名無しさん
05/01/25 22:18:55
>>753
だからオーバーサンプリングを無限にかければノイズは取れるだろ？
757:デフォルトの名無しさん
05/01/25 22:26:38
デジタル信号をCR+シュミットで処理してるなら
オーバサンプリングすれば、等価な処理が理論的にも可能だし、
CRよりもっと急峻で特性が良いフィルタを作る事も可能だ。
758:デフォルトの名無しさん
05/01/25 22:27:27
ああ、無限に早くする必要はないという意味ね
759:デフォルトの名無しさん
05/01/25 22:31:13
>>756
無限にオーバーサンプリングしたのをアナログと言う
たぶん・・・
760:デフォルトの名無しさん
05/01/25 22:38:53
>>759
有限でもいいでしょ？
無限に近くオーバーサンプリングすれば
それはデジタルですよ。
761:デフォルトの名無しさん
05/01/25 22:40:53
>>760
それを屁理屈と言う
間違いない
762:デフォルトの名無しさん
05/01/25 22:45:25
>>755
なんか昨日のハードディスク廚と同じ臭いがするな
なんでチャタリング取りとノイズ取りは同じか？という話をしているところに
そんな自分でわざわざ使うメリットもないと書いてある理屈を持ち出してくるんだか・・・
msecオーダーの話じゃなかったのか？
763:デフォルトの名無しさん
05/01/25 22:47:25
>>740-741
ﾜﾛｽ
764:デフォルトの名無しさん
05/01/25 22:56:45
>>743
限られたポートで多くの接点を認識したい場合に使うよね。
765:デフォルトの名無しさん
05/01/25 23:22:43
>>762
書いた意味は、
わざわざ FIRフィルタやIIRフィルタを使わなくても、
単純に２度比較やANDを(1/z + 1) と考えて使えばいいじゃない 程度の意味ですよ
外部のCRを近似したいなら b/(1/z+a) のデジタルフィルタで十分良い近似が得られますよ。
766:デフォルトの名無しさん
05/01/26 14:17:15
＞７５４
＞そもそも相手の仕様が設計時には判らない事も多いからだ。
おいおい、堂々とそんなことを書くなよ。
その方がはるかに大きな問題だろう。
767:デフォルトの名無しさん
05/01/26 14:29:49
>>766
ユニバーサルなインターフェースだとそういうことはよくある
768:デフォルトの名無しさん
05/01/26 17:18:48
>>766
あんまり現場（設置場所）へは行かないの？
または恵まれた環境なのかな。
うらやましー。
769:デフォルトの名無しさん
05/01/26 17:52:05
チャタリングとノイズの除去かー。
SWのチャタリングは 15ms × 2回 （おいらは 3回） が一般的じゃねーの？
Digital In（TTLレベルでの外からの入力） のノイズ除去はしてないね。
実際できないのが多い。
ある条件後、数ms〜数十ms以内に Hi/Lo を検出して即座に
Out ってのがほとんどだからか。
汎用のソフト作るならまだしも、特定の機器に接続ってのが
ほとんどだからあんまし気にしてないし、上の方法で実際問題ないね。
ほとんどが検査装置+ロガーだから特殊かな？
770:デフォルトの名無しさん
05/01/26 18:08:01
数マイクロ要求されたら無理だけど、数ミリなら
レベルで動作して、問題ない信号なら無理にノイズ取りはしないけど
エッジ処理（カウンタとか）をする場合は、最低2回は取る処理を入れてる。
771:デフォルトの名無しさん
05/01/26 20:11:21
>>745
必要十分でなくて十分だろ。
>>747
あるスレでは、リセットラインのノイズ対処でLSI/FPGA設計者が盛り上がってました。
あなたは非同期リセット派ですね。
>>753
信号帯域のノイズは消せない。
>>769
だからチャタは2度読み必要無いって。
772:デフォルトの名無しさん
05/01/26 20:25:13
このスレ読んで、理論と実践の両面で高レベルな人間は貴重だなと思った。
773:デフォルトの名無しさん
05/01/26 21:53:45
センサ→R→C→ CPU とやるのは
これはサージからCPUを保護するのが主な目的で
CPUの入力ポートがシュミット特性を持っていなければ
ノイズ取りは結局はCPUがやらなければいけない。
Cが大きいと逆にCPUにとってはノイズ取りが難しくなる場合もある。
よく勘違いがあるので注意。 ＝＞『CRが入ってるからノイズ取りはしていません』
ノイズ取りはCR+シュミットが必要なのよ。
似ているが、
センサ→R1→C--R2⇔CPU とやるのは シュミット特性までソフトで実現しようというもの
当然サージ保護の機能も兼用されている。 R1<<R2にしてADC代わりに使う事さえ出来る
リレー接点やスイッチの場合はR1を小さいか無くして、Cから接点クリーニング電流を流す
事まで兼用してしまう。
774:デフォルトの名無しさん
05/01/26 23:21:37
うーん、数レスROMってたけど、
2度読み必要ないってのは、誤認識(スイッチ押されたのに押されたと覆わない)しても
次のサンプルタイミングでは必ずチャタが落ち着いて正常認識できるはずだから
必要ないって認識でよい？
775:デフォルトの名無しさん
05/01/27 00:56:00
電気の基礎が分かっていないな。
776:デフォルトの名無しさん
05/01/27 07:21:29
>>770
カウンタなのにそんなことしたら・・・
777:デフォルトの名無しさん
05/01/27 09:56:01
>>776
一定周波数以上のパルスは打ち切りってことでしょ。
ハードウェアなんかだと、シフトレジスタ組んで、XORやANDをとったりってのは
ノイズ除去のためによくやる方法。
入力が断線したりした場合に不正なパルスを拾っちゃったりするので、
そういうのも考慮すると必要だと思う。
ノイズでゲートの論理が反転してしまうのは、ハードの問題ってレスがあったけど、
ケーブルへの輻射ノイズならよくある話で、
ハードだけでの対策はなかなか大変。
大抵は上で書いたようなのを、PLDなんかで組んじゃうんだけど、
(もちろんCRフィルタも入れて)
直接CPUのI/Oポートに入力だと、ソフトでやるんだろうね。
778:デフォルトの名無しさん
05/01/27 10:04:04
分解能は何で定義されますか？
779:デフォルトの名無しさん
05/01/27 20:03:57
>>774
HとLが変わるときに、1回だけHかLどちらかの値が読めてしまう可能性がある。
なんか問題あるか？
780:デフォルトの名無しさん
05/01/28 00:39:02
>>707
> ハードで誤りの確率が決まっていて、
はぁ ?
メディアの種類によって誤りの確率なんか全然違うぞ。
そんなあほなこと書いてて
> あのね、それ知ってて言ってるの
なんて、言ってるのはちと恥ずかしいね。(藁
781:デフォルトの名無しさん
05/01/28 07:26:18
>>780
メディアによる違いを含めて一定以下ということじゃないの？
782:よねちん。
05/01/28 09:24:29
OSitron、言語C++
Aタスクでthrow()を抄出した直後に、
割り込みが発生し割り込みでset_flgをおこなったあと、
ディスパッチが起こり、Aタスクに戻ってきたときに、
terminateしてクラッシュしてしまい、catch(...)に捕捉されません。
なんか制約があるのでしょうか・・・？
783:デフォルトの名無しさん
05/01/28 17:09:12
マイコン組み込み系、主に8bit経験者です。(20年)
シーケンサは見たこともないのですが、キーエンスのPLCをプログラムしてみないか
と打診が来ました。経験が生かせるでしょうか？
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
4739日前に更新/245 KB
担当:undef