Overview#

The EdgeFast Open Bluetooth Host stack software is built based on MCUXpresso SDK. The following chapter uses RT1060 as an example, other boards have similar folder structure and corresponding document.

Folder structure#

The following figure shows the EdgeFast Open examples folder structure.

The following figure shows the EdgeFast Open host stack folder structure.

The following table provides information regarding the structure and description.

Folder	Description
boards/ CMSIS/ devices/ docs/ middleware/ rtos/ tools/	MCUXpresso SDK directory. Refer to Chapter 5 Release contents of MCUXpresso SDK Release Notes at root/docs/ MCUXpresso SDK Release Notes for EVK-MIMXRT1060.pdf to know the details
boards/<board>/wireless/edgefast_open_examples	EdgeFast Open Bluetooth host stack example projects
middleware/wireless/edgefast_open	EdgeFast Open Bluetooth host stack source code

The EdgeFast Open folder includes two subfolders:

include: This subfolder includes EdgeFast Open Bluetooth host stack headers.
source: This subfolder includes EdgeFast Open Bluetooth host stack source code ported from Zephyr Bluetooth Host stack.

Parent topic:Overview

Architecture#

The figure Architecture of EdgeFast Open demo in MCUXpresso SDK below shows that the EdgeFast Open Bluetooth host stack is integrated into the MCUXpresso SDK as a middleware component. It leverages the RTOS, the board support, the peripheral driver/component, and other components in the MCUXpresso SDK. The Bluetooth application is built on top of the EdgeFast Open Bluetooth host stack and supports different peripheral features, Bluetooth features, and different RTOSes required by the user.

MCUXpresso SDK has the dual-chip architecture defined by EdgeFast Open Bluetooth project, the Bluetooth application code, and the EdgeFast Open Bluetooth host stack running on the reference board. For example, MIMXRT1060-EVK and the Linker Layer (LL) run on the Bluetooth modules like AW-AM457-USD, Murata Type 1XK, and Murata Type 1ZM and has single-chip architecture. Bluetooth Host stack and LL runs on the same chip, and communicate with Internal Communication Unit (IMU).

The communication between the host stack and the LL is implemented via the standard HCI UART interface and PCM interface for voice, or the IMU interface.

EdgeFast Open is an open-source Bluetooth Host protocol stack solution provided by NXP as part of the MCUXpresso SDK. It is derived from the Bluetooth Host Stack of Zephyr RTOS and has been ported, tailored, and enhanced by NXP. The stack runs on the MCU host processor, positioned below the application layer and above the HCI driver, and is responsible for the complete Bluetooth Classic and BLE host-side protocol functionality, including GAP, GATT, L2CAP, ATT, SM, RFCOMM, HFP, A2DP, AVRCP, etc.

Its architecture consists of two main parts:

The EdgeFast Open Host Stack itself, which contains the Bluetooth host protocol implementation ported from Zephyr, and a Porting Layer (abstraction layer) that maps Zephyr’s required kernel and system services—such as threads, mutexes, semaphores, queues, FIFOs, work queues, heaps, settings, shell, and logging—to the MCUXpresso SDK environment based on FreeRTOS and NXP platforms. Through this porting layer, the originally Zephyr-oriented Bluetooth stack can run seamlessly on FreeRTOS. EdgeFast Open communicates with the underlying Bluetooth Controller (Link Layer), typically an external BT/BLE module or wireless SoC, via a standard HCI interface (for example, UART, SPI, or PCM).

Note: The porting layer source code is located in the middleware/wireless/edgefast_open/source/porting directory, which includes implementations for thread management, work queues, synchronization primitives, and other kernel services required to adapt the Zephyr Bluetooth stack to FreeRTOS and MCUXpresso SDK platforms.

Note: The “ported” aspects of EdgeFast Open ensure compatibility with MCUXpresso SDK while maintaining the robustness and feature completeness of the original Zephyr Bluetooth Host Stack implementation. Therefore, the source code of Edgefast Open is consistent with the source code of the Zephyr Bluetooth protocol stack. This eliminates the need for any source code modifications to the core of the Zephyr Bluetooth protocol stack, thus facilitating maintenance and future updates.

For details about the different components in MCUXpresso SDK, see Getting Started with MCUXpresso SDK User’s Guide (document MCUXSDKGSUG) at root/docs/Getting Started with MCUXpresso SDK.pdf. For details on possible hardware rework requirements, see the hardware rework guide document of the relative board. Parent topic:Overview

