Raspberry PiのWiFi設定-DHCPから固定IPアドレスまで最速版

有線のLAN環境がないところでRaspberry PiのWiFiを設定する方法。いろいろ混乱があるようなので、2014年6月20日版Raspbianで最短(当社調べw)の設定手順を最短で書く。

Raspbianが起動している状態で、login: pi, Password: raspberryのデフォルトアカウントでログインしているところからはじめる。

$ sudo bash
# chmod 660 /etc/wpa_suoplicant/wpa_supplicant.comf
# wpa_passphrase SSID KEY >> $* ← SSIDもKEY(パスワード)も、特にダブルクォートなどで囲むことなく、そのまま書く。ハッシュしたほうに、それがKEYの文字として含まれしまい認証エラーになることがあるるようだ。
# vi $* ← 編集する。

内容は、以下のとおり。

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
network={
    ssid="SSID" ←コマンドで指定したSSIDが入っている。
    key_mgmt=WPA-PSK
    proto=WPA2
    pairwise=TKIP CCMP
    group=TKIP CCMP ←ここまでの4行追記
    #psk="4332221111"←コマンドで入力したまま
    psk=9a7cdfea2bbbda47edacc95b2ae7a1c..... ←長いハッシュされた鍵が生成されている  
}

複数のWiFi接続先があれば、上のwpa_passphraseコマンドでのハッシュを含むnetworkエントリ生成から、4行追記を繰り返す。

続いて、/etc/network/interfacesファイルの編集。Raspbianの設定のままではWPA2のWiFiスポットに接続しないので、それをまず直す。

auto lo

iface lo inet loopback
iface eth0 inet dhcp

allow-hotplug wlan0
iface wlan0 inet dhcp　←なぜか"manual"になっているが、素直にdhcpするように直す
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf　←wpa-roamはwpa-confにしておく
iface default inet dhcp

この状態で、

$ sudo ifdown wlan0
$ sudo ifup wlan0

するとDHCPでのアドレス取得がいつまでたっても終わらないので、迷わず上記はやらずにsudo reboot。

WPA2のSSIDと共有鍵さえ間違っていなければ接続できるはず。逆に、いくらやっても接続できないなら、記述を見なおすとか、wpa_passphraseを再度実行するのもよいかもしれない。また、WiFiドングルが2.4GHzまで対応なのか5GHz対応なのかで違ってくるので、2.4GHzまでの安いものを使うなら、WiFiスポットが2.4GHzでの接続に対応するよう設定しておく。記述は正しいと考えれれるのにつながらないならWiFiルータの再起動で解決することもある。

ここで、/etc/resolv.confの自動生成をするパッケージresolvconfを入れる。

$ sudo apt-get install resolvconf
$ sudo service resolvconf start

WiFiでDHCPにより接続できているはずなので、apt-getなども問題なくうまくいくはず。だめなら設定を見なおすとかエラーメッセージをよくみて考えるなどして解決する。ときには、WiFiルータ側を再起動する必要があるかもしれない。特に混雑しているAPは、新たに一台追加する余裕がないときがあるので、ルータ再起動でいちはやく接続を勝ち取るのは有効な戦略。

最後に、固定IPの設定に変更する。/etc/network/interfacesをそのように書きなおす。

auto lo
iface lo inet loopback
auto lo

iface lo inet loopback
iface eth0 inet dhcp

allow-hotplug wlan0
iface wlan0 inet static　←固定IP設定を宣言して、以下パラメータを入れる。
address 192.168.1.xxx ←使う予定の固定IPアドレスを書く
netmask 255.255.255.0 ←接続するネットワークの設定に合わせる
gateway 192.168.1.1 ←default routeを決めるので、ネットワークの設定に合わせる
dns-nameservers 192.168.1.1 ←/etc/resolv.confの設定にかかわる。ここではWiFiルータを指しているがいつまでも安全とはいえないので、ひとまず信頼できるDNSを書いておくのは悪くない（が、8.8.8.8は愚の骨頂だと思う）。
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
iface default inet dhcp

「address」から「dns-nameservers」までの追記が正しければ、以下の手順でうまくいく。

$ sudo ifdown wlan0
$ sudo ifup wlan0

このときに、「can't read /etc/network/interfaces」などと出たら、そのファイルの記述が誤っていないか確認すべき。

あとは再起動しようがなにしようがWiFiで固定IPの設定が維持されるはず。 

Eagleでプリント基板のデザインをして発注するまで（追記あり：ドリルデータとドリルリストについて）

来週末は、勤務先のイベントで小学生対象の「ものづくり教室」の担当。去年実施したのが、Parallax社の8 core 32bitマイコンであるPropellerを使った、ドラムシンセサイザーだった。

