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

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 vari

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/ we will just have: arch

We are looking into this and will send a proposal to address this by EOD. Anas

I am working right now on defining a new layer in Kconfig and reorganising Kconfig for this purpose and will take the STM32 changes and propose better structure for all architectures and existing SoCs

Hi, The issue has been reported and being addressed. Still not known what the issue is exactly :( Anas

Mads, Were you trying to install the SDK on Mac OS? If yes, this issue will be addressed in the latest SDK drop which will be released today. Anas

Hi, Zephyr v1.2.0-rc1 has been tagged, merge window for major features is now closed. We are targeting a release of v1.2.0 end of this week. Below you will find the changes since v1.1.0. Regards, Anas

Beside the issue above, the proposal looks good to me and will definitely improve and expand the coverage. Lets find a way to make this work without adding the parser into the tree please. Thanks, Ana

also look at include/misc/stack.h for Stack usage analysis helpers Anas

Hi, We tagged release candidate 2 and planning to release 1.2.0 end of the day Friday. There are already a few bug fixes on top of rc2 that will be in the final release. Below is the log since 1.2.0-r

Hi, We tagged v1.2.0 and merge window for the next release is now open. Changes since v1.2.0-rc1 are below: Alexandre d'Alton (2): arc: implement stack checking arc: remove unecessary instruction and

Hi IMO the driver interface is still considered public APIs. Someone might be using those to write drivers external to Zephyr, changing the signatures will break such drivers. Anas

Hi, To establish relationships between Jira items and gerrit requests and to enhance traceability of changes we have a system in place that handles the cross-reference and creates the necessary links

Hi, Any files or headers included from an external project that need to be kept in sync with upstream can keep their style and formatting to allow updates in the future. This was the approach taken wh

Hi, Preference is to keep the most essential parts for building a basic Zephyr application on a specific board self-contained without external dependencies. Anas

No, bot sure why you want to use Yocto to build zephyr. What is the use case here? see https://www.zephyrproject.org/doc/dev/getting_started/installation_linux.html Anas

if you think doing this # make ZEPHYR_BASE=/path/to/source/tree BOARD=blah blah hundreds of times per day is more convenient than doing 'source zephyr-env.sh’ once a day per shell then we have a diffe

<snip> This sounds like the mBed approach. Whether you put the files in Zephyr main source tree or in some other Git repo you are still maintaining the files the same way, adding the file somewhere el

My view on the subject and I think we need this resolved ASAP: Keeping APIs stable is crucial, the question is, how do we get to stable APIs and how do we maintain progress while keeping those stable.