Dynamic creation / deletion of services

[mrquincle]

The setup procedure performs a reboot. This of course will make sure that a new configuration is loaded, however it is a cop out. It should be possible to load a new configuration on-the-fly.

It would be convenient if consecutive function calls can be initiated through an ordered set of events. In that case we can push this vector of events on some kind of stack and pop them of sequentially after each event has been executed. For example:

In setup mode we have the following sequence:

• create setup services
• loop through services and create corresponding characteristics
• set to low TX mode
• set encryption to true

In normal mode we have the sequence:

• prepare normal mode (enable scanning and meshing)
• create crownstone services
• loop through services and create corresponding characteristics
• set encryption to true

We also have a onStart function where in setup mode:

• the switch is turned on after a delay

And in normal mode:

• zero crossing detection is enabled
• the scheduler is started
• the scanner is started (with a randomized delay)
• the tracker is started
• the mesh is started

Every tick in normal mode:

• the advertisement parameters are updated
• the data in the advertisement is updated

[AlexDM0]

We have a restart after each change in settings. This greatly simplified the code and there is no impact for the user.

---

From: Anne van Rossum notifications@github.com Sent: Tuesday, September 11, 2018 2:09 PM To: crownstone/bluenet Cc: Subscribed Subject: [crownstone/bluenet] Dynamic creation / deletion from services (#58)

The setup procedure performs a reboot. This of course will make sure that a new configuration is loaded, however it is a cop out. It should be possible to load a new configuration on-the-fly.

It would be convenient if consecutive function calls can be initiated through an ordered set of events. In that case we can push this vector of events on some kind of stack and pop them of sequentially after each event has been executed. For example:

In setup mode we have the following sequence:

• create setup services
• loop through services and create corresponding characteristics
• set to low TX mode
• set encryption to true

In normal mode we have the sequence:

• prepare normal mode (enable scanning and meshing)
• create crownstone services
• loop through services and create corresponding characteristics
• set encryption to true

We also have a onStart function where in setup mode:

• the switch is turned on after a delay

And in normal mode:

• zero crossing detection is enabled
• the scheduler is started
• the scanner is started (with a randomized delay)
• the tracker is started
• the mesh is started

Every tick in normal mode:

• the advertisement parameters are updated
• the data in the advertisement is updated

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/crownstone/bluenet/issues/58, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AFHWTQe9jvKP-VDcx9JabxtnbCCFVgQKks5uZ6gRgaJpZM4WjLV0.

[mrquincle]

A "reset the app" or a "reset Bluetooth" does have a more immediate impact on the user. However, it is not the case that just resetting devices to apply changes does not have impact on the user.

• It admits defeat as developer. Basically the developer says that he/she doesn't know the state of the system.
• The softdevice will reset the connection to the peer without being instructed to. The other party is not properly informed of a broken connection.
• Latency/speed. Just adding a service or characteristic is much faster than going through a reboot.
• Reboots interfere with writing stuff to storage. You will have to wait not only till you get the events back that storage is done, but also that the right fields have been stored.
• In theory you might even send a "switch" command, store that to flash, and reboot the device to get into the new switch state. The party sending the BLE commands has to track which commands will and which commands will not be followed by a spontaneous reboot.
• Proper halt() and resume() functions on the Bluetooth stack are anyway necessary. Now at times the code leads to a SoftDevice error because state is not properly tracked and e.g. the device is still advertising while it shouldn't.
• Code consistency. At every location where you see a malloc/new, there is a corresponding free/delete.
• Code structure. If you do not have to properly track the state your architecture will suffer. For example SetupService derives from CrownstoneService, but does not call addCharacteristics of its parent class. If you would call the corresponding functions this will all lead to errors. If you care about state you will create self-contained classes such as a shared ServiceBase class where each function call is valid and subclasses where each function call is valid.
• If we expose an Arduino interface we want to allow users to change settings, however, we might not want to train them to start to reset the Crownstone device. We might even disable the option that they can reset it from Arduino code.
• If we have third-party code you can't ask them to just put their stuff in the startup code. It's not a modular setup.
• The mode switching behavior is one of the most overarching architectural choices. This henceforth needs to be a first-class citizen. This is in C++ a class. To have the state transitions between modes indirectly coded into a startup procedure does not do justice to the importance of this behavior.
• Conceptual understanding. If you know how to properly shutdown a stack you have a better grasp of the state of a system.

Note, that a watchdog timer is still a good idea, but it's an ultimate measure. Reset is not a feature.

[mrquincle]

Let's make it a bit more nuanced:

• In cases where there is just a bit of state to be stored on a high level it might be worth doing allocation/deallocation instead of rebooting the entire device.
• In cases where we do not have access to the state (e.g. in the proprietary Nordic SoftDevice) we might want to reset the appropriate code, rather than deletion/addition of the corresponding services/characteristics. In this case we can limit the reset to the SoftDevice itself. We don't have to reboot the device.

[mrquincle]

The Softdevice does not even support deleting services or characteristics. This renders most of the arguments moot. To have the system in a proper state, a reset is warranted.