Date   

Re: Settings subsystem

robert.konc@...
 

Hi

Thanks for answer, Andrzej.

Find that I lock value after first key find in flash. I did not know that FBC scan all keys in flash. The problem is that some keys are writen more times and after long period could this be problem. I will try to implement settings with NFFS.

Regards,
Robert


Re: Settings subsystem

Puzdrowski, Andrzej
 

So while loading settings subsystem loads all available in storage kay-value pairs. Guaranteed are that it will load the most recently values as the last and  then h_commit handler will be executed.

Settings doesn’t implement any cash for value-pair while loading.

For FCB-backend there is a try patch which intended to mitigate inconvenience described above: https://github.com/zephyrproject-rtos/zephyr/pull/11574

 

So can you check whether what you expected was loaded just in next step?

 

 

 

From: devel@... [mailto:devel@...] On Behalf Of robert.konc@...
Sent: Tuesday, December 04, 2018 11:57 AM
To: devel@...
Subject: [Zephyr-devel] Settings subsystem

 

I'm using settings to save application data.
But after one setting was writen more than once and application is restarted I get after call settings_load() first value and not last one.
For writing I use settings_save_one().

This is part of flash where settings are stored.

îîÿÀ.ÿ...SENP/SEN/RNG=200000.000000ú.SENP/SEN/SENS=0.003000).SENP/SEN/OFFS=0.000000..SENP/RNG/MIN=-100000.000000ã.SENP/RNG/ZERO=0.000000*.SENP/RNG/MAX=10000.000000}.SENP/FLT/TIME=5000l.SENP/FLT/CUTF=50æ.SENP/SEN/OFFS=-0.000055ü.SENP/SEN/OFFS=-0.000054ûÿÿÿÿÿ

Settings key "SENP/SEN/OFFS" is writen twice. But when I call settings_load() I get "0.000000" instead "-0.000054".

Here is also Hex valuje.

EE EE FF C0 01 FF 00 00  1A 53 45 4E 50 2F 53 45

4E 2F 52 4E 47 3D 32 30  30 30 30 30 2E 30 30 30

30 30 30 FA 16 53 45 4E  50 2F 53 45 4E 2F 53 45

4E 53 3D 30 2E 30 30 33  30 30 30 29 16 53 45 4E

50 2F 53 45 4E 2F 4F 46  46 53 3D 30 2E 30 30 30

30 30 30 91 1B 53 45 4E  50 2F 52 4E 47 2F 4D 49

4E 3D 2D 31 30 30 30 30  30 2E 30 30 30 30 30 30

E3 16 53 45 4E 50 2F 52  4E 47 2F 5A 45 52 4F 3D

30 2E 30 30 30 30 30 30  2A 19 53 45 4E 50 2F 52

4E 47 2F 4D 41 58 3D 31  30 30 30 30 2E 30 30 30

30 30 30 7D 12 53 45 4E  50 2F 46 4C 54 2F 54 49

4D 45 3D 35 30 30 30 6C  10 53 45 4E 50 2F 46 4C

54 2F 43 55 54 46 3D 35  30 E6 17 53 45 4E 50 2F

53 45 4E 2F 4F 46 46 53  3D 2D 30 2E 30 30 30 30

35 35 FC 17 53 45 4E 50  2F 53 45 4E 2F 4F 46 46

53 3D 2D 30 2E 30 30 30  30 35 34 FB FF FF FF FF


Regards,
Robert


Settings subsystem

robert.konc@...
 

I'm using settings to save application data.
But after one setting was writen more than once and application is restarted I get after call settings_load() first value and not last one.
For writing I use settings_save_one().

This is part of flash where settings are stored.

îîÿÀ.ÿ...SENP/SEN/RNG=200000.000000ú.SENP/SEN/SENS=0.003000).SENP/SEN/OFFS=0.000000..SENP/RNG/MIN=-100000.000000ã.SENP/RNG/ZERO=0.000000*.SENP/RNG/MAX=10000.000000}.SENP/FLT/TIME=5000l.SENP/FLT/CUTF=50æ.SENP/SEN/OFFS=-0.000055ü.SENP/SEN/OFFS=-0.000054ûÿÿÿÿÿ

Settings key "SENP/SEN/OFFS" is writen twice. But when I call settings_load() I get "0.000000" instead "-0.000054".

