There is a basic disconnects between my original RFC and this one. In mine all drivers are required to provide an implementation of suspend/resume even if it is null. All the information for the

I think it might be useful to add a function to retrieve the timebase of the counter. ATM the developer just needs to *know* what is being counted. A function to set the timebase may be needed in

Having thought about it for 10 seconds it seems reasonable :-) To the greatest extent reasonable please avoid link time binding of SOC specifc code into the generic stm32 code. We don't want to the

Thanks for letting me know about this. I will modify and re-submit. If anyone notices anything missing, please let me know. ----- Daniel Leung

Hi, I have been working with Dan's stm32 patch to add support for stm32f4xx and just wanted to share couple of thoughts. https://gerrit.zephyrproject.org/r/#/c/209/ I would second the idea of

Hi,

Hi Luiz, I don't see anything we could do about that in this logging API. If there is something to be done, let's see it in another patch. Nanokernel could get it, it would run in low prio fiber and

Hi Fabian, <fabien.chereau(a)intel.com> wrote: Which is why I commented that having log level is not really necessary, perhaps this is even misleading since it should always be selected at build-time

Hi Daniel, It seems you've missed at least drivers/nble/uart.c that uses both IRQ_CONNECT and irq_enable. Otherwise the change looks fine to me. Johan

Acked-by: Dirk Brandewie <dirk.j.brandewie(a)intel.com>

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

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

Hi Fabien, Very good point. We also experienced it with networking drivers where debugging in the middle or RX/TX just kills timing. This would need to be addressed, but besides this log macros

Hello, FYI, in thunderdome we have also created a log system solving some of the problems you mention in your RFC. Here are my 2 cents following our experience: - In our implementation we now

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

Hi Anas, Can you please confirm if you want me to progress this RFC (since it's more convenient to have the VARIANT set, rather than specifying CROSS_COMPILE each time)? If so, what if any changes

Makes sense. I think we should also add another 'MCU family' level of hierarchy. We would have then: arch/ arm/ soc/ stm32/ stm32f1xx/ <soc specific> stm32f2xx/

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