[jenkicar/rpp-simulink.git] / doc / reports / report2 / publish / tex / report2.tex

\newcommand{\superscript}[1]{\ensuremath{^{\textrm{\small#1}}}}
\newcommand{\subscript}[1]{\ensuremath{_{\textrm{\small#1}}}}

\documentclass{article}

\usepackage{graphicx} % images and graphics
\usepackage{paralist} % needed for compact lists
\usepackage[normalem]{ulem} % needed by strike
\usepackage{listings} % required for code blocks
\usepackage[urlcolor=blue,colorlinks=true,hyperfootnotes=false]{hyperref} % links
\usepackage[utf8]{inputenc}  % char encoding
\usepackage[bottom]{footmisc} % footnotes

% header
\usepackage[top=2.5cm, bottom=2.5cm, left=2.5cm, right=2.5cm]{geometry}
\usepackage{float} % To fix images position

% Prettify code documentation
\usepackage{color}
\definecolor{gray97}{gray}{.97}
\definecolor{gray75}{gray}{.75}
\definecolor{gray45}{gray}{.45}
\lstset{ frame=Ltb,
     framerule=0pt,
     aboveskip=0.5cm,
     framextopmargin=3pt,
     framexbottommargin=3pt,
     framexleftmargin=0.4cm,
     framesep=0pt,
     rulesep=.4pt,
     backgroundcolor=\color{gray97},
     rulesepcolor=\color{black},
     %
     stringstyle=\ttfamily,
     showstringspaces = false,
     basicstyle=\small\ttfamily,
     commentstyle=\color{gray45},
     keywordstyle=\bfseries,
     %
     numbers=left,
     numbersep=15pt,
     numberstyle=\tiny,
     numberfirstline = false,
     breaklines=true,
     xleftmargin=20px,
   }

% Spacing
\addtolength{\parskip}{\baselineskip} % Paragraph spacing
\linespread{1.15} % Lines spacing
\setlength{\plitemsep}{0.5\baselineskip} % List items spacing
\definecolor{deepblue}{RGB}{0,0,61}
\hypersetup{linkcolor=deepblue,}

% Table of content depth
\setcounter{tocdepth}{4}

% Landscape pages
\usepackage{lscape}
\usepackage{pdflscape}

% Change page
\usepackage{changepage}

% Font options
% Sans-serif
% \renewcommand{\familydefault}{\sfdefault}
% Better PDF font
\usepackage{lmodern}

% Multiple columns
\usepackage{multicol}

\begin{document}

% Title
\newcommand{\HRule}{\rule{\linewidth}{0.5mm}}

\begin{titlepage}
\begin{center}

% Upper part of the page
\includegraphics[width=0.70\textwidth]{media/images/logos.png}\\[1cm]
\textsc{\LARGE Costa Rica Institute of Technology}\\[0.5cm]
\textsc{\LARGE Czech Technical University in Prague}\\[1.5cm]
\textsc{\Large Undergraduate project}\\[0.5cm]


% Document title
\HRule \\[0.4cm]
{ \huge \bfseries Progress report 2}\\[0.4cm]
\HRule \\[1.5cm]


% Author
\emph{Author:}\\
Carlos \textsc{Jenkins}\\

\vfill

% Bottom of the page
{\large \today}

\end{center}
\end{titlepage}
% Title end

\tableofcontents

\newpage

\hypertarget{introduction}{}
\section{Introduction}

This document describes the second progress report for the project ``Code generation for automotive 
rapid prototyping platform using Matlab/Simulink" executed on the first semester of 2013 at the 
Department of Control Engineering, Faculty of Electrical Engineering, Czech Technical University, 
as part of the specialty practice for applying for the Computer Engineering Bachelor degree at the 
Costa Rica Institute of Technology.

This report aims to outline the design of the system to develop.

\hypertarget{design_model}{}
\section{Design model}

This section describes the architecture of the system to be built. Please note that this project
target C embedded development and Simulink code generation (no user graphical interface, no 
database management system, etc) and thus traditional UML based design methodologies does not 
apply.

\newpage

\hypertarget{c_support_library}{}
\subsection{C Support Library}

The RPP C Support Library define the API to communicate with the board. It include drivers and
operating system. This section documents the design of this library.

\hypertarget{architecture}{}
\subsubsection{Architecture}

The RPP library is structured into 5 layers with the following guidelines:

\begin{compactitem}
\item Top-down dependency only. No lower layer depends on anything from upper layers.
\item 1-1 layer dependency only. The top layer depends exclusively on the bottom layer, not on any
  lower level layer (except for a couple of exceptions).
\item Each layer should provide a unified layer interface (\texttt{rpp.h}, \texttt{drv.h}, \texttt{hal.h}, \texttt{sys.h}
  and \texttt{os.h}), so top layers depends on that layer interface and not on individual elements from
  that layer.
\end{compactitem}

\begin{figure}[H]\begin{center}

\noindent\includegraphics[width=250px]{media/images/layers.pdf}
\caption{The RPP library layers.}\end{center}\end{figure}

As a consequence of this division the source code files and interface files will be placed on
private directories so the previous prefix based inclusion \texttt{drv\_din.h} will be replaced by
\texttt{drv/din.h}. With this organization user applications will only need to include the top layer
interface file (\texttt{rpp/rpp.h}) to be able to use the library API.

\hypertarget{rpp_layer_modules}{}
\subsubsection{RPP Layer Modules}

The RPP Layer is structured into 14 different modules from 4 different categories that match the
hardware modules on the board:

\begin{center}\begin{tabular}{lll}
\textbf{Category} & \textbf{Description} & \textbf{MNEMONIC} \\
Logic IO & Digital Input & \texttt{[DIN ]} \\
 & Digital (Logic) Output & \texttt{[LOUT]} \\
 & Analog Input & \texttt{[AIN ]} \\
 & Analog Output & \texttt{[AOUT]} \\
Power output & H-Bridge output & \texttt{[HBR ]} \\
 & Power output (12V, 2A) & \texttt{[MOUT]} \\
 & High-Power output (12V, 10A) & \texttt{[HOUT]} \\
Communication & CAN Bus & \texttt{[CAN ]} \\
 & LIN (Local Interconnect Network) & \texttt{[LIN ]} \\
 & FlexRay & \texttt{[FR  ]} \\
 & Serial Communication Interface & \texttt{[SCI ]} \\
 & Ethernet & \texttt{[ETH ]} \\
Logging & SD Card & \texttt{[SDC ]} \\
 & SD-RAM & \texttt{[SDR ]} \\
\end{tabular}\end{center}

Please note the mnemonic of each module, as they will be constantly used on the Software and
documentation. Also note that only the following modules will be implemented as part of this 
project:

\begin{multicols}{2}

\begin{compactitem}
\item DIN.
\item LOUT.
\item AIN.
\item AOUT.
\item HBR.
\item MOUT.
\item SCI.
\item SDR.
\end{compactitem}

\end{multicols}

Modules for which there is a low-level API available on the library but no high-level module will 
be implemented:

\begin{multicols}{2}

\begin{compactitem}
\item CAN.
\item LIN.
\item FR.
\end{compactitem}

\end{multicols}

Modules that are not yet available on the library at all:

\begin{multicols}{2}

\begin{compactitem}
\item ETH (in the works).
\item SDC.
\item HOUT (partial).
\end{compactitem}

\end{multicols}

The following graphic shows the library modules and the connectors on the hardware they map to.

\begin{figure}[H]\advance\leftskip-1cm

\noindent\includegraphics[width=500px]{media/images/blocks.pdf}
\caption{The RPP Library modules.}\end{figure}

\newpage

\hypertarget{os_interchangeable_layer}{}
\subsubsection{OS interchangeable layer}

The OS Layer is composed by the FreeRTOS source code files. Because the FreeRTOS exposes an stable
API the OS layer can be changed in order to upgrade the Operating System or use a different port of
the OS, without changing the upper layers source code. The OS Layers currently available for the
RPP Library at \texttt{$<$repo$>$/rpp/lib/os/} at the time of this writing are:

\begin{compactitem}
\item Version 6.0.4 using POSIX port. This layer is the one that should be used when compiling a
  program for x86(\_64) simulation. The port uses the \texttt{pthread} library and because of this the
  port is not true real time and this is considered a simulator.
\item Version 7.0.2 using HalCoGen port for TMS570. This layer is the one currently supported and
  tested. It was originally included in the testing application and was generated by an older
  version of TI code generation tool HalCoGen.
\item Version 7.4.0 using HalCoGen port for TMS570. This layer was extracted from a newly generated
  project using a newer version of HalCoGen. This layer is untested but \textit{should} work out of the
  box.
\item Version 7.4.2 using ARM Cortex R4 official port for CCS. This layer was created from vanilla
  FreeRTOS 7.4.2 release. It is tested but non-working. Ticks are proved to be executed in time but
  applications using this kernel runs at full-speed. The reason if this is currently unknown.
\end{compactitem}

The general layout of all the layers are as following:

\begin{itemize}
\item Common source code (kernel):

\begin{verbatim}
    src/os/croutine.c (Optional)
    src/os/list.c
    src/os/queue.c
    src/os/tasks.c
    src/os/timers.c (Optional)
\end{verbatim}


Originally found in vanilla distribution in: \texttt{$<$FreeRTOSRoot$>$/FreeRTOS/Source}

\item Common interface files:

\begin{verbatim}
    include/os/croutine.h
    include/os/FreeRTOS.h
    include/os/list.h
    include/os/mpu_wrappers.h
    include/os/portable.h (with minor editions)
    include/os/projdefs.h
    include/os/queue.h
    include/os/semphr.h
    include/os/StackMacros.h
    include/os/task.h
    include/os/timers.h
\end{verbatim}


Originally found in vanilla distribution in: \texttt{$<$FreeRTOSRoot$>$/FreeRTOS/Source/include}

\item Memory management file:

\begin{verbatim}
    src/os/heap.c (One of 4 version available, see Appendix A).
\end{verbatim}


Originally found in vanilla distribution in: \texttt{$<$FreeRTOSRoot$>$/FreeRTOS/Source/portable/MemMang}

\item Port specific files:

\begin{verbatim}
    src/os/port.c
    src/os/portASM.asm
    include/os/portmacro.h
    include/os/FreeRTOSConfig.h
\end{verbatim}


This depend of the port. In the case of the 7.4.2 TMS570 / ARM Cortex R4 for CCS port:

 \begin{compactitem}
 \item First three files can be found in vanilla distribution in \newline{}
   \texttt{$<$FreeRTOSRoot$>$/FreeRTOS/Source/portable/CCS/ARM\_Cortex-R4}.
 \item Last file in \texttt{$<$FreeRTOSRoot$>$/FreeRTOS/Demo/CORTEX\_R4\_RM48\_TMS570\_CCS5}.
 \end{compactitem}
\end{itemize}

In general, the following changes were applied to the source code base of all kernels:

\begin{itemize}
\item Replaced include directives to adapt to RPP library standard:

\texttt{\#include "} with \texttt{\#include "os/}

\item Line ending character set to UNIX '$\backslash$n' and tabs replaced by 4 spaces.
\end{itemize}

\newpage

\hypertarget{api_development_guidelines}{}
\subsubsection{API development guidelines}

\vspace{-0.40cm}

The following are the development guidelines that will be used for developing the RPP API:

\begin{compactitem}
\item User documentation should be placed in header files, not in source code, and should be Doxygen
  formatted using autobrief. Documentation for each function present is mandatory.
\item Function declarations on the headers files is for public functions only. Do not declare
  local/static/private functions on the header.
\item Documentation on source code files should be non-doxygen formatted and intended for developers,
  not users. Documentation here is optional and at the discretion of the developer.
\item Always use standard data types for IO when possible. Use custom structs as very last resort.
\item Use prefix based functions names to avoid clash. The prefix is of the form \texttt{[layer]\_[module]\_},
  for example \texttt{rpp\_din\_update()} for the update function of the DIN module in the RPP Layer.
\item To be very careful about symbol export. Because it is used as a static library the modules should
  not export any symbol that is not intended to be used (function) or \texttt{extern}'ed (variable) from
  application. As a rule of thumb declare all global variables as static.
\item Only the RPP Layer symbols are available to user applications. All information related to lower
  layers is hidden for the application. This is accomplished by conditionally including the layers
  elements on the implementations files only and never on the interface files. Never expose any
  other layer to the application or the the whole system below that layer will be exposed. In other
  words, never \texttt{\#include "foo/foo.h"} in any RPP Layer interface file.
\item Any module is conditionally included by using \texttt{rppCONFIG\_INCLUDE\_\{MNEMONIC\}} directive on the
  \texttt{RppConfig.h} configuration file.
\end{compactitem}

\vspace{-0.40cm}

\hypertarget{simulink_coder_target}{}
\subsection{Simulink Coder Target}

The Simulink Coder Target is the deliverable that will allow Simulink model's code generation, 
compilation and download for the board.

The Simulink RPP Target will provide support for C source code generation from Simulink models and
compilation of that code on top of the RPP library and the FreeRTOS operating system. This target
will use Texas Instrument ARM compiler (armcl) included in the Code Generation Tools available with
Code Composer Studio.

This library will also provide support for automatically download the compiled machine code to the 
RPP board.

\hypertarget{code_generation_process}{}
\subsubsection{Code generation process}

\begin{figure}[H]\begin{center}

\noindent\includegraphics[width=400px]{media/images/tlc_process.png}
\caption{TLC code generation process.}\end{center}\end{figure}

\hypertarget{simulink_block_library}{}
\subsection{Simulink Block Library}

\vspace{-0.25cm}

The Simulink Block Library will be a set of blocks that allows Simulink models to use board IO and 
communication peripherals.

\vspace{-0.5cm}

\hypertarget{c_mex_s_functions}{}
\subsubsection{C MEX S-Functions}

All of the blocks will be implemented as a C Mex S-Function coded by hand. In the this section the 
approach that will be taken is explained.

C-MEX S-Function:

 \begin{compactitem}
 \item C : Implemented in C language. Other options are Fortran and Matlab language itself.
 \item MEX: Matlab Executable. They are compiled by Matlab GCC wrapper called MEX.
 \item S-Function: System Function, as opposed to standard functions, or user functions.
 \end{compactitem}

A C-MEX S-Function is a structured C file that includes the following mandatory callbacks:

\begin{compactenum}
\item \texttt{mdlInitializeSizes}: \newline{}
  Specify the number of inputs, outputs, states, parameters, and other characteristics of the C 
  MEX S-function.
\item \texttt{mdlInitializeSampleTimes}: \newline{}
  Specify the sample rates at which this C MEX S-function operates.
\item \texttt{mdlOutputs}: \newline{}
  Compute the signals that this block emits.
\item \texttt{mdlTerminate}: \newline{}
  Perform any actions required at termination of the simulation.
\end{compactenum}

Plus many more optional callbacks. Relevant optional callbacks are:

\begin{compactenum}
\item \texttt{mdlCheckParameters}: \newline{}
  Check the validity of a C MEX S-function's parameters.
\item \texttt{mdlRTW}: \newline{}
  Generate code generation data for a C MEX S-function.
\item \texttt{mdlSetWorkWidths}: \newline{}
  Specify the sizes of the work vectors and create the run-time parameters required by the C MEX 
  S-function.
\item \texttt{mdlStart}: \newline{}
  Initialize the state vectors of the C MEX S-function.
\end{compactenum}

A complete list of callbacks can be found in:

        \begin{quotation}
\htmladdnormallink{http://www.mathworks.com/help/simulink/create-cc-s-functions.html}{http://www.mathworks.com/help/simulink/create-cc-s-functions.html}
        \end{quotation}

\newpage
The way a C-MEX S-Function participates in a Simulink simulation is shown by the following diagram:

\begin{figure}[H]\begin{center}

\noindent\includegraphics[width=250px]{media/images/sfunctions_process.png}
\caption{Simulation cycle of a S-Function.}\end{center}\end{figure}

In general, a S-Function can perform calculations and inputs and outputs for simulation. Because 
the blocks that will be implemented for this project are for hardware peripherals control and IO 
the blocks will be implemented as pure sink or pure source. That is, the S-Function will be a 
descriptor of the block but will not do any calculation or input or output for simulation. 

The S-Functions required could be implemented in several ways:

\begin{compactenum}
\item Writing the S-Function. \newline{}
  Using this method, the user hand write a new C S-Function and associated TLC file. This method 
  requires the most knowledge about the structure of a C S-Function.
\item Using an S-Function Builder block. \newline{}
  Using this method, the user enter the characteristics of the S-function into a block dialog. This 
  method does not require any knowledge about writing S-Functions. However, a basic understanding 
  of the structure of an S-Function can make the S-Function Builder dialog box easier to use.
\item Using the Legacy Code Tool (LCT). \newline{}
  Using this command line method, the user define the characteristics of your S-function in a data 
  structure in the MATLAB workspace. This method requires the least amount of knowledge about 
  S-Functions.
\end{compactenum}

From the above, the LCT is a tool that can be called within Matlab workshop that allows to generate 
source code for S-Functions given the descriptor of a C function call. This approach is used by
most of the other targets reviewed for this project. The descriptor is a Matlab file with 
definitions like the following:

\newpage
\lstset{language=}
\begin{lstlisting}
%% GPIO Write
% Populate legacy_code structure with information
GPIOWrite = legacy_code('initialize');
GPIOWrite.SFunctionName = 'sfun_GPIOWrite';
GPIOWrite.HeaderFiles = {'gpiolct.h'};
GPIOWrite.SourceFiles = {'gpiolct.c'};
GPIOWrite.OutputFcnSpec = 'GPIOWrite(uint32 p1, uint8 u1, uint8 u2)';
% Support calling from within For-Each subsystem
GPIOWrite.Options.supportsMultipleExecInstances = true;
\end{lstlisting}

The interface and implementation files specified should hold the declaration and implementation of
the \texttt{OutputFcnSpec} function. This tool will generate a simple S-Function that will input and 
output the values required by that function. This approach will \textbf{not} be used for this project, 
mainly because:

\begin{itemize}
\item The RPP Library requires that after some actions (like setting one LOUT output) the changes are 
  committed to the hardware, or before some other actions (like getting the value from DIN using 
  the fixed threshold) the values cached are updated. And the implementation of a wrapper function
  that would update or commit the changes wasn't considered because of the efficiency impact it
  would have.

\item Furthermore, the error handling of the function call is not considered, and for some blocks 
  (like MOUT and HOUT) the diagnostic handling is mandatory.

\item Also, the dialog parameters of the S-Function cannot be validated otherwise than data type 
  (cannot validate range, for example). 

\item For future improvements the LCT cannot generate code for simulation, and a lot of S-Function 
  options cannot not be fine tuned. 

\item Finally, the generated code is very obscure, hard to read and to maintain in case the above 
  functionality had to be implemented on top of the generated code.
\end{itemize}

Similarly hand written S-Functions share a large amount of code like parameters scalar, data 
type and range validation, standard options for this kind of blocks, unused functions, among other. 
Because of this a mini framework for writing S-Functions for RPP will be implemented in the form of 
two files that are directly included at the beginning and end of the S-Function implementation: 
\texttt{header.c} and  \texttt{trailer.c}. 

This mini-framework will reduce the amount of required code for each S-Function considerably, 
making easier to maintain and adapt. Because each S-Function is a program by itself there is no 
need to use interface files and the files are directly included.

\newpage
The final form of the S-Function will be a C file of around 100 lines of code with the following 
layout:

\begin{itemize}
\item Define S-Function name \texttt{S\_FUNCTION\_NAME}.

\item Include header file \texttt{header.c}.

\item In \texttt{mdlInitializeSizes} define:
 \begin{itemize}
 \item Number of \textit{dialog} parameter.
 \item Number of input ports.
  \begin{compactitem}
  \item Data type of each input port.
  \end{compactitem}
 \item Number of output ports.
  \begin{compactitem}
  \item Data type of each output port.
  \end{compactitem}
 \item Standard options for driver blocks.

 \end{itemize}
\item In \texttt{mdlCheckParameters}:
 \begin{itemize}
 \item Check data type of each parameter.
 \item Check range, if applicable, of each parameter.

 \end{itemize}
\item In \texttt{mdlSetWorkWidths}:
 \begin{compactitem}
 \item Map \textit{dialog} parameter to \textit{runtime} parameters.
  \begin{itemize}
  \item Data type of each \textit{runtime} parameter.

  \end{itemize}
 \end{compactitem}
\item Define symbols for unused functions.

\item Include trailer file \texttt{trailer.c}.
\end{itemize}

The C-MEX S-Function implemented will compile with the following command:

\lstset{language=bash}
\begin{lstlisting}
<matlabroot>/bin/mex sfunction_{mnemonic}.c
\end{lstlisting}

As noted the standard is to always prefix S-Function with \texttt{sfunction\_} and use lower case 
mnemonic of the block.

Also a script called \texttt{compile\_blocks.m} will be included that will allows all \texttt{sfunctions\_*.c} 
to be fed to the \texttt{mex} compiler so all S-Functions are compiled at once.

\newpage

\hypertarget{target_language_compiler_files}{}
\subsubsection{Target Language Compiler files}

C code generated from a Simulink model will be placed on a file called \texttt{$<$modelname$>$.c} along with 
other support files in a folder called \texttt{$<$modelname$>$\_$<$target$>$/}. For example, the source code
generated for model \texttt{foobar} will be placed in current Matlab directory \texttt{foobar\_rpp/foobar.c}.

The file \texttt{$<$modelname$>$.c} has 3 main functions:

\begin{compactitem}
\item \texttt{void $<$modelname$>$\_step(void)}: \newline{}
  This function recalculates all the outputs of the blocks and should be called once per step. This
  is the main working function.
\item \texttt{void $<$modelname$>$\_initialize(void)}: \newline{}
  This function is called only once before the first step is issued. Default values for blocks IOs
  should be placed here.
\item \texttt{void $<$modelname$>$\_terminate(void)}: \newline{}
  This function is called when terminating the model. This should be used to free memory of revert 
  other operations made on the initialization function. With current implementation this function
  should never be called unless an errors is detected and in most models it is empty.
\end{compactitem}

In order to generate code for each one of those functions each S-Function will implement a TLC file
for \textit{inlining} the S-Function on the generated code. The TLC files are files that describe how to 
generate code for a specific C-MEX S-Function block. They are programmed using TLC own language and 
include C code within TLC instructions, just like LaTeX files include normal text in between LaTeX 
macros.

TLC files will be located under \texttt{$<$repo$>$/rpp/blocks/tlc\_c/} directory. For a diagram on how TLC 
files work see \htmladdnormallink{Code generation process}{\#code\_generation\_process} section.

The standard for a TLC file is to be located under the \texttt{tlc\_c} subfolder from where the 
S-Function is located and to use the very exact file name as the S-Function but with the \texttt{.tlc}
extension:

\texttt{sfunction\_foo.c} \noindent$\rightarrow$ \texttt{tlc\_c/sfunction\_foo.tlc}

The TLC files that will be implemented for this project use 3 hook functions in particular (other 
are available, see TLC reference documentation):

\begin{itemize}
\item \texttt{BlockTypeSetup}: \newline{}
  BlockTypeSetup executes once per block type before code generation begins.
  This function can be used to include elements required by this block type, like includes or
  definitions.

\item \texttt{Start}: \newline{}
  Code here will be placed in the \texttt{void $<$modelname$>$\_initialize(void)}. Code placed here will
  execute only once.

\item \texttt{Outputs}: \newline{}
  Code here will be placed in the \texttt{void $<$modelname$>$\_step(void)} function. Should be used to 
  get the inputs o a block and/or to set the outputs of that block.
\end{itemize}

The general layout of the TLC files that will be implemented for this project are:

\begin{itemize}
\item In \texttt{BlockTypeSetup}: \newline{}
  Call common function \texttt{\%$<$RppCommonBlockTypeSetup(block, system)$>$} that will include the 
  \texttt{rpp/rpp.h} header file (can be called multiple times but header is included only once).

\item \texttt{Start}: \newline{}
  Call setup routines from RPP Layer for the specific block type, like HBR enable, DIN pin setup, 
  AOUT value initialization, SCI baud rate setup, among others.

\item \texttt{Outputs}: \newline{}
  Call common IO routines from RPP Layer, like DIN read, AOUT set, etc. Success of this functions
  is checked and in case of failure error is reported to the block using ErrFlag.
\end{itemize}

\hypertarget{simulink_demos_library}{}
\subsection{Simulink Demos Library}

The Simulink RPP Demo Library will be a set of Simulink models that use blocks from the 
Simulink RPP Block Library and generates code using the Simulink RPP Target.

The demos library will be used as a test suite for the Simulink RPP Block Library but it is also
intended to show basic programs built using it. Because of this, the demos will try to use more 
than one type of block and more than one block per block type.

The following table shows the specification and status of the demos:

\begin{center}\begin{tabular}{|l|l|l|}
\hline \textbf{Name} & \textbf{Implemented} & \textbf{Tested} \\
\hline analog\_passthrough & \multicolumn{1}{|c|}{NO} & \multicolumn{1}{|c|}{NO YET} \\
\hline analog\_sinewave & \multicolumn{1}{|c|}{NO} & \multicolumn{1}{|c|}{NO YET} \\
\hline digital\_passthrough & \multicolumn{1}{|c|}{NO} & \multicolumn{1}{|c|}{NO YET} \\
\hline echo\_char & \multicolumn{1}{|c|}{NO} & \multicolumn{1}{|c|}{NO YET} \\
\hline hbridge\_analog\_control & \multicolumn{1}{|c|}{NO} & \multicolumn{1}{|c|}{NO YET} \\
\hline hbridge\_digital\_control & \multicolumn{1}{|c|}{NO} & \multicolumn{1}{|c|}{NO YET} \\
\hline hbridge\_sinewave\_control & \multicolumn{1}{|c|}{NO} & \multicolumn{1}{|c|}{NO YET} \\
\hline hello\_world & \multicolumn{1}{|c|}{NO} & \multicolumn{1}{|c|}{NO YET} \\
\hline led\_blink\_all & \multicolumn{1}{|c|}{NO} & \multicolumn{1}{|c|}{NO YET} \\
\hline led\_blink & \multicolumn{1}{|c|}{NO} & \multicolumn{1}{|c|}{NO YET} \\
\hline log\_analog\_input & \multicolumn{1}{|c|}{NO} & \multicolumn{1}{|c|}{NO YET} \\
\hline power\_toggle & \multicolumn{1}{|c|}{NO} & \multicolumn{1}{|c|}{NO YET} \\
\hline \end{tabular}\end{center}

\newpage

\hypertarget{work_schedule}{}
\section{Work schedule}

\begin{center}\begin{tabular}{|c|c|l|}
\hline \textbf{Date} & \textbf{Deliverable} & \textbf{Priority} \\
\hline \multicolumn{1}{|l|}{15.4.2013} & \multicolumn{1}{|l|}{C support library and test suite.} & \multicolumn{1}{|c|}{1} \\
\hline \multicolumn{1}{|l|}{01.5.2013} & \multicolumn{1}{|l|}{Simulink Coder target for RPP board.} & \multicolumn{1}{|c|}{2} \\
\hline \multicolumn{1}{|l|}{01.6.2013} & \multicolumn{1}{|l|}{Simulink Block library. S-Functions and TLC files.} & \multicolumn{1}{|c|}{3} \\
\hline \multicolumn{1}{|l|}{07.6.2013} & \multicolumn{1}{|l|}{Simulink Demo  library.} & \multicolumn{1}{|c|}{4} \\
\hline \multicolumn{1}{|l|}{21.6.2013} & \multicolumn{1}{|l|}{Finish documentation of the developed product.} & \multicolumn{1}{|c|}{5} \\
\hline \end{tabular}\end{center}

\end{document}