Re: [Xenomai-core] Problems generating vxworks/koan in two step: cc and link

2006-01-19 Thread Gilles Chanteperdrix
Niklaus Giger wrote:
 > ld -o koan  -L/usr/xenomai/lib -luvm -lnucleus -lpthread -lvxworks -lnative  
 > -e __xeno_skin_init  /home/hcu/project/bb/3_1_x/work/xeno/koan.o
 > Now I get the following error output
 > ld: warning: cannot find entry symbol __xeno_skin_init; defaulting to 
 > 12a0
 > /home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function `TaskTest':koan.c:
 > (.text+0xbc): undefined reference to `semTake'
 > /home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function `CreateTask':koan.c:
 > (.text+0x124): undefined reference to `taskSpawn'
 > /home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function `usrClock':koan.c:
 > (.text+0x1c8): undefined reference to `semGive'
 > :koan.c:(.text+0x1f0): undefined reference to `tickAnnounce'
 > /home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function 
 > `koan_sysClkInit':koan.c:(.text+0x224): undefined reference to `semBCreate'
 > :koan.c:(.text+0x23c): undefined reference to `sysClkConnect'
 > :koan.c:(.text+0x240): undefined reference to `sysClkEnable'
 > /home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function 
 > `__xeno_user_exit':koan.c:(.text+0x2c0): undefined reference to `taskDelete'
 > 
 > What is wrong with my split?

What happens if you try :

cc -u __xeno_skin_init -o koan -L/usr/xenomai/lib -luvm -lnucleus -lpthread 
-lvxworks -lnative /home/hcu/project/bb/3_1_x/work/xeno/koan.o

-u seems to be a link-time option.

-- 


Gilles Chanteperdrix.



[Xenomai-core] Problems generating vxworks/koan in two step: cc and link

2006-01-19 Thread Niklaus Giger
Hi

I am trying to bring my build infrastructure up to Xenomai 2.1 and got the 
following problem:
I have no problems to generate koan using the following command:
  cc  -o koan2  /home/hcu/kernel/tst_xeno_ppc/koan.c  -I. \ 
-I/usr/xenomai/include -O2 -D_GNU_SOURCE -D_REENTRANT -D__XENO__ -Wall \
-pipe -D__XENO_UVM__  -u__xeno_skin_init -L/usr/xenomai/lib -luvm -lnucleus \ 
-lpthread -lvxworks -lnative

No in order to be able to compile and link bigger applications my first try 
was to compile koan first and then to link. However running the following two 
commands

c   -c -I. -I/usr/xenomai/include -O2 -D_GNU_SOURCE -D_REENTRANT -D__XENO__ 
-Wall -pipe -D__XENO_UVM__ -u__xeno_skin_init
-I. /home/hcu/project/bb/3_1_x/work/xeno/koan.c  
-o /home/hcu/project/bb/3_1_x/work/xeno/koan.o
ld -o koan  -L/usr/xenomai/lib -luvm -lnucleus -lpthread -lvxworks -lnative  
-e __xeno_skin_init  /home/hcu/project/bb/3_1_x/work/xeno/koan.o
Now I get the following error output
ld: warning: cannot find entry symbol __xeno_skin_init; defaulting to 
12a0
/home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function `TaskTest':koan.c:
(.text+0xbc): undefined reference to `semTake'
/home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function `CreateTask':koan.c:
(.text+0x124): undefined reference to `taskSpawn'
/home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function `usrClock':koan.c:
(.text+0x1c8): undefined reference to `semGive'
:koan.c:(.text+0x1f0): undefined reference to `tickAnnounce'
/home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function 
`koan_sysClkInit':koan.c:(.text+0x224): undefined reference to `semBCreate'
:koan.c:(.text+0x23c): undefined reference to `sysClkConnect'
:koan.c:(.text+0x240): undefined reference to `sysClkEnable'
/home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function 
`__xeno_user_exit':koan.c:(.text+0x2c0): undefined reference to `taskDelete'

What is wrong with my split?

-- 
Niklaus Giger



Re: [Xenomai-core] Initialization of a nucleus pod

2006-01-19 Thread Germain Olivier
Thank you for your response

So rootcb isn't the "scheduler task".
I was thinking it was this task which was determining what thread to run,
depending of its parameters (priority, periodicity, scheduling mode).

