Bluetooth 개요¶

개요¶

이 가이드는 SF32 제품의 Bluetooth 연결을 계획하고 구현하는 방법을 설명합니다. BLE와 듀얼 모드 Bluetooth의 선택, GATT 서비스 설계, 프로파일 선택, 연결 파라미터 튜닝, 페어링과 보안, LE Audio, 그래픽/오디오/센서 워크로드와의 공존처럼 실제 설계를 좌우하는 실용적인 결정에 초점을 맞춥니다.

SF32는 애플리케이션 처리와 시간이 중요한 Bluetooth 컨트롤러 작업을 분리합니다. 일반적으로 애플리케이션 프로세서가 제품 로직과 UI를 처리하고, Bluetooth 또는 저전력 프로세서가 링크 레이어 타이밍과 라디오 스케줄링을 처리합니다. 호스트 스택과 GATT 서비스의 배치는 디바이스와 SDK 구성에 따라 달라지므로, 모든 서비스가 애플리케이션 프로세서에서 실행된다고 가정하지 마십시오. 선택한 예제의 코어 구성과 코어 간 통신 경로를 확인하십시오.

기반이 되는 서브시스템에 대한 자세한 설명은 Bluetooth 프로세서를 참조하십시오.

제품의 무선 동작을 설계할 때 필요한 역할과 프로파일, 사용자가 기대하는 응답성과 배터리 수명, 휴대폰·라디오·애플리케이션 펌웨어 간 책임 분담을 정하려면 이 페이지를 참고하십시오. 이 페이지는 설계 가이드이며, 대상 휴대폰과 액세서리에서 상호 운용성을 검증하는 절차를 대신하지 않습니다.

제품의 연결 요구 사항 정의¶

GATT 코드를 작성하기 전에, 제품에 실제로 필요한 것이 무엇인지 확정하십시오.

• BLE 전용인지, 듀얼 모드 Bluetooth(BT Classic + BLE)인지.
• Bluetooth 오디오는 Classic(A2DP/AVRCP/HFP)인지 LE Audio인지.
• 일반적인 연결 간격, 지연 시간, 처리량 요구 사항.
• 애플리케이션 프로세서가 얼마나 자주 깨어나야 하고 얼마나 슬립 상태를 유지하는지.
• 제품이 기존 휴대폰 측 서비스(알림, 미디어 제어, 통화)와 상호 운용되어야 하는지, 커스텀 컴패니언 앱과만 연동하면 되는지.
• 예상 통신 거리, 안테나/케이스 제약, RF 인증 목표.
• 펌웨어 업데이트를 Bluetooth로 전달할지 여부.

이러한 답은 디바이스 선택, 시작점으로 삼을 SDK 예제, 메인 CPU가 슬립 상태를 유지할 수 있는 시간을 결정합니다.

BLE, Classic, 듀얼 모드 선택¶

Bluetooth Low Energy (BLE)¶

BLE는 대부분의 연결형 웨어러블과 센서에 적합한 기본 선택입니다. 간헐적이고 이벤트 중심의 트래픽, 낮은 평균 전력, 폭넓은 휴대폰 OS 지원이 장점입니다. 일반적인 BLE 우선 제품으로는 피트니스 밴드, 건강 센서, 비콘, 컴패니언 앱에 대한 설정/제어 링크가 있습니다.

Classic Bluetooth와 듀얼 모드¶

제품에 오디오 스트리밍(A2DP/AVRCP), 핸즈프리 통화(HFP), 시리얼 방식 데이터 링크(SPP) 또는 기존 Classic 프로파일과의 호환성이 필요하다면 Classic Bluetooth를 추가하십시오. 듀얼 모드 설계는 BLE 전용 설계보다 라디오 스케줄링과 공존 측면에서 부담이 크며, 전용 Bluetooth 프로세서는 바로 이러한 워크로드를 시스템의 나머지 부분으로부터 분리하기 위해 만들어졌습니다.

모든 SF32 제품군이 듀얼 모드 Bluetooth를 제공하는 것은 아닙니다. 부품 번호를 확정하기 전에 Bluetooth 프로세서의 디바이스 표를 확인하십시오.

