TOPPERS/JSP for秋月電子H8 3069 LANボード (6)

前回からだいぶ間が空いてしまいました。

ブレーク信号を受信するとTOPPERS/JSPカーネルがハングしてしまっていたのですが、これは受信割込ハンドラだけでなくエラー受信割込ハンドラを有効にすることで回避できました。また、実際はブレーク受信時の処理を書く必要はなかったのです・・・まったく、一体何のためにあれだけ苦労したのかと。

ちなみに、今回この問題が起きたわけは、もっと深いところにありました。深いとは言ってもソフトではなく、ハードです。

実は、H8 3069 LANボードに載っているH8 3069には3チャネルのシリアルコントローラが載っているんですが、チャネル0とチャネル1はRS-232C用に信号レベルの変換を行うチップが接続され、そのチップ経由でチャネル1がD-sub 9ピンの雌コネクタに接続されています。このチャネル1をシリアルコンソールとして利用するわけです。

ところで、今回はまっていたのはこのRS-232C向けに出力されているチャネル0を使った通信だったのですが、RS-232C用に信号レベルを変換されてしまうと都合の悪いデバイスに接続をしなければならなかったので、このH8からレベルシフタへの配線パターンをカットして、そこからリード線を引き出す様な使い方をしていたんですね。

ちなみに、RS-232Cとはシリアル通信に対してHIGHとLOWの電圧を定めたもので、HIGHが+12V、LOWが-12Vで作動します。通常のシリアル通信(UART)にはHIGHレベルの電圧についての規定はなく、LOWレベルはグラウンドで動作します。

TOPPERS/JSPのシリアルドライバは、チャネル0のUARTがレベルシフタに直結している事を想定していた為に、今回の問題が起こった様でした。

ま、基板に直接手を入れる様な事をすれば、この様な想定外の事態が起こる、ということなんでしょうな。ともかく良い勉強になりました。

TOPPERS/JSP for秋月電子H8 3069 LANボード (5)

さてさて、H8向けのTOPPERS/JSPには、シリアルインタフェースドライバ内にシリアル受信割込ハンドラとシリアル受信エラー割込ハンドラの2つが定義可能です。しかし、後者は #ifdef の条件分岐によってコメントアウトされており、前者内でエラーの割込も処理するようになっています。

ちなみに、実装は jsp/config/h8/hw_serial.c 内の SCI_in_handler です。

さて、SCI_in_handler の実装を見てみましょう。

void SCI_in_handler(ID sioid)
{
SIOPCB *pcb;
UB status;

pcb = get_siopcb(sioid);
status = sil_reb_mem((VP)(pcb->inib->base + H8SSR));

if (status & (H8SSR_ORER | H8SSR_FER | H8SSR_PER)) {

/* エラー処理 */

/* エラーフラグをクリア */
sil_wrb_mem((VP)(pcb->inib->base + H8SSR), status & ~(H8SSR_ORER | H8SSR_FER | H8SSR_PER));
}

if (status & H8SSR_RDRF) {
if (pcb->openflag) {
/* 受信可能コールバックルーチンを呼出す。*/
SCI_ierdy_rcv(pcb->exinf);
} else {
sil_wrb_mem((VP)(pcb->inib->base + H8SSR), status & ~H8SSR_RDRF);
}
}
}

ううむ・・・真ん中当たりに「エラー処理」と書かれて放置されている(っぽい)辺りが怪しい。ここに書けば良いのかな。

とりあえず、フレーミングエラーの場合はシリアルチャネルのRxDを調べて、ブレーク信号かどうかを判断すれば良いそうです。こんな処理を入れちゃいましょう。

/* フレーミングエラー発生時 */
if (status & H8SSR_FER){
/* RDR (Receive Data Register) がブレーク信号受信状態 (全ビットがLOW = 0x00) であるかどうかをチェック */
if (sil_reb_mem((VP)(pcb->inib->base + H8RDR)) == 0x00){
/* ブレーク信号受信時には SCR (Serial Control Register) の RE (Receive Enable) フラグを落とす */
sil_wrb_mem((VP)(pcb->inib->base + H8SCR),
sil_reb_mem((VP)(pcb->inib->base + H8SCR)) & ~H8SCR_RE);
}
}

RxDを調べるとブレーク信号かどうか分かるって言うんですが、それってRDR (Receive Data Register) の値を調べれば良いって事と等価ですよね？RSR (Receive Shift Register) は直接CPUから読み書きできませんので、これで合ってると思うんですが。

そして、このコード修正をカーネルに反映してアプリを再コンパイルします。カーネルをアプリとは別にコンパイルしている場合は、

% cd jsp/(kernel_build_dir)
% make realclean
% make depend
% make libkernel.a

とかやっときましょう。たぶん最後の行の「make libkernel.a」だけで良い筈ですが、チキンな私は「make realclean」からやっときました(^^;)

さて、アプリをコンパイルしてH8に転送し、実行します。そして、シリアルコンソールのminicomから「Ctrl-a f」でブレーク信号を送信しますが・・・あ、シリアルコンソールからのデバッグ出力が止まった。カーネルがハングしたっぽい。

何でやねん！！

今入れたコードは何だったんだ・・・orz

(苦悩は続く・・・)

TOPPERS/JSP for秋月電子H8 3069 LANボード (4)

あああ、、、やってしまった。

前回のエントリでは、一生懸命SH2向けのTOPPERS/JSP実装をベースにH8 3069F向けのブレーク信号検出時の割り込みハンドラについて想定しましたが、やってしまいました。そもそも、H8にはブレーク信号検出割り込みというものは無いのです。代わりに、受信エラー割り込みの割り込みハンドラ内で、ブレーク信号の検出時の挙動を書いてやる必要が有りそうです。

ちなみに、受信エラー割り込みハンドラは既に jsp/config/h8/hw_serial.c 内に実装されており、シリアルステータスレジスタ(SSR)の3つのフラグ(ORER: オーバーランエラー, FER: フレーミングエラー, 及び PER: パリティエラー)をチェックし、フラグが立っていれば単にそれらをクリアする、という実装になっています。

ここに何かを実装すれば良い気がします。

TOPPERS/JSP for秋月電子H8 3069 LANボード (3)

引き続き備忘録です。

TOPPERS/JSPカーネルのH8向け実装には、シリアルインタフェースの受信時にブレーク信号を検出した際の割り込みハンドラが実装されていない様です。これで相当にハマりました。しょうがないので、自分で作ることにします。

幸いな事に、TOPPERS/JSPカーネルのソースツリーを調べると、SH2プロセッサのSH7615向けにはブレーク信号検出の割り込みハンドラが実装されていますので、それを参考にします。というか、他のプロセッサ／プラットフォーム向けにはブレーク信号検出の割り込みハンドラが実装されていない様に見受けられます。みんな必要なかったんでしょうか。。。謎だ。

さて、以下は作業予定ですので、実際にこの通りやってうまくいかない可能性も有ります。作業が終わったらまたアップデートする予定です。

作業のレシピはこんな感じ。

ソース:

1. jsp/config/sh2/sh7615scif.c
• 割り込みハンドラの実体である sh2scif_isr_siop_brk 関数があります
• シリアルチャネル0向けの割り込みハンドラである sh2scif_isr_brk 関数があります(その実体は sh2scif_isr_siop_brk 関数です)
• シリアルチャネル1向けの割り込みハンドラである sh2scif_isr2_brk 関数があります(その実体は sh2scif_isr_siop_brk 関数です)
2. jsp/config/sh2/hsb7616it/hw_serial.h
• 割り込みハンドラの名前を付け変える以下の#defineディレクティブがあります
• #define sio_handler_brk sh2scif_isr_brk
• #define sio_handler2_brk sh2scif_isr2_brk
3. jsp/config/sh2/hsb7616it/hw_serial.cfg
• 割り込みハンドラを登録する以下の静的APIがあります
• DEF_INH(INHNO_SERIAL_BRK, { TA_HLNG, sio_handler_brk });
• DEF_INH(INHNO_SERIAL2_BRK, { TA_HLNG, sio_handler2_brk });

なんか、これだけ材料があったら負ける気がしません(笑)。

さて、私がターゲットにしているのはH8 3069を搭載した秋月電子製マイコンボード(H8 3069F LANボード)ですので、上記のレシピで以下の様な読み替えを行います。

• sh2 => h8
• hsb7616it => akih8_3069f
  

また、シリアルチャネルの数が最大3に増えます。

この読み替えを行うと、H8 3069F LANボード向けには以下の作業をすることになります。

作業:

1. jsp/config/h8/akih8_3069fscif.c を作成する
   
