Date   

Re: HCI_UART

Carles Cufi
 

Hi there,

 

Could you please attach a btmon log of the attach procedure?

 

On one shell run “sudo btmon”

On another shell then run: “sudo btattach -B /dev/ttyACM0 -S 1000000”

 

And then attach the log output from btmon in an email or paste service.

 

Also, have you tried “sudo btmgmt --index 0”? i.e. specifying the index when invoking btmgmt?

 

Carles

 

From: devel@... <devel@...> On Behalf Of Cale Collins
Sent: 03 October 2018 17:43
To: devel@...
Subject: [Zephyr-devel] HCI_UART

 

Hello,

 

I have built and installed HCI_UART to nRF52840 Nordic Development kit.  When I connect this device it appears with "lsusb", seemingly I can attach it using "btattach -B /dev/ttyACM0 -S 1000000", revealing hci0.  I have made the recommended adaptation to "/lib/systemd/system/bluetooth.service", appending -E to the "ExecStart=/usr/lib/bluetooth/bluetoothd -E" line.

 

When issuing commands with "btmgmt", "btmon" reports "Invalid Index (0x11)".  Normal HCI commands fail such as "hciconfig hci0 up".  

 

Using Bionic-Beaver Ubuntu, 4.15 kernel, Bluez 5.48, also tested with Xenial Ubuntu 4.15 kernel, Bluez 5.50.  Any suggestions would be greatly appreciated. 

 

Best regards, 

 

Cale Collins
Field Application Engineer
Gateworks Corporation

3026 S. Higuera, SLO, CA 93401
T: (805)781-2000 x37


HCI_UART

Cale Collins <ccollins@...>
 

Hello,

I have built and installed HCI_UART to nRF52840 Nordic Development kit.  When I connect this device it appears with "lsusb", seemingly I can attach it using "btattach -B /dev/ttyACM0 -S 1000000", revealing hci0.  I have made the recommended adaptation to "/lib/systemd/system/bluetooth.service", appending -E to the "ExecStart=/usr/lib/bluetooth/bluetoothd -E" line.

When issuing commands with "btmgmt", "btmon" reports "Invalid Index (0x11)".  Normal HCI commands fail such as "hciconfig hci0 up".  

Using Bionic-Beaver Ubuntu, 4.15 kernel, Bluez 5.48, also tested with Xenial Ubuntu 4.15 kernel, Bluez 5.50.  Any suggestions would be greatly appreciated. 

Best regards, 

Cale Collins
Field Application Engineer
Gateworks Corporation
3026 S. Higuera, SLO, CA 93401
T: (805)781-2000 x37


Re: Best pinmux approach for Atmel sam soc (sam4s & same70)

Jiří Kubias <jiri.kubias@...>
 

Hi,
isn't better to put the pin config into the arch/.../soc_pinmap.h and then the user app is responsible for proper pin setup. As the same board can be used in various way (typically dev boards) and some MCU can map peripheral pin function to varios pins so the soc_pinmap.h  should contain all configuration variables and user have to select the correct one for his board. 

Best regards, 
Jiri

st 3. 10. 2018 v 17:14 odesílatel Kumar Gala <kumar.gala@...> napsal:


> On Oct 3, 2018, at 6:15 AM, Vincent - VLoTech <vincent@...> wrote:
>
> Hi all,
>
> I'm currently extending the support for the sam4s and same70, by adding the SPI driver for it.
>
> To create / extend a board which actually uses the SPI bus, I noticed there several different approaches to handle the pinmux.
> 1) device tree spec at board level assigning peripheral pins.
> 2) pinmux.c file using pinmux interface
> 3) pinmux.c file useing pinmux device interface
>
> What is the preferred way, or better said, what is the design pattern to apply for now and in the near future.
>
> Looking forward to your insights.
>
> Kind regards,
>
> Vincent van der Locht

I’d avoid device tree for right now, it is were we want to be, but requires a bunch of other work we are making progress on.

So we should have a pinmux driver that sets pins, and than we have board level pin settings.  You can look at boards/arm/frdm_k64f/pinmux.c and drivers/pinmux/pinmux_mcux.c for an example/pattern to use.

- k




--
===================================================
Ing. Jiri Kubias
 
e-mail: jiri.kubias@...
mobile: 775 593 956
===================================================


Re: Best pinmux approach for Atmel sam soc (sam4s & same70)

Kumar Gala
 

On Oct 3, 2018, at 6:15 AM, Vincent - VLoTech <vincent@vlotech.nl> wrote:

Hi all,

I'm currently extending the support for the sam4s and same70, by adding the SPI driver for it.

To create / extend a board which actually uses the SPI bus, I noticed there several different approaches to handle the pinmux.
1) device tree spec at board level assigning peripheral pins.
2) pinmux.c file using pinmux interface
3) pinmux.c file useing pinmux device interface

What is the preferred way, or better said, what is the design pattern to apply for now and in the near future.

Looking forward to your insights.

Kind regards,

Vincent van der Locht
I’d avoid device tree for right now, it is were we want to be, but requires a bunch of other work we are making progress on.

So we should have a pinmux driver that sets pins, and than we have board level pin settings. You can look at boards/arm/frdm_k64f/pinmux.c and drivers/pinmux/pinmux_mcux.c for an example/pattern to use.

- k


Best pinmux approach for Atmel sam soc (sam4s & same70)

Vincent - VLoTech
 

Hi all, 

I'm currently extending the support for the sam4s and same70, by adding the SPI driver for it. 

To create / extend a board which actually uses the SPI bus, I noticed there several different approaches to handle the pinmux. 
1) device tree spec at board level assigning peripheral pins. 
2) pinmux.c file using pinmux interface
3) pinmux.c file useing pinmux device interface

What is the preferred way, or better said, what is the design pattern to apply for now and in the near future. 

Looking forward to your insights. 

Kind regards,

Vincent van der Locht


Re: Compilers working on Zephyr

Yasushi SHOJI
 

Hi Gil,

It's nice to see someone using TI CGT!
I've been working on it but the current Zephyr code base has many GCC-ism's.
Most challenging part of it is the final linking. In parts, CGT's
pre-processor doesn't handle
.S with C includes, it expands ".text" into ". text" with a white
space between dot and alpha,
the linking commands assume c compiler with linker options, etc.

I've talked to Sebastian about it and he said he'd like to go with a
compiler translator,
a python script to translate a compiling commands to another. A
tentative code is at
https://github.com/zephyrproject-rtos/zephyr/issues/10182

With the script. I've compiled all C code but haven't finished the
final linking.

just to note, currently the CROSS_COMPILE environment variable only works with a
tool chain with same prefix. ie) "armeb-eabi-". Check
cmake/compiler/gcc.cmake.

Regards,
--
yashi

On Tue, Oct 2, 2018 at 2:42 AM Gil Pitney <gil.pitney@linaro.org> wrote:

Hi Flavio,

I also recorded some issues attempting to integrate TI compiler/toolchain:

https://github.com/zephyrproject-rtos/zephyr/issues/9284

I haven't gotten back to it as it's lower priority for the moment.

Regards,
- Gil


On 1 October 2018 at 10:29, Flavio Ceolin <flavio.ceolin@intel.com> wrote:

Hi Sebastian,

The in-tree documentation is lacking indeed, but I also wanted to know
whether people is trying to use other compilers and the problems they
are facing.

The work on MISRA-C and C99 conformance will make easier use different
tools -from code only perspective - and I'm trying to map what are the other
problems.

This is a known hole in our documentation.

To discover toolchains that have in-tree integrations see the contents of zephyr/cmake/toolchain.

Toolchains that are not integrated use CROSS_COMPILE, but using CROSS_COMPILE will only work for certain types of toolchains and certain types of Zephyr configurations.

________________________________________
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> on behalf of Flavio Ceolin <flavio.ceolin@intel.com>
Sent: Saturday, September 29, 2018 12:01:04 AM
To: zephyr-devel@lists.zephyrproject.org
Subject: [Zephyr-devel] Compilers working on Zephyr

Hi,

Guys I'm trying to have a list of supported compilers on Zephyr, but in
our wiki just mention about 3rd-party compilers but don't mention any
other than GNU ARM compiler.

If you are using a compiler different from our SDK, can you tell me so I
can catalog it. If you're just trying to use other compiler, please tell
me which problems you are facing.

Regards,
Flavio Ceolin

Regards,
Flavio Ceolin



Zephyr Development News, 02 October 2018

Marti Bolivar <marti@...>
 

This is the 02 October 2018 newsletter tracking the latest Zephyr
development merged into the mainline tree on GitHub.

HTML is available here:


Compared to previous newsletters, we're changing the format to
hopefully be more consumable (and keep the author from going crazy) by
decreasing the Highlights section to a few chosen interesting or
significant changes.  We're also giving up and letting pandoc handle
all aspects of the plain-text conversion.

We're still keeping the Individual Changes section with each
merged commit, separated into affected areas.

We may tweak this further as we go forward; if you have any feedback,
please let us know!


HIGHLIGHTS


This newsletter covers the following inclusive commit range, which is
the first part of the v1.14 development cycle's merge window.

-   e2e0720c release: Post-release patch level update, merged 10
    September 2018
-   d6de4c7a cmake: Fall back to ZEPHYR_BASE when the board is not in
    BOARD_ROOT, merged 1 October 2018


Fresh and New

A brief summary of newly-minted Zephyr support.

-   BOARDS: Cypress PSoC6 Cortex-M0 and Cortex-M4
    (cy8ckit_062_wifi_bt_m0 and cy8ckit_062_wifi_bt_m4), Atmel SAMD21
    XPlained (atsamd21_xpro), NXP i.MXRT1062 Cortex-M7 (mimxrt1060_evk),
-   SHIELDS: The first mainline shields were merged, with support for
    STMicro X-NUCLEO-IKS01A1 and X-NUCLEO-IKS01A2 (x-nucleo-iks01a1 and
    x-nucleo-iks01a2).
-   DRIVERS: RTC support for STM32L4, -F3, -F4; slave devices and 10-bit
    addressing mode for I2C; SPI for NXP LPSPI; GPIO for Intel Apollo
    Lake; UART for Cypress PSoC6 and POSIX;
