制御系なら俺に聞いてもいいぜ（６）

制御系なら俺に聞いて ..

511:476
05/01/09 20:51:31
>>508
御心配頂かなくても、弊社はコンパイラメーカでもあるから勘所はわかりますよ

512:デフォルトの名無しさん
05/01/09 20:58:12
>>511
でもあんたはコンパイラの開発にかかわってないだろ？

513:ライブラリアン
05/01/09 21:11:42
Ｃも大変ですね。その調子ではシステムの開発が
完了するか予測ができませんね。
やはりＬＡＢＶＩＥＷがいいな。

514:デフォルトの名無しさん
05/01/09 21:25:17
ビットフィールドだと、
数ビットあるエリアに値を書く必要がある場合は便利なんだがな…

515:デフォルトの名無しさん
05/01/09 21:27:25
>>511
大丈夫、あんたの事なんか心配してない。
都合のいいことだけレスしてそうでないことはスルーしているのが気に入らないだけ。
あー、もし私の仕事と関わりが出てくるようなら話は別だが。

>>513
中途半端な顧客だとLabViewだと納得してくれなくてね。
#判ってない客は動けばいいと言う。よく判ってる客はLabViewをきちんと評価できる。

516:487
05/01/09 21:35:06
>>505
だからさ、
ビットフィールドの内部操作をバイトで処理する実装をバグだというから、
それよりも、PCIバスボードのくせに、I/Oをメモリマップにして、しかもバイトイネーブルに対応していない
ボードの設計の方がバグだろうと　言ってるだけさ。

ビットフィールドの内部操作をバイトで処理する実装は、メモリが相手である限りはバグではない
正しい実装だろう。

517:487
05/01/09 21:40:00
>>513
パソコンならDelphiでやっつけた方が余程簡単で、しかもやっつけられる範囲が広い上
再利用性が高いよ。

今では
メータ類もポトペタしてプロパティ設定するだけ。
シーケンサとの通信もポトペタしてイベントにコード書くだけだし

目の前でコード作れますよ

518:デフォルトの名無しさん
05/01/10 00:24:47
>>416
はぁ ? 何が言いたいんだ ?
それこそ、ハッキリ書けよ。

> 余計な事を言って手間増やされちゃたまらんよ