• 割り込みハンドラの実体である h8scif_isr_siop_brk 関数を実装する
• シリアルチャネル0向けの割り込みハンドラである h8scif_isr_brk 関数を実装する(その実体は h8scif_isr_siop_brk 関数である)
• シリアルチャネル1向けの割り込みハンドラである h8cif_isr2_brk 関数を実装する(その実体は h8scif_isr_siop_brk 関数である)
• シリアルチャネル2向けの割り込みハンドラである h8cif_isr3_brk 関数を実装する(その実体は h8scif_isr_siop_brk 関数である)
2. jsp/config/h8/akih8_3069f/hw_serial.h を作成する
   
• 割り込みハンドラの名前を付け変える以下の#defineディレクティブを定義する
• #define sio_handler_brk h8scif_isr_brk
• #define sio_handler2_brk h8scif_isr2_brk
• #define sio_handler3_brk h8scif_isr3_brk
3. jsp/config/h8/akih8_3069f/hw_serial.cfg を作成する
   
• 割り込みハンドラを登録する以下の静的APIを記述する
• DEF_INH(INHNO_SERIAL_BRK, { TA_HLNG, sio_handler_brk });
• DEF_INH(INHNO_SERIAL2_BRK, { TA_HLNG, sio_handler2_brk });
• DEF_INH(INHNO_SERIAL3_BRK, { TA_HLNG, sio_handler3_brk });

ここで、H8プロセッサ、及びH8 3069F LANボードにおける、TOPPERS/JSPのファイル構成を考慮して、少し修正を施します。

1. jsp/config/h8/akih8_3069fscif.c を作成する
• 既存の jsp/config/h8/hw_serial.c に追記する
2. jsp/config/h8/akih8_3069f/hw_serial.h を作成する
• 既存の jsp/config/h8/hw_serial.h に追記する
3. jsp/config/h8/akih8_3069f/hw_serial.cfg を作成する
• 既存の jsp/config/h8/hw_serial.cfg に追記する

さらに、既存のH8向けシリアルインタフェースドライバの関数名を踏襲しましょう。修正された作業内容は以下の通りです。

1. 既存の jsp/config/h8/hw_serial.c に追記する
• 割り込みハンドラの実体である SCI_brk_handler 関数を実装する
• シリアルチャネル0向けの割り込みハンドラである sio_brk_handler 関数を実装する(その実体は SCI_brk_handler 関数である)
• シリアルチャネル1向けの割り込みハンドラである sio_brk2_handler 関数を実装する(その実体は SCI_brk_handler 関数である)
• シリアルチャネル2向けの割り込みハンドラである sio_brk3_handler 関数を実装する(その実体は SCI_brk_handler 関数である)
2. 既存の jsp/config/h8/hw_serial.h に追記する
• 割り込みハンドラの名前付け変えは不要
  
3. 既存の jsp/config/h8/hw_serial.cfg に追記する
• 割り込みハンドラを登録する以下の静的APIを記述する
• DEF_INH(INHNO_SERIAL_BRK, { TA_HLNG, sio_brk_handler });
• DEF_INH(INHNO_SERIAL2_BRK, { TA_HLNG, sio_brk2_handler });
• DEF_INH(INHNO_SERIAL3_BRK, { TA_HLNG, sio_brk3_handler });

さて、これでやることが決まりました。
作業を始めますか。。。

Vine Linuxでマイコン開発(2)

その後、すっかり記述がご無沙汰してしまいました。

結局、Vine 4.2ではRPMによるクロス開発環境構築を諦め、通常の様にソースからconfigure & make & make installを行いました。但し、インストール先はユーザのホームディレクトリ以下です。

これで、binutilsとgcc、そしてnewlibが揃いました。

次は、開発に用いる組込向けOSを用意します。今回はμITRON 4.0に準拠したオープンソースのOSである、TOPPERS/JSPを用います。

TOPPERS/JSPは、実はOSと言うよりも大きなライブラリです。ソースが公開されていますし、既に様々なCPUやプラットフォームに移植済です。当然、今回のターゲットであるルネサスH8 3069Fプロセッサや、秋月電子 H8 3069F LANボードに対応しています。

ところで、TOPPERS/JSPを使うプログラムは、TOPPERS/JSPカーネル(実体はソースをビルドする事で得られるlibkernel.aという静的ライブラリ)とリンクされ、H8 3069Fの内部フラッシュROMに書き込まれることで、実行可能となります。

しかし、H8 3069のフラッシュROMは100回の書き込みしか保証されていません。そこで、毎回毎回フラッシュROMに書き込まなくても良い様に、フラッシュROMには簡易モニタプログラムを書き込むことにします。H8用の簡易モニタプログラムはこちらからダウンロードできます。

H8簡易モニタは、既にコンパイル済のバイナリが配られているアーカイブに含まれていますし、それをビルドするためのソースも同梱されています。特にバイナリ版で問題が無ければ、バイナリ版をH8 3069のフラッシュROMに転送します。

ちなみに、転送するにはROMライタプログラムが別途必要です。今回は、ソースが手に入るOpen H8/SH Writeを利用することにします。ソースファイル「h8write.c」をダウンロードし、そのまま例えば以下の様なコマンドラインでコンパイルします。

% gcc -o h8write h8write.c

出来上がったROMライタを使って簡易モニタをH8 3069のフラッシュROMに転送します。

% h8write -3069 -f20 mon3069.mot /dev/ttyUSB0

但し、簡易モニタプログラムのモトローラSレコード形式ファイルのファイル名をmon3069.mot、また今回はUSB/シリアル変換ケーブルを用いているので、シリアルポートのデバイスファイルを/dev/ttyUSB0としています。

これでとりあえずH8簡易モニタが起動する様になります。H8 3069ボードのシリアルポートコネクタにUSB/シリアル変換ケーブルを接続し、Vine上でrootにsuしてからminicomを起動します。root権限が無いとシリアルポートのデバイスファイル/dev/ttyUSB0がオープン出来ませんので、ご注意下さい。また、ターミナルソフトはminicomじゃなくても構いません。

minicomを起動する場合は、まず最初にシリアルポートの接続設定を行う必要がありますので、コマンドラインオプションに”-s”を指定します。

% su -
% minicom -s

もしくは、普通にオプション無しでminicomを起動し、”Ctrl-a s”で設定画面を呼び出しても同じです。

シリアルポートの設定は、以下の通りです。

• 通信速度: 38,400bps
• データサイズ: 8ビット
• パリティ: 無し
• ストップビット: 1

H8 3069ボードに接続し、簡易モニタの起動が確認出来ればひと段落です。

TOPPERS/JSP for秋月電子H8 3069 LANボード (2)

引き続き備忘録です。