Here is also Hex valuje.
EE EE FF C0 01 FF 00 00  1A 53 45 4E 50 2F 53 45
4E 2F 52 4E 47 3D 32 30  30 30 30 30 2E 30 30 30
30 30 30 FA 16 53 45 4E  50 2F 53 45 4E 2F 53 45
4E 53 3D 30 2E 30 30 33  30 30 30 29 16 53 45 4E
50 2F 53 45 4E 2F 4F 46  46 53 3D 30 2E 30 30 30
30 30 30 91 1B 53 45 4E  50 2F 52 4E 47 2F 4D 49
4E 3D 2D 31 30 30 30 30  30 2E 30 30 30 30 30 30
E3 16 53 45 4E 50 2F 52  4E 47 2F 5A 45 52 4F 3D
30 2E 30 30 30 30 30 30  2A 19 53 45 4E 50 2F 52
4E 47 2F 4D 41 58 3D 31  30 30 30 30 2E 30 30 30
30 30 30 7D 12 53 45 4E  50 2F 46 4C 54 2F 54 49
4D 45 3D 35 30 30 30 6C  10 53 45 4E 50 2F 46 4C
54 2F 43 55 54 46 3D 35  30 E6 17 53 45 4E 50 2F
53 45 4E 2F 4F 46 46 53  3D 2D 30 2E 30 30 30 30
35 35 FC 17 53 45 4E 50  2F 53 45 4E 2F 4F 46 46
53 3D 2D 30 2E 30 30 30  30 35 34 FB FF FF FF FF

Regards,
Robert


Re: Is bluetooth sample "peripheral" still working well?

Johan Hedberg
 

Hi Jun,

On 4 Dec 2018, at 0.08, Li, Jun R <jun.r.li@intel.com> wrote:
Thanks for the quick reply! Is there an issue addressing the 9 second delay problem during the booting process? It seems the issue #11780 (https://github.com/zephyrproject-rtos/zephyr/issues/11780) is similar though it is using mesh network stack.
Based on bisecting it seems commit 4d94257162b22f37104e9f85238ed7c3486c5a1c is introducing the issue. Reverting it made the delay and log_strdup failure go away for me. It also fixed the timestamps (they shouldn’t be all zero).

And how can I get rid of the warning "No ID address"? It always happens on every booting up process.
Why do you want to get rid of it? It’s there to remind app writers that they need to do something extra (i.e. call settings_load) after calling bt_enable().

Actually, I found another "HARD FAULT" issue if I don't erase all of the flash memory after flashing the firmware built from the latest master. I'll try to identify if the is caused by my app or just a generic one. But basically, this never happened before I rebased the app.
This is something I haven’t seen. What do you mean by not erasing all flash memory? Which parts don’t you erase? What was there from before? You might have uncovered some issue with the settings subsystem if there’s some garbage data there. It’s also worth excluding the possibility of stack overflow, since the settings code increases stack usage. So try increasing your stack sizes before anything else.

Johan


Re: Opus codec on nrf52840

nicolas lantz
 

Thanks you for the reponse.
I took the time to extract the modified opus library code from the Smart Ready project (from the .exe to linux) and compared it to the origin opus lib.
Now i will try to use it in a zephry project

Regards,
 
Nicolas
Nicolas LANTZ
M : +33 (0)6 19 07 43 43
T : +33 (0)9 52 96 81 86
www.ubicore.net
Le 29/11/2018 à 12:56, Zięcik, Piotr a écrit :

Hello.

 

I can recommend looking into https://www.nordicsemi.com/eng/Products/Bluetooth-low-energy/nRFready-Smart-Remote-3-for-nRF52-Series

Unfortunately it is not based on the Zephyr, however it implements audio streaming using Opus and contains an optimized version of the codec

(with reduced memory requirements as well as using DPS extensions available on the Nordic chips).

 

If you require any further information, feel free to contact me.

Piotr ZIĘCIK | Senior Firmware Engineer
M +48 698 726 973| Kraków, Poland
nordicsemi.com | devzone.nordicsemi.com

Nordic_logo_signature

 

From: Cufi, Carles
Sent: Thursday, November 29, 2018 12:49 PM
To: nicolas lantz <nicolas.lantz@...>; devel@...; Zięcik, Piotr <Piotr.Ziecik@...>
Subject: RE: [Zephyr-devel] Opus codec on nrf52840

 

+ Piotr

 

From: devel@... <devel@...> On Behalf Of nicolas lantz
Sent: 29 November 2018 12:41
To: devel@...
Subject: [Zephyr-devel] Opus codec on nrf52840

 

Hi,

I would like to use the Opus codec with zephyr on a nrf52840 to encode or decode an audio stream.
Has anyone have a suggestion on this project?

Regards,
 
Nicolas
 


Re: Is bluetooth sample "peripheral" still working well?

Li, Jun R
 

Hi Johan,
Thanks for the quick reply! Is there an issue addressing the 9 second delay problem during the booting process? It seems the issue #11780 (https://github.com/zephyrproject-rtos/zephyr/issues/11780) is similar though it is using mesh network stack.

