Re: newbie question : xenomai tasks and linux interrupts

On Fri, 2007-09-28 at 09:45 +0200, alberto.tomasi <at> gefran.com wrote:
> 
> Hi everybody
> I'm a xenomai (and linux) newbie and I'm trying to understand what's
> happening on the serial device of my system
> My serial device is controlled by a linux driver and used by a linux
> task
> Often the serial line dialog stops : no enough bytes received or CRC
> errors are the warning indications coming from the linux task
> 
> Problems started when I've introduced an "heavy" xenomai (real time)
> task and seems to have an higher frequency if I use an higher baud
> rate on the serial line
> In this condition the linux driver says that a lot of overrun error
> occurs in the serial device
> 
> My question is : when the xenomai task is running, all the interrupts
> managed by linux are always blocked and delayed until the task has
> finished its job ?
> (I'm almost sure about but finding a confirmation of this in the
> xenomai sources I haven't understood if and where this happen...)
> 
> If the answer is yes, how can I manage the serial device without
> overrun ?
> 
> Is it possible to setup a "special" management (no mask or immediate
> propagation...) on specific interrupts used by linux ?

https://mail.gna.org/public/xenomai-core/2007-09/msg00002.html

Re: [Adeos-main] EBUSY error with rt_intr_create API for timer interrupt

poornima r wrote:
> Hello,
> 
> I am trying to register an handler for the timer
> interrupt with the following call in my init_module()
> (kernel space) for xenomai domain.
> 
> err = 
> rt_intr_create(&intr_desc,"ir-xenomai",TIMER_INTERRUPT,
> &ir_handler,NULL, I_SHARED);

Xenomai questions are better addressed to Xenomai mailing lists. I moved
this thread therefore.

>  
> When I try inseting my module, I get EBUSY error.
> 
> Is there any problem with the interrupt object
> creation mode (I_SHARED)?
> Why is this error when interrupts can be shared
> between 
> Xenomai and Linux?

Generally, sharing IRQs between the RT and the non-RT (Linux) domain is
a very tricky thing that quickly makes your box instable or at least
indeterministic.

Specifically for sharing the timer IRQ, the Xenomai with the help of the
I-pipe patch provides fine APIs so that you don't need to mess with
internals, just have a look at the docs. Because Xenomai already manages

rt usb

Hi,

I was just wondering whether any work was going on for real-time usb?

This would enable the use of PCI adaptors over USB so that PCI-IO cards 
(like the peak-can card) can be used from laptops. CAN over USB is also 
rather valuable.

Is any documentation available which clarifies why usb is a problem and 
how big the problem is (perhaps I can risk it?:) )

regards,

Roland

Re: rt usb

Roland Tollenaar wrote:
> Hi,
> 
> I was just wondering whether any work was going on for real-time usb?
> 
> This would enable the use of PCI adaptors over USB so that PCI-IO cards 
> (like the peak-can card) can be used from laptops. CAN over USB is also 
> rather valuable.

http://developer.berlios.de/projects/usb4rt
https://gna.org/projects/usb20rt

Both projects are generally not directly usable and are currently in a 
dormant state.

> 
> Is any documentation available which clarifies why usb is a problem and 
> how big the problem is (perhaps I can risk it?:) )

No longer at hand (a former student of mine did his diploma thesis about 
usb4rt). Generally, there is no real show-stopper, we "just" need a 
real-time-aware stack that provides appropriate API (e.g. to 
preallocated required resources) and that is bug-free... :)

Jan

--

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: rt usb

Hi Jan,

>> Is any documentation available which clarifies why usb is a problem 
>> and how big the problem is (perhaps I can risk it?:) )
> 
> No longer at hand (a former student of mine did his diploma thesis about 
> usb4rt). 
Pity.

