|
Pinmux driver model: per board vs. unified
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
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
|
By
Dmitriy Korovkin
· #2335
·
|
|
Pinmux driver model: per board vs. unified
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
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
|
By
Dmitriy Korovkin
· #2337
·
|
|
[RFC] Nanokernel timers rework proposal
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
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
|
By
Dmitriy Korovkin
· #2338
·
|
|
[RFC] Nanokernel timers rework proposal
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
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
|
By
Dmitriy Korovkin
· #2426
·
|
|
[RFC] Sensor API
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
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
|
By
Dmitriy Korovkin
· #2484
·
|
|
RFC: extend sanitycheck testcase filtering expressiveness
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 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
|
By
Dmitriy Korovkin
· #2626
·
|
|
RFC: Timer/Timeout API
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
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
|
By
Dmitriy Korovkin
· #2692
·
|
|
RFC: Timer/Timeout API
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
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
|
By
Dmitriy Korovkin
· #2710
·
|
|
RFC: Timer/Timeout API
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
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
|
By
Dmitriy Korovkin
· #2716
·
|
|
RFC: Unified kernel
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
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
|
By
Dmitriy Korovkin
· #3051
·
|
|
JTAG debugging on Arduino Due board
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
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
|
By
Dmitriy Korovkin
· #3115
·
|
|
[users] Re: Re: Re: zephyr on Arduino 101
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
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
|
By
Dmitriy Korovkin
· #3180
·
|
|
[RFC] Power Management Infrastructure
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
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
|
By
Dmitriy Korovkin
· #3231
·
|
|
How to directly dertermine the initialization sequence of all devices
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
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
|
By
Dmitriy Korovkin
· #3435
·
|
|
RFC: Thread abort handler in unified kernel
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
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
|
By
Dmitriy Korovkin
· #3777
·
|
|
Timer utility function to use single timer
I was also thinking on setting this to 0 and save some space. /Dmitriy
I was also thinking on setting this to 0 and save some space. /Dmitriy
|
By
Dmitriy Korovkin
· #3784
·
|
|
[RFC] Ring buffers
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
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
|
By
Dmitriy Korovkin
· #3787
·
|
|
[RFC] Ring buffers
User can always add a semaphore. Or specify K_NO_WAIT as a timeout value. /Dmitriy
User can always add a semaphore. Or specify K_NO_WAIT as a timeout value. /Dmitriy
|
By
Dmitriy Korovkin
· #3789
·
|
|
[RFC] Ring buffers
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
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
|
By
Dmitriy Korovkin
· #3792
·
|
|
[RFC] Ring buffers
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
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
|
By
Dmitriy Korovkin
· #3793
·
|