-   SAMPLES: demonstration applications for the newly merged shields in
    samples/shields.
-   SOCS: Cypress PSoC6, i.MX RT1060


Shell Subsystem Reimplementation

Zephyr's shell subsystem has been completely reimplemented. Official
docs for the new version claim the following features:

-   Multiple backends (though it's not clear what the future holds for
    interaction with the nascent TTY layer)
-   Integration with the new Logger subsystem
-   Tab completion
-   Built-in shell support for clear, shell, colors, echo, history and
    resize.
-   Command history with arrow key (↑ and ↓) support, as well as editing
    with arrow key (← and →), Backspace, Delete, End, Home, and Insert
    key support
-   Support for ANSI escape codes, multi-line commands, wildcards (* and
    ?), and meta keys
-   Built-in command help handling

The new features come at a price: during a Technical Steering Committee
presentation on the subject, a minimum of 8KB ROM footprint was given.
Total footprint and memory usage can, of course, be tuned via Kconfig.

As of now, the Bluetooth shell has been ported to the new shell
subsystem.


Wading in the Waters of MISRA-C Compliance

The Motor Industry Software Reliability Organization (MISRA) defines a
variety of software standards used in the automotive industry. Among
them are the MISRA C guidelines for use of the C programming language.
These have gone through three versions, released in 1998, 2004, and
2012; they are proprietary specifications which can be purchased for
£15. Zephyr is targeting the most recent (2012) version of the MISRA C
standard.

Zephyr has been targeting MISRA-C compliance for some time now, and the
first development along these lines is now taking place. A mailing list
thread was started introducing the subject and incoming changes to
Zephyr, and some commits have been merged which address violations of
the standard. So far, these have been fairly wide-ranging changes both
in the kernel and across the tree, some scripted using Coccinelle.
Initial changes seem focused on somewhat mechanical transformation to
address requirements like not ignoring return values or respecting
reserved portions of the namespace, which have not been, let's say,
universally loved. However, nobody seems to disagree with the idea that
Zephyr being certifiable in an automotive context is desirable for the
project, even if it implies somewhat baroque and artificial restrictions
on the codebase.


Portability and C++

In a slightly orthogonal but somewhat similar set of changes, various
patches are going in to make Zephyr usable with C++ applications and
non-GNU toolchains. Some examples include avoiding non-standard void
pointer arithmetic, C99 rules around semicolons in structures, and
making Zephyr's device driver API headers compile in C++.


Out-of-tree SoC Support

Zephyr already has support for integrating with board definitions that
aren't part of the Zephyr tree; it now also includes support for out of
tree SoCs. The official documentation describes how to integrate such a
definition into the Zephyr tree. Internally, this resulted in a
top-level soc directory (i.e. parallel to arch), and the movement of
existing SoC support there from its previous home in arch.

The remaining code in arch now focuses more narrowly on CPU cores
themselves, rather than the SoCs which integrate them with peripherals,
other cores, etc. In addition to easing out of tree and proprietary
usage of Zephyr, this is arguably a cleaner construction, especially
given that some modern "microcontroller" SoCs are complex, multi-core
creatures, with cores from different processor subfamilies (or even
architectures).


KCONFIG_ROOT by Convention

Zephyr has long supported applications defining their own Kconfig
options, provided that:

1.  The application's Kconfig file includes Zephyr's somewhere in its
    definition.
2.  The application CMakeLists.txt (or the CMake command line) sets the
    KCONFIG_ROOT variable to point at the application's Kconfig file.

The second requirement has now been partially lifted. If the
application's directory contains a file named Kconfig, this is used by
default as the KCONFIG_ROOT. Applications are still free to set
KCONFIG_ROOT to any value they desire.

These details are now described in the application development primer.


Arm MPU Reorganization

Previously, Zephyr's Memory Protection Unit (MPU) support for Arm cores
was split into multiple Kconfig options depending on the target SoC.
(Perhaps) needless to say, the story got a bit complicated over time.

For example, users of SoCs with the MPU core provided by Arm Limited
could set CONFIG_ARM_CORE_MPU=y, while those with NXP MPUs would use
options like CONFIG_NXP_MPU or CONFIG_ARM_MPU_IMX_RT. Nordic nRF52
aficionados would naturally prefer CONFIG_ARM_MPU_NRF52X, and of course
lovers of the STM32 line could set CONFIG_STM32_ARM_MPU_ENABLE.

This has been simplified and consolidated under a single CONFIG_ARM_MPU
option. If this is set to y, chip-specific build system logic will
select and enable the relevant MPU support code for the target SoC. This
is in keeping with similar behavioral changes made to Zephyr's device
driver support.


More Progress on Power Management

A previous newsletter from the v1.13 RC period celebrated the addition
of an "OS-managed" power management framework, which enabled the kernel
to handle some aspects of conserving energy depending on system state it
was already tracking. This celebration was muted by limitations to nRF
devices and hard-coded data structures limiting support to certain
peripherals, but looked forward to further improvements.

These improvements are incoming, with the addition of generic arch
infrastructure for power state support, which is now used by Arm nRF52,
ARC quark_se_c1000_ss, and x86 quark_se SoCs.

The power management core itself now advertises pluggable policies, with
an initial example based on CPU residency.

We look forward to further improvements and documentation in this area.


Logger API Changes and Improvements

In a Logger blog series, we deep-dived into the initial version of the
Logger API merged into Zephyr. This subsystem has since seen some
changes and improvements, both to its core implementation and usage
within the tree.

Here's a quick recap:

-   The LOG_MODULE_REGISTER() and LOG_MODULE_DECLARE() macros now take
    the name of the module being registered (or declared), so the old
    way:

    LOG_MODULE_REGISTER();

    Must now be:

    LOG_MODULE_REGISTER(your_module_name_goes_here);

    If you want to continue defining LOG_MODULE_NAME as before, you can
    simply pass that as a parameter to the relevant macro.

-   A template file, subsys/logging/Kconfig.template.log_config, was
    added, which provides a standard way to define log level
    configuration Kconfig options for a module. This uses the new macro
    substitution feature that is part of recent Kconfig implementations.

-   The UART-backend specific color and timestamp options were made
    generic and renamed CONFIG_LOG_BACKEND_SHOW_COLOR and
    CONFIG_LOG_BACKEND_FORMAT_TIMESTAMP.

-   A new logger backend was added for the POSIX pseudo-architecture; it
    is configurable using CONFIG_LOG_BACKEND_NATIVE_POSIX.

-   Logging control commands were added to Zephyr's new shell subsystem;
    they can be enabled with CONFIG_LOG_CMDS.

-   Flags were added to control whether the log level and timestamp are
    printed.


(Experimental) Socket Offload API

As we've discussed at some length in previous newsletters, Zephyr's
networking stack is in the process of being rearchitected so that all
network access, including use of TLS and DTLS, is via its sockets API.

One of the main reasons this is happening is to enable offloading of
network support to external chips. The idea behind this is that if the
user relies only on standard socket APIs (plus some nonstandard
setsockopt() calls to handle the TLS state machine), then the networking
implementation can be a software stack on the same chip or a driver for
an external chip with a "sockets-ish" wire protocol, with nobody above
the sockets API being the wiser.

One important missing piece needed to make this vision a reality is a
socket-based API for writing such "offload" drivers. Experimental work
was merged rectifying this with the addition of a new
CONFIG_NET_SOCKETS_OFFLOAD option. When this is enabled, a new API in
will be substituted for the usual software implementation, providing its
own socket API declarations which call into a struct socket_offload
vtable. The TI SimpleLink WiFi driver is the first in-tree user of this
option and API.

Support at present seems limited to installing a single socket_offload
structure at a time, so mixing use of multiple network interfaces with
this feature doesn't seem possible at the moment.



INDIVIDUAL CHANGES


Patches by area (532 patches total):

-   Arches: 46
-   Bluetooth: 52
-   Boards: 38
-   Build: 30
-   Continuous Integration: 9
-   Device Tree: 38
-   Documentation: 21
-   Drivers: 46
-   External: 13
-   Kernel: 40
-   Libraries: 12
-   Logging: 19
-   Maintainers: 6
-   Miscellaneous: 37
-   Networking: 38
-   Power Management: 1
-   Samples: 39
-   Scripts: 13
-   Storage: 7
-   Testing: 27

Arches (46):

-   0439deea arm: Clear primask and faultmask during startup
-   c850ba8e arch: arm: soc: nordic_nrf: nrf52: Add missing header
-   726bda6a arch: arm: correct placement of macro documentation
-   3d1252ff soc: adapt Kconfig/CMake for soc in top /
-   cff0005a x86: move soc/cpu to top-level under soc/
-   70d819b4 arm: soc: move arm SoCs to top-dir
-   f1834446 arc: move soc to top-level dir soc/
-   cea0b3a9 xtensa: move soc to top-level dir soc/
-   279cc2e4 riscv32: move soc to top-level dir soc/
-   696aa869 nios2: move soc to top-level dir soc/
-   563c161a posix: move soc to top-level dir soc/
-   66b524a6 soc: support out of dir soc code
-   73e8454d arch: arm: remove power-of-two align and size requirement
    for ARMv8-m
-   2eb347b1 arm: exx32: Use one common soc.c for all exx32 socs
-   ba5476a2 native_posix: Add control of traces color
-   b47e37c7 native_posix: Add logger configuration backend
-   17652760 arch: arm: Use BL instead of B to jump to _PrepC
-   ae8d4ede soc: arm: Enable the lpspi driver and clock for the imxrt
    soc
-   eb1ee5f1 arch: stm32: Remove STM32_ARM_MPU_ENABLE option.
-   c4cd4cfe arch: beetle: Remove ARM_MPU_ENABLE option.
-   9331064f arch: nrf52: Remove ARM_MPU_NRF52X option.
-   edfcab42 arch: nxp_imx: Remove ARM_MPU_IMX_RT option.
-   d9cc147c arch: nxp_kinetis: Remove HAS_SYSMPU option.
-   d393186d arch: arm: Introduce CPU_HAS_ARM_MPU and CPU_HAS_NXP_MPU
    options
