Not all \glspl{Task} are suitable to run on an \gls{IoT}-device and therefore
-an \gls{EDSL} is used to offer a constrained language that expresses \glspl{Task}
-for the new system. The \gls{mTask}-\gls{EDSL} shown in
-Chapter~\ref{chp:mtask} provides the language to create imperative programs that
-are suitable to run on microcontrollers. The \gls{EDSL}'s main view is a
+an \gls{EDSL} is used to offer a constrained language that expresses
+\glspl{Task} for the new system. The \gls{mTask}-\gls{EDSL} shown in
+Chapter~\ref{chp:mtask} provides the language to create imperative programs
+that are suitable to run on microcontrollers. The \gls{EDSL}'s main view is a
\gls{C} code generator who's code compiles to \gls{Arduino} compatible
microcontrollers. The big downside of this approach is the stiffness of the
system. Once the code has been generated and the microcontroller has been
a limited amount of write cycles on their program memory available and
therefore it is very expensive to keep recompiling and reprogramming the chips.
To solve this problem, a new view is proposed for the \gls{mTask}-\gls{EDSL}
-which compiles the expressions not to \gls{C}-code, but to a bytecode format.
-To achieve this, several classes have been added to the \gls{mTask}-\gls{EDSL}.
-Not all of the functionality of the \gls{mTask} language is used.
+which compiles the expressions not to \gls{C}-code, but to a bytecode format
+which is interpetable and thus the need for reprogramming is removed. To
+achieve this, several classes have been added to the \gls{mTask}-\gls{EDSL}.
+Not all of the functionality of the \gls{mTask} language is needed or not
+implemented.
-The added functionality and implementation to the \gls{mTask}-\gls{EDSL} is
+The functionality and implementation added to the \gls{mTask}-\gls{EDSL} is
shown in Chapter~\ref{chp:mtaskcont}.
repositories / msc-thesis1617.git / blobdiff