Hi there, Zephyr supports both newlib and picolibc, which are fully-featured C standard libraries. Unless I am mistaken timezone-conversion functions are part of the C standard library (<time.h>), so

#zephyr

Hi there, We have a board porting guide that you can use as a starting point to work on adding support for this board: https://docs.zephyrproject.org/latest/hardware/porting/board_porting.html Feel fr

Hi Dave, The ztest framework is platform agnostic, so you can use it to build a Zephy image that then runs on Qemu, native_posix or on target hardware. There is also a Unit Testing framework (part of

Hi there, To my knowledge OpenCV does not support Zephyr. Looking at their ports folder it seems like they target full-blown operating systems, and not smaller RTOS like Zephyr: https://github.com/ope

If ST Micro uses custom HCI commands to create services then it means they are running both Host and Controller. For a platform-neutral Host that can work with any standard HCI device (including Zephy

#stm32 #nrf52840 #hci #spi

Hi there, BLE is fully reliable for GATT, and notifications are guaranteed to be delivered in sequence. But what you really want is to configure your GATT MTU to the size of the data you want to send.

#ble #bluetooth

Hi there, I am unclear as to what you are asking exactly, but I’ll give it a go. If your question is whether porting Zephyr code to another RTOS is easy, the answer is: generally it is not, because ev

#stm32 #nrf52840 #hci #spi

https://github.com/zephyrproject-rtos/zephyr/blob/df9c0d8efa2ead7c42000780d5cb3cd08b162300/include/zephyr/drivers/flash.h#L80 https://github.com/zephyrproject-rtos/zephyr/blob/df9c0d8efa2ead7c42000780

Hi there, https://github.com/zephyrproject-rtos/zephyr/blob/df9c0d8efa2ead7c42000780d5cb3cd08b162300/subsys/storage/stream/stream_flash.c#L178 Carles

I don’t think you need to create your own backend if you are willing to send a PR or carry an out-of-tree patch. As long as your backed of choice is using log_output_msg_process(): From what I can tel

Hi there, I think exceptions need some extra work to be thread-safe, but Stephanos should know more. Regarding the lack of documentation, we do have: https://docs.zephyrproject.org/latest/develop/lang

#CPP

Hi there, On the board acting as a Host (i.e. the one that is running the app, not the on running hci_uart) you need to add a chosen node for zephyr,bt-uart, like here: https://github.com/zephyrprojec

Hi Rob, I think you are referring to Zephyr's native_posix port, which we also call "Native port". It currently runs on Linux but Chris Friedt is working on porting it to macOS. You can find more info

Hi Mohamed, This look like a question related to Nordic’s nRF Connect SDK. Please ask this question in Nordic’s Devzone instead: https://devzone.nordicsemi.com/ Thanks! Carles

#nrf52832

Hi there, Right now, no. archs (unlike SoCs or boards) are expected to be in-tree. If you cannot upstream your arch you will likely need to keep a fork of Zephyr patched. Carles

#customboard

> PS: Now about Zephyr support for USB-host and USB-OTG... We do not have a timeframe for this, but it will certainly come sooner or later. Carles

Hi Dave, Thread safety for newlib was implemented in Zephyr recently, there should not be any issues left with it. If there are, please open a GitHub issue: https://github.com/zephyrproject-rtos/zephy

Hi there, Why don’t you send a Pull Request to the hal_nxp repository to add the HAL you need? Thanks, Carles

Additional item, as per the Stable API Change procedure: - RFC: API Change: IPM - Issue: https://github.com/zephyrproject-rtos/zephyr/issues/38609 - PR: https://github.com/zephyrproject-rtos/zephyr/pu

Hi all, Agenda for tomorrow: - Pinctrl: Now focusing on #37572 as the single PR to target our efforts - PR: https://github.com/zephyrproject-rtos/zephyr/pull/37572 - Updates by Gerard and Kumar on the