Re: [Xenomai-core] Adeos PowerPC port over 2.6.21
Philippe Gerum wrote: Benjamin, On Tue, 2007-08-07 at 14:03 +0200, Benjamin ZORES wrote: Benjamin ZORES wrote: Benjamin ZORES wrote: Hi, I've seen that Adeos has been officially ported to PowerPC architecture. Please find an update of the adeos-ipipe-2.6.20-powerpc-1.6-02 to Linux 2.6.21 (.5) kernel, in case somebody's interested in it. Sorry for the delay in replying, I was caught on the dark 64bit side of the powerpc world. I won't do this again, I mean, delaying, not 64bit fiddling. Ok, maybe I'll do, but I will apologize again. Merged in both branches. Thanks a lot, Hi, It's definitely not a problem. I work in OSS too so I know what delaying answers on ML means ;-) I'm just glad it has been commited. Thx ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Activation of IRQ handler in the Linux domain
On Mon, 2007-09-03 at 14:11 +0200, ROSSIER Daniel wrote: Hello, I'm doing a small RT application using the I2C driver from Linux. At a certain time, when the task is activated and data are written to the I2C bus, the driver waits for a IRQ that confirmed the data have been sent out. The write function actually polls a variable state until a timeout or a state change occurring on reception of that IRQ (done by the handler). However, since driver functions are called from the Xenomai domain, the IRQ handler is not processed at the reception since the hander belongs to the Linux domain. It ends up with a timeout during the write. I implemented a local ISR within the Xenomai application, but the propagation of IRQ is not performed while the task is running. Which is expected. All the pipeline abstraction relies on the very fundamental assumption that domains run by priority order, which in turn means that a high priority domain must run until all the pending work is processed, and a Xenomai task in a runnable state represents some pending work for the Xenomai domain. Make your Xenomai task sleep on some synchronization object (likely a RTDM one) for synchronizing with the code which signals the wakeup condition, and the pending IRQ will flow down to Linux as expected. Busy waiting for such condition is a dead end here. Is there a way to tell Adeos to forward the IRQ to the Linux domain with no delay so that the Linux handler can be called? or do I need to re-implement the ISR in the Xenomai application? Your code cannot be on both side of the same fence. Either you want a real-time guarantee for interrupt delivery and task dispatching and you need a Xenomai ISR to process IRQs to wake-up some Xenomai task; or, you don't need any guarantee, but still want Linux to process the i2c IRQs just for the purpose of recycling some vanilla code, and in such a case, you need to make the Linux IRQ handler wake up the Xenomai task. In the latter case, the Xenomai task (in primary RT mode) must sleep at some point waiting for the wake up event, there is no sideways possible here. You may call rt_sem_v() or sem_post(), or a rtdm object signaling routines from a Linux context to wake up a real-time sleeper. Thanks for any hints. Daniel ___ 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
[Xenomai-core] VxWorks skin is missing new VxWorks headers for RTP
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? If any of my assumptions is false or if you have any comment/answers please reply. thanks Ravid -- Ravid Baruch Naali [EMAIL PROTECTED] +972 4 6732729 +972 52 5830021 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH] VxWorks semaphore usage demo
Hello again,
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
Thanks
--
Ravid Baruch Naali
[EMAIL PROTECTED]
+972 4 6732729
+972 52 5830021
Index: ksrc/skins/vxworks/demos/sem.c
===
--- ksrc/skins/vxworks/demos/sem.c (revision 0)
+++ ksrc/skins/vxworks/demos/sem.c (revision 0)
@@ -0,0 +1,104 @@
+#include stdio.h
+#include stdlib.h
+#include string.h
+#include unistd.h
+#include sys/types.h
+#include sys/wait.h
+#include errno.h
+#include vxworks/vxworks.h
+#include sys/mman.h
+
+
+#define TASK_NUM 10
+#define STACK_SIZE 1024
+#define xnarch_printf printf
+
+SEM_ID semID, syncSEM;
+
+void taskMain(long arg1, long arg2, long arg3, long arg4, long arg5, long arg6, long arg7, long arg8, long arg9, long arg10)
+{
+int localerrno;
+//Waiting to start synchronized with all other spawned tasks
+semTake(syncSEM, WAIT_FOREVER);
+//Taking the counting semaphore to indicate task started running,
+//stall main from exiting
+STATUS result = semTake(semID, WAIT_FOREVER);
+//Chaking for failures
+if(result == ERROR){
+ localerrno = errnoGet();
+ //checking failure reason
+ switch(localerrno){
+ case S_objLib_OBJ_ID_ERROR:
+ xnprintf( Semaphore ID is invalid\n);
+ break;
+ case S_objLib_OBJ_UNAVAILABLE:
+ xnprintf( Semaphore unavailable (NO_WAIT)\n);
+ break;
+ case S_objLib_OBJ_TIMEOUT:
+ xnprintf( Timeout occured before semaphore was released\n);
+ break;
+ case S_semLib_INVALID_OPTION:
+ xnprintf( Semaphore type is invalid\n);
+ break;
+ case EINTR:
+ xnprintf( Received interup\n);
+ break;
+ default:
+ break;
+ }
+ return;
+}
+
+int i = 10;
+//Getting this task's ID
+int ownID = taskIdSelf();
+//Getting this task's pririty
+int priority;
+result = taskPriorityGet(ownID, priority);
+
+xnprintf( My priority is %d\n, priority);
+while(i){
+ printf(My name is %s my tid=%d\n, taskName(ownID), ownID);
+ sleep(1);
+ i--;
+}
+//Signaling main that this task as finished
+semGive(semID);
+//Not realy required but releasing semaphore
+semGive(syncSEM);
+}
+
+
+int main(int argc, char **argv)
+{
+
+mlockall(MCL_CURRENT|MCL_FUTURE);
+int tidStat;
+int tids[TASK_NUM];
+//Creating counting semaphore on which main waits until all tasks are done
+semID = semCCreate(SEM_Q_PRIORITY, TASK_NUM);
+if(!semID){
+ xnprintf( Failed to create semaphore\n);
+ exit(1);
+}
+//Creating a binary semaphore to sync all tasks
+syncSEM = semBCreate(SEM_Q_PRIORITY, SEM_EMPTY);
+if(!syncSEM){
+ xnprintf( Failed to create binary semaphore\n);
+ exit(1);
+}
+//creating all the tasks
+int i;
+for(i = 0; i TASK_NUM; i++){
+ tids[i] = taskSpawn(NULL, 25-i, 0, STACK_SIZE , taskMain,0,0,0,0,0,0,0,0,0,0);
+ xnprintf( Spawned task: %d\n, tids[i]);
+}
+//Giving all tasks a signal to start
+semFlush(syncSEM);
+//Waiting for all task to complete their main routine
+semTake(semID, WAIT_FOREVER);
+for(i = 0; i TASK_NUM; i++)
+ taskDelete(tids[i]);
+semDelete(semID);
+semDelete(syncSEM);
+}
Index: ksrc/skins/vxworks/demos/Makefile
===
--- ksrc/skins/vxworks/demos/Makefile (revision 2960)
+++ ksrc/skins/vxworks/demos/Makefile (working copy)
@@ -7,7 +7,7 @@
STD_CFLAGS := $(shell $(XENO_CONFIG) --xeno-cflags)
STD_LDFLAGS := $(shell $(XENO_CONFIG) --xeno-ldflags) -lvxworks
-STD_TARGETS := satch
+STD_TARGETS := satch sem
GCIC := $(prefix)/bin/gcic
SIM_CFLAGS := -g
@@ -27,6 +27,9 @@
satch: satch.c
$(CC) -o $@ $ $(STD_CFLAGS) $(STD_LDFLAGS)
+sem: sem.c
+ $(CC) -o $@ $ $(STD_CFLAGS) $(STD_LDFLAGS)
+
satch_sim: satch_sim.o
$(GCIC) -o $@ $ $(SIM_LDFLAGS)
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] VxWorks semaphore usage demo
On Mon, 2007-09-03 at 17:32 +0200, 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. It is. We do want a common style regardless of the execution space. TIA, -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] VxWorks semaphore usage demo
Philippe Gerum wrote: On Mon, 2007-09-03 at 17:32 +0200, 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. It is. We do want a common style regardless of the execution space. TIA, Thanks for the comments I'll adapt and fix it before I'll send it again. -- Ravid Baruch Naali [EMAIL PROTECTED] +972 4 6732729 +972 52 5830021 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] VxWorks semaphore usage demo
Re sending the patch following Gilles comments
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.
--
Ravid Baruch Naali
[EMAIL PROTECTED]
+972 4 6732729
+972 52 5830021
Index: ksrc/skins/vxworks/demos/sem.c
===
--- ksrc/skins/vxworks/demos/sem.c (revision 0)
+++ ksrc/skins/vxworks/demos/sem.c (revision 0)
@@ -0,0 +1,138 @@
+#include stdio.h
+#include stdlib.h
+#include string.h
+#include unistd.h
+#include sys/types.h
+#include sys/wait.h
+#include errno.h
+#include vxworks/vxworks.h
+#include sys/mman.h
+
+
+#define TASK_NUM 10
+#define STACK_SIZE 1024
+#define LOOPS 10
+#define xnarch_printf printf
+#define TOP_PRIORITY 25
+
+SEM_ID task_counter_sem;
+SEM_ID task_sync_sem;
+
+static errno_to_messgae(char *failing_func);
+
+/*
+ * A shared main routine for all tasks other then the main
+ * each task waits for the signal from the main task
+ * then it notify it's existing
+ *
+ * It then loops and prints out LOOPS times it's name and tid
+ * when done it notifies
+ *
+ * None of the parameters are being used
+ */
+void task_main_routine(long arg1, long arg2, long arg3, long arg4, long arg5, long arg6,
+ long arg7, long arg8, long arg9, long arg10)
+{
+ int localerrno;
+ STATUS result;
+ int priority;
+ int i = LOOPS;
+ int ownID = taskIdSelf();
+
+ /*Waiting to start synchronized with all other spawned tasks*/
+ result = semTake(task_sync_sem, WAIT_FOREVER);
+ if (result == ERROR) {
+ errno_to_messgae(semTake counter);
+ return;
+ }
+ /*Taking the counting semaphore to indicate task started running stall
+ * main from exiting */
+ result = semTake(task_counter_sem, WAIT_FOREVER);
+ if (result == ERROR) {
+ errno_to_messgae(semTake counter);
+ return;
+ }
+ result = taskPriorityGet(ownID, priority);
+
+ xnprintf( Task priority is %d\n, priority);
+ while (i) {
+ xnprintf(Task name is %s tid=%d\n, taskName(ownID), ownID);
+ sleep(1);
+ i--;
+ }
+ /*Signaling this task is done*/
+ semGive(task_counter_sem);
+}
+
+/*
+ * Main task:
+ * spawns TASK_NUM tasks synchronize their operation
+ * exit and clean up when all tasks are done
+ */
+int main(int argc, char **argv)
+{
+ /*array holding all tasks ids*/
+ int tids[TASK_NUM];
+ int i;
+ mlockall(MCL_CURRENT|MCL_FUTURE);
+ /* counting semaphore inital value set to the number of tasks*/
+ task_counter_sem = semCCreate(SEM_Q_PRIORITY, TASK_NUM);
+ if (!task_counter_sem) {
+ xnprintf( Failed to create semaphore\n);
+ exit(1);
+ }
+ /* semaphore to synchronize all task operation */
+ task_sync_sem = semBCreate(SEM_Q_PRIORITY, SEM_EMPTY);
+ if (!task_sync_sem) {
+ xnprintf( Failed to create binary semaphore\n);
+ exit(1);
+ }
+ for (i = 0; i TASK_NUM; i++) {
+ tids[i] = taskSpawn(NULL, (TOP_PRIORITY - i), 0, STACK_SIZE ,
+task_main_routine,0,0,0,0,0,0,0,0,0,0);
+ xnprintf( Spawned task: %d\n, tids[i]);
+ }
+ /* Signaling all tasks to run */
+ semFlush(task_sync_sem);
+ /* Waiting for all task to complete their main routine */
+ for (i = 0; i TASK_NUM; i++)
+ semTake(task_counter_sem, WAIT_FOREVER);
+ /* Cleanup */
+ for (i = 0; i TASK_NUM; i++)
+ taskDelete(tids[i]);
+ semDelete(task_counter_sem);
+ semDelete(task_sync_sem);
+}
+
+
+/*
+ * Prints out the meaning of an error with relation to the failing function
+ *
+ * parameter:
+ * a prefix string to the failure reason
+ */
+static errno_to_messgae(char *failing_func)
+{
+ int localerrno = errnoGet();
+ xnprintf(%s: , failing_func);
+ switch(localerrno){
+ case S_objLib_OBJ_ID_ERROR:
+ xnprintf( Semaphore ID is invalid\n);
+ break;
+ case S_objLib_OBJ_UNAVAILABLE:
+ xnprintf( Semaphore unavailable (NO_WAIT)\n);
+ break;
+ case S_objLib_OBJ_TIMEOUT:
+ xnprintf( Timeout occured before semaphore was
+ released\n);
+ break;
+ case S_semLib_INVALID_OPTION:
+ xnprintf( Semaphore type is invalid\n);
+ break;
+ case EINTR:
+ xnprintf( Received interup\n);
+ break;
+ default:
+ break;
+ }
+}
Index: ksrc/skins/vxworks/demos/Makefile
===
--- ksrc/skins/vxworks/demos/Makefile (revision 2960)
+++
Re: [Xenomai-core] VxWorks skin is missing new VxWorks headers for RTP
I imagined thats the policy. But is it worth investing time in? or is there higher priority task I can be assigned to? 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 -- Ravid Baruch Naali [EMAIL PROTECTED] +972 4 6732729 +972 52 5830021 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
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 signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
