Part Number: CC1352R
In this DMM Lab we are instructed to use the SimplePeripheral_fastStateUpdateCb mechanism to propagate connection-down and connection-up (but before connection params are negotiated) states to the DMM via DMMPolicy_updateStackState(). However, to notify the DMM that the connection param negotiation is done (and thus the connection is stable and able to be preempted by other stacks without dropping the link), we're instructed to hook the GAP_LINK_PARAM_UPDATE_EVENT case in SimplePeripheral_processGapMessage().
I note with interest that SimplePeripheral_processGapMessage() has link up (GAP_LINK_ESTABLISHED_EVENT) and link down (GAP_LINK_TERMINATED_EVENT) cases as well. Why wouldn't we put all three DMMPolicy_updateStackState() invocations in there, as sibling cases, rather than having two in SimplePeripheral_fastStateUpdateCb() and only the param update hook in SimplePeripheral_processGapMessage()? It would seem simpler to me to put all three of the DMM updates at the same level.
For that matter, what is the unique job of SimplePeripheral_fastStateUpdateCb() that isn't already covered by SimplePeripheral_processGapMessage already? Perhaps understanding that would be the key to my first question.
CC1352R1F3 / SDK v3.20.00.68 / CCS 9.1.0.00010