Some cards are slow to get the connection link up after the
"rtifconfig rteth0 up" command, e.g. on an Atom-x5 with an Intel I210
(rt_igb driver) I detected approximately 3 seconds to get the link up.
On master, the "rtifconfig rteth0 up" is followed by TDMA configuration and
start. After the TDM
Il 22/04/22 18:55, Jan Kiszka ha scritto:
On 22.04.22 16:25, Mauro S. via Xenomai wrote:
Some cards are slow to get the connection link up after the
"rtifconfig rteth0 up" command, e.g. on an Atom-x5 with an Intel I210
(rt_igb driver) I detected approximately 3 seconds to get the link up.
On ma
On 22.04.22 16:25, Mauro S. via Xenomai wrote:
> Some cards are slow to get the connection link up after the
> "rtifconfig rteth0 up" command, e.g. on an Atom-x5 with an Intel I210
> (rt_igb driver) I detected approximately 3 seconds to get the link up.
>
> On master, the "rtifconfig rteth0 up" is
Hi,
What is the procedure to build and run the application with EVL? For
example a fifo thread.
#include
#include
#include
#include
#include
#include
int main(int argc, char *argv[])
{
struct sched_param param;
int ret, tfd;
param.sched_priority = 8;
ret = pthread_setschedparam(pthread_se
60 bytes
Desc: not available
URL:
<http://xenomai.org/pipermail/xenomai/attachments/20220422/daed78d0/attachment.bin>
Ashwik John via Xenomai writes:
> Hi,
>
> I have the same problem when running #evl test.
>
> basic-xbuf: OK
> clock-timer-periodic: OK
> clone-fork-exec: OK
> detach-self: OK
> duplicate-element: OK
> element-visibility: OK
> fault: OK
> fpu-preload: OK
> fpu-stress: OK
> heap-torture: OK
> ma
Hi,
I have the same problem when running #evl test.
basic-xbuf: OK
clock-timer-periodic: OK
clone-fork-exec: OK
detach-self: OK
duplicate-element: OK
element-visibility: OK
fault: OK
fpu-preload: OK
fpu-stress: OK
heap-torture: OK
mapfd: OK
monitor-deadlock: OK
monitor-event: OK
monitor-flags: OK
On Fri, Apr 22, 2022 at 5:02 AM Jae Hyun Park wrote:
> Then can I understand that tasks made with rt_task_create work similarly to
> multi-threading?
>
> And I wonder if there is any difference in real-time guarantee performance
> between pthread
>
> of posix skin and xnthread of realtime thread