[Xenomai-help] xnpod help

[Xenomai-help] xnpod help

[Brandt Erickson]

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

Hey,
I'm trying to write a simple looping module to test out xenomai nucleus
usage.  The problem is, when I insert the module (code attached), only the
printks from the initialization function ever get displayed and none from
the indefinite loop.  All the pod startup functions return success, so is
the thread working and just not successfully sending the messages out or
is the thread not starting up at all?  Could someone tell me if I'm using
the xenomai nucleus correctly?  Thanks.
-Brandt

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: runloop.c --]
[-- Type: text/x-csrc; name="runloop.c", Size: 2865 bytes --]


////// Standard C/C++ headers //////
#include <linux/module.h>       
#include <linux/kernel.h>       


////// Xenomai (real-time) headers //////
#include <nucleus/xenomai.h>


////// Self-Header //////
#include "runloop.h"  //Right now an empty header


////// Global Variables for this Module //////
xnthread_t thread;


////// Loop Function Declaration //////
void runloop_fcn(int arg);


////// Module Initialization //////
int init_module(void) {


  /*
  int xnpod_init_thread(xnthread_t *thread,
			const char *name,
			int prio,
			xnflags_t flags,
			unsigned stacksize);
  */

  printk("Thread Initialization ...\n");
  switch (xnpod_init_thread(&thread, "Control Thread", 0, XNFPU, 0)) {
  case EINVAL:
  case -EINVAL:
    printk("EINVAL\n");
    break;
  case ENOMEM:
  case -ENOMEM:
    printk("ENOMEM\n");
    break;
  case 0:
    printk("Success.\n");
    break;
  default:
    printk("Unknown error.\n");
  }


  /*
  int xnpod_start_thread(xnthread_t *thread,
			 xnflags_t mode,
			 int imask,
			 xnarch_cpumask_t affinity,
			 void(*)(void *cookie) entry,
			 void * cookie);
  */
  printk("Starting Thread ...\n");
  switch (xnpod_start_thread(&thread, 0, 1, XNPOD_ALL_CPUS,
			     runloop_fcn, NULL)) {
  case EBUSY:
  case -EBUSY:
    printk("EBUSY\n");
    break;
  case EINVAL:
  case -EINVAL:
    printk("EINVAL\n");
    break;
  case 0:
    printk("Success.\n");
    break;
  default:
    printk("Unknown error.\n");
  }


  /*
  int xnpod_start_timer(u_long nstick,
			xnisr_t tickhandler);
  */

  
  printk("Starting Timer ...\n");
  switch (xnpod_start_timer(1, XNPOD_DEFAULT_TICKHANDLER)) {
  case EBUSY:
  case -EBUSY:
    printk("EBUSY\n");
    break;
  case EINVAL:
  case -EINVAL:
    printk("EINVAL\n");
    break;
  case ENODEV:
  case -ENODEV:
    printk("ENODEV\n");
    break;
  case ENOSYS:
  case -ENOSYS:
    printk("ENOSYS\n");
    break;
  case 0:
    printk("Success.\n");
    break;
  default:
    printk("Unknown error.\n");
  }
  



  /*
  int xnpod_set_thread_periodic(xnthread_t *thread,
				xnticks_t idate,
				xnticks_t period);
  */

  
  printk("Setting periodic behavior  ...\n");
  switch (xnpod_set_thread_periodic(&thread, xnpod_get_time() + 1000000, 
				    1000000)) {
  case ETIMEDOUT:
  case -ETIMEDOUT:
    printk("ETIMEOUT\n");
    break;
    
  case EWOULDBLOCK:
  case -EWOULDBLOCK:
    printk("EWOULDBLOCK\n");
    break;

  case 0:
    printk("Success.\n");
    break;
  default:
    printk("Unknown error.\n");
  }

  xnpod_unblock_thread(&thread);

  return 0;
}


