\def\tgtIdTMSHDK{tms570\_hdk}
\def\tgtIdRMHDK{rm48\_hdk}
\def\tgtIdTMSRPP{tms570\_rpp}
+\def\tgtIdHydCtr{tms570\_hydctr}
% Include target specific macros etc.
-\input{rpp_simulink_target.tex}
+\input{target_def}
\begin{document}
\vspace{0.4cm}
{\huge \bfseries Simulink code generation target for Texas~Instruments
\tgname{} platform\par}
+\vspace{0.8cm}
+{\Large Version for \tgtBoardName{} board\par}
\vspace{0.4cm}
\HRule \\[1.5cm]
platforms by
recompilation. \\ \hline
- ? & ? & Sojka & Updated section \ref{sec:adding-new-funct}.
+ 0.5 beta & 2015-07-03 & Sojka & Updated section \ref{sec:adding-new-funct}.
+ Added support for Eaton Hydraulics
+ Controller board (TMS570LS1227).
+ \\\hline
+ 0.5.5 & 2015-08-27 & Sojka, Horn & rpp-lib: HAL merged into DRV
+ layer, FreeRTOS upgraded to version 8.2.2.
\\\hline
\end{tabularx}
\label{chap-introduction}
This text documents software part of Rapid Prototyping Platform (RPP)
-project for Texas Instruments \tgname{} safety microcontroller. The
-software consists of code generation target for Simulink Embedded
-Coder, a low-level run-time C library and a tool for interactive
-testing of hardware and software functionality.
+project for Texas Instruments \tgname{} safety microcontroller
+developed by Czech Technical University in Prague (CTU). The software
+consists of code generation target for Simulink Embedded Coder, a
+low-level run-time C library and a tool for interactive testing of
+hardware and software functionality.
Originally, the RPP project was created for a custom TMS570-based board
and the port to other platforms such as RM48 HDK and TMS570 HDK
\label{sec-background}
In this document, the term \emph{Rapid Prototyping Platform} denotes a
-hardware board and accompanying software. The hardware is
-\develkitname{} development kit from Texas Instruments based on ARM
-Cortex R4 safety microcontroller \mcuname{}. This MCU contains several
-protective mechanisms (two cores in lockstep, error correction
-mechanisms for SRAM and Flash memory, voltage monitoring, etc.) to
-fulfill the requirements for safety critical applications.
-See~\cite{\tgrefman} for details.
+hardware board and accompanying software. The hardware board is
+\tgtBoardName{} based on ARM Cortex R4 safety microcontroller
+\mcuname{}. This MCU contains several protective mechanisms (two cores
+in lockstep, error correction mechanisms for SRAM and Flash memory,
+voltage monitoring, etc.) to fulfill the requirements for safety
+critical applications. See~\cite{\tgrefman} for details.
In order to develop non-trivial applications for the RPP, an operating
system is necessary. The RPP is based on FreeRTOS -- a simple
another block. This block can implement some clever algorithm and its
output is passed to another block, which sends the computed value as a
message over CAN bus to some other MCU. Such a model can be simulated
-and tested even before the real hardware is available by replacinf the
+and tested even before the real hardware is available by replacing the
input and output blocks with simulated ones. Once the hardware is
ready, C code is automatically generated from the model by a Simulink
Coder. The code is then compiled by the MCU compatible compiler and
\section{Hardware description}
\label{sec-hardware-description}
-This section provides a brief description of the Texas Instrument
-\develkitname{} development kit. For a more detailed information refer to
-\cite{\tghdkman}. The kit is depicted in
-Figure~\ref{fig-board_photo}.
-
-\begin{figure}\begin{center}
- \noindent
- \includegraphics[width=300px]{images/board.png}
- \caption{The \develkitname{} kit \cite[p. 8]{\tghdkman}}
- \label{fig-board_photo}
-\end{center}\end{figure}
-
-Only a subset of peripherals available on the kit is currently
-supported by the RPP software. A block diagram in
-Figure~\ref{fig-blocks} ilustrates the supported peripherals and their
-connection to the MCU, expansion connectors and other components on
-the development kit. For pinout description of the implemented
-peripherals refer the \tgname{} HDK User's Guide
-\cite{\tghdkman}. The main features of supported
-peripherals are provided in the following subsections.
-
-\begin{figure}\begin{center}
- \noindent
- \includegraphics[width=400px]{images/blocks.png}
- \caption{Block diagram of supported peripherals}
- \label{fig-blocks}
-\end{center}\end{figure}
-
-\subsection{Digital Inputs and Outputs (DIN and DOUT)}
-\label{par-digital-inputs-outputs}
- \begin{compactitem}
- \item 46 pins available on Expansion connector J11.
- \item 8 pins available on GIOA
- \item 8 pins available on GIOB
- \item 30 pins available on NHET1. Pins NHET1 6 and NHET1 13 are disabled.
- \item All the pins are configurable as inputs and outputs with different modes:
- \begin{compactitem}
- \item Push/Pull or Open Drain for Output configuration.
- \item Pull up, Pull down or tri-stated for Input configuration.
- \end{compactitem}
- \item Some of the pins are connected to LEDs or to a button. See
- Figure~\ref{fig-blocks} or refer to~\cite{\tghdkman}.
- \end{compactitem}
-
-\subsection{Analog Input (ADC)}
-\label{par-analog-input}
-\vbox{% Keep this on the same page
- \begin{compactitem}
- \item 16 channels available on the Expansion connector J9.
- \item Range for 0 -- 5 Volts.
- \item 12 bits resolution.
- \end{compactitem}
-}
-\subsection{CAN bus (CAN)}
-\label{par-can}
-\begin{compactitem}
- \item Up to three CAN ports
- \begin{compactitem}
- \item 2 ports equipped with physical layer CAN transciever
- connected to J2 and J3 connectors.
- \item All 3 ports available as link-level interface on the
- Expansion connector J11.
- \end{compactitem}
- \item High speed.
- \item Recovery from errors.
- \item Detection of network errors.
-\end{compactitem}
-
-\subsection{Serial Communication Interface (SCI)}
-\label{par-sci}
-\begin{compactitem}
- \item 1 port available on connector J7.
- \item Configurable baud rate. Tested with 9600 and 115200 bps.
- \item RS232 compatible.
-\end{compactitem}
+\input{hwdesc}
\section{Software architecture}
\label{sec-software-architecture}
% 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 that top layers depends on the layer interface
+ \texttt{os.h}), so that higher layers depend on the lower layer's interface
and not on individual elements from that layer.
\end{compactitem}
\subsection{Operating System layer}
\label{sec-operating-system-layer}
-This is an interchangeable operating system layer, containing the
+This is an interchangeable operating system (OS) layer containing the
FreeRTOS source files. The system can be easily replaced by another
version. For example it is possible to compile the RPP library for
Linux (using POSIX version of the FreeRTOS), which can be desirable
The following FreeRTOS versions are distributed:
\begin{description}
- \item[6.0.4\_posix] POSIX version, usable for compilation of the library
-for Linux system.
- \item[7.0.2] Preferred version of the FreeRTOS, distributed by
-Texas Instruments. This version has been tested and is used in the current
-version of the library.
- \item[7.4.0] Newest version distributed by the Texas Instruments.
- \item[7.4.2] Newer version available from FreeRTOS pages. Slightly
-modified to run on \tgname{} MCU.
+\item[6.0.4\_posix] POSIX version, usable for compilation of the
+ library for Linux system.
+\item[8.2.2] Currently used FreeRTOS version. This is the version
+ downloaded from FreeRTOS.org with changes in directory structure.
+ Namely, include files have added the \emph{os/} prefix and platform
+ dependent code (portable) for \tgname{} is copied to the same
+ directory as platform independent code.
\end{description}
-\noindent
-Both 7.4.x version were tested and work, but the testing was not so
-extensive as with the used 7.0.2 version.
-
\subsection{System Layer}
\label{sec-system-layer}
This layer contains system files with data types definitions, clock definitions,
folder.
Large part of this layer was generated by the HalCoGen tool (see
-Section~\ref{sec-halcogen}).
-
-\subsection{HAL abstraction layer}
-\label{sec-hal-abstraction-layer}
-Hardware Abstraction Layer (HAL) provides an abstraction over the real
-hardware. For example imagine an IO port with 8 pins. First four pins
-are connected directly to the GPIO pins on the MCU, another four pins
-are connected to an external integrated circuit, communicating with
-the MCU via SPI. This layer allows to control the IO pins
-independently of how that are connected to the MCU, providing a single
-unified API.
-
-Note that this functionality is not needed in the current version of
-for \develkitname, because all IOs are controlled directly by GPIO pins.
-
-As a result, the higher layers do not have to know anything about the
-wiring of the peripherals, they can just call read, write or configure
-function with a pin name as a parameter and the HAL handles all the
-details.
-
-The source files can be found in
-\texttt{$\langle$rpp\_lib$\rangle$/rpp/src/hal} and the header files can
-be found in \texttt{$\langle$rpp\_lib$\rangle$/rpp/include/hal} folder.
+Section~\ref{sec-halcogen}). Some files were then modified by hand.
\subsection{Drivers layer}
\label{sec-drivers-layer}
The Drivers layer contains code for controlling the RPP peripherals.
Typically, it contains code implementing IRQ handling, software
queues, management threads, etc. The layer benefits from the lower
-layers thus it is not too low level, but still there are some
+layer thus it is not too low level, but still there are some
peripherals like ADC, which need some special procedure for
initialization and running, that would not be very intuitive for the
-user.
+typical end user.
The source files can be found in
\texttt{$\langle$rpp\_lib$\rangle$/rpp/src/drv} and the header files can
\label{sec-matlab-simulink}
Matlab Simulink is a set of tools, runtime environment and development
environment for Model--Based \cite{modelbasedwiki2013} applications development,
-simulations and generation code for target platforms. Supported Matlab Simulink
+simulations and code generation for target platforms. Supported Matlab Simulink
version is R2013b for 64 bits Linux and Windows. A licence for an Embedded Coder is
necessary to be able to generate code from Simulink models, containing RPP blocks.
The tool is available for Windows at
\begin{quotation}
-\url{http://www.ti.com/tool/halcogen?keyMatch=halcogen&tisearch=Search-EN}
+\url{http://www.ti.com/tool/halcogen}
\end{quotation}
The HalCoGen has been used in early development stage of the RPP
headers and other files necessary for building and downloading
Simulink models.
\item[rpp-test-sw] Contains an application for interactive testing and
- control of the \develkitname{} board over the serial interface. Details can be
+ control of the \tgtBoardName{} board over the serial interface. Details can be
found in Chapter~\ref{chap-rpp-test-software}.
The package also contains the binary of the RPP Library and all
The following sections describe how to start working with individual
packages.
+\ifx\tgtId\tgtIdTMSRPP
+\subsection{Getting sources from git repository}
+\begin{verbatim}
+git clone --recursive git@rtime.felk.cvut.cz:jenkicar/rpp-simulink
+\end{verbatim}
+If you get release packages, follow the instructions in the next sections.
+\fi
+
\subsection{rpp-simulink}
\label{sec-rpp-simulink-installation}
This section describes how to install the rpp-simulink project, which
\item Configure the compiler \#include search path to contain
project's \texttt{include} directory, \penalty-100
- \texttt{\$\{RPP\_LIB\_ROOT\}/os/7.0.2/include} and
+ \texttt{\$\{RPP\_LIB\_ROOT\}/os/8.2.2/include} and
\texttt{\$\{RPP\_LIB\_ROOT\}/rpp/include}, in that order.
\includegraphics[scale=.43]{images/base_5.png}
\item Connect the Texas Instruments XDS100v2 USB emulator to the JTAG port.
\item Connect a USB cable to the XDS100v2 USB emulator and the development computer.
\else
- \item Connect the USB cable to the \develkitname{} board.
+ \item Connect the USB cable to the \tgtBoardName{} board.
\fi
\item Plug in the power supply.
\item In the Code Composer Studio click on the
Code $\rightarrow$ Build Model}.
\end{enumerate}
-To run the model on the \develkitname{} board continue with Section
+To run the model on the \tgtBoardName{} board continue with Section
\ref{sec-running-model-on-hw}.
\subsection{Running models on the RPP board}
\label{sec-running-model-on-hw}
-To run the model on the \develkitname{} hardware you have to enable the download
+To run the model on the \tgtBoardName{} hardware you have to enable the download
feature and build the model by following this procedure:
\begin{enumerate}
\item Open the model you want to run (see
\end{itemize}
Use GtkTerm on Linux or Bray Terminal on Windows for accessing the
-serial interface. On \develkitname{}, the serial line is tunneled over
-the USB. % See Section \ref{sec-hardware-description} for reference about
+serial interface. On \tgtBoardName{} board, the serial line is tunneled over
+the USB.
+% TODO: Conditional compilation
+ % See Section \ref{sec-hardware-description} for reference about
% the position of the serial interface connector on the RPP board.
\section{Bug reporting}
\begin{compactitem}
\item Configure include search path to contain the directory of
used FreeRTOS version, e.g.
- \texttt{\repo/os/7.0.2/include}. See Section
+ \texttt{\repo/os/8.2.2/include}. See Section
\ref{sec-software-architecture}.
\item Include \texttt{rpp/rpp.h} header file or just the needed
peripheral specific header files such as \texttt{rpp/can.h}.
\section{Changing operating system}
\label{sec-changing-os}
The C Support Library contains by default the FreeRTOS operating
-system in version 7.0.2. This section describes what is necessary to
+system in version 8.2.2. This section describes what is necessary to
change in the library and other packages in order to replace the
operating system.
the operating system header files.
Current implementation for FreeRTOS includes a header file
-\texttt{\repo/rpp/lib/os/\-7.0.2\-include/os.h}, which
+\texttt{\repo/rpp/lib/os/\-8.2.2\-include/os.h}, which
contains all necessary declarations and definitions for the FreeRTOS.
We suggest to provide a similar header file for your operating system as
well.
wrapper on the \texttt{loadti.sh}, \texttt{loadti.bat} and \texttt{loadopenocd.sh} script. More information on the \texttt{loadti.sh}
script can be found in:
\begin{verbatim}
-<css>/ccs_base/scripting/examples/loadti/readme.txt
+<ccs>/ccs_base/scripting/examples/loadti/readme.txt
http://processors.wiki.ti.com/index.php/Loadti
\end{verbatim}
\item \textbf{Use OpenOCD to download the compiled binary}: This feature is not yet
implemented for the \mcuname{} simulink target.
+% TODO Not true - use conditional compilation here.
\item \textbf{Print model metadata to SCI at start}: if set this option will
print a message to the Serial Communication Interface when the model start
\item[refs/] Contains third party references, which license allows the
distribution.
\item[rpp/blocks] Contains the Simulink blocks specific to the
- \develkitname{} board and their sources (.c and .tlc files). When an
+ \tgtBoardName{} board and their sources (.c and .tlc files). When an
user calls \texttt{rpp\_setup.m}, these files are processed and
Simulink block library \texttt{rpp\_lib.slx} is created.
\item[rpp/blocks/tlc\_c]Contains the templates for C code generation from the
\item \texttt{Outputs}: \newline{}
Code here will be placed in the \texttt{void
$\langle$modelname$\rangle$\_step(void)} function. Should be used to get the
-inputs o a block and/or to set the outputs of that block.
+inputs of a block and/or to set the outputs of that block.
\end{itemize}
-The general layout of the TLC files implemented for this project are:
+The general layout of the TLC files implemented for this project is:
\begin{itemize}
\item In \texttt{BlockTypeSetup}: \newline{}
Call common function \texttt{\%$<$RppCommonBlockTypeSetup(block, system)$>$} that will include the
This function is called only once before the first step is issued. Default values for blocks IOs
should be placed here.
\item \texttt{void $\langle$modelname$\rangle$\_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
+ This function is called when terminating the model. This should be used to free memory or revert
+ other operations made in the initialization function. With current implementation this function
should never be called unless an error is detected and in most models it is empty.
\end{compactitem}
"C:\ti\ccsv5\utils\bin\"gmake.exe lib
\end{lstlisting}
-Both commands will create a directory for each compiled demo, which will contai the generated C code and binary file with the firmware. To download the firmware to the board and run it see Section \ref{sec-running-software-on-hw}.
+Both commands will create a directory for each compiled demo, which will contain the generated C code and binary file with the firmware. To download the firmware to the board and run it, see Section \ref{sec-running-software-on-hw}.
\end{enumerate}
\section{Adding new functionality}
specifies graphical representation of the block as well as
the content of the block parameters dialog box.
\end{enumerate}
-The following subsections demonstrates the procedure on an example of a simple user defined block.
+The following subsections demonstrate the procedure on an example of a simple user defined block.
\subsection{Block interface definition in a C MEX S-function}
\label{sec:block-definition-c}
\item Outputs
\end{enumerate}
-For detail description about each one of those functions, refer to
+For detailed description about each one of those functions, refer to
\cite{targetlanguagecompiler2013}. A simple TLC file, which generates
some code may look like this:
\begin{lstlisting}[language=c]
\label{sec-rpp-test-sw-intro}
The \texttt{rpp-test-suite} is a RPP application developed testing and direct
control of the RPP hardware. The test suite implements a command processor,
-which is listening for a commands and prints some output related to the commands
+which is listening for commands and prints some output related to the commands
on the serial interface. The command processor is modular and each peripheral
-has its commands in a separated module.
+has its commands in a separate module.
The command processor is implemented in \texttt{$\langle$rpp-test-sw$\rangle$/cmdproc} and commands
modules are implemented in \texttt{$\langle$rpp-test-sw$\rangle$/commands} directory.
\textbf{115200-8-N-1}. When the software starts, the received welcome message
and prompt should look like:
+
+\ifx\tgtId\tgtIdTMSRPP
+\begin{verbatim}
+Rapid Prototyping Platform v00.01-001
+Test Software version v0.2-261-gb6361ca
+CTU in Prague 2014
+-->
+\end{verbatim}
+\else
\begin{verbatim}
Ti HDK \mcuname, FreeRTOS 7.0.2
Test Software version eaton-0.1-beta-8-g91419f5
CTU in Prague 10/2014
-->
\end{verbatim}
+\fi
Type in command help for a complete list of available command, or help command
for a description of concrete command.
projects / pes-rpp / rpp-simulink.git / blobdiff