内容は、Propellerのプロジェクトとして公開されている、Amiga Commodor 64の音源チップSIDのエミュレータを使い、シンセドラムっぽい音をプログラムで自作したもの。欧米を中心に「SID Tune」という分野があって何千曲ものデータ蓄積があり、SIDはレジスタに書かれたパラメータに合わせて音響信号を出すだけのLSIなので、プログラムで高速制御して見事な効果を含む演奏する専用プログラムがあったほど。いまでも「SID Emulator」が各OS用にいろいろあって、バイナリに変換されたSIDレジスタ書き込みシーケンシャルデータを読み込んで再生することができる。それらには及ばないものの、僕もPropellerマイコン内蔵インタプリタを直接呼び出す言語「SPIN」で、様々に試行錯誤を突貫で行って、まぁなんとかできたという感じだった。

もともとの志は高かった。叩く部分、通称「パッド」にピエゾスピーカーを仕込んで、高速なA/Dコンバータならば、衝撃力に応じた電圧をばっちり計測できるところまで実験は済んでいたのだが、使ったチップがAnalog DevicesのADC124S021というもので、これはParallaxのActivity Boardという実験用基板で採用されているので、カリフォルニア本社まで出かけて諸々懸案を電子エンジニアと相談して解決したものだった。

ところが、このADC124S021はTSSOP10という、足の間隔が0.5mmの表面実装パーツで、DIP変換基板を使わないと自作基板の実験さえできないし、当時はDigikeyにしか在庫がなく、たしか1個400円ぐらいだったような気がする。10名参加で、このADCは4channelなので5つのパッドのためにひとりあたり2個、故障やはんだ失敗などを見込んで全部で30個を買った。DIP変換基板で0.5mmピッチの10pinで手頃なものはたまたま在庫がなく、Aitendoの18pin用をカットして使ったりした。それで、変換基板への手ハンダはうちの学生さんが職人技でやったんだけれど、そのあとピンヘッダを、教室実施の前夜にものすごくおおざっぱにつけたおかげでADCが浮いてしまい全部オシャカ（ICは生きているはずなんだが足を直す時間なし）という衝撃の事態があり、タクトスイッチに置き換えることになったりした。

アンプは、Activity BoardはRail-to-Railのオペアンプを使ってΣΔDACを組んで、たいへん良好な音を出していたんだけれど、カネが続かないので秋月のいちばん安価なオーディオ・アンプを選択したのが敗因で、すごくS/Nが悪く（あとから、秋葉原の店頭でアルバイトの男子学生さんっぽい従業員に尋ねたら、「僕も試してみたんですけどたしかにノイズ多いです」と答えてくれた）、回路が同じでも実装のしかたで音が全く違ってしまい、ブレッドボードで最適な増幅度とS/Nを見出しても、ユニバーサル基板に組むと、どれもまともな音が出なくて個別に調整というたいへんな思いをした。

そんな疲労困憊の記憶があるので、今年は両面基板を製作してリフローするんだと決めていたわけなんだけれど、PCBミルを自作してみたものの経験が足りなくて0.1mmの精度は出せず、そうしているうちにFusion PCB（安くて早いので有名な深圳のSeed Studio社のサービス）のリードタイムにも間に合わないことがわかり、最短翌日出荷に対応する、静岡県磐田市の「プリント基板センターPB」さんにお願いすることにした次第。前日到着は怖いので木曜到着を考えると水曜出荷で、金曜日に受け付けても月曜からの計算になるので3日コースということになった。この工場ですけれど、見積をオンラインでざっくりできるのでみていただきたいですが、特急であることを考えたらかなり安いほうだと思います。納品したガーバーデータも夜遅くまでひとつひとつチェックしてくださって、対応はとても良好な感じです。

まぁそういうわけで、3日寝ないで名古屋まで出かける非常勤講師の授業もこなしたりしつつ作ったのがこれ。ちなみにその前日までは、前エントリーのRaspbianのSDカード量産なんかをしていたので、週末から数えてやっぱり全く寝ていない。

Eagleの画面
SMD部品のサイズがいろいろなのは入手できたのがそれしかなかったから

今週末もArduino量産とかいろいろあるので徹夜が続く予定。

それはともかくEagleなんだけれど、回路はぶっちゃけActivity Boardの流用（オープンソースハードウェアです）に、去年の夏のノウハウが入ったものなので、回路図はライブラリを集めるのに苦労したけれどわりとさっくりできた（徹夜をはさんで2日でできた）。問題は図の右下をみていただくと気づかれるかどうか、スライドスイッチが裏面にあるわけです。

