소개

Swift는 별로 관계 없지만. mm 힘들기 때문에 손을 내밀어 보면, 역시 Cocoa는 손이 걸리는 아이였다고 한다… … 익숙해지면 더 잘 쓸 수 있을까. 그건 그렇고, 작년 말에 여러가지 조사하고 있던 Koshian/Konashi에 대해서 휴가가 끝나기 전에 정리해 두자… … 라고, 그런 것입니다.

코나이 터프

Koshian과 Konashi에 대해서는 과거 기사 를 참고해 주세요. 요점은 1,000엔으로 입수할 수 있는 BLE 모듈로, Bluetooth 경유로 펌웨어의 재기록을 할 수 있게 되어 있습니다. 하지만, 툴 등도 특별히 제공되지 않고, 사양도 수수께끼 로 잘 다루는데 고전하고 있었다, 라고 하는 것이 전회까지의 개요.

이번 사양과 버그 같은 거동이 밝혀져 어떻게든 워크 어라운드 포함으로 Windows와 OS X에서 팜을 다시 쓰는 데 성공했기 때문에 모처럼의 섬세한 앱으로 정리해 보았습니다.

이런

도돈! 무려 GUI.
CUI로 비동기라든지 신경지에서 싫었을 뿐입니다만. 우선 Broadcom사의 툴 정도의 일은 할 수 있습니다.

세트 GitHub에서 공개 합니다.

힘든 점

서비스 취득

분명히 Konasi OTAFU의 서비스 인 Characteristics는 모두 팜을 작성할 때 결정하는 임의의 UUID를 사용하는 것 같습니다. 그래서 찾는 것이 귀찮다. 우선 캐릭터리스틱스를 2개 가지는 서비스를 찾아 notification 서포트하는 쪽이 Control Point, 다른 한쪽이 Data 같은 잡한 판정하고 있습니다.

Notification을 사용할 수 없음

Konashi의 버그로 Konashi OTAFU 측의 Control Point로부터의 Notification이 Broadcom OTAFU 측의 Control Point로부터 도착합니다(약간). 클라이언트 구성하지 않은 상태로 도착하기 때문에 OS X이 올바르게 알림을 전달하지 않습니다. Client Configuration을 시도해도 Broadcom OTAFU측의 서비스가 할리보테이므로 Configuration하려고 하면 오류가 반환됩니다.

라는 상당히 괴로운 문제. 도대체 iOS판의 Konash.js가 어떤 구조로 움직이고 있는지 매우 신경이 쓰이는 곳입니다만. 우선 통지를 체크하지 않고, 데이터의 흘림만 조심해 건간 써 가면 마지막에 CRC32가 일치한 곳에서 팜이 갱신되는 모양. 지금까지 수십 번이나 써 왔지만 CRC 불일치는 한 번도 일어나지 않았고, 일어나면 일어났고 갱신되지 않을 뿐이므로, 실용상은 그다지 문제 없을까,라고 생각합니다.

덧붙여서 Windows라고 콜백 등록해 두면 Notification의 설정하지 않아도 통지가 배송되는 것 같아, 제대로 결과 체크 첨부로 움직였습니다. 거동은 기분 나쁘지만.

결론

우선 BLE에 대해 이해 깊게하고 싶다, 라고 생각해 입수한 Koshian. 덕분에 BLE에는 많은 친숙함이있었습니다. 하지만 쓸데없이 Win/Mac/Android의 Bluetooth API에 자세하게 되어 버렸습니다. 거구의 끝에는 Swift까지… 사실은 웹 블루투스를 사용하여 웹에서 팜을 다시 쓰고 싶다고 생각했을 뿐이었습니다. 취미이기 때문에 할 수 있는 궁극의 둘레.