direct assignment to ble_gap_conn_params_t variable

[Joseph]

Hello Nordic support team,

Forgive me if I am asking a stupid question.

In the source file ble_conn_params.c, there is a function called ble_conn_params_init() and I found this direct assignment:

    m_preferred_conn_params = *p_init->p_conn_params;

but m_preferred_conn_params is a variable of ble_gap_conn_params_t which is a structure:

typedef struct {

uint16_t min_conn_interval;
/**< Minimum Connection Interval in 1.25 ms units, see @ref BLE_GAP_CP_LIMITS.*/

uint16_t max_conn_interval;
/**< Maximum Connection Interval in 1.25 ms units, see @ref BLE_GAP_CP_LIMITS.*/

uint16_t slave_latency;
/**< Slave Latency in number of connection events, see @ref BLE_GAP_CP_LIMITS.*/

uint16_t conn_sup_timeout;
/**< Connection Supervision Timeout in 10 ms units, see @ref BLE_GAP_CP_LIMITS.*/

} ble_gap_conn_params_t;

So why this direct assignment is possible?

Best Regards, Joseph

[zara bolen]

This is a great question, Joseph — it's always good to revisit fundamentals! Direct assignment between structures like m_preferred_conn_params = *p_init->p_conn_params; is valid in C when both operands are of the same struct type, as in the case of ble_gap_conn_params_t. It performs a shallow copy, meaning all the member values are copied field by field — no need to manually assign each one. This kind of clean struct handling in embedded C is one of the reasons why BLE stacks like Nordic's are relatively intuitive once you get familiar.

On a related note, when diving into embedded development, juggling low-level concepts, timing constraints, and hardware interactions can be overwhelming — especially for students. That’s why resources offering assignment help or even the option to pay someone to do assignments in embedded systems can be lifesavers when deadlines are tight or concepts aren’t clicking immediately. Just make sure to balance learning with any assistance you get!