>Generally, there is no real show-stopper, we "just" need a 
> real-time-aware stack that provides appropriate API (e.g. to 

So, if I run CAN over USB from a rt thread there is a chance that even 
though it is not rt-safe, it may not screw up latency?

I realize that this will seem pointless and is technically incorrect but 
  if for example the USB device is not addressed by any other processes, 
what is the chance that I will have problems?

Regards,

Roland

> 
> Jan
> 

Re: rt usb

Roland Tollenaar wrote:
> Hi Jan,
> 
>>> Is any documentation available which clarifies why usb is a problem 
>>> and how big the problem is (perhaps I can risk it?:) )
>>
>> No longer at hand (a former student of mine did his diploma thesis 
>> about usb4rt). 
> Pity.
> 
>> Generally, there is no real show-stopper, we "just" need a 
>> real-time-aware stack that provides appropriate API (e.g. to 
> 
> So, if I run CAN over USB from a rt thread there is a chance that even 
> though it is not rt-safe, it may not screw up latency?
> 
> I realize that this will seem pointless and is technically incorrect but 
>  if for example the USB device is not addressed by any other processes, 
> what is the chance that I will have problems?

The things is just as with RTnet vs. standard Linux networking: You need 
a stack like the mentioned ones to provide rt-safe access to the USB 
hardware. For CAN (e.g. the Peak dongle), you then need a high-level USB 
driver that connects the RT-USB and RT-CAN stacks. But there is no point 
in trying to tunnel your USB requests through the Linux USB stack, I 
case you meant this.

Jan

--

-- 

Re: rt usb

Jan Kiszka wrote:
> Roland Tollenaar wrote:
>> Hi,
>>
>> I was just wondering whether any work was going on for real-time usb?
>>
>> This would enable the use of PCI adaptors over USB so that PCI-IO cards 
>> (like the peak-can card) can be used from laptops. CAN over USB is also 
>> rather valuable.
> 
> http://developer.berlios.de/projects/usb4rt
> https://gna.org/projects/usb20rt
> 
> Both projects are generally not directly usable and are currently in a 
> dormant state.
> 
>> Is any documentation available which clarifies why usb is a problem and 
>> how big the problem is (perhaps I can risk it?:) )
> 
> No longer at hand (a former student of mine did his diploma thesis about 
> usb4rt). Generally, there is no real show-stopper, we "just" need a 
> real-time-aware stack that provides appropriate API (e.g. to 
> preallocated required resources) and that is bug-free... :)
One problem with USB is the inherent 1ms(full speed)/125us(high speed) cycles,
which (AFAICT) prohibits closing a control loop any faster than that. On top of
that at least some USB I/O-cards (somewhat off-topic, since post was about CAN
over USB) tend to pack multiple values into one USB-packet, which leads to
larger delays.

I would investigate Ethernet-CAN gateways, perhaps brew my own using

rt_task crash kernel

/*******************************************************************
 * isrtimer_m.c 
 *******************************************************************/

#include <native/task.h>
#include <native/intr.h>
#include <native/alarm.h>

#define STACK_SIZE         8192        /* Taille de la pile par défaut */
#define MS                 1000000     /* 1 ms exprimé en ns */
#define TIMER_PERIODIC     1           /* 1: timer périodique, 0: timer apériodique */

RT_TASK myTask;
RT_ALARM myAlarm;

int err; /* stockage du code d'erreur */

/* cleanup_module() */
void __exit cleanup_module (void) {

  printk("#irqtimer: cleanup\n");

  rt_task_delete(&myTask);

  printk("Bye bye!\n");
}

/* Tâche périodique */
void periodic(void *cookie) {
   while(1) {
      printk("debut 20ms\n");
      rt_timer_spin(20 * MS);
      printk("fin 20ms\n");
      rt_task_wait_period(NULL);
   }
}

/* init_module() */
int __init init_module (void) {

  printk("#module de test: starting...\n");

  
  /* Timer initialization */
  if (TIMER_PERIODIC)
    err = rt_timer_set_mode(MS);   /* periodic mode, one tick will be equal to 1 ms */ 
  else
    err = rt_timer_set_mode(TM_ONESHOT);

  if (err != 0) {
    printk("Error timer: %d\n", err);
    return -1;
  }

  /*Création de la tache*/
  rt_task_create(&myTask, "taskCharge", STACK_SIZE, 10, 0);
  //rt_task_set_periodic(&myTask,TM_NOW,50*(TIMER_PERIODIC?1:MS));
  rt_task_start(&myTask, periodic, NULL);

  return 0;
}

MODULE_LICENSE("GPL");

_______________________________________________
Xenomai-help mailing list
Xenomai-help <at> gna.org
https://mail.gna.org/listinfo/xenomai-help

Re: rt_task crash kernel

On 10/2/07, Patrick <kpa_info <at> yahoo.fr> wrote:
>
>
>
>
> Hi,
>
>
>
> I'm using Xenomai 2.3.4 with 2.6.20 kernel on an ARM PXA270 board.
>
> The installation was executed successfully.
>
>
>
> Now I'm trying to insert a small test module (source code is attached) but the kernel crashes on rt_task_start().
>
> I have tried the same module on another x86 machine and there is no problem.
>
> I have tried with or without rt_task_set_periodic in aperiodic and periodic timer mode but the result is
the same.
>
>
>
> Do you have an idea?

Do you observe the same behaviour with the latency test ?

--

-- 
                                               Gilles Chanteperdrix

Re: rt_task crash kernel

-----Message d'origine-----
De : Patrick [mailto:kpa_info <at> yahoo.fr] 
Envoyé : mardi, 2. octobre 2007 12:46
À : 'Gilles Chanteperdrix'
Objet : RE: [Xenomai-help] rt_task crash kernel

Yes, I have tried with latency -p 1000 and the issues is the same.

-----Message d'origine-----
De : Gilles Chanteperdrix [mailto:gilles.chanteperdrix <at> gmail.com] 
Envoyé : mardi, 2. octobre 2007 11:46
À : Patrick
Cc : xenomai-core
Objet : Re: [Xenomai-help] rt_task crash kernel

On 10/2/07, Patrick <kpa_info <at> yahoo.fr> wrote:
>
>
>
>
> Yes, I have tried with bin/latency user space application and the system
> crashes.

latency appears to crash on ARM when launched with the default 100us
period, the system is just too busy. Do you observe the crash with a 1
ms period ?

--

-- 
                                               Gilles Chanteperdrix