Re: Runtime "configuration" system naming
Carles Cufi
The advantage of “settings” is that it matches what other people mean by those:
https://support.apple.com/en-us/HT201274
The disadvantage is that it is a bit long J “sett_” perhaps as a prefix?
From: Erwan Gouriou <erwan.gouriou@...>
Sent: 27 March 2018 17:32 To: Jukka Rissanen <jukka.rissanen@...> Cc: Cufi, Carles <Carles.Cufi@...>; devel@... Subject: Re: [Zephyr-devel] Runtime "configuration" system naming
I actually like "settings", I find it carries well the idea of run time configuration
On 27 March 2018 at 17:21, Jukka Rissanen <jukka.rissanen@...> wrote:
|
|
Re: Runtime "configuration" system naming
Erwan Gouriou
I actually like "settings", I find it carries well the idea of run time configuration
On 27 March 2018 at 17:21, Jukka Rissanen <jukka.rissanen@...> wrote: Hi Carles,
|
|
Re: Runtime "configuration" system naming
Carles Cufi
Hi Sterling,
toggle quoted messageShow quoted text
Thanks for the feedback.
-----Original Message-----Me too actually, it's growing on me and it matches the original Mynewt name relatively closely as well as describing the functionality well. The only drawback is that it contains "cfg" which stands for "configuration" and therefore somehow collides with our Kconfig as mentioned in my original email. Regards, Carles
|
|
Re: Runtime "configuration" system naming
Carles Cufi
Hi Jukka,
toggle quoted messageShow quoted text
Thanks for the feedback.
-----Original Message-----I like cfgdb, even though there is no real "database" involved. Perhaps "syscfg" is a bit more neutral though in the sense that it's a "system-wide configuration" of the device without actually explicitly naming any storage backend (database) or mechanism (serialization). Carles
|
|
Re: Runtime "configuration" system naming
Sterling Hughes <sterling@...>
I like syscfg mentioned below.
toggle quoted messageShow quoted text
On 27 Mar 2018, at 8:21, Jukka Rissanen wrote:
Hi Carles,
|
|
Re: Runtime "configuration" system naming
Carles Cufi
Hi Erwan,
Thanks for the feedback.
I did think about using “marshalling”, but I thought it was less common than “serialization” so I went for the “s11n” abbreviation. I would really like to keep it short if possible J
Carles
From: Erwan Gouriou <erwan.gouriou@...>
Sent: 27 March 2018 15:30 To: Cufi, Carles <Carles.Cufi@...> Cc: devel@... Subject: Re: [Zephyr-devel] Runtime "configuration" system naming
Hi Carles, Serialization is also sometime called marshalling, so an alternative could be "marshal"/"cfg_marshal"/"rtcfg_marshal"
Cheers Erwan
On 27 March 2018 at 14:51, Cufi, Carles <Carles.Cufi@...> wrote:
|
|
Re: Runtime "configuration" system naming
Jukka Rissanen
Hi Carles,
toggle quoted messageShow quoted text
as this seems to be about configuration settings, why not settings cfgdb or something like that. Why do we need to mention the serialization at all in the function names, that sounds like implementation detail. Cheers, Jukka
On Tue, 2018-03-27 at 15:29 +0200, Erwan Gouriou wrote:
Hi Carles,
|
|
Re: Runtime "configuration" system naming
Erwan Gouriou
Hi Carles, Serialization is also sometime called marshalling, so an alternative could be "marshal"/"cfg_marshal"/"rtcfg_marshal"
On 27 March 2018 at 14:51, Cufi, Carles <Carles.Cufi@...> wrote: Hi all,
|
|
Runtime "configuration" system naming
Carles Cufi
Hi all,
Andrzej from Nordic has just ported the *run-time* configuration system from Mynewt into Zephyr [1]. This is essentially a system-wide way of loading and storing all state from and to non-volatile memory (i.e. flash) in a completely centralized way. Since it serializes the data before storing it (and deserializes it after loading), and we already use the word "config" for *compile-time* configuration, we have currently renamed it to "s11n" (for serialization). But some people find this name confusing, so I am now addressing a wider audience for feedback. The currently proposed names are: * s11n * syscfg Any preferences or alternatives? Thanks, Carles [1] https://github.com/zephyrproject-rtos/zephyr/pull/6408
|
|
Re: [Bluetooth mesh]CONFIG_BT_PERIPHERAL, what does it mean?
Kai Ren
Yes, I had to increate both stacks’ size, current configuration is: CONFIG_MAIN_STACK_SIZE=640 (from 512) CONFIG_BT_RX_STACK_SIZE=1450 (from 1100)
Regards, Kai
From: Chettimada, Vinayak Kariappa [mailto:vinayak.kariappa.chettimada@...]
Sent: Monday, March 26, 2018 5:19 PM To: Kai Ren <kren@...>; Johan Hedberg <johan.hedberg@...> Cc: zephyr-devel@... Subject: RE: [Zephyr-devel] [Bluetooth mesh]CONFIG_BT_PERIPHERAL, what does it mean?
Thanks Kai. Glad to know you have PB-GATT sans micro:bit display, working.
Did you have to increase the STACK_SIZE(s)? if so, which ones?
Regards, Vinayak
From: Kai Ren [mailto:kren@...]
Hi Vinayak,
I followed your instruction to disable some features above Bluetooth core spec v4.0, like 4.1, 4.2 and 5.0 as follow:
#Controller #5.0 features CONFIG_BT_CTLR_PHY=n CONFIG_BT_CTLR_CHAN_SEL_2=n CONFIG_BT_CTLR_MIN_USED_CHAN=n CONFIG_BT_CTLR_ADV_EXT=n CONFIG_BT_CTLR_PHY_2M=n
#4.2 features CONFIG_BT_CTLR_DATA_LENGTH=n CONFIG_BT_CTLR_DATA_LENGTH_MAX=27 CONFIG_BT_CTLR_PRIVACY=n CONFIG_BT_CTLR_EXT_SCAN_FP=n
#4.1 features CONFIG_BT_CTLR_CONN_PARAM_REQ=n CONFIG_BT_CTLR_LE_PING=n
With this kind of configuration, there are 56 bytes saving, but it’s still not enough for me to squeeze the firmware into RAM. In order to make it happen, made some changes:
After above configuration, the RAM usage is 99.32% and I can:
Thank you for the help!
Regards, Kai
From: "Chettimada, Vinayak Kariappa" <vinayak.kariappa.chettimada@...>
Hi Ken,
As the faulting instruction address is in RAM, I suspect an overflow of some thread call stack. The PB-GATT may not have been tested on micro:bit due to restricted amount of RAM. But, please review the Kconfig option for the controller (me being the maintainer of controller) in menuconfig and disable any options that will not be needed for your usecase, like disabling 4.1 and above features and reducing any buffer counts.
That said, please increase these: CONFIG_MAIN_STACK_SIZE CONFIG_BT_RX_STACK_SIZE
… provided you can find some free RAM space!
Regards, Vinayak
From:
zephyr-devel-bounces@...
[mailto:zephyr-devel-bounces@...]
On Behalf Of Kai Ren
Hi Johan, Thank you for the proposal, I've tested it. I copied microbit_gatt.conf and reduced CONFIG_BT_L2CAP_TX_BUF_COUNT to 2, RAM usage is 99.93%, which can make it fit micro:bit RAM size, but when I use BlueZ to provision it, after OOB output on micro:bit, it seems to be corrupted, a HARD FAULT as below. OOB Number: 549 ***** HARD FAULT ***** Executing thread ID (thread): 0x20001670 Faulting instruction address: 0x200014dc Fatal fault in ISR! Spinning...
I guess that there may be two causes:
So, I have a question that can I enable optimization level for source code compiling? I had used Keil or IAR, their GUI support to configure optimization level, but how can I configure it on Zephyr? I hope it may save some valuable bytes in RAM of micro:bit.
Regards, Kai
On 22/03/2018, 11:39 PM, "Johan Hedberg" <johan.hedberg@...> wrote:
Hi Kai,
On Thu, Mar 22, 2018, Kai Ren wrote: > I’m try to run ./sample/Bluetooth/mesh/ on micro:bit, I found that > current source code for micro:bit just support PB-ADV, don’t support > PB-GATT. So, I want to add PB-GATT on it, but I found that it’s really > hard to pass the build process because it runs out of RAM if I > modified prj_bbc_microbit.conf. > Meanwhile, I also found that there is a configuration flag, > CONFIG_BT_PERIPHERAL, it consumes about 2KB RAM when I enable it, so > I’m just curious that what function does this flag provide? And is it > necessary for PB-GATT on micro:bit? Thanks!
There's actually a samples/bluetooth/mesh/microbit_gatt.conf configuration that's intended to be used for a GATT-based build of the mesh sample. That said, I just tried it and it actually overflows the RAM by 300 bytes. That's much less than 2k however, and hopefully easily to fix. Looking into it now. It might e.g. be possible that the CONFIG_BT_L2CAP_TX_BUF_COUNT=5 variable can be lowered since there was recently an extra segmentation buffer introduced for outgoing ACL packets.
Note: you can select microbit_gatt.conf e.g. by passing the following to cmake: -DCONF_FILE=microbit_gatt.conf
Johan
|
|
Re: [Bluetooth mesh]CONFIG_BT_PERIPHERAL, what does it mean?
Chettimada, Vinayak Kariappa
Thanks Kai. Glad to know you have PB-GATT sans micro:bit display, working.
Did you have to increase the STACK_SIZE(s)? if so, which ones?
Regards, Vinayak
From: Kai Ren [mailto:kren@...]
Sent: Sunday, March 25, 2018 3:36 PM To: Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...>; Johan Hedberg <johan.hedberg@...> Cc: zephyr-devel@... Subject: Re: [Zephyr-devel] [Bluetooth mesh]CONFIG_BT_PERIPHERAL, what does it mean?
Hi Vinayak,
I followed your instruction to disable some features above Bluetooth core spec v4.0, like 4.1, 4.2 and 5.0 as follow:
#Controller #5.0 features CONFIG_BT_CTLR_PHY=n CONFIG_BT_CTLR_CHAN_SEL_2=n CONFIG_BT_CTLR_MIN_USED_CHAN=n CONFIG_BT_CTLR_ADV_EXT=n CONFIG_BT_CTLR_PHY_2M=n
#4.2 features CONFIG_BT_CTLR_DATA_LENGTH=n CONFIG_BT_CTLR_DATA_LENGTH_MAX=27 CONFIG_BT_CTLR_PRIVACY=n CONFIG_BT_CTLR_EXT_SCAN_FP=n
#4.1 features CONFIG_BT_CTLR_CONN_PARAM_REQ=n CONFIG_BT_CTLR_LE_PING=n
With this kind of configuration, there are 56 bytes saving, but it’s still not enough for me to squeeze the firmware into RAM. In order to make it happen, made some changes:
After above configuration, the RAM usage is 99.32% and I can:
Thank you for the help!
Regards, Kai
From: "Chettimada, Vinayak Kariappa" <vinayak.kariappa.chettimada@...>
Hi Ken,
As the faulting instruction address is in RAM, I suspect an overflow of some thread call stack. The PB-GATT may not have been tested on micro:bit due to restricted amount of RAM. But, please review the Kconfig option for the controller (me being the maintainer of controller) in menuconfig and disable any options that will not be needed for your usecase, like disabling 4.1 and above features and reducing any buffer counts.
That said, please increase these: CONFIG_MAIN_STACK_SIZE CONFIG_BT_RX_STACK_SIZE
… provided you can find some free RAM space!
Regards, Vinayak
From:
zephyr-devel-bounces@...
[mailto:zephyr-devel-bounces@...]
On Behalf Of Kai Ren
Hi Johan, Thank you for the proposal, I've tested it. I copied microbit_gatt.conf and reduced CONFIG_BT_L2CAP_TX_BUF_COUNT to 2, RAM usage is 99.93%, which can make it fit micro:bit RAM size, but when I use BlueZ to provision it, after OOB output on micro:bit, it seems to be corrupted, a HARD FAULT as below. OOB Number: 549 ***** HARD FAULT ***** Executing thread ID (thread): 0x20001670 Faulting instruction address: 0x200014dc Fatal fault in ISR! Spinning...
I guess that there may be two causes:
So, I have a question that can I enable optimization level for source code compiling? I had used Keil or IAR, their GUI support to configure optimization level, but how can I configure it on Zephyr? I hope it may save some valuable bytes in RAM of micro:bit.
Regards, Kai
On 22/03/2018, 11:39 PM, "Johan Hedberg" <johan.hedberg@...> wrote:
Hi Kai,
On Thu, Mar 22, 2018, Kai Ren wrote: > I’m try to run ./sample/Bluetooth/mesh/ on micro:bit, I found that > current source code for micro:bit just support PB-ADV, don’t support > PB-GATT. So, I want to add PB-GATT on it, but I found that it’s really > hard to pass the build process because it runs out of RAM if I > modified prj_bbc_microbit.conf. > Meanwhile, I also found that there is a configuration flag, > CONFIG_BT_PERIPHERAL, it consumes about 2KB RAM when I enable it, so > I’m just curious that what function does this flag provide? And is it > necessary for PB-GATT on micro:bit? Thanks!
There's actually a samples/bluetooth/mesh/microbit_gatt.conf configuration that's intended to be used for a GATT-based build of the mesh sample. That said, I just tried it and it actually overflows the RAM by 300 bytes. That's much less than 2k however, and hopefully easily to fix. Looking into it now. It might e.g. be possible that the CONFIG_BT_L2CAP_TX_BUF_COUNT=5 variable can be lowered since there was recently an extra segmentation buffer introduced for outgoing ACL packets.
Note: you can select microbit_gatt.conf e.g. by passing the following to cmake: -DCONF_FILE=microbit_gatt.conf
Johan
|
|
What is need of addition authentication in case of #BluetoothMesh if ECDH public key exchanged over OOB ?
#bluetoothmesh
Vikrant More <vikrant8051@...>
Hi, If #BluetoothMesh DEVICE ECDH-public key (oob public key) is exchanged over OOB channel then what is further need of authentication using input-OOB or output-OOB or static-OOB ? Thanks,
|
|
Re: How hacker will hack/impact my BLE device, when ...??
Vikrant More <vikrant8051@...>
Hi, I think we can do OOB pairing, even if Device doesn't have display to share Passkey with user App.1. Create ECDH public-private key pair (only once in Device life) 2. Read ECDH-Public key via Device serial terminal. Create QR code from it & add it in Device packaging. 3. User will scan it with APP & APP will transfer own dynamically created public key over BLE link. 4. Shared secret will created on both side which can be used to encrypt further communication. Thanks, vikrant8051
On Wed, Mar 21, 2018 at 9:13 PM, Vikrant More <vikrant8051@...> wrote:
|
|
Re: [Bluetooth mesh]CONFIG_BT_PERIPHERAL, what does it mean?
Kai Ren
Hi Vinayak,
I followed your instruction to disable some features above Bluetooth core spec v4.0, like 4.1, 4.2 and 5.0 as follow:
#Controller #5.0 features CONFIG_BT_CTLR_PHY=n CONFIG_BT_CTLR_CHAN_SEL_2=n CONFIG_BT_CTLR_MIN_USED_CHAN=n CONFIG_BT_CTLR_ADV_EXT=n CONFIG_BT_CTLR_PHY_2M=n
#4.2 features CONFIG_BT_CTLR_DATA_LENGTH=n CONFIG_BT_CTLR_DATA_LENGTH_MAX=27 CONFIG_BT_CTLR_PRIVACY=n CONFIG_BT_CTLR_EXT_SCAN_FP=n
#4.1 features CONFIG_BT_CTLR_CONN_PARAM_REQ=n CONFIG_BT_CTLR_LE_PING=n
With this kind of configuration, there are 56 bytes saving, but it’s still not enough for me to squeeze the firmware into RAM. In order to make it happen, made some changes:
After above configuration, the RAM usage is 99.32% and I can:
Thank you for the help!
Regards, Kai
From: "Chettimada, Vinayak Kariappa" <vinayak.kariappa.chettimada@...>
Hi Ken,
As the faulting instruction address is in RAM, I suspect an overflow of some thread call stack. The PB-GATT may not have been tested on micro:bit due to restricted amount of RAM. But, please review the Kconfig option for the controller (me being the maintainer of controller) in menuconfig and disable any options that will not be needed for your usecase, like disabling 4.1 and above features and reducing any buffer counts.
That said, please increase these: CONFIG_MAIN_STACK_SIZE CONFIG_BT_RX_STACK_SIZE
… provided you can find some free RAM space!
Regards, Vinayak
From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...]
On Behalf Of Kai Ren
Sent: Friday, March 23, 2018 4:11 AM To: Johan Hedberg <johan.hedberg@...> Cc: zephyr-devel@... Subject: Re: [Zephyr-devel] [Bluetooth mesh]CONFIG_BT_PERIPHERAL, what does it mean?
Hi Johan, Thank you for the proposal, I've tested it. I copied microbit_gatt.conf and reduced CONFIG_BT_L2CAP_TX_BUF_COUNT to 2, RAM usage is 99.93%, which can make it fit micro:bit RAM size, but when I use BlueZ to provision it, after OOB output on micro:bit, it seems to be corrupted, a HARD FAULT as below. OOB Number: 549 ***** HARD FAULT ***** Executing thread ID (thread): 0x20001670 Faulting instruction address: 0x200014dc Fatal fault in ISR! Spinning...
I guess that there may be two causes:
So, I have a question that can I enable optimization level for source code compiling? I had used Keil or IAR, their GUI support to configure optimization level, but how can I configure it on Zephyr? I hope it may save some valuable bytes in RAM of micro:bit.
Regards, Kai
On 22/03/2018, 11:39 PM, "Johan Hedberg" <johan.hedberg@...> wrote:
Hi Kai,
On Thu, Mar 22, 2018, Kai Ren wrote: > I’m try to run ./sample/Bluetooth/mesh/ on micro:bit, I found that > current source code for micro:bit just support PB-ADV, don’t support > PB-GATT. So, I want to add PB-GATT on it, but I found that it’s really > hard to pass the build process because it runs out of RAM if I > modified prj_bbc_microbit.conf. > Meanwhile, I also found that there is a configuration flag, > CONFIG_BT_PERIPHERAL, it consumes about 2KB RAM when I enable it, so > I’m just curious that what function does this flag provide? And is it > necessary for PB-GATT on micro:bit? Thanks!
There's actually a samples/bluetooth/mesh/microbit_gatt.conf configuration that's intended to be used for a GATT-based build of the mesh sample. That said, I just tried it and it actually overflows the RAM by 300 bytes. That's much less than 2k however, and hopefully easily to fix. Looking into it now. It might e.g. be possible that the CONFIG_BT_L2CAP_TX_BUF_COUNT=5 variable can be lowered since there was recently an extra segmentation buffer introduced for outgoing ACL packets.
Note: you can select microbit_gatt.conf e.g. by passing the following to cmake: -DCONF_FILE=microbit_gatt.conf
Johan
|
|
Board Config Files
Justin
I'm attempting to port over a custom board (NRF52832) and I'm a little confused by which config files are still being used (CMAKE build). Should I be putting my configurations in <board>_defconfig, KConfig* files or both? Or should I just be using device tree files now? Thanks, Justin
|
|
Re: [Bluetooth mesh]CONFIG_BT_PERIPHERAL, what does it mean?
Chettimada, Vinayak Kariappa
Hi Ken,
As the faulting instruction address is in RAM, I suspect an overflow of some thread call stack. The PB-GATT may not have been tested on micro:bit due to restricted amount of RAM. But, please review the Kconfig option for the controller (me being the maintainer of controller) in menuconfig and disable any options that will not be needed for your usecase, like disabling 4.1 and above features and reducing any buffer counts.
That said, please increase these: CONFIG_MAIN_STACK_SIZE CONFIG_BT_RX_STACK_SIZE
… provided you can find some free RAM space!
Regards, Vinayak
From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...]
On Behalf Of Kai Ren
Sent: Friday, March 23, 2018 4:11 AM To: Johan Hedberg <johan.hedberg@...> Cc: zephyr-devel@... Subject: Re: [Zephyr-devel] [Bluetooth mesh]CONFIG_BT_PERIPHERAL, what does it mean?
Hi Johan, Thank you for the proposal, I've tested it. I copied microbit_gatt.conf and reduced CONFIG_BT_L2CAP_TX_BUF_COUNT to 2, RAM usage is 99.93%, which can make it fit micro:bit RAM size, but when I use BlueZ to provision it, after OOB output on micro:bit, it seems to be corrupted, a HARD FAULT as below. OOB Number: 549 ***** HARD FAULT ***** Executing thread ID (thread): 0x20001670 Faulting instruction address: 0x200014dc Fatal fault in ISR! Spinning...
I guess that there may be two causes:
So, I have a question that can I enable optimization level for source code compiling? I had used Keil or IAR, their GUI support to configure optimization level, but how can I configure it on Zephyr? I hope it may save some valuable bytes in RAM of micro:bit.
Regards, Kai
On 22/03/2018, 11:39 PM, "Johan Hedberg" <johan.hedberg@...> wrote:
Hi Kai,
On Thu, Mar 22, 2018, Kai Ren wrote: > I’m try to run ./sample/Bluetooth/mesh/ on micro:bit, I found that > current source code for micro:bit just support PB-ADV, don’t support > PB-GATT. So, I want to add PB-GATT on it, but I found that it’s really > hard to pass the build process because it runs out of RAM if I > modified prj_bbc_microbit.conf. > Meanwhile, I also found that there is a configuration flag, > CONFIG_BT_PERIPHERAL, it consumes about 2KB RAM when I enable it, so > I’m just curious that what function does this flag provide? And is it > necessary for PB-GATT on micro:bit? Thanks!
There's actually a samples/bluetooth/mesh/microbit_gatt.conf configuration that's intended to be used for a GATT-based build of the mesh sample. That said, I just tried it and it actually overflows the RAM by 300 bytes. That's much less than 2k however, and hopefully easily to fix. Looking into it now. It might e.g. be possible that the CONFIG_BT_L2CAP_TX_BUF_COUNT=5 variable can be lowered since there was recently an extra segmentation buffer introduced for outgoing ACL packets.
Note: you can select microbit_gatt.conf e.g. by passing the following to cmake: -DCONF_FILE=microbit_gatt.conf
Johan
|
|
Re: [Bluetooth mesh]CONFIG_BT_PERIPHERAL, what does it mean?
Kai Ren
Hi Johan, Thank you for the proposal, I've tested it. I copied microbit_gatt.conf and reduced CONFIG_BT_L2CAP_TX_BUF_COUNT to 2, RAM usage is 99.93%, which can make it fit micro:bit RAM size, but when I use BlueZ to provision it, after OOB output on micro:bit, it seems to be corrupted, a HARD FAULT as below. OOB Number: 549 ***** HARD FAULT ***** Executing thread ID (thread): 0x20001670 Faulting instruction address: 0x200014dc Fatal fault in ISR! Spinning...
I guess that there may be two causes:
So, I have a question that can I enable optimization level for source code compiling? I had used Keil or IAR, their GUI support to configure optimization level, but how can I configure it on Zephyr? I hope it may save some valuable bytes in RAM of micro:bit.
Regards, Kai
On 22/03/2018, 11:39 PM, "Johan Hedberg" <johan.hedberg@...> wrote:
Hi Kai,
On Thu, Mar 22, 2018, Kai Ren wrote:
> I’m try to run ./sample/Bluetooth/mesh/ on micro:bit, I found that > current source code for micro:bit just support PB-ADV, don’t support > PB-GATT. So, I want to add PB-GATT on it, but I found that it’s really > hard to pass the build process because it runs out of RAM if I > modified prj_bbc_microbit.conf. > Meanwhile, I also found that there is a configuration flag, > CONFIG_BT_PERIPHERAL, it consumes about 2KB RAM when I enable it, so > I’m just curious that what function does this flag provide? And is it > necessary for PB-GATT on micro:bit? Thanks!
There's actually a samples/bluetooth/mesh/microbit_gatt.conf configuration that's intended to be used for a GATT-based build of the mesh sample. That said, I just tried it and it actually overflows the RAM by 300 bytes. That's much less than 2k however, and hopefully easily to fix. Looking into it now. It might e.g. be possible that the CONFIG_BT_L2CAP_TX_BUF_COUNT=5 variable can be lowered since there was recently an extra segmentation buffer introduced for outgoing ACL packets.
Note: you can select microbit_gatt.conf e.g. by passing the following to cmake: -DCONF_FILE=microbit_gatt.conf
Johan
|
|
Re: Firmware over the air (FOTA) and FCB support in 1.11.0
laczenJMS
Hi Carles,
toggle quoted messageShow quoted text
I will add the lifetime calculation to the documentation of NVS. Regarding the comparison between FCB and NVS: FCB would need an additional layer to be able to get this functionality (which is the config layer). The following decisions are influencing flash wear: 1. Config system: store name-value pairs as strings: this makes the difference between 10 bytes and 26 bytes (should really be 27 because I forgot the zero termination). 2. FCB storage: use of scratch sector this reduces the lifetime to the amount of scratch sector erases. Decision 1 will reduce life with a factor 2.6, Decision 2 will reduce life with at least a factor 2. Kind regards, Jehudi
Date: Thu, 22 Mar 2018 15:27:23 +0000
|
|
Re: [Bluetooth mesh]CONFIG_BT_PERIPHERAL, what does it mean?
Hi Kai,
On Thu, Mar 22, 2018, Kai Ren wrote: Meanwhile, I also found that there is a configuration flag,I forgot to answer your question regarding CONFIG_BT_PERIPHERAL: it enables support for the Peripheral GAP role, which is definitely something you need to have a GATT server for PB-GATT and GATT Proxy. Johan
|
|
Re: [Bluetooth mesh]CONFIG_BT_PERIPHERAL, what does it mean?
Hi Kai,
On Thu, Mar 22, 2018, Kai Ren wrote: I’m try to run ./sample/Bluetooth/mesh/ on micro:bit, I found thatThere's actually a samples/bluetooth/mesh/microbit_gatt.conf configuration that's intended to be used for a GATT-based build of the mesh sample. That said, I just tried it and it actually overflows the RAM by 300 bytes. That's much less than 2k however, and hopefully easily to fix. Looking into it now. It might e.g. be possible that the CONFIG_BT_L2CAP_TX_BUF_COUNT=5 variable can be lowered since there was recently an extra segmentation buffer introduced for outgoing ACL packets. Note: you can select microbit_gatt.conf e.g. by passing the following to cmake: -DCONF_FILE=microbit_gatt.conf Johan
|
|