5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

組込み系とオープン系プログラマーの激烈差

1 :仕様書無しさん:03/10/18 18:47
これぞ組込み系のコードっての書いてください。
単にアドレス見てってビット立ててもいいです。下っぽいコードでもいいです。
制御系PGとオープン系PGの違いってなんすかね。

void funcbiton(char* ch)
{
ch|=1;
}

2 :仕様書無しさん:03/10/18 18:49
Cとか言ってるレベルでなあ

3 :仕様書無しさん:03/10/18 18:51
>>1
そんな関数、何に使うんだ?

4 :仕様書無しさん:03/10/18 18:54
>>1
それが組み込み系のコードか(藁

5 :仕様書無しさん:03/10/18 18:54
俺が必ず先に一度定義しておく関数

function Int32x32Div(X, Y, Z: Integer): Integer;register;//X*Y/Z
asm
IMUL Y
IDIV Z
end;


6 :仕様書無しさん:03/10/18 18:56
>>3
何の意味もないよって意味では?

7 :仕様書無しさん:03/10/18 18:59
たしかに、もれが見慣れてるコードとは空気が違うな。
ビット演算を使うこと自体がほとんどないっす。
ていうか、フラグをビットとして実装するということがなーい。

8 :仕様書無しさん:03/10/18 19:00
mov EAX,w2;  // p=127 τ=63
rcl EAX,1
rcl w3,1
mov EDX,w0;
mov EAX,w1;
SHLD EAX,EDX,2
XOR EAX,w3
mov Result,EAX


9 :仕様書無しさん:03/10/18 19:03
組み込みで86使う機会は少ないと思うんだがどうよ

10 :仕様書無しさん:03/10/18 19:06
>>9
それしかしらないんだから仕方ないだろ

11 :仕様書無しさん:03/10/18 19:06
こんなので書き直せば満足か?

MR1=DM(I5,M5);
MR0=DM(I5,M4);
SR= LSHIFT MR1 BY 1(HI);
SR=SR OR LSHIFT MR0 BY 1(LO);
AY1 =DM(I5,M5);
modify(I5,M4);
AR=SR1 XOR AY1;


12 :仕様書無しさん:03/10/18 19:19
>>7
APIやVBなんかでもビット演算は使うんだが。
たとえばVBのForm_KeyDown(KeyCode As Integer, Shift As Integer)のShiftは
vbShiftMask 1 Shift キー ビットを取り出します。
VbCtrlMask 2 Ctrl キー ビットを取り出します。
VbAltMask 4 Alt キー ビットを取り出します。

13 :仕様書無しさん:03/10/18 19:37
定義さえきちんとやればコード自体はオープン系も組み込みもそう変わらんだろ。
メモリの制約やスピード重視のためにあえて汚いコード書いたりすることはあるけど。


14 :仕様書無しさん:03/10/18 21:18
static unsigned char p11_on = 0;

/* メインループ所属関数 */
void push_button()
{
 if ( !tm_100ms ) /* 100msポーリング */
  {
   Set_Tm_100ms(TM_CLEAR); /* タイマクリア */
   if ( p11 && p11 && p11 ) /* ポート11 ON検出 */
    {
     if ( p11_on++ > 3 )    
Button_On();
    }
else p11_on = 0;
  }
}

15 :仕様書無しさん:03/10/18 21:29
>>10はx86なのか?
漏れも>>9とおなじ印象をもってるんだが。

16 :仕様書無しさん:03/10/18 21:44
>>14
それはヘタなやり方だとおもうがなあ
20〜35msポーリングで 2度同じなら、そのビットを採用するのが王道だろう。
void portin(void)
{
static int port=0;
static int old=0;
int w=INP( port11);
port ^= (port ^ w) /*この間を書いてごらん*/ (w ^ old);
old=w;
return port;
}




17 :仕様書無しさん:03/10/18 21:47
普通にチップのタイマ機能使ったほうがいいと思うけど

18 :仕様書無しさん:03/10/18 21:51
>>16
/*この間を書いてごらん*/ は俺にはわからんが
その前にunsignedでない理由を教えてくれ。

話は変わるが組み込みってほんっっっっとにピンキリだよな。
良いコードの例があるサイトとかないのかね

19 :16:03/10/18 21:56
ゴメン、 void 型で定義して値返してら ・・・ハハ

unsigned で無いのは、 I/O は 8bitである事が多いからかな
論理演算で使う時は ムリに unsigned に自分はしないなあ

20 :仕様書無しさん:03/10/18 22:12
コックの代わりはすぐに見つかると思うぞ。シェフはなかなかみつからないけどね

21 :仕様書無しさん:03/10/18 22:25
*((unsigned char *)0x200000)=0xaa;


22 :仕様書無しさん:03/10/18 22:47
組込み系はI/Oポートを使う
オープン系はI/O関数を使う

組込み系はマジックナンバーを使う。
オープン系はマジックナンバーを使わない。

23 :18:03/10/18 22:50
>>19
そういう理由でしたか。納得です。

漏れはI/O入出力にsignedを使うのはなんか抵抗があるんだよなー

24 :16:03/10/18 23:03
>>23
そうなの? 論理演算で使うんだから符号はあんまり考えない。
 わざわざ unsigned ってつけるだけ余計だと思ってたけどなあ

>>16 の答え xor と not を間に入れる


参考:
 http://www.tensyo.com/urame/prog/ALGO.HTM


25 :仕様書無しさん:03/10/18 23:21


グライコのようなインジケータ x 個のLEDを点ける

OUT(portA , (1 << x) -1 )



26 :仕様書無しさん:03/10/19 02:16
>>21
せめてdefineかconstで定義しる。
で、あたかもポートを変数のように使う(メモリマップドIOの場合)。

#define PORT *((unsigned char *)0x200000)
PORT = 0xaa;

27 :26:03/10/19 02:20
おっと、ポートなんだからvolatile忘れちゃいけね。

#define PORT *((volatile unsigned char *)0x200000)
PORT = 0xaa;

28 :仕様書無しさん:03/10/19 21:18
>>26
識別子の意味が見た目と変わってしまうようなマクロはやだなあ

#define PORTADR ((volatile unsigned char *)0x200000)
*PORTADR = 0xaa;

29 :仕様書無しさん:03/10/19 22:02
constを使わないのが組み込み系プログラマ(w

30 :仕様書無しさん:03/10/19 22:09
組み込みの特徴っていうとsprintfを自分で
定義することだと思ふ

31 :仕様書無しさん:03/10/19 22:14
printf文も用途に応じて作ってみたり

32 :仕様書無しさん:03/10/19 22:33
車輪の再発明をするのが組み込み系プログラマ

33 :仕様書無しさん:03/10/19 22:33
>>29
普通に使いますが何か?

34 :仕様書無しさん:03/10/19 23:57
>>32
だって車輪がないんだもん。自分で作らないと。

>>29
参照のみで書き換えの必要が無い変数を定数領域においておきたい場合は普通につかう。
そのほうがRAMを消費しなくてすむ。

35 :仕様書無しさん:03/10/20 02:50
電気だろ?

36 :仕様書無しさん:03/10/20 03:02
>>29
アフォハケーン

37 :仕様書無しさん:03/10/20 03:31
「組込屋はボラタイルがお好き」 民明書房 \680

38 :仕様書無しさん:03/10/20 03:32
>>25
15へぇ

39 :仕様書無しさん:03/10/20 03:37
ボラタイル ワロタ

40 :仕様書無しさん:03/10/20 12:43
組込っていまだにオブジェクト指向でさえ無いの?

41 :仕様書無しさん:03/10/20 12:44
>>40
だからなんなの?

42 :仕様書無しさん:03/10/20 12:55
こんなわけわからん書き方するより
P1.DDR = 0xff;/* ポート1を出力に設定 */
P1.DR.BIT.B0 = 1;/* ポート1の0番目のLEDを点灯 */

こういうふうにOOっぽく書けた方が分かりやすくない?
const Port &port1 = cpu.getPort(1);
port1.SetState(Port::OUT);
port1.getLed(0).TurnOn();


43 :仕様書無しさん:03/10/20 13:12
>>42
じゃあ 1,2,3 番目のLEDも点けたい場合は?

0,1... n 番目迄(n変数)のLEDを点灯したい場合は?

44 :仕様書無しさん:03/10/20 13:17
for(int i=0;i<3;++i)
port1.getLed(i).TurnOn();

for(int i=0;i<n;++i)
port1.getLed(i).TurnOn();

ポートが全部違うんだったら
for(int i=0; i<n; ++i)
 cpu.getPort(i).getLed(0).TurnOn();

45 :仕様書無しさん:03/10/20 13:28
>>44
やっぱり >>25 のシンプルさには及ばないね。
リソースの制限のキツイ組込だと採用されないでしょ。

46 :仕様書無しさん:03/10/20 13:51
コンパイル時にほとんどインライン展開されるようにすれば
最適化されてビットシフト1つになるんじゃないの

47 :仕様書無しさん:03/10/20 14:15
>>46
それは無理っぽいなあ なぜって、最終的に出力するのはメモリじゃなくてI/Oポートだから
勝手に最適化されて一つになっちゃうと逆に怒られるよ。

順に信号を出力する場合とどうやって区別するのよ!


48 :仕様書無しさん:03/10/20 14:17
>>32
車輪ってなんですか???


49 :仕様書無しさん:03/10/20 14:30
>>44
どうせやるなら
busyLed.TurnOn();
とかいう感じにし、ポート云々を隠すようにする。

50 :仕様書無しさん:03/10/20 19:15
組み込み系はプログラミングの抽象化がオープン系にくらべて
数年遅れているようですね。

51 :仕様書無しさん:03/10/20 20:42
>50
あんたの言っている抽象化とやらの内部の話をしていると思われ。

52 :仕様書無しさん:03/10/20 20:52
>>29 大嘘。できるだけconstにしてROMにブチ込むのが組み込み系。
>>34 だよな。それにフルセットのprintfなんて入らねー事たびたび。
>>40 >>50 embeded C++とかならあるけど?

組み込みにはprintfよりcoutのほうが相性いいかもね。
printfだとまるごとリンクされるけど、coutだと使わなければリンクされない組み方がありそうだし。

53 :仕様書無しさん:03/10/20 22:11
>>52
embeded C++は威張れん。

coutだとメンバ関数の呼び出しが大量に展開されそうだけど…

54 :仕様書無しさん:03/10/20 23:52
組み込みの神髄

#define FOREVER while(1){}

void main(void)
{



FOREVER;
}


55 :仕様書無しさん:03/10/21 00:00
>>42
せめて、ビットフィールドにしよう。

56 :仕様書無しさん:03/10/21 00:03
おまえら、どのくらいの記憶容量のことをイメージしながら話してんの?

57 :仕様書無しさん:03/10/21 00:04
>>56
Javaerが記憶容量なんて考えるわけないだろ

58 :仕様書無しさん:03/10/21 00:16
組み込み系に必要なのは抽象化とカプセル化であり
オブジェクト指向ではない

59 :仕様書無しさん:03/10/21 00:22
組込系だろうがオープン系だろうが大差ないということでFA?

60 :仕様書無しさん:03/10/21 00:23
動作速度とか気にしてなさそうなレスが結構見受けられるんだが

61 :仕様書無しさん:03/10/21 00:28
>>60
今は32bitな石にOS乗っけてC++やってる人のほうが多数派でそ

動作速度とか気にする時代でもないと思う

62 :仕様書無しさん:03/10/21 00:36
>>61
え?そうなの?

63 :仕様書無しさん:03/10/21 00:37
>>61
知らない間に、そんなに進んでたのか。

64 :仕様書無しさん:03/10/21 00:38
>>61
貴様はPICを侮辱したッッ!

65 :仕様書無しさん:03/10/21 00:38
>>61
いや、C++はどうだろ?
いずれにせよ速度は常に気にするものだと思うよ。


66 :仕様書無しさん:03/10/21 00:41
>>61
そりゃケースバイケースでしょ。
32bitCPUでも割り込み処理とか高速にすべき部分はある訳だし。
やっぱ組み込みの醍醐味つったら割り込み処理だよな。
あと内蔵ペリフェラルを使った処理。

67 :61:03/10/21 00:42
>>64
コスト重視な案件ではPICが多数派だけどやっぱニッチだよ

>>65
8bit/16bitな時代に比べたらの話ね
あの頃はほらカツカツだったじゃない
それと比べちゃうとさあ
あんま気にする程でもないかなって思うのよ

68 :仕様書無しさん:03/10/21 00:43
OSのオーバーヘッドが気になることなんて多々あることなんだが

69 :仕様書無しさん:03/10/21 00:43
組込み系の分野も幅が広がっている事は事実だよな

70 :仕様書無しさん:03/10/21 00:45
H8とかでもOSのっけるほうが多いのか?

71 :65:03/10/21 00:46
>>67
すまん。漏れ、8bitも16bitも32bitもいまだに全部やってるんだよ…


72 :61:03/10/21 00:48
>>66
確かに部分的には速度を意識することもあるね

>動作速度とか気にする時代でもないと思う
は言いすぎだったかな


>>70
freeのITRONもあるからね。TOPPERSだっけ?
イエローソフトがNORTiの安い奴出してるし
中小零細もパキパキRTOS使っとるよね

73 :仕様書無しさん:03/10/21 00:50
>>68
うん、それはいつも悩ましい

74 :61:03/10/21 00:58
>>71
おお、それは失礼した
「速度を気にする」の解釈の違いがあるとは思うけどな

昔に比べたら動作速度とか気にしなくても良くなったと思う
とか書けばよかったかな

75 :仕様書無しさん:03/10/21 01:00
>>72
そっか、NORTiはちょっと興味あったけど、先日の案件は
OS入れるほどややこしい話じゃなかったから全部割り込みで済ましちゃったけど。
今度なんかあったら見てみるか。

76 :61:03/10/21 01:18
>>75
最近(というか結構前からだが)は既存ハードをEthernetに対応してくれ、という要望が激増量中
んでプロトコルスタックとか書くならRTOSのっけとくか、とそういう流れなんでないかな

77 :仕様書無しさん:03/10/21 01:23
大差なし。
---------終了---------

78 :仕様書無しさん:03/10/21 01:26
はいはい。再開。

79 :仕様書無しさん:03/10/21 01:37
組み込み系=割り込み
オープン系=イベント

割り込みの数 < イベントの数

80 :仕様書無しさん:03/10/21 01:42

組込み系にRTOS載せてメッセージ処理してるとどっちなの?
というか、そもそもオープン系と組込み系っていう比較の仕方が間違っているような気もするが。

81 :仕様書無しさん:03/10/21 02:16
工場とかのパネルコンピュータに操作用Windowsプログラム実装するのはどっち?

82 :仕様書無しさん:03/10/21 02:43
結論としては、APIを使うかI/Oポートを使うかって違いだけなので
たいした違いはない。
>>1のもくろみはみごとはずれたわけ。

---------終了---------

83 :仕様書無しさん :03/10/21 02:57
組み込みといっても、いろいろあるからな
例えば、ATMやカーナビみたいに
WINDOWS上で動くアプリつくっても
組み込み機器なんだから、組み込み系って言ってるだろ



84 :仕様書無しさん:03/10/21 05:25
>>82
ほんとかよ
おまえ何言ってんだ

85 :仕様書無しさん:03/10/21 08:52
マシンの性能向上にしたがい、
組み込み系はオープン系に近くなっていく。

86 :仕様書無しさん:03/10/21 09:07
電池駆動があると32bitだろうがメモリ沢山あろうが、やっぱりCPUコストへの注意は残ってしまうよ。


87 :仕様書無しさん:03/10/21 09:19
電池で動くのなんて少ないけどな。

88 :仕様書無しさん:03/10/21 09:33
量が出るのはやっぱり電池で動くものじゃないの?

逆にあと10年したらWin2000が携帯電話かPDAかで動くようになるんだろ
今のオープン系の連中はその時再生利用されるかもな。

89 :仕様書無しさん:03/10/21 13:06
制御アプリのみでだけどな

90 :仕様書無しさん:03/10/21 20:53
束縛条件が多少違うだけ。どっちも大差なし。

-------終了-------


91 :26:03/10/21 22:51
PORTの空読み
#define PORT *((volatile unsigned char *)0x200000)
(void)PORT;

って、通らないもしくは省略されてしまう処理系もありそうだな。
gccだとちゃんと空読みされてたけど。

92 :仕様書無しさん:03/10/22 21:14
煽りではありません。
ある種の組み込みの現場では、ヒープの利用が禁じられている、
理由はフラグメンテーション、
と聞いたことがあります。
本当だとしたら、フラグメンテーションの何がいけないのでしょうか?
よろしくお願いします。

93 :仕様書無しさん:03/10/22 21:56
それはあれだよあれ

94 :仕様書無しさん:03/10/22 22:02
Win厨必死だなw

95 :仕様書無しさん:03/10/22 22:03
>逆にあと10年したらWin2000が携帯電話かPDAかで動くようになるんだろ
アホですか?

96 :92:03/10/22 23:10
すみません、私自身組み込みを経験していますし、
フラグメンテーションは嫌いです。
Windowsな現場に移りましたが、そこの人が、
メモリーリークがどうしたこうした言うたび
「おまえフラグメンテーションのことを知ってるのか」
と思っていました。
ただ、WindowsでもUnixでも、長く走らせるサーバプログラムで
ヒープを使ったりしているようですね。
それで、フラグメンテーションがどれだけ「現実問題」なのか、
知りたくなったのです。

97 :仕様書無しさん:03/10/22 23:14
malloc()禁止

98 :仕様書無しさん:03/10/22 23:20
>>95
今から10年前に比べてCPUもメモリもは100倍以上になっている。
あと10年たったらWin2000ぐらい携帯電話でも動くだろう。
もっともそのころはWin2013だろうが。

99 :組み込みや:03/10/22 23:22
>>92
全部で 4KB or 8KB などといった少ないサイズの RAM 環境ではフラグメンテーションの余裕を取れません。

100 :仕様書無しさん:03/10/22 23:33
>>99
果たしてそうかな?ふっふっふっ。

101 :仕様書無しさん:03/10/22 23:48
あれでしょ、結局、情報科学部で電気工学が分らなかったら
ソフトハウスでしょ?
あとは皆、メーカで組込みじゃない?

102 :仕様書無しさん:03/10/23 00:23
char const mes[]="MESSAGE\n";

constを入れる位置によって、ポインタが定数になったり文字列が定数になったりする。
ポインタが定数(ROM領域)に置かれて、ROM領域に置かれた文字列が
起動時にRAMにコピーされる(初期値つき変数(DATAセクション)に変数がとられた場合)が
最悪。

103 :仕様書無しさん:03/10/23 00:35
#pragma interrupt
void sci0_int(void)
{
:
:
}

104 :仕様書無しさん:03/10/23 00:36

void main (void)
{
puts("標準って何?");
}


105 :仕様書無しさん:03/10/23 00:42
void main(void)
{
  :
  :
  while(1)
  {
  :
  :
  }
}

106 :仕様書無しさん:03/10/23 00:46
俺はくみこ系

107 :ななし:03/10/23 01:01
auto変数を作る時に、スタックの残りサイズが気になる。

108 :仕様書無しさん:03/10/23 01:08
変数は1つのintを使い回して再利用しろよ

109 :仕様書無しさん:03/10/23 01:54
>>102
挙動を理解しろよ低脳

110 :仕様書無しさん:03/10/23 01:58
>>96
>それで、フラグメンテーションがどれだけ「現実問題」なのか、
>知りたくなったのです。
Win32の場合は各プロセスが持つことのできる仮想メモリ空間は4Gもあるんで、フ
ラグメントが問題になることはほとんど無いんじゃないかと思うけど、多分。。。。
どっちかと言うと各プロセスが共通に使用するシステムリソース(デスクトップアプ
リケーションヒープだっけ?)とか、ローカルヒープを開放するのを忘れてメモリを
食いつぶすことの方が深刻じゃないかな〜。

111 :仕様書無しさん:03/10/23 02:07
>>107
char a[4096] なんてやると一発でどっかとんでちゃうな(w

112 :仕様書無しさん:03/10/23 08:15
>>110
そうだね。仮想記憶の仕掛けがあるから、仮想記憶のブロック単位 4096だったけか?
以上のサイズのインスタンスをドカドカ取れば フラグメンテーションなんて気にする事もないしね。

組み込みでは あるデータが100バイトであるデータが128なんてのをボコボコ取るとそのうち
128バイトの方が取れなくなってしなう。

113 :仕様書無しさん:03/10/23 09:58
>>110
カーネルオブジェクトの食いつぶしは深刻だね。メモリリークより
性質が悪い。CloseHandleしないとどんどんシステム全体のリソース
が減っていく。Win95系では特に悲惨。

>>112
そうならないように、普通はフラグメントが起こらないようなメモリ
マネージャを自作するよね?

114 :仕様書無しさん:03/10/23 10:04
>>112
でも、そろそろ実メモリが32bit空間を埋め尽くせる時代だから、またフラグメンテーション問題が再燃かもね。

115 :92:03/10/23 13:59
>>99>>100>>110>>112>>113>>114
なるほど。フラグメンテーションが現実問題になるのは、
メモリがタイトなときということですね。よくわかりました。
OSのリソースに関する私の経験なのですが、
私の現場では、VC++が使われていました。
C++なら、リソースの確保と開放を文字通り自動化する
ラッパクラスを作って、オブジェクトをスタックに取ることができます。
しかし、メモリリークを云々する人は、せっかくそういう意図で作ったクラスを、
馬鹿の一つ憶えのようにnewしてくれていました。
一方、私は私で、馬鹿の一つ憶えのようにフラグメンテーションを嫌がり、
メモリマネージャ用のクラステンプレートを作ったりしていました。
仮想記憶のブロック単位の話は、よくわかりません。
ブロック間に依存関係が生じたらどうなる? と思ってしまいます。

116 :仕様書無しさん:03/10/23 16:21
>>115
仮想記憶が働いてくれれば、実メモリが一杯になれば使われない領域はHDDに押し出される。
だからそこに穴が空いてもそんなに気にしなくていい。
滅多に参照されないのも使われないのも同じだしね。
ただし、メモリ空間そのものも有限だからというのが >>114 の話



117 :仕様書無しさん:03/10/23 16:26
という事で、フラグメンテーションが起こってボコボコに穴が空いても
仮想メモリ空間に十分な余裕があるなら問題ない。
実際、今までは十分な余裕があった。
しかしメモリリークがあれば、連続運転によっていつかは仮想メモリ空間も不足してしまう。

だから、Windows環境では今まではメモリリークの方が重要な問題だったんだと思うよ。


118 :92:03/10/23 22:54
>>116-117
ありがとうございます。理解できました。

119 :仕様書無しさん:03/10/24 00:39
>>109
素人の派遣やろうはひっこんでな

120 :仕様書無しさん:03/10/24 05:23
>>117
たとえはDreamCastのWinCEとかmallocからしてメモリリークって聞いたけど。


121 :仕様書無しさん:03/10/24 06:29
>>120
お前のコーディングにバグがあんだよ。

122 :仕様書無しさん:03/10/24 07:39
ファーム屋はまだシステム全体を見渡すことが出来るからいいよ。
誰が作ったら解らない挙動不信なライブラリを使うことも無いし、
OSのバグに悩まされたりすることもあまり無い。あったとしても構
造は大体把握できてるから、それを避けて通ることもできる。
まぁ、大抵のことは自力で解決できる。
 組み込み系=村長さん
 オープン系=国家元首
ぐらい気の使い方が違うんじゃないかと思うけど。


123 :仕様書無しさん:03/10/24 11:48
今、チップのバグに悩まされてる…

124 :仕様書無しさん:03/10/24 12:11
俺もだ・・・特定の命令とソースの組み合わせが正常に動作しない。
DSP作ったら全命令チェックしろよ!

125 :仕様書無しさん:03/10/24 14:34
動かないボード渡されるよりは…

126 :仕様書無しさん:03/10/24 16:08
最初はそれが当たり前だと思うが......

127 :仕様書無しさん:03/10/24 16:35
プログラムが全く動かないのに何をしろと…

128 :126:03/10/24 16:55
>>127
ICE繋いで何が原因が探る......って事をオレはするが......
......って、最近はICE使わないんかな?
漏れは今もROM-ICE使ってるが。

......と、書いてみたが、本来ならば、基板作ったヤシが、
RESET信号とかメモリ信号とかの確認をオシロ継げて確認するのがスジか......
でもまぁ、ハード設計者に「こういう状況だから、これがおかしいんじゃない?」
って事を言えるくらいの事は、何かしらできると思われ。

129 :仕様書無しさん:03/10/24 16:56
悩まなくていい…

130 :129:03/10/24 16:57
遅かった…
>>128 へのレスです。

131 :仕様書無しさん:03/10/24 18:21
>>128
結局動作チェック用のROM焼いて渡しますた。
ブートするくらいまではチェックしてクレ…と。

132 :仕様書無しさん:03/10/24 22:28
>>128
最近のICEって安いのか?
CPUICEは軽く100マソは超えるし、ターゲットが変るとまた買い換えだし。
なんといってもLEDピコピコさせるかシンクロで波形見るのが1番安くつく。

133 :仕様書無しさん:03/10/24 23:57
やっぱり組み込みの方は「一ヶ月の出勤日・休日」を32ビットで表現するのですか?

134 :仕様書無しさん:03/10/25 03:04
ふだんはソフトとハードを一人でやっていて、
複数人での仕事のときも、ソフトとハードの両方ができるメンバーが集まるから、
ソフト/ハードで担当者が別れているプロジェクトの内情がひどいモノなんだろうなってことは
なんとなくわかるような気がする。
実際端から見ていてもケンカが絶えない様子だし、ちょっとした修正に何日も使ったりしてるし。

135 :仕様書無しさん:03/10/25 08:49
うちはソフト開発時間の7割はハードウェアのデバッグに割かれてる
デバッグしたといってる割には、まともなボードが上がってきたためしがない
次からはデバッグ込みで工数くださいって頼んだよ

136 :仕様書無しさん:03/10/25 09:26
というかさ、有名所の企業の開発室でも 仕事してるのは皆派遣なんだね・・・・その現状知って驚いたよ

137 :仕様書無しさん:03/10/25 15:46
有名どころには職人さんがいない(育たない?)からね。

138 :仕様書無しさん:03/10/26 06:28
>>135 そんなもんさ。しまいにゃハードのアドバイスを求められたりするし。

139 :仕様書無しさん:03/10/26 09:00
ASICの設計をプログラム屋がやってるってよくある話、だよな。
組み込み屋ってオープン系よりむしろハード屋に近いのかも。

140 :128:03/10/27 10:23
遅レススマソ
>>131
基本部分が動作するソフトが出来あがってる場合は漏れもそうすよ。
......ってか、試作ハードが出来あがってないうちから
評価ボードとかで動作デバックするから、試作基板できあがった頃には、
基本部分が動作するソフトは出来あがってるから、
試作ハードの初期動作テストはこれが普通かも......
で、それで良く分からないと言われた場合は、ICE繋いでテストか。

141 :128:03/10/27 10:31
>>132
ICEは高いよ。
でも、CPUICEはPICくらいのしか、最近は見たことないなぁ.....
ROM-ICEばっかりなのかも。
かく言う漏れが使ってるICEもROM-ICEだからね。

でも、こんなの使ってるから、個人的にH8で遊んでても、
本格的なデバック環境が欲しくなるんだろうなぁ......とか考えたりして......
個人的にYellowIDE+コンパイラ買ってしまった。合計\56,000也
でも、ホントにプログラム組むペースが全然違うよ。

142 :仕様書無しさん:03/10/27 10:49
>>139
そうだと思う。組み込み系はハード直接操作だからね。
ソフトの知識だけじゃプログラム組めないし。

漏れが今の会社入った時は、純ソフト屋だったけれども、
今はCPU周りのポート割り当てとか接続したICの制御方法の検討とか、
CPU周りの回路図確認くらいはできるようになった。

まぁ、未だに回路図を書く事はできないけどね。
CRとかOPアンプとか、漏れはそういうのはよく分からん。

143 :仕様書無しさん:03/10/27 22:01
>>142
そうだよな。デジタルなら何とかなるけど、アナログはなぁ〜
高周波とかになるとサパーリわからん。

144 :仕様書無しさん:03/11/07 20:47
>>92
>>115-118
 蒸し返して済みませんけど。
WindowsやUNIXでは、ユーザー空間のプログラムは、
OSがどうやってメモリを確保してプロセスに渡してくれるかを
気にする必要がない、通常は気にすることが「できない」って話ですよね。
 メモリ資源の物理的配置はOSしか知らないんだから、
フラグメンテーションの対処は全てOSに任せると。
ユーザープロセスはメモリリークだけ気にしていればよいと。

145 :仕様書無しさん:03/12/30 00:20
>>143
分布定数回路っての?
大学の電磁波工学でやってけどよくわからん買った。

146 :仕様書無しさん:04/01/02 22:05
組み込みと言えば volatile.


147 :仕様書無しさん:04/01/02 23:44
組み込みって言ったっていろいろあるからなあ。
メモリ無しでGCCだったのでvolatile使わなかった。レジスタ割り当て
でなんとかできる。

148 :仕様書無しさん:04/01/03 00:03
おれもあんまりvolatile使わない。
どうしても必要なところはしょうがないけど、こないだやった奴は必要なかった。

149 :仕様書無しさん:04/01/04 14:59
メモリマップドIOだと使わざるを得ないと思うんだけど
ぼらたいる使わないで済む方法ってある?
知識として知りたい

150 :仕様書無しさん:04/01/04 16:24
そもそも、メモリマップI/OをCから操作する方法なんて環境依存なんだしさ
組込系のCコンパイラなら色々だと思うよ

151 :仕様書無しさん:04/01/06 19:43
組み込みと言えば

const char * const i_am_located_at_rom;


152 :仕様書無しさん:04/01/08 22:43
最適化オプションを最低にすればできるコンパイラもある。
でも、そんなことするくらいならvolatile使った方がいい。

153 :仕様書無しさん:04/01/17 01:27
main()
{
startUp()

initBat()
/* 各状態にTaskを登録 */
switch(状態)
case 朝立ち

case 初期化

case 通常

case おねんねする

 デフォ
リセット()

}

単体で動いてるって雰囲気が
組込みだと思ってる
が、RTOS使ってるようなやつはどんな感じ?

154 :153:04/01/17 02:17
風呂入ってたら、ループ入れるの忘れてたのに気づいた
訂正:

for(;;){
switch

}

設計して(コード書いて)、帰宅してから寝る瞬間ぐらいにミスに気づくタイプだな俺は...
itai

155 :仕様書無しさん:04/01/18 14:52
main()
{
wakeupalltask();
halt();
}


156 :仕様書無しさん:04/01/18 15:01
>>154
それ、漏れもよくある。

157 :仕様書無しさん:04/01/18 22:38
void main()
{
asm("start:");
なんか処理
for (;;) {
なんか
asm("trap_return:");
なんか
}
}


33 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)