-   1c16cfcc arch: arm: Make ARM_MPU the sole option controlling MPU
    usage
-   63200436 qemu: nios2: Enable UART 16550 driver for QEMU
-   56117f9f arch: Kconfig: Add Kconfig options for Low Power States
-   f0a2f2b4 soc: arm: nrf52: Select the supported Power States
-   023bc923 soc: mps2_an385: Added support for MPU
-   0e60644f soc: mps2_an385: Enable Memory Protection unit.
-   31c8817d include: arm: CMSIS header redefining MPU_PRESENT.
-   93f938c4 arm: Add Cypress PSoC6 SoC support
-   343c48f7 arch: atmel_sam0: sam21j18a: Convert _U to __U to fix
    compile warning
-   98e38109 arch: arm: fix error reason intialization
-   7d4339a9 arch: arm: add explanatory comment for SPLIM_NS set
    functions
-   66192618 arch: arm: Minor style and typo fixes in inline comments
-   ccffca4a soc: arm: mps2: remove un-necessary Kconfig option
    selection
-   5b62ea0e arch: arm: nxp: imxrt1060: add device support
-   13a4d884 arch: arm: remove un-necessary inclusion of <string.h>
-   3b72a545 soc: nxp_imx: Use generated clock controller in dts fixup
-   27459a13 arch: Add LOG_PANIC to fault handlers
-   47323284 arch: arm: group Userspace-related regions together
-   12c02448 arch: arm: style fixes in documentation of MPU region types
-   0be60001 soc: x86: arc: Remove spi base address and irq macros
-   a404d4df soc: arc: quark_se_c1000_ss: Select the supported Power
    States
-   3a8e37ca soc: x86: quark_se: Select the supported Power States

Bluetooth (52):

-   877c4d0c Bluetooth: controller: Use nRFx functions for PPI reg
    access
-   9af28ddc Bluetooth: host: directed advertising support
-   3e8f118d Bluetooth: shell: adding command for directed advertising
-   8853cb3d subsys: bluetooth: Add notification TX complete callback
-   a8f43709 Bluetooth: Move bt_setup_id_addr() to avoid forward
    declaration
-   cb08963f Bluetooth: Fix identity creation through vendor HCI
-   b4d7c290 Bluetooth: Remove bogus condition for setting IRK for an
    identity
-   3c1dab00 Bluetooth: SMP: Remove bogus ARG_UNUSED() macro
-   6a68a667 Bluetooth: GATT: Use BT_GATT_DESCRIPTOR() for descriptors
-   366378f8 Bluetooth: GATT: Fix const'ness of characteristic
    descriptor data
-   22a27fa0 Bluetooth: hci_ecc: Fix byte order of dbg keys
-   0d1724b0 Bluetooth: GATT: Fix long write procedure
-   e2362e1d Bluetooth: GATT: Make bt_gatt_discover perform discover all
    procedure
-   f67d4560 Bluetooth: shell: Fix requiring UUID for gatt-discover
-   64e608be Bluetooth: testing: Exclude Mesh related code if BT_MESH
    not set
-   7ff9eeea Bluetooth: Add Kconfig option to disable bondable mode
-   4f74f698 Bluetooth: Add run-time option to disable SMP bondable mode
-   323243d3 Bluetooth: Add a shell command to disable bondable mode
-   f93eef17 Bluetooth: Fix security level checking with LE SC and
    no-bonding
-   e76224d0 Bluetooth: Controller: Add CONFIG_BT_HCI_VS option
-   732b45cf Bluetooth: Read static address from FICR on nRF5 if no VS
    enabled
-   139beac5 Bluetooth: host: Add set channel map command
-   9c2214e2 Bluetooth: shell: Add shell command set channel map
-   9fe378b7 Bluetooth: Mesh: Enforce proper compilation.
-   0a230675 Bluetooth: GATT: Remove BT_GATT_WRITE_FLAG_PREPARE check in
    GAP
-   6c89c4b5 Bluetooth: Controller: Add support for setting public
    address
-   e48434bc Bluetooth: gatt: gatt_discover_next with inclusive handle
    range
-   cf6f87f2 Bluetooth: samples/peripheral_sc_only: Improve logging
-   0287a043 Bluetooth: host: Fix name conflict with kernel smp_init in
    smp.c
-   3151d265 Bluetooth: L2CAP: Add return to recv
-   8af4786e Bluetooth: L2CAP: Restore credits after receiving an SDU
-   62f41df2 Bluetooth: L2CAP: Prevent the channel to stall
-   da83616e Bluetooth: L2CAP: Fix identation of struct members
-   16fdd749 Bluetooth: L2CAP: Make use of net_buf_append_bytes
-   8c02af73 Bluetooth: shell: Add l2cap-recv command
-   559578c0 Bluetooth: Add API to iterate through existing bonds
-   75405f56 Bluetooth: Fix connection parameters update
-   bb271a6d Bluetooth: Add option to configure peripheral connection
    parameters
-   868a3bff Bluetooth: host: always set address via HCI before scanning
-   684f753f Bluetooth: controller: Fix Data Length Update
    implementation
-   d813b131 Bluetooth: controller: Remove timestamp from HCI
-   063123f3 Bluetooth: Allow to configure background scan window and
    interval
-   f0f4147a Bluetooth: Allow to configure LE Create Connection timeout
-   9c5c2f8b Bluetooth: Fix incorrectly reporting connection as failure
-   a7bf9de0 Bluetooth: Use BT_CMD_TEST macro for testing supported
    commands
-   d5836195 Bluetooth: controller: Increase advertising random delay
    resolution
-   592dd2e9 Bluetooth: shell: Port commands to the news shell
-   310ffc4c Bluetooth: shell: Split BR/EDR commands
-   bcfc9939 Bluetooth: shell: Split RFCOMM commands
-   043a8b02 Bluetooth: shell: Split GATT commands
-   fb4785d2 Bluetooth: shell: Split L2CAP commands
-   17558c93 Bluetooth: shell: Use to terminate line

Boards (38):

-   dc60f86d boards: add usb to stm32f4_disco
-   e84709e1 boards: arm: nrf51_pca10028: use dts for LED and button
    configuration
-   24c6407c boards: arm: nrf52810_pca10040: use dts for LED and button
    config
-   7eb26dc2 boards: arm: nrf52840_pca10059: use dts for LED and button
    config
-   50e05a54 boards: arm: nrf52832_pca10040: use dts for LED and button
    config
-   6ca042d3 boards: arm: nrf52840_pca10056: use dts for LED and button
    config
-   7c2197f2 boards: nrf: uart: Moved UART pin configuration to DTS (nRF
    boards)
-   0329ec7e boards: nucleo_f429zi: Fix typo in the docs
-   e688d5c6 boards/arm: Enable RTC on STM32F4 based boards
-   d3c515ec boards/arm: Enable RTC on STM32F3 based boards
-   62d7a7a5 boards: arm: nrf: Update supported features
-   8acf21d5 boards: arm: nrf52810_pca10040: Fix dts
    avoid_unnecessary_addr_size warn
-   271f8421 boards: arm: nrf: Fix dts avoid_unnecessary_addr_size warn
-   ca6a232e mimxrt1050_evk: Configure an lpspi instance and pins
-   6802534d boards/x86: up_squared: add board option for SoC variants
-   2f0282a2 boards/x86: up_squared: updates SYS_CLOCK_HW_CYCLES_PER_SEC
-   d328a4fe boards/x86: up_squared: add GPIO dts configuration
-   79e8f794 boards/x86: up_squared: add sample app for GPIO
-   b64b9e78 boards: arm: dts: remove unnecessary interrupt flag
-   d547c9b2 boards: mps2_an385: Enable userspace for MPS2_AN385.
-   de24cd69 boards/arm: Fix button dts syntax for stm32 based boards
-   b9b2e58d boards: arm: Add Cypress PSoC6 cy8ckit_062_wifi_bt_m0 board
    support
-   3591c852 boards: arm: Add Cypress PSoC6 cy8ckit_062_wifi_bt_m4 board
    support
-   ec408d3a boards: add support for shields x-nucleo-iks01a1 and
    -iks01a2
-   674ccd36 boards: arm: atsamd21: Add SAMD21 XPlained board
-   80b8da69 boards: arm: nrf52840_pca10056: Fix typo
-   7b0ce852 boards: dts: Fix dtc warning in stm32 board dts files
-   b47067b7 boards/shields: Clean-up connectors Kconfig options
-   c62815a3 boards: nucleo_f091rc: Add i2c to list of supported
    features
-   6585fe45 boards: arm: Add board support for mimxrt1060_evk
-   8d898150 boards: Remove redundant "select HAS_DTS_I2C"
-   c73d5c78 boards: mimxrt1050_evk: Enable lpuart3 for bluetooth hci
-   78935f93 boards: nucleo_f429zi: Enable USB
-   228b148b boards: nucleo_f429zi: fix PWM instance
-   96ddb42f boards: nucleo_f412zg: Fix default config
-   37e5a9dc boards: nucleo_f413zh: Fix default config
-   c0d58d1a boards: nucleo_f207zg: Fix default config
-   339a631a boards: Remove redundant "select HAS_DTS_SPI"

Build (30):

-   213a88f7 Kconfig: Support macro expansion within symbol names
-   d0e8752a Kconfig: Rename $ENV_VAR_{ARCH,BOARD_DIR} to ARCH/BOARD_DIR
-   d713033d Kconfig: Use new preprocessor syntax for env. variables
-   1d90bcdc cmake: Use find_program on CMAKE_CXX_COMPILER
-   5744437d kconfig: adapt help messages for new location of SoC code
-   abcf2ad5 kconfig: move soc selection to ZEPHYR_BASE/soc/
-   96455d58 build: support out of tree SoC definition
-   d3390305 cmake: menuconfig: Fix missing SOC_DIR macro
-   ba31cb55 cmake: Add zephyr base address when looking file into soc/
-   d98e046a cmake: move ti_lm3s6965-specific code into the soc
    directory
