Hide minor edits - Show changes to markup
May 16, 2011, at 12:32 PM
Added lines 1-30:
Technical Meeting #14: FLC software design
This meeting took place at 11:30 on Tuesday 10 May 2011. Attendees: JSY, EBS, MF, DFB.
- FLC will use same real-time architecture as FTT (whatever that is)
- Various options for inter-task communications, need to investigate in more detail
- System Modes:
- Standby: camera powered off, receives status & telemetry from FttEnvController
- Fast Tip-Tilt (FTT only)
- "Accumulate defined amount of data" modes, with common userland real-time task:
- Acquisition Check
- Dark Frame
From discussions between JSY, EBS, DFB.
Link MROI Generic System Interface generated code with Xenomai user-space library, substituting Xenomai POSIX API wrappers for standard pthreads calls as described at http://www.xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai . Note that this transforms the primary thread into a (non-RT) Xenomai thread. Threads created using the Xenomai pthread_create will be switched transparently between primary and secondary mode, and can use the Xenomai API. The Xenomai POSIX API includes a useful queue implementation which can be used for thread-safe communications between RT and non-RT tasks: http://www.xenomai.org/documentation/trunk/html/api/group__posix__mq.html
There are also buffer services in the "native" API, but its not clear whether the two APIs can be mixed. In any case use of the native API is discouraged for portability reasons.
Need to check whether substitutions of Linux system calls (e.g. socket()) are harmful, and if so best way to prevent substitution. They probably just do context switching as necessary and hence it should be OK to use the Xenomai wrappers.