[Xenomai-help] the same error

[Xenomai-help] the same error

[marcellin]

well, I've made some little modifications, now i use the 
"rt_task_shadow()  function", but  from  the  "rt_intr_wait() function"  
the  numerical  error is  "-1".  To answer to Gilles, i use the RTC irq 
because i work on a (slow) acquisition system wich works continuously, 
and don't allow time drifts. The use of xenomai is to have tiny latencies.

the modified test program :

#include <sys/mman.h>
#include <sys/time.h>
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <signal.h>
#include <getopt.h>
#include <time.h>
#include <native/task.h>
#include <native/mutex.h>
#include <native/timer.h>
#include <native/sem.h>
#include <native/intr.h>
#include <native/cond.h>
#include <rtdm/rtbenchmark.h>
#include <linux/rtc.h>
#include <sys/ioctl.h>
//#include <sys/time.h>
//#include <sys/types.h>
#include <fcntl.h>
#include <errno.h>


RT_TASK task;

RT_TASK main_task;


RT_INTR intr_desc;

RT_COND cond;

RT_MUTEX mutextest;

int err,fd,retval,i,irqcount = 0;
unsigned long data;
char err_message[80];
const int TIMER_IRQ = 8;

void mytask(void * cookie)
{
  sleep(1);
  err = rt_cond_signal(&cond);
  if(err != 0){
    printf("\nrt_cond_signal : %i\n",err);
  }
         

}

int main (int argc, char **argv)
{

  mlockall(MCL_CURRENT | MCL_FUTURE);
   
  rt_timer_set_mode(TM_ONESHOT);
 
  err = rt_task_shadow(&main_task,"main_task",11,0); 
  if(err != 0){                                                         
           
    printf("\nrt_task_shadow : %i",err);
  }

  err = rt_cond_create(&cond,"condition");
  if(err != 0){
    printf("\nrt_cond_create : %i",err);
  }
  err = rt_mutex_create(&mutextest,"mut");
  if(err != 0){
    printf("\nrt_mutex_create : %i",err);
  }
 
  err = rt_task_create(&task,"SecondTask",0,99,0);
  if(err != 0){
    printf("\nrt_task_create : %i",err);
  }
  err = rt_task_start(&task,&mytask,NULL);
  if(err != 0){
    printf("\nrt_task_start : %i",err);
  }
 
  err = rt_cond_wait(&cond,&mutextest,20000000);
  if(err != 0){
    printf("\nrt_cond_wait : %i",err);
  }
  printf("\nend \n");
 
  rt_mutex_delete(&mutextest);
  rt_cond_delete(&cond);
  rt_task_delete(&main_task);
  rt_task_delete(&task);

return(0);

}


regards

Marcell1

Re: [Xenomai-help] the same error

[Gilles Chanteperdrix]

marcellin wrote:
 > well, I've made some little modifications, now i use the 
 > "rt_task_shadow()  function", but  from  the  "rt_intr_wait() function"  
 > the  numerical  error is  "-1".  

What does lsmod say, did you compile the native skin as a module, is the
module loaded ?
Did you try the latency program ?

 > To answer to Gilles, i use the RTC irq 
 > because i work on a (slow) acquisition system wich works continuously, 
 > and don't allow time drifts. The use of xenomai is to have tiny latencies.

Then rt_task_set_periodic()/rt_task_wait_period() is probably what
you should be using.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] the same error

[marcellin]