And how can I get rid of the warning "No ID address"? It always happens on every booting up process.

Actually, I found another "HARD FAULT" issue if I don't erase all of the flash memory after flashing the firmware built from the latest master. I'll try to identify if the is caused by my app or just a generic one. But basically, this never happened before I rebased the app.

Thank you!

Regards,
Jun

On 12/3/18, 13:16, "Hedberg, Johan" <johan.hedberg@intel.com> wrote:

Hi,


> On 3 Dec 2018, at 22.03, Li, Jun R <jun.r.li@intel.com> wrote:
> [00:00:00.000,000] <inf> bt_hci_core.hci_vs_init: HW Platform: Nordic Semiconductor (0x0002)
> [00:00:00.000,000] <inf> bt_hci_core.hci_vs_init: HW Variant: nRF51x (0x0001)
> [00:00:00.000,000] <inf> bt_hci_core.hci_vs_init: Firmware: Standard Bluetooth controller (0x00) Version 1.13 Build 99
> [00:00:00.000,000] <wrn> bt_hci_core.bt_init: No ID address. Expecting one to come from storage.

This is normal when CONFIG_BT_SETTINGS=y is enabled. In such a case the identity address isn’t initialised until the app calls settings_load(), since the identity may be stored in flash.

> [00:00:00.000,000] <inf> bt_hci_core.bt_dev_show_info: Identity: <log_strdup alloc failed>

This shows that the identity has been successfully initialised as a consequence of calling settings_load(), however apparently there are too few log buffers available to log the string-format address.

> • There are about 9 seconds delay between the first message “Bluetooth initialized” and the second one “Advertising successfully started” every time when the board restarts. Not sure what is blocking the booting process.

You’re not the first one to report something like this - it needs to be investigated.

> • I got a “No ID address” warning which is highlighted in red above. The problem never happened before. Is it a new feature? And Does any board need to be provisioned with an ID address before being used from now on?

As I mentioned earlier this is a non-issue. The identity does get loaded properly but there’s an issue allocating a log buffer for its string representation. In general I have a slight suspicion that all these issues could somehow be related to the new logging subsystem.

Johan


Re: Is bluetooth sample "peripheral" still working well?

Johan Hedberg
 

Hi,


On 3 Dec 2018, at 22.03, Li, Jun R <jun.r.li@intel.com> wrote:
[00:00:00.000,000] <inf> bt_hci_core.hci_vs_init: HW Platform: Nordic Semiconductor (0x0002)
[00:00:00.000,000] <inf> bt_hci_core.hci_vs_init: HW Variant: nRF51x (0x0001)
[00:00:00.000,000] <inf> bt_hci_core.hci_vs_init: Firmware: Standard Bluetooth controller (0x00) Version 1.13 Build 99
[00:00:00.000,000] <wrn> bt_hci_core.bt_init: No ID address. Expecting one to come from storage.
This is normal when CONFIG_BT_SETTINGS=y is enabled. In such a case the identity address isn’t initialised until the app calls settings_load(), since the identity may be stored in flash.

[00:00:00.000,000] <inf> bt_hci_core.bt_dev_show_info: Identity: <log_strdup alloc failed>
This shows that the identity has been successfully initialised as a consequence of calling settings_load(), however apparently there are too few log buffers available to log the string-format address.

• There are about 9 seconds delay between the first message “Bluetooth initialized” and the second one “Advertising successfully started” every time when the board restarts. Not sure what is blocking the booting process.
You’re not the first one to report something like this - it needs to be investigated.

• I got a “No ID address” warning which is highlighted in red above. The problem never happened before. Is it a new feature? And Does any board need to be provisioned with an ID address before being used from now on?
As I mentioned earlier this is a non-issue. The identity does get loaded properly but there’s an issue allocating a log buffer for its string representation. In general I have a slight suspicion that all these issues could somehow be related to the new logging subsystem.

Johan


Is bluetooth sample "peripheral" still working well?

Li, Jun R
 

Hi there,

I’m trying to rebase my project which is based on NRF51822 SoC from V1.13 to the latest version but found the application doesn’t work anymore. It seems the application suffers from some issues related to BT settings. To identify the issue, I tried the BLE sample “sample/Bluetooth/peripheral” with the board “nrf51_pca10028” which is the one I’m using. The build process ran well, and flashing was good. However, I found the sample application also suffers from the same issue I found on my project, as shown below:

 

***** Booting Zephyr OS zephyr-v1.13.0-2303-g55f091f *****

Bluetooth initialized

Advertising successfully started

[00:00:00.000,000] <inf> bt_hci_core.hci_vs_init: HW Platform: Nordic Semiconductor (0x0002)

[00:00:00.000,000] <inf> bt_hci_core.hci_vs_init: HW Variant: nRF51x (0x0001)

