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

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? :-)

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

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

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()

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:

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.

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 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 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

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

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

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

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 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 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.

<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, 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

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