NFFS support will be removed from the zephyr-project codebase. It was decided to take such action as NFFS has few serious issue which made it unreliable (Such issues were not fixed since a long

Phil, I sent a PR which adds a test for this: https://github.com/zephyrproject-rtos/zephyr/pull/21920 It passes on all the emulated targets we have (including Cortex-M), but if this is

Interrupts should be unlocked when handling system calls, and indeed a thread in a system call can sleep or be preempted. Sounds like you have found a bug. And a gap in testing, we ought to have a

Hi Johan Thank you for your quick reply. Yes, as you mentioned and as I already understand, hci_uart is for separating the controller and host on different chips. In this situation, I need to run my

Hello Zephyr users and developers, We've just uploaded a pre-release version of west to PyPI with a new feature: manifest imports. We would like your feedback! For a short README you can follow to

Reminder: Zephyr Project: APIs When: Tuesday, 14 January 2020, 9:00am to 10:00am, (GMT-08:00) America/Los Angeles Where:https://zoom.us/j/177647878 An RSVP is requested. Click here to

Hi all, This week we will focus on a new RFC and GPIO. - RFC: New counter_get_value() API call - https://github.com/zephyrproject-rtos/zephyr/issues/21846 - GPIO: Update on progress - Proposal

Hi Ryan, What do you mean by a “Host application”? A Bluetooth host application? Using what APIs? That’s a bit confusing. hci_uart is for cases where the Bluetooth controller and host are on

I've noticed that on ARM Cortex-R with user mode enabled, that when we enter the system call handlers, such as z_hdlr_k_str_out(), that interrupts are disabled. It seems to me that external

Hi there, I am currently trying to port the Zephyr HCI UART example (for nrf52840_pca10056) to FreeRTOS but and am having some difficulties doing so. The reasoning behind this is that I want to

Morning, As Erwan was telling, IMHO the pinmux variant is a good solution. For example if you doing power saving, you might power down parts of you pcb. Just image the case that you have a peripheral

Looks like https://lists.zephyrproject.org/g/devel/topic/61321118

Hi all, Device trees are used during compile time within Zephyr. But what if you want to support several hardware revisions in the same binary? (E.g. based on stored hw id or so) To minimize the

Hi all, Our current counter API has a function for reading the current counter value (counter_read()) which does not allow indicating read failure in a standard way. I have submitted an RFC for

Hi Allen, Pinmuxing is one of the remaining areas where device tree is not in use (except for socs with specific pin management such as nrf). So we still rely on the c definition for this. Cheers

I am obviously showing my ignorance here but I thought Zephyr was using device tree for this stuff. -- Allen Curtis Medical Device Architect Critical Software Solutions, LLC

Hi, Modifying board pinmux.c (along with boards .dst nd Kconfig.defconfig) is indeed the way to enable the device. It cannot be done otherwise. Once this is done (and tested ok) you can submit the

Hi all, I am using the stm32f4_disco board and I am trying to use the i2c ports, but it is not defined in pinmux.c and I must thzn modify this file to add the I2C configuration. Is there a better way

Reminder: Zephyr Project: Dev Meeting When: Thursday, 9 January 2020, 8:00am to 9:00am, (GMT-08:00) America/Los Angeles Where:https://zoom.us/j/993312203 An RSVP is requested. Click here to

Here’s the agenda topics for this week: * drivers: allow to retrieve device structure by the name prefix: [ https://github.com/zephyrproject-rtos/zephyr/pull/21709 ] * dt topics If there’s