I go back to the code to understand how it work ...

Germain

>
> xnthread_init does part of the initialization. The low level part of
> rootcb (its xnarchtcb_t member) is initialized twice, first by the call
> to xnarch_init_tcb in xnthread_init, and then overriden by
> xnarch_init_root_tcb in xnpod_init.
>
> For any other thread than root, the thread would be given a stack and
> entry point by the call to xnarch_init_thread in xnpod_start_thread. But
> the root thread is Xenomai idle task, a placeholder for whatever task
> Linux is currenty running. At the time where xnpod_init is called, the
> root thread is the current context, so already has a stack and is
> already running.
>
> --
>
>
>   Gilles Chanteperdrix.
>




Re: [Xenomai-core] Missing IRQ end function on PowerPC

2006-01-19 Thread Wolfgang Grandegger

Gilles Chanteperdrix wrote:

Wolfgang Grandegger wrote:
 > Therefore we need a dedicated function to re-enable interrupts in the 
 > ISR. We could name it *_end_irq, but maybe *_enable_isr_irq is more 
 > obvious. On non-PPC archs it would translate to *_irq_enable. I 
 > realized, that *_irq_enable is used in various place/skins and therefore 
 > I have not yet provided a patch.


The function xnarch_irq_enable seems to be called in only two functions,
xintr_enable and xnintr_irq_handler when the flag XN_ISR_ENABLE is set.


But the user may want to re-enable the interrupt without using 
XN_ISR_ENABLE as well.



In any case, since I am not sure if this has to be done at the Adeos
level or in Xenomai, we will wait for Philippe to come back and decide.


In both, I guess. OK and thanks.

Wolfgang.





Re: [Xenomai-core] Missing IRQ end function on PowerPC

2006-01-19 Thread Gilles Chanteperdrix
Wolfgang Grandegger wrote:
 > Therefore we need a dedicated function to re-enable interrupts in the 
 > ISR. We could name it *_end_irq, but maybe *_enable_isr_irq is more 
 > obvious. On non-PPC archs it would translate to *_irq_enable. I 
 > realized, that *_irq_enable is used in various place/skins and therefore 
 > I have not yet provided a patch.

The function xnarch_irq_enable seems to be called in only two functions,
xintr_enable and xnintr_irq_handler when the flag XN_ISR_ENABLE is set.

In any case, since I am not sure if this has to be done at the Adeos
level or in Xenomai, we will wait for Philippe to come back and decide.

-- 


Gilles Chanteperdrix.



Re: [Xenomai-core] Problems generating vxworks/koan in two step: cc and link

2006-01-19 Thread Gilles Chanteperdrix
Niklaus Giger wrote:
 > ld -o koan  -L/usr/xenomai/lib -luvm -lnucleus -lpthread -lvxworks -lnative  
 > -e __xeno_skin_init  /home/hcu/project/bb/3_1_x/work/xeno/koan.o
 > Now I get the following error output
 > ld: warning: cannot find entry symbol __xeno_skin_init; defaulting to 
 > 12a0
 > /home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function `TaskTest':koan.c:
 > (.text+0xbc): undefined reference to `semTake'
 > /home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function `CreateTask':koan.c:
 > (.text+0x124): undefined reference to `taskSpawn'
 > /home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function `usrClock':koan.c:
 > (.text+0x1c8): undefined reference to `semGive'
 > :koan.c:(.text+0x1f0): undefined reference to `tickAnnounce'
 > /home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function 
 > `koan_sysClkInit':koan.c:(.text+0x224): undefined reference to `semBCreate'
 > :koan.c:(.text+0x23c): undefined reference to `sysClkConnect'
 > :koan.c:(.text+0x240): undefined reference to `sysClkEnable'
 > /home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function 
 > `__xeno_user_exit':koan.c:(.text+0x2c0): undefined reference to `taskDelete'
 > 
 > What is wrong with my split?

What happens if you try :

cc -u __xeno_skin_init -o koan -L/usr/xenomai/lib -luvm -lnucleus -lpthread 
-lvxworks -lnative /home/hcu/project/bb/3_1_x/work/xeno/koan.o

-u seems to be a link-time option.

-- 