Compare with EdgeFast Bluetooth PAL#

This document provides a detailed comparison between EdgeFast Open Bluetooth Host stack and EdgeFast Bluetooth PAL, highlighting the differences in features, examples, and APIs.

Features comparison#

The following table compares the features between EdgeFast Open Bluetooth Host stack and EdgeFast Bluetooth PAL.

Feature	EdgeFast Open	EdgeFast Bluetooth PAL
Bluetooth Core Specification	5.3	5.0
Bluetooth Host Stack	Zephyr-based	Proprietary with Zephyr API compatible
Bluetooth Controller	Supported (NXP controller)	Supported (NXP controller)
Mode	LE and Classic	LE and Classic
Protocol Support	L2CAP, GAP, GATT, RFCOMM, SDP, SM, SPP	L2CAP, GAP, GATT, RFCOMM, SM, SPP
Classic Profiles	A2DP, HFP, AVRCP, AVRCP Cover Art, GOEP, BIP, MAP, PBAP	A2DP, HFP, AVRCP, MAP, PBAP
LE Profiles	HTP, PXP, IPSP, HPS, GATT-based services	HTP, PXP, IPSP, HPS
Enhanced Attribute (EATT)	Supported	Supported
LE Audio	Supported	Supported

Examples comparison#

The following table compares the available examples between EdgeFast Open Bluetooth Host stack and EdgeFast Bluetooth PAL.

Example	EdgeFast Open	EdgeFast Bluetooth PAL
a2dp_bridge	Supported	Not supported
a2dp_sink	Supported	Supported
a2dp_source	Supported	Supported
bmr_4bis	Supported	Supported
bms_4bis	Supported	Supported
broadcast_media_receiver	Supported	Supported
broadcast_media_sender	Supported	Supported
call_gateway	Supported	Supported
call_terminal	Supported	Supported
central_fmp	Supported	Supported
central_hpc	Supported	Supported
central_ht	Supported	Supported
central_ipsp	Supported	Supported
central_pxm	Supported	Supported
central_tip	Supported	Supported
handsfree	Supported	Supported
handsfree_ag	Supported	Supported
map_mce	Supported	Supported
map_mse	Supported	Supported
pbap_pce	Supported	Supported
pbap_pse	Supported	Supported
peripheral_beacon	Supported	Supported
peripheral_fmp	Supported	Supported
peripheral_hps	Supported	Supported
peripheral_ht	Supported	Supported
peripheral_ipsp	Supported	Supported
peripheral_pxr	Supported	Supported
peripheral_tip	Supported	Supported
sco_bridge	Supported	Not supported
shell	Supported	Supported
spp	Supported	Supported
tmap_central	Supported	Supported
tmap_peripheral	Supported	Supported
umr2bms	Supported	Supported
umr_4cis	Supported	Supported
ums_4cis	Supported	Supported
ums_microphone	Supported	Supported
unicast_media_receiver	Supported	Supported
unicast_media_sender	Supported	Supported
wifi_cli_over_ble_wu	Supported	Supported
wireless_uart	Supported	Supported

APIs comparison#

Workflow#

The following workflow compares the key different of API between EdgeFast Open Bluetooth Host stack and EdgeFast Bluetooth PAL.

The following diagram is a typical Egdefast Open workflow:

The following diagram is a typical EdgeFast Bluetooth PAL workflow:

API Differences#

Core Protocols#

Core Protocols Comparison#

There are no differences in the following protocols, including GAP, SM, SPP, and L2CAP (CBFC).

L2CAP Classic Comparison#

The following table compares the L2CAP Classic differences between EdgeFast Open Bluetooth Host stack and EdgeFast Bluetooth PAL.

Feature	EdgeFast Open	EdgeFast Bluetooth PAL
Connection-oriented channels in Basic Mode	Supported	Supported
Connection-oriented channels in Retransmission Mode	Supported	Not supported
Connection-oriented channels in Flow control Mode	Supported	Not supported
Connection-oriented channels in Enhanced Retransmission Mode	Supported	Supported
Connection-oriented channels in Streaming Mode	Supported	Supported
Connectionless data channel in Basic L2CAP mode	Supported	Not supported
Signaling packet ECHO	Supported	Not supported