-   e0f1d77f menuconfig: Fix some minor graphical glitching and add
    custom styles
-   878a0f05 ld: Put 'sizeof(struct device)' in the generated offsets
    header
-   d4b5ab64 CMakeLists.txt: Set application shared memory dependency
-   1b80f00f cmake: Suppress the stderr from 'git describe' on
    successfull runs
-   b6a65a97 kconfig: Make CONIG_FP_SOFTABI generate floating point
    instructions
-   c764e021 CMakeLists.txt: Updated the rule for shared memory
    alignment.
-   89a197be cmake: Re-direct KCONFIG_ROOT when convention is used
-   72e7bfa6 cmake: Remove unnecessary KCONFIG_ROOT configuration
-   6af514b6 build: enable shields dir treatment
-   4e61ccd1 cmake: Add quotes to handle missing
    ZEPHYR_TOOLCHAIN_VARIANT variable
-   f8616291 Kconfig: BT: Give the LL selection option a name
-   ab676394 cmake: Add build system target for west attach command
-   c0ff084f cmake: Do not abort even if git describe failed
-   c0287695 kconfig: Remove remnants of unimplemented BUILD_TIMESTAMP
    feature
-   905e65d6 Kconfig: Improve error messages for mismatched
    endchoice/endif/endmenu
-   4dfd3114 kconfig: Don't set the deprecated env var
    KCONFIG_AUTOHEADER
-   8ade2626 kconfig: Change the format of KERNELVERSION
-   669781f2 cmake: version: Misc. refactorings for readability
-   fd8022ae cmake: Misc. cleanups of how BOARD_ROOT and BOARD_DIR are
    used
-   d6de4c7a cmake: Fall back to ZEPHYR_BASE when the board is not in
    BOARD_ROOT

Continuous Integration (9):

-   0b48df35 ci: Increase number of build slaves to 7
-   7e625ab8 ci: reduce minions to 5
-   5f5bd8b9 ci: disable cache
-   ac419c4a ci: Use Ninja with sanitycheck
-   84b0448e ci: Print the toolchain database when CI fails
-   0f555387 gitlint: accept "'" in committer names
-   43398eb2 sanitycheck: fail on check_compliance issues
-   ba4643b7 sanitycheck: remove special ansi charachters from xml
-   d5d902a1 Revert "sanitycheck: fail on check_compliance issues"

Device Tree (38):

-   5c3992f3 dts: update I2C bindings for nRF chips
-   990a0e8c dts: add SPI bindings for nRF family
-   15d1f203 dts: stm32f429vX: Fix delete-node syntax
-   00603bfa dts: bindings: consolidate binding for flash controller
-   1755cf65 dts/bindings: Add 'generation' directive on for
    'compatible' property
-   52ebc02c dts: arm: ti: Remove use of CONFIG_SOC_* from TI SoC dts
    files
-   912b4a27 dts: arm: silabs: Remove use of CONFIG_SOC_* from Silabs
    SoC dts files
-   b6806883 dts/st: enables possibility to define Flash and SRAM out of
    tree
-   0e505265 dts/arm/st: Add rtc node to STM32F4
-   e072aba4 dts/arm/st: Add rtc node to STM32F3
-   91e03885 dts/arm/st: Remove unneeded setting of
    #{address,size}-cells from RTC
-   6e240da2 dts: Use new DT_SIZE_{K,M} macros
-   84612176 dts: arm: atmel_same70: Remove use of CONFIG_SOC_* from
    Atmel dts files
-   236a2d6f dts: arm: nrf: Remove use of CONFIG_SOC_* from Nordic dts
    files
-   e4a96ccb dts: Cleanup warnings associated with unit_address_format
    and leading 0s
-   df2ca60d dts: Cleanup warnings associated with alias_paths using '-'
-   16fa966f dts: Cleanup warnings associated with gpio_keys that aren't
    buttons
-   0ff2ae1f dts: Cleanup warnings associated with interrupt controller
    nodes
-   716047f3 dts: Cleanup warnings associated with unit_address_vs_reg
    and cpu node
-   6856ad14 dts: Cleanup warnings associated with flash and memory
    nodes
-   48dbffd3 dts: Cleanup warnings associated with unit_address_vs_reg
    on intel_curie
-   ca26a4bd dts/arm/st: Fix dtc warning in stm32 *-pinctrl.dtsi files
-   def322fe dts: Cleanup warnings associated with cpu node
-   1b394d6e dts/arm/st: Add missing properties to stm32f2 fash
    controller node
-   e4aacd31 dts: Add lpspi yaml bindings and dts nodes
-   abf54a54 dts/bindings: document use of value 'use-prop-name'
-   67ca29a0 dts: nrf: Expand nRF DTS to support ARM TrustZone
    CryptoCell 310
-   1ac3517c dts: Add missing 'compatible' property in flash base nodes
-   350c3d77 dts: Simplify overlay build scripts
-   ebd0ff9f dts: arm: st: Remove use of CONFIG_SOC_* from STM32 F0 dts
    files
-   aecc4c5d dts: arm: st: Remove use of CONFIG_SOC_* from STM32 F1 dts
    files
-   223d4266 dts: arm: st: Remove use of CONFIG_SOC_* from STM32 L0 dts
    files
-   46592e63 dts: arm: st: Remove use of CONFIG_SOC_* from STM32 L4 dts
    files
-   fe86919c dts: arm: st: Remove use of CONFIG_SOC_* from STM32 F2 dts
    files
-   6ab22d4c dts: arm: st: Remove use of CONFIG_SOC_* from STM32 F3 dts
    files
-   52646287 dts: arm: st: Remove use of CONFIG_SOC_* from STM32 F4 dts
    files
-   b9ee9bba dts: arm: st: Remove use of CONFIG_SOC_* from STM32 F7 dts
    files
-   1ec4b689 dts: arm: st: mem.h

Documentation (21):

-   1e1b46d1 doc: Using doxygen comments from the code for USB DC
-   798cdaec doc: Using doxygen comments from the code for USB Core
-   c164c8ea doc: fix using Ninja to generate PDF
-   7a1ec635 doc: convert internal http links to references
-   1d88e868 doc: document build target for PDF
-   81b27211 docs: fixed documenation pointers
-   16661304 doc: custom SOC configurations
-   7a9f4f68 doc: fix desription SoC tree structure example
-   02d0523f doc: Fix RST error in Kconfig template documentation
-   3a805185 doc: Indent RST code blocks and notes
-   47db520a docs: revamp section introducing Zephyr
-   461a9de7 doc: Bluetooth: Mention Mesh in the supported features
-   242c7295 doc: provide shield usage documentation
-   780c1c28 doc: Update intro with ble mesh and kernel features
-   713b6df5 doc: fix doxygen BUILD_ASSERT error
-   7599fad1 doc: cmake: Do not use USES_TERMINAL on latex/pdf targets
-   1692790d doc: fix misspellings in API headers
-   8dce59b6 doc: kconfig: Explain the '<type> <prompt>' shorthand
-   bef64c3b doc: subsystems: shell: Add documentation.
-   432562dd doc: fix doc misspellings
-   93230a52 doc: cmake: Change the format of KERNELVERSION to match
    Zephyr

Drivers (46):

-   71182cb2 driver: wifi: simplelink: Register socket offload
    operations.
-   4cf0127f usb: dc: Clean doxygen documentation
-   ce6de827 usb: device: Clean doxygen documentation
-   61eb2a1c drivers: gpio: nrfx: Use GPIOTE HAL for checking allocated
    channels
-   70efac6e drivers: sensor: dht: Fix fetch fail when config hw
    cycles=32768
-   ab9017ec sensor: Eliminate repetitive Kconfig "depends on" in sensor
    drivers
-   7fe3a481 sensor: Remove redundant Kconfig "depends on SENSOR" in
    sensor drivers
-   232cb657 sensor: Remove unnecessary Kconfig parentheses in sensor
    drivers
-   dc45def9 drivers/gpio_sam: Fix incorrect flag checking
-   95be60a8 usb: device: Fix kinetis driver to compile with SYS_LOG
    disabled
-   10c763cf drivers/rtc: Enable RTC driver for STM32F4 series
-   0c172511 drivers/rtc: Enable RTC driver for STM32F3 series
-   2b7840ea spi: Remove unused Kconfig symbols from mcux dspi driver
-   04bb2477 drivers: i2c: Add 10 bit addressing flag to i2c message
    flags.
-   fd04e7de drivers: nrf: Switched nrf i2c drivers to 10 bit address
    msg flag
-   873d63c5 drivers: i2c: Parse 10-bit addressing flag in mcux driver
-   23302065 drivers: eth: gmac: Proper ptp clock setup
-   83a67815 clock_control: Add support for lpspi clock in mcux ccm
    driver
-   45d3d8e4 spi: Introduce mcux lpspi shim driver
-   86442038 drivers: pinmux: add PINMUX_DEV CMakeLists.txt
-   eb6ea286 gpio: enable callback to specify pin in addition to
    pin_mask
-   8d18ebde gpio: add driver for Intel Apollo Lake SoC
-   2875c052 drivers: sensor: Fix unused variable warnings
-   7ac70c47 drivers: sensor: Fix compiler format warning in bmi160
-   553a31ef drivers: sensor: Add missing cmake files for bmm150
-   06f73456 drivers: sensor: Fix casting warnings
-   a013ce3b drivers: sensor: Fix incorrect Kconfig dependency in
    lsm6dsl
-   36365e38 drivers: timers: systick: Enforce a barrier in
    _timer_cycle_get_32.
-   9da6a85c drivers: flash: nrf5: Use faster write interval with BT
    sync
-   163629c9 drivers: apds9960: use i2c_burst_read to fetch ALS data
-   9c3d7738 driver: apds9960: reorganize ALS and proximity setups
-   963f97d0 drivers: apds9960: use interrupt output for sample
-   b192b2b5 drivers: apds9960: add trigger mode for proximity
-   59a6ec44 drivers: apds9960: use power management
-   7ed7d535 drivers: adc: nrfx: Use SAADC HAL for setting the burst
    mode
