X-Git-Url: https://git.martlubbers.net/?a=blobdiff_plain;f=conclusion.tex;h=3f0b3e5ae317657806f10e0d93c1dacd9bb9d5bf;hb=8755061062b9738c80da1f5966c93ac6ec832a5c;hp=850e4b4244200d29f52090c352de7e20bfec8a6d;hpb=5f23e1fc77da5ea47ca9e1f71f7c2e862e0e0df2;p=msc-thesis1617.git

diff --git a/conclusion.tex b/conclusion.tex
index 850e4b4..3f0b3e5 100644
--- a/conclusion.tex
+++ b/conclusion.tex
@@ -1,53 +1,5 @@
-\section{Conclusion}
-This thesis introduces a new view for the existing \gls{mTask}-\gls{EDSL}.
-The new view for the \gls{EDSL} compiles the language in to bytecode that can
-be interpreted by an \gls{mTask}-client. Clients have been written for several
-microcontrollers and consumer architectures that can be connected through
-various means of communication such as serial, bluetooth, wifi and wired
-network communication. The bytecode on the devices is interpreted using a
-simple stack machine and provides the programmer interfaces to the peripherals.
-The semantics of the \glspl{mTask} tries to resemble the \gls{iTasks} semantics
-as close as possible.
-
-The host language has a very efficient compiler and code generator. Therefore,
-the \gls{mTask}-system is also relatively fast because the compilation of
-\glspl{mTask} is nothing more than running some functions in the host language.
-
-The dynamic nature allows the microcontroller to be programmed once and used
-many times. The program memory of microcontrollers often guarantees around
-$10.000$ write or upload cycles and therefore existing techniques such as
-generating \gls{C} code are not usable for dynamic \gls{Task} environments.
-The dynamic nature also allows the programmer to design fail-over mechanisms.
-When a device is assigned a \gls{Task} but another device suddenly becomes
-unusable, the \gls{iTasks} system can reassign a new \gls{mTask}-\gls{Task} to
-the first device that possibly takes over some of the functionality of the
-broken device without needing to recompile the code.
+\section{Discussion \& Future Research}
+\input{conclusion.discussion}
 
-
-\section{Discussion}
-
-\section{Future Research}
-Future improvements of the system could be:
-\begin{itemize}
-	\item Add an additional simulation view to the \gls{mTask}-\gls{EDSL} that
-		simulates the bytecode interpreter and possibly functions as a full
-		fledged device, thus handling all communication through the existing
-		system.
-	\item Add true multitasking to the client software allowing
-		\gls{mTask}-\glspl{Task} to run truly parallel. This does require
-		separate stacks for each task and therefore increases the system
-		requirements of the client software. However, it could be implemented
-		as a compile-time option and exchanged during the handshake so that the
-		server knows the multithreading capabilities of the client.
-	\item Resource analysis during compilation can be useful to determine if an
-		\gls{mTask}-\gls{Task} is suitable for a specific device. If the device
-		does not contain the correct peripherals such as an \gls{LCD} then the
-		\gls{mTask}-\gls{Task} should be rejected and feedback to the user must
-		be given. This could also be extended to minimum stack size needed to
-		run the task and memory requirements for storing the \gls{Task}.
-	\item Implement more \gls{Task} combinators such as the step combinator to
-		allow for more fine-grained control flow between
-		\gls{mTask}-\glspl{Task}. This could be extended to a similar system
-		as in the \gls{C}-code generation view. The \glspl{Task} can launch
-		other \glspl{Task} and compose \glspl{Task} of subtasks.
-\end{itemize}
+\section{Conclusion}
+\input{conclusion.conclusion}