[Xenomai] rtcan loopback behaviour when physical device is in error

[Julien Blanc]

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 happens, this also block the loopback interface, since can
messages are only loopbacked if succesfully sent to the physical
interface.

We would like to change the behaviour in the following way :

* if the physical interface is in error, and there is a single client,
no change (ie, continue to block)
* if the physical interface is in error, but there are multiple clients
(ie, the loopback will be trigged), then :
  * discard the message from the physical interface
  * loopback the messages to the connected clients

We believe this is a more logical behaviour if each program working
with the rtcan is seen as a separate physical device -> the error of
one device should not compromise the communication between others,
while still remain the behaviour that if no one listens, then the
message cannot be sent.

This is a big change, and likely to break any code that rely on the
previous behaviour.

So, questions :

* has such a change any chance to reach mainline xenomai ? (we're gonna
do and provide the necessary patches)
* if so, should this behaviour be made optional ? The loopback property
could be changed from a single yes/no to a tri-valued easily in that
regard.

Thanks,

Julien

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] [rtcan] Access to tx / rx / err counters

[Julien Blanc]

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
would like to avoid duplicating any existing feature, or to read the
/proc filesystem whose format is not really guaranted.

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_TXCOUNTER _IOR(RTIOC_TYPE_CAN, 0xD, int)
#define RTCAN_RTIOC_GET_ERRCOUNTER _IOR(RTIOC_TYPE_CAN, 0xE, int)

Regards,

Julien

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [rtcan] Access to tx / rx / err counters

[Julien Blanc]

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_TXCOUNTER _IOR(RTIOC_TYPE_CAN, 0xD, int)
> #define RTCAN_RTIOC_GET_ERRCOUNTER _IOR(RTIOC_TYPE_CAN, 0xE, int)

Attached is a patch that does exactly that (ie, adding the ioctls).
Based on xenomai 3.0.4, tested only with the flexcan driver (but should
work with any other).

Regards,

Julien
-- next part --
A non-text attachment was scrubbed...
Name: rtcan_counters_ioctl.patch
Type: text/x-patch
Size: 1792 bytes
Desc: not available
URL: 
<http://xenomai.org/pipermail/xenomai/attachments/20180703/034e174c/attachment.bin>
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Posix vs Alchemy - multiplexing and registry

[Julien Blanc]

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() implementation, other resources (e.g. queues,
> buffers etc) don't.

Thanks for your answer. If i understand correctly, this also means that
it is not recommended to mix both APIs in the same program. For example
a queue created with rt_create_queue cannot be read with
__cobalt_mq_open, am I right ?

> I would suggest to enable the registry for your application (not for
> the entire POSIX API), as you might not need each and every resource
> to be exposed via a fuse-based fs.

This is something i'd rather avoid if possible. Though, thanks for the
pointers, at first glance it seems much simpler than what i feared.

Regards,

Julien

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] Posix vs Alchemy - multiplexing and registry

[Julien Blanc]

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 API.

The downside is that by doing so, we lose the registry : with the posix
api nothing is exported. We would like to access all this data, at
least for debugging purposes (ideally, disable it in production build).

I couldnt find any pointer for doing either of the following :
- enable the registry while using the posix API
- multiplex using the alchemy api
- retrieve a posix-api compatible file descriptor from an alchemy
handle (which would allow a __cobalt_select call)

Is there some resources or something obvious that i'm missing ?

Best regards,

Julien



___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] Multiplexing and rtcan socket

[Julien Blanc]

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). Sample code to reproduce the issue is attached.

Regards,

Julien
-- next part --
A non-text attachment was scrubbed...
Name: test.cpp
Type: text/x-c++src
Size: 1982 bytes
Desc: not available
URL: 

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Multiplexing and rtcan socket

[Julien Blanc]

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 doing something wrong ? (like a missing
> > parameter). Sample code to reproduce the issue is attached.
> > 
> The RTCAN stack predates the implementation of select(), and was
> never 
> updated to provide this, hence ENODEV. If somebody volunteers to
> provide 
> this, this should likely go into the code implementing the raw CAN
> socket.

Thanks for your answer. I unfortunately will have no time to spend on
this in the near future, since this is not a critical issue for us.

I'll look into it when possible, though, it would be a very nice to
have feature.

