制御系なら俺に聞いてもいいぞ（２）

「さっきの打ち合わせで、全ポートプルアップやめてプルダウンにしたから」

なんだよそれ

>>935
うわ。。。。。いっそ論理逆転させられた方が楽かも。

つーか、俺なら「だったら論理逆転させろやこら(怒)」と言う。

で、ＩＮ/OUTさせるところで反転いれて主要ロジックに変更なしでｳﾏｰ
ってのは良くやったな。

H/W屋からすると、バッファの種類を変えるだけだったり、
PLD内のラッチの出力を引っ張りだす場所を変えるだけだったり
意外と受け入れられ易かったりする。

937 ：デフォルトの名無しさん：03/07/13 23:13

>>936
結局、ファーム屋っつーポジションは
ソフトもハードも押さえなきゃならんってことだね

938 ：デフォルトの名無しさん：03/07/13 23:25

>>937
リリースの遅れや動作不良はうかうかしてるとソフト屋側に被せられかねない
ハードのチェックぐらいできないとやられてしまう

939 ：デフォルトの名無しさん：03/07/14 01:22

余っているポート使って（無ければ無理矢理こじ開けて）ログ確認用の
printfの自作ぐらいできないと勤まらないのがこの業界だからな。
少なくともどんな構成でハードが動いているかぐらい判らなければ
つとまらんよ。

940 ：919：03/07/14 05:53

>>920 最初の１，２個それやってから(´∀｀)、
セクタ毎のハードプロテクトかけるようにしました。

941 ：デフォルトの名無しさん：03/07/14 08:16

>>920
デバッグ用の基板って、ROMが外付けでソケットになってたりしないの？

>>939
俺、printfは作れません。。。

942 ：920：03/07/14 13:13

>>941
１～２時間で終わる位の修正だったので、その辺に置いてあった基板を使っていたのですよ。
で、しばらく触っていなかったので、手順を間違えたことに気が付かないで…

