2016年12月14日水曜日

Mac OS Sierradでのボリューム修復

もう5年を超えるMac miniを業務のメインマシンとして使っているのですが、一昨年ドライブをいろいろと交換して、なんとか継続使用中です。

もう新しいマシンを購入できる予算がないので工夫するわけですが、昨夜自宅からつながらないなあと思ったら、起動前の白い画面で固まっておりました。っていうかいつ再起動したんだ。

いちばんつらかったのがTimeMachine用ドライブが認識しなかったことですが、これはDisk UtilityのFirst Aidでなんとかなりました。

一方、別の外付けドライブがFist Aidでどうにもならず、検索したんですが、起動ディスクが認識しないときの古い話で、「single user modeでfsck -fyを繰り返す」というのですが、Sierraにはどちらのオプションもありません。

試行錯誤したところ、
# fsck_hfs -l ファイルシステム名
で、なんとかなりました、とりあえず。「-l」は、マウント中でも強制チェックするためのもののよう。

まだまだ問題が出そうですが、ひとまずこちらへメモ。

2016年9月11日日曜日

FT231XS(SSOP20タイプ)のピン配置図

まさか公式データシートにピン配置図がないとは...

あんまりびっくりしたんで、パワポで作図してみました。
FT231XSのピン配置(SSOP20タイプ)
ご参考まで。データシートを読めば誰でも作れる図だと思いますので、ご自由にお使いください。

This is a pin layout of FTDI FT231XS which is missing in official FTDI's datasheet.

You may use this freely because anyone can draw this by reading the datasheet.

DISCLAIMER:
LICENSE of this picture:  AS-IS.
I don't have any warranty to the correctness of this picture.  Use at your own risk.

2016年9月10日土曜日

Eagleで作るドリルデータがgerbvでよく見えない件→解決

いまだにEagleの無償コースを使っています。KiCadのいま、とか、Altiumのクラウド版CircuitMakerなどに全くついていけていません。クラウド版CircuitMakerについては、日本語ではガレスタさんの詳しい解説がありますね。

というわけで今回のプロジェクトもEagleなのでして、しかもいまさら感のある内容ですが検索してもなかなかわからなかったので、こちらに書くことにしました。

Eagleで作ったガーバーファイルをプレビューするにはMacならgerbvが定番だと思うのですが、ここで問題になるのがドリルデータがちゃんと見えない件。基板製造会社さんはドリルデータ作成にexcellon.camを使ってくださいとだいたい書かれていますが、できたガーバーファイルをgerbvでプレビューすると、ドリル穴が見えないぐらいちっちゃくて不安になるパターンでありました。コールセンターに電話して確認する感じで。それもどうかということで、調べてみました。

ドリルの問題については、OSH社のサポートページがよくまとまっています。
Common Errors with Drill Files - OSH Park Docs
んで、「EXCELLON24を使え」というんですが、それがどこにあるかは書いてありません。それで検索しつつさまよっていたところ、「Eableのbinの下にあるeagle.defを見ろ」と書かれた呪いがありまして、早速たしかめてみると、いわゆるWindowsの設定ファイルの形式でありました。つまり、角括弧の見出しのあとに、「キーワード=値」がずらっと並ぶもので、たくさん見出しがあるんですが、そのなかに、「EXCELLON」と「EXCELLON_24」があったわけです。

このふたつのどこが違うかというと、ResXとResYが10倍違っていて、EXCELLONは100000、EXCELLON_24は10000でありました。加工機の精度に合わせてあるんだと思うのですが、他のデータを作るGERBER_RS274Xは10000なのでして、gerbvがそっちに合っているのかなと思った次第です。低い方の数値でも工場が保証する加工精度には十分見合っているようなので、camファイルをコピーして、EXCELLON_24に書き換えておきました。具体的には、4行目を
Device="EXCELLON_24"
のように、「_24」を追記しただけ、ということであります。

ご参考になれば。

2016年8月28日日曜日

ATmega32U2のMinimus32開発環境―Windows編

さきほどのMinimus32について、プロジェクトのサイトが見つかりましたので最初にご報告。
projects/minimus32 - rlab.org.uk
連合王国でしたのですね。さすが小さなものがお好みなお国柄。あと、同じく連合王国のリーズにあるハックスペースさんでも情報提供が。
Minimus - wiki.leadshackspace.org.uk
MAXIMの1Wireプロトコルの実装by pbrookさんが紹介されています。I2Cがなくても俺たちには1Wireがあるという心意気でしょうか。

それで、WindowsのArduino IDE 1.6.11ではどうだろうと試してみたところ、ZIPを展開した状態ではどうもうまくいかなくて、インストーラで入れた1.6.11に、Surreallitylabsさんの1.6対応の一式を、Macと同様にぶっこんだあと少し調整したら、一応なんとかなっているようです。

  1. c:\Program Files(x86)\Arduino\hardware の下に、minimumというフォルダを作成して、上のをZIPでとってきて展開した「avr」フォルダをそのなかに放り込みます。
  2. 念のため、boards.txtの冒頭に、arduino側と同じ一行「menu.cpu=Processor」を書いておきます。
  3. コンパイルしてみるとplatform.txtの記述が古いよといいつつ終えるのですが、気持ち悪いのでarduino側にあるものをコピーして入替えます。
これで、Arduino IDEを起動すると、ちゃんとMinimus32がCPUとして選べて、コンパイルまで成功します。あ、もし3.3V版にしているのでしたら、先ほどのエントリの内容にしておいてください。

転送、って言ってませんが、avrdudeが一時的に作成されているはずのhexファイルが「見つからない」という理由以上終了し、呼び出したArduino IDE側がJavaランタイムのスタックトレースを吐いてしまいます。

様子がよくわからないので、コマンドプロンプトを開いて、そこからarduino_debug.exeを起動して同じことをやると、不思議なことに、hexファイルを見落とすことなく書き込みまできれいに完了してしまいました。よくわかりませんが。

ということで、まあこれで当面の目的は達成できるのでよしとして、困ったのが、COMポートの番号増加であります。書き込み終了と同時に、USBの抜き差しの音が出たんで嫌な予感がしたんですよね。

なんとなく、シリアルポートが開いた状態で、avrdudeが書き込みを行うときにCPUのリセットをかけてしまうと、Windowsの都合で、開いた状態のポートが消える前に新しいポートを作ろうとして、番号が上がってしまうというではないかと疑っているところです。

ATmega32U2にArduinoのbootloaderを書き込んでArduino IDEが使えるようにした(追記:2016年9月10日)

とある事情から、ATmega32U2をArduino化する必要があり、いろいろと困っておりましたが、解決したので記録を兼ねてご報告。

まずATmega32U2がArduinoになるのか、ということですが、「ATmega32U2にはADCもI2Cもない」。アナログ入力がないわけです。それらが揃っているのはU4のほう。U4はArduino Leonardoに始まり、各種のボードが販売されているものの、U2は機能不足だから商品化するメリットないよね、と納得しました。(追記 2016-09-10:データシート見ると,A0に対するコンパレータはあるようです。端子にAIN0に対してAIN1〜6がMUX経由でコンパレータにつながっている図がありました。ピン配置をみると,Port D(PD1,4-7)がアナログ入力ですね。PC2にAIN2が飛んでいますけど)

とはいえU2ちっちゃいしピン数もU4より少なくて値上がりしたとはいえまだ秋月で400円だし、もう撤退できない状況があるので、検索をGoogleに変更してみたところ、わりとあっさりとkosakailabさんのブログエントリがヒットしまして、
ATmega32U2でArduinoモドキを作る - kosakailab
Minimus32というプロジェクトがあり、一部販売も(?)されたことがあるらしいことを知りました。

kosakailabさんがGitHubリポジトリとbootloader作成の手がかりを示してくださっているほか、こちらMinimus32解析サイトで部品や回路図などが書き起こされていることで、一通りのなかみはわかりました。
pbrook/minimus-arduino - GitHub
実際のところ、5V電源で16MHzのクロックを使うなら、すでにhexが置いてあるのでコンパイルする必要はないんですが、3.3V動作にする都合でクロックを8MHzに変更する必要があり、Makefileを書き換えてコンパイルする必要があった次第。
データシートの26.3項に、「安全動作圏」を示したグラフがあり、8bitのAVRマイコンでは3.3Vでは10MHz以下のクロックにしなければなりません。Arduinoでは3.3V製品としてSparkFun製Arduino Pro Miniの3.3V版があり、それに合わせて8MHz設定が公式ライブラリに追加されているので、3.3V動作の場合、8MHzのクリスタル一択です。
bootloaderコンパイルにはLUFAが必要だよ、と書かれています。Unoが搭載しているUSB-UART変換にいまはATmega8U2が使われていますが、かつてはATmega16U2が使われていたこともあり、それらには、LUFAが活用されているようです。
オフィシャルサイトは「(2013)」と但し書きがついていますが、GitHubリポジトリは今年も更新されているようです。ともかくも、LUFAは、USBつきAVR開発支援軽量ライブラリとのこと。

さてそんじゃあbootloader作るべし、となるのですが、minimusプロジェクトが3年前で止まっているので、ちと工夫が必要でした。

まず、pbrookさんのレポジトリですが、Forkとjoinのグラフをみると、2年前にSurrealityLabsさんが手を加えたのがいまの最新っぽく見えました。
SurrealityLabs/minimus-arduino - GitHub
これを開くといきなり「avr」しか見えなくて不安になりますが大丈夫、全部入ってます。

よって、ここからgit clone。あとLUFAですが、最新のリポジトリからもってきたものはいろいろ構成がかわっているようで、コンパイルが通らず、Makefileに書かれていた111009(2011年10月9日版)を公式サイトからダウンロードしてくるのが簡単でした。

配置ですが、avr-gccなどツールチェインをArduino IDEから借りるのが手っ取り早いので、すでにインストールしてあるArduino IDE 1.6.11に組み込んでしまうのが話が早いです。あと、Windowsではmakeをどうするの、とかよくわからなかったのでコンパイルはMacでやりました。実はBash on Ubuntu on Windows 10でがんばってみたんだけど断念。いま思えばLinux用Arduino IDEから拾えばよかったのかも。

コンパイルに必要な変更は、Makefileの「F_CPU = 16000000」を8000000に変更するだけ。あと、bootloaderはCaterinaを使っていて、USBのVID/PIDは、Arduino LLCのVIDとLeonardoのPIDが書かれたままになっていますが、目をつぶってそのままに。おかげでlsusbすると「Arduino SA Leonardo ( CDC ACM, HID)」と出ますが、まあそういうことであります。

pbrookさんのWikiには、Arduino IDEのhardware/avr以下を置き換えろみたいな乱暴なことが書かれていますが、そうするとMacの場合、Arduino IDEが上がらなくなってしまいました。

で、Windowsのほうではどうだろうと、SurrealityLabsさんのplatform.txtには1.6.0と書かれているので1.6.0でがっつり置き換えると、まあ起動はしましたが、bootloaderを書こうとすると、「書き込み装置の選択をしろ」的なメッセージが出て先に進みません。AVRISP mkIIを使っているので、それを選択してあるんですが、どうもだめ。

そこで再び検索すると、こんなブログエントリがありまして
Arduino IDE on Windows with Minimus32 Profile
なんだか、「一式固めといたよ」としてZIPファイルがリンクされていました。ですが、これを展開するとバッチファイルがありまして、Arduino IDE 1.0.5をダウンロードしてそこに置き換えのツールチェインとpbrookさんのリポジトリのZIPを配置する、というような仕立てになっておりました。

それができた状態で、Macで作ったhexファイルをもとのものと置き換えるものの、こちらではbootloaderを書き込もうとするとJavaのランタイムエラーが出てだめでした。Windows 10(1608版)なんですが。

もうこれはavrdudeのコマンドラインでいくしかないかな、と思いつつ、「もしやMacでこれと同じ構成にしたらうまくいくんではないか?」と思ったところ、うまくいきました。

Arduino IDEの設計は全くわかっていないんですが、hardware以下にarduinoというフォルダがあるところを、上のバッチファイルで作成した1.0.5版では、minimusというフォルダを隣に作り、pbrookさんの一式はこちらにまるっと入れるという仕上がりになっていて、既存のファイル、特にboards.txtなんかは一切書き換えていないのですが、起動したArduino IDEではきちんとminimus以下のboards.txtの内容が反映されていたわけです。

ということで、Macの1.6.11でも同様に、hardware/minimusというフォルダを作り、一式をそこに放り込み、LUFA-111009も放り込んでMakefileavr-gcc等を呼び出すパスの追記やLUFAのパスを現状に合わせます。それから、macOSの認証を通すために一度無改造のままArduino.appを起動してからなかみの変更をする必要がありますが、最初の起動時に、ボード設定その他をJSON形式で ~/Library/Arduino15 以下に置くので、それをリセットするために、このフォルダごと消しておきます。

そして、とても大事なことなんですが、3.3Vにしたので、boards.txtに記述するAVRのフューズビットの設定を変更し、ブラウンアウト(電圧低下)検出 の電圧を3Vから2.7Vにしておかないと不安です。フューズビットは書き込み時にavrdudeのコマンドラインをArduino IDEが生成するときboards.txtを参照するので、その16進の値を理解して、適切に設定した内容を書いておかなければなりません。

ここで、AVR Fuse Calculatorの出番です。ところが検索してもATmega32Uシリーズが入っているものがなかなかありませんが、なんとか見つけました。
Engbedded Atmel AVR® Fuse Calculator - Electronics-Base.com
で、「AVR Part Name」はATmega32U2ですからすぐ終わるわけですが、あとが困ります。わかんねえ。データシート全部読むのめんどい。

