Am 06.01.2010 14:02, schrieb Michael Schnell:
> Stefan Kisdaroczi wrote:
> 
>> You can call normal linux system calls without problems, that is one of the
>> big features of xenomai, but of course you have to take care, it can have an
>> impact on the realtime performance.
> 
> Meaning that when doing a Linux system call, at this point a potentially
> huge delay might be introduced.

True, but for realtime apps the most important part is the application design.
You never create tasks realtime, you never alloc mem in realtime.
You dont take a "normal" app, recompile it with xenomai and everything works
realtime.

> As the standard FPC memory management in
> the RTL potentially does Linux system calls, you either need to modify
> the RTL on that behalf (AFAIK the memory manager is done as a plugin and
> thus you easily _can_ provide your own one), or avoid memory management
> completely (no idea how this might be possible).

AFAIK the RTL allocs the heap on app startup, or on thread-creation with 2.4.0.
In my code im using getmem() to alloc mem from the heap, this will not generate
syscalls because the heap is already allocated and the RTL has its own 
MemoryManager.
Regarding the memory management I think using fpc with Xenomai is even better 
than
using C, where you have to call malloc(), which will probably make a linux 
syscall.

The only "problem" is the locking of the MemoryManager. It should not use 
Linux-Mutexes,
it should use Xenomai-Mutexes. This is what I did with the custom 
MemoryMutexManager.

If i'm wrong here please cry loud "STOP", thx :-)

The custom ThreadManager is like the cthreads implementation, but it creates 
tasks
over the xenomai library instead of the pthreads lib. Important here is to 
setup the
TLS after creating the tasks over xenomai for fpc.

> 
>> IRQ's:
>>   - Xenomai adds a Interrupt-Pipeline:
>>     Interrupts are handled first by the xenomai scheduler and then passed to 
>> the
>>     linux scheduler.
>>     --> Linux interrupt handling is stalled while the realtime scheduler has 
>> tasks
>>     to run
> 
> That is what I meant with "running Linux in a kind of virtualization".
> 
>> Future:
>>   If you build your realtime apps as Xenomai userspace apps and make 
>> RTDM-Drivers,
>>   in about two years (just guessed), you will be able to run your realtime 
>> apps
>>   with the Xenomai Duo-Kernel approach or on the linux native preempt_rt 
>> realtime
>>   support without changing anything in the application or driver code, just 
>> recompile.
>>
> 
> Even closer to "Virtualization". Of course this is very interesting when
> dual core hardware is provided (which gets more and more "standard".

Its interesting on a singlecore too :-) But yes, on a duo-core you can use one 
processor
exclusively for the realtime scheduler and the other one for the linux 
scheduler.
Which variant you choose, duo-scheduler or single-scheduler with preempt_rt, 
depends
on the worstcase latency your app needs.

The worstcase latency on recent x86 machines is something like:
-  20us : duo-kernel xenomai
- 200us : linux preempt_rt
-  >2ms : linux native
Of course that numbers are wrong, it depends on a lot of things, they are just 
to give an idea.

> I do suppose Xenomai offers some memory management paradigm, which you
> can use instead of Linux system calls in your alternative FPC memory
> manager.

You can alloc realtime heaps, I use them for shared mems between multiple apps.

Xenomai supports multiple API's (Native,Posix,VxWorks,pSOS+,VRTX,uITRON), i'm 
using the native
skin for some reasons. If you want to use fpc for realtime with the posix skin, 
i think you
just have to adapt cthreads that it links against pthread_rt instead of 
pthread. Not tested.

kisda

> 
> -Michael
> _______________________________________________
> fpc-devel maillist  -  fpc-devel@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
> 


Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply via email to