On Thu, Jun 10, 2021 at 9:58 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> On 10/06/2021 16:24, Gedare Bloom wrote:
> >>> 5. Can anyone give some suggestions to solve the problem? thanks!
> > Classic and POSIX APIs can be mixed. It is a poorly documented benefit
> > of RTEMS. I
On 10/06/2021 16:24, Gedare Bloom wrote:
5. Can anyone give some suggestions to solve the problem? thanks!
Classic and POSIX APIs can be mixed. It is a poorly documented benefit
of RTEMS. I think in this case, you should be able to use
pthread_setschedparam(...) with passing policy == SCHED_RR t
On Thu, Jun 10, 2021 at 4:10 AM Kuan-Hsun Chen wrote:
>
> Hello,
>
> If that is the case, I think we should probably first agree on, what is the
> preferred behavior under the circumstance. I think picking heir tasks always
> in the same order is a proper design, but the preemption should not co
Hello,
If that is the case, I think we should probably first agree on, what is the
preferred behavior under the circumstance. I think picking heir tasks
always in the same order is a proper design, but the preemption should not
corrupt the "fair" time slicing in my opinion (so follow what you obse
Description of the issue：I created three tasks, Task A, Task B and Task C. All tasks are based on RTEMS_TIMESLICE | RTEMS_PREEMPT , Task A has a higher priority than other tasks, Task B has the same priority as Task C.Tasks B and C loop forever, Task A sleeps 1 TICK on an endless loop. When I test,