Atmelのデータシートの作りも不親切で、Fuse Bitについてまとめた項目がないんですよ。機能の説明があって、そこにFuse Bitはこう設定する、という部分的な表がばらばらにあるので、一覧できない。全部嫁ということになる。

まあいいや、ということで、既存のboards.txtでATmega32U4が採用されているものと、Minimus32の設定を見比べつつ、上の計算機の値をポチポチしてみると、Minimus32とU4採用Arduinoのfuse bitの設定は同じだということに気づくわけです。Yún, Leonardo, Micro, Esplora, Lilypad USB、どれとも共通です。すると問題になるのはBODの電圧設定のみで、それはextendedの項目であり、5V版である既存設定では3.0V。U2の場合選べるのは最低2.7Vしかないので、そこだけを変更。すると、0xf8が0xf6になるだけだ、という結論が導かれました。

ということで、既存のminimus32の設定を複写して、minimus32v33とかクラス名を変更したところで、name=Minimus 32 (3.3V)とか書いて、bootloader.extended_fuses=0xf6と書き換えます。あと、build.f_cpu=8000000L も忘れずに変更しておきます。build.usb_productにも「3V3」を追記して、これでおしまい。

参考までに、作ってみた部分を掲載しておきます。
#############################################################

minimus32v33.name=Minimus 32 (3.3V)
minimus32v33.vid.0=0x2341
minimus32v33.pid.0=0x0036
minimus32v33.vid.1=0x2341
minimus32v33.pid.1=0x8036
minimus32v33.upload.tool=avrdude
minimus32v33.upload.protocol=avr109
minimus32v33.upload.maximum_size=28672
minimus32v33.upload.speed=57600
minimus32v33.upload.disable_flushing=true
minimus32v33.upload.use_1200bps_touch=true
minimus32v33.upload.wait_for_upload_port=true

minimus32v33.bootloader.tool=avrdude
minimus32v33.bootloader.low_fuses=0xff
minimus32v33.bootloader.high_fuses=0xd8
minimus32v33.bootloader.extended_fuses=0xf6
minimus32v33.bootloader.file=caterina/Caterina-Minimus.hex
minimus32v33.bootloader.unlock_bits=0x3F
minimus32v33.bootloader.lock_bits=0x2F

minimus32v33.build.mcu=atmega32u2
minimus32v33.build.f_cpu=8000000L
minimus32v33.build.vid=0x2341
minimus32v33.build.pid=0x8036
minimus32v33.build.usb_product="Minimus32 3V3"
minimus32v33.build.usb_manufacturer="Arduino"
minimus32v33.build.board=MINIMUS32
minimus32v33.build.core=minimus
minimus32v33.build.variant=minimus32
minimus32v33.build.extra_flags={build.usb_flags}
追記するのは、minimusフォルダ以下のboards.txtだけでよいです。arduino以下には一切触りません。

それでArduino IDE 1.6.11を起動して、ボードの選択をすると、ちゃんとArduinoとMinimusでカテゴリが分けられて選択できるようになりました。よくできてる。
ボード選択メニューの下に追加された
この状態で、「ええい、ままよ」と彼岸島な心で「ブートローダーの書き込み」を選択すると、さっくりと書き込まれまして、USBデバイスを再認識したアラーム音がmacOSから鳴りました。ちゃんとシリアルポートも選べます。でかした! ヤンヤヤンヤ

ためしにスケッチを書いて、コンパイルと転送が通るかも試します。といっても、いまは何もないので、SerialオブジェクトがUSBに割り当てられているのを使って、IDEのシリアルモニタから入力があったら"Hello"を印刷する簡単なスケッチを作り、コンパイルと転送してみました。なにやら「Minimusには対応していません」な警告が3つぐらい出ましたが、そのままコンパイルを終えて書き込みまでさくっと完了しました。感動。

USBの標準速度が57600bpsになっているので、Serial.begin(57600); などと書き、シリアルモニタの設定も57600bpsにして適当な文字を入れ、「送信」ボタンを押すと、"Hello"が出ました。動いているようです。これで、追加の回路も載せて制御できる見通しが立ちました。よかったよかった。

なんですが、ひとつ回路について重大なことを書くのが遅くなりました。このブログエントリは流れ的にソフトウェアの話でいったん完結させるしかなかったので、最後ですが、自作されようとする方のために、また自分の作業記録として、書かなければなりませんので、ここに記します。

Minimus32の解析サイトに回路図がありますが、これをみると、普通のArduinoには見慣れない「HWB」というタクトスイッチがあります。pbrookさんのWikiにも図があって、リセットと隣合わせに並んでいるようです。そして、データシートを見ると、2ページのピン配置図では13番ピンに、「#HWB」なる端子があります(#は負論理)。さらに、他のU4を使ったArduinoでもフューズビット設定で、「Hardware Boot Enable」にチェックを入れています。「ハードウェアブート」はArduinoにおいて重要らしい。

Minimus32の商品(?)では、まじめにそのボタンをつけているんですが、U4を使った他のArduinoにそんなボタンはありません。なんでだろうと思ってデータシートを読むと、「HWBがLのときにRESETがUPするとハードウェアリセットがかかる」とありました。めんどくせえ。それで、手持ちのArduino Nanoの回路図をみたところ、HWBのラインは10kΩの抵抗を通してプルダウンされており(GNDに接続)、わざわざ「USB RESET EN」と書かれていました。HWBをプルダウンしておけば、リセットラインのL→Hの瞬間にリセットがかかるわけで、「これでいいのだ」ということのようです。よって、このピンはプルダウンしておきました。

それから、Minimus32はあえてICSP端子を設けていません。が、最初にbootloaderを書くにはICSPの6端子を用意しておいたほうが便利なわけでして、僕はつけておくことにしました。U2だと15ピンがSCK、16ピンがMOSI、17ピンがMISOと、SPI端子が連続しているので作りやすいと思います。

あと、要注意な点として、Minimusのピン配列は普通のArduinoとはだいぶ違います。pbrookさんのWikiの図必携。

具体的には、HardwareSerialSerial1)はD2がRx、D3がTxですし、D6, D7はUSBの送受信表示のLEDに使われています。D8はHWBで今回はプルダウンされたまま。さらにU2の制約として、タイマーは0(16bitカウンタ)と1(8bitカウンタ)の2つしかないのでPWMは4つですが、D1, D17がタイマー0、D19とD21がタイマー1という配置。

タイマーという点では、標準ライブラリのServo()はタイマー1を使うのでたぶん動くと思いますが、タイマー0はmills()delay()など時間関係の関数のために保留されていて、analogWrite()は使えるよう考慮されているものの、Tone()のために使うことはできず鳴りません。ためしにD1を指定してみたものの、コンパイルは通っても実際には鳴りませんでした。

ただ、タイマー1で音を出すライブラリはいくつかあるようなので、Servo()に興味がなく、音を出したいという用途にはそれらを使うのだろうと思います。
最初のは正確な音程とコードのシンプルさ追求、2番目はタイマー出力2ピン両方をスピーカーにつなぐ形での音質追求、最後のはタイマー0のプリスケーラを1にして(分周しない)、超音波まで出せて音量調節まで実現するかわりに時間関数は破綻してよしとするなど、標準ライブラリに物足りない人向けのようです。

長くなりましたが、こちらからは以上です。

ATmega32U2にArduinoのbootloaderを書き込んでArduino IDEが使えるようにした

とある事情から、ATmega32U2をArduino化する必要があり、いろいろと困っておりましたが、解決したので記録を兼ねてご報告。

まずATmega32U2がArduinoになるのか、ということですが、「ATmega32U2にはADCもI2Cもない」。アナログ入力がないわけです。それらが揃っているのはU4のほう。U4はArduino Leonardoに始まり、各種のボードが販売されているものの、U2は機能不足だから商品化するメリットないよね、と納得しました。

とはいえU2ちっちゃいしピン数もU4より少なくて値上がりしたとはいえまだ秋月で400円だし、もう撤退できない状況があるので、検索をGoogleに変更してみたところ、わりとあっさりとkosakailabさんのブログエントリがヒットしまして、
ATmega32U2でArduinoモドキを作る - kosakailab
Minimus32というプロジェクトがあり、一部販売も(?)されたことがあるらしいことを知りました。

kosakailabさんがGitHubリポジトリとbootloader作成の手がかりを示してくださっているほか、こちらMinimus32解析サイトで部品や回路図などが書き起こされていることで、一通りのなかみはわかりました。
pbrook/minimus-arduino - GitHub
実際のところ、5V電源で16MHzのクロックを使うなら、すでにhexが置いてあるのでコンパイルする必要はないんですが、3.3V動作にする都合でクロックを8MHzに変更する必要があり、Makefileを書き換えてコンパイルする必要があった次第。
データシートの26.3項に、「安全動作圏」を示したグラフがあり、8bitのAVRマイコンでは3.3Vでは10MHz以下のクロックにしなければなりません。Arduinoでは3.3V製品としてSparkFun製Arduino Pro Miniの3.3V版があり、それに合わせて8MHz設定が公式ライブラリに追加されているので、3.3V動作の場合、8MHzのクリスタル一択です。
bootloaderコンパイルにはLUFAが必要だよ、と書かれています。Unoが搭載しているUSB-UART変換にいまはATmega8U2が使われていますが、かつてはATmega16U2が使われていたこともあり、それらには、LUFAが活用されているようです。
オフィシャルサイトは「(2013)」と但し書きがついていますが、GitHubリポジトリは今年も更新されているようです。ともかくも、LUFAは、USBつきAVR開発支援軽量ライブラリとのこと。

さてそんじゃあbootloader作るべし、となるのですが、minimusプロジェクトが3年前で止まっているので、ちと工夫が必要でした。

まず、pbrookさんのレポジトリですが、Forkとjoinのグラフをみると、2年前にSurrealityLabsさんが手を加えたのがいまの最新っぽく見えました。
SurrealityLabs/minimus-arduino - GitHub
これを開くといきなり「avr」しか見えなくて不安になりますが大丈夫、全部入ってます。

よって、ここからgit clone。あとLUFAですが、最新のリポジトリからもってきたものはいろいろ構成がかわっているようで、コンパイルが通らず、Makefileに書かれていた111009(2011年10月9日版)を公式サイトからダウンロードしてくるのが簡単でした。

配置ですが、avr-gccなどツールチェインをArduino IDEから借りるのが手っ取り早いので、すでにインストールしてあるArduino IDE 1.6.11に組み込んでしまうのが話が早いです。あと、Windowsではmakeをどうするの、とかよくわからなかったのでコンパイルはMacでやりました。実はBash on Ubuntu on Windows 10でがんばってみたんだけど断念。いま思えばLinux用Arduino IDEから拾えばよかったのかも。

コンパイルに必要な変更は、Makefileの「F_CPU = 16000000」を8000000に変更するだけ。あと、bootloaderはCaterinaを使っていて、USBのVID/PIDは、Arduino LLCのVIDとLeonardoのPIDが書かれたままになっていますが、目をつぶってそのままに。おかげでlsusbすると「Arduino SA Leonardo ( CDC ACM, HID)」と出ますが、まあそういうことであります。

pbrookさんのWikiには、Arduino IDEのhardware/avr以下を置き換えろみたいな乱暴なことが書かれていますが、そうするとMacの場合、Arduino IDEが上がらなくなってしまいました。

で、Windowsのほうではどうだろうと、SurrealityLabsさんのplatform.txtには1.6.0と書かれているので1.6.0でがっつり置き換えると、まあ起動はしましたが、bootloaderを書こうとすると、「書き込み装置の選択をしろ」的なメッセージが出て先に進みません。AVRISP mkIIを使っているので、それを選択してあるんですが、どうもだめ。

そこで再び検索すると、こんなブログエントリがありまして
Arduino IDE on Windows with Minimus32 Profile
なんだか、「一式固めといたよ」としてZIPファイルがリンクされていました。ですが、これを展開するとバッチファイルがありまして、Arduino IDE 1.0.5をダウンロードしてそこに置き換えのツールチェインとpbrookさんのリポジトリのZIPを配置する、というような仕立てになっておりました。

それができた状態で、Macで作ったhexファイルをもとのものと置き換えるものの、こちらではbootloaderを書き込もうとするとJavaのランタイムエラーが出てだめでした。Windows 10(1608版)なんですが。

もうこれはavrdudeのコマンドラインでいくしかないかな、と思いつつ、「もしやMacでこれと同じ構成にしたらうまくいくんではないか?」と思ったところ、うまくいきました。

Arduino IDEの設計は全くわかっていないんですが、hardware以下にarduinoというフォルダがあるところを、上のバッチファイルで作成した1.0.5版では、minimusというフォルダを隣に作り、pbrookさんの一式はこちらにまるっと入れるという仕上がりになっていて、既存のファイル、特にboards.txtなんかは一切書き換えていないのですが、起動したArduino IDEではきちんとminimus以下のboards.txtの内容が反映されていたわけです。

ということで、Macの1.6.11でも同様に、hardware/minimusというフォルダを作り、一式をそこに放り込み、LUFA-111009も放り込んでMakefileavr-gcc等を呼び出すパスの追記やLUFAのパスを現状に合わせます。それから、macOSの認証を通すために一度無改造のままArduino.appを起動してからなかみの変更をする必要がありますが、最初の起動時に、ボード設定その他をJSON形式で ~/Library/Arduino15 以下に置くので、それをリセットするために、このフォルダごと消しておきます。