적합한 SF32 디바이스 선택¶

클럭 속도만이 아니라 제품에 필요한 연결 기능 세트를 기준으로 디바이스를 선택하십시오.

제품에 연결 외의 기능이 필요하다면, 그래픽 개요와 AI 가속기 페이지의 디스플레이, 메모리, AI 요구 사항과 대조해 확인하십시오.

GATT 서비스와 Sibles 프레임워크¶

SiFli-SDK는 GATT 서비스를 등록하고 사용하기 위한 Sibles를 제공합니다. GATT는 서비스/특성(characteristic) 계층 구조와 속성 접근을 정의하고, GAP는 디바이스 검색, 광고, 연결 수립 및 관련 역할을 정의합니다. 이 둘은 서로 보완하는 책임이며, GAP 위에 GATT 레이어가 구축되는 관계가 아닙니다. GATT 데이터베이스를 처음부터 만들지 말고 가장 가까운 SDK 예제에서 시작하십시오.

SDK는 다음을 비롯한 여러 표준 및 벤더 프로파일의 예제 구현을 제공합니다.

가장 가까운 예제의 등록, 이벤트 처리, 보안 검사를 재사용하십시오. 표준 프로파일을 구현할 때는 해당 프로파일의 UUID와 동작을 그대로 유지하고, 제품의 데이터 모델이 요구하는 경우에는 커스텀 서비스와 UUID를 사용하십시오. 목표는 검증된 기반 코드를 재사용하는 것이지, 모든 컴패니언 앱 프로토콜을 표준 프로파일에 억지로 맞추는 것이 아닙니다.

Classic Bluetooth 프로파일¶

듀얼 모드 제품을 위해 SDK는 다음 프로파일의 예제 구현을 제공합니다.

• SPP — 단순한 양방향 시리얼 데이터. 레거시 또는 비 GATT 컴패니언 앱에 유용합니다.
• A2DP (싱크 및 소스) — Bluetooth 오디오 스트리밍.
• AVRCP — A2DP 링크와 함께 사용하는 재생 제어(재생/일시 정지/트랙/볼륨).
• HFP — 핸즈프리 통화. HF(핸즈프리 디바이스)와 AG(오디오 게이트웨이) 역할이 있습니다. 문서화된 HFP 예제는 HF를 구현합니다. AG 지원은 선택한 SDK 구성에서 별도로 확인하십시오.
• PAN — Bluetooth를 통한 네트워크. PAN 기반 OTA 전달 예제를 포함합니다.

오디오 및 레거시 프로파일은 일반 BLE 링크보다 타이밍과 처리량 요구 사항이 엄격한 경향이 있으므로, 공존 테스트 시간을 그에 맞게 확보하십시오(아래 공존 참조).

Bluetooth 오디오와 LE Audio¶

오디오 방식에 따라 두 가지 별개의 경로가 있습니다.

• Classic Bluetooth 오디오 — 스트리밍에는 A2DP, 전송 제어에는 AVRCP, 통화에는 HFP를 사용합니다. 검증된 방식이며 기존 휴대폰 및 헤드셋과의 호환성이 넓습니다.
• LE Audio — Basic Audio Profile (BAP)은 유니캐스트와 브로드캐스트 LE Audio 스트림을 모두 관리하는 절차를 정의합니다. SDK에는 브로드캐스트 소스 및 싱크 예제가 포함되어 있으며, 전환 기간 동안 두 방식을 모두 연결해야 하는 제품을 위해 브로드캐스트 소스와 Classic BT를 함께 사용하는 혼합 예제도 있습니다.

어느 경로든 안정적인 타이밍, 버퍼링, 신뢰할 수 있는 샘플 이동이 필요하며, 보통 DMA를 사용합니다. 지원되는 Bluetooth 오디오 역할과 SDK 구성이 제품 요구 사항을 충족한다면 SF32LB52x/56x/58x를 선택하십시오. SF32LB55x는 BLE 전용이므로 Classic Bluetooth 오디오를 제공할 수 없습니다. BLE 전용이라고 해서 디바이스에 로컬 오디오 기능이 없다는 뜻은 아닙니다. DMA와 버퍼링은 오디오 개요와 Bluetooth 프로세서를 참조하십시오.

