Deinit on nimble init failure #68
Conversation
|
|
|
Hi @tannewt , I have a query. The init for controller should not fail . If controller init fails, then as it is bluetooth cannot be used. So , when init fails, rather than freeing up the memory, it is better to understand what is failing and ensure bluetooth init never fails. What use case are you targetting where it is ok to have bluetooth init fail ? |
|
I didn’t see the controller init fail but I guarded against it anyway. Nimble init failed and I wanted it to shutdown all of Bluetooth.
This makes circuitpython work better because it uses that freed memory to attempt to run user code again. Without it, only the first attempt fails gracefully. The second fails harder because it has less memory to work with.
…On Tue, May 7, 2024, at 12:39 AM, Rahul wrote:
Hi @tannewt <https://github.com/tannewt> ,
I have a query. The init for controller should not fail . If controller init fails, then as it is bluetooth cannot be used. So , when init fails, rather than freeing up the memory, it is better to understand what is failing and ensure bluetooth init never fails.
What use case are you targetting where it is ok to have bluetooth init fail ?
—
Reply to this email directly, view it on GitHub <#68 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAM3KNVXZ6SM6XSC5L7GELZBBZJDAVCNFSM6AAAAABHGI2RSGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJXGU2TMMRSHA>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
Ok. I feel there is no harm in doing so. The current PR is against nimble-1.5.0-idf. I will raise internally to match with nimble-1.6.0-idf and backport your PR to other 5.2 / 5.1 branch. Thanks for your contribution |
|
PR is merged since quite some time. Closing |
Otherwise the controller is left on and uses memory.