Gilles Chanteperdrix.

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] Missing IRQ end function on PowerPC

2006-01-19 Thread Wolfgang Grandegger

Gilles Chanteperdrix wrote:

Wolfgang Grandegger wrote:
 > Hello,
 > 
 > with RTnet over Xenomai and Linux 2.4 on PowerPC I realized that Xenomai 
 > does not distinguish between a normal IRQ enable and an IRQ unmask at 
 > the end of an ISR (to reenable the IRQ). In the latter case the IRQ 
 > should be enabled on PowerPC as shown:
 > 
 > if (rthal_irq_descp(irq)->handler->end != NULL)

 >  rthal_irq_descp(irq)->handler->end(irq);
 >  else
 >  rthal_irq_descp(irq)->handler->enable(irq);
 > 
 > To handle this case properly, we need to different functions, I think.


I am not sure I understand what you mean. Would you want functions
rthal_end_irq and xnarch_end_irq added and that this xnarch_end_irq
would be called in xnintr_irq_handler when XN_ISR_ENABLE is set ?


Yes, that's what I have basically done to get the RTnet SCC enet driver 
working on my MPC8xx module. In arch/ppc/kernel/irq.c you can see how 
Linux re-enables interrupts at the end of it's ISR (see

http://cvs.gna.org/cvsweb/linux/v2.4/2.4.25-ppc/arch/ppc/kernel/irq.c?rev=1.1;cvsroot=adeos):

  507:   * The ->end() handler has to deal with interrupts which got
  508:   * disabled while the handler was running.
  509:   */
  510:  if (desc->handler) {
  511:  if (desc->handler->end)
  512:  desc->handler->end(irq);
  513:  else if (desc->handler->enable)
  514:  desc->handler->enable(irq);

In PPC Linux 2.6 things are a bit different. The "end" functions seems 
to be mandatory now (I have to check more carefully).


Therefore we need a dedicated function to re-enable interrupts in the 
ISR. We could name it *_end_irq, but maybe *_enable_isr_irq is more 
obvious. On non-PPC archs it would translate to *_irq_enable. I 
realized, that *_irq_enable is used in various place/skins and therefore 
I have not yet provided a patch.


Wolfgang.





Re: [Xenomai-core] Initialization of a nucleus pod

2006-01-19 Thread Gilles Chanteperdrix
Germain Olivier wrote:
 > Hello
 > 
 > I am trying to understand how a pod is initialized.
 > 
 > I think it start with xncore_attach() from core.c, then with xnpod_init from
 > pod.c
 > But here (in xnpod_init) there is something not clear about the root thread
 > creation.
 > 
 > It use xnthread_init(&sched->rootcb, ...), but I don't see where
 > &sched->rootcb is initialized

xnthread_init does part of the initialization. The low level part of
rootcb (its xnarchtcb_t member) is initialized twice, first by the call
to xnarch_init_tcb in xnthread_init, and then overriden by
xnarch_init_root_tcb in xnpod_init.

For any other thread than root, the thread would be given a stack and
entry point by the call to xnarch_init_thread in xnpod_start_thread. But
the root thread is Xenomai idle task, a placeholder for whatever task
Linux is currenty running. At the time where xnpod_init is called, the
root thread is the current context, so already has a stack and is
already running.

-- 


Gilles Chanteperdrix.



Re: [Xenomai-core] Missing IRQ end function on PowerPC

2006-01-19 Thread Gilles Chanteperdrix
Wolfgang Grandegger wrote:
 > Hello,
 > 
 > with RTnet over Xenomai and Linux 2.4 on PowerPC I realized that Xenomai 
 > does not distinguish between a normal IRQ enable and an IRQ unmask at 
 > the end of an ISR (to reenable the IRQ). In the latter case the IRQ 
 > should be enabled on PowerPC as shown:
 > 
 > if (rthal_irq_descp(irq)->handler->end != NULL)
 > rthal_irq_descp(irq)->handler->end(irq);
 >  else
 > rthal_irq_descp(irq)->handler->enable(irq);
 > 
 > To handle this case properly, we need to different functions, I think.

I am not sure I understand what you mean. Would you want functions
rthal_end_irq and xnarch_end_irq added and that this xnarch_end_irq
would be called in xnintr_irq_handler when XN_ISR_ENABLE is set ?

-- 


Gilles Chanteperdrix.



[Xenomai-core] Problems generating vxworks/koan in two step: cc and link

2006-01-19 Thread Niklaus Giger
Hi

I am trying to bring my build infrastructure up to Xenomai 2.1 and got the 
following problem:
I have no problems to generate koan using the following command:
  cc  -o koan2  /home/hcu/kernel/tst_xeno_ppc/koan.c  -I. \ 
-I/usr/xenomai/include -O2 -D_GNU_SOURCE -D_REENTRANT -D__XENO__ -Wall \
-pipe -D__XENO_UVM__  -u__xeno_skin_init -L/usr/xenomai/lib -luvm -lnucleus \ 
-lpthread -lvxworks -lnative

No in order to be able to compile and link bigger applications my first try 
was to compile koan first and then to link. However running the following two 
commands

c   -c -I. -I/usr/xenomai/include -O2 -D_GNU_SOURCE -D_REENTRANT -D__XENO__ 
-Wall -pipe -D__XENO_UVM__ -u__xeno_skin_init
-I. /home/hcu/project/bb/3_1_x/work/xeno/koan.c  
-o /home/hcu/project/bb/3_1_x/work/xeno/koan.o
ld -o koan  -L/usr/xenomai/lib -luvm -lnucleus -lpthread -lvxworks -lnative  
-e __xeno_skin_init  /home/hcu/project/bb/3_1_x/work/xeno/koan.o
Now I get the following error output
ld: warning: cannot find entry symbol __xeno_skin_init; defaulting to 
12a0
/home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function `TaskTest':koan.c:
(.text+0xbc): undefined reference to `semTake'
/home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function `CreateTask':koan.c:
(.text+0x124): undefined reference to `taskSpawn'
/home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function `usrClock':koan.c:
(.text+0x1c8): undefined reference to `semGive'
:koan.c:(.text+0x1f0): undefined reference to `tickAnnounce'
/home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function 
`koan_sysClkInit':koan.c:(.text+0x224): undefined reference to `semBCreate'
:koan.c:(.text+0x23c): undefined reference to `sysClkConnect'
:koan.c:(.text+0x240): undefined reference to `sysClkEnable'
/home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function 
`__xeno_user_exit':koan.c:(.text+0x2c0): undefined reference to `taskDelete'

What is wrong with my split?

-- 
Niklaus Giger

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] RTAI vs XENOMAI

