Cのコードを移植

特に有用な内容は無いです。

以前
Cでモジュールを書く
でCで書いたモジュールをLimboから呼び出す試みをしましたが、
Limboで書くより若干速いというメリットの他に、
既存のCのプログラムが移植しやすいというメリットが有るのではないかと思いました。

そこで、既存のCのコードをコンパイルできるか試してみました。

サンプルは
plan9のcatです。
Cと言っても、ansiではなく、ken ccのように見えるので、
plan9由来のコードが移植しやすいと判断しました。

plan9のコードからcat.cを見つけて、
中身を以前試したexample.cにコピーしたところ、
ビルド自体は通りました。
わりとそのまま行ける感じです。

ただ、ファイルシステムへのアクセス方法がよくわからず、
使えていませんが。

plan9のls.cを参考に、ディレクトリサーチを試みましたが、
dirreadが無いと怒られ頓挫(openはできたっぽい)。
ヘッダにはプロトタイプがあるのにね。

charonで日本語が潰れる問題をとりあえず回避

charonで日本語の入ったページを表示させると、
小さい文字が「NUL」になることがあります。
どうすればよいかよくわかっていませんが、
とりあえずの回避方法を見つけました。

/fonts/charonのなんとか.tiny.font となんとか.small.font
をまとめて消してしまうのです。
これでひとまず表示できました。

良い方法ではないと思うけど。

tclはいけるが、tkはだめ

tcl/tkが使えるか試してみました。
tclshでtclスクリプトが実行出来ることは確認できました。

しかし、wishでtkを呼び出すことはできませんでした。
windowが出てくれないのです。

なお、shからtkを呼び出すのに、

load tk
wid=${tk window 'window'}
tk $wid update

とかしてみましたが、やはりウィンドウが表示されませんでした。
tkがだめ？

charonの実力を探る

ふと気になって、charonがどのくらい使えるのか調べてみました。

ECMAScript

ECMAScript 2 に対応とのことなので、試してみました。

このへんの
Javascript入門ページのサンプルを実行してみたところ、
割といけました。
面白い。

特に引数に何も付けなくてもscriptは使えましたが、
ドキュメントによると、-doscripts 1 とか付けないとだめとなっていたので動かない場合はオプションに注意、ということで。

なお、alertはポップアップではなく、コンソールに出るようで。

ログインできるページ

今まで駄目だと諦めていたgmailにログインできることがわかりました。
ユーザー名、パスワード入力後エラーページが表示されますが、
その後もしつこくgmailをクリックすると、basic htmlにて
メールの表示ができました。
なんとメールの送信も可能です。

amazonもログイン可能でした。ただ、検索はできないようで。
怖いので購入は試していません。

mixiも行けました。mixiはほぼすべての機能が使えるのではないかと。

駄目だったのは、dropbox, evernote, twitter, facebookと、今流行りの
ウェブサービス。

AVR32 でROMライター無しの開発環境構築

無関係のAVR32の話題を。

最近LAN対応の小さいシステムとして、AVR32とH8をいじっています。
H8の方はtoppers+tinetであれば公式ドキュメントが完全に説明して
くれているのでなんとでもなりそうですが、
AVR32の方はなかなか大変でしょうね。
開発環境をインストールしたあと結構途方にくれるきがします。

TCP/IPをやりたい場合はlwipを使うのが良さそうですね。
ここではlwipの導入方法は説明せず(というか昔のことなのでやり方忘れた)、
ROM Writer無しで開発できる環境を作る方法について書き残しておこうかと思います。

本来こういったリソースの少ない開発ではボードとICEとセットで使い、
ICE経由でファームウェアを書き込むのが普通なのでしょうが、
このボードの場合はUSBをもち、PCと接続すると本体自身が
デバッガになるという機能があります。
デバッガになるためにはその機能を持つブートローダーを入れる必要があります。
Flashの先頭にはそのブートローダを書きこんでおきます。
後半はあけておき、PCから自由にファームウェアを入れることができます。
ファームウェア側にも変更が必要で、ブートローダーの分ずれたアドレスに
コードが 配置されるようにしなければなりません。

・環境

