title to php.net

menu 総合掲示板 日記 リンク iαppli 開発&Tips C/C++全般 Java全般 Windowsアプリ 組込 i-αppli Webアプリ PHP 組込入門 ロジック
1371224
←前の10件 次の10件→

--日立H8S C/C++コンパイラ--
≪read()のデータ数≫
≪___curr_eh_stack_entry≫
≪Internal error≫
≪ベクタテーブル≫
≪ビット位置の変更≫
≪read()の戻り値≫
≪C++リンケージ≫
≪IICのDDCSWRのCLRビット≫
≪ヒープ≫
≪例外処理≫

←前の10件 次の10件→

開発日誌っす

組込
←前の10件 次の10件→

日立H8S C/C++コンパイラ
≪read()のデータ数≫
read()のデータ数はバッファリング時にはまとめてバッファサイズ分で呼び出される。そのため、前述したようにクラスタサイズが小さい場合は、ユーザーバッファ定義が必須となる。

≪___curr_eh_stack_entry≫
L2310 (E) Undefined external symbol "___curr_eh_stack_entry" referenced in...のエラーメッセージは、コンパイラオプションにて、C++とEC++の両方を暗黙で使用するように設定してしまうと、発生する。どちらか片方のみを選ばなくてはならない。といっても、オプションの所では判りにくい。

≪Internal error≫
C4099 (?) Internal errorが発生する場合あり。筆者の環境では、マクロ定義が複雑になり、マクロがマクロを参照するような状態で中カッコ}を書き忘れた時に発生。

≪ベクタテーブル≫
「アプリケーションノート」には、ベクタテーブルファイル、「vecttbl.c」及び「vect.h」が生成されると書いてあるが、実際は生成されず。ベクタ定義は自動で行われるらしく、割り込み関数は、__interrupt(vect=xx) void foo();としてxxの部分にベクタ番号を書いておけば、リンカが解決してくれる模様。マニュアルには、その旨の記述なし。

≪ビット位置の変更≫
ポートデータ等のビット位置を第0ビット目以外にコピーする場合、受け側の変数を次の様な構造体にすると良い。
struct {
unsinged char B7:1;
unsinged char B6:1;
unsinged char B5:1;
unsinged char B4:1;
unsinged char B3:1;
unsinged char B2:1;
unsinged char B1:1;
unsinged char B0:1;
} FOO;
で、実装は
bar.FOO.B4 = P_P1.PORT.B6;

≪read()の戻り値≫
低水準インターフェースのread()の戻り値は読み込んだデータ数だが、これに0を返すと高水準側でEOFとマーキングされ以後呼び出されなくなってしまう。

≪C++リンケージ≫
CPPファイル内でC++リンケージの関数ポインタを扱う時、extern "C"を行わないと、ヌルポインタとして処理されてしまう。この時、コンパイラ及びリンカはエラーもワーニングも出さない。

≪IICのDDCSWRのCLRビット≫
フレームワークが自動生成するiodefine.h内にある、DDCSWRの構造体にCLRビットがなく、必要のないSWE、SW、IE、IFの定義がある。サポートに確認を取ったら誤りだそうで、近いうちに修正されると思われる。これに関しては、H8S/2633Rのハードウェアマニュアルにも誤記があり、使用しないビットの設定に触れられている。

≪ヒープ≫
ヒープって便利なんだけど、組込の場合フラグメンテーションの後始末が面倒。
純正コンパイラの場合プロジェクト生成時に「ヒープを使わない」設定ができる。
でも、これが曲者でファイル操作(putsとか)を使うと「_sbrk()が無い」と言われちゃう。
_sbrk()はユーザー作成関数なので、「ヒープ使う」にするとウィザードが自動生成(雛形)してくれる。
で、コレが無いから、ファイル操作を行うと、バッファ(キャッシュ)割り当てをヒープから行おうとするので、「未定義エラー」となるわけ。
前述しているようにユーザーバッファを割り当てても、コンパイラは知ったこっちゃ無いので、無条件に「未定義エラー」となる
回避方法は・・・。無いんじゃないかな。
結局ダミーの「_sbrk()」でも作って、ファイルバッファはユーザーバッファを割り当てるようにして、呼び出しが起こらないようにするしか無いみたい。シンボルは無いとリンクエラーが起こるから。
何て無駄な・・・。

≪例外処理≫
try、catchなどの例外処理はC++ではとても便利な機構。
ファイル操作なんかの場合、よく使われる手法ですな。
純正コンパイラの場合、オプション設定で有効/無効が切り替えられる。
でもコレ、有効にしたら、標準ライブラリ内でRAMを10K近く消費してくれる。
2633とかってRAMの総容量が16Kなんですが、その内10Kなんて、ほとんどなんですけど・・・。
結局使わないほうが良いみたい。

←前の10件 次の10件→