趣味の電子工作などの記録。時にLinuxへ行ったり、ガジェットに浮気したりするので、なかなかまとまらない。
Z68マシンにUbuntuをインストールしてみました。11.04の新しいインタフェースは好きになれないので、いまだに10.04LTSです。ただし、せっかくなので64bit版を入れてみます。インストール自体は32bit版と何も変わるところはありません。500GB全部をUbuntuに割り当てました。
さくっとインストールを終わって、再起動すると・・・・起動しません。これは明らかにおかしいので、よく考えてみると、今回購入した500GBのHDDではインストールの際にはHDDは認識するものの、起動はできないということになります。HDDに絡む比較的新しいスペックというと、SATA3の6Gbps転送が浮かび上がりました。実際、HDDにも3Gbpsに制限するためのジャンパがありましたので、ここをセットして再度起動してみたところ・・・無事に起動しました。
実際のところ、6Gbpsが原因なのか、使用しているハードディスクリーダライタが3Gbpsまでしか対応していないことが原因なのかはわかりませんが、一瞬あせりました。
実はWindowsXPの方もこれが原因なのかもしれませんので、試してみたいと思います。
引き続きZ68雑用マシンへのWindowsXPのインストールです。
WindowsXPのインストーラはHDDを認識するようになったのですが、ファイルのコピー後にリブートした後、通常ならHDDから起動するところでHDDから起動せずに再度CD-ROMから起動してしまいます。こりゃ、お手上げかな、と思って現実逃避していたのですが、ふとAsrockのWebサイトをみてみると、BIOS（UEFI）のアップデートが出ていました。最新版は1.20で、今入っているのは1.10です。なので、アップデートを試してみることにしました。
です。
しかし、結果は変わらず・・・。もう、諦めます（笑）。
＜9/18追記＞解決できました。原因はハードディスクリーダライタがSATA3に対応していないことでした。
なぜなら、調べてみるとWindowsXPでUEFIをサポートしているのは64bit版のみ。つまり32bit版ではブートの部分が対応してないっぽい気がします。
雑用はWindows7でも入れてやらせるようにするしかないかな・・・。ただ、NASのSambaとの相性とかで引っかかったりしないか不安だったりします。
雑用マシンにWindowsXPをインストールします。インストールにはServicePack3まで統合したCD-ROMを使ったので、すぐ終わると思っていたのですが、これが実は落とし穴でした・・・。Ｚ６８マザーにWindowsXPをインストールするのは結構骨が折れるかもしれません。
まず、インストーラがHDDを認識しません。ディスクコントローラがSATAのコントローラを認識してくれません。これはインテルのWebサイトから「ラピッド・ストレージ・テクノロジー F6 ドライバー・ディスク」のx86版を持ってきて、FDDに展開して追加ドライバとして読ませればいいはず・・・でした。
実際にもってきて、FloppyDiskに展開したドライバを書き込んで、USB-FDDドライブに挿入した状態でインストールCDを起動すると、追加ディスクの読み込み確認のところでとまるので、そこで「S」を押してFloppyを読ませると、AHCIドライバとRAIDドライバがあることが表示されます。そこでAHCIドライバを選択したのですが、結局ディスク（HDD）がないと言われて終わってしまいます。
半ば途方にくれていたところで、よく画面を見ると、ドライバの種類は選択できる（つまり、途中まではFDを読めている）にも関わらず、「FloppyDiskからドライバを読み込むためのFloppy Driveがない」という表示をしています。つまりUSB-FDDでは途中からFDが見えなくなってしまうようです。しかたがないので、nLite（画面のど真ん中に広告イメージ＆リンクがあるので注意）でドライバをインストールCDに統合してトライしてみたところ、無事にその先に進むことができました。
・・・が、また途中で固まってしまいました。よく考えると、WindowsXP自身もAHCIなんて知らないはずですので、ドライバを突っ込んでやらないといけない気がします。今日は遅くなってしまったので、続きは明日考えます。
先にWindows雑用マシンが崩壊してしまい、やむを得ずAtom230なマザーボードにWindowsXPを入れたことは書きましたが、やはりAtom230にWindowsは荷が重すぎて、環境復旧が進んでいませんでした。かといって、そのままではどうにもならなかったのですが、この度ようやくアップグレードしました。
元のマシン
更新後のマシン
となりました。HDDは5インチベイに容易に抜き差しできるようにハードディスクリーダライタ経由で取り付けてあります。用途に応じてHDDを差し替えて使うためですが、このハードディスクリーダライタはインナートレーが不要なことと、ファンがついているので熱的な心配をしなくてもいいことが優れモノです。
それ以外はお店で適当にMiniITXの条件で安そうな組み合わせを選んだだけです。ChipSetはZ68ですが、そもそもメインがLinuxなのでSRT（Smart Response Technology）というSSDをキャッシュにする機能も興味なし（そもそもLinuxで使えるのだろうか？？）ですし、QSV（Quick Sync Video）もよくわからないけど興味なし。メモリはPC3-12800の4GB×2枚セットで 3980円でしたので8GBにしました。PC3-10600なら3000円弱だったのですが、メモリの速度はCPUの周波数以上に効くのでちょっとだけ贅沢してみました。もっとも、8GBあってもWindowsXPの32bit版にはもったいないですが、ハードディスクリーダライタですぐにHDDを交換して64bit版のLinuxなども試せます。OSについてはWindows7 Professional 64bit版を入れることも一瞬考えたのですが、最近Windowsを使うこともめっきり減ってしまったのでやめました。
組み立てた後、試しに元々ついていた320GB SATAのHDDを取り付けてSATAのモードをIDE互換にBIOSで設定してみたら、あっさり中に入っていたUbuntu10.04が動きました。この投稿も更新後のマシンのUbuntuから書いていますがパフォーマンス的には非常に快適です。これからWindowsXPをインストールしなおして、環境再構築です。
とりあえず動くようになったが、いまいち使いにくいので試行錯誤してみます。
fsusbは千秋ゼミに改良版があるようです。UBW開発ツールアーカイブの中にある「UBW用tool」の fsusb-20090218.zip を取ってきて展開、srcフォルダで make、sudo make install でインストールできました。インストールは容易なのですが、やはり root権限がないと動作しません。
こちらのページにある仮想COMポートのスケルトンを取ってきて、展開、hexフォルダにあるhexファイルを書き込んで動かしてみます。ブートモードに変更してから
$ sudo fsusb cdcusb.hex
で書き込んだ後、リセットをかけて、
$ screen /dev/ttyACM0
で仮想COMポートに接続してみると無事にエコーバックが帰ってきました。「Ctrl-A \」で切断して終了です。
Synapticからsdccをインストールした後、srcディレクトリで make をかけるとパスのエラーが出ました。途中の「MY_BASE=C:/SDCC」を「MY_BASE=/usr」に修正すると make に成功しました。
その後、
$ sudo fsusb cdcusb.hex
で書き込んだ後、
$ screen /dev/ttyACM0
でエコーバックを確認できました。さらに、小文字大文字変換をするように変更して再度 make して書き込んで接続すると変更が反映されていることが確認できました。
これでとりあえずUBW + sdccで仮想シリアルポート付きの何かを作る環境が整いました。
ただ、sdccUSB-cdcを改造しようとしてすぐに気づいたのですが、これはMicrochip社のUSBフレームワークをベースにしているようです。このフレームワークはずいぶん前にMPLAB上で弄ったことがあるのですが、割り込みではなくポーリングで動作しています。そのため、処理に時間がかかるとUSBプロトコル上で問題がありそうで、いまいち使いにくかったように思います。とはいえ、Linux上で開発できるのはありがたい話です。
これまでAVR中心に扱ってきましたが、AVRにおけるArduinoと似たような存在として、PICの方でもUBW（USB Bit Whacker）というものがあることを知りました。こちらはマイコンにUSBコントローラを内蔵しているPIC18F2550を使用可能で、しかも、秋月で売っている18F2550マイコンボードをほぼそのまま使えるようです。しかも、ホストとの通信にはデバイス内臓のUSBコントローラを使うということで、極小サイズでデバッグができるようです。
というわけで、試してみることにしました。
ハードウェアは千秋ゼミのサイトを参考に、AE-18F2550を使ってブレッドボード上に構成しました。
UBWでは、ブートローダのことをFirmware Bと呼ぶようです。このFirmware Bは、こちらのページの「UBW driver」というリンクの先にあるB.zipファイルに入っています。これを展開すると、FW_B_20MHz.hexというファイルが「output_20MHz」フォルダの下にあるので、これをWindows上の「PICkit 2 Programmer」で書き込みます。
書き込み完了後、UbuntuマシンにAE-18F2550を接続しても・・・・なにも起きません。動いてないと困るので、ポートRC2をGNDに落としながらMCLRをリリースすると、LEDが交互点滅し、どうやらブートローダが動いていることがわかりました。
次にダウンロード（ブートローダにアプリケーションを流し込んで書き込む）用のプログラムをコンパイルします。
こちらのサイトを参考に fsusb-0.1.11-2.tar.gz をダウンロード、コンパイルします。一次配布サイトなのかどうかよくわからなかったのですが、make一発でコンパイルします。
次に、Firmware D と呼ばれるアプリケーションをダウンロードします。こちらのページの途中に「・・・・ UBW Firmware D released」というリンクがありますので、それをクリックすると、Firmware D の圧縮ファイルが入手できます。これを展開したら、ポートRC2をGNDに落としながらMCLRをリリースして、LEDを交互点滅させます。この状態でブートローダが待機しているようですので、
$ sudo ./fsusb FW_D_2553.hex
として書き込んで、再度MCLRでリセットをかけると、異なるパターンのLED点滅が始まりました。
fsusb をルート権限で動かすのは面倒くさいので、こちらの記事で追加した /etc/udev/rules.d/60-local.rules に
# PICkit2 programmer
ATTRS{idVendor}=="0d48",ATTRS{idProduct}=="0033",GROUP="usbuser",MODE="0660"
# UBW bootloader
ATTRS{idVendor}=="0d48",ATTRS{idProduct}=="000b",GROUP="usbuser",MODE="0660"
を追加してみました。再起動しないと効果がわからないので、うまくいくかわかりませんが・・・。
やっぱりダメでした・・・。何でroot権限要求するのかソース読んでみないと・・・。
さくらのVPSマシンでは遠隔操作ソフトとしてFreeNXを使っています。しかし、最近XperiaArcoを手に入れたので、これで遠隔操作したいと思って調べてみました。残念ながらFreeNXは使用できないようで、主流はVNCのようです。その中でもFreeで使用可能なTightVNCを使ってみることにしました。
で、最新のLinuxで使用可能なTightVNCは1.3.10のようなのですが、ここでは簡単にSynapticからインストール可能な1.3.9-6を入れてみることにします。インストールはSynapticを使うのでごく簡単で、「VNC」で検索して「tightvncserver」を選択してインストールするだけです。
インストールしたら、「アプリケーション」→「インターネット」→「X11VNC Server」で起動し、設定を行います。ここではセキュリティ確保のため、SSHを使ったトンネル接続を行いますので、「Listen on localhost」と「File Transfer: TightVNC」にチェックを入れてOKを押します。さらに、「Accept Connections」とパスワード設定をしてOKを押します。Ubuntuのリモートデスクトップビューアはパスワードがなくても問題ありませんが、Androidの Android-vnc-viewerの方はパスワードがないとアクセスできませんでした。
さらに、TightVNCは暗号化などのセキュリティがないために、sshトンネルと併用しなければなりません。
テストのためローカルのUbuntuからSSHトンネルを掘って接続してみます。
$ ssh -p (SSHポート) -L 15900:localhost:5900 userid@接続先
で手元のマシンの Port 15900 がSSHでログインした先から見た localhost:5900 にトンネル接続されます。この状態でローカルのリモートデスクトップビューアで localhost:15900 に接続すると、リモートマシンの画面が表示されました！
ATmega644には無印644、644P、644A、644PAがありますが、それぞれ微妙に機能が違います。
その違いをブロック図で見ていきたいと思います。（それぞれデータシートから抜粋しました）
まず無印644です。
次に、Sanguinoに使われていて、秋月でも扱っている644Pです。ちなみに秋月のサイトに掲載されているデータシートは644Aのものだったりします。
大きな変化では、
というところが変わっています。
さらに644Aです。
さらに、644Aでは16bitのT/C3が追加されているのと、なぜかもう一つ16bit T/C1 の箱が増えています。また、ポートとの接続も複雑になっています。
次に644PAです。
644PAでは大きな変更はなさそうです。
644、644P、644A、644PAでは微妙に差があるので、データシートを見るときは気をつけてみる必要がありそうです。
次にアナログ入力を試してみたのですが、サンプル「AnalogInput」をコンパイル＆実行しようとしてみると、エラーが発生します。
エラーの原因は
int sensorPin = A0
の行で、「A0」が未定義ということのようです。で、元からある arduino-0022/hardware/arduino の下のファイルと、追加した arduino-0022/hardware/sanguino の下のファイルを見比べてみると、WProgram.h のファイルにA0～A15の設定が抜けていることがわかりました。
そこで、arduino-0022/hardware/arduino/cores/arduino/WProgram.h から以下の部分のうちの黒字部分と、ATmega644Pの記述（赤字の部分）を追加しました。
#if defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__)
const static uint8_t A0 = 54;
const static uint8_t A1 = 55;
const static uint8_t A2 = 56;
const static uint8_t A3 = 57;
const static uint8_t A4 = 58;
const static uint8_t A5 = 59;
const static uint8_t A6 = 60;
const static uint8_t A7 = 61;
const static uint8_t A8 = 62;
const static uint8_t A9 = 63;
const static uint8_t A10 = 64;
const static uint8_t A11 = 65;
const static uint8_t A12 = 66;
const static uint8_t A13 = 67;
const static uint8_t A14 = 68;
const static uint8_t A15 = 69;
#elif defined(__AVR_ATmega644P__)
const static uint8_t A0 = 24;
const static uint8_t A1 = 25;
const static uint8_t A2 = 26;
const static uint8_t A3 = 27;
const static uint8_t A4 = 28;
const static uint8_t A5 = 29;
const static uint8_t A6 = 30;
const static uint8_t A7 = 31;
#else
const static uint8_t A0 = 14;
const static uint8_t A1 = 15;
const static uint8_t A2 = 16;
const static uint8_t A3 = 17;
const static uint8_t A4 = 18;
const static uint8_t A5 = 19;
const static uint8_t A6 = 20;
const static uint8_t A7 = 21;
#endif
さらに、これを処理する部分があるはずなので、探したところ、同様に wiring_analog.c の中の、analogRead()という関数で処理していそうだったので、同様に以下のように黒字部分を arduino-0022/hardware/arduino/cores/arduino/wiring_analog.c から追加し、さらに赤字部分をオリジナルで追加しました。
#if defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__)
if (pin >= 54) pin -= 54; // allow for channel or pin numbers
#elif defined(__AVR_ATmega644P__)
if (pin >= 24) pin -= 24; // allow for channel or pin numbers
#else
if (pin >= 14) pin -= 14; // allow for channel or pin numbers
#endif
これでサンプル「AnalogInput」も無事に動作するようになりました。
ただ、これだけの記述だけではデジタルピンが sanguino.ccに掲載されている端子配置にならないような気がしたのですが、上記の変更でデジタルピンもこの順番で動作するようです。
・・・もう少し調べてみたら、arduino-0022/hardware/sanguino/cores/arduino/pins_arduino.c の中の配列 digital_pin_to_bit_mask_PGM[] の中で、PortAだけ逆順に並んでいました。ここでデジタルピンの並び順を変換しているようですね。
ライセンスを見ると、LGPLのようなので、差分を取り込んだファイルを添付（sanguino_analog.tar.gz）しておきます。同名のファイルを差し替えれば同じレベルになるはずです
無事にコンパイルできることが確認できた（といっても、Blinkだけですが）ので、ハードウェアを準備します。確認のターゲットはまずはサンプルプログラムBlinkです。なので、（Arduinoでの）デジタル１３ピンにLEDを接続したものを点滅させるのが目標になります。
最終的に作ったハードウェアはこんな感じです。（途中の写真がないのですみません）
16MHzのクリスタルと22pFのコンデンサ２つ、Vcc/GND間のパスコン（チップセラミックコンデンサ1uF）を実装した小さな基板を作って、ブレッドボード上のATmega644Pのそばに取り付けました。さらに、リセット端子のプルアップ抵抗と電源供給の配線を行っています。画面左上の青いコンデンサは自動リセット用のDTR信号にかませる0.1uFのコンデンサです。右上の緑色の基板はホストとの通信用のAE-UM232Rで、上の写真ではすでに接続済みです。写真下にはちょっとだけLEDの頭が見えています。
これで問題なく無事にLEDが点滅しました。