We have a similar issue on Linux 4.4.87 and 4.4.113, with xenomai 3.0.5:
https://github.com/RobertCNelson/ti-linux-kernel-dev/issues/16 (comes with
code to reproduce issue).
Best,
Giulio
From: Xenomai on behalf of Greg Gallagher
Sent: 26 February 20
the same time as long as it's not the same pin. I
will look into this this week, I have RPI stuff on the go as well so
patience is appreciated.
-Greg
On Mon, Feb 26, 2018 at 10:54 AM, Giulio Moro wrote:
> We have a similar issue on Linux 4.4.87 and 4.4.113, with xenomai 3.0.5:
git checkout stable-3.0.x
scripts/bootstrap
mkdir -p ../xenomai-3-build && cd ../xenomai-3-build
../xenomai-3/configure --with-core=cobalt --enable-pshared
--host=arm-linux-gnueabihf --build=arm CFLAGS="-march=armv7-a -mfpu=vfp3"
--enable-dlopen-libs
make V=1
will eventually result in
arm-linux
On Xenomai 2.6, native API, I used to run
rt_task_shadow(&thisTask, threadName, threadPriority, T_JOINABLE | T_FPU);
Now I am using Cobalt on Xenomai 3 and I am looking for a drop-in replacement.
Going through the source of alchemy.c, copperplate/internal.c and
cobalt/thread.c, it seems that
No, I have ported all the rest of the application to Cobalt (because of the
faster thread wakeup time), this is the last bit that is missing.
Thanks,
Giulio
From: Greg Gallagher
Sent: 04 April 2018 20:44
To: Giulio Moro
Cc: xenomai@xenomai.org
Subject: Re
/usr/xenomai/bin/xeno-config --skin cobalt --ldflags --no-mode-check
returns
-Wl,--no-as-needed /usr/xenomai/lib/xenomai/bootstrap.o -Wl,--wrap=main
-Wl,--dynamic-list=/usr/xenomai/lib/dynlist.ld -L/usr/xenomai/lib -lcobalt
-lmodechk -lpthread -lrt
which removes the modechk wrappers, but lea
What is the difference between the Posix and Cobalt skin, as far as xeno-config
is concerned??
Difference between
xeno-config --skin posix --cflags
xeno-config --skin cobalt --cflags
is that the former declares -D__COBALT_WRAP__ (which in turn adds fwd
declarations for clock_nanosleep() and
so would it not be up to the external libs to specify in their docs that they
should be linked with -lmodechk?
From: Philippe Gerum
Sent: 05 April 2018 07:43
To: Giulio Moro; xenomai@xenomai.org
Subject: Re: [Xenomai] xeno-config --no-mode-check still has
ks,
Giulio
From: Philippe Gerum
Sent: 05 April 2018 07:36
To: Giulio Moro; xenomai@xenomai.org
Subject: Re: [Xenomai] doc for xeno-config skins
On 04/04/2018 10:15 PM, Giulio Moro wrote:
> What is the difference between the Posix and Cobalt skin, as far as
> xeno-config is concerned?
This is about best practices.
The GNU Make manual says
(https://www.gnu.org/software/make/manual/html_node/Implicit-Variables.html)
> LDFLAGS
> Extra flags to give to compilers when they are supposed to invoke the linker,
> ‘ld’, such as -L. Libraries (-lfoo) should be added to the LDLIBS variab
or
cat /proc/xenomai/stat
and see if the count in the MSW column increases for that task
From: Xenomai on behalf of Greg Gallagher
Sent: 06 April 2018 18:41
To: C Smith
Cc: Xenomai@xenomai.org
Subject: Re: [Xenomai] Context switch to secondary mode in
Ports UART1, UART2, UART4, UART5 are available on the BeagleBone's P8 and P9,
and UART0 is on the debugging header. UART3 is also available, but only the TX
line I think.
These can be accessed through the linux driver at `/dev/ttyS0`...`/dev/ttyS5`
Additionally, you have uart0 from the PRUSS.
S
> 1) is it true the same POSIX-code will generate Xenomai rt-task with options
> below
Yes. Make sure you set the scheduler policy to SCHED_FIFO (or SCHED_RR) (e.g.:
with pthread_attr_setschedpolicy())
> Does it mean: all of this (man -s2) POSIX-functions safely use from real-time
> points of
> So, from my point of view it confirm my suspicious that the wrapper
> mechanism is fragile. I really didn't understand why Xenomai core team
> changed the native API for the POSIX. Although I saw the Jan Kiska
> conference video explaining it, tell me primitive or dump, but I prefer to
> have
>
Hello there,
I am new to the list, I am working on this project
https://github.com/BelaPlatform/Bela/ for real-time audio
on the BeagleBone Black using Xenomai.
I am trying to use Xenomai's POSIX skin to create and access
shared memory objects, but I am getting mode switches to
secondary mode
>- xenomai 2.6.3 is old. 2.6.5 is the last stable version of 2.6.x branch.
>Also, 2.6.x branch AFAIK is just in maintenance mode, so I would recommend you
>if you are beginning a new project use Xenomai 3.x
Thanks for the advice, the project started three years ago so it was 2.x from
the begin
Thanks Philippe,
>> //causes mode switches:
>> rt_printf("%f\n", arr[n]);
>>
>
>This is due to minor faults, when the memory is there but not referenced
>to by a valid PTE in the page table for the current process yet.
>
>Before the 3.10 series, the pipeline used to switch to secondary mode
>eage
>You could have a Linux process writing in your file data coming from
>your RT process through IPC RT communication.
I have a question on this:
what IPC method would you recommend?
If I understand correctly, mode switches carry an overhead. If this is true, I
guess is it reasonable to try to kee
Hello,
freshly installed Cobalt 3.0.3 on a BeagleBone Black (ARM Cortex-A8) with
kernel 4.4.35 (rcn:
https://github.com/RobertCNelson/ti-linux-kernel-dev/tree/ti-linux-xenomai-4.4.y
).
When runnig xeno-test I get the below error.
Note that latency test works ok (though the values are a bit high
Thanks
> - the figures reported by latency
Latency results with the previously described system were
RTS| 7.872| 11.098| 54.957| 0| 0| 00:00:18/00:00:18
> - whether you enabled debug (--enable-debug) when building the user libs
> and programs?
> You may also want to make sure that debug options
if you have compiled with
CONFIG_XENO_OPT_AUTOTUNE=mthen when you run autotune you get
./autotune: cannot open autotune device: No such file or directory
The error message is not very informative and should suggests `modprobe
xeno_autotune`.
Is there an issue tracker somewhere?
What is the bes
If it can help, a 4.4.y kernel for BeagleBone by RobertCNelson with Xenomai
3.0.3 is here
https://github.com/RobertCNelson/ti-linux-kernel-dev/tree/ti-linux-xenomai-4.4.y
From: Øyvind Netland
To: xenomai@xenomai.org
Sent: Friday, 6 January 2017, 20:01
Subject: [Xenomai] Xenomai 3
What's the deal with using the posix skin to wrap C++ mutex, locks and threads?
I am on ARMv7 (Beaglebone Black), with gcc 4.9, xeno-config on this system
returns the following:$ /usr/xenomai/bin/xeno-config --skin=posix --ldflags
--cflags-Wl,@/usr/xenomai/lib/posix.wrappers -L/usr/xenomai/lib -l
here been any effort in writing a
Xenomai-wrappable (or Xenomai-friendly) C++ standard library?
Thanks,Giulio
From: Giulio Moro
To: Xenomai
Sent: Sunday, 19 February 2017, 1:38
Subject: pthread_rt and C++ on Xenomai 2.6
What's the deal with using the posix skin to wrap C++ mu
In Alchemy RT_TASK_INFO has a member struct threadobj_stat which is
undocumented
(https://xenomai.org//documentation/xenomai-3/html/xeno3prm/structRT__TASK__INFO.html).
Looking at the source of copperplate/threadobj.h
(https://xenomai.org//documentation/xenomai-3/html/xeno3prm/threadobj_8h_sourc
Hi,
I have a 4.4.61 kernel with Xenomai 3.0.4 on am335x (BeagleBone Black) compiled
with
CONFIG_BROKEN_ON_SMP=y
CONFIG_GENERIC_SMP_IDLE_THREAD=y
CONFIG_HAVE_SMP=y
# CONFIG_SMP is not set
(see XENO flags at the bottom of the email)
When I compile the user-space support with
/root/xenomai/con
> xeno-config --info would help.
root@bela:~# /usr/xenomai/bin/xeno-config --info
Xenomai version: Xenomai/cobalt v3.0.4 -- #f68a020 (2017-04-02 16:46:34 +0200)
Linux bela 4.4.62-ti-xenomai-r103 #1 Sat May 13 03:08:17 BST 2017 armv7l
GNU/Linux
Kernel parameters: console=ttyS0,115200n8 root=/dev/m
Thanks for your response Philippe,
> --enable-smp in user-space entails no interaction with the kernel at
> all, this is only a matter of issuing memory barriers in the code flow
> to deal with lockless atomic sections.
still, is it expected that when not using --enable-smp my code fails?
> xeno
The recent commit
9a865549170f82561389eaa6d4dbda6f8a46d2e1
"cobalt/arm: fixups for kernel 4.8+"
seems to have broken 4.4 kernel, see build log below:
arch/arm/xenomai/machine.c: In function ‘mach_arm_prefault’:
arch/arm/xenomai/machine.c:38:20: warning: passing argument 1 of
‘handle_mm_fault
Hi,
Xenomai 3.0.5 here on kernel 4.4.68-ti-xenomai-r106 on a AM3358 (BeagleBone
Black).
If I create a task with `rt_task_create()`, I can then successfully bind to it
using its descriptive name from within the same process that started it, e.g.:
rt_task_create(&task, task_name, 0, 40, T_JOINABL
Sent: 16 May 2017 10:56
To: Giulio Moro; xenomai@xenomai.org
Subject: Re: [Xenomai] rt_task_bind returns -EINVAL when not using --enable-smp
On 05/15/2017 12:04 PM, Giulio Moro wrote:
> Hi,
> I have a 4.4.61 kernel with Xenomai 3.0.4 on am335x (BeagleBone Black)
> comp
api-tags.html ?
Thanks,
Giulio
________
From: Philippe Gerum
Sent: 10 June 2017 21:02
To: Giulio Moro; xenomai@xenomai.org
Subject: Re: [Xenomai] rt_taks_bind() returns -EAGAIN for existing task
On 06/10/2017 09:34 PM, Giulio Moro wrote:
> Hi,
> Xenomai 3.0
Giulio Moro wrote:
>> A side note: it seems that calling `rt_task_bind()` causes a switch to
>> secondary mode, as I see the MSW counter increasing for every call to it.
>>
Philippe Gerum wrote:
>This should not be the case in x3; you may want to run the app over gdb,
&
As I understand it, bin/latency is based on the posix API and demo/altency is
based on the Alchemy API. On the BeagleBone black, the former always returns
results which are about 10us better than the latter.
Is there any other difference between the two tests? Why do I get different
performance
mendments?
From: Philippe Gerum
Sent: 11 June 2017 16:47
To: Giulio Moro; xenomai@xenomai.org
Subject: Re: [Xenomai] rt_taks_bind() returns -EAGAIN for existing task
On 06/11/2017 04:11 AM, Giulio Moro wrote:
> Great info, it would be good to integrate these in the main docs somewhere. I
> h
Not sure if this helps, but I have Xenomai 3.0.5 running on the BeagleBone
Black.
We build the image (kernel + rootfs) using this script
github.com/BelaPlatform/bela-image-builder/, in particular the defconfig file
for the kernel is
https://github.com/BelaPlatform/bela-image-builder/blob/maste
Hi,
I ported this GPIO driver from Xenomai 2.6 to Xenomai 3 and I run it on the
Beaglebone Black: https://github.com/giuliomoro/gpio-irq-rtdm/
TheRTDM irq_handler (in gpio_irq_rtdm.c) toggles a pin "kernel timingpin" as
soon as the IRQ is received.
The test program registers a pin to monitor an
> So it seems that in my case it takes a long time for the irq_handler() to be
> called after the test pin is toggled.
> Am I doing something wrong in the kernel module ?
by the way, I get this in dmesg:
[ 76.152289] irq 98, desc: dc18df00, depth: 1, count: 0, unhandled: 0
[ 76.152314] ->han
the `dev` member of `struct gpio_chip` was replaced by `parent` as of
commit 58383c78425e4ee1c077253cf297b641c861c02e
Author: Linus Walleij
Date: Wed Nov 4 09:56:26 2015 +0100
gpio: change member .dev to .parent
The name .dev in a struct is normally reserved for a struct device
> This is unlikely a Xenomai issue strictly speaking. You may want to
> check the I-pipe code instead, there is certainly a problem with the
> interrupt delivery code in the low level handler.
I have no idea where to start from in checking the i-pipe code.
What I can say is that I went back to 4.
Thanks Len,
> Turns out that in that case smartidle was enabled and the gpio bank
> would go into sleep mode and it took 4ms to wake up before the irq would
> show up. Turning off the smartidle on the gpio bank so that it never
> could go to sleep solved the problem. Maybe this TI chip has a si
As you ask "Can't we work without device driver ?": here is a driver-less
solution which may work on your platform (if it supports memmapping the GPIO
banks) and may suit your needs.
I have some working user-space code to read and toggle GPIOs on a BeagleBone
Black, which simply uses memory map
> Can you explain please why this is not writing to a file:
Is this related to "Re: Toggling GPIO RT Xenomai on Dragonboard 41c" or should
it go under a separate heading?
> (without the rt_task_sleep(1000) and the while it works fine).
Many things could be wrong with this.
If `time_to_run` is
> Is there any other sleep function for real time ?
That is the correct sleep function for real time, and the sleep time is
expressed in nanoseconds, so you are trying to sleep for 1 microsecond, which
is well beyond Xenomai's capabilities on many (all?) platforms. Minimum latency
values are ar
Your task is sent a SIGXCPU/SIGDEBUG signal when it does not sleep for more
than a given amount of time (I think default is 4 seconds).
Make sure your task sleeps (e.g.: rt_task_suspend(), rt_task_sleep() or wait on
an interrupt) as soon as it is done processing.
Alternatively, you may have T_WA
> It seems that gcc doesn't include standard include paths
I would suggest you add `--verbose` to your CFLAGS so you will see explicitly
what is in the search path for that one invocation that fails.
Giulio
PS: note that the weird line wrapping of your message (possibly due to your
email clien
_____
From: Simone Zucchi
Sent: 26 July 2017 15:14
To: Giulio Moro; xenomai@xenomai.org
Subject: Re: Xenomai 2->3: gcc/makefile wrong include paths
Hello Giulio,
I've obtained the (expected) result: no standard include path is included.
Before posting that I'd like to ha
Hello,
I am porting a Xenomai 3 application from Alchemy to the Posix API*. Under
Alchemy, I was using rt_task_suspend(NULL) to suspend a task and
rt_task_resume(&task) to resume the task from a separate thread. What is the
best / recommended way of porting this to the Posix API?
Are there any d
The Xenomai documentation for pthread_cond_variable says
"Note that only pthread_cond_init() may be used to initialize a condition
variable, using the static initializer PTHREAD_COND_INITIALIZER is not
supported."
However, demo/posix/cyclictest/cyclictest.c has the following line:
static pt
I am using condition variables with the Posix skin on Xenomai 3.0.5
I find that if the thread calling pthread_cond_signal() has not acquired the
lock associated with the condition variable, the waiting thread is not resumed.
Is this expected behaviour? As
According to the Posix specifications (re
> libcobalt enforces the requirement to hold the lock so that optimizing
> the wake up process is possible - under the assumption that the caller
> owns the lock. There is no hack around this.
Then I would suggest that pthread_cond_signal() should return an error code if
the caller does not own t
On Xenomai 3.0.5, if I compile a program with the posix skin and I try to run
it with `--session=mySessionName`, it errors as it cannot find the `--session`
option. This is strange, because main() is definitely getting wrapped: if I run
`--help`, it does show some Xenomai command-line options:
-
> The POSIX API does not depend on copperplate, so
> you don't have support for multi-process sessions when linking against
> libcobalt exclusively.
Ok. All we need this for is to prevent multiple instances of our program to be
started at the same time. What would you suggest as the best way to
At Bela (bela.io) we use Xenomai on the BeagleBone Black for audio. Currently
our resources are pretty scarce, but hopefully from March things should get
better For instance, now that RobertCNelson has discontinued support for
Xenomai on the BeagleBone, we may be able to help with that (incident
armv7 (BeagleBone Black), Xenomai 3.0.5.
When linking a shared library with something like
gcc `/usr/xenomai/bin/xeno-config --skin=alchemy --ldflags` -rdynamic -shared
-o libmylib.so
I get
/usr/bin/ld: /usr/xenomai/lib/xenomai/bootstrap.o: relocation
R_ARM_THM_MOVW_ABS_NC against `a loca
Again, armv7 BeagleBone Black, Xenomai 3.0.5
My main executable uses the posix API, hence ldd tells me :
libcobalt.so.2 => /usr/xenomai/lib/libcobalt.so.2 (0xb6ed3000)
libmodechk.so.0 => /usr/xenomai/lib/libmodechk.so.0 (0xb6f39000)
I am trying to dlopen() a library which uses the
> From: Philippe Gerum
> As mentioned in the documentation, --enable-dlopen-libs is needed when
> configuring
Brilliant, thanks. The docs mentions
> Enabling dynamic loading introduces some overhead in TLS accesses when
> enabled (see --enable-tls), which might be noticeable depending on the
Passing the options returned by `xeno-config --skin=posix --ldflags` to the
linker will automatically "wrap" the calls to most `posix_` functions (full
list at /usr/xenomai/lib/posix.wrappers). When a function (e.g.:
pthread_create() ) is "wrapped", then all the calls to `pthread_create()` will
In message <20180109122202.1f89c...@mmd1pvb1c.ad001.siemens.net> you wrote:
>
> We have now agreed on a time and place for this meeting, and i want to
> announce it and invite the whole community to it.
>
> Where: somewhere in Brussels (details will follow)
>and remotely, TelCo link will be
Hi Fred,
See here for an example of a rtdm driver that receives interrupts from the PRU:
https://github.com/BelaPlatform/rtdm_pruss_irq/blob/master/rtdm_pruss_irq.c
with ioctl you can set up the interrupts and route them through the interrupt
channels and export them to the ARM interrupt contr
You can download a working Debian image with Xenomai that runs on BB here
https://github.com/BelaPlatform/bela-image-builder/releases
This contains Linux 4.14.108-ti-xenomai-r135 with Xenomai 3.0.10
The kernel is built from this branch
https://github.com/RobertCNelson/ti-linux-kernel-dev/tree/t
I should have mentioned that you can also build an Isar image for the BBB with
Xenomai from here https://gitlab.denx.de/Xenomai/xenomai-images
Giulio Moro wrote:
You can download a working Debian image with Xenomai that runs on BB here
https://github.com/BelaPlatform/bela-image-builder
The easiest way is to boot without sd card, login, and then
sudo su
dd if=/dev/zero of=/dev/mmcblk1 bs=1024k count=100
This should make the eMMC unbootable and so boot from SD. Otherwise you can
give power while holding down the USER button every time.
From: Xeno
Hi there,
I tried building this with:
kas-container build
kas.yml:board-beagle-bone-black.yml:opt-linux-latest-5.4.yml
(not sure if that's the right syntax to get 5.4 ... I had to second guess it)
but it errors. I think the relevant error is:
AR kernel/printk/built-in.a
CC kern
From: Giulio Moro
Signed-off-by: Giulio Moro
---
recipes-kernel/linux/linux-xenomai_latest.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/recipes-kernel/linux/linux-xenomai_latest.bb
b/recipes-kernel/linux/linux-xenomai_latest.bb
index bbec6b0..e6834fd 100644
--- a
I don't have any of those variables set in my env and that I am not
running behind a proxy, but the failure seems to be unrelated (I am no docker
expert), so maybe the README needs update on this one, too?
Best,
Giulio
Jan Kiszka wrote on 09/02/2021 11:42:
On 09.02.21 12:35, Giulio Moro wro
I have clang 3.9.1 (on Debian Stretch) on armv7.
the below minimal program clz-test.c:
```
#include
#include
int main()
{
return __clz(0);
}
```
will fail to build when compiled with
`clang -I/usr/xenomai/include/cobalt -I/usr/xenomai/include clz-test.c` , as
follows:
```
In file inclu
right, digging deeper into the issue, ARM says that if the __ARM_ACLE macro is
defined by the compiler, then it's safer to include `arm_acle.h`, which will
define __clz() as a function, so a better approach could be perhaps:
#ifdef __ARM_ACLE
#include
#else
#define __clz(__v)\
//
> Why not solving the namespace clash the simplest way by renaming the
> offending stuff in boilerplate/compiler.h? __clz and friends are
> definitely not part of the public interface, so you only have to care
> about in-tree users. __clz could be renamed as count_leading_zeroes()
> without affecti
>From de7bf8033570f15b68b00b6386097ceb8a402d6b Mon Sep 17 00:00:00 2001
From: Giulio Moro
Date: Tue, 20 Nov 2018 22:32:00 +
Subject: [PATCH] Rename __clz to xenomai_count_leading_zeros to avoid
namespace conflicts (e.g.: with Clang's arm_acle.h)
Signed-off-by: Giulio Moro
---
>From 398a77d3d172c10cda9826a7cc2a15266ff4c6a9 Mon Sep 17 00:00:00 2001
From: Giulio Moro
Date: Sat, 10 Nov 2018 20:23:10 +
Subject: [PATCH] Rename __clz to xenomai_count_leading_zeros.
This is to avoid namespace conflicts (e.g.: with Clang's arm_acle.h)
Signed-off-by: Giu
The docs for sched_setscheduler_ex() [1] and pthread_setscheparam_ex()[2]
claim that among the valid values for policy there is "SCHED_NORMAL"
however, SCHED_NORMAL is not provided by any of the Xenomai headers, so you get
a compile-time error.
[1]
https://xenomai.org/documentation/xenomai-3
Also, it may be worth pointing out in the docs that SCHED_SPORADIC, SCHED_TP,
SCHED_QUOTA need kernel support ( the docs already mention something about
kernel support for SCHED_WEAK).
Giulio
From: Xenomai on behalf of Giulio Moro via
Xenomai
Sent
Hi all,
is there a "cheap", RT-safe call that can be made in order to find out if the
current thread is a Xenomai thread or a Linux thread? Also, to detect whether
the Xenomai thread is in primary or secondary mode?
It seems that cobalt_thread_mode() gives some (all?) of these details. Is it
RT
functions returns EPERM, then it is not called from a
Xenomai thread and the current thread should be switched to Xenomai.
Now I tested A and B, and it seems to work, any known pitfalls?
Thanks,
Giulio
From: Jan Kiszka
Sent: 13 January 2019 03:30
T
>Date: Fri, 18 Jan 2019 11:48:12 +0800 (CST)
>From: 张建昆
>The system freeze when interrupt is triggered. I clone ipipe-arm master,
> and use xenomai 3.0.8 following xenomai startup tutorial.
>The hardware cpu is am3358. System works fine after start up, but the system
>immediately locks up wh
Hi there,
I have my kernel (4.4.113-ti-xenomai-r149 on BeagleBone BlacK) compiled with
CONFIG_XENO_OPT_WATCHDOG=y
CONFIG_XENO_OPT_WATCHDOG_TIMEOUT=4
I would like to experience the breeze of running without watchdog, to see what
the bare-metal performance of the board are, removing the overhead o
Hi there,
booting a 4.14.94-ti kernel with Cobalt 3.0.8 from the "stable/v3.0.x" branch,
on an am3358 (PocketBeagle) I get a warning during boot "irqchip tps65217 is
not pipeline-safe!". The tps65217 is the power-management IC for the board.
What does this message mean exactly? Is it something t
Hi there,
apologies if this has been discussed before.
In an older thread on this mailing list there was a link to
http://git.xenomai.org/ipipe-arm.git/commit/?id=63b8ee7f25b73547ac8eff7a6be5b587422015ca
, but the correct url is now
https://gitlab.denx.de/Xenomai/ipipe-arm/commit/63b8ee7f25b735
we use this one for 4.14
https://github.com/RobertCNelson/ti-linux-kernel-dev/tree/ti-linux-xenomai-4.14.y
(and the 4.4 branch there for 4.4). These are scripts to "rebuild a kernel":
it checks out the appropriate vendor (TI) branch, and merges the corresponding
ipipe patches in.
Known issues
It definitely is possible. Our image allows that
https://github.com/BelaPlatform/bela-image-builder/releases .
When you log in via serial, what is the result of `lsusb` ? Can you see the two
USB interfaces?
If not, are they enabled in the device tree? Are the USB drivers compiled in
your kernel
danwe wrote:
> I'm sorry I forgot to say that I was using Xenomai 2 with RTnet on top. I
> think RTnet is the problem isn't it? What exactly does RTnet to stop using
> mini usb port?
>
> Kind regards
>
> Daniel
You surely cannot use RTnet on that port, if that is what you are asking,
because
A previous conversation on the topic can be found here
https://xenomai.org/pipermail/xenomai/2017-October/037758.html
Jan Leupold via Xenomai wrote:
> I just realised that not locking the mutex for pthread_cond_signal() is not
> a good practice
I don't necessarily agree with this. There are case
Hi everyone,
From /proc/xenomai/sched/stat I infer there must be an internal struct
somewhere keeping track of how much CPU time is actually used by each thread.
Is there any way to access this kind of statistics from a running Xenomai user
space program without leaving primary mode and without
Philippe Gerum wrote on 29/04/2022 17:29:>
Giulio Moro via Xenomai writes:
Hi everyone,
From /proc/xenomai/sched/stat I infer there must be an internal struct
somewhere keeping track of how much CPU time is actually used by each
thread. Is there any way to access this kind of statistics f
85 matches
Mail list logo
