6 %!style(xhtmls): media/themes/Clean/style.css
7 %!postproc(xhtmls): 'NEWPAGE' ''
8 %!nested(xhtmls): --libs syntaxhighlighter
9 %!options(tex): --enum-title --toc --toc-level 5
10 %!postproc(tex): '\.pdf\.png' '.pdf'
11 %!postproc(tex): 'NEWPAGE' '\\newpage'
12 %!postproc(tex): '-\$>\$' '\\noindent$\\rightarrow$'
13 %!postproc(tex): 'TAB' '\\hspace{1.0em}'
14 %!nested(tex): --docclass {article} --pdf
16 %S = Table of contents =[table_of_contents]
26 %tex% ''' \listoffigures
30 = Introduction =[introduction]
34 This document describes the final results of the project ``Code generation for automotive rapid prototyping
35 platform using Matlab/Simulink".
37 The general layout of this document is as follows:
39 - Project description, objectives and outcome. This section.
40 - Software and Hardware setup for development, repository layout and programming standards.
41 - A section for each of the four products delivered, with:
42 - Implementation fundamentals.
43 - Repository branch description.
44 - Product specific aspects.
45 - Reference documentation.
52 == Background ==[background]
56 Back in the beginning of 2012 a leading automotive company requested the Czech Technical University to
57 develop a Engine Control Unit (ECU) for automotive applications. Real-Time Systems group at the Department
58 of Control Engineering from the Faculty of Electrical Engineering developed a hardware and Software
59 platform to the needs of this industry. The hardware uses Texas Instruments TMS570LS3137 CPU and has was
60 built with automotive standards and interfaces in mind. It uses a real-time operating system and was
61 directly programmed in C.
63 Nevertheless, in accordance to company policies the Software developed for the engine control unit must be
64 designed in a safe and auditable way. The company has the policy to implement the Software for their
65 system using Model-Based Design:
67 Model-Based Design (MBD) is a mathematical and visual method of addressing
68 problems associated with designing complex control, signal processing and
69 communication systems. It is used in many motion control, industrial equipment,
70 aerospace, and automotive applications. Model-based design is a methodology
71 applied in designing embedded software.
73 In order to meet this requirement an interaction layer between the platform and the Software the company
74 uses, Matlab/Simulink, must be implemented. This document describes the implementation of this interaction
79 == Technologies involved ==[technologies_involved]
83 + Matlab/Simulink data flow graphical programming language tool for modeling, simulating and analyzing
84 multidomain dynamic systems.
85 + Standard ANSI C programming.
86 + FreeRTOS real-time operating system.
87 + Texas Instruments TI Code Generation Tools (CGT).
88 + RPP in-house automotive hardware board using Texas Instruments TMS570LS3137 CPU.
91 == Objectives ==[objectives]
95 Main objectives of this project are:
97 + Allow C code generation from Matlab/Simulink models for custom made hardware platform.
98 + Implement model blocks for some of the peripheral units of the board for use in Simulink programming.
101 At the time of this writing the objectives of this project are considered successfully achieved.
103 == Benefits ==[benefits]
107 Expected benefits of this project are:
109 + Enabling faster implementation and rapid-prototyping of Software components through the use of model-based
111 + Enabling better and clearer visualization of Software implementations for the hardware board through models.
112 + Improve auditability of Software system for automotive applications.
115 At the time of this writing the benefits of this project are considered enabled.
117 == Final outcome ==[final_outcome]
121 The main products generated for this project are:
123 - Simulink RPP Target.
124 - RPP Library and API.
125 - Simulink RPP Block Library.
126 - Simulink RPP Demo Library.
129 Each of this product is described deeply in the following sections.
131 = Project setup =[project_setup]
135 This sections describes the Software and Hardware aspects required to undertake development for
136 this project. It considers:
138 - Software development environment.
139 - Hardware reference documentation and wiring for development.
140 - Repository's general layout.
143 == Development environment ==[development_environment]
147 This section describes the Software environment setup for development.
149 === Operating system ===[operating_system]
153 This project was developed on a GNU/Linux operating system. For development it is recommended to use a
154 Debian based operating system for development as most of the tools are easily available from repositories.
155 Relevant OS information is:
157 - Ubuntu 12.04.2 LTS AMD64.
158 - Kernel 3.2.0-48-generic.
162 No test for cross-platform interoperability was performed on the code developed. Although care was taken
163 to try to provide platform independent code and tools this are the elements that are know to be Linux
166 - LCM1 hardware control tool. @@
167 This tool is both GUI and command line capable, the following just affects the GUI part.
168 Command line should be usable under Windows systems. @@
169 __Cause__: Serial port search algorithm is Linux dependent and Gtk 3.0 dynamic Python bindings are not
170 available on Windows operating systems.
171 - TI CGT support file for RPP Simulink Target ``target_tools.mk``. @@
172 __Cause__: Use UNIX path separator ``/``.
173 - Simulink RPP Target download script ``rpp_download.m``. @@
174 __Cause__: Use UNIX path separator ``/``.
175 - Simulink RPP Target install script ``rpp_setup.m``. @@
176 __Cause__: Use UNIX path separator ``/``.
177 - Simulink RPP Block Library block compilation script ``compile_blocks.m``. @@
178 __Cause__: Call Matlab MEX executable with Unix name.
179 - All CCS projects under ``<repo>/rpp/lib/apps/``. @@
180 __Cause__: Paths are configure using UNIX path separator ``/``.
184 === Version Control System ===[version_control_system]
188 The version control system used for this project is **git**. The repository of this project contains all
189 the files produced during development, including documentation, references, code and graphics. Also the
190 GUI application **giggle** was used to easily review changes. To install both execute on a terminal:
193 sudo apt-get install git giggle
196 === TI Code Composer Studio ===[ti_code_composer_studio]
200 Code Composer Studio (CCS) is the official Integrated Development Environment (IDE) for developing
201 applications for Texas Instruments embedded processors. CCS is multiplatform Software based on Eclipse
204 The version used in this project is the 5.3.0. Download and install CCS for Linux from:
206 http://processors.wiki.ti.com/index.php/Category:Code_Composer_Studio_v5
208 CCS download requires a valid MyTI account. Tedious. CCS download is about 1.5GB. Once downloaded extract
209 the content of the ``tar.gz`` archiver and run ``css_setup_<version>.bin`` script as __root__. Installation
210 must done as root in order to install driver set.
212 After installation the application can be executed with:
215 cd <ccs>/ccsv5/eclipse/
219 If the application fails to start on 64bits systems is because CCS5 is a 32bits application a thus requires
223 sudo apt-get install libgtk2.0-0:i386 libxtst6:i386
226 If the application crashes with a segmentation fault edit file:
229 nano <ccs>/ccsv5/eclipse/plugins/com.ti.ccstudio.branding_<version>/plugin_customization.ini
232 And change key ``org.eclipse.ui/showIntro`` to false.
234 Choose ``FREE License - for use with XDS100 JTAG Emulators" on the licensing options. Code download for the
235 board is uses that particular hardware. See [Hardware configuration #hardware_configuration] for more details
238 CCS include Texas Instruments Code Generation Tools (CGT) (compiler, linker, etc). Simulink code generation
239 requires the CGT to be available in the system, and thus, even if no library development will be done or the
240 IDE is not going to be used CCS is still required. See ``<repo>/rpp/rpp/README.txt`` file for more information.
242 You can find documentation for CGT compiler in ``<repo>/ref/armcl.pdf`` and for CGT archiver in
243 ``<repo>/ref/armar.pdf``.
246 === Matlab/Simulink ===[matlabsimulink]
250 Matlab/Simulink version used is R2012b for Linux 64 bits. For in-house development the CVUT should provide a
251 network licensing server descriptor file.
253 === GtkTerm ===[gtkterm]
257 Most of the interaction with the board for development is done through a RS-232 serial connection.
258 The terminal Software used for communication is called GtkTerm.
260 The default configuration for the board serial communication module is 9600-8-N-1. Note that the RPP
261 Library test suite is setup to 115200-8-N-1.
263 To install GtkTerm execute:
266 sudo apt-get install gtkterm
270 === Doxygen ===[doxygen]
274 Doxygen is the name of the documentation generator used to generate the RPP API documentation based on the
275 source code files. The generated API include dependency graphs and thus it also requires Graphviz, a graph
276 drawing tool. To install both execute:
279 sudo apt-get install doxygen graphviz
282 See [API generation #api_generation] on how to use Doxygen to generate the API Reference documentation.
286 === Nested ===[nested]
290 Nested is the documentation editor used to create the document you're reading. It features a plain text
291 version control friendly simple to read non-cluttered format, WYSIWYM paradigm, divide and conquer document
292 creation approach, a nested (non-linear) document tree and content/presentation separation scheme and thus
293 documents can be published to LaTeX, PDF or HTML. Nested is a tool created by the author of this report.
295 To install Nested first install dependencies:
298 sudo apt-get install python2.7 python-gtk2 python-webkit python-gtkspellcheck texlive-publishers texlive texlive-latex-extra rubber iso-codes subversion
301 Then get the latest revision from the stable repository:
304 svn checkout svn://svn.code.sf.net/p/nestededitor/code/trunk nested
314 Nested sources for this document can be found on the repository under ``<repo>/doc/reports/report/``.
320 The LMC1 is a simple script developed for this project written in Python 3 using Gtk+ 3.0 Python dynamic
321 bindings PyGObject. This script, based on Michal Horn command line only script, allows to set or clear the
322 outputs of the test board.
324 This script includes both a GUI and command line tool. If no parameters are given to the script the GUI
327 %tex% ''' \begin{figure}[H]\begin{center}
329 %tex% ''' \caption{LMC1 GUI application.}\end{center}\end{figure}
331 To run the LMC1 application first install dependencies:
334 apt-get install python3 python3-gi python3-serial
337 To launch LMC1 GUI version double click file:
339 ``<repo>/rpp/lib/apps/lmc1/lmc1.py``
341 To launch LMC1 command line version type:
343 ``<repo>/rpp/lib/apps/lmc1/lmc1.py --help``
348 == Hardware reference ==[hardware_reference]
350 This section provides reference documentation for the RPP board:
353 - Modules capabilities and features.
354 - Wiring configuration for development and testing.
357 Please note that although this is a hardware reference documentation this is from a Software
358 development perspective and __**NOT**__ Hardware development perspective. For full hardware
359 details please refer to schematics and related documentation.
361 %tex% ''' \begin{figure}[H]\begin{center}
363 %tex% ''' \caption{The RPP board (signal connector missing).}\end{center}\end{figure}
365 === Connectors pinout ===[connectors_pinout]
367 %tex% ''' \begin{figure}[H]\advance\leftskip-1cm
369 %tex% ''' \caption{The RPP connectors pinout.}\end{figure}
372 === Modules description ===[modules_description]
376 ==== Logic IO ====[logic_io]
380 ===== 16x digital input (DIN) =====[16x_digital_input_din]
382 - Read status via GPIO pin (configurable threshold).
383 - Read status via SPI pin (fixed threshold).
384 - Setting pin programmable via SPI.
387 ===== 8x digital outputs for loads up to 100 mA (LOUT) =====[8x_digital_outputs_for_loads_up_to_100_ma_lout]
391 - Reading the SPI status excitation.
393 ===== 12x analog-to-digital converter =====[12x_analog_to_digital_converter]
395 - Reading values on all channels.
397 ===== 4x digital-to-analog converter =====[4x_digital_to_analog_converter]
399 - Set the required voltage on all channels.
401 ==== Power Output ====[power_output]
405 ===== 1x H-Bridge =====[1x_h_bridge]
407 - Setting the direction.
409 - Communication with excitation by SPI.
413 ===== 6x outputs for loads up to 2 A (MOUT) =====[6x_outputs_for_loads_up_to_2_a_mout]
417 - Reading diagnostics values (DIAG).
419 ===== 6x output up to 10 A with PWM (HOUT) =====[6x_output_up_to_10_a_with_pwm_hout]
423 - Reading analog values of current flowing (IFBK).
424 - Reading diagnostics values (DIAG).
425 - Detection of a fault condition.
426 - Turn on the PWM pin.
428 ==== Communication ====[communication]
432 ===== 3x CAN High speed =====[3x_can_high_speed]
434 - Sending and receiving messages between the CAN bus interfaces.
435 - Recover from error.
436 - Detection of network errors.
438 ===== 2x LIN =====[2x_lin]
440 - Testing least one LIN using a loop. The second connector is shared with serial interface, which is tested alone communicate with the computer. Detailed testing makes sense to be no support for access to diagnostics unit via Ethernet or other interface.
442 ===== 1x FlexRay =====[1x_flexray]
444 - Sending and receiving messages between two plates JRVA.
447 ===== 1x Serial Comm. Interface =====[1x_serial_comm_interface]
451 ===== 1x Ethernet =====[1x_ethernet]
454 - Code for testing Ethernet is the result of this thesis and is therefore not analyzed.
456 ==== Data storage/logging ====[data_storagelogging]
460 ===== External Memory SDRAM =====[external_memory_sdram]
462 - Determine the total capacity of the module fitted.
463 - Performing a memory test module using the entire address range.
466 ===== SD Card =====[sd_card]
470 === Development wiring ===[development_wiring]
472 How to wire the board for testing.
474 === Test wiring ===[test_wiring]
478 == Repository layout ==[repository_layout]
481 The repository is hosted on the server of the Real-Time Systems group at the Department
482 of Control Engineering
486 |-- doc - Documentation created for this project.
487 |-- refs - Official reference documentation.
489 |-- blocks - Simulink RPP Block Library.
490 |-- demos - Simulink RPP Demo Library.
491 |-- lib - RPP Library and API.
492 `-- rpp - Simulink RPP Target.
497 == Programming standards ==[programming_standards]
502 === TLC files ===[tlc_files]
506 === RPP API ===[rpp_api]
510 === S-Functions ===[s_functions]
514 = Simulink RPP Target =[simulink_rpp_target]
518 == Description ==[description]
520 The Simulink RPP Target provides support for C source code generation from Simulink models and compilation of
521 that code on top of the RPP library and the FreeRTOS operating system. This target uses Texas Instrument ARM
522 compiler (armcl) included in the Code Generation Tools available with Code Composer Studio, and thus it depends
523 on it for proper functioning.
525 This library also provides support for automatically download the compiled machine code to the RPP board.
527 === Code generation process ===[code_generation_process]
529 %tex% ''' \begin{figure}[H]\advance\leftskip-1cm
530 [530-tlc_process.png]
531 %tex% ''' \caption{TLC code generation process.}\end{figure}
533 == Repository subtree description ==[repository_subtree_description]
538 RPP Target install script.
540 This script will, among other things, ask the user to provide the location of the armcl parent directory,
541 infer and save some relevant CCS paths, add paths to Matlab path and build S-Function blocks for
542 user's architecture (using Matlab's mex command line tool).
545 - ``<repo>/refs/rtw_ug.pdf`` p. 1137.
550 Embedded real-time system target file for RPP.
552 This file is the system target file (STF), or target manifest file. Functions of the STF include:
554 - Making the target visible in the System Target File Browser.
555 - Definition of code generation options for the target (inherited and target-specific).
556 - Providing an entry point for the top-level control of the TLC code generation process.
560 - ``<repo>/refs/rtw_ug.pdf`` p. 1129 and __1144__.
565 Embedded Coder Template Makefile.
567 This is just standard Embedded Coder Template Makefile, provided by Matlab. It was slightly modified to
568 support ``armcl`` particularities and added template rules for assembler files (which were included by the
569 ``rpp_lib_support.m`` script, but is no longer the case).
572 - ``<repo>/refs/rtw_ug.pdf`` p. 1130 and __1183__.
575 -> ``rpp_download.m``
577 Code download utility for Simulink RPP Target.
579 This function is optionally executed at the end of the build process if it is successful and the user selected
580 //Download compiled binary to RPP// option on the build configuration panel. This function calls ``loadti.sh``
581 script with the generated binary and using configuration for the XDS100v2 JTAG Emulators. The board should be
582 powered and correctly wired. See [Development wiring #development_wiring].
586 -> ``rpp_file_process.tlc``
588 Code generation custom file processing template.
590 This file should decide which //main// to generate according to configuration, in particular which mode, Single
591 Tasking or Multitasking, is chosen. The RPP Target ignores this settings because it uses a tasking system based
592 on tasking features provided by FreeRTOS. In consequence is only a wrapper to the //Single Tasking// main, which
593 clearly is not for single tasking.
596 - ``<repo>/refs/ecoder_ug.pdf`` p. 556.
597 - ``<repo>/refs/ecoder_ref.pdf`` p. 1347.
600 -> ``rpp_lib_support.m``
602 **DEPRECATED**. Simulink support for RPP library and operating system setup.
604 This files used to add the source code from the RPP library and operating to the build. This is no longer required
605 when using the static library. This is left for future reference in case new source code needs to be included to
609 - ``<repo>/refs/rtw_ug.pdf`` p. 1058.
610 - ``<repo>/refs/rtw_ref.pdf`` p. 56.
613 -> ``rpp_make_rtw_hook.m``
615 Build process hooks file.
617 This file is hook file that invoke target-specific functions or executables at specified points in the build process.
618 In particular, this file handle the copying of required files before the compilation stage.
621 - ``<repo>/refs/rtw_ug.pdf`` p. 1066-1072 and 1131.
624 -> ``rpp_select_callback_handler.m``
626 RPP Target select callback handler.
628 This callback function is triggered whenever the user selects the target in the System Target File Browser. Default
629 values for Simulation and configurations parameters are set. Some options are disabled if it is not allowed to be
633 - ``<repo>/refs/rtw_ug.pdf`` p. 1211.
637 -> ``rpp_srmain.tlc``
639 Custom file processing to generate a //main// file.
641 This file generated the //main// file for the RPP target on top of the RPP library and the FreeRTOS operating system.
642 The ``sr`` prefix is standard to mark Single Tasking main, which is not the case. See ``rpp_file_process.m`` description
643 above for more information about this.
646 - Example in ``<matlab>/rtw/c/tlc/mw/bareboard_srmain.tlc``.
649 -> ``target_tools.mk``
651 Makefile for CCS (``armcl``) toolchain support.
653 This file set variables to CCS tools to support build for this toolchain. This file is included by ``rpp.tmf`` before
654 declaring the rules for source code.
657 - "Include a tool specification settings" comment block in ``rpp.tmf``.
658 - Compiler options documentation available in ``armcl.pdf``.
663 == Installation procedure ==[installation_procedure]
666 **1) Download and install CCS for Linux:**
668 Details on how to setup CCS are available in section [TI Code Composer Studio #ti_code_composer_studio].
671 **2) Install RPP Target:**
673 Open Matlab and type on command window:
680 This will launch the RPP setup script. This script will ask the user to provide the path to the CCS compiler
681 root directory (the directory where ``armcl`` binary is located), normally:
684 <ccs>/tools/compiler/arm_5.X.X/
687 This script will, among other things, ask the user to provide the location of the armcl parent directory,
688 infer and save some relevant CCS paths, add paths to Matlab path and build S-Function blocks for user's
689 architecture (using Matlab's mex command line tool).
692 **3) Create a new model or load a demo:**
694 Demos are located on ``<repo>/rpp/demo`` or you can start a new model and configure target to RPP. For new models
695 see [Target Reference #target_reference] section below.
699 == Target Reference ==[target_reference]
702 This section describes the options required or available for running a Simulink model with the RPP Target.
704 === Simulink model options ===[simulink_model_options]
707 The Simulink model needs to be configured in the following way:
710 - //fixed-step discrete//.
711 - Tasking mode set to //SingleTasking//. @@
712 [400-simulink_solver.png]
714 - Diagnostics - Sample Time:
715 - Disable warning source block specifies -1 sampling time. It's ok for the source blocks to run once per tick. @@
716 [400-simulink_diagnostics.png]
718 - Set to ``rpp.tlc``. @@
719 [400-simulink_code.png]
722 Note: Single Tasking is the only currently supported mode. If multitasking is required to be implemented in the
723 future create a new file ``rpp_mrmain.tlc`` in ``<repo>/rpp/rpp/`` and edit ``rpp_file_process.tlc`` to use
724 that file instead when multitasking is selected.
727 === RPP Target options ===[rpp_target_options]
730 The RPP Target include the following configuration options, all of them configurable per model under
731 ``Code Generation`` -> ``RPP Options``:
733 - **C system stack size**: this parameter is passed directly to the linker for the allocation of the stack.
734 Note that this is the stack for the application when running outside a FreeRTOS task, normally before
735 the scheduler has started and for system routines. Default value is 4096.
736 - **C system heap size**: this parameter is passed directly to the linker for the allocation of the heap.
737 See [Appendix A: Notes on FreeRTOS memory management #appendix_a_notes_on_freertos_memory_management]
738 for an important overview of memory management and why this parameter is one of the most important in
740 - **Model step task stack size**: this parameter will be passed to the ``xTaskCreate()`` that creates the
741 task for the model to run. In a Simulink model there is always two tasks:
742 - The worker task. This task is the one that executes the model step. This task requires enough stack
743 memory to execute the step. Take into account for example than only a single call to
744 ``rpp_sci_printf()`` requires, with current configuration, 128 bytes from the stack. This value should
745 be minor than the C system heap and leaving enough heap for the system tasks.
746 See [Appendix A: Notes on FreeRTOS memory management #appendix_a_notes_on_freertos_memory_management]
747 for more information.
748 - The control task. This task controls when the worker task should execute and controls overruns.
749 - **Download compiled binary to RPP**: if set, this option will download the generated binary to the board after
750 the model is successfully built. Note that this option is unaware of the option //Generate code only// in
751 the //Code Generation// options panel, so it will try to upload even if only source code has being generated,
752 failing graciously or uploading an old binary laying around in the build directory. This option calls the
753 ``rpp_download.m`` script, which is in turn a wrapper on the ``loadti.sh`` script. More information on the
754 ``loadti.sh`` script can be found in:
756 <css>/ccs_base/scripting/examples/loadti/readme.txt
757 http://processors.wiki.ti.com/index.php/Loadti
759 The ``loadti.sh`` script will close after the download of the generated program and in consequence the execution
760 of the loaded program will stop (because it work as the CCS debug server). In order to test the loaded model a
761 manual reset of the board is always required after a successful download.
762 - **Print model metadata to SCI at start**: if set this option will print a message to the Serial Communication
763 Interface when the model start execution on the board. This is very helpful to identify the model running on the
764 board. The message is in the form:
766 `model_name' - generated_date (TLC tlc_version)
770 `hbridge_analog_control' - Wed Jun 19 14:10:44 2013 (TLC 8.3 (Jul 20 2012))
775 = RPP Library and API =[rpp_library_and_api]
779 == Description ==[description]
782 The RPP Library is the support library used by Simulink models. It is designed from the board user
783 perspective and exposes a simplified high-level API to handle the board's peripheral modules in a safe
786 The library as a concept and as a functional unit was introduced by this project. At the beginning of this
787 project the RPP board had just one application developed for. This application intended for board testing
788 allows the user to issue low-level commands to control and test the peripherals of the board. This application
789 was created using a combination of custom code, contributed drivers and generated code from TI tool HalCoGen.
790 Library functionality, like drivers and hardware access, and application logic, like command processor and test
791 routines, was largely merged in a single layer, 166 source code files long highly coupled application.
792 In order to develop independent applications for the RPP board, as it was expected to be each Simulink model,
793 the library logic needed to be separated from the application logic. This work implied a heavy refactoring on
794 the testing application in order extract from it the library functionality. Because the application files were
795 highly coupled in a single layer the refactoring and testing of the library implied roughly 70% of the work done
798 %tex% ''' \begin{figure}[H]\advance\leftskip-1cm
799 [500-adc_dep_before.png]
800 %tex% ''' \caption{Dependency graph of the ADC driver before refactoring.}\end{figure}
802 The above graph shows the dependencies of the ADC driver before the refactoring. Please note the dependency on
803 ``cmdproc_io_tisci.h`` and ``cmdproc.h``, both application level modules. Also, note the indirect dependency on
804 the Operating System is being resolved through the application modules.
806 %tex% ''' \begin{figure}[H]\begin{center}
807 [150-adc_dep_after.png]
808 %tex% ''' \caption{Dependency graph of the ADC driver after refactoring.}\end{center}\end{figure}
810 The above graph shows the current dependencies for the ADC driver in the RPP Library. Please note that it
811 dependents only on the system layer low-level driver and that the Operating System indirect dependency is resolved
812 through the library foundations ``base.h``.
814 Some other relevant changes introduced with the refactoring are:
816 - ADC driver was completely rewritten.
817 - MOUT driver was implemented.
818 - DIN driver was slightly modified and extended.
819 - DAC driver was slightly modified.
820 - HBR driver was largely modified (in particular watchdog functionality).
821 - SCI driver was refactored and extended.
822 - SDR driver was implemented.
825 Also, once the library functionality could be isolated, the resulting API was too low-level to be used by
826 applications, in consequence one of the contributions of this projects was the implementation of a high-level
827 API on top of this low level API: the RPP Layer.
832 === Architecture ===[architecture]
835 The RPP library was structured into 5 layers with the following guidelines:
837 - Top-down dependency only. No lower layer depends on anything from upper layers.
838 - 1-1 layer dependency only. The top layer depends exclusively on the bottom layer, not on any
839 lower level layer (except for a couple of exceptions).
840 - Each layer should provide a unified layer interface (``rpp.h``, ``drv.h``, ``hal.h``, ``sys.h`` and
841 ``os.h``), so top layers depends on that layer interface and not on individual elements from that layer.
844 %tex% ''' \begin{figure}[H]\begin{center}
846 %tex% ''' \caption{The RPP library layers.}\end{center}\end{figure}
849 As a consequence of this division the source code files and interface files are now placed on private directories
850 so the previous prefix based inclusion ``drv_din.h`` is replaced by ``drv/din.h``. With this organization user
851 applications only needs to include the top layer interface file (``rpp/rpp.h``) to be able to use the library API.
853 Please note the sublayer uLut, which is used only by the SPI driver in order to use thread safe queue mechanisms.
854 Because the FreeRTOS already provides thread safe queues and in order to match the order parts of the system it
855 would be advisable to drop this dependency in the future.
859 === RPP Layer Modules ===[rpp_layer_modules]
862 The RPP Layer was structured into 14 different modules from 4 different categories that match the hardware
863 modules on the board:
865 || Category | Description | MNEMONIC
866 | Logic IO | Digital Input | ``[DIN ]`` |
867 | | Digital (Logic) Output | ``[LOUT]`` |
868 | | Analog Input | ``[AIN ]`` |
869 | | Analog Output | ``[AOUT]`` |
870 | Power output | H-Bridge output | ``[HBR ]`` |
871 | | Power output (12V, 2A) | ``[MOUT]`` |
872 | | High-Power output (12V, 10A) | ``[HOUT]`` |
873 | Communication | CAN Bus | ``[CAN ]`` |
874 | | LIN (Local Interconnect Network) | ``[LIN ]`` |
875 | | FlexRay | ``[FR ]`` |
876 | | Serial Communication Interface | ``[SCI ]`` |
877 | | Ethernet | ``[ETH ]`` |
878 | Logging | SD Card | ``[SDC ]`` |
879 | | SD-RAM | ``[SDR ]`` |
882 Please note the mnemonic of each module, as they are constantly used on the Software and documentation.
883 Also note that only the following modules where implemented as part of this project:
885 %tex% ''' \begin{multicols}{2}
896 %tex% ''' \end{multicols}
898 Modules for which there is a low-level API available on the library but no high-level module was implemented:
900 %tex% ''' \begin{multicols}{2}
906 %tex% ''' \end{multicols}
908 Modules that are not yet available on the library at all:
910 %tex% ''' \begin{multicols}{2}
911 - ETH (in the works).
916 %tex% ''' \end{multicols}
918 The following graphic shows the library modules and the connectors on the hardware they map to.
920 %tex% ''' \begin{figure}[H]\advance\leftskip-1cm
922 %tex% ''' \caption{The RPP Library modules.}\end{figure}
926 === OS interchangeable layer ===[os_interchangeable_layer]
929 The OS Layer is composed by the FreeRTOS source code files. Because the FreeRTOS exposes an stable
930 API the OS layer can be changed in order to upgrade the Operating System or use a different port of the
931 OS, without changing the upper layers source code. The OS Layers currently available for the RPP Library
932 at ``<repo>/rpp/lib/os/`` at the time of this writing are:
934 - Version 6.0.4 using POSIX port. This layer is the one that should be used when compiling a program for
935 x86(_64) simulation. The port uses the ``pthread`` library and because of this the port is not true
936 real time and this is considered a simulator.
937 - Version 7.0.2 using HalCoGen port for TMS570. This layer is the one currently supported and tested. It was
938 originally included in the testing application and was generated by an older version of TI code generation
940 - Version 7.4.0 using HalCoGen port for TMS570. This layer was extracted from a newly generated project using
941 a newer version of HalCoGen. This layer is untested but //should// work out of the box.
942 - Version 7.4.2 using ARM Cortex R4 official port for CCS. This layer was created from vanilla FreeRTOS 7.4.2
943 release. It is tested but non-working. Ticks are proved to be executed in time but applications using this
944 kernel runs at full-speed. The reason if this is currently unknown.
947 The general layout of all the layers are as following:
949 - Common source code (kernel):
952 src/os/croutine.c (Optional)
956 src/os/timers.c (Optional)
959 Originally found in vanilla distribution in: ``<FreeRTOSRoot>/FreeRTOS/Source``
961 - Common interface files:
964 include/os/croutine.h
965 include/os/FreeRTOS.h
967 include/os/mpu_wrappers.h
968 include/os/portable.h (with minor editions)
969 include/os/projdefs.h
972 include/os/StackMacros.h
977 Originally found in vanilla distribution in: ``<FreeRTOSRoot>/FreeRTOS/Source/include``
979 - Memory management file:
982 src/os/heap.c (One of 4 version available, see Appendix A).
985 Originally found in vanilla distribution in: ``<FreeRTOSRoot>/FreeRTOS/Source/portable/MemMang``
987 - Port specific files:
992 include/os/portmacro.h
993 include/os/FreeRTOSConfig.h
996 This depend of the port. In the case of the 7.4.2 TMS570 / ARM Cortex R4 for CCS port:
998 - First three files can be found in vanilla distribution in @@
999 ``<FreeRTOSRoot>/FreeRTOS/Source/portable/CCS/ARM_Cortex-R4``.
1000 - Last file in ``<FreeRTOSRoot>/FreeRTOS/Demo/CORTEX_R4_RM48_TMS570_CCS5``.
1003 In general, the following changes were applied to the source code base of all kernels:
1005 - Replaced include directives to adapt to RPP library standard:
1007 ``#include "`` with ``#include "os/``
1009 - Line ending character set to UNIX '\n' and tabs replaced by 4 spaces.
1014 === API development guidelines ===[api_development_guidelines]
1017 The following are the development guidelines use for developing the RPP API:
1019 - User documentation should be placed in header files, not in source code, and should be Doxygen formatted
1020 using autobrief. Documentation for each function present is mandatory.
1021 - Function declarations on the headers files is for public functions only. Do not declare local/static/private
1022 functions on the header.
1023 - Documentation on source code files should be non-doxygen formatted and intended for developers, not users.
1024 Documentation here is optional.
1025 - Always use standard data types for IO when possible. Use custom structs as very last resort.
1026 - Use prefix based functions names to avoid clash. The prefix is of the form ``[layer]_[module]_``, for example
1027 ``rpp_din_update()`` for the update function of the DIN module in the RPP Layer.
1028 - To be very careful about symbol export. Because it is used as a static library the modules should not export
1029 any symbol that is not intended to be used (function) or externed (variable) from application. As a rule of
1030 thumb declare all global variables as static.
1034 === Further improvements ===[further_improvements]
1037 The following are recommendations for future improvements of the library:
1039 - General code revision to remove local-only methods and variables from being exported.
1040 - General code revision and refactoring to normalize the functions naming scheme. Normalize DRV and HAL
1041 to use prefix based scheme, not all the functions and exported variables do. Refactor the SYS layer,
1042 most of it generated by HalCoGen and that uses ``thisNamingScheme`` to use library standards (see
1043 [RPP API #rpp_api] programming standards).
1044 - Simplify doxygen documentation on the SYS layer, because is clunky, doesn't add any value and is
1045 repetitive. Move it the header files.
1046 - The HAL layer currently two elements:
1047 - CPU and chips abstractions. This should stay.
1048 - Command descriptors. This is remaining elements from the testing applications and should be moved to
1052 Recommendations for changes on the electrical diagrams:
1054 - Change name of GPIO MOUT1_EN to MOUT1_DIAG.
1055 - Change name of GPIO MOUT1_IN to MOUT1_EN.
1058 This are misleading.
1060 == Repository subtree description ==[repository_subtree_description]
1063 -> ``librpp.a`` and ``rpp-lib.lib``
1065 Version controlled RPP static libraries.
1067 The first one is for POSIX simulation, the second one for Simulink models and other ARM/TMS570
1068 applications. This files are placed here by the projects ``apps/rpp-lib_posix`` and
1069 ``apps/rpp-lib`` when built.
1074 Applications related to the RPP library.
1076 This include the CCS studio project for generation of the static library and the test suite.
1081 OS layers directory.
1083 See [OS interchangeable layer #os_interchangeable_layer] for more information.
1086 -> ``rpp/`` main directory for the RPP Library.
1088 -> include/rpp/rpp.h
1090 Main library header file.
1092 To use this library just include this file and this file only. Also,
1093 before using any library function please call rpp_init() function for
1094 hardware initialization.
1097 -> include/rpp/RppConfig.h
1099 Library configuration file.
1101 Please refer to the API documentation and header file comments for
1102 specific documentation for each configuration parameter.
1105 -> include/rpp/rpp_{mnemonic}.h
1107 Header file for {mnemonic} module.
1109 This files includes function definitions, pin definitions, etc, specific
1110 to {mnemonic} module. The inclusion of this header can be configured
1111 in RppConfig.h using rppCONFIG_INCLUDE_{MNEMONIC} directive.
1114 -> src/rpp/rpp_{mnemonic}.c
1116 Module implementation.
1118 Implementation of rpp_{mnemonic}.h's functions on top of the DRV
1124 Implementation of library-wide functions.
1129 Configuration file for Doxygen code documentation generation tool.
1135 == Test Suite ==[test_suite]
1138 The ``rpp-test-suite`` is a RPP application developed as part of this project that includes a series of
1139 test tasks or test commands to verify the correct behavior and functionality of the RPP layer modules.
1140 There is one command per module, and the command use the same mnemonic that the module.
1142 This test suite can be found in ``<repo>/rpp/lib/apps/rpp-test-suite`` for the ARM version and in
1143 ``<repo>/rpp/lib/apps/rpp-test-suite_posix`` for the simulated version.
1145 The application enables a command processor using the SCI at **115200-8-N-1**:
1148 RPP Library Test Suite.
1149 ===========================================================
1150 [Type a module to test or 'help']
1153 help - Display this help.
1154 ain - Test Analog Input.
1155 aout - Test Analog Output.
1156 can - Test CAN communication.
1157 din - Test Digital Inputs.
1158 eth - Test Ethernet communication.
1159 fr - Test Frame Relay communication.
1160 hbr - Test H-Bridge.
1161 hout - Test High Power Output.
1162 lin - Test LIN communication.
1163 lout - Test Digital Outputs.
1164 mout - Test Power Outputs.
1165 sci - Test Serial Communication Interface.
1170 Current modules with tests implemented are:
1172 %tex% ''' \begin{multicols}{2}
1179 - SCI. (the test-suite itself)
1183 %tex% ''' \end{multicols}
1187 === AIN test description ===[ain_test_description]
1190 This test will read all the analog inputs at a rate of 100 times per second and print the result.
1194 Analog Inputs Test [1-12]:
1195 ===========================================================
1196 1 2 3 4 5 6 7 8 9 10 11 12
1197 0 0 0 0 0 0 0 0 0 0 0 0
1200 Status: **PASSED** for channels 1-5. 6-12 remain untested but they //should// work.
1202 === AOUT test description ===[aout_test_description]
1205 This test will generate a 10Hz sinus wave on all the analog outputs with a sampling rate of 1kHz.
1206 The sinus wave of each analog output channel is sifted by (1/4)pi.
1210 Analog Output Test at 10 Hz:
1211 ===========================================================
1217 === DIN test description ===[din_test_description]
1220 This test will read all 16 + 8 the digital inputs at a rate of 100 times per second, using both low speed
1221 SPI chip and variable threshold high-speed inputs.
1225 Digital Inputs Test [1-16]:
1226 ===========================================================
1227 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 A B C D E F G H
1228 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1232 - Low speed fixed threshold [1-16]: **PASSED**.
1233 - High speed variable threshold [A-H]: **FAILED**.
1235 === HBR test description ===[hbr_test_description]
1238 This test will generate a sinus wave to control the H-Bridge of one period per 20 seconds (0.05Hz) at a
1239 sampling rate of 20Hz.
1243 H-Bridge Test at 0.05 Hz:
1244 ===========================================================
1250 === LOUT test description ===[lout_test_description]
1253 This test will show in the digital outputs the value in binary of a counter, incrementing the counter
1254 once per second. The counter is 8 bits, the same as the outputs, so 255 seconds are required for an
1255 overflow/restart of the counting.
1259 Digital Output Test:
1260 ===========================================================
1266 === MOUT test description ===[mout_test_description]
1269 This test will toggle the power outputs one by one per second, then wait 10 seconds in that state while
1270 constantly verifying the diagnostics.
1275 ===========================================================
1277 1: OK 1: OK 1: OK 1: OK 1: OK 1: OK
1282 === SCI test description ===[sci_test_description]
1285 A more comprehensive test is not implemented. The very use of this test-suite implies the correct function
1286 of the SCI module. Nevertheless, as a future improvement, a test that will verify run-time baud rate changes
1287 and test some other RPP SCI functions is desirable.
1291 You're using the SCI, reading this and typing this command.
1292 Press any key to continue...
1297 === SDR test description ===[sdr_test_description]
1300 This test will launch a noise generator task that will log noise and then start the library included SD-RAM
1301 logging command processor, allowing the user to see and handle the log on the SD-RAM.
1305 Log control: 1024kB available.
1306 ===========================================================
1308 [ 1239864] This is the noise generator at iteration 1 putting some noise value 279735017.
1309 [ 1240779] This is the noise generator at iteration 2 putting some noise value 1943579783.
1312 1023 kB of 1024 kB available.
1324 == Static libraries ==[static_libraries]
1327 The RPP Library can be compiled as a static library for ARM using TI CGT and for x86(_64) using GCC. CCS
1328 projects ``rpp-lib`` and ``rpp-lib_posix`` in ``<repo>/rpp/lib/apps/`` allows to generate the static
1329 libraries. After compilation, as part of the build process, both projects will automatically update the
1330 version-controlled static libraries in ``<repo>/rpp/lib/``:
1332 - ``rpp-lib.lib``, static library for ARM using TI naming scheme.
1333 - ``librpp.a``, static library for x86(_64) using standard Linux naming scheme.
1336 One future improvement would be the creation of a Makefile for each compilation scheme in order to not depend
1337 on CCS managed build system. For ARM manual compilation or makefile creation using Texas CGT see the
1338 ``target_tools.mk`` file under the Simulink RPP Target folder. The relevant aspects for compiling and linking
1339 an application using the static libraries are:
1341 **ARM compilation using CCS for the RPP board:**
1343 - Include headers files of the OS for which the library was compiled against. At the time of this writing the OS
1344 is FreeRTOS 7.0.2. See [OS interchangeable layer #os_interchangeable_layer] section above.
1345 - Include header files for the RPP library.
1346 - Add library ``rpp-lib.lib`` to the linker libraries. The RPP library **MUST** be looked for before Texas
1347 Instruments support library ``rtsv7R4_T_be_v3D16_eabi.lib``.
1348 - Configure linker to retain ``.intvecs`` section from RPP Library:@@
1349 ``--retain="rpp-lib.lib<sys_intvecs.obj>(.intvecs)"``
1350 - Use the provided linker command file ``TMS570LS313xFlashLnk.cmd``.
1353 **x86(_64) compilation using GCC for Simulation:**
1355 - Include headers files of the OS for Simulation. At the time of this writing the OS is POSIX FreeRTOS 6.0.4.
1356 - Include header files for the RPP library.
1357 - Create a ``RppConfig.h`` override file and drop DRV layer dependency: ``rppCONFIG_DRV 0``.
1358 - Includes must be configured in a way that the ``RppConfig.h`` taken under consideration is the override and not
1360 - Add library ``librpp.a`` to the linker libraries.
1361 - Add ``pthread`` to the linker libraries.
1364 As an important note, all the models compiled using Simulink will link against ``rpp-lib.lib``. When compiling a
1365 Simulink model, Simulink, and then ``make``, will not update the generated binary if the model hasn't changed, and
1366 then if the source code hasn't changed. Static libraries changes are not considered for re-compilation and
1367 re-linking. If library development is being done and static library is updated, in order for the Simulink model
1368 to generate a newly linked version of the binary the whole code generation folder needs to be deleted in order to
1369 force code generation, compilation and linking with the new static library.
1374 == Base application ==[base_application]
1377 In ``<repo>/rpp/lib/apps/`` there is two RPP base applications, ``base`` and ``base_posix``, that
1378 already configured for the RPP Library. It is advised that new applications uses this projects a foundations.
1380 To create a new application copy this directory and rename it. Now open files ``.project``, ``.cproject`` and
1381 ``.ccsproject`` (if available) and change any occurrence of the work ``base`` with the name of your project.
1382 Use only lower case ASCII letters and underscores.
1384 **Steps to configure a new CCS (ARM, using CGT) RPP application:**
1386 + Create a new CCS project.@@
1388 + Create a normal folder ``include``.
1389 + Create a source folder ``src``.
1390 + Add common ``.gitignore`` to the root of that project:
1397 + Add new variable ``RPP_LIB_ROOT`` and point to this repository branch root.@@
1399 + Add ``rpp-lib.lib`` static library to linker libraries and add ``RPP_LIB_ROOT`` to the library search path.@@
1402 + Configure linker to retain ``.intvecs`` from RPP static library.@@
1404 + Configure compiler to include local includes, OS includes for TMS570 and RPP includes, in that order.@@
1407 + Configure compiler to allow GCC extensions.@@
1409 + Import and link (__do not copy!__) linker file and board upload descriptor.@@
1413 **Steps to configure a new GCC (x86(_64)) RPP simulated application:**
1415 + Create a new managed C project that uses Linux GCC toolchain.
1416 + Create a source folder ``src``. Link all files from original CCS application to this folder.
1417 + Create a normal folder ``include``. Create a folder ``rpp`` inside of it.
1418 + Add common ``.gitignore`` to the root of that project:
1425 + Add new variable ``RPP_LIB_ROOT`` and point to this repository branch root.@@
1426 [400-base_posix_1.png]
1427 + Configure compiler to include local includes, CCS application includes, OS includes for POSIX and
1428 RPP includes, in that order.@@
1429 [400-base_posix_2.png]
1431 + Add ``rpp`` and ``pthread``to linker libraries and add ``RPP_LIB_ROOT`` to the library search path.@@
1432 [400-base_posix_3.png]
1433 + Copy ``RppConfig.h`` from RPP Library to a new folder ``include/rpp`` and configure it drop DRV layer
1434 dependency: ``rppCONFIG_DRV 0``.@@
1435 [200-base_posix_4.png]
1438 **In general any RPP application uses the layout/template:**
1440 + Include RPP library header file.
1442 #include "rpp/rpp.h"
1446 + Create one or as many FreeRTOS task function definitions as required. Those
1447 tasks should use functions from this library.
1449 void my_task(void* p)
1451 static const portTickType freq_ticks = 1000 / portTICK_RATE_MS;
1452 portTickType last_wake_time = xTaskGetTickCount();
1454 /* Wait until next step */
1455 vTaskDelayUntil(&last_wake_time, freq_ticks);
1456 rpp_sci_printf((const char*)"Hello RPP.\r\n");
1461 + Create the main function that will:
1462 - Initialize the RPP board.
1463 - Spawn the tasks the application requires. Refer to FreeRTOS API for
1465 - Start the FreeRTOS Scheduler. Refer to FreeRTOS API for details.
1466 - Catch if idle task could not be created.
1471 /* Initialize RPP board */
1475 if(xTaskCreate(my_task, (const signed char*)"my_task",
1476 512, NULL, 0, NULL) != pdPASS) {
1478 rpp_sci_printf((const char*)
1479 "ERROR: Cannot spawn control task.\r\n"
1482 while(TRUE) { asm(" nop"); }
1485 /* Start the FreeRTOS Scheduler */
1486 vTaskStartScheduler();
1488 /* Catch scheduler start error */
1490 rpp_sci_printf((const char*)
1491 "ERROR: Problem allocating memory for idle task.\r\n"
1494 while(TRUE) { asm(" nop"); }
1498 + Create hook functions for FreeRTOS:
1499 - ``vApplicationMallocFailedHook()`` allows to catch memory allocation errors.
1500 - ``vApplicationStackOverflowHook()`` allows to catch if a task overflows it's
1504 #if configUSE_MALLOC_FAILED_HOOK == 1
1506 * FreeRTOS malloc() failed hook.
1508 void vApplicationMallocFailedHook(void) {
1510 rpp_sci_printf((const char*)
1511 "ERROR: manual memory allocation failed.\r\n"
1518 #if configCHECK_FOR_STACK_OVERFLOW > 0
1520 * FreeRTOS stack overflow hook.
1522 void vApplicationStackOverflowHook(xTaskHandle xTask,
1523 signed portCHAR *pcTaskName) {
1525 rpp_sci_printf((const char*)
1526 "ERROR: Stack overflow : \"%s\".\r\n", pcTaskName
1536 == API generation ==[api_generation]
1539 The RPP Layer is formatted using Doxygen documentation generator. This allows to generate a high quality
1540 API reference. To generate the API reference do in a terminal:
1543 cd <repo>/rpp/lib/rpp/doc/api
1544 doxygen doxygen.conf
1545 xdg-open html/index.html
1548 The files under ``<repo>/rpp/lib/rpp/doc/api/content`` are used for the API reference generation are their
1549 name is self-explanatory:
1559 To install Doxygen see [Development environment #development_environment] section.
1561 == API Reference ==[api_reference]
1564 For the complete API reference please generate the HTML version using the above section instructions.
1565 Here is listed the index of functions of each module and their brief.
1567 Please note that not all modules were implemented as part of this project. See
1568 [RPP Layer Modules #rpp_layer_modules] for a list of the modules implemented.
1572 === DIN API Reference ===[din_api_reference]
1575 ``int8_t rpp_din_init();`` @@ -> DIN module initialization. @@ @@
1576 ``int8_t rpp_din_ref(uint16_t refA, uint16_t refB);`` @@ -> Configure voltage reference levels for digital inputs using variable reference threshold. @@ @@
1577 ``int8_t rpp_din_setup(uint8_t pin, boolean_t pull_type, boolean_t active, boolean_t can_wake);`` @@ -> Configure given pin. @@ @@
1578 ``int8_t rpp_din_get(uint8_t pin, boolean_t var_thr);`` @@ -> Get the current cached value of the given pin. @@ @@
1579 ``int8_t rpp_din_diag(uint8_t pin);`` @@ -> Get the diagnostic cached value for given pin. @@ @@
1580 ``int8_t rpp_din_update();`` @@ -> Read and update cached values and diagnostic values of all pins. Also commit configuration changes.
1582 === LOUT API Reference ===[lout_api_reference]
1585 ``int8_t rpp_lout_init();`` @@ -> LOUT module initialization. @@ @@
1586 ``int8_t rpp_lout_set(uint8_t pin, uint8_t val);`` @@ -> Set the output cache of given pin to given value. @@ @@
1587 ``int8_t rpp_lout_diag(uint8_t pin);`` @@ -> Get the diagnostic cached value for given pin. @@ @@
1588 ``int8_t rpp_lout_update();`` @@ -> Flush cached output values and read back diagnostic values of all pins.
1590 === AIN API Reference ===[ain_api_reference]
1593 ``int8_t rpp_ain_init();`` @@ -> AIN module initialization. @@ @@
1594 ``int16_t rpp_ain_get(uint8_t pin);`` @@ -> Get the current analog value on the given pin. @@ @@
1595 ``int8_t rpp_ain_update();`` @@ -> Read and update analog cached values.
1598 === AOUT API Reference ===[aout_api_reference]
1601 ``#define RPP_DAC_OA 5.6`` @@ -> DAC output operational amplifier multiplication constant. @@ @@
1602 ``#define RPP_DAC_VREF 2.5`` @@ -> DAC hardware reference voltage. @@ @@
1603 ``int8_t rpp_aout_init();`` @@ -> AOUT module initialization. @@ @@
1604 ``int8_t rpp_aout_setup(uint8_t pin, boolean_t enabled);`` @@ -> Configure enabled/disabled state for given pin. @@ @@
1605 ``int8_t rpp_aout_set(uint8_t pin, uint16_t val);`` @@ -> Set the output cache of given pin to given value. @@ @@
1606 ``int8_t rpp_aout_set_voltage(uint8_t pin, uint16_t mv);`` @@ -> Set output to given voltage. @@ @@
1607 ``int8_t rpp_aout_update();`` @@ -> Flush cached output values and configuration changes.
1609 === HBR API Reference ===[hbr_api_reference]
1612 ``int8_t rpp_hbr_init();`` @@ -> HBR module initialization. @@ @@
1613 ``int8_t rpp_hbr_enable(int32_t period);`` @@ -> Enable the H-Bridge for control. @@ @@
1614 ``int8_t rpp_hbr_control(double cmd);`` @@ -> Control the H-Bridge direction, enabled/disabled and PWM. @@ @@
1615 ``int8_t rpp_hbr_disable();`` @@ -> Disable the H-Bridge.
1619 === MOUT API Reference ===[mout_api_reference]
1622 ``int8_t rpp_hbr_init();`` @@ -> HBR module initialization. @@ @@
1623 ``int8_t rpp_mout_init();`` @@ -> MOUT module initialization. @@ @@
1624 ``int8_t rpp_mout_set(uint8_t pin, uint8_t val);`` @@ -> Set the output of given pin to given value. @@ @@
1625 ``int8_t rpp_mout_get(uint8_t pin);`` @@ -> Get the cached value of the given pin set by rpp_mout_set(). @@ @@
1626 ``int8_t rpp_mout_diag(uint8_t pin);`` @@ -> Reads the value on the given diagnostic pin.
1628 === HOUT API Reference ===[hout_api_reference]
1631 ``int8_t rpp_hout_init();`` @@ -> HOUT module initialization.
1633 === CAN API Reference ===[can_api_reference]
1636 ``int8_t rpp_can_init();`` @@ -> CAN module initialization.
1638 === LIN API Reference ===[lin_api_reference]
1641 ``int8_t rpp_lin_init();`` @@ -> LIN module initialization.
1643 === FR API Reference ===[fr_api_reference]
1646 ``int8_t rpp_fr_init();`` @@ -> FR module initialization.
1650 === SCI API Reference ===[sci_api_reference]
1653 ``int8_t rpp_sci_init();`` @@ -> SCI module initialization. @@ @@
1654 ``boolean_t rpp_sci_setup(uint32_t baud);`` @@ -> SCI module setup. @@ @@
1655 ``uint16_t rpp_sci_available();`` @@ -> Number of bytes available on input buffer. @@ @@
1656 ``int8_t rpp_sci_read(uint32_t amount, uint8_t* buffer);`` @@ -> Read n number of bytes from input buffer. @@ @@
1657 ``int8_t rpp_sci_read_nb(uint32_t amount, uint8_t* buffer);`` @@ -> Read n number of bytes from input buffer if possible. @@ @@
1658 ``int8_t rpp_sci_write(uint32_t amount, uint8_t* data);`` @@ -> Write n number of bytes to the output buffer. @@ @@
1659 ``int8_t rpp_sci_write_nb(uint32_t amount, uint8_t* data);`` @@ -> Write n number of bytes to the output buffer if possible. @@ @@
1660 ``int8_t rpp_sci_flush(boolean_t buff);`` @@ -> Flush incomming or outgoing buffers. @@ @@
1661 ``int32_t rpp_sci_printf(const char* format, ...);`` @@ -> C style printf using RPP SCI module. @@ @@
1662 ``int8_t rpp_sci_putc(uint8_t byte);`` @@ -> C style putc (put character) using RPP SCI module. @@ @@
1663 ``int16_t rpp_sci_getc();`` @@ -> C style getc (get character) using RPP SCI module.
1665 === ETH API Reference ===[eth_api_reference]
1668 ``int8_t rpp_eth_init();`` @@ -> ETH module initialization.
1670 === SDC API Reference ===[sdc_api_reference]
1673 ``int8_t rpp_sdc_init();`` @@ -> SDC module initialization.
1675 === SDR API Reference ===[sdr_api_reference]
1678 ``#define RPP_SDR_ADDR_START 0x80000000U`` @@ -> SDRAM start address on RPP board. @@ @@
1679 ``#define RPP_SDR_ADDR_END 0x83FFFFFFU`` @@ -> SDRAM end address on RPP board. @@ @@
1680 ``int8_t rpp_sdr_init();`` @@ -> SDR module initialization. @@ @@
1681 ``int8_t rpp_sdr_setup(boolean_t enable);`` @@ -> Configure SD-RAM logging. @@ @@
1682 ``uint32_t rpp_sdr_available();`` @@ -> Query for the amount of space free on the SD-RAM. @@ @@
1683 ``int32_t rpp_sdr_printf(const char* format, ...);`` @@ -> Store a formatted user string on the log, if logging is enabled. @@ @@
1684 ``int8_t rpp_sdr_clear();`` @@ -> Clear log. @@ @@
1685 ``int8_t rpp_sdr_show(boolean_t start);`` @@ -> Start/Stop the task that sends the log to the SCI.
1689 = Simulink RPP Block Library =[simulink_rpp_block_library]
1693 == Description ==[description]
1695 The Simulink RPP Block Library is the ideal set of blocks that should be implemented for the RPP board.
1696 As part of this project this ideal set was defined, but not all blocks were implemented. The following
1697 table shows the current status of the block library.
1699 || CATEGORY | NAME | STATUS* | MNEMONIC | LRH*
1700 | System blocks | Configuration block | ``X`` | ``[CONF]`` | ``RppConfig.h`` |
1701 | Logic IO blocks | Digital Input block | ``T`` | ``[DIN ]`` | ``rpp_din.h`` |
1702 | | Digital Output block | ``T`` | ``[LOUT]`` | ``rpp_lout.h`` |
1703 | | Analog Input block | ``T`` | ``[AIN ]`` | ``rpp_ain.h`` |
1704 | | Analog Output block | ``T`` | ``[AOUT]`` | ``rpp_aout.h`` |
1705 | Power output blocks | H-Bridge Control block | ``T`` | ``[HBR ]`` | ``rpp_hbr.h`` |
1706 | | Power output block | ``T`` | ``[MOUT]`` | ``rpp_mout.h`` |
1707 | | High-Power output block | ``X`` | ``[HOUT]`` | ``rpp_hout.h`` |
1708 | Communication blocks | CAN Bus receive block | ``X`` | ``[CANR]`` | ``rpp_can.h`` |
1709 | | CAN Bus send msg block | ``X`` | ``[CANS]`` | - Idem - |
1710 | | LIN receive block | ``X`` | ``[LINR]`` | ``rpp_lin.h`` |
1711 | | LIN send msg block | ``X`` | ``[LINS]`` | - Idem - |
1712 | | FlexRay receive block | ``X`` | ``[FRR ]`` | ``rpp_fr.h`` |
1713 | | FlexRay send msg block | ``X`` | ``[FRS ]`` | - Idem - |
1714 | | SCI receive block | ``T`` | ``[SCIR]`` | ``rpp_sci.h`` |
1715 | | SCI send msg block | ``T`` | ``[SCIS]`` | - Idem - |
1716 | | SCI configure block | ``T`` | ``[SCIC]`` | - Idem - |
1717 | | Ethernet receive block | ``X`` | ``[ETHR]`` | ``rpp_eth.h`` |
1718 | | Ethernet send msg block | ``X`` | ``[ETHS]`` | - Idem - |
1719 | Logging/Storage blocks | SD Card write block | ``T`` | ``[SDCW]`` | ``rpp_sdc.h`` |
1720 | | SDRAM write block | ``X`` | ``[SDRW]`` | ``rpp_sdr.h`` |
1721 | Trigger blocks | Overrun detected block | ``X`` | ``[TROR]`` | - None - |
1722 | | Stack overflow detected block | ``X`` | ``[TRSO]`` | - None - |
1723 | | Malloc Failed detected block | ``X`` | ``[TRMF]`` | - None - |
1726 - *LRH : Library Reference Header.
1728 - ``X`` - Unimplemented. Files non present.
1729 - ``P`` - Unimplemented. Files present.
1730 - ``W`` - Work in progress.
1731 - ``I`` - Implemented.
1732 - ``T`` - Implemented and tested.
1735 __Notes__: Each block that can detect fault condition should have a trigger output.
1736 High-power output provides current flow as an input to the model.
1740 === C MEX S-Functions ===[c_mex_s_functions]
1742 All of the blocks are implemented as a C Mex S-Function coded by hand. In the this section this approach is
1748 === Target Language Compiler files ===[target_language_compiler_files]
1755 == Repository subtree description ==[repository_subtree_description]
1757 -> ``header.c`` and ``trailer.c``
1759 RPP framework for simple S-Functions.
1761 This files are included at the head and tail of each S-Function file. They include refactored and
1762 commonly repeated structures that pollute S-Functions implementations. They include basic includes,
1763 required definitions, macro definitions, common functions implementations and documentation on
1764 optional functions and commented prototypes for optional model calls/hooks.
1770 -> ``sfunction_{mnemonic}.c``
1772 C-MEX S-Function implementation for {mnemonic} block.
1774 This file implements the {mnemonic} block using C-MEX S-Function API. See the reference for information
1775 about the S-Function API.
1778 - ``<repo>/refs/sfunctions.pdf``
1781 -> ``tlc_c/sfunction_{mnemonic}.tlc``
1783 Target Language Compiler (TLC) file for {mnemonic} block.
1785 This file implements the C code inlining for {mnemonic} block. See the reference for information about
1789 - ``<repo>/refs/rtw_tlc.pdf``
1792 -> ``tlc_c/common.tlc``
1794 Common TLC functions.
1796 This file implements common TLC functions used by all the blocks.
1804 Simulink library control file.
1806 This file allows a group of blocks to be integrated into the Simulink Library and Simulink Library
1807 Browser. This file is required by Simulink in order to interpret this folder as a block library.
1808 For information about this file see the references.
1811 - ``<repo>/refs/rtw_ug.pdf`` p. 1127
1816 RPP Simulink block library.
1818 Simulink block library that includes all the blocks. This file is referenced by ``slblocks.m``
1826 Blocks compilation script.
1828 This script compiles all the sfunction blocks to MEX executables. This script is called by the
1829 ``rpp_setup()`` function in order make all the blocks available to the Simulink environment or it
1830 can be called independently when developing S-Functions.
1838 == Block Library Reference ==[block_library_reference]
1840 This section describes each one of the Simulink blocks implements as part of this project:
1842 %tex% ''' \begin{figure}[H]\advance\leftskip-1cm
1843 [530-block_library.png]
1844 %tex% ''' \caption{Simulink RPP Block Library.}\end{figure}
1848 === DIN Digital Input block ===[din_digital_input_block]
1859 uint8 Pin number [1-16]
1860 bool Use variable threshold
1863 This block allows to read the digital inputs on the RPP board. The variable threshold check change the read
1864 mode of the pin (from the block size this is working, library call is not working though). The ErrFlag should
1865 raise if ``rpp_din_update()`` or ``rpp_din_get()`` returns error. ``rpp_din_update()`` is called just by the
1866 first DIN block in the model and thus only the first block could raise the flag because of this. In case an
1867 errors occurs the return value will always be LOW (0). Because the ErrFlag should never set, once set the
1868 following steps will never clear it back.
1871 %tex% ''' \begin{multicols}{3}
1874 - Compilation and general use.
1877 %tex% ''' \vfill\columnbreak
1879 - Faulty situation for the ErrFlag to set.
1882 %tex% ''' \vfill\columnbreak
1884 - Using variable threshold.
1887 %tex% ''' \end{multicols}
1890 **RPP API functions used:**
1891 - ``rpp_din_setup()``.
1892 - ``rpp_din_update()``.
1893 - ``rpp_din_get()``.
1897 - ``digital_passthrough``.
1898 - ``hbridge_digital_control``.
1903 === LOUT Digital Output block ===[lout_digital_output_block]
1913 uint8 Pin number [1-8]
1916 This block allows to write to the digital outputs on the RPP board. The ErrFlag should raise if ``rpp_lout_set()``
1917 or ``rpp_lout_update()`` returns error. Because the ErrFlag should never set, once set the following steps will
1918 never clear it back. ``rpp_lout_update()`` is called on each block, which is not the most efficient but guaranties
1919 consistent behavior.
1923 %tex% ''' \begin{multicols}{3}
1926 - Compilation and general use.
1929 %tex% ''' \vfill\columnbreak
1931 - Faulty situation for the ErrFlag to set.
1934 %tex% ''' \vfill\columnbreak
1938 %tex% ''' \end{multicols}
1941 **RPP API functions used:**
1942 - ``rpp_lout_set()``.
1943 - ``rpp_lout_update()``.
1947 - ``digital_passthrough``.
1948 - ``led_blink_all``.
1954 === AIN Analog Input block ===[ain_analog_input_block]
1965 uint8 Pin number [1-12]
1968 This block allows to read the analog inputs on the RPP board. The ErrFlag should if raise ``rpp_ain_update()``
1969 or ``rpp_ain_get()`` returns error. ``rpp_ain_update()`` is called just by the first DIN block in the model and
1970 thus only the first block could raise the flag because of this. In case an errors occurs the return value will
1971 always be 0. Because the ErrFlag should never set, once set the following steps will never clear it back.
1975 %tex% ''' \begin{multicols}{3}
1978 - Compilation and general use.
1981 %tex% ''' \vfill\columnbreak
1983 - Faulty situation for the ErrFlag to set.
1986 %tex% ''' \vfill\columnbreak
1990 %tex% ''' \end{multicols}
1993 **RPP API functions used:**
1994 - ``rpp_ain_update()``.
1995 - ``rpp_ain_get()``.
1999 - ``analog_passthrough``.
2000 - ``hbridge_analog_control``.
2001 - ``log_analog_input``.
2006 === AOUT Analog Output block ===[aout_analog_output_block]
2010 uint16 Analog Output
2016 uint8 Pin number [1-4]
2020 This block allows to write to the analog outputs on the RPP board. The UseVoltage flag allows the user to
2021 configure if block inputs should be interpreted as raw DAC value or millivolts. The ErrFlag should raise
2022 if ``rpp_aout_update()`` or ``rpp_aout_set()`` (or ``rpp_aout_set_voltage()`` depending on block configuration)
2023 returns error. Because the ErrFlag should never set, once set the following steps will never clear it back.
2025 ``rpp_aout_update()`` is called on each block but the implementation provides this to be efficient.
2027 There is a know bug on the RPP Library, check ``rpp_aout_update()`` on the RPP API for details. Because of this,
2028 the outputs of the DACs are initialized on the first step of the model and not on the model initialization.
2032 %tex% ''' \begin{multicols}{3}
2035 - Changing voltage/value flag.
2036 - Compilation and general use.
2039 %tex% ''' \vfill\columnbreak
2041 - Faulty situation for the ErrFlag to set.
2044 %tex% ''' \vfill\columnbreak
2046 - Initializing DACs on model's initialization.
2049 %tex% ''' \end{multicols}
2052 **RPP API functions used:**
2053 - ``rpp_aout_setup()``.
2054 - ``rpp_aout_set()``, or
2055 - ``rpp_aout_set_voltage()``.
2056 - ``rpp_aout_update()``.
2060 - ``analog_passthrough``.
2061 - ``analog_sinewave``.
2066 === HBR H-Bridge Control block ===[hbr_h_bridge_control_block]
2079 This block allows to control the H-Bridge on the RPP board. The ErrFlag should raise only if
2080 ``rpp_hbr_control()`` returns error. The H-Bridge is initialized with the default frequency (~18kHz).
2081 A future improvement could include a parameter to set the frequency. Because the ErrFlag should never
2082 set, once set the following steps will never clear it back.
2086 %tex% ''' \begin{multicols}{3}
2088 - Compilation and general use.
2091 %tex% ''' \vfill\columnbreak
2093 - Faulty situation for the ErrFlag to set.
2096 %tex% ''' \vfill\columnbreak
2100 %tex% ''' \end{multicols}
2103 **RPP API functions used:**
2104 - ``rpp_hbr_enable()``.
2105 - ``rpp_hbr_control()``.
2109 - ``hbridge_analog_control``.
2110 - ``hbridge_digital_control``.
2111 - ``hbridge_sinewave_control``.
2116 === MOUT Power Output block ===[mout_power_output_block]
2126 uint8 Pin number [1-6]
2129 This block allows to write the power outputs (2A) on the RPP board. The ErrFlag should raise only if
2130 ``rpp_mout_set()``returns error. Note that ``rpp_mout_set()`` returns error only if some bad parameter
2131 or in case it could detect a faulty condition on the pin in a very very short period of time after
2132 setting the value, see the function API for details. If the faulty condition persist on the next step
2133 the call will successfully detect the faulty condition and ErrFlag should set. Because the ErrFlag should
2134 never set, once set the following steps will never clear it back.
2138 %tex% ''' \begin{multicols}{3}
2141 - Compilation and general use.
2144 %tex% ''' \vfill\columnbreak
2146 - Faulty situation for the ErrFlag to set.
2149 %tex% ''' \vfill\columnbreak
2153 %tex% ''' \end{multicols}
2156 **RPP API functions used:**
2157 - ``rpp_mout_set()``.
2166 === SCIR Serial Comm. Interface Receive ===[scir_serial_comm_interface_receive]
2180 This block allows to receive a byte from the SCI. The ErrFlag should raise if ``rpp_sci_read_nb()``
2181 doesn't succeed. The behavior of the ErrFlag is different from others blocks in that this block will
2182 set or clear the flag if the call fails of success at each step. Note that this block uses the
2183 non-blocking call to read the SCI and thus will never cause an overrun.
2187 %tex% ''' \begin{multicols}{3}
2190 - Compilation and general use.
2191 - Faulty situation for the ErrFlag to set.
2194 %tex% ''' \vfill\columnbreak
2198 %tex% ''' \vfill\columnbreak
2202 %tex% ''' \end{multicols}
2205 **RPP API functions used:**
2206 - ``rpp_sci_read_nb()``.
2215 === SCIS Serial Comm. Interface Send ===[scis_serial_comm_interface_send]
2226 string PrintFormat [SETTING]
2229 This block allows to send a byte to the SCI or to print a formatted string that uses that byte. The
2230 UsePrintf flag allows to user to select ``rpp_sci_write_nb()`` (raw send) or ``rpp_sci_printf()``
2231 (formatted print) as the function the block should use on code generation. If UsePrintf is set the
2232 PrintFormat string parameters SETTING is used as the format specifier. Note that this value is
2233 inserted raw between quotes on code generation and thus there is no validation on it. User should
2234 always put any valid integer specifier for the value on the input of the block.
2236 The behavior of this block depends if UsePrintf is set or not. If set, the call ``rpp_sci_printf()``
2237 (a blocking call) could potentially overrun the step. Also, the ErrFlag will set only if
2238 ``rpp_sci_printf()`` returns an error, and because it should never set, once set it will never
2239 clear back. On the contrary, if UsePrintf is clear, the call ``rpp_sci_write_nb()`` (non-blocking)
2240 is used and thus the step cannot be overrun, but because is a best-effort call it cannot guarantee that
2241 all the data will be sent. In the case that not all data could be sent, the ErrFlag will set, but it
2242 will clear back if the next step is able to send all it's data (which with the current implementation
2245 A possible future improvement for this block is to allow input to be non-scalar so user can print a whole
2246 string in one step using raw non-blocking write. This is currently possible if input configuration is
2247 adapted in S-Function and TLC. The problem this could pose is is that for printf user should include
2248 specifiers for all the cells in the non-scalar input, and if unknown, then printf cannot be used.
2252 %tex% ''' \begin{multicols}{3}
2255 - Compilation and general use.
2258 %tex% ''' \vfill\columnbreak
2260 - Faulty situation for the ErrFlag to set.
2263 %tex% ''' \vfill\columnbreak
2267 %tex% ''' \end{multicols}
2270 **RPP API functions used:**
2271 - ``rpp_sci_write_nb()``, or ``rpp_sci_printf()``.
2275 - ``echo_char`` and ``hello_world``.
2280 === SCIC Serial Comm. Interface Configure ===[scic_serial_comm_interface_configure]
2293 This block allows to configure the baud rate of the SCI. There should only one block of this type per
2294 model, and this requirement is not validated, but the inclusion of several blocks is harmless and will
2295 just produce the baud rate to be changed several times, being the final baud rate to be the one of the
2296 last executed block. This block just executes on model initialization and not on each step.
2300 %tex% ''' \begin{multicols}{3}
2302 - Changing baud rate.
2303 - Compilation and general use.
2306 %tex% ''' \vfill\columnbreak
2308 - Using more than one block in a model.
2311 %tex% ''' \vfill\columnbreak
2315 %tex% ''' \end{multicols}
2318 **RPP API functions used:**
2319 - ``rpp_sci_setup()``.
2329 === SDRW SD-RAM Write ===[sdrw_sd_ram_write]
2340 string PrintFormat [SETTING]
2343 This block allows to log a double value to the SD-RAM. User needs to provide a valid PrintFormat string to
2344 format and register the double value on the log. The PrintFormat string should include two specifiers:
2346 - For the block ID. Any valid integer specifier.
2347 - For the value to log. Any valid double specifier.
2350 Note that the value of PrintFormat is inserted raw between quotes on code generation and thus there is no
2351 validation on it. Error to provide a valid PrintFormat could generate compilation errors on even run-time
2352 errors (normally this generates a warning on compile time). Note that the function for logging used is
2353 ``rpp_sdr_printf()``, which is a blocking call, and can potentially overrun the step. The ErrFlag will set
2354 if ``rpp_sdr_printf()`` returns an error (for example out of memory), but will clear back if the next step
2355 the call to this function is successful.
2359 %tex% ''' \begin{multicols}{3}
2362 - Compilation and general use.
2365 %tex% ''' \vfill\columnbreak
2367 - Faulty situation for the ErrFlag to set.
2370 %tex% ''' \vfill\columnbreak
2374 %tex% ''' \end{multicols}
2377 **RPP API functions used:**
2378 - ``rpp_sdr_printf()``.
2382 - ``log_analog_input``.
2387 = Simulink RPP Demo Library =[simulink_rpp_demo_library]
2391 == Description ==[description]
2393 The Simulink RPP Demo Library is a set of Simulink models that use blocks in the Simulink RPP Block Library
2394 and generates code using the Simulink RPP Target. It is used as a test suite for the Simulink RPP Block Library
2395 but they are also intended to show basic programs built using it, because of this the demos try to use more than
2396 one type of block and more than one block per block type.
2398 The following table shows the current status of the demos:
2400 || Name | Implemented | Tested
2401 | analog_passthrough | YES | SUCCESS |
2402 | analog_sinewave | YES | SUCCESS |
2403 | digital_passthrough | YES | SUCCESS |
2404 | echo_char | YES | SUCCESS |
2405 | hbridge_analog_control | YES | SUCCESS |
2406 | hbridge_digital_control | YES | SUCCESS |
2407 | hbridge_sinewave_control | YES | SUCCESS |
2408 | hello_world | YES | SUCCESS |
2409 | led_blink_all | YES | SUCCESS |
2410 | led_blink | YES | SUCCESS |
2411 | log_analog_input | YES | SUCCESS |
2412 | power_toggle | YES | SUCCESS |
2414 In the reference below you can find a complete description for each of the demos.
2416 == Repository subtree description ==[repository_subtree_description]
2421 == Demos Reference ==[demos_reference]
2423 This section describes the demos implemented as part of this project that uses the Simulink RRP Block
2424 Library and generates code using the RPP Simulink Target.
2426 === analog_passthrough ===[analog_passthrough]
2428 %tex% ''' \begin{figure}[H]\begin{center}
2429 [450-demo_analog_passthrough.png]
2430 %tex% ''' \caption{Analog Passthrough Simulink RPP demo.}\end{center}\end{figure}
2434 LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM
2435 LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM
2436 LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM
2437 LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM
2441 === analog_sinewave ===[analog_sinewave]
2443 %tex% ''' \begin{figure}[H]\begin{center}
2444 [350-demo_analog_sinewave.png]
2445 %tex% ''' \caption{Analog Sinewave Simulink RPP demo.}\end{center}\end{figure}
2449 LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM
2450 LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM
2451 LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM
2452 LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM
2456 === digital_passthrough ===[digital_passthrough]
2458 %tex% ''' \begin{figure}[H]\begin{center}
2459 [350-demo_digital_passthrough.png]
2460 %tex% ''' \caption{Digital Pass-through Simulink RPP demo.}\end{center}\end{figure}
2464 LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM
2465 LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM
2466 LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM
2467 LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM
2471 === echo_char ===[echo_char]
2473 %tex% ''' \begin{figure}[H]\begin{center}
2474 [450-demo_echo_char.png]
2475 %tex% ''' \caption{Echo Character Simulink RPP demo.}\end{center}\end{figure}
2479 LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM
2480 LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM
2481 LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM
2482 LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM
2486 === hbridge_analog_control ===[hbridge_analog_control]
2488 %tex% ''' \begin{figure}[H]\begin{center}
2489 [450-demo_hbridge_analog_control.png]
2490 %tex% ''' \caption{H-Bridge Analog Control Simulink RPP demo.}\end{center}\end{figure}
2494 LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM
2495 LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM
2496 LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM
2497 LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM
2501 === hbridge_digital_control ===[hbridge_digital_control]
2503 %tex% ''' \begin{figure}[H]\begin{center}
2504 [450-demo_hbridge_digital_control.png]
2505 %tex% ''' \caption{H-Bridge Digital Control Simulink RPP demo.}\end{center}\end{figure}
2509 LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM
2510 LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM
2511 LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM
2512 LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM
2516 === hbridge_sinewave_control ===[hbridge_sinewave_control]
2518 %tex% ''' \begin{figure}[H]\begin{center}
2519 [450-demo_hbridge_sinewave_control.png]
2520 %tex% ''' \caption{H-Bridge Sinewave Control Simulink RPP demo.}\end{center}\end{figure}
2524 LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM
2525 LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM
2526 LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM
2527 LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM
2531 === hello_world ===[hello_world]
2533 %tex% ''' \begin{figure}[H]\begin{center}
2534 [350-demo_hello_world.png]
2535 %tex% ''' \caption{Hello World Simulink RPP demo.}\end{center}\end{figure}
2539 LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM
2540 LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM
2541 LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM
2542 LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM
2546 === led_blink_all ===[led_blink_all]
2548 %tex% ''' \begin{figure}[H]\begin{center}
2549 [350-demo_led_blink_all.png]
2550 %tex% ''' \caption{LED Blink All Simulink RPP demo.}\end{center}\end{figure}
2554 LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM
2555 LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM
2556 LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM
2557 LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM
2561 === led_blink ===[led_blink]
2563 %tex% ''' \begin{figure}[H]\begin{center}
2564 [300-demo_led_blink.png]
2565 %tex% ''' \caption{LED Blink Simulink RPP demo.}\end{center}\end{figure}
2569 LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM
2570 LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM
2571 LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM
2572 LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM
2576 === log_analog_input ===[log_analog_input]
2578 %tex% ''' \begin{figure}[H]\begin{center}
2579 [450-demo_log_analog_input.png]
2580 %tex% ''' \caption{Log Analog Input Simulink RPP demo.}\end{center}\end{figure}
2584 LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM
2585 LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM
2586 LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM
2587 LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM
2591 === power_toggle ===[power_toggle]
2593 %tex% ''' \begin{figure}[H]\begin{center}
2594 [300-demo_power_toggle.png]
2595 %tex% ''' \caption{Power Toggle Simulink RPP demo.}\end{center}\end{figure}
2599 LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM
2600 LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM
2601 LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM
2602 LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM LORENS IPSUM
2606 = Glossary =[glossary]
2609 //Analog to Digital Converter.//
2610 Hardware circuitry that converts a continuous physical quantity (usually voltage) to a
2611 digital number that represents the quantity's amplitude.
2615 Mnemonic to refer to or something related to the analog input (ADC) hardware module.
2619 Mnemonic to refer to or something related to the analog output (DAC) hardware module.
2622 //Controller Area Network.//
2623 The CAN Bus is a vehicle bus standard designed to allow microcontrollers and devices to
2624 communicate with each other within a vehicle without a host computer.
2625 In this project it is also used as mnemonic to refer to or something related to the CAN
2629 //Code Generation Tools.//
2630 Name given to the tool set produced by Texas Instruments used to compile, link, optimize,
2631 assemble, archive, among others. In this project is normally used as synonym for
2632 ``Texas Instruments ARM compiler and linker."
2635 //Digital to Analog Converter.//
2636 Hardware circuitry that converts a digital (usually binary) code to an analog signal
2637 (current, voltage, or electric charge).
2641 Mnemonic to refer to or something related to the digital input hardware module.
2644 //Engine Control Unit.//
2645 A type of electronic control unit that controls a series of actuators on an internal combustion
2646 engine to ensure the optimum running.
2650 Mnemonic to refer to or something related to the Ethernet hardware module.
2654 FlexRay is an automotive network communications protocol developed to govern on-board automotive
2656 In this project it is also used as mnemonic to refer to or something related to the FlexRay
2661 Mnemonic to refer to or something related to the H-Bridge hardware module. A H-Bridge is
2662 an electronic circuit that enables a voltage to be applied across a load in either direction.
2665 //High-Power Output.//
2666 Mnemonic to refer to or something related to the 10A, PWM, with current sensing, high-power
2667 output hardware module.
2670 //Integrated Development Environment.//
2671 An IDE is a Software application that provides comprehensive facilities to computer programmers
2672 for software development.
2675 //Local Interconnect Network.//
2676 The LIN is a serial network protocol used for communication between components in vehicles.
2677 In this project it is also used as mnemonic to refer to or something related to the LIN
2682 Mnemonic to refer to or something related to the digital output hardware module.
2683 It is logic output (100mA), as opposed to power outputs (2A, 10A).
2686 //Model-Based Design.//
2687 Model-Based Design (MBD) is a mathematical and visual method of addressing problems associated
2688 with designing complex control, signal processing and communication systems.
2691 //Matlab Executable.//
2692 Type of binary executable that can be called within Matlab. In this document the common term
2693 used is `C MEX S-Function", which means Matlab executable written in C that implements a system
2697 //(Motor) Power Output.//
2698 Mnemonic to refer to or something related to the 2A push/pull power output hardware module.
2701 //Rapid Prototyping Platform//.
2702 Name of the automotive hardware board. Also generic term to define something related
2703 to the board, like the RPP Library, RPP Layer, RPP API, etc.
2706 //Serial Communication Interface.//
2707 Serial Interface for communication through hardware's UART using communication standard RS-232.
2708 In this project it is also used as mnemonic to refer to or something related to the Serial
2709 Communication Interface hardware module.
2713 Mnemonic to refer to or something related to the SD-Card hardware module.
2717 Mnemonic to refer to or something related to the SD-RAM hardware module for logging.
2720 //Target Language Compiler.//
2721 Technology and language used to generate code in Matlab/Simulink.
2724 //Universal Asynchronous Receiver/Transmitter.//
2725 Hardware circuitry that translates data between parallel and serial forms.
2731 = References =[references]
2733 - Horn, M. (2013). //Software obsluhující periferie a flexray na automobilové rídicí jednotce//.
2734 (Unpublished master's thesis, Czech Technical University in Prague, Prague, Czech Republic).
2736 - //Model-based design//. (n.d.). In Wikipedia.
2737 Retrieved March 10, 2013, from http://en.wikipedia.org/wiki/Model-based_design
2742 = Appendix A: Notes on FreeRTOS memory management =[appendix_a_notes_on_freertos_memory_management]
2744 Write about heap implementation, FreeRTOSConfig.h heap size, C heap size, C stack size, Simulink memory, among others.