18F2550 -> 18F14K50

本日14K50が届いたので準備の続き。先日ブレッドボードで組んだpic18spxはリセットボタンを付けて基板に載せました。部品点数少なすぎて基板がスカスカ。配線ガシャガシャしててもUSB側は安定してるんでリセットボタンいらなかったかも。書き込み用のピンは手元の機材ですぐに実験できるAVR用の2×3タイプのみ。

右が2550。TINY2313の読み出しを確認した後、左の14K50を使った2台目の書き込みに。書き込みにはpic18spx-2010-0416に付属のpicwriter.exeを利用。hidspxでいけるもんだと思い込んでて-rが成功せずにしばらく悩んだ。

新たにブレッドボードで動作確認。リセットをプルアップしてる以外はクロックと配線のみの超手抜き状態。ですが、安定動作してます。水晶は秋月で28.6円のSG531PAP。水晶のOUTをCLKINに繋げてCLKOUTは開放。設定変更くらい必要かと思ったけど、そのままで動いてる。こっちは基板では2×3と1×6両方付けるつもり。
と、ここまででようやく開発の準備が完了です。
そう言えば、フルスピードになると我が家のオシロでは対応できないので、ハード側でハマると死にそうです。

pic18spx

手持ちのPICライター、AKI-PICではPIC18F14K50に書き込めないっぽいので対策。嬉しい事にさくっと見つけたpic18spxが需要を満たしてくれそう。個人的に嬉しいポイントは

• Linux / OS Xからも使える
• PIC18F2550とPIC18F14K50に対応してる
• ライターもツールもhidspxの上位互換として動く（AVRにも書き込める）
• PIC18F2550と20MHz水晶だけで作れるので、手持ち在庫とAKI-PICで作れる

ってところ。

回路

ざっくりオフィシャル通りでこんな感じ。

追記：RC2をpull upしてるけど標準hexではBoot Loaderは殺されてるので不要

Linux / OS Xでの利用（ややハマりポイントあり）

picmon/picbootは関してはオフィシャルページのpic18spx-2010-0416.zipを展開すればWindows用のバイナリと一緒にソースが入ってる。picspxは別途配布されているpic18spx-linux.zipを使うこと。

Linuxでは中で呼んでるusb_claim_interface()にroot権限が必要なため、sudoしないと駄目。オフィシャルページ読めば書いてあるけど見落としてた。hidspxではroot権限不要だったと思うんだけど・・・まじめに調べてないけど、単純にhidspxはcontrol転送しか使ってないんで標準HIDドライバが不審に思って掴まなかっただけな気がする。

同じ理由でOS Xでもusb_claim_interface()が失敗。こっちはrootでも駄目。usb_detach_kernel_driver_np()を試しても失敗するのでusb_strerror()を読んでみたら「function not implemented」を返してきた。もう少し検索してみるとこんなスレッド発見。要は標準ドライバ避けに専用kernel driver作ってOSを再起動するしか方法はないらしい。まぁHIDはセキュリティ的にも際どいし、わからなくもない。

よくよく考えるとWindows使わない身としてはHIDのフリをさせるメリットもないので、独自クラスにデスクリプタ書き換えたfirmwareを作ることで解決するつもり。そうしとけば、その気になればUSB API使ってChromeからも書き込めるし。

そのほかハマった点

前エントリの通り、最新版のAKI-PICを試そうとして危うくVM上のWin XPを再起不能にしかけた。しかも試し損。加えてVMのUSBブリッジが不安定。結局、唯一稼働してる実機Windows、Win7/LOOX U50WNを引っ張りだしてPIC18F2550を焼いた。ライターにhidspxを使ってPICに書けるPICspxなんてのあったけど、うちの環境で読み込んでみたら不定値が返ってくる。ライター側のバージョンでAPIが微妙に変わってそうなので、深入りせずに過去に実績のあるAKI-PICに逃げた。これがAKI-PIC最後の出番かも。
追記：USBブリッジの問題はホスト側で/etc/udev/rules.d/40-vmware.rulesみたいなのを以下の内容で作ってやったら解決した。USBデバイスのパーミッションが常に全開放になる点だけは注意。vmware server 2.0/Ubuntu 10.04.4 LTSの組み合わせ（この組み合わせもいい加減古い）。

