mtaskext.tasksem.tex

   1 The current \gls{mTask} engine for devices does not support \glspl{Task} in the
   2 sense that the \gls{C}-view does. \Glspl{Task} used with the \gls{C}-view are a
   3 main program that executes code and launches \glspl{Task}. It was also possible
   4 to just have a main program. The current \gls{mTask}-system only supports main
   5 programs. Sending a \gls{Task} always goes together with choosing a scheduling
   6 strategy. This strategy can be one of the following three strategies as
   7 reflected in the \CI{MTTask} message type.
   8
   9 \begin{itemize}
  10         \item\CI{OneShot}
  11
  12                 \CI{OneShot} takes no parameters and means that the \gls{Task} will run
  13                 once and will then be removed automatically. This type of scheduling
  14                 could be useful, for example, in retrieving sensor information on
  15                 request of a user.
  16         \item\CI{OnInterval}
  17
  18                 \CI{OnInterval} has the number of milliseconds to wait in between
  19                 executions as a parameter. \Glspl{Task} running with this scheduling
  20                 method are executed at predetermined intervals.
  21         \item\CI{OnInterrupt}
  22
  23                 The last scheduling method is running \glspl{Task} on a specific
  24                 interrupt. Unfortunatly, due to time constraints and focus, none of the
  25                 current client implementations support this. Interrupt scheduling is
  26                 useful for \glspl{Task} that have to react on a certain type of
  27                 hardware event such as the press of a button.
  28 \end{itemize}