The following compares the L2CAP Classic differences between EdgeFast Open Bluetooth Host stack and EdgeFast Bluetooth PAL.

Aspect	EdgeFast Open	EdgeFast Bluetooth PAL
L2CAP architecture	Zephyr native L2CAP	PAL adds explicit L2CAP config negotiation
Channel config	Static fields in chan.rx.*	Callback‑based config exchange
Mode negotiation	Implicit	Explicit (get_cfg / cfg_req / cfg_rsp)
Who drives config	Local side before connect	Both sides during config phase

L2CAP Classic on EdgeFast Open#

static int l2cap_recv(struct bt_l2cap_chan *chan, struct net_buf *buf)
{
}

static void l2cap_connected(struct bt_l2cap_chan *chan)
{
}

static void l2cap_disconnected(struct bt_l2cap_chan *chan)
{
}

static struct net_buf *l2cap_alloc_buf(struct bt_l2cap_chan *chan)
{
}

#if defined(CONFIG_BT_L2CAP_SEG_RECV)
static void seg_recv(struct bt_l2cap_chan *chan, size_t sdu_len, off_t seg_offset,
		     struct net_buf_simple *seg)
{
}
#endif /* CONFIG_BT_L2CAP_SEG_RECV */

static const struct bt_l2cap_chan_ops l2cap_ops = {
	.alloc_buf = l2cap_alloc_buf,
	.recv = l2cap_recv,
	.connected = l2cap_connected,
	.disconnected = l2cap_disconnected,
#if defined(CONFIG_BT_L2CAP_SEG_RECV)
	.seg_recv = seg_recv,
#endif /* CONFIG_BT_L2CAP_SEG_RECV */
};

static struct bt_l2cap_br_chan chan = {
	.chan.ops = &l2cap_ops,
	.rx.mtu = DATA_BREDR_MTU,
},

chan.rx.mode = <Mode>;
chan.rx.max_transmit = <max_transmit>;
chan.rx.optional = <Mode optional settings>;
chan.rx.extended_control = <extended_control>;
chan.rx.max_window = <max_window>;

int err = bt_l2cap_chan_connect(default_conn, &chan.chan, psm);
if (err < 0) {
	PRINTF("Unable to connect to psm %u (err %d)\n", psm, err);
} else {
	PRINTF("L2CAP connection pending\n");
}

L2CAP Classic on EdgeFast Bluetooth PAL#

void l2cap_mode_get_cfg(struct bt_l2cap_chan *chan, struct bt_l2cap_cfg_options *cfg)
{
	/* Channel configuration handler */
	/* `cfg` argument needs to be filled with the configuration options */
}

void l2cap_mode_cfg_req(struct bt_l2cap_chan *chan, struct bt_l2cap_cfg_options *cfg, struct bt_l2cap_cfg_options *rsp)
{
	/* Channel configuration response handler */
	/* `rsp` argument needs to be filled with the response configuration options */
}

void l2cap_mode_cfg_rsp(struct bt_l2cap_chan *chan, struct bt_l2cap_cfg_options *rsp)
{
	/* Channel configuration response handler */
}

static const struct bt_l2cap_chan_ops l2cap_mode_ops = {
	.alloc_buf	= l2cap_alloc_buf,
	.recv		= l2cap_recv,
	.connected	= l2cap_connected,
	.disconnected	= l2cap_disconnected,
        .get_cfg        = l2cap_mode_get_cfg,
        .cfg_req        = l2cap_mode_cfg_req,
        .cfg_rsp        = l2cap_mode_cfg_rsp
};

static struct bt_l2cap_br_chan chan = {
	.chan.ops = &l2cap_mode_ops,
	.rx.mtu = DATA_BREDR_MTU,
},

int err = bt_l2cap_chan_connect(default_conn, &chan.chan, psm);
if (err < 0) {
	PRINTF("Unable to connect to psm %u (err %d)\n", psm, err);
} else {
	PRINTF("L2CAP connection pending\n");
}

Parent topic:Core Protocols Comparison

SDP#

The following compares the SDP differences between EdgeFast Open Bluetooth Host stack and EdgeFast Bluetooth PAL.

