It looks like we need a PR to master to change doc/config.py to reference 1.14.1

Hi all, This week we will look at: - GPIO: Update on progress - Look at the PRs with driver conversion - Check the timeline - Debouncing:

Hi Alessandro, could you create github issue about the slowness of the networking stack, we can then discuss more about the issue there. Cheers, Jukka wrote:

Stefan, Erwan thank you for your feedback Cheers, Adam

The 1.14.1 docs are here: https://docs.zephyrproject.org/1.14.1/ We still need to update the indexes everywhere to point to the new dot release. David, where should this be changed? (show 1.14.1

Hi Marc, That's awesome and useful, thanks! - Pushpal

Extremely useful workaround: https://github.com/zephyrproject-rtos/zephyr/commits/v1.14-branch \-> https://github.com/zephyrproject-rtos/zephyr/pull/19639

Hi Anas, This is great, thank you. I had a question on the documentation - I can't seem to find the 1.14.1 docs. I see https://docs.zephyrproject.org/1.14.0/, just no 1.14.1. Is the

Hi Adam, We've started to push briks to enable power management on STM32. Two first PRs are: - https://github.com/zephyrproject-rtos/zephyr/pull/18582 that enable LPTIMER to enable a tick source in

Hi everyone, I am looking forward to some description or a hint how to utilize Power Management in STM32L0/L4 MCU family. System will work in power constraint environment. I've seen some HAL based

Hi, We are pleased to announce that we have tagged the first 1.14 maintenance releasewith fixes, as well as Bluetooth qualification listings for the Bluetooth protocol stack included in Zephyr.

Oh weird - I was on the developer call last week and everyone agreed it would be merged. Is there a merge window then? I have but no luck so far. In any case, are there some benchmarks available for

This hasn't merged yet and was never the backend for malloc() or k_mem_pool, are you pulling it locally and writing code to its internal API? Have you tried a simple git bisect over your tree to look

Recently a sys_heap change went into zephyr https://github.com/zephyrproject-rtos/zephyr/pull/17628 The PR says that it's faster, but I'm seeing some behaviour that would suggest that's not the

Something like this should work: struct device *clk_dev = device_get_binding(DT_INST_0_NORDIC_NRF_CLOCK_LABEL "_16M"); clock_control_on(clk_dev, (void *)1); Jim

Hello Zephyr Community, We work on board based on NRF52840 using zephyr. We are encountering problems to communicate with a device using UARTE at 9600 bit/s. We observe that the current speed is

The "west -vvv build" line is correct, but will potentially enable a lot more verbose output than is desired. The -v option can be given multiple times, and west build includes compiler output when

Reminder: Zephyr Project: Dev Meeting When: Thursday, 3 October 2019, 8:00am to 9:00am, (GMT-07: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: kernel: Introduce k_triggered_work: https://github.com/zephyrproject-rtos/zephyr/pull/14041 Let me know if anyone has any other topics. - k

Even simpler: west -vvv build samples/hello_world