Sounds good, but we need to do it in away that keeps APIs compatible I guess. Anas

Thanks for documenting this but I don't think forcing people to use git-review is the right approach. It worked for us before in many other projects, why is this different and why can't I use vanilla

You are right, this will not break existing code. Nevertheless, we should track such API changes and document them in release notes. Anas >

Hi, You need to go into an application directory and build in the application directory, for example: $ cd samples/hello_world/nanokernel $ make BOARD=galileo Regards, Anas

Oleg, you can also install without sudo in your home directory or any other location. The script will only extract the contents of the file. We do have instructions on how to build the SDK yourself, I

Hi Oleg, I think this can be fixed with: diff --git a/zephyr-env.sh b/zephyr-env.sh index dcb0638..d17780a 100644 --- a/zephyr-env.sh +++ b/zephyr-env.sh @@ -1,5 +1,5 @@ -if [ "X$(basename -- "$0")" =

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

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 durin

Hi

You have a typo in your makefile? mico instead of micro? Anas From: Corey Williamson <corey.bailey.williamson(a)gmail.com<mailto:corey.bailey.williamson(a)gmail.com>> Date: To: "devel(a)lists.zephyrpr

Hugo, Looks good to me. You can also do that by specifying CROSS_COMPILE at the command line, for example: CROSS_COMPILE=arm-none-eabi- make BOARD=qemu_cortex_m3 will build using the installed ARM too

+1 This sounds more scalable, basically removes the need for defining a domain and using the levels to do the selection of how verbose messages are for each domain. Anas >

Hi Hugo, Yes, please do submit. Regards, Anas

Hi, The last month has been very busy. Zephyr was launched, we had 2 releases and a lot of changes to address the launch of the project. Sorry about the late notice. Up to the release of the project w

The main issue with this is the fact that stm32 extends all the way from M0 to M7, in total set of 11 series • STM32F0 Series • STM32F1 Series • STM32F2 Series • STM32F3 Series • STM32F4 Series • STM3

stm32 is very generic, we should consider placing the series at the top level under soc/ and have the supported SoCs below it. So for STM32 we will end up with stm32f0/ ... stm32f1/ ... stm32f2/ STM32

Hi, After resolving some issues with git and a slight delay, here is the first release candidate for Zephyr v1.1.0. Below you will find all the changes since v1.0.0. A summary of the changes since v1.

Yes please, Thanks. Anas

Hi, Zephyr v1.1.0 was tagged 2 days ago and merge window for the next release is no open. Release notes and other details will be posted on the website. Here is the log of changes since the rc1. Merge

Maybe I was misunderstood in my email about the structure. I was suggesting to move the SoCs directly under soc/ and ski[ the st_stm32 level. If we are to do things the same way across architecture we