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

It's the MACRO names the need fixed up IMO. Any functions that are added should be in the sys_* space sure. I didn't see any new C functions being added.

Again, do we want to take over _another_ namespace ? Maybe it should be sys_debug or sys_dbg or sys_dbg_log ? The sample implementation is adding all these in logging.h, which is a public API file:

If get binding fails the app will know the device failed or is otherwise unavailable. The return code from init() tells the kernel whether it's a fatal error and to call _NanoFatalErrorHandler()

I like this in general we need a common set of debug output macros that all drivers can use. Currently we have a *bunch* of different versions of the same thing in use throughout the driver tree. I

Dirk Brandewie <dirk.j.brandewie(a)intel.com> writes: [...] I already started this. Hoping to have something to show later today or tomorrow. Cheers, -- Vinicius

yeah better idea :-D when the quark_se gets more design wins things would get crowded. Now the question is who is signing up to do the refactoring? :-)

Hi Genaro, The idea is nice, at least it will prevent to declare debug macros everywhere. However, split the patch: - first provide a patch with the logging.h and it's related Kconfig file - and

Hi Genaro, <genaro.saucedo.tejada(a)intel.com> wrote: I welcome these changes but Im not so sure logging levels are actually necessary if one can define different domains, at least in case

From 9baee79d211bfb94aeed970c55f31cd3c4b2a8ad Mon Sep 17 00:00:00 2001 From: Genaro Saucedo Tejada <genaro.saucedo.tejada(a)intel.com> Date: Fri, 19 February 2016 23:10:28 +0000 Subject: [PATCH] Log

Hello, please review this proposal and provide feedback if possible. This email should be followed by a patch containing a prototype implementation for reference but not meant to be

Thanks for pointing out the facts and issues :-) I agree it cannot be used as a replacement for proper handling of resume() by devices.