Closed victorsowa12 closed 6 months ago
I realized since I had to merge develop into the feature/bm_serial_get_bcmp_cfgs
branch for the BRIDGE_CFG_LOG_PRINT function there are a bunch of changes on develop that are now also being merged into feature/bcmp_req_rep
. So I highlighted the two files to look at with comments, but those are bcmp.cpp
and ncp_config.cpp
.
Sorry for the duplicate comment... something to do with using github's in-browser code editor to do the review. 🤷
Yes that flow is correct!
does
bm_serial
callncp_cfg_get_cb
in the bridge? And perhaps that used to be the only place that would be called, so it was unconditional.
This is still true, ncp_cfg_get_cb
is still only called from bm_serial
. The if node_id == 0 || node_id == getNodeID()
just decides whether we respond directly with the bridges configs, or send out a request to another node using bcmp_config_get
. The "_cb
" is used to tell bcmp_config_get
that when it receives a reply, forward the reply via bm_serial
back to Spotter.
I see, yeah, perfect, thank you. So really — the core feature we were aiming for is in that else clause. It used to ignore the node id and only work for the bridge directly. Now we actually check the node id, and if it's for someone else, we make the bcmp request. ✨
Using the node_id and adding callbacks to handle config req/rep! This allows Spotter to set/get/del configs from its CLI. I also added that we call the callback upon bcmp request message timeout. So I made sure the callbacks can handle a NULL payload ~however, for the handling of a failed request right now I am just doing a bm_printf~. I changed it to use a
BRIDGE_CFG_LOG_PRINT
of the failure.Example from Spotter's CLI: