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 to express \glspl{Task}
-for the new system in. The \gls{mTask}-\gls{EDSL} shown in
-Chapter~\ref{chp:mtask} provides a 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 for \gls{Arduino} compatible
+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
programmed, nothing can be changed to it anymore. \gls{IoT}-devices often have
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}.
-Some functionality of the \gls{mTask} system is not 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