Feature	EdgeFast Open	EdgeFast Bluetooth PAL
SDP record discovery	Support Attribute ID list and range settings	Not supported
SDP record parse	bt_sdp_record_parse	Not supported
Check attribute	bt_sdp_has_attr	Not supported
Parse attribute value	bt_sdp_get_attr bt_sdp_attr_value_parse bt_sdp_attr_has_uuid bt_sdp_attr_read	Not supported
Parse Additional Protocol Descriptor List attribute	bt_sdp_attr_addl_proto_parse bt_sdp_attr_addl_proto_count bt_sdp_attr_addl_proto_read	Not supported

Parent topic:Core Protocols Comparison

Parent topic:Compare with EdgeFast Bluetooth PAL

LE Profiles#

No differences between EdgeFast Open Bluetooth Host stack and EdgeFast Bluetooth PAL for LE profiles.

LE Audio Profiles#

No differences between EdgeFast Open Bluetooth Host stack and EdgeFast Bluetooth PAL for LE Audio profiles.

Classic Profiles#

The following compares the available Classic profiles between EdgeFast Open Bluetooth Host stack and EdgeFast Bluetooth PAL.

A2DP#

AVRCP#

HFP#

MAP#

PBAP#

PBAP Comparison#

The following compares the PBAP differences between EdgeFast Open Bluetooth Host stack and EdgeFast Bluetooth PAL.

1. Architectural Differences (Core Changes)#

Dimension	EdgeFast Open	EdgeFast Bluetooth PAL	Migration impact
API abstraction	PDU-/protocol-driven: most APIs take only `net_buf buf` (+ a few `flags/rsp_code`); all headers are added by the application via `obex_add_header_xxx()`*	Parameter-driven: function parameters directly carry `name/wait/flag/auth/peer_feature`	Old: “pass parameters”; New: “build PDUs + add headers + parse buffers”.
Header construction	Application builds 100% of headers (Name/Type/AppParams/SRMP/Body/EndBody/auth, etc.)	OBEX/PBAP headers are built internally based on API parameters; application mainly reserves headroom	Main migration task: map old API parameters into a sequence of `obex_add_header_xxx()` calls.
Connection responsibility	Clearly split: transport bearer (RFCOMM/L2CAP) + OBEX CONNECT/DISCONNECT/ABORT PDU handling	Connect APIs often bundle object creation, authentication, feature info, and transport setup	Connection procedure becomes longer (one or two extra steps).
Segmentation/chunking	Final-bit / End-of-Body and segmentation are decided by the application’s PDU construction; PBAP APIs only transmit	Driven by `enum bt_obex_req_flags` + `CONTINUE/SUCCESS` responses	Requires redesign of “first packet / subsequent packet / last packet” strategy.
SRMP (“wait”)	Not a parameter anymore; application adds SRMP header	`bool wait` parameter controls SRMP	`wait` → SRMP header.
Name/path	Not a function parameter; carried in the OBEX Name header inside `buf`	`char *name` passed as parameter or provided by callback	`name` → header + parsing.
Authentication	New provides nonce/digest/verify helpers; auth headers are added by the application	Old callback includes `get_auth_info()` providing `struct bt_pbap_auth`	Auth shifts from “configuration/struct callback” to “parse challenge + compute + add headers”.

2. PCE (Client) API Alignment Differences (Function Level)#

