2009年7月 9日 (木)

PIC18F14K50-I/P

 秋月のHPでPIC18F14K50-I/Pの取り扱いが始まっていました。DIPでないものは、ちょっと前から扱われていたようですが、今回のものは20ピンDIP。お値段は@200。

 価格もお手軽だし、DIPなので扱いやすい。機能は、ROM8KW、RAM768B。AD 11 / EUSART 1 / ECCP 1 / MSSP といったところに、USB(256Bバッファつき)搭載。USBを除けば、PIC16F88ぐらいの機能です。クロックは48Mまで可能なようです。
 18Fシリーズとしては決して強力なチップではないのですが、何しろ、DIPで、@200。よほど天邪鬼でない限り、16F88や16F648Aなど18ピンクラスのチップは出番がなくなりそうです。

 とはいえ、16Fシリーズ。結構な数の手持ちがあるので、しばらく、使い続けそう。消化試合?

| | コメント (0)

2009年7月 8日 (水)

熱いHDD

 いよいよ暑い夏に入りそうです。

 プログラムを組んでいるだけならば、それほど、容量が要らないHDDですが、画像やサウンドを扱い始めると、やはり、多い方がいい。
 ということで、リソースバックアップ用にUSBインタフェースのHDDを使っています。300Gぐらいのものが一台だったけれど、さらに、別のプロジェクトで300Gぐらいのものを用意しました。

 この二台、リソースを一度退避すれば、数ヶ月に一度ぐらいしか使わない。ということで、特に冷却性能などは気にしていなかったのです。
 ところが、実際にリソースの転送をすると、HDDの筐体が、とても、熱くなります。動いているのですが、何か、不安になるほど。結局、心配で、動作中は外から風を送ってしまいました。電池で回るような小さなファンでも、十分に冷えるようです。
 電子工作の手が止まっているのですが、まず、最初に再開するのは、HDD冷却用のファン台製作になりそうです。

 この巨大なリソースのバックアップ用のドライブを捜したところ、ポータブルHDDで512Gというのがありました。こちらも、熱関係を心配したのですが、それほど、熱くはなりませんでした。ポータブルということで省電力設計されているのが幸いしたのかも知れません。

| | コメント (1)

2009年6月25日 (木)

リュートのロバート・ジョンソン

 よく弾くリュート曲の作曲家としてクレジットされているロバート・ジョンソン。どんな人か、気になっていたのですが、調べていませんでした。

 たまたま、眠れぬ夜に、手持ちのヴァージナルの楽譜を眺めていたとき、「Elozabeth Rogers Hir Virginall Booke」の序章で、ロバート・ジョンソンについて書いてありました。

 リュート奏者で、作曲家。シェークスピアの劇音楽を書いた人。同時代の他の舞台音楽も手がけているそうです。王族や貴族のお抱え楽師?。当時のリュート奏者としては、ジョン・ドーランドに次ぐ評価を受けていたらしい。

 どこで誰に仕えたとか、そういう記述があるのですが、これが、ちょっと、問題でした。というのは、おなじみの wiki や、allmusic に書いてあるものと、相当違う。手元の本は1982年版だから、情報が古いのは考えられることです。しかし、wiki や allmusic の記載をそのまま、信じられるものかどうか。

 「Elozabeth Rogers Hir Virginall Booke」の同じところで、ジョン・ウィルソン(John Wilson 1595-1674)という、リュート奏者(作曲家)が紹介されていました。ジョン・ドーランド、ロバート・ジョンソンに続き、「英国一のリュート奏者」と呼ばれていたそうです。この人の曲も、弾いてみたいです。

| | コメント (0)

2009年6月23日 (火)

テキストのコード

 パソコンで扱うテキストのコード、大抵の場合、ShiftJisで扱っていました。

 WEB関係は別としても、プログラムに関しては、大体、これで通っていたのですが、新しいツールでは、ソースプログラム自体がUTF-8など、新しい?エンコーディングで書くのが標準になってきています。
 Windows自体、内部はUnicodeで動いているのだから、こっちの方が、自然なのだから、当然の流れとは思うのですが、結構不便。
 過去の遺産のテキストファイル(まさに、テキストや、ソースプログラム)は、殆どが、ShiftJis。新しいファイルは、UTF-8で書いてあるから、テキストファイルの種類がいくつもあることになります。拡張子がtxtだからって、エンコーディングまでは、読んでみないと判らない。

 プログラミング上でも、新しい方ではテキストの扱いが自然になって、バイトの区切りで文字が生き別れになるようなことがなくなり、とても便利なりました。
 が、一方で、過去の遺産のライブラリや、パーツとしてのプログラムでは、文字の扱いが違うので、そのまま、流用できないのは、痛い。

 プログラミング言語の仕様の違いなどよりも、テキストコードの違いの方が、影響が大きい気がします。

| | コメント (0)

«ツィス