////// Module Cleanup //////
void cleanup_module(void) {
  xnpod_stop_timer();
  xnpod_delete_thread(&thread);
}



////// Realtime Loop Function //////
void runloop_fcn(int arg) {
  printk("Loop Thread Started.\n");
  while (1) {
    xnpod_wait_thread_period(NULL);
    printk("Timer: %d\n", (int)xnpod_get_time());
  }
}

Re: [Xenomai-help] xnpod help

[Jan Kiszka]

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

Brandt Erickson wrote:
> Hey,
> I'm trying to write a simple looping module to test out xenomai nucleus
> usage.  The problem is, when I insert the module (code attached), only the
> printks from the initialization function ever get displayed and none from
> the indefinite loop.  All the pod startup functions return success, so is
> the thread working and just not successfully sending the messages out or
> is the thread not starting up at all?  Could someone tell me if I'm using
> the xenomai nucleus correctly?  Thanks.

Have a look at other skins and their prologue/epilogue. RTDM is a fairly
simple skin e.g.

This is lacking in your case for init and may explain your problems
(unless some skin is already attached - but it's still required for
consistency):

#if defined(__KERNEL__) && defined(CONFIG_XENO_OPT_PERVASIVE)
    /* The RTDM skin is stacked over the Xenomai pod. */
    err = xncore_attach();
#else /* !(__KERNEL__ && CONFIG_XENO_OPT_PERVASIVE) */
    /* The RTDM skin is standalone. */
    err = xnpod_init(&__rtdm_pod, XNCORE_LOW_PRIO, XNCORE_HIGH_PRIO,
XNREUSE);
#endif /* __KERNEL__ && CONFIG_XENO_OPT_PERVASIVE */

Jan


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

Re: [Xenomai-help] xnpod help

[Gilles Chanteperdrix]

Brandt Erickson wrote:
 > Hey,
 > I'm trying to write a simple looping module to test out xenomai nucleus
 > usage.  The problem is, when I insert the module (code attached), only the
 > printks from the initialization function ever get displayed and none from
 > the indefinite loop.  All the pod startup functions return success, so is
 > the thread working and just not successfully sending the messages out or
 > is the thread not starting up at all?  Could someone tell me if I'm using
 > the xenomai nucleus correctly?  Thanks.
 > -Brandt

If you seriously intend to write a skin, you should have a look at the
simulator, it will allow you to run your skin in a debugger and to get
reproducible behaviours.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] xnpod help

[Jan Kiszka]

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

Gilles Chanteperdrix wrote:
> Brandt Erickson wrote:
>  > Hey,
>  > I'm trying to write a simple looping module to test out xenomai nucleus
>  > usage.  The problem is, when I insert the module (code attached), only the
>  > printks from the initialization function ever get displayed and none from
>  > the indefinite loop.  All the pod startup functions return success, so is
>  > the thread working and just not successfully sending the messages out or
>  > is the thread not starting up at all?  Could someone tell me if I'm using
>  > the xenomai nucleus correctly?  Thanks.
>  > -Brandt
> 
> If you seriously intend to write a skin, you should have a look at the
> simulator, it will allow you to run your skin in a debugger and to get
> reproducible behaviours.
> 

...or an emulator. I'm using Qemu attached to ddd for such elementary
kernel development now.

The simulator is good to reproduce weird timing scenarios. The emulator
is a bit closer to the real application environment, specifically if you
plan to write a syscall interface for your skin. And Qemu can even
generate multiple CPUs. The last SMP bug of Ipipe, e.g., was also
"emulatable" (but was debugged on real hardware with kgdb first).

Jan


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

Re: [Xenomai-help] xnpod help

[Brandt Erickson]