-   edd6c7df drivers: serial: Add Cypress PSoC6 UART driver
-   1dd5dc63 drivers: i2c: Add dts support for i2c slaves.
-   c065ebdf drivers: ethernet: native: Fix compile issue in RedHat 7
-   50d276f1 drivers: i2c: Select HAS_DTS_I2C in designware and qmsi
    drivers
-   00d60055 drivers: serial: Add instances to mcux lpuart shim driver
-   5df93af8 subsys: storage: flash_map: add API for check flash driver
    support
-   013f2791 uart: Add driver for posix arch
-   15959c8b drivers: eth_sam: Add generate random mac address feature
-   55caa7b7 drivers: spi: Select HAS_DTS_SPI in designware driver
-   e2c590a0 drivers: ethernet: native: fix compile error when glibc >=
    2.20
-   5dc58497 drivers: gpio: Select HAS_DTS_GPIO in various drivers

External (13):

-   1a8ac641 ext: hal: nordic: Update nrfx to version 1.2.0
-   48e6ec7b ext: nffs: bugfix of possible to corrupt filename
-   486b731b ext: lib: Add fnmatch library
-   836cb5b7 ext: hal: nordic: Update nrfx to version 1.3.0
-   11716e46 ext: hal: nordic: Update nrfx adaptation layer
-   65085270 ext: hal: cypress: Import Cypress PDL for PSoC6 SoC Support
-   2aa3815a ext: hal: cypress: Integrate Cypress PDL into Zephyr Build
    system
-   4d6b6621 ext: hal: cypress: Protect floating point code with
    CONFIG_FLOAT
-   c632d25a ext: hal: nrfx: Update README after upgrading to version
    1.3.0
-   a4633da9 ext: hal: nxp: mcux: Add device files for RT1060
-   6a355243 ext: libmetal: Update import of libmetal from b4b5bea to
    a4f7630
-   a82cb244 ext: nffs: portability: Avoid void* arithmetics which is a
    GNU extension
-   b45fcc6b ext: hal: nordic: Update nrfx to version 1.3.1

Kernel (40):

-   26c51c43 userspace: sample app domain applications
-   a3cea50c kernel: Add missing break/default in switch statement
-   3259ac08 kernel: userspace: Sanitize switch usage
-   585d90f8 kernel: Fix k_stack_alloc_init behavior
-   91b61239 kernel: syscall: Explicitly ignoring not used return
-   8a9ba10c kernel: swap: Fix __swap signature
-   5884c7f5 kernel: Explicitly ignoring _Swap return
-   1663ca85 kernel: Ignore _pend_current_thread return in some cases
-   4d5397bb kernel: Ignore _abort_timeout return
-   abffd83d kernel: atomic: Ignore atomic_and/or return when not used
-   98c64b6d kernel: Change _reschedule signature
-   8f72f245 kernel: Explicitly check _abort_thread_timemout
-   65b5280e kernel: Check k_thread_create return value
-   0a447843 kernel; Checking functions return
-   4218d5f8 kernel: Make If statement have essentially Boolean type
-   b3d92027 kernel: Using boolean constants instead of 0 or 1
-   c806ac3d kernel: Compare pointers with NULL in while statements
-   8f488ff3 kernel: stack: Fix k_stack_pop api
-   ae92f2ba subsys: app_memory: Fixed the size calculation for power of
    2 MPUs
-   0a73ea04 kernel: remove deprecate k_call_stacks_analyze
-   3c834bdf kernel: Fix list-node add again corruption case in timeout
    handling
-   7228a601 kernel: Fix compilation errors when CONFIG_TIMESLICING=n
-   2df1829c kernel: thread: Typo fixes in comment
-   57b7c3de kernel: improve help text of INIT_STACKS option
-   3a117c22 kernel: remove unused macro parameter
-   57554055 kernel: add a new API for setting thread names
-   6fdc56d2 kernel: Using boolean types for boolean constants
-   d8837c68 kernel: Using boolean expression on ASSERT macros
-   02ed85bd kernel: sched: Change boolean APIs to return bool
-   92ea2f91 kernel: Calling Z_SYSCALL_VERIFY_MSG with boolean
    expressions
-   ea716bf0 kernel: Explicitly comparing pointer with NULL
-   6fc84fea kernel: syscalls: Change handlers namespace
-   0b148664 kernel: sys_clock: Remove unnecessary if
-   3e97acc7 kernel: Sanitize if else statement according with MISRA-C
-   d4c7617a kernel: Remove unused variables
-   10f90372 kernel: Avoid duplicated type definition in x86
-   78f27a81 kernel: Using the same paramenters names in a specific
    function
-   061a2c5b kernel: mempool: Remove unnecessary condition check
-   7f4a3179 subsys: app_memory: Fixed incorrect linker syntax.
-   10c6a0c1 subsys: app_memory: Fixed the build issue wrt ARC.

Libraries (12):

-   9fed7d63 lib/cmsis_rtos_v1: Use k_mbox_async_put instead of
    k_mbox_put
-   e0dda1b4 lib: posix: clock: Add gettimeofday() call
-   9921eb32 lib: posix: clock: Add read of CLOCK_REALTIME
-   9d6f1c60 lib: posix: clock: Implement clock_settime
-   da4c00c0 libc: minimal: Add sys/fcntl.h enough to compile
    net/lib/sockets
-   4462dfab lib: posix: fix couple of race conditions
-   1e152ff2 lib: cmsis_rtos_v1: do null check before use
-   25fb2302 libc: minimal: Add error codes for key management
-   482579e4 lib: posix: add error code return
-   7e6c103f lib: posix: fix return error code
-   d3ab9a37 lib: posix: remove return error code
-   df5c29d3 lib: POSIX: Add check for deadlock in pthread_join

Logging (19):

-   4fede8dd log: make name param explicit
-   1fbea945 logging: Refactor log_output module
-   a728a46a logging: add template for log configuration
-   70f046e3 logger: Rename SHOW_COLOR and FORMAT_TIMESTAMP options
-   e65ee687 logger: Add native backend for native_posix
-   f8b97ab7 subsys: logging: Fix for no CONFIG_LOG_PROCESS_THREAD
-   2f6370c0 subsys: logging: for native_posix use appropriate tracing
-   6162caf7 logger: Add init() api and simplify init and activate
-   94bae6a4 logger: Move native_posix_backend definition
-   8fc5fd55 logger: Simplify UART backend initialization
-   9666e46f logging: fix undeclared __log_current_const_data_get
-   2328ed7e subsys: logging: native_posix: Fixed output buffer size
-   ba01a395 logging: Add shell commands
-   204acc82 subsys: logger: fix merge error
-   7c19e906 subsys: logging: Mark the local functions as 'static'
-   07da32aa logging: Add option to suppress level printing in
    log_output
-   2cc6d0c9 logging: Add option to suppress timestamp printing in
    log_output
-   1aed3858 logging: rename log_process_thread to logging
-   87d177a6 logging: allow mulitple log_panic calls

Maintainers (6):

-   a06f091b CODEOWNERS: fix syntax
-   d7f7324d CODEOWNERS: adapt to new location of soc code
-   b7fdc239 CODEOWNERS: Add @MeganHansen to review nxp board docs
-   a75dfe35 CODEOWNERS: Assign missing nRF boards and SoC
-   4ed481b0 CODEOWNERS: Assign maintainers for Nordic SoC .dtsi files
-   30d04578 CODEOWNERS: Assing maintainer for all native_posix backends

Miscellaneous (37):

-   e2e0720c release: Post-release patch level update
-   5c48c26f release: Post-release patch level update
-   28f5da6c subsys: shell : fs new shell module for fs mount operation
-   a1135620 misc: printk: Change function return
-   da49f2e4 coccicnelle: Ignore return of memset
-   a7fffa9e headers: Fix headers guards
-   67ca1767 headers: Fix headers across the project
-   4a211ec2 include: Add missing headers guard
-   9d3237c8 shell: Add support for custom line2argv callback
-   52725650 shell: Rename shell to legacy_shell
-   6aed72e4 shell: Shell subsystem reimplementation
-   f7aad1a8 sys: dlist: Add sys_dlist_peek_prev_no_check and
    sys_dlist_peek_prev
-   82ca8116 shell: Add shell history feature
-   989fef9c shell: Add built-in shell commands
-   c71a5595 shell: Extend shell as a log backend
-   68249ce9 shell: Add wildcard support
-   f568673e c++: Fix compilation of C++ file that includes i2c.h
-   8feab483 shell: fix shell_log_backend dependency
-   73c01f9e shell: modules: Adapt kernel commands to new shell
-   e59b8cbe subsys : shell : Added API changing prompt
-   f3db4d70 subsys: shell: removing troubleshooting assert
-   73c21780 shell : assert standardization
-   46f7cd51 shell: kernel: print thread name
-   6d3fb8b4 shell: kernel: add more thread data to threads command
-   ab8d0c4f include/logging: Avoid subtraction on void pointers
-   e1e12ba0 gitignore: Ignore GNU Global's tag files
-   c09b76ab subsys: shell: support posix arch
-   3e41ac5f subsys: shell: Add missing dependency to SERIAL
-   070716ec misc: dlist: Returning boolean for assertive functions
-   2c924119 misc: assert: Using boolean constants
-   788f9665 misc: list_gen: Using boolean expressions
-   420bb620 misc: dlist: Using boolean expressions
-   d67096da portability: Avoid void* arithmetics which is a GNU
    extension
-   28394cc4 portability: Warn at void* arithmetics which is a GNU C
    extension
-   f0e2e1bc portability: Remove C99-illegal semicolons from the global
    scope
-   9960bd95 portability: Ensure no C99-illegal semicolons exists in
    structs
-   20b28ba6 misc: mic

Networking (38):

-   4d375eef net: config: Use sizeof() to get size of buffer for
    net_addr_ntop()
-   5f8d24ba net: Add INET_ADDRSTRLEN POSIX define
-   c4cc8a5f net: if: Refactor IPv6 address lifetime timer
-   09390e5b net: if: Support long lifetime IPv6 prefixes
-   3f4d4680 net: if: Add utility function to return IPv6 prefix info
-   1d33f2ba net: shell: Add information about IPv6 configuration
-   e1757277 net: lldp: Implement LLDP RX API
-   c90549c4 net: buf: Use void * instead of u8_t * for arbitrary data
-   b088a092 net: buf: Use size_t instead of u16_t for lengths in public
    API
