I am not in favour of adding the stm32 layer. I am all for adding the "SoC series" or "family layer”. What this means: instead of arch/ arm/ soc/ stm32/ st_stm32f1/ st_stm32f2/

Hi Genaro, Could you give the gerrit links? Aren't these 2 being mitigated by CONFIG_STDOUT_CONSOLE ? If this option is set: printf will be used, printk otherwise. Tomasz

Jeudi 10-03-2016 à 23:14 Boie, Andrew P a écrit: Hello Andrew, ok, i'll send a patch soon. regards, Yves-Gaël.

Problem Statement: Add OS infrastructure to enable application-based power management policies, which is architecture independent, supports microkernel and nanokernel and the interface clearly

This is the second attempt to define a common system logging API, Original thread can be seen

Problem Statement: Zephyr needs to provide an architecture independent method for power management application to invoke the SOC Deep Sleep functionality. Why this is a

Problem Statement: Zephyr needs to provide an architecture independent method for power management application to invoke a low power state on the CPU. Why this is a

Problem Statement: Not all Zephyr kernel drivers provide the same interfaces. Why this is a problem: ----------------------------- The Zephyr kernel currently has devices that are essential for core

Problem Statement: Power management Kconfig flags are not consistent and hierarchy is not clear Why this is a problem: ----------------------------- The names include terms like “ADVANCED” which

Here are the revised RFCs that attempts to state the problems, reasons and solutions more clearly Thanks to Dan for spending a lot of time with me in making it right. (It was a challenge to put

The best thing to do if you find code defects is one of two things: 1. Send a patch to Gerrit that fixes it for review. 2. File a bug in JIRA https://jira.zephyrproject.org/ so that the issue is

Question: if they're almost the same, do we really need an extra directory layer, or simply have different files for the parts that differ in the same directory ? That would prevent

Of course, but I don't know if at the time we were thinking about supporting a bunch of variants of a particular microcontroller that are almost the same. I think this is an opportunity for

Hello, I have uploaded another iteration of the sensor API patches on Gerrit [1]. This addresses some minor issues that have been raised this week and also ports another driver, the SX9500 SAR

Hi, i just read the source code of zephyr. I have found an error into : drivers/spi/spi_k64.c line 204, baud_rate_prescaler is use instead of baud_rate_scaler (causes an out of bound

Where did you see a new layer in what I said? The current patch and adding st_stm32 is adding a new layer. st_stm32 is not an SoC, its an architecture (just like there is STM8) that has different

Do we need another layer of abstraction in the build for SoC variants? I share Dan's concerns, I think it may be better to have st_stm32/ SoC and then subdirectories with variants thereof, with common

Yes, the only different from what you have right now is having 1 level less. I think everything else should stay the same. Anas