[fpc-devel] custom ThreadManager and MemoryMutexManager for hard realtime

[Stefan Kisdaroczi]

Am 07.01.2010 09:40, schrieb Michael Schnell:
> Jonas Maebe wrote:
> 
>> while the rtl does pre-allocate some
>> memory from the system on startup, it can still allocate more later if
>> necessary, and it can also free memory back to the system.
>>
> 
> That is why I suggested that he needs to create a Xenomai aware Memory
> Manager Plugin.

Thanks for this suggestion, that was really important.

> Moreover he'd need Xenomai aware components for Timer, TCP/IP, serial
> interface, file operations, ...

No, I don't need that, really. You are not wrong here, but in my case we
have something like an own RTL, because our old compiler (1989) didnt had
that.

Timer:
  No pascal timing functions like sleep() are used, my own timing unit
  calls rt_task_sleep() in the xenomai library. We have other timing
  functions calling xenomai functions.

TCP/IP:
  It's not realtime anyway, so there are no calls in time critical code.
  I simply use the fpc sockets unit, the thread is running under the
  linux scheduler when doing socket calls, thats no problem. Because
  the thread is known to the realtime scheduler too, i can use xenomai
  message functions (queues, pipes, sem...) to send the received bytes
  to a task which is always scheduled by the realtime scheduler.

Serial Interface:
  Im calling directly the the xenomai library functions rt_dev_open().

File operations:
  Not used in time critical parts of the code.

Another good example to show that the scheduler migration is a nice
feature is writing the log files:
 - The realtime task writes the log data in a buffer and signals that
   with a realtime semaphore to the writer task. The writer-task is
   blocking on that realtime semaphore. The writer-task now calls
   the normal writeln() function, this switches the task to the linux
   scheduler. After that the task blocks again on the realtime sema,
   this will switch the task back to the realtime scheduler. If there
   is no place in the buffer, the realtime task's dont block, they
   discard the data.

kisda

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20100107/e4b75f98/attachment.sig>