[00:00:00.000,000] <inf> bt_hci_core.hci_vs_init: Firmware: Standard Bluetooth controller (0x00) Version 1.13 Build 99

[00:00:00.000,000] <wrn> bt_hci_core.bt_init: No ID address. Expecting one to come from storage.

[00:00:00.000,000] <inf> bt_hci_core.bt_dev_show_info: Identity: <log_strdup alloc failed>

[00:00:00.000,000] <inf> bt_hci_core.bt_dev_show_info: HCI: version 5.0 (0x09) revision 0x0000, manufacturer 0x05f1

[00:00:00.000,000] <inf> bt_hci_core.bt_dev_show_info: LMP: version 5.0 (0x09) subver 0xffff

 

 

I found two issues:

  1. There are about 9 seconds delay between the first message “Bluetooth initialized” and the second one “Advertising successfully started” every time when the board restarts. Not sure what is blocking the booting process.
  2. I got a “No ID address” warning which is highlighted in red above. The problem never happened before. Is it a new feature? And Does any board need to be provisioned with an ID address before being used from now on?

 

Does anyone know if I’m missing something for correctly using this sample?

 

Thank you!

 

Jun Li @ Intel Corporation

 


Running rpl border and rpl node on bluetooth

Akash Naidu <akashnaiduece@...>
 

Hi All,
Currently i am working on IPV6 over BLE mesh, For that i have chosen reference of RPL Border and RPL Node of zephyr  RTOS.I have seen examples of rpl node and border router, but those were integrated with IEEE 802.15.4 network.
How to integrate RPL node and border router with Bluetooth(nrf52832) to transfer IPV6 packets?
Could you please suggest me some examples that integration of Bluetooth with rpl node or border router?
 
please provide some useful links or information about forming mesh over IPV6.

I would like to form the mesh on IPV6 over BLE, not on Bluetooth mesh profile(on/off example etc...)

Advance in thanks.

BR
Akash.


Re: [BLE Mesh] How many nodes can zephyr mesh support and how about the throughput?

cheney chen <wjchen7@...>
 

Hi Johan,

Thanks a lot for the useful reply. I noticed your reply in github as well. Thanks a lot!

Thanks,
Vincent


From: Hedberg, Johan <johan.hedberg@...>
Sent: Saturday, December 1, 2018 9:35 PM
To: cheney chen
Cc: devel@...
Subject: Re: [Zephyr-devel] [BLE Mesh] How many nodes can zephyr mesh support and how about the throughput?
 
Hi,


> On 1 Dec 2018, at 16.44, cheney chen <wjchen7@...> wrote:
>
> Recently I am investigating on adopting a possible BLE Mesh solution in my project. Just found there is BLE mesh support in zephyr now. I am wondering how many nodes can zephyr mesh support? And how about the throughout in point-to-point transfer (e.g. can it support up to 10KB/s throughput in BLE mesh OTA)?
>
> Thanks in advance for any answer to this question. It'd be better if any document or link.