I think there's a little bit of a misunderstanding.  I'm not trying to
write my own skin.  I'm new to xenomai and I'm just trying write a simple
kernel module that starts a periodic realtime thread.  Write now I'm just
trying to have it write a simple message to printk but eventually I'm
going to want it to write to a DAC to control a servo.  I've been browsing
the xenomai API linked off the main website and I thought that using the
nuclues was the prefered method for doing this but I get the feeling now
that is not the case.  My ultimate goal is to have a realtime kernel-space
thread that acts as a pid-controller that communicates and synchronizes
with a non-realtime user-space application that displays pertinent
information to the user.  How would you recommend going about doing that? 
Thanks.
-Brandt

Re: [Xenomai-help] xnpod help

[Jan Kiszka]

Brandt Erickson wrote:
> I think there's a little bit of a misunderstanding.  I'm not trying to
> write my own skin.  I'm new to xenomai and I'm just trying write a simple
> kernel module that starts a periodic realtime thread. 

Ok, things get clearer. But why a kernel module? Are you *that* short on
CPU cycles? The overhead is rather low, see "latency -t0
-p<your-period>" vs. "latency -t1 -p<your-period>" on your box for a
comparison.

> Write now I'm just
> trying to have it write a simple message to printk but eventually I'm
> going to want it to write to a DAC to control a servo.  I've been browsing
> the xenomai API linked off the main website and I thought that using the
> nuclues was the prefered method for doing this but I get the feeling now
> that is not the case.  My ultimate goal is to have a realtime kernel-space
> thread that acts as a pid-controller that communicates and synchronizes
> with a non-realtime user-space application that displays pertinent
> information to the user.  How would you recommend going about doing that? 

In any case, do not use the nucleus directly. Its feasible, for sure,
but rather unhandy for application development. Take a look at the
native or the posix API instead.

Again, consider carefully if the inconvenience to go to kernel space is
really required. You will understand what I mean when you start thinking
about how to communicate between the RT and the Linux tasks.

Here is a simple native example which can easily be extended with
pthreads for non-RT jobs, or use main() directly:

#include <signal.h>
#include <sys/mman.h>
#include <native/task.h>

void demo(void *arg)
{
    rt_task_set_periodic(NULL, TM_NOW, 200000);
    while (1) {
        rt_task_wait_period(NULL);
        /* real-time jobs */
    }
}

void catch_signal(int sig) { }

int main(int argc, char* argv[])
{
    RT_TASK demo_task;

    signal(SIGINT, catch_signal);
    mlockall(MCL_CURRENT|MCL_FUTURE);
    rt_task_create(&demo_task, "mydemo", 0, 99, 0);
    rt_task_start(&demo_task, &demo, NULL);
    pause();
    rt_task_delete(&demo_task);
    return 0;
}

Jan

Re: [Xenomai-help] xnpod help

[Brandt Erickson]

> Ok, things get clearer. But why a kernel module? Are you *that* short on
> CPU cycles?

The reason why I'm trying to develop a kernel-space application is not for
latency issues but because I need to be in kernel-space to read/write
to/from my DAC.  Is the IPC between kernel-space realtime and user-space
non-realtime that much more difficult the user-space realtime to
user-space non-realtime?  I've familiar with regular user-space IPC using
condition variables, semaphores, and shared memory, so if it's fairly
similar, I'm hoping that won't be a problem.
-Brandt

Re: [Xenomai-help] xnpod help

[Jan Kiszka]

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

Brandt Erickson wrote:
>> Ok, things get clearer. But why a kernel module? Are you *that* short on
>> CPU cycles?
> 
> The reason why I'm trying to develop a kernel-space application is not for
> latency issues but because I need to be in kernel-space to read/write
> to/from my DAC.

ioperm() or iopl() not applicable?

> Is the IPC between kernel-space realtime and user-space
> non-realtime that much more difficult the user-space realtime to
> user-space non-realtime?  I've familiar with regular user-space IPC using
> condition variables, semaphores, and shared memory, so if it's fairly
> similar, I'm hoping that won't be a problem.

