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 >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