Hi Gilles,
lsmod say nothing because Xenomai is configured in Static with the 
kernel. About rt_task_set_periodic()/rt_task_wait_periode() is there a 
drift with the "second time top" of the RTC IRQ ? because my acquisition 
works the for time stamping of sample electrical values. If after a few 
mounths there is a drift of some seconds, we can't use the samples. If 
the rt_task_set_periodic()/rt_task_wait_periode() are synchronize ( or 
if it's possible ) with the RTC irq, then it's Ok.

regards

Marcell1

Re: [Xenomai-help] the same error

[Gilles Chanteperdrix]

marcellin wrote:
 > About rt_task_set_periodic()/rt_task_wait_periode() is there a 
 > drift with the "second time top" of the RTC IRQ ?

The RTC probably drift less than Xenomai system clock, but according to
an FAQ (http://www.beaglesoft.com/mainfaqclock.htm), the RTC drift is
typically 5 or 6 seconds a day. One way to have your system synchronized
with a precise time source is by using NTP. Unfortunately, Xenomai does
not benefit from using NTP. I guess you may plug a GPS system to the
serial port and get precise timings from there.

The reason why I suggest rt_task_set_periodic()/rt_task_wait_period() is
because they use Xenomai system clock, which compensate a constant part
of the interrupt and scheduling latencies. So, using them should lead to
the small latencies the "latency" test give you.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] the same error-solution

[marcellin]

Hi ,

Now it works fine, in fact there was two mistakes :

-I've forgot to link with librtdm (-lrtsm)

-I've forgot rt_task_shadow() in the main Linux thread

thanks everybody.

Best regards

Marcell1

Re: [Xenomai-help] the same error-solution

[Jeff Webb]

marcellin wrote:
> -I've forgot rt_task_shadow() in the main Linux thread

It would be helpful to add a note to the API docs for rt_task_shadow() explaining this usage.  It would also be good to note that tasks created in this way must also be cleaned up using rt_task_delete().

rt_task_shadow()
-----
Turns the current Linux task into a native Xenomai task.  Creates a real-time task running in the context of the calling regular Linux task in user-space.  For instance, calling rt_task_shadow() from main() will map the program's main thread to a native Xenomai thread, allowing it to invoke blocking real-time services.  Note that all tasks created using rt_task_shadow() must be cleaned up using rt_task_delete().
-----

It would be good to put a note in the rt_task_delete() docs as well.

rt_task_delete()
-----
... A task exists in the system since rt_task_create() ( or possibly rt_task_shadow() ) has been called to create it, so this service must be called in order to destroy it afterwards...
-----

I'm sure these comments are obvious to many folks, but it would help out the newbies.  It is helpful when the documentation explicitly says things like this, so one doesn't have to guess.

Thanks again for putting in the effort to make great API documentation.  I believe it is essential to the widespread adoption of Xenomai, and makes it very attractive to the newcomer.

If you would rather have me submit suggestions like this in patch form, I would be happy to do so.  Just show me an example diff (or 'svn diff'?)  command so I know what command-line options you prefer.

-Jeff

Re: [Xenomai-help] the same error-solution

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2216 bytes --]

Jeff Webb wrote:
> marcellin wrote:
>> -I've forgot rt_task_shadow() in the main Linux thread
> 
> It would be helpful to add a note to the API docs for rt_task_shadow()
> explaining this usage.  It would also be good to note that tasks created
> in this way must also be cleaned up using rt_task_delete().
> 
> rt_task_shadow()
> -----
> Turns the current Linux task into a native Xenomai task.  Creates a
> real-time task running in the context of the calling regular Linux task
> in user-space.  For instance, calling rt_task_shadow() from main() will
> map the program's main thread to a native Xenomai thread, allowing it to
> invoke blocking real-time services.  Note that all tasks created using
> rt_task_shadow() must be cleaned up using rt_task_delete().
> -----

Oops, this need for cleanup likely dates back to my comment It's
actually not that hard. The related kernel resources get released when
the task terminates. But cleanup is (still) mandatory for non-task objects.

