Hi Andrew, Will you update the Getting Started guides to include the package in the command-line instructions? Thanks, Carles From:<zephyr-devel-bounces@...> on behalf of "Boie,

Now that the merge window is open and we are working towards 1.10, we have a new host system dependncy: gperf. It is a tool that has existed for a long time, it generates C code that implements

Hi, We are pleased to announce the release of Zephyr v1.9.0. Major enhancements planned with this release include: Bluetooth 5.0 Support (all features except Advertising Extensions) Bluetooth

Hi, Just tagged RC4, this will hopefully be the final RC and released as 1.9.0 https://github.com/zephyrproject-rtos/zephyr/releases/tag/v1.9.0-rc4 Regards, Anas

Hi Steve, Thanks! Except for a missing "Bluetooth: Mesh: " prefix in the commit subject, the patch looks good to me. However, the process for getting it included upstream is by creating a github

Signed-off-by: Steve Brown <sbrown@...> --- subsys/bluetooth/host/mesh/transport.c | 1 + 1 file changed, 1 insertion(+) diff --git a/subsys/bluetooth/host/mesh/transport.c

Hi Tamra, As far as I know, there is no “bdaddr_t” type in Zephyr. There is a “bd_addr_t” type that is declared in hci.h:

Hi Steve, I think you're right. Previously the code would do a "return bt_mesh_model_recv(rx, sdu);", but after the function was changed to return void adding a separate return statement was

I'm using bluez' meshctl to provision a redbear ble nano2 running zephyr at commit 637087cc56040b7b3c4a81d0707723fb68e17895. I've also applied unsupp_slave_feat_req.diff from Vinayak's email

You're right PA15 (usart2_pins_b) could not be connected to USART2. This is a real issue, and this is true for whole F4 series, not only F412. I'll correct it. Thanks

I re-read the datasheet. USART2_TX can be assigned to PA2 or PD5 USART2_RX can be assigned to PA3 or PD6 PA15 cannot be configured as USART2_RX and, seeing how multiplexing is set in

Hi Jehudi, This is the PR: https://github.com/zephyrproject-rtos/zephyr/pull/1390 Please add yourself as reviewer and approve the same after you have confirm the fix by testing. Regards, Vinayak

Find attached the diff to handle the unknown rsp. -Vinayak

Hi Jehudi, Thank you for the quick response. (btw, I am on #zephyrproject with nickname vich, if that’s faster to communicate) It was a local intiated slave feature req that is not support by the

Hi Vinayak, With the diff applied I got the following: Kernel stacks: main (real size 512): unused 220 usage 292 / 512 (57 %) idle (real size 256): unused 200 usage 56

Hi Zephyr Team, I am trying to compile a bluetooth application in the zephyr folder. I am trying to use the data type 'bdaddr_t', but I keep getting the error below: error: unknown type name

Hi Jehudi, This is very helpful. The local controller (if I assume correct, is in slave role) is under channel map update waiting for the instant when it received an unknown rsp PDU. Please apply a

Hi Vinayak and Carles, I applied the patch and increased stack sizes as required, it took some time before I got the error again. The result: Kernel stacks: main (real size 512): unused

Yes, for net_app APIs, this is expected behavior if the UDP client makes use of the net_app_connect() function (required if using DTLS). I noticed this as well when porting the LwM2M library to

Hi Jehudi, To further debug the conditions around the assert, please apply the attached diff. And send me which assert is hit. Regards, Vinayak