This could be implemented without a "global" category but providing an menu option to rise log level of every category lower than user input. Currently I have a "default" log level to deal with

I mean applications could rely on log API to report the most important messages even in a complete application (that's what I meant by production), it wouldn't make sense to expect a terminal in that

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 •

Maybe it did not come clear in my reply, but what I proposed did not have a global logging level, or rather, the global level is always "OFF". Each subsystem that you want to log has to enable it,

+1 -- Benjamin Walsh, SMTS Wind River Rocket www.windriver.com Zephyr kernel maintainer www.zephyrproject.org

<daniel.kalowsky(a)intel.com> wrote: Single 'x' as in 'everything that comes after the i-1 character' :) As for the models, I'm not aware of any non STF32F10x MCUs, however all of these are

Sure. I will be glad to work with you on making it better. Thanks.

device called In this RFC I tried to keep the main ideas and feedbacks from the original RFCs but made some modifications as I encountered issues during implementation. These should not impact the

Hey Pawel,

Hi Ramesh,

Implementing this. +1 I'm supporting this now and will implement this on some reference module as example for the following patch set.

I understand, for this first effort the goal is to unify calls under a single API that can be later provided by different implementations. I don't foresee conflicts between initial proposal and

Although a namespace is needed (as noted bellow) debug is not the only goal of this infrastructure INFO and ERROR level might be used for big production environments in the future. I reused some

The peripherals utilizing UART were required to register their own ISR rountines. This means that all those peripherals drivers need to know which IRQ line is attached to a UART controller, and

Yes, after the timeout expires, delta_ticks_from_prev is -1. I agree, we can check it and not use any flag. This can be implemented. In this case nano_timer_test() places the nano_timeout part of

I don't think you need this expired flag: delta_ticks_from_prev is either 0 or -1 when the timeout expires (-1 I think). I would prefer if we had a nano_timer object that is a wrapper around

This is to give an opportunity for the PM service app to do additional operations saving power around the tickless idle i.e. do more than just rely on the power savings achieved by HLT that is done by

With all due respect what are you talking about? Tickless idle and PM are orthogonal! Tickless idle means we don't come out of idle to just serve periodic timer interrupts, we come out of idle for the