|
Issue with k_poll
Can you submit that as a github bug? I don't know that I see it, but if you're sure that it can happen it's something we need to fix. Andy
Can you submit that as a github bug? I don't know that I see it, but if you're sure that it can happen it's something we need to fix. Andy
|
By
Andy Ross
· #8156
·
|
|
Issue with k_poll
That's right: k_poll() is level triggered, it's not a queue. The number of wakeups is not guaranteed to be equal to the number of events signalled. The idea is that you go to sleep waiting on any of a
That's right: k_poll() is level triggered, it's not a queue. The number of wakeups is not guaranteed to be equal to the number of events signalled. The idea is that you go to sleep waiting on any of a
|
By
Andy Ross
· #8153
·
|
|
stm32h7xx REQUIRES_FULL_LIBC
That sounded curious, so I checked. It looks like the STM32 RTC driver you found is an old-style y/m/d/h/m/s device with separate fields, and the driver is using mktime() to convert those to a linear
That sounded curious, so I checked. It looks like the STM32 RTC driver you found is an old-style y/m/d/h/m/s device with separate fields, and the driver is using mktime() to convert those to a linear
|
By
Andy Ross
· #7113
·
|
|
Thread Scheduling question
Your understanding is correct. If a higher priority thread is available to run, then a preemptible thread will yield to that thread at every scheduling point. I'm not quite sure what you are trying to
Your understanding is correct. If a higher priority thread is available to run, then a preemptible thread will yield to that thread at every scheduling point. I'm not quite sure what you are trying to
|
By
Andy Ross
· #6999
·
|
|
回复:[Zephyr-devel] Is this a bug? how to guarantee the "atomic semantics access of readyqueue" in "do_swap" function during context switch in SMP mode?
Actually, that PR merged a few hours ago, so code in master does not have this issue anymore. But yes: it was real and visible in CI testing as a spurious failure in qemu_x86_64. Andy
Actually, that PR merged a few hours ago, so code in master does not have this issue anymore. But yes: it was real and visible in CI testing as a spurious failure in qemu_x86_64. Andy
|
By
Andy Ross
· #6671
·
|
|
What is the difference "z_reschedule_irqlock" and "z_reschedule“? why two implementations?
Traditional locking in Zephyr is done with a single global "irq lock" (implemented on single processor systems with a straightforward interrupt mask). SMP allows for finer grained spinlocks, which hav
Traditional locking in Zephyr is done with a single global "irq lock" (implemented on single processor systems with a straightforward interrupt mask). SMP allows for finer grained spinlocks, which hav
|
By
Andy Ross
· #6664
·
|
|
Is this a bug? how to guarantee the "atomic semantics access of readyqueue" in "do_swap" function during context switch in SMP mode?
There is a fix for exactly this race this in https://github.com/zephyrproject-rtos/zephyr/pull/21903
There is a fix for exactly this race this in https://github.com/zephyrproject-rtos/zephyr/pull/21903
|
By
Andy Ross
· #6663
·
|
|
Delayed vs non-delayed Workqueues usage
Yes, you can. The work queue is the same. The k_delayed_work API is really just a convenience wrapper for "a work queue item plus a timeout for when to submit it". It's your (i.e. the code author's) s
Yes, you can. The work queue is the same. The k_delayed_work API is really just a convenience wrapper for "a work queue item plus a timeout for when to submit it". It's your (i.e. the code author's) s
|
By
Andy Ross
· #6495
·
|
|
PR #17628: sys_heap benchmarks?
This hasn't merged yet and was never the backend for malloc() or k_mem_pool, are you pulling it locally and writing code to its internal API? Have you tried a simple git bisect over your tree to look
This hasn't merged yet and was never the backend for malloc() or k_mem_pool, are you pulling it locally and writing code to its internal API? Have you tried a simple git bisect over your tree to look
|
By
Andy Ross
· #6361
·
|
|
Consequences of relying on 64 bit uptime
Generally it's much more often than 50 days. The hardware counter is the overflow that needs to be detected, not the millisecond count. With a 24 bit counter updating at 100+ MHz speds (c.f. the systi
Generally it's much more often than 50 days. The hardware counter is the overflow that needs to be detected, not the millisecond count. With a 24 bit counter updating at 100+ MHz speds (c.f. the systi
|
By
Andy Ross
· #6306
·
|
|
回复:[Zephyr-devel] Is The tick handler "z_clock_announce" in SMP mode dupulicate caculated?
Indeed, that looks like a bug in the driver when SMP and !TICKLESS are set. Can you file an issue on github? Andy
Indeed, that looks like a bug in the driver when SMP and !TICKLESS are set. Can you file an issue on github? Andy
|
By
Andy Ross
· #6204
·
|
|
Is The tick handler "z_clock_announce" in SMP mode dupulicate caculated?
This is the responsibility of the timer driver. The ticks announced needs to be globally correct. The existing drivers do this by locking a "last count" state variable and updating it, so they see the
This is the responsibility of the timer driver. The ticks announced needs to be globally correct. The existing drivers do this by locking a "last count" state variable and updating it, so they see the
|
By
Andy Ross
· #6193
·
|
|
Why the smp version of zephyr kernel "idle" task implent the "k_busy_wait(100)" delay?
FWIW: the reason for the busy wait is to reduce the number of calls to k_yield() which needs to enter the scheduler and obviously take a spinlock for synchronization. If you have one CPU spinning on t
FWIW: the reason for the busy wait is to reduce the number of calls to k_yield() which needs to enter the scheduler and obviously take a spinlock for synchronization. If you have one CPU spinning on t
|
By
Andy Ross
· #6148
·
|
|
Why is 'Sensor' a Peripheral in the API Reference?
Inertia, probably, and maybe a lack of somewhere better to put them. Properly "sensors" are an abstract subsystem and the related peripherals would be things like "accelerometers", "gyroscopes", "ther
Inertia, probably, and maybe a lack of somewhere better to put them. Properly "sensors" are an abstract subsystem and the related peripherals would be things like "accelerometers", "gyroscopes", "ther
|
By
Andy Ross
· #6132
·
|
|
RFC - C99 issue regarding unnamed union/structs
Thomas Törnblom wrote: And we'd never use this trick in C++ for that reason. :) I'd personally prefer to see this done via rework that doesn't introduce needless memory. I know I mocked it, but an ARC
Thomas Törnblom wrote: And we'd never use this trick in C++ for that reason. :) I'd personally prefer to see this done via rework that doesn't introduce needless memory. I know I mocked it, but an ARC
|
By
Andy Ross
· #5597
·
|
|
RFC - C99 issue regarding unnamed union/structs
In order: 1. Empty structs are really useful, for example the spot you're noticing that allows arch code to define its own set of private data, which might be zero-length. Obviously that could be work
In order: 1. Empty structs are really useful, for example the spot you're noticing that allows arch code to define its own set of private data, which might be zero-length. Obviously that could be work
|
By
Andy Ross
· #5593
·
|
|
RFC - C99 issue regarding unnamed union/structs
Yeah, I have a ton of sympathy for poor Flavio having to deal with all these conflicting rules and requirements, but not a lot for this particular rule that was clearly solved by the C standards commi
Yeah, I have a ton of sympathy for poor Flavio having to deal with all these conflicting rules and requirements, but not a lot for this particular rule that was clearly solved by the C standards commi
|
By
Andy Ross
· #5592
·
|
|
Timer using FRDM-K64F
Changing the k_timer API to work in some other unit than milliseconds is doable, though a little messy from a compatibility standpoint. The underlying unit of ticks is configurable, and except for the
Changing the k_timer API to work in some other unit than milliseconds is doable, though a little messy from a compatibility standpoint. The underlying unit of ticks is configurable, and except for the
|
By
Andy Ross
· #5582
·
|
|
Minimum required CMake version is now 3.13.1
Uh... those instructions still tell you to get cmake 3.8.2 :) The latest is currently at https://cmake.org/files/LatestRelease/cmake-3.13.2-Linux-x86_64.sh it seems. Andy
Uh... those instructions still tell you to get cmake 3.8.2 :) The latest is currently at https://cmake.org/files/LatestRelease/cmake-3.13.2-Linux-x86_64.sh it seems. Andy
|
By
Andy Ross
· #5570
·
|
|
[Zephyr-users] #BluetoothMesh ...about latest kernel OOPS & exception
#bluetoothmesh
Vikrant8051 <vikrant8051@...> wrote: I was pointed to this on IRC. The symptom you've got there sounds a lot like a scheduler mistake that got fixed yesterday, where ostensibly-pended threads co
Vikrant8051 <vikrant8051@...> wrote: I was pointed to this on IRC. The symptom you've got there sounds a lot like a scheduler mistake that got fixed yesterday, where ostensibly-pended threads co
|
By
Andy Ross
· #4663
·
|