05/01/03 11:38:35
制御系＝マイコンではないな。ＰＣを使ってもできる。
要は何台作るかだ。一台しか作らないのにマイコンで
やることはない。あとＦＰＧＡを使うてもある。
ソフトでできる処理はせいぜい１０マイクロＳＥＣ。
ＦＰＧＡはその１００倍は可能だから勝負にならない。
値段はたかくなるけど。
370:アルゴリズム
05/01/03 11:44:09
事務系から制御系に移れるかという質問があった。
それは不可能。日本語を話せる大工さんが、すぐに旋盤工に
なれないようなもの。この場合ソフトは日本語にしか相当
しない。それに制御系を選んだ人はだいたいプラモデルとか
作るのが好きな人。
このような要素は勉強してどうなるものではない。
371:デフォルトの名無しさん
05/01/03 11:48:18
>>370
私は論理学を専門にやってた院卒ですがちゃんとやれてます。
372:アルゴリズム
05/01/03 11:52:23
うちの制御系はＷＩＮ－ＸＰとＬＡＢＶＩＥＷとＦＰＧＡで
作っている。Ｈ８に比較し数十倍のパフォーマンスが可能。
用途は計測、制御、画像処理、モーション、
ＩＣテスターなどだ。台数としては１台か２台かだ。
この特長はエクセルやイーサネットが使えることだ。
制御でＥ－ＭＡＩＬで携帯に警報をだすなんてしゃれたこともできる。
373:デフォルトの名無しさん
05/01/03 12:01:08
>>372
> この特長はエクセルやイーサネットが使えることだ。
> 制御でＥ－ＭＡＩＬで携帯に警報をだすなんてしゃれたこともできる。
>
今時ﾏｲｺﾝでも普通にできてる（Excelを除く）
374:アルゴリズム
05/01/03 12:02:50
マイコンでも製品開発をすることがある。
この場合パソコン上でＬＡＢＶＩＥＷで雛形を開発する。
それで仕様を決定しマイコンに移すのだ。
製品開発はソフトのスキルより重要なことがある。
それは仕様をきめるということ。
マイコンをやった人なら分かると思うけど、
仕様変更がなんどもくるよね。それは仕様が決まって
いないからだ。あげくはこのチップではできなから
違うチップに変えたなんてこともある。
つまり制御系も仕様が一番大事だ。
だからパソコン上で雛形を作る。それを
お客（自社の幹部）に検討してもらう。
このようにすれば結果的は速く、安く
仕上がる。
375:アルゴリズム
05/01/03 12:09:05
マイコンをやっている人は会社の利益とかは
あまり興味がない。自分のスキルを評価して
くれるかどうかだ。会議などでも「その技術は面白い」
とか「そのチップは性能が良い」の類の発言をする。
でも会社は利益が大事だ。
だから会議などで「その方法は利益面でマイナスだ」
なんて発言したら注目をあびることは間違いない。
376:アルゴリズム
05/01/03 12:16:54
＞３７３
＞この特長はエクセルやイーサネットが使えることだ。
＞制御でＥ－ＭＡＩＬで携帯に警報をだすなんてしゃれた
＞こともできる。
普通っていうけど、あなたならＰＩＣでアナログ信号を読み取り
その値を１時間ごとにＥ－ＭＡＩＬで携帯に送るソフトを
何時間で作れますか？
377:デフォルトの名無しさん
05/01/03 12:55:30
>>376
373じゃないけど、PIC16F873クラスを使って良ければ
A/Dとシリアルは実装済みなんで、回路基盤を起こす時間を無視すると
そんなに時間はかからんでしょう。
Linux Boxに繋げてcronでメールまでスクリプトでできると思うし。
そういう俺もLabVIEWで組んで仕様書作って
外注している立場だけどね。
# LabVIEWは俺を堕落させた。
378:デフォルトの名無しさん
05/01/03 13:24:29
普通のマイコン＝ＰＩＣ
と認定されました
379:デフォルトの名無しさん
05/01/03 13:26:32
>>369
>一台しか作らないのにマイコンでやることはない。
そんなことはない。
パソコンで低消費電力、リアルタイム、無停止のシステムが組めるのか？
380:デフォルトの名無しさん
05/01/03 13:52:17
>だから会議などで「その方法は利益面でマイナスだ」
>なんて発言したら注目をあびることは間違いない。
どんな会社だ・・・
381:デフォルトの名無しさん
05/01/03 13:56:42
まちがいない！
382:アルゴリズム
05/01/03 14:14:09
＞３７９
＞パソコンで低消費電力、リアルタイム、
＞無停止のシステムが組めるのか？
組めるよ、ＰＤＡもあるし。
反対にの１台しか必要なのに、マイコンで作るのか。
趣味ならそれでいいかもしれないけど。私が担当者なら
シーケンサとかパソコンで作るね。
最初から制御＝マイコンと考えるのは
頭が硬直している。
383:アルゴリズム
05/01/03 14:15:43
＞３７７
＞そういう俺もLabVIEWで組んで仕様書作って
＞外注している立場だけどね。
それが正しい。
あなたは出世するタイプだ。すでにしていると思うけど。
384:アルゴリズム
05/01/03 14:17:54
＞３７９
さんに聞きたい。
リアルタイムとはどのようなものと考えいてる。
385:377
05/01/03 16:11:48
>>383
出世しないよ。それだけなら代わりはいくらでもいるからね。
# つーか仕様書を書かされている段階で下っ端だよ。
386:アルゴリズム
05/01/03 16:24:53
＞３８５
自分を卑下してはいかん。
387:デフォルトの名無しさん
05/01/03 17:52:40
まぁあれだ、業務系と制御系を両方経験した私が語ろう。
職業の喩えを出していた人がいたが、その例に倣うと
業務系プログラマ(会計士)に制御系プログラマ(職人)の真似はできませんよ、と。
#勿論逆も難しいわけだが。
業務系は画面の枚数で仕事量を量ることがあるということで判るとおり敢えて言えば広さの仕事。
制御系はその逆で、テストしながら仕様を確定したりI/Fを伴わない改変があったりと、深さの仕事だと思う。
学業が理数系と文型と言う風に単純に分けられないのと同様、単純には分けられないけどね。
どちらにしても、社内顧客なんて相手にしていても仕様を詰める楽しみはないんじゃないかな。
尤も、エンドユーザと仕様を詰めるような立場になると、コーディングなんてしてられなくなるけど。
388:デフォルトの名無しさん
05/01/03 18:50:31
組み込み以外から組み込みの分野に来て、うまくいった例を見たことが殆どない。
皆さんの周りで成功した事例ってあります？
389:デフォルトの名無しさん
05/01/03 19:16:48
>>388
もろハードオンリーから組込みに来てる人は
普通に成功してる ような気がする
390:デフォルトの名無しさん
05/01/03 19:29:11
業務系、制御系、組み込みの違いが分かってない香具師が
結構いるよね。
変なｺﾃは分かってるけどあえてごちゃ混ぜにしてる釣り師。
391:388
05/01/03 19:42:35
ハードからは、ね・・・・・・・・・
仕事でマジ困ってます。「純ソフト屋」っての？あいつら猿？
仕事で（ﾟДﾟ）ﾊｧ?の連続です。明後日からチンカスの相手だ（涙
392:デフォルトの名無しさん
05/01/03 19:48:42
適応領域の知識が足りないので、ソフト屋うんぬんは関係ない。
(= ソフトができても物を知らんと使えない)
逆の立場にならないことを祈ろう。
393:デフォルトの名無しさん
05/01/03 20:17:51
>391
まったくの素人と思えば良い
メモリアクセスを隠蔽した言語しかできないのな
394:デフォルトの名無しさん
05/01/03 21:33:31
ハードなんて言葉使ってる所がか・な・り芋っぽいです
395:デフォルトの名無しさん
05/01/04 00:59:07
器用貧乏の称号を授かり、なんでもかんでもやらされるのも考えものだ
396:379
05/01/04 02:08:26
>>382
ほんじゃ、人工衛星にのっけるものもPDAでやりますか？
397:379
05/01/04 02:21:35
>>382
４８５でデータを受けて、パトライトを６点表示。
自動車組み立て工場で使用。使用期間半年。
PDAでやりますか？シーケンサでやりますか？
私なら PICマイコンで十分と思うけど。
398:379
05/01/04 02:35:18
>>382
これはマジですが。
トリガ信号で、
A/D 12bit精度で9ch を 70μsec以内にサンプリング
100μsec間隔 で 3000サンプリング
３バンクを用意して連続３回のトリガに対応
シリアルでホストに転送。
無停止、電源の投入遮断は、手順なしで電源線で行う。
こういうデータロガを１台のみ。シーケンサやPDAでできますか？
399:ライブラリアン
05/01/04 10:45:41
＞３９８
マジで回答いたします。
その仕様どおりならシーケンサーでは無理だと思います。
普通、目的を達成すればいいのだから仕様を決める時点
では柔軟性があるはずです。
マイコンを前提にした仕様をシーケンサーに移るかどうかの
議論は意味がない。
パソコンならできますね。今はパソコンとＰＣＩのボード
のほうがマイコンよりはるかに性能がいいのはご存知ですよね。
さらに１台しか作らない場合はパソコンの方が安い。
ＰＩＣが安い言う人、ＰＩＣが得意なので自慢したいだけ。
ビジネスとは違う次元の話である。
ドキュメント、メンテナンスを総合
で考えるとパソコンの方が全て場合安くなるのが普通。
400:デフォルトの名無しさん
05/01/04 11:32:02
>>399
1台だけ作るなら、職人さんに発注すると基板作ってパソコン一式と同じ程度で作ってくれますよ。
確かにドキュメントまで期待したら倍以上取られますが
それはパソコンでやっても同じでしょ？
それに、パソコンでやると振動、電源、寿命と、色んな意味で難しいでしょ？
現実1台こっきりでも納品して3年ちゃんと動かないと、マズイくないような場合ってそんな多いですか？
401:ライブラリアン
05/01/04 12:01:56
＞４００
＞ドキュメントまで期待したら倍以上取られますが
＞それはパソコンでやっても同じでしょ？
あなたの言うとおり、パソコンでやるとドキュメントが無いことにはならない。
だから基板を作るか買うかの問題です。パソコンで作ることは
すなわち、市販のボードを買うことになる。
それにはドキュメントが当然ついているので、その費用はないということです。
＞現実1台こっきりでも納品して3年ちゃんと動かないと、
＞マズイくないような場合ってそんな多いですか？
的を射た指摘だ。まず品質は多く作られたものが良い。
大量生産のＤＥＬＬのパソコンの方が１毎だけ作った基盤より
品質が良い。基板も後々、バグもでてくる。
作った製品をお客のところで信頼性試験をしてもらっているようなものである。
それから故障用として予備のものを用意しなければならない場合もあり、
さらに価格が高くなるということになる。
故障したときには絶対呼ばれる。パソコンならお客がメンテナンス
してくれる。
唯一電源を落ものはＵＰＳを途中に入れなければ
ならないけど。
402:デフォルトの名無しさん
05/01/04 13:43:41
>>401
大量生産のDELLのボードが3年持つというのは・・・・制御用専用に作られたのならともかく
残念だけどパソコン品質じゃ 手組みで1枚だけ作ったボードに明らかに劣るよ。
ホントに使った事あるのかな？
毎日電源入れたり切ったりしたら3年で半数近くが故障しないかい？
特に振動やホコリの多い現場で使った経験ある？
それなりに対策はするけど、その対策費用はけっこう高くついてるよ。
パソコンならお客がの話も無理っぽいんだが？
そもそも、パソコンでも制御用だとどうしてもキーとなる部品が必要だろ？
I/OとかADC用ボードとかさ、そのあたりのボードメーカって栄枯盛衰。
安価なの出してる所は3年もしたらどうなるやら判らんし
高価な有名所はボード1枚がマザーより高いじゃかないか
結局職人さんが生きてる限りはメインテナンス出来る方が 実は安心だったりするよ。
といってもそれは客先にはいえないんだけどね
403:379
05/01/04 13:46:36
>>399
>>A/D 12bit精度で9ch を 70μsec以内にサンプリング
>>100μsec間隔 で 3000サンプリング
>ＰＩＣが安い言う人、ＰＩＣが得意なので自慢したいだけ。
>ビジネスとは違う次元の話である。
元来PICじゃ無理でしょ。
パソコンで100μsec間隔のサンプリング？
QNIXならわかるけど、windowsでやりたくないな。
>>無停止、電源の投入遮断は、手順なしで電源線で行う。
>パソコンならできますね
できますか？
404:デフォルトの名無しさん
05/01/04 13:54:31
>>403
PICで難しいのは最後の 3千サンプルの部分だね。
EEROMだと 100マイクロ間隔で書き込む事が出来ない。
ささっとすましたいなら M16の出来合いのボードにADC接続だけど
1品料理に汎用ADC在庫するのもなんだから、自分ならPICを９個汎用ADC代わりに使うかな
という事で M16の汎用ボード＋9個PICでチャチャとやっつけるな
405:デフォルトの名無しさん
05/01/04 14:11:35
パソコンでこの条件で作る事は、その性能のADCボードが入手出来るならという条件が満たせるなら
UPSを入れて、停電検出してHDDに保存後電源断という事になるだろうね。
ただ、９CHを70マイクロ以内で同期というのは結構厳しいかもな。
９CH分のサンプルホールドを持ってて、ADC中安定してホールド出来なければいけない。
変換速度と、12ビット精度の両立は自分の知ってる範囲じゃ難しそうだ。
M16+PICでやる場合も、電源断を検出してM16の内蔵フラッシュにサンプリング中データを
書き込まなければいけないけど
M16のフラッシュ書き込みはバンク単位なのでPICの２５６倍高速なんで
電源断を検出して数10ミリ秒バックアップすればいいから、電解コンデンサでバックアップは十分。
406:デフォルトの名無しさん
05/01/04 14:38:06
まてよ。 10ビットADCのPICで１２ビット精度出そうとすると
差動入力にして1ビット稼いで、さらにノイズ混ぜての3回平均で
最小6サンプルしなくちゃいけないけど、 PICのADCは２０マイクロ必要だから
７０マイクロってのは厳しいな。
素直にADC外付けが無難か
407:デフォルトの名無しさん
05/01/04 15:30:49
パソコンのマザーボードは
・部品点数の多さと全体の配線の複雑さ
・部品信頼性の低さ （ほんとによく壊れる）
・接触部品が結構多い （ROM、CPUソケット、DRAMソケット、ISAやPCIボード）
ファンの存在がなによりも故障率を上げてると思える。
まずホコリが入るし、ホコリが入る事で放熱性が悪化するだけじゃなく結露時のショートを起こす。
次に自ら起こす振動。 ただでさえ多い接点を自ら振動させるんだから動作中の不良が起きて当然だ。
そして、パソコンのマザーは高温に弱いだけじゃなく、低温にも弱い。
もちろん、それでも利用出来るところはあるんだけどね。
408:デフォルトの名無しさん
05/01/04 16:16:06
＞４０４
＞M16の汎用ボード＋9個PICでチャチャとやっつけるな
それは何時間？
409:ライブラリアン
05/01/04 16:27:53
＞４０２
＞ホントに使った事あるのかな？
年間１００件くらいかな。
＞残念だけどパソコン品質じゃ
＞手組みで1枚だけ作ったボードに明らかに劣るよ
高級車のポルシェと大衆車のビッツはどちらが故障が多いと思う。
品質というのは数を作らないとでないんだよ。
それに２ギガのＡ／Ｄボードは手組みではつくれないだろう。
＞結局職人さんが生きてる限りはメインテナンス出来る方が
＞実は安心だったりするよ。
心情的には賛成だけど、ビジネスとしては広がりがない。
410:デフォルトの名無しさん
05/01/04 16:36:10
>>408
PICはこの場合適当でないと後で訂正してるけど、
うちの職人さんに頼めば、たぶん感光基板で半日もかからず作ってくるだろう。
M16は自分がCで書くからこれも30分もかからない。
というかコード使いまわして、クロック出してデータ貰う部分を９台分同時に変更すりゃいいだけ。
PICをADCに替えても、殆どコードも同じ。
なんなら今注文貰ったら明日午後には納品しまっせ。
たぶん、パソコン使ったって、ADC+UPSじゃ部品代に20万以上かかるでしょ？
そしてADCボードの入手に時間かかるでしょ？
で、プログラムはそのボード入手してからボードの使い方調べてになるでしょ？
トータル、うちと同じ値段じゃ出来ないと思うよ。
411:ライブラリアン
05/01/04 16:43:47
＞４１０
凄い、注文します。注文書の送付先の連絡頂戴。
その製品は使わなくても、その技術が欲しい。（笑
器用貧乏にならないように私がマーケテイングしてあげるよ。
412:デフォルトの名無しさん
05/01/04 16:58:05
>>411
はは、書けたらいいんだけどね。
凄いというけど、なんか自分の周りはそんな奴が多いんだが・・・・まあスキルミスマッチが起きてるのかもな。
器用貧乏はおっしゃる通り、職人さんも自分のとこも、なんだか忙しいばかりだ。
413:デフォルトの名無しさん
05/01/04 17:58:37
よくは知らんが、ラックマウントのPCは100万も出せば手に入る。
逆に言えば、10万のPCと同じ程度の性能なのにその金額になるのは保証と信頼故じゃないの?
414:デフォルトの名無しさん
05/01/04 18:17:40
市販されてるUPSの寿命は電池が2年、本体5年だよ。
もちろんそれ以上の期間動作させられるけど
メーカー的には上記の時間が経過したら
新品への交換を勧めている。
そういう機材だってことわかって言ってるのかな。
415:デフォルトの名無しさん
05/01/05 00:44:21
なんで PC = Windows みたいな話になってるの ?
別に Compact Flash かなんかに Linux でも入れて、メモリー上にファイルシステム作って、てきとーなデバイスにデータ書けばいいと思うんだが。
途中で電源切れたって、データ書くところさえちゃんとしてれば問題ないから、UPS なんか不要だよ。
416:デフォルトの名無しさん
05/01/05 03:48:44
知らないならハッキリ知らないと言いなさい、むしろ黙ってなさい
余計な事を言って手間増やされちゃたまらんよ
417:デフォルトの名無しさん
05/01/05 05:21:48
スキルに裏打ちされた議論で勉強になります。ののしりあいにならないのも珍しい
俺はハード屋さんが決めた仕様に従ってソフト書くだけだからなあ。
418:デフォルトの名無しさん
05/01/05 07:53:37
>>415
そのシステムで書き込み途中に電源落とされたらどうなるわけ？
419:ライブラリアン
05/01/05 09:39:03
＞４１３
＞ラックマウントのPCは100万も出せば手に入る。
＞逆に言えば、10万のPCと同じ程度の性能なのにその金額になるのは保証と信頼故じゃないの?
いわゆるＦＡ用のパソコンだよね。でもソフトを含めると信頼性は
それほど高くない。昔ＤＥＬＬのパソコンでラインのシステムを
作った。故障が無くて好評だった。リピートの時、調子に乗って信頼性をあげる目的
でＦＡ用のパソコン（金額で４倍くらい高い）に変えたら、まともに
動かなかった。メーカーのサポートは良かったけれども、顧客の信頼は
著しく低下した。そのような経験は何度もある。
やはり数が売れている方が信頼性が高い。
420:ライブラリアン
05/01/05 09:52:19
私も昔はマイコンでやっていた。
みなさんと同じことを言っていた。
しかしあることに気がついた。
それはハードが安ければソフトも安くなってしまうことだ。
「１０００円のＰＩＣに３００万円のソフトを入れました」
と言っても顧客は納得しない。
「１５０万のハードに１５０万のソフトを入れました」
と言えば納得してくれる。
つまりそういう心理的なことも性能とは関係のないところで
あるのです。
421:デフォルトの名無しさん
05/01/05 09:58:27
＞４１７
同意。大人の議論だ。
422:デフォルトの名無しさん
05/01/05 10:09:55
>>420
昔の話してどうするの。
いまではソフトが高いのは納得済み。
423:ライブラリアン
05/01/05 10:13:13
私はプログラマはあまり得意ではない。
離れて時間が経っているからね。
いまはＳＥという立場で顧客と話すことが多い。
よく次のようなことを自慢げに言う担当者がいる。
１ うちの会社は特殊なことをやっている
２ うちの会社はスペックが特別厳しい
３ うちの会社は予算がない
でもそれは違う。こちらの本音は
１ あなたの会社は特殊ではない。あんたが特殊なのだ。
２ それはあんたの好みの問題だ。
３ それはあんたが会社から信用されていなからだ。
424:デフォルトの名無しさん
05/01/05 10:19:25
…等と考えてるSEとは一緒に仕事したくないと言う本音も聞こえてきそうですね。
425:デフォルトの名無しさん
05/01/05 10:31:15
はい、したくないですー にゃんにゃん
426:ライブラリアン
05/01/05 10:34:33
＞４２４
そうじゃないんだな。ここからスタート
するということ。説明して、そのことに気がついてもらうんだ。
好きとか嫌いとか言うレベルではない。最終的に満足してもらう
ことが大事。
427:デフォルトの名無しさん
05/01/05 11:36:37
でもね。 パソコンで一丁上がりってやってると 数が出るリピートする商品が来ないんだよ
428:デフォルトの名無しさん
05/01/05 12:49:46
＞４２７
＞数が出るリピートする商品が来ないんだよ
そうなんだ。リピートはハードをお客が購入してソフトをコピーすれば
頼まなくてもいいからね。
だけど自分がお客でソフトのコピーを許している契約で
あればそうするよね。だからメンテナンス契約をするとかして
、少しはつながっているようにしないといけない。
429:379
05/01/05 14:07:43
>>420
>「１０００円のＰＩＣに３００万円のソフトを入れました」
>と言っても顧客は納得しない。
納得しますよ。
言いたいことはわかるそう考えたこともあるし、同じことをやった。
でも、頭をひねってむりやりパソコンで実現するより、素直に考えたほうがお客は納得する。
そして、パソコンベースで怖いのは、部品の故障
修理はメーカ送りだし、生産中止したらアウトで代替手段がマシン交換。
自社ハードだと、その心配がすくなくないか？
そして、パソコン系の開発環境はＯＳに依存するので
組み込みの開発環境の方が寿命がながくないかな？
ＱＮＩＸやLINUXでコマンドラインの環境ならいいけど
>>382
>反対にの１台しか必要なのに、マイコンで作るのか。
一品料理であっても、人工衛星に載せるのにパソコンは使わないでしょ
いいたいことはわかるけど、適材適所、臨機応変だと思う。
斬ったつもりだろうが、住んでる世界が狭すぎるよ。
430:379
05/01/05 14:10:02
「１台しか必要ないなら、マイコンでやらずにパソコンでできるケースは多々ある」
と言うなら、禿同だ。
なんでもかんでもマイコン、とか、１台ならなんでもかんでもパソコン
というのには賛同できない。
431:デフォルトの名無しさん
05/01/05 14:12:00
PCでやるのは実験機だけ。
一台しか必要ない場合というのを、実験機と混同しているのではないの？
432:379
05/01/05 14:17:14
連ですまないが
パソコンベースのデータ収録機を作ったとき
ＩＯボードの絶縁の問題で散々苦労したことがある。
こういうことがあると、自社ハードなら作り直しは簡単だが、
PCI/ISAバスのＩ／Ｏボードとなると、それだけで１作番になってしまう。
出来合いのものでつくると、出来合いの範囲でしか対応できなくなる。
こういうとき、お客に対して、どう説明する？
433:デフォルトの名無しさん
05/01/05 14:20:54
一台しか必要ないシステムなんていくらでもあるよ。
#つーか、2台目は仕様変更入るから同じにならないだけだけど。
私のところでは昔はメモリとOSの安定性からEWSを使っていた制御系の応用でも、
同じ金額で受注するならソフトに多く金額を割けるPCを使うことが増えた。
それにしても、制御系とは斯くも個々の事情が違うものなのだなぁと実感。
434:アルゴリズム
05/01/05 14:31:13
＞自社ハードだと、その心配がすくなくないか？
顧客の立場にたてばどうかな。よく制御系の会社は倒産する。
倒産した会社のマイコンシステムが壊れた、なんとかしてくれ
とお客から持ち込まれることがあるよ。「一品料理の
手作り製品はもうこりごり。だれもわからない。
スタンダードな規格で作ってもらいたかった」とこぼされる。
倒産だけではなく担当者もよく辞める。
担当者が辞めたら後は知らないではすませられないだろう。
そんな考えでは顧客の信頼を得られない。
自分だけの立場でものを考えてはだめだ。
要するに、顧客の立場でも考えるべきだ。
人工衛星に載せるシステムの案件はやったことがないけど、
それは別格で、そのときはマイコンとかパソコンにこだわる
ことはないだろう。そんな実績があるなら脱帽する。
435:アルゴリズム
05/01/05 14:36:32
＞４３０
先生それはそうですよ。円は楕円の特別の場合だから、
円も楕円と呼ぶべきだ。当然そうですよ。でもそう書けば話が
面白くないでしょう。
436:アルゴリズム
05/01/05 14:45:56
＞４３１
＞PCでやるのは実験機だけ
それが事実だ。実験機で用が済めばそれでいいだろう。
目的が達成できれば、それが実験機に分類されようと、どうでも
いいではないか。それはお客が決めること。
お客が満足すればＯＫ。
今まで議論を聞いていて、一番感じるのは自分の都合ばっかりで
お客がどっかに飛んでしまっていることだ。
437:379
05/01/05 14:57:24
>>434
>自分だけの立場でものを考えてはだめだ。
>要するに、顧客の立場でも考えるべきだ。
そんなのは当たり前の話だけどな、別に学校の講義を受けるつもりはないので（ｒｙ
逆に「スタンダードな規格」での不都合な点もいうべきではないかな
>>432 の場合なんか、どうする？
「スタンダードな規格」で納めたが、絶縁などの問題などが発生。
スタンダードだからあきらめろというのか？
>>430で言ったように、どれにもこだわってはいけないと思うが。
438:379
05/01/05 15:11:46
>>432
医療機器なんかの場合、高周波系と混在すると絶縁対策が原因で
暴走の危険性があるが、パソコンベースのシステムで対応できると思えない。
また、>>398のケースで、
強電界下での使用ということに対する暴走対策、
電源の断接でリセットスタートさせるがその応答を２秒以内
こういうことにパソコンベースのシステムで対応できるのか？
439:デフォルトの名無しさん
05/01/05 15:57:35
実験機がなぜダメなのかというと、実験のために関係ない部分まであちこちいじり
倒しているうえに、なんだか変なジャンプ配線ばかりだったり、場合によっては
ユニバーサル基板で作ってあったりして、とにかく信頼性が低い。
関係ある部分だけ抽出して試作品を作り、うまくいったらちゃんとした物をつくる、
ってしないと。
440:379
05/01/05 16:39:05
すくなくとも、
マイコンしかやったことがないからマイコンでとか
パソコンしかやったことがないからパソコンで
ＰＬＣしか（ｒｙ
という技術者にはなりたくない。
441:ライブラリアン
05/01/05 17:04:39
＞４７３
＞そんなのは当たり前の話だけどな、
＞別に学校の講義を受けるつもりはないので（ｒｙ
申し訳ない、偉そうに書いて。（笑
442:ライブラリアン
05/01/05 17:10:01
この話題をこれくらいにしてもっと面白い
テーマはないかな。
443:デフォルトの名無しさん
05/01/05 17:22:12
>>442
なんでお前が仕切ってるんだよ
444:デフォルトの名無しさん
05/01/05 20:14:25
>>434
パソコンだけじゃ制御の役に立たないでしょ？
何か入出力ポートが必要でしょ？
で、結局はその入出力ポートの実現の部分で スタンダードな規格 が無いんだよね。
だから、パソコンは標準であっても、納品したものは標準じゃないわけだ。
445:デフォルトの名無しさん
05/01/05 20:19:14
ラックマウント → FA というロジックは面白いと思いました。
446:デフォルトの名無しさん
05/01/05 20:48:57
俺が仕切ってやるぜ
447:デフォルトの名無しさん
05/01/05 22:29:51
アルゴリズムとライブラリアンは同一人物？
448:デフォルトの名無しさん
05/01/05 22:37:16
PC使う方に一票
なんかPCのボードが生産中止になったら・・・みたいな話が出てるけど
そういう心配はむしろ自社ハードにこそいえるのでは？
マイコンも周辺チップもどんどん新旧交代して修理しようにも互換品がない、
なんてこと結構ありがちだと思うんだけど。
あとソフトの価値が認められるようになってきているって意見があったが
これはむしろ時代に逆行した意見だろう。
ソフトの貨幣的な価値なんてむしろどんどん下がってきてるでしょ。
449:デフォルトの名無しさん
05/01/05 22:51:57
>>418
> >>415
> そのシステムで書き込み途中に電源落とされたらどうなるわけ？
ＦＡだとそこまで対策してるのは見たことないよ
取説に「書込中は電源を切らないでください」でおしまい
もしそこまで気にするならバックアップメモリやHDDも二重にするしかないんじゃないの？
450:379
05/01/05 23:59:08
>>448
>マイコンも周辺チップもどんどん新旧交代して修理しようにも互換品がない、
>なんてこと結構ありがちだと思うんだけど。
自社物だと、DISCON品がどこかにあってなんとか対応できるが
メーカ物は、電源ユニットひとつでも終わったらホントにおしまい。
451:デフォルトの名無しさん
05/01/06 07:51:16
>>448
PCのボードってI/OとかADC/DACの事だよね？
リスクとしてはこっちの部品がが無くなる事と等価だよ。
それ以上に、他社である分それが起きた時の問題は厄介だ。
ようは対応出来ない。（対応出来ない事を利用に新規にしちゃうワザもあるだろうけどね）
たぶん、PCのボードを勧める人は 今1チップマイコンの内蔵RAM・フラッシュがどれだけ
あるか、そして、どれだけ簡単か知らないんだろうと思う。
URLﾘﾝｸ(akizukidenshi.com)
URLﾘﾝｸ(www.oaks-ele.com)
みたいな所からボード買って勉強してみればいい。
外付けにフォトカプラなり、オペアンプなりをつなぐだけで大抵のシステムは完成だ。
パソコンを使うなら、これをRS232CやLANで接続すればいい
まあFAで使うような場合は、そんなボード使わなくてもシーケンサ＋パソコンで間に合うのも事実だけどね。
452:デフォルトの名無しさん
05/01/06 12:40:32
>>451
あははー ゆかいゆかい
453:ライブラリアン
05/01/06 12:41:20
＞４５１
ＯＡＫＳは思い出した。ありがとう。
自分もアマチュア精神が旺盛なので、こんなのをみると
結構ワクワクする。ただビジネスで考えると
また違う考えだけどね。
ワンボードマイコンを使う機会は無いことはない。
お客がどうしてもと言えばそうする。
ただＣＰＵの種類が多すぎるので勉強して使う
のにリスクが多い。
＞FAで使うような場合は、そんなボード使わなくても
＞シーケンサ＋パソコンで間に合うのも事実だけどね。
そうなんだ。実はこれは優れたソリュウションなんだ。
シーケンサはイーサネットでパソコンのＩ／Ｏボードの代用だ。
プログラミングはしない。シーケンサーは
ノイズに強いし売れているメーカを使えば、安心。
原子力関係では制限があるようだけど。
さらに仕事の終盤になると安全性の対応でプロテクトをかけたり、
非常停止の問題がでてくる。
それはシーケンサのプログラムだけで簡単に
対応できる。
454:379
05/01/06 14:15:57
>>453
>ただＣＰＵの種類が多すぎるので勉強して使う
>のにリスクが多い。
それほど大変じゃない。
H8で作ったシリアルやタイマーなどのルーチンは
そのままSH1やSH3で使えるほどファミリーは同じようなアーキテクチャーになっている。
ＰＬＣ(シーケンサはミツビシの商標ね)の場合
モデムで発呼とか端末側起動のシリアル通信が面倒じゃないだろうか？
っていうかできるのか？
455:379
05/01/06 14:32:05
引用ばかりですまんが
>>451
>それ以上に、他社である分それが起きた時の問題は厄介だ。
>ようは対応出来ない。（対応出来ない事を利用に新規にしちゃうワザもあるだろうけどね）
実際、そういうことが多い。
むりやり、パソコンでやろうとする姿勢はどうも賛同できない。
部品点数が多いだけでも信頼性に問題があるとおもうし
振動試験や絶縁試験にも合格すると思えない。
それだけ適応が狭くなる。
というか、そもそも ライブラリアン氏は、そういうケースの仕事はあまり多くない？
どうも、私の世界と違うように感じる。
456:デフォルトの名無しさん
05/01/06 14:49:39
まあ、用途によるってこった
457:デフォルトの名無しさん
05/01/06 15:29:30
>>454
そういうのは一度作っちゃえばパソコン側はそれでOK
自分はパソコン関係はDelphiで作ってるから、通信部分をコンポーネントにしてて
再利用はポトペタ一発だ。
458:379
05/01/06 18:21:38
>>457
いや、端末側起動といったのは、
ＰＬＣからモデムをコントロールしたりということ
459:デフォルトの名無しさん
05/01/06 19:27:05
どこで質問すればよいのか分からなかったのでここで教えてください。
論理回路のことなんですが・・・
2進数どおしの加算は半加算回路・全加算回路で出来ます。
積算はどうやってするのですか？
ＨＥＬＰ ＭＥ～
460:デフォルトの名無しさん
05/01/06 19:47:41
もっとも簡単な10進カウンタを作る
URLﾘﾝｸ(tamuro.gooside.com)
URLﾘﾝｸ(tamuro.gooside.com)
461:デフォルトの名無しさん
05/01/06 20:01:41
>>459
積算という事は、
加算した結果を覚えておく手段（ＦＦとか）と加算器で出来るでしょ
462:デフォルトの名無しさん
05/01/06 20:26:21
boothでググれ。
463:デフォルトの名無しさん
05/01/06 21:20:32
>>458
そういう時はBASIC Unit(オムロンでいうASC Unit)なんかを使うんじゃないですかね。
464:デフォルトの名無しさん
05/01/07 05:49:52
誰か知っていたら教えてください。
PC系のボードを使って、PCIバスに制御用のカードをさしています。
カードに載っているデバイスへのアクセスは32bit幅限定。
ByteEnableの信号が無いらしく、byteやwordで書き込みすると、
他のビットが化けてしまいます。
このデバイスのレジスタマップは、
現在、ビットフィールドの構造体で定義されていて、これを流用したのですが、
コンパイラ(GCC)がビット操作をbyte単位で行うように
コンパイルしてくれて、困っています。(アセンブラ展開見て確認)
ビットフィールドってANSIではintでしか使えないはずだから、
当然32bit幅でアクセスするようにコンパイルされると思っていたのですが…。
コードの記述やコンパイルオプションの設定とかで、
何とか32bitでリード/ビット変更/ライトするようにコンパイルできないんでしょうか?
あ、もちろんレジスタのアドレスは4バイト境界になっています。
マクロ使ってビットアクセスを定義しなおすのは
かなりの量のレジスタがあり、コードもかなり変更しなければならなくなるので、
なるべく避けたいです。
同じような経験された方いますか?
465:デフォルトの名無しさん
05/01/07 11:00:51
ダミーのビットフィールドを入れて無理やり32bitにするのは駄目なの？
466:デフォルトの名無しさん
05/01/07 12:11:15
>>464
普通はそういう経験はしない。
理由はメモリマップ式のI./Oはめずらしいし
メモリマップ式でも、PCIバスだと普通のメモリに比べて遅いから普通のI/Oと同じように
読んで書く方式にするから
467:デフォルトの名無しさん
05/01/07 18:53:20
>>464
具体的な情報がないのでなんともいえんが、
bitfieldが本当に32bitサイズの型で宣言されていて、かつvolatile修飾されているのであれば
gccのバグだろう。そうでなければそれは仕様。
468:464
05/01/07 19:33:36
>>465
もちろん、ビットフィールドはダミーも入れて
きっちり32bit単位で全部埋まってます。
int(32bit)変数とのunionにしてあります。
で、たとえば、アドレス0の32bitレジスタのbit8に1をセットするような場合、
コンパイル結果を見ると、
アドレス1をバイトでリード/bit0を変更/ライトするコードが吐き出されているわけです。
アドレス0を32bitでリード/変更/ライトしてほしいのに。
>>464
やっぱりそうですよね。
RAM領域も持っているデバイスなのでメモリにマップされています。
マクロで定義しなおすしかないか・・・
469:デフォルトの名無しさん
05/01/07 20:36:06
ｇｃｃの仕様として有名な話ではないの？
「ｇｃｃ使う場合、日立ＳＨのサンプルソースはそのまま使えない。
理由は日立のサンプルがビットフィールド使ってるから」
みたいなのをインターフェースか何かで読んだことあるぞ
470:464
05/01/07 20:43:16
>>469
そうだったのか。
サンクス。
471:デフォルトの名無しさん
05/01/07 20:48:06
>>470
確か↓の本に書いてあったと思う。今手元に無いんで未確認だが
URLﾘﾝｸ(www.cqpub.co.jp)
472:デフォルトの名無しさん
05/01/07 20:50:51
gccでビット操作するとき、鬱陶しくなるようなマクロをよく使うよね。
移植性を高めた結果、問題の起こりやすいビットフィールドなんか
使ってられるか、ってことなんだろうね。
473:デフォルトの名無しさん
05/01/07 21:31:07
>469
gcc3以降だと大丈夫じゃないか？
474:デフォルトの名無しさん
05/01/07 21:33:56
>>473
ごめん、そこまで詳しくは知らない
475:デフォルトの名無しさん
05/01/07 22:02:31
そういうのはasmを使えば簡単で確実。
GCCのasmはCとのインターフェースも簡単なんだからさ。
(C++ならうまくクラスを作れば、ソースを変えなくてもできるかもしれない。
まったくお薦めしないが)
Cのレベルではアクセス幅なんて決まってないんだから、ビットフィールドの幅を
どうしようとアーキにあわせた最適な幅でやっちゃうんじゃない？
それもI/Oなんかつながって無いつもりで。
で、GCCのその辺の設定は、mdファイルに書いてあるはず。
476:デフォルトの名無しさん
05/01/07 22:08:32
処理系の影響を受けない様にビットフィールドではなく
論理演算を使ったり、展開を読むことも考慮して可読性を高める様
に書く様にしている俺はチキンでしょうか？
極端な話、
a++;
ではなく
a=a+1;
と書きます。これならコボラーが入ってきても対応できる可能性があるからね。
展開効率を上げるのはコンパイラの仕事だしい・・・・・・
477:デフォルトの名無しさん
05/01/07 22:14:38
>>476
a++も理解できないコボラーに対応させることの方が怖い。
そのレベルだと、strcmp()使わずにポインタ同士を比較しかねないぞ。
478:デフォルトの名無しさん
05/01/07 22:20:45
展開を読むってなに？
ビットフィールドはコンパイラと心中するつもりでないと使わないよな。
479:デフォルトの名無しさん
05/01/07 23:39:08
>>469
> 「ｇｃｃ使う場合、日立ＳＨのサンプルソースはそのまま使えない。
> 理由は日立のサンプルがビットフィールド使ってるから」
？
日立のＨＰからダウンロードできるヘッダファイルのこと？
たしかにビットフィールドばんばん使っている。
でも、これがＨＥＷ以外で困るのは、
ビットフィールドの並びが普通と逆だからじゃなかったっけ？
480:デフォルトの名無しさん
05/01/07 23:45:35
>>479
逆だとしても、468の問題とは別だろ
481:デフォルトの名無しさん
05/01/08 00:40:39
>>479
ビットフィールドをバイトアクセスに展開してしまうｇｃｃの処理を問題にしていたと記憶してます。
本で読んだだけで、自分で試したわけじゃないです。
482:デフォルトの名無しさん
05/01/08 01:05:37
●5月7日
ん? この割り込みプログラム、これでほんとに動くか?? と、うちのRISCキットを使ってテスト…
なんてしてるから、単行本の編集作業が終わらんのだよ(^^;)
ん～そうか、日立純正Cコンパイラはビットフィールド演算してももとのレジスタサイズでアクセスされるのか…
それでこのソースうちのぢゃ通らないんだなぁ～などと納得。
URLﾘﾝｸ(www.cqpub.co.jp)
483:379
05/01/08 01:29:43
>>464
1999年8月1発行、Ｉｎｔｅｒｆａｃｅ増刊TECHI
「ＳｕｐｅｒＨプロセッサ(SH-1/SH-2/SH-3/SH-4のハード＆ソフト完璧マスタ)」
P169：コラム１「日立純正Cコンパイラとｇｃｃ」より引用
ｇｃｃは非常によくできたコンパイラです（一時は、日立純正Cコンパイラより断然性能がよいと言われた頃もあった）。
しかし、ｇｃｃをSHシリーズで使用する場合には注意する点があります。それは周辺機能レジスタに対してビット名を使用したアクセスを行わないようにすることです。８ビット以外のレジスタ内容の参照や変更が出来ません。
（以下略）
484:デフォルトの名無しさん
05/01/08 01:53:44
>>483
乙彼
まさにその記事のことですわ
485:464
05/01/08 05:40:40
レス、サンクス。
結局マクロで組みなおすことになりました。
486:デフォルトの名無しさん
05/01/08 07:43:58
しかしそんな有名なバグがなんで直ってないんだろう。
487:デフォルトの名無しさん
05/01/08 07:52:46
>>486
この場合、バグは、I/Oなのにメモリマップにして、しかもバイトアクセスに対応しない自分勝手なボードの方だろう
488:487
05/01/08 07:59:07
さらに言うと、ビットフィールドをI/Oアクセスで利用しようという設計で
コンパイラを変更しようとしている甘えにも問題がある。
ワンチップマイコンでは強力なビット操作命令（I/Oにおいて特に有効な）をCから手軽に
利用出来るようにと、ビットフィールド関係を最適化して使いやすくした 専用Cコンパイラを
提供してくれている場合がある。
その場合、1ビット単位のI/O操作は当然ビットフィールドを使うのだけど、
それの方式が一般だと思ったり、移植可能と思っちゃいけない。
汎用性を考えるなら、ビットフィールドをそこで直接書かずに、マクロで抽象化してしまう事だ
489:デフォルトの名無しさん
05/01/08 08:21:31
>>487
この例は
デバイスがバイトアクセスに対応してないし、
そもそもメモリマップI/Oしか選択肢のないプロセッサの場合の話だと思うが
490:デフォルトの名無しさん
05/01/08 11:05:10
ｇｃｃのバグではない
純正コンパイラが機能拡張させてるだけ
491:デフォルトの名無しさん
05/01/08 11:32:09
>>489
> デバイスがバイトアクセスに対応してないし、
だから、“PCIバスに接続された制御用カード”のバグじゃん
492:379
05/01/08 16:30:19
>>487
>I/Oなのにメモリマップにして
って、モトローラ系はもともとそうだとおもうけど
３２bitでアクセスできないわけじゃなくビットフィールドが対応していないだけでしょ？
493:487
05/01/08 18:24:19
じゃI/O空間が無いCPUは絶対にI/O空間を使うPCIカードが使えないのか？
というとそんな事はないわけで、それぞれ使えるように工夫するものだし、そうじゃなければ逆に困るだろう。
I/OはやはりPCIバスのI/O空間に割り当てるのが正しい作法だろうと思うよ。
わざわざPCIのメモリ空間に割り当てたなら、バイトでアクセスしようが対応しなくちゃダメだろ。
という話。
VRAMがRGBにわけてバイトでアクセスさせたらダメなんて事になってたら、ムカつかないか？
494:デフォルトの名無しさん
05/01/08 19:11:54
コンパイラは純正使ってれば間違いありませんし、高機能なものは無料
では手に入りません。あなた方の商売道具なのですよ？
_, ,_ ∩
( ﾟ∀ﾟ)彡☆ ソレミタコトカー
⊂彡
495:464
05/01/08 19:12:13
なんか、いろんな論議に発展してるな。
特殊用途の通信チップなのです。
アドレスの前半がレジスタエリアで、
後半数ｋバイトがバッファRAMエリア。
通常は32bit単位でしか使わないような仕様です。
もともと組み込み用途なので、
SHとかに接続するように設計されているチップみたいでした。
496:デフォルトの名無しさん
05/01/08 23:13:31
SHCなら、volatile修飾すればビットフィールドは宣言型サイズ（int b0 : 1;なら4バイト）で参照されるな。
H8Cなら、evenaccess。
gccも何かないの？ 最適化をoffにするとか。
497:デフォルトの名無しさん
05/01/09 04:21:19
すまん
HEWも癖があるけど、
これ、やっぱり結局gccのバグなんだよな？
498:379
05/01/09 04:53:50
>>493
SHは、メモリマップドI/Oなんだけどな。
そういうことを話してるのとは違うのか？
PCIカードだろうがなんだろうが、メモリ空間にマッピングされるのが気に入らないのか？
ビッグエンディアンも気に入らない？
499:デフォルトの名無しさん
05/01/09 06:50:22
>>497
> これ、やっぱり結局gccのバグなんだよな？
バグ、バグ、って正直ウザイよ,オマエ。
所詮Cじゃバスアクセスの幅は規定されないから、
処理系依存は当然だ。それを使いこなせないなら
その人間がアホなだけ。
500:487
05/01/09 07:40:38
>>498
それはCPU側から見た話で、PCIカードのI/O空間をCPUのI/O空間にどう割り振るかとは別の問題だろう。
・CPUにI/O空間が無い⇒だったらPCIカード側もI/O空間を使わない方が楽だろ？
みたいな考えじゃないの？
だったら既存のPCIカードでI/O空間を使ってるものを全て使わないつもり？
501:487
05/01/09 07:55:30
そういや、少し前のC++Builderで バイト(char)でビットフィールド定義してたら
なんか1ビット不連続になってた事があったな。
確かにバイトでビットフィールド使うのはCの規格の範囲じゃないけど
あるコンパイラでバイトで定義するとそこを最適化してくれるものだから、使ってて、
それをC++Builderでデバッグしようとして、どつぼに嵌っちゃった
まあ、ビットフィールドには気をつけろってこった。
502:デフォルトの名無しさん
05/01/09 15:11:02
>>501
問題はビットフィールドでアクセスすると
「バイトアクセス命令に落ちる」ってことなんじゃないのか？
ｇｃｃのバグというより処理系依存で作りこまれたバグとしか思えん
I/Oにビットフィールドきっても、実際にI/Oに設定に行くときはunion
使うなりなんなりしてレジスタサイズ丸々writeするけど。
MemoryMappedI/Oで利きもしないBit操作命令になんかに
落とされちゃたまらん。
503:デフォルトの名無しさん
05/01/09 15:57:55
ビットフィールドってAND ORもわからんアプリ屋が使うものだとばかり思ってた
・・・・・メリット、デメリットを計りにかけて設計・実装してますか？
504:デフォルトの名無しさん
05/01/09 16:07:02
>>503
出来上がるコードの違いわかってますか？
505:379
05/01/09 16:18:29
>>500
>だったら既存のPCIカードでI/O空間を使ってるものを全て使わないつもり？
PCIカードはいままでどおり勝手にすればいいのと違うか？CPUは、メモリマップするだけのこと。
すまないが、それが、ビットフィールドの不具合とどう関係するのか
漏れの不勉強な部分もあって、わからん。
もともと、ビットフィールドは使わないし。
どうせ、何ビットでアクセスしなきゃいかんのか意識しなきゃならないし
後で見て、どう定義されているか確認するのは避けられないから
直接、AND ORして、わかるようにコメント書いておしまいにしてる。
506:デフォルトの名無しさん
05/01/09 16:19:53
すべては仕様ですから～残念！
507:503
05/01/09 16:21:47
>>出来上がるコードの違いわかってますか？
全部、とは言いませんが、初めて使うコンパイラなんかだと、色々試して
アセンブラの展開を読んでからコーディング規約を作ってるけどね。
int , unsigned intの差とか、charの扱いとか、引数の渡され方とか、auto変数の
レジスタアロケートルールとか。etc etc
俺は>>476でもあるが、a++;とa=a+1;では、多くのRISCチップ様コンパイラでは同じ
展開になりますよ。
508:デフォルトの名無しさん
05/01/09 20:11:34
あーやっぱり>476は判ってない困ったチャンだったのか。
509:デフォルトの名無しさん
05/01/09 20:21:16
long *a = (long*)0;
long *b = a;
a++;
b=b+1;
if(a != b){
printf("残念！");
}
510:デフォルトの名無しさん
05/01/09 20:31:12
>>502
バグはおまえの頭。
>>507
a++とa=a+1が同じだったら、a++の方が分かりやすいだろう。
あと、生成コードの癖はちょっと見ただけであたりを付けるとはまるよ。
コンパイラが保証していないことを独自に保証するには、相当の覚悟がいる。
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
＞チャタを確実にキャンセルできるかどうかはチャタが持続する時間より
＞サンプリングの周期が長いかどうか、それだけで決まる。
正解
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乗分の１に下げる方が余程実用的で
なおかつ実際に問題が発生しない実装になるわけだ