はじめに
Swiftはあんまり関係ないですけど。mm辛いので手を出してみたら、やっぱりCocoaは手のかかる子だったという……慣れればもっとうまく書けるのだろうか。それはさておき、昨年末に色々と調査してたKoshian/Konashiについて休暇が終わる前にまとめておこう……と、そういうわけです。
Konashi OTAFU
KoshianとKonashiについては過去の記事を参考にして下さい。要は1,000円で入手できるBLEモジュールで、Bluetooth経由でファームウェアの書き換えができる事になってます。が、ツール等も特に提供されておらず、仕様も謎で使いこなすのに苦戦していた、というのが前回までのあらすじ。
今回、仕様とバグっぽい挙動が明らかになり、なんとかワークアラウンド込みでWindowsやOS Xからファームを書き換える事に成功したため、せっかくなのできちっとしたアプリとしてまとめてみました。
こんなの
どどーん！なんとGUI。
CUIで非同期とか新境地で嫌だっただけなんですが。とりあえずBroadcom社のツール程度の事はできます。
一式GitHubにて公開してます。
苦労した点
サービスの取得
どうやらKonashi OTAFUのサービス、キャラクタリスティクスはともにファーム書き込み時に決定するランダムなUUIDを用いているようです。なので探すのが面倒。とりあえずキャラクタリスティクスを2つ持つサービスを探してnotificationサポートしてるほうがControl Point、もう一方がDataみたいな雑な判定してます。
Notificationが取れない
KonashiのバグでKonashi OTAFU側のControl PointからのNotificationが、Broadcom OTAFU側のControl Pointから届きます（ややこしい）。Client Configurationしてない状態で届くため、OS Xが正しく通知を配送してくれません。Client Configurationをしようと思ってもBroadcom OTAFU側のサービスがハリボテなので、Configurationしようとするとエラーが返ってきます。
という、結構悩ましい問題。いったいiOS版のKonashi.jsがどんな仕組みで動いているのか非常に気になるところですが。とりあえず通知をチェックせずに、データの取りこぼしだけ気をつけてガンガン書き込んでいけば最後にCRC32が一致したところでファームが更新される模様。今まで何十回も書いてきたけどCRC不一致は一度も起きてないし、起きたら起きたで更新されないだけなので、実用上はあまり問題ないかな、と思います。
ちなみにWindowsだとコールバック登録しておけばNotificationの設定しなくても通知が配送されるみたいで、きちんと結果チェック付きで動きました。挙動は気持ち悪いですが。
おわりに
とりあえずBLEについて理解深めたいなぁ、と思って入手したKoshian。おかげでBLEにはだいぶ親しみが持てました。が、無駄にWin/Mac/AndroidのBluetooth APIに詳しくなってしまいました。挙句の果てにはSwiftまで……。本当はWeb Bluetooth使ってWebからファームを書き換えたいなぁ、とか思ってただけだったんですけどね。趣味だから出来る究極の遠回り。