2006-01-19 Thread Gilles Chanteperdrix
Doyle, Alan \(Siemens\) wrote:
 > Hi,
 > 
 > I'm looking into porting an embedded application using Accelerated
 > Technologies 'Nucleus' RTOS to a real time Linux variant. RTAI is the
 > preferred approach but on looking into available documentation I have
 > discovered Xenomai which seems to be designed to solve this sort of
 > problem. However as there is no existing emulator for Nucleus on Xenomai
 > I would have to write one so I'm unsure whether there would then be any
 > benefit. Could somebody advise me as to the pros and cons of porting to
 > RTAI or Xenomai.

Using Xenomai would ease writing a skin for the nucleus RTOS. Philippe
once wrote a mail on how to write a new skin, which you will find on
rtai.dk: 

http://rtai.dk/cgi-bin/gratiswiki.pl?How_To_Implement_A_New_Skin

The reasons why the Xenomai project, was made a separate project from
RTAI is explained in the following post on RTAI mailing list :

https://mail.rtai.org/pipermail/rtai/2005-October/013155.html

-- 


Gilles Chanteperdrix.



Re: [Xenomai-core] Scheduling while atomic

2006-01-19 Thread Jeroen Van den Keybus
Turned off:
  o  nucleus debugging
  o  ipipe stats
  o  ipipe tracing
  o  ishield
 
The problem persists. Also tried three tasks, with same result. With one task, there is no problem.
 
 
Jeroen.


Re: [Xenomai-core] Initialization of a nucleus pod

2006-01-19 Thread Germain Olivier
Thank you for your response

So rootcb isn't the "scheduler task".
I was thinking it was this task which was determining what thread to run,
depending of its parameters (priority, periodicity, scheduling mode).

I go back to the code to understand how it work ...

Germain

