오랜만에 EFR32로 개발할 일이 생겼다. 그때는 무선 RF 통신만 했었는데, 이번엔 BLE SPP 통신을 기반으로 하는 개발 건 이었다.
CPU 파트는 조금 다르지만 해봤던 제품이었고 BLE도 Apollo 칩으로 해 본 적이 있으니 어렵지 않을꺼라 했는데,
조금 헷갈렸던 부분이 있어서 정리할 겸 글을 쓴다.
1. 특성별 UUID 는 다 달라야 한가?
BLE로 송수신을 하려면 UUID가 필요하다. 서비스 UUID와 characteristic UUID가 있으면 서비스 등록 및 통신이 가능한다. 보통 Write, Notification 2가지로 송수신을 하는데, 보통 다들 다들 다른 UUID를 사용한다. Nordic도 그랬고 Apollo도 그랬다. 당연히 EFR32도 그렇겠지 했는데...
요 2가지만 있는게 아닌가? 처음에는 UUID가 소스상에 어디 숨어 있나? 했지만 아무리 찾아봐도 다른 UUID는 보이지 않았다.
우선은 여기서는 같은 UUID로 해도 되는구나 라도 이해했다.
2. Read 와 Notify의 차이
처음에는 Read도 있어야 하고 Notify도 있어야 한다고 생각했는데 아래의 사진을 보고 다른것임을 알게 되었다.
Read 동작은 핸드 쉐이킹 같이 Read를 하기 위한 여러 동작이 있지만 Notification은 GATT server가 client에 바로 알림을 던지는 동작이다. (TCP와 UDP의 차이와 비슷) 즉 같은 Read 동작인데 확인을 받느냐 안받느냐의 차이이다. 그래서 Read 동작은 굳이 없어도 되었다.
그러면 다른 질문이 나왔다. Notify 을 하기 위한 CCCD (Client Characteristic Configuration Descriptor) 의 UUID는 뭐지? Write에 쓰는 걸 그대로 스면 되나?
(사실 Client Characteristic Configuration Descriptor의 UUID는 고정값이지만 이때만 해도 기기별로 다른 값을 쓰는 줄 암.)
그래서 Write UUID를 CCCD에 넣고 enableTXNotification를 실행하니 코드에서 descriptor이 null 값이 나와 에러가 발생했다.
저걸 안하면 수신을 못받는데 어쩌지... 하고 "getDescriptor null" 검색어로 검색하니, 폰에서 BluetoothGattDescriptor를
지원 못하는 것일수도 있으니 Descriptor 리스트를 검색하는 방법을 알려주는 코드를 확인했다.
위 코드로 TxChar로 CCCD가능한 UUID를 조회해보니 00002902-0000-1000-8000-00805f9b34fb 가
떡하니 조회되었다. 여기서 눈치를 챘다. "아 이 값은 고정이구나..."
3. 안드로이드와 BLE SPP 테스트
WriteDescriptor를 정상 실행하고 디바이스와 통신을 하니 정상적으로 데이터를 송수신 하는것을
확인했다.
'개발이야기' 카테고리의 다른 글
| [ESP32] 블루투스 스피커와 버퍼링 (0) | 2022.10.14 |
|---|---|
| 펌웨어로 2개의 wav 오디오 믹싱하기 (0) | 2022.03.21 |
| PIC32 MPLAB X 개발 후기 (0) | 2022.03.13 |
| MP3 현재 재생시간 계산하기 (플레이타임) (0) | 2022.01.24 |
| MP3 총 재생 시간 계산하기 (0) | 2022.01.24 |