Sibles 서비스 구현 패턴¶

유지 보수하기 쉬운 BLE 서비스는 보통 다음 패턴을 따릅니다.

이렇게 하면 서비스 정의, 휴대폰 앱과의 계약, 보안 정책, 전력 동작이 서로 일치하도록 유지됩니다.

광고 및 연결 파라미터¶

연결 및 광고 파라미터는 지연 시간, 처리량, 전력 사이의 균형을 조절하는 주된 수단입니다.

이 연결 파라미터는 BLE ACL 링크를 설명하는 것이며, 모든 Bluetooth 오디오 전송에 적용되지는 않습니다. Classic 오디오는 BR/EDR 전송 타이밍을 사용하고, LE Audio는 CIS 또는 BIS 아이소크로너스 타이밍을 사용합니다. BLE GATT 연결 간격을 어느 오디오 경로에도 그대로 적용하지 마십시오. Bluetooth SIG LE 입문서가 이러한 서로 다른 전송 방식을 설명합니다.

비콘 방식 제품(iBeacon 호환 광고)과 주기적 광고 용도(대규모 또는 단방향 브로드캐스트를 위한 주기적 광고 동기화 포함)는 전체 GATT 연결 없이 전용 SDK 예제로 지원됩니다.

연결 간격, 페리퍼럴 지연 시간, 감독 타임아웃(supervision timeout)은 컨트롤러와 상대 기기가 모두 받아들이는 유효한 조합이어야 합니다. 업데이트를 요청했다고 해서 그것이 적용되었다는 증거는 아닙니다. 협상된 값을 로그로 남기고, 거부된 업데이트와 유휴 설정으로의 복귀를 포함하여 실제 휴대폰 또는 액세서리에서 테스트하십시오.

제품 단계별 파라미터 프리셋¶

타협한 설정 하나를 쓰지 말고 단계마다 다른 Bluetooth 파라미터를 사용하십시오.

단계 간 전환을 문서화하십시오. "무작위"로 보이는 Bluetooth 전력 또는 지연 시간 버그의 상당수는 실제로는 상태 변경 후에 제품이 잘못된 단계에 머물러 있는 경우입니다.

페어링, 본딩, 보안¶

BLE는 페어링 없이도 연결을 수립할 수 있습니다. 페어링은 보안 키를 수립하고, 본딩은 이후 연결을 위해 그 키를 유지합니다. 모든 제품에 기본적으로 본딩을 요구하지 말고, 어떤 서비스에 암호화, 인증, 영구 본드가 필요한지 결정하십시오.

• 제품에 Just Works, 패스키 입력, 숫자 비교 페어링 중 무엇이 필요한지 일찍 결정하십시오. Just Works는 중간자 공격(MITM) 방어를 제공하지 않습니다. 암호화된 연결이 반드시 인증된 연결인 것은 아닙니다. 연결 수립 방식은 양쪽 디바이스의 I/O 기능과 제품의 보안 요구 사항에 맞추십시오. Bluetooth GAP 보안 요구 사항을 참조하십시오.
• ANCS의 경우 휴대폰 측 승인은 링크 암호화 및 본딩과 별개이므로, 거부되거나 철회된 권한을 처리하십시오. ANCS와 AMS는 모두 연결 중에 나타나거나 사라질 수 있습니다. 페어링하면 항상 사용할 수 있다고 가정하지 말고 Service Changed를 모니터링하여 서비스를 다시 검색하십시오.
• 재부팅과 OTA 업데이트 후에도 본드가 유지되도록, SDK가 권장하는 저장소/파티션 방식에 따라 본딩 정보를 저장하십시오.
• 제품 UI와 휴대폰 양쪽 모두에서 재페어링 및 "디바이스 삭제(forget device)" 흐름을 정의하십시오.
• 보안 정책(암호화 요구 사항, I/O 기능, 키 크기)을 검토 없이 기본값으로 두지 말고 제품 결정으로 다루십시오.