I’ve tried to answer your questions in the GitHub issue (#11789) that you opened before sending this email. In the future, please use either to GitHub *or* the mailing list, but not both, since otherwise we’ll end up having duplicated and unconnected discussions on the same topic.

Johan


Re: [BLE Mesh] How many nodes can zephyr mesh support and how about the throughput?

Johan Hedberg
 

Hi,


On 1 Dec 2018, at 16.44, cheney chen <wjchen7@hotmail.com> wrote:

Recently I am investigating on adopting a possible BLE Mesh solution in my project. Just found there is BLE mesh support in zephyr now. I am wondering how many nodes can zephyr mesh support? And how about the throughout in point-to-point transfer (e.g. can it support up to 10KB/s throughput in BLE mesh OTA)?

Thanks in advance for any answer to this question. It'd be better if any document or link.
I’ve tried to answer your questions in the GitHub issue (#11789) that you opened before sending this email. In the future, please use either to GitHub *or* the mailing list, but not both, since otherwise we’ll end up having duplicated and unconnected discussions on the same topic.

Johan


[BLE Mesh] How many nodes can zephyr mesh support and how about the throughput?

cheney chen <wjchen7@...>
 

Hi,

Recently I am investigating on adopting a possible BLE Mesh solution in my project. Just found there is BLE mesh support in zephyr now. I am wondering how many nodes can zephyr mesh support? And how about the throughout in point-to-point transfer (e.g. can it support up to 10KB/s throughput in BLE mesh OTA)?

Thanks in advance for any answer to this question. It'd be better if any document or link.

Thanks,
Vincent.


Re: Minimum one second delay in activating board LED in Zephyr Bluetooth Mesh based on OnOff applic

vikrant8051 <vikrant8051@...>
 

Hi,
It is because of new logging sub-system.
And If you disable CONFIG_BT_DEBUG_LOG to avoid that then provisioned NODE
takes 10+ seconds to initialized the Mesh.

I've already raised issue for that ...

Regards,
vikrant

On Fri, Nov 30, 2018 at 6:42 PM frv <F.Vieren@...> wrote:
Hi Zephyr community, bluetooth Mesh fans,

I played around with the Zephyr Mesh OnOff applic running on a Nordic nRF52 board.
https://docs.zephyrproject.org/1.13.0/samples/boards/nrf52/mesh/onoff-app/README.html

I made a mesh network with 4 nRF52 boards, 1 running a generic onoff client model as client node, 2 running a generic onoff server model as peripheral node and 1 acting purely as relay node to extend BLE coverage/range.
For setting up the mesh network(provisioning) I rely on the tool meshctl.

All seems to work pretty well, although independent of placing a relay node in between the client and server node, it takes mostly roughly at least 1 second after the button is pressed on the client node to light up one of the green LEDs on the server node (regardless if it close or far (maybe 150 meters) from the client node).

Only on the relay node the relay mode is active, on the other nodes the applic is running with RELAY DISABLED define (as unmodified OnOff . All other nodes is the relay function not enabled. I must say for all the nodes the 4 elements are defined but on each node only one element is bounded and on the client node only the generic onoff client model (thus linked to the primary element) publishes to a group address. On the server nodes only one element (1 to primary element on other node to second element) is subscribed to the group address.

This minimum 1 second delay is this normal after pushing the button on the client node? If not which (time?) parameters can be further tuned, is there a cost?

BTW it is great to have these Mesh examples around in Zephyr  to speed up proto typing in a Bluetooth Mesh environment. Thanks! Keep on the good work.

Thanks in advance.

Best regards,
Frank






Minimum one second delay in activating board LED in Zephyr Bluetooth Mesh based on OnOff applic

frv
 

Hi Zephyr community, bluetooth Mesh fans,

I played around with the Zephyr Mesh OnOff applic running on a Nordic nRF52 board.
https://docs.zephyrproject.org/1.13.0/samples/boards/nrf52/mesh/onoff-app/README.html

I made a mesh network with 4 nRF52 boards, 1 running a generic onoff client model as client node, 2 running a generic onoff server model as peripheral node and 1 acting purely as relay node to extend BLE coverage/range.
For setting up the mesh network(provisioning) I rely on the tool meshctl.

All seems to work pretty well, although independent of placing a relay node in between the client and server node, it takes mostly roughly at least 1 second after the button is pressed on the client node to light up one of the green LEDs on the server node (regardless if it close or far (maybe 150 meters) from the client node).

Only on the relay node the relay mode is active, on the other nodes the applic is running with RELAY DISABLED define (as unmodified OnOff . All other nodes is the relay function not enabled. I must say for all the nodes the 4 elements are defined but on each node only one element is bounded and on the client node only the generic onoff client model (thus linked to the primary element) publishes to a group address. On the server nodes only one element (1 to primary element on other node to second element) is subscribed to the group address.

This minimum 1 second delay is this normal after pushing the button on the client node? If not which (time?) parameters can be further tuned, is there a cost?

BTW it is great to have these Mesh examples around in Zephyr to speed up proto typing in a Bluetooth Mesh environment. Thanks! Keep on the good work.

Thanks in advance.

Best regards,
Frank


Re: logging subsys questions / concerns

Boie, Andrew P
 

apboie: I think the k_sleep() call in the log thread is not ideal, the system might
be idle and have some bandwidth to dump logs, but instead the log thread can
be sitting there in a sleep() call. In addition the log thread will be waking up all
the time even when it has nothing to do.
Actually, I think I'm mistaken, the k_wakeup() calls will ensure that it doesn't sleep for the full amount each iteration. We're probably fine. It only wakes up on its own by default every 1000ms, not a big deal.

I opened bugs for the other items talked about.

Andrew


Re: logging subsys questions / concerns

Zięcik, Piotr <piotr.ziecik@...>
 

5) What does it mean if CONFIG_LOG_INPLACE_PROCESS=n, but
CONFIG_LOG_PROCESS_THREAD=n? Can we simplify our Kconfigs?
Krch: It is possible to use deferred mode and not use the thread. Most likely that would be the case when multithreading is disabled.
Still not quite following you, but I'll look at the code some more.
Hi.

Since Krzysztof already left the office, I will try to answer that.

When logs are deffered, you need to call LOG_PROCESS() periodically to format log messages and push them to the backends.
If CONFIG_LOG_PROCESS_THREAD=y, you are creating dedicated thread which does that for you and you just don't care about
that in your application. If the CONFIG_LOG_PROCESS_THREAD is set to n, then calling LOG_PROCESS() is the application responsibility.
Also, if multithreading is disabled, "manual" calling of LOG_PROCESS() becomes the only way to use deffered logs.

PIOTR ZIĘCIK | Senior Firmware Engineer
M +48 698 726 973| Kraków, Poland
nordicsemi.com | devzone.nordicsemi.com


-----Original Message-----
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> On Behalf Of Boie, Andrew P
Sent: Thursday, November 29, 2018 6:28 PM
To: Cufi, Carles <Carles.Cufi@nordicsemi.no>; Chruściński, Krzysztof <Krzysztof.Chruscinski@nordicsemi.no>; zephyr-devel <zephyr-devel@lists.zephyrproject.org>; Rzeszutko, Jakub <Jakub.Rzeszutko@nordicsemi.no>
Cc: zephyr-devel <zephyr-devel@lists.zephyrproject.org>
Subject: Re: [Zephyr-devel] logging subsys questions / concerns

Hi Krzystof,

For some reason I did not get your email, Carles had to forward to me.

1) The default priority of the logging thread is -2. This is a very
high non preemptive priority. I don't understand why the logging
background thread doesn't run at the lowest preemptible priority on
the system, like the idle thread. If people are running out of buffer
space then they need to make their buffers bigger or switch to synchronous logging.
Krch:  Intention was to set it to the lowest possible value - K_LOWEST_APPLICATION_THREAD_PRIO. Now I've noticed that it's -2 only when CONFIG_PREEMPT_ENABLED is set. So it can be updated or fixed to K_LOWEST_APPLICATION_THREAD_PRIO in the code.

apboie: OK cool

I think we need to move the
invocation of LOG_PANIC until *much* later, when we decide we need to
hang the system instead of just aborting the faulting thread.
Krch: please suggest the better place. Note that ideally it should be as early as possible when non-recoverable error is hit since by doing that we reduce the risk of losing any logs (as before panic we keep using msg pool so there is a chance of overflow).

apboie: Good point, we don't want to deal with overflow in this situation. I think what we need is an API call to clear the panic mode state if _SysFatalErrorHandler() decides not to hang the system, immediately before the API call to k_thread_abort().

3) It does not appear that there is any support for invoking LOG()
macros from user mode, which severely limits its usability. Until
there is an answer to this, conversations about default mapping
printk() to the log subsystem really scare me. Is LOG intended to be
used by end user applications or just internally to the kernel?
Krch: currenly it is not supported, should be addded

apboie: Cool. I can help with this. I'll open a bug.

I think CONFIG_LOG_PROCESS_SLEEP_MS and
CONFIG_LOG_PROCESS_TRIGGER_THRESHOLD should be completely removed.
Krch: Speed was the purpose of not using semaphores and sticking to simple counter. Currently, it takes ~250 cycles (nrf52 - ~4us @64MHz) to log an average log message (up to 2 arguments). k_sem_give would add 1,5us so logging time would increase 4us->5,5us. Is that acceptable? I don't know. What do we gain? Solution is cleaner. Is it worth ~35% performance degradation?

apboie: I think the k_sleep() call in the log thread is not ideal, the system might be idle and have some bandwidth to dump logs, but instead the log thread can be sitting there in a sleep() call. In addition the log thread will be waking up all the time even when it has nothing to do.

As mentioned in my follow-up email, what I really think we need is instead of a semaphore, drop the custom list implementation and just use a k_queue. They are fast, are callable from IRQ context, and with the variant k_queue_alloc_append() API, also callable from user mode (when we cross that bridge). Producer-consumer problems like this are what k_queues are intended for.

If you can show using a k_queue would add a lot of overhead I could be convinced otherwise, but I really thing we should pursue this route as it will also make the code simpler and let the scheduler do its job. How are you measuring latencies btw?

5) What does it mean if CONFIG_LOG_INPLACE_PROCESS=n, but
CONFIG_LOG_PROCESS_THREAD=n? Can we simplify our Kconfigs?
Krch: It is possible to use deferred mode and not use the thread. Most likely that would be the case when multithreading is disabled.