SUBSYSTEM=="usb", ENV=="usb_device", MODE="0666"
SUBSYSTEM=="usb_device", MODE="0666"

関係ないけど驚いたこと

vimでhexファイル（PICのa.out的なもの）を開いたらレコードごとに色分けして表示してくれた。超便利。これ見ながらpicmonで期待してるデータが読めるか確認。ピンクが長さ、青がアドレス、赤がタイプ、無印がデータ、最後の黄色バックがチェックサムです。

AKIPIC PICPGM6β6.76でハマった

最新版のデバイス対応状況を確認しようとしてカジュアルにアップデートかけたらOSが起動しなくなった。一番悪いのは僕。なにせ使ってたのはXP、アハハ。

問題は単純で、システムのOLEAUT32.DLLを上書きされちゃう。Vista以降でしか動かないバージョンで。エラーメッセージ的にはMSVCRT.DLLにstrcat_sのエントリが見つからない、といってexplorerも何も動かなくなっちゃうんだけど、実際にはエントリがないのがXP版としては正しくて。Vista以降のMSVCRT.DLLに依存を持ったOLEAUT32.DLLがインストールされたのが本質的な原因。

ってことで、対処としては、OSのインストールディスクをドライブXに用意して、コマンドプロンプトを使って以下の処理を行う。explorerは起動しないけど、Ctl+Alt+Delからタスクマネージャは呼べるので、ファイル＞新しいタスクの実行(N)…からcmd.exeを実行です。

C:¥WINDOWS¥system32>ren oleaut32.dll oleaut32.bak
C:¥WINDOWS¥system32>x:
X:¥>cd i386
X:¥I386>expand oleaut32.dl_ c:¥windows¥system32
X:¥I386>c:
C:¥WINDOWS¥system32>ren oleaut32.dl_ oleaut32.dll

更新履歴にはVista以降はまだ準対応とか書きながら、実際はVista以降でしか動かないという…かなり攻撃力高いです。っていうか、僕悪く無いじゃん、やっぱり。

昔のサイトをHerokuに詰め込んだ

仲間内の共有サーバに詰め込んでた昔のサイト。マシン乗り換えの話が出たので「えいやっ」とクラウドに載せ替えた。古いサイトなので、基本はほとんど静的なページばかり。リンク先やら取り込んでるコンテンツやらが死亡しまくりなので、動的コンテンツも真面目にサルベージするほどでもない。

ってことで、とりあえずSinatra/Ruby/Herokuの組み合わせで対応してみた。ドメイン的には10サイトほどあるけど、まぁ1Dynoでさばけるでしょう、と。（むしろ、まとめてた方がインスタンスが寝なくて好都合？）

とりあえず静的なコンテンツはSinatraに丸投げしたかったんだけど、VirtualHost対応はApacheやnginxで行い、その下でSinatraが動かすのが一般的だったのかな？　Sinatra単体でスマートな方法はなさそうだったんだけど、ここはSinatra単体で行きたかったので小細工で対応しました。動作はRuby 2.0.0 + Sinatra 1.4.4で確認。

require 'sinatra' 

set :add_charset, [] 

before '*/' do
  request.path_info = request.path_info + 'index.html'
end 

before do
  request.path_info = '/' + request.host + request.path_info
  static! if (request.get? || request.head?)
end