멀티 커넥션과 역할¶

SDK는 센트럴과 페리퍼럴 역할의 동시 수행과 다중 동시 연결을 시연합니다. 제품은 BLE 페리퍼럴로서 휴대폰에 연결하는 동시에 센서에 대해서는 센트럴로 동작하거나, 여러 컴패니언 연결을 처리할 수 있습니다. 선택한 디바이스, 컨트롤러 펌웨어, SDK 구성, 버퍼, 결합된 라디오 워크로드에 대해 역할 조합과 연결 한도를 검증하십시오. 예제가 제품군 전체의 용량을 보장하는 것은 아닙니다.

제품이 링크를 처리량 한계에 가깝게 밀어붙여야 한다면, 한계가 애플리케이션 코드에 있다고 가정하기 전에 SDK의 처리량(throughput) 예제를 시작 기준선으로 사용하십시오.

Bluetooth를 통한 OTA 펌웨어 업데이트¶

일반적으로 두 가지 전달 경로가 있습니다.

• 페리퍼럴 연결과 통합된 BLE 기반 DFU 방식 업데이트(OTA가 일반 페리퍼럴 GATT 역할에 연결되는 방식은 peripheral_with_ota 예제를 참조).
• PAN OTA: 이미 데이터용으로 PAN을 사용하는 듀얼 모드 제품에서 Bluetooth PAN 네트워크 링크를 통해 펌웨어를 전달합니다.

어느 경로든 릴리스 전에 파티션 레이아웃, 장애 복구, 롤백을 계획하고 테스트하십시오. BLE OTA의 경우 전송 중에는 더 짧은 연결 간격과 0의 페리퍼럴 지연 시간을 검토한 다음, 일반적인 절전 설정을 복원하십시오. PAN OTA는 Classic Bluetooth 전송을 사용하므로, BLE 연결 파라미터를 적용하지 말고 처리량과 복구를 별도로 튜닝하십시오.

다른 워크로드와의 공존¶

SF32의 Bluetooth는 단독으로 동작하는 경우가 드뭅니다. 그래픽, 오디오, 센서, 때로는 외부 Wi-Fi와 시스템을 공유합니다. 전용 Bluetooth 프로세서가 링크 타이밍 위험의 대부분을 흡수하지만, 애플리케이션 수준의 공존에는 여전히 주의가 필요합니다.

• 애플리케이션 프로세서에서 임계 구역이 길거나 인터럽트가 비활성화되면 호스트 측 Bluetooth 처리가 지연될 수 있습니다.
• 디스플레이와 PSRAM 트래픽은 Bluetooth 오디오 버퍼와 메모리 대역폭을 놓고 경쟁합니다.
• 애플리케이션 프로세서를 너무 자주 깨우는 센서 인터럽트는, Bluetooth 프로세서가 링크를 처리하는 동안 애플리케이션 프로세서를 슬립 상태로 두어 얻는 에너지 절감을 무너뜨릴 수 있습니다.

시스템 수준의 관점은 다른 워크로드와의 공존을 참조하고, 각 서브시스템을 따로 테스트하지 말고 현실적인 최악의 조합(예: 디스플레이 활성 + 오디오 + 바쁜 BLE 링크)에서 테스트하십시오.

RF, 상호 운용성, 인증 준비¶

Bluetooth 펌웨어는 RF 하드웨어와 같은 엄밀함으로 검증해야 합니다.

• 개발용 휴대폰 하나만이 아니라 여러 휴대폰 제조사, OS 버전, 재연결 시나리오로 테스트하십시오.
• 오래된 본드, 휴대폰 측 디바이스 삭제, 디바이스 측 공장 초기화, OTA 이후의 동작을 확인하십시오.
• 배터리, 디스플레이, 충전기, 사용자가 착용하거나 쥔 위치를 포함하여 최종 케이스에서 통신 거리와 패킷 안정성을 검증하십시오.
• 양산 및 인증 지원을 위해 RF 테스트 모드, 캘리브레이션 접근, 로그를 사용할 수 있게 유지하십시오.
• 프로파일 비중이 큰 제품은 자격 인증/프로파일 테스트 시간을 확보하십시오. 데모 앱을 통과했다고 해서 상호 운용 가능하다는 뜻은 아닙니다.

