Linux ザウルス用HDLツール

だいぶ前からIcarus Verilogがザウルス用に用意されていることを知っていたが、コンソールアプリケーションのクロスコンパイルだけなら簡単なので、自作ツール(sfl2vl)もクロスコンパイルしてみた。
コンパイルはすんなり通っているので問題なく動作するはずだが、自分のザウルスにはキーボードがないので、まともに開発をこれで行う気にはさすがになれない。
ホームページのsfl2vlダウンロードページに掲載したので、ザウルスでSFLを用いた論理設計をやりたいという方はぜひ試されたし。

ところで、ザウルスのシェルはまともなbashだったかな？もしかしたら、スクリプトが通らないかも？
スクリプトでこける場合にはbashをインストールしてください。

体調不良

今週は悲惨だ
月曜の発熱を押して会議に出かけたあたりはまだましだったけど、その後おなかを壊し食べものが入るとあっと言う間にトイレに駆け込む状態がいまだに続く
ここ三日くらいは一食だけの半絶食状態
また熱と頭痛が出てきた
今週はバイオリンの練習どころか仕事でもやるつもりだったことが積み残し
早いとこ回復しないと困るね

誰も知らない男

先日の出張のときに飛行機の中で読むために買ったブルース・バートンの「誰も知らない男」を完読。
この本はナザレのイエスを扱ったもので、アメリカで２０世紀にもっとも売れた本ということらしい。
しばらく前に読んだリー・ストロベルの「ナザレのイエスは神の子か」がむなしい言葉の羅列であったのに対し、「誰も知らない男」は少なくとも私には説得力を感じさせる魅力があった。
またマンガネタで恐縮だが、三原順の「はみだしっ子」でアンジーが牧師に「イエスは笑ったことがありますか？聖書に一度でも出てきますか？」と質問し、牧師は「いや」と返答するシーンがあるのだが、バートンは「笑わないイエス」というのは神学が与えた「神の子羊」のイメージからくるだけで、本来のイエス像とはかけ離れていると看破する。

実は、この本は８０年も前に書かれたビジネス書なのであるが、内容に古さを感じさせない。

デビルマン

今日は職場の懇親会で久々に電車で通勤
帰りに駅前のブックオフに昔夢中になって読んだ漫画のデビルマンを見つけ一巻のこと始めの部分を立ち読み
そこには1,3,4巻があって4巻の後書きに山田正紀が書いているのを見つけた
彼の初期の作品も夢中になって読んだものだがどこかつながるところがある
アニメになったデビルマンにはストーリー性がなくがっかりした記憶があるのだが昨年だったか公開された映画の方はどうだったのだろう
多少、気になるなあ

42

帰りの飛行機の座席は43だった。
ふと気がつくと前の席は41
飛行機にも縁起をかつぐのねぇ
ちょっと不思議だった

徹夜何日目かな？みんなご苦労さま

理論だけなんてのは論外としても、シミュレーションで動いたというレベルと
実際にものを動かすレベルは全く異なることがきっと身にしみたことでしょう。
もっとも、まだ動いていないから、今日一日が勝負の日となるんだけれど・・

アナログの物理世界をディジタル化して扱う組込みでは、開発前に机上で立てた理論が
完璧ということはまずありえない。プリント基板にしても、信号の取り回し一つ
とっても問題山積みなのである。これは自ら痛い目にあわないと中々実感できないと
いうのが、私のスタイルである。組込み分野にいながら、「ものを作ったことがない」と
おっしゃる先生がいるのには驚かされるが、エンタープライズ分野でも仕様書ありきの
ウォーターフォール型の開発スタイルには無理があることが知られていて、色々な
開発プロセスが模索されている。

読み物として面白いものがあったので、紹介する。
ＸＰ開発を行う過程をフィクション仕立てで書き下ろしたものだ。
「ホールインワンを狙わない」というのは、開発の現場にいたものの実感が
こもっているようであり、妙に共感してしまった。
アジャイルだのＸＰだの最近の手法は名前を見ただけでは何を言っているのか
分からないのが大問題で、名前の付け方一つで生産性が大きく変わると
思っている私には納得いかないのだが、それはそれとして、こういった
物語にしてくれると論文を読むよりも分かりやすいかも？

物語では残業をしないというのをルールとして先に決めてスタートしたが、
作業能力がある程度見えたスタッフ以外にはこのやり方は難しいかもね。

四日も徹夜が続いている

と、彼らは言っているけれど、朝大抵みんな椅子で寝ているんだよな。
これって、徹夜なの？
いや、単なる疑問なのだけれど・・・