Regards,

Julien

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] Strange behaviour after calling clock_settime

[Julien Blanc]

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 bad behaviour when doing so. Notably, alchemy
condition variables seems to no longer work. Resetting the xenomai
CLOCK_REALTIME to the initial value puts things back in order.

Is it a known issue ? Are we doing something wrong ? Or is it just
better to let the xenomai CLOCK_REALTIME live its life, considering it
as a CLOCK_MONOTONIC, and rely to CLOCK_HOST_REALTIME whenever we need
real dates ?

Regards

Julien

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Call Alchemy API from a Posix skin thread

[Julien Blanc]

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 may be a wrapping
issue, which will result in your posix threads not using cobalt API,
but the linux nptl api.

Make sure your calling thread shows up in /prox/xenomai/sched/threads.
If not, check your build and linker settings. (or force the use of
cobalt api with __RT macro for your pthread* calls).

Regards,

Julien

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Problem with rt_cond_wait and rt_cond_signal combination

[Julien Blanc]

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 create a condition variable and wait for the condition inside a
> task.
> Then, we immediately signal the condition from the main thread, and
> simply
> wait for the test to finish.

Looks like you're signalling the condition variable before it is even
begin waited by the newly created thread, so i would say the behaviour
is normal.

If this is just for test purpose, you can for example add a sleep
inside your main thread so that you make sure that the child thread
reaches the rt_cond_wait call before the main thread executes
rt_cond_signal.

Regards,

Julien

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] Canonical way to differentiate between NPTL / Cobalt threads

[Julien Blanc]

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 understanding is that calling pthread_getschedparam and checking
that the returned policy is SCHED_FIFO does the job.

* is it correct ? Or are they some corner cases not covered by this
test ?
* is it the canonical way, or is there another one ? (maybe cheaper -
since this call will do two calls in case of a posix thread, there must
be a cheaper way to detect the running context).

Regards,

Julien



___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Canonical way to differentiate between NPTL / Cobalt threads

[Julien Blanc]

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.

Regards,

Julien

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Order options to build a Xenomai program

[Julien Blanc]

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
> controller, possibly connected to remote hardware to debug stuff. For
> these cases  the POSIX skin is very useful.

I thought that was the purpose of the mercury core.

For a full xenomai application, the wrapping mechanism is nice. For a
mixed rt / non-rt executable, this tends to be full of pitfalls. The
__RT and __STD macros are of a great help in this regard. 

I also still wonder if there’s a way to make std::thread work in such a
mixed environment.

> What do you mean with "convert Xenomai a CMake project"? I feel that
> I am missing something...

I think it means "build xenomai with cmake" (which is unlikely to
happen afaik).

Regards,

Julien

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Waking up a linux thread from a xenomai thread, without mode switch

[Julien Blanc via Xenomai]

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 of the time, we’ve noticed that this incurs
a mode switch when the xenomai rt-thread calls real_sem_post, and,
under heavy load, it can results in that specific thread being
suspended for too long.

I couldn’t find in the documentation how to do this properly :
* waiting on a xenomai semaphore from a linux thread is forbidden
* posting a linux semaphore from a xenomai thread incurs a mode switch

I’d like each thread to stay in its mode. I can live with the linux
thread entering the primary mode for a small amount of time, but not
the xenomai thread entering the secondary mode.

Did i miss something obvious ?

Regards,

Julien

Re: Waking up a linux thread from a xenomai thread, without mode switch

[Julien Blanc via Xenomai]

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 would incur two mode switches for the caller - one to
> switch to primary, then a converse switch to relax when returning
> from
> the blocking syscall - you certainly don't want to use that method in
> high-frequency loops, because this would be very costly CPU-wise.

Do you mean, using a third thread acting as a proxy, so that the
xenomai thread never leaves the primary domain ? This is something i
identified as a « possible solution », but yes, the overhead seems
pretty high. At this rate it may be cheaper to just use an active
waiting loop (in the linux domain) with a ~5ms period in the linux
domain, instead of waiting on a semaphore.

> Did you try the streaming output mode with MSG_MORE as illustrated in
> demo/posix/cobalt/xddp-stream.c? The streaming mode attempts to pack
> multiple messages from the rt-side into a single message delivered to
> the read() side, until the latter eventually resumes.

