I found the source of my fpu issue. A single kernel module with two
tasks was also active. I noticed the failure occurred whenever sound
would play. (This is one of the tasks.) It seems the problem is that the
sound task doesn't use the FPU, so I didn't turn on T_FPU. The tone task
(not in use at that time) does, so it has T_FPU. When I turned on T_FPU
for the sound task, I never saw the problem again. With it off, if I
played sound while running the program, I'd regularly see the
corruption.
Here is the task code:
static void sound_func(void *data)
{
for (;;) //go until suspended or thread deletion
{
if (play==stop) //time to stop if this happens
{
unsigned long evt = 0;
play=stop=0; // just in case
rt_event_clear(&sound_event, SOUND, 0);
rt_task_set_periodic(&sound_task, TM_NOW, TM_INFINITE); /*
disable periodic mode */
rt_event_wait(&sound_event, SOUND, &evt, EV_ALL,
TM_INFINITE);
rt_task_set_periodic(&sound_task, TM_NOW,
rt_timer_ns2ticks(ST_AUDIO_PERIOD));
}
#if BUFSIZE != 65536
if (play==BUFSIZE) play=0;
#endif
if(rt_task_wait_period(0)) rt_task_wait_period(0); //wait for
next tick and ignore overruns (do the best we can)
// Since the index is incrementd subtract 2 from the size before
comparing the index
outb(buf[play++], DAC_ADDRESS); //send the next byte to the dac
}
}
The buffer is filled with a linux userland process and an appropriate
wait queue. This same code worked fine in RTAI without the FPU flag.
I've tested this for several minutes.
Any idea?
Steven
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help