ケースも3Dプリントしたものを使うのだけれど、小学校3年生がネジ止めで工作できる範囲というと、ケースの上面にはスピーカーと電源スイッチ、電源ランプ相当のチップLEDの窓がある形にならざるを得ず、簡単で安価なのは基板をフタにネジ止めすることで、したがって電源スイッチとLEDが基板の裏面にあって、表面から電池ボックスのコネクタやスピーカーの端子にアクセスする形をとることになるというわけ。

ここでようやく本題。Eagleは部品を裏にまわすには、基板エディタでパーツを選んで「Mirror」ボタンを押せばいいのだけれど、それは表面実装部品の場合で、Padがあるスライドスイッチはそうはいかない感じでありました。シルクは反転して裏面に行っている感じなんだけれど。それでPadの上に同じ形のSMDパターンを置いたりなんだとやったら、当然ERCでも文句言われるし、オートルーティングでも無視されたりするわけです。

しかたがないので手で配線を引いてやるわけですが、そのあとのオートルーティングもベタパターンもどうも具合が悪い。

やむなくライブラリを手編集すべえと調べてみたら、ライブラリ（.lbrファイル）ってXMLのテキストファイルなのですね。で、DTDはdocの下にあるeagle.dtdなんだと。それで、DTDの<pad>タグの定義にLayerを追加したりとか変なことをしているうちに、「Info」ボタンから「Properties」を開いてやると、「mirror」というチェックボックスがあるじゃないですか。それチェックしたら、TOPレイヤーにPadが描かれて（緑色のPadの上に赤のクロスハッチが上書きされた状態になる）、これでオートルーティングかけると何事もなかったかのように未配線を残さず完了するわけで、ここまでたどりつくのに3時間かかってすごく残念な気分になりました。

これをチェックすればスルーホール部品でも裏面に移動できる

Eagleのネット上での説明というと、「EAGLEによるプリントパターン自動作成」が唯一まともな資料として他の説明もすべてそこにリンクされているわけですけれども、両面基板だとかSMDだとかのことは書いてないわけです。そもそも、最終工程がエッチングなのでして、基板発注をお安く個人がする時代のちょっと前の記事です。

そういうわけで、ガーバーデータを出力するのは、例えばCuBeatSystemsさん（個人）のページとかが簡潔にまとまっているのかな、というところ。ガーバーデータを確認するビューアは、3Dプリンタがらみでいろいろ入れているのでいつのまにかgerbvが入っていたのでMacでもことなきを得た感じ。

（追記：「ドリルデータとドリルリストがありません」とのご指摘をプリント基板センターPBご担当者様からいただき、急ぎ送信しました。諸々は「P板.com」さんの手順と同じなんだろうと思うので、Cam Processorのジョブでexcellong.camを実行する形で作成したんですが、ドリルデータってG-Codeなんですね。へえって思いました。2014-07-07）

あと、今回はプリント基板センターPBさんに、特別にメタルマスク（英語的にステンシルというと思っていたんだけれど、それでは通じないんですね）も製作してもらうことにしたので、メタルマスク出力用の設定追加は「Eagleでメタルマスク用ガーバーデータを出力する」のブログエントリをみて実施しました。

当初の構想では、カッティングマシンでコート紙でも切ればいいやと思っていたけれど、最小ピン間0.15mmなんでたぶん無理だろうと。試行錯誤している時間がないからプロに頼むと。

いずれにせよ、プリント基板製作にもメタルマスク作成にもCNCミル使っているはずなんで、自作するなら手堅くプロクソンのフライス盤をCNC化していく方向から経験を積んでいかねばならんだろうなと思っているところ。

そして、レジストとシルクなんだけれども、レジストは塗布後にマスクを印刷したフィルムを載せて紫外線に当ててから洗えばいいのかと。参考

シルクは、インクジェットプリンタでプリントゴッコ（昭和の記憶）的にやるのが簡単そうだなと。参考

あとはあまり考えたくないんだがリフロー前のマウンタも自作したりしたら実装の内職できるんじゃないかみたいななにか。

そういえば、クリームはんだ（はんだペースト）をまだ買ってないのだった。大昔にシリンジに入ったのを買ったのがどこかにあるはずだが、フラックス足せば古くても使えるとか読んだんだがそれで足りるのだろうか。アマゾンで65gの瓶が3000円で出ているが、価格を出している業者を見ると980円なんで、えらいぼったくりだなと思ったり。参考

それで、検索すると「クリームはんだ印刷機」というのがいつもトップにあるんだけれど、いまどきはマスクみたいな再利用がきかないものは作らないんですね。ついでに「クリームはんだロボット」という見出しが別に見えたので、もしかすると3Dプリンタのエクストルーダ改造で、シリンジ入りのソルダペーストをプリントできるんではないかと思った。