That's feasible as well, and the API is identical. It's just the
difference of writing two separate applications instead of a single
multi-threaded one plus the additional effort for dealing with modules
(building, loading, unloading).

Jan


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

Re: [Xenomai-help] xnpod help

[Brandt Erickson]

> ioperm() or iopl() not applicable?

I'm not sure.  I'm using a Sensoray S626 card (PCI).  The driver I have is
something I pieced together from psuedo-working code I got from someone
else, so I'm not entirely sure how it works (or if it's even rt-safe).
-Brandt

Re: [Xenomai-help] xnpod help

[Jan Kiszka]

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

Brandt Erickson wrote:
>> ioperm() or iopl() not applicable?
> 
> I'm not sure.  I'm using a Sensoray S626 card (PCI).  The driver I have is
> something I pieced together from psuedo-working code I got from someone
> else, so I'm not entirely sure how it works (or if it's even rt-safe).
> -Brandt
> 

Sounds like very good preconditions to create a deterministic
time-critical system. :)

I just had a short look at their linux driver [1] (if this is what you
are referring to): in fact, terrible code. That there is no locking
makes it highly suspicious. And the way kernel 2.4 compat code is
handled is very ugly as well.

But the driver core is fortunately not that large (in contrast to the
user lib - bah!), so you may try to grab the essentials from it.
Converting that API to RTDM would be straightforward (given that there
are no design faults in that code).

I wonder if there is already comedi support for this device. Alexis, do
you know this? That would likely be a better driver model, because it's
generic.

Jan


[1] http://www.sensoray.com/html/626data.htm


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

Re: [Xenomai-help] xnpod help

[Gilles Chanteperdrix]

Brandt Erickson wrote:
 > > Ok, things get clearer. But why a kernel module? Are you *that* short on
 > > CPU cycles?
 > 
 > The reason why I'm trying to develop a kernel-space application is not for
 > latency issues but because I need to be in kernel-space to read/write
 > to/from my DAC.

There are several way you can write an application with Xenomai:
- first, the canonical way, split your application between driver code
  and application code, implement the driver in kernel-space and the
  application in user-space. Xenomai ease your work by providing the
  RTDM skin for writing drivers in kernel-space, and user-space skins
  (posix, native, vxworks, etc...) for writing applications in
  user-space. For a good portability, I would suggest to use the posix
  skin in user-space.

- second, the rapid way, good for prototyping, do it all in
  user-space. You may use iopl or ioperm to allow your application to
  access I/O regions, and libpci and mmaping /dev/mem to access PCI
  devices from user-space. Xenomai will ease your work here by allowing
  you to run your whole application in gdb, and skins generally provide
  functions to implement IRQ servers in user-space. See for example
  pthread_intr_wait_np.

- a third way, maybe useful as an intermediate between the first
  two. Split your code between kernel-space and user-space, but use
  the same skin in user-space and kernel-space. Xenomai ease your
  work here because skin interfaces are written to be very similar in
  kernel-space and user-space, and IPCs may generally be used to
  communicate between the two address spaces.

 >  Is the IPC between kernel-space realtime and user-space
 > non-realtime that much more difficult the user-space realtime to
 > user-space non-realtime?  I've familiar with regular user-space IPC using
 > condition variables, semaphores, and shared memory, so if it's fairly
 > similar, I'm hoping that won't be a problem.
 > -Brandt

The only IPC existing to communicate between real-time (whether
user-space or kernel-space) and non-realtime user-space threads is the
native skin message pipes: 
http://www.xenomai.org/documentation/trunk/html/api/group__pipe.html

By contrast all other IPC implemented by all skins are accessible to
real-time threads running in secondary mode: they will simply switch to
primary mode the time they use blocking services. So, it is probably a
better idea to create your non-realtime threads as real-time threads and
let them switch to secondary mode when they use non-realtime services.

-- 


					    Gilles Chanteperdrix.