Still not quite following you, but I'll look at the code some more.

Andrew


Re: logging subsys questions / concerns

Boie, Andrew P
 

Hi Krzystof,

For some reason I did not get your email, Carles had to forward to me.

1) The default priority of the logging thread is -2. This is a very
high non preemptive priority. I don't understand why the logging
background thread doesn't run at the lowest preemptible priority on
the system, like the idle thread. If people are running out of buffer
space then they need to make their buffers bigger or switch to synchronous logging.
Krch:  Intention was to set it to the lowest possible value - K_LOWEST_APPLICATION_THREAD_PRIO. Now I've noticed that it's -2 only when CONFIG_PREEMPT_ENABLED is set. So it can be updated or fixed to K_LOWEST_APPLICATION_THREAD_PRIO in the code.

apboie: OK cool

I think we need to move the
invocation of LOG_PANIC until *much* later, when we decide we need to
hang the system instead of just aborting the faulting thread.
Krch: please suggest the better place. Note that ideally it should be as early as possible when non-recoverable error is hit since by doing that we reduce the risk of losing any logs (as before panic we keep using msg pool so there is a chance of overflow).

apboie: Good point, we don't want to deal with overflow in this situation. I think what we need is an API call to clear the panic mode state if _SysFatalErrorHandler() decides not to hang the system, immediately before the API call to k_thread_abort().