連日の会議

会議のために毎日のように東京に出るから移動時間がばかにならないね
バイオリンの練習がまるでできないまま次のレッスンの日程が迫ってきた
今回は先生と僕のスケジュールが合わなくて前のレッスンからの間が一週間しかないのだった
四月も日程厳しいし先生のコンサートがあるからどうなることか
やっぱり月一くらいにしないと無理かなぁ

飛行船の日程は思ったより後ろになったからこちらは多少余裕がでた
そろそろロケットをなんとかしないとね

携帯の充電USBケーブル

100円ショップで購入し、携帯のコネクタ部分をばらす。
これだけで簡易電源完成
苦労してパラレルポートから電流とるよりスマートだね

移動体通信料金体系変革の予感

WILLCOM社がPHSの比較的安い料金の音声通話定額コースを発表した。

NTT回線をバイパスして自前の回線に流すことで実現したようだけど、
ビジネスモデルの大きな変革が発生しそうな感じだね。

そもそも、日本で移動体通信が出始めた頃、そのとんでもなく高価な
音声通話料金を何とか回避しながら連絡を取る手段としてSMSが流行り、
GSM圏と違いSMSのローミングが整備されなかったので、emailに流れた
ように見えるので、音声が基本料金だけで定額となるとかなり音声に
戻る人たちが増えるのではないかな。
もちろん、音声通話ができないところではemailの優位さはあるし、
蓄積型のよさもあるのは分かっているけど。

話は変わって、
ここしばらく来年度のパンフレットの校正をやっていた。
校正の作業はたまに朱記が入る程度なら赤ペンでやったほうが
効率的だけれど、今回はページレイアウトから図の変更まで
大幅な変更が多々あるので、こうなるとマシンリーダブルな
ファイルをもらってそれに直接書かせて欲しいと思ってしまう。
どんなケースにも万能な手段なんてありえないのだけれど、
このインタフェースを何とかして欲しいなぁ。

今夜は、前の会社の同期会にお誘い。
宴会場はなんと会社の中のレストランだそうな。
ほとんど会うことのない人たちと久々の再会は楽しみ。

コラボレーションは難しい

先輩が後輩を指導するなんて当たり前のことができないんだよなぁ。
大した技術でもないのに、他人に隠したがり、そのくせ人のものは
見たがる。「お前はブラックホールだなぁ」って思うけど、まぁ色々な
人間がいるのは仕方がないか・・

DELLのノートＰＣはなんと割引クーポンサービスまでやっていて、物欲を
かき立ててくれるが、やっぱりどう考えても無駄遣いな気がして買うのはやめよう。
その代わり、MACminiを買いたい気分・・（結局無駄遣いをしたいだけか、お前は）

通信モジュールの試験は置いておいて、ユニットへのアクセスライブラリを
多少整備しはじめた。LinuxとCygwinのgccソースとマイコン用のSDCCソースを
ライブラリ部分は共通化し、プラットホーム依存部分を切り出してみた。
中心周波数の違いによって、PLLへの設定値が変わるから、この部分は
定数にするとまずい気がするが、テストのためにはとりあえずはこれで
いいだろう。参加チームが決まったら、チームごとに周波数を多少変位させ
同じ場所で動作させても電波がかぶらないようにしておこう。

バイオリンの先生が５月の大阪コンサートの動員を心配していたから、
ちょっとだけ知り合いに声をかけてチケット販売のお手伝い。
あのホール400人入るのだけど、チケットを2000円で売って
満席でも80万だから、ホールの賃貸料に足りるのか他人事ながら
心配してしまうね。
その後、４月の横浜コンサートも知り合いがいたら・・との連絡。
こっちも苦労しているのかな。まぁ、去年日本に帰ってきたばかりで
実績も何もないから大変なんだろうね。

rdtsc命令での時間計測の件

どうやらSpeedStepで勝手にクロック周波数が600MHzに落ちていたようだ。
バックグランドで思い切り負荷をかけたら正しそうな値になった。
システムのプロパティを見てもクロックが変動しているようには
表示されていないので、今のクロック周波数が分からないなぁ。
これでは負荷の状況によって値が変わるので、
時間計測にRDTSCを用いるのは難しい。
LinuxではSpeedStepをアクティベートしていなかったのかな？

nanosleep関数