> IOW, if the rt-side is able to send N messages before the linux side
> eventually wakes up, then the latter will receive all the streamed
> output packed into a single read().

I don’t remember having tried that, thanks for the pointer.

Regards,

Julien

Re: "cheap", RT-safe way of detecting if a thread is Xenomai or Linux

[Julien Blanc via Xenomai]

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
> mode?

quoting Philippe, who i asked a similar question some time ago :

« 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. »

This works perfectly.

Julien

Re: serial driver for imx28

[Julien Blanc via Xenomai]

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: serial driver for imx28
> > 
> > 
> > We’re currently trying to make the serial port working on a custom
> > board
> > based on an imx28 som.
> 
> Are you using the Debug uart or the Application UART?
> The debug uart has incredibly slow register accesses, and can't do
> DMA, you would not be happy about that in an RT application.

I’m talking about the application uart. Also, note that the UART does
not need to be realtime (the reason we are using it from plain linux in
the first place), but the issues we encounter make us reconsider this
decision.

> Further what interfaces are you planning to use? Ethernet is rather
> horrible to use aswell, as you need to byteswap *all* data (hardware
> bug, I am not talking about the Ethernet heads using BigEndian).

We’re not planning to do any rtnet, and the linux driver seems fine
(frow a user pov). RT is required for CAN and gpios (both handled by
xenomai drivers) which work fine. Our only issues are with uart, called
from linux domain (issues which were unfortunately not seen during the
qualification phase).

> Sorry, don’t know the state of Xenomai in regards to this SOC, (but I
> know the Chip and its warts pretty well).

Switching to another chip is not an option (we need to solve this issue
for existing boards).

Thanks for your reply,

Regards,

Julien

serial driver for imx28

[Julien Blanc via Xenomai]

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 for the linux
kernel to handle them, resulting in the data loss).

To fix this issue, we’re trying to migrate from the linux non-rt driver
to the xenomai rt_imx_uart driver (other suggestions welcome).

Our kernel is 4.9.24, and xenomai is 3.0.5. An upgrade to 3.0.7 fixes
the compilation issue.

However, we can't manage to make this driver recognize the uart, nor to
find any documentation / pointers on how to configure it for our needs.

So, the questions are :
- is the imx28 supported ?
- are there any pointers / samples as to how to configure it (correct
address / irq, etc.).

Regards,

Julien

Re: serial driver for imx28

[Julien Blanc via Xenomai]

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 enabling it in the first place remains a
mystery to me.

Thank you very much,

Julien

Re: serial driver for imx28

[Julien Blanc via Xenomai]

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 DMA until the data has
> been read from the RX buffer and pushed to the TTY layer.  Given the
> tiny size of the UART RX FIFO, this will cause frequent overruns if
> you don't enable or cannot use flow control.

Indeed.

The driver seems to be really buggy outside the simple use cases
(anything involving reconfiguring the transmission settings on the fly
is not recommended), but RTS/CTS definitely solved our data loss
issues. As a bonus we were even able to increase the baudrate up to
460800 bauds.

Best regards and thanks all for your answers,

Julien

Re: having problems with daemonizing

[Julien Blanc via Xenomai]

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 connecting to sysregd that is inherited by
> the forked process (which has FD_CLOEXEC set) hasn't yet gotten
> closed (no exec() yet so no action on FD_CLOEXEC flags yet).

We ran into a similar issue (still using 3.0.5, which seems not to have
the FD_CLOEXEC flag set).

If you don’t share any file descriptors with the child process, the
following (after the fork and before the exec) did help in our case :

DIR* dirs = opendir("/proc/self/fd");
int fd = dirfd(dirs);
dirent* d = readdir(dirs);
while (d != nullptr)
{
int a = 0;
a = std::strtol(d->d_name, nullptr, 10);
if (errno == 0 && a > 2 && a != fd)
{
close(a);
}
d = readdir(dirs);
}
closedir(dirs);

Basically it closes any open file descriptor by the child process,
except stdout/stderr.

Note that we are forking from a linux domain thread hosted in a xenomai
application, creating a pure linux application. In that case the
registry stuff is complete nonsense in the child process. But this
should also be ok for other use cases.

Regards,

Julien

SCHED_WEAK vs linux regular threads

