Re: [Xenomai-core] RE : Activation of IRQ handler in the Linux domain
Hi Jan and Philippe, I decided to move the ISR into the RT domain and everything works well. Thanks for your suggestions. Actually, we've our i.MX21 board with some i2c devices (namely leds and buttons), and I wanted to make some example of applications using the i2c in the Xenomai domain. However, the way how the official i2c driver is coded is maybe not optimal since there is this polling on a state variable (transfer complete) which is updated by the ISR. My wish was to touch the driver as few as possible. Daniel -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: lundi 3 septembre 2007 23:37 To: ROSSIER Daniel Cc: [EMAIL PROTECTED]; xenomai-core Subject: Re: [Xenomai-core] RE : Activation of IRQ handler in the Linux domain Hi Daniel, [Some add-ons to what Philippe already pointed out:] ROSSIER Daniel wrote: ... Ok, I totally agree. I've tried to use a rtdm_event object which I've declared in the Linux driver side. Then, the write function is called from a RT task, That sounds error-prone: Is write only called from RT context? Does it have to synchronise with functions running in non-RT context, and is this synchronisation done in a RT-safe manner (rtdm_lock_...)? You may check this offline - or online with CONFIG_IPIPE_DEBUG_CONTEXT. then it calls rtdm_event_wait() at a certain point, and the i2c ISR performs a rtdm_event_signal() to wake up the RT task. However, I got a kernel crash when rtdm_event_wait() is called. Sometimes it is helpful to analyse what the crash says precisely, e.g. at which line of code (during which memory access) the crash happens. Also, debugging options may help to catch some potential root bug earlier. In general, I also smell a bit too much hacking and too less designing here... ;) Jan ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] VxWorks skin is missing new VxWorks headers for RTP
On Tue, 2007-09-04 at 00:04 +0300, Ravid Baruch Naali wrote: I imagined thats the policy. But is it worth investing time in? or is there higher priority task I can be assigned to? I don't think RTP is high priority for now. Two other tasks would have a much more significant impact, both for Xenomai users and developers. 1) Make Valgrind usable with Xenomai apps; of course without any real-time guarantee anymore, but this would nevertheless plug a serious hole in the development toolset available to users. 2) We do, certainly, definitely, desperately miss an automated way to get performance charts for a few selected Xenomai tests, which would allows us to conduct comparative analysis between versions, and find out what's right or wrong with our changes. For instance, we are currently maintaining seven architecture ports; each time something changes in some part of Xenomai's generic code, we have no freaking idea whether all archs benefit from such change, or if at least no arch gets penalized by it. And the very same goes for the interrupt pipeline, for which any hazardous change may generate adverse effects on an even much larger scale. Let me put this bluntly: this won't fly much longer; we are losing precious time getting rid of any regression way after it has actually happened into the code, because we cannot easily and routinely COMPARE how different versions behave. Aside of this, we don't have any factual data regarding how Xenomai evolved over time in terms of latency, code footprints and so on. What we need is a simple automated way to a given test on any given Xenomai version (actually a SVN commit number would be much better) extracted from our repository, draw a few charts summing up the results, and move those results to our website periodically or even as soon as they are available. _This_ would help users to understand the current trend and why we did some changes (or why we should not have done them), and allow developers to pull the brake each time a serious regression is visible from those charts. Simple and easy: TEST/x86: interrupt latency to kernel handler [latency -t2] (latency in us) ^ |x (XX us) = Houston, we have a problem. | x (ZZ us) | | x (YY us) | +--- commit#72 ...commit#2004 commit#any (v2.0) (v2.3) Another test could analyse the task dispatch latency, another one the code footprints in kernel space, and so on. Once this framework is available, we would find the various hardware to run the tests on and get the results from, that is not an issue anymore. Besides, tackling this issue is quite a good way to have his feet wet almost immediately with the Xenomai framework as a power user, and also to get immediate reward for such work, since we would push its results online routinely. Please, somebody implement this, damnit! Or I'm going to rewrite the entire Xenomai stack in Bourne shell with Java applets for speedups, so you could not complain about bad latencies and unwanted overhead anymore. Thank you, Philippe Gerum wrote: On Mon, 2007-09-03 at 17:05 +0300, Ravid Baruch Naali wrote: Hello again, Preface: As of VxWorks 6.x vxworks implement RTP which is an implementation of user space processes with real time capabilities, which of course include an extended API, which from my testings I discovered that we do not support yet. Currently extending the VxWorks API is not in Xenomai task list, does it have any demand? If I'll take it as a my task, do we have any legal issues with using Wind River's headers? This matter is muddy; fair use, interoperability, and copyrights of header files and/or their contents is a legal mess. Our policy is simple: paste-copy of any portion of any proprietary licensed header is unwanted and will be systematically rejected. You need to implement your own header, defining what you need for satisfying all the references within the emulator your are writing from scratch. You should also explicitly mention in the copyright notice that the resulting software is an emulator. We claim to mimick the original software as correctly as possible, according to the API specs which have been made publically available by the copyright holder of the original work, with all the limitations inherent to such exercise. In any case, we don't claim to produce a copy of the original software we only emulate. In short, Xenomai is a Chameleon, not a clone. If any of my assumptions is false or if you have any comment/answers please reply. thanks Ravid -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] VxWorks skin is missing new VxWorks headers for RTP
The automated chart seems exactly the thing for me (I have some testing tools development experience). I'll look into it and will soon send a initial design. Of course any pinters/advice/suggestions will be highly appreciated. Philippe Gerum wrote: On Tue, 2007-09-04 at 00:04 +0300, Ravid Baruch Naali wrote: I imagined thats the policy. But is it worth investing time in? or is there higher priority task I can be assigned to? I don't think RTP is high priority for now. Two other tasks would have a much more significant impact, both for Xenomai users and developers. 1) Make Valgrind usable with Xenomai apps; of course without any real-time guarantee anymore, but this would nevertheless plug a serious hole in the development toolset available to users. 2) We do, certainly, definitely, desperately miss an automated way to get performance charts for a few selected Xenomai tests, which would allows us to conduct comparative analysis between versions, and find out what's right or wrong with our changes. For instance, we are currently maintaining seven architecture ports; each time something changes in some part of Xenomai's generic code, we have no freaking idea whether all archs benefit from such change, or if at least no arch gets penalized by it. And the very same goes for the interrupt pipeline, for which any hazardous change may generate adverse effects on an even much larger scale. Let me put this bluntly: this won't fly much longer; we are losing precious time getting rid of any regression way after it has actually happened into the code, because we cannot easily and routinely COMPARE how different versions behave. Aside of this, we don't have any factual data regarding how Xenomai evolved over time in terms of latency, code footprints and so on. What we need is a simple automated way to a given test on any given Xenomai version (actually a SVN commit number would be much better) extracted from our repository, draw a few charts summing up the results, and move those results to our website periodically or even as soon as they are available. _This_ would help users to understand the current trend and why we did some changes (or why we should not have done them), and allow developers to pull the brake each time a serious regression is visible from those charts. Simple and easy: TEST/x86: interrupt latency to kernel handler [latency -t2] (latency in us) ^ |x (XX us) = Houston, we have a problem. | x (ZZ us) | | x (YY us) | +--- commit#72 ...commit#2004 commit#any (v2.0) (v2.3) Another test could analyse the task dispatch latency, another one the code footprints in kernel space, and so on. Once this framework is available, we would find the various hardware to run the tests on and get the results from, that is not an issue anymore. Besides, tackling this issue is quite a good way to have his feet wet almost immediately with the Xenomai framework as a power user, and also to get immediate reward for such work, since we would push its results online routinely. Please, somebody implement this, damnit! Or I'm going to rewrite the entire Xenomai stack in Bourne shell with Java applets for speedups, so you could not complain about bad latencies and unwanted overhead anymore. Thank you, Philippe Gerum wrote: On Mon, 2007-09-03 at 17:05 +0300, Ravid Baruch Naali wrote: Hello again, Preface: As of VxWorks 6.x vxworks implement RTP which is an implementation of user space processes with real time capabilities, which of course include an extended API, which from my testings I discovered that we do not support yet. Currently extending the VxWorks API is not in Xenomai task list, does it have any demand? If I'll take it as a my task, do we have any legal issues with using Wind River's headers? This matter is muddy; fair use, interoperability, and copyrights of header files and/or their contents is a legal mess. Our policy is simple: paste-copy of any portion of any proprietary licensed header is unwanted and will be systematically rejected. You need to implement your own header, defining what you need for satisfying all the references within the emulator your are writing from scratch. You should also explicitly mention in the copyright notice that the resulting software is an emulator. We claim to mimick the original software as correctly as possible, according to the API specs which have been made publically available by the copyright holder of the original work, with all the limitations inherent to such exercise. In any case, we don't claim to produce a copy of the original software we only emulate. In short, Xenomai is a Chameleon, not a clone.
Re: [Xenomai-core] Make watchdog-timer configurable
On Tue, 2007-09-04 at 15:12 +0200, Johan Borkhuis wrote:
I made the following change to Xenomai (version 2.3.2, but it could also
be applied to 2.4 as the watchdog code has not been changed).
The watchdog timeout is fixed at 4 seconds. For us this is a problem as
there are some processes that take more time than this.
I made the following change to allow this to be changed through the
Linux kernel configuration. The value is configurable between 1 and 60
seconds.
Below is a patchfile that implements this change. Please let me know if
you have comments on this, or if there are problems with this change.
Looks good. Will merge, thanks.
diff -u -r org/xenomai-2.3.2/ksrc/nucleus/Kconfig
xenomai-2.3.2/ksrc/nucleus/Kconfig
--- org/xenomai-2.3.2/ksrc/nucleus/Kconfig 2007-07-06
18:42:14.0 +0200
+++ xenomai-2.3.2/ksrc/nucleus/Kconfig 2007-09-04 14:13:41.0 +0200
@@ -172,6 +172,17 @@
behalf of the timer tick handler, thus is only active after
the timer has been started.
+config XENO_OPT_WATCHDOG_PERIOD
+ depends on XENO_OPT_WATCHDOG
+ int Watchdog period (s)
+ default 4
+range 1 60
+ help
+
+Nr of seconds of uninterrupted real-time activity after which
+the watchdog triggers.
+
+
menu Timing
config XENO_OPT_TIMING_PERIODIC
diff -u -r org/xenomai-2.3.2/ksrc/nucleus/pod.c
xenomai-2.3.2/ksrc/nucleus/pod.c
--- org/xenomai-2.3.2/ksrc/nucleus/pod.c2007-07-07
10:18:57.0 +0200
+++ xenomai-2.3.2/ksrc/nucleus/pod.c2007-09-04 14:06:35.0 +0200
@@ -2925,7 +2925,7 @@
return nkpod-svctable.faulthandler(fltinfo);
}
-#ifdef CONFIG_XENO_OPT_WATCHDOG
+#if (defined CONFIG_XENO_OPT_WATCHDOG)
(CONFIG_XENO_OPT_WATCHDOG_PERIOD 0)
/*!
* @internal
@@ -2948,7 +2948,7 @@
return;
}
- if (unlikely(++sched-wd_count = 4)) {
+ if (unlikely(++sched-wd_count =
CONFIG_XENO_OPT_WATCHDOG_PERIOD)) {
xnltt_log_event(xeno_ev_watchdog, thread-name);
xnprintf(watchdog triggered -- killing runaway thread
'%s'\n,
thread-name);
Kind regards,
Johan Borkhuis
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] VxWorks semaphore usage demo
On Tue, 2007-09-04 at 10:50 +0200, Gilles Chanteperdrix wrote: On 9/3/07, Ravid Baruch Naali [EMAIL PROTECTED] wrote: Gilles Chanteperdrix wrote: On 9/3/07, Ravid Baruch Naali [EMAIL PROTECTED] wrote: Hello again, Hi, I'm not sure what is the preferred way to commit my changes, so before I commit i'm Attaching my patch in order to get you remarks and further instructions The synchronization on tasks completion with the semID semaphore seems broken. The main thread will get the semahore when the first task completes, not when all the tasks complete. I see too many comments, for instance: // Checking for failures if (error == ERROR) is useless, it is pretty obvious from reading the code that you are checking for failure. Comments should tell us things that are not obvious. Now, about the style, this is C code, so use C style comments. I would also prefer that you use the kernel coding style, but this is not kernel code, so I am not sure the rule is to use the kernel coding style. Re sending the patch following Gilles comments Looks good to me, except for the typo in the errno_to_message function. Philippe, could you apply this patch ? I am changing ISP, so I have not internet at home. Ok, will merge. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] VxWorks skin is missing new VxWorks headers for RTP
Ravid Baruch Naali wrote: The automated chart seems exactly the thing for me (I have some testing tools development experience). I'll look into it and will soon send a initial design. Hurray! You just deserved an option for a free beer! Now you just need to post the first related patch - and manage to meet me personally (the latter may be a bit trickier than the former ;)). Of course any pinters/advice/suggestions will be highly appreciated. Let's start with creating the infrastructure for the targets firsts. Once we have more tests with unified output locally on the Xenomai targets, we can think about how to transfer this data to a central database and how to visualise that database on the web. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