3) It does not appear that there is any support for invoking LOG()
macros from user mode, which severely limits its usability. Until
there is an answer to this, conversations about default mapping
printk() to the log subsystem really scare me. Is LOG intended to be
used by end user applications or just internally to the kernel?
Krch: currenly it is not supported, should be addded

apboie: Cool. I can help with this. I'll open a bug.

I think CONFIG_LOG_PROCESS_SLEEP_MS and
CONFIG_LOG_PROCESS_TRIGGER_THRESHOLD should be completely removed.
Krch: Speed was the purpose of not using semaphores and sticking to simple counter. Currently, it takes ~250 cycles (nrf52 - ~4us @64MHz) to log an average log message (up to 2 arguments). k_sem_give would add 1,5us so logging time would increase 4us->5,5us. Is that acceptable? I don't know. What do we gain? Solution is cleaner. Is it worth ~35% performance degradation?

apboie: I think the k_sleep() call in the log thread is not ideal, the system might be idle and have some bandwidth to dump logs, but instead the log thread can be sitting there in a sleep() call. In addition the log thread will be waking up all the time even when it has nothing to do.

As mentioned in my follow-up email, what I really think we need is instead of a semaphore, drop the custom list implementation and just use a k_queue. They are fast, are callable from IRQ context, and with the variant k_queue_alloc_append() API, also callable from user mode (when we cross that bridge). Producer-consumer problems like this are what k_queues are intended for.

If you can show using a k_queue would add a lot of overhead I could be convinced otherwise, but I really thing we should pursue this route as it will also make the code simpler and let the scheduler do its job. How are you measuring latencies btw?

5) What does it mean if CONFIG_LOG_INPLACE_PROCESS=n, but
CONFIG_LOG_PROCESS_THREAD=n? Can we simplify our Kconfigs?
Krch: It is possible to use deferred mode and not use the thread. Most likely that would be the case when multithreading is disabled.

Still not quite following you, but I'll look at the code some more.

Andrew


Re: logging subsys questions / concerns

Carles Cufi
 

Re-sending since apparently this email never reached its destination.

 

From: Chruściński, Krzysztof <Krzysztof.Chruscinski@...>
Sent: 29 November 2018 07:54
To: Cufi, Carles <Carles.Cufi@...>; Boie, Andrew P <andrew.p.boie@...>; zephyr-devel <zephyr-devel@...>; Rzeszutko, Jakub <Jakub.Rzeszutko@...>
Subject: RE: logging subsys questions / concerns

 

Hi Andrew,

 

Thanks for valid feedback. I’ve put my comments below.

 

Regards,

Krzysztof

 

-----Original Message-----
From: Cufi, Carles
Sent: Wednesday, November 28, 2018 9:40 PM
To: Boie, Andrew P <andrew.p.boie@...>; zephyr-devel <zephyr-devel@...>; Chruściński, Krzysztof <Krzysztof.Chruscinski@...>; Rzeszutko, Jakub <Jakub.Rzeszutko@...>
Subject: RE: logging subsys questions / concerns

 

Hi Andrew,

 

Thanks for all the feedback.

As agreed on Slack I am copying Krzysztof and Jakub here so that they see your comments and then, if applicable, we can create one or more issues alongside the ones that Paul has already opened.

 

Regards,

 

Carles

 

> -----Original Message-----

> From: devel@... <devel@...> On

> Behalf Of Boie, Andrew P

> Sent: 28 November 2018 21:01

> To: zephyr-devel <zephyr-devel@...>

> Subject: [Zephyr-devel] logging subsys questions / concerns

>

> I've been looking at the logging subsystem code and I wanted to bring

> up some topics.

>

> 1) The default priority of the logging thread is -2. This is a very

> high non preemptive priority. I don't understand why the logging

> background thread doesn't run at the lowest preemptible priority on

> the system, like the idle thread. If people are running out of buffer

> space then they need to make their buffers bigger or switch to synchronous logging.