[Julien Blanc via Xenomai]

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 policy and a sched_param value of 90
* thread 2, RT, with SCHED_WEAK policy and a sched_param value of 0
* thread 3, RT, with SCHED_WEAK policy and a sched_param value of 0
* thread 4, non-RT, with SCHED_RR policy and a sched_param value of 30

Now, what happens regarding the scheduling ?
* thread 1 always run first as long as it does not leave the primary
domain
* thread 2 and 3 enters the primary domain only during xenomai xthread-
only calls ? And leaves it just after.
* if thread 2 and 4 competes for the CPU (while thread 2 is in the
secondary domain), who is given CPU ?
* how does thread 2 and 3 competes (while in secondary mode) against
linux kernel (while in secondary mode) ? And other programs ? (ie, can
a SCHED_WEAK process eating all cpu hang the whole linux system, like
with standard RT threads).
* is there a way to prioritize thread 2 and thread 3 (while in the
secondary domain) ? (for example by adjusting a posix only priority).
Or is it the whole reason behind CONFIG_XENO_OPT_SCHED_WEAK ?

Regards,

Julien

Re: SCHED_WEAK vs linux regular threads

[Julien Blanc via Xenomai]

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, with SCHED_WEAK policy and a sched_param value of 0
> > * thread 3, RT, with SCHED_WEAK policy and a sched_param value of 0
> 
> Should 2 and 3 have the same parameters in your scenario?

That is not necessary. But our kernel currently lacks OPT_SCHED_WEAK,
so i need to consider whether we need to rebuild and deploy a new one
or not (i’d like to avoid it for now).

> You can assign non-zero prios to thread 2 and 3, ordering it this
> way, but then also while both are in primary mode. For "weak"
> ordering, you could also leave their prio at 0 and play with their
> nice level. That would be a Linux-only "prio".

I’ll give that a try.

Thanks and thanks to Philippe for your detailed answers, this is much
clearer now.

Regards,

Julien

Re: rt_task_inquire() equivalent for POSIX ?

[Julien Blanc via Xenomai]

Le jeudi 07 novembre 2019 à 06:47 +0100, Pierre FICHEUX via Xenomai a
écrit :
> I've tried it but got the pid of the "main" thread not the RT one
> (that's
> normal...).
> 

extern "C"
{
int cobalt_thread_pid(pthread_t);
}

int tid = cobalt_thread_pid(pthread_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

Re: Is it possible to implement a real-time API to read the files on the disk?

[Julien Blanc via Xenomai]

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 you mean by "real-time", but
disks (hard-disks and ssds as well) typically have non-deterministic
response times, which breaks any real-time promise.

There may be a way to define an api using only asynchronous operations.
I don't know enough of the low-level stuff involved in sata to have a
strong opinion on this. It's possible with some flash devices and
microcontrollers.

The other way is: do your i/o in a linux thread, communicating
asynchronously with your rt threads.

Regards,

Julien

Re: Large gpio interrupt latency

[Julien Blanc via Xenomai]

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() :
> rtdm_clock_read(); })
> 
> may end up being faster than:
> 
> xnticks_t (*__get_timestamp)(clockid_t clock);
> #define get_timestamp(__clock)__get_timestamp(__clock)

Is really a runtime switch necessary ? Since relying on the realtime
clock is inherently broken, my understanding is that it should be kept
as compatibility purpose only.

