The reason that Zephyr does not copy the items to the list is that it offers primitives that copy them (message queues) and primitives that do not (FIFOs). Then you can use FIFOs if you have your own

Hi all, Another special agenda for today: - Modbus: https://github.com/zephyrproject-rtos/zephyr/pull/26516 - In order to help with the 2.4 release we will go through bugs labeled API or drivers and t

Hi Harish, Best I can think of for that is to use a filter in GitHub to see all issues (open and closed) that target the next 1.14.3 release: https://github.com/zephyrproject-rtos/zephyr/issues?q=+is%

Hi Harish, You can browse the issues that were addressed in the 1.14.x releases here: https://docs.zephyrproject.org/1.14.1/releases/release-notes-1.14.html https://github.com/zephyrproject-rtos/zephy

Hi all, Special agenda for today: - In order to help with the 2.4 release we will go through bugs labeled API or drivers and try to clean up or assign as many as we can. Teams link: https://teams.micr

Hi Erik, FYI, pyocd is Zephyr-aware and Nordic’s J-Link OBs can be reflashed with pyocd-compatible firmware: https://www.nordicsemi.com/Software-and-tools/Development-Kits/nRF52-DK/Download#infotabs A

#debugging #gdb #nrf52480 #ztest #bluetoothmesh

Hi Deepa, From your question it seems you are using the nRF Connect SDK, and not vanilla Zephyr. You should therefore direct your question to the Nordic DevZone instead: https://devzone.nordicsemi.com

Hi Dominik, >. Is there a reason why Zephyr does not copy the items to the queue like FreeRTOS does it? The Zephyr documentation lacks this kind of information! FIFOs do not copy the contents of the m

Hi Nikos, Maybe you want to look at MCUboot, which supports this out of the box and is integrated with Zephyr? https://mcuboot.com/ https://docs.zephyrproject.org/latest/reference/kconfig/CONFIG_BOOTL

#flash #nrf52480

Hi all, Agenda for today, sorry for the short notice. - Stable API change: All hid_ops callbacks get device pointer - https://github.com/zephyrproject-rtos/zephyr/pull/27619 - Add Regulator driver inf

Hi all, Agenda for tomorrow: - Extend LED API - PR: https://github.com/zephyrproject-rtos/zephyr/pull/26101 - [RFC] API change - Device structure attribute renaming - PR: https://github.com/zephyrproj

Hi all, Sorry for the late agenda. Topics for today: - RFC: downgrade i2c eeprom_slave driver to sample - Issue: https://github.com/zephyrproject-rtos/zephyr/issues/27303 - Add regulator driver infras

Hi all, Today's topics: - Device: Normalize DMA, IPM and UART callbacks signatures including the caller's device pointer (should be quick, PRs are already approved and email sent to the mailing lists)

Hi all, Today's topics: - Device: Normalize DMA, IPM and UART callbacks signatures including the caller's device pointer (should be quick, PRs are already approved and email sent to the mailing lists)

Hi Lawrence, Right, I think I understand what you mean. This is almost certainly a bug in the SMP shell transport, but just to make sure, please: Create an issue on GitHub with this description Includ

Hi Lawrence, Try instead using the .dts in your board, or add an overlay, and change this line: zephyr,uart-mcumgr = &uart0; Thanks, Carles

Hi all, Tomorrow's topics: - Conclusion on fs_open() flags Stable API Change: - Issue: https://github.com/zephyrproject-rtos/zephyr/issues/26833 - RFC: Require system clock stability on startup - Issu

Hi Simon, Not to my knowledge, no. But perhaps Ioannis or Anas know if it’s also documented elsewhere. Regarding the “stamp of approval” that was mentioned earlier in the thread, I think we could adop

Hi Simon, A decision like that would need to go through the TSC, and in order to be able to vote we’d need to have clear stats on how many PRs are actually blocked by this policy. I was thinking about

Hi all, Tomorrow's topics: - VIDEO/DISPLAY: add ELCDIF support and VIDEO/DISPLAY shim layer - PR https://github.com/zephyrproject-rtos/zephyr/pull/21009 - Add i2c_async for asynchronous transfers - PR