Function	EdgeFast Open API (`pbap.h`)	EdgeFast Bluetooth PAL API (`pbap_pce.h`)	Key differences (incl. migration notes)
Callback registration / init	(No equivalent global `register` found)	`bt_pbap_pce_register(struct bt_pbap_pce_cb *cb)`	Old: global callback registration; New: more instance-oriented, `cb` is passed during connect.
RFCOMM connect (SCN/channel)	`bt_pbap_pce_rfcomm_connect(conn, pce, cb, channel)`	`bt_pbap_pce_scn_connect(conn, channel, auth, peer_feature, &pce)`	Old creates/returns the PCE object and takes `auth/peer_feature`; New requires caller-owned `pce` and does not express auth/features via connect parameters.
L2CAP connect (PSM)	`bt_pbap_pce_l2cap_connect(conn, pce, cb, psm)`	`bt_pbap_pce_psm_connect(conn, psm, auth, peer_feature, &pce)`	Same pattern as RFCOMM connect.
Disconnect (high-level)	`bt_pbap_pce_disconnect(pce, buf)`	`bt_pbap_pce_disconnect(pce)`	New requires application-provided `buf` and application-built OBEX Disconnect headers.
Disconnect (transport bearer)	`bt_pbap_pce_rfcomm_disconnect(pce)` / `bt_pbap_pce_l2cap_disconnect(pce)`	(No dedicated API)	New separates bearer teardown from OBEX DISCONNECT PDU.
OBEX CONNECT (PBAP session)	`bt_pbap_pce_connect(pce, mopl, buf)`	(Typically implicit in old connect flow)	Application must construct the OBEX CONNECT PDU and headers via `obex_add_header_xxx()`.
ABORT	`bt_pbap_pce_abort(pce, buf)`	`bt_pbap_pce_abort(pce)`	Application constructs ABORT PDU headers.
Pull Phonebook	`bt_pbap_pce_pull_phone_book(pce, buf)`	`bt_pbap_pce_pull_phonebook(pce, buf, name, wait, flag)`	`flag` removed; `name/wait` moved into headers. Application adds Name/Type/AppParams/SRMP and segmentation-related headers/flags. Function name also changes (`phonebook`→`phone_book`).
SetPath	`bt_pbap_pce_set_phone_book(pce, flags, buf)`	`bt_pbap_pce_set_phonebook_path(pce, buf, name)`	Old passes `name`; New uses `flags + buf`. Folder name must be carried in the OBEX Name header (application-built).
Pull vCard Listing	`bt_pbap_pce_pull_vcard_listing(pce, buf)`	`bt_pbap_pce_pull_vcard_listing(pce, buf, name, wait, flag)`	Same as Pull Phonebook: parameters → headers.
Pull vCard Entry	`bt_pbap_pce_pull_vcard_entry(pce, buf)`	`bt_pbap_pce_pull_vcard_entry(pce, buf, name, wait, flag)`	Same as above.
Get max packet length	(No same-name API found)	`bt_pbap_pce_get_max_pkt_len(pce, &len)`	Old provides direct query; New may obtain it via OBEX CONNECT negotiation (e.g., MOPl) or OBEX layer APIs.
Helper: parse App Params	(No same-name macro in `pbap.h`; likely use OBEX layer)	`bt_pbap_pce_app_param_parse(...)` (macro to OBEX parser)	New encourages direct OBEX/AppParams header manipulation/parsing by the application.
Helper: get Body	(No same-name macro in `pbap.h`; likely use OBEX layer)	`bt_pbap_pce_get_body(...)` (macro to OBEX helper)	New callbacks deliver `buf`; application should parse OBEX Body/End-of-Body headers.

3. PSE (Server) API Alignment Differences (Function Level)#

Function	EdgeFast Open API (`pbap.h`)	EdgeFast Bluetooth PAL API (`pbap_pse.h`)	Key differences (incl. migration notes)
Callback registration / init	`bt_pbap_pse_register(struct bt_pbap_pse pse, struct bt_pbap_pse_cb cb)`	`bt_pbap_pse_register(struct bt_pbap_pse_cb *cb)`	New requires a PSE instance, i.e., a more instance-based server model.
Server bearer registration	`bt_pbap_pse_rfcomm_register(server)` / `bt_pbap_pse_l2cap_register(server)`	(Not provided in old header)	New adds explicit RFCOMM/L2CAP server registration and accept model.
Disconnect	`bt_pbap_pse_disconnect_rsp(pse, rsp_code, buf)`	`bt_pbap_pse_disconnect(pse)`	New is response/PDU oriented; application builds the response PDU and headers.
CONNECT/ABORT response	`bt_pbap_pse_connect_rsp(pse, mopl, rsp_code, buf)` / `bt_pbap_pse_abort_rsp(pse, rsp_code, buf)`	(More abstracted in old version)	New requires explicit response PDU construction and transmission.
Pull phonebook response	`bt_pbap_pse_pull_phone_book_rsp(pse, rsp_code, buf)`	`bt_pbap_pse_pull_phonebook_response(pse, result, buf, wait)`	`wait` moves to SRMP header; `result`→`rsp_code`; buffer payload/headers fully application-built.
SetPath response	`bt_pbap_pse_set_phone_book_rsp(pse, rsp_code, buf)`	`bt_pbap_pse_set_phonebook_path_response(pse, result)`	New requires a response `buf` even for SetPath.
Pull vCard listing response	`..._rsp(pse, rsp_code, buf)`	`..._response(pse, result, buf, wait)`	`wait` removed; application adds SRMP and body/end-body.
Pull vCard entry response	`..._rsp(pse, rsp_code, buf)`	`..._response(pse, result, buf, wait)`	Same as above.
Get max packet length	(No same-name API found)	`bt_pbap_pse_get_max_pkt_len(pse, &len)`	New may rely on OBEX/GOEP layer APIs.
Get peer supported features	(No same-name API found)	`bt_pbap_pse_get_peer_supported_features(pse, &feat)`	New may expose this via negotiation/callback/buffer parsing or internal state.

