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 refe

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 right? As f

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 th

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 the

As for me, it's a very good aproach for drivers in general. At the very least, it reduces interrupt latency. Keeping in mind the fact that some drivers support callback functions, it may be reasonable

I see nothing bad in the proposal. I would refrain from copying PLY into the source tree for the following reasons: - Support. Updating the library, which is not the part of the project may be a heada

I am not quite sure I understand the problem. Kernel keeps the track of nanokernel timers and timeouts. If needed, each fiber can wait on a timer (one fiber per timer). Not sure, what is the need for

In other words, the idea of several fibers does not work for you, I see. Ok, now it gets clearer. You are asking for a nanokernel timer API that executes a registered callback when it expires. I do no

I would suggest starting with RFC, as it may be good to have it implemented in the Zephyr OS kernel: If we enable NANO_TIMER_CALLBACK config option, we start a fiber that sleeps on all the nanokernel

Boosting priority of the invoking task may not be what we want to achieve. In case of work_queue (correct me if I am wrong) we have an interrupt handler that offloads the long work to the fiber for in

Colleagues, while trying to use JTAG on Arduino Due board, I face the problem of the CPU clock stop while the CPU executes wfe or wfi instruction, which, if not makes JTAG debug impossible, but requir

Hello Mahavir, First question, am I right, you are using USB and dfu-utils for flashing Zephyr image? Am I right, you are using FTDI TTL-USB 3.3V connected to Arduino header, as wiki suggests? The nex

Hi Hezi, I think RFC needs to be extended with the description of the idea of controlling power state of each device (if I got you correctly). Without it the need of int (*get_state)(struct device *de

The way I know looks like this: grep INIT_PRIORITY outdir/.config CONFIG_KERNEL_INIT_PRIORITY_DEFAULT is usually the highest usable priority, CONFIG_KERNEL_INIT_PRIORITY_DEVICE is the priority that de

Any comment on this? Zephyr microkernel tasks allow user to set the task abort handler by invoking task_abort_handler_set(). The abort handler is executed by microkernel server fiber when it aborts th

I was also thinking on setting this to 0 and save some space. /Dmitriy

Colleagues, any comment on this? In it's current state the ring buffers appear as internal kernel objects used by event loger and ipm console. The proposal here is to make them kernel objects availabl

User can always add a semaphore. Or specify K_NO_WAIT as a timeout value. /Dmitriy

Just for the clarification. I never stated the idea of concurrency protocol. As I stated previously, the idea that is discussed here is to make ring buffers available for users the same way as it is d

Peter, this is a very good statement. The question is what we get from ring buffer that we can not get from fifo? Thanks! /Dmitriy