LATEXFLAGS:=-file-line-error -halt-on-error -no-shell-escape
FIGURES:=$(addsuffix .png,$(addprefix img/,$(notdir $(basename $(wildcard fig/*.dot)))))
+LISTINGS:=$(wildcard listings/*)
+TEXS:=$(wildcard *.bib)
+BIBS:=$(wildcard *.tex)
.PHONY: all clean
.SECONDARY: $(addsuffix .fmt,$(DOCS)) $(FIGURES)
%.pdf: %.mlog
if $(GREP) -iFq 'Rerun' $<; then $(LATEX) $(LATEXFLAGS) $(basename $<); fi
-%.mlog: %.tex %.fmt $(wildcard *.bib) $(wildcard *.tex) $(FIGURES)
+%.mlog: %.tex %.fmt $(BIBS) $(TEXS) $(FIGURES) $(LISTINGS)
$(LATEX) $(LATEXFLAGS) $<
if $(GREP) -q '^\\bibdata{' $(basename $<).aux; then $(BIBTEX) $(BIBTEXFLAGS) $(basename $<); fi
if $(GREP) -q '\@istfilename' $(basename $<).aux; then $(MAKEGLOSSARIES) $(MAKEGLOSSARIESFLAGSFLAGS) $(basename $<); fi
#include <stdint.h>
#include <stdarg.h>
-#define read16() 256*(uint8_t)read_byte() + (uint8_t)read_byte()
-#define from16(a, b) 256*a+b
-#define write16(i) { write_byte((uint8_t)i/256); write_byte((uint8_t)i%256); }
+#ifdef LINUX
+#define STACKSIZE 1024
+#define MEMSIZE 1024
+#define HAVELED 1
+#define HAVEAIO 1
+#define HAVEDIO 1
+#elif defined STM
+...
+#endif
+
+/* Communication */
+bool input_available(void);
uint8_t read_byte(void);
void write_byte(uint8_t b);
+/* Analog and digital pins */
+#if HAVEDIO == 1
void write_dpin(uint8_t i, bool b);
bool read_dpin(uint8_t i);
-
+#endif
+#if HAVEAIO == 1
void write_apin(uint8_t i, uint8_t a);
uint8_t read_apin(uint8_t i);
+#endif
+/* UserLED */
+#if HAVELED == 1
void led_on(uint8_t i);
void led_off(uint8_t i);
+#endif
-long millis(void);
-bool input_available(void);
-void delay(long ms);
+/* Delay and communication */
+unsigned long getmillis(void);
+void msdelay(unsigned long ms);
-void setup(void);
+/* Auxilliary */
+void real_setup(void);
void debug(char *fmt, ...);
void pdie(char *s);
void die(char *fmt, ...);
and implement (part of) the device specific interface. The shared codebase only
uses standard \gls{C} and no special libraries or tricks are used. Therefore
the code is compilable for almost any device or system. Note that it is not
-needed to implement a full interface. The full interface, listed in
-Appendix~\label{app:device-interface}\todo{update interface listing}, also
-includes functions for accessing the peripherals that not every device might
-have. Devices can choose what to implement by setting the correct macros in the
-top of the file. When a server connects to a client the specifications are
+needed to implement a full interface. The full interface excluding the device
+specific settings is listed in Appendix~\ref{app:device-interface}. The
+interface works in a similar fashion as the \gls{EDSL}. Devices do not have to
+implement all functionality, this is analogous to the fact that views do not
+have to implement all type classes in the \gls{EDSL}. When the device connects
+for the first time with a server the specifications of what is implemented is
communicated.
-The current list of supported and tested devices is as follows:
+At the time of writing the following device families are supported and can run
+the device software.
\begin{itemize}
- \item $^*$\texttt{NIX} systems such as Linux
- \item \emph{STM32} like development boards supported by \texttt{ChibiOS}
- such as the \emph{STM32f7x} series.
- \item \emph{Arduino} compatible microcontrollers. Even development boards
- with as little as \emph{2K} \emph{RAM} such as the \emph{Arduino UNO}
- are supported.
+ \item \texttt{POSIX} compatible systems
+
+ This includes systems running \emph{Linux} and \emph{MacOS}.
+ \item \texttt{STM32} family microcontrollers supported by \texttt{ChibiOS}.
+
+ This is tested in particular on the \texttt{STM32f7x} series \gls{ARM}
+ development board.
+ \item Microcontrollers programmable by the \emph{Arduino} \gls{IDE}.\\
+
+ This does not only include \emph{Arduino} compatible boards but also
+ other boards capable of running compiled \emph{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}.
\end{itemize}
\subsection{Specification}
a \gls{SDS} containing all devices. From the macro settings in the interface
file a profile is created for the device that describes the specification. When
a connection between the server and a client is established the server will
-send a request for specification. The client will serialize his specs and send
-it to the server so that the server knows what the client is capable of. The
-exact specification is listed in Listing~\ref{lst:devicespec}
+send a request for specification. The client will serialize his specification
+and send it to the server so that the server knows what the client is capable
+of. The exact specification is listed in Listing~\ref{lst:devicespec}
\begin{lstlisting}[language=Clean,label={lst:devicespec},
caption={Device specification for \glspl{mTask}}]
,bytesMemory :: Int
}
\end{lstlisting}
+
+\subsection{Memory Management}
\todo{Explain specification, combine task and share space}
\subsection{Communication}
The first downside of the type of \gls{EDSL} can be overcome by using
\glspl{GADT}. Listing~\ref{lst:exdeepgadt} shows the same language, but
-type-safe with a \gls{GADT}\footnote{Note that \glspl{GADT} are not supported
-in \gls{Clean}. They can be simulated using bimaps}\todo{cite}. Unfortunately
-the lack of extendability stays a problem. If a language construct is added no
-compile time guarantee is given that all views support it.
+type-safe with a \gls{GADT}\footnote{\glspl{GADT} are not supported
+in the current version of \gls{Clean}. However, they can be simulated using
+bimaps}. Unfortunately the lack of extendability stays 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}}]
+ caption={A minimal deep \gls{EDSL} using \glspl{GADT}}]
:: DSL a
= LitI Int -> DSL Int
| LitB Bool -> DSL Bool
\subsection{Shallow embedding}
In a shallowly \gls{EDSL} all language constructs are expressed as functions in
-the host language. Our example language then looks something like the code
-shown in Listing~\ref{lst:exshallow} if implementing the evaluator. Note that
-much of the internals of the language can be hidden away using monads.
+the host language. An evaluator view for our example language then looks
+something like the code shown in Listing~\ref{lst:exshallow}. Note that much of
+the internals of the language can be hidden away using monads.
\begin{lstlisting}[language=Clean,label={lst:exshallow},%
caption={A minimal shallow \gls{EDSL}}]
implement.
\subsection{Class based shallow embedding}
-The third type of embedding is called class based shallow embedding and is
-supposed to have the best of both shallow and deep embedding. In class based
-shallow embedding the language constructs are defined as type classes. The same
-language is shown with the new method in Listing~\ref{lst:exclassshallow}.
-
-This type of embedding inherits the easyness of adding views from shallow
-embedding. A view is just a different type implementing one or more type
-classes as shown in the aforementioned Listing where an evaluator and a pretty
-printer are implemented.
+The third type of embedding is called class based shallow embedding and has the
+best of both shallow and deep embedding. In class based shallow embedding the
+language constructs are defined as type classes. The same language is shown
+with the new method in Listing~\ref{lst:exclassshallow}.
+
+This type of embedding inherits the easiness of adding views from shallow
+embedding. A view is just a different data type implementing one or more of the
+type classes as shown in the aforementioned Listing where an evaluator and a
+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
specialization instances for these functions and show an according interface.
Generated interfaces can be modified with decoration operators.
-
\subsection{Combinators}
+\todo{Stukje over combinators, in ieder geval bind en paralel}
commentstyle=\itshape, % comment style
keywordstyle=\bfseries, % keyword style
stringstyle=\ttfamily, % string literal style
- language=Clean, % the language of the code
showspaces=false, % show spaces everywhere adding particular underscores; it overrides 'showstringspaces'
showstringspaces=false, % underline spaces within strings only
showtabs=false, % show tabs within strings adding particular underscores
\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}
\newglossaryentry{Clean}{name=Clean,
description={is a pure lazy functional programming language based on graph
rewriting}}
repositories / msc-thesis1617.git / commitdiff