-   b6468999 net/pkt: Rename link layer address accessors relevantly
-   c21b0fb3 net: sockets: Add a socket offload module
-   f1e5e17d net/udp: Removing useless insert/append _raw functions
-   a7ddb1fb net/udp: Removing useless init function
-   e8dee890 net/udp: Separating net_context from udp and other cleanup
-   5286524a net: tls: Add missing entropy header
-   349e14d6 net: tls: Fix mbedtls hostname erros when certificates are
    not used
-   09b6f956 net: gptp: kconfig: Fix log-based intervals help
-   c3baa227 net: gptp: Fix sync timeout calculation
-   3c68a067 net: gptp: Fix the default value of sync receipt timeout
-   24a91afa net: gptp: Remove unused macro
-   ab8ff324 net: mdns: Select source IPv4 address properly for sent msg
-   0433e1a8 net: mdns: Wrong net_buf pool was used
-   fc27a81e net: context: Select proper network interface when binding
-   3b8c37de net: route: Check NULL value in debug print
-   02e9f9c8 net: route: Check that neighbor exists before deleting it
-   9f798623 net: buf: Use net_buf_add_mem in net_buf_append_bytes
-   7ba6736a net: ipv6: set pkt properties prior to routing
-   2cd1e418 net: sockets: Add missing POLLERR definition
-   85925018 net: Remove s_addr/s6_addr defines from in_addr/in6_addr
-   2bdc5923 net: coap: Fix Coap coap_option_value_to_int and
    coap_append_option_int
-   a84e60b8 net: gptp: Rename the ClockMasterSyncReceive state struct
-   792dfd4a net: gptp: Convert SyncReceiptTime to ExtendedTimestamp
-   5c5a4461 net: gptp: Fix port number in SYN and FUP packets
-   117b9ac3 net: gptp: Use packed enums when applicable
-   68127a31 net: gptp: Initial GrandMaster capability support
-   0888da4d net: gptp: Add clock accuracy selection
-   a979841e net: gptp: Fix sync receipt timeout timer starting
-   3a51c8d9 net: gptp: Fix sync interval timeout timer starting

Power Management (1):

-   c511857f subsys: power: Add support for pluggable PM policies

Samples (39):

-   e02dcf25 samples: lldp: Add simple parsing to sample
-   844e6f5a samples: net: sockets: echo: enable socket offload for
    cc3220sf_launchxl
-   53cd7c24 samples: basic: button: use dts-generated defines
-   7fb051bc samples: nrf52: onoff_level_lightning_vnd_app: use
    dts-generated defines
-   0a157938 samples: nrf52: onoff-app: use dts-generated defines
-   ea4f8b7d samples: nrf52: power_mgr: use dts-generated defines
-   89f00e64 samples: mesh: nrf52: upgrade README.rst
-   c805beea samples: mesh: nrf52: initialized dev_uuid to some
    arbitrary value
-   6858cb41 samples: mesh: nrf52: corrected conditional compilation
-   864ebaab samples: mesh: nrf52: revised status resp. behaviour & TT
    calculation
-   be27afb7 samples: mesh: nrf52: corrected spelling
-   09e2cf3d samples: mesh: nrf52: corrected state Binding for Delta
    Level
-   ccade20c samples: mesh: nrf52: corrected Range status response
-   ef7a2318 samples: shared_mem: Reduce CMake required version to 3.8.2
-   4add83c5 samples: subsys: logging: example of kconfig.log_template
    usage
-   8ec537dc samples: nvs: improve one output message, fix another one
-   47c20d6e sample: we have dedicated test for single thread
-   e36c7f5b samples: hello world: print board name
-   169cab09 sample: subys: logging: fix for posix arch
-   006ca970 samples: openamp: build with ninja
-   8c8de70f samples: blink_led: add support for nRF boards
-   a0efbf3c samples: bme280: Disable i2c in spi project configuration
-   ba808d78 samples: subsys: shell: Port sample to new shell subsystem
-   3d836016 samples: net: echo_server: Add VLAN support
-   b9fa6d4b samples: net: echo-client: Add VLAN support
-   b17b1609 samples: net: sockets: echo-client: Add VLAN support
-   27d99d16 samples: net: sockets: echo_server: Add VLAN support
-   7e273b28 samples: subsys: power_mgr: Add changes as per PM policy
    Kconfig
-   58542d8d samples: Include regex matching in samples
-   cc56de70 samples: apds9960: rework APDS9960 sample
-   7ee8b7a5 samples: Provide x-nucleo-iks01a1 shield sample
-   b3829adc samples: shell: enable kernel shell
-   743e6499 samples: net: sockets: Put echo samples configuration into
    single file
-   b4d85639 samples: net: sockets: Use TLS overlay config file
-   e4fa2f5d samples: sockets: echo_client/server: Build for minimal
    libc
-   a6de97b3 samples: net: sockets: Update docs with TLS information
-   739fd901 samples: synchronization: remove unused conf
-   2f30c5dc samples: synchronisation: set thread names
-   4e5a316b samples: blinky: Remove platform whitelist

Scripts (13):

-   5cf80e4e scripts: requirements.txt: fix PyYAML for python 3.7
-   c5ada394 scripts: extract_dts_includes.py: generate 'compatible'
    CONFIG flags
-   5f102fbf scripts: ci: Set SOC_DIR for check-compliance.py
-   6af68b36 scripts: elf_helper.py: run through flake8
-   7a08b2b3 scripts: gen_kobject_list.py: run through flake8
-   2e7bdb6b scripts: gen_priv_stacks.py: run through flake8
-   8245b0c1 scripts/dts: extract_dts_includes: remove unused 'names'
    argument
-   cc054c80 scripts/dts/extract: factorize 'reg' prop extraction
-   14ced2f0 scripts/dts/extract: Cleanup reg extraction
-   c57f3a09 scripts/dts/extract: Fix handling of value extraction based
    on cells
-   55b462cd scripts: update west to latest upstream version.
-   9e3edbbd scripts: fix west launcher for macOS
-   ddad53ab scripts: add colorama to requirements.txt

Storage (7):

-   9ec11d70 subsys: fs/nvs: improve some comments
-   afa9e1f9 subsys: fs/nvs: improve syslog messages
-   f1c6f91d subsys: fs/nvs: declare the ate structure as packed
-   725d9f7e subsys: fs/nvs: simplify crc8 computation
-   7a76792c subsys: fs/nvs: break if no end of sector is found
-   ce7e1a1c subsys: fs/nvs: do not change flash protection for
    zero-length case
-   9fa1af69 subsys: fs/nvs: do not leave the flash unprotected in case
    of error

Testing (27):

-   f8c6c7f0 tests: net: ipv6: Test long address lifetime timeouts
-   6850df31 tests: net: ipv6: Test long lifetime IPv6 prefixes
-   8f3c3384 tests/cmsis_rtos_v1: Introduce negative tests for mailQ
-   ced1c03c tests: posix: Test realtime clock
-   ec18f1d6 tests: tinycrypt: consolidate tests
-   ec6b0dfb tests: crypto: rename hmac_prng
-   75780a81 tests: pipe: Enhance tests to improve code coverage
-   4c81e94a tests: usb: Don't enable stdout console
-   df2cc408 tests: usb: Enable usb tests on frdm_k64f
-   eca0fb6c tests: subsys: logging: log_core fix with inplace process
-   05272d62 tests: mem_protect: syscalls: set CONFIG_USERSPACE in
    prj.conf
-   cd850647 tests: subsys; logging: log_core test to cover
    LOG_MODULE_DECLARE()
-   cddf26a4 tests: spi_loopback: Add mimxrt1050_evk configuration
-   806bc1a4 tests: build_all: Add missing dts fixups for sensor drivers
-   71feeceb tests: build_all: Add missing sensor drivers and rebalance
    testcases
-   a8f26756 tests: userspace: Update the required stack size for
    mps2_an385
-   44057a19 tests: kernel: pipe : Update the stack size.
-   b19f3ec2 tests: mem_protect: mem_protect: Update the stack size.
-   0e11792f tests: userspace: Incorrect location to the privileged
    stack.
-   da736062 tests: benchmarks: sys_kernel: Reduce the number of loops.
-   22d653fd tests: sched: Use SCHED_MULTIQ for native posix platform
-   d2d07644 tests: build_all: Add missing dts fixups for apds9960
-   71f5a177 tests: i2c_slave_api: Add missing testcase.yaml
-   4b120c27 tests: adc_api: Fix delay problem with test
-   f6e7e989 tests: test k_thread_name_set
-   bded528b tests: uart: add extra config for native_posix
-   6a34c725 tests: POSIX: Enhance test to verify deadlock


Re: Compilers working on Zephyr

Flavio Ceolin
 

Hi Gil,

Thanks for pointing it out. I'll take a look on it.


Hi Flavio,

I also recorded some issues attempting to integrate TI compiler/toolchain:

https://github.com/zephyrproject-rtos/zephyr/issues/9284

I haven't gotten back to it as it's lower priority for the moment.

Regards,
- Gil


On 1 October 2018 at 10:29, Flavio Ceolin <flavio.ceolin@intel.com> wrote:

Hi Sebastian,

The in-tree documentation is lacking indeed, but I also wanted to know
whether people is trying to use other compilers and the problems they
are facing.

The work on MISRA-C and C99 conformance will make easier use different
tools -from code only perspective - and I'm trying to map what are the
other
problems.

This is a known hole in our documentation.

To discover toolchains that have in-tree integrations see the contents
of zephyr/cmake/toolchain.

Toolchains that are not integrated use CROSS_COMPILE, but using
CROSS_COMPILE will only work for certain types of toolchains and certain
types of Zephyr configurations.