そして、とても大事なことなんですが、3.3Vにしたので、boards.txtに記述するAVRのフューズビットの設定を変更し、ブラウンアウト(電圧低下)検出 の電圧を3Vから2.7Vにしておかないと不安です。フューズビットは書き込み時にavrdudeのコマンドラインをArduino IDEが生成するときboards.txtを参照するので、その16進の値を理解して、適切に設定した内容を書いておかなければなりません。

ここで、AVR Fuse Calculatorの出番です。ところが検索してもATmega32Uシリーズが入っているものがなかなかありませんが、なんとか見つけました。
Engbedded Atmel AVR® Fuse Calculator - Electronics-Base.com
で、「AVR Part Name」はATmega32U2ですからすぐ終わるわけですが、あとが困ります。わかんねえ。データシート全部読むのめんどい。

Atmelのデータシートの作りも不親切で、Fuse Bitについてまとめた項目がないんですよ。機能の説明があって、そこにFuse Bitはこう設定する、という部分的な表がばらばらにあるので、一覧できない。全部嫁ということになる。

まあいいや、ということで、既存のboards.txtでATmega32U4が採用されているものと、Minimus32の設定を見比べつつ、上の計算機の値をポチポチしてみると、Minimus32とU4採用Arduinoのfuse bitの設定は同じだということに気づくわけです。Yún, Leonardo, Micro, Esplora, Lilypad USB、どれとも共通です。すると問題になるのはBODの電圧設定のみで、それはextendedの項目であり、5V版である既存設定では3.0V。U2の場合選べるのは最低2.7Vしかないので、そこだけを変更。すると、0xf8が0xf6になるだけだ、という結論が導かれました。

ということで、既存のminimus32の設定を複写して、minimus32v33とかクラス名を変更したところで、name=Minimus 32 (3.3V)とか書いて、bootloader.extended_fuses=0xf6と書き換えます。あと、build.f_cpu=8000000L も忘れずに変更しておきます。build.usb_productにも「3V3」を追記して、これでおしまい。

参考までに、作ってみた部分を掲載しておきます。
#############################################################

minimus32v33.name=Minimus 32 (3.3V)
minimus32v33.vid.0=0x2341
minimus32v33.pid.0=0x0036
minimus32v33.vid.1=0x2341
minimus32v33.pid.1=0x8036
minimus32v33.upload.tool=avrdude
minimus32v33.upload.protocol=avr109
minimus32v33.upload.maximum_size=28672
minimus32v33.upload.speed=57600
minimus32v33.upload.disable_flushing=true
minimus32v33.upload.use_1200bps_touch=true
minimus32v33.upload.wait_for_upload_port=true

minimus32v33.bootloader.tool=avrdude
minimus32v33.bootloader.low_fuses=0xff
minimus32v33.bootloader.high_fuses=0xd8
minimus32v33.bootloader.extended_fuses=0xf6
minimus32v33.bootloader.file=caterina/Caterina-Minimus.hex
minimus32v33.bootloader.unlock_bits=0x3F
minimus32v33.bootloader.lock_bits=0x2F

minimus32v33.build.mcu=atmega32u2
minimus32v33.build.f_cpu=8000000L
minimus32v33.build.vid=0x2341
minimus32v33.build.pid=0x8036
minimus32v33.build.usb_product="Minimus32 3V3"
minimus32v33.build.usb_manufacturer="Arduino"
minimus32v33.build.board=MINIMUS32
minimus32v33.build.core=minimus
minimus32v33.build.variant=minimus32
minimus32v33.build.extra_flags={build.usb_flags}
追記するのは、minimusフォルダ以下のboards.txtだけでよいです。arduino以下には一切触りません。

それでArduino IDE 1.6.11を起動して、ボードの選択をすると、ちゃんとArduinoとMinimusでカテゴリが分けられて選択できるようになりました。よくできてる。
ボード選択メニューの下に追加された
この状態で、「ええい、ままよ」と彼岸島な心で「ブートローダーの書き込み」を選択すると、さっくりと書き込まれまして、USBデバイスを再認識したアラーム音がmacOSから鳴りました。ちゃんとシリアルポートも選べます。でかした! ヤンヤヤンヤ

ためしにスケッチを書いて、コンパイルと転送が通るかも試します。といっても、いまは何もないので、SerialオブジェクトがUSBに割り当てられているのを使って、IDEのシリアルモニタから入力があったら"Hello"を印刷する簡単なスケッチを作り、コンパイルと転送してみました。なにやら「Minimusには対応していません」な警告が3つぐらい出ましたが、そのままコンパイルを終えて書き込みまでさくっと完了しました。感動。

USBの標準速度が57600bpsになっているので、Serial.begin(57600); などと書き、シリアルモニタの設定も57600bpsにして適当な文字を入れ、「送信」ボタンを押すと、"Hello"が出ました。動いているようです。これで、追加の回路も載せて制御できる見通しが立ちました。よかったよかった。

なんですが、ひとつ回路について重大なことを書くのが遅くなりました。このブログエントリは流れ的にソフトウェアの話でいったん完結させるしかなかったので、最後ですが、自作されようとする方のために、また自分の作業記録として、書かなければなりませんので、ここに記します。

Minimus32の解析サイトに回路図がありますが、これをみると、普通のArduinoには見慣れない「HWB」というタクトスイッチがあります。pbrookさんのWikiにも図があって、リセットと隣合わせに並んでいるようです。そして、データシートを見ると、2ページのピン配置図では13番ピンに、「#HWB」なる端子があります(#は負論理)。さらに、他のU4を使ったArduinoでもフューズビット設定で、「Hardware Boot Enable」にチェックを入れています。「ハードウェアブート」はArduinoにおいて重要らしい。

Minimus32の商品(?)では、まじめにそのボタンをつけているんですが、U4を使った他のArduinoにそんなボタンはありません。なんでだろうと思ってデータシートを読むと、「HWBがLのときにRESETがUPするとハードウェアリセットがかかる」とありました。めんどくせえ。それで、手持ちのArduino Nanoの回路図をみたところ、HWBのラインは10kΩの抵抗を通してプルダウンされており(GNDに接続)、わざわざ「USB RESET EN」と書かれていました。HWBをプルダウンしておけば、リセットラインのL→Hの瞬間にリセットがかかるわけで、「これでいいのだ」ということのようです。よって、このピンはプルダウンしておきました。

それから、Minimus32はあえてICSP端子を設けていません。が、最初にbootloaderを書くにはICSPの6端子を用意しておいたほうが便利なわけでして、僕はつけておくことにしました。U2だと15ピンがSCK、16ピンがMOSI、17ピンがMISOと、SPI端子が連続しているので作りやすいと思います。

あと、要注意な点として、Minimusのピン配列は普通のArduinoとはだいぶ違います。pbrookさんのWikiの図必携。

具体的には、HardwareSerialSerial1)はD2がRx、D3がTxですし、D6, D7はUSBの送受信表示のLEDに使われています。D8はHWBで今回はプルダウンされたまま。さらにU2の制約として、タイマーは0(16bitカウンタ)と1(8bitカウンタ)の2つしかないのでPWMは4つですが、D1, D17がタイマー0、D19とD21がタイマー1という配置。

タイマーという点では、標準ライブラリのServo()はタイマー1を使うのでたぶん動くと思いますが、タイマー0はmills()delay()など時間関係の関数のために保留されていて、analogWrite()は使えるよう考慮されているものの、Tone()のために使うことはできず鳴りません。ためしにD1を指定してみたものの、コンパイルは通っても実際には鳴りませんでした。

ただ、タイマー1で音を出すライブラリはいくつかあるようなので、Servo()に興味がなく、音を出したいという用途にはそれらを使うのだろうと思います。
最初のは正確な音程とコードのシンプルさ追求、2番目はタイマー出力2ピン両方をスピーカーにつなぐ形での音質追求、最後のはタイマー0のプリスケーラを1にして(分周しない)、超音波まで出せて音量調節まで実現するかわりに時間関数は破綻してよしとするなど、標準ライブラリに物足りない人向けのようです。

長くなりましたが、こちらからは以上です。

ATmega32U2にArduinoのbootloaderを書き込んでArduino IDEが使えるようにした

とある事情から、ATmega32U2をArduino化する必要があり、いろいろと困っておりましたが、解決したので記録を兼ねてご報告。

まずATmega32U2がArduinoになるのか、ということですが、「ATmega32U2にはADCもI2Cもない」。アナログ入力がないわけです。それらが揃っているのはU4のほう。U4はArduino Leonardoに始まり、各種のボードが販売されているものの、U2は機能不足だから商品化するメリットないよね、と納得しました。

とはいえU2ちっちゃいしピン数もU4より少なくて値上がりしたとはいえまだ秋月で400円だし、もう撤退できない状況があるので、検索をGoogleに変更してみたところ、わりとあっさりとkosakailabさんのブログエントリがヒットしまして、
ATmega32U2でArduinoモドキを作る - kosakailab
Minimus32という商品(?)がかつてあったらしいことを知りました。

こちらMinimus32解析サイトによりますと、www.minimususb.comというドメインがOfficialだということでリンクが貼ってあるんですが、いま見ても日本語で2015年頃にゲーミングマウスがどうとかいう数個のエントリが掲載されたブログが表示されるのみでして、経緯がよくわかりません。他のリンク先もドメインが無効だったりして、情報不足であります。

ただ、kosakailabさんがGitHubリポジトリとbootloader作成の手がかりを示してくださっているので、一通り道具は揃いました。
pbrook/minimus-arduino - GitHub
実際のところ、5V電源で16MHzのクロックを使うなら、すでにhexが置いてあるのでコンパイルする必要はないんですが、3.3V動作にする都合でクロックを8MHzに変更する必要があり、Makefileを書き換えてコンパイルする必要があった次第。
データシートの26.3項に、「安全動作圏」を示したグラフがあり、8bitのAVRマイコンでは3.3Vでは10MHz以下のクロックにしなければなりません。Arduinoでは3.3V製品としてSparkFun製Arduino Pro Miniの3.3V版があり、それに合わせて8MHz設定が公式ライブラリに追加されているので、3.3V動作の場合、8MHzのクリスタル一択です。
bootloaderコンパイルにはLUFAが必要だよ、と書かれています。Unoが搭載しているUSB-UART変換にいまはATmega8U2が使われていますが、かつてはATmega16U2が使われていたこともあり、それらには、LUFAが活用されているようです。
オフィシャルサイトは「(2013)」と但し書きがついていますが、GitHubリポジトリは今年も更新されているようです。ともかくも、LUFAは、USBつきAVR開発支援軽量ライブラリとのこと。

さてそんじゃあbootloader作るべし、となるのですが、minimusプロジェクトが3年前で止まっているので、ちと工夫が必要でした。

まず、pbrookさんのレポジトリですが、Forkとjoinのグラフをみると、2年前にSurrealityLabsさんが手を加えたのがいまの最新っぽく見えました。
SurrealityLabs/minimus-arduino - GitHub
これを開くといきなり「avr」しか見えなくて不安になりますが大丈夫、全部入ってます。

よって、ここからgit clone。あとLUFAですが、最新のリポジトリからもってきたものはいろいろ構成がかわっているようで、コンパイルが通らず、Makefileに書かれていた111009(2011年10月9日版)を公式サイトからダウンロードしてくるのが簡単でした。

配置ですが、avr-gccなどツールチェインをArduino IDEから借りるのが手っ取り早いので、すでにインストールしてあるArduino IDE 1.6.11に組み込んでしまうのが話が早いです。あと、Windowsではmakeをどうするの、とかよくわからなかったのでコンパイルはMacでやりました。実はBash on Ubuntu on Windows 10でがんばってみたんだけど断念。いま思えばLinux用Arduino IDEから拾えばよかったのかも。

コンパイルに必要な変更は、Makefileの「F_CPU = 16000000」を8000000に変更するだけ。あと、bootloaderはCaterinaを使っていて、USBのVID/PIDは、Arduino LLCのVIDとLeonardoのPIDが書かれたままになっていますが、目をつぶってそのままに。おかげでlsusbすると「Arduino SA Leonardo ( CDC ACM, HID)」と出ますが、まあそういうことであります。

pbrookさんのWikiには、Arduino IDEのhardware/avr以下を置き換えろみたいな乱暴なことが書かれていますが、そうするとMacの場合、Arduino IDEが上がらなくなってしまいました。

で、Windowsのほうではどうだろうと、SurrealityLabsさんのplatform.txtには1.6.0と書かれているので1.6.0でがっつり置き換えると、まあ起動はしましたが、bootloaderを書こうとすると、「書き込み装置の選択をしろ」的なメッセージが出て先に進みません。AVRISP mkIIを使っているので、それを選択してあるんですが、どうもだめ。

そこで再び検索すると、こんなブログエントリがありまして
Arduino IDE on Windows with Minimus32 Profile
なんだか、「一式固めといたよ」としてZIPファイルがリンクされていました。ですが、これを展開するとバッチファイルがありまして、Arduino IDE 1.0.5をダウンロードしてそこに置き換えのツールチェインとpbrookさんのリポジトリのZIPを配置する、というような仕立てになっておりました。

それができた状態で、Macで作ったhexファイルをもとのものと置き換えるものの、こちらではbootloaderを書き込もうとするとJavaのランタイムエラーが出てだめでした。Windows 10(1608版)なんですが。

もうこれはavrdudeのコマンドラインでいくしかないかな、と思いつつ、「もしやMacでこれと同じ構成にしたらうまくいくんではないか?」と思ったところ、うまくいきました。