> 
> It would be good to put a note in the rt_task_delete() docs as well.
> 
> rt_task_delete()
> -----
> ... A task exists in the system since rt_task_create() ( or possibly
> rt_task_shadow() ) has been called to create it, so this service must be
> called in order to destroy it afterwards...
> -----
> 
> I'm sure these comments are obvious to many folks, but it would help out
> the newbies.  It is helpful when the documentation explicitly says
> things like this, so one doesn't have to guess.
> 
> Thanks again for putting in the effort to make great API documentation. 
> I believe it is essential to the widespread adoption of Xenomai, and
> makes it very attractive to the newcomer.
> 
> If you would rather have me submit suggestions like this in patch form,
> I would be happy to do so.  Just show me an example diff (or 'svn
> diff'?)  command so I know what command-line options you prefer.

Yes, svn diff gives very good output. And yes, a patch is even more
welcome than your already helpful comments. I recently learned again
that RTDM is also still suffering from inherent but undocumented
characteristics, things that are obvious - at least for me. ;)

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] the same error

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2655 bytes --]

marcellin wrote:
> well, I've made some little modifications, now i use the
> "rt_task_shadow()  function", but  from  the  "rt_intr_wait() function" 
> the  numerical  error is  "-1".  To answer to Gilles, i use the RTC irq
> because i work on a (slow) acquisition system wich works continuously,
> and don't allow time drifts. The use of xenomai is to have tiny latencies.
> 
> the modified test program :
> 
> #include <sys/mman.h>
> #include <sys/time.h>
> #include <unistd.h>
> #include <stdlib.h>
> #include <stdio.h>
> #include <string.h>
> #include <signal.h>
> #include <getopt.h>
> #include <time.h>
> #include <native/task.h>
> #include <native/mutex.h>
> #include <native/timer.h>
> #include <native/sem.h>
> #include <native/intr.h>
> #include <native/cond.h>
> #include <rtdm/rtbenchmark.h>
> #include <linux/rtc.h>
> #include <sys/ioctl.h>
> //#include <sys/time.h>
> //#include <sys/types.h>
> #include <fcntl.h>
> #include <errno.h>
> 
> 
> RT_TASK task;
> 
> RT_TASK main_task;
> 
> 
> RT_INTR intr_desc;
> 
> RT_COND cond;
> 
> RT_MUTEX mutextest;
> 
> int err,fd,retval,i,irqcount = 0;
> unsigned long data;
> char err_message[80];
> const int TIMER_IRQ = 8;
> 
> void mytask(void * cookie)
> {
>  sleep(1);
>  err = rt_cond_signal(&cond);
>  if(err != 0){
>    printf("\nrt_cond_signal : %i\n",err);
>  }
>        
> }
> 
> int main (int argc, char **argv)
> {
> 
>  mlockall(MCL_CURRENT | MCL_FUTURE);
>    rt_timer_set_mode(TM_ONESHOT);
> 
>  err = rt_task_shadow(&main_task,"main_task",11,0);  if(err !=
> 0){                                                                     
> printf("\nrt_task_shadow : %i",err);
>  }
> 
>  err = rt_cond_create(&cond,"condition");
>  if(err != 0){
>    printf("\nrt_cond_create : %i",err);
>  }
>  err = rt_mutex_create(&mutextest,"mut");
>  if(err != 0){
>    printf("\nrt_mutex_create : %i",err);
>  }
> 
>  err = rt_task_create(&task,"SecondTask",0,99,0);
>  if(err != 0){
>    printf("\nrt_task_create : %i",err);
>  }
>  err = rt_task_start(&task,&mytask,NULL);
>  if(err != 0){
>    printf("\nrt_task_start : %i",err);
>  }
> 
>  err = rt_cond_wait(&cond,&mutextest,20000000);

This service is very similar to POSIX condition variables: you have to
acquire the mutex before you can wait on the condition.

>  if(err != 0){
>    printf("\nrt_cond_wait : %i",err);
>  }
>  printf("\nend \n");
> 
>  rt_mutex_delete(&mutextest);
>  rt_cond_delete(&cond);
>  rt_task_delete(&main_task);
>  rt_task_delete(&task);
> 
> return(0);
> 
> }
> 
> 
> regards
> 
> Marcell1
> 

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]