>
> xnthread_init does part of the initialization. The low level part of
> rootcb (its xnarchtcb_t member) is initialized twice, first by the call
> to xnarch_init_tcb in xnthread_init, and then overriden by
> xnarch_init_root_tcb in xnpod_init.
>
> For any other thread than root, the thread would be given a stack and
> entry point by the call to xnarch_init_thread in xnpod_start_thread. But
> the root thread is Xenomai idle task, a placeholder for whatever task
> Linux is currenty running. At the time where xnpod_init is called, the
> root thread is the current context, so already has a stack and is
> already running.
>
> --
>
>
>   Gilles Chanteperdrix.
>


___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] Missing IRQ end function on PowerPC

2006-01-19 Thread Wolfgang Grandegger

Gilles Chanteperdrix wrote:

Wolfgang Grandegger wrote:
 > Therefore we need a dedicated function to re-enable interrupts in the 
 > ISR. We could name it *_end_irq, but maybe *_enable_isr_irq is more 
 > obvious. On non-PPC archs it would translate to *_irq_enable. I 
 > realized, that *_irq_enable is used in various place/skins and therefore 
 > I have not yet provided a patch.


The function xnarch_irq_enable seems to be called in only two functions,
xintr_enable and xnintr_irq_handler when the flag XN_ISR_ENABLE is set.


But the user may want to re-enable the interrupt without using 
XN_ISR_ENABLE as well.



In any case, since I am not sure if this has to be done at the Adeos
level or in Xenomai, we will wait for Philippe to come back and decide.


In both, I guess. OK and thanks.

Wolfgang.



___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] Missing IRQ end function on PowerPC

2006-01-19 Thread Gilles Chanteperdrix
Wolfgang Grandegger wrote:
 > Therefore we need a dedicated function to re-enable interrupts in the 
 > ISR. We could name it *_end_irq, but maybe *_enable_isr_irq is more 
 > obvious. On non-PPC archs it would translate to *_irq_enable. I 
 > realized, that *_irq_enable is used in various place/skins and therefore 
 > I have not yet provided a patch.

The function xnarch_irq_enable seems to be called in only two functions,
xintr_enable and xnintr_irq_handler when the flag XN_ISR_ENABLE is set.

In any case, since I am not sure if this has to be done at the Adeos
level or in Xenomai, we will wait for Philippe to come back and decide.

-- 


Gilles Chanteperdrix.

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] Missing IRQ end function on PowerPC

2006-01-19 Thread Wolfgang Grandegger

Gilles Chanteperdrix wrote:

Wolfgang Grandegger wrote:
 > Hello,
 > 
 > with RTnet over Xenomai and Linux 2.4 on PowerPC I realized that Xenomai 
 > does not distinguish between a normal IRQ enable and an IRQ unmask at 
 > the end of an ISR (to reenable the IRQ). In the latter case the IRQ 
 > should be enabled on PowerPC as shown:
 > 
 > if (rthal_irq_descp(irq)->handler->end != NULL)

 >  rthal_irq_descp(irq)->handler->end(irq);
 >  else
 >  rthal_irq_descp(irq)->handler->enable(irq);
 > 
 > To handle this case properly, we need to different functions, I think.


I am not sure I understand what you mean. Would you want functions
rthal_end_irq and xnarch_end_irq added and that this xnarch_end_irq
would be called in xnintr_irq_handler when XN_ISR_ENABLE is set ?


Yes, that's what I have basically done to get the RTnet SCC enet driver 
working on my MPC8xx module. In arch/ppc/kernel/irq.c you can see how 
Linux re-enables interrupts at the end of it's ISR (see

http://cvs.gna.org/cvsweb/linux/v2.4/2.4.25-ppc/arch/ppc/kernel/irq.c?rev=1.1;cvsroot=adeos):

  507:   * The ->end() handler has to deal with interrupts which got
  508:   * disabled while the handler was running.
  509:   */
  510:  if (desc->handler) {
  511:  if (desc->handler->end)
  512:  desc->handler->end(irq);
  513:  else if (desc->handler->enable)
  514:  desc->handler->enable(irq);

In PPC Linux 2.6 things are a bit different. The "end" functions seems 
to be mandatory now (I have to check more carefully).


Therefore we need a dedicated function to re-enable interrupts in the 
ISR. We could name it *_end_irq, but maybe *_enable_isr_irq is more 
obvious. On non-PPC archs it would translate to *_irq_enable. I 
realized, that *_irq_enable is used in various place/skins and therefore 
I have not yet provided a patch.


Wolfgang.



___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] Initialization of a nucleus pod