1. 特定のI/OポートのHigh/Lowを見る方法。
• 例えばポート4に属する8つのI/Oポート(H8 3069のピン配置では#18-21, #23-26)の値は、H8P4DRマクロを使ってアクセスします。
• ポート4の1ビット目は(*((UB *) H8P4DR) & 0x01)でRead/Writeアクセスできます。
• 電圧Highは1、電圧Lowは0となります。
2. 特定のI/Oポートの入出力方向の取得/設定方法
• まず、H8ではI/Oポートの入出力方向を設定するレジスタ(DDR: Data Direction Register)が書き込み専用です。その為、現在の設定値を保持する為にTOPPERS/JSPでは特別にカーネル内部に設定値保持の為の変数を設けています。
• 入出力方法の設定には、sil_wrb_ddrサービスコールを用います。例えば、ポート2の1ビット目から6ビット目までは出力、7ビット目と8ビット目は入力、と設定する場合は、sil_wrb_ddr(IO_PORT2, 0x3F)とコールします。出力に設定するI/Oポートのビットは1を、入力に設定するI/Oポートのビットは0を指定します。
• 設定済みの値を読み出したい場合は、sil_reb_ddr(IO_PORT2)とコールし、その返り値をチェックします。
• 設定済みの値に対して特定のビットだけをON/OFFしたい場合は、sil_anb_ddr (既存値とのAND演算)、sil_orb_ddr (既存値とのOR演算)を用います。
3. タスクのウエイト
• 通常のCプログラムにおけるsleep関数のような事をしたい場合は、dly_tskサービスコールを用います。引数は1つだけで、ミリ秒単位の時間を表す整数です。
• 例えば、1秒間ウエイトしたい場合は、dly_tsk(1000)とコールします。
  

TOPPERS/JSP for秋月電子H8 3069 LANボード

本エントリは備忘録です。

μITRON4の実装であるTOPPERS/JSPを使って、秋月電子製のルネサステクノロジH8 3069を搭載したボード上で稼働するプログラムを書いています。

H8 3069はH8 300Hファミリ、最大クロック25MHz (但し当該ボードでは20MHzで駆動)、内部フラッシュROM 512KB、内部RAM 15KB、外部RAM 2MB (16Mbits)といったところです。シリアルインタフェースは3ch搭載されています。

1. シリアルポートI/O
• ER_UINT serial_rea_dat(ID portid, char * buf, UINT len)
• portidのシリアルポートからbufが先頭アドレスのバッファにlen文字読み出す
• ER_UINT serial_wri_dat(ID portid, char * buf, UINT len)
• portidのシリアルポートにbufが先頭アドレスのバッファからlen文字書き出す
2. ログ出力
• void syslog(UINT prio, const char * format, ...)
• prioのプライオリティでログを出力する
• format以降の引数については標準Cライブラリのprintf関数と同様
• 但し、formatより後ろの引数は最大5個まで
  

Vine Linuxでマイコン開発(1)

Macで敗北したので、会社のVAIOをWindows XP Home + Vine Linux 4.2のデュアルブートにすることに。

Vineを本格的に触るのは、学生時代以来だから実に7年半ぶり。すっかりインストーラも洗練されて、特に問題無くグラフィカルログイン可能な状態にまで持って来れた。

Vine 4.2の特筆すべき点は、WinXPに比べた時に格段に軽く感じる点ではないかと思う。Firefox 3.0.3を起動するにしても、WinXPに比べてかなり速い。これは良い。今回はクロス開発環境を追い求めてLinuxを選択し、かつ非力なノートPC (Pentium M 900MHz + 256MB RAM) だったのでVineを選んだが、Vineのラップトップというのも良いかも知れない。

さて、Linuxが一旦動き出すと、H8用のクロス開発環境の準備も格段に楽になる。「Tools for Linux」のページから、MES2.0、H8ユーザプログラム用の GNU binutils、GNU gcc、及びRedHat newlibのソースRPMを頂き、件のVineでバイナリRPMをリビルドするだけ。

この際には、以下のコマンドを実行した。

% cd ~/rpm/SRPM
% (カレントディレクトリにソースRPMをコピー)
% rpm -i <パッケージ名>.src.rpm
% cd ~/rpm/SPECS
% rpmbuild -bb <パッケージ名>.spec
% cd ~/rpm/RPMS/i386
% su
% rpm -Uvh <パッケージ名>.i386.rpm

但し、上記ソースRPMのSPECファイルそのままではリビルドが出来ない。SPECファイル内に書かれている”Copyright: “という行が互換性エラーを吐くので、ここをエディタで”License: “と書き換える。RPMコマンドのバージョンによってSPECファイルの書式が変わったのかな？

あと、newlibのリビルド中にstripコマンドが「このファイル形式は認識出来ん」とエラーを吐く。これは、先にインストールしたH8用のbinutilsに入っているstripではなく、ホスト環境(i386)用のstripを使ってしまっているため。H8用のstripがどこに入っているか調べるには、いかのコマンドを実行する。

% rpm -ql h8-binutils-elf | grep strip

結果、”/usr/local/bin/h8300-elf-strip”としてインストールされているのが分かるので、とりあえずnewlibのリビルド中だけ対症療法としてstripという名前のシンボリックリンクを作っておく。ホストのstripは/usr/bin/stripだが、PATH環境変数によって/usr/binより/usr/local/binを先に見るようになっている。従って、以下のコマンドでリンクを張る。

% cd /usr/local/bin
% ln -sf h8300-elf-strip strip

これで無事ビルド完了。このシンボリックリンクはnewlibのリビルド後に消せば良い。

(※追記: 残念なことにnewlibのSRPMからのビルドは出来なかった)

これだけでクロス開発環境が導入できる。楽ちんである。Macであれだけはまったのは何だったんだろう・・・。

MacBookでマイコン開発(4)

MacPortsからGNUのgcc v4.3を入れたところ、コンパイルに4時間も掛かった・・・orz いくらC以外の言語(C++とかJavaとか)も含まれているとは言え、Core2 Duo 2.0GHzでこんなに掛かるとは・・・。

ちなみに、無事入ったgccでbinutils-2.16.1をh8300-hms向けにコンパイルしたところ、相変わらず以下のエラーが。これはXcodeのgcc v4.0.1でも出る。

checking for gcc... (cached) /opt/local/bin/gcc-mp-4.3
checking whether the C compiler (/opt/local/bin/gcc-mp-4.3 -g -O2 ) works... no
configure: error: installation or configuration problem: C compiler cannot create executables.

gccはちゃんとインストールされているのに、何故”worsk... no”って出ちゃうんでしょう・・・。もう五里霧中です。

とりあえずMac上でのクロス開発環境構築はpendingとします(汗)

# 現在Windows XP Homeが入っている会社PCにVine Linuxをdual bootで入れることにしますです。

ああ、なんか敗北感。

MacBookでマイコン開発(3)

とりあえず、コンパイラが怪しい感じがするのでMacPortsからXcodeとは別のgccを入れることに。

% sudo port install apple-gcc42

インストールは成功するが、インストールされたgcc (v4.2.1)を使ってもbinutilsのビルドが通らない。ウガー！しょうがないので、今度はバージョンを落としてみる。

% sudo port install apple-gcc33

今度は、Intel Mac用のApple版gccにはv3.3が無い事が発覚。更にGNU版gccを試みる。

% sudo port install gcc33

するとビルドエラーでストップ。

Undefined symbols:
"__init_keymgr", referenced from:
___darwin_gcc3_preregister_frame_info in crt2.o
ld: symbol(s) not found for inferred architecture i386

諦めきれずにリビジョンアップしたgcc v3.4もやってみる。

% sudo port install gcc34

やっぱりビルドエラー。

/gcc/gcc.c:1095: error: syntax error before ',' token

なんでこんな初歩的なコンパイルエラーが出るんだろう。
う〜む・・・どうしたものか。

MacBookでマイコン開発(2)

MacOS X Leopard上でのH8 3069向けクロス開発の環境構築にはまっています。ターゲット”h8300-hms”向けのgccクロスコンパイラを準備しなければいけないわけですが、サポートツール(arとかldとか)としてbinutilsパッケージもクロス開発に対応させなければいけません。

ところが、こいつのコンパイルが通らない。やったことは以下の通り。

1. binutils-2.19のソースコードをゲット
2. 適当なところに上記ソースを展開
3. 展開後のbinutils-2.19ディレクトリに移動
4. “build”ディレクトリを作成
5. 上記作成済みディレクトリ内に移動
6. % ../configure --prefix=<パス> --target=h8300-hms
7. % make
8. “This target is no longer supported in gas”というエラーと共にmake失敗

ウガー！！何故なんだー。ちなみに開発ツールとしてLeopardのDVD-ROMから入れたgccのバージョンは以下の通り。

% gcc -v
Using built-in specs.
Target: i686-apple-darwin9
Configured with: /var/tmp/gcc/gcc-5465~16/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=i686-apple-darwin9 --with-arch=apple --with-tune=generic --host=i686-apple-darwin9 --target=i686-apple-darwin9
Thread model: posix
gcc version 4.0.1 (Apple Inc. build 5465)

トラブルシューティングは続く・・・

MacBookでマイコン開発(1)

仕事でH8マイコンをベースにしたソフトウェアの開発をやっているんですが、ここでは備忘録がてら情報を残しておこうと思います。

1. EclipseのC開発環境のTIPS
Eclipse 3.4.1のC開発環境を導入すれば、基本的にMacOS上でのC言語によるソフトウェアの開発の準備はOKですが、1点だけポイントがあります。

Cプロジェクトで[staticライブラリ]を選択するとstaticアーカイブ(拡張子.a)を生成するプロジェクトが作れますが、このプロジェクトのツールチェインを内部ビルダに設定すると、ツールチェインにranlibを実行する段が無く、生成されたstaticアーカイブを実行ファイルとリンクする際にシンボルテーブルが無いと言われてしまいます。

これは、ツールチェインの[GCCアーカイバ]でarのオプションに"-s"を手作業で加えることで回避できます。(元々arのオプションは”-r”なので、結果的に”-rs”となります)

任天堂の苦しい言い訳？

WiFiのWEP暗号化が無意味だという話題が世の中を席捲していますが、PCやPDA等の主要なWiFi機器はWPAに既に対応しているので、設定さえ変えれば特に問題無かったりします。

しかし、世の中に大量に普及していて、WiFi機能があり、更にWEPにしか対応していないという機器があるのです。

そう。それが任天堂DSです。

ITmedia: WEPは一瞬で解読 — ニンテンドーDSはどうなる

IT業界人はゲームも大好き、ということで早速槍玉に挙がっています。まぁ、ああいった低価格なゲーム機器で複数の暗号化方法に対応するのは、製造原価の観点から見送らざるを得なかった判断なのかも知れませんが、任天堂広報室の最後のひと言が面白い。

「ただ乗りはマナー違反。家の鍵が壊れていたからといって、侵入していいというものではない。マナーの向上を期待する」

え〜！家の鍵が壊れていたら、泥棒なら喜んで侵入しますよね？
今問題にしているのは、たまたま脇の甘いWiFi電波をただ乗りするという比較的無害なユーザではなく、そこを踏み台にして悪さをする様な犯罪者ユーザの事なんだと思いますが・・・。

ただ乗りされるだけなら一時的に自分がお金を払っている回線の帯域をタダで使われてしまうだけで、まぁ悔しいという程度で済んでしまう話ですが、仮に犯罪を起こされた場合、侵入されたWiFiを持っている方にISPが割り当てたグローバルIPでインターネットに接続して犯罪を犯すわけで、下手するとWiFiに侵入されてしまった方は無実の罪で捕まってしまうことにもなりかねません。問題にすべきはこういったシチュエーションで、マナーとかそういう次元では無いと思うんですが・・・。

まぁ、広報担当者はITの専門家でもなく、ましてやセキュリティの専門家でも無いんでしょうけれど、ちょっとこのコメントは的外れ過ぎるかなぁ、という気がしました。

WEP暗号化はもはや用を為さず？

あまりに衝撃的な記事を見てしまったので、慌てて自宅と職場の無線LANの暗号化方式をWEPからWPA2に変更しました。

ITmedia - 「WEPを一瞬で解読する方法」を研究者グループ発表　プログラムも公開予定

プログラムが公開されるまでの期間が言わば「執行猶予」だったわけだけれど、もしそんなプログラムが公開されてWEPキーのクラッキングがカジュアルに行えるようになってしまったら、もはやWEP暗号化なんて何の意味も無くなってしまう。

というわけで、この記事を読まれた方は一刻も早くWEPを捨ててWPAもしくはWPA2 (AES暗号)へ！

C言語プリプロセッサ

現在、仕事で組込向けプログラムをC言語で実装しているのですが、ネットで調べても載っていなかったことを備忘録代わりに書いておきます。

C言語のプリプロセッサ命令に文字列結合の”##”という命令があるのですが、ネットのどこを調べても載っていません。私が以前Cを勉強したとき(もうかれこれ10年以上前ですが・・・)には確かに習った記憶があるのですが、最近は教えないんでしょうか？？

ともあれ、手元のコンパイラ(gcc v4.0.1 for MacOS X)ではちゃんと機能しますので、私の記憶違いでは無さそうです。

そういえば、私がCを勉強していたときも、関数ポインタについて記述している書籍は殆ど皆無でしたので、ある意味プロフェッショナル向けの隠し機能みたいな考えられ方をしてるんでしょうかね。

Cプログラミング雑記

すっかりこちらの更新が滞っていました。

最近、C言語でのプログラミングを仕事でやっているんですが、組込向けなので自前でライブラリ関数レベルの機能を実装しなければいけなくて、結構ハマる事もしばしば。

最近ではBASE64エンコード/デコードのコードを書いたのですが、細かなビットシフト演算の部分でミスがあったりして、1週間くらい格闘する羽目に陥りました。結局は全て解決して、やっとちゃんとしたコードになりました。

あともう一つハマったのは、CでBASE64エンコードしたデータを受け取る側のPHPスクリプトの問題です。Content-Typeをapplication/x-www-form-urlencodedで送ると、URLエンコード特有の処理をPHPが裏でやってくれてしまうんですよね。いわゆる、空白文字をプラス文字(+)に置き換えている処理を、PHPスクリプトでは自動デコードしてくれてしまうのです。

BASE64は、アルファベット(A-Za-z)と数字(0-9)と記号(+/)にデータを変換するのですが、URLエンコードの自動でコード処理をされてしまうと、+にエンコードされていたデータが空白に戻されてしまっておかしな事になります。

これもだいぶハマりました。。。

まぁ、うまく行った時の達成感は得がたい物がありますが、C言語は本当に全てがプログラマ任せで大変です。Javaがメインだった頃が懐かしい・・・

Fireworks

今日は、東京湾大華火祭でしたね～。

昨年は、ホテルの高層階にあるレストランで鉄板焼きをほうばりつつ観覧した花火ですが、やはり間近にあの迫力を感じたいということで今年は原点に立ち返り、芝浦埠頭の会場に見に行きました。芝浦では、今まで一般に開放された(とは言いつつ人数制限は有る)会場で見ていましたが、今年は相方が港区民専用の会場をゲットしてくれたので、おかげさまで「19時の花火を観る為に15時から行列して待つ」という荒行をせずに済みました。

ちなみに、今回はクーラーバッグにドリンク＆保冷剤を装備し、行きがけのミッドタウンで食べ物も調達したりして、準備は万端。冷えたドリンクを飲みながらつまみを食べ、ど迫力の花火を楽しむ、という最高な夜でした。東京湾の花火は、とても大きなサイズの玉が高いところまで打ちあがるので、近くで観ると仰角が高く首が痛くなります。ちょうど映画館の最前列で映画を観ている様な感じですかね。

しかし、明日は朝からゴルフ。果たして無事4時半に起床出来るのでしょうか！？

すべらない話

IT史に輝く「すべったテクノロジー」ベスト25 (前編 | 後編)

前々職の同僚の方が日記に書かれていたので読んでみたところ、非常に面白いランキングです。

「すべった」と言うと「失敗した」というイメージが強いかなと思いますが、物によっては「早過ぎた」とか「時代がまだ受け入れる準備をしていなかった」という物もあるかなと思います。気になったものだけピックアップしてみますと:

25位: IBM PS/2

私もリアルタイムでは知らないIBM PS/2ですが、ひと昔前までのパソコンには必ず付いていたPS/2ポート(キーボードとマウスを接続する為に各1つずつある)にその名残がありますね。キーボードとマウスに限定されているとは言え、ここまでしぶとくその名が生き残ったという意味では、何というか執念のような物を感じます。

22位: OpenDoc

実は、OpenDocがもてはやされた頃に私の親は情報システムを担当していて、自宅にあった「OpenDocジェネシス」という本を読んだことがありました。当時の、コンピュータを全く理解していない高校生だった私にはちんぷんかんぷんの内容でしたが、今考えるとOpenDocは非常に先進的な事をやろうとしていたという事が理解できます。ただ、惜しむらくは当時のハードウェア性能ではこれを実用的なレベルにまで引き上げる事が出来なかったのではないだろうかということです。私の理解が正しければ、OpenDocと類似の技術としてMicrosoftのOLEがあり、それらは依然としてMicrosoft Office等のアプリケーションで利用されています。そういった意味では、Appleには先見の明があったのでしょうね。

19位: GNU Hurd

今日のLinuxの繁栄を支えているのは、間違いなくGNUプロジェクトの数々の成果物であり、その為GNUプロジェクトの創始者であるRichard M Stallman (通称RMS)は、「LinuxではなくGNU/Linuxと呼べ」とのたまわっている程です。つまり、Linuxは単なるUNIXライクなカーネルであり、その周りにGNUソフトウェア(例えばbash: Borne Again SHell)を配置する事で、やっと実用的なOSとなるという事を言っているのですね。しかし、面白い事にGNUプロジェクトの根幹たるカーネルは未だ存在せず、その名前はGNU Hurdと呼ばれているが未だにリリースされていません。

GNU Hurdの実用化にどの様な障害が存在するのかは分かりませんが、恐らくはカーネルとしてのLinuxとGNU Hurd以外のGNUソフトウェアとの組み合わせがあまりにもうまく行き過ぎたために、人々がGNU Hurdをそれ程強く望まないことが理由なのではないか、と思われます。もしくは、単にマイクロカーネルを採用するGNU Hurdに、マイクロカーネルに有りがちな性能面などの問題があり、未だに実用に至っていないだけかも知れないですが。ちなみに、その辺りを現実的な選択肢で乗り切ったLinuxは、分類としてはモノリシックカーネルです。

10位: Itanium

Itanium、いやIA64と言った方が良いかも知れないですが、この全く過去との互換性を断ち切った新しい64ビットCPUのアーキテクチャを作り上げるプロジェクトは、現在のところ商業的な成功を収めているとは言い難いかも知れません。しかし、実行時にCPUがアプリケーションの並列性を判断するのではなく、コンパイル時にコンパイラがそれを判断するというアプローチに変えた事は、非常に先見の明があったと言えるのではないでしょうか。

現在、IA32とその64ビット拡張であるx64では、パイプラインの増大と動作クロック向上によるCPU性能の向上は限界を迎え、IPCの高い命令セットで複数のコアをダイに載せるというアプローチに代わりました。しかし、同時に多数のプロセスが走る事が前提のサーバ用途では良いですが、デスクトップ用途ではこんなアプローチは気休めに過ぎないという事は誰でも気付く事だと思います。そもそも同時に走るべきプロセスの数は少なく、アプリケーションは並列化に対応していないとなれば、コアを増やしたところで遊んでしまうだけなわけです。そこでIA64で取り入れられた「コンパイラによる並列化」が活きるのではないかと思うのです。

7位: 64ビットPC

確かに、コンシューマ向けのPCに64ビットのアドレス空間は不要です。しかし、32ビットのアドレス空間、つまり4GBというアドレス空間は、Windows Vistaという非常にgreedyなOSの登場によって、「あるいは食い尽くされてしまうかも知れない」程度のサイズとして認識されるようになったのは確かです。Windows Vistaがユーザに支持されているとは言い難いですが、それでもMicrosoftがこの手のリソース食いなOSを出し続ける場合、必然的に32ビットでは対応しきれないアドレス空間を必要とする日が来るでしょう。それが良いかどうかは別として、ですが。

2位: Windows Vista

今更Vistaについてコメントは不要だと思われますが、私にとっての驚きは、Vistaの価値をWinFSに置いていた人が私以外にも意外に多かった事ですね。少なくとも、Vistaの価値がAeroだなんて、悪い冗談にしか聞こえないです。

*****

さて、皆さんはこの記事を読んでどの様な感想を持たれたでしょうか。

仮想化

ハイパーバイザの価値とは

サーバ仮想化の市場では、先行するVMWareとそれを追従するXenSource、またサーバOSにハイパーバイザを統合したMicrosoftが主立ったプレーヤだ。しかし、それぞれは出自が違うこともあり、仮想化に対する考え方も随分と違う。

元々、VMWareはハイパーバイザ型の仮想化をやっていたわけではなく、後になって製品を追加して対応した。しかし、Xenはそもそもがハイパーバイザの研究から生まれたプロジェクトであり、XenSourceを買収したCitrixがその技術を積極的にMSに供与して作られたのがHyper−Vだ。

ただ、この記事から何となく読み取れるのは、もはやハイパーバイザ機能はサーバ機のハードウェアの一部として、ある種のBIOSの様な形で搭載され、顧客にとってはシームレスな存在として出荷される、という流れが出来つつある事だ。

今後の普及に期待感はあるが、純粋な仮想化技術自体に関して言うと、もはやエキサイティングな状況を過ぎた様に思えるのが少し寂しい。

予想

せっかくなので天童寺 vs 瑞穂を予想してみよう。

とりあえず天童寺から。
多分、ディフェンスはハーフコートマンツーだろうな。明和大日立戦を見てても、これがディフェンスの命っぽいし。瑞穂はアウトサイドに強いから、敢えてゾーンディフェンスにする意味も無さそうだし。多分、スタメンは今までどおりの5人(沢登、剣、如月、北沢、本田)でスタートなんだろうな。

対して、瑞穂は秋田城北戦でも機能した1-3-1ゾーンで行くのだろうか。最初からハーフコートマンツーで行くと、後半は体力的にきつくなるんじゃ？という気もする。ただ、天童寺のアウトサイド攻撃に対する対策は絶対必要だ。

ちょっと考えたのだけれど、チョッ速3Pの本田を押さえるために1年の榎本をディフェンス要員としてマンツーで投入し、他の4人はゾーンを組むという選択肢も有りかと思う。ダイアモンド・ワンって感じかな。そして、もし天童寺が鎌倉まで投入してきたら、哀川がマンツーで当たるトライアングル・ツーだろうか。その場合、残りの三人(藤原、土橋、石井)がどれくらい天童寺のインサイド攻撃をしのげるか、というのが鍵だな。オフェンスを考えると榎本より三浦の方が良いけれど、足を痛めている状況で本田にマンツーで付くのはきつそう。もしくは、榎本ではなくて高階を使うのかな。

うーむ、イマイチ良いアイデアが思い浮かばない。ていうか天童寺強過ぎ。次元が違う。

長い・・・

天童寺 vs 明和大日立の試合が長い。。。

天童寺の強さと、瑞穂がそれをどう攻めるかという今後の展開について提示したいのだろうが、主役が絡まない試合にしてはいい加減に長過ぎる気がする。そして、頑張ったんだけどやっぱり勝てそうにない明和大日立。結局、この試合の結論は、天童寺は強過ぎたという事なのだろうか。

目の前の成田中央に勝たなければ何も始まらないのだが、瑞穂はどうやって天童寺を攻略するのだろうか。この明和大日立戦のせいで目前の成田中央戦が霞んでしまい、天童寺との来るべき決勝ばかりが気になる。

MSフリーなデスクトップPC

IBM、“MSフリー”なデスクトップPC提供へ

「MSフリーな」つまりMicrosoft社のソフトウェアに非依存なデスクトップPCを作り出すには、以下の構成要素が必要不可欠だったと思う。

1. Windowsに代わる実用的なデスクトップOS
2. Internet Explorerに代わる実用的なウェブブラウザ
3. Microsoft Officeに代わる実用的なプロダクティビティスイート

上記2については、かつてのNetscapeの流れをくむMozilla Firefoxが早いうちから登場していたが、1と3については中々現実的な選択肢が無い状態が続いていた。しかし、1についてはUbuntu Linuxが、3についてはOpenOffice.orgが登場した事で、一気に駒が揃った感がある。

賛否両論はあるものの、IBMはOpenOffice.orgをベースにLotus Symphonyをリリースし、MSフリーなデスクトップPCの流れに本格的に参入した形だ。そして、今回のハードウェアも含めた提供開始は、これから始まる過酷な戦いを暗示させるものであると思われる。

ショッキンぐ〜

そう言えば、先日ゴルフに行った帰りに高速道路のS.A.で給油したら、GSのお兄さんが「右後ろのブレーキランプのバルブが切れてますよ」と言ってたので、愛車を点検と部品交換に出さなくちゃなあと思ってネットで検索していたら、何と愛車が既に販売中止になっていたことを知った。ショーック！

まぁ、某トヨタに似合わない4WDターボな車だったので、いずれ近い将来に無くなるだろうとは思っていたけれど、フルチェン直後の購入から5年を待たずして販売中止とは。。。

昨年の春にタービンからのオイル漏れでタービンブロー＆エンジンブローを経験し、タービンとシリンダブロック、一部ピストンの総とっかえ(＠メーカー保証)を行ったのだけれど、今後の保守が気になるので今度点検のついでに聞いてみることにしようっと。

話は変わるが、@ITの連載「いまさら聞けない エンジン設計入門」が面白過ぎる。IT系のウェブ媒体にも関わらず、初歩とは言え自動車のメカに関するガチな説明が満載だ。しかも、実際の部品の写真を見ながらの解説はとても分かり易い。

無限の誘惑

パケット定額値下げキター!!!!

ソフトバンク、パケット定額フルを改定、iPhone 3Gは月額2990円から・メール無期限保存へ

もはや、私がiPhone 3Gを購入することを阻む壁は全て取り払われました。せいぜい本体の重さ位でしょうか。あぁ、今すぐにソフバンショップにダッシュしたい。。。

いいえ、それも仕様です

昨日日記に書いたApple MobileMeの不具合(とおぼしき事象)だが、本日進展有り。

なんと、受信トレイ以外のフォルダも表示された！・・・1個だけだが・・・orz

勿論、私のメールボックスには100以上のフォルダがあるので、これも明らかに不審な挙動。

えぇぃ！どうにかならぬものなのか！！

街並み

Googleマップの「ストリートビュー」に日本の街路写真

何に使うのか、実用性の観点からするとイマイチ私の駄目な頭では理解に苦しむのですが、単に楽しむという点ではこの上なく楽しめる機能ですね。私の自宅前の道路、私の実家前の道路、そして弊社オフィス前の道路、などなど、「そんな場所の写真までGoogleちゃんに掲載されてるの!?」という小市民的喜びを得るにはもってこいの機能である気がします。

現在は首都圏のみを網羅しているっぽいですが、細い道路までかなりのカバレッジですので、次は是非地方へ進出して頂きたいところです。

ありえない続報

NTTひかり電話の不具合ですが、弊社ひかり電話のルータはビンゴでした(爆)

ただ、導入時期から計算すると7月20日辺りに不具合を起こしていておかしくない筈ですので、運が良かったのか不具合の発生しない個体だったのか分かりませんが、とりあえず問題は無い様です。

+++++

さて、先ほど弊社オフィスのある千代田区三番町地方は激しい雷雨に見舞われ、11:45頃～12:45頃はまるで東南アジアのスコールの様な雨が降り、道路は川の様になっていました。しかし、一旦雨が弱まり始めると(弱まる、とは言っても豪雨状態との比較論ですが・・・)、路面を覆い尽くしていた水はサーっと引いていき、5分も経たずに元通り。凄い排水システムです。さすがに税金が有り余っている千代田区らしいです。

ありえない

イー・モバイルのCMではない。

ＮＴＴひかり電話１２６万台、２４９日使用で発着不能に

えー！何すかそのしょうもない不具合は。。。

ちなみに、弊社でもひかり電話を使っているので、この問題に該当する機種かどうかを調べなければいけません。導入は昨年の11月半ばだったと思うので、当該機種なら間もなくビンゴです。

+++++

話は変わりますが、例の首都高池袋線での火災は、そう簡単に復旧しないみたいですね。短くて数週間、長ければ数ヶ月とか。。。それはそうですよね、14キロリットルものガソリンが5時間も燃え続けたわけですから、その熱と炎にさらされた首都高の橋桁や路面へのダメージは相当なものかと。。。

復旧に掛かるコストは少なくとも数億円だそうです。事故を起こしたタンクローリーが所属する会社への損害賠償請求は必至ですね。首都高が使えない事による迷惑や周辺道路、迂回路の渋滞による経済損失まで考えたら、もっと大変なことになりますね。

ハンドルを握るということは、場合によってはとんでもない結果に行き着く、ということを改めて実感させられました。自分も気を付けないと。

不具合ですか？いえ、それは仕様です。

.Mac (dot mac)がiPhone 3Gのリリースと同時にMobileMeになりましたが、どうもMobileMeは不具合が多発している様ですね。

私は旧.Macメールをプライベートなメールアカウントのメインに使っているんですが、最近Mozilla ThunderbirdからのIMAP4アクセスで受信トレイ以外が見えなくなりました。

なんやねんそれ！とつっこみを入れたくなりますが、とりあえず自宅のMacBookではThunderbirdを捨ててApple Mailに戻ることに。さすがに、Apple Mailではちゃんと動きますね > MobileMe

まぁ、元々Apple Mailは結構気に入っていて、何故かCPUを100% (Core2 Duoの両コアとも) 使い切るという暴走をする前はこれがデフォルトだったので、戻っても全然問題はないのです。そもそも、メールはMobileMe (IMAP4)やGMailがメインですので。

とりあえず、釈然としない理由ではあるものの、Apple Mailに出戻ってきました。後は、会社のWindowsマシンでどうするか、という点が残りますね。。。

よもやま

タンクローリー炎上の首都高、復旧めど立たず…周辺が混雑

事故の速報を聞いた時から嫌な予感がしていましたが、やはり復旧には長い時間が掛かりそうです。実は、来週のゴルフではまさにこの首都高池袋線を使おうとしていたので、今週中の復旧を期待したいのですが。。。もしダメな場合、6号向島線からC2経由で東北道に入るルートになります。迂回ルートに車が殺到して渋滞、なんて羽目にはなりたくないです。

+++++

ところで、自宅のMacBookのWiFi (11g)が物凄く不安定でブチブチ切れるので気になっていたのですが、どうもMicrosoftのワイアレスマウスとコンフリクトしているのではないかという気がして、マウスの利用を止めたところ安定してくれました。おやまあ何というか・・・。

ワイアレスマウスは、MSだけでなくロジクール(Logitech)でも2.5GHz帯付近で独自の無線通信をしていたりして、2.5GHz帯のWiFiとぶつかりそうな悪寒はしていたのですが、どうも本当にぶつかっていた様です。

こればっかりはどうしようもないので、MacBookがBluetooth標準搭載なのを良いことに、Bluetoothワイアレスマウスに代えようかな、なんてことを妄想しています。

暴落

ついにここまで（涙）— 1TバイトHDDがまさかの1万円割れ

キャンペーンとはいえ、遂に1万円で1TB HDDが買える様になった模様です。つまり、1円で100MBという計算です。

昔、1995年夏に初めて自宅で買ったDOS/V PC (この呼び名も懐かしい) は、無印Pentium CPU (50MHz)、8MBのSDRAM、520MBの無印ATA HDD、Windows 3.1を搭載し17インチCRT付きで27万円 (！) でした。恐らく、この頃のHDDは100MBで1万円程度であったと思われます。

つまり、この13年でHDDの価格は1万分の1に下がったということなのですね。。。物凄い暴落っぷりですね。

ソフトウェア企業の社会的責務

Notes/Dominoユーザーが立つ岐路 - 企業のコラボレーション基盤を考える

この記事の趣旨とは違うが、読んでいてふとソフトウェア企業、いわゆるソフトウェアベンダの社会的責務について考えた。

ソフトウェアの世界は非常に進歩が激しい為、短くて1年、長くて3年といったサイクルで新しいバージョンが提供されていく。しかし、それによって当然「旧バージョン」が作り出され、それらはいずれベンダからサポートされなくなっていく。

最近のニュースとしては、Windows XPのサポート終了に関する話題が最も身近だろうか。

こういった状況では、「現行バージョン」の顧客をいかに「新バージョン」に移行させるか、ということが課題となる。ベンダにとっては、「新バージョン」を「有償で購入してもらう事による売上」という側面と、「旧バージョン」の「サポートを続けるコストの削減(もしくは撤廃)」という側面の両面で、この移行作業は重要だ。

しかし、全くもって明白なのは、これらのどちらもがベンダにとってのメリットであり、顧客にとってのメリットではない、というところだ。

さて、そんな顧客にとってメリットの無い選択肢を顧客に受け入れてもらう為に、ベンダが自らの行為を正当化する武器は何かと言うと、「新バージョン」における「機能強化」、「機能追加」、「性能強化」、等々のお題目である。

それらのお題目が仮に真実だったとしても、ここには一つの可能性が残る。つまり、顧客はそれらお題目のどれも必要としていない可能性、である。

この場合、顧客には二つの選択肢がある。一つには、ベンダの言うことを聞いて嫌々ながら「新バージョン」に移行するか、もしくはベンダの言うことから顔を背けて「旧バージョン」を使い続けるか(そしてベンダからのサポートをいずれ失うか)、だ。

上記のLotus Notesの記事は、まさにこの状況について書いていた物だ。

さて、私はどちらかというとソフトウェアを作る側の人間であるので、立場としてはベンダに近いわけなのだが、この様な現状にとても違和感を覚える。何と言うか、「サポートの終了を人質に新バージョンを顧客に押し売りしている」気がしてしまうのだ。

ソフトウェアベンダは、こんな事をしていて良いのだろうか。

勿論、ビジネスでソフトウェアを開発し販売している以上、ビジネスにならない事は出来ない。しかし、今までの「常に新バージョンを作り続け、それを売る」というビジネスと「(顧客が望む場合は)旧バージョンのサポートも続ける」という行為は、果たして両立出来ない物なのだろうか。仮に旧バージョンのサポートを続ける事がビジネスベースでは難しいのであれば、オープンソースソフトウェア開発というモデルを利用してそれを行う事は出来ないのであろうか。

社名は失念してしまったが、新バージョンを商用ソフトとして販売し、旧バージョンはオープンソースにして公開する、というやり方を行っていたソフトウェアベンダの話を聞いた事がある気がする。しかし、残念ながら未だにそれを行っている会社が増えているとは耳にしない。

何と言うか、個人的には傲慢にも思えてしまうこのベンダの姿勢は、今後変えていかなければならないものである様に思える。そうしないと、業界全体が何か大きなしっぺ返しを喰うことになってしまう様な、そんな気にさえなるのだ。

待ち遠しい

先日、久々のラウンドを楽しんで来た(というかコース中をダッシュしてきた)わけなんですが、また近々ラウンドすることになりました！今度は、豪華リゾート地で温泉付き、なんてことではなく普通に日帰りなんですが、今から楽しみです。遠足前日の子供みたいになってます。

にしても、ラウンド前に一度くらいは打ちっ放しに行った方が良いかしらん。。。

前回のラウンドでは、1日目はドライバーがバッチリだったのに2日目はドライバーが死亡(全てフック。信じられない程フック。引っかけまくり。打つ手無し)だったので、ドライバーを練習した方がいい気がする。もしくは前回2日目の様に、ドライバーは封印してティーショットからウッドを使う、という手もあるが。

後は、アプローチが要練習か。特に、短い距離(50ヤード以下)でトップするのを何とかしたい。

うむぅ。こうしてはいられぬ。。。

罠

まずはこちらのコードをご覧頂きたい。

unsigned char i;

for (i=0; i<256; i++){
...statement...
}

さて、このコードを実行するとどうなるだろうか？

答えは、無限ループする、なのである。
直感的にこの答えが分かった方は素敵なCプログラマだ。

備忘録

秋月電子のH8 3069Fボードで開発を行っているのだが、基板裏面に半田付け済の外付け16Mbit RAMチップのアドレスが分からず暫く往生していた。しかし、ググ先生にお伺いを立てたところ「AKI-H8/3069F」のページを発見し、参考にさせて頂く事が出来た。「ちなみに16Mbits DRAMはH8/3069RFのCS1でアドレスデコードされ、0x400000〜 0x5fffffに割り当てられます。」とのこと。有難や。

どおりで一生懸命0x080000にデータを書いても意味がないわけだ(笑)。

にしても、どうやったらこの外部メモリのアドレスを知ることが出来るのだろう。。。うぅむ、組込は奥が深い。

C

久々にmakeしちゃったりして、Cでプログラム書いちゃったりして。

にしても、makeって本当に分かり難いsyntaxだよね。。。
Antの方が優れているということが実感される。

しかし、makeとCの組み合わせは本当に処理が早い。
まさに「ネイティブ」という感じの動作速度。
Pentium M 900MHzという2世代くらい前のVAIOモバイルノートでも、へっちゃらでコンパイル可能。

迂闊

うっかり、5Vの基板に6V 2Aの電源を接続してしまっていた(汗)!!
5Vの電源ゲットしなくちゃ。。。

完遂

やっとEmperorを突破。パワーアップ2.0とクレジット+10でやっとこさ、というていたらく。今でも、Strength辺りから辛い。Magicianもイマイチ勝ちパターンが掴めていない状況。

日本語化

MySQL 5 (正確にはバージョン5.1) のリファレンスマニュアルが日本語化されている事に気付いた。

ここ1年半ほどMySQLとPHPでの開発をしていたが、日本語のリファレンスマニュアルはバージョン4までしか無かったので、バージョン4と5の差分は英語のリファレンスマニュアルを読んでしのいでいたが、ここに来て日本語版が出てくれたことは非常に助かる。

MySQL 4には、RDBMSとしてはちょっと信じがたいのだが、viewが無かったりするのだ。MySQLを使って行くには、やはりバージョン5を使いこなす事が必要に思う。

エンジニアにも英語力は必要だと思うし、自分も仕事で英語の読み書きは毎日の様に行っているけれど、やはり母国語での処理能力に比べると格段に劣ってしまう。

マニュアルの翻訳という地道な作業でオープンソースソフトウェアの普及に貢献されている方々に感謝したい。

CPAN

前の日記でCPANにDBD::mysqlをインストールしたが、その際にはビルドエラーが発生する場合がある。ちなみに、私の場合は発生した。

解決方法に関しては、[[mac][perl]Mac OS XにDBD::mysqlをインストールする]を参考にさせて頂く。もしかすると、MacOS XでPerlとDBD::mysqlを使う場合特有の問題かも知れない。

ちなみに、"DBD::MySQL"の様にMySQLとキャピタリゼーションして表記するのは間違いの様だ。"DBD::mysql"と小文字で書くのが正しい。

林檎と真珠

私のMacBookは、主としてドキュメント作成と画像編集にしか使っておらず、以前は仕事でプログラムも書いたのだがそれでもPHPやJavaで事足りていた。しかし、最近になってDBアクセスも含めてPerlを使いこなす必要が生じた為、急遽環境を整備する必要に。

PerlのDBアクセスはDBIというフレームワークを使うのが一般的で、私のMacにも既にPerlとDBIはインストールされている。しかし、MySQLへ接続する為の個別のモジュール(DBD)が無い為、CPANを使ってDBD::MySQLを入れることにする。

私はPerl歴は結構長いのだがCPANはあまり使ったことが無かったので、[CPAN経由でLinuxにモジュールを組み込む]を参考にさせて頂き、CPANをチェックしてみる。

% perl -MCPAN -e shell

すると、手動でのCPAN設定が開始される。ここで気付いたのが、CPANに必要なlynxやwget等のツールが無いということ。通常のMacOS X向けのユニバーサルバイナリを探したのだが、ネット上にはtar-ballからのインストール情報が溢れていたので、気を取り直してMacPortsを使うことにする。

というか、MacBookを使い始めてもう1年半以上経つのに、未だにMacPortsを入れていないことがバレてしまった。。。UNIX使いとして失格である。

さて、MacPortsというパッケージシステム自体はユニバーサルバイナリで提供されている為、MacPortsのサイトからダウンロードする。

画面左側のメニューから[Installing MacPorts]をクリックし、画面右側のリンク[Leopard (Universal)]をダウンロードし、MacPortsをインストールする。但し、画面右側の下部に記載されている様に、MacOS X 10.5 LeopardではXcode 3.0がインストールされている必要がある。私のMacBookには既にインストールされているので問題ないが、未導入の場合はMacBook付属のCD-ROMからインストールする必要がある。

MacPortsが入ったら、後はターミナルで操作を行う。

MacPortsでインストールしたいパッケージ(hoge)を検索する際:
% port search hoge

MacPortsでパッケージ(hoge)のオプションを検索する際:
% port variants hoge

MacPortsでパッケージ(hoge)をインストールする際:
% sudo port install hoge

後は、MacPortsを使って必要なコマンドをインストールする。

注意点としては、CPANが要求するコマンド名と、MacPortsのパッケージ名が必ずしも一致しない事だ。lynxコマンドやwgetコマンドはパッケージ名もlynx及びwgetだが、ncftpgetコマンドのパッケージ名はncftpであり、gpgコマンドのパッケージ名はgnupgだ。

後は設定に関する質問に答えていけば、CPANの設定は完了する。

CPANの設定が完了するとCPANのコマンドラインプロンプトが表示されるので、やっと念願であったDBD::MySQLのインストールが出来る。インストールは以下のコマンドで実行する。

cpan> install Bundle::DBD::MySQL

ちなみに、このインストール作業中にCPAN自体のアップデート(？)も推奨されるので、以下のコマンドも実行する。

cpan> install Bundle::CPAN
cpan> reload cpan

以上で(やっとこさ) PerlスクリプトからMySQLに接続する準備が整った。さて、書くか。。。

変貌

昨日は、仕事で使うパーツを調達しに、久々に秋葉原の地を踏みました。以前、2年ほど前にビジネスパートナーのフランス人を案内してお土産を買うのに付き合いましたが、パーツ漁りという観点からは4年ぶりくらいです。

今回は、秋葉原の変貌ぶりを目の当たりにして、かなり驚きました。お店が無くなっていたり、場所を変えていたり、一群の小さなお店が消えて大きなマンションの建設現場に変わっていたりと、街の再開発が進んでいる事が実感されました。特に、駅の直近は全く過去の面影をなくしていました。

平日と言うこともありましたが、PCのパーツショップも随分と空いている感じがしました。私が大学生だった10年ほど前には、平日でももっと多くのお客さんが来ていた気がします。PCの自作が価格的な優位性を失った事が主原因でしょうか。代わって、パーツショップ独自ブランドのホワイトボックスPCが店内で幅を利かせていました。主なアピールポイントは強烈なグラフィックス性能のようで、いわゆるゲーミングPCの様でした。

ついでにこちらも初体験のヨドバシAkibaに寄ったのですが、広過ぎて閉口しました。しかも、それだけ広いのに買おうとしていたパーツが無く、その点はがっかりでした。仕方なしに有楽町のビックにも寄りましたが、そちらにはちゃんと目的のパーツが数種類置いてありました。広さとしても程よく、ヨドバシAkibaに比べて何となく安心を感じさせます。

ともあれ、久々の秋葉原は良い経験になりました。秋月は昔のままでしたし、一部のショップ(ドスパラ, クレバリー, フェイス)は昔と同じ場所で健在でしたので。千石が随分と小綺麗になっていたのがビックリでしたが。

週末

この週末は、相方のご両親にお招き頂いて避暑地でのゴルフと温泉を堪能させて頂きました。

ゴルフは、久々のラウンドであり練習もここ3ヶ月位していなかった為、初日は1ホール目から大叩きしてコース中をランニングする羽目に。汗をたっぷりかいて健康的でしたが、起伏のあるコースをあちこち走ったせいでかなり膝に負担が掛かり、ラウンド後は下り階段がかなり辛い状態に。そして、翌日はお約束の全身筋肉痛・・・orz

# 最近の運動不足をしっかり実感する出来事でした。

しかし、それでもやはりゴルフは楽しいです。今回のラウンドでは井上誠一という有名なゴルフコース設計者の方が設計されたコースを回ったのですが、色々な意味で素晴らしいコースだなと感じました。その素晴らしさを感じるには実際にコースを見て頂くのが一番ですが、敢えて言葉で表現するならば、自然を活かした美しいコース設計とそこに隠されたチャレンジングな設定、といったところでしょうか。ティーグラウンドから眺める際にはコースの美しさが際立ちますが、実際にそこを攻める際には様々な罠が隠されています。また、全てのグリーンがフラットではなく、様々な方向に向かって加えられた僅かな傾斜によって、挑戦者のカップインを阻みます。

今回のラウンドでは、実力相応と言うか、まぁひとことで言うととんでもないスコア(笑)を叩いてしまったのですが、このコースを思い通りに攻められたら楽しいだろうなあ、とつくづく実感しました。何度も回ってみたいコースです。

さて、今回のラウンドではTaylorMadeのr7フェアウェイウッドが実戦に初投入されたのですが、これが素晴らしく飛びます。改心のショットが出た時の快感は何とも言い難いです。元々、ウッドの必要性は以前アメリカでラウンドした時にロングホールで実感していたのですが、今回のラウンドで400ヤード程度のミドルホールでもかなり使えることが分かりました。今は5番しか持っていないんですが、是非3番とか7番も使いこなしたいです。(TaylorMadeの店員さんに「3番は難しいですよ」と言われて、とりあえずは5番を買ったのでした)

また、頂き物の本間のアイアンセットも今回が実戦初投入でした。やはり頂き物で前回ラウンドまで使っていたBen Hogan APEXよりも、かなり打ち易いと感じました。シャフト重量はあまり変わっていないと思うのですが、マッスルバックとキャビティの違いが出ているのかも知れません。ロングアイアンはまだまだ難しいのですが、5番以降は結構使いこなせる様になったと思います。(初心者なので気のせいかも知れませんが、、、)

ところで、今日の東京の天気はどうだったのか分かりませんが、私の滞在していた妙高高原では午後1時半頃から激しい雷鳴が轟き、その後はかなり激しい雨が降りました。当初雷が鳴り出した頃はまだ曇り空だったので普通に2日目のラウンドを楽しんでいたのですが、突如かなり近くに大きな雷が落ちてビックリしました。当然クラブの指示でゲームは中止となり、急いでクラブハウスに戻ったあと、そのままホテルに帰りました。

ゴルフ場で落雷を身近に経験する怖さは、遭った人でないと分からないと思いますが、本当に怖いです。大学時代に見学した人工雷の実験なんて比較にならないですね。

ともあれ、週末のゴルフと温泉は、このところ疲れていた心身を非常にリフレッシュしてくれました。もっとゴルフの練習して、もっと思い通りのショット、アプローチ、パットが出来るようになって、より良いスコアを出したいと思います。

素晴らしい機会をプレゼントして下さった相方のご両親と相方に感謝です！

ノキアがTrollTechを買収

ノキア、オープンソース企業Trolltechを買収

TrollTechと言えば、クロスプラットフォームのGUIツールキット「Qt」の開発元です。Linux等で使われているKDEデスクトップ環境のベースになっているQtですが、LinuxだけでなくWindowsにも移植されており、PC環境でもクロスプラットフォーム性が高いツールキットです。そして、Qtは更に携帯電話などの組み込み環境でも使える為に、今回の買収劇に至ったのだと思われます。

さて、Qtは非商用利用時のオープンソースライセンスと商用利用時のライセンスのデュアルライセンス方式だった筈ですが、Nokiaによる買収後もオープンソースの方針は維持されるそうです。

オープンソース陣営にとってはひと安心ですね。

仮想化プロジェクトフェーズ1失敗に終わる

どうも、素のXenはイマイチかも知れないと思えてきた。

Windows XP Professionalを完全仮想化でゲストOSに仕立て上げたのだが、何かの拍子で起動時にセーフモードに入る様になってしまい、仮想マシンコンソールが繋がらなくなってしまった。

これではWindows相手に手も足も出ないので断念することに。Xenはもはやスッパリと諦めて、Fedora Core 8にインストールしたXen関連のパッケージを全てyumで抹殺。おもむろにLinux版VMware Serverを入れることに。

vmware-config.plを実行するとカーネルのコンパイルに入るのだが、ここで失敗してしまう。ネットを検索するとany-anyなるものがあるらしいのでそれを使う。

しかし、今気付いたのだが、私の入れたVMware Server 1.0.3は古いらしく、any-anyの要らない1.0.4がもう出ている様だ。ガーン。VMwareのサイトで全く見落としてた。。。目が節穴だ。。。しくしく。

とりあえずVMwareはインストール後は良い感じ。早速Windows XP ProfessionalとUbuntuの環境を作成することに。

ガチなのかどうか - .NET版Emacs

Microsoftが.NET版のEmacsエディタを開発するという噂が。

確かに、EmacsはUNIX系OSにおいてviと双璧をなすエディタであり、Emacs派対vi派の戦いはもはや宗教戦争の様相を呈している。EmacsはそれだけUNIX系OSでは有名なエディタなのであるが、.NET版のEmacsエディタを作っただけでUNIX系OSの開発者をWindowsに取り込めるかどうかは疑問だ。

まぁ、とは言いつつ、UNIX系OSの開発者がWindowsを開発環境として使わない理由は、

• まともなエディタがあまり無い
• シェルが貧弱
• フリーの良い開発環境があまり無い

というのが三大要因だと思われるので、.NET版Emacsはその一つを解消するのかも知れない。

ちなみに、私はEmacs派であり、LinuxではGNU Emacs、MacOS XではCarbon Emacs(X11ではなくMacOS Xネイティブのグラフィックスシステムに対応したEmacs)を使っている。Windowsでは秀丸エディタにEmacsキーバインドを仕込んでいるが、中途半端なので我慢ならないところだ。

そういう意味では、.NET版のEmacsが出たら使ってみたい気もする。但し、重たくないのが絶対条件だ。

まぁ、例え使ってみるにしても、メインの開発環境はMacOS Xのままであるのは変わりないが。

新年早々仮想化

新年早々、仕事に関連してやりたかったが、今まで時間が無くて出来なかったことをやってみる。それは、Xenによる仮想化。

まず、ディスク管理ツール代わりのKNOPPIX (CD-ROM起動可能なLinuxディストリビューション)を起動し、仕事で使っているDELL Latitude D520というラップトップPCにプリインストールされた、diagツール専用の隠しパーティション及びWindows XP Professionalのパーティションを、おもむろに完全抹殺。Fedora Coreインストール用に、色々と考えてパーティション作成を実施。(以下の様な感じ)

• /boot 100MB
• / 1GB
• /var 5GB
• /tmp 5GB
• /usr 5GB
• /usr/local 5GB
• /opt 10GB
• /home 43GB

Fedora Core 8の導入は、普通に日本語版のインストールDVD ISOイメージをダウンロードし、インストールするだけで完了。GUIベースのインストーラで、まるでWindowsの様に簡単にインストールが完了。グラフィックスも問題無くチップを認識し、XGAでGNOMEが起動。

これだけではXenは有効化され無いので、Xen関連パッケージを以下のコマンドでインストール。

% yum install xen kernel-xen

これだけで、Xenに必要なパッケージがサクサク依存関係解決がてらインストールされる。
まったく便利になったものだ。

ここでブートローダGRUBの設定(/etc/grub.conf)を変更し、Xenのカーネルから起動する様にする。Xenのカーネルの起動に必要な設定は既にgrub.confに書かれているので、デフォルトで起動するカーネルの指定を、非XenのカーネルからXenのカーネルに変えるだけで良い。

そしてシステムを再起動。

起動時には、まずはXenの起動画面が表示され、すぐにDomain-0であるFedora Core 8の起動画面に切り替わる。無事にGNOMEが起動され、Xenのカーネルによる起動が完了。

次に、これだけではXenの利用が面倒なので、仮想マシン管理ツールをインストール。

% yum install virt-manager

これでインストール完了。

GNOMEの[アプリケーション]メニューから[システムツール]→[仮想マシンマネージャ]と選択すると、仮想マシンマネージャが起動される。ここで一覧の[localhost]を選択し、右クリックして[起動]を選択すると、無事にDomain-0に接続される。

Fedora Core 8のインストールにだいぶ時間は掛かったものの、特につまづく点も無くXenが導入できてしまった。素晴らしい。そして今このブログはFedora Core上のFirefoxから書いている。日本語入力もまったく問題無し。感動的だ。

次はWindowsの仮想マシン構築について書こうと思う。