本当はbeforeフィルタでpath_infoを書き換えれば後はよしなに・・・というのを期待したんですが、ファイル存在判定はbeforeフィルタより手前でやってるんですね。なので、path_infoを書き換えた後に、もう一度static!を呼んでファイル再判定させてます。ちょっとしかコード追ってないんですが、ファイルチェックを一番最初にやってbeforeフィルタは常に回して、afterフィルタはファイルの時には回さない、という挙動っぽいけど、何か意味あるのかな？Sinatra詳しいってわけではまったくないので、詳しい人、あるいはもっと良い方法あるよ、という場合は教えて頂けると幸いです。

あと、add_charsetは明示的に空にしてます。これやらないとtext系のContent-Typeにcharset=utf-8を自動的に付けちゃって古いShift_JISのコンテンツに悪影響与えるので。HTTPヘッダのContent-TypeについてるcharsetとHTML側のcharsetのメタ情報が一致しない、Content-Languageとhtmlのlang情報が一致しない・・・ってのはChromeでも良くハマる問題で。文字化けや、間違った翻訳サジェストの原因になってます。頑張って間違い推定するようにしたんだけど、完全にはできないのでサーバ側で気をつけたいところです。

あと、http://toyoshima-house.net/ にあったコンテンツは有用な物だけ当ブログにマージして、元ドメインには転送をしかけました。Google+には更新情報として古いコンテンツも飛んでたみたいですが、コンテンツ自体は古い日付でエントリされてます。加えて、このブログにも独自ドメインを振りました。

照明機材を身近に

バンドやってる人はわかると思うんだけど、ライブハウスでイベントやる時、音はどうにか自分たちで仕込めるんだけど、照明は完全に会場スタッフに任せっきり。しかも、当日紙一枚見て適当にフィーリングでやられちゃうので残念極まりない。という事で、照明機材をもっと身近にできないかなぁ・・・という事で作ってみました、USB-MIDIタイプのDMX変換器です。

USB MIDI - DMX bridge from toyoshim

これがあるとChrome上で楽器から照明、VJスクリーンまで好き勝手に制御できるので幸せ。まぁ、夢には遠いけど第一歩という事で。

PIC18F14K50についてはスライド作りながらF2550っていくらだっけ？と調べて存在を知った。170円でUSB2.0インタフェース内蔵、内蔵オシレータで16MHzまで出て、PLLを通せば32MHzまで安定したクロックが供給できる。SRAMも768Bと、このクラスにしては十分なサイズ。重い腰上げてPICに戻っても良いかも。

ChromeにおけるWeb MIDI APIの実装状況

2013もそろそろ終わりって事で今年色々と動きはじめたWeb MIDI APIの実装状況について簡単にまとめておきたいと思います。会社の方針とかそういう話ではなく、担当者として客観的事実の報告です。

ChromeではMac版のみで実装を進めてきました。最初の実装という事で、実装から仕様へのフィードバック、上位仕様とのすり合わせなどで仕様変更が伴います。全OSの対応を同時に進めると、イテレーションのコストが大きくなってしまうためです。

Chrome 30からchrome://flags#enable-web-midiが登場しました。この時点ではMacで入力ポートのみ動作していました。ただし、SysExメッセージ入力にバグがあり、このバグはChrome 32まで残っています。

Chrome 31で入出力ひと通りの機能が揃い、SysExメッセージ利用許可を求めるUI、設定などが入りました。Chrome的に言うとContent Settingsという仕組みの中に統合しています。

Chrome 32ではIAC Driver経由で外部ソフトウェア（音源）と連携できるようになりました。

Chrome 33からはいよいよWindows版でも動くようになりました。Timestampが異常値を返すバグがあるのですが、基本的な機能は動作するはずです。TimestampのバグはChrome 34で修正されています。

さて、ここまではリリース済み、またはブランチカット済みのバージョンの話でした。ここから先は予定の話になるので確約はできないことをご了承ください。現在、開発中の最新バージョンはChrome 34です。以下はChrome 34に向けて実装を始めている項目です。