2006-01-19 Thread Gilles Chanteperdrix
Germain Olivier wrote:
 > Hello
 > 
 > I am trying to understand how a pod is initialized.
 > 
 > I think it start with xncore_attach() from core.c, then with xnpod_init from
 > pod.c
 > But here (in xnpod_init) there is something not clear about the root thread
 > creation.
 > 
 > It use xnthread_init(&sched->rootcb, ...), but I don't see where
 > &sched->rootcb is initialized

xnthread_init does part of the initialization. The low level part of
rootcb (its xnarchtcb_t member) is initialized twice, first by the call
to xnarch_init_tcb in xnthread_init, and then overriden by
xnarch_init_root_tcb in xnpod_init.

For any other thread than root, the thread would be given a stack and
entry point by the call to xnarch_init_thread in xnpod_start_thread. But
the root thread is Xenomai idle task, a placeholder for whatever task
Linux is currenty running. At the time where xnpod_init is called, the
root thread is the current context, so already has a stack and is
already running.

-- 


Gilles Chanteperdrix.

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] Missing IRQ end function on PowerPC

2006-01-19 Thread Gilles Chanteperdrix
Wolfgang Grandegger wrote:
 > Hello,
 > 
 > with RTnet over Xenomai and Linux 2.4 on PowerPC I realized that Xenomai 
 > does not distinguish between a normal IRQ enable and an IRQ unmask at 
 > the end of an ISR (to reenable the IRQ). In the latter case the IRQ 
 > should be enabled on PowerPC as shown:
 > 
 > if (rthal_irq_descp(irq)->handler->end != NULL)
 > rthal_irq_descp(irq)->handler->end(irq);
 >  else
 > rthal_irq_descp(irq)->handler->enable(irq);
 > 
 > To handle this case properly, we need to different functions, I think.

I am not sure I understand what you mean. Would you want functions
rthal_end_irq and xnarch_end_irq added and that this xnarch_end_irq
would be called in xnintr_irq_handler when XN_ISR_ENABLE is set ?

-- 


Gilles Chanteperdrix.

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] RTAI vs XENOMAI

2006-01-19 Thread Gilles Chanteperdrix
Doyle, Alan \(Siemens\) wrote:
 > Hi,
 > 
 > I'm looking into porting an embedded application using Accelerated
 > Technologies 'Nucleus' RTOS to a real time Linux variant. RTAI is the
 > preferred approach but on looking into available documentation I have
 > discovered Xenomai which seems to be designed to solve this sort of
 > problem. However as there is no existing emulator for Nucleus on Xenomai
 > I would have to write one so I'm unsure whether there would then be any
 > benefit. Could somebody advise me as to the pros and cons of porting to
 > RTAI or Xenomai.

Using Xenomai would ease writing a skin for the nucleus RTOS. Philippe
once wrote a mail on how to write a new skin, which you will find on
rtai.dk: 

http://rtai.dk/cgi-bin/gratiswiki.pl?How_To_Implement_A_New_Skin

The reasons why the Xenomai project, was made a separate project from
RTAI is explained in the following post on RTAI mailing list :

https://mail.rtai.org/pipermail/rtai/2005-October/013155.html

-- 


Gilles Chanteperdrix.

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] Scheduling while atomic

2006-01-19 Thread Jeroen Van den Keybus
Turned off:
  o  nucleus debugging
  o  ipipe stats
  o  ipipe tracing
  o  ishield
 
The problem persists. Also tried three tasks, with same result. With one task, there is no problem.
 
 
Jeroen.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] Scheduling while atomic

2006-01-19 Thread Jeroen Van den Keybus

Hold on. Just crashed without the file access: please disregard last post.
 
 
Jeroen.


[Xenomai-core] Scheduling while atomic

2006-01-19 Thread Jeroen Van den Keybus
Hm.
 
When I remove the output() from both tasks, all seems fine.
 
Jeroen.