君のことか ? (藁

>>418
OS としては全然大丈夫 Compact Flush はリードしかしないし、ファイルシステムは使い捨てだから。
(そのために、メモリー上にファイルシステムを作る。)

もちろん、データを書き込むデバイスは途中で書き込みが中断されることがあるけど、そこはソフトで何とかする。
例えば、ブロック単位で書き込みを行い最後にブロック毎のチェックサムを書き込む。
次回の起動時や別の機器でそのデバイスを読み出す時は、先頭からブロック毎にチェックしていってチェックサムが異常だったらその前までのデータを有効とするとか等。

>>449
> ＦＡだとそこまで対策してるのは見たことないよ

まあ、FA と言っても色々だろうけど、君が見たことないからと言って世間にないわけじゃない。
あと、仮に対策していても取り説には「書込中は電源を切らないでください」とは普通書いておく。
なんかトラぶったときの保険としてね。

519:デフォルトの名無しさん
05/01/10 00:29:19
>>416
はぁ ? 何が言いたいんだ ?
それこそ、ハッキリ書けよ。

> 余計な事を言って手間増やされちゃたまらんよ

君のことか ? (藁

>>418
OS としては全然大丈夫 Compact Flush はリードしかしないし、ファイルシステムは使い捨てだから。
(そのために、メモリー上にファイルシステムを作る。)

もちろん、データを書き込むデバイスは途中で書き込みが中断されることがあるけど、そこはソフトで何とかする。
例えば、ブロック単位で書き込みを行い最後にブロック毎のチェックサムを書き込む。
次回の起動時や別の機器でそのデバイスを読み出す時は、先頭からブロック毎にチェックしていってチェックサムが異常だったらその前までのデータを有効とするとか等。

>>449
> ＦＡだとそこまで対策してるのは見たことないよ

まあ、FA と言っても色々だろうけど、君が見たことないからと言って世間にないわけじゃない。
あと、仮に対策していても取り説には「書込中は電源を切らないでください」とは普通書いておく。
なんかトラぶったときの保険としてね。

520:デフォルトの名無しさん
05/01/10 02:43:48
Flushなんて書いているあふぉはほっとこ。

521:デフォルトの名無しさん
05/01/10 02:59:44
>>516

> ビットフィールドの内部操作をバイトで処理する実装は、メモリが相手である限りはバグではない
> 正しい実装だろう。

だからさ、
メモリを相手にするばかりじゃないわけだからさ、
実際SHなんかだと、そういうケースが多いし、
ビットフィールドで書けたら、そっちの方が便利なわけで
いくら「正しい実装」だろうと、不便だとみんな言ってるんでないのか？？？

522:デフォルトの名無しさん
05/01/10 03:06:04
>>521
メーカーのコンパイラ使えばいいだけだろ？
いつまでも何を言ってんだ。

523:379
05/01/10 05:00:02
>>516
>PCIバスボードのくせに、I/Oをメモリマップにして
H8/SHで、I/Oをメモリマップ以外にできるのかな？

>バイトイネーブルに対応していないボードの設計の方がバグだろうと　言ってるだけさ。
バイトアクセスを保障しない仕様はよくあるけどな、内部レジスタでもなかったかな。
ＰＣＩのボードだけは保障するべきだということかな？

そもそも、ビットフィールドはＡＮＳＩの仕様で、
定義したビット数でアクセスすることを保障しているのだろうか？

524:487
05/01/10 07:46:05
>>521
誰も保障しろとまで書いてないだろ？

ビットフィールドの内部実装でバイト単位にアクセスするコンパイラと
どっちがお馬鹿な実装かって話しをしてるだけさ。

PCIボードの実装で、メモリー空間に割り付けてバイトイネーブルに対応しない事と
メモリ空間しかないCPUで　バイトでアクセス出来ないI/Oとを一緒にしてくれるなよ。
　16ビットのカウンターを８ビット単位に書き出すのは、それは馬鹿だろ？

だから、ビットフィールドの定義なんて読んだって、そんな細かな事は書いてないだろ。
どっちから確保されるかさえ書いてないんだからさ

525:487
05/01/10 08:05:52
面白いので調べてみた
URLﾘﾝｸ(www.asahi-net.or.jp)

＞失望と誤解
＞以下の問題が存在することは残念ではありますが、実際にこれを回避するための方法を私たちは1つも知りません。

ビットフィールドへのアクセスは、たとえアクセスされるビットフィールドがvolatile指定されたオブジェクトの一部であっても、
1バイトや1ワードなど、よりサイズの大きいオブジェクトにアクセスすることによって動作します。
ビットフィールドの読み込みや書き込みを行うために、ある決まったサイズのオブジェクトが
アクセスされるということをあてにすることはできません。同一のビットフィールドであっても、
その用途に依存してアクセスされるサイズが変わってくることもありえます。
アクセスされるメモリのサイズを制御することに関心があるのであれば、
volatileを使い、ビットフィールドは使わないでください。

526:デフォルトの名無しさん
05/01/10 09:13:32
>>521
だったら、自分がそういう実装のコンパイラを作れよ。
GCCを改造すりゃいいだろ？

たぶん、それを要望してもそういう実装をしようという奴は少ないと思うよ。
ビットフィールドそのものが実装は厄介な上、実装時も実行時も非効率。
かつ実際に、めったに使われない機能。
喜んで使うのは小規模組込屋くらいだろ。

実際、他の言語でビットフィールドもどきをサポートしてるのは殆どない。
似た機能としてはpascalの集合型くらいだろうけど、
これは1ビット単位だから、複数ビットのフィールドを定義出来るCのビットフィールド
に比べると簡単だしな

527:ライブラリアン
05/01/10 09:27:49
＞５１５

＞#判ってない客は動けばいいと言う。
＞よく判ってる客はLabViewをきちんと評価できる。

これはいい指摘だ。お客のことが言いたかった。
皆さんのマニアックなレスを読んで何の為に仕事を
しているかの一端が分かった。それはお客に評価されるためだ。
私の喜びはお客に評価して貰うことだ。
「あなたの作ったシステムはとても役に
たつよ」、「上司からいい評価をもらったよ」
「リピートを出すよ」「新しい案件があるので、是非あなたに
やってもらいたい」と言われることだ。

528:デフォルトの名無しさん
05/01/10 09:39:30
>>527
いや、だからあなたが優秀な営業マンである事は判ったけどさ、
しまいにはPCを車載でも平気で採用しそうな勢いだな。
・・まあ、超小ロットの特殊仕様車じゃそういうのもアリかもしれんけど・・・

529:デフォルトの名無しさん
05/01/10 10:14:24
>>520
Typo しか指摘できないということで FA ?

530:デフォルトの名無しさん
05/01/10 10:38:10
わたしゃ519じゃないが、フラッシュメモリの英語表記(?)は
Flushでも間違ってないよ。Flashの方が圧倒的にメジャーではあるが。

むしろこんなことも知らない奴は普段ちゃんと石のデータシート読んでるのかと
問い詰めたくなる。

531:デフォルトの名無しさん
05/01/10 10:39:57
SHでビットフィールド実装するとして　値１を書き込む場合、

バイトreadして即値or　して、バイトwrite　って事になるのが普通じゃない？
だって8ビット以上の測値はpc相対オフセットで読む事になるから
命令も長くなるしさ。

int幅だから32bitでアクセスしろって事？
で、charで指定した場合だけ8ビットでアクセスしろって贅沢言うわけね？
しかしさ、int以外のビットフィールドはANSIじゃないでしょ？

というかさ、ビットフィールドの型は、本来、そのビットを　どう型変換するかって意味じゃないの？
だから　　signed かどうかで　1ビットが1になったり-1になったりするだろ？

532:デフォルトの名無しさん
05/01/10 10:55:15
話は少しそれるが、ISO/ANSIの言語仕様で、

objectの型がvolatileの場合はメモリ参照サイズ = 型のサイズになる
（たとえば struct S { volatile int bit1 : 1; } b; ならb.bit1の参照時には常に4バイトアクセスコードがでる）

という保証はないの？　いままでそういうつもりで使ってたんだけど…

533:デフォルトの名無しさん
05/01/10 11:24:12
>>532
無いでしょ。
それは構造体 S で　1bit　の領域を定義して、そのbit1を int で参照しますという意味じゃないの？
普通はintは符号付だから　結果は　0か-1になる筈だけど
ANSIでは、どっちでもいいとしてるもんだから混乱の元
（コンパイルオプションで変更出来るものも多いようだけど）

534:デフォルトの名無しさん
05/01/10 13:13:02
>>532
ANSIの仕様は忘れたが、うちのコンパイラでは保証してる。
以前、そういう例に対して、最適化して1バイトアクセスコードを出すようにしたら、
顧客からがんがん苦情がきたよ…。

535:デフォルトの名無しさん
05/01/10 14:15:03
>>534
532はISOで保証される（処理系依存ではない）か
聞いているのに、オマエ馬鹿だろ。

コンパイラで保証されるものがあっても当たり前すぎる。

536:デフォルトの名無しさん
05/01/10 15:25:34
バイトアクセスに最適化してくれた方が性能出る場合に、
どっかのバカを救うためにいつもワードアクセスされた方が困るがな。

Cは生成コードが想像つきやすいこともあって、「想像」=「事実」と
勘違いしてしまう人も多いのかな。

537:379
05/01/10 16:31:54
>>534
>ANSIの仕様は忘れたが、うちのコンパイラでは保証してる。
つまり、ANSI準拠というわけではないということですか？
別にそうでも構わないし、ヴァカとは思いませんが。

538:デフォルトの名無しさん
05/01/10 17:06:07
68020なんかのCPUでは、ビットフィールド命令を使用するか否かの
コンパイルオプションがあったので、
アクセス幅設定のオプションもあるかなと思ったわけですが、
無いんですね。

539:デフォルトの名無しさん
05/01/10 17:07:26
該当するbitに対してのみvolatileが保障される

540:デフォルトの名無しさん
05/01/10 17:29:33
>>533
今ANSIの仕様書をみてるんだが、その辺の事情はどの辺を読めばわかる？
volatileの項とかみたけどよくわからん。

541:デフォルトの名無しさん
05/01/10 18:37:40
このスレ、ツール屋も結構混じってるな・・・・・・
CM
　コンパイラ、ICE、評価ボードはお金を払って買いましょう。
　いや、買ってください。m(。。;)m

542:デフォルトの名無しさん
05/01/10 19:11:04
>>540
ビットフィールドとvolatileは無関係。

ビットフィールドの値の符号有無しは規格では決まってない。処理系で規定する
ことが求められているのは、領域の埋めかただけだな。
volatileオブジェクトは処理系の外で変化するかもしれないから毎回アクセスする。

書いてないことは保証されていない。

543:デフォルトの名無しさん
05/01/10 19:39:35
>>542
ありがとう。
volatileがある時にメモリアクセスサイズが保証されるかを調べたかった。

> 書いてないことは保証されていない。
そうだね。
しかし、どこにも書いてないことを確認するのが大変だ…。
直接書いてなくても、あちこちの記述をつなぎあわせると
規定されていることがわかったりするし。
以前、識別子のスコープルール（block scopeの生成条件）を調べるのに一日かかったよ。

544:デフォルトの名無しさん
05/01/11 01:24:34
>>537,379
処理系依存だったら処理系が保証して当然。
保証しなくていいのは不定な動作だけ。
まぁ、馬鹿には分からんかもしれん。

545:379
05/01/11 01:36:12
釣られて言えば、
処理系依存なら処理系の勝手

546:デフォルトの名無しさん
05/01/11 07:19:09
処理系定義（implementation defined）
未規定（unspecified）
未定義（undefined）

を区別しよう。

547:デフォルトの名無しさん
05/01/11 21:09:28
>>464
すごい燃料だな・・・・・まだ燃えてるよ・・・・

548:デフォルトの名無しさん
05/01/11 22:29:57
ビットフィールドは便利なようだが処理系依存なので使わないのが吉。

ビットフィールドは使わずにビット操作。
なおかつアセンブリで8bit/16bit/32bitでread/writeする関数を作成して使っている。
さらにコンパイラ/ターゲット依存を覚悟で、
inlineかつインラインアセンブリな関数にしている。

コンパイラ変更あるいはターゲット変更でも、
read/write関数を直すだけですむので無問題。
ビットフィールドは、あっちこっち直す羽目になるので問題大。

549:デフォルトの名無しさん
05/01/11 23:01:08
途中からコンパイラを変更するなんてあるの？ちょっと信じがたい。
まあソースの再利用はあるかもしれないけど。

550:デフォルトの名無しさん
05/01/12 01:22:07
つか、組み込み屋がIOアクセスするのにビットフィールドを平気で使うこと
自体が折れには到底信じられないんだが・・・・。使わないことが常識だと思ってたよ。

>>519
書き込み可能なデバイスで、書き込み中に電源断しても、デバイスのその後の動作に問題が
発生しないことを保証するものはあまりない。SDカードやCFなんてのも普通は全くの保証外。
壊れても文句言えない。少なくとも、ちゃんとデバイスメーカーに確認してから使えよな。
ま、保証してくれるかはわからないが（ｗ

551:デフォルトの名無しさん
05/01/12 03:20:02
>>550
> つか、組み込み屋がIOアクセスするのにビットフィールドを平気で使うこと
> 自体が折れには到底信じられないんだが・・・・。使わないことが常識だと思ってたよ。

しかし、組込屋が使わないとなると誰が使うんだ？

552:デフォルトの名無しさん
05/01/12 04:50:09
おう、組み込み屋じゃない漏れはよく使うぜ。

553:379
05/01/12 05:26:37
>>551
むしろ組み込み屋じゃないほうが良く使うと思う。

554:デフォルトの名無しさん
05/01/12 06:45:49
俺もビットフィールドは嫌いだが、メーカーの提供しているヘッダファイルの
IO定義がビットフィールドを使ってるしなあ（ SH/H8）。

555:デフォルトの名無しさん
05/01/12 13:03:34
まあ、取り込み作戦なんだろうけど、それを使ってもさらに抽象化しとくべきだろうな

556:デフォルトの名無しさん
05/01/12 13:26:12
>>553
ドライバ屋さんはI/Fは用意してくれるがビットに詰めるのこっち任せだったりするからね。

557:デフォルトの名無しさん
05/01/12 13:32:08
質問です。
デバイスドライバを書くときに、デバイスのどういうことを調べていくのが一般的ですか？

558:デフォルトの名無しさん
05/01/12 19:01:21
デバイスドライバを書くときは、デバイスがどういうものかを調べていくのが一般的です

559:デフォルトの名無しさん
05/01/12 19:26:26
>>558
参考になりました！ありがとうございます！！！

560:デフォルトの名無しさん
05/01/13 00:35:39
なったのかよ！

561:デフォルトの名無しさん
05/01/13 01:22:49
>>560
いいえ、皮肉です。

562:デフォルトの名無しさん
05/01/13 06:33:58
むしろ果肉

563:デフォルトの名無しさん
05/01/13 12:48:41
>>557 マニュアルはたいがい「このレジスタにこれを書くとこう動く」式で書かれてるね。
その中から、「アプリからこう使えれば便利だな」を抽出するように読もうとしてるよ。
機能レベルでそれを把握してから、時間的な条件（割り込み発生のタイミングとか、
許されるディレイ）、制約条件（この使い方のときはこっちがダメとか、書き込みと
割り込みが同時に起きたときどっちが優先、とか）の所と照合すると、間違った使い方
しようとしてないかの検証になる。

564:379
05/01/13 18:07:44
>>557
どう動かすかということはもちろんだけれども、
どう抽象化するかが上手い下手になると思う。
そのために操作の単位がどうなるのかを調べる。
そんな風に、設計してます。

565:デフォルトの名無しさん
05/01/14 21:44:36
はじめまして、一つ伺いたいのですがよろしいでしょうか？

あるRAMエリアに対して0でクリアしたあと本当に0になってるか
チェックする処理を作りたいのですが、とにかく処理時間重視と言われました。

処理能力を気にしないので良いなら悩まなくても良いんですが、
どういうロジックを組めば最も高速にクリア＆チェックできるか私の頭ではわかりませんでした。

言語はCですが、処理能力考えるとアセンブラで組んだほうがいいような気もします。
何かよい知恵がありましたら教えてください。

566:デフォルトの名無しさん
05/01/14 21:45:34
あと、使ってるのはSH-2です。

567:デフォルトの名無しさん
05/01/14 21:51:01
>>565
どうやったらいいのか
どこで差がつくのかわからん

568:デフォルトの名無しさん
05/01/14 22:05:17
クリアした後
本当に0になってるかチェックした後
本当に0になってるかチェックした後
本当に0になってるかチェックした後
本当に0になってるかチェックした後
本当に0になってるかチェックした後
……

569:デフォルトの名無しさん
05/01/14 22:45:21
・・・・・よし、明日の朝はトーストとハムエッグにしよっと。

570:デフォルトの名無しさん
05/01/15 00:44:15
埋める方をDMAのバースト転送を使ってやる。
ただし、転送元は内部レジスタで０になってるとこ。

チェックはソフトで地道に。

これで、全体的には速くなる（ｗ

571:デフォルトの名無しさん
05/01/15 01:39:09
>>570
CPUからメモリへの書き込みパスがチェックできてない。
…ということを考える必要があるかな？

572:デフォルトの名無しさん
05/01/15 02:22:53
私は普通にmemsetで0にクリアして、その後そのRAMエリアを読み込んで
0と比較すれば良いと思ったんだけど、処理能力、処理能力いうんですが
やっぱり大きく変わるんですかね～？

一番大きいバッファでもクリア&チェックする領域は64KBぐらいです。

573:デフォルトの名無しさん
05/01/15 03:35:19
どれくらいの速さが要求されているのかにもよるな

574:379
05/01/15 04:01:11
>>565
なんで？

575:デフォルトの名無しさん
05/01/15 05:20:41
>>565 >>572 memsetでいいよ。それの中はASMで作られているから。ただしその後の
memcmpで64KBのゼロと比較するとしたら、あまりにもサイズのムダなので許せない。
#define CLRTOP 0x100000
#define CLRLEN 65536　　　　　　/* 100000h番地から６４Ｋクリヤするとして */
memset((char*)CLRTOP,0,CLRLEN);
if( 0==memcmp((char*)CLRTOP,(char*)CLRTOP+1,CLRLEN-1) ) で、クリヤされたと判定

576:デフォルトの名無しさん
05/01/15 05:44:56
指示出した奴が評価できるとは思えんので、なにやってもﾖｼ

577:デフォルトの名無しさん
05/01/15 06:44:27
バッファの先頭・終端addressが共に4 byte alignされてるとして、
int is_zeromemory(char *start_address, char *end_address)
{
　　int result = 0, *p;
　　for(p = (int *)start_address; p < (int *)end_address; p++) {
　　　　result |= *p;
　　}
　　return result == 0;
}
あたりが定番か（4 byte alignされてない時は前後に補償コードを追加）。

578:デフォルトの名無しさん
05/01/15 09:34:50
ゼロになってるか判定するコードだね。確かにバイトでやるより速い。
どうせならforの中で、resultが０でなければreturn 0、forが終わったらreturn 1に
してほしかった。　もっと速さを要求されるなら、書き込んで読みそれがゼロか見るループを
書けばいいが、そのとき最適化によって書いたメモリを読まずに書き込んだレジスタのほうを
判定するコードが出されることがよくあるので注意が必要。

579:デフォルトの名無しさん
05/01/15 11:02:18
その程度の処理ならタコな書き方しなければ大差ないだろ。
それより0書いて0読んでテストできた気になってる方が問題　ヽ(´ー｀)ﾉ　

580:デフォルトの名無しさん
05/01/15 11:07:44
>>578
> どうせならforの中で、resultが０でなければreturn 0、forが終わったらreturn 1に
> してほしかった。
せっかくビットORを使ってループ中の分岐を減らしてるのに、それじゃ意味がないと思う。

値が0でないメモリが見つかる（= 書き込みが失敗していた）ケースは
滅多にないはずだし。　

581:デフォルトの名無しさん
05/01/15 11:26:46
>>578
volatile

582:デフォルトの名無しさん
05/01/15 12:10:45
みなさんありがとうございます。

・・・というとCでもアセンブラでも大差はないということでしょうか？
0でクリアした後0でチェックするのは、ちょっと他の所で問題があったらしいのです。

なので私は最初あるバッファに対し0xB6を書いて読んでチェック、0x49を書いて読んでチェック
その後0でクリアして0でチェックという関数を作った矢先、処理能力云々言われ
今に至っているんです。

消すバッファが最初は2つぐらいで良いといってたのに、
最終的には処理の中間に生成するバッファも含めてやばそうなバッファ全部消せ
ということで処理速度をさらに重視した次第・・・らしいです。

583:デフォルトの名無しさん
05/01/15 13:10:09
素朴な疑問。
書き込みに失敗してたらどうするんだろ。

584:デフォルトの名無しさん
05/01/15 13:13:52
マーチングテスト最強

585:デフォルトの名無しさん
05/01/15 14:28:55
582>キャッシュのことは考慮済み？

586:デフォルトの名無しさん
05/01/15 15:15:03
SH2はキャッシュがあったかどうかしらんが
キャッシュがあるＣＰＵだとキャッシュに書き込んでいるだけになることもあるよな

587:デフォルトの名無しさん
05/01/15 16:00:34
そこでランダムリプレースアルゴリズムのキャッシュですよ。

588:379
05/01/15 16:26:19
で、どうして、書いたものが保証されないという事態がおきる？
ＲＡＭに書いたものが保証されたないって、スタックも保証されない？

589:デフォルトの名無しさん
05/01/15 16:33:37
>>582 584の言ってるのは55,AA,FFを書いた後00にする検査のことね。585,586,587はそこまで
問題にならないとおもう。583のギモンに対して特に対処策がないなら、単にmemsetでゼロを
書くだけでいいと思う。B6/49という値に何か意味はあるの？

590:デフォルトの名無しさん
05/01/15 16:36:42
たしかに、書いた物が保証されないって、RAMが別チップでﾁｯﾌﾟｾﾚｸﾄがちゃんと出てないとか、
そんな事態ぐらいしか想像できないね。そんなのハードのアドレスデコード部分のバグだから
よっぽどのことがないとお目にかかれないぞ。

591:デフォルトの名無しさん
05/01/15 16:59:24
PCのBIOSがメモリチェックやるのはあれは何のため？

592:デフォルトの名無しさん
05/01/15 17:54:53
あれは「仕事してま～～す」というデモンストレーション」なだけ

593:デフォルトの名無しさん
05/01/15 17:57:40
>>591
PCのメモリは、
ソケット着脱式だから、
　メモリをユーザが取り替えているかもしれないから、少なくとも容量はチェックしないといけない
　もしかして接触不良があるかもしれない

594:デフォルトの名無しさん
05/01/15 18:23:24
>>590
バグと言うか、製造後の不良品のチェック用に商品に検査モードを搭載してるけどな。
RAMのアドレスバスのショートのテスト、データバスのショートの検査とかも入ってるよ。
55,AA,FF、00もそうだし、0x01,0x02,0x04,0x08,0x10・・・・・の様にデータバスのビット
立てたり、書いた後でアドレスバスがショートしてた場合の該当アドレス参照したり。

595:582
05/01/15 18:53:33
大きなことではいえませんが
昔はそのバッファは消していませんでした。
次の取引で「上書きされるだろう」とのことで・・・（処理時間を気にした結果、消さなかった）

しかし、前回のバッファが上書きされること無く悪さしたため大変なことになりました。
よって今回、いちいちそのバッファに情報を書き込む前に前回情報を消して、
本当に消えてるかチェックするという事態になりました。

596:デフォルトの名無しさん
05/01/15 19:28:15
ありがちな話だ…

597:デフォルトの名無しさん
05/01/15 20:31:30
要はバグを修正せずに小手先で逃げているわけか。
桑原桑原。

598:デフォルトの名無しさん
05/01/15 20:40:07
>>588
RAMは良く壊れます。ハードエラー(故障)だけでなくソフトエラー
(α線などによる)もあります。
RAMだけECCやパリティチェックを入れたりしているハードウェアもありますよね。

>>595を見るとそういう話でないようだけど。チェックの意味ないじゃん。

599:デフォルトの名無しさん
05/01/15 21:24:10
>>582
気が弱そうだな。そんなんで　やっていけるのか？心配だな。
・・・・・・・・・・・・・・なんか小腹がすいたな。>>582よ。メロンパン買って来い　(・∀・)ﾉｼ

600:デフォルトの名無しさん
05/01/15 21:36:42
オレ午後ティー

601:デフォルトの名無しさん
05/01/15 23:46:35
>599
いえ・・・まだ新人なのもで社会人として一年も経験してませんし。
組み込み系に流れ着いたのも何かの縁、がんばります。

ところで制御系といっても同期はなにやら違うことをやってます。
なんていうかGUIでなにやら作っている感じです。（詳しくはわかりませんが）
なのでアドレスのことやI/Oのことなど特に意識してないようです。

私はSH-2でモータとか回してます。制御系といっても色々あるんですね。

602:デフォルトの名無しさん
05/01/16 04:39:02
いろいろあるよ。俺はリレーの開閉とか無線の周波数作るシンセの制御が多い。
どの分野でもシリアル通信のプロトコルは勉強しとくといいよ。割り込み、リングバッファ、
ACK/NAK、チェックバイト、再送云々・・・殆どの機器で付いて回るから。

603:デフォルトの名無しさん
05/01/16 13:22:13
>>602
>無線の周波数作るシンセの制御
これってDDS？

604:デフォルトの名無しさん
05/01/16 15:24:06
DDSにしても直接プログラムで作り出すのは無理っぽいね

605:デフォルトの名無しさん
05/01/16 15:31:28
DDSコントローラーのレジスタに書き込んで
あとはおまかせポン
ソフトだけじゃ周波数合成に専念させても数十kHzが限度

606:デフォルトの名無しさん
05/01/16 17:05:51
>>601
>なんていうかGUIでなにやら作っている感じです。（詳しくはわかりませんが）

多分、操作画面を作ってるんじゃないの?
タッチパネルとか、PCからコントロールするためとか。

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
＞チャタを確実にキャンセルできるかどうかはチャタが持続する時間より
＞サンプリングの周期が長いかどうか、それだけで決まる。

正解

次ページ