Hi All, Hi Jan,
Apologize for my (very) bad english.
I have a doubt about RTDM:
Is it possible open a rtdm device driver with a open() standard syscall
(without rt_dev_open())? I already tried but open() return always -1 :-(
Obviously rt_dev_open() works perfectly.
Thanks you.
Regards,
Alessio
No, my application uses and always has used periodic timing with a tick of
125 us.
Steven
On 2/17/06 10:29 AM, Philippe Gerum [EMAIL PROTECTED] wrote:
Steven Seeger wrote:
Could my problem be caused by me using the latest SVN for xenomai? Should I
try the released version instead?
You
Just to let you know, I tried recompiling everything without periodic
support enabled and I can't even load the xeno_nucleus.ko module. I get an
-ENODEV presumably because my board won't work with the aperiodic timing
mode.
On 2/17/06 7:59 AM, Philippe Gerum [EMAIL PROTECTED] wrote:
Yous seem
thank you for the hint to the vxworks-skin-examples (ksrc/skins/vxworks/demos/)
Unfortunately a new problem occured with these examples :
Executing the Makefile, I get the following Error-Message :
ppc-linux-gcc -o satch satch.c -I. -I~/xenomai-2.1-rc2/_install/include -O2
Hello,
I'm trying Xenomai latest release on kernel 2.4.25 of ppc_devel for
MPC5200.
After patch, I have encountered this error in kernel linking:
/kernel/xenomai/skins/posix/xeno_posix.o(.text+0xed9c): In function
`close':
I have found what seems to cause my problem.
I have two threads, t1 and t2.
t1 has a priority level of 30, and t2 has a priority level of 5. I am using
the native skin, so t1 has the higher priority.
t2 is flashing an LED on my board every 40 ms, and t1 does nothing until I
hit a key on the
Just to let you know, I tried recompiling everything without periodic
support enabled and I can't even load the xeno_nucleus.ko module. I get an
-ENODEV presumably because my board won't work with the aperiodic timing
mode.
On 2/17/06 7:59 AM, Philippe Gerum [EMAIL PROTECTED] wrote:
Yous seem
I have found what seems to cause my problem.
I have two threads, t1 and t2.
t1 has a priority level of 30, and t2 has a priority level of 5. I am using
the native skin, so t1 has the higher priority.
t2 is flashing an LED on my board every 40 ms, and t1 does nothing until I
hit a key on the
In my last email I said that making a system call in a lower priority task
seems to interfere with a higher priority task. I also said that once a
shadow thread makes a system call, it seems to forever lose its determinism.
The higher priority task I mentioned in my last email does indeed make a