デバッグメッセージ

.01 2011 C言語 comment(0) trackback(0)
開発中のデバッグメッセージは最終的には消したいものですが、完成後バグが見つかった時などはデバッグメッセージを消したことを後悔する…なんてことがよくあります。
そんなときに便利な方法。

#include <stdarg.h>
void
dbg(const char *format, ...)
{
#ifdef DEBUG
	va_list args;
	fprintf(stdout, "[Debug] ");
	va_start(args, format);
	vfprintf(stdout, format, args);
	va_end(args);
#endif
}
この例ではifdefでやっていますが、起動時の引数を見てデバッグモードならデバッグメッセージを表示するとかいろいろ方法はあります。

C言語備忘録

.12 2011 C言語 comment(0) trackback(0)

  • 引数分解 → getopt
  • uint32_tなど → stdint.h
  • sys/stat.h使うならその前にsys/types.hをincludeするのが正しい
  • remove syscallは内部的に「dir → rmdir, file → unlink」を呼んでいる
  • dir関連のsyscall → opendir, readdir, closedir, mkdirなど

環境依存でもいいのでとにかく色付き文字を表示したい!
というときはとりあえずprintf中とかで\x1b[%dmを使う。%dには数字を入れる。
4なら下線、41なら赤、42なら緑などなど。複数指定するときは\x1b[4;41mみたいに指定する。

備忘録終わり。以下近況。

そろそろSystemCなんかはじめてみようかと思ったり。でSystemCはC++にライブラリとかつけたものなので結局C++を使いこなせないとダメ。
そんなわけで今更ながらC++を勉強してみたり。

SystemCってのはハードウェア記述をVHDLとかVerilogとかよりもう一段抽象化して考える言語。
ムーアの法則でチップ上のトランジスタの数が指数関数的に増えているのでVHDLですべてを書くのはそのうち限界になる…と予想されます。

コンピュータができて最初の頃はアセンブリで全部書いていて、結構最近でも「速度が必要な部分だけはアセンブリ」という感じだったのが今ではシステム関連でもほとんど全部Cです。
ある本によれば、かの天才クヌース氏も「Cで書くのは非効率だ。アセンブリで書くのが当然」と言っていたそうですが、今ではコンパイラの最適化技術の進歩、ハードウェアアーキテクチャの進歩などにより、効率的なコードがCから簡単に生成され、ハンドアセンブルした場合とほぼ同じ速度が出ます。

# もちろんこれはある程度大規模なシステムでの話であって、クヌースがこの発言をした当時と同じ規模のシステム、つまりマイコンとかで性能を出したい場合にはアセンブリで書くべきです。

VHDL, VerilogからSystemCへの移行はこれと同じくらい画期的なもので、現在ではまだVHDL, Verilogが「当たり前」ですが、そのうち「基本的にはSystemCで、必要ならVHDLで最適化」という時代が来ると思われます。
そんなわけで近い将来SystemCが必要な時代がくると考えています。まさか?と思うようなことが平気で起こるのがこの業界です。

さて、C++勉強しますか。あと院試ではC, JAVAのコードが出されることがあるらしいのでJAVAも勉強しないと。

TODO:
  • 分散並列関連(ハードウェア的にもソフトウェア的にも)の勉強
  • JAVA
  • C++
  • SystemC
  • 簡易OS自作
  • 遠征

# いつも忘れるVIMコマンド:ctrl + d/uで半画面スクロール。スクロール系は半画面程度が自分にはあってる気がする。あとz.でカーソル位置を画面中央とかも便利だけどいつも忘れるなー
# mouse=aにしてるせいでH, M, Lとかの基本的なカーソル移動コマンドも全然使わないからなかなかvim使いになれなくて残念。

ファイル分割

.23 2009 C言語 comment(0) trackback(0)
さて、AVR-LCDのソースは今のところ
  • 下層(LCDにコマンドを送ったりVRAMの制御をしている部分)がアセンブリで500行程度
  • 上層(アプリケーション層)がCで500行程度
となっていて、アセンブリの方はそのままでいいのですがCの方はそろそろ分割したくなってきました。

というわけで早速分割。

…なぜかコンパイル後のhexファイルのサイズが大きくなってしまいました(泣

えー、無駄な処理が入っただけかと思ったのですがAVRにダウンロードしてみるとどうもRAMがあふれているようです。
症状としては、あるアプリケーションを起動すると、(おそらく)1画面分描画したあとリセットベクタに飛んで最初から実行を開始する。
つまりそのアプリケーションは起動した瞬間に落ちるというわけです。

=>バグの原因はSRAMにアクセスしている部分に特定できたわけです。

というわけで以下具体的に分割前後のコードのうち、VRAMとして使っている領域をどういうふうに宣言しているのか見ていきます。

分割前:
#include <avr/io.h>

uint8_t buf[30 * 64]; // VRAM

void
app1(void)
{
   ...
}

int
main(void)
{
   ...
}

分割後:
// main.c
#include "app.h"

uint8_t buf[30 * 64];

int
main(void)
{
   ...
}



// app.h
#include <avr/io.h>

extern uint8_t buf[];

void app1(void);



// app.c
#include "app.h"

void
app1(void)
{
   ...
}


うー…ここだけ見ると別に問題なさそうだ。
どこか他のところに原因があるんでしょうか?

とりあえず今日はI2Cの方を見ないといけないのでファイル分割は後日改めて。

# プログラムコード表示用にスタイルシートいじってみました。ちゃんと更新されたかな?
# せっかくなのでこの際Syntax Highlighterを導入してみました。
 HOME