シリアルポート(COM1)に順調にメッセージが流れ、Angstromのロゴが出て無事に立ち上がったようだ。ソフトキーボードのログイン画面が出た。さあ、キーボードが入るか。おおお、ちゃんとパスワード入力がキーボードからできる。Enlightmentの画面に替った。マウスは?これも問題ない。何の問題もなく認識するではないか。ブートメッセージを見ていくと、キーボードの型番までしっかり出ている。昔のLinuxとは大違いだ。海外の情報を頼りに新しいI/Oディバイスを認識させるのが、インストールのときの大仕事だった。次は一番問題のLANだ。うまくいったので調子に乗って、動いたままUSB-LANを接続する。活線挿抜というやつだ。ほほう、何か動き始めたぞ。eth0が設定されたが、downしているというメッセージが出た。eth0とすると、IPアドレスが定義されていない。やれやれこれは自分でやれと言うことか。これが、ちょっと前までさんざん使っていたコマンドがもう思い出せない。gatewayはどこだ。eth0を入れてみたら、さっき定義したIPアドレスが変わっている。DHCPが動いたのか。物は試しと、Elightmentのウェブブラウザーを立ち上げて見る。何と、何と、ネットがつながっている。Mogillaの初期画面が出た!いやあきれたものだ。何もしないで、全部つながってしまった。日本語フォントが入っていないので字化けしているが間違いない。余りにも簡単にイーサネットが動いてしまってあっけにとられるばかりだ。一区切りがついて考えた。BeagleBoardは明らかに今までの組み込みコンピューターとは違う。要するに、小さなボードで電子工作っぽいけれど、もう、ここまで来ると、これは電子工作ではない。ここはLinuxと変わらない。ハードに素人が立ち入る隙がもうないのだ。それにソフトウエアの規模が大きすぎる。ARM7あたりまでは、まだソースを追いかける気力があるが、このレベルでは無理だ。これはこれで昔、Linuxにはまっていたから、がた老「AVR」研究所としては研究の意味はあるが、8ビットの石を工夫して機械にしているときの、わくわくする気持ちがない。嬉しいことに、このあいだのSDカードのLPCMプレーヤーは、周りの複数の人から発注を受けて量産を考えなければいけなくなった。プリント基板制作に挑戦しようかとも考えているが、電池ホルダーが難物だ。これの自作はちょっと大変だが、物を作る喜びは、こちらの方が大きい。BeagleBoardは、ケースを考えたり、日本語フォントのインストール、それとウェブサーバーとしての能力をテストする課題などが残っているが、これはもう電子工作とは別の次元の話だ。老AVR研究所としては、BeagleBoardは余技としておこう。本業はあくまでもAVRクラスだ(最近はARMばっかりだけど)。(月)ダブルバッファーでUSB仮想UARTの内部速度が2Mbpsしゃれた実装を考えたが挫折(5/28/09)SysTickタイマーで1ms単位の経過時間が測れるようになったので、勇躍、STM32基板のUSB仮想UARTの高速化にとりかかった。これまでにわかっていることは、UARTの速度が遅いときは問題ないが、早くなってくるとエンドポイントの送信終了の割込みがユーザープログラムがデータを移している最中に入り、このときのデータサイズが実際のデータと不整合が生じてデータが欠落する。これはSTマイクロが提供するSTM32F(Cortex-M3)用のVCPデモプログラムに最初からあった問題で、STマイクロのフォーラムで去年話題になり議論されていた。少なくとも私の知る限りまだ解決していないはずである。SysTickを使って改修されたコードがアップされたが、その後本人が動かないとして取り下げている。この解決を当研究所がやろうというのである。うまく行けば鼻が高い。方式はダブルバッファー方式である。前のDACのデコードと同じような考え方だ。ひとつのバッファーをユーザーの送信関数の書き込み用とし、ここに送信データを入れていく。送信関数ではエンドポイントに直接書き込まない。ここで書き込むと、書き込み終了の割り込みがどこで起きるかわからないからである。ひとつのバッファーは、割込みルーチンが既に書き込み処理をしたデータが入っている。書き込み終了の割込みがかかり、割込みルーチンに制御が渡ったときに、バッファーをスイッチして、今度は送信関数が書き溜めていたデータをエンドポイントに書き込む。さきほど送り終わったバッファーが今度は送信関数が新たに書き込むバッファーとなる。これで、データ書き込みと送り出しの衝突を避けることができる。最初、コードを少なくするため、2組必要なバッファー配列とカウンターをポインター変数にし、そのアドレスをスイッチして動くようなスマートな方式でコードを組んだ。送信バイト;みたいなプロっぽいコードである。バッファーアドレスとカウンターポインターを取り替えるだけで、main.cの送信関数USB_Putc()はダブルバッファーであることを知らないで済む。いやコーディング技術も格段に進歩したものだ、と、得意になって完成させた。ロジックはそう難しいものではない。気をつけないといけないところは、バッファーを切り替えるときに、ユーザープログラムの実行と重ならないように、フラグを立てて守るということである。今度は、割込みルーチンが見えているので、ユーザー側は、そのフラグを見て待てばよい。これが全くうんともすんとも言わないのである。さっきのステートメントのところで暴走している。表記に間違いはないはずだ。何度もウェブなどで確かめる。うーむ、何か勘違いがあるのだろうか。プログラムはまさしく考えたようには動かない。書いたように動くだけだ。いずれにしても、ポインターを使ったコーディングは一歩間違えば、とんでもないところにデータを書き込み、簡単に暴走してしまう。いじったが好転しない。悩んだ挙句、この方法をとりあえずあきらめ、普通の配列を使い、愚直に2組のバッファーを別々に操作するルーチンに切り替えた。これなら暴走しようがない。ありゃりゃあ、これでも動かない。シングルバッファーに戻すと何事もなく動く。このあたりでGDBが使えれば良いのだが、今のままでは、USBを使っているので初期化の段階で、HardFaultに落ちてしまいメインループに来ない。環境を大きく換えないと使えない。別のUARTで変数を出してデバッグする手もあるが、どちらも手間がかかる。ダブルバッファーが動いた!しかしこれで良いのか(5/29/09)開発が暗礁に乗り上げている。マラソンや登山と同じだ。この苦しみが歓喜の材料なのだが、その最中はそれどころではない。大げさに言えば人生が暗い。今まで生きてきたことすべてが意味のない時間だったような気分になる。BeagleBoardのために久しぶりにモニターを取り替え、1920x1080のワイドディスプレイになって開発環境は一変し(エディターと端末が同時に見られる)、快適になったのだが、気分は優れない。救いは、このあいだの第三のファーム書き込み手法ROMのフラッシュローダーが思いのほか使い勝手が良く、プログラムの修正、ビルド、ファーム書き込みのサイクルが飛躍的に早くなったことである。AVRなみの開発環境である。Eclipseは編集とビルドだけにしか使っていないが、これはこれで便利だ。それはともかく、ダブルバッファーが動かない。基本的なところを少しづつ確認していくしかない。何回目かのコードレビューの最中に、ふっと気がついた。ファーを切り替えるのを待っている。誰がUSBのエンドポイントに書き込むのだ。エンドポイントに書き込む処理は、エンドポイントに書いた後の割込みルーチンにしかない。ポインターの暴走でもなんでもない。何と言うお馬鹿なコードだ。これでは永遠に送れない。