2018年12月25日火曜日

enebularはNode-REDの一発デプロイツールとして超便利なのでは

先日ウフルのenebular meetupに参加するので、Node-REDを常時動かすためにherokuにデプロイしてみました。公開されている手順でherokuにNode-REDの環境がサクサクと立ち上がりました。このときに「enebular=IoTをよしなにするツールだと思っていたけど、Node-REDを即デプロイできるツールとしても便利なのでは?」と思いました。

Webhookを受け取る環境をサクッと立ち上げられる

過去にWebhookを受け取りたい場面があり、その都度サーバーの設定をするのは面倒だなと思っていました。その当時はngrokを使いましたが、enebularでWebhookを受け取るフローをつくりそれをherokuにデプロイしておけば、ngrokのようにローカルでプロセスを動かしている必要はないなと。ちょっと試してみました。

入力にHTTP Inputを置き、まずはそのままHTTPの出力につなぎます。こちらの3項にあった「HTTPの入力は本当に入力しかしないので、HTTPの出力につながないとWebhookの発行側がエラーになる」という内容を参考にしています。入力のHTTPを分岐し、とりあえずデバッグで中身を全部出力するようにします。

Webhook発行側に登録するURLは、herokuデプロイ前なら「デプロイボタンの左にある(i)のボタンで表示されるドメイン+HTTP Inputに設定したパス」が使えます。これで動作確認ができれば、そのまま先ほどの手順に従ってHerokuにデプロイしてWebhookを常時待機できるようになります。

2018年12月16日日曜日

なぜnanoloopのカートリッジは基板だけで差し込めるのか

ゲームボーイ用カートリッジのnanoloopは、カートリッジ本体が基板のみで、いわゆるカートリッジらしい樹脂筐体を含みません。nanoloop monoはさらに、カートリッジの端子幅だけしか本体サイズがありません。なぜこれで差し込みに問題ないのか、差し込み時の位置合わせは正確に行えるのかが疑問でした。この理由がわかれば、今自分で作っている基板も他のカートリッジから筐体を借りなくて済むので、調べてみました。

厚みについて

カートリッジと本体側ソケットそれぞれの端子が接していれば動作します。一般的なカートリッジの端子部の厚みを基板に合わせれば動作すると考えました。

2.1mmなので、厚みがおおよそ2.0mmあればおそらく大丈夫だろうと思います。

差し込みについて

厚みがわかったので、差し込み時の位置合わせやガイドについて調べました。カートリッジのふたを開けた状態で差す様子をみると、この状態では筐体(矢印で示している箇所)が位置を合わせているように見えます。

ここで、厚みをおおよそ2.0mmに調整したカートリッジ基板を差し込んでみます。

正しい位置に収まり、カートリッジも正常に動作しました。このときにわかったのですが、位置合わせのガイドとなっているのはカートリッジ筐体ではなく、本体ソケットの突起でした。次の写真は差し込み口を上から見た図です。

正しい厚み・正しい幅の板が上から降りてくるとき、ソケットのガイドに従って差し込まれるので、端子同士がまっすぐ接触するようになっています。

結論

基板厚み2.0mmでカートリッジ基板を製造すれば、筐体なしでもカートリッジは機能する。

機能検証(とカートリッジをもとのゲームに戻す)のために、上で差した基板の厚みを2.0mmにしたものを製造中です。届き次第試します。

2018年12月14日金曜日

AE-TYBLE16にBLE-MIDIを実装するための途中経過

秋月電子通商のBLEモジュール AE-TYBLE16 は、SWDの書き込み端子が出ているのでファームウェアを書き換えられます。NordicのnRF5 SDKのサンプルコードをいろいろ使うだけでも十分できるのですが、興味のあった MIDI over BLE はサンプルがなかったので実装に挑戦しました。アドベントカレンダーに投稿するのに間に合わなかったので、今回は途中経過を記載します。

Nordic nRF5 SDKでサービスの実装が大変

仕様をみると、次のように実装することとあります。

The following service and characteristic are defined:

  • MIDI Service (UUID: 03B80E5A-EDE8-4B33-A751-6CE34EC4C700)
  • MIDI Data I/O Characteristic (UUID: 7772E5DB-3868-4112-A1A9-F2669D106BF3)
    • write (encryption recommended, write without response is required)
    • read (encryption recommended, respond with no payload)
    • notify (encryption recommended)

「このUUIDのサービスとキャラクタリスティックを実装すればいいんだろ」と思っていましたが、この時点でまず大変でした。

今回のようにサービスとキャラクタリスティックでUUIDが異なっていると、「フルサイズのUUIDをいくつも使うぞ」という設定が必要でした。フォーラムのやり方でそれっぽいのを見つけて実装しデバッグすると、ログにメッセージが出ます。「ユーザーが使うメモリの割当を次のように変えろ」というメッセージが出るので、それに従ってリンカスクリプトを修正します。これでやっと電波が飛ぶようになります。

仕様の「encryption recommended」にひっかかる

電波が飛ぶようになったのですが、MacはMIDIポートとして設定してくれません。おそらく仕様の「encryption recommended」が欠けているのが原因のようで、Mac側としてはマウスやキーボードのようにペアリング動作を完了できないとMIDIポートとして設定されないようです。もともとベースにしていたサンプルコードがペアリング処理のないものだったので、ペアリング処理のあるサンプルに移植するのもめんどうだなとなって放置気味になってきたところで今日に至っています。

まとめ

すごく手間なので、Arduino環境でつくるほうに乗り換えようかちょっと考えています。でもペアリングの動きとか後ろ側の動きについてかなり勉強になった感じはするので、なしではないです。