EVK1100。
どうやら最初からブートローダーが書きこまれているという話。
もし書きこまれていなければ、初回はやはりWriterが必要で、一度bootloaderを
書きこむ必要がある。
ブートローダーはDFUブートローダーと呼ばれています。

開発環境はAVR32 studioとそれに対応したコンパイラ。
DFUブートローダーを利用してファーム書き込みを行う場合は、
PC側にDFUのドライバが必要。
それはFLIP3というソフトウェアが必要となります。

ドキュメントは
「AVR UC3 USB DFU Bootloader」という名前のPDFがあります。
これを読めばすべて書かれているはずです。

・ビルド

trampolineという仕組みを含めてビルドします。
ドキュメントの「Adding or Removing the Trampoline」に書かれているとおりです。
たぶん。

・DFUブートローダーで起動

DFUブートローダーモードで起動するには、
スティックを押しながら電源を投入します。
電源はPCからのUSB給電がよいでしょう。
PCではEVK1100はDFUとして見えます。
Windowsであればデバイスマネージャーで見えるはずです。

初回はドライバのインストールが促されます。
予めFlip3をインストールしてあれば、Flip3のインストールディレクトリのUSBディレクトリ以下にドライバがあるはずです。

・AVR32 studioからDFUを使うように登録

AVR32のtargetというペインで、DFUを登録します。
これもドキュメントのとおりです。

・fusesの保存

targetを右クリックして、read fusesでファイルにfusesの内容を
保存しておきます。
そのファイルを開くとGUIでfusesをいじれますが、GPの値に注目してください。
0x7になっているかもしれません(ビット0x4が立っている。立っていないケースも有るかも。このビットはユーザーの書き込んだファームを実行するかどうかのフラグ)。
ファームを書きこむ際には、このビットを落とす必要があるので、
もし0x7とかになっていたら、0x3に直して保存しておいてください。

fusesはファームを書き込むときに使います。

・ファームウェアの書き込み

以降の手順はファームウェアを変更するたびに行います。

targetで右クリックし、programを選びます。
(runとかdebugからは実行できないのが残念)
ファームは、debug/〇〇.elfとかrelease/〇〇.elfとか
elfファイルです。

注意点としては、書きこむ前にflashの消去を行う必要があることです。
書きこむ画面で、unlock and erase のチェックボックスをチェックして下さい。

書き込みが終わったら、次にfusesの書き込みが要ります。
どうやらファームを書き込んだりfusesを読み込むと勝手にfusesが書き換わるようで、
ユーザーが書き込んだファームを実行するためには書き換えが必須です。

targetを右クリックしてprogram fusesを実行します。
保存しておいたfusesを選んで書きこんでください。

以上で、ファームウェアの書き込みが完了です。
ROMに書きこまれたので、電源を切ってもファームは残ります。

・実行

再起動するとユーザーフォームが立ち上がります。

以降は、

ビルド→DFUモードで再起動→ファームの書き込み→fusesの書き込み→再起動

という流れで作業を行います。
面倒ですね。

・まとめ

ほとんど公式のドキュメントに書かれているとおりですが、
Flashの消去を忘れない、ファーム書き込みの時にfusesも書きこむのを忘れない、
という注意点があります。

書籍

Principles of Operating Systemsのinternational版(ペーパーバック)があるそうです。
ハードカバーより高いという。

地獄の門を見逃した

先日東京に行った折、西洋美術館に行ったのですが、
入り口にあったロダンの地獄の門をスルーしてしまいました。
今から思えば、神曲を表す地獄の門を見ないのは、
Infernoエンジニアとしてあるまじきことでした。
あ〜あ。

次回は必ず見る。

ところで、考える人って地獄の門に含まれていたのですね。知らなかった。

Cでモジュールを書く

Cでモジュールを作成し、limboで使用する
http://powerman.name/doc/Inferno/c_module_en
だそうです。

ここに書かれている方法に従えばいけました。
OSX で試しましたが、ちょっとはまった点がありました。
紹介されている方法はLinuxが前提となっているので、OSX用にちょっと
手直しが必要でした。

emu/MacOSX/emuを編集し、modにexampleを追加します。

これでパフォーマンスが必要なところはCで書く、なんてことが可能になります。
クール。

ただ、JITの1.3-1.5倍速くなる、だそうで、もともとLimboのパフォーマンスは高いのでしょうね。