Bluetooth 문제 디버깅¶

흔한 실수¶

• 제품에 이미 Classic 오디오가 필요한 시점에 BLE 전용 하드웨어를 선택함.
• 불필요하게 서비스 기반 코드를 다시 구현하거나, 맞지 않는 표준 프로파일에 커스텀 데이터 모델을 억지로 끼워 맞춤.
• 대부분의 시간을 유휴 상태로 보내는 링크에서 페리퍼럴 지연 시간을 0으로 둠.
• 디스플레이/오디오/Bluetooth를 처음 결합하는 후반 통합 단계까지 공존 테스트를 미룸.
• 페어링/본딩을 설계된 UX 흐름이 아니라 뒤늦은 고려 사항으로 취급함.
• 안테나, 매칭 회로, 크리스털 정확도 같은 RF 브링업 검증을 최종 PCB 리비전까지 건너뜀.
• 펌웨어 튜닝만으로 열악한 RF 레이아웃을 보완할 수 있다고 가정함.

브링업 체크리스트¶

• BLE 전용인지 듀얼 모드인지 요구 사항을 확정하고 그에 맞는 SF32 디바이스를 선택합니다.
• 제품의 사용 사례에 가장 가까운 SDK 프로파일/서비스 예제를 파악합니다.
• 검색, 활성 사용, 유휴 상태별 광고 및 연결 파라미터 목표를 정의합니다.
• 페어링, 본딩, "디바이스 삭제" UX를 설계합니다.
• 실제 하드웨어에서 RF 레이아웃, 안테나 매칭, 크리스털 정확도를 검증합니다.
• 선택한 프로파일(GATT 서비스, A2DP/AVRCP/HFP 또는 LE Audio 브로드캐스트)을 실제 휴대폰 또는 레퍼런스 호스트로 브링업합니다.
• 현실적인 결합 부하에서 디스플레이, 오디오, 센서 워크로드와의 공존을 테스트합니다.
• 펌웨어 업데이트를 Bluetooth로 출하할 경우 OTA 전달 경로를 계획하고 테스트합니다.
• 연결 유휴 전력을 프로파일링하고 애플리케이션 프로세서가 예상대로 슬립하는지 확인합니다.

핵심 요약¶

• 먼저 BLE 전용인지 듀얼 모드 Bluetooth인지 결정하십시오. 이것이 디바이스 선택과 따르게 될 SDK 경로의 대부분을 좌우합니다.
• 처음부터 만들지 말고 SDK에 이미 있는 GATT 서비스와 Classic 프로파일 예제(HRPC, DISS, CTS, HID, ANCS/AMS, SPP, A2DP, AVRCP, HFP, PAN)에서 시작하십시오.
• 연결 간격, 페리퍼럴 지연 시간, 감독 타임아웃, TX 전력은 지연 시간, 처리량, 전력의 균형을 맞추는 주된 수단입니다.
• Bluetooth 오디오는 선택한 디바이스와 SDK 구성에서 필요한 Classic 또는 LE Audio 역할을 확인한 다음 버퍼링과 공존을 설계하고 테스트하십시오. 제품군 전체에 대한 기능 주장은 이 확인을 대신할 수 없습니다.
• Bluetooth는 시스템 수준의 문제입니다. RF 레이아웃, 클럭, 페어링 UX, 그래픽/오디오/센서와의 공존은 GATT 코드 자체만큼 중요합니다.

현재 Classic Bluetooth, BLE, LE Audio SDK 프로젝트를 작업 중심으로 정리한 지도는 Bluetooth SDK 예제를 참조하십시오.

대상 디바이스의 실제 Bluetooth 소비 전력을 확인하는 실용적인 방법은 Bluetooth 저전력 프로파일링을 참조하십시오.

최종 업데이트: 2026-10-19