ＡＲＭって、どのくらいのニーズがあるんでしょうかねえ？

http://headlines.yahoo.co.jp/hl?a=20080620-00000005-cwj-sci

インテルＣＰＵに対して、ＡＲＭがｌｉｎｕｘＯＳ用
ＣＰＵのシェアを伸ばそうという話らしいです。

確かにＡＲＭって、消費電力でいったらインテルＣＰＵ
よりもアドバンテージは有るんでしょうけど、
ＡＲＭのｌｉｎｕｘマシンといえば真っ先に思いつく
のは玄箱ｐｒｏ。

玄箱を世界に広げよう！って話ではないんでしょうけど、
そのくらいの処理能力では、高機能サーバーとしての
用途には多分むかないだろうなぁ…。

自宅で、個人でＰｅｒｌスクリプトやＰＨＰスクリプト
をｌａｍｐサーバーで動かす程度なら負荷もたかが
知れてるけど、公開サーバーとなると、負荷が
ちょっと高まったら動かなくなっちゃったりとか。

それじゃぁねぇ…どんな用途に使うんだろう？

玄箱を家で弄るのは面白いんだけど、ＡＲＭの
サーバーを商用とかで使うのは…普及するの
かなぁ？

消費電力を処理能力で割って指標化したら、
インテルとＡＲＭ、そもそもどっちがお得なんだろう？

やっぱりＳＰＩかな？

ＡＶＲスプライトのカラービデオ表示の続き。

6ビットを確保するとなると、ＵＳＡＲＴを
諦めてＤポートを空け、ＳＰＩ接続にすると
いうのがが一番いいかなぁという気が
しています。

そういえば、Ｉ２Ｃ（ＴＷＩ）は、フラッシュ
メモリーやリアルタイムクロックなどで遊んだ
記憶がありますが、ＳＰＩ接続はまだ使った
ことが無かったなぁ。Ｉ２Ｃよりはずっと
解り易いので、使うだけならなんてことは
無いんだろうけど、問題は転送速度。

山根さんの本を引っ張り出して来て、ＳＰＩの
所を読み直す…。
最も遅い速度に設定した場合、ビットレートは
ＣＰＵクロックの１／１２８となるとのこと。
マスター側ＣＰＵを２０ＭＨｚで動かした場合、
19531バイト／秒？

ＵＡＲＴを使っていたときには、115200bps。
startとstopを合わせて1バイト10ビットなので、
11520バイト／秒。

まだ速いなぁ…。というのは…

水平同期1本につき1バイトを入力するロジックに
なっているんですが、そうすると、1秒では
60フィールド×252本＝15120バイト。

これより速くアクセスすると取りこぼして
しまうので、送信側でタイミングを計って
送信する必要が出てしまうはず。

そういう不便なのはイヤなんですよね…
高級言語からも、何も考えずにデータを
垂れ流しできるようにしたい…

あと、ＳＰＩを使っちゃうと、ＩＳＰで書き込み
する時にちょっと不便なんですよね。まぁ、それは
本質的な問題ではないですけど。

うーん。もうちょっと考えてみよう。

続：ＡＶＲスプライトのカラー表示

ＡＶＲのスプライト表示カラービデオの件。

データシートを眺めていて、困ったことに
気付いてしまいました…。

Ｂポート、Ｃポート、Ｄポートとも、8ビット丸々
ビデオ表示に使えるポートが空いていないと
いうことに！

６ビットカラー表示（６４色）としても、６ビット
に加えてドット出力有無として１ビットの計
７ビットが最低でも必要なのですが…

Ｃポートは7ピンのうち1ピンがリセット端子だし、
Ｄポートは０と１がＵＳＡＲＴに割り当たって
いるし、Ｂポートは６と７が発振器入力に割り
当たっているし…。

内部発振子では８ＭＨｚにしかならないから、
Ｂポート６、７への外付けクリスタル（セラロック）
は必須。
とすれば、外部リセットを殺すかＵＡＲＴ接続を
諦めるか…

もしくは５ビットカラーで我慢するか…

５ビットカラーは勘弁だなぁ…
どうしたものやら…