Linuxとcygwinの双方でnanosleep関数があるので、精度の高い時間待ちに
この関数が利用できると思うのは甘い！
Linuxではjiffiesは10mS単位なので、nanosleepで小さな時間を
指定してもまずそんな時間では動かないのであった。
たとえば、通信モジュールで250uSの待ち時間が必要な部分があるのだが、
こんな小さな時間を指定しても、Linuxでは20mS近くの待ちが入る。
cygwinでは時間粒度は少しだけ細かいが、これは
WindowsXPのタイマ粒度がLinuxよりも細かいようだ(1mS?)。
とはいっても、XPでも時々とんでもなく長い時間の待ちになることが
あるので、スケジューラの都合など色々条件があるのだろう。

それと、不思議なことにcygwinで時間をRDTSCとgettimeofdayの２通りで計ってみたら、
この二つの値が大きく違う。（rdtsc計測は0.4倍。）
不思議だ～。cygwinの問題なのか、windowsXPの問題なのかは分からない。
VisualC++にはgettimeofdayがないので、timeGetTimeも合わせて計測したら
こちらはcygwinのgettimeofdayに近いようだ。RDTSCのカウンタ値がPentiumMでは
おかしいのかな？別のマシンでも確認要だね。

Linuxでは、10mS以上の大きな待ち時間を設定した場合には、+10mSの
遅れ（これはschedule tickによるのだろう）がある以外はほとんど
ぴったりの待ち時間が計上されるので、粒度は荒いが納得はできる。

いずれにせよ、通信モジュールの待ち時間は最低限を規定しているだけなので、
250uSが20mSでも困ることはないのでどうでもいいようなものだが、
関数の説明だけ読んでそのとおり動くと信じる人がいるんだろうね。

実は、この精度のテストをしていて、rdtsc命令を使っていたのだが、
2月のセミナの時に使ったプログラムの時間の表示が誤っていたことに
気がついた（あらら～）
参加者に連絡したほうがいいかも・・・

cygwinでioperm関数

Linuxとの互換性を狙ってのことだと思うけど、iopermが使えるようになっているんだ。
これはかなり便利で、WindowsXPでも直接IOポートを叩くアプリケーションが
簡単に実現できる。もっとも、ドライバをそのつどインストールしておく必要が
あるんで、忘れやすいけれど。

飛行船の基地局システムはLinuxで行くことにしているのは、IOを叩くだけでなく、
タイマなどで時間管理をするドライバを作る時にWindowsだとDDKを導入したり
大事になってしまうからなので、方針自体は変える必要はないけれど、
日々の簡単な実験ならこれがあれば両互換のプログラムが作れるし、
かなりスムースにできるね。

ただ、私のPCカードパラレルポートはWindowsだと割り当てアドレスが
iopermでは届かないところにアサインされてしまうので、ioplを使う必要がある。
Linuxで使うと普通にLPT2のアドレス(0x278)に割り当ててくれるから
WindowsXPが何かおかしなことをやっているのだろうけれど、不便だ。

PnPのポートでなければ、40:08からポートアドレスが取得できるのだけれど、
PCカードのパラレルポートはLinux/Windowsともに40:08からのテーブルには
格納されないようだ。BIOSが関知しないから当然といえば当然だが・・


備忘録

• ioperm -i : ドライバインストール
• ioperm -u : ドライバアンインストール
• 実行プログラムのコンパイル時にlibiopermのリンクが必要

あ、バイオリンのレッスン前に練習しなくっちゃ～・・・

ＰＣカードパラレルポートのＩＯアドレス

Windowsではデバイスマネージャで読み出すことができるのだけど、
プログラムから自動的にできないと使い勝手が悪いので、調べていたら、
どうやらPnPのパラレルポート用のioctlが定義されているようだ。
これを使えばアドレスをプログラムから読み出せるはずだけれど、
ioctlの説明を読んでもどうもよく分からない。Linuxのioctlなら
簡単なんだけど、WindowsのPnPデバイスだとドライバが２段階に
なっているようで、一筋縄ではいかないのかも。
というところまで、調べて、結局あきらめた。

まぁ、何を調べればよいのかは分かったので、本当に困ったら
何とかできるでしょう。

そもそもパラレルポートの付いていないノートＰＣを買ってしまった
ところに問題があるわけで、実験用にパラレルつきのノートを
購入するというのも一つの解ではある。

でも、英語キーボードのノートＰＣって日本では数が少なく、
パラレルとシリアルが付いているマシンを探すってのが難しい・・




DELLのD505がキャンペーンで安売りしているらしい。
これなら、パラレルもシリアルも付いて、英語キーボードで発注可能だから
希望通りのマシンだ。でも、DELLをさらに一台、パラレルポートのためだけに
買うというのはやっぱりあんまりだよなぁ・・