Jun 29, 2011
anthy9100h+G-HAL's patch+UTUMI's Anthy dictionary [computer]
Q:これは何?
A: FreeBSDのports形式のアーカイブです。 日本語かな漢字変換システムのjapanese/anthyに修正を加えて変換効率を上げられるよう既存のpatchを加え、改良された辞書を使うようにしたものです。 元々のjapanese/anthyからの変更点は以下の適用です。
- G-HALさんのanthyパッチpatch0, patch13
- UTUMI HirosiさんのAnthy Dictionaries
- okinawa dicを最新版に更新
- configメニューを導入
G-HALさんのパッチ(patch13)は、anthyが使っているうちに少し前の学習結果を忘れてしまう問題に対処するところから始まった変換効率改善パッチです。patch13は学習データの量の上限の拡大、学習情報のシステム辞書の頻度情報の扱いの変更、iconv対応(辞書データのutf-8対応)等の変更が行われているようですが詳しくはG-HALさんのページを参照してください。patch0はanthyに元々含まれているコーパス情報を無効にするパッチです。元々のコーパス情報が実状に合わないのではないかという検討に基づいたものです。
UTUMI Hirosiさんの辞書はvagusさんのcannadic改(alt-cannadic)をもとにG-HALさんのシステム辞書頻度情報の扱い変更に会わせて頻度情報のチューニングを行ったものです。utf-8辞書のため利用にはG-HALさんのパッチ適用が必要です。 UTUMI HirosiさんはModified Anthyというパッチ込みのソースを作成されていますが、従来のportsとの連続性を考えてG-HALさんのパッチ+UTUMIさんの辞書という形式をとっています。
Q:今使っているanthyからアップデートして問題ない?
A: G-HALさんのページによれば 個人用の単語辞書、個人用の学習データ、 インストール後のシステムの辞書、 全てに於いて、一部の文字の互換性が無くなります。 ということです。問題の出る文字は G-HALさんのWebを参照してください。 思い切りよく~/.anthy/以下を一旦消してしまうというのも手です。
Q:send-prはする?
A: まぁ、気が向いたら(w 上記の互換性の問題があるので様子見というのもありますが、自分で使うために作ったのでかなりやっつけです。
Q:何か余計なものに依存していたりする?
A: UTUMI HirosiさんのAnthy dictionaryの作成にrubyが必要です。特に意味はありませんがDEPENDの指定をしていませんので無いとエラーになります(w
May 09, 2010
玄箱HG のクロックのお話 [computer]
玄箱/玄箱HGのクロックは精度が悪いという話を聞きますが、この件はこの辺に詳細があります。 玄箱HGのハードウェア情報
これによればクロックモジュールの2番ピンをプルアップしてカーネル内のクロック周波数のパラメータを変更するのが一番よいように思います。 玄箱NetBSDではカーネルのクロック周波数パラメータを現物合わせする形で補正しているのである程度はクロックのずれは押さえられて....いるはずなんだけど普通のPCに比べると誤差が大きくてntpが落ち着くまで時間がかかるようで。
玄箱NetBSDではkernelのconfig optionでパラメータを変えられるのでさらに自分の持っているもので追い込んでみましたよ。
#options KUROBOX_BASE_CLOCK="(32517900)" options KUROBOX_BASE_CLOCK="(32521600)"上がデフォルトの値で下が使用中の値。これでntpの収束も早くなった...んー自己満足。
May 04, 2010
玄箱HG NetBSD 5.0.2 [computer]
忘れた頃のお話しばらく前に玄箱でNetBSD5.0.2を動かしている
やりかたは前に書いた5.0.1とほとんど同じ(同じ玄箱パッチ20090124.diff.bz2 を使用) 訂正と注意点のみ
- 追加パッチ
- コマンドライン
コンパイルエラーが出るような。エンディアンに関するマクロが未定義っぽい。
--- usr/src/common/lib/libc/hash/sha2/sha2.c +++ usr.patched/src/common/lib/libc/hash/sha2/sha2.c @@ -41,5 +41,6 @@ #endif #include <sys/cdefs.h> +#include <sys/endian.h> #if defined(_KERNEL) || defined(_STANDALONE)
これが正しい手段かどうかはわからんが、コンパイルは通る。動いてはいるがsha2を使った検証はしていない。
build.shでX不要だったら-xつけちゃダメだね
× % ./build.sh -U -x -u -m evbppc release ○ % ./build.sh -U -u -m evbppc release
-Uも微妙。パーミッション等の後の事を考えて rootで実行、-Uをつけない方がいいのかも。
Oct 20, 2009
玄箱HG NetBSD distcc で混合pkgsrc作成環境 [computer]
NetBSDのベースシステムはクロスビルドが簡単にできるようになっているがpkgsrcはそれほど簡単ではない。
pkgsrcはdistccに対応しているのでdistccを使ってホストPC側のクロスコンパイラを使うようにすることができる。configure等は玄箱上のセルフ環境で行うのですべてが速くなるわけではないが、pkgsrcがかなり「使える」ようになる。
- ホストPC側の設定
distccdを高速なホストPC側で動かす。distccのマニュアルによればdistccでクロスコンパイルを行う場合はターゲットアーキテクチャ用のクロスコンパイラを規則に従った名前にして...等あるが、ここではNetBSDのpkgsrcで使う関係上別の方法で対応する。
ホスト側のコンパイラはNetBSDベースシステムのクロスビルドで使用したtoolchainのコンパイラを利用する。
例えば/usr/local/evbppc/toolchain/bin以下にクロスコンパイラがあるとする。 (toolchainの作成時に例えば、
# ./build.sh -T /usr/local/evbppc/toolchain -m evbppc等で作成しておく)
# cd /usr/local/evbppc/toolchain/bin # ln -s powerpc--netbsd-gcc gcc # ln -s powerpc--netbsd-gcc cc # ln -s powerpc--netbsd-g++ g++ # ln -s powerpc--netbsd-c++ c++
distccdの起動時にPATHをクロスコンパイラのあるディレクトリにしておくようにする。 例えばホストのIPアドレスが 192.168.1.129 であるとして起動スクリプトで
#!/bin/sh PATH=/usr/local/evbppc/toolchain/bin distccd -a 192.168.1.0/24 --user distcc --daemon \ -P /var/run/distcc.pid --listen 192.168.1.129など。
ちなみにホストPC側がFreeBSDの場合、portsからdistccをインストールするとデフォルトではIPv6のアドレスに対してbindされるためIPv4でネットワークを構築している場合、上記のように--listenでIPv4のアドレスを指定しないと使えない場合がある。
NetBSDのpkgsrcでコンパイラにdistccを使う場合なら/etc/mk.confに以下のような記述を 入れておけばよい。DISTCC_HOSTSはdistccでコンパイル行うホストのアドレスを書いておく(distccのマニュアル参照)。
PKGSRC_COMPILER= distcc gcc DISTCC_HOSTS= 192.168.1.129
Oct 15, 2009
玄箱HG NetBSD 5.0.1 [computer]
これは個人的なメモ
玄箱(HG)のCPUはOSをセルフビルドすると丸一日かけても終わらない程度に非力なのでOSなどのシステムを構築するにはクロス開発環境があったほうがいい。幸いNetBSDではクロス環境でOSを構築するのは簡単にできるようになっている。
今回は玄箱に接続したディスクには領域を確保はしておくが、まずUSBメモリ上に動作するNetBSDを構築してみる。
- 玄箱HGの初期セットアップ
- クロス環境のホスト上でソースコードの展開、パッチの摘要をする
- カーネル、リリースバイナリのクロスビルド、USBメモリへインストール
- デバイスファイルの作成
- 玄箱HG上にNetBSDをブートするためのブートマネージャを設定する
具体的手順
- 玄箱HGの初期セットアップ
- クロス環境のホスト上でソースコードの展開、パッチの摘要をする
- カーネル、リリースバイナリのクロスビルド、USBメモリへインストール
- デバイスファイルの作成
- 玄箱HG上にNetBSDをブートするためのブートマネージャを設定する
私の所有している玄箱にはシリアルコンソールコネクタをつけてあるので特に困るようなところはない。通常の玄箱のセットアップ手順のとおりHDDを組み込んでLinuxのシステムをインストールする。気をつけるのはHDD上にNetBSDを組み込むための空き領域を作っておくことぐらい。mfdiskを手動で実行して空き領域を確保しよう。 あとは各種webサイトなどを参考に。 たとえば今はこんな状態。
Device Boot Start End Blocks Id System /dev/hda1 1 4161 2097112+ 83 Linux /dev/hda2 4162 4681 262080 82 Linux swap /dev/hda3 4682 29648 12583368 83 Linux /dev/hda4 29649 77545 24140088 a9 Unknown
NetBSDの3以降はevbppcをベースにしてパッチを当てたものが動いている。 5.0.1 (evbppc)+ 5.0用パッチで多分何とかなるだろう。ならなかったら何とかしようという方針で。
NetBSDのマスタサイトからソースコードアーカイブを持ってくる。(最近はbittorrentがおすすめらしいけど) http://ftp.netbsd.org/pub/NetBSD/NetBSD-5.0.1/source/sets/ などから src.tgz, syssrc.tgz, gnusrc.tgz, sharesrc.tgz を持ってくる。さすがにxsrc.tgzはいらんだろ。
% tar xvzf src.tgz % tar xvzf syssrc.tgz % tar xvzf gnusrc.tgz % tar xvzf sharesrc.tgz展開するとusrディレクトリを作ってその下にソースツリーが出来る。
パッチも持ってくる。
こちらを参考に 玄箱でNetBSDを動かす ここ から持ってきた。 使用したパッチは 20090124.diff.bz2
% cd usr/src % zbcat ../../20090124.diff.bz2 | patch -pクロスビルドはFreeBSD上でやっているのでpatchのオプションは上記の形になっているがOSによっては違うオプションが必要になるだろう。
普通にパッチは当たってrejectは出ないのでまあいいんだろう。 クロスビルドの方法は以下に従ってやってみる。 http://www.netbsd.org/docs/guide/en/chap-build.html つまった記憶はないので多分問題ないんだろう。
% ./build.sh -m evbppc tools % ./build.sh -u -m evbppc kernel=KUROBOX
生バイナリのカーネル usr/src/sys/arch/evbppc/compile/obj/KUROBOX/netbsd.bin が作成される
KUROBOXの設定で作られたカーネルは玄箱上のLinuxで動くブートマネージャで読み込むので玄箱のLinuxパーティション上に置いておく。私はLinuxのパーティションに/bootというディレクトリを作ってそこに置いている。
% ./build.sh -U -u -m evbppc release
usr/src/releasedir/evbppc/binary/sets 以下にリリースバイナリができる。
base.tgz comp.tgz etc.tgz games.tgz man.tgz misc.tgz tests.tgz text.tgz
カーネルも何種類かできるが使わない。PC上等で既に動いている FreeBSDやNetBSDでUSBメモリ上にffs作って上記のバイナリを展開しておく。 これがテンポラリに起動するNetBSD5.0.1になる。 /etc/rc.confなどが適切に設定されていないとマルチユーザモードにならないので設定しておく。
とりあえずbase.tgz, comp.tgz, etc.tgz, misc.tgzぐらいを入れておく
/etc/rc.confの設定は私は以下のようにしてみた。
rc_configured=YES hostname="nb_kurobox" domainname="hoge.local" dhclient=YES #defaultroute=192.168.0.1 sendmail=NO no_swap=YES clear_tmp=YES quota=NO savecore=NO syslogd=YES #kuro_avrd=YES sshd=YES postfix=NO named9=NO ntpd=NO
USBメモリ上にデバイスファイルを作っておく。例えばターゲットのUSBメモリが/mntにマウントされていて、クロスビルド環境は /usr/kuro_netbsd以下、ツールチェインのディレクトリが/usr/kuro_netbsd/usr/src/tooldir.HogeSystemの場合、
# cd /mnt/dev # sh MAKEDEV -m /usr/kuro_netbsd/usr/src/tooldir.HogeSystem/bin/nbmknod all
元々古めのsandpoint版玄箱NetBSDを入れていたマシンだったので、いい加減なことを書いてしまった。修正しておく。(2009/10/20)
ブートマネージャ(kuro_bootsel2)のアーカイブを玄箱HGのLinux環境上に展開し、make installを実行する(付属のドキュメントを参照)。 kuro_morse, kuroswread, kuro_bootsel2.sh が予定の場所にインストールされる。
NetBSDのカーネル(生バイナリ形式 netbsd.bin等)及びローダー(nbloader_v3.o)をLinux環境の/boot以下に置く
玄箱のLinuxパーティション上にブートマネジャー(nbloader_v3.o)をインストールしておく。/boot/nbloader_v3.oで置いてあるとする。起動時のスクリプトkuro_bootsel2.shを
玄箱のLinux上で/etc/init.d/kuro_bootsel2.shに置く。/etc/rc.d/rcS.d/にシンボリックリンクを作成する
設定ファイル/etc/kuro_boot.confに適切な設定を行う。
# Menu entry No.2 # menu2="NetBSD(USB:sd0a)" loader2=/boot/nbloader_v3.o kernel2=/boot/netbsd.bin option2='cmdline="bootdev=sd0a"'これでUSBメモリからの起動の実験ができるはず
- それから
うまく起動したらUSBメモリにリリースバイナリのアーカイブを入れてハードディスク上に確保した領域にNetBSDをインストールする。
ハードディスクへのインストールは最初に起動するところまではUSBで起動させるまでと大体同じ。
swapをLinuxのswapパーティションと共有する場合はLinuxのswap物理(fdisk)パーティションのoffsetとsizeを出してそれぞれoffset+8, size-8をNetBSDのswapのoffset, sizeにすればいいとか。disklableで見ると f:が元々あったLinuxのswapパーティションの情報、b:がNetBSD用に確保したswap領域
b: 524152 4194296 swap f: 524160 4194288 unused
あとはrc.confを直すなりパッケージを入れるなり適当に
May 17, 2009
DS18B20を使ってみる(プログラム) [computer]
前回書いた時点で既にDS18B20を使って温度を測定するところまで動いていたが動作検証したプログラムについては特に述べなかった。
動くのは動くんだが、 ソフトウェア的にμS単位のタイミングを制御する必要があり動作環境で動いたり動かなかったりすることがあるのも確認している(ぉい)
どのみちすべての環境で動くことが期待できるようにするのは難しいし、そこまでやる気がないのでスペルミス等の些細な部分だけ直したきちゃないプログラムを公開してみる。
それぞれFreeBSDの7.1-stable(時々buildしなおしているのでいつの環境かは不明。前回迄は確かに7.1だったが今は7.2-stableになっていたりする)上で作成した。Linux(Debian 5.0)上でも一応動くようにはしたがろくに動作確認はしていない。どのみちマザーボード等のハードウェアによって動いたり動かなかったりする。
ターゲットマシンのスペック、動作条件は以下のとおり
- マザーボード Intel D945GCLF (intel Atom230 1.6GHz/945GC)
- RAM 2GB
- BIOSでプリンタポートを双方向に設定
- FreeBSDではpowerdは止めている。これはCPUのrdtscを使ってタイミングを計っているため、動作中に省電力化のためにクロックが変わってしまうとタイミングに誤りが出てしまうため。
ちなみに以下のプログラムのds_tlib.cにはセンサのリセットルーチンが2つ(ds_reset(), ry_reset() )入っている。デバッグ時の便宜も考えてリセットの時のステータスを見ながらリセットをかけているのがds_reset()だが、これがたまたま試してみたマシンで動作しなかった。ry_reset()は単純に規程時間だけ待ってリセットがかかったとみなしている。ds_reset()が動かなかったマシンでry_reset()を代わりに使ったらそれなりに動いたので残してみた。
- 温度測定 (chktemp090517.tar.gz )
- rom_read
センサを1個だけ前回(5/7分)の図のバス上に接続して使うプログラム。 makeするとrom_readとchktempの2つの実行ファイルができるはず。
半分デバッグ用。実行するとセンサの情報を色々だしてくれる。
% ./rom_read tsc_1micro 1599 Family Code: 28 CRC : c8 Serial No. : 000001aff6c5 verify CRC : c8 OK 8a 01 4b 46 7f ff 06 10 2c scpad crc 2c CRC : 2c Temperature : 24.625000 out length 12 verify CRC : 2c OK
このプログラムを 動かすと延々温度を測定して表示する。 多分時々エラーが出るでしょう。
% ./chktemp Temp. : 24.69 Temp. : 24.69 Temp. : 24.62 Temp. : 24.69 Temp. : 24.69 Temp. : 24.69 Temp. : 24.69 Temp. : 24.75
複数のセンサをバス上に接続してこれを動かすと1-Wireバスのサーチアルゴリズムにより各センサのROM IDを取得して画面上に表示する。以下実行例。
% ./rom_search write: f0, 1599 find device 28 78 07 b0 01 00 00 4c write: f0, 1599 28 ac bf b1 01 00 00 aa write: f0, 1599 28 c5 f6 af 01 00 00 c8この例では3個のDS18B20が接続されている。
このプログラムについてはアルゴリズムの中核部分、CRCの算出部分にMAXIMが提供しているサンプルコードを使用している。そのライセンスの部分をここに引用しておく。
Copyright (C) 2000 Dallas Semiconductor Corporation, All Rights Reserved. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL DALLAS SEMICONDUCTOR BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. Except as contained in this notice, the name of Dallas Semiconductor shall not be used except as stated in the Dallas Semiconductor Branding Policy.
P.S. ところで某の某氏よりUSB温度計の話が秋葉原の三月兎で売られていることを聞いた。確かにWebの方にも紹介されている。いかにもな怪しい作りで、PCにつなぐとUSBシリアルがつながっているように見え、USBシリアルの先に温度センサがあるようだ。
というかこれUSB-シリアルコンバータのPL230xじゃない。どうもデータ垂れ流しっぽいような気もするけど。
秋月で売られているUSBデータロガーも試してみるかな?
May 08, 2009
DS18B20 を使ってみる:1-Wireバスの接続 [computer]
1-Wireバスはコントローラ1台と複数台のスレーブデバイスから構成される。 コントローラは+5Vの電源が供給できて、データ線は1ビットの入出力端子が必要となる。 入出力端子の出力側はTTLレベルの3-stateまたはオープンドレイン出力である必要がある。データ線は5KΩ程度でプルアップされる。
電気的には大きな問題はないが、PCをコントローラにする場合タイミングの条件が比較的厳しい。仕様上タイミングを最低15μS以内で制御する必要がある。これはUnix系のOSのようなラウンドロビンのスケジューリングをするOSの場合、ユーザプログラムでは条件を満たすことができない場合がある。
信頼性を高くする必要のあるアプリケーションの場合、クリチカルな部分ではカーネル内で割り込みを禁止して処理を行う必要がある。 もっとも温度の測定タイミングが数秒ずれても問題が無いような場合(室温の測定や水槽の水温の測定の場合が当てはまる)はそこまで厳密に行う必要がない。 ディスクのアクセスやネットワークからのデータ処理のため温度測定に失敗したとしたらまた最初からやり直せばいい。
今回はプリンタポートを双方向モードに設定してポートのデータ線のうち最下位ビットを1-Wireに割り当てることにした。+5Vはプリンタポートのコントロール信号のうち1本(~AUTOFEED)を利用した。後で仕様の確認をしたところ、電流の供給能力等で問題がないわけではないことが分かったが取り合えずセンサ1,2本をつないで動かしたところ動いてはいるので現状のままにしてある。
DS18B20等の1-Wireバスのデバイスはそれぞれ64bitのユニークなID(ROMID)を持っている。コントローラは各デバイスにIDを指定してコマンド(温度測定開始、変換結果の読み取り等)を送る。なお温度測定開始など一部のコマンドについてはバス上のデバイスすべてに対して同時に送ることもできるようになっている。
P.S.
ところで最近ではレガシーなインターフェースが無いマザーボードとかもあって、USB-シリアル変換器とかUSB-パラレル変換器とか後ろ向きなソリューションを使ってる人もいるかと思いやす。
この手の変換器では対応できないことがいくつかあります。ここに書いたような用途もその一つです。現状、USB-パラレル変換器では絶対に動きません(USB3.0が出てきたら可能性はある)。
USBではフレーム単位でデータの送信が行われ、USB1.1では1ms, 2.0のハイスピードモードでは125μsの単位で転送動作が行われます。なのでホスト側でスレーブのデバイスの信号線を15μs以下の間隔でソフトウェア制御するのは不可能です。 USBしか使えない場合素直にUSBの先にPICなりH8なりMAXIMの出しているプロトコルコントローラICなりを繋ぎましょう。
May 07, 2009
デジタルシリアル出力の温度センサ DS18B20 [computer]
PCなどに接続して使う目的で温度センサを色々検討していた。 従来LM35などの温度をアナログの電圧に変換するセンサとA/Dコンバータを組み合わせるスタイルが多かったが、今はIC化したセンサにA/Dコンバータも内蔵してシリアルのデジタル出力が得られるものも多い。
よく使われるものはPCのマザーボード上の温度測定で比較的よく知られているLM75。 これは2線式インターフェース(データ線が2本。通常別に電源ラインが必要)のI2Cインターフェースが使用されている。
Web上で検索するとMAXIMのDS18S20を使った例がいくつか見つかった。これは1線式の1-Wireインターフェースを利用するもので比較的安価で精度が高いらしい。 MAXIMのサイトにはスペックからICの品種候補を出してくれるページがありこちらで調べてみるとDS18B20というものもあるらしい。 簡単にまとめるとこんな感じ。
| 型番 | インターフェース | 精度 | 分解能 | パッケージ |
|---|---|---|---|---|
| LM75 | I2C (同期2線式バス) | ±2℃(-25℃〜100℃ 最大) | 0.5℃(9bit出力:LSB=0.5℃) | SOP (8pin 1.27mmピッチフラット) |
| DS18B20 | 1-Wire (非同期1線式バス) | ±0.5℃ (-10℃〜85℃ 最大) | 0.0625℃ (12bit出力時 9〜12bit出力) | TO-92 (3pin) |
| DS18S20 | 1-Wire (非同期1線式バス) | ±0.5℃ (-10℃〜85℃ 最大) | 0.5℃ (9bit出力:LSB=0.5℃) | TO-92 (3pin) |
精度については個々のセンサのばらつき以外に温度範囲の中での校正誤差が含まれる。 つまり温度の上限(例えばLM75では100℃近辺)、下限では比較的誤差が大きい。
I2Cバスはホスト→センサ方向のデータ線とセンサ→ホスト方向のデータ線が別で同期バスで通信速度は速い(ノーマルモードで100kbps、最大3.4Mbpsの仕様もある)。1-Wireの場合は1本の線を両方の方向の通信に用い、非同期通信を行う。制御がやや複雑で通信速度は遅い(1bit送るのに少なくとも60μSかかる=16kbps程度。最大142kbpsの仕様もあるがDS18B20のデータシートには記載はない)。 温度測定の場合は扱うデータの量が少ないため通信速度が遅くてもあまり問題にはならない。
DS18B20とDS18S20は外見上もソフト的にもほとんど同じ。値段も1個数百円で大して違わない(MAXIMから直接1000個以上で購入した場合DS18B20の方が安い)。
どうせ使うならDS18B20の方がよいだろう。試しに3個ほど買ってみた。 ちなみに秋葉原のパーツショップでは置いてある所は見つからないので通販を利用した。 最近の傾向として電子部品は標準品やカタログ/web等で確認できるもの以外は通販を使った方が便利。
1-WireやDS18B20/DS18S20についてはWeb上で検索すればそれなりに情報は出てくる。 時期的な関係なのか9bit固定出力のDS18S20の方が使用例は多い。 また、MAXIMのサイトには詳細な情報とサンプルプログラムが置いてあるので参考になる。
書籍ではCQ出版より
「マイコンの1線2線3線インターフェース活用入門」(ISBN978-4-7898-4208-2: 2800円)
が出ていて1-Wire/I2CやDS18S20についての詳しい解説がある。
これは実際にある程度プログラムを動かしてからだが、人に説明する必要もあって買った。
サンプルプログラムもCQ出版のサイトから入手できる。ただしターゲットはPICやH8なので...まあ1-Wireに関する限り普通のPCよりもH8あたりの方が扱いやすいかもしれない。
Mar 03, 2009
PCの機材入れ替えなど [computer]
遊び用のマシンを数週間前から色々部品入れ替え- マザーボード
- Windows XP
- SATAディスク (WD 10EDAS)
- USB地デジチューナー DY-UD200
- FreeBSDのUSBブートイメージ
- 暗号化
945チップセットの物からP45辺りの物に変えてみるかという趣旨。
ASUSのP5Qシリーズがアレだという話を聞いたので少々迷ったあげくAsRock(ぉ)のP45TSにしてみた。P45XEじゃないのはPCIの本数の関係。 このボードはDDR3とDDR2用のメモリスロットが両方あり、どちらかを選べるという仕様。 これでもAsRockにしてはおとなしい方(?)
まずディスクのバックアップを取ったがTrueImageの10はSATAにまともに対応しておらず、compatibleモードで動かすとディスク1本のバックアップに24時間かかると出てきた(!)。(実際それぐらいかかった)
そいでもって暇を持て余し...というのはやっぱり宜しくない。 一部の関係各位にそれでご迷惑をお掛けした。申し訳ない。
後でTrueImage11にアップデートして完了後にもう一度試した所30分でバックアップが終わった。おいおい...
マザーボードを入れ替えてバックアップも完了した所でSP3を適用したインストールディスクでおもむろに上書き修復。あれ?アクティベーション必要なしのようだ。
160Gのディスクは捨てて特売の1Tディスクに入れ替え。後でWindows7でも入れるか。
色々ディスクを入れ替えた関係で一時的にだけどWindowsXP onlyのマシンになったwww
5000円位ならということで買ってみた。秋葉原に行ったらPT1の実物もあったが、録画して見るようなものもとくに無くてモチベーションがわかないのでスルー。
最近物を買うときには一応情報収集してからにするようにしているが、某所でなにやら小規模の祭りが起きていたらしい。
というかね、この値段でこれだけTV見れれば十分じゃないかな?
開いているディスクにFreeBSDの7.1を取り合えず入れてみようかと思ってインストーラのCDで起動したところ、2つめのCPUを認識したあとでCDがタイムアウトを起こして止まる。 インストールCDを作るときにburncdでイメージを書いたが、書き込み完了のところで タイムアウトを起こしていたような気がするので書き込み側の問題かもしれない。 (もっともその同じインストーラCDを他のAthlon64なマシンで起動すると問題なく最後まで起動するのだが)
CDの問題ならUSBメモリから起動するようにすれば問題なかろうということで起動USBメモリを作ってみる。
気分の問題でMD上にスライスを作成してdisklabelを書きパーティションを作った
# dd if=/dev/zero of=image bs=512 count=1200000 # mdconfig -a -t vnode -u 1 -f image # fdisk -i /dev/md1 (ごにょごにょ) # bsdlabel -w /dev/md1s1 # bsdlabel -e /dev/md1s1 (md1s1a を4.2BSDパーティションに) # newfs /dev/md1s1 # mount /dev/md1s1a /mnt (インストールCDのイメージをどこかにマウントして中身を/mntにコピー) # bsdlabel -B -b /mnt/boot/boot # umount /mnt (grubでもboot0でも何でもいいから md1のMBRに書き込んでブートできるようにする) extiplの場合は(extiplインストール済みとして) # extipl install /dev/md1
これでできた作業ディレクトリにあるimage(600MBぐらい)をddでUSBメモリに書き込めばOK BIOSのブートメニューなりBIOSの設定でUSBからブートできるようにするなりすればUSBメモリからインストーラが起動する。
インストーラの中で使用するディスクのなかにda0を入れて/mntあたりにマウントしておくこと(newfsしたら笑える)。インストール元のメディアをファイルシステムにして/mntからインストールするようにすればちゃんとインストールできる。
ただしインストール後に再起動した後/etc/fstabにしっかり/dev/da0s1aが書かれてしまうので再起動時にもUSBメモリはいれて、起動後にfstabを書き換えるように。
こんなもん「初心者」にはまず使えないな。まあインストールスクリプトを少々書き換えればいいんだろうけどね。スライスを作った理由はレスキューディスクを入れたりすることも考えて。
ところでvector等のダウンロード販売して買ったソフトはDVD-RAM等にまとめて入れておいたけど、管理が悪くてみつからないことも(←バカ)
登録IDとかシリアルナンバーとかクレジットカードの暗証番号とかは opensslの暗号化を使ってファイルにして置いてある。何ヶ所かに置いておけば大丈夫だろう。 (マスターのパスワードを忘れなければ)
# openssl enc -aes-256-cbc -in hoge.pass -out hoge.pass.aes256cbc
というようなかんじ。ところでこないだ話題になったopensshでの脆弱性のはなし だけどopenssl 0.9.8eではCTRモードは動くようになっていないようで。 資料読んだ限りでは暗号化そのものについては問題とされていないようだけど どうなんだろう。
それはともかく暗号化した上でbase64の出力も作ることができたり 公開鍵暗号は鍵が大きいなど使いにくい場合とか使いたくない特殊な場合には 手軽に使えるかな。
# openssl enc -aes-256-cbc -a -in hoge.pass enter aes-256-cbc encryption password: Verifying - enter aes-256-cbc encryption password: U2FsdGVkX18NUNbCWKD0E/+ffIYEbA4edxHsvute5rc=
