headers
Philippe Gerum | 2 Jan 2006 10:06
Favicon

Xenomai v2.1-rc1


So new that the paint is still wet, here is the first candidate release 
of the upcoming 2.1 series. The major changes since v2.0.x are as follows:

* New build system which allows to compile Xenomai statically into the 
kernel image, and ensures proper decoupling between kernel and 
user-space supports.
* SMP support for ppc64 and tree refactoring toward 2.6.15/powerpc.
* Backport to Linux 2.4 for x86 and ppc32.
* Port to the Blackfin architecture (http://blackfin.uclinux.org/).

and a number of updates to the nucleus, rtdm, the native and POSIX APIs. 
As usual, see the ChangeLog for details.

Since we have a few major updates still cooking outside of the main tree 
which are planned for inclusion in 2.1 final, this is not a feature 
freeze, yet.

Also note that starting with the v2.1 series, the simulator is available 
as a separate tarball.

http://download.gna.org/xenomai/testing/xenomai-2.1-rc1.tar.bz2
http://download.gna.org/xenomai/testing/simulator/xenosim-2.1-rc1.tar.bz2

Best wishes to all for this New Year.

--

-- 

Philippe.
(Continue reading)

Permalink | Reply | 0 comments |
headers
vdkeybus | 3 Jan 2006 00:19
Picon
Favicon

Re: RTDM interrupt programming practice

Ok. I've applied the patches (kernel is now also 2.6.14-5).

1. I've also upgraded the kernel from 2.6.14 to 2.6.14-5, because 
Xenomai's make ...config was complaining about not finding 
CONFIG_IPIPE_EXTENDED after application of Adeos patch 1.1-00 to 
a 'vanilla' 2.6.14-5 Linux kernel. Eventually I added the CONFIG line 
myself, but I'm now consequently working with a newer kernel than the 
one in my previous report.

2. While compiling kernels (I'm still far from enjoying this 
activity...), I accidentally turned back on SMP (2 CPUs) with 
multithreading (SMT). Everything worked fine (as opposed to my first 
2.6.14 SMP venture some weeks ago, which gave tons of smp_processor_id
() bugwarnings and forced me to turn of SMP), but I was getting massive 
delays with ./latency (about 20 times normal values with lots of 
overruns). I turned SMP+SMT back off, and all values are normal again. 
Is this a known issue ? Or should I just not try to push things...

3. Three things concerning interrupt programming:

3a - I _did_ disable the card's interrupt lines, but I _forgot_ to 
enable interrupts with rtdm_irq_enable(). Nevertheless, I still _got_ 
the interrupts, until I placed the PCI card in a slot without interrupt 
sharing. BTW the return value of the rtdm_irq_request() and 
rtdm_irq_free() funtions was 0.

3b - Is it ok to return from the ISR with RTDM_IRQ_ENABLE if the 
interrupt is for the card and to return with RTDM_IRQ_PROPAGATE if it 
is not ? Should I logically OR them together ?
(Continue reading)

Permalink | Reply | 1 comment |
headers
Philippe Gerum | 3 Jan 2006 10:26
Favicon

Re: RTDM interrupt programming practice

vdkeybus wrote:
> Ok. I've applied the patches (kernel is now also 2.6.14-5).
> 
> 1. I've also upgraded the kernel from 2.6.14 to 2.6.14-5, because 
> Xenomai's make ...config was complaining about not finding 
> CONFIG_IPIPE_EXTENDED after application of Adeos patch 1.1-00 to 
> a 'vanilla' 2.6.14-5 Linux kernel. Eventually I added the CONFIG line 
> myself, but I'm now consequently working with a newer kernel than the 
> one in my previous report.

Which is wrong. Xeno 2.0.x is not expected to work with the Adeos 1.1 
series. The fact that it still does with -00 is pure luck, and won't be 
true anymore with the next 1.1 releases. You should stick with the 
patches available from arch/i386/patches which have been validated 
against the Xeno version that ships them, at least until you have a 
working configuration. I know that the tracer is a very desirable tool, 
but the workforce is not infinite here, and backporting every 
significant improvement to each Xenomai version on every platform is not 
possible.

> 
> 2. While compiling kernels (I'm still far from enjoying this 
> activity...), I accidentally turned back on SMP (2 CPUs) with 
> multithreading (SMT). Everything worked fine (as opposed to my first 
> 2.6.14 SMP venture some weeks ago, which gave tons of smp_processor_id
> () bugwarnings and forced me to turn of SMP), but I was getting massive 
> delays with ./latency (about 20 times normal values with lots of 
> overruns). I turned SMP+SMT back off, and all values are normal again. 
> Is this a known issue ? Or should I just not try to push things...
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dominique.RAGOT | 3 Jan 2006 17:22

RE: RTDM interrupt programming practice

Hello,

I can answer only to item 2.

Measurements were made on bi-Xeon PCs for SMP and SMP+SMT configurations, using kernel 2.6.13 and Xenomai
2.0. It showed that SMT has a negative impact on latency benchmark figures. Disabling SMT and keeping SMP
brought latency figures back to nominal performance.

Hope this can help.

----------
Dominique RAGOT

> -----Message d'origine-----
> De : xenomai-help-bounces <at> gna.org
> [mailto:xenomai-help-bounces <at> gna.org]De la part de Philippe Gerum
> Envoyé : mardi 3 janvier 2006 10:27
> À : vdkeybus
> Cc : xenomai-help <at> gna.org
> Objet : Re: [Xenomai-help] RTDM interrupt programming practice
> 
> 
> vdkeybus wrote:
> > Ok. I've applied the patches (kernel is now also 2.6.14-5).
> > 
> > 1. I've also upgraded the kernel from 2.6.14 to 2.6.14-5, because 
> > Xenomai's make ...config was complaining about not finding 
> > CONFIG_IPIPE_EXTENDED after application of Adeos patch 1.1-00 to 
> > a 'vanilla' 2.6.14-5 Linux kernel. Eventually I added the 
> CONFIG line
(Continue reading)

Permalink | Reply | 0 comments |
headers
S. ancelot | 11 Jan 2006 14:44
Picon
Favicon

newbie heap usage problem

Hi,
I tried to make a programming sample using heap .
The heap seems to be created regarding registry in proc, but then the  
program seg faults

Here is my program

#include <sys/mman.h>
#include <xenomai/native/heap.h>
#include <stdio.h>

RT_HEAP *m;
int x;

int main()
{
  mlockall(MCL_CURRENT|MCL_FUTURE);
  x = rt_heap_create(m,"toto",100,H_SHARED);
  rt_heap_delete(m);
  return 0;

}

Best Regards
S <at>
Permalink | Reply | 1 comment |
headers
Stephan Zimmermann | 11 Jan 2006 14:09
Picon

Using Xenomai in C++ App.

Hello List, 
actually I am playing around with Xenomai 2.0.1 functions in a C++ 
Application. I Wrote some simple wrapper-classes to use mutexes, semaphores 
and tasks. Now, after thinking a while about message queues, I am confused 
somehow. Is it possible to use the standard 'new' Operator in a mutithreaded 
realtime application, or do I need to allocate memory inside a Xenomai heap 
(and overload operator new to do so)?

I would be thankful for some hints,
Greetings, Stephan
Permalink | Reply | 2 comments |
headers
Philippe Gerum | 11 Jan 2006 14:07
Favicon

Re: newbie heap usage problem

S. ancelot wrote:
> Hi,
> I tried to make a programming sample using heap .
> The heap seems to be created regarding registry in proc, but then the  
> program seg faults
> 
> 
> Here is my program
> 
> #include <sys/mman.h>
> #include <xenomai/native/heap.h>
> #include <stdio.h>
> 

- RT_HEAP *m;
+ RT_HEAP m;

> int x;
> 
> int main()
> {
>  mlockall(MCL_CURRENT|MCL_FUTURE);

- x = rt_heap_create(m,"toto",100,H_SHARED);
- rt_heap_delete(m);
+ x = rt_heap_create(&m,"toto",100,H_SHARED);
+ rt_heap_delete(&m);

>  return 0;
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Philippe Gerum | 11 Jan 2006 15:00
Favicon

Re: Using Xenomai in C++ App.

Stephan Zimmermann wrote:
> Hello List, 
> actually I am playing around with Xenomai 2.0.1 functions in a C++ 
> Application. I Wrote some simple wrapper-classes to use mutexes, semaphores 
> and tasks. Now, after thinking a while about message queues, I am confused 
> somehow. Is it possible to use the standard 'new' Operator in a mutithreaded 
> realtime application,

It's possible but could make some of your application threads migrate to secondary 
(i.e. relaxed execution) mode while running, due to the presence of Linux syscalls 
in the malloc code that underlies the standard C++ allocator, unless you did 
overload the new & delete operators appropriately. IOW, you would lose determinism 
wrt execution latency. Typical issues would concern brk() for extending the data 
segment of the current process to get more core, or controlled access to a 
contended critical section by means of glibc mutexes, that malloc() may start 
behind your back.

  or do I need to allocate memory inside a Xenomai heap
> (and overload operator new to do so)?

That would be a correct solution for keeping the allocation/deallocation ops 
within the bounds of very strict timing constraints, I think.

Hint: check out the T_WARNSW of rt_task_set_mode() for debugging unexpected 
transitions to secondary mode.

> 
> I would be thankful for some hints,
> Greetings, Stephan
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gilles Chanteperdrix | 11 Jan 2006 16:48
Favicon

Re: Using Xenomai in C++ App.

Stephan Zimmermann wrote:
 > Hello List, 
 > actually I am playing around with Xenomai 2.0.1 functions in a C++ 
 > Application. I Wrote some simple wrapper-classes to use mutexes, semaphores 
 > and tasks. 

Maybe you will be interested in xeno--:

https://gna.org/projects/xenomm/

--

-- 

					    Gilles Chanteperdrix.
Permalink | Reply | 0 comments |
headers
Rodrigo Rosenfeld Rosas | 11 Jan 2006 19:55
Picon
Favicon

PCI Framegrabber real-time driver

Hi,

I developed a v4l2 driver for my PCI framegrabber and I need to use it in my
real-time applications. I think I need to write a new one with real-time
constrainments. But I'm not sure of which API would be the best one for this
kind of driver.

I know about existence of RTDM, but I'm not sure if it is the best choice...

Let me explain how the driver works. It initializes the board with some PCI
writes on startup. It's passed to the kernel the parameter "mem=510M"
reserving 2Mb for use with the framegrabber through DMA access. I need a
continuous physic memory area and I can't get it through kmalloc or similar
functions. I map this memory in my programs in user space. So, I basically
need to write and read from PCI registers in the drive. But I don't know if
it should be better to develop the driver using some existing API or not
because I didn't find any API that applies to framegrabbers like v4l does on
Linux domain...

Please, what do you suggest about the design of my driver?

Thanks,

Rodrigo.

	

	
		
_______________________________________________________
(Continue reading)

Permalink | Reply | 11 comments |

Gmane