片手間で終わらせるつもりが、大仕事になってしまいました(w

943 ：デフォルトの名無しさん：03/07/14 16:26

>>941
printfは7行スレに簡易的な奴が落ちてたよ。
基本的にデバッグ用としてなら必要十分だったから
使わせてもらってるよ

944 ：デフォルトの名無しさん：03/07/14 16:42

◎無修正画像をご覧下さい◎２日間無料です◎
★http://yahooo.s2.x-beat.com/linkvp/linkvp.html★

945 ：デフォルトの名無しさん：03/07/14 19:02

ソフト（マイコンプログラミング）とハード（HDLによるRTL）もやっている人はいないの？

946 ：デフォルトの名無しさん：03/07/14 19:06

俺はstdio.hもincludeしないが、なにか？

947 ：デフォルトの名無しさん：03/07/14 20:26

>>936
基本的に入出力は独立させとくのは、もはや常識だと思うが。
別に、制御系に限ったことじゃないと思うし。

>>946
この世界じゃ、別に珍しいことじゃないと思うけど。

この世界じゃなくても、Windows プログラムなら stdio.h なんかインクルードしてないのが普通だし。

948 ：デフォルトの名無しさん：03/07/14 21:48

>>947
何も考えずにメモリマップ度I/Oをそのままビット演算しちゃうなんて
初心者にはよくあることです。
おかげで申告できない残業が増えるんですよ。

なに、泣いてんの？笑ってんの？

りょーほー

949 ：デフォルトの名無しさん：03/07/14 22:01

stdrom.hなら。
SHのHEW使いから、LSIC-86使いに戻りますた・・

>>945
それなりにいそうだが。
折れは、趣味ではHDLいじってる電子工作好きのｿﾌﾄ屋でつ。
でも、仕事じゃなぁ～。いまはASIC起こすことがほとんどなくなったし・・・

950 ：デフォルトの名無しさん：03/07/14 22:52

>>947-948
メモリマップドI/Oをそのままビット演算するのがいけなくて、
入出力は独立させておくのが常識というのがよくわからないのですが。

書き込み専用のI/O（出力）を、リードしてしまうとか、その辺のことですか？

951 ：デフォルトの名無しさん：03/07/14 23:00

>>950
メモリマップドI/Oを彼方此方で読む
　→処理中にI/Oの状態が変化した場合、ヤバイことになること多し

　H/Wとのインタフェースは余程特殊な場合を除いて、
独立したモジュールで一括処理するのが無難

　腐ったH/WでReadしながらタイミング見計らって
叩いてやらなきゃいかんような場合は例外

952 ：デフォルトの名無しさん：03/07/14 23:23

>>951
> メモリマップドI/Oを彼方此方で読む
> 　→処理中にI/Oの状態が変化した場合、ヤバイことになること多し

なんか話がずれてるような気が...、ハードウェアアクセスの所ってハードの都合で変更されたりすることがあるから、一箇所にまとめておけば修正が楽って言う話じゃないの ?

処理途中で値が変化するとか言うのはまた別な話だと思うが。

953 ：デフォルトの名無しさん：03/07/15 00:09

>>951
> メモリマップドI/Oを彼方此方で読む
> 　→処理中にI/Oの状態が変化した場合、ヤバイことになること多し

これは、タイミング的な話しで、ダイレクトにI/Oを読んでいると、
処理の途中で、I/Oの状態が変化すると、処理に一貫性がなくなるので、
処理の中では、読むところを一カ所に固定して、その値を内部のレジスタに取り込んで、
そのレジスタ値を処理の対象にせよ、ということだね。

>>952
＞ハードウェアアクセスの所ってハードの都合で変更されたりすることがあるから、
＞一箇所にまとめておけば修正が楽って言う話じゃないの ?

これは、プログラムの構造の話しで、あちこちにI/Oアクセスを散らばらせるのではなく、
一カ所に関数（一種のデバイスドライバ）化しておいておけば、その関数を修正すれば済むので、
柔軟に対応ができる、ということだね。

954 ：山崎渉：03/07/15 09:38

　__∧＿∧_
　|（　　＾＾）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣

955 ：デフォルトの名無しさん：03/07/15 11:01

波形やタイミングによっては、チャタリング防止とか入れるし、
１モジュールにした方がその後は修正しやすいし。

956 ：デフォルトの名無しさん：03/07/15 13:38

板の動作チェックも兼ねてるからI/Oルーチンから出来上がるｗ

957 ：山崎渉：03/07/15 14:02

　__∧＿∧_
　|（　　＾＾）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣

958 ：デフォルトの名無しさん：03/07/15 20:22

>>956
漏れもそうだな。
テストプログラムが発展して本番プログラムのI/Oモジュールになる。

こういうのも他に流用出来るといいんだけどなーと思いつつ、毎回作ってるが。

959 ：デフォルトの名無しさん：03/07/16 02:11

そろそろ次スレを誰か立てて・・・

960 ：デフォルトの名無しさん：03/07/17 19:52

すみません、教えて下さい。

機器でSRAMカード（ATAじゃなくて、ただのSRAMカード）をメモリとして使ってます。
WindowsでSRAMカードの内容を読みたいのですが、どうすれば良いのでしょうか？

961 ：デフォルトの名無しさん：03/07/17 22:37

>>960
げろ。
まるち野郎なんかに答えてやるんじゃなかった。

962 ：デフォルトの名無しさん：03/07/17 23:13

>>961
こことマルチしたくなるようなスレあったか？

>>959
このペースならもっとギリギリ（９８０位？）でもいいんじゃない？
２，３日レスつかないこともしょっちゅうだし

963 ：デフォルトの名無しさん：03/07/22 16:01

JEIDAから規格書買え

964 ：デフォルトの名無しさん：03/07/22 16:18

>>963
旧JEIDAと旧EIAJ（社団法人日本電子機械工業会）は
2000年11月1日付けで統合され、
JEITA（社団法人電子情報技術産業協会）となりました。

965 ：デフォルトの名無しさん：03/07/22 19:46

すまん。うちにある仕様書がJEIDAのものだった為……

966 ：デフォルトの名無しさん：03/07/24 04:44

組込み制御分野でオブジェクト指向（C++)で開発した人いますか？
何か良いことありました？

967 ：デフォルトの名無しさん：03/07/24 04:52

>>966
Javaでならあるけど。
PC上で組んだコードがそのまま使える
ので開発はめちゃ楽。
メモリ制限めちゃ厳しいけど。