Raspberry Piでドリトルを実行する（解決・追記あり）

（追記：最新のRaspbian（2014/6/20付）ではOracle JDKの7と8が最初から入っているので、以下の記述の先頭にある、apt-getでOracle版を入れる作業は不要です。2014-07-02）
（追記：Oracle Java EE 8 JDKを使うということと、RXTXが使えるようなshell scriptに訂正した。headlessとheadfulについても補足した。2014-07-01）

以前にも書いたのだけれども、教育用プログラミング言語「ドリトル」は、OpenJDK7で動作するが、いまはOracle Java EE 8がheadlessじゃなくてAWTも含む形で配布されているので、そちらを使うことにする。なので、

$ sudo apt-get install oracle-java8-jdk

でいくことにする。以前、openjdk-7-jreを入れていた人は、

$ sudo apt-get delete openjdk-7-jre
$ sudo apt-get autoremove

してから、Oracleのやつを入れることになると思う。というのも、どうも、OpenJDKでRXTXが使えているという話がなくって、Oracleのを使えという意見が散見されるから。実際には追ってないのでよくわからないけど。

ただ、Oracleので実行すると、日本語フォントが明朝になるのがどうも残念。このあたり誰か教えてほしいかもしれない。

（追記：OpenJDK-7が持っている、fontconfig.propertiesを/usr/lib/jvm/*/jre/lib以下に置いてやれば解決した。したがって、いったんOpenJDK-7を入れてから同ファイルをどこかにコピーしておき、apt-get remove後に当該の場所へ残しておいたファイルを入れてやればいいことになると思われる。なお、この設定ファイルはvlgothic, IPA, sazanamiあたりを使うので、もしこれらのフォントが入っていなければ、apt-get install fonts-ipafontなどで入れてやらなと効果が出ない。）

それで、ドリトル本体なのだが、普通にzipファイルを展開してもうまくいかないので、だいたい次のような手順をとればよいのではないかと思う。

$ cd 　　←ホームディレクトリにいる。ここにダウンロードしたzipファイルを置いておく。
$ mkdir dolittle
$ cd dolittle
$ unzip ../dolittle232.zip　←適当に、その時点での最新のものを展開
$ rm -r lib*　← RXTXライブラリがIntel用なので捨てる
$ sudo apt-get install librxtx-java　← ARM版のRXTXをインストールする

それで、dolittle.shは、以下のものに置き換える。

#!/bin/sh
cd /home/pi/dolittle
java -cp /usr/share/java/RXTXcomm.jar:dolittle.jar -Djava.library.path=/usr/lib/jni -Dgnu.io.rxtx.SerialPorts=/dev/ttyAMA0 o3.UI 2>&1 /dev/null &

要するに、ドリトルを展開したディレクトリをカレントディレクトリにして、そこでjava実行し、標準エラー出力に出てくるJVMのエラーメッセージを/dev/nullに捨てるということ。

（追記：2>&1じゃないと、1って名前のファイルができますな。すみません。それと、/usr/lib/jniの下にRXTXのネイティブコードがあるんだけれど、そこをオプションで指さないとだめみたいだったので、追記しました。さらに、Raspbianの場合、シリアルポートをシステムプロパティで指定する必要があるんだそうで、この一連の作業でRXTXの問題が完全解決しました。2014-07-01）

Raspberry Piの場合、例えばArduinoを接続すると/dev/ttyACM0というデバイスができる。これは特にシステムプロパティで指定しなくてもドリトルから見つかるのだが、通信の設定が正しいかどうかは不明。デジタルもアナログも、コマンドはドリトル側から送信するのだがArduinoは正しく受け取っていないように見える。一方、GPIOに出ているシリアルポートは/dev/ttyAMA0で、これを使うと問題なくArduinoと通信することができた。

Arduinoのシリアルポートは5Vで、Raspberry PiのGPIOは3.3Vだから、直結してはいけない。正しくはレベルコンバータを通して（専用ICもあるけれどトランジスタと分圧抵抗で自作してよい）つながなければ、Raspberry Piを壊す可能性があるが、シリアルに関しては、この記事にあるように、RX端子だけ分圧するのでなんとかいけるようだ。同記事には、GPIOのシリアルポートをシリアルコンソールを解除して自由に使えるようにする設定も記述されているので参照されたい。

なお、Javaのシステムプロパティを操作しなければいけないという話は、ArduinoのサンプルJavaコードのコメントに書かれている。

（追記：今回の場合、dolittle.jarが相対パスなので、カレントディレクトリをdolittle.jarがある場所にしておかないと、headless modeという、グラフィック機能をオフにしたJVMが起動してしまうことがある。headfulかheadlessかのフラグは、システムプロパティのjava.awt.headlessに論理値で指定できるので、javaのオプションに「-Djava.awt.headless=false」を書いておけばheadlessが選ばれる可能性はなくなるが、カレントディレクトリが間違っていた場合は結局「o3.UIが見つかりません」とか「mainが見つかりません」のようなエラーになるので、よしあしではある。このへんは、Oracleのjava seにおけるheadlessについてのページに書かれている。 2014-07-01）

さらに、デスクトップにアイコンを置くために、ayumi.pngをjarから取り出しておく。

$ unzip dolittle.jar image/ayumi.png
$ mv image/ayumi.png .
$ rmdir image

で、デスクトップの設定を以下のように書いておく。ファイル名は、~/Desktop/dolittle.desktopでいいと思う。

[Desktop Entry]
Encoding=UTF-8
Version=1.0
Type=Application
Exec=/home/pi/dolittle/dolittle.sh
Icon=/home/pi/dolittle/ayumi.png
Terminal=false
Name=Dolittle
Name[ja]=ドリトル
Comment= Dolittle Programming System
Categories=Application;Education;Development;
MimeType=application/x-dolittle-program

Scratchの設定をパクらせてもらったので適当だけれど、まぁこんな感じなんではないかと思う。さらにこれをLXDEのメニューに反映させるため、

$ sudo cp dolittle.desktop /usr/share/applications

しておくと幸せな感じになるような気がします。

LXDEのメニューに追加された

ドリトル実行中

tt-rssとReeder

Google Reader終了後、いろんな他サービスに移行した人は多いと思うのだけれど、僕のみたところ、どこも広告リンクを踏ませて収益を得ようとするとか、行動ターゲティング広告を狙ったようなアクセス解析に使うことを目的としたのが露骨に現れたサービスが目立ち、全く使う気になれなかった。

そんな折、自前サーバでフィードのアグリゲーションができるサーバとしてtt-rssの存在を知った。僕はさくらのVPSを借りていて、FreeBSDを入れていたのだけれど、portsにtt-rssも入っていて、簡単に使えたのでおすすめしたい。なにより第三者にどんなフィードを読んでいるかを知られることもなければ不要な広告リンクを踏まされる必要もない。あえていうならば、feedlyが人気らしいが、あそこはすべての記事が広告リンク経由になっているから、莫大な収益が得られているはずだ。ワンクリック0.1円だとしても、1万人が平均1日100アーティクル読むだけで10万円、世界的に利用者がいるはずなので、その1000倍は稼いでいるはずだ。その意味では、Flipboardのような、マガジン形式にするサービスも同様にアクセス解析等で収益を得ているはず。RSSフィードを活用している人は、自分がどれだけ相手の事業に貢献しているのか、儲けさせすぎていないか考えてよいのではないだろうか。

一方で、tt-rssのモバイルアプリとしてAndroid用があるが、これも決してよいUIではなく、改善が求められると思っている。それ以外はモバイルWebに対応させる手段しかなく、ttrss-mobileは簡単だが素朴にすぎ、g2ttrss-mobileは僕のところでは動かなかった。

しかし、iPhone限定ながら、Google Reader用RSSリーダとして非常に洗練されたアプリであるReederから、tt-rssにアクセスできるプラグインがあることを検索で知った。

tt-rssのフォーラムで公開されている、Feverプラグインがそれだ。Feverという、なにやら閲覧履歴からおすすめを温度で提示してくれるらしきフィードアグリゲーションサービスがあるようだけれど、そのAPIを模したプラグインがtt-rss用として提供されている。現在のバージョンは1.2。スレッドトップの記事のattachmentのところにリンクされているので、zipファイルを展開し、自分のtt-rss/pluginsの下に展開し、Webの設定からプラグインを有効にしてやればよい。Reeder側からはFeverの設定として、自前のtt-rssサーバのFeverプラグインのURIを指定し、tt-rssの自分のユーザと、プラグインで設定したパスワード（tt-rssのユーザパスワードとは独立）を設定すればよい。メールアドレス入力をするようReederから指示されるが、そこは無視してユーザ名を入れればよい。

iPadの場合、タブレット向けUIを犠牲にしてiPhone用アプリをそのまま使うか、4種類のアプリがApp Storeにあるので、それを使うことになる。ひと通り見てみたが、いずれもtt-rssのWebインタフェースを超えるものではなかったので、無料の「Tiny Reader」で十分ではないかと思う。300円のTTReaderはスクリーンショットでは一見よさそうに見えるが、特にこれといった機能があるわけではなく、シェア機能に「Pocketに入れる」がある程度だったりする。Reederの利点であるMobilizerを通すものはひとつもないので、Mobilizer必須ならば、ReederのiPhone版一択だが、個人的感想ではそれほど悪くないと思っている。

（追記：「tt-rss Reederテーマ」を試してみた。PC上のChromeでは素晴らしい表示。機能もかなり近づけられていてたいへんよいが、iPadのSafariではやや遅めの印象。iPad Airなど最近の機種ではどうかわからないが、iPad 3では厳しかった。）

富士通FMV-C8230でUbuntu

Windows XP終了で職場から大量放出された、職員用ノートPCを引き取ってきた。富士通の仕様のページに書かれているように、これは法人向けモデル。

さすがに7年前（2007年購入とラベルに書いてある）のマシンだけにやや不安だったけれども、無事パーツ入れ替え等でUbuntuが使える状態になったので報告。

まずメモリ、これは裏側の大きな蓋のなかにDIMMスロットがある。最大4GB。Core2Duoなんだからなんとかしてよーと思わないでもないけれども、マザーボードの設計がそうなんだそうで、やむなし。

「DDR2 PC2-5300」と書いてあるので、それに応じたメモリを買ってみた。製品だと、DDR2-667と書いてあるものに相当するようだ。2GB2枚セットで比較的割安だった、「UMAX Castor DCSoDDR2-4GB-667」で問題なし。

次がHDDなんだが、入っていたのは40GBの富士通製MHW2040BWとかいうドライブだったけれども7年毎日使ったものなので外して、SSDを入れることにした。予算がないので64GBにしたんだけれども、店頭では「ビッグドライブに対応していない可能性があるから120GBより大きいのは避けたほうがいい」とも言われて納得してたんだけれど、ネットをみると500GB認識したとか750GBでもとかいう話があって、「たいへん残念だ」。値段同じぐらいだから。1TBもいけるんではないか説も目にしたような気がするんだけれどもよく知らない。なお、SSDといっても所詮本体がSATA 1.5インタフェースなので速度はそう出ないから、最近のHDDでも十分限界まで引っ張れるのではないかと思う。

HDDはねじ1本で本体から外れる。そのあと、4本のねじでマウンタに固定されているので取り替える。もとは9mmだけれど、7mmの高さでも問題なし。固定されるから。というか、ネジ穴は面一というか底一で合う位置にあるので特に浮くという感じもない。

最後がCD-ROMのスリムDVDスーパーマルチドライブへの交換なんだけれど、これがネットのどこにも外し方が書いてないというぼやきを見たので、ここに書いておく。あ、ドライブのタイプはIDEなので、間違ってATAのドライブを買わないように（自分のことだが）。

んで、各種ネジをまとめて書いておいた。

FMV-C8230の裏面

この写真で見るように3つのネジだけで留まっているので、これを外してから、ゼムクリップを伸ばした針金でドライブトレイを開け、そのまま引き抜けばよい。と思ったら、左端は関係ないみたいね。たしかにドライブに取り付けられている金具に対応するネジは右の2本なので、これだけ外せばよいと思う。

参考

ベゼルは切り欠きがあるので、市販のドライブのベゼルとは違うから、うまくツメを精密ドライバなどで外してうまく引っ張れば外せる。新しいのも外して交換してやればよいわけだが、「DVDのロゴがない」という割と残念な結果になるので、同じ形になるよう切り取ったほうがいいような気がする。ミニ丸鋸盤かバンドソーあたりの機械があれば一発だと思う。もとのベゼルも結構周囲から浮いているので、あまり厳密な寸法で切らなくてもよいのではないか。

あと適当なドライブを挿してみて、BIOSで認識するかどうか、起動時にENTERを叩いてBIOSのメニュー項目を選んでみるわけだけれど、認識しなかったらマスターの設定になっているので、スレーブになるよう、「47番ピン」を倒し、それでだめなら「48番ピン」を倒して47番ピンとショートさせる、という作業がいるようだ。このページでは「千枚通しのような先端のとがったもの」と書いてあるけれど残念ながら当方には各種工具はあるものの文房具がいまひとつなので、カッターナイフの先端で端子を引っ掛けて内側に倒してみた。90度倒すために押しこむのは必要ないかもしれないけれど、精密ドライバあたりで押し込んでみたり。

今回はAmazonで2200円ぐらいだった東芝のドライブだったんだがこれに該当したので経緯を記すと、47番ピン（写真でいちばん奥から2番目）だけを倒した状態でBIOSセットアップでは認識したが、Ubuntuで認識せず、48番ピンも倒してショートさせたらBIOSセットアップから消えたけれどUbuntuで認識されるという不思議な結果だった。LinuxだからBIOS関係ないところがあるのかもしれないし、あまり深く考えていない。

で、UbuntuはDVDメディア入れないとファイルシステムにマウントされなくて、ファイルブラウザーからも見えないのね。最初慌てたので為念。

と、実はUbuntuのインストールはSDカードで行ったので作成したDVDは、このチェックのとき初めて使った次第。

SDカードをUSBカードリーダーに挿して、何か適当な方法でISOイメージを書き込んで（Mac OS Xなのでddで書いた。Raspberry PiのSDカードイメージ作成の説明が該当するので調べてください）、BIOSセットアップの起動順序で「USB HDD」を先頭にもってくればSDカードから起動する。たぶんDVDを読むより速いのではないかと思う。わりとあっさりとインストール完了したので偉いもんだなと思った。

そういえば忘れてたけど、Core2Duoなので当然64bit版OSを入れるべし。メモリも4GB全部（といっても一部はVRAMとシェアするので3.3GBぐらいしか使えないけど）使うんだったらWindowsでも64bit版が必要。

使用感だけれど、単体で使う分には特に問題ない印象。x11vncでMacと画面共有しようとするとXサーバが2つ立つことになるのでメモリが足りない感じがする。やはりスワップがあるとちときつい。

それから、古いマシンなのであまり省エネではない。CPUとかの発熱があって、いまどきのマシンと較べるとかなり熱くなるし、それほど静音というわけでもない。キーボード等もへたっているし液晶も4:3で四角いのでなんというか、「ラップトップ（というにふさわしいと思う。いまでは）のままでは使いたくない」感じ。なので、そのへんに置いて画面共有で使いたい。とはいえ発熱が結構あって、この手のマシンはキーボードやパームレストあたりを放熱に設計されていたりするので、液晶パネルを閉じた状態で動かすのは怖い。したがって開いたまま放置することに。いいんだか悪いんだか。

そういえば、7年前のマシンだけれどEthernetは1000Base-Tに対応しているので有線なら通信が遅いということはないはず。以前、ミニWiFiルータ（ホテルに有線しかなかったときに無線にしたりするアレ。といってもいまどき有線しかないところはあまりないので出番がない）のおまけについてきたUSBドングル（150Mbps）があったので、配線面倒でそれを挿して使っている。

で、このマシンが何になるかというと、前のエントリに書いたFxOSビルド用のつもり... だったんだが残念な結果になったのでいまのところ用途がない。まぁ、オープンソースの世界だと「Ubuntuでビルド」がデフォルト的なところがあるので、例えばRaspberry Pi用バイナリのクロスコンパイルなど、ARMのバイナリ作成用になる予感がする。

（追記）そういえばRaspberry Pi用mozcのクロスビルドという重要な用件があったっけ。セルフでビルドすると半日以上かかる感じなのでクロスビルド重要。そのうちやってみる。

[Nexus 7 2012] MultiROM

先日2月9日に行われた「Firefox OS勉強会 in 名古屋 2nd」にて刺激を受けて、いま使ってないNexus 7 (2012, つまり初号機)にFxOS（と略すらしい）を入れるべくビルド環境を作ったりしていたのだけれど、ビルドできるのは2013年版、つまり新しい、Snapdragon使ってて、高解像度なNexus 7用だけだった。

どうも以前に移植を試みた人がいたようだけれどまだその頃はFxOSも開発途上でタブレットのことが考えていなかったことなどもあり、移植できたけど使えねーということで投げてしまい、そのままになっていたところ、なぜか2013年版にがりがり取り組む別の人が現れてそのまま、という状況らしい。

Galaxy S2とかがターゲットだったりする一方、タブレットへの取り組みは遅れているようで。1.3はだいぶ改善しているという話だけれど、いまさら2012年版に取り組む人がいるのかどうか、オープンソースプロジェクトのジレンマというか、やる気のある人がいないとだめだねってことみたい。Mozillaのサイトにも、Galaxy Nexusは最近聞かないから動くかどうかわからん（MDNのこのへんのTire 3んとこに書いてある）とかあるし。

でもまぁ、一丁emulatorでもビルドしてみるかと./config.sh emulatorとかやっても、

... A new repo command ( 1.21) is available
... You should upgrade soon: 

    cp .../B2G/.repo/repo/repo .../B2G/repo 

Get git://github.com/mozilla-b2g/b2g-manifest

とか言われてあとはPythonのエラーが続いたりする。書いてあるようにやるんだろうけど、なんか違うみたいなんで面倒になって投げてしまった。

それで、なんか別のOSないかなーとxda-forumsを探していたら、「Nexus 7とNexus 4ならいまはMultiROMだぜ」みたいな雰囲気になってて、つまりICSが入ってたNexusはこれでいろんなROMを切り替えられるし最新版も取ってこられます、ということだった。

例えばこのへん：
　[MOD][FEB 02] MultiROM v22a

rootがとれている状態で、カーネルにパッチがあたっている状態にしたものから、Google PlayでMultiROM Managerをインストールして実行すればいいんだそうだ。Nexusなんで、rootをとるのにハラハラする必要もなく、普通にCWM RecoveryからSuperSUや、パッチ当てたカーネルなんかをインストールしてやればおしまい。

デフォルトではもとの環境のほかにUbuntu Touchが選べるみたいで、他を試したかったらそれぞれROM用意してメニューから操作しろ的な話なので、Ubuntu Touchを入れてみることにした。saucy (13.10)じゃなくてtrusty-custom (14.x)にいきなりチャレンジみたいな無謀なことしたり。

当然開発版を入れることになるので、Wi-Fi経由でじんわりとROMを読んで再起動したあともまた、なんだかイメージのアップデートを延々としたあと再起動がかかった。TWIPのカスタムリカバリみたいな作りなので、タッチ操作でOSを選ぶことになる...んだが、起動まで、Googleロゴ画面のあと真っ暗な状態が1分ほど続いて怖かったよ。

んで、起動したものの... 遅いわこれ。Androidの4倍ぐらい遅い感じ。設定に入るともう、キーボード入力はいつ入るんだろうというような世界。いや、すみませんでしたと謝るしかないほど悲しい。

とりあえず気分がかわったので、続きはやるかどうか考えないで、ひとまずこちらに報告だけしておきます。

（追記：投稿直後）
GMailはわりと普通に近い感じでログインはできたんだけど、日本語フォントが毛筆体でびびった。そのあと操作どころではない感じなのは設定時と同じ。いやはや。それと、シャットダウンのしかたがわかってないので電源ボタン長押しで落としてしまっているのもどうかと思ったり。
（さらに追記：1時間後）
業を煮やしてJerry Bean 4.4.2に戻してみたものの、遅かった... Androidはもともと重いと記憶していたけれど、iPhone 5sとiPad 3だけを使っていたのでNexus 7 (2012)の速度を忘れていた。これでは、FxOSだとしてもかなりチューニングしなければならないんだろうなとか思ったり。つまり、2012年版をがんばる動機に欠けるんだろうなと。

[RepRap PCB milling] How to compile "pcb2gcode" in Mac OS X Mavericks

My current project is creating the RepRap style PCB milling Machine.

One of my undergraduate student agreed to join this as his final project for the credit of graduation.

He designed the machine part.  Because his good skill on the engineering, it worked fine.  My part is for an electricity and the toolchain as softwares.

For designing the circuit board, I designed my own deliberative  one from Generation 7 v1.4.1, and Printrboard from the reason of availability of some parts in Japan.

This board is currently only a prototype, but when the PCB milling machine will worked, I will design more compact, and stable board that can build with it.

The toolchain is basically following the description of RepRap Wiki page.  But on my Mac, the recommented driver "CNCGcodeController" did not work.  It is a Java application, but I think the reason of the failior would be the serial communication class includes OS native code inside.  If so, the code should be re-written to be portable such as using RXTX serial communication class.

Then I installed "Printrun" on my Mac by following the instruction from source for Mac OS X in the README file.  It worked very fine with my choice of firmware "Teacup".

But due to Teacup firmware only accepts G-Code, and my targeting PCB Layout software "KiCad" does not support exporting G-Code directly for now, I needed to convert exported "Gerber" data into G-Code file.

There are several toolpaths is introduced in the Wiki page, but everything in the page but "pcb2gcode" didn't work or fit for my intention of using KiCad (Jan 10 2014 version) as a PCB design tool on my Mac.

I got the source code of pcb2gcode both from sourceforge and GitHub, but the development of this software looks not a hot recently.  The newest download on the sourceforge is dated 2012-07-02, and the head on the GitHub looks the same.

I had a trial of building with this code, but the code conflicts between recent Xcode 5.x toolchain and the boost.  In order to solve this, by looking at the discussions on StackOverflow, I made the replacing using shared_ptr feature from boost to std class, and port a template definition of dynamic_pointer_cast from boost (it is included in "shared_ptr.hpp").

The put my patch on my GitHub repository: https://github.com/tkamada/pcb2gcode

If there were a fail or something that I misunderstand, please post your issue message to my repository.