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

I agree, Galileo is a special case and it's initialization code may/will share enough code with development part. I think, pinmux_galileo_priv.c will implement those common functions, am I

Hi Dmitriy, Dmitriy Korovkin <dmitriy.korovkin(a)windriver.com> writes: Good idea, this is going to be useful to see if what I have in mind is aligned with what other's have. This is a rough sketch

It would be good to have design changes for pinmux outlined in one text. Are we talking about code consolidation for Quark SE/D2000 or the global change for all pinmuxes? Are we touching the part

Hi all, Quoting Vinicius Costa Gomes (2016-02-24 18:34:16) Yes, I also like this proposal and I think we should move with it instead of with the proposal I did. I have just one comment regarding the