Re: Controlled shutdown
Hi Martin, On Fri, Sep 28, 2018 at 04:30:17PM -0700, Martin Turon wrote: > +1 for graceful shutdown. > > It could also be useful for coarse, multi-protocol use cases such as using > BLE for commissioning, shutting down that stack, and then starting a 15.4 > stack such as Thread. > > In general, it would be great if nimble could support high level stack > start / stop commands such as the following shell API imply: > > ble start# start nimble stack > ble scan start # start BLE scan ... > ble scan stop# stop BLE scan > *ble stop *# NEW: gracefully shutdown nimble > > > All of the above can be supported right now, except "ble stop", so your > proposal is welcome. > > I would also suggest keeping the concepts of graceful shutdown and reset > separable. I agree with all of the above. Unfortunately, the ability to stop the stack absent a reset, which implies the ability to reenable it, adds a bit of complexity to this feature. I think this functionality is important enough to justify the added complexity. Chris
Re: Controlled shutdown
+1 to the idea of being able to handle this at the module/package level to subscribe to 'shutdown' or 'sleep' events. The package level is the right place to handle this since the package itself is aware of the transport being used for drivers (I2C/SPI/etc.), and the pins that can be switched to an appropriate power-saving mode (disable internal pullups, etc.) and properly restored on wakeup. It does bring up the question of SRAM retention at the HAL level, though, and sharing access to whatever block of SRAM is being maintained in lower powder mode(s) if the scope here is larger than just 'shutting down' and 'starting up'? > I guess device can be powered off simply as a power saving option or > shipping mode so perhaps 'reason' parameter could be added to shutdown > call. I do not know if it really matters to any package whether we shutdown > to reset device or just to power it off, but single extra parameter won't > hurt. > I think this is a good idea in situations where you might want to log the shutdown reason and perhaps check it on the next startup. For example, if we shutdown because the battery is critically low, and this is detected at the next startup, you can run through a config memory verification process, etc. Kevin
