Re: [Bluetooth mesh]unprovisioned device (micro:bit) can't be discovered
Hi Kai,toggle quoted messageShow quoted text
Hijacking the thread a bit here but have you considered using an nRF52-based board instead of the micro:bit? There's quite a few of them in really interesting form factors, including the reel_board and many others:
(unfortunately I cannot filter by nRF52 but you can look around)
On 15/03/2019, 15:49, "firstname.lastname@example.org on behalf of Kai Ren via Lists.Zephyrproject.Org" <email@example.com on behalf of firstname.lastname@example.org> wrote:
Thanks for the prompt reply.
I think you're expert of Zephyr Bluetooth, I have two questions before getting into the detail for optimization:
1. compiling same sample code, like sample/bluetooth/mesh/, compared with v1.12.0, do you think v1.14.0 is hungry or efficient for RAM consumption?
2. as your estimation, how many bytes will be consumed if add persistent storage?
From: Hedberg, Johan <email@example.com>
Sent: Friday, March 15, 2019 6:23 PM
To: Kai Ren <firstname.lastname@example.org>
Subject: Re: [Zephyr-devel] [Bluetooth mesh]unprovisioned device (micro:bit) can't be discovered
On 15 Mar 2019, at 12.12, Kai Ren <email@example.com> wrote:
> I had done it, the micro:bit can be:
> 1. provisioned by nRF Mesh and meshctl through PB-GATT 2. don't
> support provisioningdata persistent storage; 3. model configuration,
> just two models here: Configuration Server and Generic OnOff Server. Micro:bit can be configured through PB-GATT.
> 4. don't support Proxy.
> 5. basing on Zephyr v1.12 release.
> I tried to put it basing on v1.14-rc1, but I think it's impossible.
I wouldn’t say it’s impossible. I bet there’s still place for memory optimisation, e.g. thread stacks that can be shrunk, buffer sizes & counts that can be lowered, and possibly unneeded features that can be disabled. Someone would just need to find the time to look into this :)