________________________________________
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> on
behalf of Flavio Ceolin <flavio.ceolin@intel.com>
Sent: Saturday, September 29, 2018 12:01:04 AM
To: zephyr-devel@lists.zephyrproject.org
Subject: [Zephyr-devel] Compilers working on Zephyr

Hi,

Guys I'm trying to have a list of supported compilers on Zephyr, but in
our wiki just mention about 3rd-party compilers but don't mention any
other than GNU ARM compiler.

If you are using a compiler different from our SDK, can you tell me so I
can catalog it. If you're just trying to use other compiler, please tell
me which problems you are facing.

Regards,
Flavio Ceolin

Regards,
Flavio Ceolin



Regards,
Flavio Ceolin


GPIO flags rework

Kumar Gala
 

Wanted to get anyone and everyone’s input on cleaning up the GPIO flags. Please comment on this GitHub issue if you have input:

https://github.com/zephyrproject-rtos/zephyr/issues/10339

Thanks

- k


Nordic nRF52: Including nrfx_gpiote

Gavrikov Paul <Paul.Gavrikov@...>
 

Hello,

 

I am having trouble to include “nrfx_gpiote.h”. I can see that “nrfx_gpiote.c” only implements all methods if the check “NRFX_CHECK(NRFX_GPIOTE_ENABLED)” is passed.

But how do I set NRFX_GPIOTE_ENABLED? Is there any Kconfig parameter for this?

 

Best,

Paul

 


Re: Choosing Tx Buffers in BLE stack

Chettimada, Vinayak Kariappa
 

Hi Dhananjay,

Related PR and its explanation in the commit message: https://github.com/zephyrproject-rtos/zephyr/pull/10332

This does not solve your Windows crash, but will in general reduce data transmission latencies in the cases where in host is trying to continuously transmit packets as fast as it can.

Regards,
Vinayak

-----Original Message-----
From: <devel@lists.zephyrproject.org> on behalf of "dhguja@gmail.com" <dhguja@gmail.com>
Date: Monday, 1 October 2018 at 4:20 PM
To: "Dunaj, Pawel" <Pawel.Dunaj@nordicsemi.no>
Cc: "devel@lists.zephyrproject.org" <devel@lists.zephyrproject.org>
Subject: Re: [Zephyr-devel] Choosing Tx Buffers in BLE stack

Hello Pawel,
Thank you very much for the reply.


Yes i used the zephyr sample as reference(HoG mouse device) but modified for keyboard. The report map i use is directly from Nordic SDK HID keyboard sample.
I am also sending standard USB HID report for every character (u8_t
modifier, u8_t media, u8_t keys[6]
=> totally 8 bytes). I think every BLE packet sends one character
since I did not change the MTU size (~20 bytes for application)


This report map and report along with BLE Tx buffer changes works fine in Android and iOS device without any problems. Even in Windows if i use the default buffer

settings where 1 character is sent every connection interval, things works fine. Only when there are more packets sent continuously without a delay windows HID driver
crashes in the middle. I also tried to enable some low level logs in zephyr BLE for debugging but apparently logging adds some delay which hides the problem from appearing.


Also your comment is true
"Zephyr will block when there is no buffer available to add the notification data too"

Zephyr did block the notify API when the windows driver crashed and could not receive further characters.




I checked the behavior of other existing HID barcode scanner devices where i see that there is at least a delay (almost connection interval time) every 9-10 characters sent.
I was just curious if we can config this as setting in Zephyr. These commercial devices also send the data to windows with similar timing per packet (~ 600 microsec)
as my Zephyr based device . The only difference is the delay of connection interval for every ~10 packets.



Is there something i can further do from zephyr configs?


Regards,
Dhananjay G J


On Mon, Oct 1, 2018 at 3:37 PM <pawel.dunaj@nordicsemi.no> wrote:


Hi,

Whatever Zephyr is doing I don't think Win should crash. I expect this is a bug in the OS or the driver. You can try MS support, maybe they can help. It should simply reject the data (that will probably not help you much as you may miss an information about
key release).

At first I expected you are not sending normal HID data but instead put some custom data in the HID report, but you state that you work on a keyboard. Are you using zephyr hid sample? How is your report defined? How much data are you sending with each notification?

Zephyr will block when there is no buffer available to add the notification data too. If data is not picked fast enough by the host (i.e. connection is slow) pipeline of data waiting to be served will build up. It is up to your application to ensure the valid
data flow. For that you can check optional callback added to Zephyr recently.

As for limiting the number of data sent with each connection interval, you are doing that by correctly setting up the report map and sending data according to it. Are you doing that? (Maybe system receives too much data compared to what was stated in the map
and crash?)

To limit the data sent with each interval you can try changing MTU, however I don't think this is the problem.

Thanks,
Pawel


Re: Does Zephyr allow provisioning using relays?

vikrant8051 <vikrant8051@...>
 

Hi,

FYI, as of now #nRFMesh App itself doesn't support remote provisioning.

Regards,
vikrant

On Mon, Oct 1, 2018, 8:14 PM IosuGorostiza <balcalde@...> wrote:
Hi, everybody:
I´m using four boards Nordic PCA10056 with nRF52840 for creating a simple mesh net. For provisioning I´m using the Nordic App  nRF mesh. I'm using the sample "onoff_level_lighting_vnd_app". Two of the boards are configured as relays, one is Generic On/Off Client and the last one is Generic On/Off  Server. Between the Client and the Server are the relays like this:

Client -> Relay1 -> Relay2 -> Server

When I´m close to the Client the App nRF mesh doesn't reach  the Server and when I'm close to the Server the doesn't reach  the Client. For provisioning all the net I have to move close to the Server and close to the Client. 
I would like to know if Zephyr allows to provisioning using  relays.

Thanks in advance.
Best regards


Re: Does Zephyr allow provisioning using relays?

vikrant8051 <vikrant8051@...>
 

Hi,
As per my knowledge, remote provisioning is not yet part of Bluetooth SIG Mesh specification. That is why this feature is not included in Zephyr mesh stack.

Nordic own mesh SDK supported it. Have you tried to do remote provisioning using #nRFMesh App on Mesh in which NODEs are executing Nordic mesh SDK ? Because I have doubt that it is possible with #nRFMesh App itself.

Thanks & regards,
vikrant






On Mon, Oct 1, 2018, 8:14 PM IosuGorostiza <balcalde@...> wrote:
Hi, everybody:
I´m using four boards Nordic PCA10056 with nRF52840 for creating a simple mesh net. For provisioning I´m using the Nordic App  nRF mesh. I'm using the sample "onoff_level_lighting_vnd_app". Two of the boards are configured as relays, one is Generic On/Off Client and the last one is Generic On/Off  Server. Between the Client and the Server are the relays like this:

Client -> Relay1 -> Relay2 -> Server

When I´m close to the Client the App nRF mesh doesn't reach  the Server and when I'm close to the Server the doesn't reach  the Client. For provisioning all the net I have to move close to the Server and close to the Client. 
I would like to know if Zephyr allows to provisioning using  relays.

Thanks in advance.
Best regards


Re: Compilers working on Zephyr

Gil Pitney
 

Hi Flavio,

I also recorded some issues attempting to integrate TI compiler/toolchain:


I haven't gotten back to it as it's lower priority for the moment.

Regards,
- Gil


On 1 October 2018 at 10:29, Flavio Ceolin <flavio.ceolin@...> wrote:
Hi Sebastian,

The in-tree documentation is lacking indeed, but I also wanted to know
whether people is trying to use other compilers and the problems they
are facing.

The work on MISRA-C and C99 conformance will make easier use different
tools -from code only perspective - and I'm trying to map what are the other
problems.

> This is a known hole in our documentation.
>
> To discover toolchains that have in-tree integrations see the contents of zephyr/cmake/toolchain.
>
> Toolchains that are not integrated use CROSS_COMPILE, but using CROSS_COMPILE will only work for certain types of toolchains and certain types of Zephyr configurations.
>
> ________________________________________
> From: devel@... <devel@...> on behalf of Flavio Ceolin <flavio.ceolin@...>
> Sent: Saturday, September 29, 2018 12:01:04 AM
> To: zephyr-devel@lists.zephyrproject.org
> Subject: [Zephyr-devel] Compilers working on Zephyr
>
> Hi,
>
> Guys I'm trying to have a list of supported compilers on Zephyr, but in
> our wiki just mention about 3rd-party compilers but don't mention any
> other than GNU ARM compiler.
>
> If you are using a compiler different from our SDK, can you tell me so I
> can catalog it. If you're just trying to use other compiler, please tell
> me which problems you are facing.
>
> Regards,
> Flavio Ceolin
>
>

Regards,
Flavio Ceolin





Re: Compilers working on Zephyr

Flavio Ceolin
 

Hi Sebastian,

The in-tree documentation is lacking indeed, but I also wanted to know
whether people is trying to use other compilers and the problems they
are facing.

The work on MISRA-C and C99 conformance will make easier use different
tools -from code only perspective - and I'm trying to map what are the other
problems.

This is a known hole in our documentation.

To discover toolchains that have in-tree integrations see the contents of zephyr/cmake/toolchain.

Toolchains that are not integrated use CROSS_COMPILE, but using CROSS_COMPILE will only work for certain types of toolchains and certain types of Zephyr configurations.

________________________________________
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> on behalf of Flavio Ceolin <flavio.ceolin@intel.com>
Sent: Saturday, September 29, 2018 12:01:04 AM
To: zephyr-devel@lists.zephyrproject.org
Subject: [Zephyr-devel] Compilers working on Zephyr

Hi,

Guys I'm trying to have a list of supported compilers on Zephyr, but in
our wiki just mention about 3rd-party compilers but don't mention any
other than GNU ARM compiler.

If you are using a compiler different from our SDK, can you tell me so I
can catalog it. If you're just trying to use other compiler, please tell
me which problems you are facing.

Regards,
Flavio Ceolin

Regards,
Flavio Ceolin


Benchmarking of Real-Time Operating Systems for Internet of Things Devices

julien.gomez@...
 

Hello Zephyr community !

We are two students of the Université catholique de Louvain from Belgium and we work on our master thesis. The thesis is called "Benchmarking of Real-Time Operating Systems for Internet of Things Devices" and is about comparing the different implementations of open-source RTOS's currently available on the market.