Arduino IDEの設計は全くわかっていないんですが、hardware以下にarduinoというフォルダがあるところを、上のバッチファイルで作成した1.0.5版では、minimusというフォルダを隣に作り、pbrookさんの一式はこちらにまるっと入れるという仕上がりになっていて、既存のファイル、特にboards.txtなんかは一切書き換えていないのですが、起動したArduino IDEではきちんとminimus以下のboards.txtの内容が反映されていたわけです。

ということで、Macの1.6.11でも同様に、hardware/minimusというフォルダを作り、一式をそこに放り込み、LUFA-111009も放り込んでMakefileavr-gcc等を呼び出すパスの追記やLUFAのパスを現状に合わせます。それから、macOSの認証を通すために一度無改造のままArduino.appを起動してからなかみの変更をする必要がありますが、最初の起動時に、ボード設定その他をJSON形式で ~/Library/Arduino15 以下に置くので、それをリセットするために、このフォルダごと消しておきます。

そして、とても大事なことなんですが、3.3Vにしたので、boards.txtに記述するAVRのフューズビットの設定を変更し、ブラウンアウト(電圧低下)検出 の電圧を3Vから2.7Vにしておかないと不安です。フューズビットは書き込み時にavrdudeのコマンドラインをArduino IDEが生成するときboards.txtを参照するので、その16進の値を理解して、適切に設定した内容を書いておかなければなりません。

ここで、AVR Fuse Calculatorの出番です。ところが検索してもATmega32Uシリーズが入っているものがなかなかありませんが、なんとか見つけました。
Engbedded Atmel AVR® Fuse Calculator - Electronics-Base.com
で、「AVR Part Name」はATmega32U2ですからすぐ終わるわけですが、あとが困ります。わかんねえ。データシート全部読むのめんどい。

Atmelのデータシートの作りも不親切で、Fuse Bitについてまとめた項目がないんですよ。機能の説明があって、そこにFuse Bitはこう設定する、という部分的な表がばらばらにあるので、一覧できない。全部嫁ということになる。

まあいいや、ということで、既存のboards.txtでATmega32U4が採用されているものと、Minimus32の設定を見比べつつ、上の計算機の値をポチポチしてみると、Minimus32とU4採用Arduinoのfuse bitの設定は同じだということに気づくわけです。Yún, Leonardo, Micro, Esplora, Lilypad USB、どれとも共通です。すると問題になるのはBODの電圧設定のみで、それはextendedの項目であり、5V版である既存設定では3.0V。U2の場合選べるのは最低2.7Vしかないので、そこだけを変更。すると、0xf8が0xf6になるだけだ、という結論が導かれました。

ということで、既存のminimus32の設定を複写して、minimus32v33とかクラス名を変更したところで、name=Minimus 32 (3.3V)とか書いて、bootloader.extended_fuses=0xf6と書き換えます。あと、build.f_cpu=8000000L も忘れずに変更しておきます。build.usb_productにも「3V3」を追記して、これでおしまい。

参考までに、作ってみた部分を掲載しておきます。
#############################################################

minimus32v33.name=Minimus 32 (3.3V)
minimus32v33.vid.0=0x2341
minimus32v33.pid.0=0x0036
minimus32v33.vid.1=0x2341
minimus32v33.pid.1=0x8036
minimus32v33.upload.tool=avrdude
minimus32v33.upload.protocol=avr109
minimus32v33.upload.maximum_size=28672
minimus32v33.upload.speed=57600
minimus32v33.upload.disable_flushing=true
minimus32v33.upload.use_1200bps_touch=true
minimus32v33.upload.wait_for_upload_port=true

minimus32v33.bootloader.tool=avrdude
minimus32v33.bootloader.low_fuses=0xff
minimus32v33.bootloader.high_fuses=0xd8
minimus32v33.bootloader.extended_fuses=0xf6
minimus32v33.bootloader.file=caterina/Caterina-Minimus.hex
minimus32v33.bootloader.unlock_bits=0x3F
minimus32v33.bootloader.lock_bits=0x2F

minimus32v33.build.mcu=atmega32u2
minimus32v33.build.f_cpu=8000000L
minimus32v33.build.vid=0x2341
minimus32v33.build.pid=0x8036
minimus32v33.build.usb_product="Minimus32 3V3"
minimus32v33.build.usb_manufacturer="Arduino"
minimus32v33.build.board=MINIMUS32
minimus32v33.build.core=minimus
minimus32v33.build.variant=minimus32
minimus32v33.build.extra_flags={build.usb_flags}
追記するのは、minimusフォルダ以下のboards.txtだけでよいです。arduino以下には一切触りません。

それでArduino IDE 1.6.11を起動して、ボードの選択をすると、ちゃんとArduinoとMinimusでカテゴリが分けられて選択できるようになりました。よくできてる。
ボード選択メニューの下に追加された
この状態で、「ええい、ままよ」と彼岸島な心で「ブートローダーの書き込み」を選択すると、さっくりと書き込まれまして、USBデバイスを再認識したアラーム音がmacOSから鳴りました。ちゃんとシリアルポートも選べます。やったー!

ためしにスケッチを書いて、コンパイルと転送が通るかも試します。といっても、いまは何もないので、SerialオブジェクトがUSBに割り当てられているのを使って、IDEのシリアルモニタから入力があったら"Hello"を印刷する簡単なスケッチを作り、コンパイルと転送してみました。なにやら「Minimusには対応していません」な警告が3つぐらい出ましたが、そのままコンパイルを終えて書き込みまでさくっと完了しました。感動。

USBの標準速度が57600bpsになっているので、Serial.begin(57600); などと書き、シリアルモニタの設定も57600bpsにして適当な文字を入れ、「送信」ボタンを押すと、"Hello"が出ました。動いているようです。これで、追加の回路も載せて制御できる見通しが立ちました。よかったよかった。

なんですが、ひとつ回路について重大なことを書くのが遅くなりました。このブログエントリは流れ的にソフトウェアの話でいったん完結させるしかなかったので、最後ですが、自作されようとする方のために、また自分の作業記録として、書かなければなりませんので、ここに記します。

Minimus32の解析サイトに回路図がありますが、これをみると、普通のArduinoには見慣れない「HWB」というタクトスイッチがあります。pbrookさんのWikiにも図があって、リセットと隣合わせに並んでいるようです。そして、データシートを見ると、2ページのピン配置図では13番ピンに、「#HWB」なる端子があります(#は負論理)。さらに、他のU4を使ったArduinoでもフューズビット設定で、「Hardware Boot Enable」にチェックを入れています。「ハードウェアブート」はArduinoにおいて重要らしい。

Minimus32の商品(?)では、まじめにそのボタンをつけているんですが、U4を使った他のArduinoにそんなボタンはありません。なんでだろうと思ってデータシートを読むと、「HWBがLのときにRESETがUPするとハードウェアリセットがかかる」とありました。めんどくせえ。それで、手持ちのArduino Nanoの回路図をみたところ、HWBのラインは10kΩの抵抗を通してプルダウンされており(GNDに接続)、わざわざ「USB RESET EN」と書かれていました。HWBをプルダウンしておけば、リセットラインのL→Hの瞬間にリセットがかかるわけで、「これでいいのだ」ということのようです。よって、このピンはプルダウンしておきました。

それから、Minimus32はあえてICSP端子を設けていません。が、最初にbootloaderを書くにはICSPの6端子を用意しておいたほうが便利なわけでして、僕はつけておくことにしました。U2だと15ピンがSCK、16ピンがMOSI、17ピンがMISOと、SPI端子が連続しているので作りやすいと思います。

あと、要注意な点として、Minimusのピン配列は普通のArduinoとはだいぶ違います。pbrookさんのWikiの図必携。

具体的には、HardwareSerialSerial1)はD2がRx、D3がTxですし、D6, D7はUSBの送受信表示のLEDに使われています。D8はHWBで今回はプルダウンされたまま。さらにU2の制約として、タイマーは0(16bitカウンタ)と1(8bitカウンタ)の2つしかないのでPWMは4つですが、D1, D17がタイマー0、D19とD21がタイマー1という配置。

タイマーという点では、標準ライブラリのServo()はタイマー1を使うのでたぶん動くと思いますが、タイマー0はmills()delay()など時間関係の関数のために保留されていて、analogWrite()は使えるよう考慮されているものの、Tone()のために使うことはできず鳴りません。ためしにD1を指定してみたものの、コンパイルは通っても実際には鳴りませんでした。

ただ、タイマー1で音を出すライブラリはいくつかあるようなので、Servo()に興味がなく、音を出したいという用途にはそれらを使うのだろうと思います。
最初のは正確な音程とコードのシンプルさ追求、2番目はタイマー出力2ピン両方をスピーカーにつなぐ形での音質追求、最後のはタイマー0のプリスケーラを1にして(分周しない)、超音波まで出せて音量調節まで実現するかわりに時間関数は破綻してよしとするなど、標準ライブラリに物足りない人向けのようです。

長くなりましたが、こちらからは以上です。

2016年8月15日月曜日

FTDI VCPドライバが正常動作しない場合(El Capitan 10.11.6)

Arduino Nanoを最近使っていて、Macでシリアルデバイスが突然消えるので困っていた。

最初は/dev/{cu,tty}.usbserial-xxxxが生えるのだが、ポートを開いたり閉じたりしているといつのまにかデバイスが消えている。kextstatすればFTDIのカーネルモジュールはロードされているし、なにが起きているのかよくわからなかった。

というわけで、Google先生にお伺いを立ててみたところ、我らがParallaxのページに、「バージョン2.2.18と2.3があるが、10.9 (Mavericks)以後は2.3じゃないとだめだよ」ときちんと書いてあった。

いやまさか、最新ドライバに入れ替えたはずだと思ってFTDIのVCPドライバのページを見ると、同じことが書いてあり、El Capitanなら2.3の一択。間違えようがない。

不審に思ってkextstatすると、「com.FTDI.driver.FTDIUSBSerialDriver (2.2.18)」。ああすみません(泣)。

カーネルモジュールなので、kextunloadできるはずだと実行するも、「1 instanceがあるからunloadできないよ」と言われる。さっきまでつないでいたFTDIチップ搭載基板(Modern Device社のUSB BUB初代品)のせいで作られたインスタンスがなにかをつかんでいて消えないんだろう。

やむなく
# rm -rf /System/Library/Extensions/FTDIUSBSerialDriver.kext
を実行して再起動。そして、バージョン2.3を確認してダウンロードし、インストール。基板を接続すると、ちゃんと /dev/{cu,tty}.usbserial-xxxx が生えてきたのでkextstat。無事「com.FTDI.driver.FTDIUSBSerialDriver (2.3)」がおりました。よしよし。

カーネルモジュールちゃんとあるよね、と/System以下を見るも見当たらず、mdfindしたら、/Library/Extensions/FTDIUSBSerialDriver.kextに移動していた。あとからインストールしたものだから、たしかにこちらにあるべきで、いままでは何かの理由で/System以下に置いていたのだろうか、謎。

検索では「Mavericks以後はApple版のFTDIドライバがいるけれど不具合が云々」、というエントリがたくさんヒットしたのだけれど、「ドライバのバージョン間違いしてないか」を確かめることを注意したものが見当たらなかったので、書いておくことにしました。いや、そんな間抜けはいないのかもしれませんが、ここに1名おりまして。

それらの解説では、MavericksではApple版とFTDI版のkext両方がロードされてコンフリクトするようですが、El Capitanでは、FTDI版があればApple版ドライバがロードされることはないようでした。為念。

2016年8月10日水曜日

Raspbian JessieがWindows用USBタッチスクリーンディスプレイに対応していた件

モンゴル方面からテクニカルな相談が相次ぐ昨今、Raspberry Piのタッチディスプレイをプロジェクタに映せないかという、検索するとよくある「それできません」な要件がありました。

いろいろ調べてみたところ、usbtouchdisplayというドライバがLinux kernel 3のどこかで入った模様をつかみ、だめもとで、Windows 10で使っている「Dell S2340T」23インチ10点マルチタッチディスプレイをUSBとHDMI接続して、Raspbianをそのまま起動してみました。

lsusbしてみた結果がこれ。
Raspbian JessieにDell S2340Tを接続してlsusb
"MicroTouch Systems, Inc"というのが見えますね。さらにDisplayLinkも見えました。いや素晴らしい。HDMIなくてもDisplayLinkに対応していればUSBだけでいけるということなんではないでしょうか(そっちも試せという声が... いやすみません)。

試しにタッチしてみました。
どうもキャリブレーションは必要なようですが、とにかく指に反応する様子は確認できました。

検索では皆さんいろいろご苦労されている様子があったので、ゆうべはずいぶん悩んで調べていたのですが、たぶん、たいていのWindows用外部ディスプレイのUSBマルチタッチは対応しているんではないかと思います。

モンゴル方面には、なにか適当なマルチタッチディスプレイとHDMIスプリッタを用意せよと連絡して完了。よかった。

ひとまず速報的にお知らせいたします。

2016年6月11日土曜日

Nekoboard2をArduino化するw

Scaratchセンサーボードとして大人気らしい「Nekoboard2」について調べてほしいという依頼があり、週末にお借りしていろいろいじってみました。

第一印象は、この一言に尽きます。「え〜、こんなにちっちゃいの!?」
とってもちっちゃいNekoboard2
比較のために、なのぼ〜どAG 1.4と、秋月から購入したスライドボリュームを並べてみましたが、わかりにくいので言葉で補足すると、いちばん長い横幅で、5.3cmしかありません。大人の手のひらで握ってしまえるぐらいの大きさ。搭載されているスライドボリュームの長さが4.5cm。秋月のは6cmです。なのぼ〜どAGが5cm角。