4. Authentication-related API Alignment#

Functionality	EdgeFast Open	EdgeFast Bluetooth PAL	Notes
Compute nonce (challenge)	`bt_pbap_calculate_nonce(pwd, nonce)`	(Not exposed in old headers)	New exposes a helper for OBEX/PBAP authentication flow.
Compute response digest	`bt_pbap_calculate_rsp_digest(pwd, nonce, rsp_digest)`	(Not exposed in old headers)	New exposes digest computation for challenge/response authentication.
Verify authentication response	`bt_pbap_verify_authentication(nonce, rsp_digest, pwd)`	(Not exposed in old headers)	New exposes verification helper.

5. Callback Model Differences: From “High-level Events” to “Protocol Events + Buffer-driven”#

5.1 PCE callbacks#

Aspect	EdgeFast Open `bt_pbap_pce_cb`	EdgeFast Bluetooth PAL `bt_pbap_pce_cb`	Migration impact
Bearer connected	`rfcomm_connected(conn,pce)` / `l2cap_connected(conn,pce)`	`connected(pce)`	New distinguishes bearer type and provides `bt_conn*`.
Bearer disconnected	`rfcomm_disconnected(pce)` / `l2cap_disconnected(pce)`	`disconnected(pce, result)`	The disconnect reason/result is more reflected in protocol `rsp_code` paths.
OBEX CONNECT result	`connect(pce, rsp_code, version, mopl, buf)`	(Not typically exposed explicitly)	New exposes negotiated parameters and delivers the raw buffer.
pull/set/abort callbacks	uniformly `rsp_code + buf`	result + buf (some callbacks without buf)	Application must parse OBEX headers/body from `buf`.
Auth info retrieval	(Not present)	`get_auth_info(pce, auth)`	New expects application-driven OBEX auth header handling (parse challenge, compute, add response).

5.2 PSE callbacks#

Aspect	EdgeFast Open `bt_pbap_pse_cb`	EdgeFast Bluetooth PAL `bt_pbap_pse_cb`	Migration impact
Pull request callback params	`(..., buf)`	`(..., buf, name, flag)`	New requires parsing Name/Type/AppParams/SRMP/segmentation from `buf`.
SetPath request	`set_phone_book(pse, flags, buf)`	`set_phonebook_path(pse, name)`	Flags are standardized; folder name is parsed from Name header in `buf`.
connect/disconnect/abort	New provides buffer-level callbacks and explicit response APIs	More abstracted	New behaves like an OBEX server role: app participates in handshake and PDU construction.

6. Migration Mapping: “Old parameters” → “New headers (obex_add_header_xxx)”#

Old parameter/concept	EdgeFast Open	EdgeFast Bluetooth PAL	Application action (conceptual)
`name`	Not a function parameter anymore	API parameter `char *name` or callback provides name	Add/parse OBEX Name header in request/response PDUs.
`Type`	`BT_PBAP_PULL_*_TYPE` macros exist	Often internal in old stack	Add OBEX Type header (`x-bt/phonebook`, `x-bt/vcard-listing`, `x-bt/vcard`).
App Parameters (filter/format/order/search, etc.)	enums in `pbap.h` (order/format/property_mask, etc.)	via `BT_PBAP_ADD_xxx` or internal	Encode/decode PBAP AppParams TLVs inside the OBEX App Parameters header.
`wait` (SRMP)	Not present as parameter	`bool wait` parameter	Add/parse SRMP header to control Server Response Mode Parameter.
`flag` (START/CONTINUE)	Not present as parameter	`enum bt_obex_req_flags flag`	Express segmentation via PDU construction (Final-bit, Body vs End-of-Body, multi-PDU flow).
`result` vs `rsp_code`	unified `rsp_code`	`SUCCESS/CONTINUE`-style results	Choose OBEX response code based on whether more PDUs follow; build Body/End-of-Body accordingly.
`auth`	nonce/digest/verify helpers	connect parameter or `get_auth_info` callback	Build OBEX auth headers in PDUs; compute/verify using provided helpers.
`peer_feature`	not in prototypes	connect parameter or explicit getter	Likely obtained via negotiation/SDP/buffer parsing/internal state; avoid injecting via connect signature.

