From cde787301da5c4441615534df29823c7b9fc1f00 Mon Sep 17 00:00:00 2001 From: Mart Lubbers Date: Wed, 12 Jul 2017 20:24:34 +0200 Subject: [PATCH] enrich intro even more --- intro.intro.tex | 10 +++++----- intro.related.tex | 12 +++++++++++- todo.txt | 2 -- 3 files changed, 16 insertions(+), 8 deletions(-) delete mode 100644 todo.txt diff --git a/intro.intro.tex b/intro.intro.tex index fd7f265..6d264e9 100644 --- a/intro.intro.tex +++ b/intro.intro.tex @@ -41,11 +41,11 @@ example, this layer would be the app that can be used to monitor the electricity consumption. These tools on the application layer can again be created into a wide variety of programming languages and different paradigms. -The separation of \gls{IoT} in layers is one of the causes of an integration -problem in \gls{IoT}. The different layers are built with different paradigms, -programming languages and different architectures which is difficult to -connect. Rolling out updates is also complicated since reprogramming -microcontrollers in the field is very expensive. +The separation of \gls{IoT} in layers is a difficulty when developing \gls{IoT} +applications. All layers use different paradigms, languages and architecture. +Rolling out changes to the system is also complicated since reprogramming +microcontrollers in the field is very expensive. Even the simple repurposing of +a device requires often a full reprogram. \subsection{Task Oriented Programming} The \gls{TOP} paradigm and the corresponding \gls{iTasks} implementation offer diff --git a/intro.related.tex b/intro.related.tex index 69f2166..de306e5 100644 --- a/intro.related.tex +++ b/intro.related.tex @@ -25,7 +25,7 @@ for and \gls{Clean} and \gls{Haskell} which compile the respective code to \gls{SAPL}~\cite{domoszlai_compiling_2012}. The \gls{SAPL} language is still a functional language and therefore requires big stacks and heaps to operate and is therefore not directly suitable for devices with little RAM such as the -\gls{Arduino} Uno which only boasts $2K$ of RAM. It might be possible to +\gls{Arduino}~Uno which only boasts $2K$ of RAM. 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 @@ -55,3 +55,13 @@ functions. There is no intermediate \gls{AST}. Moreover, \gls{Ivory} generates static programs and thus it is necessary to reprogram the devices when they need to be repurposed. It would be interesting to explore the possibilities of writing the client software in an \gls{EDSL} as well. + +Not all \gls{IoT} devices run solely compiled code. The popular \emph{ESP8266} +powered \textsc{NodeMCU} is able to run interpreted \gls{LUA} code. Moreover, +there is a variation on \gls{Python} called \emph{micropython} that is suitable +for running on microcontrollers. However, the overhead of the interpreter for +such rich languages often results into limitations on the program size. It +would not be possible to repurpose a device with \gls{IoT} because implementing +this extensibility in the interpreted language leaves no room for the actual +programs. Also, some devices only have $2K$ of ram, which is not enough for +this. diff --git a/todo.txt b/todo.txt deleted file mode 100644 index 59754de..0000000 --- a/todo.txt +++ /dev/null @@ -1,2 +0,0 @@ -intro: Problem statement en introductie uitwijden -concl: Uitleggen hoe/of de probleemstelling opgelost is -- 2.20.1