念のため追記しておきますが、Nekoboard2にはモータドライバもArduinoとしてのI/O端子もありません。オリジナルのMIT PicoBoardと同じ機能。いまはSparkFun版が公式のようですね。よって、自作スケッチもセンサの値をシリアルで送る以外にこれといって実用的な用途はなさそうです。

SparkFun版もそうですが、ATmega328Pを使いながら、使うI/Oはたったの8個という豪華仕様。未使用ピンがたっぷりありますが32TQFPパッケージで周囲も他の部品が密集して取り囲んでいるのでリードを引っ張りだすのはほぼ無理。クロックも16MHzで、速度的にも余裕たっぷりです。

Nekoboard2は、MITがワニ口クリップのついたケーブルをイヤフォンジャック4個でつなぐ形にこだわるのを捨てて、とにかく小さく、安くする方針というのが特徴になると思います。日本では両ワニ口ケーブルが簡単に入手できるので、イヤフォンジャックつき専用ケーブルはちょっと過剰な仕様ではないかと僕も思います。

というわけで、Scratchセンサボード本来の使い方として、MITのScratch 2.0サイトにアクセスして、ブラウザに機能拡張を入れて動くことを確認したのち、Arduinoスケッチを書き込んだらどうなるのか、試してみました。

目的は、ドリトルのArduino対応用スケッチで、ドリトルのセンサボードとして使う、という方向です。結論からいうと、とても簡単でした。実際、普通に使えてしまいます。

以下、作業手順を記録しておきます。

まず、出荷状態のファームウェアのバックアップをとります。Nekoboad2は特にコードがロックされていないので、avrdudeで簡単にFlashの読み書きができます。ただ、Scratch 2.0対応とするためにFT231XS USB-シリアル変換チップのDTRがATmega328Pのリセットにつながっていないので、optibootをbootloaderにしていると、単にUSBでPCと接続しただけではavrdudeからリセットがかけられません。

よって、タクトスイッチの手前、FTDIチップの右にあるISP端子を使います。つまり、ISP装置必須です。といっても、arduinoISPが使えるので、Arduinoで生のAVRにArduinoのbootloaderを書き込むのと同じ準備でいいと思います。適当に検索していただく感じで。手元にはAVR ISPmkIIがあるので、それを使いました。
ISPの位置
Nekoboard2に給電するために、Nekoboard2をPCのUSB端子に、同じPCにISP装置をUSB接続します。

何度も書き換えを行う場合はISP端子にピンヘッダを立てておくのがよいと思いますが、今回は借り物なので、はんだづけしないで「指の力で押さえる」方式をとりました。
ピンヘッダを取り付けたISPコネクタを基板に押し付ける
コツは、斜めに力を加えることでしょうか。垂直では隙間ができてしまうので、傾けて穴のハンダメッキされた壁に全部の端子がきっちり当たる状態を保つ感じです。差し込む向きが合っていれば、ISP装置のランプが緑色になります。逆向きだとオレンジで点滅するのでわかります。接続がない状態では赤なので、色が変わる場所を探しましょう。

それで、avrdudeを使いますが、Arduino IDEがインストールされていればそのharware/avr/tools/以下にツールチェインが揃っているので、それを使うのが簡単。bin以下にバイナリがあり、etcの下にavrdude.confがあります。よって、
$ cd /Applications/Arduino.app/Contents/Java/hardware/avr/bin
$ ./avrdude -C../etc/avrdude.conf -p m328p -cavrisp2 -v -v -U flash:r:/tmp/flash.bin:r
これで、/tmp/flash.binにバックアップがとれます。Windowsな方は適当にアレンジしてください。

こんなログがとれました。


avrdude: Version 6.0.1, compiled on Apr 14 2015 at 16:30:25
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2009 Joerg Wunsch

System wide configuration file is "../etc/avrdude.conf"
User configuration file is "/Users/abcde/.avrduderc"
User configuration file does not exist or is not a regular file, skipping

Using Port : usb
Using Programmer : avrisp2
avrdude: usbdev_open(): Found AVRISP mkII, serno: 000200006105
AVR Part : ATmega328P
Chip Erase delay : 9000 us
PAGEL : PD7
BS2 : PC2
RESET disposition : dedicated
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 200
StabDelay : 100
CmdexeDelay : 25
SyncLoops : 32
ByteDelay : 0
PollIndex : 3
PollValue : 0x53
Memory Detail :

Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
eeprom 65 20 4 0 no 1024 4 0 3600 3600 0xff 0xff
flash 65 6 128 0 yes 32768 128 256 4500 4500 0xff 0xff
lfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
hfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
efuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
lock 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00

Programmer Type : STK500V2
Description : Atmel AVR ISP mkII
Programmer Model: AVRISP mkII
Hardware Version: 1
Firmware Version Master : 1.10
Vtarget : 5.1 V
SCK period : 8.00 us

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e950f
avrdude: safemode: lfuse reads as FF
avrdude: safemode: hfuse reads as D6
avrdude: safemode: efuse reads as 5
avrdude: reading flash memory:

Reading | ################################################## | 100% 9.61s

avrdude: writing output file "/tmp/flash.bin"

avrdude: safemode: lfuse reads as FF
avrdude: safemode: hfuse reads as D6
avrdude: safemode: efuse reads as 5
avrdude: safemode: Fuses OK (H:05, E:D6, L:FF)

avrdude done. Thank you.


今度は適当なArduinoのスケッチを書き込むわけですが、これはArduino IDEでできます。

ボードの設定を「Arduino Pro or Pro Mini」に、プロセッサを「ATmega328 (5V; 16MHz)」に選択します。

ボードとプロセッサの選択を間違えないように
コンパイル後の書き込みはシリアルポートからできないので、いつもの編集画面のボタンではなく、メニューから「書込装置を使って書き込む」を選択します。
メニューから書き込みを実行
これで、ISPの緑ランプの点滅が終われば書き込み完了しているので、押さえた手を離してISPケーブルを外します。この時点でリセットされているはずですが、念のため、Nekoboard2のUSBケーブルを抜き差しして再起動してみます。

これで、書き込んだスケッチが動作しているはず。といってもNekoboard2上の赤い明るいLEDは単なる電源ランプなので、Lチカできません。残念でした。

今回はドリトル同梱のスケッチを使いましたが、センサの値をシリアルで送信するようなスケッチとして、[ファイル]→[スケッチの例]→[3. Analog]→[AnalogInoutSerial]あたりはどうでしょうか。といっても、A0はセンサでなく外付けセンサA端子なので、コメント直下の最初の行にある「const int analogInPin = A0;」を、A4(明るさ)、A5(音量)、A7(スライドボリューム)のどれかに変えてからコンパイルするのがよいと思います。それで、シリアルモニタを開くと、値が数値で表示されるはずです。それから、Nekoboard2はタクトスイッチがD2につながっているので、デジタル入力のサンプルで値が変化するのをみてもよいと思います(Scratch向けには1のとき1023を返すようにしているようです)。

というわけで、簡単にArduinoとして使えることがわかってしまいました。USB-シリアル変換チップもFTDIを使っているのでとても安定していて、いい感じです。

さて、返却前にファームウェアをもとに戻しておかなくてはいけませんので、再びavrdudeを使います。ISPをつなぎましょう。
$ ./avrdude -C../etc/avrdude.conf -p m328p -cavrisp2 -v -v -U flash:w:/tmp/flash.bin
こんなログがとれました。


avrdude: Version 6.0.1, compiled on Apr 14 2015 at 16:30:25
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2009 Joerg Wunsch

System wide configuration file is "../etc/avrdude.conf"
User configuration file is "/Users/abcde/.avrduderc"
User configuration file does not exist or is not a regular file, skipping

Using Port : usb
Using Programmer : avrisp2
avrdude: usbdev_open(): Found AVRISP mkII, serno: 000200006105
AVR Part : ATmega328P
Chip Erase delay : 9000 us
PAGEL : PD7
BS2 : PC2
RESET disposition : dedicated
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 200
StabDelay : 100
CmdexeDelay : 25
SyncLoops : 32
ByteDelay : 0
PollIndex : 3
PollValue : 0x53
Memory Detail :

Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
eeprom 65 20 4 0 no 1024 4 0 3600 3600 0xff 0xff
flash 65 6 128 0 yes 32768 128 256 4500 4500 0xff 0xff
lfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
hfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
efuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
lock 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00

Programmer Type : STK500V2
Description : Atmel AVR ISP mkII
Programmer Model: AVRISP mkII
Hardware Version: 1
Firmware Version Master : 1.10
Vtarget : 5.1 V
SCK period : 8.00 us

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e950f
avrdude: safemode: lfuse reads as FF
avrdude: safemode: hfuse reads as D6
avrdude: safemode: efuse reads as 5
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "/tmp/flash.bin"
avrdude: input file /tmp/flash.bin auto detected as raw binary
avrdude: writing flash (32768 bytes):

Writing | ################################################## | 100% 9.52s

avrdude: 32768 bytes of flash written
avrdude: verifying flash memory against /tmp/flash.bin:
avrdude: load data flash data from input file /tmp/flash.bin:
avrdude: input file /tmp/flash.bin auto detected as raw binary
avrdude: input file /tmp/flash.bin contains 32768 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 9.63s

avrdude: verifying ...
avrdude: 32768 bytes of flash verified

avrdude: safemode: lfuse reads as FF
avrdude: safemode: hfuse reads as D6
avrdude: safemode: efuse reads as 5
avrdude: safemode: Fuses OK (H:05, E:D6, L:FF)

avrdude done. Thank you.


これで元通り、Scratchセンサボードとして使えます。

2016年4月20日水曜日

別のMacに接続したHDDへTimeMachineバックアップした場合の復元方法

TimeMachineバックアップで簡単なのは、Apple製品に囲われること、つまりTimeCapsuleをWiFi APとして使い、それに内蔵されたHDDをTimeMachineバックアップの対象とすることなんでしょうが、それにはお金がかかるので、別のMacがTimeMachineバックアップにしているHDDにファイル共有で相乗りしたいと思う人も多いのではないかと思います。

このときですが、普通にFinderからリモートドライブをマウントすると、SMB(Windowsファイル共有)でマウントされてしまうので、TimeMachineバックアップするときは、AFPでマウントしないと、権限が違うという理由で、そもそもTImeMachineバックアップが作成できません。マウスクリックでやる方法はわかりませんが、明示的にafpを指定してあげれば大丈夫。FinderからCmd-Kで「afp://マシンのドメイン名/保存先」のように。

このあと、TImeMachieをONにすれば、バックアップが始まります。

すると不思議なのは、ローカルHDDへのTimeMachineバックアップは、そのまま普通にファイルシステムとして見えて、バックアップ先のファイルを普通にコピーできるのに(ACLの属性はあれですが)、ネットワークでマウントした場合には、バックアップそのものは、マシンごとにひとつのsparsebundleつまりフォルダになっていて、おなじみInfo.plistなどもそこにはあります。そこにあるデータはなんだかフラグメントされたデータファイルの塊であって、ファイルとして見えません。

それで、リストアできるのか心配なので、念のためtarballを自分で作ってGoogle Driveにあげておいたりしたのですが、杞憂でした。

1回目の修理のときにGeniusに尋ねたら、「ファイルシステムとしてマウントすると普通のファイルに見えるんですよ」とのこと。実はこの説明はひとつだけはしょっているところがあるんですが、後述します。

