Hi,
With xenomai 3 (but i think the behaviour was the same with xenomai 2),
with loopback enabled, when there is no physical device on the bus, the
following happens :
* the messages fill the internal socket buffers. this result in any
blocking send call actually blocking the caller
* when this
Hi,
/proc/rtcan/devices , as well as the respective
/proc/rtcan//info both gives access to the TX-Counter, RX-
Counter and Errors counter of the device.
I'd like to access these counters from an application, but cannot find
the appropriate ioctls to do this. Adding them is not an issue, but i
Le mardi 03 juillet 2018 à 09:40 +0200, Julien Blanc a écrit :
>
> Is there a way to access these counters ? And if not, what would be
> the
> ioctl to add ? For example :
>
> #define RTCAN_RTIOC_GET_RXCOUNTER _IOR(RTIOC_TYPE_CAN, 0xC, int)
> #define RTCAN_RTIOC_GET_TXCOUNTE
Le jeudi 25 janvier 2018 à 15:21 +0100, Philippe Gerum a écrit :
> On 01/25/2018 02:43 PM, Julien Blanc wrote:
> >
> There is no provision for I/O multiplexing with alchemy. Only the
> pipe object embeds a RTDM file descriptor which could be passed to
> libcobalt's select() imp
Hi,
We have a xenomai 3 application currently using the alchemy API
(application development started on xenomai 2.x).
We would like to add I/O multiplexing in some parts of the application.
My understanding is that it is not supported by the alchemy API, so we
would have to resort to the Posix
I'm trying to use multiplexing wih rtcan sockets (using
xeno_can_flexcan driver).
Unfortunately, i had no luck yet to make it work. __RT(select) fails
with ENODEV error, while __RT(poll) returns a POLLERR event.
Is it unsupported, or am i doing something wrong ? (like a missing
parameter).
Le dimanche 04 février 2018 à 10:58 +0100, Philippe Gerum a écrit :
> On 02/02/2018 09:51 AM, Julien Blanc wrote:
> >
> > I'm trying to use multiplexing wih rtcan sockets (using
> > xeno_can_flexcan driver).
> >
> >
> > Is it unsupported, or am i
Hi,
The current xenomai documentation states that it is allowed to call
clock_settime with CLOCK_REALTIME parameter to set the value of the
xenomai realtime clock. On our board, the value at bootup is always 0
(so, epoch), despite the hardware clock being correctly set.
However, we experience
Le jeudi 19 avril 2018 à 15:27 +0200, Yann le Chevoir a écrit :
>
> I thought that both Alchemy and Posix skins would create a "Xenomai
> thread"
> and so I could mix the calls to API skins.
You can mix the APIs, but not the descriptors (ie, don't
rt_mutex_acquire a pthread_mutex_t). However, it
Le mercredi 28 mars 2018 à 13:24 +0530, Pintu Kumar a écrit :
> Hi,
>
> We are facing one issue on Xenomai-3 on x86_64 system.
> Kernel: 4.9.51
> ipipe version: 4
> # /usr/xenomai/sbin/version
> Xenomai/cobalt v3.0.6 -- #5956064 (2018-03-20 12:13:33 +0100)
>
> Its a very simple API level test.
>
We're using a mix of regular NPTL posix threads and RT cobalt threads
in our application, using XDDP communication between them.
In a few places, we need to identify the calling context, ie, whether
we're being called from a cobalt RT thread or from a regular NPTL
thread, and act accordingly.
My
Le mercredi 28 mars 2018 à 16:16 +0200, Philippe Gerum a écrit :
>
> cobalt_thread_pid(pthread_t) from the internal support library would
> do
> the job. A successful call would denote a cobalt thread, -ESRCH would
> denote a regular (or invalid) pthread.
Seems to work perfectly, thanks.
Le vendredi 14 septembre 2018 à 02:45 -0500, Per Oberg a écrit :
>
> This!
>
> Being able to use the same code, without patches or a lot of defines
> including other files is a very clean way of debugging your software.
> I often set up Simulations where I use my laptop running or our
>
Hi,
We’re currently using semaphores and a shared buffer to allow
communication between a xenomai cobalt thread and a linux regular
thread (the xddp interface has been tested and does not perform well
for our use case, which is exchanging a lot a very small messages).
While this works fine most
Le vendredi 14 décembre 2018 à 12:07 +0100, Philippe Gerum a écrit :
>
> You could use non-rt Xenomai threads on the linux side with policies
> SCHED_FIFO+prio=0 or SCHED_WEAK, allowing the thread to issue
> blocking
> Xenomai syscalls (such as waiting on a Cobalt sema4).
>
> But, since this
Le dimanche 13 janvier 2019 à 02:33 +, Giulio Moro via Xenomai a
écrit :
> 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
>
Le vendredi 14 juin 2019 à 12:26 +, Lange Norbert via Xenomai a
écrit :
> > -Original Message-
> > From: Xenomai On Behalf Of Julien
> > Blanc
> > via Xenomai
> > Sent: Freitag, 14. Juni 2019 13:54
> > To: Xenomai@xenomai.org
> > Subject: s
Hi,
We’re currently trying to make the serial port working on a custom
board based on an imx28 som.
The serial port is correctly handled by the linux mxs-uart driver.
However, under (slightly) heavy xenomai loads, we experience data loss
(we suspect xenomai is delaying interrupts for too long
Le vendredi 14 juin 2019 à 13:19 +, Lange Norbert a écrit :
> If the issue is on the receive side you probably need HW flow-control
> via RTS/CTS pins to make sure you don’t lose anything.
This proved to be a very good advice, as it seems to solve our issues.
Why we did not think about
Le vendredi 21 juin 2019 à 14:14 +0200, Wolfgang Denk a écrit :
> Dear Julien,
>
> The i.MX28 is a special beast.
>
> Your issue is most likely caused by a somewhat stup^H^H^H^Hsimple
> implementation of the UART driver. When it receives the interrupt
> after receiving a block of data, it stops
Le vendredi 26 avril 2019 à 17:20 -0500, Steve Freyder via Xenomai a
écrit :
>
> I can tell you that I have a hang issue due to fork() in a Xenomai
> program if, after the fork(), I don't do an exec(). I believe
> the hang is related to registry access, and the fact that the
> Unix domain socket
Hi,
I'm a bit puzzled about how SCHED_WEAK behaves vs linux regular
threads.
Suppose a kernel built without CONFIG_XENO_OPT_SCHED_WEAK (so, only 0
is a valid value for sched_priority, which should be the same as
SCHED_OTHER).
Let’s say i have four threads :
* thread 1, RT, with SCHED_FIFO
Le jeudi 01 août 2019 à 13:25 +0200, Jan Kiszka a écrit :
> On 01.08.19 11:53, Julien Blanc via Xenomai wrote:
> > Hi,
> >
> > Let’s say i have four threads :
> > * thread 1, RT, with SCHED_FIFO policy and a sched_param value of
> > 90
> > * thread 2, RT, w
d_self())
but i’m not sure what you mean by the cobalt thread id vs posix thread
id. IIRC they have the same value (ie, syscal(__NR_gettid) would give
the same value (for rt threads), maybe at the expense of a mode
switch).
Regards,
Julien Blanc
Le lundi 04 janvier 2021 à 19:58 +0800, 孙世龙 sunshilong via Xenomai a
écrit :
> Is it possible to implement a real-time API to read the files on the disk?
>
> As far as I know, there is no such an interface now, but is it
> possible to achieve this goal?
I doubt it could be. It depends on what
Le mardi 22 juin 2021 à 09:38 +0200, Philippe Gerum via Xenomai a
écrit :
>
> With this in mind, assuming that we have previously sanitized the
> clock
> identifier, doing this:
>
> #define get_timestamp(__clock) \
> ({ (__clock) == CLOCK_MONOTONIC ? rtdm_clock_read_monotonic() :
>
Le lundi 15 février 2021 à 14:52 +0100, Leandro Bucci via Xenomai a
écrit :
> What I want is to have a function that generates me mode switches
__STD(nanosleep)(timeout, NULL) with a zero timeout should do it.
and you can use any switch-primary call to go back to primary mode.
Regards,
Julien
Hi,
I'm having a bit of trouble setting the core clock under xenomai. We're
currently evaluating an imx6 based SOM for our new board. The core
clock should run at 528MHz, but starts and stays at 396MHz (its lowest
frequency), which is the expected behaviour according to the
manufacturer. We would
I'm trying to read the values of some gpios, which are connected to an
io expander, inside a xenomai kernel module.
I can read these gpio fine using standard linux gpiod calls.
Just calling gpio_get_value (or gpio_get_value_cansleep) from the
xenomai kernel module works fine during module init.
Le mardi 14 juin 2022 à 10:04 +0200, Philippe Gerum a écrit :
> Julien Blanc <
> julien.bl...@sprinte.eu
> > writes:
>
> > Le mardi 14 juin 2022 à 08:54 +0200, Philippe Gerum a écrit :
> > > Julien Blanc via Xenomai
> > > > #defi
Le mardi 14 juin 2022 à 08:54 +0200, Philippe Gerum a écrit :
> Julien Blanc via Xenomai
> >
> > #define __fallthrough __attribute__((fallthrough))
> >
>
> 6.39. attribute syntax
> https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html#Attribute-Syn
Le mardi 14 juin 2022 à 09:44 +, Bezdeka, Florian a écrit :
>
> Based on the kernel's fallthrough, introducing evl_fallthrough would
> avoid all kinds of conflicts (IMHO):
>
> #ifndev evl_fallthrough
> #if __has_attribute(__fallthrough__)
> # define evl_fallthrough
Le lundi 13 juin 2022 à 14:39 +, Russell Johnson via Xenomai a
écrit :
> I use boost throughout my entire app, so I need
> to figure how to get both of these libraries to play nice with each
> other. Any ideas? ( I am using gcc 8.3 and boost 1.70.0)
>
> /opt/evl/include/evl/compiler.h:64:36:
33 matches
Mail list logo
