You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was testing the exposed addrList in pyrf24 and hit a segmentation fault when I changed the mesh child node into a master node and explicitly called loadDHCP(). I already can see the problem because if the node's ID is not 0 upon calling mesh.begin(), then the addrList doesn't have any memory allocated.
Is there a practical use case in which the master node of a mesh can change similar to how child nodes change?
This wouldn't be a hard problem to solve, but it would definitely involve increased compile size... One could probably just solve it by recalling mesh.begin() after mesh.setNodeID(0).
The text was updated successfully, but these errors were encountered:
I don't think there is really a use case for it, plus as you mentioned it would increase memory and program space usage just to support an unlikely scenario.
I also had an idea a while back (when porting to pure python) to reserve a msg type that transfers the DHCP list to a new master node. The only case for that would be if you want a continuous network running while phasing in a firmware update.
I was testing the exposed
addrList
in pyrf24 and hit a segmentation fault when I changed the mesh child node into a master node and explicitly calledloadDHCP()
. I already can see the problem because if the node's ID is not 0 upon callingmesh.begin()
, then theaddrList
doesn't have any memory allocated.code to reproduce segmentation fault
Is there a practical use case in which the master node of a mesh can change similar to how child nodes change?
This wouldn't be a hard problem to solve, but it would definitely involve increased compile size... One could probably just solve it by recalling
mesh.begin()
aftermesh.setNodeID(0)
.The text was updated successfully, but these errors were encountered: