From 435b0d98d22a47530f50ff82f2451e70ce2bed96 Mon Sep 17 00:00:00 2001 From: Mart Lubbers Date: Fri, 2 Jun 2017 15:41:59 +0200 Subject: [PATCH] process camil's notes --- acronyms.tex | 18 -------- glossaries.tex | 21 ++++++++++ introduction.tex | 102 ++++++++++++++++++++++++---------------------- methods.dsl.tex | 43 ++++++++++--------- methods.mtask.tex | 57 +++++++++++++------------- methods.top.tex | 9 ++-- results.arch.tex | 10 ++--- thesis.tex | 3 +- 8 files changed, 137 insertions(+), 126 deletions(-) delete mode 100644 acronyms.tex diff --git a/acronyms.tex b/acronyms.tex deleted file mode 100644 index 01ac16a..0000000 --- a/acronyms.tex +++ /dev/null @@ -1,18 +0,0 @@ -\newacronym{GADT} {GADT} {Generalized Algebraic Datatype} -\newacronym{GPIO} {GPIO} {General-Purpose Input/Output} -\newacronym{ADT} {ADT} {Algebraic Datatype} -\newacronym{SDS} {SDS} {Shared Data Source} -\newacronym{IoT} {IoT} {Internet of Things} -\newacronym{TOP} {TOP} {Task Oriented Programming} -\newacronym{EDSL} {EDSL} {Embedded Domain Specific Language} -\newacronym{RISC} {RISC} {Reduced Instruction Set Computer} -\newacronym{ARM} {ARM} {Acorn \acrshort{RISC} Machine} -\newacronym{LTN} {LTN} {Low Throughput Network} -\newacronym{IDE} {IDE} {Integrated Development Environment} -\newacronym{TCP} {TCP} {Transmission Control Protocol} -\newacronym{RFID} {RFID} {Radio-Frequency Identification} -\newacronym{GNSS} {GNSS} {Global Navigation SAtellite System} -\newacronym{LCD} {LCD} {Liquid Crystal Display} -\newacronym{AST} {AST} {Abstract Syntax Tree} -\newacronym{GPS} {GPL} {Global Positioning System} -\newacronym{GLONASS}{GLONASS}{Global Navigation Satellite System} diff --git a/glossaries.tex b/glossaries.tex index a13ed34..ad7701a 100644 --- a/glossaries.tex +++ b/glossaries.tex @@ -30,3 +30,24 @@ \newglossaryentry{Javascript}{name={\emph{Javascript}}, description={is an imperative programming language designed to run in web browsers}} +\newcommand{\newglossacr}[2]{\newglossaryentry{#1}{name={#1},first={% + \glsentrylong{#1} (\glsentryname{#1})},firstplural={\glsentrylong{#1}% + \glspluralsuffix (\glsentryname{#1}\glspluralsuffix},description={#2}}} +\newglossacr{GADT}{Generalized Algebraic Data type} +\newglossacr{GPIO} {General-Purpose Input/Output} +\newglossacr{ADT} {Algebraic Datatype} +\newglossacr{SDS} {Shared Data Source} +\newglossacr{IoT} {Internet of Things} +\newglossacr{TOP} {Task Oriented Programming} +\newglossacr{EDSL} {Embedded Domain Specific Language} +\newglossacr{RISC} {Reduced Instruction Set Computer} +\newglossacr{ARM} {Acorn \glsentryname{RISC} Machine} +\newglossacr{LTN} {Low Throughput Network} +\newglossacr{IDE} {Integrated Development Environment} +\newglossacr{TCP} {Transmission Control Protocol} +\newglossacr{RFID} {Radio-Frequency Identification} +\newglossacr{GNSS} {Global Navigation Satellite System} +\newglossacr{LCD} {Liquid Crystal Display} +\newglossacr{AST} {Abstract Syntax Tree} +\newglossacr{GPS} {Global Positioning System} +\newglossacr{GLONASS}{Global Navigation Satellite System} diff --git a/introduction.tex b/introduction.tex index b7adb23..7ea1d08 100644 --- a/introduction.tex +++ b/introduction.tex @@ -1,25 +1,26 @@ \section{Introduction} -\Gls{IoT} technology is emerging very quickly and offers myriads of solutions +\Gls{IoT} technology is emerging very quickly. It offers myriads of solutions and transforms the way we interact with technology. Initially the term was coined to describe \gls{RFID} devices and the communication between them. However, currently the term \gls{IoT} encompasses all small devices that communicate with each other and the world. These devices -often contain sensors, \gls{GNSS}\footnote{e.g.\ the American \gls{GPS} or -the Russian \gls{GLONASS}} and actuators\cite{da_xu_internet_2014}. With these -new technologies information can be tracked very accurately using very little -power and bandwidth. Moreover, \gls{IoT} technology is coming into people's -homes, clothes and in healthcare\cite{riazul_islam_internet_2015}. For example, -for a few euros a consumer ready fitness tracker watch can be bought that -tracks heartbeat and respiration levels. +are often equipped with sensors, \gls{GNSS}\footnote{e.g.\ the American +\gls{GPS} or the Russian \gls{GLONASS}} and actuators% +\cite{da_xu_internet_2014}. With these new technologies information +can be tracked very accurately using very little power and bandwidth. Moreover, +\gls{IoT} technology is coming into people's homes, clothes and in +healthcare\cite{riazul_islam_internet_2015}. For example, for a few euros a +consumer ready fitness tracker watch can be bought that tracks heartbeat and +respiration levels. The \gls{TOP} paradigm and the corresponding \gls{iTasks} implementation offer a high abstraction level for real life workflow tasks% \cite{plasmeijer_itasks:_2007}. These workflow tasks can be described through -an \gls{EDSL} and modeled as \glspl{Task}. The system will generatea multi-user -web service from the specification. This web service can be accessed -through a browser and is used to complete these \glspl{Task}. Familiar workflow -patterns like sequence, parallel and conditional tasks can be modelled using +an \gls{EDSL} and modeled as \glspl{Task}. The system will generate multi-user +web app from the specification. This web service can be accessed through a +browser and is used to complete these \glspl{Task}. Familiar workflow patterns +like sequence, parallel and conditional tasks can be modelled using combinators. \gls{iTasks} has been proven to be useful in many fields of operation such as @@ -28,40 +29,42 @@ generated for the types of data which makes rapid development possible. \Glspl{Task} in the \gls{iTasks} system are modelled after real life workflow tasks but the modelling is applied on a very high level. Therefore it is difficult to connect \gls{iTasks}-\glspl{Task} to real world tasks and let -them interact. A lot of the actual tasks could be \emph{performed} by small +them interact. A lot of the actual tasks could be performed by small \gls{IoT} devices. Nevertheless, adding such devices to the current system is difficult to say the least as it was not designed to cope with these devices. -In the current system such adapters, in principle, can be written as -\glspl{SDS}\footnote{Similar as to resources such as time are available in -the current \gls{iTasks} implementation} but this requires a very specific -adapter to be written for every device and function. However, this forces -a fixed logic in the device that is set at compile time. A lot of the small -\gls{IoT} devices have limited processing power but can still contain decision -making. Oortgiese et al.\ lifted \gls{iTasks} from a single server model to a -distributed server architecture that is also runnable on smaller devices like -\acrshort{ARM} devices\cite{oortgiese_distributed_2017}. However, this is -limited to fairly high performance devices that are equipped with high speed -communication channels. Devices in \gls{IoT} often have only \gls{LTN} -communication with low bandwidth and a very limited amount of processing power -and are therefore not suitable to run an entire \gls{iTasks} core. +In the current system such adapters connecting devices to \gls{iTasks} --- in +principle --- can be written as \glspl{SDS}\footnote{Similar as to resources +such as time are available in the current \gls{iTasks} implementation}. +However, this +requires a very specific adapter to be written for every device and function. +This forces a fixed logic in the device that is set at compile time. A +lot of the small \gls{IoT} devices have limited processing power but can still +contain decision making. Oortgiese et al.\ lifted \gls{iTasks} from a single +server model to a distributed server architecture that is also runnable on +smaller devices like \acrshort{ARM} devices\cite{oortgiese_distributed_2017}. +However, this is limited to fairly high performance devices that are equipped +with high speed communication channels. Devices in \gls{IoT} often have only +\gls{LTN} communication with low bandwidth and a very limited amount of +processing power and are therefore not suitable to run an entire \gls{iTasks} +core. \section{Problem statement} -The updates to the \gls{mTask}-system will bridge this gap by introducing a new -communication protocol, device application and \glspl{Task} synchronizing the -formers. The system can run on devices as small as \gls{Arduino} -microcontrollers\cite{noauthor_arduino_nodate} and operates via the same -paradigms and patterns as regular \glspl{Task} in the \gls{TOP} paradigm. -Devices in the \glspl{mTask}-system can run small imperative programs written -in an \gls{EDSL} and have access to \glspl{SDS}. \Glspl{Task} are sent to the -device at runtime, avoiding recompilation and thus write cycles on the program -memory. +The updates to the \gls{mTask}-system\cite{koopman_type-safe_nodate} will +bridge this gap by introducing a new communication protocol, device application +and \glspl{Task} synchronizing the formers. The system can run on devices as +small as \gls{Arduino} microcontrollers\cite{noauthor_arduino_nodate} and +operates via the same paradigms and patterns as regular \glspl{Task} in the +\gls{TOP} paradigm. Devices in the \gls{mTask}-system can run small imperative +programs written in an \gls{EDSL} and have access to \glspl{SDS}. \Glspl{Task} +are sent to the device at runtime, avoiding recompilation and thus write cycles +on the program memory. \section{Document structure} The structure of this thesis is as follows. Chapter~\ref{chp:introduction} contains the problem statement, motivation, -literature embedding and the structure of the document. +related work and the structure of the document. Chapter~\ref{chp:top} introduces the reader to the basics of \gls{TOP} and \gls{iTasks}. Chapter~\ref{chp:dsl} discusses the pros and cons of different embedding @@ -82,8 +85,8 @@ communicating between the server and client. Appendix~\ref{app:device-interface} shows the concrete interface for the devices. -\section{Relevant research} -Several types of similar research has been conducted concerning these matters. +\section{Related work} +Several types of similar research have been conducted concerning these matters. Microcontrollers such as the \gls{Arduino} can be remotely controlled by the \gls{Firmata}-protocol\footnote{``firmata/protocol: Documentation of the Firmata protocol.'' (\url{https://github.com/firmata/protocol}). [Accessed: @@ -93,7 +96,7 @@ allows very fine grained control but with the cost of excessive communication overhead since no code is executed on the device, only the peripherals are queried. A \gls{Haskell} implementation of the protocol has been created% \footnote{``hArduino by LeventErkok.'' (\url{% -https://leventerkok.github.io/hArduino}). [Accessed: 23-May-2017].} +https://leventerkok.github.io/hArduino}). [Accessed: 23-May-2017].}. \Gls{Clean} has a history of interpretation and there is a lot of research happening on the intermediate language \gls{SAPL}. \Gls{SAPL} is a purely @@ -101,16 +104,17 @@ functional intermediate language that has interpreters written in \gls{C++}\cite{jansen_efficient_2007} and \gls{Javascript}% \cite{domoszlai_implementing_2011} and \gls{Clean} and \gls{Haskell} compiler backends\cite{domoszlai_compiling_2012}. However, interpreting the resulting -code is still heap-heavy therefore not directly suitable for devices with as -few as $2K$ of RAM such as the \gls{Arduino}. It might be possible to compile -the \gls{SAPL} code into efficient machine language or \gls{C} but then the -system would lose its dynamic properties since the microcontroller then would -has to be reprogrammed every time a new \gls{Task} is sent to the device. +code is still heap-heavy and therefore not directly suitable for devices with as +little as $2K$ of RAM such as the \gls{Arduino} \emph{UNO}. It might be +possible to compile the \gls{SAPL} code into efficient machine language or +\gls{C} but then the system would lose its dynamic properties since the +microcontroller then would have to be reprogrammed every time a new \gls{Task} +is sent to the device. \Glspl{EDSL} have often been used to generate \gls{C} code for microcontroller environments. For starters, this work is built upon the \gls{mTask}-\gls{EDSL} that generates \gls{C} code to run a \gls{TOP}-like system on microcontrollers% -\cite{plasmeijer_shallow_2016}.\cite{koopman_type-safe_nodate}. +\cite{plasmeijer_shallow_2016}\cite{koopman_type-safe_nodate}. Again, this requires a reprogramming cycle every time the \gls{Task}-specification is changed. @@ -121,9 +125,9 @@ make unsafe languages type safe. For example, \gls{Ivory} has been used in the automotive industry to program parts of an autopilot% \cite{pike_programming_2014}\cite{hickey_building_2014}. \Gls{Ivory}'s syntax is deeply embedded but the type system is shallowly embedded. This requires -several \gls{Haskell} extensions that offer dependant type constructions. The +several \gls{Haskell} extensions that offer dependent type constructions. The process of compiling an \gls{Ivory} program happens in stages. The embedded code is transformed into an \gls{AST} that is sent to a backend. The -\gls{mTask} \gls{EDSL} transform the embedded code during compile-time directly -into the backend which is often a state transformer that will execute on -runtime. +\gls{mTask} \gls{EDSL} transforms the embedded code during compile-time +directly into the backend which is often a state transformer that will execute +on runtime. diff --git a/methods.dsl.tex b/methods.dsl.tex index df1e198..be9d7ac 100644 --- a/methods.dsl.tex +++ b/methods.dsl.tex @@ -1,12 +1,15 @@ -There are several techniques available for creating \glspl{EDSL}. Each of -them have their own advantages and disadvantages such as extendability, -typedness and view support. In the following subsections each of the main -techniques are briefly explained. +An \gls{EDSL} is a language embedded in a host language. \glspl{EDSL} can have +one or more backends or views. Commonly used views are pretty printing, +compiling, simulating, verifying and proving the program. There are several +techniques available for creating \glspl{EDSL}. Each of them have their own +advantages and disadvantages in terms of extendability, typedness and view +support. In the following subsections each of the main techniques are briefly +explained. \section{Deep embedding} -A deep \gls{EDSL} means that the language is represented as an \gls{ADT}. Views -are functions that transform something to the datatype or the other way around. -As an example we have the simple arithmetic \gls{EDSL} shown in +A deep \gls{EDSL} is a language represented as an \gls{ADT}. Views are +functions that transform something to the datatype or the other way around. As +an example we have the simple arithmetic \gls{EDSL} shown in Listing~\ref{lst:exdeep}. \begin{lstlisting}[language=Clean,label={lst:exdeep},% @@ -21,20 +24,20 @@ Listing~\ref{lst:exdeep}. | Eq DSL \end{lstlisting} Deep embedding has the advantage that it is very simple to build and the views -are easy to make and add. To the downside, the expressions created with this -language are not type-safe. In the given language it is possible an expression -such as \CI{Plus (LitI 4) (LitB True)} which to add a boolean to an integer. +are easy to add. To the downside, the expressions created with this language +are not type-safe. In the given language it is possible to create an expression +such as \CI{Plus (LitI 4) (LitB True)} that adds a a boolean to an integer. Evermore so, extending the \gls{ADT} is easy and convenient but extending the views accordingly is tedious and has to be done individually for all views. -The first downside of the type of \gls{EDSL} can be overcome by using +The first downside of this type of \gls{EDSL} can be overcome by using \glspl{GADT}\cite{cheney_first-class_2003}. Listing~\ref{lst:exdeepgadt} shows the same language, but type-safe with a \gls{GADT}. \glspl{GADT} are not supported in the current version of \gls{Clean} and therefore the syntax is -artificial. However, it has been shown that \glspl{GADT} can be simulated using -bimaps or projection pairs\cite{cheney_lightweight_2002}. Unfortunately the -lack of extendability remains a problem. If a language construct is added, no -compile time guarantee is given that all views support it. +hypothetical. However, it has been shown that \glspl{GADT} can be simulated +using bimaps or projection pairs\cite{cheney_lightweight_2002}. Unfortunately +the lack of extendability remains a problem. If a language construct is added, +no compile time guarantee is given that all views support it. \begin{lstlisting}[language=Clean,label={lst:exdeepgadt},% caption={A minimal deep \gls{EDSL} using \glspl{GADT}}] @@ -60,18 +63,18 @@ the internals of the language can be hidden using monads. :: DSL a = DSL (Env -> a) Lit :: a -> DSL a -Lit x = \e->x +Lit x = \e -> x Var :: String -> DSL Int -Var i = \e->retrEnv e i +Var i = \e -> retrEnv e i Plus :: (DSL Int) (DSL Int) -> DSL Int -Plus x y = \e->x e + y e +Plus x y = \e -> x e + y e ... Eq :: (DSL a) (DSL a) -> DSL Bool | == a -Eq x y = \e->x e + y e +Eq x y = \e -> x e + y e \end{lstlisting} The advantage of shallowly embedding a language in a host language is its @@ -100,7 +103,7 @@ pretty printer are implemented. Just as with \glspl{GADT} in deep embedding type safety is guaranteed. Type constraints are enforced through phantom types. One can add as many phantom -type as is necessary. Lastly, extensions can be added easily, just as in +type as necessary. Lastly, extensions can be added easily, just as in shallow embedding. When an extension is made in an existing class, all views must be updated accordingly to prevent possible runtime errors. When an extension is added in a new class, this problem does not arise and views can diff --git a/methods.mtask.tex b/methods.mtask.tex index a0ec96b..5bdbbb1 100644 --- a/methods.mtask.tex +++ b/methods.mtask.tex @@ -2,7 +2,7 @@ The \gls{mTask}-\gls{EDSL} is the basis on which the system is built. The \gls{mTask}-\gls{EDSL} was created by Koopman et al.\ to support several views such as an \gls{iTasks} simulation and a \gls{C}-code generator. The \gls{EDSL} was designed to generate a ready to compile \gls{TOP}-like system for -microcontrollers such as the Arduino\cite{koopman_type-safe_nodate}% +microcontrollers such as the \gls{Arduino}\cite{koopman_type-safe_nodate}% \cite{plasmeijer_shallow_2016}. The \gls{mTask}-\gls{EDSL} is a shallowly embedded class based \gls{EDSL} and @@ -12,17 +12,18 @@ that are used in this extension. The parts of the \gls{EDSL} that are not used will not be discussed and the details of those parts can be found in the cited literature. -A view for the \gls{mTask}-\gls{EDSL} is a type of kind \CI{*->*->*} that -implements some of the classes given. The types do not have to be present as -fields in the higher kinded view and can, and will most often, solely be -phantom types. A view is of the form \CI{v t r}. The first variable will be the -type of the view, the second type variable will be the type of the -\gls{EDSL}-expression and the third type variable represents the role of the -expression. Currently the role of the expressions form a hierarchy. The three -roles and their hierarchy are shown in Listing~\ref{lst:exprhier}. This implies -that everything is a statement, only a \CI{Upd} and a \CI{Expr} are -expressions. The \CI{Upd} restriction describes updatable expressions such as -\gls{GPIO} pins and \gls{SDS}. +A view for the \gls{mTask}-\gls{EDSL} is a type with kind \CI{*->*->*}% +\footnote{A type with two free type variables.} that implements some of the +classes given. The types do not have to be present as fields in the higher +kinded view and can, and will most often, solely be phantom types. A view is of +the form \CI{v t r}. The first type variable will be the type of the view, the +second type variable will be the type of the \gls{EDSL}-expression and the +third type variable represents the role of the expression. Currently the role +of the expressions form a hierarchy. The three roles and their hierarchy are +shown in Listing~\ref{lst:exprhier}. This implies that everything is a +statement, only a \CI{Upd} and a \CI{Expr} are expressions. The \CI{Upd} +restriction describes updatable expressions such as \gls{GPIO} pins and +\glspl{SDS}. \begin{lstlisting}[% language=Clean,label={lst:exprhier},caption={Expression role hierarchy}] @@ -63,13 +64,13 @@ class boolExpr v where Looping of \glspl{Task} happens because \glspl{Task} are executed after waiting a specified amount of time or when they are launched by another task or even themselves. Therefore there is no need for loop control flow functionality such -as \emph{while} or \emph{for} constructions. The main control flow is the -sequence operator and the \emph{if} statement. Both are shown in -Listing~\ref{lst:control}. The first class of \emph{If} statements describe the -regular \emph{if} statement. The expressions given can have any role. The -functional dependency on \CI{s} determines the return type of the statement. -The sequence operator is very straightforward and just ties the two expressions -together in sequence. +as \emph{while} or \emph{for} constructions. The main control flow operators +are the sequence operator and the \emph{if} statement. Both are shown in +Listing~\ref{lst:control}. The first class of \emph{If} statements describes +the regular \emph{if} statement. The expressions given can have any role. The +functional dependency\todo{explain} on \CI{s} determines the return type of the +statement. The sequence operator is very straightforward and just ties the two +expressions together in sequence. \begin{lstlisting}[% language=Clean,label={lst:control},caption={Control flow operators}] @@ -81,11 +82,11 @@ class seq v where \end{lstlisting} \section{Input/Output and class extensions} -All expressions that have an \CI{Upd} role can be assigned to. Examples of such -expressions are \glspl{SDS} and \gls{GPIO}. Moreover, class extensions can be -created for specific peripherals such as user LEDs. The classes facilitating -this are shown in Listing~\ref{lst:sdsio}. In this way the assignment is the -same for every assignable entity. +Values can be assigned to all expressions that have an \CI{Upd} role. Examples +of such expressions are \glspl{SDS} and \gls{GPIO} pins. Moreover, class +extensions can be created for specific peripherals such as builtin LEDs. The +classes facilitating this are shown in Listing~\ref{lst:sdsio}. In this way the +assignment is the same for every assignable entity. \begin{lstlisting}[% language=Clean,label={lst:sdsio},caption={Input/Output classes}] @@ -114,7 +115,7 @@ class assign v where A way of storing data in \glspl{mTask} is using \glspl{SDS}. \glspl{SDS} serve as variables in the \gls{mTask} and maintain their value across executions. The classes associated with \glspl{SDS} are listed in -Listing~\ref{lst:sdsclass}. The \CI{Main} class is introduced to box an +Listing~\ref{lst:sdsclass}. The \CI{Main} type is introduced to box an \gls{mTask} and make it recognizable by the type system. \begin{lstlisting}[% @@ -139,9 +140,9 @@ the actual \gls{Task} will be executed some time in the future. The \gls{iTasks}-backend simulates the \gls{C}-backend and thus uses the same semantics. This engine expressed in pseudocode is listed as Algorithm~\ref{lst:engine}. All the \glspl{Task} are inspected on their waiting -time. When the waiting time has not passed the delta is subtracted and they are -pushed to the end of the queue. When the waiting has has surpassed they are -executed. When a \gls{mTask} wants to queue another \gls{mTask} it can just +time. When the waiting time has not passed; the delta is subtracted and the +task gets pushed to the end of the queue. When the waiting has surpassed they are +executed. When an \gls{mTask} wants to queue another \gls{mTask} it can just append it to the queue. \begin{algorithm}[H] diff --git a/methods.top.tex b/methods.top.tex index c05165a..6d47dfc 100644 --- a/methods.top.tex +++ b/methods.top.tex @@ -1,8 +1,8 @@ \section{iTasks} -\gls{TOP} is a recent programming paradigm implemented as +\gls{TOP} is a modern recent programming paradigm implemented as \gls{iTasks}\cite{achten_introduction_2015} in the pure lazy functional language \gls{Clean}\cite{brus_cleanlanguage_1987}. \gls{iTasks} is a -\gls{EDSL} to model workflow tasks in the broadest sense. A \CI{Task} is just +\gls{EDSL} to model workflow tasks in the broadest sense. A \gls{Task} is just a function that --- given some state --- returns the observable \CI{TaskValue}. The \CI{TaskValue} of a \CI{Task} can have different states. Not all state transitions are possible as shown in Figure~\ref{fig:taskvalue}. Once a value @@ -42,6 +42,7 @@ enterName = enterInformation "Enter your name" [] \end{lstlisting} \begin{figure}[H] + \centering \begin{subfigure}{.25\textwidth} \centering \includegraphics[width=.9\linewidth]{taskex1} @@ -60,8 +61,8 @@ enterName = enterInformation "Enter your name" [] \caption{Example of a generated user interface} \end{figure} -For a type to be suitable it must have instances for a collection of generic -functions that are captured in the class \CI{iTask}. Basic types have +For a type to be suitable, it must have instances for a collection of generic +functions that is captured in the class \CI{iTask}. Basic types have specialization instances for these functions and show an according interface. Generated interfaces can be modified with decoration operators. diff --git a/results.arch.tex b/results.arch.tex index f4b615a..e33dc47 100644 --- a/results.arch.tex +++ b/results.arch.tex @@ -22,13 +22,13 @@ the device software. This is tested in particular on the \texttt{STM32f7x} series \gls{ARM} development board. - \item Microcontrollers programmable by the \emph{Arduino} \gls{IDE}.\\ + \item Microcontrollers programmable by the \gls{Arduino} \gls{IDE}.\\ - This does not only include \emph{Arduino} compatible boards but also - other boards capable of running \emph{Arduino} code. The code + This does not only include \gls{Arduino} compatible boards but also + other boards capable of running \gls{Arduino} code. The code has been found working on the \texttt{ESP8266} powered \emph{NodeMCU}. - It is tested on devices as small as the regular \emph{Arduino UNO} - board that only boasts a meager \emph{2K} of \emph{RAM}. + It is tested on devices as small as the regular \gls{Arduino} + \emph{UNO} board that only boasts a meager \emph{2K} of \emph{RAM}. \end{itemize} \section{Specification} diff --git a/thesis.tex b/thesis.tex index 519f9c2..26697c2 100644 --- a/thesis.tex +++ b/thesis.tex @@ -1,9 +1,8 @@ %&thesis -\usepackage[nonumberlist,acronyms]{glossaries} % Glossaries and acronyms +\usepackage[nonumberlist]{glossaries} % Glossaries and acronyms \usepackage[]{algorithm2e} % Pseudocode \makeglossaries% -\input{acronyms} \input{glossaries} \begin{document} -- 2.20.1