さて、いったん初期化されたマシンからリモートドライブ上のTimeMachineバックアップで復元する方法ですが、以下の手順となるようです。(参考
  1. Cmd-Rで起動して、リカバリモードに入る
  2. ターミナルを起動して、リモートドライブをマウントし、おまじないをする。
  3. すると「TimeMachineバックアップ」という名前で見えるようになる
  4. ターミナルを終了して、通常のリカバリ手順に入る
結局、ターミナルでコマンドラインを入力するのに慣れていないとちょっとつらい、ということです。コマンドライン無理な人はTimeCapsule買うがいい(と、突き放してみる)。

さて、参考サイトをみながらやった手順を以下に記しておきます。ご参考まで。
  1.  リカバリモードから[ユーティリティ]→[ターミナル]で、ターミナルを起動する
  2. rootのコマンドプロンプトが出るので、管理者(シングルユーザモード?)ということがわかる
  3. ネットワークを接続しておく(やはり有線が早くて良いけれど、WiFiの設定はこの時点でもできる)
  4.  以下のコマンドで、まずリモートドライブをマウントする
    • mkdir /Volumes/TimeMachine
    • mount_afs afp://ユーザ名:パスワード@マシン名/保存先 /Volumes/TimeMachine
  5. すると、/Volumes/TimeMachine以下に、バックアップしたマシン名のsparsebundleフォルダが見えるので、以下のコマンドで普通のファイルに見えるようにします
    • hdid /Volumes/TimeMachine/バックアップしたマシン名.sparsebundle
  6. ターミナルをexitして、Cmd-Qで終了すると、起動時のメニューになるので、「TimeMachieバックアップからリストア」に入る
  7. 「TimeMachineバックアップ」の名前があるので、それをクリックして選択し、先に進む
ということでした。hdidがキモになるコマンドだ、ということですね。で、man hdidすると、backward comatibilityのためにのみ存在するコマンド、とかあって、将来的にどうなのかわからないですけれど、OS X 10.4の頃のhdutilコマンド(現存しない模様)の機能を切り出したものだということで、必要性がある限りは残るんでしょう。El Capitan時点ではまだあります。

MBP Retine 13"ディスプレイ破損と交換、さらに再修理の顛末

前回の回復後、急いでTimeMachineバックアップをとったものの、次の打合せに持参したところで落としてしまい、ついにディスプレイがブラックアウトしたままどうにもならなくなりました。

一回目の修理


やむを得ず、Apple電話サポートと話をして、Genius Barの予約をとってもらいました。とはいえGenious BarはiPhone修理の人でいつも混雑していて、なかなかとれないこと。でも、電話サポートの人は、こちらが動ける4月3日(土)と6(水)の予約を2つ入れてくれました。

なんとか土曜の予約時間に間に合ったので、そこでみていただくと、iPadでステータスを確認しながら、見えない画面でいろいろキーボード操作して診断していた模様。ThunderboltにEthernetのドングルをつけた状態です。

それで、「外部ディスプレイに出力が出るかもしれません」ということで接続すると、普通に起動した状態の表示が出て、「たぶん本体とディスプレイの間のケーブルやコネクタの部分の問題でしょう」ということで、基本料金33,000円(税込み35,640円)の見積もりとなりました。うれしい金額です。キーボードのバックライトが点灯しない理由については、「環境光センサーで明るさが決まるので、その配線の問題では」ということで、いよいよ配線のみだろう、という気持ちが高まりました。

そして、修理センター送りにしたのですが、翌日すぐにApple Storeから電話が。業務があり気が付かなかったのですが、メールで連絡があり、リンクをクリックすると、詳しい診断結果が表示されました。
  • ディスプレイパネル折損。圧力によるものと考えられる
  • ロジックボードに分解痕、コネクタの一部はがれ
 でありまして、分解結果見つかった破損箇所を爪楊枝で指しているくっきりした写真つきのため、ぐうの音も出ません。占めて税込み81,000円の見積もり。この際、クラムシェルのディスプレイ側全体を交換ということになったようです。見積書にはこの金額だけが書かれていて、最初の見積もりとの差を考慮して、諸費用はまけてくれたようです。ついでにロジックボードの交換を含めた金額なので、かなり良心的な対応(Retinaディスプレイ全体の価格が8,1000円のようなので)。

さて困りました。そんな金額はどこにもありません。というか、これからかかる様々な費用に備えて積み立てていた3万円しかないわけです。前の金額なら、食費を削って捻出を考えていたんですが、もうだめ。やむなく、財務大臣に土下座して、華麗に無視されたわけですが、2日後にはなんだか5万円が無造作にテーブルに置かれておりました。「これ以上は出ないからあとはなんとかしろ」と理解して、積立全部崩すこと決定。仕事になりませんから。

で、そのままサイトで修理承諾のボタンを押したところ、4月11日(月)にはAppleStoreに届いたとの連絡がありました。動けるのが水曜だけなので、13日に受け取りに行きました.

2度目の修理


受け取りは特にGeniusではなく普通の店員が対応するので、単に倉庫からもってきて、受け取りサインをしたら引っ込もうとするわけですが、「念のため起動の確認させてください」と言って、立ち会いのもと電源を入れてみます。

すると、いきなりこの画面ですよ。
おなじみ(笑)kernel panicの画面
初めて見るので戸惑っていると、「工場のテストのあとこういうことはあるので、続ければいいです」というので、何かキーボードを押すとbootが進みます。で、まあ、それらしい画面になりました。というか、修理に出す前のままの画面でして、Chromeのタブも全部そのまま復元。SSDの消去などは一切しなかったようです。ありがたや。

それで、少し見ていると、まあ大丈夫そうだったので、そのままディスプレイを閉じてスリープしたんですが、なんだか嫌な予感が残りました。マウスカーソルが固まっている気配。

帰宅するとやっぱり固まっているので、電源長押しで電源断、再起動。まあ使えているようです。それで、その日は疲れていたのでそのまま寝落ちして、朝起きたらやっぱり固まっていました。

この際、セルフテストすべきだろうと思って、キーボードの「d」を押しながら起動すると、2つぐらい進んだところで固まります。え。

強制電源断、 再起動して、仕事を始めようとするんですが、ログイン画面の背景の上に、画面左上からだーっと小さな文字でkernel panicのメッセージが流れます。をを! これでこそUNIX。

感動と戸惑いを抱えつつ再起動すると、今度はログイン画面に入る前に、同じく上からkernel panicメッセージ。さすがに心配になったので、もう一度セルフテストにかけると、こんどは「異常なし」できれいに終わります。なんなんだ。

変なkernel moduleでもいるのかな、と、追加で入れたデバイスドライバなどを消してみるも、特に改善しません。というか、だんだんkernel panicの間隔が短くなってきたので、これはOSのクリーンインストールをして、それでもだめならハードウェアの問題、セルフテストは通るけど。と考えて帰宅。自宅でCmd-Rで再起動し、ディスクユーティリティでパーティションを再作成して、ファイルシステムの消去(フォーマット)をしてから、リカバリに入ります。リカバリ領域に入っていたのは購入時のMaveriks。インストールを進めるのですが、しばらくするとkernel panic! 素敵すぎる。単に再起動してみるとどうなるんだろうと思ったら、続きのインストールをはじめます。再びkernel panic! 再起動して、ようやくMavericksが入りました。しばらく触っていて、なんとなく普通に動いているようにみえます。ハードウェアはおかしそうだけれど、まあいいやと思って、El Capitanにアップグレードするも、こちらはkernel panicのメッセージは出ないもののプログレスバー(iOSと同じ感じのやつ)が動かなくなるので、そこで電源断、再起動を2回やったらインストールが終わりました。でも、しばらく触るとすぐにkernel panic(上の図の画面)するので、Safariでメールの用事を少し片付けたところで諦め、翌朝からApple電話サポートに電話。

といっても、セルフテスト通るので、「これは詳細調査させてください」ということで、再びGenius Barを2つ予約。今度は13日(水)の夕方と閉店前の2つ。もう宅配ピックアップでいいと思ったんですが、「いったんお店でみてもらってからのほうが」ということで、こうなったんですが、正解でした。

Genius Barの本領発揮


水曜日の前の日に最終バスを逃してしまい帰れなくなったので翌日そのまま仕事して、早めに上がりたかったけれど業務が終わらないので、自宅にいったんMBPをとりに戻り、そのままAppleStoreに直行。8時過ぎについたので、45分の予約よりはずいぶん早いのですが、iPhone修理の人がいっぱいいるなか、10分ほどで呼び出してくれました。

で、マシンを出すのですが、これといって異常を見せないわけです。こういうときって。

そこで登場したのが、Genius Barにある、ネットワークブートでの診断ツール。例によってEthernetドングルをつないで、[Option]キーで起動すると、ずらりとネットワークブートの地球が並びます。それぞれ名前がついていて、目的に応じた専用ツールがあるようです。「nを押して起動する方法もあるんですよ」とのこと。なんだか、NetBootとよばれる機能があるようですね。詳しい説明がここにありました。NFS使うんですかへえ。

それでハードウェア診断のツールでboot。今度はグラフィカルな表示で、プログレスバーやチェック項目のアイコンが現れては診断結果をアイコンにつけつつ進みます。結局すべてのハードウェアに緑色のチェックマークがついて、OK。

別のツールで見るも、これといった異常がなくて、「少しお待ち下さい」ということで現れたのは、エンジニアリングに最も詳しいと思われるスタッフのお兄さん。同じように診断結果がオールグリーンなのを確認して、普通にSSDから起動しようとするときの、ちょっとしたもたつきを彼は見落としませんでした。

「ログを見てみましょう」といって、コンソールを開くと「SSDのアクセス失敗が大量に出ていますね」という。僕も見ればすぐにそれとわかります。

そう思ってみると、起動時にも、メニューバーがなかなか出なかったりします。

すぐに、最初に対応したスタッフのおねえさんに指示を出します。「ロジックボード交換と、念のためSSDの交換」、診断状況の報告についてもいくつか文言の指示を出します。

それで出てきた見積書が、ロジックボード47,100円を無償、128GB SSD 33,500円を無償、ハードウェア修理の技術費3,300円を無償、合計83,900円を90日保障で無償というもの。前回の修理でロジックボード交換されているのは明らかですが、これだけ割り引いてくれたんだという感慨がありました。最後の修理費とはなにかと思ったら、AppleStore店内でパーツを取り寄せて交換するときの料金とのこと。「修理センター送りでいいんですけど」と言ってみたら、「やることは同じですけど、確かめておきたいので」と。修理センター送りにするとどこが悪いのか確認できないから自分の目でしっかり見たいという、エンジニアの性なんでしょう。「仲間だ」と思ったので、「お願いします」ということで、店舗へのパーツ到着を待って交換したのち、一定の負荷テストをすることに。

しばらく日数がかかると思っていたのですが、昨日、4月19日に修理完了のメールが届いたので、本日(水)に受け取ってきた次第。今度も、店内の一般店員はあまり技術に明るくなさそうでしたが、「前回受け取った時にちゃんと起動しなかったので」と言って、きちんと起動し、しばらく問題がないことを自分で確認しました。そのときに、「こちらでも、一定時間電源を入れて、いくつかアプリを使って正しく動作することを確認していますので」という説明がありました。

というわけで、いま、このエントリを書いている間にTimeMachineバックアップを戻し終わったところ。 ネットワーク共有先のドライブの場合どうするかについて、次のエントリに続きます。

ちなみに、なんだかSSDがめちゃくちゃ早いです。これが単に、リカバリ直後だからなのか、それとも、もしかして、もしかするとMBP Early 2015以後のPCIe 3.0x4のSSDだったりしたら、細かな心遣いに感謝したいわけですが、そればっかりは分解してみないとわからないわけで、ひとまず気にしないことにします。システム情報見たら、STAT/STAT Expressのところで「リンク幅: x2」とあったので気のせいでしたはい。

2016年4月18日月曜日

I-O DataのWN-AC433UAをArch Linuxで使う

(追記:2017年4月19日)最近のカーネルでは、この記事のドライバでは問題がありそうです。新たに記事を起こしましたので、ご参照ください。

WiFi APの構築をしています。NCUで。

当初はVyOSを使おうとしていたんですが、IntelのNCUではbootできませんでした。あと、内蔵Wi-FiモジュールはLinux Kernel 4.2以上が必要ということで、3であるVyOSは対象から除外することとなりました。それでいろいろ苦労しております。

そのあたりは後述するとして、この際LinuxはArch Linuxにしようと決めました。理由はただひとつ、どんどん新しくなるからセキュリティ対応も早かろうと。

Wi-FiのAPなので、アンテナが外部に出ていたほうがなにかと便利と思い、I-O DataのWN-AC433UAがなんだか在庫があるということで、何も考えずに注文して届いたわけですが、当然Arch Linuxでは認識できないわけです。動いたという報告が見当たらなくて、しばらく途方に暮れていたのですが、日をあらためて調べ直すと、チップセットは「Realtek RTL8811AU」とのこと。つまり、このカーネルモジュールを入れればよいということになります。

すると簡単に、AURとして「rtl8812au_rtl8821au-dkms-git」があることがわかりました。名前はあれですが、RTL8811AUもサポートすると書かれています。

そうくればあとは簡単です。

とりあえず、AURの環境が準備されていなかったので、こちらの手続きにしたがって、yaourtでAURのパッケージコンパイルとインストールができるようにします。

そして、linux-headers、dkms、rtl8812au_rtl8821au-dkms-gitをインストールすることになります。最初はカーネルモジュールだけ入れて、dkmsが必要と言われてdkms、linux-headersがないと言われてlinux-headersを入れたのですが、この逆がよいのではないかと思います。

sudo yaourt -S linux-headers dkms
sudo yaourt -S rtl8812au_rtl8821au-dkms-git
dkmsを使うのは初めてだったので再起動してしまったのですが、そうしなくてもなんとかなるんだろうとは思います。

これでdkms statusすると
$ dkms status
rtl8812au_rtl8821au, 4.3.22_beta.r9.928e27f, 4.5.0-1-ARCH, x86_64: installed
と、カーネルに組み込まれていることがわかります。そこでおもむろにWN-AC433UAをUSBポートに挿し、lsusbすると
$ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 006: ID 8087:0a2a Intel Corp.
Bus 001 Device 004: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 001 Device 002: ID 04bb:0953 I-O Data Device, Inc.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
こんな感じで見えるようになりました。ip linkすると、
$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
3: wlp2s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
4: wlp0s20u1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether yy:yy:yy:yy:yy:yy brd ff:ff:ff:ff:ff:ff
ちゃんとデバイスが生えています。よかった。

まだ通信テストができていませんが、それはこれから。

2016年3月26日土曜日

MacBook Pro Retina 13-inch Mid 2014死亡→3日後に復活(追記:やっぱり死亡 in 2016年4月3日)

 (追記:2016年4月20日)
いったん復活したかに見えたのですが、結局ディスプレイのブラックアウトが発生し、どうにもならなくなりました。以後の顛末は次のエントリで。


3日前、新学期に備えて3Dプリンタの修理をしていて、調整のためUSBケーブルで接続していたところ、椅子で膝にMBPを載せた状態のまま、ふと立ち上がろうとしたら手すりがケーブルを引っ掛けてMBPが2m以上吹き飛び、ケーブルも壊れるという事態が発生しました。

MBPには、AppleStoreサイト限定の「Tech21 13インチ Impact Snap Case for MacBook Pro」を装着していて、これまでも教室への運搬中に落下させるなど、ひどい扱いをしているものの、特に傷が入ることもなく、本体の動作に支障をきたすこともなく使えていたのですが、今回はMicroUSBアダプタをSDスロットに指していて、それが破壊するほどの衝撃だったためか、起動不能状態に陥りました。

こういうときはまずPROMリセットから、ということで、Command+Option+P+Rを押した状態で電源を入れ、いったんはそれで何事もなく再起動したのですが、ほどなく突然ブラックアウトし、そのまま再びPROMリセットしても、SCMCクリアしても、起動音こそすれAppleロゴが現れない、ターゲットディスクモードのため、Tキーを押して起動した状態でThunderbolt接続したMac miniで様子をみても、外付けディスクとしても、「システム情報」にもThuderboltデバイスとして見つからず、お手上げになりました。

最後の頼みでAppleのサポートに電話して、3時間ほどあれこれと対処を探るものの改善せず、「残念ですが修理になります」という結論になりました。

Mac miniはTime Machineバックアップしているのですが、MBPは128GB SSDということもあり、クラウドに必要と思ったものを載せるやりかたでやっていて、作業中のファイルや、メモ的に開きっぱなしにしているブラウザのタブが失われると仕事が分断されるところがあり、修理に出してきれいさっぱりということには強い抵抗がありました。あと、Apple Careを購入していなくて1年保証が切れてしばらく経ったこの時点で修理代を払うこともできない状態で、詰んでいるような気持ちになっていました。

検索すると、内部の掃除だけで復旧できたという話がこのモデルについてもいくつかあり、なんとか底面の星形レンチのねじを外してみたいと強く思うに至りました。

そういうときはiFixitなわけですが、該当ページによれば使う工具は「P5」タイプのドライバとのこと、Amazonでいろいろ見ると、Penta 1.2mmという記述するものと同じようでした。ただ、iFixitの最初の写真は、P5以外にヒンジ部分の2本はP6と書かれており、2種類必要そうであるものの、使う工具の欄はP5ひとつだけということで、よくわかりませんでした。

翌日大須で、こういう特殊ドライバを置いている店をくまなく探してみるものの、工具を多く扱う店の入っている第2アメ横ビルは水曜休み、他の多くの店に置かれていた中華ドライバビットのセットで、P5とP6の両方が入ったものは扱いがありませんでした(あっても、P5のみを含むセットのみ)。

それでAmazonをポチると、通常配送で翌日には届いてしまい、電車賃払う必要があったのかと自問。

さて、それで、iFixitのサイトをみるのですが、さきのリンクの通り、Teardownのページがなく、内部掃除のため部品を外していく明確な手順はわかりませんでした。

それで、まずP5のビットでねじを外していくと、裏蓋のすべてのねじがP5であって、P6に合うものはありませんでした。ということは、大須にあったセットでもよかったわけですが、価格が1500円前後だったので、電車賃を入れてもAmazonのほうが安かった。結果的に。

ひとまず内部が見えたので観察するのですが、ほとんどの部品はねじでしっかり留められており、SSDもビス止めされ、振動などで部品が緩んで起動できなくなるような要素は見当たりませんでした。

そこで、ゴムのなかに接点があるようなコネクタ部分を指でしっかり押さえてみて、外した裏蓋をウエットティッシュで拭いたあと、見えている部分のほこりをさっと拭ったところで、裏蓋が外れたまま電源を入れてみると、意外にもAppleロゴが表示されました。そのまま、リカバリ手順に入ったように見えるのですが、メニューバーはあってAppleメニューがあるので、そこから再起動すると、普通にもとの状態で再起動してきました。

疑心暗鬼のまま、裏蓋を再度ねじどめして、もとの状態に戻して電源を入れると、なぜか完全復旧できた様子で、そのままいまに至ります。

考えてみたら、このマシンは購入翌日になにか致命的な初期不良があって、いったん修理に出していたのでした。そのときはGenius Barで確認して1年保証の範囲で無償修理に出しました。2013年モデルではビデオ関係の問題でApple Care関係なく無償修理対象だったことがあるようで、Mid 2014でも何か不具合が出やすいなにかがあるのかもしれません。

明日はTime Machine用HDDがついたマシンにTime Machineバックアップしておこうと思います。

2016年3月12日土曜日

Raspberry Pi純正7inch Touch ScreenとRaspbian Jessieへのジェスチャー機能の導入

Raspberry Pi公式7inch Touch Screenが届いたのが1月中旬だったかと思いますが、いままで多忙のため、ほったらかしにしていました。

OSも入れ替えるので、スクリーンがあったほうがよいと思い、使ってみることにしました。

まずボードを見ると、ATTINY88、つまり汎用AVRマイコンがいて、おや、と思いました。基板のパターンが見えないのでなんともいえませんが、東芝TC358762XBG DPI-DSIシリアル-パラレル変換チップとディスプレイコントローラのFT5406DQ9(フレキのなかに埋まっている)の間に入って、パラレル信号をAVRマイコンのI/Oで受けて、FT5406DQ9にSPIで画面のビットマップデータを渡す仕事をしているのかなあと思うところです。TC358762XBGの右側、Raspberry Piロゴのところで盛大にパラレルのラインが走っているのですが、スルーホールが終端になっているので、そこから基板の裏に抜けてATTINY88のI/Oに入っていると想像すると、ATTINY88とフレキのコネクタが隣り合っている理由が立つんではないか、という感じです。

あとRaspberry Piにこのボードから給電する使い方なので、電源がどうなっているのかが気になりますが、搭載されている電源チップはTIのTPS65101という液晶ディスプレイ用マルチ電圧電源チップが搭載されているだけで、Raspberry Pi基板給電についてこれといった特別な配慮はないように見えました。USB端子から給電されたものを液晶用にはこのチップで複数の電圧の電源を作って使いますが、Raspberry Pi側にはそのまま流すだけなのかなと思います。

マルチタッチのための指の座標などを扱うI2Cに関しては、Raspberry Pi A+/B+以後はDSI端子にI2Cが出ているのでそれを使うそうです。一方、Pi 1のDSIにはI2Cが含まれていないので、Raspberry PiのGPIOに配線するためのI2Cピンヘッダが出ているということのようです。販売されているキットに4色のメス-メスワイヤーがついてきて、赤と黒でRaspberry Piにこの基板から給電するような説明で、残りの3つのピンや黄と青のワイヤーの使い道について説明がないのは、それが理由のようです。つまり、Pi 1ならSCLとSDAを余った2本のワイヤーでそれぞれGPIOの物理ピン番号で5(SCL)と3(SDA)につないでタッチ機能を使えるようにする、ということ。さらに、ボード上のUSB A端子は5V出力用なので、百均の短いmicroUSBケーブルを使ってRaspberry Piに給電してあげれば、Pi 1以外ではキットに添付のワイヤーは不要になります。
ディスプレイ裏のボード部分
話が前後しましたが、接続方法はRSコンポーネンツの代理店ケイエスワイさんのページにある通り簡単で、DSIフラットケーブルの向きや裏表を間違えないことと、この手のケーブル用コネクタはプラスチックの押さえを引き出してからケーブルを差し込み、再度押し込んで固定する構造ということさえ理解していればよい、と、他のブログでもいろいろ解説されている通りです。Raspbianも最新のNOOBSでは最初からタッチデバイスを「FT5406」として認識してくれました。lsmodすると、「rpi_ft5406」というカーネルモジュールも入っています。

ということで、いきなり何も困らない感じでしたが、触ってみると困るのが右クリックがないこと。

WheezyではXの設定でEmulateButton3関係のプロパティを設定してあげれば動くようですが、Jessieではプロパティが設定されていても無視されるようでした。ここまではフォーラムの前半の議論の通りですが、次のページにあたる後半に、twofingというプログラムでジェスチャーイベントを設定してやる方法がありました。 設定手順は別スレッドに整理されていたので、こちらを参照されるとよいと思います。

「twofing」が実現するのは、以下の3つのジェスチャーのようです。
  • 2本指スクロール(タブレットと同様に、指に画面移動がついてくる動き)
  • 2本指ピンチズームと回転
  • 2本指タップによる右クリック
やってみると、狭い画面で2本指タップで右クリックというのはなかなかつらいですが、タップを使っている間に右クリックだけのためにマウスに手を伸ばすのはたいへん残念なので、それよりはよほどいいのかなと思います。

フォーラムに書かれている手順の概略をだいたいまとめると以下の通り。
  1. gitを入れる
    $ sudo apt-get install git
  2. ソースを取得
    $ git clone https://github.com/Plippo/twofing.git
  3. 必要なライブラリ取得
    $ sudo apt-get install build-essential libx11-dev libxtst-dev libxi-dev x11proto-randr-dev libxrandr-dev
  4. cd twofing; make; make install
  5. /etc/udev/rules.d/70-touchscreen-egalax.rules に以下を追記
    KERNEL=="event*",ATTRS{name}=="FT5406 memory based driver",SYMLINK+="twofingtouch",RUN+="/bin/chmod a+r /dev/twofingtouch"
  6. ~/.config/lxsession/LXDE-pi/autostart に以下を追記
    @/usr/bin/twofing
5番目はOS起動時にタッチスクリーンの入力イベントデバイスを、twofingが参照するデバイス /dev/twofingtouch に関連付ける記述で、6番目はLXDEが起動するときについでにtwofingを起動させるための記述です。

これで二本指ジェスチャーが使えるようになって、マウスがなくてもあまり困らなくなると思います。

右クリックは上部のバーですぐに確かめられます。スクロールは標準のEpiphanyブラウザで、ピンチでの拡大縮小はLibreOfficeで確認できると思います。

このあとさらにオンスクリーンキーボードもあればキーボードも不要になっていよいよタブレットということになりそうですが、LXDEデスクトップを使うには解像度が足りないので画面が狭く、ちょっと躊躇するところです。この画面サイズで指操作を考慮した特定のアプリケーションでの利用に限定するのが無難なのかと思います。研究・開発用という感じでしょうか。

2016年3月11日金曜日

Raspbian Jessie上のドリトルで日本語入力できた

昨年夏にRaspberry Piのドリトルで日本語入力しようとしたとき、Jessie+ibus-anthyではドリトルだけ日本語入力できないという問題があり、Wheezyに戻して使うということをしていました。

しかし、Raspberry Pi 3で標準搭載のWi-Fi+Bluetooth 4.1チップのドライバが、発表日である2月29日以後のRaspbianにしか入っていないような報告があり、Jessieがインストールされることが確実なため、日本語入力の方法を探しておかなければならないと思い、試してみました。

日本語入力については、検索してみるとscimを使う人、ibusを使う人、いろいろおられるようでしたが、uimを使う設定を書かれている人がいて、「あ、これは...!!」と思った次第。

具体的にはNOOBSは1.8.0でした(2016年2月29日付)が、もちろんJessieです。

RSコンポーネンツの解説にしたがって、日本語フォントを導入したあと、
$ sudo apt-get install uim uim-anthy
としました。なにやらuimのメニューアプレットが表示されましたが、日本語入力への切り替えがわかりませんでした。検索してみると、コマンドラインから「uim-pref-gtk」を起動せよとのこと。

起動すると、左の「グループ」のなかにいろいろありますが、「全体キー設定1」をみると、「Shift+スペース」がローマ字かな変換のオンオフということがわかりました。状態表示がよくわからないので「全体設定」グループの「視覚設定」→「□カーソルの側に入力モード表示」にチェックを入れて、「OK」ボタンを押し、設定変更してみたところ、たしかに、Shift+スペースで、直接入力とローマ字かな変換の表示が変化して、日本語変換できることが確認できました。

さてドリトルです。新しくインストールしたRaspbianなので、再び公式ページからダウンロードしてインストールするんですが、Jessieからは、ダウンロードフォルダの名称が「Downloads」になったんですね。Wheezyでは全角カタカナの「ダウンロード」だったので、コマンドラインからの入力に一手間入ってつらかったのですが、助かります。「dpkg -i ファイル名」でインストール、メニューからドリトルを起動しました。

日本語入力、ちゃんとできました。

最初に失敗してから半年以上経っているので、どこがどう変化してうまくいくようになったのかよくわかりませんが、いちおうuim-anthyでは大丈夫ということが確認できたので、ご報告です。

2016年1月16日土曜日

Raspberry Pi 2用GPIOオスメス変換アダプタ製作



RPi B+/A+以後はGPIOは40ピンになったので,B用にAdafruitから買ったコブラケーブルが使えなくなってしまいました。理由は26ピン用コネクタの両端がピンヘッダのピン間隔より広いから。「削ればまだ使えるのではないか?」と,いま気づいたけれど,ひとまず今後の課題とします。

それで,40ピンはIDEコネクタなので,画像検索してみるとIDEケーブルを使っている例が多数出てきます。

それもいいのだけれど,考えてみればブレッドボード用リード線のオスメス問題を解決したいだけなので,この方のブログエントリのように,40ピンソケットを向きあわせにはんだ付けすれば,ちと高さがアレだが十分ではないか,ということなんですね。素晴らしい発見だと思いました。

というわけで,秋月の長さを自由に切って使える2列のピンソケットが手元に常備されているので,早速取り組んでみました。実は在庫が足りなかったので,反対側は1列を重ねて,はんだ付けするのでまあいいやというやりかた。

作業は簡単で,老眼その他で目も手も怪しいのだけれど,さくさく作業が進んで,テスタで変なショートしたりずれたりしなかったか,両側にピンヘッダを差し込んで確かめてみても問題なく完了しました。よかった。

それで,このアダプタにピンの名前を印刷した紙を貼る,というアイディアをいただくことにしたのだけれど,控えめに,RPiに取り付けたときに上半分になる部分だけになるようにされていた部分,これは両幅いっぱいにして秋葉あきわさんの御札よろしく「火除け魔除けになって穴も隠れます」(牛ほめ)とするのがよいのではないかと思って,もとのodtに書かれていない,UART, SPI, I2C, PWMなど各ピンの用途を後ろに追加してみました。

スプレッドシートでどうやってぴったりのサイズに印刷できるようにするのかと思ったら,セルの高さが「0.1"」になっておりまして,印刷してみるとたしかに400milでした。幅は適当に「0.75"」にしてみましたが,あててみたらぴったり。素晴らしい。
1番ピン(奇数)側
2番ピン(偶数)側
貼り付けは,事務用のアラビアゴム糊です。一晩置いてみました。

仕上がりには満足しましたが,やっぱり紙なので保護が必要かなあと思い,透明テープを貼ろうとしたら,幅がほぼぴったりでなおびっくり。上の写真は,テープを貼ったので,はみ出したところが少し折れたりしております。ニッパで40ピンに切ったので少し長さが違っていて,カッターで削って揃えようとしたのですが,削りすぎたり足りなかったりで長さが少し違うためです。

GPIO_19に「PWM1」と書いてありますが,これはオーディオ用なんだそうです。「音声出力しないなら使ってもいいんじゃない?」とのこと。PWM2もあるけれど,それは映像用らしく,触るべきではないようです。詳しくは財団のフォーラム記事参照。モーターカー制御の予定があるので,PWMが2つとれればいいなと思って追記したんですが,使えるかどうかはためしていません。
内側はピン名が見づらいことが判明
RPi基板に載せてみました。外側(偶数ピン側)はいいんですが,内側(奇数ピン側)はとても見づらい。どうも失敗だったようです。節穴部分もへこんでしまったし... 何か埋めてからのほうがよかったんですね。パテとか。

ひとまず今回は,I2CやSPIが見えればよいということで納得することにします。いい工夫があったら,どなたかぜひ公開してください。

2016年1月9日土曜日

Raspberry Pi 2にArch Linuxを設定する

最小限の組み込みLinux環境を作るべく,Arch LinuxをRaspberry Pi 2にインストールしたので,そのメモ。

ひとまず起動用に,UHS-1 Class 10の8GBのマイクロSDカードを用意しました。Raspbianと違ってとても小さいのでこんなにいらないのだけれど,年末だったせいか,4GBは全部売り切れだったので,ひとまず最安値で。ブランドは東芝でしたが並行輸入品だそうで。

Raspberry Pi用のArch Linuxは,財団のサイトからは配布されていません。昔はみたような気がするんだけれど,とにかくいまはない。それと,イメージを書けばよいという簡単な話ではなくて,LinuxマシンでSDカードの設定をしていかなくてはいけないので,Linuxマシンが必要です。どのLinuxでもいいので,例えばUbuntuのCD-Rとか作って,CD-R起動の状態で,特にPC等へLinuxをインストールしない状態で作業してもいいんじゃないかと思います(よくわからない)。

手元にはArch Linuxで稼働しているマシンがあったので,作業はそれで行いました。

OS本体は,/rootパーティション以下を.tar.gzした状態で配布されています。また,Pi 2以外(Zeroを含む)とPi 2ではARM Coreの命令セットが違うのですが,別個に作って配布されています。

正直な話,Arch Linuxは他のディストリビューションと違って,Wikiがすべての情報源かつ,OS側に特別なサポートツールがないので,PCでArch Linuxにある程度慣れてからのほうがいいと思います。

というわけで,Wikiはこちら。

Arch Linux: Raspberry Pi

OSは,以下のページにずらっとARM向け各種が並んでいます。

 Arch Linux|ARM Downloads

Raspberry Pi 2はARMv7アーキテクチャということで,下の方に「ArchLinuxARM-rpi-2-latest.tar.gz」というファイルがあると思います。それ以外はARMv6アーキテクチャということで,上の方に「ArchLinuxARM-rpi-latest.tar.gz」というファイルがあると思います。

今回はRi 2用なので,下の方のやつをもってくるわけですが,先にSDカードの準備を含む手順があるので,その説明ページのリンクを示します。
手順はどちらも同じですが,一応Pi 2用に書かれているインストール手順に沿って書いてみます。
  1. SDカードを何らかの手段でLinuxにマウントします。USB接続のカードリーダを使うのが一般的だと思いますが,ノートブック型だとSDカードスロットがあって簡単かもしれません。そのデバイス名を見ておきます。買ってきた状態だと,FAT32でひとつのパーティションになっているはずなので,/dev/sdX1(Xは適当なアルファベット1文字)だけのデバイスに見えるはずです。僕の場合,なぜか/dev/sdg1だったので,以下,それ前提で書きます。
  2. rootになります。sudo -sでいいかな。お好みで。
    1. fdiskでパーティションを自分で切ります。# fdisk /dev/sdg
    2. 試しにpコマンドを入れると,現在のパーティションテーブルが見えると思います。これをメモリ上ですが,いったんクリアします。oコマンド。これでpすると,何もないんだよー的な数行の表示が出ると思います。続けて,nコマンドで/bootパーティション(FAT32フォーマット)を作ります。プライマリなのでpを入力し,1がデフォルト (パーティション番号1ということ)なので,そのままEnterを押してOK。続けてパーティションサイズをきかれるので,「+100M」と入力してEnterします。
    3. このパーティションをFAT32に設定するため,tコマンドを入力して,タイプにはcを入れるらしいです。これは,「W95 FAT32 (LBA)」という型に対応するようです。 心配なら,ここでpコマンドで確認してもいいと思います。
    4. 残りをext4ファイルシステムにするため,nコマンドでパーティションを追加することを指示して,プライマリp,2番目がデフォルトになっていると思うので,このままEnterを押してよいと思います。パーティションサイズは残り全部なので,そのままEnterで確定。この状態でpコマンドで確認してもいいと思います。
    5. 最後にメモリ上のパーティションテーブルを実際のSDカードに書き込みます。wコマンド。途中でわからなくなったら,wするまではSDカードは無事なので,^Cなどで中断して最初からやり直してもOK。
  3. 次に,手でファイルシステムを作ってやります。FAT32は,mkfs.vfatコマンドが必要ですが,Arch Linuxの場合,最初からは入っていません。
    # pacman -S dosfstools
    してやると入ります。
  4. # mkfs.vfat /dev/sdg1
    # mkdir /mnt/boot
    # mount /dev/sdg1 /mnt/boot
    
    パーティションが小さいので,わりとすぐに終わると思います。あと,デバイス名はくれぐれも先に調べたものに合わせてください。それと,Arch Linuxは/mntというディレクトリがあったので,そこにbootとrootを作ることにしました。お使いのLinux環境に合わせて適当に変更してください。/mnt/bootのなかみは空ですが,あとから移してきますので,マウントはしておいてください。
  5. rootパーティションのファイルシステムを作ります。ext4なのでおなじみの通り。
    # mkfs.ext4 /dev/sdg2
    # mkdir /mnt/root
    # mount /dev/sdg2 /mnt/root
    
  6. では,OS本体をもってきて,/root以下に展開します。今回はPi 2なので,そちらのイメージ。それ以外はそれなりに。
    # wget http://archlinuxarm.org/os/ArchLinuxARM-rpi-2-latest.tar.gz
    # bsdtar -xpf ArchLinuxARM-rpi-2-latest.tar.gz -C /mnt/root
    # sync
    
    wgetでとってきていますが,curlじゃなきゃやだとか思う人はcurl使ってください。ドキュメントに書いてあったのを転記しただけです。展開した後安全のためにsyncしていますが,SDカードイメージにそれなりの変更を加えているので,結構待たされます。心配になるかもしれませんが,1分ぐらいのつもりで待ちましょう。
  7. 最後に,/bootパーティションのなかみを/root/boot以下から移します。
    # mv /mnt/root/boot/* /mnt/boot
    
    ここで心配なら,再度syncしてもいいと思います。
  8. 以上でインストールは終わったので,後始末です。
    # cd /
    # umount /mnt/boot /mnt/root
    # rmdir /mnt/boot /mnt/root
    
おつかれさまでした。これで,SDカードのアンマウントも終わったので,カードはLinux PCから抜いて,Raspberry Pi 2に挿しなおしてください。

さて,以下は,Arch Linux ARM起動後の最小限の作業になると思うので, 今回はそこまでメモしておしまいにします。

最初はコンソールで作業しなければいけないので,RPi 2のUSBにキーボード,HDMIディスプレイ,Ethernetケーブルを挿して,電源を投入します。Wi-Fiしかない人は,PC用のArch Linuxのスタートアップマニュアルを参考にしてWi-Fi設定までやってください。

最初に電源を入れると,普通にLinuxの起動シーケンスが進んで,login: まできます。Arch Linux ARMのユーザ名は,Raspberry Pi版かどうかに関係なく共通で,「alarm」です。Arch Linux ARMの大文字の部分だけとってきたんだな,と思えば覚えられると思います。初期パスワードも同じく「alarm」です。

次に,rootの作業をするわけですが,驚くかもしれませんが,sudoが入っていません。よって,最初はsuする必要があります。rootの初期パスワードは「root」です。ログイン名とおんなじ。

気持ち悪いので,sudoを入れて,パスワードを変えたり,「pi」ユーザを作ったりすることにします。
$ su
Password: root
# pacman -S sudo
# vi /etc/sudoers
設定はお好みで。Raspbianに合わせるなら,
%wheel ALL=(ALL) NOPASSWORD: ALL
の行をコメントアウトするんだと思います。書き込み許可がないので,w!で強制書き込みします。

これで,sudoできるようになりましたが,alarmきもちわるいな,と思うので,ユーザ「pi」を作ってwheelグループに入れることにしました。
# useradd -G wheel -m -c "Pi User" pi
# password pi
(raspberryを2回入れる)
ついでなので,alarmはロックしてログインできなくしてしまいます。
# passwd -l alarm
rootのパスワードも変更しておきましょうか。
# passwd root
(お好みで)
 sshは最初から起動しているので,IPアドレスがわかれば,例えばいま作ったpiユーザでsshログインすることはできます。でも,やはりavahiを入れて,ホスト名を広報してもらったほうが使いやすいと思います。
# pacman -S avahi
# systemctl enable avahi-daemon
# systemctl start avahi-daemon
これで,「ホスト名.local」でつながると思います。AvahiはMac OSが採用しているmDNSなので,Windowsマシンからは,iTunes等を入れるなどしてApple Bonjourサービスが起動していないと見えません。

ホスト名は,/etc/hostnameに書かれている内容を起動時に読み込んで設定するので,お好みのホスト名に変更して再起動することで,リモートログインも気持ちよくできるんではないかと思います。初期状態では,「alarmpi」です。

最後に,SSH接続するMacなどの~/.ssh/configに,適当な設定を書いておくなど,通常のSSHクライアント設定をして,ひとまず完了かと思います。

2016年1月6日水曜日

逐次比較型A/Dコンバータの勉強

そもそもA/Dコンバータってどうやってできてるの? ADCデバイスをソフトウェアから使うとき,クロック周波数指定するけどどうして? という疑問から,いまさらながらにしくみを勉強したところ,逐次比較型A/Dコンバータって,上位ビットから順に二分探索で電圧値を求める(LSBは切り捨て)手順だということに気づいた。

説明は,第一種アマチュア無線免許の試験問題解説をされているRadio-GXKさんのサイトの記事がとてもわかりやすい。同時に解説されている二重積分形型についてもわかりやすくて,とてもよかった。

変換トリガとともにサンプルホールドした入力電圧値を,Aref電圧に対して,上位ビット(MSB)から1/2, 1/4, 1/8, ... と,求めるビット数分だけ割っていった電圧を保持するDAC(キャパシタで構成するのが一般的なようだ)を用意しておき,クロックごとに上位ビットから順に比較していき,入力電圧値がDACのそのビットの電圧値より大きければ1,小さければ0をを出力ラッチに入れると同時に,次のサイクルでDACのビット設定にも反映することをLSBまで繰り返す。

つまり,末端,葉の部分で左から0V,右に向かって2のbit数乗(8bitなら2^8=256)刻みでArefまでの値が並ぶ二分木として決定木を作り,根から左なら0,右なら1を選ぶように木をたどることでアナログの電圧値をArefの比でいくつになるのかを二進法で示した値が得られるということ。決定木は「コンピュータサイエンス・アンプラグド」の活動「20の扉」と,その解説が参考になると思う。MSBが根でLSBが葉になるところも解説の図と一致する。

なるほど二分探索ね,と思って検索してみたら,特許にそういう記述をしているものがあった。意外と大学の講義ノートのようなものには見かけないので,ソフトウェア屋さんとハードウエア屋さんの壁みたいなものを感じた次第。アルゴリズミックに動く回路なので,アルゴリズム名で説明すればいいのになあ。

一方,⊿Σ型ADCについては,日本人の発明ということで,ちょっと感動した。Wikipedia参照。PDMになる,というのは感覚的にはわかるがデジタル信号処理の理解が中途半端なので,式を見ていても,はあそうですかとしかならなかった。残念。

それで,ではPDMの結果をマルチビットにする(PCM相当に変換する)デシメーションフィルタってなんだろうと思ったら,⊿Σ変調含めて詳しく書いてあったブログがあった。このへんから入っていくと,すっきりわかるような気がする。decimationで辞書をひくと「サンプリングレートを大幅に下げる」って書いてあるけれど,高い周波数で1bit AD変換しているPDM結果を,適当な量子化ビット数に数えられるだけの間隔(例えば8bitなら,1/256)に落として,その区間における,元の周波数における1の数をカウントするという理解でよいのだろうか。密度の高低を値の大小に変換するわけだから。このページではディジタルローパスフィルタとなってて,検索してみると詳しい解説がいろいろあって,いくつか眺めているうちに,その表現に,ひとまず納得した。加算するので遅延していく(位相が遅れる)というのもアナログと同じ特性。なるほど。