968 ：デフォルトの名無しさん：03/07/24 09:58

>>966
C言語にC++を足す形にしたので、
C言語用に関数インターフェースをプラスする羽目になった。
が、計算クラスみたいなのを用意しとくだけでパラメタの保持から計算まで１クラス＝１ファイルに収まったので開発が破綻から免れた。
C言語部分は改変という形で、完成はしてるけど、
巨大なスイッチ文で破綻したコードのような気がする。

969 ：デフォルトの名無しさん：03/07/24 12:46

すんません、質問です。
SH4(SH7750)でSCIFの信号を読みたいんですが、どのレジスタを読んだらいいですか？
TxD/RxD/CTS/RTSは普通に読めるけど、それ以外はどうすれば……

970 ：デフォルトの名無しさん：03/07/24 15:02

>>969
ハードウェアマニュアルを見れ。FIFO付きシリアルインターフェースの項じゃ。

971 ：デフォルトの名無しさん：03/07/24 17:44

>>966
データを操作している人がわかりやすい
多態によって似たようなスイッチ文がへらせる。

972 ：デフォルトの名無しさん：03/07/24 21:13

>>967
めちゃくちゃ言うな。
J2SE用のｺｰﾄﾞがそのままうごくわけ無いだろ。

973 ：デフォルトの名無しさん：03/07/24 22:44

組込み系でオブジェクト指向（C++)で開発した場合、
生成されるオブジェクトはどこに割り当てられるの？
スタックですか？

974 ：デフォルトの名無しさん：03/07/25 01:02

>>972
動くんだよそれが

975 ：デフォルトの名無しさん：03/07/25 19:56

>>974
972じゃないけど、MIPS32 4KSdのJava Card対応っていうのは
本当にバイトコードが動くってことなの？
それとも、違う石なのかな？

976 ：デフォルトの名無しさん：03/07/25 22:35

>>973
構造体と同じ。
newした場合は普通ヒープ。

977 ：デフォルトの名無しさん：03/07/26 15:42

>>976
ヒープにとられるとなると、あまりオブジェクトを作って消してを繰り返せば、
ヒープが虫食いだらけになるね。
なんかC++は使いにくそう。

978 ：デフォルトの名無しさん：03/07/26 16:10

組み込みでC++使うのにnewの多用はまずいだろ

979 ：デフォルトの名無しさん：03/07/26 19:06

>>977
そんなのはガベージコレクションが有れば無問題。
ガベージコレクションのオーバーヘッドが問題になるようなら使えないが、
そういうときはヒープを使わないプログラミングをする破目になるかもな。
ま、べつに動的に生成/消滅しなきゃオブジェクト志向でないってわけでもあるまい。

980 ：976：03/07/26 20:01

>>977
newをオーバーライドして自前でアロケーションすればOK。
めんどくさいけどね。
ガベコレよりはこっちが主流じゃないかな。

でも、めんどくさいのとバグが入りやすいので
基本的には978氏に賛成。

981 ：デフォルトの名無しさん：03/07/26 20:17

可愛い娘たちが貴方を癒します・・・☆
http://yahooo.s2.x-beat.com/linkvp2/linkvp2.html

982 ：デフォルトの名無しさん：03/07/26 22:31

>>972
java.longのSystemやStringなどなど、基本的なものもない。
ガベージコレクタも実装されてない。

>>975
簡単な命令は動く。複雑な命令はソフトで実行。
速度を出すためにスタック操作をハードウェアで。

「まるごと図解最新組み込みJAVAがわかる」読んでみてください。

983 ：975：03/07/27 00:09

>>982
その本のJava Cardの部分を今日立ち読みしたんだけど、
いくつかのチップで動くみたいですね。

「インターフェース３月号ICカード特集」では
ファイル変換するようなことが書かれていたので、
実際に動くかどうかは、まだ半信半疑ですが(^^;

近いうちに現物が見れそうなので期待してます。

984 ：デフォルトの名無しさん：03/07/27 00:40

invokevirtualとかは当然ソフトウェア命令に展開されるんだろうな・・
結構遅そう

でもgcがないってことはメモリ管理はどうするんだろ