|
Minimal Zephyr build
If you disable CONFIG_MULTITHREADING, the scheduler goes away. The kernel operates in coop-mode only with a single thread, which is basically "never preempt me, except by interrupts and when that happ
If you disable CONFIG_MULTITHREADING, the scheduler goes away. The kernel operates in coop-mode only with a single thread, which is basically "never preempt me, except by interrupts and when that happ
|
By
...
· #325
·
|
|
Kernel MS Precision
Yeah, but that is not backwards-compatible with the API. And that only works for timers, not the other APIs that take timeouts. Although, that might be irrelevant. Interesting idea. That could be a ne
Yeah, but that is not backwards-compatible with the API. And that only works for timers, not the other APIs that take timeouts. Although, that might be irrelevant. Interesting idea. That could be a ne
|
By
...
· #267
·
|
|
Kernel MS Precision
ns or us, you still needed 64-bit timeouts for either, which ended up being the major concern. 64-bit math can be costly: we've seen stack usage increase of 80 bytes on some architectures. Also, I don
ns or us, you still needed 64-bit timeouts for either, which ended up being the major concern. 64-bit math can be costly: we've seen stack usage increase of 80 bytes on some architectures. Also, I don
|
By
...
· #256
·
|
|
Kernel MS Precision
Hi Mike, When prototyping the new API, I started with timeouts as an int64_t in nanoseconds, to allow the same precision as struct timespec, but without the akwardness of having to create an instance
Hi Mike, When prototyping the new API, I started with timeouts as an int64_t in nanoseconds, to allow the same precision as struct timespec, but without the akwardness of having to create an instance
|
By
...
· #253
·
|
|
[RFC] MPU support for debugging
Yet another example that shows the importance of laying out early what the different MPU regions will be used for, as stated in the top comment in my original reply to the RFC.
Yet another example that shows the importance of laying out early what the different MPU regions will be used for, as stated in the top comment in my original reply to the RFC.
|
By
...
· #214
·
|
|
[RFC] MPU support for debugging
Agreed, but I think this can be made optional if the application is trusted and user-space is used more as a debugging aid. Although, that's Yet Another Kconfig configuration to verify.
Agreed, but I think this can be made optional if the application is trusted and user-space is used more as a debugging aid. Although, that's Yet Another Kconfig configuration to verify.
|
By
...
· #210
·
|
|
how to user KTimer?
Hi Jun, <duration> is the time before the first timer expiry, and <period> is the period at which it will expiry subsenquently. If you specify a <period> of 0, the timer only fire once. e.g. If the cu
Hi Jun, <duration> is the time before the first timer expiry, and <period> is the period at which it will expiry subsenquently. If you specify a <period> of 0, the timer only fire once. e.g. If the cu
|
By
...
· #209
·
|
|
[RFC] MPU support for debugging
Some random thoughts on this, do with them as you wish. :) To get more detailed feedback, I think you need to document how exactly you intend on using the MPU. Like: - region 0 to protect the kernel t
Some random thoughts on this, do with them as you wish. :) To get more detailed feedback, I think you need to document how exactly you intend on using the MPU. Like: - region 0 to protect the kernel t
|
By
...
· #199
·
|
|
Fibers Become Unrunnable in Nanokernel
Sorry, I did not have much time to look at this. But yes, this looks indeed like a problem even in the pre-unified kernel (per-1.6).
Sorry, I did not have much time to look at this. But yes, this looks indeed like a problem even in the pre-unified kernel (per-1.6).
|
By
...
· #161
·
|
|
how to use the debug subsys and what it is used for?
The GDB server was used in WR Rocket, a product based on an early zephyr codebase. It was used for both loading images and debugging when a hardware solution was not available, such as on the Intel Ga
The GDB server was used in WR Rocket, a product based on an early zephyr codebase. It was used for both loading images and debugging when a hardware solution was not available, such as on the Intel Ga
|
By
...
· #136
·
|
|
Fibers Become Unrunnable in Nanokernel
Hi Michael, This does not really solve your problem, but Zephyr 1.6 contains a legacy layer that provides all the APIs of the old kernels on top of the new kernel. It's not a NOP to move to 1.6, since
Hi Michael, This does not really solve your problem, but Zephyr 1.6 contains a legacy layer that provides all the APIs of the old kernels on top of the new kernel. It's not a NOP to move to 1.6, since
|
By
...
· #134
·
|
|
did the zephyr kernel support the nested interrupt on all the supported arch?
Hi, Should be supported on architectures where the hardware has support for it. It is a feature of the kernel. ARM, ARC, x86 do support it. Not entirely sure about Nios2 and RiscV. Regards, Ben
Hi, Should be supported on architectures where the hardware has support for it. It is a feature of the kernel. ARM, ARC, x86 do support it. Not entirely sure about Nios2 and RiscV. Regards, Ben
|
By
...
· #115
·
|
|
did the scheduler need report the misuse of k_sched_lock before k_sleep?
Hi, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I'm not sure what this means... This code is valid. The scheduler lock is per-thread. If the thread goes to sleep, it relinquishes the CPU, but when it co
Hi, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I'm not sure what this means... This code is valid. The scheduler lock is per-thread. If the thread goes to sleep, it relinquishes the CPU, but when it co
|
By
...
· #105
·
|
|
CONFIG_SEMAPHORE_GROUPS
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ In the latest code base, that's not a valid state: only bits 0-5 are used, giving a max value of 0x3f. ./kernel/include/kernel_structs.h:#define _THREAD_DUMMY (1 << 0
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ In the latest code base, that's not a valid state: only bits 0-5 are used, giving a max value of 0x3f. ./kernel/include/kernel_structs.h:#define _THREAD_DUMMY (1 << 0
|
By
...
· #86
·
|
|
CONFIG_SEMAPHORE_GROUPS
OK, so it seems that, since you can disable the CONFIG_SEMAPHORE_GROUPS feature, you are _not_ using said feature. In theory, this if statement should always be hit in handle_sem_group(): if (!(thread
OK, so it seems that, since you can disable the CONFIG_SEMAPHORE_GROUPS feature, you are _not_ using said feature. In theory, this if statement should always be hit in handle_sem_group(): if (!(thread
|
By
...
· #49
·
|
|
Design Philosophy 'Minimal runtime error checking'...
Sure, a panic() API is a good thing to have as well. Like you said, this is for a completely different use-case then the current __ASSERT() we have.
Sure, a panic() API is a good thing to have as well. Like you said, this is for a completely different use-case then the current __ASSERT() we have.
|
By
...
· #43
·
|
|
Design Philosophy 'Minimal runtime error checking'...
Agreed, and that is why the kernel takes the approach below: __ASSERT()s are use to catch user errors early during development, and are meant to be turned off before deployment.
Agreed, and that is why the kernel takes the approach below: __ASSERT()s are use to catch user errors early during development, and are meant to be turned off before deployment.
|
By
...
· #35
·
|
|
Design Philosophy 'Minimal runtime error checking'...
Hi Marcus, The approache taken by the core kernel is pretty simple: - if an error happens because it's the user's fault, __ASSERT(): the kernel doesn't care, you did something stupid :) - if the error
Hi Marcus, The approache taken by the core kernel is pretty simple: - if an error happens because it's the user's fault, __ASSERT(): the kernel doesn't care, you did something stupid :) - if the error
|
By
...
· #29
·
|
|
How to overcome timer delay
[..snip..] [..snip..] Well, that was an in-depth explanation of what is happening internally, but I focused too much on what your code was doing that I kinda overlooked a better way of doing what you
[..snip..] [..snip..] Well, that was an in-depth explanation of what is happening internally, but I focused too much on what your code was doing that I kinda overlooked a better way of doing what you
|
By
...
· #4586
·
|
|
uint32_t typedef differences causes issues
That's basically it. IMHO, I think that this reasoning was bogus anyway, and only meant we had (probably worse) re-implementation of some libc routines, with different names, or not. :-/ +1.
That's basically it. IMHO, I think that this reasoning was bogus anyway, and only meant we had (probably worse) re-implementation of some libc routines, with different names, or not. :-/ +1.
|
By
...
· #4572
·
|