7. Newly Added / Enhanced APIs & Capabilities in EdgeFast Open#

Item	EdgeFast Open API/structure	Value
PDU allocation helper	`bt_pbap_pce_create_pdu(pce, pool)` / `bt_pbap_pse_create_pdu(pse, pool)`	Provides a PDU container to be populated by the application via `obex_add_header_xxx()`.
PSE bearer server registration	`bt_pbap_pse_rfcomm_register(server)` / `bt_pbap_pse_l2cap_register(server)` + `accept()`	More complete server integration model (multi-connection / custom accept).
OBEX-level response APIs (PSE)	`connect_rsp/disconnect_rsp/abort_rsp`	Application can explicitly control OBEX response codes and attached headers.
Authentication utilities	`bt_pbap_calculate_nonce` / `bt_pbap_calculate_rsp_digest` / `bt_pbap_verify_authentication`	Facilitates application-implemented OBEX/PBAP authentication headers and validation.

8. Migration Recommendations (High-level)#

Refactor connection sequencing (PCE):
- Establish bearer first: bt_pbap_pce_rfcomm_connect or bt_pbap_pce_l2cap_connect
- Then build the OBEX CONNECT PDU (application uses obex_add_header_xxx()) and call bt_pbap_pce_connect
Change request transmission to “build PDU first, then call PBAP API”:
- bt_pbap_pce_create_pdu() → obex_add_header_xxx() (Name/Type/AppParams/SRMP/Body…) → bt_pbap_pce_pull_*()
Change response sending (PSE) to “application fully owns headers/body/end-of-body”:
- Request callbacks deliver only buf; parse Name/Type/AppParams
- Build response buf: add Body/End-of-Body and required headers via obex_add_header_xxx() → call bt_pbap_pse_*_rsp()
Segmentation/CONTINUE strategy migration:
- Old: flag + wait + result
- New: application decides whether to include End-of-Body, whether more PDUs follow, and selects rsp_code (CONTINUE/SUCCESS)
Authentication migration:
- Old: get_auth_info + struct bt_pbap_auth
- New: application parses OBEX auth challenge headers, computes digests via bt_pbap_calculate_*, and adds auth response/challenge headers via obex_add_header_xxx()

Parent topic:Compare with EdgeFast Bluetooth PAL

Parent topic:Overview

Features#

This section provides an overview of Bluetooth features, toolchain support, and RTOS support.

Bluetooth features#

Bluetooth 5.3 compliant
Protocol support
- L2CAP, GAP, GATT, RFCOMM, SDP, SM, and SPP
Classic profile
- A2DP, HFP, AVRCP, AVRCP Cover Art, GOEP, BIP, MAP, PBAP
LE profile
- HTP, PXP, IPSP, HPS
LE audio
Digital Audio Interface including PCM interface for HFP

Parent topic:Features

Toolchain support#

IAR Embedded Workbench for ARM®
MCUXpresso IDE
Keil® MDK/μVision
Makefiles support with GCC from Arm Embedded

Note: For details on IDE Development tools version details, see Section 3, Development tools in MCUXpresso SDK Release Notes (document MCUXSDKMIMXRT106XRN). The Release Notes document is available at root/docs/ MCUXpresso SDK Release Notes for EVK-MIMXRT1060.pdf.

Parent topic:Features

RTOS support#

FreeRTOSTMOS

Note: The FreeRTOS static allocation feature is required by Edgefast Open. The macro configSUPPORT_STATIC_ALLOCATION needs to be set to enable this feature.

Parent topic:Features

Parent topic:Overview

Examples list#

