Quantcast
Channel: Forums - Recent Threads
Viewing all articles
Browse latest Browse all 262198

CC1352R: SimplePeripheral_processGapMessage vs SimplePeripheral_fastStateUpdateCb

$
0
0

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


Viewing all articles
Browse latest Browse all 262198

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>