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
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
Steven Seeger wrote:
Maybe I didn't set it up right? I followed the instructions in the
README.INSTALL file. Attached is my linux tree's .config.
Could you try and configure the timer in aperiodic mode ?
--
Gilles Chanteperdrix.
Steven Seeger wrote:
Which framebuffer support did you select at kernel level?
What is the output of testsuite/latency while using the VT console?
I'm using the gx1fb framebuffer for the geode. However, since this problem
occurs even when the VT outputting the text is not active, I don't
Maybe I didn't set it up right? I followed the instructions in the
README.INSTALL file. Attached is my linux tree's .config.
Steven
Until those numbers are sane, there is no point in trying anything else
though.
Ok, the testsuite clearly fails on your board, and something in the current
Steven Seeger wrote:
Maybe I didn't set it up right? I followed the instructions in the
README.INSTALL file. Attached is my linux tree's .config.
Try enabling the SMI workaround (Xeno's Machine menu), just in case, since you
are running a Geode box.
Steven
Until those numbers are sane,
Hehe I misread that option. I read it as disable SMI and intended for it
to be on. I'll try that. :)
Steven
On 2/17/06 6:28 AM, Philippe Gerum [EMAIL PROTECTED] wrote:
Steven Seeger wrote:
Maybe I didn't set it up right? I followed the instructions in the
README.INSTALL file. Attached is
Turning on the SMI disable stuff, rebuilding the kernel and modules, and
installing everything to my board did not solve the latency problem. My
numbers keep growing as the latency tester runs.
Any other ideas? I've never had an rtai/xenomai/fusion/whatever system fail
basic realtime requirements
Yous seem to be running in periodic timing mode, with a default slice of 125
us.
Which parameters are passed to rt_task_set_periodic() and
rt_task_wait_period() in
your sampling task?
I am confused why this matters? You said the latency test shows my realtime
does not work, so clearly the
Steven Seeger wrote:
Yous seem to be running in periodic timing mode, with a default slice of 125
us.
Which parameters are passed to rt_task_set_periodic() and
rt_task_wait_period() in
your sampling task?
I am confused why this matters? You said the latency test shows my realtime
does not
Steven Seeger wrote:
Which framebuffer support did you select at kernel level?
What is the output of testsuite/latency while using the VT console?
I'm using the gx1fb framebuffer for the geode. However, since this problem
occurs even when the VT outputting the text is not active, I don't
Steven Seeger wrote:
Turning on the SMI disable stuff, rebuilding the kernel and modules, and
installing everything to my board did not solve the latency problem. My
numbers keep growing as the latency tester runs.
Any other ideas? I've never had an rtai/xenomai/fusion/whatever system fail
Steven Seeger wrote:
Yous seem to be running in periodic timing mode, with a default slice of 125
us.
Which parameters are passed to rt_task_set_periodic() and
rt_task_wait_period() in
your sampling task?
I am confused why this matters? You said the latency test shows my realtime
does not
Could my problem be caused by me using the latest SVN for xenomai? Should I
try the released version instead?
Steven
Steven Seeger wrote:
Could my problem be caused by me using the latest SVN for xenomai? Should I
try the released version instead?
You should first try my last suggestion, i.e. disable the forced periodic support
from the configuration. If your application used to rely on the deprecated
I have a xenomai userspace application that does the following:
A thread of priority 90 toggles a bit (outb) to move a stepper motor.
A thread of priority 10 updates the display once a second.
The motor thread is periodic and uses rt_task_wait_period(). The display
thread just uses sleep(1).
Steven Seeger wrote:
I have a xenomai userspace application that does the following:
A thread of priority 90 toggles a bit (outb) to move a stepper motor.
A thread of priority 10 updates the display once a second.
The motor thread is periodic and uses rt_task_wait_period(). The display
Jan Kiszka wrote:
Steven Seeger wrote:
I have a xenomai userspace application that does the following:
A thread of priority 90 toggles a bit (outb) to move a stepper motor.
A thread of priority 10 updates the display once a second.
The motor thread is periodic and uses
19 matches
Mail list logo