The following examples are provided. Not all the examples are implemented on all the boards. See the board package for a list of the implemented examples.
- central_hpc (central http proxy service client): Demonstrates a basic Bluetooth Low Energy Central role functionality. The application scans for other Bluetooth Low Energy devices and establishes a connection to the peripheral with the strongest signal. The application specifically looks for HPS Server and programs a set of characteristics that configures a Hyper Text Transfer Protocol (HTTP) request, initiates request, and reads the response once connected.
- central_ht (central health thermometer): Demonstrates a basic Bluetooth Low Energy Central role functionality. The application scans for other Bluetooth Low Energy devices and establishes a connection to the peripheral with the strongest signal. The application specifically looks for health thermometer sensor and reports the die temperature readings once connected.
- central_ipsp (central Internet protocol support profile): Demonstrates a basic Bluetooth Low Energy Central role functionality. The application scans for other Bluetooth Low Energy devices and establishes connection to the peripheral with the strongest signal. The application specifically looks for IPSP Service and communicates between the devices that support IPSP. Once connected, the communication is done using IPv6 packets over the Bluetooth Low Energy transport.
- central_pxm (central proximity monitor): Demonstrates a basic Bluetooth Low Energy Central role functionality. The application scans for other Bluetooth Low Energy devices and establishes a connection to the peripheral with the strongest signal. The application specifically looks for Proximity Reporter.
- peripheral beacon: Demonstrates the Bluetooth Low Energy Peripheral role, This application implements types of beacon applications.
  - beacon: Demonstrates the Bluetooth Low Energy Broadcaster role functionality by advertising Company Identifier, Beacon Identifier, UUID, A, B, C, RSSI.
  - Eddystone: The Eddystone Configuration Service runs as a GATT service on the beacon while it is connectable and allows configuration of the advertised data, the broadcast power levels, and the advertising intervals.
  - iBeacon: Demonstrates the Bluetooth Low Energy Broadcaster role functionality by advertising an Apple iBeacon.
- peripheral_hps (peripheral http proxy service): Demonstrates the Bluetooth Low Energy Peripheral role. The application specifically exposes the HTTP Proxy GATT Service.
- peripheral_ht (peripheral health thermometer): Demonstrates the Bluetooth Low Energy Peripheral role. The application specifically exposes the HT (Health Thermometer) GATT Service. Once a device connects, it generates dummy temperature values.
- peripheral_ipsp (peripheral Internet protocol support profile): Demonstrates the Bluetooth Low Energy Peripheral role. The application specifically exposes the Internet Protocol Support GATT Service.
- peripheral_pxr (peripheral proximity reporter): Demonstrates the Bluetooth Low Energy Peripheral role. The application specifically exposes the Proximity Reporter (including LLS, IAS, and TPS) GATT Service.
- wireless uart: The application automatically starts advertising the wireless uart service and connects to the wireless uart service after the role switch. The wireless UART service is a custom service that implements a custom writable ASCII Char characteristic (UUID: 01ff0101-ba5e-f4ee-5ca1-eb1e5e4b1ce0) that holds the character written by the peer device.
- spp (serial prot profile): Application demonstrates the use of the SPP feature.
- handsfree: Application demonstrating usage of the Hands-free Profile (HFP) feature.
- handsfree_ag: Application demonstrating usage of the Hands-free Profile Audio Gateway (HFP-AG) feature.
- a2dp_sink: Application demonstrating how to use the a2dp sink feature.
- a2dp_source: Application demonstrating how to use the a2dp source feature.
- shell: Shell application demonstrating the shell mode of the simplified Adapter APIs.

Parent topic:Overview

Overview

Contents

Overview#

Folder structure#

Architecture#

Compare with EdgeFast Bluetooth PAL#

Features comparison#

Examples comparison#

APIs comparison#

Workflow#

API Differences#

Core Protocols#

Core Protocols Comparison#

L2CAP Classic Comparison#

L2CAP Classic on EdgeFast Open#

L2CAP Classic on EdgeFast Bluetooth PAL#

SDP#

LE Profiles#

LE Audio Profiles#

Classic Profiles#

A2DP#

AVRCP#

HFP#

MAP#

PBAP#

PBAP Comparison#

1. Architectural Differences (Core Changes)#

2. PCE (Client) API Alignment Differences (Function Level)#

3. PSE (Server) API Alignment Differences (Function Level)#

4. Authentication-related API Alignment#

5. Callback Model Differences: From “High-level Events” to “Protocol Events + Buffer-driven”#

5.1 PCE callbacks#

5.2 PSE callbacks#

6. Migration Mapping: “Old parameters” → “New headers (obex_add_header_xxx)”#

7. Newly Added / Enhanced APIs & Capabilities in EdgeFast Open#

8. Migration Recommendations (High-level)#

Features#

Bluetooth features#

Toolchain support#

RTOS support#

Examples list#