Krch:  Intention was to set it to the lowest possible value - K_LOWEST_APPLICATION_THREAD_PRIO. Now I’ve noticed that it’s -2 only when CONFIG_PREEMPT_ENABLED is set. So it can be updated or fixed to K_LOWEST_APPLICATION_THREAD_PRIO in the code.

 

> 2) The panic mode handling is not correct. It gets called from

> _NanoFatalErrorHandler, which flushes the log and then sets the

> panic_mode global *permanently* to true. This is not a good policy.

> NanoFatalErrorHandler getting called does not necessarily mean that

> the system has completely crashed, it's quite possible that the damage

> is limited to one thread dying, with the rest of the threads (and the

> overall system) still running just fine. I think we need to move the

> invocation of LOG_PANIC until *much* later, when we decide we need to

> hang the system instead of just aborting the faulting thread.

Krch: please suggest the better place. Note that ideally it should be as early as possible when non-recoverable error is hit since by doing that we reduce the risk of losing any logs (as before panic we keep using msg pool so there is a chance of overflow).

>

> 3) It does not appear that there is any support for invoking LOG()

> macros from user mode, which severely limits its usability. Until

> there is an answer to this, conversations about default mapping

> printk() to the log subsystem really scare me. Is LOG intended to be

> used by end user applications or just internally to the kernel?

Krch: currenly it is not supported, should be addded

>

> 4) The synchronization between threads invoking log points, and the

> background logging thread, do not make sense to me, and seem to be a

> way of dealing with making the log thread default to a very high non-

> preemptible priority, which I already complained about.

>

> I think CONFIG_LOG_PROCESS_SLEEP_MS and

> CONFIG_LOG_PROCESS_TRIGGER_THRESHOLD should be completely removed.

> Introduce a k_sem with initial count 0 and max count UINT_MAX. Log

> points have the caller give the semaphore every time something is

> added to the log buffer, and have the background thread simply do a

> blocking k_sem_take(). So much simpler, and we rely on the scheduler

> to do its job instead of this weird setup where the log thread is high

> priority but sleeps for hard-coded intervals.

Krch: Speed was the purpose of not using semaphores and sticking to simple counter. Currently, it takes ~250 cycles (nrf52 - ~4us @64MHz) to log an average log message (up to 2 arguments). k_sem_give would add 1,5us so logging time would increase 4us->5,5us. Is that acceptable? I don’t know. What do we gain? Solution is cleaner. Is it worth ~35% performance degradation?

>

> 5) What does it mean if CONFIG_LOG_INPLACE_PROCESS=n, but

> CONFIG_LOG_PROCESS_THREAD=n? Can we simplify our Kconfigs?

Krch: It is possible to use deferred mode and not use the thread. Most likely that would be the case when multithreading is disabled.

>

>

>

 


Re: Opus codec on nrf52840

Zięcik, Piotr <piotr.ziecik@...>
 

Hello.

 

I can recommend looking into https://www.nordicsemi.com/eng/Products/Bluetooth-low-energy/nRFready-Smart-Remote-3-for-nRF52-Series

Unfortunately it is not based on the Zephyr, however it implements audio streaming using Opus and contains an optimized version of the codec

(with reduced memory requirements as well as using DPS extensions available on the Nordic chips).

 

If you require any further information, feel free to contact me.

Piotr ZIĘCIK | Senior Firmware Engineer
M +48 698 726 973| Kraków, Poland
nordicsemi.com | devzone.nordicsemi.com

Nordic_logo_signature

 

From: Cufi, Carles
Sent: Thursday, November 29, 2018 12:49 PM
To: nicolas lantz <nicolas.lantz@...>; devel@...; Zięcik, Piotr <Piotr.Ziecik@...>
Subject: RE: [Zephyr-devel] Opus codec on nrf52840

 

+ Piotr

 

From: devel@... <devel@...> On Behalf Of nicolas lantz
Sent: 29 November 2018 12:41
To: devel@...
Subject: [Zephyr-devel] Opus codec on nrf52840

 

Hi,

I would like to use the Opus codec with zephyr on a nrf52840 to encode or decode an audio stream.
Has anyone have a suggestion on this project?

Regards,
 
Nicolas
 


Re: Opus codec on nrf52840

Carles Cufi
 

+ Piotr

 

From: devel@... <devel@...> On Behalf Of nicolas lantz
Sent: 29 November 2018 12:41
To: devel@...
Subject: [Zephyr-devel] Opus codec on nrf52840

 

Hi,

I would like to use the Opus codec with zephyr on a nrf52840 to encode or decode an audio stream.
Has anyone have a suggestion on this project?


Regards,
 
Nicolas
 

2321 - 2340 of 7817