• Promise
• 今まではthen()しか使えない限定的なWeb MIDI専用のPromiseもどきを返していました。Chrome 32から本物のPromiseが有効になるため、本物のPromiseに移行します。
• Chrome OS / Linux
• Android
• いずれのプラットフォームでもラフな実装を終え、レビューを回している段階です。

これ以外に直近で計画しているのは

• 入出力デバイスを列挙するAPIが変更になっており、その対応
• デバイスの動的な追加・削除のイベント通知

ですが、詳細なスケジュールについては調整中です。対応プラットフォームの拡大も含め、いずれもデバイスの動的な追加・削除を実現するため仕組みを、すべてのプラットフォーム上で無理なく実装するための取り組みです。

という事で、仕様も実装も完全に安定したわけではありませんが、興味ある方はぜひ使ってみてください。また、不審な点に気づいた場合には私までご一報ください。

という事で、良いお年を！

vmware-mount

vmwareの中で動かしている仮想マシン、うっかり/etc/hostsを消してしまって。
特にカスタマイズもしてなかったのでリポジトリ管理もしてないファイルだったんだけど、元通りじゃないと気持ち悪いので、仮想ディスクvmdkのバックアップから発掘しようかな、と思って作業した時のメモ。
バックアップから別の仮想マシンを起動すれば簡単なんだけど、面倒だからvmdkを直接マウントしようとして、結論から言えばもっと面倒だった、という話。

まず、普通に生活していればvmware-mountが便利に使えたはず。だったんだけど、中で動かしていた仮想マシンがNetBSDだったので、そのままだとうまく動いてくれなかった。ので、vmware-mountが中でやってると思われるmountコマンドを引数を適切に指定して呼ぶ必要がありました。

% sudo mount disk.vmdk /mnt/tmp -t ufs
-o ro,loop=/dev/loop1,offset=2719232,ufstype=44bsd

最近じゃ違うのかもしれないけど、僕は昔からNetBSDでは奥ゆかしきufsを使い続けてるので-t ufsをつけて、-oの方にはufstype=44bsdを指定。ufstypeを指定しないとoldが選ばれて、マウントはできるけど一切読めない状態になるので注意。あとufsはread onlyでしかサポートされてないのでroも必要。ここまではmanを読めばすぐわかる話。で、問題なのはoffsetの探し方。

ここで指定するoffsetはvmdkのヘッダサイズと読みたいパーティションの位置を足したもの。とりあえずvmdkのヘッダサイズがよくわからなかったので適当に推測。以下、仮想マシンの中での作業。

% disklabel /dev/wd0
(snip)
#        size    offset     fstype [fsize bsize cpg/sgs]
 a:   2097900        63     4.2BSD   2048 16384 21880  # (Cyl.      0*-   2220*)
 b:   1048950   2097963       swap                     # (Cyl.   2220*-   3330*)
 c:  41942977        63     unused      0     0        # (Cyl.      0*-  44384*)
 d:  41943040         0     unused      0     0        # (Cyl.      0 -  44384*)
(snip)

って感じの状態なので、とりあえずディスクの先頭に何が書いてあるか確認。

% hexdump -C /dev/wd0d | head -n 20

って感じで見れば、先頭から0x100付近にNetBSDのMBRのエラーメッセージが見えるので、これをキーにディスクイメージ側を探索。以下はホストでの作業。

% hexdump -C disk.vmdk|less

"BSD"をキーに探せばすぐに該当箇所が見つかる。僕の場合0x290120付近。ここからちょっと遡ると0x290000がディスクの先頭と一致することがわかる。

ここまでわかれば簡単。読みたいパーティションはoffset 63からなので

% expr 63 \* 512 + `printf %d 0x290000`
2719232

ふぅ。ちなみに最初の段階でvmdkが複数のファイルに別れてたりする場合はvmware-vdiskmanagerを使って単一ファイルのフォーマットに変換してから作業する必要があるはず。