In broad outline, we are planning to analyze the scheduling, switching context, memory management and/or any relevant metric dependant of the operating system.

Another goal is to compare networking performances or implementations of the various stacks available. We have currently no concrete planning for this part.

This project will be open source (because we <3 the open source).

Here are some questions we have for you:
- "What would you like to see in this benchmarking project?";
- "What RTOS should we benchmark?";
- "What metric should we consider?".

We'd love to hear your recommandations or any help you can provide us with.

Also if you are interested about how the project will evolve, we'll be glad to update you on our progress.

If the project gain lot of interests, we will probably create a communication channel like Slack or Gitter.

Sincerely,
Julien Gomez and Trong-Vu Tran



Does Zephyr allow provisioning using relays?

IosuGorostiza <balcalde@...>
 

Hi, everybody:
I´m using four boards Nordic PCA10056 with nRF52840 for creating a simple mesh net. For provisioning I´m using the Nordic App  nRF mesh. I'm using the sample "onoff_level_lighting_vnd_app". Two of the boards are configured as relays, one is Generic On/Off Client and the last one is Generic On/Off  Server. Between the Client and the Server are the relays like this:

Client -> Relay1 -> Relay2 -> Server

When I´m close to the Client the App nRF mesh doesn't reach  the Server and when I'm close to the Server the doesn't reach  the Client. For provisioning all the net I have to move close to the Server and close to the Client. 
I would like to know if Zephyr allows to provisioning using  relays.

Thanks in advance.
Best regards


Re: Choosing Tx Buffers in BLE stack

dhguja@gmail.com
 

Hello Pawel,
    Thank you very much for the reply. 

Yes i used the zephyr sample as reference(HoG mouse device) but modified for keyboard. The report map i use is directly from Nordic SDK HID keyboard sample.
I am also sending standard USB HID report for every character (u8_t modifier, u8_t media, u8_t keys[6] => totally 8 bytes). I think every BLE packet sends one character
since I did not change the MTU size (~20 bytes for application)

This report map and report along with BLE Tx buffer changes works fine in Android and iOS device without any problems. Even in Windows if i use the default buffer 
settings where 1 character is sent every connection interval, things works fine. Only when there are more packets sent continuously without a delay windows HID driver
crashes in the middle. I also tried to enable some low level logs in zephyr BLE for debugging but apparently logging adds some delay which hides the problem from appearing.

Also your comment is true
"Zephyr will block when there is no buffer available to add the notification data too"
Zephyr did block the notify API when the windows driver crashed and could not receive further characters.

I checked the behavior of other existing HID barcode scanner devices where i see that there is at least a delay (almost connection interval time) every 9-10 characters sent. 
I was just curious if we can config this as setting in Zephyr. These commercial devices also send the data to windows with similar timing per packet (~ 600 microsec)
as my Zephyr based device . The only difference is the delay of connection interval for every ~10 packets.

Is there something i can further do from zephyr configs?

Regards,
Dhananjay G J

On Mon, Oct 1, 2018 at 3:37 PM <pawel.dunaj@...> wrote:
Hi,

Whatever Zephyr is doing I don't think Win should crash. I expect this is a bug in the OS or the driver. You can try MS support, maybe they can help. It should simply reject the data (that will probably not help you much as you may miss an information about key release).

At first I expected you are not sending normal HID data but instead put some custom data in the HID report, but you state that you work on a keyboard. Are you using zephyr hid sample? How is your report defined? How much data are you sending with each notification?

Zephyr will block when there is no buffer available to add the notification data too. If data is not picked fast enough by the host (i.e. connection is slow) pipeline of data waiting to be served will build up. It is up to your application to ensure the valid data flow. For that you can check optional callback added to Zephyr recently.

As for limiting the number of data sent with each connection interval, you are doing that by correctly setting up the report map and sending data according to it. Are you doing that? (Maybe system receives too much data compared to what was stated in the map and crash?)

To limit the data sent with each interval you can try changing MTU, however I don't think this is the problem.

Thanks,
Pawel


Re: Choosing Tx Buffers in BLE stack

pawel.dunaj@...
 

Hi,

Whatever Zephyr is doing I don't think Win should crash. I expect this is a bug in the OS or the driver. You can try MS support, maybe they can help. It should simply reject the data (that will probably not help you much as you may miss an information about key release).

At first I expected you are not sending normal HID data but instead put some custom data in the HID report, but you state that you work on a keyboard. Are you using zephyr hid sample? How is your report defined? How much data are you sending with each notification?

Zephyr will block when there is no buffer available to add the notification data too. If data is not picked fast enough by the host (i.e. connection is slow) pipeline of data waiting to be served will build up. It is up to your application to ensure the valid data flow. For that you can check optional callback added to Zephyr recently.

As for limiting the number of data sent with each connection interval, you are doing that by correctly setting up the report map and sending data according to it. Are you doing that? (Maybe system receives too much data compared to what was stated in the map and crash?)

To limit the data sent with each interval you can try changing MTU, however I don't think this is the problem.

Thanks,
Pawel


Re: Choosing Tx Buffers in BLE stack

dhguja@gmail.com
 

Hi All,
      With regards to my previous problems I have some basic questions to understand this problem. 
By increasing the Tx Buffers i increased the number packets transmitted per connection interval. 
Even though this increased my data transfer speed i faced compatibility issue with windows HID driver 
crashing in the middle of transmission. I read that Android and iOS systems sometimes have a limit on 
the number of packets transmitted per connection interval time. May be for windows too there may be 
some limit  on this factor. when i checked the HCI logs i see that almost all the HID characters are sent 
with in one connection interval for my device. 

Is it possible to configure this factor in zephyr either directly or indirectly?
(or) 
Should application layer handle these delays?

Regards,
Dhananjay G J



On Fri, Sep 21, 2018 at 3:42 PM dhananjay gj <dhguja@...> wrote:
Hi,
    Thanks for the reply. Sorry if there is some confusion regarding the crash on windows. 

I will explain more elaborately below what i am trying to achieve & what i debugged till now.

I am working on BLE based barcode scanner which will send the data via HID over GATT profile. I am using nRF52840 
device and Zephyr 1.13 with default connection interval parameters. With the default Tx buffer numbers provided in zephyr
the characters are sent to peer devices very slowly. We can literally see that characters are printed one by one. When i checked
the HCI timestamps using btmon i see that 1 character is sent every connection interval time(around 45 ms ). 

To remove the bottleneck on Tx buffers i increased Maximum number of pending TX buffers (3) , Number of Tx buffers(3).
I see that characters are sent instantly now (within one connection interval or even less than 10ms). The improvement in speed
is seen only when i change both of these parameters from the default values.

Now with this new config changes related to Tx buffers my application works fast as expected in Android, iOS, Linux systems. 
But on windows 10 system after two or three scans 'Windows' HID driver crashes probably due to buffer overflow from sending the 
data so fast. I checked the windows log and i see that "A command sent to the adapter has timed out. The adapter did not respond".
The behavior seen is that characters are not accepted anymore and the last character that is sent to windows is printed continuously 
until the connection is closed. On the zephyr side, the bt_gatt_notify API is blocked until this time and then returns with error. 
I also checked the connection interval used with Windows 10 system as 40 ms.

I also changed different buffer numbers to know the behavior but this just changes the time when this crash in windows occurs again. 
I also checked with some commercial devices that have similar application of using HID profile to send data and it also uses buffering
to speed up. One thing i noticed in commercial device is for every 10 characters sent there is some delay equal to max connection 
interval time. But in case of my application using zephyr there is just 1 delay with connection interval for even up to 40 characters that are 
sent.

In order to control the speed of buffering i tried changing different buffer numbers but with no luck or information on how to proceed
further. If i know how to calculate or more information on these i can try to control the speed of my application by using buffer numbers or 
delays like i saw in other commercial devices. It would be helpful even if i had to look for something else in BLE specification or Zephyr.

Thanks very much for the help.

Regards,
Dhananjay G J











On Fri, Sep 21, 2018 at 1:20 PM Von Dentz, Luiz <luiz.von.dentz@...> wrote:
Hi,

I guess that is because with more buffer one can queue more data and
is less affected by the speed in which the controller acknowledge
their transmissions, obviously this increase the footprint but it is
the usual trade of size for speed. Btw, if the improvement is
substantial maybe we should have 3 by default, though we need to
figure if the crash on windows is due to some misbehaviour on our side
when are operating with more buffers.

On Fri, Sep 21, 2018 at 1:58 PM, Cufi, Carles <Carles.Cufi@...> wrote:
>
> Hi there,
>
> Copying a few people to this thread.
>
> Carles
>
> ________________________________
> From: devel@... <devel@...> on
> behalf of dhguja@... <dhguja@...>
> Sent: Thursday, September 20, 2018 11:56 AM
> To: devel@...
> Subject: [Zephyr-devel] Choosing Tx Buffers in BLE stack
>
> Hello,
>       I am working on a BLE HID keyboard application using zephyr 1.13.
>
> I was playing around with Tx buffers (specifically Maximum number of pending
> TX buffers, Number of Tx buffers).
> With default buffer settings the characters were transmitted very slowly due
> to small number of buffers. But as soon as
> i increased it to 3 pending buffers and 3 Tx buffers i saw significant
> improvement in the speed of characters transmitted.
> My question is how to choose the buffer values for this?.
>
> The reason is currently i face a compatibility problem with my HID
> application, where it works fine in Linux, Android, iOS devices
> with increased number of buffers, but crashes on windows system. When i
> debugged the HCI log (from btmon) i saw that with
> increased buffers, characters are sent very quickly on the order of 500 us
> for each character. This causes the data (of 20 characters)
> to be transmitted within one or two connection intervals. Maybe this causes
> some overflow in windows systems. I would like to know
> what are the implications of choosing a number of Tx buffers and pending
> buffers.
>
> It will be helpful if anyone can tell how to choose the number of Tx
> buffers? or even point to some direction in the BLE specification?
>
> Thank you,
> Dhananjay G J

3321 - 3340 of 8517