***These are implemented and under review*** https://gerrit.zephyrproject.org/r/#/c/532/ https://gerrit.zephyrproject.org/r/#/c/528/ https://gerrit.zephyrproject.org/r/#/c/525/ Device driver power

***This part is

Migrating this RFC from the old server for reference. This is updated with the feedbacks that were incorporated. This consists of the following parts: [0/3] - This overview [1/3] - SoC, CPU and

Hi Maciek, i'm inspired by your work and i would like to make port for other boards too , can you guide me from where can I start ? Regards, Piyush Pangtey

Really glad to see Zephyr upon chips of STM, my former employer :)

Hi

Hi, This is a much needed enhancement, thanks for making this proposal. We need to make sure we support logging for more than debugging and during development. In most cases logging will be used

Hi list, It has been a slow weekend, as part of my self-doubt recovery after a bad Codility experience I've started writing drivers for RCC, UART and pinmux for STM32F10x chips. The changes are

Problem: Setting up a Zephyr development environment on Microsoft Windows involves many steps. Proposal: Use Docker to automate the setup procedure. Docker Toolbox

Just to add missing sub-folder name in the hardware specific driver path:

Hi, I'm currently trying to build the hello world example in a directory outside the zephyr SDK and I keep getting this make

There is an effort going on right now, details will be provided soon. Anas

Hi, As per suggestion from Gerrit comment, moving the discussion to mailing list. Background -------------- On Quark (SE and D2000), there are Always On Counter (free running) and Always ON

<tomasz.bursztyka(a)linux.intel.com> wrote: The problem with the dev board that I used is that it's not really available anymore. To the best of my knowledge, the unit I have is an older version of

Hi Maciek, This is great stuff, it's totally worth working on porting Zephyr for STM32. I actually recently got the Nucleo boards F103, F030 and F334 as I was planning to play with Zephyr on it.

Hi Maciek, Very cool! Cortex-M4 should work as well, since the M4 is a superset of the M3. The first board we supported is the Freescale FRDM-K64F, which is an M4. For M0, you have to do an arch

Hi list, I've done a PoC port of Zephyr to STM32F103VE MCU on a EB-STM_06 dev board. The port is rather minimal, most of the configuration is hardcoded. The MCU is configured to use internal HSI

Hi, Dmitriy Korovkin <dmitriy.korovkin(a)windriver.com> writes: Exactly, from what I can see, it will be only one common function. I see. I wouldn't like that these _priv.{c,h} idiom would become

Problem: there are two similar mechanisms in nanokernel: nano_timers and nano_timeouts. In order to optimize codeand space it's better to have one mechanism for both. Proposal: Implement nano_timer