A compile define would suffice, then, and that could also be used to
warn users that relying on the realtime clock is deprecated and will
disappear in future versions (if that's the plan).

Regards,

Julien

Re: Mode Switch

[Julien Blanc via Xenomai]

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

Core clock under xenomai

[Julien Blanc via Xenomai]

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 like it to run at its nominal speed.

Now, according to the manufacturer, i'm supposed to use cpufreq and the
performance governor to set it to its maximum speed. However, the
xenomai docs strongly advise against using any form of CONFIG_CPU_FREQ.

* are these warning only for x86, and CONFIG_CPU_FREQ can be safely
enabled on arm ?
* is there a xenomai (cobalt) specific way to set the core clock which
i would not be aware of ?

Best regards,

Julien

gpio on i2c io expander

[Julien Blanc via Xenomai]

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. It always works
fine for non-i2c gpios.

However, doing the same read or write inside the rt task results in a
freeze of the board.

The hardware is an Imx6ull board, xenomai version 3.1.1, linux 5.4.119
(vanilla) and ipipe-core-5.4.119. The way, the expander is a pca8135.

I'm not sure what's happening there, but my guesses are that the
get_value with an i2c gpio results in the xenomai kernel spinning while
for the linux kernel (the pca driver is only available for linux), but
thus not giving it time to handle the reading from the i2c. In all
cases it means that even if it would work there would be no real-time
guarantee.

Searching "xenomai + i2c gpio" does not seems to give pertinent results
(just a few old results). So:
* is this supposed to work out-of-the-box ? (my guess is no)
* is it possible to use i2c from inside a xenomai driver
* if not, what would be the proper way to make it work under xenomai (i
can write a driver dedicated to our board (ie, i2c + io expander), but
maybe a more generic i2c would be more useful for the community).

Regards,

Julien

Re: compile conflict with Boost

[Julien Blanc via Xenomai]

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 
> > > > #define __fallthrough   __attribute__((fallthrough))
> > > > 
> > > 
> > > 6.39. attribute syntax
> > > https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html#Attribute-Syntax
> > > 
> > > 
> > 
> > Not sure what you mean with this link. The relevant attribute is
> > documented here: 
> > https://gcc.gnu.org/onlinedocs/gcc/Statement-Attributes.html
> > 
> > 
> > > PS: fixes go with patches.
> > 
> > Indeed, but i'll let Russel do this one as i don't have the
> > opportunity
> > to test it right now.
> > 
> 
> The documentation (paragraph 6.39) states that "You may optionally
> specify attribute names with ‘__’ preceding and following the name.
> This allows you to use them in header files without being concerned
> about a possible macro of the same name. For example, you may use the
> attribute name __noreturn__ instead of noreturn.".
> 
> This is generally used with C attributes as a precaution against
> namespace conflicts in the C language space. IOW, making a C++ parser
> happy is ok with me as long as this does not introduce potential
> issues down the road with regular C code.

Missed that part, thanks. The issue here is thus not within the
attribute part, which can be either fallthrough or __fallthrough__, but
only in the macro name, which should be __fallthrough instead of just
fallthrough.

(following untested, although it should be ok, pretty straightforward)

Fix fallthrough macro

Signed-off-by: Julien Blanc 

diff --git a/vendor/evl/compiler.h b/vendor/evl/compiler.h
index fce2766..8e6ad8c 100644
--- a/vendor/evl/compiler.h
+++ b/vendor/evl/compiler.h
@@ -61,7 +61,7 @@
 #endif
 
 #ifndef __fallthrough
-#define fallthrough__attribute__((__fallthrough__))
+#define __fallthrough  __attribute__((__fallthrough__))
 #endif
 
 #ifndef __alloc_size

Re: compile conflict with Boost

[Julien Blanc via Xenomai]

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-Syntax
> 

Not sure what you mean with this link. The relevant attribute is
documented here: 
https://gcc.gnu.org/onlinedocs/gcc/Statement-Attributes.html

> PS: fixes go with patches.

Indeed, but i'll let Russel do this one as i don't have the opportunity
to test it right now.

Regards,

Julien

Re: compile conflict with Boost

[Julien Blanc via Xenomai]

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  __attribute__((__fallthrough__))
> #else
> # define evl_fallthrough  do {} while (0)  /* fallthrough */
> #endif
> #endif
> 
> All evl internal users would have to be migrated.

In that case, wouldn't it make sense to migrate *all* macros in
compiler.h to an evl-prefix (nonwithstanding the fact that it's gonna
break a lot of code)? Or are they supposed to be already defined and
compiler.h is here just as a fallback (in which case, it makes sense to
stick with the __ prefix) ?

Regards,

Julien

Re: compile conflict with Boost

[Julien Blanc via Xenomai]

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: error: '__fallthrough__' was
> not
> declared in this scope
> 
> #define fallthrough __attribute__((__fallthrough__))
> 
> ^~~

This line looks wrong. The correct way to use the fallthrough attribute
(at least with gcc) is __attribute__((fallthrough)) , so that will
conflict with any usage (not only boost's).

It should probably be fixed by:

#define __fallthrough   __attribute__((fallthrough))

Regards,

Julien