diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Doxygen_Templates/cmsis_footer.html b/external/CMSIS_5/CMSIS/DoxyGen/Doxygen_Templates/cmsis_footer.html
deleted file mode 100644
index bae4bdb..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/Doxygen_Templates/cmsis_footer.html
+++ /dev/null
@@ -1,19 +0,0 @@
-
-
-
-
-
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Doxygen_Templates/cmsis_footer.js b/external/CMSIS_5/CMSIS/DoxyGen/Doxygen_Templates/cmsis_footer.js
deleted file mode 100644
index 886da84..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/Doxygen_Templates/cmsis_footer.js
+++ /dev/null
@@ -1,3 +0,0 @@
-function writeFooter() {
- document.write('Generated on {datetime} for {projectName} {projectNumber} by Arm Ltd. All rights reserved.');
-};
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Doxygen_Templates/cmsis_header.html b/external/CMSIS_5/CMSIS/DoxyGen/Doxygen_Templates/cmsis_header.html
deleted file mode 100644
index 8d48f2e..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/Doxygen_Templates/cmsis_header.html
+++ /dev/null
@@ -1,63 +0,0 @@
-
-
-
-
-
-
-
-
-
-
-
- $projectname
- $projectnumber
-
- $projectbrief
-
-
-
-
-
- $projectbrief
-
-
-
-
-
- $searchbox
-
-
-
-
-
-
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Doxygen_Templates/navtree.css b/external/CMSIS_5/CMSIS/DoxyGen/Doxygen_Templates/navtree.css
deleted file mode 100644
index e46ffcd..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/Doxygen_Templates/navtree.css
+++ /dev/null
@@ -1,123 +0,0 @@
-#nav-tree .children_ul {
- margin:0;
- padding:4px;
-}
-
-#nav-tree ul {
- list-style:none outside none;
- margin:0px;
- padding:0px;
-}
-
-#nav-tree li {
- white-space:nowrap;
- margin:0px;
- padding:0px;
-}
-
-#nav-tree .plus {
- margin:0px;
-}
-
-#nav-tree .selected {
- background-image: url('tab_a.png');
- background-repeat:repeat-x;
- color: #fff;
- text-shadow: 0px 1px 1px rgba(0, 0, 0, 1.0);
-}
-
-#nav-tree img {
- margin:0px;
- padding:0px;
- border:0px;
- vertical-align: middle;
-}
-
-#nav-tree a {
- text-decoration:none;
- padding:0px;
- margin:0px;
- outline:none;
-}
-
-#nav-tree .label {
- margin:0px;
- padding:0px;
-}
-
-#nav-tree .label a {
- padding:2px;
-}
-
-#nav-tree .selected a {
- text-decoration:none;
- padding:2px;
- margin:0px;
- color:#fff;
-}
-
-#nav-tree .children_ul {
- margin:0px;
- padding:0px;
-}
-
-#nav-tree .item {
- margin:0px;
- padding:0px;
-}
-
-#nav-tree {
- padding: 0px 0px;
- background-color: #FAFAFF;
- font-size:14px;
- overflow:auto;
-}
-
-#doc-content {
- overflow:auto;
- display:block;
- padding:0px;
- margin:0px;
-}
-
-#side-nav {
- padding:0 6px 0 0;
- margin: 0px;
- display:block;
- position: absolute;
- left: 0px;
- width: 300px;
-}
-
-.ui-resizable .ui-resizable-handle {
- display:block;
-}
-
-.ui-resizable-e {
- background:url("ftv2splitbar.png") repeat scroll right center transparent;
- cursor:e-resize;
- height:100%;
- right:0;
- top:0;
- width:6px;
-}
-
-.ui-resizable-handle {
- display:none;
- font-size:0.1px;
- position:absolute;
- z-index:1;
-}
-
-#nav-tree-contents {
- margin: 6px 0px 0px 0px;
-}
-
-#nav-tree {
- background-image:url('nav_h.png');
- background-repeat:repeat-x;
- background-color: #F9FAFC;
-}
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Doxygen_Templates/printComponentTabs.js b/external/CMSIS_5/CMSIS/DoxyGen/Doxygen_Templates/printComponentTabs.js
deleted file mode 100644
index 1858286..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/Doxygen_Templates/printComponentTabs.js
+++ /dev/null
@@ -1,40 +0,0 @@
-var strgURL = location.pathname; // path of current component
-
-// constuctor for the array of objects
-function tabElement(id, folderName, tabTxt ) {
- this.id = id; // elementID as needed in html;
- this.folderName = folderName; // folder name of the component
- this.tabTxt = tabTxt; // Text displayed as menu on the web
- this.currentListItem = '
' + this.tabTxt + ' ';
- this.listItem = '
' + this.tabTxt + ' ';
-};
-
-// array of objects
-var arr = [];
-
-// fill array
- arr.push( new tabElement( "GEN", "/General/html/", "General") );
- arr.push( new tabElement( "CORE_A", "/Core_A/html/", "Core(A)") );
- arr.push( new tabElement( "CORE_M", "/Core/html/", "Core(M)") );
- arr.push( new tabElement( "DRV", "/Driver/html/", "Driver") );
- arr.push( new tabElement( "DSP&ML", "/DSP/html/", "DSP") );
- arr.push( new tabElement( "NN", "/NN/html/", "NN") );
- arr.push( new tabElement( "RTOSv1", "/RTOS/html/", "RTOS v1") );
- arr.push( new tabElement( "RTOSv2", "/RTOS2/html/", "RTOS v2") );
- arr.push( new tabElement( "PACK", "/Pack/html/", "Pack") );
- arr.push( new tabElement( "Build", "/Build/html/", "Build") );
- arr.push( new tabElement( "SVD", "/SVD/html/", "SVD") );
- arr.push( new tabElement( "DAP", "/DAP/html/", "DAP") );
- arr.push( new tabElement( "ZONE", "/Zone/html/", "Zone") );
-
-// write tabs
-// called from the header file.
-function writeComponentTabs() {
- for ( var i=0; i < arr.length; i++ ) {
- if (strgURL.search(arr[i].folderName) > 0) { // if this is the current folder
- document.write(arr[i].currentListItem); // then print and hightlight the tab
- } else {
- document.write(arr[i].listItem); // else, print the tab
- }
- }
-};
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Doxygen_Templates/search.css b/external/CMSIS_5/CMSIS/DoxyGen/Doxygen_Templates/search.css
deleted file mode 100644
index 1746d13..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/Doxygen_Templates/search.css
+++ /dev/null
@@ -1,240 +0,0 @@
-/*---------------- Search Box */
-
-#FSearchBox {
- float: left;
-}
-
-#searchli {
- float: right;
- display: block;
- width: 170px;
- height: 24px;
-}
-
-#MSearchBox {
- white-space : nowrap;
- position: absolute;
- float: none;
- display: inline;
- margin-top: 3px;
- right: 0px;
- width: 170px;
- z-index: 102;
-}
-
-#MSearchBox .left
-{
- display:block;
- position:absolute;
- left:10px;
- width:20px;
- height:19px;
- background:url('search_l.png') no-repeat;
- background-position:right;
-}
-
-#MSearchSelect {
- display:block;
- position:absolute;
- width:20px;
- height:19px;
-}
-
-.left #MSearchSelect {
- left:4px;
-}
-
-.right #MSearchSelect {
- right:5px;
-}
-
-#MSearchField {
- display:block;
- position:absolute;
- height:19px;
- background:url('search_m.png') repeat-x;
- border:none;
- width:116px;
- margin-left:20px;
- padding-left:4px;
- color: #909090;
- outline: none;
- font: 9pt Arial, Verdana, sans-serif;
-}
-
-#FSearchBox #MSearchField {
- margin-left:15px;
-}
-
-#MSearchBox .right {
- display:block;
- position:absolute;
- right:10px;
- top:0px;
- width:20px;
- height:19px;
- background:url('search_r.png') no-repeat;
- background-position:left;
-}
-
-#MSearchClose {
- display: none;
- position: absolute;
- top: 4px;
- background : none;
- border: none;
- margin: 0px 4px 0px 0px;
- padding: 0px 0px;
- outline: none;
-}
-
-.left #MSearchClose {
- left: 6px;
-}
-
-.right #MSearchClose {
- right: 2px;
-}
-
-.MSearchBoxActive #MSearchField {
- color: #000000;
-}
-
-/*---------------- Search filter selection */
-
-#MSearchSelectWindow {
- display: none;
- position: absolute;
- left: 0; top: 0;
- border: 1px solid #90A5CE;
- background-color: #F9FAFC;
- z-index: 1;
- padding-top: 4px;
- padding-bottom: 4px;
- -moz-border-radius: 4px;
- -webkit-border-top-left-radius: 4px;
- -webkit-border-top-right-radius: 4px;
- -webkit-border-bottom-left-radius: 4px;
- -webkit-border-bottom-right-radius: 4px;
- -webkit-box-shadow: 5px 5px 5px rgba(0, 0, 0, 0.15);
-}
-
-.SelectItem {
- font: 8pt Arial, Verdana, sans-serif;
- padding-left: 2px;
- padding-right: 12px;
- border: 0px;
-}
-
-span.SelectionMark {
- margin-right: 4px;
- font-family: monospace;
- outline-style: none;
- text-decoration: none;
-}
-
-a.SelectItem {
- display: block;
- outline-style: none;
- color: #000000;
- text-decoration: none;
- padding-left: 6px;
- padding-right: 12px;
-}
-
-a.SelectItem:focus,
-a.SelectItem:active {
- color: #000000;
- outline-style: none;
- text-decoration: none;
-}
-
-a.SelectItem:hover {
- color: #FFFFFF;
- background-color: #3D578C;
- outline-style: none;
- text-decoration: none;
- cursor: pointer;
- display: block;
-}
-
-/*---------------- Search results window */
-
-iframe#MSearchResults {
- width: 60ex;
- height: 15em;
-}
-
-#MSearchResultsWindow {
- display: none;
- position: absolute;
- left: 0; top: 0;
- border: 1px solid #000;
- background-color: #EEF1F7;
-}
-
-/* ----------------------------------- */
-
-
-#SRIndex {
- clear:both;
- padding-bottom: 15px;
-}
-
-.SREntry {
- font-size: 10pt;
- padding-left: 1ex;
-}
-
-.SRPage .SREntry {
- font-size: 8pt;
- padding: 1px 5px;
-}
-
-body.SRPage {
- margin: 5px 2px;
-}
-
-.SRChildren {
- padding-left: 3ex; padding-bottom: .5em
-}
-
-.SRPage .SRChildren {
- display: none;
-}
-
-.SRSymbol {
- font-weight: bold;
- color: #425E97;
- font-family: Arial, Verdana, sans-serif;
- text-decoration: none;
- outline: none;
-}
-
-a.SRScope {
- display: block;
- color: #425E97;
- font-family: Arial, Verdana, sans-serif;
- text-decoration: none;
- outline: none;
-}
-
-a.SRSymbol:focus, a.SRSymbol:active,
-a.SRScope:focus, a.SRScope:active {
- text-decoration: underline;
-}
-
-.SRPage .SRStatus {
- padding: 2px 5px;
- font-size: 8pt;
- font-style: italic;
-}
-
-.SRResult {
- display: none;
-}
-
-DIV.searchresults {
- margin-left: 10px;
- margin-right: 10px;
-}
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Doxygen_Templates/tab_topnav.png b/external/CMSIS_5/CMSIS/DoxyGen/Doxygen_Templates/tab_topnav.png
deleted file mode 100644
index b257b77..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Doxygen_Templates/tab_topnav.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Doxygen_Templates/tabs.css b/external/CMSIS_5/CMSIS/DoxyGen/Doxygen_Templates/tabs.css
deleted file mode 100644
index ffbab50..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/Doxygen_Templates/tabs.css
+++ /dev/null
@@ -1,71 +0,0 @@
-.tabs, .tabs1, .tabs2, .tabs3 {
- background-image: url('tab_b.png');
- width: 100%;
- z-index: 101;
- font-size: 10px;
-}
-
-.tabs1 {
- background-image: url('tab_topnav.png');
- font-size: 12px;
-}
-
-.tabs2 {
- font-size: 10px;
-}
-.tabs3 {
- font-size: 9px;
-}
-
-.tablist {
- margin: 0;
- padding: 0;
- display: table;
- line-height: 24px;
-}
-
-.tablist li {
- float: left;
- display: table-cell;
- background-image: url('tab_b.png');
- list-style: none;
-}
-
-.tabs1 .tablist li {
- float: left;
- display: table-cell;
- background-image: url('tab_topnav.png');
- list-style: none;
-}
-
-.tablist a {
- display: block;
- padding: 0 20px;
- font-weight: bold;
- background-image:url('tab_s.png');
- background-repeat:no-repeat;
- background-position:right;
- color: #283A5D;
- text-shadow: 0px 1px 1px rgba(255, 255, 255, 0.9);
- text-decoration: none;
- outline: none;
-}
-
-.tabs3 .tablist a {
- padding: 0 10px;
-}
-
-.tablist a:hover {
- background-image: url('tab_h.png');
- background-repeat:repeat-x;
- color: #fff;
- text-shadow: 0px 1px 1px rgba(0, 0, 0, 1.0);
- text-decoration: none;
-}
-
-.tablist li.current a {
- background-image: url('tab_a.png');
- background-repeat:repeat-x;
- color: #fff;
- text-shadow: 0px 1px 1px rgba(0, 0, 0, 1.0);
-}
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/Driver.dxy b/external/CMSIS_5/CMSIS/DoxyGen/Driver/Driver.dxy
deleted file mode 100644
index a06a30c..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/Driver/Driver.dxy
+++ /dev/null
@@ -1,2361 +0,0 @@
-# Doxyfile 1.8.6
-
-# This file describes the settings to be used by the documentation system
-# doxygen (www.doxygen.org) for a project.
-#
-# All text after a double hash (##) is considered a comment and is placed in
-# front of the TAG it is preceding.
-#
-# All text after a single hash (#) is considered a comment and will be ignored.
-# The format is:
-# TAG = value [value, ...]
-# For lists, items can also be appended using:
-# TAG += value [value, ...]
-# Values that contain spaces should be placed between quotes (\" \").
-
-#---------------------------------------------------------------------------
-# Project related configuration options
-#---------------------------------------------------------------------------
-
-# This tag specifies the encoding used for all characters in the config file
-# that follow. The default is UTF-8 which is also the encoding used for all text
-# before the first occurrence of this tag. Doxygen uses libiconv (or the iconv
-# built into libc) for the transcoding. See http://www.gnu.org/software/libiconv
-# for the list of possible encodings.
-# The default value is: UTF-8.
-
-DOXYFILE_ENCODING = UTF-8
-
-# The PROJECT_NAME tag is a single word (or a sequence of words surrounded by
-# double-quotes, unless you are using Doxywizard) that should identify the
-# project for which the documentation is generated. This name is used in the
-# title of most generated pages and in a few other places.
-# The default value is: My Project.
-
-PROJECT_NAME = "CMSIS-Driver"
-
-# The PROJECT_NUMBER tag can be used to enter a project or revision number. This
-# could be handy for archiving the generated documentation or if some version
-# control system is used.
-
-PROJECT_NUMBER = "Version 2.8.0"
-
-# Using the PROJECT_BRIEF tag one can provide an optional one line description
-# for a project that appears at the top of each page and should give viewer a
-# quick idea about the purpose of the project. Keep the description short.
-
-PROJECT_BRIEF = "Peripheral Interface for Middleware and Application Code"
-
-# With the PROJECT_LOGO tag one can specify an logo or icon that is included in
-# the documentation. The maximum height of the logo should not exceed 55 pixels
-# and the maximum width should not exceed 200 pixels. Doxygen will copy the logo
-# to the output directory.
-
-PROJECT_LOGO = ../Doxygen_Templates/CMSIS_Logo_Final.png
-
-# The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute) path
-# into which the generated documentation will be written. If a relative path is
-# entered, it will be relative to the location where doxygen was started. If
-# left blank the current directory will be used.
-
-OUTPUT_DIRECTORY = ../../Documentation/Driver
-
-# If the CREATE_SUBDIRS tag is set to YES, then doxygen will create 4096 sub-
-# directories (in 2 levels) under the output directory of each output format and
-# will distribute the generated files over these directories. Enabling this
-# option can be useful when feeding doxygen a huge amount of source files, where
-# putting all generated files in the same directory would otherwise causes
-# performance problems for the file system.
-# The default value is: NO.
-
-CREATE_SUBDIRS = NO
-
-# The OUTPUT_LANGUAGE tag is used to specify the language in which all
-# documentation generated by doxygen is written. Doxygen will use this
-# information to generate all constant output in the proper language.
-# Possible values are: Afrikaans, Arabic, Armenian, Brazilian, Catalan, Chinese,
-# Chinese-Traditional, Croatian, Czech, Danish, Dutch, English (United States),
-# Esperanto, Farsi (Persian), Finnish, French, German, Greek, Hungarian,
-# Indonesian, Italian, Japanese, Japanese-en (Japanese with English messages),
-# Korean, Korean-en (Korean with English messages), Latvian, Lithuanian,
-# Macedonian, Norwegian, Persian (Farsi), Polish, Portuguese, Romanian, Russian,
-# Serbian, Serbian-Cyrillic, Slovak, Slovene, Spanish, Swedish, Turkish,
-# Ukrainian and Vietnamese.
-# The default value is: English.
-
-OUTPUT_LANGUAGE = English
-
-# If the BRIEF_MEMBER_DESC tag is set to YES doxygen will include brief member
-# descriptions after the members that are listed in the file and class
-# documentation (similar to Javadoc). Set to NO to disable this.
-# The default value is: YES.
-
-BRIEF_MEMBER_DESC = YES
-
-# If the REPEAT_BRIEF tag is set to YES doxygen will prepend the brief
-# description of a member or function before the detailed description
-#
-# Note: If both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the
-# brief descriptions will be completely suppressed.
-# The default value is: YES.
-
-REPEAT_BRIEF = YES
-
-# This tag implements a quasi-intelligent brief description abbreviator that is
-# used to form the text in various listings. Each string in this list, if found
-# as the leading text of the brief description, will be stripped from the text
-# and the result, after processing the whole list, is used as the annotated
-# text. Otherwise, the brief description is used as-is. If left blank, the
-# following values are used ($name is automatically replaced with the name of
-# the entity):The $name class, The $name widget, The $name file, is, provides,
-# specifies, contains, represents, a, an and the.
-
-ABBREVIATE_BRIEF = "The $name class" \
- "The $name widget" \
- "The $name file" \
- is \
- provides \
- specifies \
- contains \
- represents \
- a \
- an \
- the
-
-# If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES then
-# doxygen will generate a detailed section even if there is only a brief
-# description.
-# The default value is: NO.
-
-ALWAYS_DETAILED_SEC = NO
-
-# If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all
-# inherited members of a class in the documentation of that class as if those
-# members were ordinary class members. Constructors, destructors and assignment
-# operators of the base classes will not be shown.
-# The default value is: NO.
-
-INLINE_INHERITED_MEMB = NO
-
-# If the FULL_PATH_NAMES tag is set to YES doxygen will prepend the full path
-# before files name in the file list and in the header files. If set to NO the
-# shortest path that makes the file name unique will be used
-# The default value is: YES.
-
-FULL_PATH_NAMES = NO
-
-# The STRIP_FROM_PATH tag can be used to strip a user-defined part of the path.
-# Stripping is only done if one of the specified strings matches the left-hand
-# part of the path. The tag can be used to show relative paths in the file list.
-# If left blank the directory from which doxygen is run is used as the path to
-# strip.
-#
-# Note that you can specify absolute paths here, but also relative paths, which
-# will be relative from the directory where doxygen is started.
-# This tag requires that the tag FULL_PATH_NAMES is set to YES.
-
-STRIP_FROM_PATH =
-
-# The STRIP_FROM_INC_PATH tag can be used to strip a user-defined part of the
-# path mentioned in the documentation of a class, which tells the reader which
-# header file to include in order to use a class. If left blank only the name of
-# the header file containing the class definition is used. Otherwise one should
-# specify the list of include paths that are normally passed to the compiler
-# using the -I flag.
-
-STRIP_FROM_INC_PATH =
-
-# If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter (but
-# less readable) file names. This can be useful is your file systems doesn't
-# support long names like on DOS, Mac, or CD-ROM.
-# The default value is: NO.
-
-SHORT_NAMES = NO
-
-# If the JAVADOC_AUTOBRIEF tag is set to YES then doxygen will interpret the
-# first line (until the first dot) of a Javadoc-style comment as the brief
-# description. If set to NO, the Javadoc-style will behave just like regular Qt-
-# style comments (thus requiring an explicit @brief command for a brief
-# description.)
-# The default value is: NO.
-
-JAVADOC_AUTOBRIEF = NO
-
-# If the QT_AUTOBRIEF tag is set to YES then doxygen will interpret the first
-# line (until the first dot) of a Qt-style comment as the brief description. If
-# set to NO, the Qt-style will behave just like regular Qt-style comments (thus
-# requiring an explicit \brief command for a brief description.)
-# The default value is: NO.
-
-QT_AUTOBRIEF = NO
-
-# The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make doxygen treat a
-# multi-line C++ special comment block (i.e. a block of //! or /// comments) as
-# a brief description. This used to be the default behavior. The new default is
-# to treat a multi-line C++ comment block as a detailed description. Set this
-# tag to YES if you prefer the old behavior instead.
-#
-# Note that setting this tag to YES also means that rational rose comments are
-# not recognized any more.
-# The default value is: NO.
-
-MULTILINE_CPP_IS_BRIEF = YES
-
-# If the INHERIT_DOCS tag is set to YES then an undocumented member inherits the
-# documentation from any documented member that it re-implements.
-# The default value is: YES.
-
-INHERIT_DOCS = NO
-
-# If the SEPARATE_MEMBER_PAGES tag is set to YES, then doxygen will produce a
-# new page for each member. If set to NO, the documentation of a member will be
-# part of the file/class/namespace that contains it.
-# The default value is: NO.
-
-SEPARATE_MEMBER_PAGES = NO
-
-# The TAB_SIZE tag can be used to set the number of spaces in a tab. Doxygen
-# uses this value to replace tabs by spaces in code fragments.
-# Minimum value: 1, maximum value: 16, default value: 4.
-
-TAB_SIZE = 8
-
-# This tag can be used to specify a number of aliases that act as commands in
-# the documentation. An alias has the form:
-# name=value
-# For example adding
-# "sideeffect=@par Side Effects:\n"
-# will allow you to put the command \sideeffect (or @sideeffect) in the
-# documentation, which will result in a user-defined paragraph with heading
-# "Side Effects:". You can put \n's in the value part of an alias to insert
-# newlines.
-
-ALIASES = "token{1}=
\1 " \
- "kbd{1}=\token{
\1 }" \
- "elem{1}=\b \<\1>"
-
-# This tag can be used to specify a number of word-keyword mappings (TCL only).
-# A mapping has the form "name=value". For example adding "class=itcl::class"
-# will allow you to use the command class in the itcl::class meaning.
-
-TCL_SUBST =
-
-# Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C sources
-# only. Doxygen will then generate output that is more tailored for C. For
-# instance, some of the names that are used will be different. The list of all
-# members will be omitted, etc.
-# The default value is: NO.
-
-OPTIMIZE_OUTPUT_FOR_C = YES
-
-# Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java or
-# Python sources only. Doxygen will then generate output that is more tailored
-# for that language. For instance, namespaces will be presented as packages,
-# qualified scopes will look different, etc.
-# The default value is: NO.
-
-OPTIMIZE_OUTPUT_JAVA = NO
-
-# Set the OPTIMIZE_FOR_FORTRAN tag to YES if your project consists of Fortran
-# sources. Doxygen will then generate output that is tailored for Fortran.
-# The default value is: NO.
-
-OPTIMIZE_FOR_FORTRAN = NO
-
-# Set the OPTIMIZE_OUTPUT_VHDL tag to YES if your project consists of VHDL
-# sources. Doxygen will then generate output that is tailored for VHDL.
-# The default value is: NO.
-
-OPTIMIZE_OUTPUT_VHDL = NO
-
-# Doxygen selects the parser to use depending on the extension of the files it
-# parses. With this tag you can assign which parser to use for a given
-# extension. Doxygen has a built-in mapping, but you can override or extend it
-# using this tag. The format is ext=language, where ext is a file extension, and
-# language is one of the parsers supported by doxygen: IDL, Java, Javascript,
-# C#, C, C++, D, PHP, Objective-C, Python, Fortran, VHDL. For instance to make
-# doxygen treat .inc files as Fortran files (default is PHP), and .f files as C
-# (default is Fortran), use: inc=Fortran f=C.
-#
-# Note For files without extension you can use no_extension as a placeholder.
-#
-# Note that for custom extensions you also need to set FILE_PATTERNS otherwise
-# the files are not read by doxygen.
-
-EXTENSION_MAPPING =
-
-# If the MARKDOWN_SUPPORT tag is enabled then doxygen pre-processes all comments
-# according to the Markdown format, which allows for more readable
-# documentation. See http://daringfireball.net/projects/markdown/ for details.
-# The output of markdown processing is further processed by doxygen, so you can
-# mix doxygen, HTML, and XML commands with Markdown formatting. Disable only in
-# case of backward compatibilities issues.
-# The default value is: YES.
-
-MARKDOWN_SUPPORT = YES
-
-# When enabled doxygen tries to link words that correspond to documented
-# classes, or namespaces to their corresponding documentation. Such a link can
-# be prevented in individual cases by by putting a % sign in front of the word
-# or globally by setting AUTOLINK_SUPPORT to NO.
-# The default value is: YES.
-
-AUTOLINK_SUPPORT = YES
-
-# If you use STL classes (i.e. std::string, std::vector, etc.) but do not want
-# to include (a tag file for) the STL sources as input, then you should set this
-# tag to YES in order to let doxygen match functions declarations and
-# definitions whose arguments contain STL classes (e.g. func(std::string);
-# versus func(std::string) {}). This also make the inheritance and collaboration
-# diagrams that involve STL classes more complete and accurate.
-# The default value is: NO.
-
-BUILTIN_STL_SUPPORT = NO
-
-# If you use Microsoft's C++/CLI language, you should set this option to YES to
-# enable parsing support.
-# The default value is: NO.
-
-CPP_CLI_SUPPORT = NO
-
-# Set the SIP_SUPPORT tag to YES if your project consists of sip (see:
-# http://www.riverbankcomputing.co.uk/software/sip/intro) sources only. Doxygen
-# will parse them like normal C++ but will assume all classes use public instead
-# of private inheritance when no explicit protection keyword is present.
-# The default value is: NO.
-
-SIP_SUPPORT = NO
-
-# For Microsoft's IDL there are propget and propput attributes to indicate
-# getter and setter methods for a property. Setting this option to YES will make
-# doxygen to replace the get and set methods by a property in the documentation.
-# This will only work if the methods are indeed getting or setting a simple
-# type. If this is not the case, or you want to show the methods anyway, you
-# should set this option to NO.
-# The default value is: YES.
-
-IDL_PROPERTY_SUPPORT = YES
-
-# If member grouping is used in the documentation and the DISTRIBUTE_GROUP_DOC
-# tag is set to YES, then doxygen will reuse the documentation of the first
-# member in the group (if any) for the other members of the group. By default
-# all members of a group must be documented explicitly.
-# The default value is: NO.
-
-DISTRIBUTE_GROUP_DOC = NO
-
-# Set the SUBGROUPING tag to YES to allow class member groups of the same type
-# (for instance a group of public functions) to be put as a subgroup of that
-# type (e.g. under the Public Functions section). Set it to NO to prevent
-# subgrouping. Alternatively, this can be done per class using the
-# \nosubgrouping command.
-# The default value is: YES.
-
-SUBGROUPING = YES
-
-# When the INLINE_GROUPED_CLASSES tag is set to YES, classes, structs and unions
-# are shown inside the group in which they are included (e.g. using \ingroup)
-# instead of on a separate page (for HTML and Man pages) or section (for LaTeX
-# and RTF).
-#
-# Note that this feature does not work in combination with
-# SEPARATE_MEMBER_PAGES.
-# The default value is: NO.
-
-INLINE_GROUPED_CLASSES = YES
-
-# When the INLINE_SIMPLE_STRUCTS tag is set to YES, structs, classes, and unions
-# with only public data fields or simple typedef fields will be shown inline in
-# the documentation of the scope in which they are defined (i.e. file,
-# namespace, or group documentation), provided this scope is documented. If set
-# to NO, structs, classes, and unions are shown on a separate page (for HTML and
-# Man pages) or section (for LaTeX and RTF).
-# The default value is: NO.
-
-INLINE_SIMPLE_STRUCTS = YES
-
-# When TYPEDEF_HIDES_STRUCT tag is enabled, a typedef of a struct, union, or
-# enum is documented as struct, union, or enum with the name of the typedef. So
-# typedef struct TypeS {} TypeT, will appear in the documentation as a struct
-# with name TypeT. When disabled the typedef will appear as a member of a file,
-# namespace, or class. And the struct will be named TypeS. This can typically be
-# useful for C code in case the coding convention dictates that all compound
-# types are typedef'ed and only the typedef is referenced, never the tag name.
-# The default value is: NO.
-
-TYPEDEF_HIDES_STRUCT = YES
-
-# The size of the symbol lookup cache can be set using LOOKUP_CACHE_SIZE. This
-# cache is used to resolve symbols given their name and scope. Since this can be
-# an expensive process and often the same symbol appears multiple times in the
-# code, doxygen keeps a cache of pre-resolved symbols. If the cache is too small
-# doxygen will become slower. If the cache is too large, memory is wasted. The
-# cache size is given by this formula: 2^(16+LOOKUP_CACHE_SIZE). The valid range
-# is 0..9, the default is 0, corresponding to a cache size of 2^16=65536
-# symbols. At the end of a run doxygen will report the cache usage and suggest
-# the optimal cache size from a speed point of view.
-# Minimum value: 0, maximum value: 9, default value: 0.
-
-LOOKUP_CACHE_SIZE = 0
-
-#---------------------------------------------------------------------------
-# Build related configuration options
-#---------------------------------------------------------------------------
-
-# If the EXTRACT_ALL tag is set to YES doxygen will assume all entities in
-# documentation are documented, even if no documentation was available. Private
-# class members and static file members will be hidden unless the
-# EXTRACT_PRIVATE respectively EXTRACT_STATIC tags are set to YES.
-# Note: This will also disable the warnings about undocumented members that are
-# normally produced when WARNINGS is set to YES.
-# The default value is: NO.
-
-EXTRACT_ALL = YES
-
-# If the EXTRACT_PRIVATE tag is set to YES all private members of a class will
-# be included in the documentation.
-# The default value is: NO.
-
-EXTRACT_PRIVATE = NO
-
-# If the EXTRACT_PACKAGE tag is set to YES all members with package or internal
-# scope will be included in the documentation.
-# The default value is: NO.
-
-EXTRACT_PACKAGE = NO
-
-# If the EXTRACT_STATIC tag is set to YES all static members of a file will be
-# included in the documentation.
-# The default value is: NO.
-
-EXTRACT_STATIC = NO
-
-# If the EXTRACT_LOCAL_CLASSES tag is set to YES classes (and structs) defined
-# locally in source files will be included in the documentation. If set to NO
-# only classes defined in header files are included. Does not have any effect
-# for Java sources.
-# The default value is: YES.
-
-EXTRACT_LOCAL_CLASSES = YES
-
-# This flag is only useful for Objective-C code. When set to YES local methods,
-# which are defined in the implementation section but not in the interface are
-# included in the documentation. If set to NO only methods in the interface are
-# included.
-# The default value is: NO.
-
-EXTRACT_LOCAL_METHODS = NO
-
-# If this flag is set to YES, the members of anonymous namespaces will be
-# extracted and appear in the documentation as a namespace called
-# 'anonymous_namespace{file}', where file will be replaced with the base name of
-# the file that contains the anonymous namespace. By default anonymous namespace
-# are hidden.
-# The default value is: NO.
-
-EXTRACT_ANON_NSPACES = NO
-
-# If the HIDE_UNDOC_MEMBERS tag is set to YES, doxygen will hide all
-# undocumented members inside documented classes or files. If set to NO these
-# members will be included in the various overviews, but no documentation
-# section is generated. This option has no effect if EXTRACT_ALL is enabled.
-# The default value is: NO.
-
-HIDE_UNDOC_MEMBERS = NO
-
-# If the HIDE_UNDOC_CLASSES tag is set to YES, doxygen will hide all
-# undocumented classes that are normally visible in the class hierarchy. If set
-# to NO these classes will be included in the various overviews. This option has
-# no effect if EXTRACT_ALL is enabled.
-# The default value is: NO.
-
-HIDE_UNDOC_CLASSES = NO
-
-# If the HIDE_FRIEND_COMPOUNDS tag is set to YES, doxygen will hide all friend
-# (class|struct|union) declarations. If set to NO these declarations will be
-# included in the documentation.
-# The default value is: NO.
-
-HIDE_FRIEND_COMPOUNDS = NO
-
-# If the HIDE_IN_BODY_DOCS tag is set to YES, doxygen will hide any
-# documentation blocks found inside the body of a function. If set to NO these
-# blocks will be appended to the function's detailed documentation block.
-# The default value is: NO.
-
-HIDE_IN_BODY_DOCS = NO
-
-# The INTERNAL_DOCS tag determines if documentation that is typed after a
-# \internal command is included. If the tag is set to NO then the documentation
-# will be excluded. Set it to YES to include the internal documentation.
-# The default value is: NO.
-
-INTERNAL_DOCS = NO
-
-# If the CASE_SENSE_NAMES tag is set to NO then doxygen will only generate file
-# names in lower-case letters. If set to YES upper-case letters are also
-# allowed. This is useful if you have classes or files whose names only differ
-# in case and if your file system supports case sensitive file names. Windows
-# and Mac users are advised to set this option to NO.
-# The default value is: system dependent.
-
-CASE_SENSE_NAMES = YES
-
-# If the HIDE_SCOPE_NAMES tag is set to NO then doxygen will show members with
-# their full class and namespace scopes in the documentation. If set to YES the
-# scope will be hidden.
-# The default value is: NO.
-
-HIDE_SCOPE_NAMES = YES
-
-# If the SHOW_INCLUDE_FILES tag is set to YES then doxygen will put a list of
-# the files that are included by a file in the documentation of that file.
-# The default value is: YES.
-
-SHOW_INCLUDE_FILES = NO
-
-
-SHOW_GROUPED_MEMB_INC = NO
-
-# If the FORCE_LOCAL_INCLUDES tag is set to YES then doxygen will list include
-# files with double quotes in the documentation rather than with sharp brackets.
-# The default value is: NO.
-
-FORCE_LOCAL_INCLUDES = NO
-
-# If the INLINE_INFO tag is set to YES then a tag [inline] is inserted in the
-# documentation for inline members.
-# The default value is: YES.
-
-INLINE_INFO = YES
-
-# If the SORT_MEMBER_DOCS tag is set to YES then doxygen will sort the
-# (detailed) documentation of file and class members alphabetically by member
-# name. If set to NO the members will appear in declaration order.
-# The default value is: YES.
-
-SORT_MEMBER_DOCS = NO
-
-# If the SORT_BRIEF_DOCS tag is set to YES then doxygen will sort the brief
-# descriptions of file, namespace and class members alphabetically by member
-# name. If set to NO the members will appear in declaration order. Note that
-# this will also influence the order of the classes in the class list.
-# The default value is: NO.
-
-SORT_BRIEF_DOCS = NO
-
-# If the SORT_MEMBERS_CTORS_1ST tag is set to YES then doxygen will sort the
-# (brief and detailed) documentation of class members so that constructors and
-# destructors are listed first. If set to NO the constructors will appear in the
-# respective orders defined by SORT_BRIEF_DOCS and SORT_MEMBER_DOCS.
-# Note: If SORT_BRIEF_DOCS is set to NO this option is ignored for sorting brief
-# member documentation.
-# Note: If SORT_MEMBER_DOCS is set to NO this option is ignored for sorting
-# detailed member documentation.
-# The default value is: NO.
-
-SORT_MEMBERS_CTORS_1ST = NO
-
-# If the SORT_GROUP_NAMES tag is set to YES then doxygen will sort the hierarchy
-# of group names into alphabetical order. If set to NO the group names will
-# appear in their defined order.
-# The default value is: NO.
-
-SORT_GROUP_NAMES = NO
-
-# If the SORT_BY_SCOPE_NAME tag is set to YES, the class list will be sorted by
-# fully-qualified names, including namespaces. If set to NO, the class list will
-# be sorted only by class name, not including the namespace part.
-# Note: This option is not very useful if HIDE_SCOPE_NAMES is set to YES.
-# Note: This option applies only to the class list, not to the alphabetical
-# list.
-# The default value is: NO.
-
-SORT_BY_SCOPE_NAME = NO
-
-# If the STRICT_PROTO_MATCHING option is enabled and doxygen fails to do proper
-# type resolution of all parameters of a function it will reject a match between
-# the prototype and the implementation of a member function even if there is
-# only one candidate or it is obvious which candidate to choose by doing a
-# simple string match. By disabling STRICT_PROTO_MATCHING doxygen will still
-# accept a match between prototype and implementation in such cases.
-# The default value is: NO.
-
-STRICT_PROTO_MATCHING = YES
-
-# The GENERATE_TODOLIST tag can be used to enable ( YES) or disable ( NO) the
-# todo list. This list is created by putting \todo commands in the
-# documentation.
-# The default value is: YES.
-
-GENERATE_TODOLIST = YES
-
-# The GENERATE_TESTLIST tag can be used to enable ( YES) or disable ( NO) the
-# test list. This list is created by putting \test commands in the
-# documentation.
-# The default value is: YES.
-
-GENERATE_TESTLIST = YES
-
-# The GENERATE_BUGLIST tag can be used to enable ( YES) or disable ( NO) the bug
-# list. This list is created by putting \bug commands in the documentation.
-# The default value is: YES.
-
-GENERATE_BUGLIST = YES
-
-# The GENERATE_DEPRECATEDLIST tag can be used to enable ( YES) or disable ( NO)
-# the deprecated list. This list is created by putting \deprecated commands in
-# the documentation.
-# The default value is: YES.
-
-GENERATE_DEPRECATEDLIST= YES
-
-# The ENABLED_SECTIONS tag can be used to enable conditional documentation
-# sections, marked by \if
... \endif and \cond
-# ... \endcond blocks.
-
-ENABLED_SECTIONS =
-
-# The MAX_INITIALIZER_LINES tag determines the maximum number of lines that the
-# initial value of a variable or macro / define can have for it to appear in the
-# documentation. If the initializer consists of more lines than specified here
-# it will be hidden. Use a value of 0 to hide initializers completely. The
-# appearance of the value of individual variables and macros / defines can be
-# controlled using \showinitializer or \hideinitializer command in the
-# documentation regardless of this setting.
-# Minimum value: 0, maximum value: 10000, default value: 30.
-
-MAX_INITIALIZER_LINES = 1
-
-# Set the SHOW_USED_FILES tag to NO to disable the list of files generated at
-# the bottom of the documentation of classes and structs. If set to YES the list
-# will mention the files that were used to generate the documentation.
-# The default value is: YES.
-
-SHOW_USED_FILES = NO
-
-# Set the SHOW_FILES tag to NO to disable the generation of the Files page. This
-# will remove the Files entry from the Quick Index and from the Folder Tree View
-# (if specified).
-# The default value is: YES.
-
-SHOW_FILES = YES
-
-# Set the SHOW_NAMESPACES tag to NO to disable the generation of the Namespaces
-# page. This will remove the Namespaces entry from the Quick Index and from the
-# Folder Tree View (if specified).
-# The default value is: YES.
-
-SHOW_NAMESPACES = YES
-
-# The FILE_VERSION_FILTER tag can be used to specify a program or script that
-# doxygen should invoke to get the current version for each file (typically from
-# the version control system). Doxygen will invoke the program by executing (via
-# popen()) the command command input-file, where command is the value of the
-# FILE_VERSION_FILTER tag, and input-file is the name of an input file provided
-# by doxygen. Whatever the program writes to standard output is used as the file
-# version. For an example see the documentation.
-
-FILE_VERSION_FILTER =
-
-# The LAYOUT_FILE tag can be used to specify a layout file which will be parsed
-# by doxygen. The layout file controls the global structure of the generated
-# output files in an output format independent way. To create the layout file
-# that represents doxygen's defaults, run doxygen with the -l option. You can
-# optionally specify a file name after the option, if omitted DoxygenLayout.xml
-# will be used as the name of the layout file.
-#
-# Note that if you run doxygen from a directory containing a file called
-# DoxygenLayout.xml, doxygen will parse it automatically even if the LAYOUT_FILE
-# tag is left empty.
-
-LAYOUT_FILE = ../Doxygen_Templates/DoxygenLayout_forUser.xml
-
-# The CITE_BIB_FILES tag can be used to specify one or more bib files containing
-# the reference definitions. This must be a list of .bib files. The .bib
-# extension is automatically appended if omitted. This requires the bibtex tool
-# to be installed. See also http://en.wikipedia.org/wiki/BibTeX for more info.
-# For LaTeX the style of the bibliography can be controlled using
-# LATEX_BIB_STYLE. To use this feature you need bibtex and perl available in the
-# search path. Do not use file names with spaces, bibtex cannot handle them. See
-# also \cite for info how to create references.
-
-CITE_BIB_FILES =
-
-#---------------------------------------------------------------------------
-# Configuration options related to warning and progress messages
-#---------------------------------------------------------------------------
-
-# The QUIET tag can be used to turn on/off the messages that are generated to
-# standard output by doxygen. If QUIET is set to YES this implies that the
-# messages are off.
-# The default value is: NO.
-
-QUIET = YES
-
-# The WARNINGS tag can be used to turn on/off the warning messages that are
-# generated to standard error ( stderr) by doxygen. If WARNINGS is set to YES
-# this implies that the warnings are on.
-#
-# Tip: Turn warnings on while writing the documentation.
-# The default value is: YES.
-
-WARNINGS = YES
-
-# If the WARN_IF_UNDOCUMENTED tag is set to YES, then doxygen will generate
-# warnings for undocumented members. If EXTRACT_ALL is set to YES then this flag
-# will automatically be disabled.
-# The default value is: YES.
-
-WARN_IF_UNDOCUMENTED = YES
-
-# If the WARN_IF_DOC_ERROR tag is set to YES, doxygen will generate warnings for
-# potential errors in the documentation, such as not documenting some parameters
-# in a documented function, or documenting parameters that don't exist or using
-# markup commands wrongly.
-# The default value is: YES.
-
-WARN_IF_DOC_ERROR = YES
-
-# This WARN_NO_PARAMDOC option can be enabled to get warnings for functions that
-# are documented, but have no documentation for their parameters or return
-# value. If set to NO doxygen will only warn about wrong or incomplete parameter
-# documentation, but not about the absence of documentation.
-# The default value is: NO.
-
-WARN_NO_PARAMDOC = YES
-
-# The WARN_FORMAT tag determines the format of the warning messages that doxygen
-# can produce. The string should contain the $file, $line, and $text tags, which
-# will be replaced by the file and line number from which the warning originated
-# and the warning text. Optionally the format may contain $version, which will
-# be replaced by the version of the file (if it could be obtained via
-# FILE_VERSION_FILTER)
-# The default value is: $file:$line: $text.
-
-WARN_FORMAT = "$file:$line: $text"
-
-# The WARN_LOGFILE tag can be used to specify a file to which warning and error
-# messages should be written. If left blank the output is written to standard
-# error (stderr).
-
-WARN_LOGFILE =
-
-#---------------------------------------------------------------------------
-# Configuration options related to the input files
-#---------------------------------------------------------------------------
-
-# The INPUT tag is used to specify the files and/or directories that contain
-# documented source files. You may enter file names like myfile.cpp or
-# directories like /usr/src/myproject. Separate the files or directories with
-# spaces.
-# Note: If this tag is empty the current directory is searched.
-
-INPUT = . \
- ../../Driver/Include/Driver_Common.h \
- src/Driver_Common.c \
- ../../Driver/Include/Driver_CAN.h \
- src/Driver_CAN.c \
- ../../Driver/Include/Driver_ETH.h \
- src/Driver_ETH.c \
- ../../Driver/Include/Driver_ETH_MAC.h \
- src/Driver_ETH_MAC.c \
- ../../Driver/Include/Driver_ETH_PHY.h \
- src/Driver_ETH_PHY.c \
- ../../Driver/Include/Driver_I2C.h \
- src/Driver_I2C.c \
- ../../Driver/Include/Driver_MCI.h \
- src/Driver_MCI.c \
- ../../Driver/Include/Driver_NAND.h \
- src/Driver_NAND.c \
- ../../Driver/Include/Driver_Flash.h \
- src/Driver_Flash.c \
- ../../Driver/Include/Driver_SAI.h \
- src/Driver_SAI.c \
- ../../Driver/Include/Driver_SPI.h \
- src/Driver_SPI.c \
- ../../Driver/Include/Driver_Storage.h \
- src/Driver_Storage.c \
- ../../Driver/Include/Driver_USART.h \
- src/Driver_USART.c \
- ../../Driver/Include/Driver_USBD.h \
- src/Driver_USBD.c \
- ../../Driver/Include/Driver_USBH.h \
- src/Driver_USBH.c \
- ../../Driver/Include/Driver_USB.h \
- src/Driver_USB.c \
- ../../Driver/VIO/Include/cmsis_vio.h \
- src/VIO.txt \
- ../../Driver/Include/Driver_WiFi.h \
- src/Driver_WiFi.c \
- src/General.txt
-
-# This tag can be used to specify the character encoding of the source files
-# that doxygen parses. Internally doxygen uses the UTF-8 encoding. Doxygen uses
-# libiconv (or the iconv built into libc) for the transcoding. See the libiconv
-# documentation (see: http://www.gnu.org/software/libiconv) for the list of
-# possible encodings.
-# The default value is: UTF-8.
-
-INPUT_ENCODING = UTF-8
-
-# If the value of the INPUT tag contains directories, you can use the
-# FILE_PATTERNS tag to specify one or more wildcard patterns (like *.cpp and
-# *.h) to filter out the source-files in the directories. If left blank the
-# following patterns are tested:*.c, *.cc, *.cxx, *.cpp, *.c++, *.java, *.ii,
-# *.ixx, *.ipp, *.i++, *.inl, *.idl, *.ddl, *.odl, *.h, *.hh, *.hxx, *.hpp,
-# *.h++, *.cs, *.d, *.php, *.php4, *.php5, *.phtml, *.inc, *.m, *.markdown,
-# *.md, *.mm, *.dox, *.py, *.f90, *.f, *.for, *.tcl, *.vhd, *.vhdl, *.ucf,
-# *.qsf, *.as and *.js.
-
-FILE_PATTERNS = *.c \
- *.cpp \
- *.c++ \
- *.java \
- *.h \
- *.hh \
- *.hpp \
- *.h++ \
- *.inc \
- *.txt
-
-# The RECURSIVE tag can be used to specify whether or not subdirectories should
-# be searched for input files as well.
-# The default value is: NO.
-
-RECURSIVE = NO
-
-# The EXCLUDE tag can be used to specify files and/or directories that should be
-# excluded from the INPUT source files. This way you can easily exclude a
-# subdirectory from a directory tree whose root is specified with the INPUT tag.
-#
-# Note that relative paths are relative to the directory from which doxygen is
-# run.
-
-EXCLUDE =
-
-# The EXCLUDE_SYMLINKS tag can be used to select whether or not files or
-# directories that are symbolic links (a Unix file system feature) are excluded
-# from the input.
-# The default value is: NO.
-
-EXCLUDE_SYMLINKS = YES
-
-# If the value of the INPUT tag contains directories, you can use the
-# EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude
-# certain files from those directories.
-#
-# Note that the wildcards are matched against the file with absolute path, so to
-# exclude all test directories for example use the pattern */test/*
-
-EXCLUDE_PATTERNS =
-
-# The EXCLUDE_SYMBOLS tag can be used to specify one or more symbol names
-# (namespaces, classes, functions, etc.) that should be excluded from the
-# output. The symbol name can be a fully qualified name, a word, or if the
-# wildcard * is used, a substring. Examples: ANamespace, AClass,
-# AClass::ANamespace, ANamespace::*Test
-#
-# Note that the wildcards are matched against the file with absolute path, so to
-# exclude all test directories use the pattern */test/*
-
-EXCLUDE_SYMBOLS =
-
-# The EXAMPLE_PATH tag can be used to specify one or more files or directories
-# that contain example code fragments that are included (see the \include
-# command).
-
-EXAMPLE_PATH = ../../Driver/Include \
- ./src
-
-# If the value of the EXAMPLE_PATH tag contains directories, you can use the
-# EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp and
-# *.h) to filter out the source-files in the directories. If left blank all
-# files are included.
-
-EXAMPLE_PATTERNS = *
-
-# If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be
-# searched for input files to be used with the \include or \dontinclude commands
-# irrespective of the value of the RECURSIVE tag.
-# The default value is: NO.
-
-EXAMPLE_RECURSIVE = NO
-
-# The IMAGE_PATH tag can be used to specify one or more files or directories
-# that contain images that are to be included in the documentation (see the
-# \image command).
-
-IMAGE_PATH = src/images
-
-# The INPUT_FILTER tag can be used to specify a program that doxygen should
-# invoke to filter for each input file. Doxygen will invoke the filter program
-# by executing (via popen()) the command:
-#
-#
-#
-# where is the value of the INPUT_FILTER tag, and is the
-# name of an input file. Doxygen will then use the output that the filter
-# program writes to standard output. If FILTER_PATTERNS is specified, this tag
-# will be ignored.
-#
-# Note that the filter must not add or remove lines; it is applied before the
-# code is scanned, but not when the output code is generated. If lines are added
-# or removed, the anchors will not be placed correctly.
-
-INPUT_FILTER =
-
-# The FILTER_PATTERNS tag can be used to specify filters on a per file pattern
-# basis. Doxygen will compare the file name with each pattern and apply the
-# filter if there is a match. The filters are a list of the form: pattern=filter
-# (like *.cpp=my_cpp_filter). See INPUT_FILTER for further information on how
-# filters are used. If the FILTER_PATTERNS tag is empty or if none of the
-# patterns match the file name, INPUT_FILTER is applied.
-
-FILTER_PATTERNS =
-
-# If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using
-# INPUT_FILTER ) will also be used to filter the input files that are used for
-# producing the source files to browse (i.e. when SOURCE_BROWSER is set to YES).
-# The default value is: NO.
-
-FILTER_SOURCE_FILES = NO
-
-# The FILTER_SOURCE_PATTERNS tag can be used to specify source filters per file
-# pattern. A pattern will override the setting for FILTER_PATTERN (if any) and
-# it is also possible to disable source filtering for a specific pattern using
-# *.ext= (so without naming a filter).
-# This tag requires that the tag FILTER_SOURCE_FILES is set to YES.
-
-FILTER_SOURCE_PATTERNS =
-
-# If the USE_MDFILE_AS_MAINPAGE tag refers to the name of a markdown file that
-# is part of the input, its contents will be placed on the main page
-# (index.html). This can be useful if you have a project on for instance GitHub
-# and want to reuse the introduction page also for the doxygen output.
-
-USE_MDFILE_AS_MAINPAGE =
-
-#---------------------------------------------------------------------------
-# Configuration options related to source browsing
-#---------------------------------------------------------------------------
-
-# If the SOURCE_BROWSER tag is set to YES then a list of source files will be
-# generated. Documented entities will be cross-referenced with these sources.
-#
-# Note: To get rid of all source code in the generated output, make sure that
-# also VERBATIM_HEADERS is set to NO.
-# The default value is: NO.
-
-SOURCE_BROWSER = NO
-
-# Setting the INLINE_SOURCES tag to YES will include the body of functions,
-# classes and enums directly into the documentation.
-# The default value is: NO.
-
-INLINE_SOURCES = NO
-
-# Setting the STRIP_CODE_COMMENTS tag to YES will instruct doxygen to hide any
-# special comment blocks from generated source code fragments. Normal C, C++ and
-# Fortran comments will always remain visible.
-# The default value is: YES.
-
-STRIP_CODE_COMMENTS = NO
-
-# If the REFERENCED_BY_RELATION tag is set to YES then for each documented
-# function all documented functions referencing it will be listed.
-# The default value is: NO.
-
-REFERENCED_BY_RELATION = YES
-
-# If the REFERENCES_RELATION tag is set to YES then for each documented function
-# all documented entities called/used by that function will be listed.
-# The default value is: NO.
-
-REFERENCES_RELATION = NO
-
-# If the REFERENCES_LINK_SOURCE tag is set to YES and SOURCE_BROWSER tag is set
-# to YES, then the hyperlinks from functions in REFERENCES_RELATION and
-# REFERENCED_BY_RELATION lists will link to the source code. Otherwise they will
-# link to the documentation.
-# The default value is: YES.
-
-REFERENCES_LINK_SOURCE = NO
-
-# If SOURCE_TOOLTIPS is enabled (the default) then hovering a hyperlink in the
-# source code will show a tooltip with additional information such as prototype,
-# brief description and links to the definition and documentation. Since this
-# will make the HTML file larger and loading of large files a bit slower, you
-# can opt to disable this feature.
-# The default value is: YES.
-# This tag requires that the tag SOURCE_BROWSER is set to YES.
-
-SOURCE_TOOLTIPS = YES
-
-# If the USE_HTAGS tag is set to YES then the references to source code will
-# point to the HTML generated by the htags(1) tool instead of doxygen built-in
-# source browser. The htags tool is part of GNU's global source tagging system
-# (see http://www.gnu.org/software/global/global.html). You will need version
-# 4.8.6 or higher.
-#
-# To use it do the following:
-# - Install the latest version of global
-# - Enable SOURCE_BROWSER and USE_HTAGS in the config file
-# - Make sure the INPUT points to the root of the source tree
-# - Run doxygen as normal
-#
-# Doxygen will invoke htags (and that will in turn invoke gtags), so these
-# tools must be available from the command line (i.e. in the search path).
-#
-# The result: instead of the source browser generated by doxygen, the links to
-# source code will now point to the output of htags.
-# The default value is: NO.
-# This tag requires that the tag SOURCE_BROWSER is set to YES.
-
-USE_HTAGS = NO
-
-# If the VERBATIM_HEADERS tag is set the YES then doxygen will generate a
-# verbatim copy of the header file for each class for which an include is
-# specified. Set to NO to disable this.
-# See also: Section \class.
-# The default value is: YES.
-
-VERBATIM_HEADERS = NO
-
-#---------------------------------------------------------------------------
-# Configuration options related to the alphabetical class index
-#---------------------------------------------------------------------------
-
-# If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index of all
-# compounds will be generated. Enable this if the project contains a lot of
-# classes, structs, unions or interfaces.
-# The default value is: YES.
-
-ALPHABETICAL_INDEX = YES
-
-# The COLS_IN_ALPHA_INDEX tag can be used to specify the number of columns in
-# which the alphabetical index list will be split.
-# Minimum value: 1, maximum value: 20, default value: 5.
-# This tag requires that the tag ALPHABETICAL_INDEX is set to YES.
-
-COLS_IN_ALPHA_INDEX = 5
-
-# In case all classes in a project start with a common prefix, all classes will
-# be put under the same header in the alphabetical index. The IGNORE_PREFIX tag
-# can be used to specify a prefix (or a list of prefixes) that should be ignored
-# while generating the index headers.
-# This tag requires that the tag ALPHABETICAL_INDEX is set to YES.
-
-IGNORE_PREFIX = ARM_
-
-#---------------------------------------------------------------------------
-# Configuration options related to the HTML output
-#---------------------------------------------------------------------------
-
-# If the GENERATE_HTML tag is set to YES doxygen will generate HTML output
-# The default value is: YES.
-
-GENERATE_HTML = YES
-
-# The HTML_OUTPUT tag is used to specify where the HTML docs will be put. If a
-# relative path is entered the value of OUTPUT_DIRECTORY will be put in front of
-# it.
-# The default directory is: html.
-# This tag requires that the tag GENERATE_HTML is set to YES.
-
-HTML_OUTPUT = html
-
-# The HTML_FILE_EXTENSION tag can be used to specify the file extension for each
-# generated HTML page (for example: .htm, .php, .asp).
-# The default value is: .html.
-# This tag requires that the tag GENERATE_HTML is set to YES.
-
-HTML_FILE_EXTENSION = .html
-
-# The HTML_HEADER tag can be used to specify a user-defined HTML header file for
-# each generated HTML page. If the tag is left blank doxygen will generate a
-# standard header.
-#
-# To get valid HTML the header file that includes any scripts and style sheets
-# that doxygen needs, which is dependent on the configuration options used (e.g.
-# the setting GENERATE_TREEVIEW). It is highly recommended to start with a
-# default header using
-# doxygen -w html new_header.html new_footer.html new_stylesheet.css
-# YourConfigFile
-# and then modify the file new_header.html. See also section "Doxygen usage"
-# for information on how to generate the default header that doxygen normally
-# uses.
-# Note: The header is subject to change so you typically have to regenerate the
-# default header when upgrading to a newer version of doxygen. For a description
-# of the possible markers and block names see the documentation.
-# This tag requires that the tag GENERATE_HTML is set to YES.
-
-HTML_HEADER = ../Doxygen_Templates/cmsis_header.html
-
-# The HTML_FOOTER tag can be used to specify a user-defined HTML footer for each
-# generated HTML page. If the tag is left blank doxygen will generate a standard
-# footer. See HTML_HEADER for more information on how to generate a default
-# footer and what special commands can be used inside the footer. See also
-# section "Doxygen usage" for information on how to generate the default footer
-# that doxygen normally uses.
-# This tag requires that the tag GENERATE_HTML is set to YES.
-
-HTML_FOOTER = ../Doxygen_Templates/cmsis_footer.html
-
-# The HTML_STYLESHEET tag can be used to specify a user-defined cascading style
-# sheet that is used by each HTML page. It can be used to fine-tune the look of
-# the HTML output. If left blank doxygen will generate a default style sheet.
-# See also section "Doxygen usage" for information on how to generate the style
-# sheet that doxygen normally uses.
-# Note: It is recommended to use HTML_EXTRA_STYLESHEET instead of this tag, as
-# it is more robust and this tag (HTML_STYLESHEET) will in the future become
-# obsolete.
-# This tag requires that the tag GENERATE_HTML is set to YES.
-
-HTML_STYLESHEET =
-
-# The HTML_EXTRA_STYLESHEET tag can be used to specify an additional user-
-# defined cascading style sheet that is included after the standard style sheets
-# created by doxygen. Using this option one can overrule certain style aspects.
-# This is preferred over using HTML_STYLESHEET since it does not replace the
-# standard style sheet and is therefor more robust against future updates.
-# Doxygen will copy the style sheet file to the output directory. For an example
-# see the documentation.
-# This tag requires that the tag GENERATE_HTML is set to YES.
-
-HTML_EXTRA_STYLESHEET = ../Doxygen_Templates/cmsis.css
-
-# The HTML_EXTRA_FILES tag can be used to specify one or more extra images or
-# other source files which should be copied to the HTML output directory. Note
-# that these files will be copied to the base HTML output directory. Use the
-# $relpath^ marker in the HTML_HEADER and/or HTML_FOOTER files to load these
-# files. In the HTML_STYLESHEET file, use the file name only. Also note that the
-# files will be copied as-is; there are no commands or markers available.
-# This tag requires that the tag GENERATE_HTML is set to YES.
-
-HTML_EXTRA_FILES = ../Doxygen_Templates/tabs.css \
- ../Doxygen_Templates/tab_topnav.png \
- ../Doxygen_Templates/printComponentTabs.js \
- ../Doxygen_Templates/search.css
-
-# The HTML_COLORSTYLE_HUE tag controls the color of the HTML output. Doxygen
-# will adjust the colors in the stylesheet and background images according to
-# this color. Hue is specified as an angle on a colorwheel, see
-# http://en.wikipedia.org/wiki/Hue for more information. For instance the value
-# 0 represents red, 60 is yellow, 120 is green, 180 is cyan, 240 is blue, 300
-# purple, and 360 is red again.
-# Minimum value: 0, maximum value: 359, default value: 220.
-# This tag requires that the tag GENERATE_HTML is set to YES.
-
-HTML_COLORSTYLE_HUE = 220
-
-# The HTML_COLORSTYLE_SAT tag controls the purity (or saturation) of the colors
-# in the HTML output. For a value of 0 the output will use grayscales only. A
-# value of 255 will produce the most vivid colors.
-# Minimum value: 0, maximum value: 255, default value: 100.
-# This tag requires that the tag GENERATE_HTML is set to YES.
-
-HTML_COLORSTYLE_SAT = 100
-
-# The HTML_COLORSTYLE_GAMMA tag controls the gamma correction applied to the
-# luminance component of the colors in the HTML output. Values below 100
-# gradually make the output lighter, whereas values above 100 make the output
-# darker. The value divided by 100 is the actual gamma applied, so 80 represents
-# a gamma of 0.8, The value 220 represents a gamma of 2.2, and 100 does not
-# change the gamma.
-# Minimum value: 40, maximum value: 240, default value: 80.
-# This tag requires that the tag GENERATE_HTML is set to YES.
-
-HTML_COLORSTYLE_GAMMA = 80
-
-# If the HTML_TIMESTAMP tag is set to YES then the footer of each generated HTML
-# page will contain the date and time when the page was generated. Setting this
-# to NO can help when comparing the output of multiple runs.
-# The default value is: YES.
-# This tag requires that the tag GENERATE_HTML is set to YES.
-
-HTML_TIMESTAMP = YES
-
-# If the HTML_DYNAMIC_SECTIONS tag is set to YES then the generated HTML
-# documentation will contain sections that can be hidden and shown after the
-# page has loaded.
-# The default value is: NO.
-# This tag requires that the tag GENERATE_HTML is set to YES.
-
-HTML_DYNAMIC_SECTIONS = NO
-
-# With HTML_INDEX_NUM_ENTRIES one can control the preferred number of entries
-# shown in the various tree structured indices initially; the user can expand
-# and collapse entries dynamically later on. Doxygen will expand the tree to
-# such a level that at most the specified number of entries are visible (unless
-# a fully collapsed tree already exceeds this amount). So setting the number of
-# entries 1 will produce a full collapsed tree by default. 0 is a special value
-# representing an infinite number of entries and will result in a full expanded
-# tree by default.
-# Minimum value: 0, maximum value: 9999, default value: 100.
-# This tag requires that the tag GENERATE_HTML is set to YES.
-
-HTML_INDEX_NUM_ENTRIES = 100
-
-# If the GENERATE_DOCSET tag is set to YES, additional index files will be
-# generated that can be used as input for Apple's Xcode 3 integrated development
-# environment (see: http://developer.apple.com/tools/xcode/), introduced with
-# OSX 10.5 (Leopard). To create a documentation set, doxygen will generate a
-# Makefile in the HTML output directory. Running make will produce the docset in
-# that directory and running make install will install the docset in
-# ~/Library/Developer/Shared/Documentation/DocSets so that Xcode will find it at
-# startup. See http://developer.apple.com/tools/creatingdocsetswithdoxygen.html
-# for more information.
-# The default value is: NO.
-# This tag requires that the tag GENERATE_HTML is set to YES.
-
-GENERATE_DOCSET = NO
-
-# This tag determines the name of the docset feed. A documentation feed provides
-# an umbrella under which multiple documentation sets from a single provider
-# (such as a company or product suite) can be grouped.
-# The default value is: Doxygen generated docs.
-# This tag requires that the tag GENERATE_DOCSET is set to YES.
-
-DOCSET_FEEDNAME = "Doxygen generated docs"
-
-# This tag specifies a string that should uniquely identify the documentation
-# set bundle. This should be a reverse domain-name style string, e.g.
-# com.mycompany.MyDocSet. Doxygen will append .docset to the name.
-# The default value is: org.doxygen.Project.
-# This tag requires that the tag GENERATE_DOCSET is set to YES.
-
-DOCSET_BUNDLE_ID = org.doxygen.Project
-
-# The DOCSET_PUBLISHER_ID tag specifies a string that should uniquely identify
-# the documentation publisher. This should be a reverse domain-name style
-# string, e.g. com.mycompany.MyDocSet.documentation.
-# The default value is: org.doxygen.Publisher.
-# This tag requires that the tag GENERATE_DOCSET is set to YES.
-
-DOCSET_PUBLISHER_ID = org.doxygen.Publisher
-
-# The DOCSET_PUBLISHER_NAME tag identifies the documentation publisher.
-# The default value is: Publisher.
-# This tag requires that the tag GENERATE_DOCSET is set to YES.
-
-DOCSET_PUBLISHER_NAME = Publisher
-
-# If the GENERATE_HTMLHELP tag is set to YES then doxygen generates three
-# additional HTML index files: index.hhp, index.hhc, and index.hhk. The
-# index.hhp is a project file that can be read by Microsoft's HTML Help Workshop
-# (see: http://www.microsoft.com/en-us/download/details.aspx?id=21138) on
-# Windows.
-#
-# The HTML Help Workshop contains a compiler that can convert all HTML output
-# generated by doxygen into a single compiled HTML file (.chm). Compiled HTML
-# files are now used as the Windows 98 help format, and will replace the old
-# Windows help format (.hlp) on all Windows platforms in the future. Compressed
-# HTML files also contain an index, a table of contents, and you can search for
-# words in the documentation. The HTML workshop also contains a viewer for
-# compressed HTML files.
-# The default value is: NO.
-# This tag requires that the tag GENERATE_HTML is set to YES.
-
-GENERATE_HTMLHELP = NO
-
-# The CHM_FILE tag can be used to specify the file name of the resulting .chm
-# file. You can add a path in front of the file if the result should not be
-# written to the html output directory.
-# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
-
-CHM_FILE =
-
-# The HHC_LOCATION tag can be used to specify the location (absolute path
-# including file name) of the HTML help compiler ( hhc.exe). If non-empty
-# doxygen will try to run the HTML help compiler on the generated index.hhp.
-# The file has to be specified with full path.
-# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
-
-HHC_LOCATION =
-
-# The GENERATE_CHI flag controls if a separate .chi index file is generated (
-# YES) or that it should be included in the master .chm file ( NO).
-# The default value is: NO.
-# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
-
-GENERATE_CHI = NO
-
-# The CHM_INDEX_ENCODING is used to encode HtmlHelp index ( hhk), content ( hhc)
-# and project file content.
-# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
-
-CHM_INDEX_ENCODING =
-
-# The BINARY_TOC flag controls whether a binary table of contents is generated (
-# YES) or a normal table of contents ( NO) in the .chm file.
-# The default value is: NO.
-# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
-
-BINARY_TOC = NO
-
-# The TOC_EXPAND flag can be set to YES to add extra items for group members to
-# the table of contents of the HTML help documentation and to the tree view.
-# The default value is: NO.
-# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
-
-TOC_EXPAND = NO
-
-# If the GENERATE_QHP tag is set to YES and both QHP_NAMESPACE and
-# QHP_VIRTUAL_FOLDER are set, an additional index file will be generated that
-# can be used as input for Qt's qhelpgenerator to generate a Qt Compressed Help
-# (.qch) of the generated HTML documentation.
-# The default value is: NO.
-# This tag requires that the tag GENERATE_HTML is set to YES.
-
-GENERATE_QHP = NO
-
-# If the QHG_LOCATION tag is specified, the QCH_FILE tag can be used to specify
-# the file name of the resulting .qch file. The path specified is relative to
-# the HTML output folder.
-# This tag requires that the tag GENERATE_QHP is set to YES.
-
-QCH_FILE =
-
-# The QHP_NAMESPACE tag specifies the namespace to use when generating Qt Help
-# Project output. For more information please see Qt Help Project / Namespace
-# (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#namespace).
-# The default value is: org.doxygen.Project.
-# This tag requires that the tag GENERATE_QHP is set to YES.
-
-QHP_NAMESPACE = org.doxygen.Project
-
-# The QHP_VIRTUAL_FOLDER tag specifies the namespace to use when generating Qt
-# Help Project output. For more information please see Qt Help Project / Virtual
-# Folders (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#virtual-
-# folders).
-# The default value is: doc.
-# This tag requires that the tag GENERATE_QHP is set to YES.
-
-QHP_VIRTUAL_FOLDER = doc
-
-# If the QHP_CUST_FILTER_NAME tag is set, it specifies the name of a custom
-# filter to add. For more information please see Qt Help Project / Custom
-# Filters (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#custom-
-# filters).
-# This tag requires that the tag GENERATE_QHP is set to YES.
-
-QHP_CUST_FILTER_NAME =
-
-# The QHP_CUST_FILTER_ATTRS tag specifies the list of the attributes of the
-# custom filter to add. For more information please see Qt Help Project / Custom
-# Filters (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#custom-
-# filters).
-# This tag requires that the tag GENERATE_QHP is set to YES.
-
-QHP_CUST_FILTER_ATTRS =
-
-# The QHP_SECT_FILTER_ATTRS tag specifies the list of the attributes this
-# project's filter section matches. Qt Help Project / Filter Attributes (see:
-# http://qt-project.org/doc/qt-4.8/qthelpproject.html#filter-attributes).
-# This tag requires that the tag GENERATE_QHP is set to YES.
-
-QHP_SECT_FILTER_ATTRS =
-
-# The QHG_LOCATION tag can be used to specify the location of Qt's
-# qhelpgenerator. If non-empty doxygen will try to run qhelpgenerator on the
-# generated .qhp file.
-# This tag requires that the tag GENERATE_QHP is set to YES.
-
-QHG_LOCATION =
-
-# If the GENERATE_ECLIPSEHELP tag is set to YES, additional index files will be
-# generated, together with the HTML files, they form an Eclipse help plugin. To
-# install this plugin and make it available under the help contents menu in
-# Eclipse, the contents of the directory containing the HTML and XML files needs
-# to be copied into the plugins directory of eclipse. The name of the directory
-# within the plugins directory should be the same as the ECLIPSE_DOC_ID value.
-# After copying Eclipse needs to be restarted before the help appears.
-# The default value is: NO.
-# This tag requires that the tag GENERATE_HTML is set to YES.
-
-GENERATE_ECLIPSEHELP = NO
-
-# A unique identifier for the Eclipse help plugin. When installing the plugin
-# the directory name containing the HTML and XML files should also have this
-# name. Each documentation set should have its own identifier.
-# The default value is: org.doxygen.Project.
-# This tag requires that the tag GENERATE_ECLIPSEHELP is set to YES.
-
-ECLIPSE_DOC_ID = org.doxygen.Project
-
-# If you want full control over the layout of the generated HTML pages it might
-# be necessary to disable the index and replace it with your own. The
-# DISABLE_INDEX tag can be used to turn on/off the condensed index (tabs) at top
-# of each HTML page. A value of NO enables the index and the value YES disables
-# it. Since the tabs in the index contain the same information as the navigation
-# tree, you can set this option to YES if you also set GENERATE_TREEVIEW to YES.
-# The default value is: NO.
-# This tag requires that the tag GENERATE_HTML is set to YES.
-
-DISABLE_INDEX = NO
-
-# The GENERATE_TREEVIEW tag is used to specify whether a tree-like index
-# structure should be generated to display hierarchical information. If the tag
-# value is set to YES, a side panel will be generated containing a tree-like
-# index structure (just like the one that is generated for HTML Help). For this
-# to work a browser that supports JavaScript, DHTML, CSS and frames is required
-# (i.e. any modern browser). Windows users are probably better off using the
-# HTML help feature. Via custom stylesheets (see HTML_EXTRA_STYLESHEET) one can
-# further fine-tune the look of the index. As an example, the default style
-# sheet generated by doxygen has an example that shows how to put an image at
-# the root of the tree instead of the PROJECT_NAME. Since the tree basically has
-# the same information as the tab index, you could consider setting
-# DISABLE_INDEX to YES when enabling this option.
-# The default value is: NO.
-# This tag requires that the tag GENERATE_HTML is set to YES.
-
-GENERATE_TREEVIEW = YES
-
-# The ENUM_VALUES_PER_LINE tag can be used to set the number of enum values that
-# doxygen will group on one line in the generated HTML documentation.
-#
-# Note that a value of 0 will completely suppress the enum values from appearing
-# in the overview section.
-# Minimum value: 0, maximum value: 20, default value: 4.
-# This tag requires that the tag GENERATE_HTML is set to YES.
-
-ENUM_VALUES_PER_LINE = 1
-
-# If the treeview is enabled (see GENERATE_TREEVIEW) then this tag can be used
-# to set the initial width (in pixels) of the frame in which the tree is shown.
-# Minimum value: 0, maximum value: 1500, default value: 250.
-# This tag requires that the tag GENERATE_HTML is set to YES.
-
-TREEVIEW_WIDTH = 250
-
-# When the EXT_LINKS_IN_WINDOW option is set to YES doxygen will open links to
-# external symbols imported via tag files in a separate window.
-# The default value is: NO.
-# This tag requires that the tag GENERATE_HTML is set to YES.
-
-EXT_LINKS_IN_WINDOW = NO
-
-# Use this tag to change the font size of LaTeX formulas included as images in
-# the HTML documentation. When you change the font size after a successful
-# doxygen run you need to manually remove any form_*.png images from the HTML
-# output directory to force them to be regenerated.
-# Minimum value: 8, maximum value: 50, default value: 10.
-# This tag requires that the tag GENERATE_HTML is set to YES.
-
-FORMULA_FONTSIZE = 10
-
-# Use the FORMULA_TRANPARENT tag to determine whether or not the images
-# generated for formulas are transparent PNGs. Transparent PNGs are not
-# supported properly for IE 6.0, but are supported on all modern browsers.
-#
-# Note that when changing this option you need to delete any form_*.png files in
-# the HTML output directory before the changes have effect.
-# The default value is: YES.
-# This tag requires that the tag GENERATE_HTML is set to YES.
-
-FORMULA_TRANSPARENT = YES
-
-# Enable the USE_MATHJAX option to render LaTeX formulas using MathJax (see
-# http://www.mathjax.org) which uses client side Javascript for the rendering
-# instead of using prerendered bitmaps. Use this if you do not have LaTeX
-# installed or if you want to formulas look prettier in the HTML output. When
-# enabled you may also need to install MathJax separately and configure the path
-# to it using the MATHJAX_RELPATH option.
-# The default value is: NO.
-# This tag requires that the tag GENERATE_HTML is set to YES.
-
-USE_MATHJAX = NO
-
-# When MathJax is enabled you can set the default output format to be used for
-# the MathJax output. See the MathJax site (see:
-# http://docs.mathjax.org/en/latest/output.html) for more details.
-# Possible values are: HTML-CSS (which is slower, but has the best
-# compatibility), NativeMML (i.e. MathML) and SVG.
-# The default value is: HTML-CSS.
-# This tag requires that the tag USE_MATHJAX is set to YES.
-
-MATHJAX_FORMAT = HTML-CSS
-
-# When MathJax is enabled you need to specify the location relative to the HTML
-# output directory using the MATHJAX_RELPATH option. The destination directory
-# should contain the MathJax.js script. For instance, if the mathjax directory
-# is located at the same level as the HTML output directory, then
-# MATHJAX_RELPATH should be ../mathjax. The default value points to the MathJax
-# Content Delivery Network so you can quickly see the result without installing
-# MathJax. However, it is strongly recommended to install a local copy of
-# MathJax from http://www.mathjax.org before deployment.
-# The default value is: http://cdn.mathjax.org/mathjax/latest.
-# This tag requires that the tag USE_MATHJAX is set to YES.
-
-MATHJAX_RELPATH = http://www.mathjax.org/mathjax
-
-# The MATHJAX_EXTENSIONS tag can be used to specify one or more MathJax
-# extension names that should be enabled during MathJax rendering. For example
-# MATHJAX_EXTENSIONS = TeX/AMSmath TeX/AMSsymbols
-# This tag requires that the tag USE_MATHJAX is set to YES.
-
-MATHJAX_EXTENSIONS =
-
-# The MATHJAX_CODEFILE tag can be used to specify a file with javascript pieces
-# of code that will be used on startup of the MathJax code. See the MathJax site
-# (see: http://docs.mathjax.org/en/latest/output.html) for more details. For an
-# example see the documentation.
-# This tag requires that the tag USE_MATHJAX is set to YES.
-
-MATHJAX_CODEFILE =
-
-# When the SEARCHENGINE tag is enabled doxygen will generate a search box for
-# the HTML output. The underlying search engine uses javascript and DHTML and
-# should work on any modern browser. Note that when using HTML help
-# (GENERATE_HTMLHELP), Qt help (GENERATE_QHP), or docsets (GENERATE_DOCSET)
-# there is already a search function so this one should typically be disabled.
-# For large projects the javascript based search engine can be slow, then
-# enabling SERVER_BASED_SEARCH may provide a better solution. It is possible to
-# search using the keyboard; to jump to the search box use + S
-# (what the is depends on the OS and browser, but it is typically
-# , /, or both). Inside the search box use the to jump into the search results window, the results can be navigated
-# using the . Press to select an item or to cancel
-# the search. The filter options can be selected when the cursor is inside the
-# search box by pressing +. Also here use the
-# to select a filter and or to activate or cancel the filter
-# option.
-# The default value is: YES.
-# This tag requires that the tag GENERATE_HTML is set to YES.
-
-SEARCHENGINE = YES
-
-# When the SERVER_BASED_SEARCH tag is enabled the search engine will be
-# implemented using a web server instead of a web client using Javascript. There
-# are two flavours of web server based searching depending on the
-# EXTERNAL_SEARCH setting. When disabled, doxygen will generate a PHP script for
-# searching and an index file used by the script. When EXTERNAL_SEARCH is
-# enabled the indexing and searching needs to be provided by external tools. See
-# the section "External Indexing and Searching" for details.
-# The default value is: NO.
-# This tag requires that the tag SEARCHENGINE is set to YES.
-
-SERVER_BASED_SEARCH = NO
-
-# When EXTERNAL_SEARCH tag is enabled doxygen will no longer generate the PHP
-# script for searching. Instead the search results are written to an XML file
-# which needs to be processed by an external indexer. Doxygen will invoke an
-# external search engine pointed to by the SEARCHENGINE_URL option to obtain the
-# search results.
-#
-# Doxygen ships with an example indexer ( doxyindexer) and search engine
-# (doxysearch.cgi) which are based on the open source search engine library
-# Xapian (see: http://xapian.org/).
-#
-# See the section "External Indexing and Searching" for details.
-# The default value is: NO.
-# This tag requires that the tag SEARCHENGINE is set to YES.
-
-EXTERNAL_SEARCH = NO
-
-# The SEARCHENGINE_URL should point to a search engine hosted by a web server
-# which will return the search results when EXTERNAL_SEARCH is enabled.
-#
-# Doxygen ships with an example indexer ( doxyindexer) and search engine
-# (doxysearch.cgi) which are based on the open source search engine library
-# Xapian (see: http://xapian.org/). See the section "External Indexing and
-# Searching" for details.
-# This tag requires that the tag SEARCHENGINE is set to YES.
-
-SEARCHENGINE_URL =
-
-# When SERVER_BASED_SEARCH and EXTERNAL_SEARCH are both enabled the unindexed
-# search data is written to a file for indexing by an external tool. With the
-# SEARCHDATA_FILE tag the name of this file can be specified.
-# The default file is: searchdata.xml.
-# This tag requires that the tag SEARCHENGINE is set to YES.
-
-SEARCHDATA_FILE = searchdata.xml
-
-# When SERVER_BASED_SEARCH and EXTERNAL_SEARCH are both enabled the
-# EXTERNAL_SEARCH_ID tag can be used as an identifier for the project. This is
-# useful in combination with EXTRA_SEARCH_MAPPINGS to search through multiple
-# projects and redirect the results back to the right project.
-# This tag requires that the tag SEARCHENGINE is set to YES.
-
-EXTERNAL_SEARCH_ID =
-
-# The EXTRA_SEARCH_MAPPINGS tag can be used to enable searching through doxygen
-# projects other than the one defined by this configuration file, but that are
-# all added to the same external search index. Each project needs to have a
-# unique id set via EXTERNAL_SEARCH_ID. The search mapping then maps the id of
-# to a relative location where the documentation can be found. The format is:
-# EXTRA_SEARCH_MAPPINGS = tagname1=loc1 tagname2=loc2 ...
-# This tag requires that the tag SEARCHENGINE is set to YES.
-
-EXTRA_SEARCH_MAPPINGS =
-
-#---------------------------------------------------------------------------
-# Configuration options related to the LaTeX output
-#---------------------------------------------------------------------------
-
-# If the GENERATE_LATEX tag is set to YES doxygen will generate LaTeX output.
-# The default value is: YES.
-
-GENERATE_LATEX = NO
-
-# The LATEX_OUTPUT tag is used to specify where the LaTeX docs will be put. If a
-# relative path is entered the value of OUTPUT_DIRECTORY will be put in front of
-# it.
-# The default directory is: latex.
-# This tag requires that the tag GENERATE_LATEX is set to YES.
-
-LATEX_OUTPUT = latex
-
-# The LATEX_CMD_NAME tag can be used to specify the LaTeX command name to be
-# invoked.
-#
-# Note that when enabling USE_PDFLATEX this option is only used for generating
-# bitmaps for formulas in the HTML output, but not in the Makefile that is
-# written to the output directory.
-# The default file is: latex.
-# This tag requires that the tag GENERATE_LATEX is set to YES.
-
-LATEX_CMD_NAME = latex
-
-# The MAKEINDEX_CMD_NAME tag can be used to specify the command name to generate
-# index for LaTeX.
-# The default file is: makeindex.
-# This tag requires that the tag GENERATE_LATEX is set to YES.
-
-MAKEINDEX_CMD_NAME = makeindex
-
-# If the COMPACT_LATEX tag is set to YES doxygen generates more compact LaTeX
-# documents. This may be useful for small projects and may help to save some
-# trees in general.
-# The default value is: NO.
-# This tag requires that the tag GENERATE_LATEX is set to YES.
-
-COMPACT_LATEX = NO
-
-# The PAPER_TYPE tag can be used to set the paper type that is used by the
-# printer.
-# Possible values are: a4 (210 x 297 mm), letter (8.5 x 11 inches), legal (8.5 x
-# 14 inches) and executive (7.25 x 10.5 inches).
-# The default value is: a4.
-# This tag requires that the tag GENERATE_LATEX is set to YES.
-
-PAPER_TYPE = a4
-
-# The EXTRA_PACKAGES tag can be used to specify one or more LaTeX package names
-# that should be included in the LaTeX output. To get the times font for
-# instance you can specify
-# EXTRA_PACKAGES=times
-# If left blank no extra packages will be included.
-# This tag requires that the tag GENERATE_LATEX is set to YES.
-
-EXTRA_PACKAGES =
-
-# The LATEX_HEADER tag can be used to specify a personal LaTeX header for the
-# generated LaTeX document. The header should contain everything until the first
-# chapter. If it is left blank doxygen will generate a standard header. See
-# section "Doxygen usage" for information on how to let doxygen write the
-# default header to a separate file.
-#
-# Note: Only use a user-defined header if you know what you are doing! The
-# following commands have a special meaning inside the header: $title,
-# $datetime, $date, $doxygenversion, $projectname, $projectnumber. Doxygen will
-# replace them by respectively the title of the page, the current date and time,
-# only the current date, the version number of doxygen, the project name (see
-# PROJECT_NAME), or the project number (see PROJECT_NUMBER).
-# This tag requires that the tag GENERATE_LATEX is set to YES.
-
-LATEX_HEADER =
-
-# The LATEX_FOOTER tag can be used to specify a personal LaTeX footer for the
-# generated LaTeX document. The footer should contain everything after the last
-# chapter. If it is left blank doxygen will generate a standard footer.
-#
-# Note: Only use a user-defined footer if you know what you are doing!
-# This tag requires that the tag GENERATE_LATEX is set to YES.
-
-LATEX_FOOTER =
-
-# The LATEX_EXTRA_FILES tag can be used to specify one or more extra images or
-# other source files which should be copied to the LATEX_OUTPUT output
-# directory. Note that the files will be copied as-is; there are no commands or
-# markers available.
-# This tag requires that the tag GENERATE_LATEX is set to YES.
-
-LATEX_EXTRA_FILES =
-
-# If the PDF_HYPERLINKS tag is set to YES, the LaTeX that is generated is
-# prepared for conversion to PDF (using ps2pdf or pdflatex). The PDF file will
-# contain links (just like the HTML output) instead of page references. This
-# makes the output suitable for online browsing using a PDF viewer.
-# The default value is: YES.
-# This tag requires that the tag GENERATE_LATEX is set to YES.
-
-PDF_HYPERLINKS = YES
-
-# If the LATEX_PDFLATEX tag is set to YES, doxygen will use pdflatex to generate
-# the PDF file directly from the LaTeX files. Set this option to YES to get a
-# higher quality PDF documentation.
-# The default value is: YES.
-# This tag requires that the tag GENERATE_LATEX is set to YES.
-
-USE_PDFLATEX = YES
-
-# If the LATEX_BATCHMODE tag is set to YES, doxygen will add the \batchmode
-# command to the generated LaTeX files. This will instruct LaTeX to keep running
-# if errors occur, instead of asking the user for help. This option is also used
-# when generating formulas in HTML.
-# The default value is: NO.
-# This tag requires that the tag GENERATE_LATEX is set to YES.
-
-LATEX_BATCHMODE = NO
-
-# If the LATEX_HIDE_INDICES tag is set to YES then doxygen will not include the
-# index chapters (such as File Index, Compound Index, etc.) in the output.
-# The default value is: NO.
-# This tag requires that the tag GENERATE_LATEX is set to YES.
-
-LATEX_HIDE_INDICES = NO
-
-# If the LATEX_SOURCE_CODE tag is set to YES then doxygen will include source
-# code with syntax highlighting in the LaTeX output.
-#
-# Note that which sources are shown also depends on other settings such as
-# SOURCE_BROWSER.
-# The default value is: NO.
-# This tag requires that the tag GENERATE_LATEX is set to YES.
-
-LATEX_SOURCE_CODE = NO
-
-# The LATEX_BIB_STYLE tag can be used to specify the style to use for the
-# bibliography, e.g. plainnat, or ieeetr. See
-# http://en.wikipedia.org/wiki/BibTeX and \cite for more info.
-# The default value is: plain.
-# This tag requires that the tag GENERATE_LATEX is set to YES.
-
-LATEX_BIB_STYLE = plain
-
-#---------------------------------------------------------------------------
-# Configuration options related to the RTF output
-#---------------------------------------------------------------------------
-
-# If the GENERATE_RTF tag is set to YES doxygen will generate RTF output. The
-# RTF output is optimized for Word 97 and may not look too pretty with other RTF
-# readers/editors.
-# The default value is: NO.
-
-GENERATE_RTF = NO
-
-# The RTF_OUTPUT tag is used to specify where the RTF docs will be put. If a
-# relative path is entered the value of OUTPUT_DIRECTORY will be put in front of
-# it.
-# The default directory is: rtf.
-# This tag requires that the tag GENERATE_RTF is set to YES.
-
-RTF_OUTPUT = rtf
-
-# If the COMPACT_RTF tag is set to YES doxygen generates more compact RTF
-# documents. This may be useful for small projects and may help to save some
-# trees in general.
-# The default value is: NO.
-# This tag requires that the tag GENERATE_RTF is set to YES.
-
-COMPACT_RTF = NO
-
-# If the RTF_HYPERLINKS tag is set to YES, the RTF that is generated will
-# contain hyperlink fields. The RTF file will contain links (just like the HTML
-# output) instead of page references. This makes the output suitable for online
-# browsing using Word or some other Word compatible readers that support those
-# fields.
-#
-# Note: WordPad (write) and others do not support links.
-# The default value is: NO.
-# This tag requires that the tag GENERATE_RTF is set to YES.
-
-RTF_HYPERLINKS = NO
-
-# Load stylesheet definitions from file. Syntax is similar to doxygen's config
-# file, i.e. a series of assignments. You only have to provide replacements,
-# missing definitions are set to their default value.
-#
-# See also section "Doxygen usage" for information on how to generate the
-# default style sheet that doxygen normally uses.
-# This tag requires that the tag GENERATE_RTF is set to YES.
-
-RTF_STYLESHEET_FILE =
-
-# Set optional variables used in the generation of an RTF document. Syntax is
-# similar to doxygen's config file. A template extensions file can be generated
-# using doxygen -e rtf extensionFile.
-# This tag requires that the tag GENERATE_RTF is set to YES.
-
-RTF_EXTENSIONS_FILE =
-
-#---------------------------------------------------------------------------
-# Configuration options related to the man page output
-#---------------------------------------------------------------------------
-
-# If the GENERATE_MAN tag is set to YES doxygen will generate man pages for
-# classes and files.
-# The default value is: NO.
-
-GENERATE_MAN = NO
-
-# The MAN_OUTPUT tag is used to specify where the man pages will be put. If a
-# relative path is entered the value of OUTPUT_DIRECTORY will be put in front of
-# it. A directory man3 will be created inside the directory specified by
-# MAN_OUTPUT.
-# The default directory is: man.
-# This tag requires that the tag GENERATE_MAN is set to YES.
-
-MAN_OUTPUT = man
-
-# The MAN_EXTENSION tag determines the extension that is added to the generated
-# man pages. In case the manual section does not start with a number, the number
-# 3 is prepended. The dot (.) at the beginning of the MAN_EXTENSION tag is
-# optional.
-# The default value is: .3.
-# This tag requires that the tag GENERATE_MAN is set to YES.
-
-MAN_EXTENSION = .3
-
-# If the MAN_LINKS tag is set to YES and doxygen generates man output, then it
-# will generate one additional man file for each entity documented in the real
-# man page(s). These additional files only source the real man page, but without
-# them the man command would be unable to find the correct page.
-# The default value is: NO.
-# This tag requires that the tag GENERATE_MAN is set to YES.
-
-MAN_LINKS = NO
-
-#---------------------------------------------------------------------------
-# Configuration options related to the XML output
-#---------------------------------------------------------------------------
-
-# If the GENERATE_XML tag is set to YES doxygen will generate an XML file that
-# captures the structure of the code including all documentation.
-# The default value is: NO.
-
-GENERATE_XML = NO
-
-# The XML_OUTPUT tag is used to specify where the XML pages will be put. If a
-# relative path is entered the value of OUTPUT_DIRECTORY will be put in front of
-# it.
-# The default directory is: xml.
-# This tag requires that the tag GENERATE_XML is set to YES.
-
-XML_OUTPUT = xml
-
-# The XML_SCHEMA tag can be used to specify a XML schema, which can be used by a
-# validating XML parser to check the syntax of the XML files.
-# This tag requires that the tag GENERATE_XML is set to YES.
-
-XML_SCHEMA =
-
-# The XML_DTD tag can be used to specify a XML DTD, which can be used by a
-# validating XML parser to check the syntax of the XML files.
-# This tag requires that the tag GENERATE_XML is set to YES.
-
-XML_DTD =
-
-# If the XML_PROGRAMLISTING tag is set to YES doxygen will dump the program
-# listings (including syntax highlighting and cross-referencing information) to
-# the XML output. Note that enabling this will significantly increase the size
-# of the XML output.
-# The default value is: YES.
-# This tag requires that the tag GENERATE_XML is set to YES.
-
-XML_PROGRAMLISTING = YES
-
-#---------------------------------------------------------------------------
-# Configuration options related to the DOCBOOK output
-#---------------------------------------------------------------------------
-
-# If the GENERATE_DOCBOOK tag is set to YES doxygen will generate Docbook files
-# that can be used to generate PDF.
-# The default value is: NO.
-
-GENERATE_DOCBOOK = NO
-
-# The DOCBOOK_OUTPUT tag is used to specify where the Docbook pages will be put.
-# If a relative path is entered the value of OUTPUT_DIRECTORY will be put in
-# front of it.
-# The default directory is: docbook.
-# This tag requires that the tag GENERATE_DOCBOOK is set to YES.
-
-DOCBOOK_OUTPUT = docbook
-
-#---------------------------------------------------------------------------
-# Configuration options for the AutoGen Definitions output
-#---------------------------------------------------------------------------
-
-# If the GENERATE_AUTOGEN_DEF tag is set to YES doxygen will generate an AutoGen
-# Definitions (see http://autogen.sf.net) file that captures the structure of
-# the code including all documentation. Note that this feature is still
-# experimental and incomplete at the moment.
-# The default value is: NO.
-
-GENERATE_AUTOGEN_DEF = NO
-
-#---------------------------------------------------------------------------
-# Configuration options related to the Perl module output
-#---------------------------------------------------------------------------
-
-# If the GENERATE_PERLMOD tag is set to YES doxygen will generate a Perl module
-# file that captures the structure of the code including all documentation.
-#
-# Note that this feature is still experimental and incomplete at the moment.
-# The default value is: NO.
-
-GENERATE_PERLMOD = NO
-
-# If the PERLMOD_LATEX tag is set to YES doxygen will generate the necessary
-# Makefile rules, Perl scripts and LaTeX code to be able to generate PDF and DVI
-# output from the Perl module output.
-# The default value is: NO.
-# This tag requires that the tag GENERATE_PERLMOD is set to YES.
-
-PERLMOD_LATEX = NO
-
-# If the PERLMOD_PRETTY tag is set to YES the Perl module output will be nicely
-# formatted so it can be parsed by a human reader. This is useful if you want to
-# understand what is going on. On the other hand, if this tag is set to NO the
-# size of the Perl module output will be much smaller and Perl will parse it
-# just the same.
-# The default value is: YES.
-# This tag requires that the tag GENERATE_PERLMOD is set to YES.
-
-PERLMOD_PRETTY = YES
-
-# The names of the make variables in the generated doxyrules.make file are
-# prefixed with the string contained in PERLMOD_MAKEVAR_PREFIX. This is useful
-# so different doxyrules.make files included by the same Makefile don't
-# overwrite each other's variables.
-# This tag requires that the tag GENERATE_PERLMOD is set to YES.
-
-PERLMOD_MAKEVAR_PREFIX =
-
-#---------------------------------------------------------------------------
-# Configuration options related to the preprocessor
-#---------------------------------------------------------------------------
-
-# If the ENABLE_PREPROCESSING tag is set to YES doxygen will evaluate all
-# C-preprocessor directives found in the sources and include files.
-# The default value is: YES.
-
-ENABLE_PREPROCESSING = YES
-
-# If the MACRO_EXPANSION tag is set to YES doxygen will expand all macro names
-# in the source code. If set to NO only conditional compilation will be
-# performed. Macro expansion can be done in a controlled way by setting
-# EXPAND_ONLY_PREDEF to YES.
-# The default value is: NO.
-# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
-
-MACRO_EXPANSION = NO
-
-# If the EXPAND_ONLY_PREDEF and MACRO_EXPANSION tags are both set to YES then
-# the macro expansion is limited to the macros specified with the PREDEFINED and
-# EXPAND_AS_DEFINED tags.
-# The default value is: NO.
-# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
-
-EXPAND_ONLY_PREDEF = NO
-
-# If the SEARCH_INCLUDES tag is set to YES the includes files in the
-# INCLUDE_PATH will be searched if a #include is found.
-# The default value is: YES.
-# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
-
-SEARCH_INCLUDES = YES
-
-# The INCLUDE_PATH tag can be used to specify one or more directories that
-# contain include files that are not input files but should be processed by the
-# preprocessor.
-# This tag requires that the tag SEARCH_INCLUDES is set to YES.
-
-INCLUDE_PATH =
-
-# You can use the INCLUDE_FILE_PATTERNS tag to specify one or more wildcard
-# patterns (like *.h and *.hpp) to filter out the header-files in the
-# directories. If left blank, the patterns specified with FILE_PATTERNS will be
-# used.
-# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
-
-INCLUDE_FILE_PATTERNS =
-
-# The PREDEFINED tag can be used to specify one or more macro names that are
-# defined before the preprocessor is started (similar to the -D option of e.g.
-# gcc). The argument of the tag is a list of macros of the form: name or
-# name=definition (no spaces). If the definition and the "=" are omitted, "=1"
-# is assumed. To prevent a macro definition from being undefined via #undef or
-# recursively expanded use the := operator instead of the = operator.
-# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
-
-PREDEFINED = __DOXYGEN__
-
-# If the MACRO_EXPANSION and EXPAND_ONLY_PREDEF tags are set to YES then this
-# tag can be used to specify a list of macro names that should be expanded. The
-# macro definition that is found in the sources will be used. Use the PREDEFINED
-# tag if you want to use a different macro definition that overrules the
-# definition found in the source code.
-# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
-
-EXPAND_AS_DEFINED =
-
-# If the SKIP_FUNCTION_MACROS tag is set to YES then doxygen's preprocessor will
-# remove all refrences to function-like macros that are alone on a line, have an
-# all uppercase name, and do not end with a semicolon. Such function macros are
-# typically used for boiler-plate code, and will confuse the parser if not
-# removed.
-# The default value is: YES.
-# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
-
-SKIP_FUNCTION_MACROS = NO
-
-#---------------------------------------------------------------------------
-# Configuration options related to external references
-#---------------------------------------------------------------------------
-
-# The TAGFILES tag can be used to specify one or more tag files. For each tag
-# file the location of the external documentation should be added. The format of
-# a tag file without this location is as follows:
-# TAGFILES = file1 file2 ...
-# Adding location for the tag files is done as follows:
-# TAGFILES = file1=loc1 "file2 = loc2" ...
-# where loc1 and loc2 can be relative or absolute paths or URLs. See the
-# section "Linking to external documentation" for more information about the use
-# of tag files.
-# Note: Each tag file must have an unique name (where the name does NOT include
-# the path). If a tag file is not located in the directory in which doxygen is
-# run, you must also specify the path to the tagfile here.
-
-TAGFILES =
-
-# When a file name is specified after GENERATE_TAGFILE, doxygen will create a
-# tag file that is based on the input files it reads. See section "Linking to
-# external documentation" for more information about the usage of tag files.
-
-GENERATE_TAGFILE =
-
-# If the ALLEXTERNALS tag is set to YES all external class will be listed in the
-# class index. If set to NO only the inherited external classes will be listed.
-# The default value is: NO.
-
-ALLEXTERNALS = NO
-
-# If the EXTERNAL_GROUPS tag is set to YES all external groups will be listed in
-# the modules index. If set to NO, only the current project's groups will be
-# listed.
-# The default value is: YES.
-
-EXTERNAL_GROUPS = YES
-
-# If the EXTERNAL_PAGES tag is set to YES all external pages will be listed in
-# the related pages index. If set to NO, only the current project's pages will
-# be listed.
-# The default value is: YES.
-
-EXTERNAL_PAGES = YES
-
-# The PERL_PATH should be the absolute path and name of the perl script
-# interpreter (i.e. the result of 'which perl').
-# The default file (with absolute path) is: /usr/bin/perl.
-
-PERL_PATH = /usr/bin/perl
-
-#---------------------------------------------------------------------------
-# Configuration options related to the dot tool
-#---------------------------------------------------------------------------
-
-# If the CLASS_DIAGRAMS tag is set to YES doxygen will generate a class diagram
-# (in HTML and LaTeX) for classes with base or super classes. Setting the tag to
-# NO turns the diagrams off. Note that this option also works with HAVE_DOT
-# disabled, but it is recommended to install and use dot, since it yields more
-# powerful graphs.
-# The default value is: YES.
-
-CLASS_DIAGRAMS = NO
-
-# You can define message sequence charts within doxygen comments using the \msc
-# command. Doxygen will then run the mscgen tool (see:
-# http://www.mcternan.me.uk/mscgen/)) to produce the chart and insert it in the
-# documentation. The MSCGEN_PATH tag allows you to specify the directory where
-# the mscgen tool resides. If left empty the tool is assumed to be found in the
-# default search path.
-
-MSCGEN_PATH =
-
-# You can include diagrams made with dia in doxygen documentation. Doxygen will
-# then run dia to produce the diagram and insert it in the documentation. The
-# DIA_PATH tag allows you to specify the directory where the dia binary resides.
-# If left empty dia is assumed to be found in the default search path.
-
-DIA_PATH =
-
-# If set to YES, the inheritance and collaboration graphs will hide inheritance
-# and usage relations if the target is undocumented or is not a class.
-# The default value is: YES.
-
-HIDE_UNDOC_RELATIONS = YES
-
-# If you set the HAVE_DOT tag to YES then doxygen will assume the dot tool is
-# available from the path. This tool is part of Graphviz (see:
-# http://www.graphviz.org/), a graph visualization toolkit from AT&T and Lucent
-# Bell Labs. The other options in this section have no effect if this option is
-# set to NO
-# The default value is: NO.
-
-HAVE_DOT = NO
-
-# The DOT_NUM_THREADS specifies the number of dot invocations doxygen is allowed
-# to run in parallel. When set to 0 doxygen will base this on the number of
-# processors available in the system. You can set it explicitly to a value
-# larger than 0 to get control over the balance between CPU load and processing
-# speed.
-# Minimum value: 0, maximum value: 32, default value: 0.
-# This tag requires that the tag HAVE_DOT is set to YES.
-
-DOT_NUM_THREADS = 0
-
-# When you want a differently looking font n the dot files that doxygen
-# generates you can specify the font name using DOT_FONTNAME. You need to make
-# sure dot is able to find the font, which can be done by putting it in a
-# standard location or by setting the DOTFONTPATH environment variable or by
-# setting DOT_FONTPATH to the directory containing the font.
-# The default value is: Helvetica.
-# This tag requires that the tag HAVE_DOT is set to YES.
-
-DOT_FONTNAME = Helvetica
-
-# The DOT_FONTSIZE tag can be used to set the size (in points) of the font of
-# dot graphs.
-# Minimum value: 4, maximum value: 24, default value: 10.
-# This tag requires that the tag HAVE_DOT is set to YES.
-
-DOT_FONTSIZE = 10
-
-# By default doxygen will tell dot to use the default font as specified with
-# DOT_FONTNAME. If you specify a different font using DOT_FONTNAME you can set
-# the path where dot can find it using this tag.
-# This tag requires that the tag HAVE_DOT is set to YES.
-
-DOT_FONTPATH =
-
-# If the CLASS_GRAPH tag is set to YES then doxygen will generate a graph for
-# each documented class showing the direct and indirect inheritance relations.
-# Setting this tag to YES will force the CLASS_DIAGRAMS tag to NO.
-# The default value is: YES.
-# This tag requires that the tag HAVE_DOT is set to YES.
-
-CLASS_GRAPH = YES
-
-# If the COLLABORATION_GRAPH tag is set to YES then doxygen will generate a
-# graph for each documented class showing the direct and indirect implementation
-# dependencies (inheritance, containment, and class references variables) of the
-# class with other documented classes.
-# The default value is: YES.
-# This tag requires that the tag HAVE_DOT is set to YES.
-
-COLLABORATION_GRAPH = YES
-
-# If the GROUP_GRAPHS tag is set to YES then doxygen will generate a graph for
-# groups, showing the direct groups dependencies.
-# The default value is: YES.
-# This tag requires that the tag HAVE_DOT is set to YES.
-
-GROUP_GRAPHS = YES
-
-# If the UML_LOOK tag is set to YES doxygen will generate inheritance and
-# collaboration diagrams in a style similar to the OMG's Unified Modeling
-# Language.
-# The default value is: NO.
-# This tag requires that the tag HAVE_DOT is set to YES.
-
-UML_LOOK = NO
-
-# If the UML_LOOK tag is enabled, the fields and methods are shown inside the
-# class node. If there are many fields or methods and many nodes the graph may
-# become too big to be useful. The UML_LIMIT_NUM_FIELDS threshold limits the
-# number of items for each type to make the size more manageable. Set this to 0
-# for no limit. Note that the threshold may be exceeded by 50% before the limit
-# is enforced. So when you set the threshold to 10, up to 15 fields may appear,
-# but if the number exceeds 15, the total amount of fields shown is limited to
-# 10.
-# Minimum value: 0, maximum value: 100, default value: 10.
-# This tag requires that the tag HAVE_DOT is set to YES.
-
-UML_LIMIT_NUM_FIELDS = 10
-
-# If the TEMPLATE_RELATIONS tag is set to YES then the inheritance and
-# collaboration graphs will show the relations between templates and their
-# instances.
-# The default value is: NO.
-# This tag requires that the tag HAVE_DOT is set to YES.
-
-TEMPLATE_RELATIONS = NO
-
-# If the INCLUDE_GRAPH, ENABLE_PREPROCESSING and SEARCH_INCLUDES tags are set to
-# YES then doxygen will generate a graph for each documented file showing the
-# direct and indirect include dependencies of the file with other documented
-# files.
-# The default value is: YES.
-# This tag requires that the tag HAVE_DOT is set to YES.
-
-INCLUDE_GRAPH = YES
-
-# If the INCLUDED_BY_GRAPH, ENABLE_PREPROCESSING and SEARCH_INCLUDES tags are
-# set to YES then doxygen will generate a graph for each documented file showing
-# the direct and indirect include dependencies of the file with other documented
-# files.
-# The default value is: YES.
-# This tag requires that the tag HAVE_DOT is set to YES.
-
-INCLUDED_BY_GRAPH = YES
-
-# If the CALL_GRAPH tag is set to YES then doxygen will generate a call
-# dependency graph for every global function or class method.
-#
-# Note that enabling this option will significantly increase the time of a run.
-# So in most cases it will be better to enable call graphs for selected
-# functions only using the \callgraph command.
-# The default value is: NO.
-# This tag requires that the tag HAVE_DOT is set to YES.
-
-CALL_GRAPH = NO
-
-# If the CALLER_GRAPH tag is set to YES then doxygen will generate a caller
-# dependency graph for every global function or class method.
-#
-# Note that enabling this option will significantly increase the time of a run.
-# So in most cases it will be better to enable caller graphs for selected
-# functions only using the \callergraph command.
-# The default value is: NO.
-# This tag requires that the tag HAVE_DOT is set to YES.
-
-CALLER_GRAPH = NO
-
-# If the GRAPHICAL_HIERARCHY tag is set to YES then doxygen will graphical
-# hierarchy of all classes instead of a textual one.
-# The default value is: YES.
-# This tag requires that the tag HAVE_DOT is set to YES.
-
-GRAPHICAL_HIERARCHY = YES
-
-# If the DIRECTORY_GRAPH tag is set to YES then doxygen will show the
-# dependencies a directory has on other directories in a graphical way. The
-# dependency relations are determined by the #include relations between the
-# files in the directories.
-# The default value is: YES.
-# This tag requires that the tag HAVE_DOT is set to YES.
-
-DIRECTORY_GRAPH = YES
-
-# The DOT_IMAGE_FORMAT tag can be used to set the image format of the images
-# generated by dot.
-# Note: If you choose svg you need to set HTML_FILE_EXTENSION to xhtml in order
-# to make the SVG files visible in IE 9+ (other browsers do not have this
-# requirement).
-# Possible values are: png, jpg, gif and svg.
-# The default value is: png.
-# This tag requires that the tag HAVE_DOT is set to YES.
-
-DOT_IMAGE_FORMAT = png
-
-# If DOT_IMAGE_FORMAT is set to svg, then this option can be set to YES to
-# enable generation of interactive SVG images that allow zooming and panning.
-#
-# Note that this requires a modern browser other than Internet Explorer. Tested
-# and working are Firefox, Chrome, Safari, and Opera.
-# Note: For IE 9+ you need to set HTML_FILE_EXTENSION to xhtml in order to make
-# the SVG files visible. Older versions of IE do not have SVG support.
-# The default value is: NO.
-# This tag requires that the tag HAVE_DOT is set to YES.
-
-INTERACTIVE_SVG = NO
-
-# The DOT_PATH tag can be used to specify the path where the dot tool can be
-# found. If left blank, it is assumed the dot tool can be found in the path.
-# This tag requires that the tag HAVE_DOT is set to YES.
-
-DOT_PATH =
-
-# The DOTFILE_DIRS tag can be used to specify one or more directories that
-# contain dot files that are included in the documentation (see the \dotfile
-# command).
-# This tag requires that the tag HAVE_DOT is set to YES.
-
-DOTFILE_DIRS =
-
-# The MSCFILE_DIRS tag can be used to specify one or more directories that
-# contain msc files that are included in the documentation (see the \mscfile
-# command).
-
-MSCFILE_DIRS =
-
-# The DIAFILE_DIRS tag can be used to specify one or more directories that
-# contain dia files that are included in the documentation (see the \diafile
-# command).
-
-DIAFILE_DIRS =
-
-# The DOT_GRAPH_MAX_NODES tag can be used to set the maximum number of nodes
-# that will be shown in the graph. If the number of nodes in a graph becomes
-# larger than this value, doxygen will truncate the graph, which is visualized
-# by representing a node as a red box. Note that doxygen if the number of direct
-# children of the root node in a graph is already larger than
-# DOT_GRAPH_MAX_NODES then the graph will not be shown at all. Also note that
-# the size of a graph can be further restricted by MAX_DOT_GRAPH_DEPTH.
-# Minimum value: 0, maximum value: 10000, default value: 50.
-# This tag requires that the tag HAVE_DOT is set to YES.
-
-DOT_GRAPH_MAX_NODES = 50
-
-# The MAX_DOT_GRAPH_DEPTH tag can be used to set the maximum depth of the graphs
-# generated by dot. A depth value of 3 means that only nodes reachable from the
-# root by following a path via at most 3 edges will be shown. Nodes that lay
-# further from the root node will be omitted. Note that setting this option to 1
-# or 2 may greatly reduce the computation time needed for large code bases. Also
-# note that the size of a graph can be further restricted by
-# DOT_GRAPH_MAX_NODES. Using a depth of 0 means no depth restriction.
-# Minimum value: 0, maximum value: 1000, default value: 0.
-# This tag requires that the tag HAVE_DOT is set to YES.
-
-MAX_DOT_GRAPH_DEPTH = 0
-
-# Set the DOT_TRANSPARENT tag to YES to generate images with a transparent
-# background. This is disabled by default, because dot on Windows does not seem
-# to support this out of the box.
-#
-# Warning: Depending on the platform used, enabling this option may lead to
-# badly anti-aliased labels on the edges of a graph (i.e. they become hard to
-# read).
-# The default value is: NO.
-# This tag requires that the tag HAVE_DOT is set to YES.
-
-DOT_TRANSPARENT = NO
-
-# Set the DOT_MULTI_TARGETS tag to YES allow dot to generate multiple output
-# files in one run (i.e. multiple -o and -T options on the command line). This
-# makes dot run faster, but since only newer versions of dot (>1.8.10) support
-# this, this feature is disabled by default.
-# The default value is: NO.
-# This tag requires that the tag HAVE_DOT is set to YES.
-
-DOT_MULTI_TARGETS = NO
-
-# If the GENERATE_LEGEND tag is set to YES doxygen will generate a legend page
-# explaining the meaning of the various boxes and arrows in the dot generated
-# graphs.
-# The default value is: YES.
-# This tag requires that the tag HAVE_DOT is set to YES.
-
-GENERATE_LEGEND = YES
-
-# If the DOT_CLEANUP tag is set to YES doxygen will remove the intermediate dot
-# files that are used to generate the various graphs.
-# The default value is: YES.
-# This tag requires that the tag HAVE_DOT is set to YES.
-
-DOT_CLEANUP = YES
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/Driver_CAN.c b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/Driver_CAN.c
deleted file mode 100644
index a132af0..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/Driver_CAN.c
+++ /dev/null
@@ -1,1151 +0,0 @@
-/**
-\defgroup can_interface_gr CAN Interface
-\brief Driver API for CAN Bus Peripheral (%Driver_CAN.h)
-\details
-
-The Controller Area Network Interface Bus (CAN) implements a multi-master serial bus for connecting
-microcontrollers and devices, also known as nodes, to communicate with each other in applications without a host computer.
-CAN is a message-based protocol, designed originally for automotive applications, but meanwhile used also in many other surroundings.
-The complexity of the node can range from a simple I/O device up to an embedded computer with a CAN interface and sophisticated software.
-The node may also be a gateway allowing a standard computer to communicate over a USB or Ethernet port to the devices on a CAN network.
-Devices are connected to the bus through a host processor, a CAN controller, and a CAN transceiver.
-
-
-The CAN Driver API allows to implement CAN Interfaces that conform to the
-
-CAN specifications available from BOSCH :
- - CAN 2.0B: CAN Specification 2.0B (released Sep. 1991) which is now superseded by ISO 11898-1.
- - CAN FD: CAN with Flexible Data Rate introduced in 2012 (released April 17th, 2012).
-
-Wikipedia offers more information about the CAN Bus CAN FD
-
-Support for CAN FD depends on the hardware.
-A CMSIS-Driver that supports CAN FD has the capability \ref ARM_CAN_CAPABILITIES data field \b fd_mode = \token{1}, which can be
-retrieved with the function \ref ARM_CAN_GetCapabilities.
-
-CAN FD supports:
- - message can contain up to 64 data bytes
- - faster data transfers with faster bitrate used during the data phase
-
-CAN FD does not support \ref Remote_Frame requests.
-
-Block Diagram
-
-The CAN Driver API defines a CAN interface for middleware components. The CAN Driver supports multiple
-nodes, which are able to send and receive messages, but not simultaneously.
-
-\image html CAN_Node.png "CAN Node Schematic"
-
-CAN API
--------
-
-The following header files define the Application Programming Interface (API) for the CAN interface:
- - \b %Driver_CAN.h : Driver API for CAN Bus Peripheral
-
-The driver implementation is a typical part of the Device Family Pack (DFP) that supports the
-peripherals of the microcontroller family.
-
-
-Driver Functions
-
-The driver functions are published in the access struct as explained in \ref DriverFunctions
- - \ref ARM_DRIVER_CAN : access struct for CAN driver functions
-
-Example Code
-
-The following example code shows the usage of the CAN interface.
-
-\code
-
-#include
-#include
-#include "cmsis_os.h"
-
-#include "Driver_CAN.h"
-
-// CAN Driver Controller selector
-#define CAN_CONTROLLER 1 // CAN Controller number
-
-#define _CAN_Driver_(n) Driver_CAN##n
-#define CAN_Driver_(n) _CAN_Driver_(n)
-extern ARM_DRIVER_CAN CAN_Driver_(CAN_CONTROLLER);
-#define ptrCAN (&CAN_Driver_(CAN_CONTROLLER))
-
-uint32_t rx_obj_idx = 0xFFFFFFFFU;
-uint8_t rx_data[8];
-ARM_CAN_MSG_INFO rx_msg_info;
-uint32_t tx_obj_idx = 0xFFFFFFFFU;
-uint8_t tx_data[8];
-ARM_CAN_MSG_INFO tx_msg_info;
-
-static void Error_Handler (void) { while (1); }
-
-void CAN_SignalUnitEvent (uint32_t event) {}
-
-void CAN_SignalObjectEvent (uint32_t obj_idx, uint32_t event) {
-
- if (obj_idx == rx_obj_idx) { // If receive object event
- if (event == ARM_CAN_EVENT_RECEIVE) { // If message was received successfully
- if (ptrCAN->MessageRead(rx_obj_idx, &rx_msg_info, rx_data, 8U) > 0U) {
- // Read received message
- // process received message ...
- }
- }
- }
- if (obj_idx == tx_obj_idx) { // If transmit object event
- if (event == ARM_CAN_EVENT_SEND_COMPLETE) { // If message was sent successfully
- // acknowledge sent message ...
- }
- }
-}
-
-int main (void) {
- ARM_CAN_CAPABILITIES can_cap;
- ARM_CAN_OBJ_CAPABILITIES can_obj_cap;
- int32_t status;
- uint32_t i, num_objects;
-
- can_cap = ptrCAN->GetCapabilities (); // Get CAN driver capabilities
- num_objects = can_cap.num_objects; // Number of receive/transmit objects
-
- status = ptrCAN->Initialize (CAN_SignalUnitEvent, CAN_SignalObjectEvent); // Initialize CAN driver
- if (status != ARM_DRIVER_OK ) { Error_Handler(); }
-
- status = ptrCAN->PowerControl (ARM_POWER_FULL); // Power-up CAN controller
- if (status != ARM_DRIVER_OK ) { Error_Handler(); }
-
- status = ptrCAN->SetMode (ARM_CAN_MODE_INITIALIZATION); // Activate initialization mode
- if (status != ARM_DRIVER_OK ) { Error_Handler(); }
-
- status = ptrCAN->SetBitrate (ARM_CAN_BITRATE_NOMINAL, // Set nominal bitrate
- 100000U, // Set bitrate to 100 kbit/s
- ARM_CAN_BIT_PROP_SEG(5U) | // Set propagation segment to 5 time quanta
- ARM_CAN_BIT_PHASE_SEG1(1U) | // Set phase segment 1 to 1 time quantum (sample point at 87.5% of bit time)
- ARM_CAN_BIT_PHASE_SEG2(1U) | // Set phase segment 2 to 1 time quantum (total bit is 8 time quanta long)
- ARM_CAN_BIT_SJW(1U)); // Resynchronization jump width is same as phase segment 2
- if (status != ARM_DRIVER_OK ) { Error_Handler(); }
-
- for (i = 0U; i < num_objects; i++) { // Find first available object for receive and transmit
- can_obj_cap = ptrCAN->ObjectGetCapabilities (i); // Get object capabilities
- if ((rx_obj_idx == 0xFFFFFFFFU) && (can_obj_cap.rx == 1U)) { rx_obj_idx = i; }
- else if ((tx_obj_idx == 0xFFFFFFFFU) && (can_obj_cap.tx == 1U)) { tx_obj_idx = i; break; }
- }
- if ((rx_obj_idx == 0xFFFFFFFFU) || (tx_obj_idx == 0xFFFFFFFFU)) { Error_Handler(); }
-
- // Set filter to receive messages with extended ID 0x12345678 to receive object
- status = ptrCAN->ObjectSetFilter(rx_obj_idx, ARM_CAN_FILTER_ID_EXACT_ADD, ARM_CAN_EXTENDED_ID(0x12345678U), 0U);
- if (status != ARM_DRIVER_OK ) { Error_Handler(); }
-
- status = ptrCAN->ObjectConfigure(tx_obj_idx, ARM_CAN_OBJ_TX); // Configure transmit object
- if (status != ARM_DRIVER_OK ) { Error_Handler(); }
-
- status = ptrCAN->ObjectConfigure(rx_obj_idx, ARM_CAN_OBJ_RX); // Configure receive object
- if (status != ARM_DRIVER_OK ) { Error_Handler(); }
-
- status = ptrCAN->SetMode (ARM_CAN_MODE_NORMAL); // Activate normal operation mode
- if (status != ARM_DRIVER_OK ) { Error_Handler(); }
-
- memset(&tx_msg_info, 0U, sizeof(ARM_CAN_MSG_INFO)); // Clear message info structure
- tx_msg_info.id = ARM_CAN_EXTENDED_ID(0x12345678U); // Set extended ID for transmit message
- tx_data[0] = 0xFFU; // Initialize transmit data
- while (1) {
- tx_data[0]++; // Increment transmit data
- status = ptrCAN->MessageSend(tx_obj_idx, &tx_msg_info, tx_data, 1U); // Send data message with 1 data byte
- if (status != 1U) { Error_Handler(); }
- for (i = 0U; i < 1000000U; i++) { __nop(); } // Wait a little while
- }
-}
-\endcode
-
-
-\section can_objects CAN Message Objects
-
-The CMSIS-Driver for the CAN interface provides multiple CAN message objects, which can be seen as individual communication channels.
-The number of available CAN message objects depends on the CAN peripheral. The function \ref ARM_CAN_GetCapabilities returns
-the maximum number of available CAN message objects. The number is encoded in the structure \ref ARM_CAN_CAPABILITIES in the data field \em num_objects.
-CAN message objects are addressed with the functions listed below, whereby the parameter \em obj_idx addresses an individual object.
-The valid range for \em obj_idx is \token{[0 .. (\em num_objects - 1)]}.
-
-Function | Description
-:----------------------------------|:--------------------------------------------
-\ref ARM_CAN_ObjectGetCapabilities | Retrieves message object capabilities such as receive, transmit, \ref Remote_Frame automatic handling and \ref can_filtering.
-\ref ARM_CAN_ObjectSetFilter | Allows to set-up CAN ID filtering for the message object.
-\ref ARM_CAN_ObjectConfigure | Allows to configure the message object for receive, transmit or \ref Remote_Frame automatic handling.
-\ref ARM_CAN_MessageRead | Read received message from the message object.
-\ref ARM_CAN_MessageSend | Send CAN message or send \ref Remote_Frame or set CAN message to be sent automatically on reception of matching \ref Remote_Frame on the message object.
-\ref ARM_CAN_SignalObjectEvent | Callback function that signals a message transfer or a received message overrun.
-
-Each CAN message object may have different capabilities. Before using a CAN message object, call the
-function \ref ARM_CAN_ObjectGetCapabilities to verify the available features.
-
-
-\section can_filtering CAN Message Filtering
-
-The CMSIS-Driver for the CAN interface supports ID filtering for the receiving message objects. The receiving CAN node examines the identifier
-to decide if it was relevant. This filtering is done by the CAN peripheral according the settings configured with the function \ref ARM_CAN_ObjectSetFilter.
-
-The function \ref ARM_CAN_ObjectGetCapabilities retrieves the filter capabilities of the CAN message objects stored in \ref ARM_CAN_OBJ_CAPABILITIES.
-
-Data Fields | CAN Messages Object can be filtered with ...
-:--------------------------|:--------------------------------------------
-\em exact_filtering | an exact ID value set by using the function \ref ARM_CAN_ObjectSetFilter with \em control = \ref ARM_CAN_FILTER_ID_EXACT_ADD.
-\em range_filtering | a range ID value set by using the function \ref ARM_CAN_ObjectSetFilter with \em control = \ref ARM_CAN_FILTER_ID_RANGE_ADD.
-\em mask_filtering | a mask ID value set by as using the function \ref ARM_CAN_ObjectSetFilter with \em control = \ref ARM_CAN_FILTER_ID_MASKABLE_ADD.
-\em multiple_filters | ... several filters to capture multiple ID values, or ID value ranges.
-
-CAN message filtering using an exact ID
-
-Example: accept in message object #1 only frames with extended ID = 0x1567.
-\code
- status = ptrCAN->ObjectSetFilter (1, ARM_CAN_FILTER_ID_EXACT_ADD, ARM_CAN_EXTENDED_ID(0x1567), 0);
- if (status != ARM_DRIVER_OK) ... // error handling
-\endcode
-
-Example: accept in message object #2 frames with extended ID = 0x3167 and extended ID = 0x42123.
-\code
- status = ptrCAN->ObjectSetFilter (2, ARM_CAN_FILTER_ID_EXACT_ADD, ARM_CAN_EXTENDED_ID(0x3167), 0);
- if (status != ARM_DRIVER_OK) ... // error handling
- status = ptrCAN->ObjectSetFilter (2, ARM_CAN_FILTER_ID_EXACT_ADD, ARM_CAN_EXTENDED_ID(0x42123), 0);
- if (status != ARM_DRIVER_OK) ... // error handling
-\endcode
-
-CAN message filtering using a range ID
-
-Example: accept in message object #3 only frames with extended ID >= 0x1567 and extended ID <= 0x1577.
-\code
- status = ptrCAN->ObjectSetFilter (3, ARM_CAN_FILTER_ID_RANGE_ADD, ARM_CAN_EXTENDED_ID(0x1567), ARM_CAN_EXTENDED_ID(0x1577));
- if (status != ARM_DRIVER_OK) ... // error handling
-\endcode
-
-
-CAN message filtering using a mask ID
-
-Using the function \ref ARM_CAN_ObjectSetFilter with \em control = \ref ARM_CAN_FILTER_ID_MASKABLE_ADD allows to specify with \em arg a mask value.
- - if a mask bit is \token{0}, the corresponding \em ID bit will be accepted, regardless of the value.
- - if a mask bit is \token{1}, the corresponding \em ID bit will be compared with the value of the ID filter bit; if they match the message will be accepted otherwise the frame is rejected.
-
-Example: accept in message object #0 only frames with extended IDs 0x1560 to 0x156F.
-\code
- status = ptrCAN->ObjectSetFilter (0, ARM_CAN_FILTER_ID_MASKABLE_ADD, ARM_CAN_EXTENDED_ID(0x1560), 0x1FFFFFF0);
- if (status != ARM_DRIVER_OK) ... // error handling
-\endcode
-
-Example: accept in message object #2 only frames with extended IDs 0x35603, 0x35613, 0x35623, and 0x35633.
-\code
- status = ptrCAN->ObjectSetFilter (2, ARM_CAN_FILTER_ID_MASKABLE_ADD, ARM_CAN_EXTENDED_ID(0x35603), 0x1FFFFFCF);
- if (status != ARM_DRIVER_OK) ... // error handling
-\endcode
-
-Example: accept any message in object #4 regardless of the ID.
-\code
- status = ptrCAN->ObjectSetFilter (4, ARM_CAN_FILTER_ID_MASKABLE_ADD, ARM_CAN_EXTENDED_ID(0), 0);
- if (status != ARM_DRIVER_OK) ... // error handling
-\endcode
-
-\section Remote_Frame Remote Frame
-
-In general, data transmission is performed on an autonomous basis with the data source node sending out Data Frames.
-
-However, sending a Remote Frame allows a destination node to request the data from the source node.
-The examples below shows the data exchange using a Remote Transmission Request (RTR) .
-
-Example for automatic Data Message response on RTR
-
-For automatic data message response on an RTR, the object is configured with the function \ref ARM_CAN_ObjectConfigure \em obj_cfg = \ref ARM_CAN_OBJ_RX_RTR_TX_DATA.
-
-In this case, the function \ref ARM_CAN_MessageSend sets a data message that is transmitted when an RTR with a matching CAN ID is received.
-If \ref ARM_CAN_MessageSend was not called before the RTR is received, the response is hardware dependent (either last data message is repeated
-or no data message is sent until \ref ARM_CAN_MessageSend is called).
-
-After data transmission is completed, the driver calls a callback function \ref ARM_CAN_SignalObjectEvent with \em event = \ref ARM_CAN_EVENT_SEND_COMPLETE
-and the related \em obj_idx.
-
-Example:
-\code
- status = ptrCAN->ObjectSetFilter(0, ARM_CAN_FILTER_ID_EXACT_ADD, ARM_CAN_EXTENDED_ID(0x12345678U), 0U);
- if (status != ARM_DRIVER_OK) ... // error handling
- status = trCAN->ObjectConfigure(0, ARM_CAN_OBJ_RX_RTR_TX_DATA);
- if (status != ARM_DRIVER_OK) ... // error handling
-
- memset(&tx_msg_info, 0, sizeof(ARM_CAN_MSG_INFO)); // Clear transmit message structure
- tx_msg_info.id = ARM_CAN_EXTENDED_ID(0x12345678U); // Set ID of message
- data_buf[0] = '1'; data_buf[1] = '2'; // Prepare data to transmit
- data_buf[2] = '3'; data_buf[3] = '4';
- data_buf[4] = '5'; data_buf[5] = '6';
- data_buf[6] = '7'; data_buf[7] = '8';
- ptrCAN->MessageSend(0, &tx_msg_info, data_buf, 8); // Start send message that will be triggered on RTR reception
-\endcode
-
-
-Example for automatic Data Message reception using RTR
-
-For automatic data message reception on an RTR, the object is configured with the function \ref ARM_CAN_ObjectConfigure \em obj_cfg = \ref ARM_CAN_OBJ_TX_RTR_RX_DATA.
-
-The receiver or consumer requests data with transmission of an RTR with the \ref ARM_CAN_MessageSend. This RTR requests from the transmitter or producer to send the data message.
-Once the data message is received, the driver calls a callback function \ref ARM_CAN_SignalObjectEvent with \em event = \ref ARM_CAN_EVENT_RECEIVE
-and the related \em obj_idx. The received data message can then be read with the function \ref ARM_CAN_MessageRead.
-
-Example:
-\code
- status = ptrCAN->ObjectSetFilter(0, ARM_CAN_FILTER_ID_EXACT_ADD, ARM_CAN_EXTENDED_ID(0x12345678U), 0U);
- if (status != ARM_DRIVER_OK) ... // error handling
- status = ptrCAN->ObjectConfigure(0, ARM_CAN_OBJ_TX_RTR_RX_DATA);
- if (status != ARM_DRIVER_OK) ... // error handling
- memset(&tx_msg_info, 0, sizeof(ARM_CAN_MSG_INFO)); // Clear transmit message structure
- tx_msg_info.id = ARM_CAN_EXTENDED_ID(0x12345678U); // Set ID of message
- tx_msg_info.rtr = 1; // Set RTR flag of message to send RTR
- tx_msg_info.dlc = 1; // Set data length code of message to 1 to request 1 data byte
- ptrCAN->MesageSend(0, &tx_msg_info, 0, 0); // Send RTR
-
- // Wait for ARM_CAN_EVENT_RECEIVE
- ptrCAN->MessageRead(0, &rx_msg_info, data_buf, 8); // Read received message
-\endcode
-
-
-@{
-*****************************************************************************************************************/
-
-/**
-\struct ARM_DRIVER_CAN
-\details
-The functions of the CAN are accessed by function pointers exposed by this structure. Refer to \ref DriverFunctions for overview information.
-
-Each instance of a CAN provides such an access structure.
-The instance is identified by a postfix number in the symbol name of the access structure, for example:
- - \b Driver_CAN0 is the name of the access struct of the first instance (no. 0).
- - \b Driver_CAN1 is the name of the access struct of the second instance (no. 1).
-
-A configuration setting in the middleware allows you to connect the middleware to a specific driver instance Driver_CANn .
-*******************************************************************************************************************/
-
-/**
-\struct ARM_CAN_CAPABILITIES
-\details
-A CAN driver can be implemented with different capabilities encoded in the data fields of this structure.
-
-Returned by:
- - \ref ARM_CAN_GetCapabilities
-
-\sa \ref ARM_CAN_OBJ_CAPABILITIES for information about CAN objects.
-*******************************************************************************************************************/
-
-/**
-\struct ARM_CAN_STATUS
-\details
-Structure with information about the status of the CAN unit state and errors.
-The data fields encode the unit bus state, last error code, transmitter error count, and receiver error count.
-
-Returned by:
- - \ref ARM_CAN_GetStatus
-*****************************************************************************************************************/
-
-/**
-\struct ARM_CAN_MSG_INFO
-\brief CAN Message Information
-\details
-Structure with information about the CAN message.
-
-In CAN mode, the following \ref ARM_CAN_MSG_INFO data fields are ignored: \em edl, \em brs, \em esi. \n
-In CAN FD mode, the following \ref ARM_CAN_MSG_INFO data field is ignored: \em rtr.
-
-Parameter for:
- - \ref ARM_CAN_MessageSend
- - \ref ARM_CAN_MessageRead
-
-\sa \ref can_filtering
-\sa \ref Remote_Frame
-*****************************************************************************************************************/
-
-/**
-\typedef ARM_CAN_SignalUnitEvent_t
-\details
-Provides the typedef for the callback function \ref ARM_CAN_SignalUnitEvent.
-
-Parameter for:
- - \ref ARM_CAN_Initialize
-*******************************************************************************************************************/
-
-/**
-\typedef ARM_CAN_SignalObjectEvent_t
-\details
-Provides the typedef for the callback function \ref ARM_CAN_SignalObjectEvent.
-
-Parameter for:
- - \ref ARM_CAN_Initialize
-*******************************************************************************************************************/
-
-/**
-\defgroup can_status_code_ctrls Status Error Codes
-\ingroup can_interface_gr
-\brief Status codes of the CAN driver.
-\details
-
-The following callback notification unit events are generated:
-@{
-\def ARM_CAN_UNIT_STATE_INACTIVE
-\def ARM_CAN_UNIT_STATE_ACTIVE
-\def ARM_CAN_UNIT_STATE_PASSIVE
-\def ARM_CAN_UNIT_STATE_BUS_OFF
-\def ARM_CAN_LEC_NO_ERROR
-\def ARM_CAN_LEC_BIT_ERROR
-\def ARM_CAN_LEC_STUFF_ERROR
-\def ARM_CAN_LEC_CRC_ERROR
-\def ARM_CAN_LEC_FORM_ERROR
-\def ARM_CAN_LEC_ACK_ERROR
-@}
-*******************************************************************************************************************/
-
-/**
-\defgroup CAN_unit_events CAN Unit Events
-\ingroup can_interface_gr
-\brief Callback unit events notified via \ref ARM_CAN_SignalUnitEvent.
-\details
-The CAN driver generates callback unit events that are notified via the function \ref ARM_CAN_SignalUnitEvent.
-
-The following callback notification unit events are generated:
-@{
-\def ARM_CAN_EVENT_UNIT_INACTIVE
-\sa \ref ARM_CAN_SignalUnitEvent
-\def ARM_CAN_EVENT_UNIT_ACTIVE
-\sa \ref ARM_CAN_SignalUnitEvent
-\def ARM_CAN_EVENT_UNIT_WARNING
-\sa \ref ARM_CAN_SignalUnitEvent
-\def ARM_CAN_EVENT_UNIT_PASSIVE
-\sa \ref ARM_CAN_SignalUnitEvent
-\def ARM_CAN_EVENT_UNIT_BUS_OFF
-\sa \ref ARM_CAN_SignalUnitEvent
-@}
-*******************************************************************************************************************/
-
-/**
-\defgroup CAN_events CAN Object Events
-\brief Callback objects events notified via \ref ARM_CAN_SignalObjectEvent.
-\details
-The CAN driver generates callback objects events that are notified via the function \ref ARM_CAN_SignalObjectEvent.
-
-The following callback notification object events are generated:
-@{
-\def ARM_CAN_EVENT_SEND_COMPLETE
-\sa \ref ARM_CAN_SignalObjectEvent
-\def ARM_CAN_EVENT_RECEIVE
-\sa \ref ARM_CAN_SignalObjectEvent
-\def ARM_CAN_EVENT_RECEIVE_OVERRUN
-\sa \ref ARM_CAN_SignalObjectEvent
-@}
-*******************************************************************************************************************/
-
-/**
-\defgroup can_control CAN Control Codes
-\ingroup can_interface_gr
-\brief Codes to configure the CAN driver.
-\details
-@{
-The various CAN control codes define:
-
- - \ref can_identifer_ctrls specify CAN identifier. Refer to \ref ARM_CAN_ObjectConfigure.
- - \ref can_mode_ctrls control CAN interface operation. Refer to \ref ARM_CAN_Control.
- - \ref can_timeseg_ctrls specify CAN bit rate and timing. Refer to \ref ARM_CAN_SetBitrate.
- - \ref can_bus_mode_ctrls specify CAN bus operating mode. Refer to \ref ARM_CAN_SetMode.
- - \ref can_filter_operation_ctrls specify CAN filter operations. Refer to \ref ARM_CAN_ObjectSetFilter.
- - \ref can_obj_config_ctrls specify CAN object configuration modes. Refer to \ref ARM_CAN_ObjectConfigure.
-*****************************************************************************************************************/
-
-/**
-\defgroup can_identifer_ctrls CAN Identifier
-\brief Set object to standard or extended.
-\details
-
-@{
-\def ARM_CAN_STANDARD_ID(id)
-\sa \ref ARM_CAN_ObjectConfigure
-\def ARM_CAN_EXTENDED_ID(id)
-\sa \ref ARM_CAN_ObjectConfigure
-@}
-*******************************************************************************************************************/
-
-/**
-\defgroup can_mode_ctrls CAN Operation Codes
-\brief Set CAN operation modes.
-\details
-
-These controls set the CAN operation using the function \ref ARM_CAN_Control.
-
-@{
-\def ARM_CAN_SET_FD_MODE
-\sa \ref ARM_CAN_Control
-\def ARM_CAN_ABORT_MESSAGE_SEND
-\sa \ref ARM_CAN_Control
-\def ARM_CAN_ABORT_MESSAGE_SEND
-\sa \ref ARM_CAN_Control
-\def ARM_CAN_CONTROL_RETRANSMISSION
-\sa \ref ARM_CAN_Control
-\def ARM_CAN_SET_TRANSCEIVER_DELAY
-\sa \ref ARM_CAN_Control
-
-@}
-*****************************************************************************************************************/
-
-/**
-\defgroup can_bus_mode_ctrls CAN Bus Communication Mode
-@{
-\brief Set or initialize the CAN bus
-\enum ARM_CAN_MODE
-\details
-The enumerations below initialize and set the bus communication mode.
-
-Parameter for:
- - \ref ARM_CAN_SetMode
-@}
-*/
-
-/**
-\defgroup can_timeseg_ctrls CAN Bit Timing Codes
-@{
-\brief Set bit timing
-\details
-The following codes are used with the function \ref ARM_CAN_SetBitrate.
-
-\def ARM_CAN_BIT_PROP_SEG(x)
-\sa \ref ARM_CAN_SetBitrate
-\def ARM_CAN_BIT_PHASE_SEG1(x)
-\sa \ref ARM_CAN_SetBitrate
-\def ARM_CAN_BIT_PHASE_SEG2(x)
-\sa \ref ARM_CAN_SetBitrate
-\def ARM_CAN_BIT_SJW(x)
-\sa \ref ARM_CAN_SetBitrate
-
-*******************************************************************************************************************/
-
-/**
-\enum ARM_CAN_BITRATE_SELECT
-\brief Set the bit rate.
-\details
-Provides the typedef for setting the bit rate.
-
-Parameter for:
- - \ref ARM_CAN_SetBitrate
-*******************************************************************************************************************/
-/**
-@}
-*/
-
-/**
-\defgroup can_filter_operation_ctrls CAN Filter Operation Codes
-@{
-\brief Set CAN filter manipulation codes.
-
-\enum ARM_CAN_FILTER_OPERATION
-\details
-
-\b ARM_CAN_FILTER_OPERATION provides the controls for setting the filter type.
-Refer to \ref can_filtering for details.
-
-Parameter for:
- - \ref ARM_CAN_ObjectSetFilter
-@}
-*****************************************************************************************************************/
-
-/**
-\defgroup can_obj_config_ctrls CAN Object Configuration Codes
-@{
-\brief CAN Object Configuration codes
-\enum ARM_CAN_OBJ_CONFIG
-\details
-Provides defined values for the configuration of CAN objects.
-
-Parameter for:
- - \ref ARM_CAN_ObjectConfigure
-@}
-**************************************************************************************************************************/
-
-/**
-@}
-*/ /* End Control Code */
-
-/**
-\struct ARM_CAN_OBJ_CAPABILITIES
-@{
-\details
-A CAN object can be implemented with different capabilities encoded in the
-data fields of this structure.
-
-Returned by :
- - \ref ARM_CAN_ObjectGetCapabilities
-
-\sa \ref ARM_CAN_ObjectConfigure
-\sa \ref ARM_CAN_MessageSend
-\sa \ref ARM_CAN_MessageRead
-\sa \ref ARM_CAN_MSG_INFO
-\sa \ref can_filtering
-@}
-*****************************************************************************************************************/
-
-
-//
-// Functions
-//
-ARM_DRIVER_VERSION ARM_CAN_GetVersion (void) {
- return { 0, 0 };
-}
-/**
-\fn ARM_DRIVER_VERSION ARM_CAN_GetVersion (void)
-\details
-The function \b ARM_CAN_GetVersion returns version information of the driver implementation in \ref ARM_DRIVER_VERSION
- - API version is the version of the CMSIS-Driver specification used to implement this driver.
- - Driver version is source code version of the actual driver implementation.
-
-Example:
-\code
-extern ARM_DRIVER_CAN Driver_CAN0;
-ARM_DRIVER_CAN *drv_info;
-
-void setup_can (void) {
- ARM_DRIVER_VERSION version;
-
- drv_info = &Driver_CAN0;
- version = drv_info->GetVersion ();
- if (version.api < 0x10A) { // requires at minimum API version 1.10 or higher
- // error handling
- return;
- }
-}
-\endcode
-*******************************************************************************************************************/
-
-ARM_CAN_CAPABILITIES ARM_CAN_GetCapabilities (void) {
- return { 0 };
-}
-/**
-\fn ARM_CAN_CAPABILITIES ARM_CAN_GetCapabilities (void)
-\details
-The function \b ARM_CAN_GetCapabilities returns information about the capabilities in this driver implementation.
-The data fields of the structure \ref ARM_CAN_CAPABILITIES encode various capabilities.
-
-Example:
-\code
-extern ARM_DRIVER_CAN Driver_CAN0;
-ARM_DRIVER_CAN *drv_info;
-
-void read_capabilities (void) {
- ARM_CAN_CAPABILITIES drv_capabilities;
-
- drv_info = &Driver_CAN0;
- drv_capabilities = drv_info->GetCapabilities ();
- // interrogate capabilities
-
-}
-\endcode
-*******************************************************************************************************************/
-
-
-int32_t ARM_CAN_Initialize (ARM_CAN_SignalUnitEvent_t cb_unit_event, ARM_CAN_SignalObjectEvent_t cb_object_event) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_CAN_Initialize (ARM_CAN_SignalUnitEvent_t cb_unit_event, ARM_CAN_SignalObjectEvent_t cb_object_event)
-\details
-The function \b initializes the CAN interface.
-
-The function performs the following operations:
- - Initializes the resources needed for the CAN interface, for example dynamic memory allocation, RTOS object allocation, and possibly hardware pin configuration.
- - Registers the \ref ARM_CAN_SignalUnitEvent callback function.
- - Registers the \ref ARM_CAN_SignalObjectEvent callback function.
-
-The parameter \em cb_unit_event is a pointer to the \ref ARM_CAN_SignalUnitEvent callback function; use a NULL pointer
-when no callback signals are required.
-
-The parameter \em cb_object_event is a pointer to the \ref ARM_CAN_SignalObjectEvent callback function; use a NULL pointer
-when no callback signals are required.
-
-\b Example:
- - see \ref can_interface_gr
-
-**************************************************************************************************************************/
-
-
-int32_t ARM_CAN_Uninitialize (void) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_CAN_Uninitialize (void)
-\details
-The function \b ARM_CAN_Uninitialize de-initializes the resources of the CAN interface.
-It is called to release the software resources used by the interface such as deallocate any RTOS objects, dynamic memory and pin de-configuration.
-*******************************************************************************************************************/
-
-int32_t ARM_CAN_PowerControl (ARM_POWER_STATE state) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_CAN_PowerControl (ARM_POWER_STATE state)
-\details
-The function \b ARM_CAN_PowerControl controls the power modes of the CAN interface.
-
-The parameter \em state can be:
- - ARM_POWER_FULL: Activate clocks and driver functionality as if peripheral was reset.
- - ARM_POWER_OFF: Unconditionally put peripheral into non-functional (reset) state.
- - ARM_POWER_LOW: Put peripheral into low power consumption state ready to wake up on bus event.
-
-**************************************************************************************************************************/
-
-uint32_t ARM_CAN_GetClock (void) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn uint32_t ARM_CAN_GetClock (void)
-\details
-The function \b ARM_CAN_GetClock returns the CAN base clock frequency in \token{[Hz]}.
-This value may be used to validate the \em bitrate for the function \ref ARM_CAN_SetBitrate.
-
-Example :
-\code
- CAN_clock = ARM_CAN_GetClock(); // CAN base clock frequency
-\endcode
-
-**************************************************************************************************************************/
-
-int32_t ARM_CAN_SetBitrate (ARM_CAN_BITRATE_SELECT select, uint32_t bitrate, uint32_t bit_segments) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_CAN_SetBitrate (ARM_CAN_BITRATE_SELECT select, uint32_t bitrate, uint32_t bit_segments)
-\details
-The function \b ARM_CAN_SetBitrate sets the CAN communication bit rate.
-
-The parameter \em select selects the bit rate affected by function call as defined in \ref ARM_CAN_BITRATE_SELECT and listed in the table below.
-
-Parameter \em select | CAN Mode Bit Rate
-:--------------------------------------------|:------------------------------
-\ref ARM_CAN_BITRATE_NOMINAL | Select nominal (flexible data-rate arbitration) bitrate (CAN 2.0B)
-\ref ARM_CAN_BITRATE_FD_DATA | Select flexible data-rate data bitrate (\ref CAN_FD)
-
-The parameter \em bitrate is the bit rate for the selected CAN mode.
-
-The parameter \em bit_segments is used to setup the time quanta for sampling (see picture below).
-The values listed in the table below are ORed and specify the various sampling segments.
-The CAN controller samples each bit on the bus at the Sample Point .
-
-
-
- Parameter \em bit_segments
- Bit
- for \em select = \ref ARM_CAN_BITRATE_NOMINAL \n (CAN specification)
- for \em select = \ref ARM_CAN_BITRATE_NOMINAL \n (CAN FD specification)
- for \em select = \ref ARM_CAN_BITRATE_FD_DATA \n (CAN FD specification)
-
-
- \ref ARM_CAN_BIT_PROP_SEG(x ) \n
- Propagation Time Segment \n (PROP_SEG)
-
- 0..7
- \em x = \token{[1..8]}
- \em x = \token{[1..32] or more}
- \em x = \token{[0..8]}
-
-
- \ref ARM_CAN_BIT_PHASE_SEG1(x ) \n
- Phase Buffer Segment 1 \n (PHASE_SEG1)
-
- 8..15
- \em x = \token{[1..8]}
- \em x = \token{[1..32] or more}
- \em x = \token{[1..8]}
-
-
- \ref ARM_CAN_BIT_PHASE_SEG2(x ) \n
- Phase Buffer Segment 2 \n (PHASE_SEG2)
-
- 16..23
- \em x = \token{[1..8]}
- \em x = \token{[1..32] or more}
- \em x = \token{[1..8]}
-
- The maximum allowed value is \token{x = MAX (PHASE_SEG1, IPT)}.
- IPT = Information Processing Time. Usually, IPT = \token{2}.
- Exceptions apply. Read the specifications of your CAN controller.
-
-
- \ref ARM_CAN_BIT_SJW(x ) \n
- (Re-)Synchronization Jump Width \n (SJW).
-
- 24..31
- \em x = \token{[1..4]}
- \em x = \token{[1..4]}
- \em x = \token{[1..4]}
-
- The maximum allowed value is \token{x = MIN (MIN (PHASE_SEG1, PHASE_SEG2), 4)}.
- SJW is not allowed to be greater than either PHASE segment.
-
-
-
-
-
-The picture shows a Nominal Bit Time with 10 time quanta.
-\image html CAN_Bit_Timing.png "CAN Bit Timing"
-
-
-The time quanta (N) per bit is:
-\code
- N = 1 + PROP_SEG + PHASE_SEG1 + PHASE_SEG2; // note SYNC_SEG is always 1
-\endcode
-
-The driver uses this value and the CAN clock to calculate a suitable prescaler value (P).
-If the driver cannot achieve the requested \em bitrate it returns with \ref ARM_CAN_INVALID_BITRATE.
-The formula for the \em bitrate is:
-\code
- bitrate = (CAN_Clock / P) / N;
-\endcode
-
-Example :
-\code
-status = ptrCAN->SetBitrate (ARM_CAN_BITRATE_NOMINAL, // Set nominal bitrate
- 125000U, // Set bitrate to 125 kbit/s
- ARM_CAN_BIT_PROP_SEG(5U) | // Set propagation segment to 5 time quanta
- ARM_CAN_BIT_PHASE_SEG1(1U) | // Set phase segment 1 to 1 time quantum (sample point at 87.5% of bit time)
- ARM_CAN_BIT_PHASE_SEG2(1U) | // Set phase segment 2 to 1 time quantum (total bit is 8 time quanta long)
- ARM_CAN_BIT_SJW(1U)); // Resynchronization jump width is same as phase segment 2
-\endcode
-
-In this example, N = 8 and with a CAN_Clock = 8MHz the prescaler (P) is calculated by the driver to 8.
-**************************************************************************************************************************/
-
-int32_t ARM_CAN_SetMode (ARM_CAN_MODE mode) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_CAN_SetMode (ARM_CAN_MODE mode)
-\details
-The function \b ARM_CAN_SetMode sets the CAN bus communication mode using the parameter \em mode.
-
-The table lists the values for \em mode.
-
-
- Parameter \em mode
- Bus Communication Mode
- supported when \ref ARM_CAN_OBJ_CAPABILITIES data field
- \ref ARM_CAN_MODE_INITIALIZATION
- Initialization mode; Used to setup communication parameters for the reception
- objects and global filtering, while peripheral is not active on the bus.
- Refer to \ref can_filtering for details.
- always supported \ref ARM_CAN_MODE_NORMAL
- Normal operation mode. Used when peripheral is in active mode to
- receive, transmit, and acknowledge messages on the bus. Depending on the current unit state,
- it can generate error or overload messages. Verify the unit state with \ref ARM_CAN_GetStatus.
- always supported \ref ARM_CAN_MODE_RESTRICTED
- Restricted operation mode. Used for monitoring the bus communication non-intrusively
- without transmitting.
- \em restricted_mode = \token{1}
- \ref ARM_CAN_MODE_MONITOR
- Bus monitoring mode.
- \em monitor_mode = \token{1}
- \ref ARM_CAN_MODE_LOOPBACK_INTERNAL
- Test mode; loopback of CAN transmission to its receiver. No transmission visible on CAN bus.
- \em internal_loopback = \token{1}
- \ref ARM_CAN_MODE_LOOPBACK_EXTERNAL
- Test mode; loopback of CAN transmission to its receiver. Transmission is visible on CAN bus.
- \em external_loopback = \token{1}
-
-**************************************************************************************************************************/
-
-ARM_CAN_OBJ_CAPABILITIES ARM_CAN_ObjectGetCapabilities (uint32_t obj_idx) {
- // your code
- // return type ARM_CAN_OBJ_CAPABILITIES;
-}
-/**
-\fn ARM_CAN_OBJ_CAPABILITIES ARM_CAN_ObjectGetCapabilities (uint32_t obj_idx)
-\details
-The function \b ARM_CAN_ObjectGetCapabilities retrieves the capabilities of a CAN object.
-The structure \ref ARM_CAN_OBJ_CAPABILITIES stores the values.
-
-The parameter \em obj_idx is the message object index.
-
-\sa ARM_CAN_ObjectConfigure
-\sa ARM_CAN_ObjectSetFilter
-**************************************************************************************************************************/
-
-int32_t ARM_CAN_ObjectSetFilter (uint32_t obj_idx, ARM_CAN_FILTER_OPERATION operation, uint32_t id, uint32_t arg) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_CAN_ObjectSetFilter (uint32_t obj_idx, ARM_CAN_FILTER_OPERATION operation, uint32_t id, uint32_t arg)
-\details
-The function \b ARM_CAN_ObjectSetFilter sets or removes the filter for message reception. Refer to \ref can_filtering for details on filtering.
-
-The parameter \em obj_idx is the message object index. \n
-The parameter \em operation is the operation on the filter as listed in the table below and
-which are defined in the structure \ref ARM_CAN_FILTER_OPERATION.
-
-Parameter \em operation | Operation on Filter | supported when \ref ARM_CAN_OBJ_CAPABILITIES data field
-:---------------------------------------|:------------------------------|:------------------------------------------
-\ref ARM_CAN_FILTER_ID_EXACT_ADD | Add exact ID filter | \em exact_filtering = \token{1}
-\ref ARM_CAN_FILTER_ID_EXACT_REMOVE | Remove exact ID filter | \em exact_filtering = \token{1}
-\ref ARM_CAN_FILTER_ID_RANGE_ADD | Add range ID filter | \em range_filtering = \token{1}
-\ref ARM_CAN_FILTER_ID_RANGE_REMOVE | Remove range ID filter | \em range_filtering = \token{1}
-\ref ARM_CAN_FILTER_ID_MASKABLE_ADD | Add maskable ID filter | \em mask_filtering = \token{1}
-\ref ARM_CAN_FILTER_ID_MASKABLE_REMOVE | Remove maskable ID filter | \em mask_filtering = \token{1}
-
-The parameter \em id is the identifier of the filter or defines the start of the filter range (depends on the filter operation). \n
-The parameter \em arg is the mask of the filter or defines the end of the filter range (depends on the filter operation).
-
-\sa ARM_CAN_ObjectConfigure
-**************************************************************************************************************************/
-
-int32_t ARM_CAN_ObjectConfigure (uint32_t obj_idx, ARM_CAN_OBJ_CONFIG obj_cfg) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_CAN_ObjectConfigure (uint32_t obj_idx, ARM_CAN_OBJ_CONFIG obj_cfg)
-\details
-The function \b ARM_CAN_ObjectConfigure configures the message object, which can be a mailbox or FIFO.
-Refer to \ref can_filtering for details.
-
-The parameter \em obj_idx specifies the message object index. \n
-The parameter \em obj_cfg configures the \b object with values as shown in the following table.
-
-
-
- Parameter \em obj_cfg
- Object Configuration
- supported when \ref ARM_CAN_OBJ_CAPABILITIES data field
-
-
- \ref ARM_CAN_OBJ_INACTIVE
- Deactivate object (default after \ref ARM_CAN_Initialize)
-
- always supported
-
- \ref ARM_CAN_OBJ_RX
- Receive object; read received message with \ref ARM_CAN_MessageRead.
-
- \em rx = \token{1}
-
-
- \ref ARM_CAN_OBJ_TX
- Transmit object; send message with \ref ARM_CAN_MessageSend.
-
- \em tx = \token{1}
-
-
- \ref ARM_CAN_OBJ_RX_RTR_TX_DATA
- \ref Remote_Frame Receive; when \b RTR is received data message is transmitted; set data message with \ref ARM_CAN_MessageSend.
-
- \em rx_rtr_tx_data = \token{1}
-
-
- \ref ARM_CAN_OBJ_TX_RTR_RX_DATA
- \ref Remote_Frame Transmit; a \b RTR is sent with \ref ARM_CAN_MessageSend to trigger object reception; read received data message with \ref ARM_CAN_MessageRead.
-
- \em tx_rtr_rx_data = \token{1}
-
-
-
-When the \b object is deactivated, it is not used for data communication.
-
-\sa ARM_CAN_ObjectSetFilter
-**************************************************************************************************************************/
-
-int32_t ARM_CAN_MessageSend (uint32_t obj_idx, ARM_CAN_MSG_INFO *msg_info, const uint8_t *data, uint8_t size) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_CAN_MessageSend (uint32_t obj_idx, ARM_CAN_MSG_INFO *msg_info, const uint8_t *data, uint8_t size)
-\details
-The function \b ARM_CAN_MessageSend sends a CAN message on the CAN bus, or sets data message that will be automatically returned upon RTR reception with matching CAN ID.
-
-Only one message can be sent with a call to this function (for CAN up to \token{8} bytes; for CAN FD up to \token{64} bytes of data).
-A message transmission can be terminated with a call to the function \ref ARM_CAN_Control with \em control = \ref ARM_CAN_ABORT_MESSAGE_SEND.
-
-The parameter \em obj_idx specifies the message object index.
-
-The parameter \em msg_info is a pointer to the structure \ref ARM_CAN_MSG_INFO, which contains the following relevant data fields for sending message:
- - \em id: Identifier of the message; bit \token{31} specifies if this is an \token{11-bit} or \token{29-bit} identifier.
- - \em rtr: Specifies if Remote Transmission Request should be sent (\em dlc is used for number of requested bytes), otherwise the data message will be sent. Refer to \ref Remote_Frame for details.
- - \em edl: Specifies if Extended Data Length is used; for CAN FD, message can contain up to \token{64} data bytes.
- - \em brs: Specifies if Bit Rate Switching is to be used; for CAN FD, the bit rate can be increased during data phase.
- - \em dlc: Data Length Code of requested data bytes when sending Remote Transmission Request.
-
-The parameter \em data is a pointer to the data buffer.\n
-The parameter \em size is the number of data bytes to send.\n
-
-The function returns the number of bytes accepted to be sent or \ref ARM_DRIVER_ERROR_BUSY if the hardware is not
-ready to accept a new message for transmission.
-
-When the message is sent, the callback function \ref ARM_CAN_SignalObjectEvent is called signalling \ref ARM_CAN_EVENT_SEND_COMPLETE
-on specified object.
-
-\sa \ref can_filtering
-
-Example:
-
-\code
- status = ptrCAN->ObjectConfigure(0, ARM_CAN_OBJ_TX);
- if (status != ARM_DRIVER_OK ) { Error_Handler(); }
-
- memset(&tx_msg_info, 0, sizeof(ARM_CAN_MSG_INFO)); // Clear transmit message structure
- tx_msg_info.id = ARM_CAN_EXTENDED_ID(0x12345678U); // Set ID of message
- data_buf[0] = '1'; data_buf[1] = '2'; // Prepare data to transmit
- data_buf[2] = '3'; data_buf[3] = '4';
- data_buf[4] = '5'; data_buf[5] = '6';
- data_buf[6] = '7'; data_buf[7] = '8';
- status = ptrCAN->MesageSend(0, &tx_msg_info, data_buf, 8); // Send message
- if (status != ARM_DRIVER_OK ) { Error_Handler(); }
-\endcode
-**************************************************************************************************************************/
-
-int32_t ARM_CAN_MessageRead (uint32_t obj_idx, ARM_CAN_MSG_INFO *msg_info, uint8_t *data, uint8_t size) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_CAN_MessageRead (uint32_t obj_idx, ARM_CAN_MSG_INFO *msg_info, uint8_t *data, uint8_t size)
-\details
-The function \b ARM_CAN_MessageRead reads the message received on the CAN bus, if \em obj_idx was configured for reception or
-for automatic Data Message reception using RTR and the callback function \ref ARM_CAN_SignalObjectEvent was called
-signalling \ref ARM_CAN_EVENT_RECEIVE.
-If the message was overrun by another received message, then the callback function \ref ARM_CAN_SignalObjectEvent
-will be called signalling \ref ARM_CAN_EVENT_RECEIVE_OVERRUN.
-
-The function can read a maximum of \token{8} data bytes for CAN and \token{64} bytes for CAN FD.
-
-The parameter \em obj_idx specifies the message object index. \n
-The parameter \em msg_info is a pointer to the CAN information structure. \n
-The parameter \em data is a pointer to the data buffer for reading data. \n
-The parameter \em size is data buffer size in bytes and indicates the maximum number of bytes that can be read.
-
-The function returns the number of read data in bytes or the \ref execution_status.
-
-All data fields of the structure \ref ARM_CAN_MSG_INFO are updated as described below:
- - id: Identifier of the message that was received, bit \token{31} specifies if it is a \token{11-bit} identifier or \token{29-bit} identifier.
- - rtr: \token{1} = Remote Frame Request was received (\em dlc is number of requested bytes). \token{0} = data message
- - edl: \token{1} = CAN FD Extended Data Length message was received. \token{0} = not Extended Data Length message.
- - brs: \token{1} = CAN FD Bit Rate Switching was used for message transfer. \token{0} = no Bit Rate Switching was used.
- - esi: \token{1} = CAN FD Error State Indicator is active for received message. \token{0} = Error State Indicator is not active.
- - dlc: Data Length Code is the number of data bytes in the received message or number of data bytes requested by RTR.
-
-Message reception can be disabled by de-configuring the receive object with the function \ref ARM_CAN_ObjectConfigure.
-**************************************************************************************************************************/
-
-int32_t ARM_CAN_Control (uint32_t control, uint32_t arg) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_CAN_Control (uint32_t control, uint32_t arg)
-\details
-The function \b ARM_CAN_Control controls the CAN interface settings and executes various operations.
-
-The parameter \em control specifies various operations that are listed in the table below.
-
-The parameters \em arg provides, depending on the \em control value, additional information or set values.
-
-Parameter \em control | Operation
-:--------------------------------------------|:------------------------------
-\ref ARM_CAN_SET_FD_MODE | Select CAN FD Ethernet is a networking technology for exchanging data packages between computer systems. Several microcontrollers integrate
-an Ethernet MAC (Media Access Control) data-link layer that interfaces to an Ethernet PHY (Physical Interface Transceiver).
-
-Wikipedia offers more information about
-the Ethernet Block Diagram
-
-The Ethernet PHY connects typically to the Ethernet MAC using an MII (Media Independent Interface) or RMII (Reduced Media Independent Interface).
-
-\n
-\image html EthernetSchematic.png "Block Diagram of a typical Ethernet Interface"
-
-
-Ethernet API
-
-The following header files define the Application Programming Interface (API) for the Ethernet interface:
- - \b %Driver_ETH.h : Common definitions of the Ethernet PHY and MAC part
- - \b %Driver_ETH_MAC.h : API for the Ethernet MAC
- - \b %Driver_ETH_PHY.h : API for the Ethernet PHY
-
-The driver implementation of the Ethernet MAC is a typical part of a Device Family Pack (DFP) that supports the peripherals of the microcontroller family.
-The driver implementation of the Ethernet PHY is a typical part of a \b Network Software Pack, since PHY is typically not integrated into the microcontroller.
-
-\note
-For parameters, the value marked with (default) is the setting after the driver initialization.
-
-
-Driver Functions
-
-The driver functions are published in the access struct as explained in \ref DriverFunctions
- - \ref ARM_DRIVER_ETH_MAC : access struct for Ethernet MAC driver functions.
- - \ref ARM_DRIVER_ETH_PHY : access struct for Ethernet PHY driver functions.
-
-Both drivers are used in combination and usually the Ethernet MAC provides a media interface to the Ethernet PHY.
-A typical setup sequence for the drivers is shown below:
-
-Example Code
-
-The following example code shows the usage of the Ethernet interface.
-
-\code
-extern ARM_DRIVER_ETH_MAC Driver_ETH_MAC0;
-extern ARM_DRIVER_ETH_PHY Driver_ETH_PHY0;
-
-static ARM_DRIVER_ETH_MAC *mac;
-static ARM_DRIVER_ETH_PHY *phy;
-static ARM_ETH_MAC_ADDR own_mac_address;
-static ARM_ETH_MAC_CAPABILITIES capabilities;
-
-void ethernet_mac_notify (uint32_t event) {
- switch (event) {
- :
- }
-}
-
-
-void initialize_ethernet_interface (void) {
- mac = &Driver_ETH_MAC0;
- phy = &Driver_ETH_PHY0;
-
- // Initialize Media Access Controller
- capabilities = mac->GetCapabilities ();
-
- mac->Initialize (ethernet_mac_notify);
- mac->PowerControl (ARM_POWER_FULL);
-
- if (capabilities.mac_address == 0) {
- // populate own_mac_address with the address to use
- mac->SetMacAddress(&own_mac_address);
- }
- else {
- mac->GetMacAddress(&own_mac_address);
- }
-
- // Initialize Physical Media Interface
- if (phy->Initialize (mac->PHY_Read, mac->PHY_Write) == ARM_DRIVER_OK) {
- phy->PowerControl (ARM_POWER_FULL);
- phy->SetInterface (capabilities.media_interface);
- phy->SetMode (ARM_ETH_PHY_AUTO_NEGOTIATE);
- }
- :
- :
-}
-
-
-static ARM_ETH_LINK_STATE ethernet_link; // current link status
-
-void ethernet_check_link_status (void) {
- ARM_ETH_LINK_STATE link;
-
- link = phy->GetLinkState ();
- if (link == ethernet_link) {
- return; // link state unchanged
- }
- // link state changed
- ethernet_link = link;
- if (link == ARM_ETH_LINK_UP) { // start transfer
- ARM_ETH_LINK_INFO info = phy->GetLinkInfo ();
- mac->Control(ARM_ETH_MAC_CONFIGURE,
- info.speed << ARM_ETH_MAC_SPEED_Pos |
- info.duplex << ARM_ETH_MAC_DUPLEX_Pos |
- ARM_ETH_MAC_ADDRESS_BROADCAST);
- mac->Control(ARM_ETH_MAC_CONTROL_TX, 1);
- mac->Control(ARM_ETH_MAC_CONTROL_RX, 1);
- }
- else { // stop transfer
- mac->Control(ARM_ETH_MAC_FLUSH, ARM_ETH_MAC_FLUSH_TX | ARM_ETH_MAC_FLUSH_RX);
- mac->Control(ARM_ETH_MAC_CONTROL_TX, 0);
- mac->Control(ARM_ETH_MAC_CONTROL_RX, 0);
- }
-}
-
-\endcode
-*/
-
-/**
-\defgroup eth_interface_gr Ethernet Interface
-@{
-*/
-
-/**
-\cond
-*/
-
-/**
-\enum ARM_ETH_INTERFACE
-\details
-Encodes the supported media interface between Ethernet MAC and Ethernet PHY.
-
-The function \ref ARM_ETH_MAC_GetCapabilities retrieves the media interface type encoded in the data field \b media_interface of the struct
- \ref ARM_ETH_MAC_CAPABILITIES.
-
-Parameter for:
-- \ref ARM_ETH_PHY_SetInterface
-*/
-
-/**
-\enum ARM_ETH_DUPLEX
-\details
-Lists the supported duplex operating types for MAC.
-
-Parameter for:
- - \ref ARM_ETH_MAC_SetMode
-*/
-
-
-/**
-\typedef ARM_ETH_SPEED
-\details
-Lists the supported operating speeds for MAC.
-
-Parameter for:
- - \ref ARM_ETH_MAC_SetMode
-*/
-
-/**
-\endcond
-*/
-
-
-/**
-\typedef ARM_ETH_LINK_STATE
-\details
-The Ethernet Link status shows if the communication is currently established (up) or interrupted (down).
-
-Returned by:
- - \ref ARM_ETH_PHY_GetLinkState
-*/
-
-
-/**
-\struct ARM_ETH_LINK_INFO
-\details
-The Ethernet Link information provides parameters about the current established communication.
-
-Returned by:
- - \ref ARM_ETH_PHY_GetLinkInfo
-*/
-
-
-/**
-\struct ARM_ETH_MAC_ADDR
-\details
-Stores the MAC Address of the Ethernet interface as defined by IEEE 802. Wikipedia offers more information about
-the MAC Address Parameter for:
- - \ref ARM_ETH_MAC_GetMacAddress, \ref ARM_ETH_MAC_SetMacAddress, \ref ARM_ETH_MAC_SetAddressFilter
-*/
-
-/**
-@}
-*/
-// End ETH Interface
-
-
-/**
-\defgroup eth_interface_types1 Media Interface Types
-\ingroup eth_interface_gr
-\brief Ethernet Media Interface type
-\details
-Encodes the supported media interface between Ethernet MAC and Ethernet PHY.
-The function \ref ARM_ETH_MAC_GetCapabilities retrieves the media interface type encoded in the data field \b media_interface of the struct
- \ref ARM_ETH_MAC_CAPABILITIES.
-
-Parameter for:
-- \ref ARM_ETH_PHY_SetInterface
-
-@{
-\def ARM_ETH_INTERFACE_MII
-\sa ARM_ETH_PHY_SetInterface
-\def ARM_ETH_INTERFACE_RMII
-\sa ARM_ETH_PHY_SetInterface
-\def ARM_ETH_INTERFACE_SMII
-\sa ARM_ETH_PHY_SetInterface
-@}
-*/
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/Driver_ETH_MAC.c b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/Driver_ETH_MAC.c
deleted file mode 100644
index d5ca696..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/Driver_ETH_MAC.c
+++ /dev/null
@@ -1,641 +0,0 @@
-/**
-\defgroup eth_mac_interface_gr Ethernet MAC Interface
-\ingroup eth_interface_gr
-\brief Driver API for Ethernet MAC Peripheral (%Driver_ETH_MAC.h)
-\details
-The following section describes the Ethernet MAC Interface as defined in the %Driver_ETH_MAC.h header file.
-@{
-*/
-
-/**
-\struct ARM_ETH_MAC_CAPABILITIES
-\details
-An Ethernet MAC driver can be implemented with different capabilities.
-The data fields of this struct encode the capabilities implemented by this driver.
-
-Returned by:
- - \ref ARM_ETH_MAC_GetCapabilities
-*/
-
-/**
-\struct ARM_DRIVER_ETH_MAC
-\details
-The functions of the Ethernet MAC are accessed by function pointers. Refer to \ref DriverFunctions for
-overview information.
-
-Each instance of an Ethernet MAC provides such an access struct. The instance is indicated by
-a postfix in the symbol name of the access struct, for example:
- - \b Driver_ETH_MAC0 is the name of the access struct of the first instance (no. 0).
- - \b Driver_ETH_MAC1 is the name of the access struct of the second instance (no. 1).
-
-A configuration setting in the middleware allows connecting the middleware to a specific driver instance Driver_ETH_MACn .
-The default is \token{0}, which connects a middleware to the first instance of a driver.
-*/
-
-/**
-\struct ARM_ETH_MAC_TIME
-\details
-The two members of this struct provide fields to encode time values in the order \token{Nano seconds} and \token{seconds}.
-
-The member \em ns is also used as a correction factor for \ref ARM_ETH_MAC_TIMER_ADJUST_CLOCK.
-
-Used in:
- - \ref ARM_ETH_MAC_GetRxFrameTime
- - \ref ARM_ETH_MAC_GetTxFrameTime
- - \ref ARM_ETH_MAC_ControlTimer
-
-*******************************************************************************************************************/
-
-/**
-\typedef ARM_ETH_MAC_SignalEvent_t
-\details
-Provides the typedef for the callback function \ref ARM_ETH_MAC_SignalEvent.
-
-Parameter for:
- - \ref ARM_ETH_MAC_Initialize
-*******************************************************************************************************************/
-
-/**
-\defgroup ETH_MAC_events Ethernet MAC Events
-\ingroup eth_mac_interface_gr
-\brief The Ethernet MAC driver generates call back events that are notified via the function \ref ARM_ETH_MAC_SignalEvent.
-\details
-This section provides the event values for the \ref ARM_ETH_MAC_SignalEvent callback function.
-
-The following call back notification events are generated:
-@{
-\def ARM_ETH_MAC_EVENT_RX_FRAME
-\def ARM_ETH_MAC_EVENT_TX_FRAME
-\def ARM_ETH_MAC_EVENT_WAKEUP
-\def ARM_ETH_MAC_EVENT_TIMER_ALARM
-@}
-*/
-
-//
-// Function documentation
-//
-
-ARM_DRIVER_VERSION ARM_ETH_MAC_GetVersion (void) {
- ;
-}
-/**
-\fn ARM_DRIVER_VERSION ARM_ETH_MAC_GetVersion (void);
-\details
-The function \b ARM_ETH_MAC_GetVersion returns version information of the driver implementation in \ref ARM_DRIVER_VERSION
- - API version is the version of the CMSIS-Driver specification used to implement this driver.
- - Driver version is source code version of the actual driver implementation.
-
-Example:
-\code
-extern ARM_DRIVER_ETH_MAC Driver_ETH_MAC0;
-ARM_DRIVER_ETH_MAC *mac;
-
-void setup_ethernet (void) {
- ARM_DRIVER_VERSION version;
-
- mac = &Driver_ETH_MAC0;
- version = mac->GetVersion ();
- if (version.api < 0x10A) { // requires at minimum API version 1.10 or higher
- // error handling
- return;
- }
-}
-\endcode
-*******************************************************************************************************************/
-
-ARM_ETH_MAC_CAPABILITIES ARM_ETH_MAC_GetCapabilities (void) {
- ;
-}
-/**
-\fn ARM_ETH_MAC_CAPABILITIES ARM_ETH_MAC_GetCapabilities (void)
-\details
-The function \b ARM_ETH_MAC_GetCapabilities retrieves information about capabilities in this driver implementation.
-The data fields of the struct \ref ARM_ETH_MAC_CAPABILITIES encode various capabilities, for example
-if a hardware is capable to create checksums in hardware or signal events using the \ref ARM_ETH_MAC_SignalEvent
-callback function.
-
-Example:
-\code
-extern ARM_DRIVER_ETH_MAC Driver_ETH_MAC0;
-ARM_DRIVER_ETH_MAC *mac;
-
-void read_capabilities (void) {
- ARM_ETH_MAC_CAPABILITIES mac_capabilities;
-
- mac = &Driver_ETH_MAC0;
- mac_capabilities = mac->GetCapabilities ();
- // interrogate capabilities
-
-}
-\endcode
-*******************************************************************************************************************/
-
-int32_t ARM_ETH_MAC_Initialize (ARM_ETH_MAC_SignalEvent_t cb_event) {
-
-}
-/**
-\fn int32_t ARM_ETH_MAC_Initialize (ARM_ETH_MAC_SignalEvent_t cb_event)
-\details
-The function \b ARM_ETH_MAC_Initialize initializes the Ethernet MAC interface.
-It is called when the middleware component starts operation.
-
-The \ref ARM_ETH_MAC_Initialize function performs the following operations:
- - Initializes the resources needed for the Ethernet MAC peripheral.
- - Registers the \ref ARM_ETH_MAC_SignalEvent callback function.
-
-The parameter \em cb_event is a pointer to the \ref ARM_ETH_MAC_SignalEvent callback function; use a NULL pointer
-when no callback signals are required.
-
-\b Example:
- - see \ref eth_interface_gr - Driver Functions
-*******************************************************************************************************************/
-
-int32_t ARM_ETH_MAC_Uninitialize (void) {
-
-}
-/**
-\fn int32_t ARM_ETH_MAC_Uninitialize (void)
-\details
-The function \b ARM_ETH_MAC_Uninitialize de-initializes the resources of Ethernet MAC interface.
-
-It is called when the middleware component stops operation and releases the software resources
-used by the interface.
-*******************************************************************************************************************/
-
-int32_t ARM_ETH_MAC_PowerControl (ARM_POWER_STATE state) {
-
-}
-/**
-\fn int32_t ARM_ETH_MAC_PowerControl (ARM_POWER_STATE state)
-\details
-The function \b ARM_ETH_MAC_PowerControl allows you to configure the power modes of the Ethernet MAC interface.
-
-The parameter \em state can be:
- - ARM_POWER_OFF: Ethernet MAC peripheral is turned off.
- - ARM_POWER_FULL: Ethernet MAC peripheral is turned on and fully operational.
-
-If power \em state specifies an unsupported mode, the function returns \ref ARM_DRIVER_ERROR_UNSUPPORTED as status information
-and the previous power state of the peripheral is unchanged. Multiple calls with the same \em state generate no
-error.
-
-\b Example:
- - see \ref eth_interface_gr - Driver Functions
-*******************************************************************************************************************/
-
-int32_t ARM_ETH_MAC_GetMacAddress (ARM_ETH_MAC_ADDR *ptr_addr) {
-
-}
-/**
-\fn int32_t ARM_ETH_MAC_GetMacAddress (ARM_ETH_MAC_ADDR *ptr_addr)
-\details
-The function \b ARM_ETH_MAC_GetMacAddress retrieves the Ethernet MAC own address from the driver.
-*******************************************************************************************************************/
-
-int32_t ARM_ETH_MAC_SetMacAddress (const ARM_ETH_MAC_ADDR *ptr_addr) {
-
-}
-/**
-\fn int32_t ARM_ETH_MAC_SetMacAddress (const ARM_ETH_MAC_ADDR *ptr_addr)
-\details
-The function \b ARM_ETH_MAC_SetMacAddress configures Ethernet MAC own address.
-The Ethernet MAC accepts packets Ethernet frames Ethernet frames Ethernet frame Ethernet frame Ethernet frame Ethernet frame Ethernet frame Parameter \em control . \n
-The parameter \em arg provides, depending on the operation, additional information or values.
-
-The table lists values for the parameter \em control.
-
-Parameter \em control | Operation
-:----------------------------------------------------|:--------------------------------------------
-\ref ARM_ETH_MAC_CONFIGURE | Configure the Ethernet MAC interface; For \em arg values, see table Parameter \em arg for CONFIGURE
-\ref ARM_ETH_MAC_CONTROL_TX | Enable or disable the transmitter; \em arg : \token{0=disable; 1=enable}
-\ref ARM_ETH_MAC_CONTROL_RX | Enable or disable the receiver; \em arg : \token{0=disable; 1=enable}
-\ref ARM_ETH_MAC_FLUSH | Flush a buffer; \em arg : see table Parameter \em arg for FLUSH
-\ref ARM_ETH_MAC_SLEEP | Exit/Enter Sleep mode; \em arg : \token{0=exit; 1=enter and wait for Magic packet}
-\ref ARM_ETH_MAC_VLAN_FILTER | Configure VLAN Filter for received frames; \em arg : See table Parameter \em arg for VLAN Filter
-
-
-The table Parameter \em arg for CONFIGURE lists the \em arg values for the \em control \b ARM_ETH_MAC_CONFIGURE.
-The values can be ORed in the following way:
-\code
- mac->Control(ARM_ETH_MAC_CONFIGURE, ARM_ETH_MAC_SPEED_100M | ARM_ETH_MAC_DUPLEX_FULL | ARM_ETH_MAC_LOOPBACK);
-\endcode
-
-
-Parameter \em arg CONFIGURE Parameter \em arg Bit Category Description \ref ARM_ETH_MAC_SPEED_10M 0..1 Link Speed Set the link speed to \token{10 [Mbps]} \ref ARM_ETH_MAC_SPEED_100M Set the link speed to \token{100 [Mbps]} \ref ARM_ETH_MAC_SPEED_1G Set the link speed to \token{1 [Gbps]} \ref ARM_ETH_MAC_DUPLEX_HALF 2 Link Mode Set the link mode to half duplex \ref ARM_ETH_MAC_DUPLEX_FULL Set the link mode to full duplex n.a. 3 n.a. \em reserved \ref ARM_ETH_MAC_LOOPBACK 4 Loopback Test Mode Set the interface into a Loop-back test mode \ref ARM_ETH_MAC_CHECKSUM_OFFLOAD_RX 5 Receiver Checksum offload Enable Receiver Checksum offload \ref ARM_ETH_MAC_CHECKSUM_OFFLOAD_TX 6 Transmitter Checksum offload Enable Transmitter Checksum offload \ref ARM_ETH_MAC_ADDRESS_BROADCAST 7 Broadcast Frame address Accept frames with Broadcast address \ref ARM_ETH_MAC_ADDRESS_MULTICAST 8 Multicast Frame address Accept frames with any Multicast address \ref ARM_ETH_MAC_ADDRESS_ALL 9 Any Frame address Accept frames with any address (Promiscuous Mode)
-
-The table Parameter \em arg for FLUSH lists the \em arg values for the \em control \b ARM_ETH_MAC_FLUSH.
-The \em arg values can be ORed.
-
-
-Parameter \em arg for FLUSH Parameter \em arg Bit Category Description \ref ARM_ETH_MAC_FLUSH_RX 1 Receive buffer Flush the Receive buffer \ref ARM_ETH_MAC_FLUSH_TX 2 Transmit buffer Flush the Transmit buffer
-
-The table Parameter \em arg for VLAN Filter lists the \em arg values for the \em control \b ARM_ETH_MAC_VLAN_FILTER.
-The \em arg values can be ORed.
-
-
-Parameter \em arg for VLAN Filter Parameter \em arg Bit Category Description \em value 0..15 VLAN Tag Set VLAN Tag value \token{0} 16 Use of VLAN Compare the complete 16-bit VLAN Tag value \ref ARM_ETH_MAC_VLAN_FILTER_ID_ONLY Compare only the 12-bit VLAN Identifier \token{0} 0..16 Disable Disable the VLAN Filter
-
-
-\b Example:
-
-\code
-...
- // start transfer
- mac->Control(ARM_ETH_MAC_CONFIGURE, ARM_ETH_MAC_SPEED_100M | ARM_ETH_MAC_DUPLEX_FULL | ARM_ETH_MAC_ADDRESS_BROADCAST);
- mac->Control(ARM_ETH_MAC_CONTROL_TX, 1);
- mac->Control(ARM_ETH_MAC_CONTROL_RX, 1);
-
-... // stop transfer
- mac->Control(ARM_ETH_MAC_FLUSH, ARM_ETH_MAC_FLUSH_TX | ARM_ETH_MAC_FLUSH_RX);
- mac->Control(ARM_ETH_MAC_CONTROL_TX, 0);
- mac->Control(ARM_ETH_MAC_CONTROL_RX, 0);
- }
-}
-\endcode
-
-For a complete example, refer to \ref eth_interface_gr - Driver Functions.
-
-*******************************************************************************************************************/
-
-int32_t ARM_ETH_MAC_ControlTimer (uint32_t control, ARM_ETH_MAC_TIME *time) {
-
-}
-/**
-\fn int32_t ARM_ETH_MAC_ControlTimer (uint32_t control, ARM_ETH_MAC_TIME *time)
-\details
-The function \b ARM_ETH_MAC_ControlTimer controls the timer required for PTP (Precision Time Protocol).
-
-The parameter \em control receives \b ARM_ETH_MAC_TIMER_xxx codes to manage the timer for a PTP enabled Ethernet MAC interface. \n
-The parameter \em time is pointer to a structure that holds time information.
-
-Mode Parameters: Timer Controls | Description
-:---------------------------------------|:--------------------------------------------
-\ref ARM_ETH_MAC_TIMER_GET_TIME | Retrieve the current time and update the content \ref ARM_ETH_MAC_TIME *time.
-\ref ARM_ETH_MAC_TIMER_SET_TIME | Set the new time using the values provided with \ref ARM_ETH_MAC_TIME *time.
-\ref ARM_ETH_MAC_TIMER_INC_TIME | Increment the current time by using the values provided with \ref ARM_ETH_MAC_TIME *time.
-\ref ARM_ETH_MAC_TIMER_DEC_TIME | Decrement the current time by using the values provided with \ref ARM_ETH_MAC_TIME *time.
-\ref ARM_ETH_MAC_TIMER_SET_ALARM | Set the alarm time to the values provided with \ref ARM_ETH_MAC_TIME *time.
-\ref ARM_ETH_MAC_TIMER_ADJUST_CLOCK | Set the clock frequency; the value in time->ns is the correction factor in fractional format q31.
-
-*******************************************************************************************************************/
-
-int32_t ARM_ETH_MAC_PHY_Read (uint8_t phy_addr, uint8_t reg_addr, uint16_t *data) {
-
-}
-/**
-\fn int32_t ARM_ETH_MAC_PHY_Read (uint8_t phy_addr, uint8_t reg_addr, uint16_t *data)
-\details
-
-Read Ethernet PHY Register through the Management Interface. The function is passed to \ref ARM_ETH_PHY_Initialize.
-The Ethernet PHY driver uses this function to read the value of PHY registers.
-
-\b Example:
- - see \ref eth_interface_gr - Driver Functions
-*******************************************************************************************************************/
-
-int32_t ARM_ETH_MAC_PHY_Write (uint8_t phy_addr, uint8_t reg_addr, uint16_t data) {
-
-}
-/**
-\fn int32_t ARM_ETH_MAC_PHY_Write (uint8_t phy_addr, uint8_t reg_addr, uint16_t data)
-\details
-The function \b ARM_ETH_MAC_PHY_Write writes to a Ethernet PHY register through the Management Interface. The function is passed to \ref ARM_ETH_PHY_Initialize.
-The Ethernet PHY driver uses this function to write data to PHY registers.
-
-\b Example:
- - see \ref eth_interface_gr - Driver Functions
-
-*******************************************************************************************************************/
-
-void ARM_ETH_MAC_SignalEvent (uint32_t event) {
- ;
-}
-/**
-\fn void ARM_ETH_MAC_SignalEvent (uint32_t event)
-\details
-
-The function \b ARM_ETH_MAC_SignalEvent is a callback function registered by the function
-\ref ARM_ETH_MAC_Initialize. This function is typically called from interrupt service routines (ISR) to indicate that
-a frame is processed or a special event occurred.
-
-The parameter \a event indicates one or more events that occurred during driver operation.
-Each event is encoded in a separate bit and therefore it is possible to signal multiple events within the same call.
-
-Not every event is necessarily generated by the driver. This depends on the implemented capabilities stored in the
-data fields of the structure \ref ARM_ETH_MAC_CAPABILITIES, which can be retrieved with the function \ref ARM_ETH_MAC_GetCapabilities.
-
-The following events can be generated:
-
-Parameter \em event | Bit | Description
-:----------------------------------------|:---:|:----------------------------------------
-\ref ARM_ETH_MAC_EVENT_RX_FRAME | 0 | Occurs after a frame is received. Frame can be read by calling \ref ARM_ETH_MAC_ReadFrame.
-\ref ARM_ETH_MAC_EVENT_TX_FRAME | 1 | Occurs after call to \ref ARM_ETH_MAC_SendFrame to indicate that the frame is transmitted.
-\ref ARM_ETH_MAC_EVENT_WAKEUP | 2 | Indicates that a Magic Packet is received while the driver is in Sleep mode (set by \ref ARM_ETH_MAC_SLEEP using \ref ARM_ETH_MAC_Control).
-\ref ARM_ETH_MAC_EVENT_TIMER_ALARM | 3 | Indicates that a Timer Alarm occurred that was set with \ref ARM_ETH_MAC_TIMER_SET_ALARM using ARM_ETH_MAC_ControlTimer.
-
-*******************************************************************************************************************/
-
-
-/**
-\defgroup eth_mac_control Ethernet MAC Control Codes
-\ingroup eth_mac_interface_gr
-\brief Configure and control the Ethernet MAC using the \ref ARM_ETH_MAC_Control.
-\details
-@{
-Many parameters of the Ethernet MAC driver are configured using the \ref ARM_ETH_MAC_Control function.
-
-The various Ethernet MAC control codes define:
-
- - \ref eth_mac_ctrls configures and controls the Ethernet MAC interface
- - \ref eth_mac_configuration_ctrls specifies speed mode, link mode, checksum, and frame filtering modes
- - \ref eth_mac_flush_flag_ctrls specify controls to flush a buffer
- - \ref eth_mac_vlan_filter_ctrls specifies whether to compare only the VLAN Identifier
-
-Refer to the \ref ARM_ETH_MAC_Control function for further details.
-*/
-
-/**
-\defgroup eth_mac_ctrls Ethernet MAC Controls
-\brief Configure and control the Ethernet MAC interface.
-\details
-@{
-\def ARM_ETH_MAC_CONFIGURE
-\sa ARM_ETH_MAC_Control
-\def ARM_ETH_MAC_CONTROL_TX
-\sa ARM_ETH_MAC_Control
-\def ARM_ETH_MAC_CONTROL_RX
-\sa ARM_ETH_MAC_Control
-\def ARM_ETH_MAC_FLUSH
-\sa ARM_ETH_MAC_Control
-\def ARM_ETH_MAC_SLEEP
-\sa ARM_ETH_MAC_Control
-\def ARM_ETH_MAC_VLAN_FILTER
-\sa ARM_ETH_MAC_Control
-@}
-*/
-
-
-/**
-\defgroup eth_mac_configuration_ctrls Ethernet MAC Configuration
-\brief Specifies speed mode, link mode, checksum, and frame filtering modes.
-\details
-@{
-The function \ref ARM_ETH_MAC_Control with \em control = \ref ARM_ETH_MAC_CONFIGURE configures the Ethernet MAC interface
-as specified with \em arg listed bellow.
-
-\def ARM_ETH_MAC_SPEED_10M
-\def ARM_ETH_MAC_SPEED_100M
-\def ARM_ETH_MAC_SPEED_1G
-\def ARM_ETH_MAC_DUPLEX_HALF
-\def ARM_ETH_MAC_DUPLEX_FULL
-\def ARM_ETH_MAC_LOOPBACK
-\def ARM_ETH_MAC_CHECKSUM_OFFLOAD_RX
-\def ARM_ETH_MAC_CHECKSUM_OFFLOAD_TX
-\def ARM_ETH_MAC_ADDRESS_BROADCAST
-\def ARM_ETH_MAC_ADDRESS_MULTICAST
-\def ARM_ETH_MAC_ADDRESS_ALL
-@}
-*/
-
-/**
-\defgroup eth_mac_flush_flag_ctrls Ethernet MAC Flush Flags
-\brief Specify controls to flush a buffer
-\details
-@{
-The function \ref ARM_ETH_MAC_Control with \em control = \ref ARM_ETH_MAC_FLUSH flushes the buffer
-which is specified with \em arg listed bellow.
-
-\def ARM_ETH_MAC_FLUSH_RX
-\def ARM_ETH_MAC_FLUSH_TX
-@}
-*/
-
-
-/**
-\defgroup eth_mac_vlan_filter_ctrls Ethernet MAC VLAN Filter Flag
-\brief Specify whether to compare only the VLAN Identifier
-\details
-@{
-The function \ref ARM_ETH_MAC_Control with \em control = \ref ARM_ETH_MAC_VLAN_FILTER configures the VLAN Filter for received frames as specified with \em arg.
-
-By default the complete VLAN Tag (16-bit) is compared. When \ref ARM_ETH_MAC_VLAN_FILTER_ID_ONLY is specified then only the VLAN Identifier (12-bit) is compared.
-
-Specifying \em arg=0 disables the VLAN Filter.
-
-\def ARM_ETH_MAC_VLAN_FILTER_ID_ONLY
-@}
-*/
-
-
-/**
-@} */ // end group eth_mac_control
-
-
-/**
-\defgroup eth_mac_time_control Ethernet MAC Timer Control Codes
-\ingroup eth_mac_interface_gr
-\brief Control codes for \ref ARM_ETH_MAC_ControlTimer function.
-\details
-The following timer controls are used as parameter \em control for the \ref ARM_ETH_MAC_ControlTimer function:
-@{
-\def ARM_ETH_MAC_TIMER_GET_TIME
-\sa ARM_ETH_MAC_ControlTimer
-\def ARM_ETH_MAC_TIMER_SET_TIME
-\sa ARM_ETH_MAC_ControlTimer
-\def ARM_ETH_MAC_TIMER_INC_TIME
-\sa ARM_ETH_MAC_ControlTimer
-\def ARM_ETH_MAC_TIMER_DEC_TIME
-\sa ARM_ETH_MAC_ControlTimer
-\def ARM_ETH_MAC_TIMER_SET_ALARM
-\sa ARM_ETH_MAC_ControlTimer
-\def ARM_ETH_MAC_TIMER_ADJUST_CLOCK
-\sa ARM_ETH_MAC_ControlTimer
-@}
-*/
-
-
-/**
-\defgroup eth_mac_frame_transmit_ctrls Ethernet MAC Frame Transmit Flags
-\brief Specify frame transmit flags
-\details
-@{
-\def ARM_ETH_MAC_TX_FRAME_FRAGMENT
-\sa ARM_ETH_MAC_SendFrame
-\def ARM_ETH_MAC_TX_FRAME_EVENT
-\sa ARM_ETH_MAC_SendFrame
-\def ARM_ETH_MAC_TX_FRAME_TIMESTAMP
-\sa ARM_ETH_MAC_SendFrame
-@}
-*/
-
-
-
-/**
-@}
-*/
-// End ETH MAC Interface
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/Driver_ETH_PHY.c b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/Driver_ETH_PHY.c
deleted file mode 100644
index 8bab658..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/Driver_ETH_PHY.c
+++ /dev/null
@@ -1,303 +0,0 @@
-/**
-\defgroup eth_phy_interface_gr Ethernet PHY Interface
-\ingroup eth_interface_gr
-\brief Driver API for Ethernet PHY Peripheral (%Driver_ETH_PHY.h)
-\details The following section describes the Ethernet PHY Interface as defined in the %Driver_ETH_PHY.h header file.
-
-The %Driver_ETH_PHY.h contains two \#defines that are used to configure the connection between the PHY and the
-microcontroller device:
-- \c ETH_PHY_NUM and
-- \c ETH_PHY_ADDR
-
-Usually, the Serial Management Interface (\b SMI) (using MDC and MDIO) is used to access the PHY’s internal registers to read
-the state of the link (up/down), duplex mode, speed, and to restart auto-negotiation etc. SMI is a serial bus, which allows
-to connect up to 32 devices. Devices on the bus are accessed using a 5-bit device address. A default device address is
-hardware configurable by pin-strapping on the device (some pins are sampled when a reset is asserted or at power-up).
-
-The device’s internal weak pull-up or pull-down resistors define a default device address. This address can be changed by
-connecting strong pull-up or pull-down resistors externally. In this case, the \c ETH_PHY_ADDR needs to be defined by the
-user.
-
-If a microcontroller device offers more than one Ethernet PHY driver, the user needs to set the correct \c ETH_PHY_NUM in his
-application.
-@{
-*/
-
-/**
-\struct ARM_DRIVER_ETH_PHY
-\details
-The functions of the Ethernet PHY are accessed by function pointers exposed by this structure. Refer to \ref DriverFunctions for
-overview information.
-
-Each instance of an Ethernet PHY provides such an access struct. The instance is identified by
-a postfix number in the symbol name of the access struct, for example:
- - \b Driver_ETH_PHY0 is the name of the access struct of the first instance (no. 0).
- - \b Driver_ETH_PHY1 is the name of the access struct of the second instance (no. 1).
-
-
-A configuration setting in the middleware allows connecting the middleware to a specific driver instance Driver_ETH_PHYn .
-The default is \token{0}, which connects a middleware to the first instance of a driver.
-*****************************************************************************************************************/
-
-
-/**
-\typedef ARM_ETH_PHY_Read_t
-\details
-Provides the typedef for the register read function \ref ARM_ETH_MAC_PHY_Read.
-
-Parameter for:
- - \ref ARM_ETH_PHY_Initialize
-*******************************************************************************************************************/
-
-/**
-\typedef ARM_ETH_PHY_Write_t
-\details
-Provides the typedef for the register write function \ref ARM_ETH_MAC_PHY_Write.
-
-Parameter for:
- - \ref ARM_ETH_PHY_Initialize
-*******************************************************************************************************************/
-
-
-//
-// Functions
-//
-
-ARM_DRIVER_VERSION ARM_ETH_PHY_GetVersion (void) {
- return { 0, 0 };
-}
-/**
-\fn ARM_DRIVER_VERSION ARM_ETH_PHY_GetVersion (void)
-\details
-The function \b ARM_ETH_PHY_GetVersion returns version information of the driver implementation in \ref ARM_DRIVER_VERSION
- - API version is the version of the CMSIS-Driver specification used to implement this driver.
- - Driver version is source code version of the actual driver implementation.
-
-Example:
-\code
-extern ARM_DRIVER_ETH_PHY Driver_ETH_PHY0;
-ARM_DRIVER_ETH_PHY *drv_info;
-
-void setup_ethernet_phy (void) {
- ARM_DRIVER_VERSION version;
-
- drv_info = &Driver_ETH_PHY0;
- version = drv_info->GetVersion ();
- if (version.api < 0x10A) { // requires at minimum API version 1.10 or higher
- // error handling
- return;
- }
-}
-\endcode
-*****************************************************************************************************************/
-
-int32_t ARM_ETH_PHY_Initialize (ARM_ETH_PHY_Read_t fn_read, ARM_ETH_PHY_Write_t fn_write) {
- return 0;
-}
-/**
-\fn int32_t ARM_ETH_PHY_Initialize (ARM_ETH_PHY_Read_t fn_read, ARM_ETH_PHY_Write_t fn_write)
-\details
-The function \b ARM_ETH_PHY_Initialize initializes the Ethernet PHY interface.
-It is called when the middleware component starts operation.
-
-The \ref ARM_ETH_PHY_Initialize function performs the following operations:
- - Initializes the resources needed for Ethernet PHY peripheral.
- - Registers the \ref ARM_ETH_MAC_PHY_Read register read access function.
- - Registers the \ref ARM_ETH_MAC_PHY_Write register write access function.
-
-\b Example:
- - see \ref eth_interface_gr - Driver Functions
-
-*****************************************************************************************************************/
-
-int32_t ARM_ETH_PHY_Uninitialize (void) {
- return 0;
-}
-/**
-\fn int32_t ARM_ETH_PHY_Uninitialize (void)
-\details
-The function \b ARM_ETH_PHY_Uninitialize de-initializes the resources of Ethernet PHY interface.
-
-It is called when the middleware component stops operation and releases the software resources used by the interface.
-*****************************************************************************************************************/
-
-int32_t ARM_ETH_PHY_PowerControl (ARM_POWER_STATE state) {
- return 0;
-}
-/**
-\fn int32_t ARM_ETH_PHY_PowerControl (ARM_POWER_STATE state)
-\details
-The function \b ARM_ETH_PHY_PowerControl operates the power modes of the Ethernet PHY interface.
-
-The parameter \em state sets the operation and can have the following values:
- - \ref ARM_POWER_FULL : set-up peripheral for data transfers, enable interrupts (NVIC) and optionally DMA.
- Can be called multiple times. If the peripheral is already in this mode the function performs
- no operation and returns with \ref ARM_DRIVER_OK.
- - \ref ARM_POWER_LOW : may use power saving. Returns \ref ARM_DRIVER_ERROR_UNSUPPORTED when not implemented.
- - \ref ARM_POWER_OFF : terminates any pending data transfers, disables peripheral, disables related interrupts and DMA.
-
-Refer to \ref CallSequence for more information.
-
-\b Example:
- - see \ref eth_interface_gr - Driver Functions
-*****************************************************************************************************************/
-
-int32_t ARM_ETH_PHY_SetInterface (uint32_t interface) {
- return 0;
-}
-/**
-\fn int32_t ARM_ETH_PHY_SetInterface (uint32_t interface)
-
-\details
-The function \b ARM_ETH_PHY_SetInterface specifies the \ref eth_interface_types1 that links the Ethernet MAC and Ethernet PHY.
-After initialization of the PHY interface, you can set the media type.
-The function \ref ARM_ETH_MAC_GetCapabilities retrieves the media interface type encoded in the data field \b media_interface of the structure
-\ref ARM_ETH_MAC_CAPABILITIES.
-
-The parameter \em interface can have the following values:
-
-Parameter \em interface | Media Type
-:-----------------------------|:-------------------------
-\ref ARM_ETH_INTERFACE_MII | Media Independent Interface (MII)
-\ref ARM_ETH_INTERFACE_RMII | Reduced Media Independent Interface (RMII)
-\ref ARM_ETH_INTERFACE_SMII | Serial Media Independent Interface (SMII);
-
-\note
-Some \em interface values may be unsupported by a driver implementation. For example \ref ARM_ETH_INTERFACE_SMII may return \b ARM_DRIVER_ERROR_UNSUPPORTED.
-
-\b Example:
-\code
-static ARM_ETH_MAC_CAPABILITIES capabilities;
-static ARM_DRIVER_ETH_MAC *mac;
-static ARM_DRIVER_ETH_PHY *phy;
-
-mac = &Driver_ETH_MAC0;
-phy = &Driver_ETH_PHY0;
-
-// Initialize Media Access Controller
-capabilities = mac->GetCapabilities ();
-...
-status = phy->SetInterface (capabilities.media_interface);
-if (status != ARM_DRIVER_OK) ... // error handling
-status = phy->SetMode (ARM_ETH_PHY_AUTO_NEGOTIATE);
-if (status != ARM_DRIVER_OK) ... // error handling
-...
-\endcode
-*****************************************************************************************************************/
-
-int32_t ARM_ETH_PHY_SetMode (uint32_t mode) {
- return 0;
-}
-/**
-\fn int32_t ARM_ETH_PHY_SetMode (uint32_t mode)
-\details
-The function \b ARM_ETH_PHY_SetMode sets the operation mode parameters for the Ethernet PHY.
-
-
-The table below lists the possible values for the parameter \em mode. Values from different categories can be ORed as shown in this example code:
-
-\code
-phy->SetMode (ARM_ETH_PHY_SPEED_100M | ARM_ETH_PHY_LOOPBACK | ARM_ETH_PHY_DUPLEX_HALF );
-\endcode
-\n
-
-
-Parameter \em mode bit Category Description \ref ARM_ETH_PHY_SPEED_10M 0..1 Link Speed Set the link speed to \token{10 [Mbps]} \ref ARM_ETH_PHY_SPEED_100M Set the link speed to \token{100 [Mbps]} \ref ARM_ETH_PHY_SPEED_1G Set the link speed to \token{1 [Gbps]} \ref ARM_ETH_PHY_DUPLEX_HALF 2 Link Mode Set the link mode to half duplex \ref ARM_ETH_PHY_DUPLEX_FULL Set the link mode to full duplex \ref ARM_ETH_PHY_AUTO_NEGOTIATE 3 Autonegotiation Set the interface to Auto Negotiation mode of transmission parameters \ref ARM_ETH_PHY_LOOPBACK 4 Loopback Set the interface into a Loop-back test mode \ref ARM_ETH_PHY_ISOLATE 5 Isolation Set to indicate electrical isolation of PHY interface from MII/RMII interface
-
-\note
-Some settings may be also taken from configuration pins (example \ref ARM_ETH_PHY_ISOLATE). Check the effect of mode settings in the actual driver implementation.
-\note
-Some \em mode values may be unsupported by a driver implementation. For example \ref ARM_ETH_PHY_SPEED_1G may return \b ARM_DRIVER_ERROR_UNSUPPORTED.
-
-
-\b Example:
-\code
-static ARM_ETH_MAC_CAPABILITIES capabilities;
-static ARM_DRIVER_ETH_MAC *mac;
-static ARM_DRIVER_ETH_PHY *phy;
-
-mac = &Driver_ETH_MAC0;
-phy = &Driver_ETH_PHY0;
-
-// Initialize Media Access Controller
-capabilities = mac->GetCapabilities ();
-...
-status = phy->SetInterface (capabilities.media_interface);
-if (status != ARM_DRIVER_OK) ... // error handling
-status = phy->SetMode (ARM_ETH_PHY_SPEED_100M | ARM_ETH_PHY_DUPLEX_FULL | ARM_ETH_PHY_ISOLATE);
-if (status != ARM_DRIVER_OK) ... // error handling
-...
-\endcode
-
-
-
-*****************************************************************************************************************/
-
-ARM_ETH_LINK_STATE ARM_ETH_PHY_GetLinkState (void) {
- return 0;
-}
-/**
-\fn ARM_ETH_LINK_STATE ARM_ETH_PHY_GetLinkState (void)
-\details
-The function \b ARM_ETH_PHY_GetLinkState retrieves the connection status of the physical Ethernet link.
-
-\b Example:
- - see \ref eth_interface_gr - Driver Functions
-*****************************************************************************************************************/
-
-ARM_ETH_LINK_INFO ARM_ETH_PHY_GetLinkInfo (void) {
- return 0;
-}
-/**
-\fn ARM_ETH_LINK_INFO ARM_ETH_PHY_GetLinkInfo (void)
-\details
-The function \b ARM_ETH_PHY_GetLinkInfo retrieves information about the current established communication
-mode (half/full duplex) and communication speed. Information is only valid when link is up (see \ref ARM_ETH_PHY_GetLinkState).
-
-\b Example:
- - see \ref eth_interface_gr - Driver Functions
-*****************************************************************************************************************/
-
-
-/**
-@}
-*/
-// End ETH PHY Interface group; below the groups are included with \ingroup
-
-
-/**
-\defgroup eth_phy_mode_ctrls Ethernet PHY Mode
-\ingroup eth_phy_interface_gr
-\brief Specify operation modes of the Ethernet PHY interface
-\details
-@{
-\def ARM_ETH_PHY_SPEED_10M
-\sa ARM_ETH_PHY_SetMode
-\def ARM_ETH_PHY_SPEED_100M
-\sa ARM_ETH_PHY_SetMode
-\def ARM_ETH_PHY_SPEED_1G
-\sa ARM_ETH_PHY_SetMode
-\def ARM_ETH_PHY_DUPLEX_HALF
-\sa ARM_ETH_PHY_SetMode
-\def ARM_ETH_PHY_DUPLEX_FULL
-\sa ARM_ETH_PHY_SetMode
-\def ARM_ETH_PHY_AUTO_NEGOTIATE
-\sa ARM_ETH_PHY_SetMode
-\def ARM_ETH_PHY_LOOPBACK
-\sa ARM_ETH_PHY_SetMode
-\def ARM_ETH_PHY_ISOLATE
-\sa ARM_ETH_PHY_SetMode
-@}
-*/
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/Driver_Flash.c b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/Driver_Flash.c
deleted file mode 100644
index 259ca63..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/Driver_Flash.c
+++ /dev/null
@@ -1,365 +0,0 @@
-/**
-\defgroup flash_interface_gr Flash Interface
-\brief Driver API for Flash Device Interface (%Driver_Flash.h)
-\details
-Flash devices based on NOR memory cells are the
-preferred technology for embedded applications requiring a discrete non-volatile memory device. The low read latency
-characteristic of these Flash devices allow a direct code execution
-(XIP ) and data storage in a single memory
-product.
-
-Flash API
-
-The Flash API provides a generic API suitable for Flashes with NOR memory cells independent from the actual interface
-to the MCU (memory bus, SPI, ...). SPI
-flashes are typically not named NOR flashes but have usually same flash cell properties.
-
-The following header files define the Application Programming Interface (API) for the Flash interface:
- - \b %Driver_Flash.h : Driver API for Flash Device Interface
-
-Driver Functions
-
-The driver functions are published in the access struct as explained in \ref DriverFunctions
- - \ref ARM_DRIVER_FLASH : access struct for Flash driver functions
-@{
-
-A typical setup sequence for the driver is shown below:
-
-Example Code:
-
-\include Flash_Demo.c
-*/
-*******************************************************************************************************************/
-
-
-/**
-\defgroup Flash_events Flash Events
-\ingroup flash_interface_gr
-\brief The Flash driver generates call back events that are notified via the function \ref ARM_Flash_SignalEvent.
-\details
-This section provides the event values for the \ref ARM_Flash_SignalEvent callback function.
-
-The following call back notification events are generated:
-@{
-\def ARM_FLASH_EVENT_READY
-\def ARM_FLASH_EVENT_ERROR
-@}
-*/
-
-
-/**
-\struct ARM_FLASH_SECTOR
-\details
-Specifies sector start and end address.
-
-Element of :
- - \ref ARM_FLASH_INFO structure
-*******************************************************************************************************************/
-
-/**
-\struct ARM_FLASH_INFO
-\details
-Stores the characteristics of a Flash device. This includes sector layout, programming size and a default value for erased memory.
-This information can be obtained from the Flash device datasheet and is used by the middleware in order to properly interact with the Flash device.
-
-Sector layout is described by specifying the \em sector_info which points to an array of sector information (start and end address) and by specifying the \em sector_count which defines the number of sectors.
-The element \em sector_size is not used in this case and needs to be \em 0.
-Flash sectors need not to be aligned continuously. Gaps are allowed in the device memory space in order to reserve sectors for other usage (for example application code).
-
-When the device has uniform sector size than the sector layout can be described by specifying the \em sector_size which defines the size of a single sector and by specifying the \em sector_count which defines the number of sectors.
-The element \em sector_info is not used in this case and needs to be \em NULL.
-
-The smallest programmable unit within a sector is specified by the \em program_unit. It defines the granularity for programming data.
-
-Optimal programming page size is specified by the \em page_size and defines the amount of data that should be programmed in one step to achieve maximum programming speed.
-
-Contents of erased memory is specified by the \em erased_value and is typically \em 0xFF. This value can be used before erasing a sector to check if the sector is blank and erase can be skipped.
-
-*******************************************************************************************************************/
-
-/**
-\struct ARM_DRIVER_FLASH
-\details
-The functions of the Flash driver are accessed by function pointers exposed by this structure. Refer to \ref DriverFunctions for overview information.
-
-Each instance of a Flash interface provides such an access structure.
-The instance is identified by a postfix number in the symbol name of the access structure, for example:
- - \b Driver_Flash0 is the name of the access struct of the first instance (no. 0).
- - \b Driver_Flash1 is the name of the access struct of the second instance (no. 1).
-
-A middleware configuration setting allows connecting the middleware to a specific driver instance \b %Driver_Flashn .
-The default is \token{0}, which connects a middleware to the first instance of a driver.
-*******************************************************************************************************************/
-
-/**
-\struct ARM_FLASH_CAPABILITIES
-\details
-A Flash driver can be implemented with different capabilities. The data fields of this struct encode
-the capabilities implemented by this driver.
-
-The element \em event_ready indicates that the driver is able to generate the \ref ARM_FLASH_EVENT_READY event. In case that this event is not available it is possible to poll the driver status by calling the \ref ARM_Flash_GetStatus and check the \em busy flag.
-
-The element \em data_width specifies the data access size and also defines the data type (uint8_t, uint16_t or uint32_t) for the \em data parameter in \ref ARM_Flash_ReadData and \ref ARM_Flash_ProgramData functions.
-
-The element \em erase_chip specifies that the \ref ARM_Flash_EraseChip function is supported. Typically full chip erase is much faster than erasing the whole device sector per sector.
-
-Returned by:
- - \ref ARM_Flash_GetCapabilities
-*******************************************************************************************************************/
-
-/**
-\struct ARM_FLASH_STATUS
-\details
-Structure with information about the status of the Flash.
-
-The flag \em busy indicates that the driver is busy executing read/program/erase operation.
-
-The flag \em error flag is cleared on start of read/program/erase operation and is set at the end of the current operation in case of error.
-
-Returned by:
- - \ref ARM_Flash_GetStatus
-*****************************************************************************************************************/
-
-/**
-\typedef ARM_Flash_SignalEvent_t
-\details
-Provides the typedef for the callback function \ref ARM_Flash_SignalEvent.
-
-Parameter for:
- - \ref ARM_Flash_Initialize
-*******************************************************************************************************************/
-
-
-//
-// Functions
-//
-
-ARM_DRIVER_VERSION ARM_Flash_GetVersion (void) {
- return { 0, 0 };
-}
-/**
-\fn ARM_DRIVER_VERSION ARM_Flash_GetVersion (void)
-\details
-The function \b ARM_Flash_GetVersion returns version information of the driver implementation in \ref ARM_DRIVER_VERSION
- - API version is the version of the CMSIS-Driver specification used to implement this driver.
- - Driver version is source code version of the actual driver implementation.
-
-Example:
-\code
-extern ARM_DRIVER_FLASH Driver_Flash0;
-ARM_DRIVER_FLASH *drv_info;
-
-void read_version (void) {
- ARM_DRIVER_VERSION version;
-
- drv_info = &Driver_Flash0;
- version = drv_info->GetVersion ();
- if (version.api < 0x10A) { // requires at minimum API version 1.10 or higher
- // error handling
- return;
- }
-}
-\endcode
-*******************************************************************************************************************/
-
-ARM_FLASH_CAPABILITIES ARM_Flash_GetCapabilities (void) {
- return { 0 };
-}
-/**
-\fn ARM_FLASH_CAPABILITIES ARM_Flash_GetCapabilities (void)
-\details
-The function \b ARM_Flash_GetCapabilities returns information about capabilities in this driver implementation.
-The data fields of the struct \ref ARM_FLASH_CAPABILITIES encode various capabilities, for example
-if a hardware is able to create signal events using the \ref ARM_Flash_SignalEvent callback function.
-
-Example:
-\code
-extern ARM_DRIVER_FLASH Driver_Flash0;
-ARM_DRIVER_FLASH *drv_info;
-
-void read_capabilities (void) {
- ARM_FLASH_CAPABILITIES drv_capabilities;
-
- drv_info = &Driver_Flash0;
- drv_capabilities = drv_info->GetCapabilities ();
- // interrogate capabilities
-
-}
-\endcode
-*******************************************************************************************************************/
-
-int32_t ARM_Flash_Initialize (ARM_Flash_SignalEvent_t cb_event) {
- return 0;
-}
-/**
-\fn int32_t ARM_Flash_Initialize (ARM_Flash_SignalEvent_t cb_event)
-\details
-The function \b ARM_Flash_Initialize initializes the Flash interface.
-It is called when the middleware component starts operation.
-
-The function performs the following operations:
- - Initializes the resources needed for the Flash interface.
- - Registers the \ref ARM_Flash_SignalEvent callback function.
-
-The parameter \em cb_event is a pointer to the \ref ARM_Flash_SignalEvent callback function; use a NULL pointer
-when no callback signals are required.
-
-\b Example:
- - see \ref flash_interface_gr - Driver Functions
-
-*******************************************************************************************************************/
-
-int32_t ARM_Flash_Uninitialize (void) {
- return 0;
-}
-/**
-\fn int32_t ARM_Flash_Uninitialize (void)
-\details
-The function \b ARM_Flash_Uninitialize de-initializes the resources of Flash interface.
-
-It is called when the middleware component stops operation and releases the software resources used by the interface.
-*******************************************************************************************************************/
-
-int32_t ARM_Flash_PowerControl (ARM_POWER_STATE state) {
- return 0;
-}
-/**
-\fn int32_t ARM_Flash_PowerControl (ARM_POWER_STATE state)
-\details
-The function \b ARM_Flash_PowerControl operates the power modes of the Flash interface.
-
-The parameter \em state can have the following values:
- - \ref ARM_POWER_FULL : set-up peripheral for data transfers, enable interrupts (NVIC) and optionally DMA. Can be called multiple times.
- If the peripheral is already in this mode, then the function performs no operation and returns with \ref ARM_DRIVER_OK.
- - \ref ARM_POWER_LOW : may use power saving. Returns \ref ARM_DRIVER_ERROR_UNSUPPORTED when not implemented.
- - \ref ARM_POWER_OFF : terminates any pending data transfers, disables peripheral, disables related interrupts and DMA.
-
-Refer to \ref CallSequence for more information.
-*******************************************************************************************************************/
-
-int32_t ARM_Flash_ReadData (uint32_t addr, void *data, uint32_t cnt) {
- return 0;
-}
-/**
-\fn int32_t ARM_Flash_ReadData (uint32_t addr, void *data, uint32_t cnt)
-\details
-This function \b ARM_Flash_ReadData reads data from the Flash device.
-
-The parameter \em addr specifies the address from where to read data (needs to be aligned to data type size). \n
-The parameter \em data specifies the pointer to a buffer storing the data read.
-The data type is \em uint8_t, \em uint16_t or \em uint32_t and is specified by the \em data_width in \ref ARM_FLASH_CAPABILITIES. \n
-The parameter \em cnt specifies the number of data items to read.
-
-The function executes in the following ways:
- - When the operation is non-blocking (typical for SPI Flash) then the function only starts the operation and returns with zero number of data items read.
- When the operation is completed the \ref ARM_FLASH_EVENT_READY event is generated (if supported and reported by \ref ARM_Flash_GetCapabilities).
- In case of errors the \ref ARM_FLASH_EVENT_ERROR event is generated at the same time.
- Progress of the operation can also be monitored by calling the \ref ARM_Flash_GetStatus function and checking the \em busy flag.
- - When the operation is blocking (typical for memory mapped Flash) then the function returns after the data is read and returns the number of data items read.
-*******************************************************************************************************************/
-
-int32_t ARM_Flash_ProgramData (uint32_t addr, const void *data, uint32_t cnt) {
- return 0;
-}
-/**
-\fn int32_t ARM_Flash_ProgramData (uint32_t addr, const void *data, uint32_t cnt)
-\details
-This function \b ARM_Flash_ProgramData programs data to the Flash device.
-
-The parameter \em addr specifies the address to where to program data (needs to be aligned to \em program_unit specified in \ref ARM_FLASH_INFO). \n
-The parameter \em data specifies the pointer to a buffer containing data to be programmed.
-The data type is \em uint8_t, \em uint16_t or \em uint32_t and is specified by the \em data_width in \ref ARM_FLASH_CAPABILITIES. \n
-The parameter \em cnt specifies the number of data items to program (data size needs to be a multiple of \em program_unit).
-
-The function executes in the following ways:
- - When the operation is non-blocking (typically) then the function only starts the operation and returns with zero number of data items programmed.
- When the operation is completed the \ref ARM_FLASH_EVENT_READY event is generated (if supported and reported by \ref ARM_Flash_GetCapabilities).
- In case of errors the \ref ARM_FLASH_EVENT_ERROR event is generated at the same time.
- Progress of the operation can also be monitored by calling the \ref ARM_Flash_GetStatus function and checking the \em busy flag.
- - When the operation is blocking then the function returns after the data is programmed and returns the number of data items programmed.
-*******************************************************************************************************************/
-
-int32_t ARM_Flash_EraseSector (uint32_t addr) {
- return 0;
-}
-/**
-\fn int32_t ARM_Flash_EraseSector (uint32_t addr)
-\details
-This function \b ARM_Flash_EraseSector erases a flash sector specified by the parameter adr (points to start of the sector).
-
-The function is non-blocking and returns as soon as the driver has started the operation.
-When the operation is completed the \ref ARM_FLASH_EVENT_READY event is generated (if supported and reported by \ref ARM_Flash_GetCapabilities).
-In case of errors the \ref ARM_FLASH_EVENT_ERROR event is generated at the same time.
-Progress of the operation can also be monitored by calling the \ref ARM_Flash_GetStatus function and checking the \em busy flag.
-*******************************************************************************************************************/
-
-int32_t ARM_Flash_EraseChip (void) {
- return 0;
-}
-/**
-\fn int32_t ARM_Flash_EraseChip (void)
-\details
-The optional function \b ARM_Flash_EraseChip erases the complete device.
-If the device does not support global erase or only a portion of the Flash memory space is used for storing files,
-then the functions returns the error value \ref ARM_DRIVER_ERROR_UNSUPPORTED.
-The data field \em eras_chip = \token{1} of the structure \ref ARM_FLASH_CAPABILITIES encodes that \b ARM_Flash_EraseChip is supported.
-The field can be verified with the function \ref ARM_Flash_GetCapabilities.
-
-The function is non-blocking and returns as soon as the driver has started the operation.
-When the operation is completed, the \ref ARM_FLASH_EVENT_READY event is generated (if supported and reported by \ref ARM_Flash_GetCapabilities).
-In case of errors, the \ref ARM_FLASH_EVENT_ERROR event is generated at the same time.
-Progress of the operation can also be monitored by calling the \ref ARM_Flash_GetStatus function and checking the \em busy flag.
-
-See also:
- - ARM_Flash_SignalEvent
-*******************************************************************************************************************/
-
-ARM_FLASH_STATUS ARM_Flash_GetStatus (void) {
- return 0;
-}
-/**
-\fn ARM_FLASH_STATUS ARM_Flash_GetStatus (void)
-\details
-The function \b ARM_Flash_GetStatus returns the current Flash interface status stored in the structure \ref ARM_FLASH_STATUS.
-*******************************************************************************************************************/
-
-ARM_FLASH_INFO * ARM_Flash_GetInfo (void) {
- return NULL;
-}
-/**
-\fn ARM_FLASH_INFO * ARM_Flash_GetInfo (void)
-\details
-The function \b ARM_Flash_GetInfo returns information about the Flash device.
-*******************************************************************************************************************/
-
-void ARM_Flash_SignalEvent (uint32_t event) {
- return 0;
-}
-/**
-\fn void ARM_Flash_SignalEvent (uint32_t event)
-\details
-
-The function \b ARM_Flash_SignalEvent is a callback function registered by the function \ref ARM_Flash_Initialize.
-The function is called automatically after read/program/erase operation completes.
-
-The parameter \em event indicates one or more events that occurred during driver operation. Each event is coded in a separate bit and
-therefore it is possible to signal multiple events in the event call back function.
-
-Not every event is necessarily generated by the driver. This depends on the implemented capabilities stored in the
-data fields of the structure \ref ARM_FLASH_CAPABILITIES, which can be retrieved with the function \ref ARM_Flash_GetCapabilities.
-
-The following events can be generated:
-
-Parameter \em event | Bit | Description
-:-----------------------------------|:---:|:-----------
-\ref ARM_FLASH_EVENT_READY | 0 | Occurs after read/program/erase operation completes.
-\ref ARM_FLASH_EVENT_ERROR | 1 | Occurs together with \ref ARM_FLASH_EVENT_READY when operation completes with errors.
-
-See also:
- - \ref ARM_Flash_EraseChip
-*******************************************************************************************************************/
-
-/**
-@}
-*/
-// End Flash Interface
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/Driver_I2C.c b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/Driver_I2C.c
deleted file mode 100644
index 4e10b20..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/Driver_I2C.c
+++ /dev/null
@@ -1,605 +0,0 @@
-/**
-\defgroup i2c_interface_gr I2C Interface
-\brief Driver API for I2C Bus Peripheral (%Driver_I2C.h)
-\details
-
-I2 C (Inter-Integrated Circuit, referred to as I-squared-C, I-two-C, or IIC) is a multi-master serial single-ended bus and is mostly used
-on single boards, but can also connect to components which are linked via cable.
-
-Most significant features of the I2 C bus include:
- - Only two bus lines are required
- - I2 C is a true multi-master bus. Simple master/slave relationships exist between all components
- - A baud rate is not required; the master device determines a bus clock
- - Each connected device is addressable by a unique address
- - Providing arbitration and collision detection
-
-For more information about I2 C refer to the following web pages:
- - Wikipedia: I2 C
- - www.i2c-bus.org .
-
-Devices can operation in Master or Slave mode:
-
- - To operate in Master mode call the functions \ref ARM_I2C_MasterTransmit or \ref ARM_I2C_MasterReceive. These functions get as argument a slave address .
-
- - To operate in Slave mode set the slave address using the function \ref ARM_I2C_Control. The functions \ref ARM_I2C_SlaveTransmit or \ref ARM_I2C_SlaveReceive are used to transfer data in Slave mode.
-
-I2 C Slave Address
-
-Depending on the device, I2 C supports 7-bit and 10-bit Slaves addresses.
-The element address_10_bit in \ref ARM_I2C_CAPABILITIES indicates that the driver is able to handle 10-bit addresses.
-A 10-bit Slave address is ORed with \ref ARM_I2C_ADDRESS_10BIT.
-
-I2 C also supports a General Call to all Slaves by using the slave address value \token{0}.
-A General Call is recognized by Slaves have a slave address value \ref ARM_I2C_ADDRESS_GC registered with the
-function \ref ARM_I2C_Control.
-
-Block Diagram
-
-The I2C driver allows you to connect low-speed peripherals to a motherboard, embedded system, cellphone, or other electronic device.
-
-\image html I2C_BlockDiagram.png "Master/Slave connected via I2C interface"
-
-
-I2 C API
-
-The following header files define the Application Programming Interface (API) for the I2 C interface:
- - \b %Driver_I2C.h : Driver API for I2C Bus Peripheral
-
-The driver implementation is a typical part of the Device Family Pack (DFP) that supports the
-peripherals of the microcontroller family.
-
-
-Driver Functions
-
-The driver functions are published in the access struct as explained in \ref DriverFunctions
- - \ref ARM_DRIVER_I2C : access struct for I2C driver functions
-
-
-\anchor example Example Code
-
-The following example code shows the usage of the I2 C interface in Master mode.
-
-\include I2C_Demo.c
-
-The following example code shows the usage of the I2 C interface in Slave mode.
-
-\include I2C_SlaveDemo.c
-
-@{
-*/
-
-
-/**
-\struct ARM_DRIVER_I2C
-\details
-The functions of the I2C interface are accessed by function pointers exposed by this structure. Refer to \ref DriverFunctions for
-overview information.
-
-Each instance of an I2C provides such an access structure. The instance is indicated by
-a postfix in the symbol name of the access structure, for example:
- - \b Driver_I2C0 is the name of the access struct of the first instance (no. 0).
- - \b Driver_I2C1 is the name of the access struct of the second instance (no. 1).
-
-
-A configuration setting in the middleware allows connecting the middleware to a specific driver instance %Driver_I2Cn .
-The default is \token{0}, which connects a middleware to the first instance of a driver.
-*******************************************************************************************************************/
-
-/**
-\struct ARM_I2C_CAPABILITIES
-\details
-An I2C driver can be implemented with different capabilities.
-The data fields of this struct encode the capabilities implemented by this driver.
-
-The element \em address_10_bit indicates that the driver is able to handle 10-bit addressing natively.
-User can still emulate the 10-bit addressing in software if the driver does not support it.
-
-Returned by:
- - \ref ARM_I2C_GetCapabilities
-*******************************************************************************************************************/
-
-/**
-\struct ARM_I2C_STATUS
-\details
-Structure with information about the status of the I2C.
-
-The flag \em busy indicates that the driver is busy executing Master/Slave Transmit/Receive operation.
-
-It is set:
- - when Master operation starts: after calling \ref ARM_I2C_MasterTransmit or \ref ARM_I2C_MasterReceive
- - when Slave operation starts: after calling \ref ARM_I2C_SlaveTransmit or \ref ARM_I2C_SlaveReceive and after being addressed by a Master as the Slave
-
-It is cleared when Master/Slave operation has finished.
-
-The flag \em mode indicates the current mode which is Master when Master Transmit/Receive is active or Slave otherwise.
-
-The flag \em direction indicates either Transmitter or Receiver mode. It is updated during Master/Slave operation when the Slave is addressed by a Master.
-
-The flag \em general_call indicates a General call (address \token{0}) when in Slave mode.
-
-The flag \em arbitration_lost indicates that the Master has lost arbitration. The current Master operation is aborted.
-
-The flag \em bus_error indicates that a bus error has been detected. The current Master/Slave operation is aborted.
-
-Returned by:
- - \ref ARM_I2C_GetStatus
-*******************************************************************************************************************/
-
-/**
-\typedef ARM_I2C_SignalEvent_t
-\details
-Provides the typedef for the callback function \ref ARM_I2C_SignalEvent.
-
-Parameter for:
- - \ref ARM_I2C_Initialize
-*******************************************************************************************************************/
-
-/**
-\defgroup I2C_events I2C Events
-\ingroup i2c_interface_gr
-\brief The I2C driver generates call back events that are notified via the function \ref ARM_I2C_SignalEvent.
-\details
-This section provides the event values for the \ref ARM_I2C_SignalEvent callback function.
-
-The following call back notification events are generated:
-@{
-\def ARM_I2C_EVENT_TRANSFER_DONE
-\def ARM_I2C_EVENT_TRANSFER_INCOMPLETE
-\def ARM_I2C_EVENT_SLAVE_TRANSMIT
-\def ARM_I2C_EVENT_SLAVE_RECEIVE
-\def ARM_I2C_EVENT_ADDRESS_NACK
-\def ARM_I2C_EVENT_GENERAL_CALL
-\def ARM_I2C_EVENT_ARBITRATION_LOST
-\def ARM_I2C_EVENT_BUS_ERROR
-\def ARM_I2C_EVENT_BUS_CLEAR
-@}
-*/
-
-
-//
-// Functions
-//
-
-ARM_DRIVER_VERSION ARM_I2C_GetVersion (void) {
- return { 0, 0 };
-};
-/**
-\fn ARM_DRIVER_VERSION ARM_I2C_GetVersion (void)
-\details
-The function \b ARM_I2C_GetVersion returns version information of the driver implementation in \ref ARM_DRIVER_VERSION
- - API version is the version of the CMSIS-Driver specification used to implement this driver.
- - Driver version is source code version of the actual driver implementation.
-
-Example:
-\code
-extern ARM_DRIVER_I2C Driver_I2C0;
-ARM_DRIVER_I2C *drv_info;
-
-void setup_i2c (void) {
- ARM_DRIVER_VERSION version;
-
- drv_info = &Driver_I2C0;
- version = drv_info->GetVersion ();
- if (version.api < 0x10A) { // requires at minimum API version 1.10 or higher
- // error handling
- return;
- }
-}
-\endcode
-*******************************************************************************************************************/
-
-ARM_I2C_CAPABILITIES ARM_I2C_GetCapabilities (void) {
- return { 0 };
-};
-/**
-\fn ARM_I2C_CAPABILITIES ARM_I2C_GetCapabilities (void)
-\details
-The function \b ARM_I2C_GetCapabilities returns information about capabilities of this driver implementation.
-The data fields of the struct \ref ARM_I2C_CAPABILITIES encodes the driver capabilities.
-
-Example:
-\code
-extern ARM_DRIVER_I2C Driver_I2C0;
-ARM_DRIVER_I2C *drv_info;
-
-void read_capabilities (void) {
- ARM_I2C_CAPABILITIES drv_capabilities;
-
- drv_info = &Driver_I2C0;
- drv_capabilities = drv_info->GetCapabilities ();
- // interrogate capabilities
-
-}
-\endcode
-*******************************************************************************************************************/
-
-int32_t ARM_I2C_Initialize (ARM_I2C_SignalEvent_t cb_event) {
- return ARM_DRIVER_OK;
-};
-/**
-\fn int32_t ARM_I2C_Initialize (ARM_I2C_SignalEvent_t cb_event)
-\details
-The function \b ARM_I2C_Initialize initializes the I2C interface.
-It is called when the middleware component starts operation.
-
-The function performs the following operations:
- - Initializes and the I/O resources for the I2C interface.
- - Registers the \ref ARM_I2C_SignalEvent callback function.
-
-The parameter \em cb_event is a pointer to the \ref ARM_I2C_SignalEvent callback function.
-Use a NULL pointer when no callback events are required.
-
-Can be called multiple times. If the peripheral is already initialized the function performs no operation and
-returns with \ref ARM_DRIVER_OK. Refer to \ref CallSequence for more information.
-
-\sa ARM_I2C_PowerControl
-\sa ARM_I2C_Uninitialize
-
-\b Example:
- - refer to \ref example "Example Code"
-
-*******************************************************************************************************************/
-
-int32_t ARM_I2C_Uninitialize (void) {
- return ARM_DRIVER_OK;
-};
-/**
-\fn int32_t ARM_I2C_Uninitialize (void)
-\details
-The function \b ARM_I2C_Uninitialize releases the I/O resources of I2C interface.
-
-It is called when the middleware component stops operation and releases the I/O resources used by the I2C interface.
-Refer to \ref CallSequence for more information.
-
-\sa ARM_I2C_Initialize
-\sa ARM_I2C_PowerControl
-
-*******************************************************************************************************************/
-
-int32_t ARM_I2C_PowerControl (ARM_POWER_STATE state) {
- return ARM_DRIVER_OK;
-};
-/**
-\fn int32_t ARM_I2C_PowerControl (ARM_POWER_STATE state)
-\details
-The function \b ARM_I2C_PowerControl operates the power modes of the I2C interface.
-
-The parameter \em state can have the following values:
- - \ref ARM_POWER_FULL : set-up peripheral for data transfers, enable interrupts (NVIC) and optionally DMA.
- Can be called multiple times. If the peripheral is already in this mode,
- then the function performs no operation and returns with \ref ARM_DRIVER_OK.
- - \ref ARM_POWER_LOW : may use power saving. Returns \ref ARM_DRIVER_ERROR_UNSUPPORTED when not implemented.
- - \ref ARM_POWER_OFF : terminates any pending data transfers, disables peripheral, disables related interrupts and DMA.
-
-Refer to \ref CallSequence for more information.
-
-\sa ARM_I2C_Initialize
-\sa ARM_I2C_Uninitialize
-
-*******************************************************************************************************************/
-
-int32_t ARM_I2C_MasterTransmit (uint32_t addr, const uint8_t *data, uint32_t num, bool xfer_pending) {
- return ARM_DRIVER_OK;
-};
-/**
-\fn int32_t ARM_I2C_MasterTransmit (uint32_t addr, const uint8_t *data, uint32_t num, bool xfer_pending)
-\details
-This function \b ARM_I2C_MasterTransmit transmits data as Master to the selected Slave.
-
-The operation consists of:
- - Master generates START condition
- - Master addresses the Slave as Master Transmitter
- - Master transmits data to the addressed Slave
- - Master generates STOP condition (if \em xfer_pending is "false")
-
-The parameter \em addr is the address of the slave to transmit the data to. The value can be ORed with \ref ARM_I2C_ADDRESS_10BIT to
-identify a 10-bit address value. \n
-The parameter \em data and \em num specify the address of a data buffer and the number of bytes to transmit. \n
-Set the parameter \em xfer_pending to 'true' if another transfer operation follows. With \em xfer_pending set to 'false' a STOP condition is generated.
-
-The function is non-blocking and returns as soon as the driver has started the operation.
-During the operation it is not allowed to call any Master function again. Also the data buffer must stay allocated and the contents of data must not be modified.
-When transmit operation has finished the \ref ARM_I2C_EVENT_TRANSFER_DONE event is generated.
-When not all the data is transferred then the \ref ARM_I2C_EVENT_TRANSFER_INCOMPLETE flag is set at the same time.
-
-Number of data bytes transmitted and acknowledged is returned by the function \ref ARM_I2C_GetDataCount during and after the operation has finished.
-
-The operation is aborted in the following cases (\ref ARM_I2C_EVENT_TRANSFER_DONE event is generated together with):
- - selected slave has not acknowledged the address: \ref ARM_I2C_EVENT_ADDRESS_NACK event
- - arbitration has been lost: \ref ARM_I2C_EVENT_ARBITRATION_LOST event
- - bus error has been detected: \ref ARM_I2C_EVENT_BUS_ERROR event
-
-Status can be monitored by calling the \ref ARM_I2C_GetStatus and checking the flags.
-
-Transmit operation can be aborted also by calling \ref ARM_I2C_Control with the parameter \em control \ref ARM_I2C_ABORT_TRANSFER.
-*******************************************************************************************************************/
-
-int32_t ARM_I2C_MasterReceive (uint32_t addr, uint8_t *data, uint32_t num, bool xfer_pending) {
- return ARM_DRIVER_OK;
-};
-/**
-\fn int32_t ARM_I2C_MasterReceive (uint32_t addr, uint8_t *data, uint32_t num, bool xfer_pending)
-\details
-This function \b ARM_I2C_MasterReceive is used to receive data as Master from the selected Slave.
-
-The operation consists of:
- - Master generates START condition
- - Master addresses the Slave as Master Receiver
- - Master receives data from the addressed Slave
- - Master generates STOP condition (if \em xfer_pending is "false")
-
-The parameter \em addr is the address of the slave to receive the data from. The value can be ORed with \ref ARM_I2C_ADDRESS_10BIT to
-identify a 10-bit address value. \n
-The parameter \em data and \em num specify the address of a data buffer and the number of bytes to receive. \n
-Set the parameter \em xfer_pending to 'true' if another transfer operation follows. With \em xfer_pending set to 'false' a STOP condition is generated.
-
-The function is non-blocking and returns as soon as the driver has started the operation.
-During the operation it is not allowed to call any Master function again. Also the data buffer must stay allocated.
-When receive operation has finished the \ref ARM_I2C_EVENT_TRANSFER_DONE event is generated.
-When not all the data is transferred then the \ref ARM_I2C_EVENT_TRANSFER_INCOMPLETE flag is set at the same time.
-
-Number of data bytes received is returned by the function \ref ARM_I2C_GetDataCount during and after the operation has finished.
-
-The operation is aborted in the following cases (\ref ARM_I2C_EVENT_TRANSFER_DONE event is generated together with):
- - selected slave has not acknowledged the address: \ref ARM_I2C_EVENT_ADDRESS_NACK event
- - arbitration has been lost: \ref ARM_I2C_EVENT_ARBITRATION_LOST event
- - bus error has been detected: \ref ARM_I2C_EVENT_BUS_ERROR event
-
-Status can be monitored by calling the \ref ARM_I2C_GetStatus and checking the flags.
-
-Receive operation can be aborted also by calling \ref ARM_I2C_Control with the parameter \em control = \ref ARM_I2C_ABORT_TRANSFER.
-*******************************************************************************************************************/
-
-int32_t ARM_I2C_SlaveTransmit (const uint8_t *data, uint32_t num) {
- return ARM_DRIVER_OK;
-};
-/**
-\fn int32_t ARM_I2C_SlaveTransmit (const uint8_t *data, uint32_t num)
-\details
-This function \b ARM_I2C_SlaveTransmit is used to transmit data as Slave to the Master.
-
-The parameter \em data is a pointer to the data to transmit. \n
-The parameter \em num specifies the number of bytes to transmit.
-
-The function is non-blocking and returns as soon as the driver has registered the operation.
-The actual operation will start after being addressed by the master as a Slave Transmitter. If the operation has not been registered at that point the \ref ARM_I2C_EVENT_SLAVE_TRANSMIT event is generated.
-The same event is also generated if the operation has finished (specified number of bytes transmitted) but more data is requested by the master.
-
-It is not allowed to call this function again if the operation has started until it finishes. Also the data buffer must stay allocated and the contents of data must not be modified.
-When transmit operation has finished the \ref ARM_I2C_EVENT_TRANSFER_DONE event is generated.
-When not all the data is transferred then the \ref ARM_I2C_EVENT_TRANSFER_INCOMPLETE flag is set at the same time.
-
-Number of data bytes transmitted is returned by the function \ref ARM_I2C_GetDataCount during and after the operation has finished.
-
-In case that a General call has been detected the \ref ARM_I2C_EVENT_GENERAL_CALL flag is indicated together with the \ref ARM_I2C_EVENT_TRANSFER_DONE event (also with \ref ARM_I2C_EVENT_SLAVE_TRANSMIT event).
-
-In case that bus error has been detected then the operation is aborted and the \ref ARM_I2C_EVENT_BUS_ERROR event is generated together with \ref ARM_I2C_EVENT_TRANSFER_DONE.
-
-Slave will only respond to its own address (or General call if enabled) that is specified by calling \ref ARM_I2C_Control with \ref ARM_I2C_OWN_ADDRESS as control parameter.
-Using address \token{0} disables the slave.
-
-Status can be monitored by calling the \ref ARM_I2C_GetStatus and checking the flags.
-
-Transmit operation can be canceled or aborted by calling \ref ARM_I2C_Control with the parameter \em control = \ref ARM_I2C_ABORT_TRANSFER.
-*******************************************************************************************************************/
-
-int32_t ARM_I2C_SlaveReceive (uint8_t *data, uint32_t num) {
- return ARM_DRIVER_OK;
-};
-/**
-\fn int32_t ARM_I2C_SlaveReceive (uint8_t *data, uint32_t num)
-\details
-This function \b ARM_I2C_SlaveReceive receives data as Slave from the Master.
-
-The parameter \em data is a pointer to the data to receive. \n
-The parameter \em num specifies the number of bytes to receive.
-
-The function is non-blocking and returns as soon as the driver has registered the operation.
-The actual operation will start after being addressed by the master as a Slave Receiver. If the operation has not been registered at that point the \ref ARM_I2C_EVENT_SLAVE_RECEIVE event is generated.
-
-It is not allowed to call this function again if the operation has started until it finishes. Also the data buffer must stay allocated.
-When receive operation has finished the \ref ARM_I2C_EVENT_TRANSFER_DONE event is generated.
-When not all the data is transferred then the \ref ARM_I2C_EVENT_TRANSFER_INCOMPLETE flag is set at the same time.
-
-Number of data bytes received and acknowledged is returned by the function \ref ARM_I2C_GetDataCount during and after the operation has finished.
-
-In case that a General call has been detected the \ref ARM_I2C_EVENT_GENERAL_CALL flag is indicated together with the \ref ARM_I2C_EVENT_TRANSFER_DONE event (also with \ref ARM_I2C_EVENT_SLAVE_RECEIVE event).
-
-In case that bus error has been detected then the operation is aborted and the \ref ARM_I2C_EVENT_BUS_ERROR event is generated together with \ref ARM_I2C_EVENT_TRANSFER_DONE.
-
-Slave will only respond to its own address (or General call if enabled) that is specified by calling \ref ARM_I2C_Control with \ref ARM_I2C_OWN_ADDRESS as control parameter.
-Using address \token{0} disables the slave.
-
-Status can be monitored by calling the \ref ARM_I2C_GetStatus and checking the flags.
-
-Receive operation can be canceled or aborted by calling \ref ARM_I2C_Control with the parameter \em control = \ref ARM_I2C_ABORT_TRANSFER.
-*******************************************************************************************************************/
-
-int32_t ARM_I2C_GetDataCount (void) {
- return 0;
-}
-/**
-\fn int32_t ARM_I2C_GetDataCount (void)
-\details
-The function \b ARM_I2C_GetDataCount returns the number of currently transferred data bytes during and after:
- - \ref ARM_I2C_MasterTransmit : number of data bytes transmitted and acknowledged
- - \ref ARM_I2C_MasterReceive : number of data bytes received
- - \ref ARM_I2C_SlaveTransmit : number of data bytes transmitted
- - \ref ARM_I2C_SlaveReceive : number of data bytes received and acknowledged
-
-When the Slave is not yet addressed by the Master then \token{-1} is returned.
-*****************************************************************************************************************/
-
-int32_t ARM_I2C_Control (uint32_t control, uint32_t arg) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_I2C_Control (uint32_t control, uint32_t arg)
-\details
-The function \b ARM_I2C_Control operates the I2C interface and executes various operations.
-
-The parameter \em control specifies various operations as listed in the table below. \n
-The parameter \em arg provides, depending on the operation, additional information. \n
-
-Parameter \em control | Operation
-:--------------------------------|:--------------------------------------------
-\ref ARM_I2C_OWN_ADDRESS | Set Own Slave Address; \em arg = slave address
-\ref ARM_I2C_BUS_SPEED | Set Bus Speed; \em arg = bus speed
-\ref ARM_I2C_BUS_CLEAR | Clear the bus by sending nine clock pulses
-\ref ARM_I2C_ABORT_TRANSFER | Aborts the data transfer between Master and Slave for Transmit or Receive
-
-Set Own Slave Address
-
-After initialization, the I2C Device has no slave address assigned and does not accept any requests from
-an I2C Master.
-
-The \em control operation \ref ARM_I2C_OWN_ADDRESS sets the slave address with the parameter \em arg.
-The slave address can be ORed with \ref ARM_I2C_ADDRESS_10BIT to indicate a 10-bit address.
-
-The slave address can be ORed with \ref ARM_I2C_ADDRESS_GC to indicate that the slave accepts a General Call.
-If the slave address value is only \ref ARM_I2C_ADDRESS_GC, then the slave only accepts a General Call.
-
-The slave address value \token{0} disables Slave mode and clears any assigned slave address.
-
-**Examples:**
-
-Set the Slave address value \token{0x45} as 7-bit address.
-\code
- I2Cdrv->Control (ARM_I2C_OWN_ADDRESS, 0x45);
-\endcode
-
-Set the Slave address value \token{0x135} as 10-bit address and accept a General Call.
-\code
- I2Cdrv->Control (ARM_I2C_OWN_ADDRESS, 0x135 | ARM_I2C_ADDRESS_10BIT | ARM_I2C_ADDRESS_GC);
-\endcode
-
-Bus Speed
-
-The \em control operation \ref ARM_I2C_BUS_SPEED sets the bus speed using the parameter \em arg.
-
-Parameter \em arg | Bus Speed
-:--------------------------------|:--------------------------------------------
-\ref ARM_I2C_BUS_SPEED_STANDARD | Standard Speed to (\token{100 kHz})
-\ref ARM_I2C_BUS_SPEED_FAST | Fast Speed (\token{400kHz})
-\ref ARM_I2C_BUS_SPEED_FAST_PLUS | Fast + Speed (\token{1MHz})
-\ref ARM_I2C_BUS_SPEED_HIGH | High Speed (\token{3.4MHz})
-
-**Example:**
-
-\code
- I2Cdrv->Control (ARM_I2C_BUS_SPEED, I2C_BUS_SPEED_FAST);
-\endcode
-*****************************************************************************************************************/
-
-ARM_I2C_STATUS ARM_I2C_GetStatus (void) {
- return { 0 };
-}
-/**
-\fn ARM_I2C_STATUS ARM_I2C_GetStatus (void)
-\details
-The function \b ARM_I2C_GetStatus returns the current I2C interface status.
-
-Refer to \ref ARM_I2C_STATUS for details.
-*****************************************************************************************************************/
-
-void ARM_I2C_SignalEvent (uint32_t event) {
- // function body
-}
-/**
-\fn void ARM_I2C_SignalEvent (uint32_t event)
-\details
-The function \b ARM_I2C_SignalEvent is a callback function registered by the function \ref ARM_I2C_Initialize..
-It is called by the I2C driver to notify the application about \ref I2C_events occured during operation.
-
-The parameter \a event indicates one or more events that occurred during driver operation.
-Each event is encoded in a separate bit and therefore it is possible to signal multiple events within the same call.
-
-The following events can be generated:
-
-Parameter \em event | Bit | Description
-:---------------------------------------- |:---------:|:----------------------------------------------------------
-\ref ARM_I2C_EVENT_TRANSFER_DONE | 1UL << 0 | Occurs after Master/Slave Transmit/Receive operation has finished.
-\ref ARM_I2C_EVENT_TRANSFER_INCOMPLETE | 1UL << 1 | Occurs together with \ref ARM_I2C_EVENT_TRANSFER_DONE when less data is transferred then requested.
-\ref ARM_I2C_EVENT_SLAVE_TRANSMIT | 1UL << 2 | Occurs when addressed as Slave Transmitter and \ref ARM_I2C_SlaveTransmit has not been started.
-\ref ARM_I2C_EVENT_SLAVE_RECEIVE | 1UL << 3 | Occurs when addressed as Slave Receiver and \ref ARM_I2C_SlaveReceive has not been started.
-\ref ARM_I2C_EVENT_ADDRESS_NACK | 1UL << 4 | Occurs in master mode when address is not acknowledged from slave.
-\ref ARM_I2C_EVENT_GENERAL_CALL | 1UL << 5 | Indicates General Call in slave mode together with \ref ARM_I2C_EVENT_TRANSFER_DONE, \ref ARM_I2C_EVENT_SLAVE_TRANSMIT and \ref ARM_I2C_EVENT_SLAVE_RECEIVE.
-\ref ARM_I2C_EVENT_ARBITRATION_LOST | 1UL << 6 | Occurs in master mode when arbitration is lost.
-\ref ARM_I2C_EVENT_BUS_ERROR | 1UL << 7 | Occurs when bus error is detected.
-\ref ARM_I2C_EVENT_BUS_CLEAR | 1UL << 8 | Occurs after \ref ARM_I2C_BUS_CLEAR Control operation has finished.
-
-**************************************************************************************************************************/
-
-
-/**
-\defgroup i2c_control_gr I2C Control Codes
-\ingroup i2c_interface_gr
-\brief Many parameters of the I2C driver are configured using the \ref ARM_I2C_Control function.
-@{
-\details
-The various I2C control codes define:
- - \ref i2c_control_codes specify operation parameters and various controls
- - \ref i2c_bus_speed_ctrls specify the I2C bus speed
-
-Refer to the \ref ARM_I2C_Control function for further details.
-*/
-
-/**
-\defgroup i2c_control_codes I2C Control Codes
-\ingroup i2c_control_gr
-\brief Specify operation parameters and various controls.
-\details
-@{
-\def ARM_I2C_OWN_ADDRESS
-\sa ARM_I2C_Control
-\def ARM_I2C_BUS_SPEED
-Speed is specified using the following values: \ref i2c_bus_speed_ctrls
-\sa ARM_I2C_Control
-\def ARM_I2C_BUS_CLEAR
-\sa ARM_I2C_Control
-\def ARM_I2C_ABORT_TRANSFER
-\sa ARM_I2C_Control
-@}
-*/
-
-/**
-\defgroup i2c_bus_speed_ctrls I2C Bus Speed
-\ingroup i2c_control_gr
-\brief Specify the I2C bus speed.
-\details
-@{
-\def ARM_I2C_BUS_SPEED_STANDARD
-\sa ARM_I2C_Control
-\def ARM_I2C_BUS_SPEED_FAST
-\sa ARM_I2C_Control
-\def ARM_I2C_BUS_SPEED_FAST_PLUS
-\sa ARM_I2C_Control
-\def ARM_I2C_BUS_SPEED_HIGH
-\sa ARM_I2C_Control
-@}
-*/
-/**
-@}
-*/
-
-/**
-\defgroup i2c_address_flags I2C Address Flags
-\ingroup i2c_interface_gr
-\brief Specify address flags
-\details
-Specifies the address type for the functions \ref ARM_I2C_MasterReceive, \ref ARM_I2C_MasterTransmit and \ref ARM_I2C_OWN_ADDRESS.
-@{
-\def ARM_I2C_ADDRESS_10BIT
-\sa ARM_I2C_OWN_ADDRESS
-\sa ARM_I2C_MasterTransmit
-\sa ARM_I2C_MasterReceive
-\def ARM_I2C_ADDRESS_GC
-\sa ARM_I2C_OWN_ADDRESS
-@}
-*/
-
-
-/**
-@}
-*/
-// End I2C Interface
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/Driver_MCI.c b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/Driver_MCI.c
deleted file mode 100644
index 332636b..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/Driver_MCI.c
+++ /dev/null
@@ -1,799 +0,0 @@
-/**
-\defgroup mci_interface_gr MCI Interface
-\brief Driver API for Memory Card Interface using SD/MMC interface (%Driver_MCI.h)
-
-\details
-The Memory Card Interface (MCI) implements the hardware abstraction layer for Secure Digital (SD) and Multi Media Card (MMC)
-memory that is typically used as file storage. For embedded systems, SD/MMC devices are available as memory cards in several
-forms (SD, miniSD, microSD, MMC, MMCmicro) or as non-removable device
-es that are directly soldered to the PCB (eMMC).
-
-\b References:
-- Wikipedia offers more information about the Secure Digital memoryMultiMediaCard www.sdcard.org .
-- The MultiMediaCard Association (merged with JEDEC) provides detailed documentation under www.jedec.org .
-
-Block Diagram
-
-The MCI driver allows you to exchange data of the SD/MMC memory via SD/MMC interface.
-
-The following modes are supported by SD/MMC memory cards:
-
-- SPI bus mode: Serial Peripheral Interface Bus supported by most microcontrollers.
-- 1-bit SD/MMC Bus mode: proprietary data transfer protocol supported by SD/MMC interfaces.
-- 4-bit SD/MMC Bus mode: high-speed version of the SD/MMC interface using 4 data I/O pins.
-- 8-bit SD/MMC Bus mode: high-speed version of the SD/MMC interface using 8 data I/O pins.
-
-\image html SPI_BusMode.png "SD memory connected via SPI interface"
-
-\image html SD_1BitBusMode.png "SD memory connected via 1-bit SD Bus Mode"
-
-\image html SD_4BitBusMode.png "SD memory connected via 4-bit SD Bus Mode"
-
-
-MCI API
-
-The following header files define the Application Programming Interface (API) for the MCI interface:
- - \b %Driver_MCI.h : Driver API for Memory Card Interface using SD/MMC interface
-
-The driver implementation is a typical part of the Device Family Pack (DFP) that supports the
-peripherals of the microcontroller family.
-
-\note
-For parameters, the value marked with (default) is the setting after the driver initialization.
-
-
-Driver Functions
-
-The driver functions are published in the access struct as explained in \ref DriverFunctions
- - \ref ARM_DRIVER_MCI : access struct for MCI driver functions
-
-
-Example Code
-
-The following example code shows the usage of the MCI interface.
-
-\include MCI_Demo.c
-
-@{
-*/
-
-
-/************* Structures ******************************************************************************************************/
-/**
-\struct ARM_DRIVER_MCI
-\details
-The functions of the MCI are accessed by function pointers exposed by this structure. Refer to \ref DriverFunctions for overview information.
-
-Each instance of an MCI provides such an access structure.
-The instance is identified by a postfix number in the symbol name of the access structure, for example:
- - \b Driver_MCI0 is the name of the access struct of the first instance (no. 0).
- - \b Driver_MCI1 is the name of the access struct of the second instance (no. 1).
-
-A configuration setting in the middleware allows connecting the middleware to a specific driver instance Driver_MCIn .
-The default is \token{0}, which connects a middleware to the first instance of a driver.
-*******************************************************************************************************************/
-
-/**
-\struct ARM_MCI_CAPABILITIES
-\details
-A MCI driver can be implemented with different capabilities.
-The data fields of this struct encode the capabilities implemented by this driver.
-
-Returned by:
- - \ref ARM_MCI_GetCapabilities
-*******************************************************************************************************************/
-
-/**
-\defgroup mci_event_gr MCI Events
-\brief The MCI driver generates call back events that are notified via the function \ref ARM_MCI_SignalEvent.
-\details
-This section provides the event values for the \ref ARM_MCI_SignalEvent callback function.
-
-The following call back notification events are generated:
-@{
-\def ARM_MCI_EVENT_CARD_INSERTED
-\sa \ref ARM_MCI_SignalEvent
-\def ARM_MCI_EVENT_CARD_REMOVED
-\sa \ref ARM_MCI_SignalEvent
-\def ARM_MCI_EVENT_COMMAND_COMPLETE
-\sa \ref ARM_MCI_SignalEvent
-\def ARM_MCI_EVENT_COMMAND_TIMEOUT
-\sa \ref ARM_MCI_SignalEvent
-\def ARM_MCI_EVENT_COMMAND_ERROR
-\sa \ref ARM_MCI_SignalEvent
-\def ARM_MCI_EVENT_TRANSFER_COMPLETE
-\sa \ref ARM_MCI_SignalEvent
-\def ARM_MCI_EVENT_TRANSFER_TIMEOUT
-\sa \ref ARM_MCI_SignalEvent
-\def ARM_MCI_EVENT_TRANSFER_ERROR
-\sa \ref ARM_MCI_SignalEvent
-\def ARM_MCI_EVENT_SDIO_INTERRUPT
-\sa \ref ARM_MCI_SignalEvent
-\def ARM_MCI_EVENT_CCS
-\sa \ref ARM_MCI_SignalEvent
-\def ARM_MCI_EVENT_CCS_TIMEOUT
-\sa \ref ARM_MCI_SignalEvent
-@}
-*******************************************************************************************************************/
-
-//open mci_contorl_gr
-/**
-@{
-*/
-/**
-\defgroup mci_control_gr MCI Control Codes
-\ingroup mci_interface_gr
-\brief Configure and control the MCI using the \ref ARM_MCI_Control.
-\details
-@{
-Many parameters of the MCI driver are configured using the \ref ARM_MCI_Control function.
-
-The various MCI control codes define:
- - \ref mci_mode_ctrls configures and controls the MCI interface
- - \ref mci_bus_speed_ctrls specifies the bus speed mode
- - \ref mci_bus_data_width_ctrls specifies the data bus width
- - \ref mci_cmd_line_ctrls specifies the CMD line mode
- - \ref mci_driver_strength_ctrls specifies the driver strength
-
-Refer to the function \ref ARM_MCI_Control for further details.
-@}
-*******************************************************************************************************************/
-
-
-/**
-\defgroup mci_mode_ctrls MCI Controls
-\ingroup mci_control_gr
-\brief Configure and control the MCI interface.
-\details
-The following codes are used as values for the parameter \em control of the function \ref ARM_MCI_Control to setup the MCI interface.
-@{
-\def ARM_MCI_BUS_SPEED
-\def ARM_MCI_BUS_SPEED_MODE
-\def ARM_MCI_BUS_CMD_MODE
-\def ARM_MCI_BUS_DATA_WIDTH
-\def ARM_MCI_DRIVER_STRENGTH
-\def ARM_MCI_CONTROL_RESET
-\def ARM_MCI_CONTROL_CLOCK_IDLE
-\def ARM_MCI_UHS_TUNING_OPERATION
-\def ARM_MCI_UHS_TUNING_RESULT
-\def ARM_MCI_DATA_TIMEOUT
-\def ARM_MCI_CSS_TIMEOUT
-\def ARM_MCI_MONITOR_SDIO_INTERRUPT
-\def ARM_MCI_CONTROL_READ_WAIT
-\def ARM_MCI_SUSPEND_TRANSFER
-\def ARM_MCI_RESUME_TRANSFER
-@}
-*******************************************************************************************************************/
-
-
-/**
-\defgroup mci_bus_speed_ctrls MCI Bus Speed Mode
-\ingroup mci_control_gr
-\brief Specify the bus speed mode.
-\details
-@{
-The function \ref ARM_MCI_Control with \em control = \ref ARM_MCI_BUS_SPEED configures the bus speed of the MCI to the
-requested bits/s specified with \em arg.
-
-The function \ref ARM_MCI_Control with \em control = \ref ARM_MCI_BUS_SPEED_MODE configures the bus speed mode of the MCI
-as specified with \em arg listed bellow.
-
-The function \ref ARM_MCI_GetCapabilities lists the supported bus speed modes. Initially, all SD cards use a 3.3 volt electrical interface.
-Some SD cards can switch to 1.8 volt operation. For example, the use of ultra-high-speed (UHS)
-SD cards requires 1.8 volt operation and a 4-bit bus data width. The data field \em uhs_signaling of the structure ARM_MCI_CAPABILITIES encodes
-whether the driver supports 1.8 volt UHS signaling.
-
-\sa
- - \ref mci_driver_strength_ctrls
-
-The following codes are defined:
-
-\def ARM_MCI_BUS_DEFAULT_SPEED
-\def ARM_MCI_BUS_HIGH_SPEED
-\def ARM_MCI_BUS_UHS_SDR12
-\def ARM_MCI_BUS_UHS_SDR25
-\def ARM_MCI_BUS_UHS_SDR50
-\def ARM_MCI_BUS_UHS_SDR104
-\def ARM_MCI_BUS_UHS_DDR50
-@}
-*******************************************************************************************************************/
-
-
-/**
-\defgroup mci_bus_data_width_ctrls MCI Bus Data Width
-\ingroup mci_control_gr
-\brief Specify the data bus width.
-\details
-@{
-The function \ref ARM_MCI_Control with \em control = \ref ARM_MCI_BUS_DATA_WIDTH specifies with \em arg the number of data I/O pins on the SD/MMC interface.
-
-For high-speed memory cards, a 4-bit bus data width should be used (or 8-bit for eMMC). The data fields \em data_width_4 and \em data_width_8
-of the structure ARM_MCI_CAPABILITIES encode whether the driver supports a specific bus data with.
-
-The following codes are defined:
-
-\def ARM_MCI_BUS_DATA_WIDTH_1
-\def ARM_MCI_BUS_DATA_WIDTH_4
-\def ARM_MCI_BUS_DATA_WIDTH_8
-\def ARM_MCI_BUS_DATA_WIDTH_4_DDR
-\def ARM_MCI_BUS_DATA_WIDTH_8_DDR
-@}
-*******************************************************************************************************************/
-
-
-/**
-\defgroup mci_cmd_line_ctrls MCI CMD Line Mode
-\ingroup mci_control_gr
-\brief Specify the CMD line mode (Push-Pull or Open Drain).
-\details
-@{
-Set the CMD line type with the function \ref ARM_MCI_Control.
-The CMD line mode is push-pull (default) or open drain (needed for older MMC).
-
-\def ARM_MCI_BUS_CMD_PUSH_PULL
-\def ARM_MCI_BUS_CMD_OPEN_DRAIN
-@}
-*******************************************************************************************************************/
-
-
-/**
-\defgroup mci_driver_strength_ctrls MCI Driver Strength
-\ingroup mci_control_gr
-\brief Specify the driver strength.
-\details
-@{
-The function \ref ARM_MCI_Control with \em control = \ref ARM_MCI_DRIVER_STRENGTH specifies with \em arg the driver type of the SD interface.
-
-\sa
- - \ref mci_bus_speed_ctrls
-
-The following codes are defined:
-
-\def ARM_MCI_DRIVER_TYPE_A
-\def ARM_MCI_DRIVER_TYPE_B
-\def ARM_MCI_DRIVER_TYPE_C
-\def ARM_MCI_DRIVER_TYPE_D
-@}
-*******************************************************************************************************************/
-
-/**
-@}
-*/ // close group mci_control_gr
-
-/**
-\defgroup mci_send_command_flags_ctrls MCI Send Command Flags
-\ingroup mci_interface_gr
-\brief Specify various options for sending commands to the card and the expected response.
-\details
-\b ARM_MCI_xxx flags are sent with the function \ref ARM_MCI_SendCommand as the parameter \em flag.
-It controls the behavior of the command sent to the card and provides information about the expected response from the card.
-
-The following codes are defined:
-@{
-\def ARM_MCI_RESPONSE_NONE
-\def ARM_MCI_RESPONSE_SHORT
-\def ARM_MCI_RESPONSE_SHORT_BUSY
-\def ARM_MCI_RESPONSE_LONG
-\def ARM_MCI_RESPONSE_INDEX
-\def ARM_MCI_RESPONSE_CRC
-\def ARM_MCI_WAIT_BUSY
-\def ARM_MCI_TRANSFER_DATA
-\def ARM_MCI_CARD_INITIALIZE
-\def ARM_MCI_INTERRUPT_COMMAND
-\def ARM_MCI_INTERRUPT_RESPONSE
-\def ARM_MCI_BOOT_OPERATION
-\def ARM_MCI_BOOT_ALTERNATIVE
-\def ARM_MCI_BOOT_ACK
-\def ARM_MCI_CCSD
-\def ARM_MCI_CCS
-@}
-*******************************************************************************************************************/
-
-/**
-\defgroup mci_transfer_ctrls MCI Transfer Controls
-\ingroup mci_interface_gr
-\brief Specify data transfer mode.
-\details
-Data transfer codes specifies the transfer direction and type and are used with the function \ref ARM_MCI_SetupTransfer as the parameter \em mode.
-
-The following codes are defined:
-@{
-\def ARM_MCI_TRANSFER_READ
-\def ARM_MCI_TRANSFER_WRITE
-\def ARM_MCI_TRANSFER_BLOCK
-\def ARM_MCI_TRANSFER_STREAM
-@}
-*******************************************************************************************************************/
-
-/**
-\defgroup mci_card_power_ctrls MCI Card Power Controls
-\ingroup mci_interface_gr
-\brief Specify Memory Card Power supply voltage
-\details
-Specifies the power supply volatge for a memory card. Used with the function \ref ARM_MCI_CardPower as the parameter \em voltage.
-
-The following codes are defined:
-@{
-\def ARM_MCI_POWER_VDD_OFF
-\def ARM_MCI_POWER_VDD_3V3
-\def ARM_MCI_POWER_VDD_1V8
-\def ARM_MCI_POWER_VCCQ_OFF
-\def ARM_MCI_POWER_VCCQ_3V3
-\def ARM_MCI_POWER_VCCQ_1V8
-\def ARM_MCI_POWER_VCCQ_1V2
-@}
-*******************************************************************************************************************/
-
-
-/**
-\struct ARM_MCI_STATUS
-\details
-Structure with information about the status of the MCI.
-
-Returned by:
- - \ref ARM_MCI_GetStatus
-*******************************************************************************************************************/
-
-/**
-\typedef ARM_MCI_SignalEvent_t
-\details
-Provides the typedef for the callback function \ref ARM_MCI_SignalEvent.
-
-Parameter for:
- - \ref ARM_MCI_Initialize
-*******************************************************************************************************************/
-
-
-//
-// Functions
-//
-ARM_DRIVER_VERSION ARM_MCI_GetVersion (void) {
- return { 0, 0 };
-}
-/**
-\fn ARM_DRIVER_VERSION ARM_MCI_GetVersion (void)
-\details
-The function \b ARM_MCI_GetVersion returns version information of the driver implementation in \ref ARM_DRIVER_VERSION
- - API version is the version of the CMSIS-Driver specification used to implement this driver.
- - Driver version is source code version of the actual driver implementation.
-
-Example:
-\code
-extern ARM_DRIVER_MCI Driver_MCI0;
-ARM_DRIVER_MCI *drv_info;
-
-void setup_mci (void) {
- ARM_DRIVER_VERSION version;
-
- drv_info = &Driver_MCI0;
- version = drv_info->GetVersion ();
- if (version.api < 0x10A) { // requires at minimum API version 1.10 or higher
- // error handling
- return;
- }
-}
-\endcode
-*******************************************************************************************************************/
-
-ARM_MCI_CAPABILITIES ARM_MCI_GetCapabilities (void) {
- return { 0 };
-}
-/**
-\fn ARM_MCI_CAPABILITIES ARM_MCI_GetCapabilities (void)
-\details
-The function \b ARM_MCI_GetCapabilities returns information about capabilities in this driver implementation.
-The data fields of the structure \ref ARM_MCI_CAPABILITIES encode various capabilities, for example
-supported bus modes ...
-
-Example:
-\code
-extern ARM_DRIVER_MCI Driver_MCI0;
-ARM_DRIVER_MCI *drv_info;
-
-void read_capabilities (void) {
- ARM_MCI_CAPABILITIES drv_capabilities;
-
- drv_info = &Driver_MCI0;
- drv_capabilities = drv_info->GetCapabilities ();
- // interrogate capabilities
-
-}
-\endcode
-*******************************************************************************************************************/
-
-int32_t ARM_MCI_Initialize (ARM_MCI_SignalEvent_t cb_event) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_MCI_Initialize (ARM_MCI_SignalEvent_t cb_event)
-\details
-The function \b ARM_MCI_Initialize initializes the MCI interface.
-It is called when the middleware component starts operation.
-
-The function performs the following operations:
- - Initializes the resources needed for the MCI interface.
- - Registers the \ref ARM_MCI_SignalEvent callback function.
-
-The parameter \em cb_event is a pointer to the \ref ARM_MCI_SignalEvent callback function; use a NULL pointer
-when no callback signals are required.
-
-\b Example:
- - see \ref mci_interface_gr - Driver Functions
-
-*******************************************************************************************************************/
-
-int32_t ARM_MCI_Uninitialize (void) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_MCI_Uninitialize (void)
-\details
-The function \b ARM_MCI_Uninitialize de-initializes the resources of I2C interface.
-
-It is called when the middleware component stops operation and releases the software resources used by the interface.
-*******************************************************************************************************************/
-
-int32_t ARM_MCI_PowerControl (ARM_POWER_STATE state) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_MCI_PowerControl (ARM_POWER_STATE state)
-\details
-The function \b ARM_MCI_PowerControl operates the power modes of the MCI interface.
-
-The parameter \em state can have the following values:
- - \ref ARM_POWER_FULL : set-up peripheral for data transfers, enable interrupts (NVIC) and optionally DMA. Can be called multiple times.
- If the peripheral is already in this mode, then the function performs no operation and returns with \ref ARM_DRIVER_OK.
- - \ref ARM_POWER_LOW : may use power saving. Returns \ref ARM_DRIVER_ERROR_UNSUPPORTED when not implemented.
- - \ref ARM_POWER_OFF : terminates any pending data transfers, disables peripheral, disables related interrupts and DMA.
-
-Refer to \ref CallSequence for more information.
-*******************************************************************************************************************/
-
-int32_t ARM_MCI_CardPower (uint32_t voltage) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_MCI_CardPower (uint32_t voltage)
-\details
-The function \b ARM_MCI_CardPower operates the memory card power supply voltage.
-
-The parameter \em voltage sets the voltage. Not every voltage might be supported by the driver implementation.
-The structure \ref ARM_MCI_CAPABILITIES encodes the supported voltage. Retrieve the information with the function \ref ARM_MCI_GetCapabilities and
-verify the data fields.
-
-The following values:
-
-Parameter \em voltage | Description | supported when ARM_MCI_CAPABILITIES
-:-------------------------------------|:------------------------------|-----------------------------------------
-\ref ARM_MCI_POWER_VDD_OFF | VDD (VCC) turned off | always supported
-\ref ARM_MCI_POWER_VDD_3V3 | VDD (VCC) = \token{3.3V} | data field \em vdd = \token{1}
-\ref ARM_MCI_POWER_VDD_1V8 | VDD (VCC) = \token{1.8V} | data field \em vdd_1v8 = \token{1}
-\ref ARM_MCI_POWER_VCCQ_OFF | eMMC VCCQ turned off | always supported
-\ref ARM_MCI_POWER_VCCQ_3V3 | eMMC VCCQ = \token{3.3V} | data field \em vccq = \token{1}
-\ref ARM_MCI_POWER_VCCQ_1V8 | eMMC VCCQ = \token{1.8V} | data field \em vccq_1v8 = \token{1}
-\ref ARM_MCI_POWER_VCCQ_1V2 | eMMC VCCQ = \token{1.2V} | data field \em vccq_1v2 = \token{1}
-
-*******************************************************************************************************************/
-
-int32_t ARM_MCI_ReadCD (void) {
- return 0;
-}
-/**
-\fn int32_t ARM_MCI_ReadCD (void)
-\details
-The function \b ARM_MCI_ReadCD reads the status of the Card Detect (CD) pin.
-*******************************************************************************************************************/
-
-int32_t ARM_MCI_ReadWP (void) {
- return 0;
-}
-/**
-\fn int32_t ARM_MCI_ReadWP (void)
-\details
-The function \b ARM_MCI_ReadWP reads the status of the Write Protect (WP) pin.
-*******************************************************************************************************************/
-
-int32_t ARM_MCI_SendCommand (uint32_t cmd, uint32_t arg, uint32_t flags, uint32_t *response) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_MCI_SendCommand (uint32_t cmd, uint32_t arg, uint32_t flags, uint32_t *response)
-\details
-The function \b ARM_MCI_SendCommand
- - sends commands to the memory card
- - retrieve the response from the card
- - optionally, start the data transfer.
-
-The parameter \em cmd is the command sent to the card. \n
-The parameter \em arg contains arguments for the command \em cmd. \n
-The parameter \em flags controls the behavior of the operation and takes predefined values listed in the table below. \n
-The parameter \em response is a pointer to receive data.
-
-The parameter \em flags can have the following values:
-
-Parameter \em flags | Description
-:-------------------------------------|:------------
-\ref ARM_MCI_RESPONSE_NONE | No response expected (default)
-\ref ARM_MCI_RESPONSE_SHORT | Short response (\token{48}-bit) expected
-\ref ARM_MCI_RESPONSE_SHORT_BUSY | Short response with busy signal (\token{48}-bit) expected
-\ref ARM_MCI_RESPONSE_LONG | Long response (\token{136}-bit) expected
-\ref ARM_MCI_RESPONSE_INDEX | Check command index in response
-\ref ARM_MCI_RESPONSE_CRC | Check CRC in response
-\ref ARM_MCI_WAIT_BUSY | Wait until busy before sending the command
-\ref ARM_MCI_TRANSFER_DATA | Activate Data transfer
-\ref ARM_MCI_CARD_INITIALIZE | Execute Memory Card initialization sequence
-\ref ARM_MCI_INTERRUPT_COMMAND | Send Interrupt command (CMD40 - MMC only)
-\ref ARM_MCI_INTERRUPT_RESPONSE | Send Interrupt response (CMD40 - MMC only)
-\ref ARM_MCI_BOOT_OPERATION | Execute Boot operation (MMC only)
-\ref ARM_MCI_BOOT_ALTERNATIVE | Execute Alternative Boot operation (MMC only)
-\ref ARM_MCI_BOOT_ACK | Expect Boot Acknowledge (MMC only)
-\ref ARM_MCI_CCSD | Send Command Completion Signal Disable (CCSD) for CE-ATA device
-\ref ARM_MCI_CCS | Expect Command Completion Signal (CCS) for CE-ATA device
-
-Calling the function ARM_MCI_SendCommand only starts the operation.
-The function is non-blocking and returns as soon as the driver has started the operation.
-It is not allowed to call this function again until the operation is in progress.
-
-After the command is sent the response is retrieved if specified with ARM_MCI_RESPONSE_xxx flags.
-When the command completes successfully (requested response is received without errors) the \ref ARM_MCI_EVENT_COMMAND_COMPLETE event is generated.
-In case that response is requested but not received the \ref ARM_MCI_EVENT_COMMAND_TIMEOUT event is generated instead.
-In case of invalid response (or CRC error) the \ref ARM_MCI_EVENT_COMMAND_ERROR event is generated instead.
-Progress of command operation can be monitored by calling the \ref ARM_MCI_GetStatus and checking the \em command_active flag.
-
-After the command operation the data transfer operation is started if specified with ARM_MCI_TRANSFER_DATA flag.
-The data transfer needs to be configured before that by calling the \ref ARM_MCI_SetupTransfer.
-When the data transfer completes successfully the \ref ARM_MCI_EVENT_TRANSFER_COMPLETE event is generated.
-In case that data transfer is not completed in-time (specified by \ref ARM_MCI_DATA_TIMEOUT) the \ref ARM_MCI_EVENT_TRANSFER_TIMEOUT event is generated instead.
-In case of CRC errors the \ref ARM_MCI_EVENT_TRANSFER_ERROR event is generated instead.
-Progress of data transfer operation can be monitored by calling the \ref ARM_MCI_GetStatus and checking the \em transfer_active flag.
-
-See also:
- - \ref ARM_MCI_SignalEvent
-*******************************************************************************************************************/
-
-int32_t ARM_MCI_SetupTransfer (uint8_t *data, uint32_t block_count, uint32_t block_size, uint32_t mode) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_MCI_SetupTransfer (uint8_t *data, uint32_t block_count, uint32_t block_size, uint32_t mode)
-\details
-The function \b ARM_MCI_SetupTransfer prepares the data transfer operation that is initiated
-by calling the function \ref ARM_MCI_SendCommand with the parameter \em flags = \ref ARM_MCI_TRANSFER_DATA.
-
-The parameter \em data is a pointer to the data to transfer. \n
-The parameter \em block_count is the number of blocks to transfer. \n
-The parameter \em block_size is the size of a block. \n
-The parameter \em mode sets the transfer mode and can have the values liste in the table below:
-
-Transfer Directions | Description
-:-------------------------------------|:------------
-\ref ARM_MCI_TRANSFER_READ | Read data from MCI
-\ref ARM_MCI_TRANSFER_WRITE | Write data to MCI
-\ref ARM_MCI_TRANSFER_BLOCK (default) | Block Data transfer
-\ref ARM_MCI_TRANSFER_STREAM | Stream Data transfer (MMC only)
-
-*******************************************************************************************************************/
-
-int32_t ARM_MCI_AbortTransfer (void) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_MCI_AbortTransfer (void)
-\details
-The function \b ARM_MCI_AbortTransfer aborts the active data transfer operation initiated with \ref ARM_MCI_SendCommand.
-*******************************************************************************************************************/
-
-
-int32_t ARM_MCI_Control (uint32_t control, uint32_t arg) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_MCI_Control (uint32_t control, uint32_t arg)
-\details
-Th function \b ARM_MCI_Control controls the MCI interface and executes various operations.
-
-The parameter \em control specifies the operation.
-Values for \em control cannot be ORed, but must be called separately in the code. \n
-The parameter \em arg provides, depending on the operation, additional information or sets values.
-
-\note
-For parameters, the values marked with (default) are the setting after the driver initialization.
-
-The table lists values for the parameter \em control.
-
-Parameter \em control | Operation
-:-------------------------------------|:------------
-\ref ARM_MCI_BUS_SPEED | Set the Bus Speed. The parameter \em arg specifies the speed in bits/s; The function returns the bus speed configured in bits/s.
-\ref ARM_MCI_BUS_SPEED_MODE | Set the Bus Speed Mode. Predefined values for \em arg are listed in the table Bus Speed Mode .
-\ref ARM_MCI_BUS_CMD_MODE | Set the CMD Line Mode. Predefined values for \em arg are listed in the table Bus CMD Line Mode .
-\ref ARM_MCI_BUS_DATA_WIDTH | Set data bus width. Predefined values for \em arg are encoded in Bus Data Width .
-\ref ARM_MCI_DRIVER_STRENGTH | Set driver strength. Predefined values for \em arg are listed in the table Driver Type
-\ref ARM_MCI_CONTROL_RESET | Control optional RST_n Pin (eMMC). The parameter \em arg can have the values \token{[0:inactive(default); 1:active]}
-\ref ARM_MCI_CONTROL_CLOCK_IDLE | Control clock generation on CLK Pin when idle. The parameter \em arg can have the values \token{[0:disabled; 1:enabled]}
-\ref ARM_MCI_UHS_TUNING_OPERATION | Sampling clock Tuning operation (SD UHS-I). The parameter \em arg can have the values \token{[0:reset; 1:execute]}
-\ref ARM_MCI_UHS_TUNING_RESULT | Sampling clock Tuning result (SD UHS-I). Returns \token{[0:done; 1:in progress; -1:error]}
-\ref ARM_MCI_DATA_TIMEOUT | Set Data timeout; The parameter \em arg sets the timeout in bus cycles.
-\ref ARM_MCI_CSS_TIMEOUT | Set Command Completion Signal (CCS) timeout. The parameter \em arg sets timeout in bus cycles.
-\ref ARM_MCI_MONITOR_SDIO_INTERRUPT | Monitor SD I/O interrupt. The parameter \em arg can have the values \token{[0:disabled(default); 1:enabled]}. Monitoring is automatically disabled when an interrupt is recognized.
-\ref ARM_MCI_CONTROL_READ_WAIT | Control Read/Wait states for SD I/O. The parameter \em arg can have the values \token{[0:disabled(default); 1:enabled]}.
-\ref ARM_MCI_SUSPEND_TRANSFER | Suspend Data transfer (SD I/O). Returns the number of remaining bytes to transfer.
-\ref ARM_MCI_RESUME_TRANSFER | Resume Data transfer (SD I/O).
-
-
-Bus Speed Mode
-
-The function \ref ARM_MCI_GetCapabilities lists the supported bus speed modes. Initially, all SD cards use a 3.3 volt electrical interface.
-Some SD cards can switch to 1.8 volt operation. For example, the use of ultra-high-speed (UHS)
-SD cards requires 1.8 volt operation and a 4-bit bus data width. The bit field ARM_MCI_CAPABILITIES.uhs_signaling encodes
-whether the driver supports 1.8 volt UHS signaling.
-
-The \em control operation \b ARM_MCI_BUS_SPEED_MODE sets the bus speed mode using the parameter \em arg.
-
-Parameter \em arg | Bus Speed Mode
-:-------------------------------------------------------------|:------------------------------------------
-\ref ARM_MCI_BUS_DEFAULT_SPEED (default) | Set the bus speed for SD/MMC cards: Default Speed mode up to \token{[25;26]MHz}
-\ref ARM_MCI_BUS_HIGH_SPEED | Set the bus speed for SD/MMC: High Speed mode up to \token{[50;52]MHz}
-\ref ARM_MCI_BUS_UHS_SDR12 | Set the bus speed for SD: SDR12 (Single Data Rate) up to \token{25MHz, 12.5MB/s: UHS-I (Ultra High Speed) 1.8V signalling}
-\ref ARM_MCI_BUS_UHS_SDR25 | Set the bus speed for SD: SDR25 (Single Data Rate) up to \token{50MHz, 25 MB/s: UHS-I (Ultra High Speed) 1.8V signalling}
-\ref ARM_MCI_BUS_UHS_SDR50 | Set the bus speed for SD: SDR50 (Single Data Rate) up to \token{100MHz, 50 MB/s: UHS-I (Ultra High Speed) 1.8V signalling}
-\ref ARM_MCI_BUS_UHS_SDR104 | Set the bus speed for SD: SDR104 (Single Data Rate) up to \token{208MHz, 104 MB/s: UHS-I (Ultra High Speed) 1.8V signalling}
-\ref ARM_MCI_BUS_UHS_DDR50 | Set the bus speed for SD: DDR50 (Dual Data Rate) up to \token{50MHz, 50 MB/s: UHS-I (Ultra High Speed) 1.8V signalling}
-
-
-Bus CMD Line Mode
-
-The \em control operation \b ARM_MCI_BUS_CMD_MODE sets the bus command line mode using the parameter \em arg.
-
-Parameter \em arg | Bus CMD Line Mode
-:-------------------------------------------------------------|:------------------------------------------
-\ref ARM_MCI_BUS_CMD_PUSH_PULL (default) | Set the Push-Pull CMD line
-\ref ARM_MCI_BUS_CMD_OPEN_DRAIN | Set the Open Drain CMD line (MMC only)
-
-
-Bus Data Width
-
-Specifies the bus data width (the number of data I/O pins on the SD/MMC interface).
-
-For high speed memory cards, a 4-bit bus data width should be used (or 8-bit for eMMC). The bit fields ARM_MCI_CAPABILITIES.data_width_4 and
-ARM_MCI_CAPABILITIES.data_width_8 encode whether the driver supports a specific bus data with.
-
-The \em control operation \b ARM_MCI_BUS_DATA_WIDTH sets the bus data width using the parameter \em arg.
-
-Parameter \em arg | Bus Data Width
-:-------------------------------------------------------------|:------------------------------------------
-\ref ARM_MCI_BUS_DATA_WIDTH_1 (default) | Set the Bus data width to \token{1 bit}
-\ref ARM_MCI_BUS_DATA_WIDTH_4 | Set the Bus data width to \token{4 bits}
-\ref ARM_MCI_BUS_DATA_WIDTH_8 | Set the Bus data width to \token{8 bits}
-\ref ARM_MCI_BUS_DATA_WIDTH_4_DDR | Set the Bus data width to \token{4 bits}, DDR (Dual Data Rate) - MMC only
-\ref ARM_MCI_BUS_DATA_WIDTH_8_DDR | Set the Bus data width to \token{8 bits}, DDR (Dual Data Rate) - MMC only
-
-
-Driver Type
-
-Specifies the interface driver type.
-
-The \em control operation \b ARM_MCI_DRIVER_STRENGTH sets the interface driver type using the parameter \em arg.
-
-Parameter \em arg | Driver Type
-:-------------------------------------------------------------|:------------------------------------------
-\ref ARM_MCI_DRIVER_TYPE_A | Set the interface to SD UHS-I Driver Type A
-\ref ARM_MCI_DRIVER_TYPE_B (default) | Set the interface to SD UHS-I Driver Type B
-\ref ARM_MCI_DRIVER_TYPE_C | Set the interface to SD UHS-I Driver Type C
-\ref ARM_MCI_DRIVER_TYPE_D | Set the interface to SD UHS-I Driver Type D
-
-\b Examples:
-\code
-// Set Bus Speed to 25MHz
-MCIdrv->Control(ARM_MCI_BUS_SPEED, 25000000);
-
-// Set High Speed mode
-MCIdrv->Control(ARM_MCI_BUS_SPEED_MODE, ARM_MCI_BUS_HIGH_SPEED);
-
-// Configure CMD line as Open Drain (MMC only)
-MCIdrv->Control(ARM_MCI_BUS_CMD_MODE, ARM_MCI_BUS_CMD_OPEN_DRAIN);
-
-// Set Bus Data Width = 4bits
-MCIdrv->Control(ARM_MCI_BUS_DATA_WIDTH, ARM_MCI_BUS_DATA_WIDTH_4);
-
-// Set SD UHS-I Driver Type B
-MCIdrv->Control(ARM_MCI_DRIVER_STRENGTH, ARM_MCI_DRIVER_TYPE_B);
-
-// RTS_n Pin is not active by default
-// Assert RTS_n Pin (eMMC)
-MCIdrv->Control(ARM_MCI_CONTROL_RESET, 1);
-// De-assert RTS_n Pin (eMMC)
-MCIdrv->Control(ARM_MCI_CONTROL_RESET, 0);
-
-// Clock generation on CLK when Idle: hardware specific default behavior
-// Enable Clock generation on CLK when Idle
-MCIdrv->Control(ARM_MCI_CONTROL_CLOCK_IDLE, 1);
-// Disable Clock generation on CLK when Idle
-MCIdrv->Control(ARM_MCI_CONTROL_CLOCK_IDLE, 0);
-
-// UHS Tuning
-MCIdrv->Control(ARM_MCI_UHS_TUNING_OPERATION, 1); // start tuning
-do {
- status = MCIdrv->Control(ARM_MCI_UHS_TUNING_RESULT, 0/*argument not used*/);
- if (status == -1) { break; /* tuning failed */ }
-} while (status == 1);
-
-// Set Data Timeout to 12500000 bus cycles (0.5s @25MHz Bus Speed)
-// Default value is hardware specific (typically 2^32-1)
-MCIdrv->Control(ARM_MCI_DATA_TIMEOUT, 12500000);
-
-// Set CSS Timeout to 1000000 bus cycles
-// Default value is hardware specific
-MCIdrv->Control(ARM_MCI_CSS_TIMEOUT, 1000000);
-
-// SD I/O Interrupt Monitoring is disabled by default
-// Enable SD I/O Interrupt Monitoring
-MCIdrv->Control(ARM_MCI_MONITOR_SDIO_INTERRUPT, 1);
-// Disable SD I/O Interrupt Monitoring
-MCIdrv->Control(ARM_MCI_MONITOR_SDIO_INTERRUPT, 0);
-
-// Read/Wait for SD I/O is disabled by default
-// Enable Read/Wait for SD I/O
-MCIdrv->Control(ARM_MCI_CONTROL_READ_WAIT, 1);
-// Disable Read/Wait for SD I/O
-MCIdrv->Control(ARM_MCI_CONTROL_READ_WAIT, 0);
-
-// Suspend Data transfer (SD I/O)
-MCIdrv->Control(ARM_MCI_SUSPEND_TRANSFER, 0/*argument not used*/);
-
-// Resume Data transfer (SD I/O)
-MCIdrv->Control(ARM_MCI_RESUME_TRANSFER, 0/*argument not used*/);
-\endcode
-*******************************************************************************************************************/
-
-ARM_MCI_STATUS ARM_MCI_GetStatus (void) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn ARM_MCI_STATUS ARM_MCI_GetStatus (void)
-\details
-The function \b ARM_MCI_GetStatus returns the current MCI interface status.
-*******************************************************************************************************************/
-
-void ARM_MCI_SignalEvent (uint32_t event) {
- // function body
-}
-/**
-\fn void ARM_MCI_SignalEvent (uint32_t event)
-\details
-The function \b ARM_MCI_SignalEvent is a callback function registered by the function \ref ARM_MCI_Initialize.
-
-The parameter \em event indicates one or more events that occurred during driver operation.
-Each event is encoded in a separate bit and therefore it is possible to signal multiple events within the same call.
-
-Not every event is necessarily generated by the driver. This depends on the implemented capabilities stored in the
-data fields of the structure \ref ARM_NAND_CAPABILITIES, which can be retrieved with the function \ref ARM_NAND_GetCapabilities.
-
-The following events can be generated:
-
-Parameter \em event |Bit | Description | supported when \ref ARM_NAND_CAPABILITIES
-:------------------------------------------|---:|:----------------------------------------------------------------------|:---------------------------------------------
-\ref ARM_MCI_EVENT_CARD_INSERTED | 0 | Occurs after Memory Card inserted | always supported
-\ref ARM_MCI_EVENT_CARD_REMOVED | 1 | Occurs after Memory Card removal | always supported
-\ref ARM_MCI_EVENT_COMMAND_COMPLETE | 2 | Occurs after command completed successfully | always supported
-\ref ARM_MCI_EVENT_COMMAND_TIMEOUT | 3 | Occurs after command timeout | always supported
-\ref ARM_MCI_EVENT_COMMAND_ERROR | 4 | Occurs after command response error (CRC error or invalid response) | always supported
-\ref ARM_MCI_EVENT_TRANSFER_COMPLETE | 5 | Occurs after data transfer completed successfully | always supported
-\ref ARM_MCI_EVENT_TRANSFER_TIMEOUT | 6 | Occurs after data transfer timeout | always supported
-\ref ARM_MCI_EVENT_TRANSFER_ERROR | 7 | Occurs after data transfer error (CRC failed) | always supported
-\ref ARM_MCI_EVENT_SDIO_INTERRUPT | 8 | Indicates SD I/O Interrupt | data field \em sdio_interrupt = \token{1}
-\ref ARM_MCI_EVENT_CCS | 9 | Indicates a Command Completion Signal (CCS) | data field \em ccs = \token{1}
-\ref ARM_MCI_EVENT_CCS_TIMEOUT |10 | Indicates a Command Completion Signal (CCS) Timeout | data field \em css_timeout = \token{1}
-
-See also:
- - \ref ARM_MCI_SendCommand
-
-*******************************************************************************************************************/
-
-
-/**
-@}
-*/
-// End MCI Interface
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/Driver_NAND.c b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/Driver_NAND.c
deleted file mode 100644
index 035b75c..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/Driver_NAND.c
+++ /dev/null
@@ -1,897 +0,0 @@
-/**
-\defgroup nand_interface_gr NAND Interface
-\brief Driver API for NAND Flash Device Interface (%Driver_NAND.h).
-
-\details
-NAND devices are a type of non-volatile storage and do not require power to hold data.
-Wikipedia offers more information about
-the Flash Memories Block Diagram
-
-
-\image html NAND_Schematics.png "Simplified NAND Flash Schematic"
-
-
-
-NAND API
-
-The following header files define the Application Programming Interface (API) for the NAND interface:
- - \b %Driver_NAND.h : Driver API for NAND Flash Device Interface
-
-The driver implementation is a typical part of the Device Family Pack (DFP) that supports the
-peripherals of the microcontroller family.
-
-NAND Flash is organized in pages, grouped into blocks as the smallest erasable unit. The addressing
-of data is achieved by `byte_address = block * block_size + page_in_block * page_size + offset_in_page`.
-In terms of this NAND API blocks and pages are referred to as `row` and the byte offset within the page as `col`.
-Thus one can calculate the `byte_address = row * page_size + col`. The parameters `page_size` and `block_size`
-are device specific and must be handled by the driver user appropriately.
-
-Driver Functions
-
-The driver functions are published in the access struct as explained in \ref DriverFunctions
- - \ref ARM_DRIVER_NAND : access struct for NAND driver functions
-
-@{
-\anchor example Example Code:
-
-\include NAND_Demo.c
-*/
-/*******************************************************************************************************************/
-
-
-/**
-\defgroup nand_execution_status Status Error Codes
-\ingroup common_drv_gr
-\brief Negative values indicate errors (NAND has specific codes in addition to common \ref execution_status).
-\details
-The NAND driver has additional status error codes that are listed below.
-Note that the NAND driver also returns the common \ref execution_status.
-
-@{
-\def ARM_NAND_ERROR_ECC
-ECC generation or correction failed during \ref ARM_NAND_ReadData, \ref ARM_NAND_WriteData or \ref ARM_NAND_ExecuteSequence.
-@}
-*/
-
-
-/**
-\defgroup NAND_events NAND Events
-\ingroup nand_interface_gr
-\brief The NAND driver generates call back events that are notified via the function \ref ARM_NAND_SignalEvent.
-\details
-This section provides the event values for the \ref ARM_NAND_SignalEvent callback function.
-
-The following call back notification events are generated:
-@{
-\def ARM_NAND_EVENT_DEVICE_READY
-\def ARM_NAND_EVENT_DRIVER_READY
-\def ARM_NAND_EVENT_DRIVER_DONE
-\def ARM_NAND_EVENT_ECC_ERROR
-@}
-*/
-
-
-/**
-\defgroup nand_driver_flag_codes NAND Flags
-\ingroup nand_interface_gr
-\brief Specify Flag codes.
-\details
-The defines can be used in the function \ref ARM_NAND_ReadData and \ref ARM_NAND_WriteData for the parameter \em mode
-and in the function \ref ARM_NAND_ExecuteSequence for the parameter \em code.
-@{
-\def ARM_NAND_DRIVER_DONE_EVENT
-@}
-*/
-
-
-/**
-\defgroup nand_control_gr NAND Control Codes
-\ingroup nand_interface_gr
-\brief Many parameters of the NAND driver are configured using the \ref ARM_NAND_Control function.
-@{
-\details
-Refer to the function \ref ARM_NAND_Control for further details.
-*/
-
-/**
-\defgroup nand_control_codes NAND Mode Controls
-\ingroup nand_control_gr
-\brief Specify operation modes of the NAND interface.
-\details
-These controls can be used in the function \ref ARM_NAND_Control for the parameter \em control.
-@{
-\def ARM_NAND_BUS_MODE
-\def ARM_NAND_BUS_DATA_WIDTH
-\def ARM_NAND_DRIVER_STRENGTH
-\def ARM_NAND_DEVICE_READY_EVENT
-\def ARM_NAND_DRIVER_READY_EVENT
-@}
-*/
-
-/**
-\defgroup nand_bus_mode_codes NAND Bus Modes
-\ingroup nand_control_gr
-\brief Specify bus mode of the NAND interface.
-\details
-The defines can be used in the function \ref ARM_NAND_Control for the parameter \em arg and with the \ref ARM_NAND_BUS_MODE as the \em control code.
-@{
-\def ARM_NAND_BUS_SDR
-\def ARM_NAND_BUS_DDR
-\def ARM_NAND_BUS_DDR2
-\def ARM_NAND_BUS_TIMING_MODE_0
-\def ARM_NAND_BUS_TIMING_MODE_1
-\def ARM_NAND_BUS_TIMING_MODE_2
-\def ARM_NAND_BUS_TIMING_MODE_3
-\def ARM_NAND_BUS_TIMING_MODE_4
-\def ARM_NAND_BUS_TIMING_MODE_5
-\def ARM_NAND_BUS_TIMING_MODE_6
-\def ARM_NAND_BUS_TIMING_MODE_7
-\def ARM_NAND_BUS_DDR2_DO_WCYC_0
-\def ARM_NAND_BUS_DDR2_DO_WCYC_1
-\def ARM_NAND_BUS_DDR2_DO_WCYC_2
-\def ARM_NAND_BUS_DDR2_DO_WCYC_4
-\def ARM_NAND_BUS_DDR2_DI_WCYC_0
-\def ARM_NAND_BUS_DDR2_DI_WCYC_1
-\def ARM_NAND_BUS_DDR2_DI_WCYC_2
-\def ARM_NAND_BUS_DDR2_DI_WCYC_4
-\def ARM_NAND_BUS_DDR2_VEN
-\def ARM_NAND_BUS_DDR2_CMPD
-\def ARM_NAND_BUS_DDR2_CMPR
-@}
-*/
-
-/**
-\defgroup nand_data_bus_width_codes NAND Data Bus Width
-\ingroup nand_control_gr
-\brief Specify data bus width of the NAND interface.
-\details
-The defines can be used in the function \ref ARM_NAND_Control for the parameter \em arg and with the \ref ARM_NAND_BUS_DATA_WIDTH as the \em control code.
-@{
-\def ARM_NAND_BUS_DATA_WIDTH_8
-\def ARM_NAND_BUS_DATA_WIDTH_16
-@}
-*/
-
-/**
-\defgroup nand_driver_strength_codes NAND Driver Strength
-\ingroup nand_control_gr
-\brief Specify driver strength of the NAND interface.
-\details
-The defines can be used in the function \ref ARM_NAND_Control for the parameter \em arg and with the \ref ARM_NAND_DRIVER_STRENGTH as the \em control code.
-@{
-\def ARM_NAND_DRIVER_STRENGTH_18
-\def ARM_NAND_DRIVER_STRENGTH_25
-\def ARM_NAND_DRIVER_STRENGTH_35
-\def ARM_NAND_DRIVER_STRENGTH_50
-@}
-*/
-
-/**
-@}
-*/
-
-
-/**
-\defgroup nand_driver_ecc_codes NAND ECC Codes
-\ingroup nand_interface_gr
-\brief Specify ECC codes.
-\details
-The defines can be used in the function \ref ARM_NAND_ReadData and \ref ARM_NAND_WriteData for the parameter \em mode
-and in the function \ref ARM_NAND_ExecuteSequence for the parameter \em code.
-@{
-\def ARM_NAND_ECC(n)
-\def ARM_NAND_ECC0
-\def ARM_NAND_ECC1
-@}
-*/
-
-
-/**
-\defgroup nand_driver_seq_exec_codes NAND Sequence Execution Codes
-\ingroup nand_interface_gr
-\brief Specify execution codes
-\details
-The defines can be used in the function \ref ARM_NAND_ExecuteSequence for the parameter \em code.
-@{
-\def ARM_NAND_CODE_SEND_CMD1
-\def ARM_NAND_CODE_SEND_ADDR_COL1
-\def ARM_NAND_CODE_SEND_ADDR_COL2
-\def ARM_NAND_CODE_SEND_ADDR_ROW1
-\def ARM_NAND_CODE_SEND_ADDR_ROW2
-\def ARM_NAND_CODE_SEND_ADDR_ROW3
-\def ARM_NAND_CODE_INC_ADDR_ROW
-\def ARM_NAND_CODE_WRITE_DATA
-\def ARM_NAND_CODE_SEND_CMD2
-\def ARM_NAND_CODE_WAIT_BUSY
-\def ARM_NAND_CODE_READ_DATA
-\def ARM_NAND_CODE_SEND_CMD3
-\def ARM_NAND_CODE_READ_STATUS
-@}
-*/
-
-
-/*------------ Structures --------------------------------------------------------------------------------------*/
-/**
-\struct ARM_NAND_STATUS
-\details
-Structure with information about the status of a NAND. The data fields encode flags for the driver.
-
-Returned by:
- - \ref ARM_NAND_GetStatus
-*****************************************************************************************************************/
-
-/**
-\struct ARM_DRIVER_NAND
-\details
-The functions of the NAND driver are accessed by function pointers exposed by this structure. Refer to \ref DriverFunctions for overview information.
-
-Each instance of a NAND interface provides such an access structure.
-The instance is identified by a postfix number in the symbol name of the access structure, for example:
- - \b Driver_NAND0 is the name of the access struct of the first instance (no. 0).
- - \b Driver_NAND1 is the name of the access struct of the second instance (no. 1).
-
-A middleware configuration setting allows connecting the middleware to a specific driver instance Driver_NANDn .
-The default is \token{0}, which connects a middleware to the first instance of a driver.
-*******************************************************************************************************************/
-
-/**
-\struct ARM_NAND_CAPABILITIES
-\details
-A NAND driver can be implemented with different capabilities. The data fields of this struct encode
-the capabilities implemented by this driver.
-
-Returned by:
- - \ref ARM_NAND_GetCapabilities
-*******************************************************************************************************************/
-
-
-/**
-\typedef ARM_NAND_SignalEvent_t
-\details
-Provides the typedef for the callback function \ref ARM_NAND_SignalEvent.
-
-Parameter for:
- - \ref ARM_NAND_Initialize
-*******************************************************************************************************************/
-
-
-/**
-\struct ARM_NAND_ECC_INFO
-
-\details
-Stores the characteristics of a ECC (Error Correction Code) algorithm and provides the information about necessary
-application data handling in order to protect stored data from NAND bit errors.
-
-ECC algorithms applied on NAND memory typically operate on NAND device page level which is virtually divided to multiple
-main and spare areas. Data from main and spare area is taken into account when generating ECC data which is also stored
-into spare area. ECC codeword defines how much data will be protected and how much ECC data will be generated.
-
-To describe how application data must be organized, ECC information structure specifies protection \em type which
-defines the protected part of data. As main and spare are of different size, two different algorithms could be
-provided, we can describe them as ECC0 and ECC1. Type can then have the following values:
-
-Type| Description
-:---|:-----------
- 0 | ECC algorithm not used
- 1 | ECC0 algorithm protects main data
- 2 | ECC0 algorithm protects main and spare data
- 3 | ECC0 algorithm protects main and ECC1 algorithm protects spare data
-
-Virtual page division is described with page layout (\em page_layout), number of pages (\em page_count) and
-virtual page size (\em page_size or \em virtual_page_size). Virtual page size used by ECC algorithm can be defined
-by either \em page_size or \em virtual_page_size, depending on the \em page_size values:
-
-Value| Main + Spare size
-:----|:-----------
- 0 | 512 + 16
- 1 | 1024 + 32
- 2 | 2048 + 64
- 3 | 4096 + 128
- 4 | 8192 + 256
- 8 | 512 + 28
- 9 | 1024 + 56
- 10 | 2048 + 112
- 11 | 4096 + 224
- 12 | 8192 + 448
- 15 | Not used, use virtual_page_size
-
-Structure member \em virtual_page_size is an array of two 16-bit values. First field of array (i.e. \em virtual_page_size[0])
-contains main area size while second (i.e. \em virtual_page_size[1]) contains spare area size. Number of virtual pages N
-is defined with \em page_count and must be calculated as N = 2 ^ page_count.
-
-Page layout defines main and spare ordering and two different page layouts are possible. First ordering assumes that
-spare area follows after every main area, while in second case all main areas build one contiguous region followed by
-contiguous region of spare areas. This is defined by member \em page_layout:
-
-Layout| Description
-:-----|:-----------
- 0 | Single spare follows after single main: Main0,Spare0 ... MainN-1,SpareN-1
- 1 | Contiguous spare follows after contiguous main: Main0 ... MainN-1,Spare0 ... SpareN-1
-
-ECC codeword size defines the size of data that is protected by ECC algorithm and is different for main and spare
-area. All structure members that define the codeword are therefore arrays of two 16-bit values. Codeword offset defines
-where ECC protected data starts in main (\em codeword_offset[0]) or spare (\em codeword_offset[1]) area, codeword
-size (\em codeword_size) defines the number of data that is protected i.e. data over which ECC is calculated and
-codeword gap (\em codeword_gap) defines the space between two consecutive codeword regions.
-
-Generated ECC data is stored into spare area and is described similar as codeword, with offset from start of spare area
-(\em ecc_offset), size of generated data (\em ecc_size) and gap (\em ecc_gap) between two consecutive ECC data regions.
-
-Number of bits that ECC algorithm can correct per codeword is defined with \em correctable_bits.
-
-Parameter for:
- - \ref ARM_NAND_InquireECC
-*****************************************************************************************************************/
-
-
-//
-// Functions
-//
-
-ARM_DRIVER_VERSION ARM_NAND_GetVersion (void) {
- return { 0, 0 };
-}
-/**
-\fn ARM_DRIVER_VERSION ARM_NAND_GetVersion (void)
-\details
-The function \b ARM_NAND_GetVersion returns version information of the driver implementation in \ref ARM_DRIVER_VERSION
- - API version is the version of the CMSIS-Driver specification used to implement this driver.
- - Driver version is source code version of the actual driver implementation.
-
-Example:
-\code
-extern ARM_DRIVER_NAND Driver_NAND0;
-ARM_DRIVER_NAND *drv_info;
-
-void setup_nand (void) {
- ARM_DRIVER_VERSION version;
-
- drv_info = &Driver_NAND0;
- version = drv_info->GetVersion ();
- if (version.api < 0x10A) { // requires at minimum API version 1.10 or higher
- // error handling
- return;
- }
-}
-\endcode
-*******************************************************************************************************************/
-
-ARM_NAND_CAPABILITIES ARM_NAND_GetCapabilities (void) {
- return { 0 };
-}
-/**
-\fn ARM_NAND_CAPABILITIES ARM_NAND_GetCapabilities (void)
-\details
-The function \b ARM_NAND_GetCapabilities retrieves information about capabilities in this driver implementation.
-The data fields of the structure \ref ARM_NAND_CAPABILITIES encode various capabilities, for example
-if a hardware is able to create signal events using the \ref ARM_NAND_SignalEvent
-callback function.
-
-Example:
-\code
-extern ARM_DRIVER_NAND Driver_NAND0;
-ARM_DRIVER_NAND *drv_info;
-
-void read_capabilities (void) {
- ARM_NAND_CAPABILITIES drv_capabilities;
-
- drv_info = &Driver_NAND0;
- drv_capabilities = drv_info->GetCapabilities ();
- // interrogate capabilities
-
-}
-\endcode
-*******************************************************************************************************************/
-
-int32_t ARM_NAND_Initialize (ARM_NAND_SignalEvent_t cb_event) {
- return 0;
-}
-/**
-\fn int32_t ARM_NAND_Initialize (ARM_NAND_SignalEvent_t cb_event)
-\details
-The function \b ARM_NAND_Initialize initializes the NAND interface.
-It is called when the middleware component starts operation.
-
-The function performs the following operations:
- - Initializes the resources needed for the NAND interface.
- - Registers the \ref ARM_NAND_SignalEvent callback function.
-
-The parameter \em cb_event is a pointer to the \ref ARM_NAND_SignalEvent callback function; use a NULL pointer
-when no callback signals are required.
-
-\b Example:
- - see \ref nand_interface_gr - Driver Functions
-
-*******************************************************************************************************************/
-
-int32_t ARM_NAND_Uninitialize (void) {
- return 0;
-}
-/**
-\fn int32_t ARM_NAND_Uninitialize (void)
-\details
-The function \b ARM_NAND_Uninitialize de-initializes the resources of NAND interface.
-
-It is called when the middleware component stops operation and releases the software resources used by the interface.
-*******************************************************************************************************************/
-
-int32_t ARM_NAND_PowerControl (ARM_POWER_STATE state) {
- return 0;
-}
-/**
-\fn int32_t ARM_NAND_PowerControl (ARM_POWER_STATE state)
-\details
-The function \b ARM_NAND_PowerControl controls the power modes of the NAND interface.
-
-The parameter \em state sets the operation and can have the following values:
- - \ref ARM_POWER_FULL : set-up peripheral for data transfers, enable interrupts (NVIC) and optionally DMA.
- Can be called multiple times. If the peripheral is already in this mode the function performs
- no operation and returns with \ref ARM_DRIVER_OK.
- - \ref ARM_POWER_LOW : may use power saving. Returns \ref ARM_DRIVER_ERROR_UNSUPPORTED when not implemented.
- - \ref ARM_POWER_OFF : terminates any pending data transfers, disables peripheral, disables related interrupts and DMA.
-
-Refer to \ref CallSequence for more information.
-*******************************************************************************************************************/
-
-
-int32_t ARM_NAND_DevicePower (uint32_t voltage) {
- return 0;
-}
-/**
-\fn int32_t ARM_NAND_DevicePower (uint32_t voltage)
-\details
-The function \b ARM_NAND_DevicePower controls the power supply of the NAND device.
-
-The parameter \em voltage sets the device supply voltage as defined in the table.
-
-\b AMR_NAND_POWER_xxx_xxx specifies power settings.
-
-Device Power Bits | Description
-:--------------------------------|:--------------------------------------------
-\ref ARM_NAND_POWER_VCC_OFF | Set VCC Power off
-\ref ARM_NAND_POWER_VCC_3V3 | Set VCC = 3.3V
-\ref ARM_NAND_POWER_VCC_1V8 | Set VCC = 1.8V
-\ref ARM_NAND_POWER_VCCQ_OFF | Set VCCQ I/O Power off
-\ref ARM_NAND_POWER_VCCQ_3V3 | Set VCCQ = 3.3V
-\ref ARM_NAND_POWER_VCCQ_1V8 | Set VCCQ = 1.8V
-\ref ARM_NAND_POWER_VPP_OFF | Set VPP off
-\ref ARM_NAND_POWER_VPP_ON | Set VPP on
-
-*******************************************************************************************************************/
-
-int32_t ARM_NAND_WriteProtect (uint32_t dev_num, bool enable) {
- return 0;
-}
-/**
-\fn int32_t ARM_NAND_WriteProtect (uint32_t dev_num, bool enable)
-\details
-The function \b ARM_NAND_WriteProtect controls the Write Protect (WPn) pin of a NAND device.
-
-The parameter \em dev_num is the device number. \n
-The parameter \em enable specifies whether to enable or disable write protection.
-*******************************************************************************************************************/
-
-int32_t ARM_NAND_ChipEnable (uint32_t dev_num, bool enable) {
- return 0;
-}
-/**
-\fn int32_t ARM_NAND_ChipEnable (uint32_t dev_num, bool enable)
-\details
-The function \b ARM_NAND_ChipEnable control the Chip Enable (CEn) pin of a NAND device.
-
-The parameter \em dev_num is the device number. \n
-The parameter \em enable specifies whether to enable or disable the device.
-
-This function is optional and supported only when the data field \em ce_manual = \token{1} in the structure \ref ARM_NAND_CAPABILITIES.
-Otherwise, the Chip Enable (CEn) signal is controlled automatically by SendCommand/Address, Read/WriteData and ExecuteSequence
-(for example when the NAND device is connected to a memory bus).
-*******************************************************************************************************************/
-
-int32_t ARM_NAND_GetDeviceBusy (uint32_t dev_num) {
- return 0;
-}
-/**
-\fn int32_t ARM_NAND_GetDeviceBusy (uint32_t dev_num)
-\details
-The function \b ARM_NAND_GetDeviceBusy returns the status of the Device Busy pin: [\token{1=busy; 0=not busy or error}].
-
-The parameter \em dev_num is the device number.
-*******************************************************************************************************************/
-
-int32_t ARM_NAND_SendCommand (uint32_t dev_num, uint8_t cmd) {
- return 0;
-}
-/**
-\fn int32_t ARM_NAND_SendCommand (uint32_t dev_num, uint8_t cmd)
-\details
-The function \b ARM_NAND_SendCommand sends a command to the NAND device.
-
-The parameter \em dev_num is the device number. \n
-The parameter \em cmd is the command sent to the NAND device.
-*******************************************************************************************************************/
-
-int32_t ARM_NAND_SendAddress (uint32_t dev_num, uint8_t addr) {
- return 0;
-}
-/**
-\fn int32_t ARM_NAND_SendAddress (uint32_t dev_num, uint8_t addr)
-\details
-Send an address to the NAND device.
-The parameter \em dev_num is the device number.
-The parameter \em addr is the address.
-*******************************************************************************************************************/
-
-int32_t ARM_NAND_ReadData (uint32_t dev_num, void *data, uint32_t cnt, uint32_t mode) {
- return 0;
-}
-/**
-\fn int32_t ARM_NAND_ReadData (uint32_t dev_num, void *data, uint32_t cnt, uint32_t mode)
-\details
-The function \b ARM_NAND_ReadData reads data from a NAND device.
-
-The parameter \em dev_num is the device number. \n
-The parameter \em data is a pointer to the buffer that stores the data read from a NAND device. \n
-The parameter \em cnt is the number of data items to read. \n
-The parameter \em mode defines the operation mode as listed in the table below.
-
-Read Data Mode | Description
-:----------------------------------|:--------------------------------------------
-\ref ARM_NAND_ECC(n) | Select ECC
-\ref ARM_NAND_ECC0 | Use ECC0 of selected ECC
-\ref ARM_NAND_ECC1 | Use ECC1 of selected ECC
-\ref ARM_NAND_DRIVER_DONE_EVENT | Generate \ref ARM_NAND_EVENT_DRIVER_DONE
-
-The data item size is defined by the data type, which depends on the configured data bus width.
-
-Data type is:
- - \em uint8_t for 8-bit data bus
- - \em uint16_t for 16-bit data bus
-
-The function executes in the following ways:
- - When the operation is blocking (typical for devices connected to memory bus when not using DMA),
- then the function returns after all data is read and returns the number of data items read.
- - When the operation is non-blocking (typical for NAND controllers), then the function only starts the operation and returns with zero number of data items read.
- After the operation is completed, the \ref ARM_NAND_EVENT_DRIVER_DONE event is generated (if enabled by \b ARM_NAND_DRIVER_DONE_EVENT).
- Progress of the operation can also be monitored by calling the \ref ARM_NAND_GetStatus function and checking the \em busy data field.
- Operation is automatically aborted if ECC is used and ECC correction fails, which generates the \ref ARM_NAND_EVENT_ECC_ERROR event
- (together with \ref ARM_NAND_DRIVER_DONE_EVENT if enabled).
-
-*******************************************************************************************************************/
-
-int32_t ARM_NAND_WriteData (uint32_t dev_num, const void *data, uint32_t cnt, uint32_t mode) {
- return 0;
-}
-/**
-\fn int32_t ARM_NAND_WriteData (uint32_t dev_num, const void *data, uint32_t cnt, uint32_t mode)
-\details
-The function \b ARM_NAND_WriteData writes data to a NAND device.
-
-The parameter \em dev_num is the device number. \n
-The parameter \em data is a pointer to the buffer with data to write. \n
-The parameter \em cnt is the number of data items to write. \n
-The parameter \em mode defines the operation mode as listed in the table below.
-
-Write Data Mode | Description
-:----------------------------------|:--------------------------------------------
-\ref ARM_NAND_ECC(n) | Select ECC
-\ref ARM_NAND_ECC0 | Use ECC0 of selected ECC
-\ref ARM_NAND_ECC1 | Use ECC1 of selected ECC
-\ref ARM_NAND_DRIVER_DONE_EVENT | Generate \ref ARM_NAND_EVENT_DRIVER_DONE
-
-The data item size is defined by the data type, which depends on the configured data bus width.
-
-Data type is:
- - \em uint8_t for 8-bit data bus
- - \em uint16_t for 16-bit data bus
-
-The function executes in the following ways:
- - When the operation is blocking (typical for devices connected to memory bus when not using DMA),
- then the function returns after all data is written and returns the number of data items written.
- - When the operation is non-blocking (typical for NAND controllers), then the function only starts the operation
- and returns with zero number of data items written. After the operation is completed,
- the \ref ARM_NAND_EVENT_DRIVER_DONE event is generated (if enabled by \b ARM_NAND_DRIVER_DONE_EVENT).
- Progress of the operation can also be monitored by calling the \ref ARM_NAND_GetStatus function and checking the \em busy data field.
- Operation is automatically aborted if ECC is used and ECC generation fails,
- which generates the \ref ARM_NAND_EVENT_ECC_ERROR event (together with \ref ARM_NAND_DRIVER_DONE_EVENT if enabled).
-*******************************************************************************************************************/
-
-int32_t ARM_NAND_ExecuteSequence (uint32_t dev_num, uint32_t code, uint32_t cmd,
- uint32_t addr_col, uint32_t addr_row,
- void *data, uint32_t data_cnt,
- uint8_t *status, uint32_t *count) {
- return 0;
-}
-/**
-\fn int32_t ARM_NAND_ExecuteSequence (uint32_t dev_num, uint32_t code, uint32_t cmd, uint32_t addr_col, uint32_t addr_row, void *data, uint32_t data_cnt, uint8_t *status, uint32_t *count)
-\details
-The function \b ARM_NAND_ExecuteSequence executes a sequence of operations for a NAND device.
-
-The parameter \em dev_num is the device number. \n
-The parameter \em code is the sequence encoding as defined in the table Sequence execution Code . \n
-The parameter \em cmd is the command or a series of commands. \n
-The parameter \em addr_col is the column address. \n
-The parameter \em addr_row is the row address. \n
-The parameter \em data is a pointer to the buffer that stores the data to or loads the data from. \n
-The parameter \em data_cnt is the number of data items to read or write in one iteration. \n
-The parameter \em status is a pointer to the buffer that stores the status read. \n
-The parameter \em count is a pointer to the number of iterations. \n
-
-\b ARM_NAND_CODE_xxx specifies sequence execution codes.
-
-Sequence Execution Code | Description
-:----------------------------------|:--------------------------------------------
-\ref ARM_NAND_CODE_SEND_CMD1 | Send Command 1 (cmd[7..0])
-\ref ARM_NAND_CODE_SEND_ADDR_COL1 | Send Column Address 1 (addr_col[7..0])
-\ref ARM_NAND_CODE_SEND_ADDR_COL2 | Send Column Address 2 (addr_col[15..8])
-\ref ARM_NAND_CODE_SEND_ADDR_ROW1 | Send Row Address 1 (addr_row[7..0])
-\ref ARM_NAND_CODE_SEND_ADDR_ROW2 | Send Row Address 2 (addr_row[15..8])
-\ref ARM_NAND_CODE_SEND_ADDR_ROW3 | Send Row Address 3 (addr_row[23..16])
-\ref ARM_NAND_CODE_INC_ADDR_ROW | Auto-increment Row Address
-\ref ARM_NAND_CODE_WRITE_DATA | Write Data
-\ref ARM_NAND_CODE_SEND_CMD2 | Send Command 2 (cmd[15..8])
-\ref ARM_NAND_CODE_WAIT_BUSY | Wait while R/Bn busy
-\ref ARM_NAND_CODE_READ_DATA | Read Data
-\ref ARM_NAND_CODE_SEND_CMD3 | Send Command 3 (cmd[23..16])
-\ref ARM_NAND_CODE_READ_STATUS | Read Status byte and check FAIL bit (bit 0)
-\ref ARM_NAND_ECC(n) | Select ECC
-\ref ARM_NAND_ECC0 | Use ECC0 of selected ECC
-\ref ARM_NAND_ECC1 | Use ECC1 of selected ECC
-\ref ARM_NAND_DRIVER_DONE_EVENT | Generate \ref ARM_NAND_EVENT_DRIVER_DONE
-
-The data item size is defined by the data type, which depends on the configured data bus width.
-
-Data type is:
- - \em uint8_t for 8-bit data bus
- - \em uint16_t for 16-bit data bus
-
-The function is non-blocking and returns as soon as the driver has started executing the specified sequence.
-When the operation is completed, the \ref ARM_NAND_EVENT_DRIVER_DONE event is generated (if enabled by \b ARM_NAND_DRIVER_DONE_EVENT).
-Progress of the operation can also be monitored by calling the \ref ARM_NAND_GetStatus function and checking the \em busy data field.
-
-Driver executes the number of specified iterations where in each iteration
-items specified by \b ARM_NAND_CODE_xxx are executed in the order as listed in the table Sequence execution Code .
-The parameter \em count is holding the current number of iterations left.
-
-Execution is automatically aborted and \ref ARM_NAND_EVENT_DRIVER_DONE event is generated (if enabled by \b ARM_NAND_DRIVER_DONE_EVENT):
- - if Read Status is enabled and the FAIL bit (bit 0) is set
- - if ECC is used and ECC fails (also sets \ref ARM_NAND_EVENT_ECC_ERROR event)
-
-\note
-\ref ARM_NAND_CODE_WAIT_BUSY can only be specified if the Device Ready event can be generated (reported by \em event_device_ready in \ref ARM_NAND_CAPABILITIES).
-The event \ref ARM_NAND_EVENT_DEVICE_READY is not generated during sequence execution but rather used internally by the driver.
-*******************************************************************************************************************/
-
-int32_t ARM_NAND_AbortSequence (uint32_t dev_num) {
- return 0;
-}
-/**
-\fn int32_t ARM_NAND_AbortSequence (uint32_t dev_num)
-\details
-The function \b ARM_NAND_AbortSequence aborts execution of the current sequence for a NAND device.
-
-The parameter \em dev_num is the device number.
-*******************************************************************************************************************/
-
-int32_t ARM_NAND_Control (uint32_t dev_num, uint32_t control, uint32_t arg) {
- return 0;
-}
-/**
-\fn int32_t ARM_NAND_Control (uint32_t dev_num, uint32_t control, uint32_t arg)
-\details
-The function \b ARM_NAND_Control controls the NAND interface and executes operations.
-
-The parameter \em dev_num is the device number. \n
-The parameter \em control specifies the operation. \n
-The parameter \em arg provides (depending on the \em control) additional information or sets values.
-
-The table lists the operations for the parameter \em control.
-
-Parameter \em control | Operation
-:--------------------------------|:--------------------------------------------
-\ref ARM_NAND_BUS_MODE | Set the bus mode. The parameter \em arg sets the \ref bus_mode_tab "\b Bus Mode".
-\ref ARM_NAND_BUS_DATA_WIDTH | Set the data bus width. The parameter \em arg sets the \ref bus_data_width_tab "\b Bus Data Width".
-\ref ARM_NAND_DRIVER_STRENGTH | Set the driver strength. The parameter \em arg sets the \ref driver_strength_tab "\b Driver Strength".
-\ref ARM_NAND_DRIVER_READY_EVENT | Control generation of callback event \ref ARM_NAND_EVENT_DRIVER_READY. Enable: \em arg = \token{1}. Disable: \em arg = \token{0}.
-\ref ARM_NAND_DEVICE_READY_EVENT | Control generation of callback event \ref ARM_NAND_EVENT_DEVICE_READY; Enable: \em arg = \token{1}. Disable: \em arg = \token{0}.
-
-See Also
-- \ref ARM_NAND_GetCapabilities returns information about supported operations, which are stored in the structure \ref ARM_NAND_CAPABILITIES.
-- \ref ARM_NAND_SignalEvent provides information about the callback events \ref ARM_NAND_EVENT_DRIVER_READY and \ref ARM_NAND_EVENT_DEVICE_READY
-
-The table lists values for the parameter \em arg used with the \em control operation \ref ARM_NAND_BUS_MODE, \ref ARM_NAND_BUS_DATA_WIDTH, and
-\ref ARM_NAND_DRIVER_STRENGTH. Values from different categories can be ORed.
-
-\anchor bus_mode_tab
-
- Parameter \em arg control = \ref ARM_NAND_BUS_MODE
- Bit
- Category
- Description
- Supported when \ref ARM_NAND_CAPABILITIES \ref ARM_NAND_BUS_TIMING_MODE_0 (default)
- 0..3
- \anchor bus_timing_tab Bus Timing Mode
- \token{0}
- The maximum timing mode that can be applied to a specific \ref bus_data_interface_tab "\b Bus Data Interface"
- is stored in the data fields: sdr_timing_mode - for SDR ddr_timing_mode - for NV-DDR ddr2_timing_mode - for NV_DDR2 \ref ARM_NAND_BUS_TIMING_MODE_1 \token{1} \ref ARM_NAND_BUS_TIMING_MODE_2 \token{2} \ref ARM_NAND_BUS_TIMING_MODE_3 \token{3} \ref ARM_NAND_BUS_TIMING_MODE_4 \token{4} (SDR EDO capable) \ref ARM_NAND_BUS_TIMING_MODE_5 \token{5} (SDR EDO capable) \ref ARM_NAND_BUS_TIMING_MODE_6 \token{6} (NV-DDR2 only) \ref ARM_NAND_BUS_TIMING_MODE_7 \token{7} (NV-DDR2 only) \ref ARM_NAND_BUS_SDR (default) \anchor bus_data_interface_tab
- 4..7
- Bus Data Interface
- SDR (Single Data Rate) - Traditional interface
- always supported \ref ARM_NAND_BUS_DDR NV-DDR (Double Data Rate) data field ddr = \token{1} \ref ARM_NAND_BUS_DDR2 NV-DDR2 (Double Data Rate) data field ddr2 = \token{1} \ref ARM_NAND_BUS_DDR2_DO_WCYC_0 (default)
- 8..11
- Data Output Warm-up \anchor bus_output_tab
- Set the DDR2 Data Output Warm-up to \token{0} cycles
- Data Output Warm-up cycles are dummy cycles for interface calibration with no incremental data transfer
- and apply to NV-DDR2 of the \ref bus_data_interface_tab "\b Bus Data Interface".
- \ref ARM_NAND_BUS_DDR2_DO_WCYC_1 Set the DDR2 Data Output Warm-up to \token{1} cycles \ref ARM_NAND_BUS_DDR2_DO_WCYC_2 Set the DDR2 Data Output Warm-up to \token{2} cycles \ref ARM_NAND_BUS_DDR2_DO_WCYC_4 Set the DDR2 Data Output Warm-up to \token{4} cycles \ref ARM_NAND_BUS_DDR2_DI_WCYC_0 (default) \anchor bus_input_tab
- 12..15
- Data Input Warm-up
- Set the DDR2 Data Input Warm-up to \token{0} cycles
- Data Input Warm-up cycles are dummy cycles for interface calibration with no incremental data transfer
- and apply to NV-DDR2 of the \ref bus_data_interface_tab "\b Bus Data Interface".
- \ref ARM_NAND_BUS_DDR2_DI_WCYC_1 Set the DDR2 Data Input Warm-up to \token{1} cycles \ref ARM_NAND_BUS_DDR2_DI_WCYC_2 Set the DDR2 Data Input Warm-up to \token{2} cycles \ref ARM_NAND_BUS_DDR2_DI_WCYC_4 Set the DDR2 Data Input Warm-up to \token{4} cycles \ref ARM_NAND_BUS_DDR2_VEN \anchor bus_misc_tab
- 16
- Miscellaneous
- Set the DDR2 Enable external VREFQ as reference
-
- \ref ARM_NAND_BUS_DDR2_CMPD 17 Set the DDR2 Enable complementary DQS (DQS_c) signal \ref ARM_NAND_BUS_DDR2_CMPR 18 Set the DDR2 Enable complementary RE_n (RE_c) signal Parameter \em arg control = \ref ARM_NAND_BUS_DATA_WIDTH
- Bit
- Category \anchor bus_data_width_tab
- Description
- Supported when \ref ARM_NAND_CAPABILITIES \ref ARM_NAND_BUS_DATA_WIDTH_8 (default)
- 0..1
- Bus Data Width
- Set to \token{8 bit}
- always supported
- \ref ARM_NAND_BUS_DATA_WIDTH_16 Set to \token{16 bit} data field data_width_16 = \token{1} Parameter \em arg control = \ref ARM_NAND_DRIVER_STRENGTH
- Bit
- Category \anchor driver_strength_tab
- Description
- Supported when \ref ARM_NAND_CAPABILITIES \ref ARM_NAND_DRIVER_STRENGTH_18
- 0..3
- Driver Strength
- Set the Driver Strength 2.0x = 18 Ohms
- data field driver_strength_18 = \token{1}
- \ref ARM_NAND_DRIVER_STRENGTH_25 Set the Driver Strength 1.4x = 25 Ohms data field driver_strength_25 = \token{1} \ref ARM_NAND_DRIVER_STRENGTH_35 (default) Set the Driver Strength 1.0x = 35 Ohms always supported \ref ARM_NAND_DRIVER_STRENGTH_50 Set the Driver Strength 0.7x = 50 Ohms data field driver_strength_50 = \token{1}
-
-Example
-\code
-extern ARM_DRIVER_NAND Driver_NAND0;
-
-status = Driver_NAND0.Control (0, ARM_NAND_BUS_MODE, ARM_NAND_BUS_TIMING_MODE_5 |
- ARM_NAND_BUS_DDR2 |
- ARM_NAND_BUS_DDR2_VEN);
-
-status = Driver_NAND0.Control (0, ARM_NAND_BUS_DATA_WIDTH, ARM_NAND_BUS_DATA_WIDTH_16);
-
-status = Driver_NAND0.Control (0, ARM_NAND_DRIVER_STRENGTH, ARM_NAND_DRIVER_STRENGTH_50);
-\endcode
-
-*******************************************************************************************************************/
-
-ARM_NAND_STATUS ARM_NAND_GetStatus (uint32_t dev_num) {
- return 0;
-}
-/**
-\fn ARM_NAND_STATUS ARM_NAND_GetStatus (uint32_t dev_num)
-\details
-The function \b ARM_NAND_GetStatus returns the current NAND device status.
-
-The parameter \em dev_num is the device number.
-*******************************************************************************************************************/
-
-int32_t ARM_NAND_InquireECC (int32_t index, ARM_NAND_ECC_INFO *info) {
- return 0;
-}
-/**
-\fn int32_t ARM_NAND_InquireECC (int32_t index, ARM_NAND_ECC_INFO *info)
-\details
-The function \b ARM_NAND_InquireECC reads error correction code information.
-
-The parameter \em index is the ECC index and is used to retrieve different ECC configurations. \n
-The parameter \em info is a pointer of type \ref ARM_NAND_ECC_INFO. The data fields store the information.
-
-When multiple different ECC configurations exist, ARM_NAND_ECC_INFO structure exists for each configuration. Parameter
-\em index denotes which configuration will be retrieved. Value of index should start with zero to retrieve first ECC
-configuration and should be incremented in order to retrieve next ECC configuration. When index is out of range function
-ARM_NAND_InquireECC returns with error.
-
-Parameter \em index is used by \ref ARM_NAND_ECC(n) in \ref ARM_NAND_ReadData, \ref ARM_NAND_WriteData and
-\ref ARM_NAND_ExecuteSequence to select suitable ECC configuration.
-
-Example
-\code
-extern ARM_DRIVER_NAND Driver_NAND0;
-
-ARM_NAND_ECC_INFO ecc;
-int32_t idx;
-
-idx = 0;
-while (Driver_NAND0.InquireECC (idx, &ecc) == ARM_DRIVER_OK) {
- // Examine retrieved ECC configuration
- if (ecc.type == 2) {
- // Algorithm ECC0 protects Main+Spare
- }
- // ..
- idx++;
-}
-\endcode
-*******************************************************************************************************************/
-
-void ARM_NAND_SignalEvent (uint32_t dev_num, uint32_t event) {
- return 0;
-}
-/**
-\fn void ARM_NAND_SignalEvent (uint32_t dev_num, uint32_t event)
-\details
-The function \b ARM_NAND_SignalEvent is a callback function registered by the function \ref ARM_NAND_Initialize.
-
-The parameter \em dev_num is the device number. \n
-The parameter \em event indicates one or more events that occurred during driver operation.
-Each event is encoded in a separate bit and therefore it is possible to signal multiple events within the same call.
-
-Not every event is necessarily generated by the driver. This depends on the implemented capabilities stored in the
-data fields of the structure \ref ARM_NAND_CAPABILITIES, which can be retrieved with the function \ref ARM_NAND_GetCapabilities.
-
-The following events can be generated:
-
-Parameter \em event | Bit | Description
-:---------------------------------|-----|:---------------------------
-\ref ARM_NAND_EVENT_DEVICE_READY | 0 | Occurs when rising edge is detected on R/Bn (Ready/Busy) pin indicating that the device is ready.
-\ref ARM_NAND_EVENT_DRIVER_READY | 1 | Occurs to indicate that commands can be executed (after previously being busy and not able to start the requested operation).
-\ref ARM_NAND_EVENT_DRIVER_DONE | 2 | Occurs after an operation completes. An operation was successfully started before with \ref ARM_NAND_ReadData, \ref ARM_NAND_WriteData, \ref ARM_NAND_ExecuteSequence.
-\ref ARM_NAND_EVENT_ECC_ERROR | 3 | Occurs when ECC generation failed or ECC correction failed. An operation was successfully started before with \ref ARM_NAND_ReadData, \ref ARM_NAND_WriteData, \ref ARM_NAND_ExecuteSequence.
-
-The event \ref ARM_NAND_EVENT_DEVICE_READY occurs after complete execution of commands
-(initiated with the functions \ref ARM_NAND_SendCommand, \ref ARM_NAND_SendAddress, \ref ARM_NAND_ReadData, \ref ARM_NAND_WriteData, \ref ARM_NAND_ExecuteSequence).
-It is useful to indicate completion of complex operations (such as erase).
-The event is only generated when \ref ARM_NAND_GetCapabilities returns data field \em event_device_ready = \token{1}
-and was enabled by calling \ref ARM_NAND_Control (\ref ARM_NAND_DEVICE_READY_EVENT, 1).
-If the event is not available, poll the \em busy data field using the function \ref ARM_NAND_GetStatus.
-
-The event \ref ARM_NAND_EVENT_DRIVER_READY occurs when previously a function
-(\ref ARM_NAND_SendCommand, \ref ARM_NAND_SendAddress, \ref ARM_NAND_ReadData, \ref ARM_NAND_WriteData, \ref ARM_NAND_ExecuteSequence)
-returned with \ref ARM_DRIVER_ERROR_BUSY. It is useful when functions are called simultaneously from independent threads
-(for example to control multiple devices) and the threads have no knowledge about each other (driver rejects reentrant calls with return of \ref ARM_DRIVER_ERROR_BUSY).
-\em dev_num indicates the device that returned previously busy.
-*******************************************************************************************************************/
-
-/**
-@}
-*/
-// End NAND Interface
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/Driver_NAND_AddOn.txt b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/Driver_NAND_AddOn.txt
deleted file mode 100644
index 63332b3..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/Driver_NAND_AddOn.txt
+++ /dev/null
@@ -1,73 +0,0 @@
-/*
-Purpose: The text might be of interest in another place.
- We have to decide whether we want to use it.
-
- Until a decision is made, do not delete the file.
-
-Usage: Storage of text. Not used in doxygen.
-
-Created: March 21, 2014
-Author : Bruno
-Changed:
-*/
-
-
-
-/**
-\struct ARM_NAND_DEVICE
-\details
-Stores the characteristics of a NAND Flash device. This includes the page layout configuration, NAND type,
-device number (chip select), number of blocks, pages, sectors, and error correction code.
-
-Parameter for:
- - \ref ARM_NAND_Initialize
-
-*******************************************************************************************************************/
-
-/**
-\struct ARM_NAND_ECC_INFO_x
-\details
-Stores the default NAND page layout definition (with \ref spare_size and \ref spare_offset),
-which contains a \b Spare area after each sector. The struct \b ARM_NAND_ECC_INFO defines the \b Spare area.
-
-The page size is defined as the sum of \b User area plus \b Spare area.
-Each page has a small number of associated "spare" bytes (typically 1/32 of the data size) to store the Error Correction Algorithms (ECC).
-
-The following standard page sizes are available:
-
-Page Size| User + Spare Area
----------|-------------------
-528 | 512 + 16 bytes
-2112 | 2048 + 64 bytes
-4224 | 4096 + 128 bytes
-8448 | 8192 + 256 bytes
-
-
-\image html NAND_PageLayout.png "Default Page Layout"
-
-
-\image html NAND_SpareArea.png "Organization of the default 16-byte Spare area"
-
-NAND devices require bad block management by the driver software or by a separate controller chip.
-For example, SD cards have mechanisms that execute wear leveling and bad block management.
-The memory capacity shrinks as more blocks are marked bad.
-The block size is a value specified as amount of flash pages.
-
-The following block sizes are available:
-
-Block Size| Pages
-----------|-------------------
- 8 | 8
- 16 | 16
- 32 | 32
- 64 | 64
-128 | 128
-256 | 256
-
-\note
-NAND chip manufacturers document the order in which pages can be written.
-Typically, single pages of an erase block must be written in sequential order starting from the first. Random-order writes are prohibited or unspecified.
-
-Parameter for:
- - \ref ARM_NAND_DEVICE structure
-*******************************************************************************************************************/
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/Driver_SAI.c b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/Driver_SAI.c
deleted file mode 100644
index a0aa0c0..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/Driver_SAI.c
+++ /dev/null
@@ -1,936 +0,0 @@
-/* -----------------------------------------------------------------------------
- * Copyright (c) 2013-2014 ARM Ltd.
- *
- * This software is provided 'as-is', without any express or implied warranty.
- * In no event will the authors be held liable for any damages arising from
- * the use of this software. Permission is granted to anyone to use this
- * software for any purpose, including commercial applications, and to alter
- * it and redistribute it freely, subject to the following restrictions:
- *
- * 1. The origin of this software must not be misrepresented; you must not
- * claim that you wrote the original software. If you use this software in
- * a product, an acknowledgment in the product documentation would be
- * appreciated but is not required.
- *
- * 2. Altered source versions must be plainly marked as such, and must not be
- * misrepresented as being the original software.
- *
- * 3. This notice may not be removed or altered from any source distribution.
- *
- *
- * $Date: 9. Dec 2014
- * $Revision: V1.00
- *
- * Project: SAI (Serial Audio Interface) Driver definitions
- * -------------------------------------------------------------------------- */
-
-/**
-\defgroup sai_interface_gr SAI Interface
-\brief Driver API for Serial Audio Interface (%Driver_SAI.h)
-\details
-The Serial Audio Interface (SAI) implements a synchronous serial bus interface for connecting digital audio devices.
-It is by far the most common mechanism used to transfer two channels of audio data between devices within a system. \b SAI
-can transfer digital audio using various protocols:
-- \ref Driver_SAI_I2S
-- \ref Driver_SAI_MSB
-- \ref Driver_SAI_LSB
-- \ref Driver_SAI_PCM
-- \ref Driver_SAI_AC97
-- \ref Driver_SAI_User
-
-
-Block Diagram
-
-
-\image html SAI_Schematics.png "Simplified SAI Schematic"
-
-
-
-SAI API
-
-The following header files define the Application Programming Interface (API) for the SAI interface:
- - \b %Driver_SAI.h : Driver API for Serial Audio Interface
-
-The driver implementation is a typical part of the
-Device Family Pack (DFP) that supports the peripherals of
-the microcontroller family.
-
-
-Driver Functions
-
-The driver functions are published in the access struct as explained in \ref DriverFunctions
- - \ref ARM_DRIVER_SAI : access struct for SAI driver functions
-
-\section Driver_SAI_I2S I2S
-Integrated Interchip Sound (\b I2S) is a serial bus
-interface that connects digital audio devices together. It was introduced by Philips (now
-NXP ) in the late 80's and last revised 1996. It uses pulse code modulation
-to exchange the audio data between the devices. The following timing diagram explains the operation:
-
-\image html driver_sai_i2s.png
-
-I2S separates the clock (\b SCK) from the serial data (\b SD), resulting in a lower jitter. A complete audio data frame
-consists of two slots, one for the left channel and one for the right. The slot size equals the data size.
-The word select (\b WS) line lets the device know whether the left channel (WS is low) or the right channel (WS is high) is
-currently being transmitted. WS has a 50% duty-cycle signal that has the same frequency as the sample frequency. It is an
-early signal, meaning that the WS line changes one clock cycle before the actual data (SD) is transmitted (left or right).
-The data on SD is always transmitted MSB first and can have a data size of 8 up to 32 bits.
-
-In terms of the CMSIS-Driver for SAI, the I2S protocol can be described as follows:
-- Data Size: 8..32 (MSB first)
-- Clock Polarity: Drive on falling edge, Capture on rising edge
-- Frame Length: 2 * Data Size = 2 * Slot Size
-- Frame Sync Width: Frame Length / 2
-- Frame Sync Polarity: Active Low
-- Frame Sync Early
-- Slot Count: 2 (L R)
-- Slot Size: Data Size
-- Slot Offset: 0
-
-
-\section Driver_SAI_MSB MSB Justified
-\b MSB \b Justified is much like \ref Driver_SAI_I2S, with a few differences:
-
-\image html driver_sai_msb.png
-
-Unlike I2S, in MSB Justified the word select (\b WS) signals the left channel when it is active high and the right channel,
-when it is active low. The signal changes when the first actual \b SD data is available. It might happen that a frame (left
-or right) is not fully filled with data. In this case, all data after the LSB is forced to zero.
-
-In terms of the CMSIS-Driver for SAI, the MSB Justified protocol can be described as follows:
-- Data Size: 8..32 (MSB first)
-- Clock Polarity: Drive on falling edge, Capture on rising edge
-- Frame Length: 2 * Slot Size
-- Frame Sync Width: Frame Length / 2
-- Frame Sync Polarity: Active High
-- Slot Count: 2 (L R)
-- Slot Size: Data Size or higher (16/32)
-- Slot Offset: 0 (Zero padding after Data: Slot Size - Data Size)
-
-\section Driver_SAI_LSB LSB Justified
-\b LSB \b Justified is much like \ref Driver_SAI_MSB, with the single difference that the padding 0's are sent before the
-first actual data (MSB on \b SD):
-
-\image html driver_sai_lsb.png
-
-In terms of the CMSIS-Driver for SAI, the LSB Justified protocol can be described as follows:
-- Data Size: 8..32 (MSB first)
-- Clock Polarity: Drive on falling edge, Capture on rising edge
-- Frame Length: 2*Slot Size
-- Frame Sync Width: Frame Length / 2
-- Frame Sync Polarity: Active High
-- Slot Count: 2
-- Slot Size: Data Size or higher (16/32)
-- Slot Offset: Slot Size - Data Size (Zero padding before Data: Slot Size - Data Size)
-
-\section Driver_SAI_PCM PCM
-Pulse Code Modulation (\b PCM) differs to
-the previous protocols in a few ways:
-
-\image html driver_sai_pcm.png
-
-- Only one channel is transferred.
-
-- There are two types of synchronization modes available:
- - In \b short \b frame sync mode, the falling edge of \b Frame \b Sync indicates the start of the serial data \b SD. \b Frame \b Sync is always
- one clock cycle long.
- - In \b long \b frame sync mode, the rising edge of \b Frame \b Sync indicates the start of the serial data \b SD. \b Frame \b Sync stays active
- high for 13 clock cycles.
-
-In terms of the CMSIS-Driver for SAI, the PCM protocol can be described as follows:\n
-\b PCM \b Short \b Frame
-- Data Size: 8..32 (MSB first)
-- Clock Polarity: Drive on falling edge, Capture on rising edge
-- Frame Length: Slot Size
-- Frame Sync Width: 1
-- Frame Sync Polarity: Active High
-- Frame Sync Early
-- Slot Count: 1
-- Slot Size: Data Size or higher (16/32)
-- Slot Offset: 0
-
-\b PCM \b Long \b Frame
-- Data Size: 16..32 (MSB first)
-- Clock Polarity: Drive on falling edge, Capture on rising edge
-- Frame Length: Slot Size
-- Frame Sync Width: 13
-- Frame Sync Polarity: Active High
-- Slot Count: 1
-- Slot Size: Data Size or higher (32)
-- Slot Offset: 0
-
-\section Driver_SAI_AC97 AC'97
-Audio Codec '97 was developed by
-Intel . It is composed of five wires: the clock (12.288 MHz), a sync
-signal, a reset signal, and two data wires: sdata_out (contains the AC97 output) and sdata_in (contains the CODEC output).
-For more information, consult the
-standard documentation .
-
-\section Driver_SAI_User User Defined Protocol
-Using the control structs of the CMSIS-Driver SAI, it is possible to create support for nearly all serial audio protocols
-that are available today.
-
-\image html driver_sai_user.png
-
-The following properties can be configured for a user protocol:
-- Data Size in bits (8..32)
-- Data Bit Order: MSB first (default) or LSB first
-- Clock Polarity:
- - Driver on falling edge, Capture on rising edge (default)
- - Driver on rising edge, Capture on falling edge
-- Frame Length in bits
-- Frame Sync Width in bits (default=1)
-- Frame Sync Polarity: active high (default) or low
-- Frame Sync Early: Sync signal one bit before the first bit of frame
-- Slot Count: number of slots in frame (default=1)
-- Slot Size: equal to data size (default) or 16 or 32-bit
-- Slot Offset: offset of first data bit in slot (default=0)
-
-For more information, refer to \ref ARM_SAI_Control that explains the different configuration options in more detail.
-
-@{
-*/
-
-
-/**
-\struct ARM_DRIVER_SAI
-\details
-The functions of the SAI driver are accessed by function pointers exposed by this structure.
-Refer to \ref DriverFunctions for overview information.
-
-Each instance of an SAI interface provides such an access structure.
-The instance is identified by a postfix number in the symbol name of the access structure, for example:
- - \b Driver_SAI0 is the name of the access struct of the first instance (no. 0).
- - \b Driver_SAI1 is the name of the access struct of the second instance (no. 1).
-
-A middleware configuration setting allows connecting the middleware to a specific driver instance \b %Driver_SAIn .
-The default is \token{0}, which connects a middleware to the first instance of a driver.
-*****************************************************************************************************************/
-
-/**
-\struct ARM_SAI_CAPABILITIES
-\details
-An SAI driver can be implemented with different capabilities (for example protocol support). The data fields of this
-structure encode the capabilities implemented by this driver. If a certain hardware peripheral is not able to handle one
-of the protocols directly (not advertised using ARM_SAI_CAPABILITIES), then it might be possible to implement it using
-the \ref Driver_SAI_User (if supported).
-
-Returned by:
- - \ref ARM_SAI_GetCapabilities
-*****************************************************************************************************************/
-
-/**
-\struct ARM_SAI_STATUS
-\details
-Structure with information about the status of the SAI. The data fields encode busy flags and error flags.
-
-Returned by:
- - \ref ARM_SAI_GetStatus
-*****************************************************************************************************************/
-
-/**
-\typedef ARM_SAI_SignalEvent_t
-\details
-Provides the typedef for the callback function \ref ARM_SAI_SignalEvent.
-
-Parameter for:
- - \ref ARM_SAI_Initialize
-*******************************************************************************************************************/
-
-
-/****** SAI specific error codes *****/
-/**
-\defgroup sai_execution_status Status Error Codes
-\ingroup common_drv_gr
-\brief Negative values indicate errors (SAI has specific codes in addition to common \ref execution_status).
-\details
-The SAI driver has additional status error codes that are listed below.
-\note
-- In case multiple errors exist, only the first encountered error will be reported.
-- errors ARM_SAI_ERROR_BIT_ORDER, ARM_SAI_ERROR_FRAME_SYNC_xxx, ARM_SAI_ERROR_SLOT_xxx will only be reported in \ref Driver_SAI_User mode.
-- The SAI driver also returns the common \ref execution_status.
-
-@{
-\def ARM_SAI_ERROR_SYNCHRONIZATION
-The \b synchronization requested with the function \ref ARM_SAI_Control is not supported.
-
-\def ARM_SAI_ERROR_PROTOCOL
-The \b protocol requested with the function \ref ARM_SAI_Control is not supported.
-
-\def ARM_SAI_ERROR_DATA_SIZE
-The data size requested with the function \ref ARM_SAI_Control is not supported.
-
-\def ARM_SAI_ERROR_BIT_ORDER
-The bit order requested with the function \ref ARM_SAI_Control is not supported.
-
-\def ARM_SAI_ERROR_MONO_MODE
-The mono mode requested with the function \ref ARM_SAI_Control is not supported.
-
-\def ARM_SAI_ERROR_COMPANDING
-The companding requested with the function \ref ARM_SAI_Control is not supported.
-
-\def ARM_SAI_ERROR_CLOCK_POLARITY
-The clock polarity requested with the function \ref ARM_SAI_Control is not supported.
-
-\def ARM_SAI_ERROR_AUDIO_FREQ
-The audio frequency requested with the function \ref ARM_SAI_Control is not supported.
-
-\def ARM_SAI_ERROR_MCLK_PIN
-The MCLK pin setting requested with the function \ref ARM_SAI_Control is not supported.
-
-\def ARM_SAI_ERROR_MCLK_PRESCALER
-The MCLK prescaler requested with the function \ref ARM_SAI_Control is not supported.
-
-\def ARM_SAI_ERROR_FRAME_LENGTH
-The frame length requested with the function \ref ARM_SAI_Control is not supported.
-
-\def ARM_SAI_ERROR_FRAME_SYNC_WIDTH
-The frame sync width requested with the function \ref ARM_SAI_Control is not supported.
-
-\def ARM_SAI_ERROR_FRAME_SYNC_POLARITY
-The frame sync polarity requested with the function \ref ARM_SAI_Control is not supported.
-
-\def ARM_SAI_ERROR_FRAME_SYNC_EARLY
-The frame sync early requested with the function \ref ARM_SAI_Control is not supported.
-
-\def ARM_SAI_ERROR_SLOT_COUNT
-The slot count requested with the function \ref ARM_SAI_Control is not supported.
-
-\def ARM_SAI_ERROR_SLOT_SIZE
-The slot size requested with the function \ref ARM_SAI_Control is not supported.
-
-\def ARM_SAI_ERROR_SLOT_OFFESET
-The slot offset requested with the function \ref ARM_SAI_Control is not supported.
-@}
-*/
-
-
-/****** SAI Event *****/
-/**
-\defgroup SAI_events SAI Events
-\ingroup sai_interface_gr
-\brief The SAI driver generates call back events that are notified via the function \ref ARM_SAI_SignalEvent.
-\details
-This section provides the event values for the \ref ARM_SAI_SignalEvent callback function.
-
-The following call back notification events are generated:
-@{
-\def ARM_SAI_EVENT_SEND_COMPLETE
-\def ARM_SAI_EVENT_RECEIVE_COMPLETE
-\def ARM_SAI_EVENT_TX_UNDERFLOW
-\def ARM_SAI_EVENT_RX_OVERFLOW
-\def ARM_SAI_EVENT_FRAME_ERROR
-@}
-*/
-
-
-/**
-\defgroup sai_control SAI Control Codes
-\ingroup sai_interface_gr
-\brief Many parameters of the SAI driver are configured using the \ref ARM_SAI_Control function.
-\details
-@{
-The various SAI control codes define:
- - \ref sai_configure_control specifies SAI configuration
- - \ref sai_controls specifies SAI controls
-
-Refer to the \ref ARM_SAI_Control function for further details.
-*/
-
-
-/**
-\defgroup sai_configure_control SAI Configuration
-\ingroup sai_control
-\brief Specify Transmitter/Receiver configuration.
-\details
-@{
-Configuration is specified by ORing \b ARM_SAI_CONFIGURE_x with the following parameters:
- - \ref sai_mode_control
- - \ref sai_sync_control
- - \ref sai_protocol_control
- - \ref sai_data_bits_control
- - \ref sai_bit_order_control
- - \ref sai_mono_control
- - \ref sai_clock_pol_control
- - \ref sai_companding_control
- - \ref sai_mclk_pin_control
-
-Additional configuration specified by \em arg1:
- - \ref sai_frame_control
- - \ref sai_slot_control
-
-Additional configuration specified by \em arg2:
- - Audio Frequency (Master only)
- - \ref sai_mclk_pres_control
-
-\defgroup sai_mode_control SAI Mode
-\ingroup sai_configure_control
-\brief Defines Transmitter/Receiver mode.
-\details
-@{
-\def ARM_SAI_MODE_MASTER
-\def ARM_SAI_MODE_SLAVE
-@}
-
-\defgroup sai_sync_control SAI Synchronization
-\ingroup sai_configure_control
-\brief Defines Transmitter/Receiver synchronization.
-\details
-@{
-\def ARM_SAI_ASYNCHRONOUS
-\def ARM_SAI_SYNCHRONOUS
-@}
-
-\defgroup sai_protocol_control SAI Protocol
-\ingroup sai_configure_control
-\brief Defines Transmitter/Receiver protocol.
-\details
-@{
-\def ARM_SAI_PROTOCOL_USER
-\def ARM_SAI_PROTOCOL_I2S
-\def ARM_SAI_PROTOCOL_MSB_JUSTIFIED
-\def ARM_SAI_PROTOCOL_LSB_JUSTIFIED
-\def ARM_SAI_PROTOCOL_PCM_SHORT
-\def ARM_SAI_PROTOCOL_PCM_LONG
-\def ARM_SAI_PROTOCOL_AC97
-@}
-
-\defgroup sai_data_bits_control SAI Data Size
-\ingroup sai_configure_control
-\brief Defines data size in bits (per channel/slot).
-\details
-@{
-\def ARM_SAI_DATA_SIZE(n)
-@}
-
-\defgroup sai_bit_order_control SAI Bit Order
-\ingroup sai_configure_control
-\brief Defines the bit order.
-\details
-@{
-\def ARM_SAI_MSB_FIRST
-\def ARM_SAI_LSB_FIRST
-@}
-
-\defgroup sai_mono_control SAI Mono Mode
-\ingroup sai_configure_control
-\brief Defines mono mode.
-\details
-@{
-\def ARM_SAI_MONO_MODE
-@}
-
-\defgroup sai_companding_control SAI Companding
-\ingroup sai_configure_control
-\brief Defines companding.
-\details
-@{
-\def ARM_SAI_COMPANDING_NONE
-\def ARM_SAI_COMPANDING_A_LAW
-\def ARM_SAI_COMPANDING_U_LAW
-@}
-
-\defgroup sai_clock_pol_control SAI Clock Polarity
-\ingroup sai_configure_control
-\brief Defines clock polarity.
-\details
-@{
-\def ARM_SAI_CLOCK_POLARITY_0
-\def ARM_SAI_CLOCK_POLARITY_1
-@}
-
-\defgroup sai_frame_control SAI Frame
-\ingroup sai_configure_control
-\brief Defines frame.
-\details
-@{
-\def ARM_SAI_FRAME_LENGTH(n)
-\def ARM_SAI_FRAME_SYNC_WIDTH(n)
-\def ARM_SAI_FRAME_SYNC_POLARITY_HIGH
-\def ARM_SAI_FRAME_SYNC_POLARITY_LOW
-\def ARM_SAI_FRAME_SYNC_EARLY
-@}
-
-\defgroup sai_slot_control SAI Slot
-\ingroup sai_configure_control
-\brief Defines data slots.
-\details
-@{
-\def ARM_SAI_SLOT_COUNT(n)
-\def ARM_SAI_SLOT_SIZE_DEFAULT
-\def ARM_SAI_SLOT_SIZE_16
-\def ARM_SAI_SLOT_SIZE_32
-\def ARM_SAI_SLOT_OFFSET(n)
-@}
-
-\defgroup sai_mclk_pin_control SAI Master Clock Pin
-\ingroup sai_configure_control
-\brief Defines MCLK pin.
-\details
-@{
-\def ARM_SAI_MCLK_PIN_INACTIVE
-\def ARM_SAI_MCLK_PIN_OUTPUT
-\def ARM_SAI_MCLK_PIN_INPUT
-@}
-
-\defgroup sai_mclk_pres_control SAI Master Clock Prescaler
-\ingroup sai_configure_control
-\brief Defines MCLK prescaler.
-\details
-@{
-\def ARM_SAI_MCLK_PRESCALER(n)
-@}
-
-@}
-*/
-
-
-/**
-\defgroup sai_controls SAI Controls
-\ingroup sai_control
-\brief Specifies controls.
-\details
-@{
-\def ARM_SAI_CONFIGURE_TX
-\sa ARM_SAI_Control
-\def ARM_SAI_CONFIGURE_RX
-\sa ARM_SAI_Control
-\def ARM_SAI_CONTROL_TX
-\sa ARM_SAI_Control; ARM_SAI_Send
-\def ARM_SAI_CONTROL_RX
-\sa ARM_SAI_Control; ARM_SAI_Receive
-\def ARM_SAI_MASK_SLOTS_TX
-\sa ARM_SAI_Control; ARM_SAI_Send
-\def ARM_SAI_MASK_SLOTS_RX
-\sa ARM_SAI_Control; ARM_SAI_Receive
-\def ARM_SAI_ABORT_SEND
-\sa ARM_SAI_Control; ARM_SAI_Send
-\def ARM_SAI_ABORT_RECEIVE
-\sa ARM_SAI_Control; ARM_SAI_Receive
-@}
-*/
-
-
-/**
-@}
-*/
-// end group SAI_control
-
-
-//
-// Function documentation
-//
-
-ARM_DRIVER_VERSION ARM_SAI_GetVersion (void) {
- return { 0, 0 };
-}
-/**
-\fn ARM_DRIVER_VERSION ARM_SAI_GetVersion (void)
-\details
-The function \b ARM_SAI_GetVersion returns version information of the driver implementation in \ref ARM_DRIVER_VERSION
- - API version is the version of the CMSIS-Driver specification used to implement this driver.
- - Driver version is source code version of the actual driver implementation.
-
-\b Example:
-\code
-extern ARM_DRIVER_SAI Driver_SAI0;
-ARM_DRIVER_SAI *drv_info;
-
-void setup_sai (void) {
- ARM_DRIVER_VERSION version;
-
- drv_info = &Driver_SAI0;
- version = drv_info->GetVersion ();
- if (version.api < 0x10A) { // requires at minimum API version 1.10 or higher
- // error handling
- return;
- }
-}
-\endcode
-*****************************************************************************************************************/
-
-ARM_SAI_CAPABILITIES ARM_SAI_GetCapabilities (void) {
- return {0};
-}
-/**
-\details
-\fn ARM_SAI_CAPABILITIES ARM_SAI_GetCapabilities (void)
-The function \b ARM_SAI_GetCapabilities retrieves information about the capabilities in this driver implementation.
-The data fields of the struct \ref ARM_SAI_CAPABILITIES encode various capabilities, for example
-supported protocols, or if a hardware is capable to create signal events using the \ref ARM_SAI_SignalEvent
-callback function.
-
-\b Example:
-\code
-extern ARM_DRIVER_SAI Driver_SAI0;
-ARM_DRIVER_SAI *drv_info;
-
-void read_capabilities (void) {
- ARM_SAI_CAPABILITIES drv_capabilities;
-
- drv_info = &Driver_SAI0;
- drv_capabilities = drv_info->GetCapabilities ();
- // interrogate capabilities
-
-}
-\endcode
-*****************************************************************************************************************/
-
-int32_t ARM_SAI_Initialize (ARM_SAI_SignalEvent_t cb_event) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_SAI_Initialize (ARM_SAI_SignalEvent_t cb_event)
-\details
-The function \b ARM_SAI_Initialize initializes the SAI interface. It is called when the middleware component starts
-operation.
-
-The function performs the following operations:
- - Initializes the required resources of the SAI interface.
- - Registers the \ref ARM_SAI_SignalEvent callback function.
-
-The parameter \em cb_event is a pointer to the \ref ARM_SAI_SignalEvent callback function; use a NULL pointer
-when no callback signals are required.
-*****************************************************************************************************************/
-
-int32_t ARM_SAI_Uninitialize (void) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_SAI_Uninitialize (void)
-\details
-The function \b ARM_SAI_Uninitialize de-initializes the resources of SAI interface.
-
-It is called when the middleware component stops operation and releases the software resources used by the interface.
-*****************************************************************************************************************/
-
-int32_t ARM_SAI_PowerControl (ARM_POWER_STATE state) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_SAI_PowerControl (ARM_POWER_STATE state)
-\details
-The function \b ARM_SAI_PowerControl allows you to control the power modes of the SAI interface.
-
-The parameter \em state sets the operation and can have the following values:
- - \ref ARM_POWER_FULL : set-up peripheral for data transfers, enable interrupts (NVIC) and optionally DMA.
- Can be called multiple times. If the peripheral is already in this mode the function performs
- no operation and returns with \ref ARM_DRIVER_OK.
- - \ref ARM_POWER_LOW : may use power saving. Returns \ref ARM_DRIVER_ERROR_UNSUPPORTED when not implemented.
- - \ref ARM_POWER_OFF : terminates any pending data transfers, disables peripheral, disables related interrupts and DMA.
-
-Refer to \ref CallSequence for more information.
-*****************************************************************************************************************/
-
-int32_t ARM_SAI_Send (const void *data, uint32_t num) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_SAI_Send (const void *data, uint32_t num)
-\details
-The function \b ARM_SAI_Send sends data to the SAI transmitter.
-
-The function parameters specify the buffer with \a data and the number \a num of items to send.
-The item size is defined by the data type which depends on the configured number of data bits.
-
-Data type is:
- - \em uint8_t when configured for \token{8} data bits
- - \em uint16_t when configured for \token{9..16} data bits
- - \em uint32_t when configured for \token{17..32} data bits
-
-Transmitter is enabled by calling \ref ARM_SAI_Control with \ref ARM_SAI_CONTROL_TX as the control parameter and \token{1} as
-an argument. This starts the transmit engine which, generates a clock and frame sync signal in master mode and transmits the
-data. In slave mode, clock and frame sync are generated by the external master. When mute is active, data is discarded and
-zero values are transmitted.
-
-Calling the function ARM_SAI_Send only starts the send operation. The function is non-blocking and returns as soon as
-the driver has started the operation (the driver typically configures DMA or the interrupt system for continuous transfer).
-During the operation it is not allowed to call this function again. Also, the data buffer must stay allocated and the
-contents of unsent data must not be modified. When the send operation is completed (requested number of items have been
-sent), the event \ref ARM_SAI_EVENT_SEND_COMPLETE is generated. Progress of the send operation can be monitored by reading
-the number of already sent items by calling the function \ref ARM_SAI_GetTxCount.
-
-The status of the transmitter can also be monitored by calling the function \ref ARM_SAI_GetStatus and checking the \em tx_busy flag,
-which indicates if a transmission is still in progress.
-
-If the transmitter is enabled and data is to be sent but the send operation has not been started yet, then the event
-\ref ARM_SAI_EVENT_TX_UNDERFLOW is generated.
-
-If an invalid synchronization frame is detected in slave mode, then the event \ref ARM_SAI_EVENT_FRAME_ERROR is generated (if
-supported and reported by \em event_frame_error in \ref ARM_SAI_CAPABILITIES).
-
-The send operation can be aborted by calling the function \ref ARM_SAI_Control with the control parameter \ref ARM_SAI_ABORT_SEND.
-*****************************************************************************************************************/
-
-int32_t ARM_SAI_Receive (void *data, uint32_t num) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_SAI_Receive (void *data, uint32_t num)
-\details
-The function \b ARM_SAI_Receive is used to receive data from the SAI receiver. The function parameters specify the buffer for
-\a data and the number \a num of items to receive. The item size is defined by the data type, which depends on the configured
-number of data bits.
-
-Data type is:
- - \em uint8_t when configured for \token{8} data bits
- - \em uint16_t when configured for \token{9..16} data bits
- - \em uint32_t when configured for \token{17..32} data bits
-
-The receiver is enabled by calling the function \ref ARM_SAI_Control with the control parameter \ref ARM_SAI_CONTROL_RX and the value \token{1}
-for the parameter \em arg1. This starts the receive engine, which generates a clock and frame sync signal in master mode and receives
-data. In slave mode, clock and frame sync are generated by the external master.
-
-Calling the function ARM_SAI_Receive only starts the receive operation. The function is non-blocking and returns as
-soon as the driver has started the operation (the driver typically configures DMA or the interrupt system for continuous
-transfer). During the operation, it is not allowed to call this function again. The data buffer must also stay allocated.
-When receive operation is completed (the requested number of items have been received), the
-\ref ARM_SAI_EVENT_RECEIVE_COMPLETE event is generated. Progress of the receive operation can also be monitored by reading
-the number of items already received by calling the function \ref ARM_SAI_GetRxCount.
-
-The status of the receiver can also be monitored by calling the function \ref ARM_SAI_GetStatus and checking the \em rx_busy flag, which
-indicates whether a reception is still in progress.
-
-When the receiver is enabled and data is received but the receive operation has not been started yet, then the event
-\ref ARM_SAI_EVENT_RX_OVERFLOW is generated.
-
-If an invalid synchronization frame is detected in slave mode, then the event \ref ARM_SAI_EVENT_FRAME_ERROR is generated (if
-supported and reported by \em event_frame_error in \ref ARM_SAI_CAPABILITIES).
-
-The receive operation can be aborted by calling the function \ref ARM_SAI_Control with the control parameter \ref ARM_SAI_ABORT_RECEIVE.
-*****************************************************************************************************************/
-
-uint32_t ARM_SAI_GetTxCount (void) {
- return 0;
-}
-/**
-\fn uint32_t ARM_SAI_GetTxCount (void)
-\details
-The function \b ARM_SAI_GetTxCount returns the number of the currently transmitted data items during an \ref ARM_SAI_Send
-operation.
-*****************************************************************************************************************/
-
-uint32_t ARM_SAI_GetRxCount (void) {
- return 0;
-}
-/**
-\fn uint32_t ARM_SAI_GetRxCount (void)
-\details
-The function \b ARM_SAI_GetRxCount returns the number of the currently received data items during an \ref ARM_SAI_Receive
-operation.
-*****************************************************************************************************************/
-
-int32_t ARM_SAI_Control (uint32_t control, uint32_t arg1, uint32_t arg2) {
- return ARM_DRIVER_OK;
-}
-
-/**
-\fn int32_t ARM_SAI_Control (uint32_t control, uint32_t arg1, uint32_t arg2)
-\details
-The function \b ARM_SAI_Control controls the SAI interface and executes various operations.
-
-The parameter \em control specifies the operation. Values are listed in the table Parameter control Parameter arg1 Synchronization Clock Polarity Master Clock pin (MCLK)
- Parameter \em control Bit Category
- Description \ref ARM_SAI_CONFIGURE_TX 0..7 Operation
- Configure transmitter. \em arg1 (see Parameter arg1 \ref ARM_SAI_CONFIGURE_RX
- Configure receiver. \em arg1 (see Parameter arg1 \ref ARM_SAI_CONTROL_TX
- Enable or disable transmitter and control mute;
- \em arg1.0 : \token{0=disable (default); 1=enable;} \em arg1.1 : \token{mute} (see \ref ARM_SAI_Send) \ref ARM_SAI_CONTROL_RX
- Enable or disable receiver; \em arg1.0 : \token{0=disable (default); 1=enable} (see \ref ARM_SAI_Receive) \ref ARM_SAI_MASK_SLOTS_TX
- Mask transmitter slots; \em arg1 = \token{mask} (bit: 0=active, 1=inactive); all configured slots are active by default. \ref ARM_SAI_MASK_SLOTS_RX
- Mask receiver slots; \em arg1 = \token{mask} (bit: 0=active, 1=inactive); all configured slots are active by default. \ref ARM_SAI_ABORT_SEND
- Abort send operation (see \ref ARM_SAI_Send). \ref ARM_SAI_ABORT_RECEIVE
- Abort receive operation (see \ref ARM_SAI_Receive). \ref ARM_SAI_MODE_MASTER 8 Mode
- Master mode. \em arg2 specifies the audio frequency in [Hz]. You can also set the Master Clock pin \ref ARM_SAI_MODE_SLAVE (default)
- Slave mode. \ref ARM_SAI_ASYNCHRONOUS (default) \anchor sai_sync 9 Synchronization
- Asynchronous operation using own clock and sync signal. \ref ARM_SAI_SYNCHRONOUS
- Synchronous operation using clock and sync signal from other transmitter/receiver. \ref ARM_SAI_PROTOCOL_USER (default) 10..12 Protocol
- User defined \ref ARM_SAI_PROTOCOL_I2S
- I2C \ref ARM_SAI_PROTOCOL_MSB_JUSTIFIED
- MSB (left) justified \ref ARM_SAI_PROTOCOL_LSB_JUSTIFIED
- LSB (right) justified \ref ARM_SAI_PROTOCOL_PCM_SHORT
- PCM with short frame \ref ARM_SAI_PROTOCOL_PCM_LONG
- PCM with long frame \ref ARM_SAI_PROTOCOL_AC97
- AC'97 \ref ARM_SAI_DATA_SIZE(n) 13..17 Data Size
- Data size in bits; the range for \em n is \token{8..32}. See also: Frame Slot Size \ref ARM_SAI_MSB_FIRST 18 Bit Order
- Data is transferred with MSB first. \ref ARM_SAI_LSB_FIRST
- Data is transferred with LSB first (User protocol only, ignored otherwise). \ref ARM_SAI_MONO_MODE 19 Mono Mode
- Only for I2S, MSB/LSB justified.
- When using \ref Driver_SAI_I2S in mono mode, only data for a single channel is sent to and received from the driver.
- Hardware will duplicate the data for the second channel on transmit and ignore the second channel on receive. \ref ARM_SAI_COMPANDING_NONE (default) 20..22 Companding
- No companding \ref ARM_SAI_COMPANDING_A_LAW
- A-Law companding (8-bit data) \ref ARM_SAI_COMPANDING_U_LAW
- u-Law companding (8-bit data) \ref ARM_SAI_CLOCK_POLARITY_0 (default) \anchor sai_clk_polarity > 23 Clock Polarity
- Drive on falling edge, capture on rising edge. \ref ARM_SAI_CLOCK_POLARITY_1 \anchor master_clock
- Drive on rising edge, capture on falling edge. \ref ARM_SAI_MCLK_PIN_INACTIVE (default) 24..26 Master Clock pin (MCLK)
- MCLK not used. \ref ARM_SAI_MCLK_PIN_OUTPUT
- MCLK is output (Master mode only). \ref ARM_SAI_MCLK_PIN_INPUT
- MCLK is input (Master mode only).
-
-\anchor sai_arg1_tab
-The parameter \em arg1 provides frame-specific values depending on the \em control operation. Values from different categories can be ORed.
-
- Parameter \em arg1
- Bit
- Category
- Description \ref ARM_SAI_FRAME_LENGTH(n)
- 0..9
- Frame Length
- Frame length in bits; the possible range for \em n is \token{8..1024}; default depends on protocol and data. \ref ARM_SAI_FRAME_SYNC_WIDTH(n)
- 10..17
- Frame Sync Width
- Frame Sync width in bits; the possible range for \em n is \token{1..256}; \token{default=1}; User protocol only, ignored otherwise. \ref ARM_SAI_FRAME_SYNC_POLARITY_HIGH
- 18
- Frame Sync Polarity
- Frame Sync is active high (default). \ref ARM_SAI_FRAME_SYNC_POLARITY_LOW
- Frame Sync is active low (User protocol only, ignored otherwise). \ref ARM_SAI_FRAME_SYNC_EARLY
- 19
- Frame Sync Early
- Frame Sync one bit before the first bit of the frame (User protocol only, ignored otherwise). \ref ARM_SAI_SLOT_COUNT(n)
- 20..24
- Frame Sync Count
- Number of slots in frame; the possible range for \em n is \token{1..32}; default=\token{1}; User protocol only, ignored otherwise. \ref ARM_SAI_SLOT_SIZE_DEFAULT \anchor frame_slot_size
- 25..26
- Frame Slot Size
- Slot size is equal to data size (default). \ref ARM_SAI_SLOT_SIZE_16
- Slot size is \token{16 bits} (User protocol only, ignored otherwise). \ref ARM_SAI_SLOT_SIZE_32
- Slot size is \token{32 bits} (User protocol only, ignored otherwise). \ref ARM_SAI_SLOT_OFFSET(n)
- 27..31
- Frame Slot Offset
- Offset of first data bit in slot; The range for \em n is \token{0..31}; default=\token{0}; User protocol only, ignored otherwise.
-
-
-\anchor mckl_prescaler
-Depending on the \em control operation, the parameter \em arg2 specifies the Master Clock (MCLK) prescaler and calculates the audio frequency automatically.
-
-Parameter \em arg2 | MCLK Prescaler
-:----------------------------------------|:--------------------------------------------
-\ref ARM_SAI_MCLK_PRESCALER(n) | MCLK prescaler; Audio frequency = MCLK/n; the range for \em n is \token{1..4096}; default=\token{1}.
-
-
-\b Example
-
-\code
-extern ARM_DRIVER_SAI Driver_SAI0;
-
-// configure Transmitter to Asynchronous Master: I2S Protocol, 16-bit data, 16kHz Audio frequency
-status = Driver_SAI0.Control(ARM_SAI_CONFIGURE_TX |
- ARM_SAI_MODE_MASTER |
- ARM_SAI_ASYNCHRONOUS |
- ARM_SAI_PROTOCOL_I2S |
- ARM_SAI_DATA_SIZE(16), 0, 16000);
-
-// configure Receiver to Asynchronous Master: I2S Protocol, 16-bit data, 16kHz Audio frequency
-status = Driver_SAI0.Control(ARM_SAI_CONFIGURE_RX |
- ARM_SAI_MODE_MASTER |
- ARM_SAI_ASYNCHRONOUS |
- ARM_SAI_PROTOCOL_I2S |
- ARM_SAI_DATA_SIZE(16), 0, 16000);
-
-// enable Transmitter
-status = Driver_SAI0.Control(ARM_SAI_CONTROL_TX, 1, 0);
-
-// enable Receiver
-status = Driver_SAI0.Control(ARM_SAI_CONTROL_RX, 1, 0);
-\endcode
-
-*****************************************************************************************************************/
-
-ARM_SAI_STATUS ARM_SAI_GetStatus (void) {
- return { 0 };
-}
-/**
-\fn ARM_SAI_STATUS ARM_SAI_GetStatus (void)
-\details
-The function \b ARM_SAI_GetStatus retrieves the current SAI interface status.
-*****************************************************************************************************************/
-
-void ARM_SAI_SignalEvent (uint32_t event) {
- // function body
-}
-/**
-\fn void ARM_SAI_SignalEvent (uint32_t event)
-\details
-The function \b ARM_SAI_SignalEvent is a callback function registered by the function \ref ARM_SAI_Initialize.
-
-The parameter \em event indicates one or more events that occurred during driver operation.
-Each event is encoded in a separate bit and therefore it is possible to signal multiple events within the same call.
-
-The following events can be generated:
-
-Parameter \em event | Bit | Description
------------------------------------------- |:---:|:-----------
-\ref ARM_SAI_EVENT_SEND_COMPLETE | 0 | Occurs after call to \ref ARM_SAI_Send to indicate that all the data has been sent (or queued in transmit buffers). The driver is ready for the next call to \ref ARM_SAI_Send.
-\ref ARM_SAI_EVENT_RECEIVE_COMPLETE | 1 | Occurs after call to \ref ARM_SAI_Receive to indicate that all the data has been received. The driver is ready for the next call to \ref ARM_SAI_Receive.
-\ref ARM_SAI_EVENT_TX_UNDERFLOW | 2 | Occurs when data is to be sent but send operation has not been started. Data field \em tx_underflow = \token{1} of \ref ARM_SAI_STATUS.
-\ref ARM_SAI_EVENT_RX_OVERFLOW | 3 | Occurs when data is received but receive operation has not been started. Data field \em rx_underflow = \token{1} of \ref ARM_SAI_STATUS.
-\ref ARM_SAI_EVENT_FRAME_ERROR | 4 | Occurs in slave mode when invalid synchronization frame is detected. Data field \em event_frame_error = \token{1} of \ref ARM_SAI_STATUS.
-
-*****************************************************************************************************************/
-
-/**
-@}
-*/
-// End SAI Interface
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/Driver_SPI.c b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/Driver_SPI.c
deleted file mode 100644
index caa5f74..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/Driver_SPI.c
+++ /dev/null
@@ -1,723 +0,0 @@
-/**
-\defgroup spi_interface_gr SPI Interface
-\brief Driver API for SPI Bus Peripheral (%Driver_SPI.h)
-\details
-The Serial Peripheral Interface Bus (SPI) implements a synchronous serial bus for data exchange. In microcontroller (MCU) applications,
-the interface is often used to connect peripheral components at board (PCB) level. SPI devices can operate as Master (SCLK and SS are outputs) or
-Slave (SCLK and SS are inputs). Wikipedia offers more information about
-the Serial Peripheral Interface Bus Block Diagram
-
-The SPI Driver API defines a SPI interface for middleware components. The SPI Driver supports multiple
-slaves, but if only one slave is connected, then the Slave Select signal can be omitted.
-
-
-\image html SPI_Master1Slaves.png "SPI Master connected to a single slave"
-
-
-
-\image html SPI_Master3Slaves.png "SPI Master connected to 3 slaves"
-
-The SPI Driver functions control the following SPI signal lines.
-
-Signal | Name | Description
--------|-------------------------------------|------------------------------------------------------------------------------
-SS | Slave Select (active low) | Selects the slave. This signal can be part of the SPI peripheral or implemented using a GPIO pin.
-MOSI | Master Out, Slave In | MOSI output of the Master connects to MOSI input of the Slave.
-SCLK | Serial Clock | Serial clock output from Master. Controls the transfer speed and when data are sent and read.
-MISO | Master In, Slave Out | MISO input of the Master connects to MISO output of the Slave.
-
-
-SPI API
-
-The following header files define the Application Programming Interface (API) for the SPI interface:
- - \b %Driver_SPI.h : Driver API for SPI Bus Peripheral
-
-The driver implementation is a typical part of the Device Family Pack (DFP) that supports the
-peripherals of the microcontroller family.
-
-
-Driver Functions
-
-The driver functions are published in the access struct as explained in \ref DriverFunctions
- - \ref ARM_DRIVER_SPI : access struct for SPI driver functions
-
-
-Example Code
-
-The following example code shows the usage of the SPI interface.
-
-\include SPI_Demo.c
-
-@{
-*/
-
-
-/**
-\struct ARM_DRIVER_SPI
-\details
-The functions of the SPI driver are accessed by function pointers exposed by this structure.
-Refer to \ref DriverFunctions for overview information.
-
-Each instance of a SPI interface provides such an access structure.
-The instance is identified by a postfix number in the symbol name of the access structure, for example:
- - \b Driver_SPI0 is the name of the access struct of the first instance (no. 0).
- - \b Driver_SPI1 is the name of the access struct of the second instance (no. 1).
-
-A middleware configuration setting allows connecting the middleware to a specific driver instance \b %Driver_SPIn .
-The default is \token{0}, which connects a middleware to the first instance of a driver.
-**************************************************************************************************************************/
-
-/**
-\struct ARM_SPI_CAPABILITIES
-\details
-A SPI driver can be implemented with different capabilities.
-The data fields of this structure encode the capabilities implemented by this driver.
-
-Returned by:
- - \ref ARM_SPI_GetCapabilities
-**************************************************************************************************************************/
-
-/**
-\struct ARM_SPI_STATUS
-\details
-Structure with information about the status of the SPI. The data fields encode busy flag and error flags.
-
-Returned by:
- - \ref ARM_SPI_GetStatus
-*****************************************************************************************************************/
-
-
-/**
-\typedef ARM_SPI_SignalEvent_t
-\details
-Provides the typedef for the callback function \ref ARM_SPI_SignalEvent.
-
-Parameter for:
- - \ref ARM_SPI_Initialize
-*******************************************************************************************************************/
-
-/**
-\defgroup spi_execution_status Status Error Codes
-\ingroup common_drv_gr
-\brief Negative values indicate errors (SPI has specific codes in addition to common \ref execution_status).
-\details
-The SPI driver has additional status error codes that are listed below.
-Note that the SPI driver also returns the common \ref execution_status.
-
-@{
-\def ARM_SPI_ERROR_MODE
-The \b mode requested with the function \ref ARM_SPI_Control is not supported by this driver.
-
-\def ARM_SPI_ERROR_FRAME_FORMAT
-The frame format requested with the function \ref ARM_SPI_Control is not supported by this driver.
-
-\def ARM_SPI_ERROR_DATA_BITS
-The number of data bits requested with the function \ref ARM_SPI_Control is not supported by this driver.
-
-\def ARM_SPI_ERROR_BIT_ORDER
-The bit order requested with the function \ref ARM_SPI_Control is not supported by this driver.
-
-\def ARM_SPI_ERROR_SS_MODE
-The slave select mode requested with the function \ref ARM_SPI_Control is not supported by this driver.
-@}
-*/
-
-/**
-\defgroup SPI_events SPI Events
-\ingroup spi_interface_gr
-\brief The SPI driver generates call back events that are notified via the function \ref ARM_SPI_SignalEvent.
-\details
-This section provides the event values for the \ref ARM_SPI_SignalEvent callback function.
-
-The following call back notification events are generated:
-@{
-\def ARM_SPI_EVENT_TRANSFER_COMPLETE
-\def ARM_SPI_EVENT_DATA_LOST
-\def ARM_SPI_EVENT_MODE_FAULT
-@}
-*/
-
-//
-// Functions
-//
-
-ARM_DRIVER_VERSION ARM_SPI_GetVersion (void) {
- return { 0, 0 };
-}
-/**
-\fn ARM_DRIVER_VERSION ARM_SPI_GetVersion (void)
-\details
-The function \b ARM_SPI_GetVersion returns version information of the driver implementation in \ref ARM_DRIVER_VERSION
- - API version is the version of the CMSIS-Driver specification used to implement this driver.
- - Driver version is source code version of the actual driver implementation.
-
-Example:
-\code
-extern ARM_DRIVER_SPI Driver_SPI0;
-ARM_DRIVER_SPI *drv_info;
-
-void setup_spi (void) {
- ARM_DRIVER_VERSION version;
-
- drv_info = &Driver_SPI0;
- version = drv_info->GetVersion ();
- if (version.api < 0x10A) { // requires at minimum API version 1.10 or higher
- // error handling
- return;
- }
-}
-\endcode
-**************************************************************************************************************************/
-
-ARM_SPI_CAPABILITIES ARM_SPI_GetCapabilities (void) {
- return { 0 };
-}
-/**
-\fn ARM_SPI_CAPABILITIES ARM_SPI_GetCapabilities (void)
-\details
-The function \b ARM_SPI_GetCapabilities returns information about the capabilities in this driver implementation.
-The data fields of the structure \ref ARM_SPI_CAPABILITIES encode various capabilities, for example
-supported modes.
-
-Example:
-\code
-extern ARM_DRIVER_SPI Driver_SPI0;
-ARM_DRIVER_SPI *drv_info;
-
-void read_capabilities (void) {
- ARM_SPI_CAPABILITIES drv_capabilities;
-
- drv_info = &Driver_SPI0;
- drv_capabilities = drv_info->GetCapabilities ();
- // interrogate capabilities
-
-}
-\endcode
-
-**************************************************************************************************************************/
-
-int32_t ARM_SPI_Initialize (ARM_SPI_SignalEvent_t cb_event) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_SPI_Initialize (ARM_SPI_SignalEvent_t cb_event)
-\details
-The function \b ARM_SPI_Initialize initializes the SPI interface.
-
-The parameter \em cb_event is a pointer to the \ref ARM_SPI_SignalEvent callback function; use a NULL pointer
-when no callback signals are required.
-
-The function is called when the middleware component starts operation and performs the following:
- - Initializes the resources needed for the SPI interface.
- - Registers the \ref ARM_SPI_SignalEvent callback function.
-
-
-\b Example:
- - see \ref spi_interface_gr - Driver Functions
-
-**************************************************************************************************************************/
-
-int32_t ARM_SPI_Uninitialize (void) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_SPI_Uninitialize (void)
-\details
-The function \b ARM_SPI_Uninitialize de-initializes the resources of SPI interface.
-
-It is called when the middleware component stops operation and releases the software resources used by the interface.
-**************************************************************************************************************************/
-
-int32_t ARM_SPI_PowerControl (ARM_POWER_STATE state) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_SPI_PowerControl (ARM_POWER_STATE state)
-\details
-The function \b ARM_SPI_PowerControl controls the power modes of the SPI interface.
-
-The parameter \em state sets the operation and can have the following values:
- - \ref ARM_POWER_FULL : set-up peripheral for data transfers, enable interrupts (NVIC) and optionally DMA.
- Can be called multiple times. If the peripheral is already in this mode the function performs
- no operation and returns with \ref ARM_DRIVER_OK.
- - \ref ARM_POWER_LOW : may use power saving. Returns \ref ARM_DRIVER_ERROR_UNSUPPORTED when not implemented.
- - \ref ARM_POWER_OFF : terminates any pending data transfers, disables peripheral, disables related interrupts and DMA.
-
-Refer to \ref CallSequence for more information.
-**************************************************************************************************************************/
-
-int32_t ARM_SPI_Send (const void *data, uint32_t num) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_SPI_Send (const void *data, uint32_t num)
-\details
-This function \b ARM_SPI_Send is used to send data to the SPI transmitter (received data is ignored).
-
-The parameter \em data specifies the data buffer. \n
-The parameter \em num specifies the number of items to send. \n
-The item size is defined by the data type, which depends on the configured number of data bits.
-
-Data type is:
- - \em uint8_t when configured for 1..8 data bits
- - \em uint16_t when configured for 9..16 data bits
- - \em uint32_t when configured for 17..32 data bits
-
-Calling the function \b ARM_SPI_Send only starts the send operation.
-When in slave mode, the operation is only registered and started when the master starts the transfer.
-The function is non-blocking and returns as soon as the driver has started the operation
-(driver typically configures DMA or the interrupt system for continuous transfer).
-During the operation it is not allowed to call this function or any other data transfer function again.
-Also the data buffer must stay allocated and the contents of unsent data must not be modified.
-When send operation is completed (requested number of items sent), the \ref ARM_SPI_EVENT_TRANSFER_COMPLETE event is generated.
-Progress of send operation can also be monitored by reading the number of items already sent by calling \ref ARM_SPI_GetDataCount.
-
-Status of the transmitter can also be monitored by calling the \ref ARM_SPI_GetStatus and checking the \em busy data field,
-which indicates if transmission is still in progress or pending.
-
-When in master mode and configured to monitor slave select and the slave select gets deactivated during transfer,
-then the SPI mode changes to inactive and the \ref ARM_SPI_EVENT_MODE_FAULT event is generated (instead of \ref ARM_SPI_EVENT_TRANSFER_COMPLETE).
-
-When in slave mode but send/receive/transfer operation is not started and data is sent/requested by the master,
-then the \ref ARM_SPI_EVENT_DATA_LOST event is generated.
-
-Send operation can be aborted by calling \ref ARM_SPI_Control with \ref ARM_SPI_ABORT_TRANSFER as the control parameter.
-**************************************************************************************************************************/
-
-int32_t ARM_SPI_Receive (void *data, uint32_t num) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_SPI_Receive (void *data, uint32_t num)
-\details
-The function \b ARM_SPI_Receive is used to receive data
-(transmits the default value as specified by \ref ARM_SPI_Control with \ref ARM_SPI_SET_DEFAULT_TX_VALUE as control parameter).
-
-The parameter \em data specifies the data buffer. \n
-The parameter \em num specifies the number of items to receive. \n
-The item size is defined by the data type, which depends on the configured number of data bits.
-
-Data type is:
- - \em uint8_t when configured for 1..8 data bits
- - \em uint16_t when configured for 9..16 data bits
- - \em uint32_t when configured for 17..32 data bits
-
-Calling the function \b ARM_SPI_Receive only starts the receive operation.
-The function is non-blocking and returns as soon as the driver has started the operation
-(driver typically configures DMA or the interrupt system for continuous transfer).
-When in slave mode, the operation is only registered and started when the master starts the transfer.
-During the operation it is not allowed to call this function or any other data transfer function again. Also the data buffer must stay allocated.
-When receive operation is completed (requested number of items received), the \ref ARM_SPI_EVENT_TRANSFER_COMPLETE event is generated.
-Progress of receive operation can also be monitored by reading the number of items already received by calling \ref ARM_SPI_GetDataCount.
-
-Status of the receiver can also be monitored by calling the \ref ARM_SPI_GetStatus and checking the \em busy data field,
-which indicates if reception is still in progress or pending.
-
-When in master mode and configured to monitor slave select and the slave select gets deactivated during transfer,
-then the SPI mode changes to inactive and the \ref ARM_SPI_EVENT_MODE_FAULT event is generated (instead of \ref ARM_SPI_EVENT_TRANSFER_COMPLETE).
-
-When in slave mode but send/receive/transfer operation is not started and data is sent/requested by the master,
-then the \ref ARM_SPI_EVENT_DATA_LOST event is generated.
-
-Receive operation can be aborted by calling \ref ARM_SPI_Control with \ref ARM_SPI_ABORT_TRANSFER as the control parameter.
-**************************************************************************************************************************/
-
-int32_t ARM_SPI_Transfer (const void *data_out, void *data_in, uint32_t num) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_SPI_Transfer (const void *data_out, void *data_in, uint32_t num)
-\details
-The function \b ARM_SPI_Transfer transfers data via SPI. It synchronously sends data to the SPI transmitter and receives data from the SPI receiver.
-
-The parameter \em data_out is a pointer to the buffer with data to send. \n
-The parameter \em data_in is a pointer to the buffer which receives data. \n
-The parameter \em num specifies the number of items to transfer. \n
-The item size is defined by the data type which depends on the configured number of data bits.
-
-Data type is:
- - \em uint8_t when configured for 1..8 data bits
- - \em uint16_t when configured for 9..16 data bits
- - \em uint32_t when configured for 17..32 data bits
-
-Calling the function \b ARM_SPI_Transfer only starts the transfer operation.
-The function is non-blocking and returns as soon as the driver has started the operation
-(driver typically configures DMA or the interrupt system for continuous transfer).
-When in slave mode, the operation is only registered and started when the master starts the transfer.
-During the operation it is not allowed to call this function or any other data transfer function again.
-Also the data buffers must stay allocated and the contents of unsent data must not be modified.
-When transfer operation is completed (requested number of items transferred), the \ref ARM_SPI_EVENT_TRANSFER_COMPLETE event is generated.
-Progress of transfer operation can also be monitored by reading the number of items already transferred by calling \ref ARM_SPI_GetDataCount.
-
-Status of the transmitter and receiver can also be monitored by calling the \ref ARM_SPI_GetStatus and checking the \em busy flag.
-
-When in master mode and configured to monitor slave select and the slave select gets deactivated during transfer,
-then the SPI mode changes to inactive and the \ref ARM_SPI_EVENT_MODE_FAULT event is generated (instead of \ref ARM_SPI_EVENT_TRANSFER_COMPLETE).
-
-When in slave mode but send/receive/transfer operation is not started and data is sent/requested by the master,
- then the \ref ARM_SPI_EVENT_DATA_LOST event is generated.
-
-Transfer operation can also be aborted by calling \ref ARM_SPI_Control with \ref ARM_SPI_ABORT_TRANSFER as the control parameter.
-**************************************************************************************************************************/
-
-uint32_t ARM_SPI_GetDataCount (void) {
- return 0;
-}
-/**
-\fn uint32_t ARM_SPI_GetDataCount (void)
-\details
-The function \b ARM_SPI_GetDataCount returns the number of currently transferred data items
-during \ref ARM_SPI_Send, \ref ARM_SPI_Receive and \ref ARM_SPI_Transfer operation.
-*****************************************************************************************************************/
-
-int32_t ARM_SPI_Control (uint32_t control, uint32_t arg) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_SPI_Control (uint32_t control, uint32_t arg)
-\details
-The function \b ARM_SPI_Control controls the SPI interface settings and executes various operations.
-
-The parameter \em control is a bit mask that specifies various operations.
- - Controls form different categories can be ORed.
- - If one control is omitted, then the default value of that category is used.
- - Miscellaneous controls cannot be combined.
-
-The parameter \em arg provides (depending on the parameter \em control) additional information, for example the Bus Speed.
-
-
-
- Parameter \em control
- Bit
- Category
- Description
- \ref ARM_SPI_MODE_INACTIVE
- 0..7
- \anchor spi_mode_tab Mode Controls
- Set SPI to inactive.
- \ref ARM_SPI_MODE_MASTER
- Set the SPI Master (Output on MOSI, and the Input on MISO); \em arg = Bus Speed in \token{bps}
- \ref ARM_SPI_MODE_SLAVE
- Set the SPI Slave (Output on MISO, and the Input on MOSI)
- \ref ARM_SPI_CPOL0_CPHA0 (default)
- 8..11
- Clock Polarity CPOL=\token{0} and CPHA=\token{0}: Clock Polarity 0, Clock Phase 0
- \ref ARM_SPI_CPOL0_CPHA1
- CPOL=\token{0} and CPHA=\token{1}: Clock Polarity 0, Clock Phase 1
- \ref ARM_SPI_CPOL1_CPHA0
- CPOL=\token{1} and CPHA=\token{0}: Clock Polarity 1, Clock Phase 0
- \ref ARM_SPI_CPOL1_CPHA1
- CPOL=\token{1} and CPHA=\token{1}: Clock Polarity 1, Clock Phase 1
- \ref ARM_SPI_TI_SSI
- Specifies that the frame format corresponds to the Texas Instruments Frame Format
- \ref ARM_SPI_MICROWIRE
- Specifies that the frame format corresponds to the National Semiconductor Microwire Frame Format
- \ref ARM_SPI_DATA_BITS(n)
- 12..17
- Data Bits
- Set the number of bits per SPI frame; range for \em n = \token{1..32}.
- This is the minimum required parameter.
- \ref ARM_SPI_MSB_LSB (default)
- 18
- Bit Order
- Set the bit order from MSB to LSB
- \ref ARM_SPI_LSB_MSB
- Set the bit order from LSB to MSB
- \ref ARM_SPI_SS_MASTER_UNUSED (default)
- 19..21
- Slave Select
-
- Must be used with the corresponding master or slave controls from category Mode Controls
- Slave Select
-
- Set the Slave Select mode for the master to Not used . Used with Mode Control ARM_SPI_MODE_MASTER.
- Master does not drive or monitor the SS line. For example, when connecting to a single slave,
- which has the SS line connected to a fixed low level.
- \ref ARM_SPI_SS_MASTER_SW
- Set the Slave Select mode for the master to Software controlled . Used with Mode Control ARM_SPI_MODE_MASTER.
- The Slave Select line is configured as output and controlled via the Miscellaneous Control \ref ARM_SPI_CONTROL_SS.
- By default, the line it is not active (high), and is not affected by transfer-, send-, or receive functions.
- \ref ARM_SPI_SS_MASTER_HW_OUTPUT
- Set the Slave Select mode for the master to Hardware controlled Output . Used with Mode Control ARM_SPI_MODE_MASTER.
- The Slave Select line is configured as output and controlled by hardware.
- The line gets activated or deactivated automatically by the hardware for transfers and is not controlled by the Miscellaneous Control \ref ARM_SPI_CONTROL_SS.
- When exactly the line is activated or deactivated is hardware dependent. Typically, the hardware will activate the line before starting the transfer
- and deactivate it after the transfer completes. Some hardware will keep the line active as long as the SPI stays master.
- \note Some devices require that the SS signal is strictly defined regarding transfers. Refer to the documentation of your device.
-
- \ref ARM_SPI_SS_MASTER_HW_INPUT
- Set the Slave Select mode for the master to Hardware monitored Input . Used with Mode Control ARM_SPI_MODE_MASTER.
- Used in multi-master configuration where a master does not drive the Slave Select when driving the bus, but rather monitors it.
- When another master activates this line, the active master backs off. This is called Mode Fault. Slave Select is configured as input
- and hardware only monitors the line. When the line is activated externally while we are master,
- it presents a Mode Fault (\ref ARM_SPI_EVENT_MODE_FAULT) and the SPI switches to inactive mode.
-
-\ref ARM_SPI_SS_SLAVE_HW (default)
- Set the Slave Select mode for the slave to Hardware monitored . Used with Mode Control ARM_SPI_MODE_SLAVE.
- Hardware monitors the Slave Select line and accepts transfers only when the line is active. Transfers are ignored while the Slave Select line is inactive.
- \ref ARM_SPI_SS_SLAVE_SW
- Set the Slave Select mode for the slave to Software controlled . Used with Mode Control ARM_SPI_MODE_SLAVE.
- Used only when the Slave Select line is not used. For example, when a single master and slave are connected in the system
- then the Slave Select line is not needed. Software controls if the slave is responding or not (by default it is not responding).
- Software enables or disables transfers by using the Miscellaneous Control \ref ARM_SPI_CONTROL_SS.
- \ref ARM_SPI_SET_BUS_SPEED
- 0..21
- Miscellaneous Controls
- Set the bus speed; \em arg= Bus Speed in \token{bps}
- \ref ARM_SPI_GET_BUS_SPEED
- Get the bus speed; Return values >= \token{0} represent the bus speed in \token{bps}. Negative values are \ref spi_execution_status.
- \ref ARM_SPI_SET_DEFAULT_TX_VALUE
- Set the default transmission value; the parameter \em arg sets the value
- \ref ARM_SPI_CONTROL_SS
- Control the Slave Select signal (SS); the values for the parameter \em arg are: \token{ARM_SPI_SS_INACTIVE; ARM_SPI_SS_ACTIVE}
- \ref ARM_SPI_ABORT_TRANSFER
- Abort the current data transfer
-
-
-
-
-\b Example
-
-\code
- extern ARM_DRIVER_SPI Driver_SPI0;
-
- // configure: SPI master | clock polarity=1, clock phase=1 | bits per frame=16 | bus speed : 1000000
- status = Driver_SPI0.Control(ARM_SPI_MODE_MASTER |
- ARM_SPI_CPOL1_CPHA1 |
- ARM_SPI_DATA_BITS(16), 1000000);
-\endcode
-*****************************************************************************************************************/
-
-ARM_SPI_STATUS ARM_SPI_GetStatus (void) {
- return { 0 };
-}
-/**
-\fn ARM_SPI_STATUS ARM_SPI_GetStatus (void)
-\details
-The function \b ARM_SPI_GetStatus returns the current SPI interface status.
-*****************************************************************************************************************/
-
-void ARM_SPI_SignalEvent (uint32_t event) {
- // function body
-}
-/**
-\fn void ARM_SPI_SignalEvent (uint32_t event)
-\details
-The function \b ARM_SPI_SignalEvent is a callback function registered by the function \ref ARM_SPI_Initialize.
-
-The parameter \em event indicates one or more events that occurred during driver operation.
-Each event is encoded in a separate bit and therefore it is possible to signal multiple events within the same call.
-
-Not every event is necessarily generated by the driver. This depends on the implemented capabilities stored in the
-data fields of the structure \ref ARM_SPI_CAPABILITIES, which can be retrieved with the function \ref ARM_SPI_GetCapabilities.
-
-The following events can be generated:
-
-
-
- Parameter \em event Bit Description
- supported when ARM_SPI_CAPABILITIES
-
-
- \ref ARM_SPI_EVENT_TRANSFER_COMPLETE 0 Occurs after call to \ref ARM_SPI_Send, \ref ARM_SPI_Receive,
- or \ref ARM_SPI_Transfer
- to indicate that all the data has been transferred.
- The driver is ready for the next transfer operation.
- always supported
-
-
- \ref ARM_SPI_EVENT_DATA_LOST 1 Occurs in slave mode when data is requested/sent by master
- but send/receive/transfer operation has not been started and
- indicates that data is lost. Occurs also in master mode when
- driver cannot transfer data fast enough.
- always supported
-
-
- \ref ARM_SPI_EVENT_MODE_FAULT 2 Occurs in master mode when Slave Select is deactivated and
- indicates Master Mode Fault.
- The driver is ready for the next transfer operation.
- data field \em event_mode_fault = \token{1}
-
-
-**************************************************************************************************************************/
-
-
-/**
-\defgroup SPI_control SPI Control Codes
-\ingroup spi_interface_gr
-\brief Many parameters of the SPI driver are configured using the \ref ARM_SPI_Control function.
-\details
-@{
-The various SPI control codes define:
-
- - \ref spi_mode_ctrls specifies SPI mode
- - \ref spi_frame_format_ctrls defines the frame format
- - \ref spi_data_bits_ctrls defines the number of data bits
- - \ref spi_bit_order_ctrls defines the bit order
- - \ref spi_slave_select_mode_ctrls specifies slave select mode
- - \ref spi_misc_ctrls specifies additional miscellaneous controls
-
-Refer to the \ref ARM_SPI_Control function for further details.
-*/
-
-/**
-\defgroup spi_mode_ctrls SPI Mode Controls
-\ingroup SPI_control
-\brief Specifies SPI mode.
-\details
-@{
-\def ARM_SPI_MODE_INACTIVE
-\sa ARM_SPI_Control
-\def ARM_SPI_MODE_MASTER
-\sa ARM_SPI_Control
-\def ARM_SPI_MODE_SLAVE
-\sa ARM_SPI_Control
-@}
-*/
-
-/**
-\defgroup spi_frame_format_ctrls SPI Frame Format
-\ingroup SPI_control
-\brief Defines the frame format.
-\details
-@{
-\def ARM_SPI_CPOL0_CPHA0
-\sa ARM_SPI_Control
-\def ARM_SPI_CPOL0_CPHA1
-\sa ARM_SPI_Control
-\def ARM_SPI_CPOL1_CPHA0
-\sa ARM_SPI_Control
-\def ARM_SPI_CPOL1_CPHA1
-\sa ARM_SPI_Control
-\def ARM_SPI_TI_SSI
-\sa ARM_SPI_Control
-\def ARM_SPI_MICROWIRE
-\sa ARM_SPI_Control
-@}
-*/
-
-/**
-\defgroup spi_data_bits_ctrls SPI Data Bits
-\ingroup SPI_control
-\brief Defines the number of data bits.
-\details
-@{
-\def ARM_SPI_DATA_BITS(n)
-\sa ARM_SPI_Control
-@}
-*/
-
-/**
-\defgroup spi_bit_order_ctrls SPI Bit Order
-\ingroup SPI_control
-\brief Defines the bit order.
-\details
-@{
-\def ARM_SPI_MSB_LSB
-\sa ARM_SPI_Control
-\def ARM_SPI_LSB_MSB
-\sa ARM_SPI_Control
-@}
-*/
-
-/**
-\defgroup spi_slave_select_mode_ctrls SPI Slave Select Mode
-\ingroup SPI_control
-\brief Specifies SPI slave select mode.
-\details
-\b SPI \b Slave \b Select \b Mode configures the behavior of the \b Slave \b Select \b (SS) signal. The configuration is
-separate for \b Master (ARM_SPI_SS_MASTER_*) and for \b Slave (\ref ARM_SPI_SS_SLAVE_HW, \ref ARM_SPI_SS_SLAVE_SW). The
-active configuration depends on the current state (Master/Slave).
-
-@{
-\def ARM_SPI_SS_MASTER_UNUSED
-An SPI master does not drive or monitor the SS line. For example, when connecting to a single slave, the SS line can be connected
-to a fixed low level.
-\sa ARM_SPI_Control
-\def ARM_SPI_SS_MASTER_SW
-SS is configured as an output and controlled via \ref ARM_SPI_Control (\ref ARM_SPI_CONTROL_SS). By default, it is not active
-(high). It is activated (low) by \ref ARM_SPI_Control (\ref ARM_SPI_CONTROL_SS, \ref ARM_SPI_SS_ACTIVE) and deactivated by
-\ref ARM_SPI_Control (\ref ARM_SPI_CONTROL_SS, \ref ARM_SPI_SS_INACTIVE). It is not affected by transfer/send/receive
-functions.
-\sa ARM_SPI_Control
-\def ARM_SPI_SS_MASTER_HW_OUTPUT
-Here, SS is configured as an output. It will be automatically activated/deactivated for the transfers by hardware (not
-controlled by \ref ARM_SPI_Control (\ref ARM_SPI_CONTROL_SS)). The activation/deactivation of the line is completely hardware
-dependent. Typically, the hardware will activate it before starting a transfer and deactivate it after a transfer completes.
-Some hardware will keep the line active as long as the SPI stays master. Due to different hardware behavior, this mode is
-typically not useful because certain devices require that the SS signal is strictly defined with regards to transfers.
-\sa ARM_SPI_Control
-\def ARM_SPI_SS_MASTER_HW_INPUT
-This is normally used in a multi-master configuration, where a master does not drive the SS line when driving the bus but only
-monitors it. When another master activates this line, the active master backs off. This is called \b mode \b fault. SS is
-configured as input and the hardware only monitors it. When it is externally deactivated while being the master, it presents
-a mode fault and the SPI switches to \b inactive mode.
-\sa ARM_SPI_Control
-\def ARM_SPI_SS_SLAVE_HW
-Hardware monitors the SS line and accepts transfers only when SS line is activate. Transfers while SS is not active are
-ignored.
-\sa ARM_SPI_Control
-\def ARM_SPI_SS_SLAVE_SW
-Used only when SS line is not used. For example, when a single master and slave are connected in a system, the SS line is not
-needed (reduces the number of lines and pins used). Slave responses are controlled by software (by default, it is not
-responding). Software enables/disables transfers by calling \ref ARM_SPI_Control (\ref ARM_SPI_CONTROL_SS, \ref ARM_SPI_SS_ACTIVE / \ref ARM_SPI_SS_INACTIVE).
-\sa ARM_SPI_Control
-@}
-*/
-
-/**
-\defgroup spi_misc_ctrls SPI Miscellaneous Controls
-\ingroup SPI_control
-\brief Specifies additional miscellaneous controls.
-\details
-@{
-\def ARM_SPI_SET_BUS_SPEED
-\sa ARM_SPI_Control
-\def ARM_SPI_GET_BUS_SPEED
-\sa ARM_SPI_Control
-\def ARM_SPI_SET_DEFAULT_TX_VALUE
-\sa ARM_SPI_Control
-\def ARM_SPI_CONTROL_SS
-\sa ARM_SPI_Control
-\def ARM_SPI_ABORT_TRANSFER
-\sa ARM_SPI_Control
-@}
-*/
-
-/**
-@}
-*/
-// end group SPI_control
-
-/**
-@}
-*/
-// End SPI Interface
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/Driver_Storage.c b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/Driver_Storage.c
deleted file mode 100644
index 5100e46..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/Driver_Storage.c
+++ /dev/null
@@ -1,770 +0,0 @@
-/**
-\defgroup storage_interface_gr Storage Interface
-\brief Driver API for Storage Device Interface (%Driver_Storage.h)
-\details
-This is an abstraction for a storage controller. It offers an interface to
-access an address space of storage locations, comprising APIs for
-initialization, erase, access, program, and status-fetch operations. It also
-offers APIs to iterate over the available Storage Blocks (\ref
-ARM_STORAGE_BLOCK), allowing the discovery of block attributes such as
-write/erase granularities. Using the Storage abstraction, it becomes possible to
-write generic algorithms, such as block copy, to operate on any conforming
-storage device.
-
-\note The storage abstraction layer is not responsible for storage management.
-Algorithms such as block-allocation, wear-leveling, erase-before-write and other
-storage-management policies are the responsibility of modules external to the
-storage abstraction layer. In essence, the storage interface is the lowest
-abstraction upon which block management policies can be implemented.
-
-Here's a picture to help locate the storage abstraction in the software stack.
-The part below the box labeled 'Storage abstraction layer' is implemented by a
-storage driver.
-
-\image html storage_sw_stack.png
-
-Storage API
-
-The following header files define the Application Programming Interface (API) for the Flash interface:
- - \b %Driver_Storage.h : Driver API for Storage Device Interface
-
-
-Driver Functions
-
-The driver functions are published in the access struct as explained in \ref StorageDriverFunctions
- - \ref ARM_DRIVER_STORAGE : access struct for Storage driver functions
-
-A sample use for the driver can be found at: \ref SampleUseOfStorageDriver
-*******************************************************************************************************************/
-
-
-
-/**
-\addtogroup storage_interface_gr
-@{
-*******************************************************************************************************************/
-
-/**
-\struct ARM_STORAGE_BLOCK_ATTRIBUTES
-Contained in:
- - \ref ARM_STORAGE_BLOCK
-*******************************************************************************************************************/
-
-/**
-\struct ARM_STORAGE_BLOCK
-\details Storage blocks combine to make up the address map of a storage controller.
-*******************************************************************************************************************/
-
-/**
-\struct ARM_STORAGE_INFO
-\details
-It describes the characteristics of a Storage device. This includes total
-storage, programming size, a default value for erased memory etc. This
-information can be obtained from the Storage device datasheet and is used by the
-middleware in order to properly interact with the Storage device.
-
-Total available storage (in bytes) is contained in \em total_storage. Minimum
-programming size (in bytes) is described by \em program_unit (applicable only if
-the \em programmable attribute is set for a block). It defines the granularity
-for programming data. The offset of the start of a program-range and the size
-should also be aligned with \em program_unit.
-\note: setting \em program_unit to 0 has the effect of disabling the size and
-alignment restrictions (setting it to 1 also has the same effect).
-
-Optimal programming page-size (in bytes) is specified by \em
-optimal_program_unit. Some storage controllers have internal buffers into which
-to receive data. Writing in chunks of \em optimal_program_unit would achieve
-maximum programming speed. Like with \em program_unit, this is applicable only
-if the \em programmable attribute is set for the underlying storage block(s).
-
-\em program_cycles is a measure of endurance for reprogramming.
-A value of \em ARM_STORAGE_PROGRAM_CYCLES_INFINITE may be used to signify
-infinite or unknown endurance.
-
-Contents of erased memory is specified by the \em erased_value. It is usually
-\token{1} to indicate erased bytes with state 0xFF.
-
-\em memory_mapped can be set to \token{1} to indicate that the storage device
-has a mapping onto the processor's memory address space.
-\note: For a memory-mapped block which isn't erasable but is programmable,
-writes should be possible directly to the memory-mapped storage without going
-through the \ref ARM_Storage_ProgramData operation.
-
-The field \em programmability holds a value to indicate storage programmability.
-Similarly, \em retention_level holds a for encoding data-retention levels for
-all storage blocks.
-
-\note
-These fields serve a different purpose than the ones contained in
-\ref ARM_STORAGE_CAPABILITIES, which is another structure containing device-level
-metadata. ARM_STORAGE_CAPABILITIES describes the API capabilities, whereas
-ARM_STORAGE_INFO describes the device. Furthermore ARM_STORAGE_CAPABILITIES fits
-within a single word, and is designed to be passed around by value;
-ARM_STORAGE_INFO, on the other hand, contains metadata which doesn't fit into a
-single word and requires the use of pointers to be moved around.
-
-Returned by:
- - \ref ARM_Storage_GetInfo
-*******************************************************************************************************************/
-
-/**
-\struct ARM_DRIVER_STORAGE
-\details
-This is the set of operations constituting the Storage driver. Their
-implementation is platform-specific, and needs to be supplied by the porting
-effort. The functions of the Storage driver are accessed by function pointers
-exposed by this structure. Refer to \ref StorageDriverFunctions for overview
-information.
-
-Each instance of a Storage interface provides such an access structure.
-The instance is identified by a postfix number in the symbol name of the access structure, for example:
- - \b Driver_Storage0 is the name of the access struct of the first instance (no. 0).
- - \b Driver_Storage1 is the name of the access struct of the second instance (no. 1).
-
-A middleware configuration setting allows connecting the middleware to a specific driver instance \b %Driver_Flashn .
-The default is \token{0}, which connects a middleware to the first instance of a driver.
-*******************************************************************************************************************/
-
-/**
-\defgroup StorageDriverFunctions Use of Storage APIs
-
-Function pointers within \ref ARM_DRIVER_STORAGE form the set of operations
-constituting the Storage driver. Their implementation is platform-specific, and
-needs to be supplied by the porting effort.
-
-Some of these APIs will always operate synchronously:
-- \ref ARM_Storage_GetVersion
-- \ref ARM_Storage_GetCapabilities
-- \ref ARM_Storage_GetStatus
-- \ref ARM_Storage_GetInfo
-- \ref ARM_Storage_ResolveAddress
-- \ref ARM_Storage_GetNextBlock and
-- \ref ARM_Storage_GetBlock.
-
-This means that control returns to the caller with a relevant status code only after the completion of the operation (or
-the discovery of a failure condition).
-
-The remainder of the APIs:
-- \ref ARM_Storage_Initialize
-- \ref ARM_Storage_Uninitialize
-- \ref ARM_Storage_PowerControl
-- \ref ARM_Storage_ReadData
-- \ref ARM_Storage_ProgramData
-- \ref ARM_Storage_Erase and
-- \ref ARM_Storage_EraseAll
-
-can function asynchronously if the underlying controller supports it; that is if ARM_STORAGE_CAPABILITIES::asynchronous_ops
-is set. In the case of asynchronous operation, the invocation returns early (with ARM_DRIVER_OK) and results in a completion
-callback later. If ARM_STORAGE_CAPABILITIES::asynchronous_ops is not set, then all such APIs execute synchronously, and
-control returns to the caller with a status code only after the completion of the operation (or the discovery of a failure
-condition).
-
-If ARM_STORAGE_CAPABILITIES::asynchronous_ops is set, a storage driver may
-still choose to execute asynchronous operations in a synchronous manner. If
-so, the driver returns a positive value to indicate successful synchronous
-completion (or an error code in case of failure) and no further invocation of
-completion callback should be expected. The expected return value for
-synchronous completion of such asynchronous operations varies depending on
-the operation. For operations involving data access, it often equals the
-amount of data transferred or affected. For non data-transfer operations,
-such as EraseAll or Initialize, it is usually 1.
-
-Here's a code snippet to suggest how asynchronous APIs might be used by
-callers to handle both synchronous and asynchronous execution by the
-underlying storage driver:
-\code
- ASSERT(ARM_DRIVER_OK == 0); // this is a precondition; it doesn't need to be put in code
-
- int32_t returnValue = drv->asynchronousAPI(...);
-
- if (returnValue < ARM_DRIVER_OK) {
- // handle error.
-
- } else if (returnValue == ARM_DRIVER_OK) {
- ASSERT(drv->GetCapabilities().asynchronous_ops == 1);
- // handle early return from asynchronous execution; remainder of the work is done in the callback handler.
-
- } else {
- ASSERT(returnValue == EXPECTED_RETURN_VALUE_FOR_SYNCHRONOUS_COMPLETION);
- // handle synchronous completion.
- }
-\endcode
-
-THis example is mixing synchronous and asynchronous APIs: \ref SampleUseOfStorageDriver
-*******************************************************************************************************************/
-
-/**
-\struct ARM_STORAGE_CAPABILITIES
-\details
-A Storage driver can be implemented with different capabilities. The data fields
-of this struct encode the API capabilities implemented by this driver.
-
-The element \em asynchronous_ops indicates if APIs like initialize, read, erase,
-program, etc. can operate in asynchronous mode. Having this bit set to 1 means
-that the driver is capable of launching asynchronous operations; command
-completion for asynchronous operations is signaled by the invocation of a
-completion callback. If set to 1, drivers may still complete asynchronous
-operations synchronously as necessary--in which case they return a positive
-error code to indicate synchronous completion. If \em asynchronous_ops is not
-set, then all such APIs execute synchronously, and control returns to the caller
-with a status code only after the completion of the operation (or the discovery
-of a failure condition).
-
-The element \em erase_all specifies that the \ref ARM_Storage_EraseAll function
-is supported. Typically full chip erase is much faster than erasing the whole
-device using \em ARM_Storage_Erase.
-
-Returned by:
- - \ref ARM_Storage_GetCapabilities
-
-\note
-This data structure is designed to fit within a single word so that it can be
-fetched cheaply using a call to driver->GetCapabilities().
-*******************************************************************************************************************/
-
-/**
-\struct ARM_STORAGE_STATUS
-\details
-Structure with information about the status of the Storage device.
-
-The flag \em busy indicates that the driver is busy executing read/program/erase operation.
-
-The flag \em error flag is cleared on start of read/program/erase operation and is set at the end of the current operation in case of error.
-
-Returned by:
- - \ref ARM_Storage_GetStatus
-*****************************************************************************************************************/
-
-/**
-\enum ARM_STORAGE_OPERATION
-\details
-Command opcodes for the Storage interface. Completion callbacks use these codes
-to refer to completing commands. Refer to \ref ARM_Storage_Callback_t.
-*****************************************************************************************************************/
-
-/**
-\typedef ARM_Storage_Callback_t
-\details
-Provides the typedef for the callback function \ref ARM_Storage_Callback_t.
-
-\param [in] status
- A code to indicate the status of the completed operation. For data
- transfer operations, the status field is overloaded in case of
- success to return the count of bytes successfully transferred; this
- can be done safely because error codes are negative values.
-
-\param [in] operation
- The command op-code. This value isn't essential, but it is expected that
- this information could be a quick and useful filter for the handler.
-
-Parameter for:
- - \ref ARM_Storage_Initialize
-*******************************************************************************************************************/
-
-
-//
-// Functions
-//
-
-ARM_DRIVER_VERSION ARM_Storage_GetVersion (void) {
- return { 0, 0 };
-}
-/**
-\fn ARM_DRIVER_VERSION ARM_Storage_GetVersion (void)
-\details
-The function \b ARM_Storage_GetVersion returns version information of the driver implementation in \ref ARM_DRIVER_VERSION.
- - API version is the version of the CMSIS-Driver specification used to implement this driver.
- - Driver version is source code version of the actual driver implementation.
-
-Example:
-\code
-extern ARM_DRIVER_STORAGE *drv_info;
-
-void read_version (void) {
- ARM_DRIVER_VERSION version;
-
- version = drv_info->GetVersion ();
- if (version.api < 0x10A) { // requires at minimum API version 1.10 or higher
- // error handling
- return;
- }
-}
-\endcode
-
-\note This API returns synchronously--it does not result in an invocation
- of a completion callback.
-
-\note The function GetVersion() can be called any time to obtain the
- required information from the driver (even before initialization). It
- always returns the same information.
-*******************************************************************************************************************/
-
-ARM_STOR_CAPABILITIES ARM_Storage_GetCapabilities (void) {
- return { 0 };
-}
-/**
-\fn ARM_STORAGE_CAPABILITIES ARM_Storage_GetCapabilities (void)
-
-\details
-The function \b ARM_Storage_GetCapabilities returns information about
-capabilities in this driver implementation. The data fields of the struct
-ARM_STORAGE_CAPABILITIES encode various capabilities, for example if the device
-is able to execute operations asynchronously.
-
-Example:
-\code
-extern ARM_DRIVER_STORAGE *drv_info;
-
-void read_capabilities (void) {
- ARM_STORAGE_CAPABILITIES drv_capabilities;
-
- drv_capabilities = drv_info->GetCapabilities ();
- // interrogate capabilities
-
-}
-\endcode
-
-\note This API returns synchronously--it does not result in an invocation
- of a completion callback.
-
-\note The function GetCapabilities() can be called any time to obtain the
- required information from the driver (even before initialization). It
- always returns the same information.
-*******************************************************************************************************************/
-
-int32_t ARM_Storage_Initialize (ARM_Storage_Callback_t callback) {
- return 0;
-}
-/**
-\fn int32_t ARM_Storage_Initialize (ARM_Storage_Callback_t callback)
-\details
-The function \b ARM_Storage_Initialize is called when the middleware component starts
-operation. In addition to bringing the controller to a ready state,
-Initialize() receives a callback handler to be invoked upon completion of
-asynchronous operations.
-
-ARM_Storage_Initialize() needs to be called explicitly before
-powering the peripheral using ARM_Storage_PowerControl(), and before initiating other
-accesses to the storage controller.
-
-The function performs the following operations:
- - Initializes the resources needed for the Storage interface.
- - Registers the \ref ARM_Storage_Callback_t callback function.
-
-To start working with a peripheral the functions ARM_Storage_Initialize and ARM_Storage_PowerControl() need to be called in this order:
-\code
- drv->Initialize (...); // Allocate I/O pins
- drv->PowerControl (ARM_POWER_FULL); // Power up peripheral, setup IRQ/DMA
-\endcode
-
-- ARM_Storage_Initialize() typically allocates the I/O resources (pins) for the
- peripheral. The function can be called multiple times; if the I/O resources
- are already initialized it performs no operation and just returns with
- ARM_DRIVER_OK.
-
-- ARM_Storage_PowerControl (ARM_POWER_FULL) sets the peripheral registers including
- interrupt (NVIC) and optionally DMA. The function can be called multiple
- times; if the registers are already set it performs no operation and just
- returns with ARM_DRIVER_OK.
-
-To stop working with a peripheral the functions ARM_Storage_PowerControl() and ARM_Storage_Uninitialize() need to be called in this order:
-\code
- drv->PowerControl (ARM_POWER_OFF); // Terminate any pending transfers, reset IRQ/DMA, power off peripheral
- drv->Uninitialize (...); // Release I/O pins
-\endcode
-
-The functions ARM_Storage_PowerControl() and ARM_Storage_Uninitialize() always execute and can be used
-to put the peripheral into a Safe State, for example after any data
-transmission errors. To restart the peripheral in an error condition,
-you should first execute the Stop Sequence and then the Start Sequence.
-
-\note This API may execute asynchronously if
- ARM_STORAGE_CAPABILITIES::asynchronous_ops is set. Asynchronous
- execution is optional even if 'asynchronous_ops' is set.
-*******************************************************************************************************************/
-
-int32_t ARM_Storage_Uninitialize (void) {
- return 0;
-}
-/**
-\fn int32_t ARM_Storage_Uninitialize (void)
-\details
-It is called when the middleware component stops operation, and wishes to
-release the software resources used by the interface.
-
-\note This API may execute asynchronously if
- ARM_STORAGE_CAPABILITIES::asynchronous_ops is set. Asynchronous
- execution is optional even if 'asynchronous_ops' is set.
-*******************************************************************************************************************/
-
-int32_t ARM_Storage_PowerControl (ARM_POWER_STATE state) {
- return 0;
-}
-/**
-\fn int32_t ARM_Storage_PowerControl (ARM_POWER_STATE state)
-\details
-The function \b ARM_Storage_PowerControl operates the power modes of the Storage interface.
-
-To start working with a peripheral the functions Initialize and PowerControl need to be called in this order:
-\code
- drv->Initialize (...); // Allocate I/O pins
- drv->PowerControl (ARM_POWER_FULL); // Power up peripheral, setup IRQ/DMA
-\endcode
-
-- ARM_Storage_Initialize() typically allocates the I/O resources (pins) for the
- peripheral. The function can be called multiple times; if the I/O resources
- are already initialized it performs no operation and just returns with
- ARM_DRIVER_OK.
-
-- PowerControl (ARM_POWER_FULL) sets the peripheral registers including
- interrupt (NVIC) and optionally DMA. The function can be called multiple
- times; if the registers are already set it performs no operation and just
- returns with ARM_DRIVER_OK.
-
-To stop working with a peripheral the functions PowerControl and Uninitialize need to be called in this order:
-\code
- drv->PowerControl (ARM_POWER_OFF); // Terminate any pending transfers, reset IRQ/DMA, power off peripheral
- drv->Uninitialize (...); // Release I/O pins
-\endcode
-
-The functions ARM_Storage_PowerControl and ARM_Storage_Uninitialize always execute and can be used
-to put the peripheral into a Safe State, for example after any data
-transmission errors. To restart the peripheral in an error condition,
-you should first execute the Stop Sequence and then the Start Sequence.
-
-The parameter \em state can have the following values:
- - \ref ARM_POWER_FULL : set-up the Storage device for data transfers, enable interrupts (NVIC) and optionally DMA. Can be called multiple times.
- If the device is already in this mode, then the function performs no operation and returns with \ref ARM_DRIVER_OK.
- - \ref ARM_POWER_LOW : may use power saving. Returns \ref ARM_DRIVER_ERROR_UNSUPPORTED when not implemented.
- - \ref ARM_POWER_OFF : terminates any pending data transfers, disables peripheral, disables related interrupts and DMA.
-
-\note This API may execute asynchronously if
- ARM_STORAGE_CAPABILITIES::asynchronous_ops is set. Asynchronous
- execution is optional even if 'asynchronous_ops' is set.
-*******************************************************************************************************************/
-
-int32_t ARM_Storage_ReadData (uint64_t addr, void *data, uint32_t size) {
- return 0;
-}
-/**
-\fn int32_t ARM_Storage_ReadData (uint64_t addr, void *data, uint32_t size)
-\details
-Read the contents of a range of storage memory into a buffer
-supplied by the caller. The buffer is owned by the caller and should
-remain accessible for the lifetime of this command.
-
-\note This API may execute asynchronously if
- ARM_STORAGE_CAPABILITIES::asynchronous_ops is set. Asynchronous
- execution is optional even if 'asynchronous_ops' is set.
-*******************************************************************************************************************/
-
-int32_t ARM_Storage_ProgramData (uint64_t addr, const void *data, uint32_t size) {
- return 0;
-}
-/**
-\fn int32_t ARM_Storage_ProgramData (uint64_t addr, const void *data, uint32_t size)
-\details
-Write the contents of a given memory buffer into a range of
-storage memory. In the case of flash memory, the destination range in
-storage memory typically has its contents in an erased state from a
-preceding erase operation. The source memory buffer is owned by the
-caller and should remain accessible for the lifetime of this command.
-
-\note It is best for the middleware to write in units of
- 'optimal_program_unit' (\ref ARM_STORAGE_INFO) of the device.
-
-\note This API may execute asynchronously if
- ARM_STORAGE_CAPABILITIES::asynchronous_ops is set. Asynchronous
- execution is optional even if 'asynchronous_ops' is set.
-*******************************************************************************************************************/
-
-int32_t ARM_Storage_Erase (uint64_t addr, uint32_t size) {
- return 0;
-}
-/**
-\fn int32_t ARM_Storage_Erase (uint64_t addr, uint32_t size)
-
-\details
-This function erases a range of storage specified by [addr, addr +
-size). Both 'addr' and 'addr + size' should align with the
-'erase_unit'(s) of the respective owning storage block(s) (see \ref
-ARM_STORAGE_BLOCK and \ref ARM_STORAGE_BLOCK_ATTRIBUTES). The range to
-be erased will have its contents returned to the un-programmed state--
-i.e. to \ref ARM_STORAGE_INFO::erased_value, which
-is usually 1 to indicate the pattern of all ones: 0xFF.
-
-\note This API may execute asynchronously if
- ARM_STORAGE_CAPABILITIES::asynchronous_ops is set. Asynchronous
- execution is optional even if 'asynchronous_ops' is set.
-
-\note Erase() may return a smaller (positive) value than the size of the
- requested range. The returned value indicates the actual number of bytes
- erased. It is the caller's responsibility to follow up with an appropriate
- request to complete the operation.
-
-\note in the case of a failed erase (except when
- ARM_DRIVER_ERROR_PARAMETER, ARM_STORAGE_ERROR_PROTECTED, or
- ARM_STORAGE_ERROR_NOT_ERASABLE is returned synchronously), the
- requested range should be assumed to be in an unknown state. The
- previous contents may not be retained.
-*******************************************************************************************************************/
-
-int32_t ARM_Storage_EraseAll (void) {
- return 0;
-}
-/**
-\fn int32_t ARM_Storage_EraseAll (void)
-\details
-This optional function erases the complete device. If the device does not
-support global erase then the function returns the error value \ref
-ARM_DRIVER_ERROR_UNSUPPORTED. The data field \em 'erase_all' =
-\token{1} of the structure \ref ARM_STORAGE_CAPABILITIES encodes that
-\ref ARM_Storage_EraseAll is supported.
-
-\note This API may execute asynchronously if
- ARM_STORAGE_CAPABILITIES::asynchronous_ops is set. Asynchronous
- execution is optional even if 'asynchronous_ops' is set.
-*******************************************************************************************************************/
-
-ARM_Storage_STATUS ARM_Storage_GetStatus (void) {
- return 0;
-}
-/**
-\fn ARM_STORAGE_STATUS ARM_Storage_GetStatus (void)
-\details
-Get the status of the current (or previous) command executed by the
-storage controller; stored in the structure \ref ARM_STORAGE_STATUS.
-
-\note This API returns synchronously--it does not result in an invocation
- of a completion callback.
-*******************************************************************************************************************/
-
-int32_t ARM_Storage_GetInfo (ARM_STORAGE_INFO *info) {
- return 0;
-}
-/**
-\fn int32_t ARM_Storage_GetInfo (ARM_STORAGE_INFO *info)
-\details
-Get information about the Storage device; stored in the structure \ref ARM_STORAGE_INFO.
-
-\note It is the caller's responsibility to ensure that the buffer passed in
- is able to be initialized with a \ref ARM_STORAGE_INFO.
-
-\note This API returns synchronously--it does not result in an invocation
- of a completion callback.
-*******************************************************************************************************************/
-
-uint32_t ARM_Storage_ResolveAddress(uint64_t addr) {
- return 0;
-}
-/**
-\fn uint32_t ARM_Storage_ResolveAddress(uint64_t addr)
-\details
-Only applicable to devices with memory-mapped storage.
-
-\note This API returns synchronously. The invocation should return quickly,
- and result in a resolved address.
-*******************************************************************************************************************/
-
-int32_t ARM_Storage_GetNextBlock(const ARM_STORAGE_BLOCK* prev_block, ARM_STORAGE_BLOCK *next_block) {
- return 0;
-}
-/**
-\fn int32_t ARM_Storage_GetNextBlock(const ARM_STORAGE_BLOCK* prev_block, ARM_STORAGE_BLOCK *next_block);
-\details
-This helper function fetches (an iterator to) the next block (or
-the first block if 'prev_block' is passed in as NULL). In the failure
-case, a terminating, invalid block iterator is filled into the out
-parameter: 'next_block'. In combination with \ref
-ARM_STORAGE_VALID_BLOCK, it can be used to iterate over the sequence
-of blocks within the storage map:
-
-\code
- ARM_STORAGE_BLOCK block;
- for (drv->GetNextBlock(NULL, &block); ARM_STORAGE_VALID_BLOCK(&block); drv->GetNextBlock(&block, &block)) {
- // make use of block
- }
-\endcode
-
-\note This API returns synchronously--it does not result in an invocation
- of a completion callback.
-*******************************************************************************************************************/
-
-int32_t ARM_Storage_GetBlock(uint64_t addr, ARM_STORAGE_BLOCK *block) {
- return 0;
-}
-/**
-\fn int32_t ARM_Storage_GetBlock(uint64_t addr, ARM_STORAGE_BLOCK *block);
-\note This API returns synchronously--it does not result in an invocation
- of a completion callback.
-*******************************************************************************************************************/
-
-/**
-@}
-*/
-
-/**
-\defgroup SampleUseOfStorageDriver Sample Use of Storage Driver
-\ingroup storage_interface_gr
-@{
-Example Code:
-
-The following is a generic algorithm to erase
-and program one \ref ARM_STORAGE_BLOCK_ATTRIBUTES::erase_unit worth of storage
-and then read it back to be verified. It handles both synchronous and
-asynchronous driver implementations.
-
-\code
-// Copyright (c) 2006-2016, Arm Limited, All Rights Reserved
-// SPDX-License-Identifier: Apache-2.0
-//
-// Licensed under the Apache License, Version 2.0 (the "License"); you may
-// not use this file except in compliance with the License.
-// You may obtain a copy of the License at
-//
-// http:// www.apache.org/licenses/LICENSE-2.0
-//
-// Unless required by applicable law or agreed to in writing, software
-// distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
-// WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-// See the License for the specific language governing permissions and
-// limitations under the License.
-
-#include "Driver_Storage.h"
-#include
-#include
-
-#define TEST_ASSERT(Expr) if (!(Expr)) { printf("%s:%u: assertion failure\n", __FUNCTION__, __LINE__); while (1) ;}
-#define TEST_ASSERT_EQUAL(expected, actual) if ((expected) != (actual)) {printf("%s:%u: assertion failure\n", __FUNCTION__, __LINE__); while (1) ;}
-#define TEST_ASSERT_NOT_EQUAL(expected, actual) if ((expected) == (actual)) {printf("%s:%u: assertion failure\n", __FUNCTION__, __LINE__); while (1) ;}
-
-// forward declarations
-void callbackHandler(int32_t status, ARM_STORAGE_OPERATION operation);
-void progressStateMachine(void);
-
-static enum {
- NEEDS_INITIALIZATION,
- NEEDS_ERASE,
- NEEDS_PROGRAMMING,
- NEEDS_READ,
- NEEDS_VERIFICATION_FOLLOWING_READ,
- FINISHED
-} state;
-
-extern ARM_DRIVER_STORAGE ARM_Driver_Storage_(0);
-ARM_DRIVER_STORAGE *drv = &ARM_Driver_Storage_(0);
-
-static const unsigned BUFFER_SIZE = 16384;
-static uint8_t buffer[BUFFER_SIZE];
-
-void main(int argc __unused, char** argv __unused)
-{
- state = NEEDS_INITIALIZATION;
-
- progressStateMachine();
- while (true) {
- // WFE(); // optional low-power sleep
- }
-}
-
-void progressStateMachine(void)
-{
- int32_t rc;
-
- static ARM_STORAGE_BLOCK firstBlock;
- if (!ARM_STORAGE_VALID_BLOCK(&firstBlock)) {
- // Get the first block. This block is entered only once.
- rc = drv->GetNextBlock(NULL, &firstBlock); // get first block
- TEST_ASSERT_EQUAL(ARM_DRIVER_OK, rc);
- }
- TEST_ASSERT(ARM_STORAGE_VALID_BLOCK(&firstBlock));
- TEST_ASSERT(firstBlock.size > 0);
-
- switch (state) {
- case NEEDS_INITIALIZATION:
- rc = drv->Initialize(callbackHandler);
- TEST_ASSERT(rc >= ARM_DRIVER_OK);
- if (rc == ARM_DRIVER_OK) {
- TEST_ASSERT_EQUAL(1, drv->GetCapabilities().asynchronous_ops);
- state = NEEDS_ERASE;
- return; // there is pending asynchronous activity which will lead to a completion callback later.
- }
- TEST_ASSERT_EQUAL(1, rc); // synchronous completion
-
- // intentional fall-through
-
- case NEEDS_ERASE:
- TEST_ASSERT(firstBlock.attributes.erase_unit > 0);
- rc = drv->Erase(firstBlock.addr, firstBlock.attributes.erase_unit);
- TEST_ASSERT(rc >= ARM_DRIVER_OK);
- if (rc == ARM_DRIVER_OK) {
- TEST_ASSERT_EQUAL(1, drv->GetCapabilities().asynchronous_ops);
- state = NEEDS_PROGRAMMING;
- return; // there is pending asynchronous activity which will lead to a completion callback later.
- }
- TEST_ASSERT_EQUAL(firstBlock.attributes.erase_unit, (uint32_t)rc); // synchronous completion
-
- // intentional fall-through
-
- case NEEDS_PROGRAMMING:
- TEST_ASSERT(BUFFER_SIZE >= firstBlock.attributes.erase_unit);
- #define PATTERN 0xAA
- memset(buffer, PATTERN, firstBlock.attributes.erase_unit);
- rc = drv->ProgramData(firstBlock.addr, buffer, firstBlock.attributes.erase_unit);
- TEST_ASSERT(rc >= ARM_DRIVER_OK);
- if (rc == ARM_DRIVER_OK) {
- TEST_ASSERT_EQUAL(1, drv->GetCapabilities().asynchronous_ops);
- state = NEEDS_READ;
- return; // there is pending asynchronous activity which will lead to a completion callback later.
- }
- TEST_ASSERT_EQUAL(firstBlock.attributes.erase_unit, (uint32_t)rc); // synchronous completion
-
- // intentional fall-through
-
- case NEEDS_READ:
- rc = drv->ReadData(firstBlock.addr, buffer, firstBlock.attributes.erase_unit);
- TEST_ASSERT(rc >= ARM_DRIVER_OK);
- if (rc == ARM_DRIVER_OK) {
- TEST_ASSERT_EQUAL(1, drv->GetCapabilities().asynchronous_ops);
- state = NEEDS_VERIFICATION_FOLLOWING_READ;
- return; // there is pending asynchronous activity which will lead to a completion callback later.
- }
- TEST_ASSERT_EQUAL(firstBlock.attributes.erase_unit, (uint32_t)rc);
-
- // intentional fall-through
-
- case NEEDS_VERIFICATION_FOLLOWING_READ:
- printf("verifying data\r\n");
- for (unsigned i = 0; i < firstBlock.attributes.erase_unit; i++) {
- TEST_ASSERT_EQUAL(PATTERN, buffer[i]);
- }
- state = FINISHED;
- printf("done\r\n");
- break;
-
- case FINISHED:
- break;
- } // switch (state)
-}
-
-void callbackHandler(int32_t status, ARM_STORAGE_OPERATION operation)
-{
- (void)status;
- (void)operation;
- switch (operation) {
- case ARM_STORAGE_OPERATION_INITIALIZE:
- case ARM_STORAGE_OPERATION_READ_DATA:
- case ARM_STORAGE_OPERATION_PROGRAM_DATA:
- case ARM_STORAGE_OPERATION_ERASE:
- progressStateMachine();
- break;
-
- default:
- printf("callbackHandler: unexpected callback for opcode %u with status %ld\r\n", operation, status);
- break;
- }
-}
-\endcode
-@}
-*******************************************************************************************************************/
-// End Storage Interface
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/Driver_USART.c b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/Driver_USART.c
deleted file mode 100644
index 860223f..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/Driver_USART.c
+++ /dev/null
@@ -1,801 +0,0 @@
-/**
-\defgroup usart_interface_gr USART Interface
-\brief Driver API for Universal Synchronous Asynchronous Receiver/Transmitter (%Driver_USART.h)
-\details
-The Universal Synchronous Asynchronous Receiver/Transmitter (USART) implements a synchronous and asynchronous serial bus for exchanging data.
-When only asynchronous mode is supported it is called Universal Asynchronous Receiver/Transmitter (UART).
-Almost all microcontrollers have a serial interface (UART/USART peripheral). A UART is a simple device to send data to a PC
-via a terminal emulation program (Hyperterm, TeraTerm) or to another microcontroller.
-A UART takes bytes of data and transmits the individual bits in a sequential mode. At the destination,
-a second UART reassembles the bits into complete bytes. Each UART contains a shift register for converting between serial and parallel transmission forms.
-Wikipedia offers more information about
-the Universal asynchronous receiver/transmitter USART API
-
-The following header files define the Application Programming Interface (API) for the USART interface:
- - \b %Driver_USART.h : Driver API for Universal Synchronous Asynchronous Receiver/Transmitter
-
-The driver implementation is a typical part of the Device Family Pack (DFP) that supports the
-peripherals of the microcontroller family.
-
-
-Driver Functions
-
-The driver functions are published in the access struct as explained in \ref DriverFunctions
- - \ref ARM_DRIVER_USART : access struct for USART driver functions
-
-
-Example Code
-
-The following example code shows the usage of the USART interface for asynchronous communication.
-
-\include USART_Demo.c
-
-@{
-*/
-
-/**
-\struct ARM_DRIVER_USART
-\details
-The functions of the USART driver are accessed by function pointers exposed by this structure.
-Refer to \ref DriverFunctions for overview information.
-
-Each instance of an USART interface provides such an access structure.
-The instance is identified by a postfix number in the symbol name of the access structure, for example:
- - \b Driver_USART0 is the name of the access struct of the first instance (no. 0).
- - \b Driver_USART1 is the name of the access struct of the second instance (no. 1).
-
-A middleware configuration setting allows connecting the middleware to a specific driver instance \b %Driver_USARTn .
-The default is \token{0}, which connects a middleware to the first instance of a driver.
-*****************************************************************************************************************/
-
-/**
-\struct ARM_USART_CAPABILITIES
-\details
-An USART driver can be implemented with different capabilities.
-The data fields of this structure encode the capabilities implemented by this driver.
-
-Returned by:
- - \ref ARM_USART_GetCapabilities
-*****************************************************************************************************************/
-
-/**
-\struct ARM_USART_STATUS
-\details
-Structure with information about the status of the USART. The data fields encode busy flags and error flags.
-
-Returned by:
- - \ref ARM_USART_GetStatus
-*****************************************************************************************************************/
-
-/**
-\enum ARM_USART_MODEM_CONTROL
-\details
-Specifies values for controlling the modem control lines.
-
-Parameter for:
- - \ref ARM_USART_SetModemControl
-*****************************************************************************************************************/
-
-/**
-\struct ARM_USART_MODEM_STATUS
-\details
-Structure with information about the status of modem lines. The data fields encode states of modem status lines.
-
-Returned by:
- - \ref ARM_USART_GetModemStatus
-*****************************************************************************************************************/
-
-
-/**
-\typedef ARM_USART_SignalEvent_t
-\details
-Provides the typedef for the callback function \ref ARM_USART_SignalEvent.
-
-Parameter for:
- - \ref ARM_USART_Initialize
-*******************************************************************************************************************/
-
-
-/**
-\defgroup usart_execution_status Status Error Codes
-\ingroup common_drv_gr
-\brief Negative values indicate errors (USART has specific codes in addition to common \ref execution_status).
-\details
-The USART driver has additional status error codes that are listed below.
-Note that the USART driver also returns the common \ref execution_status.
-
-@{
-\def ARM_USART_ERROR_MODE
-The \b mode requested with the function \ref ARM_USART_Control is not supported by this driver.
-
-\def ARM_USART_ERROR_BAUDRATE
-The baud rate requested with the function \ref ARM_USART_Control is not supported by this driver.
-
-\def ARM_USART_ERROR_DATA_BITS
-The number of data bits requested with the function \ref ARM_USART_Control is not supported by this driver.
-
-\def ARM_USART_ERROR_PARITY
-The parity bit requested with the function \ref ARM_USART_Control is not supported by this driver.
-
-\def ARM_USART_ERROR_STOP_BITS
-The stop bit requested with the function \ref ARM_USART_Control is not supported by this driver.
-
-\def ARM_USART_ERROR_FLOW_CONTROL
-The flow control requested with the function \ref ARM_USART_Control is not supported by this driver.
-
-\def ARM_USART_ERROR_CPOL
-The clock polarity requested with the function \ref ARM_USART_Control is not supported by this driver.
-
-\def ARM_USART_ERROR_CPHA
-The clock phase requested with the function \ref ARM_USART_Control is not supported by this driver.
-@}
-*/
-
-
-/**
-\defgroup USART_events USART Events
-\ingroup usart_interface_gr
-\brief The USART driver generates call back events that are notified via the function \ref ARM_USART_SignalEvent.
-\details
-This section provides the event values for the \ref ARM_USART_SignalEvent callback function.
-
-The following call back notification events are generated:
-@{
-\def ARM_USART_EVENT_SEND_COMPLETE
-\def ARM_USART_EVENT_RECEIVE_COMPLETE
-\def ARM_USART_EVENT_TRANSFER_COMPLETE
-\def ARM_USART_EVENT_TX_COMPLETE
-\def ARM_USART_EVENT_TX_UNDERFLOW
-\def ARM_USART_EVENT_RX_OVERFLOW
-\def ARM_USART_EVENT_RX_TIMEOUT
-\def ARM_USART_EVENT_RX_BREAK
-\def ARM_USART_EVENT_RX_FRAMING_ERROR
-\def ARM_USART_EVENT_RX_PARITY_ERROR
-\def ARM_USART_EVENT_CTS
-\def ARM_USART_EVENT_DSR
-\def ARM_USART_EVENT_DCD
-\def ARM_USART_EVENT_RI
-@}
-*/
-
-
-/**
-\defgroup USART_control USART Control Codes
-\ingroup usart_interface_gr
-\brief Many parameters of the USART driver are configured using the \ref ARM_USART_Control function.
-\details
-@{
-The various USART control codes define:
- - \ref usart_mode_control specifies USART mode
- - \ref usart_data_bits defines the number of data bits
- - \ref usart_parity_bit defines the parity bit
- - \ref usart_stop_bits defines the number of stop bits
- - \ref usart_flow_control specifies RTS/CTS flow control
- - \ref usart_clock_polarity defines the clock polarity for the synchronous mode
- - \ref usart_clock_phase defines the clock phase for the synchronous mode
- - \ref usart_misc_control specifies additional miscellaneous controls
-
-Refer to the \ref ARM_USART_Control function for further details.
-
-*/
-
-
-/**
-\defgroup usart_mode_control USART Mode Control
-\ingroup USART_control
-\brief Specify USART mode.
-\details
-@{
-\def ARM_USART_MODE_ASYNCHRONOUS
-\sa ARM_USART_Control
-\def ARM_USART_MODE_SYNCHRONOUS_MASTER
-\sa ARM_USART_Control
-\def ARM_USART_MODE_SYNCHRONOUS_SLAVE
-\sa ARM_USART_Control
-\def ARM_USART_MODE_SINGLE_WIRE
-\sa ARM_USART_Control
-\def ARM_USART_MODE_IRDA
-\sa ARM_USART_Control
-\def ARM_USART_MODE_SMART_CARD
-\sa ARM_USART_Control
-@}
-*/
-
-
-/**
-\defgroup usart_misc_control USART Miscellaneous Control
-\ingroup USART_control
-\brief Specifies additional miscellaneous controls.
-\details
-@{
-\def ARM_USART_SET_DEFAULT_TX_VALUE
-\sa ARM_USART_Control; ARM_USART_Receive;
-\def ARM_USART_SET_IRDA_PULSE
-\sa ARM_USART_Control
-\def ARM_USART_SET_SMART_CARD_GUARD_TIME
-\sa ARM_USART_Control
-\def ARM_USART_SET_SMART_CARD_CLOCK
-\sa ARM_USART_Control
-\def ARM_USART_CONTROL_SMART_CARD_NACK
-\sa ARM_USART_Control
-\def ARM_USART_CONTROL_TX
-\sa ARM_USART_Control; ARM_USART_Send; ARM_USART_Transfer
-\def ARM_USART_CONTROL_RX
-\sa ARM_USART_Control; ARM_USART_Receive; ARM_USART_Transfer;
-\def ARM_USART_CONTROL_BREAK
-\sa ARM_USART_Control
-\def ARM_USART_ABORT_SEND
-\sa ARM_USART_Control;
-\def ARM_USART_ABORT_RECEIVE
-\sa ARM_USART_Control;
-\def ARM_USART_ABORT_TRANSFER
-\sa ARM_USART_Control;
-@}
-*/
-
-/**
-\defgroup usart_data_bits USART Data Bits
-\ingroup USART_control
-\brief Defines the number of data bits.
-\details
-@{
-\def ARM_USART_DATA_BITS_5
-\sa ARM_USART_Control
-\def ARM_USART_DATA_BITS_6
-\sa ARM_USART_Control
-\def ARM_USART_DATA_BITS_7
-\sa ARM_USART_Control
-\def ARM_USART_DATA_BITS_8
-\sa ARM_USART_Control
-\def ARM_USART_DATA_BITS_9
-\sa ARM_USART_Control
-@}
-*/
-
-/**
-\defgroup usart_parity_bit USART Parity Bit
-\ingroup USART_control
-\brief Defines the parity bit.
-\details
-@{
-\def ARM_USART_PARITY_NONE
-\sa ARM_USART_Control
-\def ARM_USART_PARITY_EVEN
-\sa ARM_USART_Control
-\def ARM_USART_PARITY_ODD
-\sa ARM_USART_Control
-@}
-*/
-
-/**
-\defgroup usart_stop_bits USART Stop Bits
-\ingroup USART_control
-\brief Defines the number of stop bits.
-\details
-@{
-\sa ARM_USART_Control
-\def ARM_USART_STOP_BITS_1
-\sa ARM_USART_Control
-\def ARM_USART_STOP_BITS_2
-\sa ARM_USART_Control
-\def ARM_USART_STOP_BITS_1_5
-\sa ARM_USART_Control
-\def ARM_USART_STOP_BITS_0_5
-\sa ARM_USART_Control
-@}
-*/
-
-/**
-\defgroup usart_flow_control USART Flow Control
-\ingroup USART_control
-\brief Specifies RTS/CTS flow control.
-\details
-@{
-\def ARM_USART_FLOW_CONTROL_NONE
-\sa ARM_USART_Control
-\def ARM_USART_FLOW_CONTROL_RTS
-\sa ARM_USART_Control
-\def ARM_USART_FLOW_CONTROL_CTS
-\sa ARM_USART_Control
-\def ARM_USART_FLOW_CONTROL_RTS_CTS
-\sa ARM_USART_Control
-@}
-*/
-
-/**
-\defgroup usart_clock_polarity USART Clock Polarity
-\ingroup USART_control
-\brief Defines the clock polarity for the synchronous mode.
-\details
-@{
-\def ARM_USART_CPOL0
-\sa ARM_USART_Control; ARM_USART_Receive; ARM_USART_Send; ARM_USART_Transfer
-\def ARM_USART_CPOL1
-\sa ARM_USART_Control; ARM_USART_Receive; ARM_USART_Send; ARM_USART_Transfer
-@}
-*/
-
-/**
-\defgroup usart_clock_phase USART Clock Phase
-\ingroup USART_control
-\brief Defines the clock phase for the synchronous mode.
-\details
-@{
-\def ARM_USART_CPHA0
-\sa ARM_USART_Control; ARM_USART_Receive; ARM_USART_Send; ARM_USART_Transfer
-\def ARM_USART_CPHA1
-\sa ARM_USART_Control; ARM_USART_Receive; ARM_USART_Send; ARM_USART_Transfer
-@}
-*/
-
-/**
-@}
-*/
-// end group USART_control
-
-
-//
-// Functions
-//
-
-ARM_DRIVER_VERSION ARM_USART_GetVersion (void) {
- return { 0, 0 };
-}
-/**
-\fn ARM_DRIVER_VERSION ARM_USART_GetVersion (void)
-\details
-The function \b ARM_USART_GetVersion returns version information of the driver implementation in \ref ARM_DRIVER_VERSION
- - API version is the version of the CMSIS-Driver specification used to implement this driver.
- - Driver version is source code version of the actual driver implementation.
-
-Example:
-\code
-extern ARM_DRIVER_USART Driver_USART0;
-ARM_DRIVER_USART *drv_info;
-
-void setup_usart (void) {
- ARM_DRIVER_VERSION version;
-
- drv_info = &Driver_USART0;
- version = drv_info->GetVersion ();
- if (version.api < 0x10A) { // requires at minimum API version 1.10 or higher
- // error handling
- return;
- }
-}
-\endcode
-*****************************************************************************************************************/
-
-ARM_USART_CAPABILITIES ARM_USART_GetCapabilities (void) {
- return { 0 } ;
-}
-/**
-\fn ARM_USART_CAPABILITIES ARM_USART_GetCapabilities (void)
-\details
-The function \b ARM_USART_GetCapabilities returns information about capabilities in this driver implementation.
-The data fields of the structure \ref ARM_USART_CAPABILITIES encode various capabilities, for example:
-supported modes, if hardware and driver are capable of signaling events using the \ref ARM_USART_SignalEvent
-callback function ...
-
-Example:
-\code
-extern ARM_DRIVER_USART Driver_USART0;
-ARM_DRIVER_USART *drv_info;
-
-void read_capabilities (void) {
- ARM_USART_CAPABILITIES drv_capabilities;
-
- drv_info = &Driver_USART0;
- drv_capabilities = drv_info->GetCapabilities ();
- // interrogate capabilities
-
-}
-\endcode
-*****************************************************************************************************************/
-
-int32_t ARM_USART_Initialize (ARM_USART_SignalEvent_t cb_event) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_USART_Initialize (ARM_USART_SignalEvent_t cb_event)
-\details
-The function \b ARM_USART_Initialize initializes the USART interface.
-It is called when the middleware component starts operation.
-
-The function performs the following operations:
- - Initializes the resources needed for the USART interface.
- - Registers the \ref ARM_USART_SignalEvent callback function.
-
-The parameter \em cb_event is a pointer to the \ref ARM_USART_SignalEvent callback function; use a NULL pointer
-when no callback signals are required.
-
-\b Example:
- - see \ref usart_interface_gr - Driver Functions
-
-*****************************************************************************************************************/
-
-int32_t ARM_USART_Uninitialize (void) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_USART_Uninitialize (void)
-\details
-The function \b ARM_USART_Uninitialize de-initializes the resources of USART interface.
-
-It is called when the middleware component stops operation and releases the software resources used by the interface.
-*****************************************************************************************************************/
-
-int32_t ARM_USART_PowerControl (ARM_POWER_STATE state) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_USART_PowerControl (ARM_POWER_STATE state)
-\details
-The function \b ARM_USART_PowerControl operates the power modes of the USART interface.
-
-The parameter \em state sets the operation and can have the following values:
- - \ref ARM_POWER_FULL : set-up peripheral for data transfers, enable interrupts (NVIC) and optionally DMA.
- Can be called multiple times. If the peripheral is already in this mode the function performs
- no operation and returns with \ref ARM_DRIVER_OK.
- - \ref ARM_POWER_LOW : may use power saving. Returns \ref ARM_DRIVER_ERROR_UNSUPPORTED when not implemented.
- - \ref ARM_POWER_OFF : terminates any pending data transfers, disables peripheral, disables related interrupts and DMA.
-
-Refer to \ref CallSequence for more information.
-
-*****************************************************************************************************************/
-
-int32_t ARM_USART_Send (const void *data, uint32_t num) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_USART_Send (const void *data, uint32_t num)
-\details
-This functions \b ARM_USART_Send is used in asynchronous mode to send data to the USART transmitter.
-It can also be used in synchronous mode when sending data only (received data is ignored).
-
-Transmitter needs to be enabled by calling \ref ARM_USART_Control with \ref ARM_USART_CONTROL_TX as the control parameter and \token{1} as argument.
-
-The function parameters specify the buffer with data and the number of items to send.
-The item size is defined by the data type which depends on the configured number of data bits.
-
-Data type is:
- - \em uint8_t when configured for 5..8 data bits
- - \em uint16_t when configured for 9 data bits
-
-Calling the function ARM_USART_Send only starts the send operation.
-The function is non-blocking and returns as soon as the driver has started the operation (driver typically configures DMA or the interrupt system for continuous transfer).
-When in synchronous slave mode the operation is only registered and started when the master starts the transfer.
-During the operation it is not allowed to call this function again or any other data transfer function when in synchronous mode. Also the data buffer must stay allocated and the contents of unsent data must not be modified.
-When send operation is completed (requested number of items sent) the \ref ARM_USART_EVENT_SEND_COMPLETE event is generated.
-Progress of send operation can also be monitored by reading the number of items already sent by calling \ref ARM_USART_GetTxCount.
-
-After send operation has completed there might still be some data left in the driver's hardware buffer which is still being transmitted.
-When all data has been physically transmitted the \ref ARM_USART_EVENT_TX_COMPLETE event is generated (if supported and reported by \em event_tx_complete in \ref ARM_USART_CAPABILITIES).
-At that point also the \em tx_busy data field in \ref ARM_USART_STATUS is cleared.
-
-Status of the transmitter can be monitored by calling the \ref ARM_USART_GetStatus and checking the \em tx_busy flag
-which indicates if transmission is still in progress.
-
-When in synchronous slave mode and transmitter is enabled but send/receive/transfer operation is not started and data is requested by the master then the \ref ARM_USART_EVENT_TX_UNDERFLOW event is generated.
-
-Send operation can be aborted by calling \ref ARM_USART_Control with \ref ARM_USART_ABORT_SEND as the control parameter.
-*****************************************************************************************************************/
-
-int32_t ARM_USART_Receive (void *data, uint32_t num) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_USART_Receive (void *data, uint32_t num)
-\details
-This functions \b ARM_USART_Receive is used in asynchronous mode to receive data from the USART receiver.
-It can also be used in synchronous mode when receiving data only (transmits the default value as specified by \ref ARM_USART_Control with \ref ARM_USART_SET_DEFAULT_TX_VALUE as control parameter).
-
-Receiver needs to be enabled by calling \ref ARM_USART_Control with \ref ARM_USART_CONTROL_RX as the control parameter and \token{1} as argument.
-
-The function parameters specify the buffer for data and the number of items to receive.
-The item size is defined by the data type which depends on the configured number of data bits.
-
-Data type is:
- - \em uint8_t when configured for 5..8 data bits
- - \em uint16_t when configured for 9 data bits
-
-Calling the function ARM_USART_Receive only starts the receive operation.
-The function is non-blocking and returns as soon as the driver has started the operation (driver typically configures DMA or the interrupt system for continuous transfer).
-When in synchronous slave mode the operation is only registered and started when the master starts the transfer.
-During the operation it is not allowed to call this function again or any other data transfer function when in synchronous mode. Also the data buffer must stay allocated.
-When receive operation is completed (requested number of items received) the \ref ARM_USART_EVENT_RECEIVE_COMPLETE event is generated.
-Progress of receive operation can also be monitored by reading the number of items already received by calling \ref ARM_USART_GetRxCount.
-
-Status of the receiver can be monitored by calling the \ref ARM_USART_GetStatus and checking the \em rx_busy flag
-which indicates if reception is still in progress.
-
-During reception the following events can be generated (in asynchronous mode):
- - \ref ARM_USART_EVENT_RX_TIMEOUT : Receive timeout between consecutive characters detected (optional)
- - \ref ARM_USART_EVENT_RX_BREAK : Break detected (Framing error is not generated for Break condition)
- - \ref ARM_USART_EVENT_RX_FRAMING_ERROR : Framing error detected
- - \ref ARM_USART_EVENT_RX_PARITY_ERROR : Parity error detected
- - \ref ARM_USART_EVENT_RX_OVERFLOW : Data overflow detected (also in synchronous slave mode)
-
-\ref ARM_USART_EVENT_RX_OVERFLOW event is also generated when receiver is enabled but data is lost because
-receive operation in asynchronous mode or receive/send/transfer operation in synchronous slave mode has not been started.
-
-Receive operation can be aborted by calling \ref ARM_USART_Control with \ref ARM_USART_ABORT_RECEIVE as the control parameter.
-*****************************************************************************************************************/
-
-int32_t ARM_USART_Transfer (const void *data_out, void *data_in, uint32_t num) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_USART_Transfer (const void *data_out, void *data_in, uint32_t num)
-\details
-This functions \b ARM_USART_Transfer is used in synchronous mode to transfer data via USART. It synchronously sends data to the USART transmitter and receives data from the USART receiver.
-
-Transmitter needs to be enabled by calling \ref ARM_USART_Control with \ref ARM_USART_CONTROL_TX as the control parameter and \token{1} as argument.
-Receiver needs to be enabled by calling \ref ARM_USART_Control with \ref ARM_USART_CONTROL_RX as the control parameter and \token{1} as argument.
-
-The function parameters specify the buffer with data to send, the buffer for data to receive and the number of items to transfer.
-The item size is defined by the data type which depends on the configured number of data bits.
-
-Data type is:
- - \em uint8_t when configured for 5..8 data bits
- - \em uint16_t when configured for 9 data bits
-
-Calling the function ARM_USART_Transfer only starts the transfer operation.
-The function is non-blocking and returns as soon as the driver has started the operation (driver typically configures DMA or the interrupt system for continuous transfer).
-When in synchronous slave mode the operation is only registered and started when the master starts the transfer.
-During the operation it is not allowed to call this function or any other data transfer function again. Also the data buffers must stay allocated and the contents of unsent data must not be modified.
-When transfer operation is completed (requested number of items transferred) the \ref ARM_USART_EVENT_TRANSFER_COMPLETE event is generated.
-Progress of transfer operation can also be monitored by reading the number of items already transferred by calling \ref ARM_USART_GetTxCount or \ref ARM_USART_GetRxCount.
-
-Status of the transmitter or receiver can be monitored by calling the \ref ARM_USART_GetStatus and checking the \em tx_busy or \em rx_busy flag.
-
-When in synchronous slave mode also the following events can be generated:
- - \ref ARM_USART_EVENT_TX_UNDERFLOW : transmitter is enabled but transfer operation is not started and data is requested by the master
- - \ref ARM_USART_EVENT_RX_OVERFLOW : data lost during transfer or because receiver is enabled but transfer operation has not been started
-
-Transfer operation can also be aborted by calling \ref ARM_USART_Control with \ref ARM_USART_ABORT_TRANSFER as the control parameter.
-*****************************************************************************************************************/
-
-uint32_t ARM_USART_GetTxCount (void) {
- return 0;
-}
-/**
-\fn uint32_t ARM_USART_GetTxCount (void)
-\details
-The function \b ARM_USART_GetTxCount returns the number of the currently transmitted data items during \ref ARM_USART_Send and \ref ARM_USART_Transfer operation.
-*****************************************************************************************************************/
-
-uint32_t ARM_USART_GetRxCount (void) {
- return 0;
-}
-/**
-\fn uint32_t ARM_USART_GetRxCount (void)
-\details
-The function \b ARM_USART_GetRxCount returns the number of the currently received data items during \ref ARM_USART_Receive and \ref ARM_USART_Transfer operation.
-*****************************************************************************************************************/
-
-int32_t ARM_USART_Control (uint32_t control, uint32_t arg) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_USART_Control (uint32_t control, uint32_t arg)
-\details
-The function \b ARM_USART_Control control the USART interface settings and execute various operations.
-
-The parameter \em control sets the operation and is explained in the table below.
-Values from different categories can be ORed with the exception of \ref usart_misc_tab "Miscellaneous Operations".
-
-The parameter \em arg provides, depending on the operation, additional information, for example the baudrate.
-
-The table lists the available \em control operations.
-
-
-Parameter \em control Bit Category Description \ref ARM_USART_MODE_ASYNCHRONOUS 0..7 Operation Mode Set to asynchronous UART mode. \em arg specifies baudrate. \ref ARM_USART_MODE_SYNCHRONOUS_MASTER Set to synchronous master mode with clock signal generation. \em arg specifies baudrate. \ref ARM_USART_MODE_SYNCHRONOUS_SLAVE Set to synchronous slave mode with external clock signal. \ref ARM_USART_MODE_SINGLE_WIRE Set to single-wire (half-duplex) mode. \em arg specifies baudrate. \ref ARM_USART_MODE_IRDA Set to Infra-red data mode. \em arg specifies baudrate. \ref ARM_USART_MODE_SMART_CARD Set to Smart Card mode. \em arg specifies baudrate. \ref ARM_USART_DATA_BITS_5 8..11 Data Bits Set to \token{5} data bits \ref ARM_USART_DATA_BITS_6 Set to \token{6} data bits \ref ARM_USART_DATA_BITS_7 Set to \token{7} data bits \ref ARM_USART_DATA_BITS_8 Set to \token{8} data bits (default) \ref ARM_USART_DATA_BITS_9 Set to \token{9} data bits \ref ARM_USART_PARITY_EVEN 12..13 Parity Bit Set to Even Parity \ref ARM_USART_PARITY_NONE Set to No Parity (default) \ref ARM_USART_PARITY_ODD Set to Odd Parity \ref ARM_USART_STOP_BITS_1 14..15 Stop Bit Set to \token{1} Stop bit (default) \ref ARM_USART_STOP_BITS_2 Set to \token{2} Stop bits \ref ARM_USART_STOP_BITS_1_5 Set to \token{1.5} Stop bits \ref ARM_USART_STOP_BITS_0_5 Set to \token{0.5} Stop bits \ref ARM_USART_FLOW_CONTROL_NONE 16..17 Flow Control No flow control signal (default) \ref ARM_USART_FLOW_CONTROL_CTS Set to use the CTS flow control signal \ref ARM_USART_FLOW_CONTROL_RTS Set to use the RTS flow control signal \ref ARM_USART_FLOW_CONTROL_RTS_CTS Set to use the RTS and CTS flow control signal \ref ARM_USART_CPOL0 18 Clock Polarity CPOL=\token{0} (default) : data are captured on rising edge (low->high transition) \ref ARM_USART_CPOL1 CPOL=\token{1} : data are captured on falling edge (high->low transition) \ref ARM_USART_CPHA0 19 Clock Phase CPHA=\token{0} (default) : sample on first (leading) edge \ref ARM_USART_CPHA1 CPHA=\token{1} : sample on second (trailing) edge \ref ARM_USART_ABORT_RECEIVE 0..19 \anchor usart_misc_tab Miscellaneous Operations Abort receive operation (see also: \ref ARM_USART_Receive) \ref ARM_USART_ABORT_SEND Abort send operation (see also: \ref ARM_USART_Send)
- \ref ARM_USART_ABORT_TRANSFER Abort transfer operation (see also: \ref ARM_USART_Transfer)
- \ref ARM_USART_CONTROL_BREAK Enable or disable continuous Break transmission; \em arg : \token{0=disabled; 1=enabled}
- \ref ARM_USART_CONTROL_RX Enable or disable receiver; \em arg : \token{0=disabled; 1=enabled} (see also: \ref ARM_USART_Receive; \ref ARM_USART_Transfer)
- \ref ARM_USART_CONTROL_SMART_CARD_NACK Enable or disable Smart Card NACK generation; \em arg : \token{0=disabled; 1=enabled}
- \ref ARM_USART_CONTROL_TX Enable or disable transmitter; \em arg : \token{0=disabled; 1=enabled} (see also: \ref ARM_USART_Send; \ref ARM_USART_Transfer)
- \ref ARM_USART_SET_DEFAULT_TX_VALUE Set the default transmit value (synchronous receive only); \em arg specifies the value. (see also: \ref ARM_USART_Receive)
- \ref ARM_USART_SET_IRDA_PULSE Set the IrDA pulse value in \token{ns}; \em arg : \token{0=3/16 of bit period}
- \ref ARM_USART_SET_SMART_CARD_CLOCK Set the Smart Card Clock in \token{Hz}; \em arg : \token{0=Clock not set}
- \ref ARM_USART_SET_SMART_CARD_GUARD_TIME Set the Smart Card guard time; \em arg = number of bit periods
-
-
-\b Example
-
-\code
- extern ARM_DRIVER_USART Driver_USART0;
-
- // configure to UART mode: 8 bits, no parity, 1 stop bit, no flow control, 9600 bps
- status = Driver_USART0.Control(ARM_USART_MODE_ASYNCHRONOUS |
- ARM_USART_DATA_BITS_8 |
- ARM_USART_PARITY_NONE |
- ARM_USART_STOP_BITS_1 |
- ARM_USART_FLOW_CONTROL_NONE, 9600);
-
- // identical with above settings (default settings removed)
- // configure to UART mode: 8 bits, no parity, 1 stop bit, flow control, 9600 bps
- status = Driver_USART0.Control(ARM_USART_MODE_ASYNCHRONOUS, 9600);
-
- // enable TX output
- status = Driver_USART0.Control(ARM_USART_CONTROL_TX, 1);
-
- // disable RX output
- status = Driver_USART0.Control(ARM_USART_CONTROL_RX, 0);
-\endcode
-*****************************************************************************************************************/
-
-ARM_USART_STATUS ARM_USART_GetStatus (void) {
- return { 0 };
-}
-/**
-\fn ARM_USART_STATUS ARM_USART_GetStatus (void)
-\details
-The function \b ARM_USART_GetStatus retrieves the current USART interface status.
-
-*****************************************************************************************************************/
-
-int32_t ARM_USART_SetModemControl (ARM_USART_MODEM_CONTROL control) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_USART_SetModemControl (ARM_USART_MODEM_CONTROL control)
-\details
-The function \b ARM_USART_SetModemControl activates or deactivates the selected USART modem control line.
-
-The function \ref ARM_USART_GetModemStatus returns information about status of the modem lines.
-
-*****************************************************************************************************************/
-
-ARM_USART_MODEM_STATUS ARM_USART_GetModemStatus (void) {
- return { 0 };
-}
-/**
-\fn ARM_USART_MODEM_STATUS ARM_USART_GetModemStatus (void)
-\details
-The function \b ARM_USART_GetModemStatus returns the current USART Modem Status lines state.
-
-The function \ref ARM_USART_SetModemControl sets the modem control lines of the USART.
-
-*****************************************************************************************************************/
-
-void ARM_USART_SignalEvent (uint32_t event) {
- // function body
-}
-/**
-\fn void ARM_USART_SignalEvent (uint32_t event)
-\details
-The function \b ARM_USART_SignalEvent is a callback function registered by the function \ref ARM_USART_Initialize.
-
-The parameter \em event indicates one or more events that occurred during driver operation.
-Each event is encoded in a separate bit and therefore it is possible to signal multiple events within the same call.
-
-Not every event is necessarily generated by the driver. This depends on the implemented capabilities stored in the
-data fields of the structure \ref ARM_USART_CAPABILITIES, which can be retrieved with the function \ref ARM_USART_GetCapabilities.
-
-The following events can be generated:
-
-
-
- Parameter \em event Bit Description
- supported when ARM_USART_CAPABILITIES
-
-
- \ref ARM_USART_EVENT_SEND_COMPLETE 0 Occurs after call to \ref ARM_USART_Send to indicate that all the data to be sent
- was processed by the driver. All the data might have been already transmitted
- or parts of it are still queued in transmit buffers. The driver is ready for the next
- call to \ref ARM_USART_Send; however USART may still transmit data.
- always supported
-
-
- \ref ARM_USART_EVENT_RECEIVE_COMPLETE 1 Occurs after call to \ref ARM_USART_Receive to indicate that all the data has been
- received. The driver is ready for the next call to \ref ARM_USART_Receive.
- always supported
-
-
- \ref ARM_USART_EVENT_TRANSFER_COMPLETE 2 Occurs after call to \ref ARM_USART_Transfer to indicate that all the data has been
- transferred. The driver is ready for the next call to \ref ARM_USART_Transfer.
- always supported
-
-
- \ref ARM_USART_EVENT_TX_COMPLETE 3 Occurs after call to \ref ARM_USART_Send to indicate that all the data has been
- physically transmitted on the wires.
- data field \em event_tx_complete = \token{1}
-
-
- \ref ARM_USART_EVENT_TX_UNDERFLOW 4 Occurs in synchronous slave mode when data is requested by the master but
- send/receive/transfer operation has not been started.
- Data field \em rx_underflow = \token{1} of \ref ARM_USART_STATUS.
- always supported
-
-
- \ref ARM_USART_EVENT_RX_OVERFLOW 5 Occurs when data is lost during receive/transfer operation or when data is lost
- because receive operation in asynchronous mode or receive/send/transfer operation in
- synchronous slave mode has not been started.
- Data field \em rx_overflow = \token{1} of \ref ARM_USART_STATUS.
- always supported
-
-
- ARM_USART_EVENT_RX_TIMEOUT 6 Occurs during receive when idle time is detected between consecutive characters
- (idle time is hardware dependent).
- data field \em event_rx_timeout = \token{1}
-
-
- \ref ARM_USART_EVENT_RX_BREAK 7 Occurs when break is detected during receive.
- Data field \em rx_break = \token{1} of \ref ARM_USART_STATUS.
- always supported
-
-
- \ref ARM_USART_EVENT_RX_FRAMING_ERROR 8 Occurs when framing error is detected during receive.
- Data field \em rx_framing_error = \token{1} of \ref ARM_USART_STATUS.
- always supported
-
-
- \ref ARM_USART_EVENT_RX_PARITY_ERROR 9 Occurs when parity error is detected during receive.
- Data field \em rx_parity_error = \token{1} of \ref ARM_USART_STATUS.
- always supported
-
-
- ARM_USART_EVENT_CTS 10 Indicates that CTS modem line state has changed.
- Data field \em cts of \ref ARM_USART_MODEM_STATUS has changed.
- data field \em event_cts = \token{1} and
-
-
- ARM_USART_EVENT_DSR 11 Indicates that DSR modem line state has changed.
- Data field \em dsr of \ref ARM_USART_MODEM_STATUS has changed.
- data field \em event_dsr = \token{1} and
-
-
- ARM_USART_EVENT_DCD 12 Indicates that DCD modem line state has changed.
- Data field \em dcd of \ref ARM_USART_MODEM_STATUS has changed.
- data field \em event_dcd = \token{1} and
-
-
- ARM_USART_EVENT_RI 13 Indicates that RI modem line state has changed from active to inactive
- (trailing edge on RI).
- Data field \em ri of \ref ARM_USART_MODEM_STATUS has changed from \token{1} to \token{0}.
- data field \em event_ri = \token{1} and
-
-
-*****************************************************************************************************************/
-
-/**
-@}
-*/
-// End USART Interface
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/Driver_USB.c b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/Driver_USB.c
deleted file mode 100644
index 017b3e3..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/Driver_USB.c
+++ /dev/null
@@ -1,153 +0,0 @@
-/**
-\defgroup usb_interface_gr USB Interface
-\brief USB common definitions (%Driver_USB.h)
-\details
-The Universal Serial Bus (USB) implements a serial bus for data exchange. It is a host controlled, plug-and-play interface
-between a USB host and USB devices using a tiered star topology.
-In microcontroller (MCU) applications, the interface is often used to connect a device to a host for data exchange or control purposes.
-
- - Wikipedia offers more information about the Universal Serial Bus www.usb.org Block Diagram
-
-Typically only one USB Device is connected to a USB Host. If several USB devices must be connected to the same USB host, then
-the connection must be done via a USB hub.
-
-
-\image html USB_Schematics.png "Simplified USB Schema"
-
-
-
-USB API
-
-The following header files define the Application Programming Interface (API) for the USB interface:
- - \b %Driver_USB.h : Common definitions of the USBD and USBH interface
- - \b %Driver_USBD.h : Driver API for USB Device Peripheral
- - \b %Driver_USBH.h : Driver API for USB Host Peripheral
-
-The driver implementation is a typical part of the Device Family Pack (DFP) that supports the
-peripherals of the microcontroller family.
-
-
-Driver Functions
-
-The driver functions are published in the access struct as explained in \ref DriverFunctions
- - \ref ARM_DRIVER_USBD : access struct for USBD driver functions
- - \ref ARM_DRIVER_USBH : access struct for USBH driver functions
-
-USB Device API
-
-The header file \b Driver_USBD.h defines the API for the USB Device Driver interface used by middleware components.
-The driver implementation itself is a typical part of the Device Family Pack, which provides entry points to the interface
-as function pointers in the struct \ref ARM_DRIVER_USBD. This structure can be available several times in each interface to control multiple USBD interfaces.
-
-Header file \b Driver_USBD.h also defines callback routines that can be categorized as
-device event callbacks and endpoint event callbacks .
-Callbacks are called by the driver, in interrupt context when an appropriate event occurs, to signal device related events (\ref USBD_dev_events)
-and endpoint related events (\ref USBD_ep_events).
-
-
-USB Device Function Call Sequence
-
-To use the USBD driver invoke the API functions in the following order:
-
-\msc
- a [label="", textcolor="indigo", linecolor="indigo", arclinecolor="red"],
- b [label="", textcolor="blue", linecolor="blue", arclinecolor="blue"];
-
- a rbox a [label="Middleware", linecolor="indigo"],
- b rbox b [label="USBD Driver", linecolor="blue"];
- a=>b [label="ARM_USBD_Initialize", URL="\ref ARM_USBD_Initialize"];
- a=>b [label="ARM_USBD_PowerControl (ARM_POWER_FULL)", URL="\ref ARM_USBD_Initialize"];
- a=>b [label="ARM_USBD_DeviceConnect", URL="\ref ARM_USBD_DeviceConnect"];
- a<=b [label="ARM_USBD_SignalDeviceEvent (ARM_USBD_EVENT_RESET)", URL="\ref ARM_USBD_SignalDeviceEvent", linecolor="orange"];
- a=>b [label="ARM_USBD_DeviceGetState", URL="\ref ARM_USBD_DeviceGetState"];
- a=>b [label="ARM_USBD_EndpointConfigure", URL="\ref ARM_USBD_EndpointConfigure", linecolor="green"];
- --- [label="Repeat and use as needed"];
- a=>b [label="ARM_USBD_EndpointTransfer", URL="\ref ARM_USBD_EndpointTransfer", linecolor="green"];
- a<=b [label="ARM_USBD_SignalEndpointEvent", URL="\ref ARM_USBD_SignalEndpointEvent", linecolor="orange"];
- a=>b [label="ARM_USBD_EndpointTransferGetResult", URL="\ref ARM_USBD_EndpointTransferGetResult", linecolor="green"];
- --- [label="Repeat End"];
- a=>b [label="ARM_USBD_DeviceDisconnect", URL="\ref ARM_USBD_DeviceDisconnect"];
- a=>b [label="ARM_USBD_PowerControl (ARM_POWER_OFF)", URL="\ref ARM_USBD_Initialize"];
- a=>b [label="ARM_USBD_Uninitialize", URL="\ref ARM_USBD_Uninitialize"];
-\endmsc
-
-*/
-
-/**
-\addtogroup usbh_interface_gr
-\ingroup usb_interface_gr
-\details
-USB Host API
-
-The header file \b Driver_USBH.h defines the API for the USB Host Driver interface used by middleware components.
-The driver implementation itself is a typical part of the Device Family Pack, which provides entry points to the interface
-as function pointers in the struct \ref ARM_DRIVER_USBH. This structure can be available several times in each interface to control multiple USBH interfaces.
-
-\b Driver_USBH.h also defines callback routines, which are categorized in
-port event callbacks and pipe event callbacks .
-Callbacks are called by the driver, in interrupt context when an appropriate event occurs, to signal port related events (\ref ARM_USBH_SignalPortEvent)
-and pipe related events (\ref ARM_USBH_SignalPipeEvent).
-
-\cond
-
-USB Host Function Call Sequence
-
-To use the USBH driver invoke the API functions in the following order:
-
-\msc
- a [label="", textcolor="indigo", linecolor="indigo", arclinecolor="red"],
- b [label="", textcolor="blue", linecolor="blue", arclinecolor="blue"];
-
- a rbox a [label="Middleware", linecolor="indigo"],
- b rbox b [label="USBH Driver", linecolor="blue"];
- a=>b [label="ARM_USBH_Initialize", URL="\ref ARM_USBD_Initialize"];
- --- [label="Repeat and use as needed"];
- --- [label="Repeat End"];
- a=>b [label="ARM_USBH_Uninitialize", URL="\ref ARM_USBH_Uninitialize"];
-\endmsc
-
- Driver_USBDn .
-The default is \token{0}, which connects a middleware to the first instance of a driver.
-
-\note The struct must remain unchanged.
-*****************************************************************************************************************/
-
-/**
-\struct ARM_USBD_CAPABILITIES
-\details
-A USB Device driver can be implemented with different capabilities.
-The data fields of this structure encode the capabilities implemented by this driver.
-
-Returned by:
- - \ref ARM_USBD_GetCapabilities
-
-\note The struct must remain unchanged.
-*****************************************************************************************************************/
-
-/**
-\struct ARM_USBD_STATE
-\details
-This structure stores information about the state of the USB Device. The data fields encode the established speed,
-whether the device is powered and active.
-
-Returned by:
- - \ref ARM_USBD_DeviceGetState
-*****************************************************************************************************************/
-
-/**
-\typedef ARM_USBD_SignalDeviceEvent_t
-\details
-Provides the typedef for the callback function \ref ARM_USBD_SignalDeviceEvent.
-
-Parameter for:
- - \ref ARM_USBD_Initialize
-*******************************************************************************************************************/
-
-/**
-\typedef ARM_USBD_SignalEndpointEvent_t
-\details
-Provides the typedef for the callback function \ref ARM_USBD_SignalEndpointEvent.
-
-Parameter for:
- - \ref ARM_USBD_Initialize
-*******************************************************************************************************************/
-
-/**
-\defgroup USBD_dev_events USBD Device Events
-\ingroup usbd_interface_gr
-\brief The USB Device driver generates Device call back events that are notified via the function \ref ARM_USBD_SignalDeviceEvent.
-\details
-This section provides the event values for the \ref ARM_USBD_SignalDeviceEvent callback function.
-
-The following call back notification events are generated:
-@{
-\def ARM_USBD_EVENT_VBUS_ON
-\def ARM_USBD_EVENT_VBUS_OFF
-\def ARM_USBD_EVENT_RESET
-\def ARM_USBD_EVENT_HIGH_SPEED
-\def ARM_USBD_EVENT_SUSPEND
-\def ARM_USBD_EVENT_RESUME
-@}
-*/
-
-/**
-\defgroup USBD_ep_events USBD Endpoint Events
-\ingroup usbd_interface_gr
-\brief The USB Device driver generates Endpoint call back events that are notified via the function \ref ARM_USBD_SignalEndpointEvent.
-\details
-This section provides the event values for the \ref ARM_USBD_SignalEndpointEvent callback function.
-
-The following call back notification events are generated:
-@{
-\def ARM_USBD_EVENT_SETUP
-\def ARM_USBD_EVENT_OUT
-\def ARM_USBD_EVENT_IN
-@}
-*/
-
-
-//
-// Functions
-//
-
-ARM_DRIVER_VERSION ARM_USBD_GetVersion (void) {
- return { 0, 0 };
-}
-/**
-\fn ARM_DRIVER_VERSION ARM_USBD_GetVersion (void)
-\details
-The function \b ARM_USBD_GetVersion returns version information of the driver implementation in \ref ARM_DRIVER_VERSION
- - API version is the version of the CMSIS-Driver specification used to implement this driver.
- - Driver version is source code version of the actual driver implementation.
-
-Example:
-\code
-extern ARM_DRIVER_USBD Driver_USBD0;
-ARM_DRIVER_USBD *drv_info;
-
-void setup_usbd (void) {
- ARM_DRIVER_VERSION version;
-
- drv_info = &Driver_USBD0;
- version = drv_info->GetVersion ();
- if (version.api < 0x10A) { // requires at minimum API version 1.10 or higher
- // error handling
- return;
- }
-}
-\endcode
-*****************************************************************************************************************/
-
-ARM_USBD_CAPABILITIES ARM_USBD_GetCapabilities (void) {
- return { 0 };
-}
-/**
-\fn ARM_USBD_CAPABILITIES ARM_USBD_GetCapabilities (void)
-\details
-The function \b ARM_USBD_GetCapabilities returns information about capabilities in this driver implementation.
-The data fields of the structure \ref ARM_USBD_CAPABILITIES encode various capabilities, for example
-if the hardware can create signal events using the \ref ARM_USBD_SignalDeviceEvent callback function.
-
-Example:
-\code
-extern ARM_DRIVER_USBD Driver_USBD0;
-ARM_DRIVER_USBD *drv_info;
-
-void read_capabilities (void) {
- ARM_USBD_CAPABILITIES drv_capabilities;
-
- drv_info = &Driver_USBD0;
- drv_capabilities = drv_info->GetCapabilities ();
- // interrogate capabilities
-
-}
-\endcode
-*****************************************************************************************************************/
-
-int32_t ARM_USBD_Initialize (ARM_USBD_SignalDeviceEvent_t cb_device_event,
- ARM_USBD_SignalEndpointEvent_t cb_endpoint_event) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_USBD_Initialize (ARM_USBD_SignalDeviceEvent_t cb_device_event, ARM_USBD_SignalEndpointEvent_t cb_endpoint_event)
-\details
-The function \b ARM_USBD_Initialize initializes the USB Device interface.
-It is called when the middleware component starts operation.
-
-The function performs the following operations:
- - Initializes the resources needed for the USBD interface.
- - Registers the \ref ARM_USBD_SignalDeviceEvent callback function.
- - Registers the \ref ARM_USBD_SignalEndpointEvent callback function.
-
-The parameter \em cb_device_event is a pointer to the \ref ARM_USBD_SignalDeviceEvent callback function; use a NULL pointer
-when no device callback signals are required. \n
-The parameter \em cb_endpoint_event is a pointer to the \ref ARM_USBD_SignalEndpointEvent callback function.
-
-\b Example:
- - see \ref usbd_interface_gr - Driver Functions
-
-*****************************************************************************************************************/
-
-int32_t ARM_USBD_Uninitialize (void) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_USBD_Uninitialize (void)
-\details
-The function \b ARM_USBD_Uninitialize de-initializes the resources of USBD interface.
-
-It is called when the middleware component stops operation and releases the software resources used by the interface.
-*****************************************************************************************************************/
-
-int32_t ARM_USBD_PowerControl (ARM_POWER_STATE state) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_USBD_PowerControl (ARM_POWER_STATE state)
-\details
-The function \b ARM_USBD_PowerControl operates the power modes of the USB Device interface.
-
-The parameter \em state sets the operation and can have the following values:
- - \ref ARM_POWER_FULL : set-up peripheral for data transfers, enable interrupts (NVIC) and optionally DMA.
- Can be called multiple times. If the peripheral is already in this mode the function performs
- no operation and returns with \ref ARM_DRIVER_OK.
- - \ref ARM_POWER_LOW : may use power saving. Returns \ref ARM_DRIVER_ERROR_UNSUPPORTED when not implemented.
- - \ref ARM_POWER_OFF : terminates any pending data transfers, disables peripheral, disables related interrupts and DMA.
-
-Refer to \ref CallSequence for more information.
-*****************************************************************************************************************/
-
-int32_t ARM_USBD_DeviceConnect (void) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_USBD_DeviceConnect (void)
-\details
-The function \b ARM_USBD_DeviceConnect signals to the host that the device is connected.
-*****************************************************************************************************************/
-
-int32_t ARM_USBD_DeviceDisconnect (void) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_USBD_DeviceDisconnect (void)
-\details
-The function \b ARM_USBD_DeviceDisconnect signals to the host that the device is disconnected.
-*****************************************************************************************************************/
-
-ARM_USBD_STATE ARM_USBD_DeviceGetState (void) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn ARM_USBD_STATE ARM_USBD_DeviceGetState (void)
-\details
-Retrieves the current USB device state.
-*****************************************************************************************************************/
-
-int32_t ARM_USBD_DeviceRemoteWakeup (void) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_USBD_DeviceRemoteWakeup (void)
-\details
-The function \b ARM_USBD_DeviceRemoteWakeup signals remote wakeup to the host.
-*****************************************************************************************************************/
-
-int32_t ARM_USBD_DeviceSetAddress (uint8_t dev_addr) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_USBD_DeviceSetAddress (uint8_t dev_addr)
-\details
-Assigns an address to the device.
-\note This function is called after status stage of the Set Address request (after IN packet in status stage was sent with the old address).
-
-*****************************************************************************************************************/
-
-int32_t ARM_USBD_ReadSetupPacket (uint8_t *setup) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_USBD_ReadSetupPacket (uint8_t *setup)
-\details
-The function \b ARM_USBD_ReadSetupPacket reads the last SETUP packet (8 bytes) that was received over Control Endpoint (Endpoint 0)
-which is indicated by \ref ARM_USBD_EVENT_SETUP event.
-
-See also:
- - \ref ARM_USBD_SignalEndpointEvent
-*****************************************************************************************************************/
-
-int32_t ARM_USBD_EndpointConfigure (uint8_t ep_addr,
- uint8_t ep_type,
- uint16_t ep_max_packet_size) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_USBD_EndpointConfigure (uint8_t ep_addr, uint8_t ep_type, uint16_t ep_max_packet_size)
-\details
-The function \b ARM_USBD_EndpointConfigure configures an endpoint for transfers.
-
-
-*****************************************************************************************************************/
-
-int32_t ARM_USBD_EndpointUnconfigure (uint8_t ep_addr) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_USBD_EndpointUnconfigure (uint8_t ep_addr)
-\details
-The function \b ARM_USBD_EndpointUnconfigure de-configures the specified endpoint.
-
-The parameter \em ep_addr specifies the endpoint address.
-*****************************************************************************************************************/
-
-int32_t ARM_USBD_EndpointStall (uint8_t ep_addr, bool stall) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_USBD_EndpointStall (uint8_t ep_addr, bool stall)
-\details
-The function \b ARM_USBD_EndpointStall sets or clears stall condition for the specified endpoint.
-
-The parameter \em ep_addr specifies the endpoint address. \n
-The parameter \em stall is a boolean parameter.
-*****************************************************************************************************************/
-
-int32_t ARM_USBD_EndpointTransfer (uint8_t ep_addr, uint8_t *data, uint32_t num) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_USBD_EndpointTransfer (uint8_t ep_addr, uint8_t *data, uint32_t num)
-\details
-
-The function \b ARM_USBD_EndpointTransfer reads from or writes data to an USB Endpoint.
-
-The parameter \em ep_addr specifies the endpoint address. \n
-The parameter \em data is a buffer for data to read or data to write. \n
-The parameter \em num is the number of bytes to transfer (must be multiple of endpoint maximum packet size for Read transfers).
-
-The function is non-blocking and returns as soon as the driver starts the operation on the specified endpoint.
-During the operation it is not allowed to call this function again on the same endpoint.
-Also the data buffer must stay allocated and the contents of data must not be modified.
-
-Direction in the endpoint address specifies the type of transfer:
-- Endpoint Read for OUT endpoint (direction = 0)
-- Endpoint Write for IN endpoint (direction = 1)
-
-Endpoint Read is finished when the requested number of data bytes have been received or when a short packet or ZLP (Zero-Length Packet) has been received.
-Completion of operation is indicated by \ref ARM_USBD_EVENT_OUT event. Number of successfully received data bytes can be retrieved
-by calling \ref ARM_USBD_EndpointTransferGetResult.
-
-Endpoint Write is finished when the requested number of data bytes have been sent.
-Completion of operation is indicated by \ref ARM_USBD_EVENT_IN event. Number of successfully sent data bytes can be retrieved
-by calling \ref ARM_USBD_EndpointTransferGetResult.
-
-Transfer operation can be aborted by calling \ref ARM_USBD_EndpointTransferAbort.
-*****************************************************************************************************************/
-
-uint32_t ARM_USBD_EndpointTransferGetResult (uint8_t ep_addr) {
- return 0;
-}
-/**
-\fn uint32_t ARM_USBD_EndpointTransferGetResult (uint8_t ep_addr)
-\details
-The function \b ARM_USBD_EndpointTransferGetResult returns the number of successfully transferred data bytes started by \ref ARM_USBD_EndpointTransfer.
-
-The parameter \em ep_addr specifies the endpoint address.
-*****************************************************************************************************************/
-
-int32_t ARM_USBD_EndpointTransferAbort (uint8_t ep_addr) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_USBD_EndpointTransferAbort (uint8_t ep_addr)
-\details
-The function \b ARM_USBD_EndpointTransferAbort aborts the transfer to an endpoint started by \ref ARM_USBD_EndpointTransfer.
-
-The parameter \em ep_addr specifies the endpoint address.
-*****************************************************************************************************************/
-
-uint16_t ARM_USBD_GetFrameNumber (void) {
- return 0;
-}
-/**
-\fn uint16_t ARM_USBD_GetFrameNumber (void)
-\details
-Retrieves the sequential 11-bit frame number of the last Start of Frame (SOF) packet.
-*****************************************************************************************************************/
-
-void ARM_USBD_SignalDeviceEvent (uint32_t event) {
- // function body
-}
-/**
-\fn void ARM_USBD_SignalDeviceEvent (uint32_t event)
-\details
-The function \b ARM_USBD_SignalDeviceEvent is a callback function registered by the function \ref ARM_USBD_Initialize.
-
-The parameter \em event indicates one or more events that occurred during driver operation.
-Each event is encoded in a separate bit and therefore it is possible to signal multiple events within the same call.
-
-Not every event is necessarily generated by the driver. This depends on the implemented capabilities stored in the
-data fields of the structure \ref ARM_USBD_CAPABILITIES, which can be retrieved with the function \ref ARM_USBD_GetCapabilities.
-
-The following events can be generated:
-
-Event | Bit| Description | supported when \ref ARM_USBD_CAPABILITIES
-:-------------------------------|---:|:---------------------------------------------------|----------------------------------------------
-\ref ARM_USBD_EVENT_VBUS_ON | 0 | Occurs when valid VBUS voltage is detected. | data field \em event_vbus_on = \token{1}
-\ref ARM_USBD_EVENT_VBUS_OFF | 1 | Occurs when VBUS voltage is turned off. | data field \em event_vbus_off = \token{1}
-\ref ARM_USBD_EVENT_RESET | 2 | Occurs when USB Reset is detected. | always supported
-\ref ARM_USBD_EVENT_HIGH_SPEED | 3 | Occurs when USB Device is switched to High-speed. | always supported
-\ref ARM_USBD_EVENT_SUSPEND | 4 | Occurs when USB Suspend is detected. | always supported
-\ref ARM_USBD_EVENT_RESUME | 5 | Occurs when USB Resume is detected. | always supported
-*****************************************************************************************************************/
-
-void ARM_USBD_SignalEndpointEvent (uint8_t ep_addr, uint32_t ep_event) {
- // function body
-}
-/**
-\fn void ARM_USBD_SignalEndpointEvent (uint8_t ep_addr, uint32_t event)
-\details
-The function \b ARM_USBD_SignalEndpointEvent is a callback function registered by the function \ref ARM_USBD_Initialize.
-
-The argument \a ep_addr specifies the endpoint. \n
-The parameter \em event indicates one or more events that occurred during driver operation.
-Each event is encoded in a separate bit and therefore it is possible to signal multiple events within the same call.
-
-The following events can be generated:
-
-Event | Bit | Description
-:----------------------------------------|----:|:-----------
-\ref ARM_USBD_EVENT_SETUP | 0 | Occurs when SETUP packet is received over Control Endpoint.
-\ref ARM_USBD_EVENT_OUT | 1 | Occurs when data is received over OUT Endpoint.
-\ref ARM_USBD_EVENT_IN | 2 | Occurs when data is sent over IN Endpoint.
-*****************************************************************************************************************/
-
-/**
-@}
-*/
-// End USBD Interface
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/Driver_USBH.c b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/Driver_USBH.c
deleted file mode 100644
index 73f968a..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/Driver_USBH.c
+++ /dev/null
@@ -1,681 +0,0 @@
-/**
-\defgroup usbh_interface_gr USB Host Interface
-\ingroup usb_interface_gr
-\brief Driver API for USB Host Peripheral (%Driver_USBH.h)
-*/
-
-/**
-\defgroup usbh_host_gr USB Host
-\ingroup usbh_interface_gr
-\brief Driver API for USB Host
-
-@{
-*/
-
-/**
-\struct ARM_DRIVER_USBH
-\details
-The functions of the USB Host driver are accessed by function pointers. Refer to \ref DriverFunctions for
-overview information.
-
-Each instance of an USBH provides such an access struct. The instance is indicated by
-a postfix in the symbol name of the access struct, for example:
- - \b Driver_USBH0 is the name of the access struct of the first instance (no. 0).
- - \b Driver_USBH1 is the name of the access struct of the second instance (no. 1).
-
-
-A configuration setting in the middleware allows connecting the middleware to a specific driver instance Driver_USBHn .
-The default is \token{0}, which connects a middleware to the first instance of a driver.
-
-\note The struct must remain unchanged.
-*****************************************************************************************************************/
-
-/**
-\struct ARM_USBH_CAPABILITIES
-\details
-A USB Host driver can be implemented with different capabilities.
-The data fields of this structure encode the capabilities implemented by this driver.
-
-Returned by:
- - \ref ARM_USBH_GetCapabilities
-
-\note The struct must remain unchanged.
-*****************************************************************************************************************/
-
-/**
-\struct ARM_USBH_PORT_STATE
-\details
-This structure stores information about the state of the USB Host Port. The data fields encode whether a device
-is connected to the port, if port overcurrent is detected, and the port speed.
-
-Returned by:
- - \ref ARM_USBH_PortGetState
-*****************************************************************************************************************/
-
-/**
-\typedef uint32_t ARM_USBH_PIPE_HANDLE
-\details
-Each pipe is identified through a unique number, which is created by the function \ref ARM_USBH_PipeCreate.
-
-Parameter for:
- - \ref ARM_USBH_PipeModify,
- \ref ARM_USBH_PipeDelete,
- \ref ARM_USBH_PipeReset,
- \ref ARM_USBH_PipeTransfer,
- \ref ARM_USBH_PipeTransferGetResult,
- \ref ARM_USBH_PipeTransferAbort,
- \ref ARM_USBH_SignalPipeEvent
-
-Retruned by:
- - \ref ARM_USBH_PipeCreate
-*****************************************************************************************************************/
-
-/**
-\typedef ARM_USBH_SignalPortEvent_t
-\details
-Provides the typedef for the callback function \ref ARM_USBH_SignalPortEvent.
-
-Parameter for:
- - \ref ARM_USBH_Initialize
-*******************************************************************************************************************/
-
-/**
-\typedef ARM_USBH_SignalPipeEvent_t
-\details
-Provides the typedef for the callback function \ref ARM_USBH_SignalPipeEvent.
-
-Parameter for:
- - \ref ARM_USBH_Initialize
-*******************************************************************************************************************/
-
-/**
-\defgroup USBH_port_events USBH Port Events
-\ingroup usbh_host_gr
-\brief The USB Host driver generates Port call back events that are notified via the function \ref ARM_USBH_SignalPortEvent.
-\details
-This section provides the event values for the \ref ARM_USBH_SignalPortEvent callback function.
-
-The following call back notification events are generated:
-@{
-\def ARM_USBH_EVENT_CONNECT
-\def ARM_USBH_EVENT_DISCONNECT
-\def ARM_USBH_EVENT_OVERCURRENT
-\def ARM_USBH_EVENT_RESET
-\def ARM_USBH_EVENT_SUSPEND
-\def ARM_USBH_EVENT_RESUME
-\def ARM_USBH_EVENT_REMOTE_WAKEUP
-@}
-*/
-
-/**
-\defgroup USBH_pipe_events USBH Pipe Events
-\ingroup usbh_host_gr
-\brief The USB Host driver generates Pipe call back events that are notified via the function \ref ARM_USBH_SignalPipeEvent.
-\details
-This section provides the event values for the \ref ARM_USBH_SignalPipeEvent callback function.
-
-The following call back notification events are generated:
-@{
-\def ARM_USBH_EVENT_TRANSFER_COMPLETE
-\def ARM_USBH_EVENT_HANDSHAKE_NAK
-\def ARM_USBH_EVENT_HANDSHAKE_NYET
-\def ARM_USBH_EVENT_HANDSHAKE_MDATA
-\def ARM_USBH_EVENT_HANDSHAKE_STALL
-\def ARM_USBH_EVENT_HANDSHAKE_ERR
-\def ARM_USBH_EVENT_BUS_ERROR
-@}
-*/
-
-/**
-\defgroup USBH_packets USBH Packet Information
-\ingroup usbh_host_gr
-\brief Specify USB packet information used by the function \ref ARM_USBH_PipeTransfer
-\details
-This section provides the packet information values (parameter \em packet) for the \ref ARM_USBH_PipeTransfer function.
-
-The following values are defined:
-@{
-\def ARM_USBH_PACKET_SETUP
-Generate SETUP transaction.
-\def ARM_USBH_PACKET_OUT
-Generate OUT transaction.
-\def ARM_USBH_PACKET_IN
-Generate IN transaction.
-\def ARM_USBH_PACKET_PING
-Generate PING transaction (no data packet).
-\def ARM_USBH_PACKET_DATA0
-Force DATA0 PID (Packet Identifier) for the initial data packet. When not specified than the driver provides the initial value according to the current state.
-\def ARM_USBH_PACKET_DATA1
-Force DATA1 PID (Packet Identifier) for the initial data packet. When not specified than the driver provides the initial value according to the current state.
-\def ARM_USBH_PACKET_SSPLIT
-Used when driver does not support automatic handling of SPLIT packets and indicates Start-Split packet.
-For isochronous OUT it indicates that the High-speed data is in the middle of the Full-speed data payload.
-\def ARM_USBH_PACKET_SSPLIT_S
-Used when driver does not support automatic handling of SPLIT packets and indicates Start-Split packet.
-Valid only for isochronous OUT and indicates that the High-speed data is the start of the Full-speed data payload.
-\def ARM_USBH_PACKET_SSPLIT_E
-Used when driver does not support automatic handling of SPLIT packets and indicates Start-Split packet.
-Valid only for isochronous OUT and indicates that the High-speed data is the end of the Full-speed data payload.
-\def ARM_USBH_PACKET_SSPLIT_S_E
-Used when driver does not support automatic handling of SPLIT packets and indicates Start-Split packet.
-Valid only for isochronous OUT and indicates that the High-speed data is all of the Full-speed data payload.
-\def ARM_USBH_PACKET_CSPLIT
-Used when driver does not support automatic handling of SPLIT packets and indicates Complete-Split packet.
-\def ARM_USBH_PACKET_PRE
-Generate PRE (Preamble) for low-speed devices within a full/low-speed signaling environment.
-@}
-*/
-
-
-//
-// Functions
-//
-
-ARM_DRIVER_VERSION ARM_USBH_GetVersion (void) {
- return { 0, 0 };
-}
-/**
-\fn ARM_DRIVER_VERSION ARM_USBH_GetVersion (void)
-\details
-The function \b ARM_USBH_GetVersion returns version information of the driver implementation in \ref ARM_DRIVER_VERSION
- - API version is the version of the CMSIS-Driver specification used to implement this driver.
- - Driver version is source code version of the actual driver implementation.
-
-Example:
-\code
-extern ARM_DRIVER_USBH Driver_USBH0;
-ARM_DRIVER_USBH *drv_info;
-
-void setup_usbh (void) {
- ARM_DRIVER_VERSION version;
-
- drv_info = &Driver_USBH0;
- version = drv_info->GetVersion ();
- if (version.api < 0x10A) { // requires at minimum API version 1.10 or higher
- // error handling
- return;
- }
-}
-\endcode
-*****************************************************************************************************************/
-
-ARM_USBH_CAPABILITIES ARM_USBH_GetCapabilities (void) {
- return { 0 };
-}
-/**
-\fn ARM_USBH_CAPABILITIES ARM_USBH_GetCapabilities (void)
-\details
-The function \b ARM_USBH_GetCapabilities returns information about capabilities in this driver implementation.
-The data fields of the structure \ref ARM_USBH_CAPABILITIES encode various capabilities, for example
-available HUB ports or if the hardware can generate signal events using the \ref ARM_USBH_SignalPortEvent
-callback function.
-
-Example:
-\code
-extern ARM_DRIVER_USBH Driver_USBH0;
-ARM_DRIVER_USBH *drv_info;
-
-void read_capabilities (void) {
- ARM_USBH_CAPABILITIES drv_capabilities;
-
- drv_info = &Driver_USBH0;
- drv_capabilities = drv_info->GetCapabilities ();
- // interrogate capabilities
-
-}
-\endcode
-*****************************************************************************************************************/
-
-int32_t ARM_USBH_Initialize (ARM_USBH_SignalPortEvent_t cb_port_event,
- ARM_USBH_SignalPipeEvent_t cb_pipe_event) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_USBH_Initialize (ARM_USBH_SignalPortEvent_t cb_port_event, ARM_USBH_SignalPipeEvent_t cb_pipe_event)
-\details
-The function \b ARM_USBH_Initialize initializes the USB Host interface.
-It is called when the middleware component starts operation.
-
-The function performs the following operations:
- - Initializes the resources needed for the USBH interface.
- - Registers the \ref ARM_USBH_SignalPortEvent callback function.
- - Registers the \ref ARM_USBH_SignalPipeEvent callback function.
-
-The parameter \em cb_port_event is a pointer to the \ref ARM_USBH_SignalPortEvent callback function; use a NULL pointer
-when no port callback signals are required.
-
-The parameter \em cb_pipe_event is a pointer to the \ref ARM_USBH_SignalPipeEvent callback function.
-
-\b Example:
- - see \ref usbh_interface_gr - Driver Functions
-
-*****************************************************************************************************************/
-
-int32_t ARM_USBH_Uninitialize (void) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_USBH_Uninitialize (void)
-\details
-The function \b ARM_USBH_Uninitialize de-initializes the resources of USB Host interface.
-
-It is called when the middleware component stops operation and releases the software resources used by the interface.
-*****************************************************************************************************************/
-
-int32_t ARM_USBH_PowerControl (ARM_POWER_STATE state) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_USBH_PowerControl (ARM_POWER_STATE state)
-\details
-The function \b ARM_USBH_PowerControl operates the power modes of the USB Host interface.
-
-The parameter \em state sets the operation and can have the following values:
- - \ref ARM_POWER_FULL : set-up peripheral for data transfers, enable interrupts (NVIC) and optionally DMA.
- Can be called multiple times. If the peripheral is already in this mode the function performs
- no operation and returns with \ref ARM_DRIVER_OK.
- - \ref ARM_POWER_LOW : may use power saving. Returns \ref ARM_DRIVER_ERROR_UNSUPPORTED when not implemented.
- - \ref ARM_POWER_OFF : terminates any pending data transfers, disables peripheral, disables related interrupts and DMA.
-
-Refer to \ref CallSequence for more information.
-*****************************************************************************************************************/
-
-int32_t ARM_USBH_PortVbusOnOff (uint8_t port, bool vbus) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_USBH_PortVbusOnOff (uint8_t port, bool vbus)
-\details
-The function \b ARM_USBH_PortVbusOnOff controls the VBUS signal of the specified port.
-*****************************************************************************************************************/
-
-int32_t ARM_USBH_PortReset (uint8_t port) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_USBH_PortReset (uint8_t port)
-\details
-Executes reset signalling on the specified port.
-*****************************************************************************************************************/
-
-int32_t ARM_USBH_PortSuspend (uint8_t port) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_USBH_PortSuspend (uint8_t port)
-\details
-The function \b ARM_USBH_PortSuspend auspends USB signaling on the specified port.
-*****************************************************************************************************************/
-
-int32_t ARM_USBH_PortResume (uint8_t port) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_USBH_PortResume (uint8_t port)
-\details
-The function \b ARM_USBH_PortResume resumes USB signaling on the specified port.
-*****************************************************************************************************************/
-
-ARM_USBH_PORT_STATE ARM_USBH_PortGetState (uint8_t port) {
- return 0;
-}
-/**
-\fn ARM_USBH_PORT_STATE ARM_USBH_PortGetState (uint8_t port)
-\details
-The function \b ARM_USBH_PortGetState returns the current state of the specified port.
-*****************************************************************************************************************/
-
-ARM_USBH_PIPE_HANDLE ARM_USBH_PipeCreate (uint8_t dev_addr,
- uint8_t dev_speed,
- uint8_t hub_addr,
- uint8_t hub_port,
- uint8_t ep_addr,
- uint8_t ep_type,
- uint16_t ep_max_packet_size,
- uint8_t ep_interval) {
- return 0;
-}
-/**
-\fn ARM_USBH_PIPE_HANDLE ARM_USBH_PipeCreate (uint8_t dev_addr, uint8_t dev_speed, uint8_t hub_addr, uint8_t hub_port, uint8_t ep_addr, uint8_t ep_type, uint16_t ep_max_packet_size, uint8_t ep_interval)
-\details
-The function \b ARM_USBH_PipeCreate creates a pipe for transfers (allocates required resources and configures the pipe).
-
-The parameters specify pipe information (connection between host and device endpoint):
- - device: address and speed
- - hub (optional): hub address and number of the hub port to which the device is connected
- - endpoint: address, type, maximum packet size and polling interval
-
-The function returns an pipe handle that is used for all subsequent operations on that pipe.
-In case of errors an invalid handle (\em NULL) is returned.
-*****************************************************************************************************************/
-
-int32_t ARM_USBH_PipeModify (ARM_USBH_PIPE_HANDLE pipe_hndl,
- uint8_t dev_addr,
- uint8_t dev_speed,
- uint8_t hub_addr,
- uint8_t hub_port,
- uint16_t ep_max_packet_size) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_USBH_PipeModify (ARM_USBH_PIPE_HANDLE pipe_hndl, uint8_t dev_addr, uint8_t dev_speed, uint8_t hub_addr, uint8_t hub_port, uint16_t ep_max_packet_size)
-\details
-The function \b ARM_USBH_PipeModify modifies a pipe configuration that was created with \ref ARM_USBH_PipeCreate.
-*****************************************************************************************************************/
-
-int32_t ARM_USBH_PipeDelete (ARM_USBH_PIPE_HANDLE pipe_hndl) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_USBH_PipeDelete (ARM_USBH_PIPE_HANDLE pipe_hndl)
-\details
-The function \b ARM_USBH_PipeDelete deletes a pipe that was created with \ref ARM_USBH_PipeCreate (deactivates the pipe and releases used resources).
-*****************************************************************************************************************/
-
-int32_t ARM_USBH_PipeReset (ARM_USBH_PIPE_HANDLE pipe_hndl) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_USBH_PipeReset (ARM_USBH_PIPE_HANDLE pipe_hndl)
-\details
-The function \b ARM_USBH_PipeReset clears Halt condition and resets data toggle on the specified pipe.
-*****************************************************************************************************************/
-
-int32_t ARM_USBH_PipeTransfer (ARM_USBH_PIPE_HANDLE pipe_hndl,
- uint32_t packet,
- uint8_t *data,
- uint32_t num) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_USBH_PipeTransfer (ARM_USBH_PIPE_HANDLE pipe_hndl, uint32_t packet, uint8_t *data, uint32_t num)
-\details
-The function \b ARM_USBH_PipeTransfer generates packets for sending or receiving data from an USB Endpoint.
-
-The function specifies the buffer with data to send or for data to receive and the number of bytes to transfer (must be multiple of device endpoint maximum packet size for receive).
-It also specifies \ref USBH_packets with parameter \em packet.
-
-The function is non-blocking and returns as soon as the driver starts the operation on the specified pipe. During the operation it is not allowed to call this function again on the same pipe. Also the data buffer must stay allocated and the contents of data must not be modified.
-
-Operation is completed when the the requested number of data bytes have been transferred and is indicated with \ref ARM_USBH_EVENT_TRANSFER_COMPLETE event.
-It can also finish earlier on reception of different handshake tokens which are also indicated through \ref USBH_pipe_events.
-
-Transfer operation can be aborted by calling \ref ARM_USBH_PipeTransferAbort.
-*****************************************************************************************************************/
-
-uint32_t ARM_USBH_PipeTransferGetResult (ARM_USBH_PIPE_HANDLE pipe_hndl) {
- return 0;
-}
-/**
-\fn uint32_t ARM_USBH_PipeTransferGetResult (ARM_USBH_PIPE_HANDLE pipe_hndl)
-\details
-The function \b ARM_USBH_PipeTransferGetResult returns the number of successfully transferred data bytes started by \ref ARM_USBH_PipeTransfer operation.
-*****************************************************************************************************************/
-
-int32_t ARM_USBH_PipeTransferAbort (ARM_USBH_PIPE_HANDLE pipe_hndl) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_USBH_PipeTransferAbort (ARM_USBH_PIPE_HANDLE pipe_hndl)
-\details
-
-The function \b ARM_USBH_PipeTransferAbort aborts an active pipe transfer started by \ref ARM_USBH_PipeTransfer.
-*****************************************************************************************************************/
-
-uint16_t ARM_USBH_GetFrameNumber (void) {
- return 0;
-}
-/**
-\fn uint16_t ARM_USBH_GetFrameNumber (void)
-\details
-The function \b ARM_USBH_GetFrameNumber returns the sequential 11-bit frame number of the last Start of Frame (SOF) packet.
-*****************************************************************************************************************/
-
-void ARM_USBH_SignalPortEvent (uint8_t port, uint32_t event) {
- // function body
-}
-/**
-\fn void ARM_USBH_SignalPortEvent (uint8_t port, uint32_t event)
-\details
-The function \b ARM_USBH_SignalPortEvent is a callback function registered by the function \ref ARM_USBH_Initialize.
-
-The parameter \em port specifies the root hub port number. \n
-The parameter \em event indicates one or more events that occurred during driver operation.
-Each event is encoded in a separate bit and therefore it is possible to signal multiple events within the same call.
-
-Not every event is necessarily generated by the driver. This depends on the implemented capabilities stored in the
-data fields of the structure \ref ARM_USBH_CAPABILITIES, which can be retrieved with the function \ref ARM_USBH_GetCapabilities.
-
-The following events can be generated:
-
-Parameter \em event | Bit | Description | supported when ARM_USBH_CAPABILITIES
-:---------------------------------|:---:|:---------------------------------------------------------------------------|---------------------------------------
-\ref ARM_USBH_EVENT_CONNECT | 0 | Occurs when USB Device connects to the Host. | data field \em event_connect=\token{1}
-\ref ARM_USBH_EVENT_DISCONNECT | 1 | Occurs when USB Device disconnects from the Host. | data field \em event_disconnect=\token{1}
-\ref ARM_USBH_EVENT_OVERCURRENT | 2 | Occurs when USB Overcurrent it detected. | data field \em event_overcurrent=\token{1}
-\ref ARM_USBH_EVENT_RESET | 3 | Occurs when USB Reset is completed after calling \ref ARM_USBH_PortReset. | always supported
-\ref ARM_USBH_EVENT_SUSPEND | 4 | Occurs when USB Suspend is detected. | always supported
-\ref ARM_USBH_EVENT_RESUME | 5 | Occurs when USB Resume is detected. | always supported
-\ref ARM_USBH_EVENT_REMOTE_WAKEUP | 6 | Occurs when USB Remote wakeup is detected. | always supported
-*****************************************************************************************************************/
-
-void ARM_USBH_SignalPipeEvent (ARM_USBH_PIPE_HANDLE pipe_hndl, uint32_t event) {
- // function body
-}
-/**
-\fn void ARM_USBH_SignalPipeEvent (ARM_USBH_PIPE_HANDLE pipe_hndl, uint32_t event)
-\details
-The function \b ARM_USBH_SignalPipeEvent is a callback function registered by the function \ref ARM_USBH_Initialize.
-
-The parameter \em pipe_hndl specifies the pipe handle. \n
-The parameter \em event indicates one or more events that occurred during driver operation.
-Each event is encoded in a separate bit and therefore it is possible to signal multiple events within the same call.
-
-The following events can be generated:
-
-Parameter \em event | Bit| Description
-:-----------------------------------------|---:|:-----------
-\ref ARM_USBH_EVENT_TRANSFER_COMPLETE | 0 | Occurs after all the data has been transferred without errors.
-\ref ARM_USBH_EVENT_HANDSHAKE_NAK | 1 | Occurs when NAK Handshake is received before all the data is transferred.
-\ref ARM_USBH_EVENT_HANDSHAKE_NYET | 2 | Occurs when NYET Handshake is received before all the data is transferred.
-\ref ARM_USBH_EVENT_HANDSHAKE_MDATA | 3 | Occurs when MDATA Handshake is received before all the data is transferred.
-\ref ARM_USBH_EVENT_HANDSHAKE_STALL | 4 | Occurs when STALL Handshake is received before all the data is transferred.
-\ref ARM_USBH_EVENT_HANDSHAKE_ERR | 5 | Occurs when ERR Handshake is received before all the data is transferred.
-\ref ARM_USBH_EVENT_BUS_ERROR | 6 | Occurs when bus error is detected before all the data is transferred.
-
-See also:
- - ARM_USBH_PipeCreate
-*****************************************************************************************************************/
-
-/**
-@}
-*/
-
-
-
-/**
-\defgroup usbh_hci_gr USB OHCI/EHCI
-\ingroup usbh_interface_gr
-\brief Driver API for USB OHCI/EHCI
-\details
-OHCI and EHCI compliant interfaces have memory mapped registers that are used to control the USB host.
-
-Only certain functionalities (interrupts, VBUS control, power control) require device specific interface which is provided through functions
-of the struct \ref ARM_DRIVER_USBH_HCI (functionality accessed with the struct \ref ARM_DRIVER_USBH is not needed).
-@{
-*/
-
-/**
-\struct ARM_DRIVER_USBH_HCI
-\details
-The functions of the USB Host HCI (OHCI/EHCI) driver are accessed by function pointers. Refer to \ref DriverFunctions for
-overview information.
-
-Each instance of an USBH provides such an access struct. The instance is indicated by
-a postfix in the symbol name of the access struct, for example:
- - \b Driver_USBH0_HCI is the name of the access struct of the first instance (no. 0).
- - \b Driver_USBH1_HCI is the name of the access struct of the second instance (no. 1).
-
-
-A configuration setting in the middleware allows connecting the middleware to a specific driver instance Driver_USBHn _HCI .
-The default is \token{0}, which connects a middleware to the first instance of a driver.
-
-\note The struct must remain unchanged.
-*/
-
-
-/**
-\struct ARM_USBH_HCI_CAPABILITIES
-\details
-A USB Host HCI (OHCI/EHCI) driver can be implemented with different capabilities.
-The data fields of this structure encode the capabilities implemented by this driver.
-
-Returned by:
- - \ref ARM_USBH_HCI_GetCapabilities
-
-\note The struct must remain unchanged.
-*****************************************************************************************************************/
-
-/**
-\typedef ARM_USBH_HCI_Interrupt_t
-\details
-Provides the typedef for the interrupt handler \ref ARM_USBH_HCI_Interrupt.
-
-Parameter for:
- - \ref ARM_USBH_HCI_Initialize
-*******************************************************************************************************************/
-
-
-//
-// Functions
-//
-
-ARM_DRIVER_VERSION ARM_USBH_HCI_GetVersion (void) {
- return { 0, 0 };
-}
-/**
-\fn ARM_DRIVER_VERSION ARM_USBH_HCI_GetVersion (void)
-\details
-The function \b ARM_USBH_HCI_GetVersion returns version information of the driver implementation in \ref ARM_DRIVER_VERSION
- - API version is the version of the CMSIS-Driver specification used to implement this driver.
- - Driver version is source code version of the actual driver implementation.
-
-Example:
-\code
-extern ARM_DRIVER_USBH Driver_USBH0_HCI;
-ARM_DRIVER_USBH *drv_info;
-
-void setup_usbh (void) {
- ARM_DRIVER_VERSION version;
-
- drv_info = &Driver_USBH0_HCI;
- version = drv_info->GetVersion ();
- if (version.api < 0x10A) { // requires at minimum API version 1.10 or higher
- // error handling
- return;
- }
-}
-\endcode
-*****************************************************************************************************************/
-
-ARM_USBH_HCI_CAPABILITIES ARM_USBH_HCI_GetCapabilities (void) {
- return { 0 };
-}
-/**
-\fn ARM_USBH_HCI_CAPABILITIES ARM_USBH_HCI_GetCapabilities (void)
-\details
-The function \b ARM_USBH_HCI_GetCapabilities returns information about capabilities in this driver implementation.
-The data fields of the structure \ref ARM_USBH_HCI_CAPABILITIES encode various capabilities, for example
-available HUB ports.
-
-Example:
-\code
-extern ARM_DRIVER_USBH_HCI Driver_USBH0_HCI;
-ARM_DRIVER_USBH_HCI *drv_info;
-
-void read_capabilities (void) {
- ARM_USBH_HCI_CAPABILITIES drv_capabilities;
-
- drv_info = &Driver_USBH0_HCI;
- drv_capabilities = drv_info->GetCapabilities ();
- // interrogate capabilities
-
-}
-\endcode
-*****************************************************************************************************************/
-
-int32_t ARM_USBH_HCI_Initialize (ARM_USBH_HCI_Interrupt_t *cb_interrupt) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_USBH_HCI_Initialize (ARM_USBH_HCI_Interrupt_t *cb_interrupt)
-\details
-The function \b ARM_USBH_HCI_Initialize initializes the USB Host HCI (OHCI/EHCI) interface.
-It is called when the middleware component starts operation.
-
-The function performs the following operations:
- - Initializes the resources needed for the USBH interface.
- - Registers the \ref ARM_USBH_HCI_Interrupt interrupt handler.
-
-The parameter \em cb_interrupt is a pointer to the interrupt routine of the OHCI/EHCI peripheral
-that needs to be registered. This function is called as ECHI Interrupt Service Handler.
-
-\b Example:
- - see \ref usbh_interface_gr - Driver Functions
-
-*****************************************************************************************************************/
-
-int32_t ARM_USBH_HCI_Uninitialize (void) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_USBH_HCI_Uninitialize (void)
-\details
-The function \ref ARM_USBH_HCI_Uninitialize de-initializes the resources of USB Host HCI (OHCI/EHCI) interface.
-
-It is called when the middleware component stops operation and releases the software resources used by the interface.
-*****************************************************************************************************************/
-
-int32_t ARM_USBH_HCI_PowerControl (ARM_POWER_STATE state) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_USBH_HCI_PowerControl (ARM_POWER_STATE state)
-\details
-The function \b ARM_USBH_HCI_PowerControl operates the power modes of the USB Host HCI (OHCI/EHCI) interface.
-
-The parameter \em state sets the operation and can have the following values:
- - \ref ARM_POWER_FULL : set-up peripheral for data transfers, enable interrupts (NVIC) and optionally DMA.
- Can be called multiple times. If the peripheral is already in this mode the function performs
- no operation and returns with \ref ARM_DRIVER_OK.
- - \ref ARM_POWER_LOW : may use power saving. Returns \ref ARM_DRIVER_ERROR_UNSUPPORTED when not implemented.
- - \ref ARM_POWER_OFF : terminates any pending data transfers, disables peripheral, disables related interrupts and DMA.
-
-Refer to \ref CallSequence for more information.
-*****************************************************************************************************************/
-
-int32_t ARM_USBH_HCI_PortVbusOnOff (uint8_t port, bool vbus) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_USBH_HCI_PortVbusOnOff (uint8_t port, bool vbus)
-\details
-The function \b ARM_USBH_HCI_PortVbusOnOff controls the VBUS signal of the specified port.
-Most HCI complained USB Host controllers do not require this optional function.
-It is only required when a external VBUS interface (for example via I/O pin) is required.
-
-*****************************************************************************************************************/
-
-void ARM_USBH_HCI_Interrupt (void) {
- // function body
-}
-/**
-\fn void ARM_USBH_HCI_Interrupt (void)
-\details
-The function \b ARM_USBH_HCI_Interrupt is called from the USBH HCI Interrupt Handler.
-*****************************************************************************************************************/
-
-/**
-@}
-*/
-// End USBH Interface
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/Driver_WiFi.c b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/Driver_WiFi.c
deleted file mode 100644
index 3cd152e..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/Driver_WiFi.c
+++ /dev/null
@@ -1,1707 +0,0 @@
-/**
-\defgroup wifi_interface_gr WiFi Interface
-\brief Driver API for WiFi (%Driver_WiFi.h)
-\details
-
-Wi-Fi is technology for radio wireless local area networking of devices. Wi-Fi compatible devices typically
-connect to the Internet via a WLAN and a wireless access point (AP) also called hotspot.
-
-Wikipedia offers more information about
-the WiFi Driver Block Diagram
-
-\image html WiFi.png "Block Diagram of the WiFi interface"
-
-WiFi API
-
-The following header files define the Application Programming Interface (API) for the WiFi interface:
- - \b %Driver_WiFi.h : Driver API for WiFi
-
-The CMSIS-Driver WiFi provides access to the following interfaces:
-
- - \ref wifi_control_gr "Control interface": setup and control the WiFi module.
- - \ref wifi_management_gr "Management interface": allows you to configure and manage the connection
- to the WiFi access point (AP) or configure and manage the access point (AP).
- - \ref wifi_socket_gr "Socket interface": provides the interface to an IP stack that is running
- on the WiFi module. This IP stack handles data communication.
- - \ref wifi_bypass_gr "Bypass interface": is an optional interface and enables the transmission of
- Ethernet frames with the WiFi module. Using this interface requires the IP stack running on the microcontroller.
-
-The WiFi interface usually requires CMSIS-RTOS features (i.e. mutex) and is often implemented
-with a peripheral device that is connected to the system using the SPI or UART interface. However,
-there are also some microcontroller devices with WiFi interface on the chip.
-
-The implementation of the WiFi CMSIS-Driver is therefore generally provided as a separate software pack.
-It is often implemented as wrapper to the SDK (Software Development Kit) of the WiFi chipset.
-
-
-Driver Functions
-
-The driver functions are published in the access struct as explained in \ref DriverFunctions
- - \ref ARM_DRIVER_WIFI : access struct for WiFi driver functions
-
-
-Example Code
-
-@{
-*/
-
-/**
-\struct ARM_DRIVER_WIFI
-\details
-The functions of the WiFi driver are accessed by function pointers exposed by this structure.
-Refer to \ref DriverFunctions for overview information.
-
-Each instance of a WiFi interface provides such an access structure.
-The instance is identified by a postfix number in the symbol name of the access structure, for example:
- - \b Driver_WiFi0 is the name of the access struct of the first instance (no. \token{0}).
- - \b Driver_WiFi1 is the name of the access struct of the second instance (no. \token{1}).
-
-A middleware configuration setting allows connecting the middleware to a specific driver instance \b %Driver_WiFin .
-The default is \token{0}, which connects a middleware to the first instance of a driver.
-*******************************************************************************************************************/
-
-
-/**
-\defgroup wifi_control_gr WiFi Control
-\ingroup wifi_interface_gr
-\brief Control functions for the WiFi module
-\details
-The \ref wifi_control_gr functions setup and control the WiFi module.
-@{
-*/
-
-/**
-\struct ARM_WIFI_CAPABILITIES
-\details
-A WiFi driver can be implemented with different capabilities.
-The data fields of this structure encode the capabilities implemented by this driver.
-
-Returned by:
- - \ref ARM_WIFI_GetCapabilities
-*******************************************************************************************************************/
-
-/**
-\typedef ARM_WIFI_SignalEvent_t
-\details
-Provides the typedef for the callback function \ref ARM_WIFI_SignalEvent.
-
-Parameter for:
- - \ref ARM_WIFI_Initialize
-*******************************************************************************************************************/
-
-/**
-\defgroup wifi_event WiFi Events
-\ingroup wifi_control_gr
-\brief The WiFi driver generates call back events that are notified via the function \ref ARM_WIFI_SignalEvent.
-\details The following call back notification events are generated:
-@{
-\def ARM_WIFI_EVENT_AP_CONNECT
-\def ARM_WIFI_EVENT_AP_DISCONNECT
-\def ARM_WIFI_EVENT_ETH_RX_FRAME
-@}
-*/
-
-ARM_DRIVER_VERSION ARM_WIFI_GetVersion (void) {
- return { 0, 0 };
-}
-/**
-\fn ARM_DRIVER_VERSION ARM_WIFI_GetVersion (void)
-\details
-The function \b ARM_WIFI_GetVersion returns version information of the driver implementation in \ref ARM_DRIVER_VERSION.
-
-API version is the version of the CMSIS-Driver specification used to implement this driver.
-Driver version is source code version of the actual driver implementation.
-
-\b Example:
-\code
-extern ARM_DRIVER_WIFI Driver_WiFi0;
-static ARM_DRIVER_WIFI *wifi;
-
-void get_wifi_version (void) {
- ARM_DRIVER_VERSION version;
-
- wifi= &Driver_WiFi0;
- version = wifi->GetVersion ();
- if (version.api < 0x100U) { // requires at minimum API version 1.0 or higher
- // error handling
- return;
- }
-}
-\endcode
-*/
-
-ARM_WIFI_CAPABILITIES ARM_WIFI_GetCapabilities (void) {
- return { 0 };
-}
-/**
-\fn ARM_WIFI_CAPABILITIES ARM_WIFI_GetCapabilities (void)
-\details
-The function \b ARM_WIFI_GetCapabilities retrieves information about capabilities in this driver implementation.
-The data fields of the struct \ref ARM_WIFI_CAPABILITIES encode various capabilities, for example
-if a WiFi module supports the Access Point mode or the bypass mode, or is capable to signal events using
-the \ref ARM_WIFI_SignalEvent callback function.
-
-\b Example:
-\code
-extern ARM_DRIVER_WIFI Driver_WiFi0;
-static ARM_DRIVER_WIFI *wifi;
-
-void get_wifi_capabilities (void) {
- ARM_WIFI_CAPABILITIES capabilities;
-
- wifi = &Driver_WiFi0;
- capabilities = wifi->GetCapabilities ();
- // interrogate capabilities
- :
-}
-\endcode
-*/
-
-int32_t ARM_WIFI_Initialize (ARM_WIFI_SignalEvent_t cb_event) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_WIFI_Initialize (ARM_WIFI_SignalEvent_t cb_event)
-\details
-The function \b ARM_WIFI_Initialize initializes the WiFi module.
-
-It is called when the middleware component starts operation.
-
-The \ref ARM_WIFI_Initialize function performs the following operations:
- - Initializes the resources and peripherals required for the WiFi module.
- - Registers the \ref ARM_WIFI_SignalEvent callback function.
-
-The parameter \em cb_event is a pointer to the \ref ARM_WIFI_SignalEvent callback function;
-use a \token{NULL} pointer when no callback signals are required.
-
-\b Example:
-\code
-extern ARM_DRIVER_WIFI Driver_WiFi0;
-static ARM_DRIVER_WIFI *wifi;
-static ARM_ETH_MAC_ADDR own_mac_address;
-
-void initialize_wifi (void) {
- wifi = &Driver_WiFi0;
-
- // Initialize and Power-on WiFi Module
- wifi->Initialize (NULL);
- wifi->PowerControl (ARM_POWER_FULL);
-
- // Populate own_mac_address with the address to use
- wifi->SetOption(ARM_WIFI_MAC, &own_mac_address, 6U);
-}
-\endcode
-*/
-
-int32_t ARM_WIFI_Uninitialize (void) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_WIFI_Uninitialize (void)
-\details
-The function \b ARM_WIFI_Uninitialize de-initializes the resources of the WiFi module.
-
-It is called when the middleware component stops operation and releases the software resources
-used by the module.
-
-\b Example:
-\code
-extern ARM_DRIVER_WIFI Driver_WiFi0;
-static ARM_DRIVER_WIFI *wifi;
-
-void uninitialize_wifi (void) {
- wifi = &Driver_WiFi0;
-
- // Power off and De-initialize WiFi Module
- wifi->PowerControl (ARM_POWER_OFF);
- wifi->Uninitialize ();
-}
-\endcode
-*/
-
-int32_t ARM_WIFI_PowerControl (ARM_POWER_STATE state) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_WIFI_PowerControl (ARM_POWER_STATE state)
-\details
-The function \b ARM_WIFI_PowerControl allows you to configure the power modes of the WiFi module.
-
-The parameter \em state specifies the \ref ARM_POWER_STATE.
-
-Low-power mode depends on additional options set by \ref ARM_WIFI_SetOption :
- - Deep-sleep mode is entered when \ref ARM_WIFI_LP_TIMER option is set to a value different than 0
- - Sleep mode is entered otherwise
-
-\b Deep-sleep mode (only for station):
-Module turns off the radio and also internal CPU thus reducing power consumption to minimum,
-only the timer is running that wakes-up the module after specified time.
-When timer expires the module reconnects to the access point.
-
-This mode is used when power consumption is a priority (battery powered devices) and when WiFi
-is used in short intervals that do not occur very often
-(example: sending a temperature from a sensor to a cloud every 10 seconds).
-
-\b Sleep mode (only for station):
-Module reduces power consumption by going into sleep and waking up periodically to listen for beacons.
-
-Delivery Traffic Indication Message (DTIM) interval can be configured with option \ref ARM_WIFI_DTIM
-(station and access point) and beacon interval with option \ref ARM_WIFI_BEACON (only for access point).
-
-Default module intervals are used when those options are not explicitly set.
-
-If power \em state specifies an unsupported mode, the function returns \ref ARM_DRIVER_ERROR_UNSUPPORTED as
-status information and the previous power state of the peripheral is unchanged. Multiple calls with the same
-\em state generate no error.
-
-\b Example:
- - see \ref ARM_WIFI_Initialize
- - see \ref ARM_WIFI_Uninitialize
-*/
-
-int32_t ARM_WIFI_GetModuleInfo (char *module_info, uint32_t max_len) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_WIFI_GetModuleInfo (char *module_info, uint32_t max_len)
-\details
-The function \b ARM_WIFI_GetModuleInfo retrieves string containing information about the WiFi module.
-
-The information might include module name, firmware version, ...
-
-\note Module must be initialized and powered before module information can be retrieved.
-
-\b Example:
-\code
-extern ARM_DRIVER_WIFI Driver_WiFi0;
-static ARM_DRIVER_WIFI *wifi;
-
-void initialize_wifi (void) {
- char info[32];
-
- wifi = &Driver_WiFi0;
-
- // Initialize and Power-on WiFi Module
- wifi->Initialize (NULL);
- wifi->PowerControl (ARM_POWER_FULL);
-
- // Retrieve module information
- wifi->GetModuleInfo(&info, sizeof(info));
-}
-\endcode
-*/
-
-void ARM_WIFI_SignalEvent (uint32_t event, void *arg) {
-}
-/**
-\fn void ARM_WIFI_SignalEvent (uint32_t event, void *arg)
-\details
-The function \b ARM_WIFI_SignalEvent is a callback function registered by the function \ref ARM_WIFI_Initialize.
-It is called by the WiFi driver to notify the application about WiFi Events occurred during operation.
-
-The parameter \em event indicates the event that occurred during driver operation.
-
-The parameter \em arg provides additional information about the event.
-
-The following events can be generated:
-
-Parameter \em event | Description
-:------------------------------------|:------------------------------------------
-\ref ARM_WIFI_EVENT_AP_CONNECT | Occurs in access point mode when a station has connected to the access point.
-\ref ARM_WIFI_EVENT_AP_DISCONNECT | Occurs in access point mode when a station has disconnected from the access point.
-\ref ARM_WIFI_EVENT_ETH_RX_FRAME | Occurs in \ref wifi_bypass_gr when an ethernet frame is received.
-*/
-
-/**
-@}
-*/
-// end group wifi_control_gr
-
-
-/**
-\defgroup wifi_management_gr WiFi Management
-\ingroup wifi_interface_gr
-\brief Configure and manage the connection to a WiFi access point (AP) or configure and manage the access point (AP).
-\details The \ref wifi_management_gr functions are used to configure and manage the connection to a WiFi access point (AP)
-also called hotspot when in station mode. They are also used to configure and manage the access point (AP) itself
-when in access point mode.
-@{
-*/
-
-/**
-\defgroup WiFi_option WiFi Option Codes
-\ingroup wifi_management_gr
-\brief WiFi Option Codes for \ref ARM_WIFI_SetOption or \ref ARM_WIFI_GetOption function.
-\details
-Many parameters of the WiFi module are configured using the \ref ARM_WIFI_SetOption or \ref ARM_WIFI_GetOption function.
-@{
-\def ARM_WIFI_BSSID
-\details Specifies the BSSID of the access point to connect or the access point itself.
-\sa WiFi_option
-\def ARM_WIFI_TX_POWER
-\details Specifies the transmit power in dBm.
-\sa WiFi_option
-\def ARM_WIFI_LP_TIMER
-\details Specifies the low-power deep-sleep time in seconds for station (disabled when 0 - default).
-\sa WiFi_option
-\def ARM_WIFI_DTIM
-\details Specifies the DTIM interval in number of beacons.
-\sa WiFi_option
-\def ARM_WIFI_BEACON
-\details Specifies the beacon interval in milliseconds for access point.
-\sa WiFi_option
-\def ARM_WIFI_MAC
-\details Specifies the MAC address.
-\sa WiFi_option
-\def ARM_WIFI_IP
-\details Specifies the IP address.
-\sa WiFi_option
-\def ARM_WIFI_IP_SUBNET_MASK
-\details Specifies the subnet mask.
-\sa WiFi_option
-\def ARM_WIFI_IP_GATEWAY
-\details Specifies the gateway IP address.
-\sa WiFi_option
-\def ARM_WIFI_IP_DNS1
-\details Specifies the IP address of the primary DNS server.
-\sa WiFi_option
-\def ARM_WIFI_IP_DNS2
-\details Specifies the IP address of the secondary DNS server.
-\sa WiFi_option
-\def ARM_WIFI_IP_DHCP
-\details Enables or disables the DHCP client for station or DHCP server for access point.
-\sa WiFi_option
-\def ARM_WIFI_IP_DHCP_POOL_BEGIN
-\details Specifies the start IP address for DHCP server (access point).
-\sa WiFi_option
-\def ARM_WIFI_IP_DHCP_POOL_END
-\details Specifies the end IP address for DHCP server (access point).
-\sa WiFi_option
-\def ARM_WIFI_IP_DHCP_LEASE_TIME
-\details Specifies the lease time for DHCP server (access point).
-\sa WiFi_option
-\def ARM_WIFI_IP6_GLOBAL
-\details Specifies the global IPv6 address.
-\sa WiFi_option
-\def ARM_WIFI_IP6_LINK_LOCAL
-\details Specifies the link-local IPv6 address.
-\sa WiFi_option
-\def ARM_WIFI_IP6_SUBNET_PREFIX_LEN
-\details Specifies the address prefix length.
-\sa WiFi_option
-\def ARM_WIFI_IP6_GATEWAY
-\details Specifies the gateway IPv6 address.
-\sa WiFi_option
-\def ARM_WIFI_IP6_DNS1
-\details Specifies the IPv6 address of the primary DNS server.
-\sa WiFi_option
-\def ARM_WIFI_IP6_DNS2
-\details Specifies the IPv6 address of the secondary DNS server.
-\sa WiFi_option
-\def ARM_WIFI_IP6_DHCP_MODE
-\details Specifies the operation mode of the DHCPv6 client.
-\sa WiFi_option
-@}
-*/
-
-/**
-\defgroup wifi_sec_type WiFi Security Type
-\ingroup wifi_management_gr
-\brief Specifies WiFi security type for \ref ARM_WIFI_Activate.
-\details
-The WiFi security type defines the standard used to protect the wireless network from unauthorized access.
-@{
-\def ARM_WIFI_SECURITY_OPEN
-\details This is an open system which provides \b no security.
-\sa wifi_sec_type
-\def ARM_WIFI_SECURITY_WEP
-\details This security standard provides \b weak level of security.
-\sa wifi_sec_type
-\def ARM_WIFI_SECURITY_WPA
-\details This security standard provides \b medium level of security.
-\sa wifi_sec_type
-\def ARM_WIFI_SECURITY_WPA2
-\details This security standard provides \b strong level of security.
-\sa wifi_sec_type
-\def ARM_WIFI_SECURITY_UNKNOWN
-\details Unknown security standard (reported by \ref ARM_WIFI_Scan).
-\sa wifi_sec_type
-@}
-*/
-
-/**
-\defgroup wifi_wps_method WiFi Protected Setup (WPS) Method
-\ingroup wifi_management_gr
-\brief Specifies WiFi WPS method for \ref ARM_WIFI_Activate.
-\details
-The WiFi WPS method defines which WPS method is used.
-@{
-\def ARM_WIFI_WPS_METHOD_NONE
-\details WPS not used.
-\sa wifi_wps_method
-\def ARM_WIFI_WPS_METHOD_PBC
-\details WPS with Push Button Configuration.
-\sa wifi_wps_method
-\def ARM_WIFI_WPS_METHOD_PIN
-\details WPS with PIN.
-\sa wifi_wps_method
-@}
-*/
-
-/**
-\defgroup wifi_dhcp_v6_mode WiFi DHCPv6 Mode
-\ingroup wifi_management_gr
-\brief Specifies IPv6 Dynamic Host Configuration Protocol (DHCP) Mode.
-\details
-The WiFi DHCPv6 mode defines the DHCP mode in IPv6.
-@{
-\def ARM_WIFI_IP6_DHCP_OFF
-\details
-In the static host configuration mode, the IPv6 address, the default gateway address,
-and the addresses of DNS servers are statically configured from the preset values.
-\sa wifi_dhcp_v6_mode
-\def ARM_WIFI_IP6_DHCP_STATELESS
-\details
-In the stateless DHCP configuration mode, the client obtains only extended information
-from a DHCPv6 server, such as DNS server addresses. Stateless auto-configuration of
-IPv6 allows the client device to self configure it's IPv6 addresses and routing based
-on the router advertisements.
-\sa wifi_dhcp_v6_mode
-\def ARM_WIFI_IP6_DHCP_STATEFULL
-\details
-In the stateful DHCP configuration mode, the client connects to a DHCPv6 server for
-a leased IPv6 address and DNS server addresses.
-\sa wifi_dhcp_v6_mode
-@}
-*/
-
-/**
-\struct ARM_WIFI_CONFIG_t
-\details
-Provides information needed to connect to the WiFi network for station or how to configure the access point (AP).
-
-Used in:
- - \ref ARM_WIFI_Activate
-*******************************************************************************************************************/
-
-/**
-\struct ARM_WIFI_SCAN_INFO_t
-\details
-Provides information about the wireless networks that were detected when searching for available WiFi networks. The structure
-contains the information needed to connect to the WiFi network. Of course, the access password is not included and must
-be provided separately.
-
-Used in:
- - \ref ARM_WIFI_Scan
-*******************************************************************************************************************/
-
-/**
-\struct ARM_WIFI_NET_INFO_t
-\details
-Provides information about the network that the station is connected to.
-
-Used in:
- - \ref ARM_WIFI_GetNetInfo
-*******************************************************************************************************************/
-
-int32_t ARM_WIFI_SetOption (uint32_t interface, uint32_t option, const void *data, uint32_t len) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_WIFI_SetOption (uint32_t interface, uint32_t option, const void *data, uint32_t len)
-\details
-The function \b ARM_WIFI_SetOption sets the value of the specified option of the WiFi module.
-
-The argument \em interface specifies the interface (0 = Station, 1 = Access Point).
-
-The argument \em option specifies the option that is to be set (see below).
-
-The argument \em data points to a buffer containing the value of the option to be set
-and must be aligned to the data type of the corresponding option.
-
-The argument \em len specifies the length of the buffer \em data and must be equal (or higher)
-to the length of the corresponding option.
-
-Option | Description | Data | Type/Length
-:--------------------------------------|:---------------------------------------|:--------------|:-----------
-\ref ARM_WIFI_BSSID | BSSID of AP to connect or AP | bssid | uint8_t[6]
-\ref ARM_WIFI_TX_POWER | Transmit power | power[dbm] | uint32_t
-\ref ARM_WIFI_LP_TIMER | Low-power deep-sleep time | time[seconds] | uint32_t
-\ref ARM_WIFI_DTIM | DTIM interval | dtim[beacons] | uint32_t
-\ref ARM_WIFI_BEACON | Beacon interval | interval[ms] | uint32_t
-\ref ARM_WIFI_MAC | MAC address | mac | uint8_t[6]
-\ref ARM_WIFI_IP | IPv4 address | ip | uint8_t[4]
-\ref ARM_WIFI_IP_SUBNET_MASK | IPv4 subnet mask | mask | uint8_t[4]
-\ref ARM_WIFI_IP_GATEWAY | IPv4 gateway address | ip | uint8_t[4]
-\ref ARM_WIFI_IP_DNS1 | IPv4 primary DNS server address | ip | uint8_t[4]
-\ref ARM_WIFI_IP_DNS2 | IPv4 secondary DNS server address | ip | uint8_t[4]
-\ref ARM_WIFI_IP_DHCP | IPv4 DHCP client/server enable/disable | dhcp (0, 1) | uint32_t
-\ref ARM_WIFI_IP_DHCP_POOL_BEGIN | IPv4 DHCP server begin address | ip | uint8_t[4]
-\ref ARM_WIFI_IP_DHCP_POOL_END | IPv4 DHCP server end address | ip | uint8_t[4]
-\ref ARM_WIFI_IP_DHCP_LEASE_TIME | IPv4 DHCP server lease time | time[seconds] | uint32_t
-\ref ARM_WIFI_IP6_GLOBAL | IPv6 global address | ip6 | uint8_t[16]
-\ref ARM_WIFI_IP6_LINK_LOCAL | IPv6 link-local address | ip6 | uint8_t[16]
-\ref ARM_WIFI_IP6_SUBNET_PREFIX_LEN | IPv6 subnet prefix length | len (1..127) | uint32_t
-\ref ARM_WIFI_IP6_GATEWAY | IPv6 gateway address | ip6 | uint8_t[16]
-\ref ARM_WIFI_IP6_DNS1 | IPv6 primary DNS server address | ip6 | uint8_t[16]
-\ref ARM_WIFI_IP6_DNS2 | IPv6 secondary DNS server address | ip6 | uint8_t[16]
-\ref ARM_WIFI_IP6_DHCP_MODE | IPv6 DHCP client mode | mode | uint32_t
-
-\b Example:
-\code
-uint8_t ip[4];
-
-ip[0] = 192U;
-ip[1] = 168U;
-ip[2] = 0U;
-ip[3] = 1U;
-
-// Set IP static address of the Station
-wifi->SetOption (0U, ARM_WIFI_IP, &ip, sizeof(ip));
-\endcode
-*/
-
-int32_t ARM_WIFI_GetOption (uint32_t interface, uint32_t option, void *data, uint32_t *len) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_WIFI_GetOption (uint32_t interface, uint32_t option, void *data, uint32_t *len)
-\details
-The function \b ARM_WIFI_GetOption retrieves the current value of the specified option of
-the WiFi module.
-
-The argument \em interface specifies the interface (0 = Station, 1 = Access Point).
-
-The argument \em option specifies the option that is to be retrieved (see \ref ARM_WIFI_SetOption).
-
-The argument \em data points to a buffer that will be used to store the value of
-the \em option and must be aligned to the data type of the corresponding option.
-
-The argument \em len is a pointer to the length of the buffer at input and returns the length
-of the option information on the output.
-
-\b Example:
-\code
-uint8_t ip[4]; // IP address
-uint8_t mask[4]; // Subnet mask
-uint8_t gateway[4]; // Gateway address
-
-// Get IP address, Subnet mask and Gateway address of the Station
-wifi->GetOption (0U, ARM_WIFI_IP, &ip, sizeof(ip));
-wifi->GetOption (0U, ARM_WIFI_IP_SUBNET_MASK, &mask, sizeof(mask));
-wifi->GetOption (0U, ARM_WIFI_IP_GATEWAY, &gateway, sizeof(gateway));
-\endcode
-*/
-
-int32_t ARM_WIFI_Scan (ARM_WIFI_SCAN_INFO_t scan_info[], uint32_t max_num) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_WIFI_Scan (ARM_WIFI_SCAN_INFO_t scan_info[], uint32_t max_num)
-\details
-The function \b ARM_WIFI_Scan searches for available WiFi networks. Using this function,
-you can determine which wireless networks are available for the connection. If the network is
-secured, you must also know the password to connect.
-
-The argument \em scan_info is a pointer to an array of network information structures, where
-the available network information will be returned.
-
-The argument \em max_num specifies maximum number of network information structures,
-that can be stored to the \em scan_info.
-
-\b Example:
-\code
-ARM_WIFI_SCAN_INFO_t scan_info[8];
-
-num = wifi->Scan (scan_info, 8U);
-
-// Print SSIDs of available WiFi networks
-for (i = 0; i < num; i++) {
- printf ("%d. ssid=%s\n", i, scan_info[i].ssid);
-}
-\endcode
-*/
-
-int32_t ARM_WIFI_Activate (uint32_t interface, const ARM_WIFI_CONFIG_t *config) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_WIFI_Activate (uint32_t interface, const ARM_WIFI_CONFIG_t *config)
-\details
-The function \b ARM_WIFI_Activate activates the specified interface.
-
-The argument \em interface specifies the interface (0 = Station, 1 = Access Point).
-
-When station interface is specified, the WiFi module connects to a wireless network.
-
-The wireless network trying to connect to must be available,
-otherwise the operation will fail after a timeout.
-
-Available wireless networks can be scanned by using the function \ref ARM_WIFI_Scan.
-
-When access point interface is specified, the WiFi module creates a wireless network
-by activating the access point.
-
-The argument \em config is a pointer to the configuration \ref ARM_WIFI_CONFIG_t
-which provides information needed to connect to a WiFi network for station interface
-or information used to configure the access point (AP) for access point interface.
-
-\em ssid specifies the name of the network to connect to or the network to create.
-
-\em pass specifies the password for accessing the wireless network.
-
-\em security specifies the security type which will be used for the connection.
-
-\em ch specifies the WiFi channel which will be used for the connection.
-Valid channels for 2.4 GHz frequency are from \token{1} to \token{13}. If the value for \em ch = \token{0},
-the system automatically selects the channel.
-For station interface the channel of the AP being connected to is used.
-For access point interface the module automatically selects the best channel for the WiFi connection.
-
-\note
-Optionally BSSID parameter can be also set using \ref ARM_WIFI_SetOption.
-It allows connection to specific BSSID when connecting to an access point or specifies
-the BSSID of the access point.
-
-\em wps_method specifies if WiFi Protected Setup (WPS) is used and which method.
-
-\em wps_pin specifies the PIN used with WPS (\ref ARM_WIFI_WPS_METHOD_PIN).
-
-With the \b push-button method, you typically press the button, either real or virtual,
-both at the access point and the station. No credentials are needed.
-
-With \b PIN method, you must provide the PIN code that you read from the label or screen
-on the wireless device.
-
-WPS configuration for station is used when station connects to an access point.
-It enables to connect without specifying SSID, Password, Security Type or WiFi Channel.
-The actual network information can be retrieved once connected with \ref ARM_WIFI_GetNetInfo.
-
-WPS configuration for access point is used when access point is activated.
-Subsequent activate calls re-trigger the WPS procedure.
-
-\note
-WPS is typically activated by pressing the WPS button at the access point.
-During the discovery mode (usually 2 minutes or less) any wireless device may connect
-to the access point (PIN needs to match when PIN method is selected).
-
-\b Example:
-\code
-ARM_WIFI_CONFIG_t wifi_config;
-
-wifi_config.ssid = "GuestAccess";
-wifi_config.pass = "guest";
-wifi_config.security = ARM_WIFI_SECURITY_WPA2;
-wifi_config.ch = 0U;
-wifi_config.wps_method = ARM_WIFI_WPS_METHOD_NONE;
-
-// Connect to wireless network
-status = wifi->Activate (0U, &wifi_config);
-if (status != ARM_DRIVER_OK) {
- // error handling
-}
-\endcode
-*/
-
-int32_t ARM_WIFI_Deactivate (uint32_t interface) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_WIFI_Deactivate (uint32_t interface)
-\details
-The function \b ARM_WIFI_Deactivate deactivates the specified interface.
-
-The argument \em interface specifies the interface (0 = Station, 1 = Access Point).
-
-When station interface is specified, the WiFi module disconnects from the wireless network.
-
-When access point interface is specified, the WiFi module deactivates the access point.
-
-\b Example:
- - see \ref ARM_WIFI_GetNetInfo
-*/
-
-uint32_t ARM_WIFI_IsConnected (void) {
- return 0;
-}
-/**
-\fn uint32_t ARM_WIFI_IsConnected (void)
-\details
-The function \b ARM_WIFI_IsConnected checks if the station is connected to a wireless network
-and returns the connection status.
-
-The function returns a \token{non-zero} value, if the station is connected. If the station
-is not connected, the function returns \token{0}.
-
-\b Example:
- - see \ref ARM_WIFI_GetNetInfo
-*/
-
-int32_t ARM_WIFI_GetNetInfo (ARM_WIFI_NET_INFO_t *net_info) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_WIFI_GetNetInfo (ARM_WIFI_NET_INFO_t *net_info)
-\details
-The function \b ARM_WIFI_GetNetInfo retrieves wireless network information of a connected station.
-
-It can be used to retrieve network connection information for subsequent connections
-after initially connecting using WPS.
-
-\b Example:
-\code
-ARM_WIFI_CONFIG_t wifi_config;
-ARM_WIFI_NET_INFO_t net_info;
-
-memset(&wifi_config, 0, sizeof(wifi_config));
-
-wifi_config.wps_method = ARM_WIFI_WPS_METHOD_PBC;
-
-// Connect to wireless network (WPS)
-status = wifi->Activate (0U, &wifi_config);
-if (status != ARM_DRIVER_OK) {
- // error handling
-}
-
-// Retrieve network information
-if (wifi->IsConnected ()) {
- status = wifi->GetNetInfo (&net_info);
- if (status != ARM_DRIVER_OK) {
- // error handling
- }
- printf("SSID=%s, Password=%s",net_info.ssid, net_info.pass);
-}
-
-// Disconnect from wireless network
-wifi->Deactivate (0U);
-\endcode
-*/
-
-/**
-@}
-*/
-// end group wifi_management_gr
-
-
-/**
-\defgroup wifi_bypass_gr WiFi Bypass Mode
-\ingroup wifi_interface_gr
-\brief Transfer Ethernet frames by WiFi module.
-\details The \ref wifi_bypass_gr functions are an optional interface and enable the transmission of
-Ethernet frames with WiFi modules. The use of this interface requires that the TCP/IP stack is running
-on the microcontroller (usually a third-party or open-source networking component). The internal TCP/IP
-stack of the WiFi module is therefore not used, and this usually means that the \ref wifi_socket_gr
-functions can not be used.
-@{
-*/
-
-int32_t ARM_WIFI_BypassControl (uint32_t interface, uint32_t mode) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_WIFI_BypassControl (uint32_t interface, uint32_t mode)
-\details
-The function \b ARM_WIFI_BypassControl enables or disables the WiFi bypass mode.
-
-The WiFi Bypass mode can only be enabled, if there is a bypass mode supported in the WiFi driver.
-You can check this by checking the driver's capabilities.
-
-\note
-Bypass mode is enabled by default if the module does not support the Socket interface.
-
-The argument \em mode specifies the desired state of the WiFi Bypass mode, which is
-enabled or disabled.
-
-\b Example:
-\code
-extern ARM_DRIVER_WIFI Driver_WiFi0;
-static ARM_DRIVER_WIFI *wifi;
-static ARM_ETH_MAC_ADDR own_mac_address;
-
-static void wifi_notify (uint32_t event, ,void *arg) {
- switch (event) {
- :
- }
-}
-
-void initialize_wifi_bypass (void) {
- ARM_WIFI_CAPABILITIES capabilities;
-
- wifi = &Driver_WiFi0;
- capabilities = wifi->GetCapabilities ();
- if (capabilities.bypass_mode == 0) {
- // error handling
- }
-
- // Initialize and Power-on WiFi Interface
- wifi->Initialize ((capabilities.eth_rx_frame_event) ? wifi_notify : NULL);
- wifi->PowerControl (ARM_POWER_FULL);
-
- // populate own_mac_address with the address to use for station
- wifi->SetOption(0U, ARM_WIFI_MAC, &own_mac_address, 6U);
-
- wifi->BypassControl (0U, 1U); // Enable bypass mode for station
-}
-\endcode
-*/
-
-int32_t ARM_WIFI_EthSendFrame (uint32_t interface, const uint8_t *frame, uint32_t len) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_WIFI_EthSendFrame (uint32_t interface, const uint8_t *frame, uint32_t len)
-\details
-The function \b ARM_WIFI_EthSendFrame writes an Ethernet frame to the WiFi transmit buffer.
-
-The WiFi bypass mode must be enabled by using the function \ref ARM_WIFI_BypassControl
-before a call to this function.
-
-The frame data addressed by \em frame starts with MAC destination and ends with the last
-Payload data byte. The frame data is copied into the transmit buffer of the WiFi interface.
-
-The maximum value for \em len is implied by the size restrictions of the Ethernet frame
-but is not verified. Using an invalid value for \em len may generate unpredicted results.
-
-\b Example:
-\code
-status = wifi->EthSendFrame (0U, &frame_data[0], frame_length);
-if (status != ARM_DRIVER_OK) {
- // error handling
-}
-\endcode
-*/
-
-int32_t ARM_WIFI_EthReadFrame (uint32_t interface, uint8_t *frame, uint32_t len) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_WIFI_EthReadFrame (uint32_t interface, uint8_t *frame, uint32_t len)
-\details
-The function \b ARM_WIFI_EthReadFrame reads an Ethernet frame from the WiFi interface
-in the bypass mode.
-
-The \em len of the Ethernet frame can be checked using the function \ref ARM_WIFI_EthGetRxFrameSize.
-
-The frame data addressed by \em frame starts with MAC destination and ends with the last
-Payload data byte. The frame data is read from the receive buffer of the WiFi interface and
-the number of bytes written into the memory addressed by \em frame is returned.
-A negative return value indicates an error whereby the status code is defined with
-driver common return codes.
-
-The function \ref ARM_WIFI_EthReadFrame may be called with \em buf = \token{NULL} and \em len = \token{0}
-to discard or release a frame. This is useful when an incorrect frame has been received or
-no memory is available to hold the Ethernet frame.
-
-\b Example:
-\code
-size = wifi->EthGetRxFrameSize ();
-if ((size < 14) || (size > 1514)) { // frame excludes CRC
- wifi->EthReadFrame (NULL, 0); // Frame error, release it
-}
-len = wifi->ReadFrame (0U, &frame_data[0], size);
-if (len < 0) {
- // error handling
-}
-\endcode
-*/
-
-uint32_t ARM_WIFI_EthGetRxFrameSize (uint32_t interface) {
- return 0;
-}
-/**
-\fn uint32_t ARM_WIFI_EthGetRxFrameSize (uint32_t interface)
-\details
-The function \b ARM_WIFI_EthGetRxFrameSize returns the size of a received Ethernet frame
-in the bypass mode. This function can be called before \ref ARM_WIFI_EthReadFrame and retrieves
-the value \em len.
-
-The frame size includes MAC destination and ends with the last Payload data byte.
-Value \token{0} indicates that no Ethernet frame is available in the receive buffer.
-Values smaller than minimum size of Ethernet frame or larger than maximum size of Ethernet frame
-indicate an invalid frame which needs to be discarded by calling \ref ARM_WIFI_EthReadFrame.
-
-\b Example:
- - see \ref ARM_WIFI_EthReadFrame
-*/
-/**
-@}
-*/
-// end group wifi_bypass_gr
-
-
-/**
-\defgroup wifi_socket_gr WiFi Socket
-\ingroup wifi_interface_gr
-\brief Socket interface to IP stack running on WiFi module
-\details The \ref wifi_socket_gr functions provide the interface to an IP stack that is running
-on the WiFi module. This IP stack handles data communication with the network and provides the user
-with a communication endpoint called sockets.
-@{
-*/
-
-/**
-\defgroup wifi_addr_family WiFi Socket Address Family definitions
-\ingroup wifi_socket_gr
-\brief WiFi Socket Address Family definitions.
-\details The WiFi Socket Address Family specifies the addressing scheme that an instance of the WiFi socket can use.
-@{
-\def ARM_SOCKET_AF_INET
-\details Internet Address Family version 4.
-\def ARM_SOCKET_AF_INET6
-\details Internet Address Family version 6.
-@}
-*/
-
-/**
-\defgroup wifi_socket_type WiFi Socket Type definitions
-\ingroup wifi_socket_gr
-\brief WiFi Socket Type definitions.
-\details The WiFi Socket Type specifies the type of the WiFi socket.
-@{
-\def ARM_SOCKET_SOCK_STREAM
-\details Stream Socket is connection-oriented, sequenced and reliable, implemented on top of the TCP protocol.
-\def ARM_SOCKET_SOCK_DGRAM
-\details Datagram Socket is connectionless, unreliable, using the UDP protocol.
-@}
-*/
-
-/**
-\defgroup wifi_protocol WiFi Socket Protocol definitions
-\ingroup WiFi_socket_gr
-\brief WiFi Socket Protocol definitions.
-\details The WiFi Socket Protocol specifies the Internet Protocol Type that the socket is using.
-@{
-\def ARM_SOCKET_IPPROTO_TCP
-\details Transmission Control Protocol.
-\def ARM_SOCKET_IPPROTO_UDP
-\details User Datagram Protocol.
-@}
-*/
-
-/**
-\defgroup wifi_soc_opt WiFi Socket Option definitions
-\ingroup WiFi_socket_gr
-\brief WiFi Socket Option definitions.
-\details The WiFi Socket Option specifies the socket option for which the value is to be set or obtained.
-@{
-\def ARM_SOCKET_IO_FIONBIO
-\details Enables or disables the non-blocking mode for the WiFi socket.
-\sa wifi_soc_opt
-\def ARM_SOCKET_SO_RCVTIMEO
-\details Specifies the time limit for receiving in blocking mode. The time limit is in milliseconds.
-\sa wifi_soc_opt
-\def ARM_SOCKET_SO_SNDTIMEO
-\details Specifies the time limit for sending in blocking mode. The time limit is in milliseconds.
-\sa wifi_soc_opt
-\def ARM_SOCKET_SO_KEEPALIVE
-\details Enables or disables the keep-alive mode for the stream socket.
-\sa wifi_soc_opt
-\def ARM_SOCKET_SO_TYPE
-\details Obtains the type of the Wifi socket.
-\sa wifi_soc_opt
-@}
-*/
-
-/**
-\defgroup wifi_soc_func WiFi Socket Function return codes
-\ingroup WiFi_socket_gr
-\brief WiFi Socket Function return codes.
-\details This section lists all the return errors the WiFi socket functions will return.
-The error codes are negative. This makes it easy to check an error when the return
-code is less than \token{0}.
-@{
-\def ARM_SOCKET_ERROR
-\sa wifi_soc_func
-\def ARM_SOCKET_ESOCK
-\sa wifi_soc_func
-\def ARM_SOCKET_EINVAL
-\sa wifi_soc_func
-\def ARM_SOCKET_ENOTSUP
-\sa wifi_soc_func
-\def ARM_SOCKET_ENOMEM
-\sa wifi_soc_func
-\def ARM_SOCKET_EAGAIN
-\sa wifi_soc_func
-\def ARM_SOCKET_EINPROGRESS
-\sa wifi_soc_func
-\def ARM_SOCKET_ETIMEDOUT
-\sa wifi_soc_func
-\def ARM_SOCKET_EISCONN
-\sa wifi_soc_func
-\def ARM_SOCKET_ENOTCONN
-\sa wifi_soc_func
-\def ARM_SOCKET_ECONNREFUSED
-\sa wifi_soc_func
-\def ARM_SOCKET_ECONNRESET
-\sa wifi_soc_func
-\def ARM_SOCKET_ECONNABORTED
-\sa wifi_soc_func
-\def ARM_SOCKET_EALREADY
-\sa wifi_soc_func
-\def ARM_SOCKET_EADDRINUSE
-\sa wifi_soc_func
-\def ARM_SOCKET_EHOSTNOTFOUND
-\sa wifi_soc_func
-@}
-*/
-
-int32_t ARM_WIFI_SocketCreate (int32_t af, int32_t type, int32_t protocol) {
- return 0;
-}
-/**
-\fn int32_t ARM_WIFI_SocketCreate (int32_t af, int32_t type, int32_t protocol)
-\details
-The function \b ARM_WIFI_SocketCreate creates a communication endpoint called a socket.
-
-The argument \em af specifies the address family. The following values are supported:
-Family | Description
-:----------------------------|:-------------------------------------------------
-\ref ARM_SOCKET_AF_INET | Address Family Internet
-\ref ARM_SOCKET_AF_INET6 | Address Family Internet version 6
-
-The argument \em type specifies the communication semantics. The following are the currently supported types:
-Type | Description
-:----------------------------|:-------------------------------------------------
-\ref ARM_SOCKET_SOCK_STREAM | Provides a reliable connection based data stream that is full-duplex
-\ref ARM_SOCKET_SOCK_DGRAM | Provides connectionless communication that is unreliable
-
-The argument \em protocol specifies the protocol that must be used with the socket type:
-Protocol | Description
-:----------------------------|:-------------------------------------------------
-\ref ARM_SOCKET_IPPROTO_TCP | Must be used with ARM_SOCKET_SOCK_STREAM socket type
-\ref ARM_SOCKET_IPPROTO_UDP | Must be used with ARM_SOCKET_SOCK_DGRAM socket type
-\token{0} | The system selects a matching protocol for the socket type
-
-\b Example:
- - see \ref ARM_WIFI_SocketListen, \ref ARM_WIFI_SocketConnect
-*/
-
-int32_t ARM_WIFI_SocketBind (int32_t socket, const uint8_t *ip, uint32_t ip_len, uint16_t port) {
- return 0;
-}
-/**
-\fn int32_t ARM_WIFI_SocketBind (int32_t socket, const uint8_t *ip, uint32_t ip_len, uint16_t port)
-\details
-The function \b ARM_WIFI_SocketBind assigns a name to an unnamed socket. The name represents the local address
-and port of the communication endpoint.
-
-The argument \em socket specifies a socket identification number returned from a previous call
-to \ref ARM_WIFI_SocketCreate.
-
-The argument \em ip is a pointer to the buffer containing the IP address octets of the local IP address.
-
-The argument \em ip_len specifies the length of the local IP address. The length is \token{4} bytes
-for the IPv4 address and \token{16} bytes for the IPv6 address.
-
-The argument \em port specifies the local port. If the argument \em port is \token{0}, the function returns error,
-because this port is reserved.
-
-\b Example:
- - see \ref ARM_WIFI_SocketListen
-*/
-
-int32_t ARM_WIFI_SocketListen (int32_t socket, int32_t backlog) {
- return 0;
-}
-/**
-\fn int32_t ARM_WIFI_SocketListen (int32_t socket, int32_t backlog)
-\details
-The function \b ARM_WIFI_SocketListen sets the specified socket to listening mode, that is to the
-server mode of operation. Before calling the \b ARM_WIFI_SocketListen function, the \ref ARM_WIFI_SocketBind
-function must be called.
-
-The argument \em socket specifies a socket identification number returned from a previous call
-to \ref ARM_WIFI_SocketCreate.
-
-The argument \em backlog specifies a maximum number of connection requests that can be queued.
-
-\b Example:
-\code
-extern ARM_DRIVER_WIFI Driver_WiFi0;
-static ARM_DRIVER_WIFI *wifi;
-
-void Echo_Server_Thread (void *arg) {
- uint8_t ip[4] = { 0U, 0U, 0U, 0U };
- int32_t sock, sd, res;
- char dbuf[120];
-
- while (1) {
- wifi = &Driver_WiFi0;
- sock = wifi->SocketCreate (ARM_SOCKET_AF_INET, ARM_SOCKET_SOCK_STREAM, ARM_SOCKET_IPPROTO_TCP);
-
- wifi->SocketBind (sock, (uint8_t *)ip, sizeof(ip), 7U);
- wifi->SocketListen (sock, 1);
- sd = wifi->SocketAccept (sock, NULL, NULL, NULL);
- wifi->SocketClose (sock);
- sock = sd;
-
- while (1) {
- res = wifi->SocketRecv (sock, dbuf, sizeof(dbuf));
- if (res < 0) {
- break; // Error occurred
- }
- if (res > 0) {
- wifi->SocketSend (sock, dbuf, res); // Echo the data
- }
- }
- wifi->SocketClose (sock);
- }
-}
-\endcode
-*/
-
-int32_t ARM_WIFI_SocketAccept (int32_t socket, uint8_t *ip, uint32_t *ip_len, uint16_t *port) {
- return 0;
-}
-/**
-\fn int32_t ARM_WIFI_SocketAccept (int32_t socket, uint8_t *ip, uint32_t *ip_len, uint16_t *port)
-\details
-The function \b ARM_WIFI_SocketAccept accepts a connection request queued for a listening socket.
-If a connection request is pending, \b ARM_WIFI_SocketAccept removes the request from the queue,
-and creates a new socket for the connection. The original listening socket remains open and continues
-to queue new connection requests. The \em socket must be a socket of type \b ARM_SOCKET_SOCK_STREAM.
-
-In blocking mode, which is enabled by default, this function waits for a connection request. In
-non blocking mode, you must call the \b ARM_WIFI_SocketAccept function again if the error code
-\c ARM_SOCKET_EAGAIN is returned.
-
-The argument \em socket specifies a socket identification number returned from a previous call
-to \ref ARM_WIFI_SocketCreate.
-
-The argument \em ip is a pointer to the buffer that will receive the IP address of the connection node.
-If the \em ip is \token{NULL}, the IP address is not returned.
-
-The argument \em ip_len is a pointer to the IP address length. It should initially contain the amount of
-space pointed to by \em ip. On return it contains the actual length of the address returned in bytes.
-
-The argument \em port is a pointer to the buffer, that will receive the port number of the connection node.
-If the \em port is \token{NULL}, the port number is not returned.
-
-\b Example:
- - see \ref ARM_WIFI_SocketListen
-*/
-
-int32_t ARM_WIFI_SocketConnect (int32_t socket, const uint8_t *ip, uint32_t ip_len, uint16_t port) {
- return 0;
-}
-/**
-\fn int32_t ARM_WIFI_SocketConnect (int32_t socket, const uint8_t *ip, uint32_t ip_len, uint16_t port)
-\details
-The function \b ARM_WIFI_SocketConnect assigns the address of the peer communication endpoint. The function
-behaves differently according to the type of socket:
-
-- \b ARM_SOCKET_SOCK_STREAM: A connection is established between the endpoints.
-
- In blocking mode, which is enabled by default, this function waits for a connection to be established.
-
- In non blocking mode, the function returns the error code \c ARM_SOCKET_EINPROGRESS and the connection
- is established asynchronously. Subsequent calls to \b ARM_WIFI_SocketConnect for the same socket,
- before the connection is established, return the error code \c ARM_SOCKET_EALREADY. When the connection
- is established, the call to \b ARM_WIFI_SocketConnect returns the error code \c ARM_SOCKET_EISCONN.
-
-- \b ARM_SOCKET_SOCK_DGRAM: An address filter is established between the endpoints.
-
- The address filter is changed with another \b ARM_WIFI_SocketConnect function call. If the socket
- is not yet bound, the system implicitly binds to a random dynamic port.
-
-The argument \em socket specifies a socket identification number returned from a previous call
-to \ref ARM_WIFI_SocketCreate.
-
-The argument \em ip is a pointer to the buffer containing the IP address octets of the endpoint node.
-
-The argument \em ip_len specifies the length of the IP address. The length is \token{4} bytes
-for the IPv4 address and \token{16} bytes for the IPv6 address.
-
-The argument \em port specifies the port of the endpoint node. If the argument \em port is \token{0},
-the function returns error, because this port is reserved.
-
-\b Example:
-\code
-extern ARM_DRIVER_WIFI Driver_WiFi0;
-static ARM_DRIVER_WIFI *wifi;
-
-static const char message[] = { "The quick brown fox jumps over the lazy dog." };
-
-void Echo_Client_Thread (void *arg) {
- uint8_t ip[4] = { 192U, 168U, 0U, 100U };
- int32_t sock, res;
- char dbuf[120];
-
- while (1) {
- wifi = &Driver_WiFi0;
- sock = wifi->SocketCreate (ARM_SOCKET_AF_INET, ARM_SOCKET_SOCK_STREAM, ARM_SOCKET_IPPROTO_TCP);
-
- res = wifi->SocketConnect (sock, (uint8_t *)ip, sizeof(ip), 7U);
- if (res == 0) {
- wifi->SocketSend (sock, message, sizeof(message));
- res = wifi->SocketRecv (sock, dbuf, sizeof(dbuf));
- if (res < 0) {
- break; // Error occured
- }
- if (res > 0) {
- if (memcmp (dbuf, message, res) != 0) {
- // error handling, message is not the same as sent
- }
- }
- }
- wifi->SocketClose (sock);
- osDelay (1000U);
- }
-}
-\endcode
-*/
-
-int32_t ARM_WIFI_SocketRecv (int32_t socket, void *buf, uint32_t len) {
- return 1;
-}
-/**
-\fn int32_t ARM_WIFI_SocketRecv (int32_t socket, void *buf, uint32_t len)
-\details
-The function \b ARM_WIFI_SocketRecv receives incoming data that has been queued for the socket.
-You can use this function with both, the stream and the datagram socket. It reads as much
-information as currently available up to the size of the buffer specified.
-
-In blocking mode, which is enabled by default, this function waits for received data. In non
-blocking mode, you must call the \b ARM_WIFI_SocketRecv function again if the error code
-\c ARM_SOCKET_EAGAIN is returned.
-
-The argument \em socket specifies a socket identification number returned from a previous call
-to \ref ARM_WIFI_SocketCreate.
-
-The argument \em buf is a pointer to the application data buffer for storing the data to.
-If the available data is too large to fit in the supplied application buffer \em buf, excess bytes
-are discarded in case of a datagram sockets. For stream sockets, the data is buffered internally
-so the application can retrieve all data by multiple calls of \b ARM_WIFI_SocketRecv function.
-
-The argument \em len specifies the size of the application data buffer.
-
-\note
-The function can also be used to check if the socket has data available to read by specifying \token{0}
-for argument \em len (argument \em buf is ignored).
-The function returns \token{0} if data is available or error code otherwise.
-In blocking mode, the function waits until data is available, in non blocking mode the function returns instantly.
-
-
-\b Example:
- - see \ref ARM_WIFI_SocketListen
-*/
-
-int32_t ARM_WIFI_SocketRecvFrom (int32_t socket, void *buf, uint32_t len, uint8_t *ip, uint32_t *ip_len, uint16_t *port) {
- return 1;
-}
-/**
-\fn int32_t ARM_WIFI_SocketRecvFrom (int32_t socket, void *buf, uint32_t len, uint8_t *ip, uint32_t *ip_len, uint16_t *port)
-\details
-The function \b ARM_WIFI_SocketRecvFrom is used to receive data that has been queued for a socket.
-It is normally used to receive messages on datagram sockets, but can also be used to receive a reliable,
-ordered stream of data on a connected stream sockets. It reads as much information as currently available
-up to the size of the buffer specified.
-
-In blocking mode, which is enabled by default, this function waits for received data. In non
-blocking mode, you must call the \b ARM_WIFI_SocketRecv function again if the error code
-\c ARM_SOCKET_EAGAIN is returned.
-
-The argument \em socket specifies a socket identification number returned from a previous call
-to \ref ARM_WIFI_SocketCreate.
-
-The argument \em buf is a pointer to the application data buffer for storing the data to.
-If the available data is too large to fit in the supplied application buffer \em buf, excess bytes
-are discarded in case of a datagram sockets. For stream sockets, the data is buffered internally
-so the application can retrieve all data by multiple calls of \b ARM_WIFI_SocketRecv function.
-
-The argument \em len specifies the size of the application data buffer.
-
-The argument \em ip is a pointer to the buffer that will receive the IP address of the sender.
-If the \em ip is \token{NULL}, the IP address is not returned.
-
-The argument \em ip_len is a pointer to the IP address length. It should initially contain the amount of
-space pointed to by \em ip. On return it contains the actual length of the address returned in bytes.
-
-The argument \em port is a pointer to the buffer, that will receive the port number of the sender.
-If the \em port is \token{NULL}, the port number is not returned.
-
-\note
-The function can also be used to check if the socket has data available to read by specifying \token{0}
-for argument \em len (arguments \em buf, \em ip, \em ip_len and \em port are ignored).
-The function returns \token{0} if data is available or error code otherwise.
-In blocking mode, the function waits until data is available, in non blocking mode the function returns instantly.
-
-\b Example:
-\code
-extern ARM_DRIVER_WIFI Driver_WiFi0;
-static ARM_DRIVER_WIFI *wifi;
-
-void Echo_Server_Thread (void *arg) {
- uint8_t ip[4];
- uint16_t port;
- int32_t sock, res;
- uint32_t ip_len;
- char dbuf[120];
-
- while (1) {
- wifi = &Driver_WiFi0;
- sock = wifi->SocketCreate (ARM_SOCKET_AF_INET, ARM_SOCKET_SOCK_DGRAM, ARM_SOCKET_IPPROTO_UDP);
-
- ip[0] = 0U; // Unspecified address
- ip[1] = 0U;
- ip[2] = 0U;
- ip[3] = 0U;
- port = 7U; // Standard port for Echo service
-
- wifi->SocketBind (sock, (uint8_t *)ip, sizeof(ip), port);
-
- while (1) {
- ip_len = sizeof(ip);
- res = wifi->SocketRecvFrom (sock, dbuf, sizeof(dbuf), (uint8_t *)ip, &ip_len, &port);
- if (res < 0) {
- break; // Error occurred
- }
- if (res > 0) { // Echo the data
- wifi->SocketSendTo (sock, dbuf, res, (uint8_t *)ip, ip_len, port);
- }
- }
- wifi->SocketClose (sock);
- }
-}
-\endcode
-*/
-
-int32_t ARM_WIFI_SocketSend (int32_t socket, const void *buf, uint32_t len) {
- return 1;
-}
-/**
-\fn int32_t ARM_WIFI_SocketSend (int32_t socket, const void *buf, uint32_t len)
-\details
-The function \b ARM_WIFI_SocketSend is used to send data on an already connected socket. This function is
-normally used to send a reliable, ordered stream of data bytes on a stream sockets. It can also be used
-to send messages on datagram sockets.
-
-The argument \em socket specifies a socket identification number returned from a previous call
-to \ref ARM_WIFI_SocketCreate.
-
-The argument \a buf is a pointer to the application data buffer containing data to transmit. The buffer
-data length is not limited in size. If the data length is too large for one packet, the \b ARM_WIFI_SocketSend function
-will fragment the data and send it in several successive data packets:
-- In blocking mode, which is enabled by default, this function returns after the data has been successfully queued for transmission.
-- In non blocking mode, the function returns immediately without blocking the system.
-
-The argument \a len specifies the length of data in bytes.
-
-Return value, when positive, represents the number of bytes sent, which can be less than \a len.
-
-\note
-The function can also be used to check if the socket is ready to send data by specifying \token{0}
-for argument \em len (argument \em buf is ignored).
-The function returns \token{0} if the socket is writable or error code otherwise.
-
-\b Example:
- - see \ref ARM_WIFI_SocketListen
-*/
-
-int32_t ARM_WIFI_SocketSendTo (int32_t socket, const void *buf, uint32_t len, const uint8_t *ip, uint32_t ip_len, uint16_t port) {
- return 1;
-}
-/**
-\fn int32_t ARM_WIFI_SocketSendTo (int32_t socket, const void *buf, uint32_t len, const uint8_t *ip, uint32_t ip_len, uint16_t port)
-\details
-The function \b ARM_WIFI_SocketSendTo is used to send data. It is normally used to send messages
-on a datagram sockets, but can also be used to send data on a connected stream sockets.
-
-If the datagram socket is not yet bound, the system implicitly binds to a random dynamic port.
-
-The argument \em socket specifies a socket identification number returned from a previous call
-to \ref ARM_WIFI_SocketCreate.
-
-The argument \a buf is a pointer to the application data buffer containing data to transmit. The buffer
-data length is not limited in size. If the data length is too large for one packet, the \b ARM_WIFI_SocketSend function
-will fragment the data and send it in several successive data packets:
-- In blocking mode, which is enabled by default, this function returns after the data has been successfully queued for transmission.
-- In non blocking mode, the function returns immediately without blocking the system.
-
-The argument \a len specifies the length of data in bytes.
-
-The argument \em ip is a pointer to the buffer containing the IP address octets of the endpoint node.
-
-The argument \em ip_len specifies the length of the IP address. The length is \token{4} bytes
-for the IPv4 address and \token{16} bytes for the IPv6 address.
-
-The argument \em port specifies the port of the endpoint node. If the argument \em port is \token{0},
-the function returns error, because this port is reserved.
-
-For the stream sockets, arguments \em ip, \em ip_len and \em port are ignored.
-
-Return value, when positive, represents the number of bytes sent, which can be less than \a len.
-
-\note
-The function can also be used to check if the socket is ready to send data by specifying \token{0}
-for argument \em len (arguments \em buf, \em ip, \em ip_len and \em port are ignored).
-The function returns \token{0} if the socket is writable or error code otherwise.
-
-\b Example:
- - see \ref ARM_WIFI_SocketRecvFrom
-*/
-
-int32_t ARM_WIFI_SocketGetSockName (int32_t socket, uint8_t *ip, uint32_t *ip_len, uint16_t *port) {
- return 0;
-}
-/**
-\fn int32_t ARM_WIFI_SocketGetSockName (int32_t socket, uint8_t *ip, uint32_t *ip_len, uint16_t *port)
-\details
-The function \b ARM_WIFI_SocketGetSockName retrieves the local IP address and port for a socket.
-
-The argument \em socket specifies a socket identification number returned from a previous call
-to \ref ARM_WIFI_SocketCreate.
-
-The argument \em ip is a pointer to the buffer that will receive the local IP address.
-If the \em ip is \token{NULL}, the local IP address is not returned.
-
-The argument \em ip_len is a pointer to the IP address length. It should initially contain the amount of
-space pointed to by \em ip. On return it contains the actual length of the address returned in bytes.
-
-The argument \em port is a pointer to the buffer, that will receive the local port number.
-If the \em port is \token{NULL}, the local port number is not returned.
-
-\b Example:
-\code
-static uint8_t local_ip[4]; // Socket address and port
-static uint16_t local_port;
-
-static void get_socket_local_info (void) {
- uint32_t ip_len;
-
- ip_len = sizeof(local_ip);
- wifi->SocketGetSockName (sock, (uint8_t *)local_ip, &ip_len, &local_port);
-}
-\endcode
-*/
-
-int32_t ARM_WIFI_SocketGetPeerName (int32_t socket, uint8_t *ip, uint32_t *ip_len, uint16_t *port) {
- return 0;
-}
-/**
-\fn int32_t ARM_WIFI_SocketGetPeerName (int32_t socket, uint8_t *ip, uint32_t *ip_len, uint16_t *port)
-\details
-The function \b ARM_WIFI_SocketGetPeerName retrieves the IP address and port of the peer to which
-a socket is connected.
-
-The argument \em socket specifies a socket identification number returned from a previous call
-to \ref ARM_WIFI_SocketCreate.
-
-The argument \em ip is a pointer to the buffer that will receive the IP address of the peer.
-If the \em ip is \token{NULL}, the IP address is not returned.
-
-The argument \em ip_len is a pointer to the IP address length. It should initially contain the amount of
-space pointed to by \em ip. On return it contains the actual length of the address returned in bytes.
-
-The argument \em port is a pointer to the buffer, that will receive the port number of the peer.
-If the \em port is \token{NULL}, the port number is not returned.
-
-\b Example:
-\code
-static uint8_t peer_ip[4]; // Socket address and port
-static uint16_t peer_port;
-
-static void get_socket_peer_info (void) {
- uint32_t ip_len;
-
- ip_len = sizeof(peer_ip);
- wifi->SocketGetPeerName (sock, (uint8_t *)peer_ip, &ip_len, &peer_port);
-}
-\endcode
-*/
-
-int32_t ARM_WIFI_SocketGetOpt (int32_t socket, int32_t opt_id, void *opt_val, uint32_t *opt_len) {
- return 0;
-}
-/**
-\fn int32_t ARM_WIFI_SocketGetOpt (int32_t socket, int32_t opt_id, void *opt_val, uint32_t *opt_len)
-\details
-The function \b ARM_WIFI_SocketGetOpt retrieves options for a socket.
-
-The argument \em socket specifies a socket identification number returned from a previous call
-to \ref ARM_WIFI_SocketCreate.
-
-The argument \em opt_id is the socket option for which the value is to be retrieved. The following
-socket options are supported:
-Option | Description
-:----------------------------|:-------------------------------------------------
-\ref ARM_SOCKET_SO_RCVTIMEO | Timeout for receiving in blocking mode
-\ref ARM_SOCKET_SO_SNDTIMEO | Timeout for sending in blocking mode
-\ref ARM_SOCKET_SO_KEEPALIVE | Keep-alive mode for the stream socket
-\ref ARM_SOCKET_SO_TYPE | Type of the socket (stream or datagram)
-
-The argument \em opt_val points to the buffer that will receive the value of the \em opt_id.
-
-The argument \em opt_len contains the length of the buffer at the input and returns the length
-of the option information on the output.
-
-\b Example:
-\code
-uint32_t type;
-
-wifi->SocketGetOpt (sock, ARM_SOCKET_SO_TYPE, &type, sizeof(type));
-if (type == ARM_SOCKET_SOCK_STREAM) {
- // Stream socket
-}
-if (type == ARM_SOCKET_SOCK_DGRAM) {
- // Datagram socket
-}
-\endcode
-*/
-
-int32_t ARM_WIFI_SocketSetOpt (int32_t socket, int32_t opt_id, const void *opt_val, uint32_t opt_len) {
- return 0;
-}
-/**
-\fn int32_t ARM_WIFI_SocketSetOpt (int32_t socket, int32_t opt_id, const void *opt_val, uint32_t opt_len)
-\details
-The function \b ARM_WIFI_SocketSetOpt sets options for a socket.
-
-The argument \em socket specifies a socket identification number returned from a previous call
-to \ref ARM_WIFI_SocketCreate.
-
-The argument \em opt_id is the socket option for which the value is to be set. The following
-socket options are supported:
-Option | Description
-:----------------------------|:-------------------------------------------------
-\ref ARM_SOCKET_IO_FIONBIO | Non-blocking mode for the socket
-\ref ARM_SOCKET_SO_RCVTIMEO | Timeout for receiving in blocking mode
-\ref ARM_SOCKET_SO_SNDTIMEO | Timeout for sending in blocking mode
-\ref ARM_SOCKET_SO_KEEPALIVE | Keep-alive mode for the stream socket
-
-The argument \em opt_val points to the buffer containing the value of the \em opt_id.
-
-The argument \em opt_len tells the exact length of the option.
-
-\b Example:
-\code
-uint32_t nonblocking = 0U; // Blocking mode
-uint32_t timeout = 10000U; // Timeout 10 seconds
-
-wifi->SocketSetOpt (sock, ARM_SOCKET_IO_FIONBIO, &nonblocking, sizeof(nonblocking));
-wifi->SocketSetOpt (sock, ARM_SOCKET_SO_RCVTIMEO, &timeout, sizeof(timeout));
-wifi->SocketSetOpt (sock, ARM_SOCKET_SO_SNDTIMEO, &timeout, sizeof(timeout));
-\endcode
-*/
-
-int32_t ARM_WIFI_SocketClose (int32_t socket) {
- return 0;
-}
-/**
-\fn int32_t ARM_WIFI_SocketClose (int32_t socket)
-\details
-The function \b ARM_WIFI_SocketClose closes an existing socket and releases the socket descriptor.
-Further references to \em socket fail with \c ARM_SOCKET_EINVAL error code.
-
-The argument \em socket specifies a socket identification number returned from a previous call
-to \ref ARM_WIFI_SocketCreate.
-
-In blocking mode, which is enabled by default, this function will wait until a socket is closed.
-In non blocking mode, you must call the \b ARM_WIFI_SocketClose function again if the error code
-\c ARM_SOCKET_EAGAIN is returned.
-
-\b Example:
- - see \ref ARM_WIFI_SocketListen
-*/
-
-int32_t ARM_WIFI_SocketGetHostByName (const char *name, int32_t af, uint8_t *ip, uint32_t *ip_len) {
- return 0;
-}
-/**
-\fn int32_t ARM_WIFI_SocketGetHostByName (const char *name, int32_t af, uint8_t *ip, uint32_t *ip_len)
-\details
-The function \b ARM_WIFI_SocketGetHostByName retrieves host information corresponding to
-a host name from a host database. It does this by sending DNS requests to the DNS server.
-The IP address of the DNS server is specified in the network interface configuration or can be
-obtained from the DHCP server for the local area network.
-
-The argument \a name is a pointer to the \token{null}-terminated name of the host to resolve.
-
-The argument \em af specifies the address family, that is, which type of IP address you want
-to resolve. The following values are supported:
-Family | Description
-:----------------------------|:-------------------------------------------------
-\ref ARM_SOCKET_AF_INET | Resolve the IPv4 address
-\ref ARM_SOCKET_AF_INET6 | Resolve the IPv6 address
-
-The argument \em ip is a pointer to the buffer that will receive the resolved IP address of the host.
-If the argument \em ip is \token{NULL}, the function returns error.
-
-The argument \em ip_len is a pointer to the IP address length. It should initially contain the amount of
-space pointed to by \em ip. On return it contains the actual length of the address returned in bytes.
-
-\b Example:
-\code
-extern ARM_DRIVER_WIFI Driver_WiFi0;
-static ARM_DRIVER_WIFI *wifi;
-
-void ping_arm_com (void) {
- uint8_t ip[4];
- uint32_t ip_len;
- int32_t res;
-
- wifi = &Driver_WiFi0;
- ip_len = sizeof(ip);
- res = wifi->SocketGetHostByName ("www.arm.com", ARM_SOCKET_AF_INET, (uint8_t *)ip, &ip_len);
- if (res == ARM_DRIVER_OK) {
- res = wifi->Ping ((uint8_t *)ip, sizeof(ip));
- if (res == ARM_DRIVER_OK) {
- // "www.arm.com" responded to ping
- }
- }
- else {
- // "www.arm.com" not resolved
- }
-}
-\endcode
-*/
-
-int32_t ARM_WIFI_Ping (const uint8_t *ip, uint32_t ip_len) {
- return ARM_DRIVER_OK;
-}
-/**
-\fn int32_t ARM_WIFI_Ping (const uint8_t *ip, uint32_t ip_len)
-\details
-The function \b ARM_WIFI_Ping checks if the remote host is reachable. It does this by sending
-an echo request and waiting for an echo response. The function then returns the result
-of the operation. Check the \ref ARM_WIFI_CAPABILITIES of the driver, if this function
-is supported in the driver implementation.
-
-The argument \em ip is a pointer to the buffer containing the IP address octets of the host to ping.
-
-The argument \em ip_len specifies the length of the IP address. The length is \token{4} bytes
-for the IPv4 address and \token{16} bytes for the IPv6 address.
-
-\note
-The host availability check fails, if the remote host does not respond to echo requests,
-or intermediate routers do not forward the echo requests or echo responses.
-
-\b Example:
-\code
-extern ARM_DRIVER_WIFI Driver_WiFi0;
-static ARM_DRIVER_WIFI *wifi;
-
-void ping_host (void) {
- uint8_t ip[4] = { 192U, 168U, 0U, 100U };
- int32_t res;
-
- wifi = &Driver_WiFi0;
- res = wifi->Ping ((uint8_t *)ip, sizeof(ip));
- if (res == ARM_DRIVER_OK) {
- // Host responded
- }
-}
-\endcode
-*/
-/**
-@}
-*/
-// end group wifi_socket_gr
-
-
-/**
-@}
-*/
-// End WiFi Interface
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/Flash_Demo.c b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/Flash_Demo.c
deleted file mode 100644
index f4dd000..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/Flash_Demo.c
+++ /dev/null
@@ -1,55 +0,0 @@
-#include "Driver_Flash.h"
-#include "cmsis_os2.h" // ARM::CMSIS:RTOS2:Keil RTX5
-
-/* Flash driver instance */
-extern ARM_DRIVER_FLASH Driver_Flash0;
-static ARM_DRIVER_FLASH * flashDev = &Driver_Flash0;
-
-/* CMSIS-RTOS2 Thread Id */
-osThreadId_t Flash_Thread_Id;
-
-/* Flash signal event */
-void Flash_Callback(uint32_t event)
-{
- if (event & ARM_FLASH_EVENT_READY) {
- /* The read/program/erase operation is completed */
- osThreadFlagsSet(Flash_Thread_Id, 1U);
- }
- if (event & ARM_FLASH_EVENT_ERROR) {
- /* The read/program/erase operation is completed with errors */
- /* Call debugger or replace with custom error handling */
- __breakpoint(0);
- }
-}
-
-/* CMSIS-RTOS2 Thread */
-void Flash_Thread (void *argument)
-{
- /* Query drivers capabilities */
- const ARM_FLASH_CAPABILITIES capabilities = flashDev->GetCapabilities();
-
- /* Initialize Flash device */
- if (capabilities.event_ready) {
- flashDev->Initialize (&Flash_Callback);
- } else {
- flashDev->Initialize (NULL);
- }
-
- /* Power-on Flash device */
- flashDev->PowerControl (ARM_POWER_FULL);
-
- /* Read data taking data_width into account */
- uint8_t buf[256U];
- flashDev->ReadData (0x1000U, buf, sizeof(buf)>>capabilities.data_width);
-
- /* Wait operation to be completed */
- if (capabilities.event_ready) {
- osThreadFlagsWait (1U, osFlagsWaitAny, 100U);
- } else {
- osDelay(100U);
- }
-
- /* Switch off gracefully */
- flashDev->PowerControl (ARM_POWER_OFF);
- flashDev->Uninitialize ();
-}
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/General.txt b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/General.txt
deleted file mode 100644
index 459f295..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/General.txt
+++ /dev/null
@@ -1,4439 +0,0 @@
-/**
-\mainpage Overview
-
-The CMSIS-Driver specification is a software API that describes peripheral driver interfaces for middleware stacks and user
-applications. The CMSIS-Driver API is designed to be generic and independent of a specific RTOS making it reusable across a
-wide range of supported microcontroller devices. The CMSIS-Driver API covers a wide range of use cases for the supported
-peripheral types, but can not take every potential use-case into account. Over time, it is indented to extend the
-CMSIS-Driver API with further groups to cover new use-cases.
-
-The CMSIS Software Pack publishes the API Interface under the Component Class \b CMSIS \b Driver with header files and a
-documentation. These header files are the reference for the implementation of the standardized peripheral driver interfaces.
-These implementations are published typically in the Device Family Pack of a related microcontroller family under the
-Component Class \b CMSIS \b Driver. A Device Family Pack may contain additional interfaces in the Component Class \b Device
-to extend the standard Peripheral Drivers covered by this CMSIS-Driver specification with additional device specific
-interfaces for example for Memory BUS, GPIO, or DMA.
-
-The standard peripheral driver interfaces connect microcontroller peripherals for example with middleware that implements
-communication stacks, file systems, or graphic user interfaces. Each peripheral driver interface may provide multiple
-instances reflecting the multiple physical interfaces of the same type in a device. For example the two physical SPI
-interfaces are reflected with a separate \ref AccessStruct for SPI1 and SPI2. The \ref AccessStruct is the interface of a
-driver to the middleware component or the user application.
-
-\image html driver.png "Peripheral Driver Interfaces and Middleware"
-
-The following CMSIS-Driver API groups are defined:
- - \ref can_interface_gr "CAN": Interface to CAN bus peripheral.
- - \ref eth_interface_gr "Ethernet": Interface to Ethernet MAC and PHY peripheral.
- - \ref i2c_interface_gr "I2C": Multi-master Serial Single-Ended Bus interface driver.
- - \ref mci_interface_gr "MCI": Memory Card Interface for SD/MMC memory.
- - \ref nand_interface_gr "NAND": NAND Flash Memory interface driver.
- - \ref flash_interface_gr "Flash": Flash Memory interface driver.
- - \ref sai_interface_gr "SAI": Serial audio interface driver (I2s, PCM, AC'97, TDM, MSB/LSB Justified).
- - \ref spi_interface_gr "SPI": Serial Peripheral Interface Bus driver.
- - \ref storage_interface_gr "Storage": Storage device interface driver.
- - \ref usart_interface_gr "USART": Universal Synchronous and Asynchronous Receiver/Transmitter interface driver.
- - \ref usb_interface_gr "USB": Interface driver for USB Host and USB Device communication.
- - \ref vio_interface_gr "VIO": API for virtual I/Os (VIO).
- - \ref wifi_interface_gr "WiFi": Interface driver for wireless communication.
-
-A list of current CMSIS-Driver implementations is available \ref listOfImplementations "here".
-
-\note Usually, WiFi chips and modules have their own networking stack incorporated. This means that payload data is sent via
-a serial interface (SPI or USART) to the WiFi chip/module and the Ethernet frames are assembled inside. If you intend to use
-a TCP/IP stack from a middleware component with a WiFi chip/module, make sure that the WiFi driver has a \ref wifi_bypass_gr.
-This allows to send the Ethernet frames assembled by the TCP/IP component transparently through the WiFi chip/module.
-
-ARM::CMSIS Pack directories:
-| Directory | Content |
-|--------------------------------|------------------------------------------------------------------------|
-|\b CMSIS/Documentation/Driver | This documentation |
-|\b CMSIS/Driver/Include | Driver header files (Driver_interface .h, Driver_Common.h) |
-|\b CMSIS/Driver/DriverTemplates | Driver implementation template files (Driver_interface .c) |
-
-
-
- Version
- Description
-
-
- 2.8.0
-
- - Changed: removed volatile from status related typedefs APIs
- - Enhanced WiFi Interface API with support for polling Socket Receive/Send
- - Added VIO API 0.1.0 (Preview)
-
-
-
- 2.7.1
-
- - Finalized WiFi Interface API 1.0.0.
-
-
-
- 2.7.0
-
- - Added WiFi Interface API 1.0.0-beta.
- - Added custom driver selection to simplify implementation of new CMSIS-Driver.
-
-
-
- 2.6.0
-
- - Enhanced CAN-Driver API with explicit BUSOFF state.
- - Enhanced NAND-Driver API for ECC handling.
-
-
-
- 2.05
-
- - Changed: All typedefs related to status have been made volatile.
-
-
-
- 2.04
-
- - Added: template files for CAN interface driver.
-
-
-
- 2.03
-
- - Added: CAN API for an interface to CAN peripherals
- - Added: Overview of the \ref driverValidation "CMSIS-Driver Validation" Software Pack.
- - Enhanced: documentation and clarified behavior of the \ref CallSequence.
-
-
-
- 2.02
-
- - Minor API changes, for exact details refer to the header file of each driver.
- - Added: Flash Interface, NAND interface.
-
-
-
- 2.00
- API with non-blocking data transfer, independent of CMSIS-RTOS.
-
-
- 1.10
- Initial release
-
-
-*/
-
-/*=======0=========1=========2=========3=========4=========5=========6=========7=========8=========9=========0=========1====*/
-/**
-\page listOfImplementations CMSIS-Driver Implementation List
-
-The following table shows a list of current CMSIS-Driver implementations. It is regularly updated, so it is subject to change.
-
-[CAN]: \ref can_interface_gr "CAN"
-[Ethernet MAC]: \ref eth_mac_interface_gr "Ethernet MAC".
-[Ethernet PHY]: \ref eth_phy_interface_gr "Ethernet PHY".
-[I2C]: \ref i2c_interface_gr "I2C".
-[MCI]: \ref mci_interface_gr "MCI".
-[NAND]: \ref nand_interface_gr "NAND".
-[Flash]: \ref flash_interface_gr "Flash".
-[SAI]: \ref sai_interface_gr "SAI".
-[SPI]: \ref spi_interface_gr "SPI".
-[Storage]: \ref storage_interface_gr "Storage".
-[USART]: \ref usart_interface_gr "USART".
-[USB Host]: \ref usbh_interface_gr "USB Host".
-[USB Device]: \ref usbd_interface_gr "USB Device".
-[VIO]: \ref vio_interface_gr "VIO".
-[WiFi]: \ref wifi_interface_gr "WiFi"
-
-
-
- Vendor
- Device/Family
- [CAN]
- [Ethernet MAC]
- [Ethernet PHY]
- [I2C]
- [MCI]
- [NAND]
- [Flash]
- [SAI]
- [SPI]
- [Storage]
- [USART]
- [USB Host]
- [USB Device]
- [VIO]
- [WiFi]
-
-
- Arm
- Musca-A1
- √ √
-
- Musca-B1
- √ √
-
- Musca-S1
- √
-
- SSE-200
- √ √ √ √
-
- SSE-300
- √ √ √ √
-
- SSE-310
- √ √ √ √
-
- Espressif
- ESP32
- √
-
- ESP8266
- √
-
- Infineon
- S29GL064Nx2
- √
-
- XMC1000
- √ √ √ √ √
-
- XMC4000
- √ √ √ √ √ √ √ √ √ √
-
- Inventek
- ISM43362
- √
-
- Microchip
- KSZ8061RNA
- √
-
- KSZ8061RNB
- √
-
- KSZ8851SNL
- √ √
-
- LAN8710A
- √
-
- LAN8720
- √
-
- LAN8742A
- √
-
- LAN8740A
- √
-
- LAN91C111
- √ √
-
- LAN9220
- √ √
-
- Micron
- M29EW28F128
- √
-
- M29W640FB
- √
-
- NXP
- LPC1500
- √ √ √
-
- LPC1700
- √ √ √ √ √ √ √ √ √
-
- LPC1800
- √ √ √ √ √ √ √ √ √
-
- LPC4000
- √ √ √ √ √ √ √ √ √
-
- LPC4300
- √ √ √ √ √ √ √ √ √
-
- i.MXRT105x
- √ √ √ √ √
-
- i.MXRT1060
- √ √ √ √ √
-
- i.MXRT1064
- √ √ √ √ √ √
-
- K32L2A31A
- √ √ √
-
- K32L2A41A
- √ √ √
-
- K32L2B11A
- √ √ √
-
- K32L2B21A
- √ √ √
-
- K32L2B31A
- √ √ √
-
- K32L3A60
- √ √ √
-
- LPC51U68
- √ √ √
-
- LPC54005
- √ √ √
-
- LPC54016
- √ √ √
-
- LPC54018M
- √ √ √
-
- LPC54018
- √ √ √
-
- LPC54102
- √ √ √
-
- LPC54113
- √ √ √
-
- LPC54114
- √ √ √ √ √
-
- LPC54605
- √ √ √
-
- LPC54606
- √ √ √
-
- LPC54607
- √ √ √
-
- LPC54608
- √ √ √
-
- LPC54616
- √ √ √
-
- LPC54618
- √ √ √
-
- LPC54628
- √ √ √
-
- LPC54S005
- √ √ √
-
- LPC54S016
- √ √ √
-
- LPC54S018M
- √ √ √
-
- LPC54S018
- √ √ √
-
- LPC5502
- √ √ √
-
- LPC5504
- √ √ √
-
- LPC5506
- √ √ √
-
- LPC5512
- √ √ √
-
- LPC5514
- √ √ √
-
- LPC5516
- √ √ √
-
- LPC5526
- √ √ √
-
- LPC5528
- √ √ √
-
- LPC5534
- √ √ √
-
- LPC5536
- √ √ √
-
- LPC55S04
- √ √ √
-
- LPC55S06
- √ √ √
-
- LPC55S14
- √ √ √
-
- LPC55S16
- √ √ √
-
- LPC55S26
- √ √ √
-
- LPC55S28
- √ √ √
-
- LPC55S36
- √ √ √
-
- LPC55S66
- √ √ √
-
- LPC55S69
- √ √ √
-
- MIMX8MD6
- √ √ √
-
- MIMX8MD7
- √ √ √
-
- MIMX8MQ5
- √ √ √
-
- MIMX8MQ6
- √ √ √
-
- MIMX8MQ7
- √ √ √
-
- MIMXRT1011
- √ √ √
-
- MIMXRT1015
- √ √ √
-
- MIMXRT1021
- √ √ √ √ √
-
- MIMXRT1024
- √ √ √ √ √
-
- MIMXRT1051
- √ √ √ √ √
-
- MIMXRT1052
- √ √ √ √ √
-
- MIMXRT1061
- √ √ √
-
- MIMXRT1061X
- √ √ √
-
- MIMXRT1062
- √ √ √ √ √
-
- MIMXRT1062X
- √ √ √ √ √
-
- MIMXRT1064
- √ √ √ √ √
-
- MIMXRT1165
- √ √ √ √ √
-
- MIMXRT1166
- √ √ √ √ √
-
- MIMXRT1173
- √ √ √ √ √
-
- MIMXRT1175
- √ √ √ √ √
-
- MIMXRT1176
- √ √ √ √ √
-
- MIMXRT533S
- √ √ √
-
- MIMXRT555S
- √ √ √
-
- MIMXRT595S
- √ √ √
-
- MIMXRT633S
- √ √ √
-
- MIMXRT685S
- √ √ √
-
- MK02F12810
- √ √ √
-
- MK11D5
- √ √ √
-
- MK11DA5
- √ √ √
-
- MK12D5
- √ √ √
-
- MK21D5
- √ √ √
-
- MK21DA5
- √ √ √
-
- MK21F12
- √ √ √
-
- MK21FA12
- √ √ √
-
- MK22D5
- √ √ √
-
- MK22F12810
- √ √ √
-
- MK22F12
- √ √ √
-
- MK22F25612
- √ √ √
-
- MK22F51212
- √ √ √
-
- MK22FA12
- √ √ √
-
- MK24F12
- √ √ √
-
- MK24F25612
- √ √ √
-
- MK26F18
- √ √ √
-
- MK27F15
- √ √ √
-
- MK27FA15
- √ √ √
-
- MK28F15
- √ √ √
-
- MK28FA15
- √ √ √
-
- MK63F12
- √ √ √
-
- MK64F12
- √ √ √ √ √ √ √ √
-
- MK65F18
- √ √ √
-
- MK66F18
- √ √ √
-
- MK80F25615
- √ √ √
-
- MK82F25615
- √ √ √
-
- MKE02Z4
- √ √ √
-
- MKE04Z1284
- √ √ √
-
- MKE04Z4
- √ √ √
-
- MKE06Z4
- √ √ √
-
- MKE12Z7
- √ √ √
-
- MKE13Z7
- √ √ √
-
- MKE14F16
- √ √ √
-
- MKE14Z4
- √ √ √
-
- MKE14Z7
- √ √ √
-
- MKE15Z4
- √ √ √
-
- MKE15Z7
- √ √ √
-
- MKE16F16
- √ √ √
-
- MKE16Z4
- √ √ √
-
- MKE17Z7
- √ √ √
-
- MKE18F16
- √ √ √
-
- MKL02Z4
- √ √ √
-
- MKL03Z4
- √ √ √
-
- MKL13Z644
- √ √ √
-
- MKL17Z4
- √ √ √
-
- MKL17Z644
- √ √ √
-
- MKL26Z4
- √ √ √
-
- MKL27Z4
- √ √ √
-
- MKL27Z644
- √ √ √
-
- MKL28Z7
- √ √ √
-
- MKL33Z4
- √ √ √
-
- MKL33Z644
- √ √ √
-
- MKL34Z4
- √ √ √
-
- MKL36Z4
- √ √ √
-
- MKL43Z4
- √ √ √
-
- MKL46Z4
- √ √ √
-
- MKL82Z7
- √ √ √
-
- MKM14ZA5
- √ √ √
-
- MKM33ZA5
- √ √ √
-
- MKM34Z7
- √ √ √
-
- MKM34ZA5
- √ √ √
-
- MKM35Z7
- √ √ √
-
- MKS20F12
- √ √ √
-
- MKS22F12
- √ √ √
-
- MKV10Z1287
- √ √ √
-
- MKV10Z7
- √ √ √
-
- MKV11Z7
- √ √ √
-
- MKV30F12810
- √ √ √
-
- MKV31F12810
- √ √ √
-
- MKV31F25612
- √ √ √
-
- MKV31F51212
- √ √ √
-
- MKV42F16
- √ √ √
-
- MKV44F16
- √ √ √
-
- MKV46F16
- √ √ √
-
- MKV56F24
- √ √ √
-
- MKV58F24
- √ √ √
-
- S32K3
- √
-
- Qualcomm
- QCA400x
- √
-
- Redpine
- RS13100
- √ √ √ √ √ √
-
- RS14100
- √ √ √ √ √ √ √ √ √
-
- Renesas
- AT45DB641E
- √
-
- AT45DB642D
- √
-
- DA16200
- √
-
- STMicroelectronics
- STM32F0xx
- √ √ √ √ √
-
- STM32F1xx
- √ √ √ √ √ √ √ √
-
- STM32F2xx
- √ √ √ √ √ √ √ √
-
- STM32F3xx
- √ √ √ √ √
-
- STM32F4xx
- √ √ √ √ √ √ √ √
-
- STM32F7xx
- √ √ √ √ √ √ √ √ √
-
- STM32G0xx
- √
-
- STM32G4xx
- √ √ √
-
- STM32H7xx
- √ √ √ √ √ √ √ √ √
-
- STM32L0xx
- √ √ √ √
-
- STM32L1xx
- √
-
- STM32L4xx
- √ √ √ √ √ √
-
- STM32L5xx
- √ √ √
-
- STM32U5xx
- √ √ √
-
- ST802RT1
- √
-
- Texas Instruments
- DP82848C
- √
-
- WizNet
- WizFi360
- √
-
-*/
-
-/*=======0=========1=========2=========3=========4=========5=========6=========7=========8=========9=========0=========1====*/
-/**
-\page theoryOperation Theory of Operation
-[TOC]
-
-This section gives an overview of the general operation of CMSIS-Drivers. It explains the \ref DriverFunctions that are
-common in all CMSIS-Drivers along with the \ref CallSequence. The topic \ref Data_Xfer_Functions describes how data
-read/write operations to the peripheral are implemented.
-
-Each CMSIS-Driver defines an \ref AccessStruct for calling the various driver functions and each peripheral (that is accessed
-via a CMSIS-Driver) has one \ref DriverInstances "Driver Instance".
-
-
-\section DriverFunctions Common Driver Functions
-
-Each CMSIS-Driver contains these functions:
-
- - \b GetVersion: can be called at any time to obtain version information of the driver interface.
-
- - \b GetCapabilities: can be called at any time to obtain capabilities of the driver interface.
-
- - \b Initialize: must be called before powering the peripheral using \b PowerControl. This function performs the following:
- - allocate I/O resources.
- - register an optional \b SignalEvent callback function.
-
- - \b SignalEvent: is an optional callback function that is registered with the \b Initialize function. This callback
- function is initiated from interrupt service routines and indicates hardware events or the completion of a data block
- transfer operation.
-
- - \b PowerControl: Controls the power profile of the peripheral and needs to be called after \b Initialize. Typically, three
- power options are available:
- - \c ARM_POWER_FULL: Peripheral is turned on and fully operational. The driver initializes the peripheral registers, interrupts, and (optionally) DMA.
- - \c ARM_POWER_LOW: (optional) Peripheral is in low power mode and partially operational; usually, it can detect
- external events and wake-up.
- - \c ARM_POWER_OFF: Peripheral is turned off and not operational (pending operations are terminated). This is the state
- after device reset.
-
- - \b Uninitialize: Complementary function to Initialize. Releases the I/O pin resources used by the interface.
-
- - \b Control: Several drivers provide a control function to configure communication parameters or execute miscellaneous
- control functions.
-
-The section \ref CallSequence contains more information on the operation of each function. Additional functions are specific
-to each driver interface and are described in the individual sections of each driver.
-
-\subsection ProcessorMode Cortex-M Processor Mode
-
-The CMSIS-Driver functions access peripherals and interrupts and are designed to execute in \b Privileged mode.
-When calling CMSIS-Driver functions from RTOS threads, it should be ensure that these threads execute in \b Privileged mode.
-
-
-\section CallSequence Function Call Sequence
-
-For normal operation of the driver, the API functions \b GetVersion, \b GetCapabilities, \b Initialize, \b PowerControl, \b Uninitialize are
-called in the following order:
-
-\msc
- a [label="", textcolor="indigo", linecolor="indigo", arclinecolor="indigo"],
- b [label="", textcolor="blue", linecolor="blue", arclinecolor="blue"];
-
- a rbox a [label="Middleware", linecolor="indigo"],
- b rbox b [label="Driver", linecolor="blue"];
- --- [label="Verify API version"];
- a=>b [label="GetVersion ()", textcolor="gray", linecolor="gray"];
- --- [label="Obtain driver features"];
- a=>b [label="GetCapabilities (...)", textcolor="gray", linecolor="gray"];
- --- [label="Setup software resources"];
- a=>b [label="Initialize (...)", textcolor="red", linecolor="red"];
- --- [label="Setup the peripheral"];
- a=>b [label="PowerControl (ARM_POWER_FULL)", textcolor="red", linecolor="red"];
- --- [label="Operate with the peripheral"];
- a=>b [label="Data Transfer Functions"];
- a<=b [label="SignalEvent (...)"];
- --- [label="Wait for external hardware events"];
- a=>b [label="PowerControl (ARM_POWER_LOW)"];
- a<=b [label="SignalEvent (...)"];
- --- [label="Stop working with peripheral"];
- a=>b [label="PowerControl (ARM_POWER_OFF)", textcolor="red", linecolor="red"];
- a=>b [label="Uninitialize (...)", textcolor="red", linecolor="red"];
-\endmsc
-
-The functions \b GetVersion and \b GetCapabilities can be called any time to obtain the required information from the driver.
-These functions return always the same information.
-
-
-\subsection CS_start Start Sequence
-
-To start working with a peripheral the functions \b Initialize and \b PowerControl need to be called in this order:
-\code
- drv->Initialize (...); // Allocate I/O pins
- drv->PowerControl (ARM_POWER_FULL); // Power up peripheral, setup IRQ/DMA
-\endcode
-
-- \b Initialize typically allocates the I/O resources (pins) for the peripheral. The function can be called multiple times;
- if the I/O resources are already initialized it performs no operation and just returns with \ref ARM_DRIVER_OK.
-- \b PowerControl (\c ARM_POWER_FULL) sets the peripheral registers including interrupt (NVIC) and optionally DMA.
- The function can be called multiple times; if the registers are already set it performs no operation and just returns with \ref ARM_DRIVER_OK.
-
-\subsection CS_stop Stop Sequence
-
-To stop working with a peripheral the functions \b PowerControl and \b Uninitialize need to be called in this order:
-\code
- drv->PowerControl (ARM_POWER_OFF); // Terminate any pending transfers, reset IRQ/DMA, power off peripheral
- drv->Uninitialize (...); // Release I/O pins
-\endcode
-The functions \b PowerControl and \b Uninitialize always execute and can be used to put the peripheral into a Safe State ,
-for example after any data transmission errors. To restart the peripheral in a error condition, you should first execute
-the \ref CS_stop and then the \ref CS_start.
-
-- \b PowerControl (\c ARM_POWER_OFF) terminates any pending data transfers with the peripheral, disables the peripheral and
- leaves it in a defined mode (typically the reset state).
- - when DMA is used it is disabled (including the interrupts)
- - peripheral interrupts are disabled on NVIC level
- - the peripheral is reset using a dedicated reset mechanism (if available) or by clearing the peripheral registers
- - pending peripheral interrupts are cleared on NVIC level
- - driver variables are cleared
-- \b Uninitialize always releases I/O pin resources.
-
-\section Share_IO Shared I/O Pins
-
-All CMSIS-Driver provide a \ref CS_start and \ref CS_stop. Therefore two different drivers can share the same I/O pins,
-for example UART1 and SPI1 can have overlapping I/O pins. In this case the communication channels can be used as shown below:
-
-\code
- SPI1drv->Initialize (...); // Start SPI1
- SPI1drv->PowerControl (ARM_POWER_FULL);
- ... // Do operations with SPI1
- SPI1drv->PowerControl (ARM_POWER_OFF); // Stop SPI1
- SPI1drv->Uninitialize ();
- ...
- USART1drv->Initialize (...); // Start USART1
- USART1drv->PowerControl (ARM_POWER_FULL);
- ... // Do operations with USART1
- USART1drv->PowerControl (ARM_POWER_OFF); // Stop USART1
- USART1drv->Uninitialize ();
-\endcode
-
-\section Data_Xfer_Functions Data Transfer Functions
-
-A CMSIS-Driver implements non-blocking functions to transfer data to a peripheral. This means that the driver configures the
-read or write access to the peripheral and instantly returns to the calling application. The function names for data
-transfer end with:
- - \b Send to write data to a peripheral.
- - \b Receive to read data from a peripheral.
- - \b Transfer to indicate combined read/write operations to a peripheral.
-
-During a data transfer, the application can query the number of transferred data items using functions named
-Getxxx Count . On completion of a data transfer, the driver calls a callback function with a specific event code.
-
-During the data exchange with the peripheral, the application can decide to:
- - Wait (using an RTOS scheduler) for the callback completion event. The RTOS is controlled by the application code which
- makes the driver itself RTOS independent.
- - Use polling functions that return the number of transferred data items to show progress information or partly read or fill
- data transfer buffers.
- - Prepare another data transfer buffer for the next data transfer.
-
-The following diagram shows the basic communication flow when using the \b _Send function in an application.
-
-\image html Non_blocking_transmit_small.png "Non-blocking Send Function"
-
-\section AccessStruct Access Struct
-
-A CMSIS-Driver publishes an \ref AccessStruct with the data type name ARM_DRIVER_xxxx that gives to access the driver
-functions.
-
-\b Code \b Example: \b Function \b Access \b of \b the \b SPI \b driver
-\code
-typedef struct _ARM_DRIVER_SPI {
- ARM_DRIVER_VERSION (*GetVersion) (void);
- ARM_SPI_CAPABILITIES (*GetCapabilities) (void);
- int32_t (*Initialize) (ARM_SPI_SignalEvent_t cb_event);
- int32_t (*Uninitialize) (void);
- int32_t (*PowerControl) (ARM_POWER_STATE state);
- int32_t (*Send) (const void *data, uint32_t num);
- int32_t (*Receive) ( void *data, uint32_t num);
- int32_t (*Transfer) (const void *data_out, void *data_in, uint32_t num);
- uint32_t (*GetDataCount) (void);
- int32_t (*Control) (uint32_t control, uint32_t arg);
- ARM_SPI_STATUS (*GetStatus) (void);
-} const ARM_DRIVER_SPI;
-\endcode
-
-\subsection DriverInstances Driver Instances
-
-A device may offer several peripherals of the same type. For such devices, the CMSIS-Driver publishes multiple instances
-of the \ref AccessStruct. The name of each driver instance reflects the names of the peripheral available in the device.
-
-\b Code \b Example: \ref AccessStruct \b for \b three \b SPIs \b in \b a \b microcontroller \b device.
-\code
-ARM_DRIVER_SPI Driver_SPI1; // access functions for SPI1 interface
-ARM_DRIVER_SPI Driver_SPI2; // access functions for SPI2 interface
-ARM_DRIVER_SPI Driver_SPI3; // access functions for SPI3 interface
-\endcode
-
-The access functions can be passed to middleware to specify the driver instance that the middleware should use for communication.
-
-\b Naming \b Convention
-
-The access structs need to follow this naming convention: the keyword "Driver" followed by an underscore "_", the interface
-name "IFNAME" (usually in upper case letters), and the instance number "n". Here's the full list of access struct names for
-all drivers (n to be replaced with the actual instance number):
-\code
-Driver_CANn
-Driver_ETH_MACn
-Driver_ETH_PHYn
-Driver_Flashn
-Driver_I2Cn
-Driver_MCIn
-Driver_NANDn
-Driver_SAIn
-Driver_SPIn
-Driver_Storagen
-Driver_USARTn
-Driver_USBDn
-Driver_USBHn
-Driver_WiFin
-\endcode
-
-
-\b Example:
-\code
-void init_middleware (ARM_DRIVER_SPI *Drv_spi) ...
-\\ inside the middleware the SPI driver functions are called with:
-\\ Drv_spi->function (...);
-\endcode
-
-\code
-\\ setup middleware
-init_middleware (&Driver_SPI1); // connect middleware to SPI1 interface
- :
-init_middleware (&Driver_SPI2); // connect middleware to SPI2 interface
-\endcode
-
-
-\section DriverConfiguration Driver Configuration
-
-For a device family, the drivers may be configurable. The \ref referenceImplementation stores configuration options in a
-central file with the name \b RTE_Device.h. However, the configuration of the drivers itself is not part of the CMSIS-Driver
-specification.
-
-\section CodeExample Code Example
-
-The following example code shows the usage of the SPI interface.
-
-\include SPI_Demo.c
-*/
-
-/*=======0=========1=========2=========3=========4=========5=========6=========7=========8=========9=========0=========1====*/
-/**
-\page referenceImplementation Reference Implementation
-
-The API of the CMSIS-Drivers is published in the \ref DriverHeaderFiles.
-
-To simplify the development of a CMSIS-Driver both \ref DriverTemplates and \ref DriverExamples are provided.
-
-ARM offers also a Software Pack for CMSIS-Driver Validation as described in \ref driverValidation.
-
-\section DriverHeaderFiles Driver Header Files
-
-The API of each CMSIS-Driver is published in a header file. It is recommended to include the header file that is part of the
-CMSIS specification in the implementation file of the CMSIS-Driver.
-
-The following header files are available in the directory .\\CMSIS\\Driver\\Include .
-
-| Header File | Description
-|----------------------|-------------------------
-| %Driver_Common.h | \ref common_drv_gr
-| %Driver_CAN.h | \ref can_interface_gr
-| %Driver_ETH.h | \ref eth_interface_gr
-| %Driver_ETH_MAC.h | \ref eth_mac_interface_gr
-| %Driver_ETH_PHY.h | \ref eth_phy_interface_gr
-| %Driver_Flash.h | \ref flash_interface_gr
-| %Driver_I2C.h | \ref i2c_interface_gr
-| %Driver_MCI.h | \ref mci_interface_gr
-| %Driver_NAND.h | \ref nand_interface_gr
-| %Driver_SPI.h | \ref spi_interface_gr
-| %Driver_Storage.h | \ref storage_interface_gr
-| %Driver_SAI.h | \ref sai_interface_gr
-| %Driver_USART.h | \ref usart_interface_gr
-| %Driver_USB.h | \ref usb_interface_gr
-| %Driver_USBD.h | \ref usbd_interface_gr
-| %Driver_USBH.h | \ref usbh_interface_gr
-| %Driver_WiFi.h | \ref wifi_interface_gr
-
-
-\section DriverTemplates Driver Template Files
-
-Driver template files are code skeletons that provide the structure of a CMSIS-Driver. The following templates are
-available in the directory .\\CMSIS\\Driver\\DriverTemplates .
-
-| Source File | Description
-|-------------------|------------------------------------
-| %Driver_CAN.c | \ref can_interface_gr
-| %Driver_ETH_MAC.c | \ref eth_mac_interface_gr
-| %Driver_ETH_PHY.c | \ref eth_mac_interface_gr
-| %Driver_Flash.c | \ref flash_interface_gr
-| %Driver_I2C.c | \ref i2c_interface_gr
-| %Driver_MCI.c | \ref mci_interface_gr
-| %Driver_SAI.c | \ref sai_interface_gr
-| %Driver_SPI.c | \ref spi_interface_gr
-| %Driver_Storage.c | \ref storage_interface_gr
-| %Driver_USART.c | \ref usart_interface_gr
-| %Driver_USBD.c | \ref usbd_interface_gr
-| %Driver_USBH.c | \ref usbh_interface_gr
-
-
-\section DriverExamples Driver Examples
-
-The driver examples are full working CMSIS-Drivers that may be adapted to a different hardware. Examples are currently
-available for the NXP LPC1800 series and provide the implementation of a complete CMSIS-Driver. The following examples are
-available in the directory .\\CMSIS\\Pack\\Example\\CMSIS_Driver .
-
-| Source File | Header File | Description
-|-------------------|-------------------|-------------------------------
-| %EMAC_LPC18xx.c | %EMAC_LPC18xx.h | \ref eth_mac_interface_gr
-| %SSP_LPC18xx.c | %SSP_LPC18xx.h | \ref spi_interface_gr
-| %I2C_LPC18xx.c | %I2C_LPC18xx.h | \ref i2c_interface_gr
-| %I2S_LPC18xx.c | %I2S_LPC18xx.h | \ref sai_interface_gr
-| %MCI_LPC18xx.c | %MCI_LPC18xx.h | \ref mci_interface_gr
-| %USART_LPC18xx.c | %USART_LPC18xx.h | \ref usart_interface_gr
-| %USBn_LPC18xx.c | %USB_LPC18xx.h | common files for \ref usbd_interface_gr and \ref usbh_interface_gr
-| %USBDn_LPC18xx.c | none | \ref usbd_interface_gr
-| %USBHn_LPC18xx.c | none | \ref usbh_interface_gr
-
-
-These CMSIS-Drivers use additional modules for GPIO and DMA control:
-
-| Source File | Header File | Description
-|-------------------|------------------|---------------------------------------
-| %GPIO_LPC18xx.c | %GPIO_LPC18xx.h | GPIO Interface for LPC1800 series
-| %GPDMA_LPC18xx.c | none | DMA Interface for LPC1800 series
-| %SCU_LPC18xx.c | %SCU_LPC18xx.h | SCU Interface for LPC1800 series
-
-The CMSIS-Drivers for the LPC1800 device have also many configuration options that are controls using \#define statements in
-the file .\\CMSIS\\Pack\\Example\\CMSIS_Driver\\Config\\RTE_Device.h . Using this file, the I/O pin and DMA assignment
-can be set among other parameters such as USB speed and PHY interfaces.
-
-Further driver reference implementations are available in Device Family Packs (DFP) labeled with version 2.0.0 or higher.
-*/
-
-/*=======0=========1=========2=========3=========4=========5=========6=========7=========8=========9=========0=========1====*/
-/**
-\page driverValidation Driver Validation
-
-The Software Pack named ARM::CMSIS-Driver_Validation contains the following:
-
- - Source code of a CMSIS-Driver Validation Suite along with configuration file.
- - Documentation of the CMSIS-Driver Validation Suite.
- - Examples that shows the usage of the CMSIS-Driver Validation Suite on various target platforms.
-
-The CMSIS-Driver Validation Suite performs the following tests:
- - Generic Validation of API function calls
- - Validation of Configuration Parameters
- - Validation of Communication with loopback tests
- - Validation of Communication Parameters such as baudrate
- - Validation of Event functions
-
-The following CMSIS-Drivers can be tested with the current release:
- - \ref can_interface_gr : with loop back test of communication.
- - \ref eth_interface_gr : MAC and PHY with loop back test of communication.
- - \ref i2c_interface_gr : only API and setup; does not test data transfer.
- - \ref mci_interface_gr : only API and setup; does not test data transfer.
- - \ref spi_interface_gr : with loop back test of communication.
- - \ref usart_interface_gr : with loop back test of communication.
- - \ref usbd_interface_gr : only API and setup; does not test data transfer.
- - \ref usbh_interface_gr : only API and setup; does not test data transfer.
- - \ref wifi_interface_gr : extensive tests for WiFi Driver.
-
-The Driver Validation output can be printed to a console or saved in an XML file, via standard output (usually ITM).
-
-\section test_output Sample Test Output
-\verbatim
-CMSIS-Driver USART Test Report Dec 6 2019 11:44:30
-
-TEST 01: USART_GetCapabilities PASSED
-TEST 02: USART_Initialization PASSED
-TEST 03: USART_PowerControl
- DV_USART.c (301): [WARNING] Low power is not supported
- PASSED
-TEST 04: USART_Config_PolarityPhase PASSED
-TEST 05: USART_Config_DataBits
- DV_USART.c (387): [WARNING] Data Bits = 9 are not supported
- PASSED
-TEST 06: USART_Config_StopBits
- DV_USART.c (425): [WARNING] Stop Bits = 1.5 are not supported
- DV_USART.c (429): [WARNING] Stop Bits = 0.5 are not supported
- PASSED
-TEST 07: USART_Config_Parity PASSED
-TEST 08: USART_Config_Baudrate PASSED
-TEST 09: USART_Config_CommonParams PASSED
-TEST 10: USART_Send PASSED
-TEST 11: USART_AsynchronousReceive PASSED
-TEST 12: USART_Loopback_CheckBaudrate PASSED
-TEST 13: USART_Loopback_Transfer PASSED
-TEST 14: USART_CheckInvalidInit PASSED
-
-Test Summary: 14 Tests, 14 Passed, 0 Failed.
-Test Result: PASSED
-\endverbatim
-
-\section loop_back_setup Setup for Loop Back Communication
-
-To perform loop back communication tests it is required to connect the input and the output of the peripherals as shown in this table:
-
-Peripheral | Loop Back Configuration
-:----------------|:----------------------------
-Ethernet | Connect TX+ (Pin 1) with RX+ (Pin 3), TX- (Pin 2) with RX- (Pin 6)
-SPI | Connect MISO to MOSI
-USART | Connect TX with RX
-
-The following picture shows the necessary external loop back connections for the Keil MCBSTM32F400 evaluation board:
- - SPI: PB14 (SPI2_MISO) and PB15 (SPI2_MOSI)
- - USART: PB6 (USART1_TX) and PB7 (USART1_RX)
- - Ethernet: Pin 1 (TX+) and Pin 3 (RX+), Pin 2 (TX-) and Pin 6 (RX-)
-
-\image html image006.png "Connections for Loop Back Communication Tests on Keil MCBSTM32F400"
-
-
-*/
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/I2C_Demo.c b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/I2C_Demo.c
deleted file mode 100644
index 2ee6313..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/I2C_Demo.c
+++ /dev/null
@@ -1,132 +0,0 @@
-#include "Driver_I2C.h"
-
-#define EEPROM_I2C_ADDR 0x51 /* EEPROM I2C address */
-
-/* I2C driver instance */
-extern ARM_DRIVER_I2C Driver_I2C0;
-static ARM_DRIVER_I2C *I2Cdrv = &Driver_I2C0;
-
-static volatile uint32_t I2C_Event;
-
-/* I2C Signal Event function callback */
-void I2C_SignalEvent (uint32_t event) {
-
- /* Save received events */
- I2C_Event |= event;
-
- /* Optionally, user can define specific actions for an event */
-
- if (event & ARM_I2C_EVENT_TRANSFER_INCOMPLETE) {
- /* Less data was transferred than requested */
- }
-
- if (event & ARM_I2C_EVENT_TRANSFER_DONE) {
- /* Transfer or receive is finished */
- }
-
- if (event & ARM_I2C_EVENT_ADDRESS_NACK) {
- /* Slave address was not acknowledged */
- }
-
- if (event & ARM_I2C_EVENT_ARBITRATION_LOST) {
- /* Master lost bus arbitration */
- }
-
- if (event & ARM_I2C_EVENT_BUS_ERROR) {
- /* Invalid start/stop position detected */
- }
-
- if (event & ARM_I2C_EVENT_BUS_CLEAR) {
- /* Bus clear operation completed */
- }
-
- if (event & ARM_I2C_EVENT_GENERAL_CALL) {
- /* Slave was addressed with a general call address */
- }
-
- if (event & ARM_I2C_EVENT_SLAVE_RECEIVE) {
- /* Slave addressed as receiver but SlaveReceive operation is not started */
- }
-
- if (event & ARM_I2C_EVENT_SLAVE_TRANSMIT) {
- /* Slave addressed as transmitter but SlaveTransmit operation is not started */
- }
-}
-
-/* Read I2C connected EEPROM (event driven example) */
-int32_t EEPROM_Read_Event (uint16_t addr, uint8_t *buf, uint32_t len) {
- uint8_t a[2];
-
- a[0] = (uint8_t)(addr >> 8);
- a[1] = (uint8_t)(addr & 0xFF);
-
- /* Clear event flags before new transfer */
- I2C_Event = 0U;
-
- I2Cdrv->MasterTransmit (EEPROM_I2C_ADDR, a, 2, true);
-
- /* Wait until transfer completed */
- while ((I2C_Event & ARM_I2C_EVENT_TRANSFER_DONE) == 0U);
- /* Check if all data transferred */
- if ((I2C_Event & ARM_I2C_EVENT_TRANSFER_INCOMPLETE) != 0U) return -1;
-
- /* Clear event flags before new transfer */
- I2C_Event = 0U;
-
- I2Cdrv->MasterReceive (EEPROM_I2C_ADDR, buf, len, false);
-
- /* Wait until transfer completed */
- while ((I2C_Event & ARM_I2C_EVENT_TRANSFER_DONE) == 0U);
- /* Check if all data transferred */
- if ((I2C_Event & ARM_I2C_EVENT_TRANSFER_INCOMPLETE) != 0U) return -1;
-
- return 0;
-}
-
-/* Read I2C connected EEPROM (pooling example) */
-int32_t EEPROM_Read_Pool (uint16_t addr, uint8_t *buf, uint32_t len) {
- uint8_t a[2];
-
- a[0] = (uint8_t)(addr >> 8);
- a[1] = (uint8_t)(addr & 0xFF);
-
- I2Cdrv->MasterTransmit (EEPROM_I2C_ADDR, a, 2, true);
-
- /* Wait until transfer completed */
- while (I2Cdrv->GetStatus().busy);
- /* Check if all data transferred */
- if (I2Cdrv->GetDataCount () != len) return -1;
-
- I2Cdrv->MasterReceive (EEPROM_I2C_ADDR, buf, len, false);
-
- /* Wait until transfer completed */
- while (I2Cdrv->GetStatus().busy);
- /* Check if all data transferred */
- if (I2Cdrv->GetDataCount () != len) return -1;
-
- return 0;
-}
-
-/* Initialize I2C connected EEPROM */
-int32_t EEPROM_Initialize (bool pooling) {
- int32_t status;
- uint8_t val;
-
- if (pooling == true) {
- I2Cdrv->Initialize (NULL);
- } else {
- I2Cdrv->Initialize (I2C_SignalEvent);
- }
- I2Cdrv->PowerControl (ARM_POWER_FULL);
- I2Cdrv->Control (ARM_I2C_BUS_SPEED, ARM_I2C_BUS_SPEED_FAST);
- I2Cdrv->Control (ARM_I2C_BUS_CLEAR, 0);
-
- /* Check if EEPROM can be accessed */
- if (pooling == true) {
- status = EEPROM_Read_Pool (0x00, &val, 1);
- } else {
- status = EEPROM_Read_Event (0x00, &val, 1);
- }
-
- return (status);
-}
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/I2C_SlaveDemo.c b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/I2C_SlaveDemo.c
deleted file mode 100644
index 89cd5ba..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/I2C_SlaveDemo.c
+++ /dev/null
@@ -1,41 +0,0 @@
-#include "Driver_I2C.h"
-
-/* I2C driver instance */
-extern ARM_DRIVER_I2C Driver_I2C0;
-static ARM_DRIVER_I2C *I2Cdrv = &Driver_I2C0;
-
-static volatile uint32_t I2C_Event;
-
-/* I2C Signal Event function callback */
-static void I2C_SignalEvent (uint32_t event) {
- I2C_Event |= event;
-}
-
-int main (void) {
- uint8_t cnt = 0;
-
- /* Initialize I2C peripheral */
- I2Cdrv->Initialize(I2C_SignalEvent);
-
- /* Power-on I2C peripheral */
- I2Cdrv->PowerControl(ARM_POWER_FULL);
-
- /* Configure I2C bus */
- I2Cdrv->Control(ARM_I2C_OWN_ADDRESS, 0x78);
-
- I2C_Event = 0;
-
- while (1) {
- /* Receive chunk */
- I2Cdrv->SlaveReceive(&cnt, 1);
- while ((I2C_Event & ARM_I2C_EVENT_TRANSFER_DONE) == 0);
- /* Clear transfer done flag */
- I2C_Event &= ~ARM_I2C_EVENT_TRANSFER_DONE;
-
- /* Transmit chunk back */
- I2Cdrv->SlaveTransmit(&cnt, 1);
- while ((I2C_Event & ARM_I2C_EVENT_TRANSFER_DONE) == 0);
- /* Clear transfer done flag */
- I2C_Event &= ~ARM_I2C_EVENT_TRANSFER_DONE;
- }
-}
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/MCI_Demo.c b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/MCI_Demo.c
deleted file mode 100644
index 74835b5..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/MCI_Demo.c
+++ /dev/null
@@ -1,253 +0,0 @@
-
-#include "Driver_MCI.h"
-
-
-/* Usage example: ARM_MCI_Initialize ----------------------------------------*/
-
-// ARM_MCI_SignalEvent callback function prototype
-void MCI_SignalEvent_Callback (uint32_t event);
-
-void init_driver (ARM_DRIVER_MCI *drv) {
- int32_t status;
-
- status = drv->Initialize (&MCI_SignalEvent_Callback);
-
- if (status != ARM_DRIVER_OK) {
- // Initialization and event callback registration failed
- }
-}
-
-/* Usage example: ARM_MCI_Uninitialize --------------------------------------*/
-
-void uninit_driver (ARM_DRIVER_MCI *drv) {
- int32_t status;
-
- status = drv->Uninitialize ();
-
- if (status == ARM_DRIVER_OK) {
- // Driver successfully uninitialized
- }
-}
-
-/* Usage example: ARM_MCI_PowerControl --------------------------------------*/
-
-void control_driver_power (ARM_DRIVER_MCI *drv, bool enable) {
- int32_t status;
-
- if (enable == true) {
- status = drv->PowerControl (ARM_POWER_FULL);
- }
- else {
- status = drv->PowerControl (ARM_POWER_OFF);
- }
-
- if (status == ARM_DRIVER_OK) {
- // Driver power enabled/disabled
- }
-}
-
-/* Usage example: ARM_MCI_CardPower -----------------------------------------*/
-
-ARM_MCI_CAPABILITIES drv_capabilities;
-
-void set_card_vdd_3v3 (ARM_DRIVER_MCI *drv) {
- int32_t status;
-
- if (drv_capabilities.vdd == 1U) {
- // Power switching to 3.3V supported
- status = drv->CardPower (ARM_MCI_POWER_VDD_3V3);
-
- if (status == ARM_DRIVER_OK) {
- // Card power set to 3.3V
- }
- }
-}
-
-/* Usage example: ARM_MCI_ReadCD --------------------------------------------*/
-
-void read_card_detect_state (ARM_DRIVER_MCI *drv) {
- int32_t status;
-
- status = drv->ReadCD();
-
- if (status == 1) {
- // Memory card is detected
- }
- else {
- if (status == 0) {
- // Memory card is not detected
- }
- else {
- // Error reading card detect pin state
- }
- }
-}
-
-/* Usage example: ARM_MCI_ReadWP --------------------------------------------*/
-
-void read_write_protect_state (ARM_DRIVER_MCI *drv) {
- int32_t status;
-
- status = drv->ReadWP();
-
- if (status == 1) {
- // Memory card write protection is enabled
- }
- else {
- if (status == 0) {
- // Memory card write protection is disabled
- }
- else {
- // Error reading write protect pin state
- }
- }
-}
-
-/* Usage example: ARM_MCI_SendCommand ---------------------------------------*/
-
-volatile uint32_t MCI_Events;
-
-void MCI_SignalEvent_Callback (uint32_t event) {
- // Save current event
- MCI_Events |= event;
-}
-
-void send_CMD0 (ARM_DRIVER_MCI *drv) {
- int32_t status;
- uint32_t cmd;
-
- MCI_Events = 0U; //Clear MCI driver event flags
- cmd = 0U; // Set GO_IDLE_STATE command code
-
- status = drv->SendCommand (cmd, 0U, ARM_MCI_CARD_INITIALIZE | ARM_MCI_RESPONSE_NONE, NULL);
-
- if (status == ARM_DRIVER_OK) {
- /* Wait for event */
- while ((MCI_Events & ARM_MCI_EVENT_COMMAND_COMPLETE) == 0U);
- // Command was successfully sent to memory card
- // ..
- }
- else {
- // Error
- }
-}
-
-/* Usage example: ARM_MCI_SetupTransfer -------------------------------------*/
-
-volatile uint32_t MCI_Events;
-
-void MCI_SignalEvent_Callback (uint32_t event) {
- MCI_Events |= event; // Save current event
-}
-
-void read_sector (ARM_DRIVER_MCI *drv, uint8_t *buf, uint32_t sz) {
- int32_t status;
- uint32_t cmd, arg;
- uint32_t resp;
-
- if (sz < 512U) {
- // Invalid buffer size, sector consists of 512 bytes
- //...
- }
-
- status = drv->SetupTransfer (buf, 1U, 512U, ARM_MCI_TRANSFER_READ | ARM_MCI_TRANSFER_BLOCK);
-
- if (status == ARM_DRIVER_OK) {
- MCI_Events = 0U; //Clear MCI driver event flags
-
- cmd = 17U; // Set READ_SINGLE_BLOCK command
- arg = 0U; // Set sector number
-
- status = drv->SendCommand (cmd, arg, ARM_MCI_RESPONSE_SHORT | ARM_MCI_RESPONSE_CRC | ARM_MCI_TRANSFER_DATA, &resp);
-
- if (status == ARM_DRIVER_OK) {
- /* Wait for event */
- while ((MCI_Events & ARM_MCI_EVENT_COMMAND_COMPLETE) == 0U);
- // Command was successfully sent to memory card
- if ((resp & 0x03U) == 0U) {
- // Sector number is valid, wait until data transfer completes
- while ((MCI_Events & ARM_MCI_EVENT_TRANSFER_COMPLETE) == 0U);
- // Data was successfully read from memory card
- // ...
- }
- }
- }
-}
-
-/* Usage example: ARM_MCI_AbortTransfer -------------------------------------*/
-
-void abort_data_transfer (ARM_DRIVER_MCI *drv) {
- ARM_MCI_STATUS drv_status;
-
- drv_status = drv->GetStatus();
-
- if (drv_status.transfer_active == 1U) {
- // Data transfer is active, abort the transfer
- if (drv->AbortTransfer() == ARM_DRIVER_OK) {
- // Transfer aborted
- // ...
- }
- }
-}
-
-/* Usage example: ARM_MCI_GetStatus -----------------------------------------*/
-
-void check_transfer_status (ARM_DRIVER_MCI *drv) {
- ARM_MCI_STATUS drv_status;
-
- drv_status = drv->GetStatus();
-
- if (drv_status.transfer_active == 1U) {
- // Data transfer is active
- }
-
- if (drv_status.transfer_timeout == 1U) {
- // Data not received, timeout expired
- }
-
- if (drv_status.transfer_error == 1U) {
- // Data transfer ended with error
- }
-}
-
-/* Usage example: ARM_MCI_SignalEvent ---------------------------------------*/
-
-void MCI_SignalEvent_Callback (uint32_t event) {
- if ((event & ARM_MCI_EVENT_CARD_INSERTED) != 0U) {
- // Memory card was inserted into socket
- }
- if ((event & ARM_MCI_EVENT_CARD_REMOVED) != 0U) {
- // Memory card was removed from socket
- }
-
- if ((event & ARM_MCI_EVENT_COMMAND_COMPLETE) != 0U) {
- // Command was successfully sent to memory card
- }
- if ((event & ARM_MCI_EVENT_COMMAND_TIMEOUT) != 0U) {
- // Command response was not received in time
- }
- if ((event & ARM_MCI_EVENT_COMMAND_ERROR) != 0U) {
- // Command response was invalid
- }
-
- if ((event & ARM_MCI_EVENT_TRANSFER_COMPLETE) != 0U) {
- // Data successfully transferred from/to memory card
- }
- if ((event & ARM_MCI_EVENT_TRANSFER_TIMEOUT) != 0U) {
- // Data not transferred from/to memory card, timeout expired
- }
- if ((event & ARM_MCI_EVENT_TRANSFER_ERROR) != 0U) {
- // Data transfer ended with errors
- }
-
- if ((event & ARM_MCI_EVENT_SDIO_INTERRUPT) != 0U) {
- // SD I/O card sent interrupt request
- }
-
- if ((event & ARM_MCI_EVENT_CCS) != 0U) {
- // CE-ATA command completion signal received
- }
- if ((event & ARM_MCI_EVENT_CCS_TIMEOUT) != 0U) {
- // CE-ATA command completion signal wait timeout expired
- }
-}
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/NAND_Demo.c b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/NAND_Demo.c
deleted file mode 100644
index 79dc354..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/NAND_Demo.c
+++ /dev/null
@@ -1,165 +0,0 @@
-#include "Driver_NAND.h"
-
-/* ONFI commands */
-#define ONFI_CMD_READ_1ST 0x00 ///< Read 1st Cycle
-#define ONFI_CMD_PROGRAM_2ND 0x10 ///< Page Program 2nd Cycle
-#define ONFI_CMD_READ_2ND 0x30 ///< Read 2nd Cycle
-#define ONFI_CMD_PROGRAM_1ST 0x80 ///< Page Program 1st Cycle
-#define ONFI_CMD_RESET 0xFF ///< Reset Command
-
-/* NAND Signal Event callback function */
-volatile uint32_t NAND_Events;
-void NAND_SignalEventCallback (uint32_t dev_num, uint32_t event) {
- if (dev_num == 0) {
- NAND_Events |= event;
- }
- else {
- // ..
- }
-}
-
-/* NAND device Power ON */
-void PowerOn (ARM_DRIVER_NAND *drv, uint32_t dev_num) {
- ARM_NAND_CAPABILITIES capabilities;
-
- // Query drivers capabilities
- capabilities = drv->GetCapabilities();
-
- // Initialize NAND device
- drv->Initialize (NAND_SignalEventCallback);
-
- // Power-on NAND driver
- drv->PowerControl (ARM_POWER_FULL);
-
- // Turn ON device power
- uint32_t volt = 0U;
-
- if (capabilities.vcc) { volt |= ARM_NAND_POWER_VCC_3V3; }
- if (capabilities.vcc_1v8) { volt |= ARM_NAND_POWER_VCC_1V8; }
- if (capabilities.vccq) { volt |= ARM_NAND_POWER_VCCQ_3V3; }
- if (capabilities.vccq_1v8) { volt |= ARM_NAND_POWER_VCCQ_1V8; }
-
- if (volt != 0U) {
- drv->DevicePower (volt);
- }
-
- // Setting bus mode
- drv->Control (0U, ARM_NAND_BUS_MODE, ARM_NAND_BUS_SDR);
-
- // Setting bus data width
- drv->Control (0U, ARM_NAND_BUS_DATA_WIDTH, ARM_NAND_BUS_DATA_WIDTH_8);
-
- // Enable chip manually if needed
- if (capabilities.ce_manual) {
- drv->ChipEnable (dev_num, true);
- }
-
- // Send ONFI Reset command */
- drv->SendCommand (dev_num, ONFI_CMD_RESET);
-}
-
-/* NAND device Power OFF */
-void PowerOff (ARM_DRIVER_NAND *drv, uint32_t dev_num) {
- ARM_NAND_CAPABILITIES capabilities;
-
- // Query drivers capabilities
- capabilities = drv->GetCapabilities();
-
- // Disable chip manually if needed
- if (capabilities.ce_manual) {
- drv->ChipEnable (0U, false);
- }
-
- // Switch OFF gracefully
- uint32_t volt = 0U;
-
- if (capabilities.vcc) { volt |= ARM_NAND_POWER_VCC_OFF; }
- if (capabilities.vccq) { volt |= ARM_NAND_POWER_VCCQ_OFF; }
- if (volt) {
- drv->DevicePower (volt);
- }
- drv->PowerControl (ARM_POWER_OFF);
- drv->Uninitialize ();
-}
-
-/* Read NAND page. */
-void ReadPage (ARM_DRIVER_NAND *drv, uint32_t row, uint8_t *data, uint32_t cnt) {
- uint32_t dev_num = 0; // Device number
- uint32_t mode;
-
- // Send Read 1st command
- drv->SendCommand (dev_num, ONFI_CMD_READ_1ST);
-
- // Send address (column: 2 cycles, row: 3 cycles)
- drv->SendAddress (dev_num, 0x00);
- drv->SendAddress (dev_num, 0x00);
- drv->SendAddress (dev_num, (uint8_t)(row));
- drv->SendAddress (dev_num, (uint8_t)(row >> 8));
- drv->SendAddress (dev_num, (uint8_t)(row >> 16));
-
- // Send Read 2nd command
- drv->SendCommand (dev_num, ONFI_CMD_READ_2ND);
-
- // Wait until device ready
- while (drv->GetDeviceBusy(dev_num) == 1) { ; }
-
- // Use ECC algorithm number 2, ECC0 (ECC over main+spare)
- mode = ARM_NAND_ECC(2) | ARM_NAND_ECC0;
-
- // Transfer data from the NAND chip
- if (drv->ReadData (dev_num, data, cnt, mode | ARM_NAND_DRIVER_DONE_EVENT) != cnt) {
- // Wait until driver done event received
- while ((NAND_Events & ARM_NAND_DRIVER_DONE_EVENT) == 0) { ; }
- // Read page completed
-
- if ((NAND_Events & ARM_NAND_EVENT_ECC_ERROR) != 0) {
- // ECC correction failed
- }
- }
-}
-
-/* Write NAND page (ExecuteSequence interface). */
-void WritePage_Seq (ARM_DRIVER_NAND *drv, uint32_t row, const uint8_t *data, uint32_t cnt) {
- uint32_t dev_num = 0; // Device number
- uint32_t cmd;
- uint32_t code;
- uint32_t seq;
-
- // Prepare commands to send
- cmd = ONFI_CMD_PROGRAM_1ST | (ONFI_CMD_PROGRAM_2ND << 8);
-
- // Construct sequence code:
- // - Send command 1
- // - Send 2 cycles of column address and 3 cycles of row address
- // - Write data from memory to device
- // - Send command 2
- code = ARM_NAND_CODE_SEND_CMD1 |
- ARM_NAND_CODE_SEND_ADDR_COL1 |
- ARM_NAND_CODE_SEND_ADDR_COL2 |
- ARM_NAND_CODE_SEND_ADDR_ROW1 |
- ARM_NAND_CODE_SEND_ADDR_ROW2 |
- ARM_NAND_CODE_SEND_ADDR_ROW3 |
- ARM_NAND_CODE_WRITE_DATA |
- ARM_NAND_CODE_SEND_CMD2 ;
-
- // - Use ECC algorithm number 2, ECC0 (ECC over main+spare)
- code |= ARM_NAND_ECC(2) | ARM_NAND_ECC0;
-
- // Number of iterations in a sequence
- seq = 1;
-
- drv->ExecuteSequence (dev_num, // Device number
- code, // Sequence code
- cmd, // Command(s)
- 0, // Column address
- row, // Row address
- (void *)data, // Data buffer
- cnt, // Number of data items (per iteration)
- NULL, // Device status will not be read
- &seq); // Number of iterations
-
- // Wait until done
- while (drv->GetStatus(dev_num).busy != 0) { ; }
-
- // Page write completed
-}
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/SPI_Demo.c b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/SPI_Demo.c
deleted file mode 100644
index 275e5ac..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/SPI_Demo.c
+++ /dev/null
@@ -1,98 +0,0 @@
-#include "Driver_SPI.h"
-#include "cmsis_os.h" // ARM::CMSIS:RTOS:Keil RTX
-
-
-void mySPI_Thread(void const *argument);
-osThreadId tid_mySPI_Thread;
-
-
-/* SPI Driver */
-extern ARM_DRIVER_SPI Driver_SPI0;
-
-
-void mySPI_callback(uint32_t event)
-{
- switch (event)
- {
- case ARM_SPI_EVENT_TRANSFER_COMPLETE:
- /* Success: Wakeup Thread */
- osSignalSet(tid_mySPI_Thread, 0x01);
- break;
- case ARM_SPI_EVENT_DATA_LOST:
- /* Occurs in slave mode when data is requested/sent by master
- but send/receive/transfer operation has not been started
- and indicates that data is lost. Occurs also in master mode
- when driver cannot transfer data fast enough. */
- __breakpoint(0); /* Error: Call debugger or replace with custom error handling */
- break;
- case ARM_SPI_EVENT_MODE_FAULT:
- /* Occurs in master mode when Slave Select is deactivated and
- indicates Master Mode Fault. */
- __breakpoint(0); /* Error: Call debugger or replace with custom error handling */
- break;
- }
-}
-
-/* Test data buffers */
-const uint8_t testdata_out[8] = { 0, 1, 2, 3, 4, 5, 6, 7 };
-uint8_t testdata_in [8];
-
-void mySPI_Thread(void const* arg)
-{
- ARM_DRIVER_SPI* SPIdrv = &Driver_SPI0;
- osEvent evt;
-
-#ifdef DEBUG
- ARM_DRIVER_VERSION version;
- ARM_SPI_CAPABILITIES drv_capabilities;
-
- version = SPIdrv->GetVersion();
- if (version.api < 0x200) /* requires at minimum API version 2.00 or higher */
- { /* error handling */
- return;
- }
-
- drv_capabilities = SPIdrv->GetCapabilities();
- if (drv_capabilities.event_mode_fault == 0)
- { /* error handling */
- return;
- }
-#endif
-
- /* Initialize the SPI driver */
- SPIdrv->Initialize(mySPI_callback);
- /* Power up the SPI peripheral */
- SPIdrv->PowerControl(ARM_POWER_FULL);
- /* Configure the SPI to Master, 8-bit mode @10000 kBits/sec */
- SPIdrv->Control(ARM_SPI_MODE_MASTER | ARM_SPI_CPOL1_CPHA1 | ARM_SPI_MSB_LSB | ARM_SPI_SS_MASTER_SW | ARM_SPI_DATA_BITS(8), 10000000);
-
- /* SS line = INACTIVE = HIGH */
- SPIdrv->Control(ARM_SPI_CONTROL_SS, ARM_SPI_SS_INACTIVE);
-
- /* thread loop */
- while (1)
- {
- /* SS line = ACTIVE = LOW */
- SPIdrv->Control(ARM_SPI_CONTROL_SS, ARM_SPI_SS_ACTIVE);
- /* Transmit some data */
- SPIdrv->Send(testdata_out, sizeof(testdata_out));
- /* Wait for completion */
- evt = osSignalWait(0x01, 100);
- if (evt.status == osEventTimeout) {
- __breakpoint(0); /* Timeout error: Call debugger */
- }
- /* SS line = INACTIVE = HIGH */
- SPIdrv->Control(ARM_SPI_CONTROL_SS, ARM_SPI_SS_INACTIVE);
-
- /* SS line = ACTIVE = LOW */
- SPIdrv->Control(ARM_SPI_CONTROL_SS, ARM_SPI_SS_ACTIVE);
- /* Receive 8 bytes of reply */
- SPIdrv->Receive(testdata_in, 8);
- evt = osSignalWait(0x01, 100);
- if (evt.status == osEventTimeout) {
- __breakpoint(0); /* Timeout error: Call debugger */
- }
- /* SS line = INACTIVE = HIGH */
- SPIdrv->Control(ARM_SPI_CONTROL_SS, ARM_SPI_SS_INACTIVE);
- }
-}
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/USART_Demo.c b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/USART_Demo.c
deleted file mode 100644
index 57b95c3..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/USART_Demo.c
+++ /dev/null
@@ -1,87 +0,0 @@
-#include "Driver_USART.h"
-#include "cmsis_os.h" /* ARM::CMSIS:RTOS:Keil RTX */
-#include
-#include
-
-void myUART_Thread(void const *argument);
-osThreadId tid_myUART_Thread;
-
-/* USART Driver */
-extern ARM_DRIVER_USART Driver_USART3;
-
-
-void myUSART_callback(uint32_t event)
-{
- uint32_t mask;
-
- mask = ARM_USART_EVENT_RECEIVE_COMPLETE |
- ARM_USART_EVENT_TRANSFER_COMPLETE |
- ARM_USART_EVENT_SEND_COMPLETE |
- ARM_USART_EVENT_TX_COMPLETE ;
-
- if (event & mask) {
- /* Success: Wakeup Thread */
- osSignalSet(tid_myUART_Thread, 0x01);
- }
-
- if (event & ARM_USART_EVENT_RX_TIMEOUT) {
- __breakpoint(0); /* Error: Call debugger or replace with custom error handling */
- }
-
- if (event & (ARM_USART_EVENT_RX_OVERFLOW | ARM_USART_EVENT_TX_UNDERFLOW)) {
- __breakpoint(0); /* Error: Call debugger or replace with custom error handling */
- }
-}
-
-
-/* CMSIS-RTOS Thread - UART command thread */
-void myUART_Thread(const void* args)
-{
- static ARM_DRIVER_USART * USARTdrv = &Driver_USART3;
- ARM_DRIVER_VERSION version;
- ARM_USART_CAPABILITIES drv_capabilities;
- char cmd;
-
- #ifdef DEBUG
- version = USARTdrv->GetVersion();
- if (version.api < 0x200) /* requires at minimum API version 2.00 or higher */
- { /* error handling */
- return;
- }
- drv_capabilities = USARTdrv->GetCapabilities();
- if (drv_capabilities.event_tx_complete == 0)
- { /* error handling */
- return;
- }
- #endif
-
- /*Initialize the USART driver */
- USARTdrv->Initialize(myUSART_callback);
- /*Power up the USART peripheral */
- USARTdrv->PowerControl(ARM_POWER_FULL);
- /*Configure the USART to 4800 Bits/sec */
- USARTdrv->Control(ARM_USART_MODE_ASYNCHRONOUS |
- ARM_USART_DATA_BITS_8 |
- ARM_USART_PARITY_NONE |
- ARM_USART_STOP_BITS_1 |
- ARM_USART_FLOW_CONTROL_NONE, 4800);
-
- /* Enable Receiver and Transmitter lines */
- USARTdrv->Control (ARM_USART_CONTROL_TX, 1);
- USARTdrv->Control (ARM_USART_CONTROL_RX, 1);
-
- USARTdrv->Send("\nPress Enter to receive a message", 34);
- osSignalWait(0x01, osWaitForever);
-
- while (1)
- {
- USARTdrv->Receive(&cmd, 1); /* Get byte from UART */
- osSignalWait(0x01, osWaitForever);
- if (cmd == 13) /* CR, send greeting */
- {
- USARTdrv->Send("\nHello World!", 12);
- osSignalWait(0x01, osWaitForever);
- }
-
- }
-}
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/VIO.txt b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/VIO.txt
deleted file mode 100644
index 19a21ab..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/VIO.txt
+++ /dev/null
@@ -1,515 +0,0 @@
-/**
-\defgroup vio_interface_gr VIO
-\brief API for Virtual I/O (VIO) (%cmsis_vio.h)
-\details
-
-The VIO software component is a virtual I/O abstraction for peripherals that are typically used in example projects. It
-enables developers to move from an evaluation kit to custom hardware and helps to scale project examples at large to many
-development boards:
-
-\image html vioRationale.png "Virtual I/O provides a generic API for examples and testing"
-
-VIO API
-
-The following header file defines the Application Programming Interface (API) for VIO:
- - \b %cmsis_vio.h : API for VIO
-
-VIO User Code Templates
-
-The VIO software component contains two user code templates with different purposes:
- - VIO:Custom: This file is an empty stub with all functions that are defined in the header file that can be used to
- implement the VIO layer for the hardware that is used in the application.
- - VIO:Virtual: This file uses a fixed memory location to emulate the VIO functionality and can be used off-the-shelf.
-
-VIO Memory Location Structure
-
-For testing purposes, it is required to have fixed memory locations that are used to read/store values. In the VIO:Virtual
-template file (\b %vio.c), an exemplary implementation is shown:
-
-\code
-// Input, output variables
-__USED uint32_t vioSignalIn; // Memory for incoming signal
-__USED uint32_t vioSignalOut; // Memory for outgoing signal
-__USED char vioPrintMem[VIO_PRINTMEM_NUM][VIO_PRINT_MAX_SIZE]; // Memory for the last value for each level
-__USED int32_t vioValue [VIO_VALUE_NUM]; // Memory for value used in vioGetValue/vioSetValue
-__USED vioValueXYZ_t vioValueXYZ[VIO_VALUEXYZ_NUM]; // Memory for XYZ value for 3-D vector
-__USED vioAddrIPv4_t vioAddrIPv4[VIO_IPV4_ADDRESS_NUM]; // Memory for IPv4 address value used in vioSetIPv4/vioGetIPv4
-__USED vioAddrIPv6_t vioAddrIPv6[VIO_IPV6_ADDRESS_NUM]; // Memory for IPv6 address value used in vioSetIPv6/vioGetIPv6
-\endcode
-
-Use these memory locations to monitor or set the variables as required in the application.
-
-Two defines are available that help to disconnect the actual peripherals and enable virtual I/Os: \c CMSIS_VIN and
-\c CMSIS_VOUT. They help to write code that can be used in testing environments without real hardware access. The following
-implementation example shows such code:
-
-Code Example (VIO Implementation)
-\code
-// Initialize test input, output.
-void vioInit (void) {
- uint32_t i;
-#if !defined CMSIS_VIN
-// Add user variables here:
-
-#endif
-#if !defined CMSIS_VOUT
-// Add user variables here:
-
-#endif
-
- vioSignalIn = 0U;
- vioSignalOut = 0U;
-
- memset (vioPrintMem, 0, sizeof(vioPrintMem));
- memset (vioValue, 0, sizeof(vioValue));
- memset (vioValueXYZ, 0, sizeof(vioValueXYZ));
- memset (vioAddrIPv4, 0, sizeof(vioAddrIPv4));
- memset (vioAddrIPv6, 0, sizeof(vioAddrIPv6));
-
-#if !defined CMSIS_VOUT
-// Add user code here:
-//
-
- BSP_LED_Init(LED_BLUE);
- BSP_LED_Init(LED_RED);
- BSP_LED_Init(LED_GREEN);
-//
-#endif
-
-#if !defined CMSIS_VIN
-// Add user code here:
-//
-
- BSP_PB_Init(BUTTON_USER, BUTTON_MODE_GPIO);
-//
-#endif
-
- return;
-}
-\endcode
-
-Memory display in IDEs
-
-Arm Keil MDK uses the provided SCVD file to display the VIO signals in Component Viewer:
-
-\image html vioComponentViewer.png
-
-@{
-*/
-
-/**
-\defgroup vioDefines_gr Defines and Structs
-\ingroup vio_interface_gr
-\brief Documents the defines and structs of the VIO API.
-\details
-@{
- Test.
-*/
-
-/**
-\defgroup vioSignals_gr Signals
-\ingroup vioDefines_gr
-\brief Signal related defines.
-\details
-@{
-\def vioLED0
-\def vioLED1
-\def vioLED2
-\def vioLED3
-\def vioLED4
-\def vioLED5
-\def vioLED6
-\def vioLED7
-\def vioLEDon
-\def vioLEDoff
-\def vioBUTTON0
-\def vioBUTTON1
-\def vioBUTTON2
-\def vioBUTTON3
-\def vioJOYup
-\def vioJOYdown
-\def vioJOYleft
-\def vioJOYright
-\def vioJOYselect
-\def vioJOYall
-@}
-*/
-
-/**
-\defgroup vioValues_gr Values
-\ingroup vioDefines_gr
-\brief Value related defines.
-\details
-@{
-\def vioAIN0
-\def vioAIN1
-\def vioAIN2
-\def vioAIN3
-\def vioAOUT0
-/**
-\struct vioValueXYZ_t
-\details
-Structure holding three-dimensional values for gyroscopes, accelerometers, etc.
-
-Parameter for:
- - \ref vioGetXYZ
- - \ref vioSetXYZ
-***************************************************************************************************************************/
-@}
-*/
-
-/**
-\defgroup vioIDs_gr IDs
-\ingroup vioDefines_gr
-\brief ID related defines.
-\details
-@{
-\def vioAIN0
-\def vioAIN1
-\def vioAIN2
-\def vioAIN3
-\def vioAOUT0
-\def vioMotionGyro
-\def vioMotionAccelero
-\def vioMotionMagneto
-@}
-*/
-
-/**
-\defgroup vioPrintLevels_gr Print Levels
-\ingroup vioDefines_gr
-\brief Print level related defines.
-\details
-@{
-\def vioLevelNone
-\def vioLevelHeading
-\def vioLevelMessage
-\def vioLevelError
-@}
-*/
-
-/**
-\defgroup vioIPAddr_gr IP Addresses
-\ingroup vioDefines_gr
-\brief IP address related structs.
-\details
-@{
-\struct vioAddrIPv4_t
-\details
-Structure holding IPv4 addresses.
-
-Parameter for:
- - \ref vioGetIPv4
- - \ref vioSetIPv4
-
-\struct vioAddrIPv6_t
-\details
-Structure holding IPv6 addresses.
-
-Parameter for:
- - \ref vioGetIPv6
- - \ref vioSetIPv6
-@}
-*/
-
-/**
-@}
-*/
-// end group vioDefines_gr
-
-
-
-void vioInit (void) {};
-/**
-\fn void vioInit (void)
-\details
-The function \b vioInit initializes the VIO interface. Use it to initialize any connected hardware that is used to
-map VIO signals.
-
-\b Code \b Example:
-\code
-#include "cmsis_vio.h" // ::CMSIS Driver:VIO
-
-int main (void) {
-
- // System Initialization
- SystemCoreClockUpdate();
- vioInit();
- // ...
-
-}
-\endcode
-***************************************************************************************************************************/
-
-int32_t vioPrint (uint32_t level, const char *format, ...) {
- return (0);
-};
-/**
-\fn int32_t vioPrint (uint32_t level, const char *format, ...)
-\details
-The function \b vioPrint prints a formatted string to a test terminal. Formatting of the output follows the rules of
-standard C language printf().
-
-Refer to \ref vioPrintLevels_gr for information about the possible \a levels.
-
-\b Code \b Example:
-\code
-#include "cmsis_vio.h" // ::CMSIS Driver:VIO
-
-int main (void) {
- int x = 3;
-
- vioInit();
- vioPrint(vioLevelNone, "Test [None]");
- vioPrint(vioLevelHeading, "Test [Heading] = Network Connector Message");
- vioPrint(vioLevelMessage, "Test [Message] = Connection failed");
- vioPrint(vioLevelError, "Test [Error] = %d", x);
-}
-\endcode
-***************************************************************************************************************************/
-
-void vioSetSignal (uint32_t mask, uint32_t signal) {};
-/**
-\fn void vioSetSignal (uint32_t mask, uint32_t signal)
-\details
-The function \b vioSetSignal set a \a signal to an output specified by \a mask. Use this function to map VIOs to actual
-hardware for displaying signals on a target board.
-
-Refer to \ref vioSignals_gr for information about the possible \a mask and \a signal values.
-
-\b Code \b Example:
-\code
-#include "cmsis_vio.h" // ::CMSIS Driver:VIO
-
-int main (void) {
-
- vioInit();
- vioSetSignal(vioLED0, vioLEDon);
- // ...
- vioSetSignal(vioLED0, vioLEDoff);
-}
-\endcode
-***************************************************************************************************************************/
-
-uint32_t vioGetSignal (uint32_t mask) {
- return (0);
-};
-/**
-\fn uint32_t vioGetSignal (uint32_t mask)
-\details
-The function \b vioGetSignal retrieves a signal from an input identified by \a mask. Use this function to read data from any
-input that is provided.
-
-Refer to \ref vioSignals_gr for information about the possible \a mask values.
-
-\b Code \b Example:
-\code
-#include "cmsis_vio.h" // ::CMSIS Driver:VIO
-
-int main (void) {
- uint32_t state;
- uint32_t last = 0U;
-
- vioInit();
- for (;;) {
- state = (vioGetSignal (vioBUTTON0)); // Get pressed button state
- if (state != last){
- if (state == vioBUTTON0){
- // do something
- }
- }
- last = state;
- }
-}
-\endcode
-***************************************************************************************************************************/
-
-void vioSetValue (uint32_t id, int32_t value) {};
-/**
-\fn void vioSetValue (uint32_t id, int32_t value)
-\details
-The function \b vioSetValue set the \a value to the output identified by \a id. Use this function to set states of I/Os for
-example.
-
-Refer to \ref vioValues_gr for information about \a value and \ref vioIDs_gr for \a id.
-
-\b Code \b Example:
-\code
-#include "cmsis_vio.h" // ::CMSIS Driver:VIO
-
-int main (void) {
-
- vioInit();
- vioSetValue(vioAOUT0, 1024);
-}
-\endcode
-***************************************************************************************************************************/
-
-int32_t vioGetValue (uint32_t id) {
- return (0);
-};
-/**
-\fn int32_t vioGetValue (uint32_t id)
-\details
-The function \b vioGetValue retrieves a value from the input identified by \a id. Use this function to read data from inputs.
-
-Refer to \ref vioIDs_gr for information about \a id.
-
-\b Code \b Example:
-\code
-#include "cmsis_vio.h" // ::CMSIS Driver:VIO
-
-int main (void) {
- uint32_t button;
-
- vioInit();
- button = vioGetValue(vioBUTTON0);
-}
-\endcode
-***************************************************************************************************************************/
-
-void vioSetXYZ (uint32_t id, vioValueXYZ_t valueXYZ) {
- return (0);
-};
-/**
-\fn void vioSetXYZ (uint32_t id, vioValueXYZ_t valueXYZ)
-\details
-The function \b vioSetXYZ sets a three-dimensional value \a valueXYZ to the output identified by \a id. Use this function to
-apply a 3d value to an output.
-
-Refer to \ref vioValues_gr for information about the \a valueXYZ and \ref vioIDs_gr for \a id.
-
-\b Code \b Example:
-\code
-#include "cmsis_vio.h" // ::CMSIS Driver:VIO
-
-int main (void) {
- vioValueXYZ_t xyz = {123, 456, 789};
-
- vioInit();
- vioSetXYZ(0, xyz);
-}
-\endcode
-***************************************************************************************************************************/
-
-vioValueXYZ_t vioGetXYZ (uint32_t id) {
- return (0);
-};
-/**
-\fn vioValueXYZ_t vioGetXYZ (uint32_t id)
-\details
-The function \b vioGetXYZ retrieves a three-dimensional value from the input identified by \a id. Use this function to get a
-3d value.
-
-Refer to \ref vioIDs_gr for information about \a id.
-
-\b Code \b Example:
-\code
-#include "cmsis_vio.h" // ::CMSIS Driver:VIO
-
-int main (void) {
- volatile vioValueXYZ_t xyz;
-
- vioInit();
- xyz = vioGetXYZ(vioMotionGyro);
-}
-\endcode
-***************************************************************************************************************************/
-
-void vioSetIPv4 (uint32_t id, vioAddrIPv4_t addrIPv4) {};
-/**
-\fn void vioSetIPv4 (uint32_t id, vioAddrIPv4_t addrIPv4)
-\details
-The function \b vioSetIPv4 sets an IPv4 address specified by \a addrIPv4 to an interface identified by \a id. Use this
-function to assign an IPv4 address to an interface.
-
-Refer to \ref vioIDs_gr for information about \a id and \ref vioIPAddr_gr for \a addrIPv4.
-
-\b Code \b Example:
-\code
-#include "cmsis_vio.h" // ::CMSIS Driver:VIO
-
-int main (void) {
- vioAddrIPv4_t addrIPv4 = {192U, 168U, 111U, 123U};
-
- vioInit();
- vioSetIPv4 (0, addrIPv4);
-}
-\endcode
-***************************************************************************************************************************/
-
-vioAddrIPv4_t vioGetIPv4 (uint32_t id) {
- return (0);
-};
-/**
-\fn vioAddrIPv4_t vioGetIPv4 (uint32_t id)
-\details
-The function \b vioGetIPv4 retrieves the IPv4 addrIPv4 from an interface identified by \a id. Use this function to read an
-IPv4 address.
-
-Refer to \ref vioIDs_gr for information about \a id.
-
-\b Code \b Example:
-\code
-#include "cmsis_vio.h" // ::CMSIS Driver:VIO
-
-int main (void) {
- vioAddrIPv4_t addrIPv4;
-
- vioInit();
- addrIPv4 = vioGetIPv4(0);
-}
-\endcode
-***************************************************************************************************************************/
-
-void vioSetIPv6 (uint32_t id, vioAddrIPv6_t addrIPv6) {};
-/**
-\fn void vioSetIPv6 (uint32_t id, vioAddrIPv6_t addrIPv6)
-\details
-The function \b vioSetIPv6 sets an IPv6 address specified by \a addrIPv6 to an interface identified by \a id. Use this
-function to assign an IPv6 address to an interface.
-
-Refer to \ref vioIDs_gr for information about \a id and \ref vioIPAddr_gr for \a addrIPv6.
-
-\b Code \b Example:
-\code
-#include "cmsis_vio.h" // ::CMSIS Driver:VIO
-
-int main (void) {
- vioAddrIPv6_t addrIPv6 = {1U, 2U, 3U, 4U, 5U, 6U, 7U, 8U,
- 9U, 10U, 11U, 12U, 13U, 14U, 15U, 16U};
-
- vioInit();
- vioSetIPv6 (0, addrIPv6);
-}
-\endcode
-***************************************************************************************************************************/
-
-vioAddrIPv6_t vioGetIPv6 (uint32_t id) {
- return (0);
-};
-/**
-\fn vioAddrIPv6_t vioGetIPv6 (uint32_t id)
-\details
-The function \b vioGetIPv6 retrieves the IPv6 addrIPv6 from an interface identified by \a id. Use this function to read an
-IPv6 address.
-
-Refer to \ref vioIDs_gr for information about \a id.
-
-\b Code \b Example:
-\code
-#include "cmsis_vio.h" // ::CMSIS Driver:VIO
-
-int main (void) {
- vioAddrIPv6_t addrIPv6;
-
- vioInit();
- addrIPv6 = vioGetIPv6(0);
-}
-\endcode
-***************************************************************************************************************************/
-
-/**
-@}
-*/
-// End VIO Interface
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/CAN_Bit_Timing.png b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/CAN_Bit_Timing.png
deleted file mode 100644
index 25eaddb..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/CAN_Bit_Timing.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/CAN_Bit_Timing.vsd b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/CAN_Bit_Timing.vsd
deleted file mode 100644
index 55e2f74..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/CAN_Bit_Timing.vsd and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/CAN_Node.png b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/CAN_Node.png
deleted file mode 100644
index b16699c..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/CAN_Node.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/CAN_Node.vsd b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/CAN_Node.vsd
deleted file mode 100644
index 40f948c..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/CAN_Node.vsd and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/ComponentSelection.png b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/ComponentSelection.png
deleted file mode 100644
index df1f9bf..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/ComponentSelection.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/EthernetSchematic.png b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/EthernetSchematic.png
deleted file mode 100644
index 6db8a03..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/EthernetSchematic.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/EthernetSchematic.vsd b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/EthernetSchematic.vsd
deleted file mode 100644
index 8a05a31..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/EthernetSchematic.vsd and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/I2C_BlockDiagram.png b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/I2C_BlockDiagram.png
deleted file mode 100644
index 9a7cd65..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/I2C_BlockDiagram.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/I2C_BlockDiagram.vsd b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/I2C_BlockDiagram.vsd
deleted file mode 100644
index 292af56..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/I2C_BlockDiagram.vsd and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/NAND_PageLayout.png b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/NAND_PageLayout.png
deleted file mode 100644
index 0f46e67..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/NAND_PageLayout.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/NAND_PageLayout.vsd b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/NAND_PageLayout.vsd
deleted file mode 100644
index a4a2391..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/NAND_PageLayout.vsd and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/NAND_Schematics.png b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/NAND_Schematics.png
deleted file mode 100644
index 651524c..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/NAND_Schematics.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/NAND_Schematics.vsd b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/NAND_Schematics.vsd
deleted file mode 100644
index 5b0a40f..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/NAND_Schematics.vsd and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/NAND_SpareArea.png b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/NAND_SpareArea.png
deleted file mode 100644
index 1eb815e..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/NAND_SpareArea.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/NAND_SpareArea.vsd b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/NAND_SpareArea.vsd
deleted file mode 100644
index eccb1c7..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/NAND_SpareArea.vsd and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/NOR_Schematics.png b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/NOR_Schematics.png
deleted file mode 100644
index b0f8d4c..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/NOR_Schematics.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/NOR_Schematics.vsd b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/NOR_Schematics.vsd
deleted file mode 100644
index 0a91e66..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/NOR_Schematics.vsd and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/Non_blocking_transmit_small.png b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/Non_blocking_transmit_small.png
deleted file mode 100644
index b47e1a5..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/Non_blocking_transmit_small.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/PDSC_Example.png b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/PDSC_Example.png
deleted file mode 100644
index 0bbb965..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/PDSC_Example.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/SAI_Schematics.png b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/SAI_Schematics.png
deleted file mode 100644
index 35e8e6f..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/SAI_Schematics.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/SAI_Schematics.vsd b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/SAI_Schematics.vsd
deleted file mode 100644
index c220bf0..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/SAI_Schematics.vsd and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/SAI_TimingDiagrams.vsd b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/SAI_TimingDiagrams.vsd
deleted file mode 100644
index 6591e29..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/SAI_TimingDiagrams.vsd and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/SD_1BitBusMode.png b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/SD_1BitBusMode.png
deleted file mode 100644
index 7cdace8..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/SD_1BitBusMode.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/SD_1BitBusMode.vsd b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/SD_1BitBusMode.vsd
deleted file mode 100644
index 59aa02c..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/SD_1BitBusMode.vsd and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/SD_4BitBusMode.png b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/SD_4BitBusMode.png
deleted file mode 100644
index 7f3944d..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/SD_4BitBusMode.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/SD_4BitBusMode.vsd b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/SD_4BitBusMode.vsd
deleted file mode 100644
index 04042cf..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/SD_4BitBusMode.vsd and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/SPI_BusMode.png b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/SPI_BusMode.png
deleted file mode 100644
index fbb7e41..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/SPI_BusMode.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/SPI_BusMode.vsd b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/SPI_BusMode.vsd
deleted file mode 100644
index f018c15..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/SPI_BusMode.vsd and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/SPI_Master1Slaves.png b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/SPI_Master1Slaves.png
deleted file mode 100644
index 45fb964..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/SPI_Master1Slaves.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/SPI_Master1Slaves.vsd b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/SPI_Master1Slaves.vsd
deleted file mode 100644
index db5c573..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/SPI_Master1Slaves.vsd and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/SPI_Master2Slaves.png b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/SPI_Master2Slaves.png
deleted file mode 100644
index 001c524..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/SPI_Master2Slaves.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/SPI_Master2Slaves.vsd b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/SPI_Master2Slaves.vsd
deleted file mode 100644
index 00c1181..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/SPI_Master2Slaves.vsd and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/SPI_Master3Slaves.png b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/SPI_Master3Slaves.png
deleted file mode 100644
index 6a268bd..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/SPI_Master3Slaves.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/SPI_Master3Slaves.vsd b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/SPI_Master3Slaves.vsd
deleted file mode 100644
index bd91297..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/SPI_Master3Slaves.vsd and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/SoftwarePacks.png b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/SoftwarePacks.png
deleted file mode 100644
index fea47c7..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/SoftwarePacks.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/Storage.vsd b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/Storage.vsd
deleted file mode 100644
index db89f6a..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/Storage.vsd and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/USB_Schematics.png b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/USB_Schematics.png
deleted file mode 100644
index dcfe569..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/USB_Schematics.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/USB_Schematics.vsd b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/USB_Schematics.vsd
deleted file mode 100644
index 8e94e4e..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/USB_Schematics.vsd and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/WiFi.png b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/WiFi.png
deleted file mode 100644
index 380c2ab..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/WiFi.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/driver.png b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/driver.png
deleted file mode 100644
index 1d5e256..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/driver.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/driver.pptx b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/driver.pptx
deleted file mode 100644
index dff56dd..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/driver.pptx and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/driver_sai_i2s.png b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/driver_sai_i2s.png
deleted file mode 100644
index 1f408c1..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/driver_sai_i2s.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/driver_sai_lsb.png b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/driver_sai_lsb.png
deleted file mode 100644
index 402198b..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/driver_sai_lsb.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/driver_sai_msb.png b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/driver_sai_msb.png
deleted file mode 100644
index 7da0b70..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/driver_sai_msb.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/driver_sai_pcm.png b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/driver_sai_pcm.png
deleted file mode 100644
index eed4160..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/driver_sai_pcm.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/driver_sai_user.png b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/driver_sai_user.png
deleted file mode 100644
index 41bb8d5..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/driver_sai_user.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/image001.png b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/image001.png
deleted file mode 100644
index 6afc7e7..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/image001.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/image002.png b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/image002.png
deleted file mode 100644
index 25e8fb6..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/image002.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/image003.png b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/image003.png
deleted file mode 100644
index 7215eaa..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/image003.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/image004.png b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/image004.png
deleted file mode 100644
index e4901ae..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/image004.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/image005.png b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/image005.png
deleted file mode 100644
index 810c629..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/image005.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/image006.png b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/image006.png
deleted file mode 100644
index 857f040..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/image006.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/storage_sw_stack.png b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/storage_sw_stack.png
deleted file mode 100644
index 6d8c30d..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/storage_sw_stack.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/vioComponentViewer.png b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/vioComponentViewer.png
deleted file mode 100644
index 396ed9c..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/vioComponentViewer.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/vioRationale.png b/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/vioRationale.png
deleted file mode 100644
index f110c0c..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/Driver/src/images/vioRationale.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/General/general.dxy b/external/CMSIS_5/CMSIS/DoxyGen/General/general.dxy
deleted file mode 100644
index 586607b..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/General/general.dxy
+++ /dev/null
@@ -1,2345 +0,0 @@
-# Doxyfile 1.8.6
-
-# This file describes the settings to be used by the documentation system
-# doxygen (www.doxygen.org) for a project.
-#
-# All text after a double hash (##) is considered a comment and is placed in
-# front of the TAG it is preceding.
-#
-# All text after a single hash (#) is considered a comment and will be ignored.
-# The format is:
-# TAG = value [value, ...]
-# For lists, items can also be appended using:
-# TAG += value [value, ...]
-# Values that contain spaces should be placed between quotes (\" \").
-
-#---------------------------------------------------------------------------
-# Project related configuration options
-#---------------------------------------------------------------------------
-
-# This tag specifies the encoding used for all characters in the config file
-# that follow. The default is UTF-8 which is also the encoding used for all text
-# before the first occurrence of this tag. Doxygen uses libiconv (or the iconv
-# built into libc) for the transcoding. See http://www.gnu.org/software/libiconv
-# for the list of possible encodings.
-# The default value is: UTF-8.
-
-DOXYFILE_ENCODING = UTF-8
-
-# The PROJECT_NAME tag is a single word (or a sequence of words surrounded by
-# double-quotes, unless you are using Doxywizard) that should identify the
-# project for which the documentation is generated. This name is used in the
-# title of most generated pages and in a few other places.
-# The default value is: My Project.
-
-PROJECT_NAME = "CMSIS"
-
-# The PROJECT_NUMBER tag can be used to enter a project or revision number. This
-# could be handy for archiving the generated documentation or if some version
-# control system is used.
-
-PROJECT_NUMBER = "Version 5.9.0"
-
-# Using the PROJECT_BRIEF tag one can provide an optional one line description
-# for a project that appears at the top of each page and should give viewer a
-# quick idea about the purpose of the project. Keep the description short.
-
-PROJECT_BRIEF = "Common Microcontroller Software Interface Standard"
-
-# With the PROJECT_LOGO tag one can specify an logo or icon that is included in
-# the documentation. The maximum height of the logo should not exceed 55 pixels
-# and the maximum width should not exceed 200 pixels. Doxygen will copy the logo
-# to the output directory.
-
-PROJECT_LOGO = ../Doxygen_Templates/CMSIS_Logo_Final.png
-
-# The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute) path
-# into which the generated documentation will be written. If a relative path is
-# entered, it will be relative to the location where doxygen was started. If
-# left blank the current directory will be used.
-
-OUTPUT_DIRECTORY = ../../Documentation/General
-
-# If the CREATE_SUBDIRS tag is set to YES, then doxygen will create 4096 sub-
-# directories (in 2 levels) under the output directory of each output format and
-# will distribute the generated files over these directories. Enabling this
-# option can be useful when feeding doxygen a huge amount of source files, where
-# putting all generated files in the same directory would otherwise causes
-# performance problems for the file system.
-# The default value is: NO.
-
-CREATE_SUBDIRS = NO
-
-# The OUTPUT_LANGUAGE tag is used to specify the language in which all
-# documentation generated by doxygen is written. Doxygen will use this
-# information to generate all constant output in the proper language.
-# Possible values are: Afrikaans, Arabic, Armenian, Brazilian, Catalan, Chinese,
-# Chinese-Traditional, Croatian, Czech, Danish, Dutch, English (United States),
-# Esperanto, Farsi (Persian), Finnish, French, German, Greek, Hungarian,
-# Indonesian, Italian, Japanese, Japanese-en (Japanese with English messages),
-# Korean, Korean-en (Korean with English messages), Latvian, Lithuanian,
-# Macedonian, Norwegian, Persian (Farsi), Polish, Portuguese, Romanian, Russian,
-# Serbian, Serbian-Cyrillic, Slovak, Slovene, Spanish, Swedish, Turkish,
-# Ukrainian and Vietnamese.
-# The default value is: English.
-
-OUTPUT_LANGUAGE = English
-
-# If the BRIEF_MEMBER_DESC tag is set to YES doxygen will include brief member
-# descriptions after the members that are listed in the file and class
-# documentation (similar to Javadoc). Set to NO to disable this.
-# The default value is: YES.
-
-BRIEF_MEMBER_DESC = YES
-
-# If the REPEAT_BRIEF tag is set to YES doxygen will prepend the brief
-# description of a member or function before the detailed description
-#
-# Note: If both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the
-# brief descriptions will be completely suppressed.
-# The default value is: YES.
-
-REPEAT_BRIEF = NO
-
-# This tag implements a quasi-intelligent brief description abbreviator that is
-# used to form the text in various listings. Each string in this list, if found
-# as the leading text of the brief description, will be stripped from the text
-# and the result, after processing the whole list, is used as the annotated
-# text. Otherwise, the brief description is used as-is. If left blank, the
-# following values are used ($name is automatically replaced with the name of
-# the entity):The $name class, The $name widget, The $name file, is, provides,
-# specifies, contains, represents, a, an and the.
-
-ABBREVIATE_BRIEF = "The $name class" \
- "The $name widget" \
- "The $name file" \
- is \
- provides \
- specifies \
- contains \
- represents \
- a \
- an \
- the
-
-# If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES then
-# doxygen will generate a detailed section even if there is only a brief
-# description.
-# The default value is: NO.
-
-ALWAYS_DETAILED_SEC = NO
-
-# If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all
-# inherited members of a class in the documentation of that class as if those
-# members were ordinary class members. Constructors, destructors and assignment
-# operators of the base classes will not be shown.
-# The default value is: NO.
-
-INLINE_INHERITED_MEMB = NO
-
-# If the FULL_PATH_NAMES tag is set to YES doxygen will prepend the full path
-# before files name in the file list and in the header files. If set to NO the
-# shortest path that makes the file name unique will be used
-# The default value is: YES.
-
-FULL_PATH_NAMES = NO
-
-# The STRIP_FROM_PATH tag can be used to strip a user-defined part of the path.
-# Stripping is only done if one of the specified strings matches the left-hand
-# part of the path. The tag can be used to show relative paths in the file list.
-# If left blank the directory from which doxygen is run is used as the path to
-# strip.
-#
-# Note that you can specify absolute paths here, but also relative paths, which
-# will be relative from the directory where doxygen is started.
-# This tag requires that the tag FULL_PATH_NAMES is set to YES.
-
-STRIP_FROM_PATH =
-
-# The STRIP_FROM_INC_PATH tag can be used to strip a user-defined part of the
-# path mentioned in the documentation of a class, which tells the reader which
-# header file to include in order to use a class. If left blank only the name of
-# the header file containing the class definition is used. Otherwise one should
-# specify the list of include paths that are normally passed to the compiler
-# using the -I flag.
-
-STRIP_FROM_INC_PATH =
-
-# If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter (but
-# less readable) file names. This can be useful is your file systems doesn't
-# support long names like on DOS, Mac, or CD-ROM.
-# The default value is: NO.
-
-SHORT_NAMES = NO
-
-# If the JAVADOC_AUTOBRIEF tag is set to YES then doxygen will interpret the
-# first line (until the first dot) of a Javadoc-style comment as the brief
-# description. If set to NO, the Javadoc-style will behave just like regular Qt-
-# style comments (thus requiring an explicit @brief command for a brief
-# description.)
-# The default value is: NO.
-
-JAVADOC_AUTOBRIEF = NO
-
-# If the QT_AUTOBRIEF tag is set to YES then doxygen will interpret the first
-# line (until the first dot) of a Qt-style comment as the brief description. If
-# set to NO, the Qt-style will behave just like regular Qt-style comments (thus
-# requiring an explicit \brief command for a brief description.)
-# The default value is: NO.
-
-QT_AUTOBRIEF = NO
-
-# The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make doxygen treat a
-# multi-line C++ special comment block (i.e. a block of //! or /// comments) as
-# a brief description. This used to be the default behavior. The new default is
-# to treat a multi-line C++ comment block as a detailed description. Set this
-# tag to YES if you prefer the old behavior instead.
-#
-# Note that setting this tag to YES also means that rational rose comments are
-# not recognized any more.
-# The default value is: NO.
-
-MULTILINE_CPP_IS_BRIEF = YES
-
-# If the INHERIT_DOCS tag is set to YES then an undocumented member inherits the
-# documentation from any documented member that it re-implements.
-# The default value is: YES.
-
-INHERIT_DOCS = NO
-
-# If the SEPARATE_MEMBER_PAGES tag is set to YES, then doxygen will produce a
-# new page for each member. If set to NO, the documentation of a member will be
-# part of the file/class/namespace that contains it.
-# The default value is: NO.
-
-SEPARATE_MEMBER_PAGES = NO
-
-# The TAB_SIZE tag can be used to set the number of spaces in a tab. Doxygen
-# uses this value to replace tabs by spaces in code fragments.
-# Minimum value: 1, maximum value: 16, default value: 4.
-
-TAB_SIZE = 8
-
-# This tag can be used to specify a number of aliases that act as commands in
-# the documentation. An alias has the form:
-# name=value
-# For example adding
-# "sideeffect=@par Side Effects:\n"
-# will allow you to put the command \sideeffect (or @sideeffect) in the
-# documentation, which will result in a user-defined paragraph with heading
-# "Side Effects:". You can put \n's in the value part of an alias to insert
-# newlines.
-
-ALIASES =
-
-# This tag can be used to specify a number of word-keyword mappings (TCL only).
-# A mapping has the form "name=value". For example adding "class=itcl::class"
-# will allow you to use the command class in the itcl::class meaning.
-
-TCL_SUBST =
-
-# Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C sources
-# only. Doxygen will then generate output that is more tailored for C. For
-# instance, some of the names that are used will be different. The list of all
-# members will be omitted, etc.
-# The default value is: NO.
-
-OPTIMIZE_OUTPUT_FOR_C = YES
-
-# Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java or
-# Python sources only. Doxygen will then generate output that is more tailored
-# for that language. For instance, namespaces will be presented as packages,
-# qualified scopes will look different, etc.
-# The default value is: NO.
-
-OPTIMIZE_OUTPUT_JAVA = NO
-
-# Set the OPTIMIZE_FOR_FORTRAN tag to YES if your project consists of Fortran
-# sources. Doxygen will then generate output that is tailored for Fortran.
-# The default value is: NO.
-
-OPTIMIZE_FOR_FORTRAN = NO
-
-# Set the OPTIMIZE_OUTPUT_VHDL tag to YES if your project consists of VHDL
-# sources. Doxygen will then generate output that is tailored for VHDL.
-# The default value is: NO.
-
-OPTIMIZE_OUTPUT_VHDL = NO
-
-# Doxygen selects the parser to use depending on the extension of the files it
-# parses. With this tag you can assign which parser to use for a given
-# extension. Doxygen has a built-in mapping, but you can override or extend it
-# using this tag. The format is ext=language, where ext is a file extension, and
-# language is one of the parsers supported by doxygen: IDL, Java, Javascript,
-# C#, C, C++, D, PHP, Objective-C, Python, Fortran, VHDL. For instance to make
-# doxygen treat .inc files as Fortran files (default is PHP), and .f files as C
-# (default is Fortran), use: inc=Fortran f=C.
-#
-# Note For files without extension you can use no_extension as a placeholder.
-#
-# Note that for custom extensions you also need to set FILE_PATTERNS otherwise
-# the files are not read by doxygen.
-
-EXTENSION_MAPPING =
-
-# If the MARKDOWN_SUPPORT tag is enabled then doxygen pre-processes all comments
-# according to the Markdown format, which allows for more readable
-# documentation. See http://daringfireball.net/projects/markdown/ for details.
-# The output of markdown processing is further processed by doxygen, so you can
-# mix doxygen, HTML, and XML commands with Markdown formatting. Disable only in
-# case of backward compatibilities issues.
-# The default value is: YES.
-
-MARKDOWN_SUPPORT = YES
-
-# When enabled doxygen tries to link words that correspond to documented
-# classes, or namespaces to their corresponding documentation. Such a link can
-# be prevented in individual cases by by putting a % sign in front of the word
-# or globally by setting AUTOLINK_SUPPORT to NO.
-# The default value is: YES.
-
-AUTOLINK_SUPPORT = YES
-
-# If you use STL classes (i.e. std::string, std::vector, etc.) but do not want
-# to include (a tag file for) the STL sources as input, then you should set this
-# tag to YES in order to let doxygen match functions declarations and
-# definitions whose arguments contain STL classes (e.g. func(std::string);
-# versus func(std::string) {}). This also make the inheritance and collaboration
-# diagrams that involve STL classes more complete and accurate.
-# The default value is: NO.
-
-BUILTIN_STL_SUPPORT = NO
-
-# If you use Microsoft's C++/CLI language, you should set this option to YES to
-# enable parsing support.
-# The default value is: NO.
-
-CPP_CLI_SUPPORT = NO
-
-# Set the SIP_SUPPORT tag to YES if your project consists of sip (see:
-# http://www.riverbankcomputing.co.uk/software/sip/intro) sources only. Doxygen
-# will parse them like normal C++ but will assume all classes use public instead
-# of private inheritance when no explicit protection keyword is present.
-# The default value is: NO.
-
-SIP_SUPPORT = NO
-
-# For Microsoft's IDL there are propget and propput attributes to indicate
-# getter and setter methods for a property. Setting this option to YES will make
-# doxygen to replace the get and set methods by a property in the documentation.
-# This will only work if the methods are indeed getting or setting a simple
-# type. If this is not the case, or you want to show the methods anyway, you
-# should set this option to NO.
-# The default value is: YES.
-
-IDL_PROPERTY_SUPPORT = YES
-
-# If member grouping is used in the documentation and the DISTRIBUTE_GROUP_DOC
-# tag is set to YES, then doxygen will reuse the documentation of the first
-# member in the group (if any) for the other members of the group. By default
-# all members of a group must be documented explicitly.
-# The default value is: NO.
-
-DISTRIBUTE_GROUP_DOC = NO
-
-# Set the SUBGROUPING tag to YES to allow class member groups of the same type
-# (for instance a group of public functions) to be put as a subgroup of that
-# type (e.g. under the Public Functions section). Set it to NO to prevent
-# subgrouping. Alternatively, this can be done per class using the
-# \nosubgrouping command.
-# The default value is: YES.
-
-SUBGROUPING = YES
-
-# When the INLINE_GROUPED_CLASSES tag is set to YES, classes, structs and unions
-# are shown inside the group in which they are included (e.g. using \ingroup)
-# instead of on a separate page (for HTML and Man pages) or section (for LaTeX
-# and RTF).
-#
-# Note that this feature does not work in combination with
-# SEPARATE_MEMBER_PAGES.
-# The default value is: NO.
-
-INLINE_GROUPED_CLASSES = NO
-
-# When the INLINE_SIMPLE_STRUCTS tag is set to YES, structs, classes, and unions
-# with only public data fields or simple typedef fields will be shown inline in
-# the documentation of the scope in which they are defined (i.e. file,
-# namespace, or group documentation), provided this scope is documented. If set
-# to NO, structs, classes, and unions are shown on a separate page (for HTML and
-# Man pages) or section (for LaTeX and RTF).
-# The default value is: NO.
-
-INLINE_SIMPLE_STRUCTS = NO
-
-# When TYPEDEF_HIDES_STRUCT tag is enabled, a typedef of a struct, union, or
-# enum is documented as struct, union, or enum with the name of the typedef. So
-# typedef struct TypeS {} TypeT, will appear in the documentation as a struct
-# with name TypeT. When disabled the typedef will appear as a member of a file,
-# namespace, or class. And the struct will be named TypeS. This can typically be
-# useful for C code in case the coding convention dictates that all compound
-# types are typedef'ed and only the typedef is referenced, never the tag name.
-# The default value is: NO.
-
-TYPEDEF_HIDES_STRUCT = YES
-
-# The size of the symbol lookup cache can be set using LOOKUP_CACHE_SIZE. This
-# cache is used to resolve symbols given their name and scope. Since this can be
-# an expensive process and often the same symbol appears multiple times in the
-# code, doxygen keeps a cache of pre-resolved symbols. If the cache is too small
-# doxygen will become slower. If the cache is too large, memory is wasted. The
-# cache size is given by this formula: 2^(16+LOOKUP_CACHE_SIZE). The valid range
-# is 0..9, the default is 0, corresponding to a cache size of 2^16=65536
-# symbols. At the end of a run doxygen will report the cache usage and suggest
-# the optimal cache size from a speed point of view.
-# Minimum value: 0, maximum value: 9, default value: 0.
-
-LOOKUP_CACHE_SIZE = 0
-
-#---------------------------------------------------------------------------
-# Build related configuration options
-#---------------------------------------------------------------------------
-
-# If the EXTRACT_ALL tag is set to YES doxygen will assume all entities in
-# documentation are documented, even if no documentation was available. Private
-# class members and static file members will be hidden unless the
-# EXTRACT_PRIVATE respectively EXTRACT_STATIC tags are set to YES.
-# Note: This will also disable the warnings about undocumented members that are
-# normally produced when WARNINGS is set to YES.
-# The default value is: NO.
-
-EXTRACT_ALL = YES
-
-# If the EXTRACT_PRIVATE tag is set to YES all private members of a class will
-# be included in the documentation.
-# The default value is: NO.
-
-EXTRACT_PRIVATE = YES
-
-# If the EXTRACT_PACKAGE tag is set to YES all members with package or internal
-# scope will be included in the documentation.
-# The default value is: NO.
-
-EXTRACT_PACKAGE = NO
-
-# If the EXTRACT_STATIC tag is set to YES all static members of a file will be
-# included in the documentation.
-# The default value is: NO.
-
-EXTRACT_STATIC = YES
-
-# If the EXTRACT_LOCAL_CLASSES tag is set to YES classes (and structs) defined
-# locally in source files will be included in the documentation. If set to NO
-# only classes defined in header files are included. Does not have any effect
-# for Java sources.
-# The default value is: YES.
-
-EXTRACT_LOCAL_CLASSES = NO
-
-# This flag is only useful for Objective-C code. When set to YES local methods,
-# which are defined in the implementation section but not in the interface are
-# included in the documentation. If set to NO only methods in the interface are
-# included.
-# The default value is: NO.
-
-EXTRACT_LOCAL_METHODS = YES
-
-# If this flag is set to YES, the members of anonymous namespaces will be
-# extracted and appear in the documentation as a namespace called
-# 'anonymous_namespace{file}', where file will be replaced with the base name of
-# the file that contains the anonymous namespace. By default anonymous namespace
-# are hidden.
-# The default value is: NO.
-
-EXTRACT_ANON_NSPACES = NO
-
-# If the HIDE_UNDOC_MEMBERS tag is set to YES, doxygen will hide all
-# undocumented members inside documented classes or files. If set to NO these
-# members will be included in the various overviews, but no documentation
-# section is generated. This option has no effect if EXTRACT_ALL is enabled.
-# The default value is: NO.
-
-HIDE_UNDOC_MEMBERS = NO
-
-# If the HIDE_UNDOC_CLASSES tag is set to YES, doxygen will hide all
-# undocumented classes that are normally visible in the class hierarchy. If set
-# to NO these classes will be included in the various overviews. This option has
-# no effect if EXTRACT_ALL is enabled.
-# The default value is: NO.
-
-HIDE_UNDOC_CLASSES = NO
-
-# If the HIDE_FRIEND_COMPOUNDS tag is set to YES, doxygen will hide all friend
-# (class|struct|union) declarations. If set to NO these declarations will be
-# included in the documentation.
-# The default value is: NO.
-
-HIDE_FRIEND_COMPOUNDS = NO
-
-# If the HIDE_IN_BODY_DOCS tag is set to YES, doxygen will hide any
-# documentation blocks found inside the body of a function. If set to NO these
-# blocks will be appended to the function's detailed documentation block.
-# The default value is: NO.
-
-HIDE_IN_BODY_DOCS = NO
-
-# The INTERNAL_DOCS tag determines if documentation that is typed after a
-# \internal command is included. If the tag is set to NO then the documentation
-# will be excluded. Set it to YES to include the internal documentation.
-# The default value is: NO.
-
-INTERNAL_DOCS = NO
-
-# If the CASE_SENSE_NAMES tag is set to NO then doxygen will only generate file
-# names in lower-case letters. If set to YES upper-case letters are also
-# allowed. This is useful if you have classes or files whose names only differ
-# in case and if your file system supports case sensitive file names. Windows
-# and Mac users are advised to set this option to NO.
-# The default value is: system dependent.
-
-CASE_SENSE_NAMES = YES
-
-# If the HIDE_SCOPE_NAMES tag is set to NO then doxygen will show members with
-# their full class and namespace scopes in the documentation. If set to YES the
-# scope will be hidden.
-# The default value is: NO.
-
-HIDE_SCOPE_NAMES = NO
-
-# If the SHOW_INCLUDE_FILES tag is set to YES then doxygen will put a list of
-# the files that are included by a file in the documentation of that file.
-# The default value is: YES.
-
-SHOW_INCLUDE_FILES = NO
-
-
-SHOW_GROUPED_MEMB_INC = NO
-
-# If the FORCE_LOCAL_INCLUDES tag is set to YES then doxygen will list include
-# files with double quotes in the documentation rather than with sharp brackets.
-# The default value is: NO.
-
-FORCE_LOCAL_INCLUDES = NO
-
-# If the INLINE_INFO tag is set to YES then a tag [inline] is inserted in the
-# documentation for inline members.
-# The default value is: YES.
-
-INLINE_INFO = YES
-
-# If the SORT_MEMBER_DOCS tag is set to YES then doxygen will sort the
-# (detailed) documentation of file and class members alphabetically by member
-# name. If set to NO the members will appear in declaration order.
-# The default value is: YES.
-
-SORT_MEMBER_DOCS = YES
-
-# If the SORT_BRIEF_DOCS tag is set to YES then doxygen will sort the brief
-# descriptions of file, namespace and class members alphabetically by member
-# name. If set to NO the members will appear in declaration order. Note that
-# this will also influence the order of the classes in the class list.
-# The default value is: NO.
-
-SORT_BRIEF_DOCS = NO
-
-# If the SORT_MEMBERS_CTORS_1ST tag is set to YES then doxygen will sort the
-# (brief and detailed) documentation of class members so that constructors and
-# destructors are listed first. If set to NO the constructors will appear in the
-# respective orders defined by SORT_BRIEF_DOCS and SORT_MEMBER_DOCS.
-# Note: If SORT_BRIEF_DOCS is set to NO this option is ignored for sorting brief
-# member documentation.
-# Note: If SORT_MEMBER_DOCS is set to NO this option is ignored for sorting
-# detailed member documentation.
-# The default value is: NO.
-
-SORT_MEMBERS_CTORS_1ST = NO
-
-# If the SORT_GROUP_NAMES tag is set to YES then doxygen will sort the hierarchy
-# of group names into alphabetical order. If set to NO the group names will
-# appear in their defined order.
-# The default value is: NO.
-
-SORT_GROUP_NAMES = NO
-
-# If the SORT_BY_SCOPE_NAME tag is set to YES, the class list will be sorted by
-# fully-qualified names, including namespaces. If set to NO, the class list will
-# be sorted only by class name, not including the namespace part.
-# Note: This option is not very useful if HIDE_SCOPE_NAMES is set to YES.
-# Note: This option applies only to the class list, not to the alphabetical
-# list.
-# The default value is: NO.
-
-SORT_BY_SCOPE_NAME = NO
-
-# If the STRICT_PROTO_MATCHING option is enabled and doxygen fails to do proper
-# type resolution of all parameters of a function it will reject a match between
-# the prototype and the implementation of a member function even if there is
-# only one candidate or it is obvious which candidate to choose by doing a
-# simple string match. By disabling STRICT_PROTO_MATCHING doxygen will still
-# accept a match between prototype and implementation in such cases.
-# The default value is: NO.
-
-STRICT_PROTO_MATCHING = NO
-
-# The GENERATE_TODOLIST tag can be used to enable ( YES) or disable ( NO) the
-# todo list. This list is created by putting \todo commands in the
-# documentation.
-# The default value is: YES.
-
-GENERATE_TODOLIST = YES
-
-# The GENERATE_TESTLIST tag can be used to enable ( YES) or disable ( NO) the
-# test list. This list is created by putting \test commands in the
-# documentation.
-# The default value is: YES.
-
-GENERATE_TESTLIST = YES
-
-# The GENERATE_BUGLIST tag can be used to enable ( YES) or disable ( NO) the bug
-# list. This list is created by putting \bug commands in the documentation.
-# The default value is: YES.
-
-GENERATE_BUGLIST = YES
-
-# The GENERATE_DEPRECATEDLIST tag can be used to enable ( YES) or disable ( NO)
-# the deprecated list. This list is created by putting \deprecated commands in
-# the documentation.
-# The default value is: YES.
-
-GENERATE_DEPRECATEDLIST= YES
-
-# The ENABLED_SECTIONS tag can be used to enable conditional documentation
-# sections, marked by \if ... \endif and \cond
-# ... \endcond blocks.
-
-ENABLED_SECTIONS =
-
-# The MAX_INITIALIZER_LINES tag determines the maximum number of lines that the
-# initial value of a variable or macro / define can have for it to appear in the
-# documentation. If the initializer consists of more lines than specified here
-# it will be hidden. Use a value of 0 to hide initializers completely. The
-# appearance of the value of individual variables and macros / defines can be
-# controlled using \showinitializer or \hideinitializer command in the
-# documentation regardless of this setting.
-# Minimum value: 0, maximum value: 10000, default value: 30.
-
-MAX_INITIALIZER_LINES = 0
-
-# Set the SHOW_USED_FILES tag to NO to disable the list of files generated at
-# the bottom of the documentation of classes and structs. If set to YES the list
-# will mention the files that were used to generate the documentation.
-# The default value is: YES.
-
-SHOW_USED_FILES = NO
-
-# Set the SHOW_FILES tag to NO to disable the generation of the Files page. This
-# will remove the Files entry from the Quick Index and from the Folder Tree View
-# (if specified).
-# The default value is: YES.
-
-SHOW_FILES = NO
-
-# Set the SHOW_NAMESPACES tag to NO to disable the generation of the Namespaces
-# page. This will remove the Namespaces entry from the Quick Index and from the
-# Folder Tree View (if specified).
-# The default value is: YES.
-
-SHOW_NAMESPACES = NO
-
-# The FILE_VERSION_FILTER tag can be used to specify a program or script that
-# doxygen should invoke to get the current version for each file (typically from
-# the version control system). Doxygen will invoke the program by executing (via
-# popen()) the command command input-file, where command is the value of the
-# FILE_VERSION_FILTER tag, and input-file is the name of an input file provided
-# by doxygen. Whatever the program writes to standard output is used as the file
-# version. For an example see the documentation.
-
-FILE_VERSION_FILTER =
-
-# The LAYOUT_FILE tag can be used to specify a layout file which will be parsed
-# by doxygen. The layout file controls the global structure of the generated
-# output files in an output format independent way. To create the layout file
-# that represents doxygen's defaults, run doxygen with the -l option. You can
-# optionally specify a file name after the option, if omitted DoxygenLayout.xml
-# will be used as the name of the layout file.
-#
-# Note that if you run doxygen from a directory containing a file called
-# DoxygenLayout.xml, doxygen will parse it automatically even if the LAYOUT_FILE
-# tag is left empty.
-
-LAYOUT_FILE = ../Doxygen_Templates/DoxygenLayout_forUser.xml
-
-# The CITE_BIB_FILES tag can be used to specify one or more bib files containing
-# the reference definitions. This must be a list of .bib files. The .bib
-# extension is automatically appended if omitted. This requires the bibtex tool
-# to be installed. See also http://en.wikipedia.org/wiki/BibTeX for more info.
-# For LaTeX the style of the bibliography can be controlled using
-# LATEX_BIB_STYLE. To use this feature you need bibtex and perl available in the
-# search path. Do not use file names with spaces, bibtex cannot handle them. See
-# also \cite for info how to create references.
-
-CITE_BIB_FILES =
-
-#---------------------------------------------------------------------------
-# Configuration options related to warning and progress messages
-#---------------------------------------------------------------------------
-
-# The QUIET tag can be used to turn on/off the messages that are generated to
-# standard output by doxygen. If QUIET is set to YES this implies that the
-# messages are off.
-# The default value is: NO.
-
-QUIET = YES
-
-# The WARNINGS tag can be used to turn on/off the warning messages that are
-# generated to standard error ( stderr) by doxygen. If WARNINGS is set to YES
-# this implies that the warnings are on.
-#
-# Tip: Turn warnings on while writing the documentation.
-# The default value is: YES.
-
-WARNINGS = YES
-
-# If the WARN_IF_UNDOCUMENTED tag is set to YES, then doxygen will generate
-# warnings for undocumented members. If EXTRACT_ALL is set to YES then this flag
-# will automatically be disabled.
-# The default value is: YES.
-
-WARN_IF_UNDOCUMENTED = YES
-
-# If the WARN_IF_DOC_ERROR tag is set to YES, doxygen will generate warnings for
-# potential errors in the documentation, such as not documenting some parameters
-# in a documented function, or documenting parameters that don't exist or using
-# markup commands wrongly.
-# The default value is: YES.
-
-WARN_IF_DOC_ERROR = YES
-
-# This WARN_NO_PARAMDOC option can be enabled to get warnings for functions that
-# are documented, but have no documentation for their parameters or return
-# value. If set to NO doxygen will only warn about wrong or incomplete parameter
-# documentation, but not about the absence of documentation.
-# The default value is: NO.
-
-WARN_NO_PARAMDOC = YES
-
-# The WARN_FORMAT tag determines the format of the warning messages that doxygen
-# can produce. The string should contain the $file, $line, and $text tags, which
-# will be replaced by the file and line number from which the warning originated
-# and the warning text. Optionally the format may contain $version, which will
-# be replaced by the version of the file (if it could be obtained via
-# FILE_VERSION_FILTER)
-# The default value is: $file:$line: $text.
-
-WARN_FORMAT = "$file:$line: $text"
-
-# The WARN_LOGFILE tag can be used to specify a file to which warning and error
-# messages should be written. If left blank the output is written to standard
-# error (stderr).
-
-WARN_LOGFILE =
-
-#---------------------------------------------------------------------------
-# Configuration options related to the input files
-#---------------------------------------------------------------------------
-
-# The INPUT tag is used to specify the files and/or directories that contain
-# documented source files. You may enter file names like myfile.cpp or
-# directories like /usr/src/myproject. Separate the files or directories with
-# spaces.
-# Note: If this tag is empty the current directory is searched.
-
-INPUT = .
-
-# This tag can be used to specify the character encoding of the source files
-# that doxygen parses. Internally doxygen uses the UTF-8 encoding. Doxygen uses
-# libiconv (or the iconv built into libc) for the transcoding. See the libiconv
-# documentation (see: http://www.gnu.org/software/libiconv) for the list of
-# possible encodings.
-# The default value is: UTF-8.
-
-INPUT_ENCODING = UTF-8
-
-# If the value of the INPUT tag contains directories, you can use the
-# FILE_PATTERNS tag to specify one or more wildcard patterns (like *.cpp and
-# *.h) to filter out the source-files in the directories. If left blank the
-# following patterns are tested:*.c, *.cc, *.cxx, *.cpp, *.c++, *.java, *.ii,
-# *.ixx, *.ipp, *.i++, *.inl, *.idl, *.ddl, *.odl, *.h, *.hh, *.hxx, *.hpp,
-# *.h++, *.cs, *.d, *.php, *.php4, *.php5, *.phtml, *.inc, *.m, *.markdown,
-# *.md, *.mm, *.dox, *.py, *.f90, *.f, *.for, *.tcl, *.vhd, *.vhdl, *.ucf,
-# *.qsf, *.as and *.js.
-
-FILE_PATTERNS = *.c \
- *.cc \
- *.cxx \
- *.cpp \
- *.c++ \
- *.d \
- *.java \
- *.ii \
- *.ixx \
- *.ipp \
- *.i++ \
- *.inl \
- *.h \
- *.hh \
- *.hxx \
- *.hpp \
- *.h++ \
- *.idl \
- *.odl \
- *.cs \
- *.php \
- *.php3 \
- *.inc \
- *.m \
- *.mm \
- *.dox \
- *.py \
- *.f90 \
- *.f \
- *.for \
- *.vhd \
- *.vhdl \
- *.txt
-
-# The RECURSIVE tag can be used to specify whether or not subdirectories should
-# be searched for input files as well.
-# The default value is: NO.
-
-RECURSIVE = YES
-
-# The EXCLUDE tag can be used to specify files and/or directories that should be
-# excluded from the INPUT source files. This way you can easily exclude a
-# subdirectory from a directory tree whose root is specified with the INPUT tag.
-#
-# Note that relative paths are relative to the directory from which doxygen is
-# run.
-
-EXCLUDE = system*.c \
- startup*.s
-
-# The EXCLUDE_SYMLINKS tag can be used to select whether or not files or
-# directories that are symbolic links (a Unix file system feature) are excluded
-# from the input.
-# The default value is: NO.
-
-EXCLUDE_SYMLINKS = NO
-
-# If the value of the INPUT tag contains directories, you can use the
-# EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude
-# certain files from those directories.
-#
-# Note that the wildcards are matched against the file with absolute path, so to
-# exclude all test directories for example use the pattern */test/*
-
-EXCLUDE_PATTERNS =
-
-# The EXCLUDE_SYMBOLS tag can be used to specify one or more symbol names
-# (namespaces, classes, functions, etc.) that should be excluded from the
-# output. The symbol name can be a fully qualified name, a word, or if the
-# wildcard * is used, a substring. Examples: ANamespace, AClass,
-# AClass::ANamespace, ANamespace::*Test
-#
-# Note that the wildcards are matched against the file with absolute path, so to
-# exclude all test directories use the pattern */test/*
-
-EXCLUDE_SYMBOLS =
-
-# The EXAMPLE_PATH tag can be used to specify one or more files or directories
-# that contain example code fragments that are included (see the \include
-# command).
-
-EXAMPLE_PATH =
-
-# If the value of the EXAMPLE_PATH tag contains directories, you can use the
-# EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp and
-# *.h) to filter out the source-files in the directories. If left blank all
-# files are included.
-
-EXAMPLE_PATTERNS = *
-
-# If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be
-# searched for input files to be used with the \include or \dontinclude commands
-# irrespective of the value of the RECURSIVE tag.
-# The default value is: NO.
-
-EXAMPLE_RECURSIVE = NO
-
-# The IMAGE_PATH tag can be used to specify one or more files or directories
-# that contain images that are to be included in the documentation (see the
-# \image command).
-
-IMAGE_PATH = src/images
-
-# The INPUT_FILTER tag can be used to specify a program that doxygen should
-# invoke to filter for each input file. Doxygen will invoke the filter program
-# by executing (via popen()) the command:
-#
-#
-#
-# where is the value of the INPUT_FILTER tag, and is the
-# name of an input file. Doxygen will then use the output that the filter
-# program writes to standard output. If FILTER_PATTERNS is specified, this tag
-# will be ignored.
-#
-# Note that the filter must not add or remove lines; it is applied before the
-# code is scanned, but not when the output code is generated. If lines are added
-# or removed, the anchors will not be placed correctly.
-
-INPUT_FILTER =
-
-# The FILTER_PATTERNS tag can be used to specify filters on a per file pattern
-# basis. Doxygen will compare the file name with each pattern and apply the
-# filter if there is a match. The filters are a list of the form: pattern=filter
-# (like *.cpp=my_cpp_filter). See INPUT_FILTER for further information on how
-# filters are used. If the FILTER_PATTERNS tag is empty or if none of the
-# patterns match the file name, INPUT_FILTER is applied.
-
-FILTER_PATTERNS =
-
-# If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using
-# INPUT_FILTER ) will also be used to filter the input files that are used for
-# producing the source files to browse (i.e. when SOURCE_BROWSER is set to YES).
-# The default value is: NO.
-
-FILTER_SOURCE_FILES = NO
-
-# The FILTER_SOURCE_PATTERNS tag can be used to specify source filters per file
-# pattern. A pattern will override the setting for FILTER_PATTERN (if any) and
-# it is also possible to disable source filtering for a specific pattern using
-# *.ext= (so without naming a filter).
-# This tag requires that the tag FILTER_SOURCE_FILES is set to YES.
-
-FILTER_SOURCE_PATTERNS =
-
-# If the USE_MDFILE_AS_MAINPAGE tag refers to the name of a markdown file that
-# is part of the input, its contents will be placed on the main page
-# (index.html). This can be useful if you have a project on for instance GitHub
-# and want to reuse the introduction page also for the doxygen output.
-
-USE_MDFILE_AS_MAINPAGE =
-
-#---------------------------------------------------------------------------
-# Configuration options related to source browsing
-#---------------------------------------------------------------------------
-
-# If the SOURCE_BROWSER tag is set to YES then a list of source files will be
-# generated. Documented entities will be cross-referenced with these sources.
-#
-# Note: To get rid of all source code in the generated output, make sure that
-# also VERBATIM_HEADERS is set to NO.
-# The default value is: NO.
-
-SOURCE_BROWSER = NO
-
-# Setting the INLINE_SOURCES tag to YES will include the body of functions,
-# classes and enums directly into the documentation.
-# The default value is: NO.
-
-INLINE_SOURCES = NO
-
-# Setting the STRIP_CODE_COMMENTS tag to YES will instruct doxygen to hide any
-# special comment blocks from generated source code fragments. Normal C, C++ and
-# Fortran comments will always remain visible.
-# The default value is: YES.
-
-STRIP_CODE_COMMENTS = YES
-
-# If the REFERENCED_BY_RELATION tag is set to YES then for each documented
-# function all documented functions referencing it will be listed.
-# The default value is: NO.
-
-REFERENCED_BY_RELATION = YES
-
-# If the REFERENCES_RELATION tag is set to YES then for each documented function
-# all documented entities called/used by that function will be listed.
-# The default value is: NO.
-
-REFERENCES_RELATION = YES
-
-# If the REFERENCES_LINK_SOURCE tag is set to YES and SOURCE_BROWSER tag is set
-# to YES, then the hyperlinks from functions in REFERENCES_RELATION and
-# REFERENCED_BY_RELATION lists will link to the source code. Otherwise they will
-# link to the documentation.
-# The default value is: YES.
-
-REFERENCES_LINK_SOURCE = NO
-
-# If SOURCE_TOOLTIPS is enabled (the default) then hovering a hyperlink in the
-# source code will show a tooltip with additional information such as prototype,
-# brief description and links to the definition and documentation. Since this
-# will make the HTML file larger and loading of large files a bit slower, you
-# can opt to disable this feature.
-# The default value is: YES.
-# This tag requires that the tag SOURCE_BROWSER is set to YES.
-
-SOURCE_TOOLTIPS = YES
-
-# If the USE_HTAGS tag is set to YES then the references to source code will
-# point to the HTML generated by the htags(1) tool instead of doxygen built-in
-# source browser. The htags tool is part of GNU's global source tagging system
-# (see http://www.gnu.org/software/global/global.html). You will need version
-# 4.8.6 or higher.
-#
-# To use it do the following:
-# - Install the latest version of global
-# - Enable SOURCE_BROWSER and USE_HTAGS in the config file
-# - Make sure the INPUT points to the root of the source tree
-# - Run doxygen as normal
-#
-# Doxygen will invoke htags (and that will in turn invoke gtags), so these
-# tools must be available from the command line (i.e. in the search path).
-#
-# The result: instead of the source browser generated by doxygen, the links to
-# source code will now point to the output of htags.
-# The default value is: NO.
-# This tag requires that the tag SOURCE_BROWSER is set to YES.
-
-USE_HTAGS = NO
-
-# If the VERBATIM_HEADERS tag is set the YES then doxygen will generate a
-# verbatim copy of the header file for each class for which an include is
-# specified. Set to NO to disable this.
-# See also: Section \class.
-# The default value is: YES.
-
-VERBATIM_HEADERS = NO
-
-#---------------------------------------------------------------------------
-# Configuration options related to the alphabetical class index
-#---------------------------------------------------------------------------
-
-# If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index of all
-# compounds will be generated. Enable this if the project contains a lot of
-# classes, structs, unions or interfaces.
-# The default value is: YES.
-
-ALPHABETICAL_INDEX = NO
-
-# The COLS_IN_ALPHA_INDEX tag can be used to specify the number of columns in
-# which the alphabetical index list will be split.
-# Minimum value: 1, maximum value: 20, default value: 5.
-# This tag requires that the tag ALPHABETICAL_INDEX is set to YES.
-
-COLS_IN_ALPHA_INDEX = 5
-
-# In case all classes in a project start with a common prefix, all classes will
-# be put under the same header in the alphabetical index. The IGNORE_PREFIX tag
-# can be used to specify a prefix (or a list of prefixes) that should be ignored
-# while generating the index headers.
-# This tag requires that the tag ALPHABETICAL_INDEX is set to YES.
-
-IGNORE_PREFIX =
-
-#---------------------------------------------------------------------------
-# Configuration options related to the HTML output
-#---------------------------------------------------------------------------
-
-# If the GENERATE_HTML tag is set to YES doxygen will generate HTML output
-# The default value is: YES.
-
-GENERATE_HTML = YES
-
-# The HTML_OUTPUT tag is used to specify where the HTML docs will be put. If a
-# relative path is entered the value of OUTPUT_DIRECTORY will be put in front of
-# it.
-# The default directory is: html.
-# This tag requires that the tag GENERATE_HTML is set to YES.
-
-HTML_OUTPUT = html
-
-# The HTML_FILE_EXTENSION tag can be used to specify the file extension for each
-# generated HTML page (for example: .htm, .php, .asp).
-# The default value is: .html.
-# This tag requires that the tag GENERATE_HTML is set to YES.
-
-HTML_FILE_EXTENSION = .html
-
-# The HTML_HEADER tag can be used to specify a user-defined HTML header file for
-# each generated HTML page. If the tag is left blank doxygen will generate a
-# standard header.
-#
-# To get valid HTML the header file that includes any scripts and style sheets
-# that doxygen needs, which is dependent on the configuration options used (e.g.
-# the setting GENERATE_TREEVIEW). It is highly recommended to start with a
-# default header using
-# doxygen -w html new_header.html new_footer.html new_stylesheet.css
-# YourConfigFile
-# and then modify the file new_header.html. See also section "Doxygen usage"
-# for information on how to generate the default header that doxygen normally
-# uses.
-# Note: The header is subject to change so you typically have to regenerate the
-# default header when upgrading to a newer version of doxygen. For a description
-# of the possible markers and block names see the documentation.
-# This tag requires that the tag GENERATE_HTML is set to YES.
-
-HTML_HEADER = ../Doxygen_Templates/cmsis_header.html
-
-# The HTML_FOOTER tag can be used to specify a user-defined HTML footer for each
-# generated HTML page. If the tag is left blank doxygen will generate a standard
-# footer. See HTML_HEADER for more information on how to generate a default
-# footer and what special commands can be used inside the footer. See also
-# section "Doxygen usage" for information on how to generate the default footer
-# that doxygen normally uses.
-# This tag requires that the tag GENERATE_HTML is set to YES.
-
-HTML_FOOTER = ../Doxygen_Templates/cmsis_footer.html
-
-# The HTML_STYLESHEET tag can be used to specify a user-defined cascading style
-# sheet that is used by each HTML page. It can be used to fine-tune the look of
-# the HTML output. If left blank doxygen will generate a default style sheet.
-# See also section "Doxygen usage" for information on how to generate the style
-# sheet that doxygen normally uses.
-# Note: It is recommended to use HTML_EXTRA_STYLESHEET instead of this tag, as
-# it is more robust and this tag (HTML_STYLESHEET) will in the future become
-# obsolete.
-# This tag requires that the tag GENERATE_HTML is set to YES.
-
-HTML_STYLESHEET =
-
-# The HTML_EXTRA_STYLESHEET tag can be used to specify an additional user-
-# defined cascading style sheet that is included after the standard style sheets
-# created by doxygen. Using this option one can overrule certain style aspects.
-# This is preferred over using HTML_STYLESHEET since it does not replace the
-# standard style sheet and is therefor more robust against future updates.
-# Doxygen will copy the style sheet file to the output directory. For an example
-# see the documentation.
-# This tag requires that the tag GENERATE_HTML is set to YES.
-
-HTML_EXTRA_STYLESHEET = ../Doxygen_Templates/cmsis.css
-
-# The HTML_EXTRA_FILES tag can be used to specify one or more extra images or
-# other source files which should be copied to the HTML output directory. Note
-# that these files will be copied to the base HTML output directory. Use the
-# $relpath^ marker in the HTML_HEADER and/or HTML_FOOTER files to load these
-# files. In the HTML_STYLESHEET file, use the file name only. Also note that the
-# files will be copied as-is; there are no commands or markers available.
-# This tag requires that the tag GENERATE_HTML is set to YES.
-
-HTML_EXTRA_FILES = ../Doxygen_Templates/tabs.css \
- ../Doxygen_Templates/tab_topnav.png \
- "../../../LICENSE.txt" \
- ../Doxygen_Templates/printComponentTabs.js
-
-# The HTML_COLORSTYLE_HUE tag controls the color of the HTML output. Doxygen
-# will adjust the colors in the stylesheet and background images according to
-# this color. Hue is specified as an angle on a colorwheel, see
-# http://en.wikipedia.org/wiki/Hue for more information. For instance the value
-# 0 represents red, 60 is yellow, 120 is green, 180 is cyan, 240 is blue, 300
-# purple, and 360 is red again.
-# Minimum value: 0, maximum value: 359, default value: 220.
-# This tag requires that the tag GENERATE_HTML is set to YES.
-
-HTML_COLORSTYLE_HUE = 220
-
-# The HTML_COLORSTYLE_SAT tag controls the purity (or saturation) of the colors
-# in the HTML output. For a value of 0 the output will use grayscales only. A
-# value of 255 will produce the most vivid colors.
-# Minimum value: 0, maximum value: 255, default value: 100.
-# This tag requires that the tag GENERATE_HTML is set to YES.
-
-HTML_COLORSTYLE_SAT = 100
-
-# The HTML_COLORSTYLE_GAMMA tag controls the gamma correction applied to the
-# luminance component of the colors in the HTML output. Values below 100
-# gradually make the output lighter, whereas values above 100 make the output
-# darker. The value divided by 100 is the actual gamma applied, so 80 represents
-# a gamma of 0.8, The value 220 represents a gamma of 2.2, and 100 does not
-# change the gamma.
-# Minimum value: 40, maximum value: 240, default value: 80.
-# This tag requires that the tag GENERATE_HTML is set to YES.
-
-HTML_COLORSTYLE_GAMMA = 80
-
-# If the HTML_TIMESTAMP tag is set to YES then the footer of each generated HTML
-# page will contain the date and time when the page was generated. Setting this
-# to NO can help when comparing the output of multiple runs.
-# The default value is: YES.
-# This tag requires that the tag GENERATE_HTML is set to YES.
-
-HTML_TIMESTAMP = YES
-
-# If the HTML_DYNAMIC_SECTIONS tag is set to YES then the generated HTML
-# documentation will contain sections that can be hidden and shown after the
-# page has loaded.
-# The default value is: NO.
-# This tag requires that the tag GENERATE_HTML is set to YES.
-
-HTML_DYNAMIC_SECTIONS = NO
-
-# With HTML_INDEX_NUM_ENTRIES one can control the preferred number of entries
-# shown in the various tree structured indices initially; the user can expand
-# and collapse entries dynamically later on. Doxygen will expand the tree to
-# such a level that at most the specified number of entries are visible (unless
-# a fully collapsed tree already exceeds this amount). So setting the number of
-# entries 1 will produce a full collapsed tree by default. 0 is a special value
-# representing an infinite number of entries and will result in a full expanded
-# tree by default.
-# Minimum value: 0, maximum value: 9999, default value: 100.
-# This tag requires that the tag GENERATE_HTML is set to YES.
-
-HTML_INDEX_NUM_ENTRIES = 100
-
-# If the GENERATE_DOCSET tag is set to YES, additional index files will be
-# generated that can be used as input for Apple's Xcode 3 integrated development
-# environment (see: http://developer.apple.com/tools/xcode/), introduced with
-# OSX 10.5 (Leopard). To create a documentation set, doxygen will generate a
-# Makefile in the HTML output directory. Running make will produce the docset in
-# that directory and running make install will install the docset in
-# ~/Library/Developer/Shared/Documentation/DocSets so that Xcode will find it at
-# startup. See http://developer.apple.com/tools/creatingdocsetswithdoxygen.html
-# for more information.
-# The default value is: NO.
-# This tag requires that the tag GENERATE_HTML is set to YES.
-
-GENERATE_DOCSET = NO
-
-# This tag determines the name of the docset feed. A documentation feed provides
-# an umbrella under which multiple documentation sets from a single provider
-# (such as a company or product suite) can be grouped.
-# The default value is: Doxygen generated docs.
-# This tag requires that the tag GENERATE_DOCSET is set to YES.
-
-DOCSET_FEEDNAME = "Doxygen generated docs"
-
-# This tag specifies a string that should uniquely identify the documentation
-# set bundle. This should be a reverse domain-name style string, e.g.
-# com.mycompany.MyDocSet. Doxygen will append .docset to the name.
-# The default value is: org.doxygen.Project.
-# This tag requires that the tag GENERATE_DOCSET is set to YES.
-
-DOCSET_BUNDLE_ID = org.doxygen.Project
-
-# The DOCSET_PUBLISHER_ID tag specifies a string that should uniquely identify
-# the documentation publisher. This should be a reverse domain-name style
-# string, e.g. com.mycompany.MyDocSet.documentation.
-# The default value is: org.doxygen.Publisher.
-# This tag requires that the tag GENERATE_DOCSET is set to YES.
-
-DOCSET_PUBLISHER_ID = org.doxygen.Publisher
-
-# The DOCSET_PUBLISHER_NAME tag identifies the documentation publisher.
-# The default value is: Publisher.
-# This tag requires that the tag GENERATE_DOCSET is set to YES.
-
-DOCSET_PUBLISHER_NAME = Publisher
-
-# If the GENERATE_HTMLHELP tag is set to YES then doxygen generates three
-# additional HTML index files: index.hhp, index.hhc, and index.hhk. The
-# index.hhp is a project file that can be read by Microsoft's HTML Help Workshop
-# (see: http://www.microsoft.com/en-us/download/details.aspx?id=21138) on
-# Windows.
-#
-# The HTML Help Workshop contains a compiler that can convert all HTML output
-# generated by doxygen into a single compiled HTML file (.chm). Compiled HTML
-# files are now used as the Windows 98 help format, and will replace the old
-# Windows help format (.hlp) on all Windows platforms in the future. Compressed
-# HTML files also contain an index, a table of contents, and you can search for
-# words in the documentation. The HTML workshop also contains a viewer for
-# compressed HTML files.
-# The default value is: NO.
-# This tag requires that the tag GENERATE_HTML is set to YES.
-
-GENERATE_HTMLHELP = NO
-
-# The CHM_FILE tag can be used to specify the file name of the resulting .chm
-# file. You can add a path in front of the file if the result should not be
-# written to the html output directory.
-# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
-
-CHM_FILE =
-
-# The HHC_LOCATION tag can be used to specify the location (absolute path
-# including file name) of the HTML help compiler ( hhc.exe). If non-empty
-# doxygen will try to run the HTML help compiler on the generated index.hhp.
-# The file has to be specified with full path.
-# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
-
-HHC_LOCATION =
-
-# The GENERATE_CHI flag controls if a separate .chi index file is generated (
-# YES) or that it should be included in the master .chm file ( NO).
-# The default value is: NO.
-# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
-
-GENERATE_CHI = NO
-
-# The CHM_INDEX_ENCODING is used to encode HtmlHelp index ( hhk), content ( hhc)
-# and project file content.
-# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
-
-CHM_INDEX_ENCODING =
-
-# The BINARY_TOC flag controls whether a binary table of contents is generated (
-# YES) or a normal table of contents ( NO) in the .chm file.
-# The default value is: NO.
-# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
-
-BINARY_TOC = NO
-
-# The TOC_EXPAND flag can be set to YES to add extra items for group members to
-# the table of contents of the HTML help documentation and to the tree view.
-# The default value is: NO.
-# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
-
-TOC_EXPAND = NO
-
-# If the GENERATE_QHP tag is set to YES and both QHP_NAMESPACE and
-# QHP_VIRTUAL_FOLDER are set, an additional index file will be generated that
-# can be used as input for Qt's qhelpgenerator to generate a Qt Compressed Help
-# (.qch) of the generated HTML documentation.
-# The default value is: NO.
-# This tag requires that the tag GENERATE_HTML is set to YES.
-
-GENERATE_QHP = NO
-
-# If the QHG_LOCATION tag is specified, the QCH_FILE tag can be used to specify
-# the file name of the resulting .qch file. The path specified is relative to
-# the HTML output folder.
-# This tag requires that the tag GENERATE_QHP is set to YES.
-
-QCH_FILE =
-
-# The QHP_NAMESPACE tag specifies the namespace to use when generating Qt Help
-# Project output. For more information please see Qt Help Project / Namespace
-# (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#namespace).
-# The default value is: org.doxygen.Project.
-# This tag requires that the tag GENERATE_QHP is set to YES.
-
-QHP_NAMESPACE = org.doxygen.Project
-
-# The QHP_VIRTUAL_FOLDER tag specifies the namespace to use when generating Qt
-# Help Project output. For more information please see Qt Help Project / Virtual
-# Folders (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#virtual-
-# folders).
-# The default value is: doc.
-# This tag requires that the tag GENERATE_QHP is set to YES.
-
-QHP_VIRTUAL_FOLDER = doc
-
-# If the QHP_CUST_FILTER_NAME tag is set, it specifies the name of a custom
-# filter to add. For more information please see Qt Help Project / Custom
-# Filters (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#custom-
-# filters).
-# This tag requires that the tag GENERATE_QHP is set to YES.
-
-QHP_CUST_FILTER_NAME =
-
-# The QHP_CUST_FILTER_ATTRS tag specifies the list of the attributes of the
-# custom filter to add. For more information please see Qt Help Project / Custom
-# Filters (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#custom-
-# filters).
-# This tag requires that the tag GENERATE_QHP is set to YES.
-
-QHP_CUST_FILTER_ATTRS =
-
-# The QHP_SECT_FILTER_ATTRS tag specifies the list of the attributes this
-# project's filter section matches. Qt Help Project / Filter Attributes (see:
-# http://qt-project.org/doc/qt-4.8/qthelpproject.html#filter-attributes).
-# This tag requires that the tag GENERATE_QHP is set to YES.
-
-QHP_SECT_FILTER_ATTRS =
-
-# The QHG_LOCATION tag can be used to specify the location of Qt's
-# qhelpgenerator. If non-empty doxygen will try to run qhelpgenerator on the
-# generated .qhp file.
-# This tag requires that the tag GENERATE_QHP is set to YES.
-
-QHG_LOCATION =
-
-# If the GENERATE_ECLIPSEHELP tag is set to YES, additional index files will be
-# generated, together with the HTML files, they form an Eclipse help plugin. To
-# install this plugin and make it available under the help contents menu in
-# Eclipse, the contents of the directory containing the HTML and XML files needs
-# to be copied into the plugins directory of eclipse. The name of the directory
-# within the plugins directory should be the same as the ECLIPSE_DOC_ID value.
-# After copying Eclipse needs to be restarted before the help appears.
-# The default value is: NO.
-# This tag requires that the tag GENERATE_HTML is set to YES.
-
-GENERATE_ECLIPSEHELP = NO
-
-# A unique identifier for the Eclipse help plugin. When installing the plugin
-# the directory name containing the HTML and XML files should also have this
-# name. Each documentation set should have its own identifier.
-# The default value is: org.doxygen.Project.
-# This tag requires that the tag GENERATE_ECLIPSEHELP is set to YES.
-
-ECLIPSE_DOC_ID = org.doxygen.Project
-
-# If you want full control over the layout of the generated HTML pages it might
-# be necessary to disable the index and replace it with your own. The
-# DISABLE_INDEX tag can be used to turn on/off the condensed index (tabs) at top
-# of each HTML page. A value of NO enables the index and the value YES disables
-# it. Since the tabs in the index contain the same information as the navigation
-# tree, you can set this option to YES if you also set GENERATE_TREEVIEW to YES.
-# The default value is: NO.
-# This tag requires that the tag GENERATE_HTML is set to YES.
-
-DISABLE_INDEX = NO
-
-# The GENERATE_TREEVIEW tag is used to specify whether a tree-like index
-# structure should be generated to display hierarchical information. If the tag
-# value is set to YES, a side panel will be generated containing a tree-like
-# index structure (just like the one that is generated for HTML Help). For this
-# to work a browser that supports JavaScript, DHTML, CSS and frames is required
-# (i.e. any modern browser). Windows users are probably better off using the
-# HTML help feature. Via custom stylesheets (see HTML_EXTRA_STYLESHEET) one can
-# further fine-tune the look of the index. As an example, the default style
-# sheet generated by doxygen has an example that shows how to put an image at
-# the root of the tree instead of the PROJECT_NAME. Since the tree basically has
-# the same information as the tab index, you could consider setting
-# DISABLE_INDEX to YES when enabling this option.
-# The default value is: NO.
-# This tag requires that the tag GENERATE_HTML is set to YES.
-
-GENERATE_TREEVIEW = YES
-
-# The ENUM_VALUES_PER_LINE tag can be used to set the number of enum values that
-# doxygen will group on one line in the generated HTML documentation.
-#
-# Note that a value of 0 will completely suppress the enum values from appearing
-# in the overview section.
-# Minimum value: 0, maximum value: 20, default value: 4.
-# This tag requires that the tag GENERATE_HTML is set to YES.
-
-ENUM_VALUES_PER_LINE = 0
-
-# If the treeview is enabled (see GENERATE_TREEVIEW) then this tag can be used
-# to set the initial width (in pixels) of the frame in which the tree is shown.
-# Minimum value: 0, maximum value: 1500, default value: 250.
-# This tag requires that the tag GENERATE_HTML is set to YES.
-
-TREEVIEW_WIDTH = 250
-
-# When the EXT_LINKS_IN_WINDOW option is set to YES doxygen will open links to
-# external symbols imported via tag files in a separate window.
-# The default value is: NO.
-# This tag requires that the tag GENERATE_HTML is set to YES.
-
-EXT_LINKS_IN_WINDOW = NO
-
-# Use this tag to change the font size of LaTeX formulas included as images in
-# the HTML documentation. When you change the font size after a successful
-# doxygen run you need to manually remove any form_*.png images from the HTML
-# output directory to force them to be regenerated.
-# Minimum value: 8, maximum value: 50, default value: 10.
-# This tag requires that the tag GENERATE_HTML is set to YES.
-
-FORMULA_FONTSIZE = 10
-
-# Use the FORMULA_TRANPARENT tag to determine whether or not the images
-# generated for formulas are transparent PNGs. Transparent PNGs are not
-# supported properly for IE 6.0, but are supported on all modern browsers.
-#
-# Note that when changing this option you need to delete any form_*.png files in
-# the HTML output directory before the changes have effect.
-# The default value is: YES.
-# This tag requires that the tag GENERATE_HTML is set to YES.
-
-FORMULA_TRANSPARENT = YES
-
-# Enable the USE_MATHJAX option to render LaTeX formulas using MathJax (see
-# http://www.mathjax.org) which uses client side Javascript for the rendering
-# instead of using prerendered bitmaps. Use this if you do not have LaTeX
-# installed or if you want to formulas look prettier in the HTML output. When
-# enabled you may also need to install MathJax separately and configure the path
-# to it using the MATHJAX_RELPATH option.
-# The default value is: NO.
-# This tag requires that the tag GENERATE_HTML is set to YES.
-
-USE_MATHJAX = NO
-
-# When MathJax is enabled you can set the default output format to be used for
-# the MathJax output. See the MathJax site (see:
-# http://docs.mathjax.org/en/latest/output.html) for more details.
-# Possible values are: HTML-CSS (which is slower, but has the best
-# compatibility), NativeMML (i.e. MathML) and SVG.
-# The default value is: HTML-CSS.
-# This tag requires that the tag USE_MATHJAX is set to YES.
-
-MATHJAX_FORMAT = HTML-CSS
-
-# When MathJax is enabled you need to specify the location relative to the HTML
-# output directory using the MATHJAX_RELPATH option. The destination directory
-# should contain the MathJax.js script. For instance, if the mathjax directory
-# is located at the same level as the HTML output directory, then
-# MATHJAX_RELPATH should be ../mathjax. The default value points to the MathJax
-# Content Delivery Network so you can quickly see the result without installing
-# MathJax. However, it is strongly recommended to install a local copy of
-# MathJax from http://www.mathjax.org before deployment.
-# The default value is: http://cdn.mathjax.org/mathjax/latest.
-# This tag requires that the tag USE_MATHJAX is set to YES.
-
-MATHJAX_RELPATH = http://www.mathjax.org/mathjax
-
-# The MATHJAX_EXTENSIONS tag can be used to specify one or more MathJax
-# extension names that should be enabled during MathJax rendering. For example
-# MATHJAX_EXTENSIONS = TeX/AMSmath TeX/AMSsymbols
-# This tag requires that the tag USE_MATHJAX is set to YES.
-
-MATHJAX_EXTENSIONS =
-
-# The MATHJAX_CODEFILE tag can be used to specify a file with javascript pieces
-# of code that will be used on startup of the MathJax code. See the MathJax site
-# (see: http://docs.mathjax.org/en/latest/output.html) for more details. For an
-# example see the documentation.
-# This tag requires that the tag USE_MATHJAX is set to YES.
-
-MATHJAX_CODEFILE =
-
-# When the SEARCHENGINE tag is enabled doxygen will generate a search box for
-# the HTML output. The underlying search engine uses javascript and DHTML and
-# should work on any modern browser. Note that when using HTML help
-# (GENERATE_HTMLHELP), Qt help (GENERATE_QHP), or docsets (GENERATE_DOCSET)
-# there is already a search function so this one should typically be disabled.
-# For large projects the javascript based search engine can be slow, then
-# enabling SERVER_BASED_SEARCH may provide a better solution. It is possible to
-# search using the keyboard; to jump to the search box use + S
-# (what the is depends on the OS and browser, but it is typically
-# , /, or both). Inside the search box use the to jump into the search results window, the results can be navigated
-# using the . Press to select an item or to cancel
-# the search. The filter options can be selected when the cursor is inside the
-# search box by pressing +. Also here use the
-# to select a filter and or to activate or cancel the filter
-# option.
-# The default value is: YES.
-# This tag requires that the tag GENERATE_HTML is set to YES.
-
-SEARCHENGINE = NO
-
-# When the SERVER_BASED_SEARCH tag is enabled the search engine will be
-# implemented using a web server instead of a web client using Javascript. There
-# are two flavours of web server based searching depending on the
-# EXTERNAL_SEARCH setting. When disabled, doxygen will generate a PHP script for
-# searching and an index file used by the script. When EXTERNAL_SEARCH is
-# enabled the indexing and searching needs to be provided by external tools. See
-# the section "External Indexing and Searching" for details.
-# The default value is: NO.
-# This tag requires that the tag SEARCHENGINE is set to YES.
-
-SERVER_BASED_SEARCH = NO
-
-# When EXTERNAL_SEARCH tag is enabled doxygen will no longer generate the PHP
-# script for searching. Instead the search results are written to an XML file
-# which needs to be processed by an external indexer. Doxygen will invoke an
-# external search engine pointed to by the SEARCHENGINE_URL option to obtain the
-# search results.
-#
-# Doxygen ships with an example indexer ( doxyindexer) and search engine
-# (doxysearch.cgi) which are based on the open source search engine library
-# Xapian (see: http://xapian.org/).
-#
-# See the section "External Indexing and Searching" for details.
-# The default value is: NO.
-# This tag requires that the tag SEARCHENGINE is set to YES.
-
-EXTERNAL_SEARCH = NO
-
-# The SEARCHENGINE_URL should point to a search engine hosted by a web server
-# which will return the search results when EXTERNAL_SEARCH is enabled.
-#
-# Doxygen ships with an example indexer ( doxyindexer) and search engine
-# (doxysearch.cgi) which are based on the open source search engine library
-# Xapian (see: http://xapian.org/). See the section "External Indexing and
-# Searching" for details.
-# This tag requires that the tag SEARCHENGINE is set to YES.
-
-SEARCHENGINE_URL =
-
-# When SERVER_BASED_SEARCH and EXTERNAL_SEARCH are both enabled the unindexed
-# search data is written to a file for indexing by an external tool. With the
-# SEARCHDATA_FILE tag the name of this file can be specified.
-# The default file is: searchdata.xml.
-# This tag requires that the tag SEARCHENGINE is set to YES.
-
-SEARCHDATA_FILE = searchdata.xml
-
-# When SERVER_BASED_SEARCH and EXTERNAL_SEARCH are both enabled the
-# EXTERNAL_SEARCH_ID tag can be used as an identifier for the project. This is
-# useful in combination with EXTRA_SEARCH_MAPPINGS to search through multiple
-# projects and redirect the results back to the right project.
-# This tag requires that the tag SEARCHENGINE is set to YES.
-
-EXTERNAL_SEARCH_ID =
-
-# The EXTRA_SEARCH_MAPPINGS tag can be used to enable searching through doxygen
-# projects other than the one defined by this configuration file, but that are
-# all added to the same external search index. Each project needs to have a
-# unique id set via EXTERNAL_SEARCH_ID. The search mapping then maps the id of
-# to a relative location where the documentation can be found. The format is:
-# EXTRA_SEARCH_MAPPINGS = tagname1=loc1 tagname2=loc2 ...
-# This tag requires that the tag SEARCHENGINE is set to YES.
-
-EXTRA_SEARCH_MAPPINGS =
-
-#---------------------------------------------------------------------------
-# Configuration options related to the LaTeX output
-#---------------------------------------------------------------------------
-
-# If the GENERATE_LATEX tag is set to YES doxygen will generate LaTeX output.
-# The default value is: YES.
-
-GENERATE_LATEX = NO
-
-# The LATEX_OUTPUT tag is used to specify where the LaTeX docs will be put. If a
-# relative path is entered the value of OUTPUT_DIRECTORY will be put in front of
-# it.
-# The default directory is: latex.
-# This tag requires that the tag GENERATE_LATEX is set to YES.
-
-LATEX_OUTPUT = latex
-
-# The LATEX_CMD_NAME tag can be used to specify the LaTeX command name to be
-# invoked.
-#
-# Note that when enabling USE_PDFLATEX this option is only used for generating
-# bitmaps for formulas in the HTML output, but not in the Makefile that is
-# written to the output directory.
-# The default file is: latex.
-# This tag requires that the tag GENERATE_LATEX is set to YES.
-
-LATEX_CMD_NAME = latex
-
-# The MAKEINDEX_CMD_NAME tag can be used to specify the command name to generate
-# index for LaTeX.
-# The default file is: makeindex.
-# This tag requires that the tag GENERATE_LATEX is set to YES.
-
-MAKEINDEX_CMD_NAME = makeindex
-
-# If the COMPACT_LATEX tag is set to YES doxygen generates more compact LaTeX
-# documents. This may be useful for small projects and may help to save some
-# trees in general.
-# The default value is: NO.
-# This tag requires that the tag GENERATE_LATEX is set to YES.
-
-COMPACT_LATEX = NO
-
-# The PAPER_TYPE tag can be used to set the paper type that is used by the
-# printer.
-# Possible values are: a4 (210 x 297 mm), letter (8.5 x 11 inches), legal (8.5 x
-# 14 inches) and executive (7.25 x 10.5 inches).
-# The default value is: a4.
-# This tag requires that the tag GENERATE_LATEX is set to YES.
-
-PAPER_TYPE = a4
-
-# The EXTRA_PACKAGES tag can be used to specify one or more LaTeX package names
-# that should be included in the LaTeX output. To get the times font for
-# instance you can specify
-# EXTRA_PACKAGES=times
-# If left blank no extra packages will be included.
-# This tag requires that the tag GENERATE_LATEX is set to YES.
-
-EXTRA_PACKAGES =
-
-# The LATEX_HEADER tag can be used to specify a personal LaTeX header for the
-# generated LaTeX document. The header should contain everything until the first
-# chapter. If it is left blank doxygen will generate a standard header. See
-# section "Doxygen usage" for information on how to let doxygen write the
-# default header to a separate file.
-#
-# Note: Only use a user-defined header if you know what you are doing! The
-# following commands have a special meaning inside the header: $title,
-# $datetime, $date, $doxygenversion, $projectname, $projectnumber. Doxygen will
-# replace them by respectively the title of the page, the current date and time,
-# only the current date, the version number of doxygen, the project name (see
-# PROJECT_NAME), or the project number (see PROJECT_NUMBER).
-# This tag requires that the tag GENERATE_LATEX is set to YES.
-
-LATEX_HEADER =
-
-# The LATEX_FOOTER tag can be used to specify a personal LaTeX footer for the
-# generated LaTeX document. The footer should contain everything after the last
-# chapter. If it is left blank doxygen will generate a standard footer.
-#
-# Note: Only use a user-defined footer if you know what you are doing!
-# This tag requires that the tag GENERATE_LATEX is set to YES.
-
-LATEX_FOOTER =
-
-# The LATEX_EXTRA_FILES tag can be used to specify one or more extra images or
-# other source files which should be copied to the LATEX_OUTPUT output
-# directory. Note that the files will be copied as-is; there are no commands or
-# markers available.
-# This tag requires that the tag GENERATE_LATEX is set to YES.
-
-LATEX_EXTRA_FILES =
-
-# If the PDF_HYPERLINKS tag is set to YES, the LaTeX that is generated is
-# prepared for conversion to PDF (using ps2pdf or pdflatex). The PDF file will
-# contain links (just like the HTML output) instead of page references. This
-# makes the output suitable for online browsing using a PDF viewer.
-# The default value is: YES.
-# This tag requires that the tag GENERATE_LATEX is set to YES.
-
-PDF_HYPERLINKS = YES
-
-# If the LATEX_PDFLATEX tag is set to YES, doxygen will use pdflatex to generate
-# the PDF file directly from the LaTeX files. Set this option to YES to get a
-# higher quality PDF documentation.
-# The default value is: YES.
-# This tag requires that the tag GENERATE_LATEX is set to YES.
-
-USE_PDFLATEX = YES
-
-# If the LATEX_BATCHMODE tag is set to YES, doxygen will add the \batchmode
-# command to the generated LaTeX files. This will instruct LaTeX to keep running
-# if errors occur, instead of asking the user for help. This option is also used
-# when generating formulas in HTML.
-# The default value is: NO.
-# This tag requires that the tag GENERATE_LATEX is set to YES.
-
-LATEX_BATCHMODE = NO
-
-# If the LATEX_HIDE_INDICES tag is set to YES then doxygen will not include the
-# index chapters (such as File Index, Compound Index, etc.) in the output.
-# The default value is: NO.
-# This tag requires that the tag GENERATE_LATEX is set to YES.
-
-LATEX_HIDE_INDICES = NO
-
-# If the LATEX_SOURCE_CODE tag is set to YES then doxygen will include source
-# code with syntax highlighting in the LaTeX output.
-#
-# Note that which sources are shown also depends on other settings such as
-# SOURCE_BROWSER.
-# The default value is: NO.
-# This tag requires that the tag GENERATE_LATEX is set to YES.
-
-LATEX_SOURCE_CODE = NO
-
-# The LATEX_BIB_STYLE tag can be used to specify the style to use for the
-# bibliography, e.g. plainnat, or ieeetr. See
-# http://en.wikipedia.org/wiki/BibTeX and \cite for more info.
-# The default value is: plain.
-# This tag requires that the tag GENERATE_LATEX is set to YES.
-
-LATEX_BIB_STYLE = plain
-
-#---------------------------------------------------------------------------
-# Configuration options related to the RTF output
-#---------------------------------------------------------------------------
-
-# If the GENERATE_RTF tag is set to YES doxygen will generate RTF output. The
-# RTF output is optimized for Word 97 and may not look too pretty with other RTF
-# readers/editors.
-# The default value is: NO.
-
-GENERATE_RTF = NO
-
-# The RTF_OUTPUT tag is used to specify where the RTF docs will be put. If a
-# relative path is entered the value of OUTPUT_DIRECTORY will be put in front of
-# it.
-# The default directory is: rtf.
-# This tag requires that the tag GENERATE_RTF is set to YES.
-
-RTF_OUTPUT = rtf
-
-# If the COMPACT_RTF tag is set to YES doxygen generates more compact RTF
-# documents. This may be useful for small projects and may help to save some
-# trees in general.
-# The default value is: NO.
-# This tag requires that the tag GENERATE_RTF is set to YES.
-
-COMPACT_RTF = NO
-
-# If the RTF_HYPERLINKS tag is set to YES, the RTF that is generated will
-# contain hyperlink fields. The RTF file will contain links (just like the HTML
-# output) instead of page references. This makes the output suitable for online
-# browsing using Word or some other Word compatible readers that support those
-# fields.
-#
-# Note: WordPad (write) and others do not support links.
-# The default value is: NO.
-# This tag requires that the tag GENERATE_RTF is set to YES.
-
-RTF_HYPERLINKS = NO
-
-# Load stylesheet definitions from file. Syntax is similar to doxygen's config
-# file, i.e. a series of assignments. You only have to provide replacements,
-# missing definitions are set to their default value.
-#
-# See also section "Doxygen usage" for information on how to generate the
-# default style sheet that doxygen normally uses.
-# This tag requires that the tag GENERATE_RTF is set to YES.
-
-RTF_STYLESHEET_FILE =
-
-# Set optional variables used in the generation of an RTF document. Syntax is
-# similar to doxygen's config file. A template extensions file can be generated
-# using doxygen -e rtf extensionFile.
-# This tag requires that the tag GENERATE_RTF is set to YES.
-
-RTF_EXTENSIONS_FILE =
-
-#---------------------------------------------------------------------------
-# Configuration options related to the man page output
-#---------------------------------------------------------------------------
-
-# If the GENERATE_MAN tag is set to YES doxygen will generate man pages for
-# classes and files.
-# The default value is: NO.
-
-GENERATE_MAN = NO
-
-# The MAN_OUTPUT tag is used to specify where the man pages will be put. If a
-# relative path is entered the value of OUTPUT_DIRECTORY will be put in front of
-# it. A directory man3 will be created inside the directory specified by
-# MAN_OUTPUT.
-# The default directory is: man.
-# This tag requires that the tag GENERATE_MAN is set to YES.
-
-MAN_OUTPUT = man
-
-# The MAN_EXTENSION tag determines the extension that is added to the generated
-# man pages. In case the manual section does not start with a number, the number
-# 3 is prepended. The dot (.) at the beginning of the MAN_EXTENSION tag is
-# optional.
-# The default value is: .3.
-# This tag requires that the tag GENERATE_MAN is set to YES.
-
-MAN_EXTENSION = .3
-
-# If the MAN_LINKS tag is set to YES and doxygen generates man output, then it
-# will generate one additional man file for each entity documented in the real
-# man page(s). These additional files only source the real man page, but without
-# them the man command would be unable to find the correct page.
-# The default value is: NO.
-# This tag requires that the tag GENERATE_MAN is set to YES.
-
-MAN_LINKS = NO
-
-#---------------------------------------------------------------------------
-# Configuration options related to the XML output
-#---------------------------------------------------------------------------
-
-# If the GENERATE_XML tag is set to YES doxygen will generate an XML file that
-# captures the structure of the code including all documentation.
-# The default value is: NO.
-
-GENERATE_XML = NO
-
-# The XML_OUTPUT tag is used to specify where the XML pages will be put. If a
-# relative path is entered the value of OUTPUT_DIRECTORY will be put in front of
-# it.
-# The default directory is: xml.
-# This tag requires that the tag GENERATE_XML is set to YES.
-
-XML_OUTPUT = xml
-
-# The XML_SCHEMA tag can be used to specify a XML schema, which can be used by a
-# validating XML parser to check the syntax of the XML files.
-# This tag requires that the tag GENERATE_XML is set to YES.
-
-XML_SCHEMA =
-
-# The XML_DTD tag can be used to specify a XML DTD, which can be used by a
-# validating XML parser to check the syntax of the XML files.
-# This tag requires that the tag GENERATE_XML is set to YES.
-
-XML_DTD =
-
-# If the XML_PROGRAMLISTING tag is set to YES doxygen will dump the program
-# listings (including syntax highlighting and cross-referencing information) to
-# the XML output. Note that enabling this will significantly increase the size
-# of the XML output.
-# The default value is: YES.
-# This tag requires that the tag GENERATE_XML is set to YES.
-
-XML_PROGRAMLISTING = YES
-
-#---------------------------------------------------------------------------
-# Configuration options related to the DOCBOOK output
-#---------------------------------------------------------------------------
-
-# If the GENERATE_DOCBOOK tag is set to YES doxygen will generate Docbook files
-# that can be used to generate PDF.
-# The default value is: NO.
-
-GENERATE_DOCBOOK = NO
-
-# The DOCBOOK_OUTPUT tag is used to specify where the Docbook pages will be put.
-# If a relative path is entered the value of OUTPUT_DIRECTORY will be put in
-# front of it.
-# The default directory is: docbook.
-# This tag requires that the tag GENERATE_DOCBOOK is set to YES.
-
-DOCBOOK_OUTPUT = docbook
-
-#---------------------------------------------------------------------------
-# Configuration options for the AutoGen Definitions output
-#---------------------------------------------------------------------------
-
-# If the GENERATE_AUTOGEN_DEF tag is set to YES doxygen will generate an AutoGen
-# Definitions (see http://autogen.sf.net) file that captures the structure of
-# the code including all documentation. Note that this feature is still
-# experimental and incomplete at the moment.
-# The default value is: NO.
-
-GENERATE_AUTOGEN_DEF = NO
-
-#---------------------------------------------------------------------------
-# Configuration options related to the Perl module output
-#---------------------------------------------------------------------------
-
-# If the GENERATE_PERLMOD tag is set to YES doxygen will generate a Perl module
-# file that captures the structure of the code including all documentation.
-#
-# Note that this feature is still experimental and incomplete at the moment.
-# The default value is: NO.
-
-GENERATE_PERLMOD = NO
-
-# If the PERLMOD_LATEX tag is set to YES doxygen will generate the necessary
-# Makefile rules, Perl scripts and LaTeX code to be able to generate PDF and DVI
-# output from the Perl module output.
-# The default value is: NO.
-# This tag requires that the tag GENERATE_PERLMOD is set to YES.
-
-PERLMOD_LATEX = NO
-
-# If the PERLMOD_PRETTY tag is set to YES the Perl module output will be nicely
-# formatted so it can be parsed by a human reader. This is useful if you want to
-# understand what is going on. On the other hand, if this tag is set to NO the
-# size of the Perl module output will be much smaller and Perl will parse it
-# just the same.
-# The default value is: YES.
-# This tag requires that the tag GENERATE_PERLMOD is set to YES.
-
-PERLMOD_PRETTY = YES
-
-# The names of the make variables in the generated doxyrules.make file are
-# prefixed with the string contained in PERLMOD_MAKEVAR_PREFIX. This is useful
-# so different doxyrules.make files included by the same Makefile don't
-# overwrite each other's variables.
-# This tag requires that the tag GENERATE_PERLMOD is set to YES.
-
-PERLMOD_MAKEVAR_PREFIX =
-
-#---------------------------------------------------------------------------
-# Configuration options related to the preprocessor
-#---------------------------------------------------------------------------
-
-# If the ENABLE_PREPROCESSING tag is set to YES doxygen will evaluate all
-# C-preprocessor directives found in the sources and include files.
-# The default value is: YES.
-
-ENABLE_PREPROCESSING = YES
-
-# If the MACRO_EXPANSION tag is set to YES doxygen will expand all macro names
-# in the source code. If set to NO only conditional compilation will be
-# performed. Macro expansion can be done in a controlled way by setting
-# EXPAND_ONLY_PREDEF to YES.
-# The default value is: NO.
-# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
-
-MACRO_EXPANSION = NO
-
-# If the EXPAND_ONLY_PREDEF and MACRO_EXPANSION tags are both set to YES then
-# the macro expansion is limited to the macros specified with the PREDEFINED and
-# EXPAND_AS_DEFINED tags.
-# The default value is: NO.
-# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
-
-EXPAND_ONLY_PREDEF = NO
-
-# If the SEARCH_INCLUDES tag is set to YES the includes files in the
-# INCLUDE_PATH will be searched if a #include is found.
-# The default value is: YES.
-# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
-
-SEARCH_INCLUDES = YES
-
-# The INCLUDE_PATH tag can be used to specify one or more directories that
-# contain include files that are not input files but should be processed by the
-# preprocessor.
-# This tag requires that the tag SEARCH_INCLUDES is set to YES.
-
-INCLUDE_PATH =
-
-# You can use the INCLUDE_FILE_PATTERNS tag to specify one or more wildcard
-# patterns (like *.h and *.hpp) to filter out the header-files in the
-# directories. If left blank, the patterns specified with FILE_PATTERNS will be
-# used.
-# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
-
-INCLUDE_FILE_PATTERNS =
-
-# The PREDEFINED tag can be used to specify one or more macro names that are
-# defined before the preprocessor is started (similar to the -D option of e.g.
-# gcc). The argument of the tag is a list of macros of the form: name or
-# name=definition (no spaces). If the definition and the "=" are omitted, "=1"
-# is assumed. To prevent a macro definition from being undefined via #undef or
-# recursively expanded use the := operator instead of the = operator.
-# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
-
-PREDEFINED =
-
-# If the MACRO_EXPANSION and EXPAND_ONLY_PREDEF tags are set to YES then this
-# tag can be used to specify a list of macro names that should be expanded. The
-# macro definition that is found in the sources will be used. Use the PREDEFINED
-# tag if you want to use a different macro definition that overrules the
-# definition found in the source code.
-# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
-
-EXPAND_AS_DEFINED =
-
-# If the SKIP_FUNCTION_MACROS tag is set to YES then doxygen's preprocessor will
-# remove all refrences to function-like macros that are alone on a line, have an
-# all uppercase name, and do not end with a semicolon. Such function macros are
-# typically used for boiler-plate code, and will confuse the parser if not
-# removed.
-# The default value is: YES.
-# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
-
-SKIP_FUNCTION_MACROS = NO
-
-#---------------------------------------------------------------------------
-# Configuration options related to external references
-#---------------------------------------------------------------------------
-
-# The TAGFILES tag can be used to specify one or more tag files. For each tag
-# file the location of the external documentation should be added. The format of
-# a tag file without this location is as follows:
-# TAGFILES = file1 file2 ...
-# Adding location for the tag files is done as follows:
-# TAGFILES = file1=loc1 "file2 = loc2" ...
-# where loc1 and loc2 can be relative or absolute paths or URLs. See the
-# section "Linking to external documentation" for more information about the use
-# of tag files.
-# Note: Each tag file must have an unique name (where the name does NOT include
-# the path). If a tag file is not located in the directory in which doxygen is
-# run, you must also specify the path to the tagfile here.
-
-TAGFILES =
-
-# When a file name is specified after GENERATE_TAGFILE, doxygen will create a
-# tag file that is based on the input files it reads. See section "Linking to
-# external documentation" for more information about the usage of tag files.
-
-GENERATE_TAGFILE =
-
-# If the ALLEXTERNALS tag is set to YES all external class will be listed in the
-# class index. If set to NO only the inherited external classes will be listed.
-# The default value is: NO.
-
-ALLEXTERNALS = NO
-
-# If the EXTERNAL_GROUPS tag is set to YES all external groups will be listed in
-# the modules index. If set to NO, only the current project's groups will be
-# listed.
-# The default value is: YES.
-
-EXTERNAL_GROUPS = YES
-
-# If the EXTERNAL_PAGES tag is set to YES all external pages will be listed in
-# the related pages index. If set to NO, only the current project's pages will
-# be listed.
-# The default value is: YES.
-
-EXTERNAL_PAGES = YES
-
-# The PERL_PATH should be the absolute path and name of the perl script
-# interpreter (i.e. the result of 'which perl').
-# The default file (with absolute path) is: /usr/bin/perl.
-
-PERL_PATH = /usr/bin/perl
-
-#---------------------------------------------------------------------------
-# Configuration options related to the dot tool
-#---------------------------------------------------------------------------
-
-# If the CLASS_DIAGRAMS tag is set to YES doxygen will generate a class diagram
-# (in HTML and LaTeX) for classes with base or super classes. Setting the tag to
-# NO turns the diagrams off. Note that this option also works with HAVE_DOT
-# disabled, but it is recommended to install and use dot, since it yields more
-# powerful graphs.
-# The default value is: YES.
-
-CLASS_DIAGRAMS = YES
-
-# You can define message sequence charts within doxygen comments using the \msc
-# command. Doxygen will then run the mscgen tool (see:
-# http://www.mcternan.me.uk/mscgen/)) to produce the chart and insert it in the
-# documentation. The MSCGEN_PATH tag allows you to specify the directory where
-# the mscgen tool resides. If left empty the tool is assumed to be found in the
-# default search path.
-
-MSCGEN_PATH =
-
-# You can include diagrams made with dia in doxygen documentation. Doxygen will
-# then run dia to produce the diagram and insert it in the documentation. The
-# DIA_PATH tag allows you to specify the directory where the dia binary resides.
-# If left empty dia is assumed to be found in the default search path.
-
-DIA_PATH =
-
-# If set to YES, the inheritance and collaboration graphs will hide inheritance
-# and usage relations if the target is undocumented or is not a class.
-# The default value is: YES.
-
-HIDE_UNDOC_RELATIONS = YES
-
-# If you set the HAVE_DOT tag to YES then doxygen will assume the dot tool is
-# available from the path. This tool is part of Graphviz (see:
-# http://www.graphviz.org/), a graph visualization toolkit from AT&T and Lucent
-# Bell Labs. The other options in this section have no effect if this option is
-# set to NO
-# The default value is: NO.
-
-HAVE_DOT = NO
-
-# The DOT_NUM_THREADS specifies the number of dot invocations doxygen is allowed
-# to run in parallel. When set to 0 doxygen will base this on the number of
-# processors available in the system. You can set it explicitly to a value
-# larger than 0 to get control over the balance between CPU load and processing
-# speed.
-# Minimum value: 0, maximum value: 32, default value: 0.
-# This tag requires that the tag HAVE_DOT is set to YES.
-
-DOT_NUM_THREADS = 0
-
-# When you want a differently looking font n the dot files that doxygen
-# generates you can specify the font name using DOT_FONTNAME. You need to make
-# sure dot is able to find the font, which can be done by putting it in a
-# standard location or by setting the DOTFONTPATH environment variable or by
-# setting DOT_FONTPATH to the directory containing the font.
-# The default value is: Helvetica.
-# This tag requires that the tag HAVE_DOT is set to YES.
-
-DOT_FONTNAME = Helvetica
-
-# The DOT_FONTSIZE tag can be used to set the size (in points) of the font of
-# dot graphs.
-# Minimum value: 4, maximum value: 24, default value: 10.
-# This tag requires that the tag HAVE_DOT is set to YES.
-
-DOT_FONTSIZE = 10
-
-# By default doxygen will tell dot to use the default font as specified with
-# DOT_FONTNAME. If you specify a different font using DOT_FONTNAME you can set
-# the path where dot can find it using this tag.
-# This tag requires that the tag HAVE_DOT is set to YES.
-
-DOT_FONTPATH =
-
-# If the CLASS_GRAPH tag is set to YES then doxygen will generate a graph for
-# each documented class showing the direct and indirect inheritance relations.
-# Setting this tag to YES will force the CLASS_DIAGRAMS tag to NO.
-# The default value is: YES.
-# This tag requires that the tag HAVE_DOT is set to YES.
-
-CLASS_GRAPH = YES
-
-# If the COLLABORATION_GRAPH tag is set to YES then doxygen will generate a
-# graph for each documented class showing the direct and indirect implementation
-# dependencies (inheritance, containment, and class references variables) of the
-# class with other documented classes.
-# The default value is: YES.
-# This tag requires that the tag HAVE_DOT is set to YES.
-
-COLLABORATION_GRAPH = YES
-
-# If the GROUP_GRAPHS tag is set to YES then doxygen will generate a graph for
-# groups, showing the direct groups dependencies.
-# The default value is: YES.
-# This tag requires that the tag HAVE_DOT is set to YES.
-
-GROUP_GRAPHS = YES
-
-# If the UML_LOOK tag is set to YES doxygen will generate inheritance and
-# collaboration diagrams in a style similar to the OMG's Unified Modeling
-# Language.
-# The default value is: NO.
-# This tag requires that the tag HAVE_DOT is set to YES.
-
-UML_LOOK = NO
-
-# If the UML_LOOK tag is enabled, the fields and methods are shown inside the
-# class node. If there are many fields or methods and many nodes the graph may
-# become too big to be useful. The UML_LIMIT_NUM_FIELDS threshold limits the
-# number of items for each type to make the size more manageable. Set this to 0
-# for no limit. Note that the threshold may be exceeded by 50% before the limit
-# is enforced. So when you set the threshold to 10, up to 15 fields may appear,
-# but if the number exceeds 15, the total amount of fields shown is limited to
-# 10.
-# Minimum value: 0, maximum value: 100, default value: 10.
-# This tag requires that the tag HAVE_DOT is set to YES.
-
-UML_LIMIT_NUM_FIELDS = 10
-
-# If the TEMPLATE_RELATIONS tag is set to YES then the inheritance and
-# collaboration graphs will show the relations between templates and their
-# instances.
-# The default value is: NO.
-# This tag requires that the tag HAVE_DOT is set to YES.
-
-TEMPLATE_RELATIONS = NO
-
-# If the INCLUDE_GRAPH, ENABLE_PREPROCESSING and SEARCH_INCLUDES tags are set to
-# YES then doxygen will generate a graph for each documented file showing the
-# direct and indirect include dependencies of the file with other documented
-# files.
-# The default value is: YES.
-# This tag requires that the tag HAVE_DOT is set to YES.
-
-INCLUDE_GRAPH = YES
-
-# If the INCLUDED_BY_GRAPH, ENABLE_PREPROCESSING and SEARCH_INCLUDES tags are
-# set to YES then doxygen will generate a graph for each documented file showing
-# the direct and indirect include dependencies of the file with other documented
-# files.
-# The default value is: YES.
-# This tag requires that the tag HAVE_DOT is set to YES.
-
-INCLUDED_BY_GRAPH = YES
-
-# If the CALL_GRAPH tag is set to YES then doxygen will generate a call
-# dependency graph for every global function or class method.
-#
-# Note that enabling this option will significantly increase the time of a run.
-# So in most cases it will be better to enable call graphs for selected
-# functions only using the \callgraph command.
-# The default value is: NO.
-# This tag requires that the tag HAVE_DOT is set to YES.
-
-CALL_GRAPH = NO
-
-# If the CALLER_GRAPH tag is set to YES then doxygen will generate a caller
-# dependency graph for every global function or class method.
-#
-# Note that enabling this option will significantly increase the time of a run.
-# So in most cases it will be better to enable caller graphs for selected
-# functions only using the \callergraph command.
-# The default value is: NO.
-# This tag requires that the tag HAVE_DOT is set to YES.
-
-CALLER_GRAPH = NO
-
-# If the GRAPHICAL_HIERARCHY tag is set to YES then doxygen will graphical
-# hierarchy of all classes instead of a textual one.
-# The default value is: YES.
-# This tag requires that the tag HAVE_DOT is set to YES.
-
-GRAPHICAL_HIERARCHY = YES
-
-# If the DIRECTORY_GRAPH tag is set to YES then doxygen will show the
-# dependencies a directory has on other directories in a graphical way. The
-# dependency relations are determined by the #include relations between the
-# files in the directories.
-# The default value is: YES.
-# This tag requires that the tag HAVE_DOT is set to YES.
-
-DIRECTORY_GRAPH = YES
-
-# The DOT_IMAGE_FORMAT tag can be used to set the image format of the images
-# generated by dot.
-# Note: If you choose svg you need to set HTML_FILE_EXTENSION to xhtml in order
-# to make the SVG files visible in IE 9+ (other browsers do not have this
-# requirement).
-# Possible values are: png, jpg, gif and svg.
-# The default value is: png.
-# This tag requires that the tag HAVE_DOT is set to YES.
-
-DOT_IMAGE_FORMAT = png
-
-# If DOT_IMAGE_FORMAT is set to svg, then this option can be set to YES to
-# enable generation of interactive SVG images that allow zooming and panning.
-#
-# Note that this requires a modern browser other than Internet Explorer. Tested
-# and working are Firefox, Chrome, Safari, and Opera.
-# Note: For IE 9+ you need to set HTML_FILE_EXTENSION to xhtml in order to make
-# the SVG files visible. Older versions of IE do not have SVG support.
-# The default value is: NO.
-# This tag requires that the tag HAVE_DOT is set to YES.
-
-INTERACTIVE_SVG = NO
-
-# The DOT_PATH tag can be used to specify the path where the dot tool can be
-# found. If left blank, it is assumed the dot tool can be found in the path.
-# This tag requires that the tag HAVE_DOT is set to YES.
-
-DOT_PATH =
-
-# The DOTFILE_DIRS tag can be used to specify one or more directories that
-# contain dot files that are included in the documentation (see the \dotfile
-# command).
-# This tag requires that the tag HAVE_DOT is set to YES.
-
-DOTFILE_DIRS =
-
-# The MSCFILE_DIRS tag can be used to specify one or more directories that
-# contain msc files that are included in the documentation (see the \mscfile
-# command).
-
-MSCFILE_DIRS =
-
-# The DIAFILE_DIRS tag can be used to specify one or more directories that
-# contain dia files that are included in the documentation (see the \diafile
-# command).
-
-DIAFILE_DIRS =
-
-# The DOT_GRAPH_MAX_NODES tag can be used to set the maximum number of nodes
-# that will be shown in the graph. If the number of nodes in a graph becomes
-# larger than this value, doxygen will truncate the graph, which is visualized
-# by representing a node as a red box. Note that doxygen if the number of direct
-# children of the root node in a graph is already larger than
-# DOT_GRAPH_MAX_NODES then the graph will not be shown at all. Also note that
-# the size of a graph can be further restricted by MAX_DOT_GRAPH_DEPTH.
-# Minimum value: 0, maximum value: 10000, default value: 50.
-# This tag requires that the tag HAVE_DOT is set to YES.
-
-DOT_GRAPH_MAX_NODES = 50
-
-# The MAX_DOT_GRAPH_DEPTH tag can be used to set the maximum depth of the graphs
-# generated by dot. A depth value of 3 means that only nodes reachable from the
-# root by following a path via at most 3 edges will be shown. Nodes that lay
-# further from the root node will be omitted. Note that setting this option to 1
-# or 2 may greatly reduce the computation time needed for large code bases. Also
-# note that the size of a graph can be further restricted by
-# DOT_GRAPH_MAX_NODES. Using a depth of 0 means no depth restriction.
-# Minimum value: 0, maximum value: 1000, default value: 0.
-# This tag requires that the tag HAVE_DOT is set to YES.
-
-MAX_DOT_GRAPH_DEPTH = 0
-
-# Set the DOT_TRANSPARENT tag to YES to generate images with a transparent
-# background. This is disabled by default, because dot on Windows does not seem
-# to support this out of the box.
-#
-# Warning: Depending on the platform used, enabling this option may lead to
-# badly anti-aliased labels on the edges of a graph (i.e. they become hard to
-# read).
-# The default value is: NO.
-# This tag requires that the tag HAVE_DOT is set to YES.
-
-DOT_TRANSPARENT = NO
-
-# Set the DOT_MULTI_TARGETS tag to YES allow dot to generate multiple output
-# files in one run (i.e. multiple -o and -T options on the command line). This
-# makes dot run faster, but since only newer versions of dot (>1.8.10) support
-# this, this feature is disabled by default.
-# The default value is: NO.
-# This tag requires that the tag HAVE_DOT is set to YES.
-
-DOT_MULTI_TARGETS = NO
-
-# If the GENERATE_LEGEND tag is set to YES doxygen will generate a legend page
-# explaining the meaning of the various boxes and arrows in the dot generated
-# graphs.
-# The default value is: YES.
-# This tag requires that the tag HAVE_DOT is set to YES.
-
-GENERATE_LEGEND = YES
-
-# If the DOT_CLEANUP tag is set to YES doxygen will remove the intermediate dot
-# files that are used to generate the various graphs.
-# The default value is: YES.
-# This tag requires that the tag HAVE_DOT is set to YES.
-
-DOT_CLEANUP = YES
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/General/src/images/Overview.png b/external/CMSIS_5/CMSIS/DoxyGen/General/src/images/Overview.png
deleted file mode 100644
index bc5a1e5..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/General/src/images/Overview.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/General/src/introduction.txt b/external/CMSIS_5/CMSIS/DoxyGen/General/src/introduction.txt
deleted file mode 100644
index b2bdf61..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/General/src/introduction.txt
+++ /dev/null
@@ -1,572 +0,0 @@
-/**
-\mainpage Introduction
-
-The CMSIS is a set of tools, APIs, frameworks, and work flows that help to simplify software re-use, reduce the
-learning curve for microcontroller developers, speed-up project build and debug, and thus reduce the time to market for new
-applications.
-
-CMSIS started as a vendor-independent hardware abstraction layer Arm® Cortex®-M based processors and was later
-extended to support entry-level Arm Cortex-A based processors. To simplify access, CMSIS defines generic tool interfaces and
-enables consistent device support by providing simple software interfaces to the processor and the peripherals.
-
-CMSIS is defined in close cooperation with various silicon and software vendors and provides a common approach to interface
-to peripherals, real-time operating systems, and middleware components. It is intended to enable the combination of software
-components from multiple vendors.
-
-CMSIS is open-source and collaboratively developed on
-GitHub .
-
-\section CM_Components CMSIS Components
-
-| CMSIS-... | Target Processors | Description |
-|:----------|:--------------------|:-------------|
-|Core(M) Core(A) Driver DSP NN RTOS v1 RTOS v2 Pack Open CMSIS Pack project Build CMSIS-Toolbox SVD DAP Zone .
- - Variables and parameters have a complete data type.
- - Expressions for \c \#define constants are enclosed in parenthesis.
- - Conforms to MISRA 2012 (but does not claim MISRA compliance). MISRA rule violations are documented.
-
-In addition, the CMSIS recommends the following conventions for identifiers:
- - \b CAPITAL names to identify Core Registers, Peripheral Registers, and CPU Instructions.
- - \b CamelCase names to identify function names and interrupt functions.
- - \b Namespace_ prefixes avoid clashes with user identifiers and provide functional groups (i.e. for peripherals, RTOS, or DSP Library).
-
-The CMSIS is documented within the source files with:
- \li Comments that use the C or C++ style.
- \li Doxygen compliant function comments that provide:
- - brief function overview.
- - detailed description of the function.
- - detailed parameter explanation.
- - detailed information about return values.
-
-Doxygen comment example:
-\verbatim
-/**
- * @brief Enable Interrupt in NVIC Interrupt Controller
- * @param IRQn interrupt number that specifies the interrupt
- * @return none.
- * Enable the specified interrupt in the NVIC Interrupt Controller.
- * Other settings of the interrupt such as priority are not affected.
- */
-\endverbatim
-
-
-\section Validation Validation
-
-The various components of CMSIS are validated using mainstream compilers. To get a diverse coverage, Arm Compiler v5 (based
-on EDG front-end), Arm Compiler v6 (based on LLVM front-end), and GCC are used in the various tests. For each component, the
-section \b "Validation" describes the scope of the various verification steps.
-
-CMSIS components are compatible with a range of C and C++ language standards. The CMSIS components comply with the
-Application Binary Interface (ABI) for the Arm
-Architecture (exception CMSIS-RTOS v1). This ensures C API interfaces that support inter-operation between various
-toolchains.
-
-As CMSIS defines API interfaces and functions that scale to a wide range of processors and devices, the scope of
-the run-time test coverage is limited. However, several components are validated using dedicated test suites
-(CMSIS-Driver ,
-CMSIS-RTOS v1 , and
-CMSIS-RTOS v2 ).
-
-The CMSIS source code is checked for MISRA C:2012 conformance using PC-Lint. MISRA deviations are documented with
-reasonable effort, however Arm does not claim MISRA compliance as there is today for example no guideline enforcement
-plan. The CMSIS source code is not checked for MISRA C++:2008 conformance as there is a risk that it is incompatible
-with C language standards, specifically warnings that may be generated by the various C compilers.
-
-
-\section License License
-
-CMSIS is provided free of charge by Arm under the Apache 2.0 License .
-
-
-\section CM_Pack_Content CMSIS Software Pack
-
-CMSIS itself is delivered in CMSIS-Pack format. The ARM::CMSIS pack contains
-the following:
-
-File/Directory |Content
-:-----------------|:---------------------------------------------------------------------------------
-\b ARM.CMSIS.pdsc |Package description file in CMSIS-Pack format.
-\b LICENSE.txt |CMSIS License Agreement (Apache 2.0)
-\b CMSIS |\ref CM_Components "CMSIS components" (see also table below)
-\b Device |CMSIS reference implementations of Arm Cortex processor based devices
-
-CMSIS Directory
----------------
-
-Directory |Content
-:-------------------------|:----------------------------------------------------------------------------------------------------------------------------------------
-\b Core |User code templates for CMSIS-Core (Cortex-M) CMSIS-Core (Cortex-A) CMSIS-DAP CMSIS-Driver CMSIS-DSP CMSIS-Core (Cortex-M) CMSIS-DSP CMSIS-NN CMSIS-Pack CMSIS-RTOS Version 1 CMSIS-RTOS Version 2 CMSIS-SVD CMSIS-Pack schema fileCMSIS-SVD schema fileCMSIS-Build schema fileCore (Cortex-M) Revision History Core (Cortex-A) Revision History Driver Revision History DSP Revision History (Change Log) NN Revision History (Change Log) RTOS v1 Revision History RTOS v2 Revision History Pack Revision History SVD Revision History DAP Revision History Zone Revision History
-
- Version
- Description
-
-
- 5.9.0
-
- - CMSIS-Core(M): 5.6.0 (see revision history for details)
- - Arm Cortex-M85 cpu support
- - Arm China STAR-MC1 cpu support
- - Updated system_ARMCM55.c
- - CMSIS-Core(A): 1.2.1 (unchanged)
- - CMSIS-Driver: 2.8.0 (unchanged)
- - CMSIS-DSP: 1.10.0 (see revision history for details)
- - CMSIS-NN: 3.1.0 (see revision history for details)
- - Support for int16 convolution and fully connected for reference implementation
- - Support for DSP extension optimization for int16 convolution and fully connected
- - Support dilation for int8 convolution
- - Support dilation for int8 depthwise convolution
- - Support for int16 depthwise conv for reference implementation including dilation
- - Support for int16 average and max pooling for reference implementation
- - Support for elementwise add and mul int16 scalar version
- - Support for softmax int16 scalar version
- - Support for SVDF with 8 bit state tensor
- - CMSIS-RTOS2: 2.1.3 (unchanged)
- - RTX 5.5.4 (see revision history for details)
- - CMSIS-Pack: deprecated (moved to Open-CMSIS-Pack)
- - CMSIS-Build: deprecated (moved to CMSIS-Toolbox in Open-CMSIS-Pack)
- - CMSIS-SVD: 1.3.9 (see revision history for details)
- - CMSIS-DAP: 2.1.1 (see revision history for details)
- - Allow default clock frequency to use fast clock mode
- - CMSIS-Zone: 1.0.0 (unchanged)
- - Devices
- - Support for Cortex-M85
- - Utilities
- - SVDConv 3.3.42
- - PackChk 1.3.95
-
-
-
- 5.8.0
-
- - CMSIS-Build 0.10.0 (beta)
- - Enhancements (see revision history for details)
- - CMSIS-Core (Cortex-M) 5.5.0
- - Updated GCC LinkerDescription, GCC Assembler startup
- - Added ARMv8-M Stack Sealing (to linker, startup) for toolchain ARM, GCC
- - Changed C-Startup to default Startup.
- - CMSIS-Core (Cortex-A) 1.2.1
- - CMSIS-Driver 2.8.0 (unchanged)
- - CMSIS-DSP 1.9.0
- - Purged pre-built libs from Git
- - CMSIS-NN 3.0.0
- - Major interface change for functions compatible with TensorFlow Lite for Microcontroller
- - Added optimization for SVDF kernel
- - Improved MVE performance for fully Connected and max pool operator
- - NULL bias support for fully connected operator in non-MVE case(Can affect performance)
- - Expanded existing unit test suite along with support for FVP
- - CMSIS-RTOS 2.1.3 (unchanged)
- - RTX 5.5.3 (see revision history for details)
- - CMSIS-Pack 1.7.2
- - Support for Microchip XC32 compiler
- - Support for Custom Datapath Extension
- - CMSIS-SVD 1.3.3 (unchanged)
- - CMSIS-DAP 2.0.0 (unchanged)
- - CMSIS-Zone 1.0.0 (unchanged)
- - Devices
- - Utilities
- - SVDConv 3.3.35
- - PackChk 1.3.89
-
-
-
- 5.7.0
-
- - CMSIS-Build 0.9.0 (beta)
- - Draft for CMSIS Project description (CPRJ)
- - CMSIS-Core (Cortex-M) 5.4.0
- - Cortex-M55 cpu support
- - Enhanced MVE support for Armv8.1-MML
- - Fixed device config define checks.
- - L1 Cache functions for Armv7-M and later
- - CMSIS-Core (Cortex-A) 1.2.0
- - Fixed GIC_SetPendingIRQ to use GICD_SGIR
- - Added missing DSP intrinsics
- - Reworked assembly intrinsics: volatile, barriers and clobber
- - CMSIS-Driver 2.8.0
- - Added VIO API 0.1.0 (preview)
- - CMSIS-DSP 1.8.0
- - Added new functions and function groups
- - Added MVE support
- - CMSIS-NN 1.3.0
- - Added MVE support
- - Further optimizations for kernels using DSP extension
- - CMSIS-RTOS 2.1.3 (unchanged)
- - RTX 5.5.2 (see revision history for details)
- - CMSIS-Pack 1.6.3
- - deprecating all types specific to cpdsc format. Cpdsc is replaced by Cprj with dedicated schema.
- - CMSIS-SVD 1.3.3 (unchanged)
- - CMSIS-DAP 2.0.0 (unchanged)
- - CMSIS-Zone 1.0.0
- - Devices
- - ARMCM55 device
- - ARMv81MML startup code recognizing __MVE_USED macro
- - Refactored vector table references for all Cortex-M devices
- - Reworked ARMCM* C-StartUp files.
- - Include L1 Cache functions in ARMv8MML/ARMv81MML devices
- - Utilities
- Attention: Linux binaries moved to Linux64 folder!
- - SVDConv 3.3.35
- - PackChk 1.3.89
-
-
-
- 5.6.0
-
- - CMSIS-Core (Cortex-M) 5.3.0
- - Added provisions for compiler-independent C startup code.
- - CMSIS-Core (Cortex-A) 1.1.4
- - Fixed __FPU_Enable.
- - CMSIS-Driver 2.7.1
- - Finalized WiFi Interface API 1.0.0
- - CMSIS-DSP 1.7.0 (see revision history for details)
- - New Neon versions of f32 functions
- - Compilation flags for FFTs
- - CMSIS-NN 1.2.0 (unchanged)
- - CMSIS-RTOS1 1.03 (unchanged)
- - RTX 4.82.0 (see revision history for details)
- - CMSIS-RTOS 2.1.3 (unchanged)
- - RTX 5.5.1 (see revision history for details)
- - CMSIS-Pack 1.6.0 (unchanged)
- - CMSIS-SVD 1.3.3 (unchanged)
- - CMSIS-DAP 2.0.0 (unchanged)
- - CMSIS-Zone 0.12.0 (preview)
- - Completely reworked
- - Devices
- - Generalized C startup code for all Cortex-M family devices.
- - Updated Cortex-A memory regions and system configuration files.
- - Utilities
- - SVDConv 3.3.27
- - PackChk 1.3.82 (unchanged)
-
-
-
- 5.5.1
-
- - CMSIS-Core (Cortex-M) 5.2.1
- - Fixed compilation issue in cmsis_armclang_ltm.h
- - CMSIS-Core (Cortex-A) 1.1.3 (unchanged)
- - CMSIS-Driver 2.7.0 (unchanged)
- - CMSIS-DSP 1.6.0 (unchanged)
- - CMSIS-NN 1.1.0 (unchanged)
- - CMSIS-RTOS 2.1.3 (unchanged)
- - RTX 5.5.0 (unchanged)
- - CMSIS-Pack 1.6.0 (unchanged)
- - CMSIS-SVD 1.3.3 (unchanged)
- - CMSIS-DAP 2.0.0 (unchanged)
- - CMSIS-Zone 0.9.0 (unchanged)
-
-
-
- 5.5.0
-
- - CMSIS-Core (Cortex-M) 5.2.0
- - Reworked Stack/Heap configuration for ARM startup files.
- - Added Cortex-M35P device support.
- - Added generic Armv8.1-M Mainline device support.
- - CMSIS-Core (Cortex-A) 1.1.3 Minor fixes.
- - CMSIS-DSP 1.6.0
- - reworked DSP library source files
- - added macro ARM_MATH_LOOPUNROLL
- - removed macro UNALIGNED_SUPPORT_DISABLE
- - added const-correctness
- - replaced SIMD pointer construct with memcopy solution
- - replaced macro combination "CMSIS_INLINE __STATIC_INLINE with "__STATIC_FORCEINLINE"
- - reworked DSP library documentation
- - Changed DSP folder structure
- - moved DSP libraries to ./DSP/Lib
- - moved DSP libraries to folder ./DSP/Lib
- - ARM DSP Libraries are built with ARMCLANG
- - Added DSP Libraries Source variant
- - CMSIS-NN 1.1.0 (unchanged)
- - CMSIS-Driver 2.7.0
- - Added WiFi Interface API 1.0.0-beta
- - Added custom driver selection to simplify implementation of new CMSIS-Driver
- - CMSIS-RTOS 2.1.3
- - RTX 5.5.0 (see revision history)
- - CMSIS-Pack 1.6.0
- - CMSIS-SVD 1.3.3 (unchanged)
- - CMSIS-DAP 2.0.0 (unchanged)
- - CMSIS-Zone 0.9.0 (Preview)
- - Devices
- - Added Cortex-M35P and ARMv81MML device templates.
- - Fixed C-Startup Code for GCC (aligned with other compilers)
- - Moved call to SystemInit before memory initialization.
- - Utilities
- - SVDConv 3.3.25
- - PackChk 1.3.82
-
-
-
- 5.4.0
-
- - CMSIS-Core (Cortex-M) 5.1.2 Minor fixes and slight enhancements, e.g. beta for Cortex-M1.
- - CMSIS-Core (Cortex-A) 1.1.2 Minor fixes.
- - CMSIS-Driver 2.6.0 (unchanged)
- - CMSIS-DSP 1.5.2 (unchanged)
- - CMSIS-NN 1.1.0 Added new math function (see revision history)
- - CMSIS-RTOS 2.1.3 Relaxed interrupt usage.
- - RTX 5.4.0 (see revision history)
- - CMSIS-Pack 1.5.0 (unchanged)
- - CMSIS-SVD 1.3.3 (unchanged)
- - CMSIS-DAP 2.0.0 (unchanged)
- - CMSIS-Zone 0.0.1 (unchanged)
-
-
-
- 5.3.0
-
- - CMSIS-Core (Cortex-M) 5.1.1
- - CMSIS-Core (Cortex-A) 1.1.1
- - CMSIS-Driver 2.6.0 (unchanged)
- - CMSIS-DSP 1.5.2 (unchanged)
- - CMSIS-NN 1.0.0 Initial contribution of Neural Network Library.
- - CMSIS-RTOS 2.1.2 (unchanged)
- - CMSIS-Pack 1.5.0 (unchanged)
- - CMSIS-SVD 1.3.3 (unchanged)
- - CMSIS-DAP 2.0.0 Communication via WinUSB to achieve high-speed transfer rates.
- - CMSIS-Zone 0.0.1 (unchanged)
-
-
-
- 5.2.0
-
- - CMSIS-Core (Cortex-M) 5.1.0 MPU functions for ARMv8-M, cmsis_iccarm.h replacing cmsis_iar.h
- - CMSIS-Core (Cortex-A) 1.1.0 cmsis_iccarm.h, additional physical timer access functions
- - CMSIS-Driver 2.6.0 Enhanced CAN and NAND driver interface.
- - CMSIS-DSP 1.5.2 Fixed diagnostics and moved SSAT/USST intrinsics to CMSIS-Core.
- - CMSIS-RTOS 2.1.2 Relaxed some ISR-callable restrictions.
- - CMSIS-Pack 1.5.0 (unchanged)
- - CMSIS-SVD 1.3.3 (unchanged)
- - CMSIS-DAP 1.2.0 (unchanged)
- - CMSIS-Zone 0.0.1 (unchanged)
-
-
-
- 5.1.1
-
- - CMSIS-Core (Cortex-M) (unchanged)
- - CMSIS-Core (Cortex-A) (unchanged)
- - CMSIS-Driver 2.05 (unchanged)
- - CMSIS-DSP 1.5.2 (unchanged)
- - CMSIS-RTOS 2.1.1 Fixed RTX5 pre-built libraries for Cortex-M.
- - CMSIS-Pack 1.5.0 (unchanged)
- - CMSIS-SVD 1.3.3 (unchanged)
- - CMSIS-DAP 1.1.0 (unchanged)
- - CMSIS-Zone 0.0.1 (unchanged)
-
-
-
- 5.1.0
-
- - CMSIS-Core (Cortex-M) 5.0.2 several minor corrections and enhancements
- - CMSIS-Core (Cortex-A) 1.0.0 implements a basic run-time system for Cortex-A5/A7/A9
- - CMSIS-Driver 2.05 status typedef made volatile
- - CMSIS-DSP 1.5.2 fixed GNU Compiler specific diagnostics
- - CMSIS-RTOS 2.1.1 added support for Cortex-A5/A7/A9 to RTX5
- - CMSIS-Pack 1.5.0 added SDF format specification
- - CMSIS-SVD 1.3.3 (unchanged)
- - CMSIS-DAP 1.1.0 (unchanged)
- - CMSIS-Zone 0.0.1 (Preview) format to describe system resources and tool for partitioning of resources
-
-
-
- 5.0.1
-
- - CMSIS-Core 5.0.1 added __PACKED_STRUCT macro and uVisor support
- - CMSIS-Driver 2.05 updated all typedefs related to status now being volatile.
- - CMSIS-DSP 1.5.1 added ARMv8M DSP libraries
- - CMSIS-RTOS 2.1.0 added support for critical and uncritical sections
- - CMSIS-Pack 1.4.8 add Pack Index File specification
- - CMSIS-SVD 1.3.3 (unchanged)
- - CMSIS-DAP 1.1.0 (unchanged)
-
-
-
- 5.0.0
-
- Added support for: ARMv8-M architecture
-
-
- 4.5.0
-
- Maintenance release that is fixing defects. See component's revision history for more details.
- See component's revision history for more details.
- - CMSIS-Core (Cortex-M) 4.30.0
- - CMSIS-DAP 1.1.0 (unchanged)
- - CMSIS-Driver 2.04.0
- - CMSIS-DSP 1.4.7
- - CMSIS-Pack 1.4.1
- - CMSIS-RTOS RTX 4.80.0
- - CMSIS-SVD 1.3.1
-
-
-
- 4.4.0
-
- Feature release adding CMSIS-DAP (see extended End User Licence Agreement) and CMSIS-Driver for CAN.
- See component's revision history for more details.
- - CMSIS-Core (Cortex-M) 4.20.0
- - CMSIS-DAP 1.1.0
- - CMSIS-Driver 2.03.0
- - CMSIS-DSP 1.4.5 (unchanged)
- - CMSIS-RTOS RTX 4.79.0
- - CMSIS-Pack 1.4.0
- - CMSIS-SVD 1.3.0
-
-
-
- 4.3.0
-
- Maintenance release adding SAI CMSIS-Driver and fixing defects. See component's revision history for more details.
- - CMSIS-Core (Cortex-M) 4.10.0
- - CMSIS-Driver 2.02.0
- - CMSIS-DSP 1.4.5
- - CMSIS-RTOS RTX 4.78.0
- - CMSIS-Pack 1.3.3
- - CMSIS-SVD (unchanged)
-
-
-
- 4.2
- Introducing processor support for Cortex-M7.
-
-
-
- 4.1
- Enhancements in CMSIS-Pack and CMSIS-Driver.\n
- Added: PackChk validation utility\n
- Removed support for GNU: Sourcery G++ Lite Edition for ARM
-
-
- 4.0
- First release in CMSIS-Pack format.\n Added specifications for CMSIS-Pack, CMSIS-Driver
-
-
- 3.30
- Maintenance release with enhancements in each component
-
-
- 3.20
- Maintenance release with enhancements in each component
-
-
- 3.01
- Added support for Cortex-M0+ processors
-
-
- 3.00
- Added support for SC000 and SC300 processors\n
- Added support for GNU GCC Compiler\n
- Added CMSIS-RTOS API
-
-
- 2.10
- Added CMSIS-DSP Library
-
-
- 2.0
- Added support for Cortex-M4 processor
-
-
- 1.30
- Reworked CMSIS startup concept
-
-
- 1.01
- Added support for Cortex-M0 processor
-
-
- 1.00
- Initial release of CMSIS-Core (Cortex-M) for Cortex-M3 processor
-
-
-
-*/
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/How2Doc.txt b/external/CMSIS_5/CMSIS/DoxyGen/How2Doc.txt
deleted file mode 100644
index 8c5d1c4..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/How2Doc.txt
+++ /dev/null
@@ -1,281 +0,0 @@
-Rules for CMSIS API Function documentation
-===========================================
-
-This document describes how to generate Doxygen-style documentation for middleware "Components".
-It explains how the Doxygen documentation under "Reference" is provided in header (*.h),
-text (*.txt), template (*.c), and config files.
-
-Folder structure:
- .\MW\component\Include *.h files
- .\MW\component\Template *.c user code templates
- .\MW\component\Config *.c or *.h config files
- .\MW\Doc\component *.txt files
- .\MW\Doc\component\images graphic files used by *.txt files
-
-Files: Middleware components have the following files that are used to generate the API documentation:
-
- - *.h files: one or more header files which expose data types and functions (the API). Doxygen uses the *.h files
- that are in .\MW\component\include folder.
-
- - *.txt files: documentation files that group functions and explain overall the API. Each *.h file should have a *.txt
- file with the same name, i.e. rl_usb.h => rl_usb.txt; a exception is permitted when a template is used to explain
- API functions.
-
- - *.c templates: show the usage of some middleware functionality and may be included in the Doxygen documentation.
- *.c templates with '%Instance%' are copied to .\MW\Doc\component and '%Instance%' is replaced with 'n', otherwise
- Doxygen uses the *.c templates in folder .\MW\component\Template. If a template is used in documentation
- the related *.txt file has the same name as the template, i.e. USBD_User_HID.c => USBD_User_HID.txt.
-
- - *.c or *.h config files should be self-explaining using tags. config files will not be replicated
- in Doxygen *.txt files, but the high-level usage will be explained. The impact of parameters to middleware
- needs therefore be part of the config files.
-
-Source files (*.c and *.h) should NOT use character. Instead of characters are used.
-
-
-API Documentation in .\Include\*.h files
-----------------------------------------
-
-Example:
-
-The following snippet shows a sample documentation (correct). In general functions are grouped and
-a short descriptive line is added before a group of functions. In case that functions are only
-relevant for the documentation (i.e. available in multiple instances), they are included in
-#ifdef __DOXYGEN__ / #endif sections.
-
-{code}
-/// \brief Called during \ref USBD_Initialize to initialize the USB Device class.
-/// \return none
-extern void USBD_HIDn_Initialize (void);
-
-// ==== USB Host Human Interface Device Functions ====
-
-/// \brief Get status of the Human Interface Device.
-/// \param[in] index instance index of HID.
-/// \return true device is configured and initialized.
-/// \return false device not ready.
-extern bool USBH_HID_GetStatus (uint8_t index);
-
-/// \brief Read data received from Human Interface Device.
-/// \param[in] index instance index of HID.
-/// \param[out] ptr_data data to be read.
-/// \return value >= 0 number of bytes read.
-/// \return value -1 communication error.
-extern int USBH_HID_Read (uint8_t index, uint8_t *ptr_data);
-
-/// \brief Write data to Human Interface Device.
-/// \param[in] index instance index of HID.
-/// \param[in] ptr_data data to be written.
-/// \param[in] data_len number of data bytes to be written.
-/// \return number of bytes written.
-extern int USBH_HID_Write (uint8_t index, uint8_t *ptr_data, uint16_t data_len);
-
-/// \brief Get last error that happened on the Human Interface Device.
-/// \param[in] index instance index of HID.
-/// \return error code.
-extern uint32_t USBH_HID_GetLastError (uint8_t index);
-
-/// \brief Retrieve state change since last call of HID Mouse.
-/// \param[in] index instance index of HID.
-/// \param[out] button pointer to variable that receives button state.
-/// \param[out] x pointer to variable that receives x position change.
-/// \param[out] y pointer to variable that receives y position change.
-/// \param[out] wheel pointer to variable that receives wheel change.
-/// \return true state change since last call.
-/// \return false no state change since last call.
-extern bool USBH_HID_GetMouseData (uint8_t index, uint8_t *button, int8_t *x, int8_t *y, int8_t *wheel);
-
-// ==== USB Device Human Interface Device Functions ====
-
-#ifdef __DOXYGEN__
-// following functions are available for each instance of a HID class.
-// generic prefix USBD_HIDn is USBD_HID0 for HID class instance 0.
-
-/// \brief Prepare HID report data to be sent.
-/// \param[in] rtype Report type
-/// - HID_REPORT_INPUT = Input report requested.
-/// - HID_REPORT_FEATURE = Feature report requested.
-/// \param[in] rid Report ID (0 if only one report exists)
-/// \param[out] buf Buffer for report data to be sent.
-/// \param[in] req Request type
-/// - USBD_HID_REQ_EP_CTRL = Control endpoint request.
-/// - USBD_HID_REQ_PERIOD_UPDATE = Idle period expiration request.
-/// - USBD_HID_REQ_EP_INT = Previously sent report on interrupt endpoint request.
-/// \return value >= 0 number of data bytes prepared
-/// \return value < 0 error code
-int32_t USBD_HIDn_GetReport (uint8_t rtype, uint8_t rid, uint8_t *buf, uint8_t req);
-
-{code}
-
-This section contains things that should be NOT DONE:
-
-/// \brief Prepares HID report data to be sent
-*** NO '.' to terminate brief documentation.
-
-
-/// \brief Prepares HID report data to be sent.
-*** NO 's' after a verb in brief documentation.
-
-
-/// \brief Retrieve a state change since last call of the HID Mouse.
-*** NO 'a' or 'the' in brief text.
-
-
-/// \return true when state change since last call, false otherwise.
-*** Confusing return statement, separate into two lines (looks also better):
-/// \return
-/// - true = when state change since last call
-/// - false = otherwise.
-
-
-/// \return 0 no communication error.
-/// \return - 1 communication error.
-*** Confusing, may generate a bullet point, use instead "value" in front of plain numbers, correct is:
-/// \return value 0 no communication error.
-/// \return value -1 communication error.
-
-
-/// \param[in] req Request type:
-/// USBD_HID_REQ_EP_CTRL = Control endpoint request.
-/// USBD_HID_REQ_PERIOD_UPDATE = Idle period expiration request.
-/// USBD_HID_REQ_EP_INT = Previously sent report on interrupt endpoint request.
-*** Missing '-' in front of parameter details => hard to read in documentation.
-
-
-/// \param[in] stat error status and line states
-/// - bit 6 - bOverRun
-/// - bit 5 - bParity
-*** Missing ':' after states and bit numbers, correct is:
-/// \param[in] stat error status and line states:
-/// - bit 6: bOverRun
-/// - bit 5: bParity
-
-
-/// \param[in] ptr_data pointer to data buffer where information is written.
-*** Wrong, should be param[out].
-*** Redundant: a data buffer is always a pointer, better is:
-/// \param[out] ptr_data data buffer that receives information.
-
-
-/// \fn bool USBH_HID_GetStatus (uint8_t index);
-/// \brief Get status of the Human Interface Device.
-/// \param[in] index instance index of HID.
-/// \return true device is configured and initialized.
-/// \return false device not ready.
-extern bool USBH_HID_GetStatus (uint8_t index);
-Wrong: \fn not needed
-
-
-/* USB Host Speed constants */
-enum {
- USBH_LS = 0, /* Low speed */
- USBH_FS, /* Full speed */
- USBH_HS /* High speed */
-};
-Wrong, should be Doxygen style. Correct is:
-/// USB Host Speed constants
-enum {
- USBH_LS = 0, ///< Low speed
- USBH_FS, ///< Full speed
- USBH_HS ///< High speed
-};
-
-
-typedef struct { ///< Hw Endpoint settings structure
- osThreadId thread_id; ///< Thread ID of thread that uses URB
- USBH_URB urb; ///< URB used for endpoint communication} USBH_EP;
-Wrong: '/// comment' before 'struct {'
-Bad: repeat of Thread ID and URB does not add value; avoid abbreviations like 'Hw'
-
-Better is:
-/// Hardware Endpoint Settings for communication functions
-typedef struct {
- osThreadId thread_id; ///< thread using USB Request Block (urb)
- USBH_URB urb; ///< USB Request Block for endpoint communication
-
-
-
-API Documentation in *.txt files
---------------------------------
-
-A *.txt file that relates to a *.h contains:
- - Functional group assignments using \defgroup along with \brief description
- - Under \details an overview description for each functional group (should contain a useful code example)
- - For each function in the header file a detailed description
-
-
-IMPORTANT:
-Text *.txt files that document the user API of a component are located in .\MW\Doc\component.
-Only for *.h files that provide user API, there is exactly one text file with the same name.
-Defines/Functions that are internally used by a Component have no *.txt file.
-
-Example:
- .\MW\component\Include\rl_usb.h => .\MW\Doc\component\rl_usb.txt
-
-The file documents each function that is exposed in *.h header file (and only those functions).
-In case that functions are described in other files (i.e. USB Class Templates) there is a reference.
-
-Functional Group assignments uses this syntax:
----------------------------
-/**
-\defgroup a group definition
-[\ingroup] optionally within a group
-\brief brief description of the group
-\details
-description
-*/
-
-/**
-\addtogroup a group definition
-@{
-*/
-
-Below \addtogroup the documentation for related functions is provided. This section
-ends with @}
-
-Function documentation uses this syntax:
---------
-/**
-\fn functionName( args )
-\details
-[\note]
-[Code Example
-\code | \snippet]
-*/
-
-See rl_usb.txt for examples
-No ';' at the end of the function declaration. Otherwise function description gets ignored.
-
-
-
-Comments in doxygen code blocks should be marked with // and not /* ... */, which leads to errors.
--------------------------------------------------------
-Example: Wrong:
-\code
-void ftp_server_notify (uint8_t event) {
- /* Notify the user application about events in FTP server.*/
- ...
-}
-\endcode
-
-Example: correct:
-\code
-void ftp_server_notify (uint8_t event) {
- // Notify the user application about events in FTP server.
- ...
-}
-\endcode
-
-
-
-Cross references (between components)
--------------------------------------
-
-Within a single component (same .dxy configuration) one can easily created cross references.
-Known symbol names are automatically assumed as a reference by Doxygen. Pages, sections and
-subsections can be referenced using "\ref" notation.
-
-Cross references do not work between different components, though. Doxygen offers the possibility
-to import so called tags (symbol and section names) from an another external documentation.
-Unfortunately this creates output that crashes the MDK DoxyIndex importer. Hence cross references
-needs to be placed manually using ... notation, for the time being.
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ActivationFunctions_2CMakeLists_8txt.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ActivationFunctions_2CMakeLists_8txt.html
deleted file mode 100644
index 4f9b21e..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ActivationFunctions_2CMakeLists_8txt.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/BasicMathFunctions_2CMakeLists_8txt.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/BasicMathFunctions_2CMakeLists_8txt.html
deleted file mode 100644
index 80ca233..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/BasicMathFunctions_2CMakeLists_8txt.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/CMSIS_Logo_Final.png b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/CMSIS_Logo_Final.png
deleted file mode 100644
index ec557ff..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/CMSIS_Logo_Final.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/CMakeLists_8txt.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/CMakeLists_8txt.html
deleted file mode 100644
index 504e4a8..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/CMakeLists_8txt.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ChangeLog_pg.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ChangeLog_pg.html
deleted file mode 100644
index 9022033..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ChangeLog_pg.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ConcatenationFunctions_2CMakeLists_8txt.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ConcatenationFunctions_2CMakeLists_8txt.html
deleted file mode 100644
index 6021482..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ConcatenationFunctions_2CMakeLists_8txt.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ConvolutionFunctions_2CMakeLists_8txt.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ConvolutionFunctions_2CMakeLists_8txt.html
deleted file mode 100644
index aa6b707..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ConvolutionFunctions_2CMakeLists_8txt.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/FullyConnectedFunctions_2CMakeLists_8txt.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/FullyConnectedFunctions_2CMakeLists_8txt.html
deleted file mode 100644
index 75a8f07..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/FullyConnectedFunctions_2CMakeLists_8txt.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/NNSupportFunctions_2CMakeLists_8txt.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/NNSupportFunctions_2CMakeLists_8txt.html
deleted file mode 100644
index 3ba6dc2..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/NNSupportFunctions_2CMakeLists_8txt.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/PoolingFunctions_2CMakeLists_8txt.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/PoolingFunctions_2CMakeLists_8txt.html
deleted file mode 100644
index 6fac249..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/PoolingFunctions_2CMakeLists_8txt.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ReshapeFunctions_2CMakeLists_8txt.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ReshapeFunctions_2CMakeLists_8txt.html
deleted file mode 100644
index cd02a72..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ReshapeFunctions_2CMakeLists_8txt.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/SVDFunctions_2CMakeLists_8txt.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/SVDFunctions_2CMakeLists_8txt.html
deleted file mode 100644
index c7048c3..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/SVDFunctions_2CMakeLists_8txt.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/SoftmaxFunctions_2CMakeLists_8txt.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/SoftmaxFunctions_2CMakeLists_8txt.html
deleted file mode 100644
index f5f3f33..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/SoftmaxFunctions_2CMakeLists_8txt.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/annotated.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/annotated.html
deleted file mode 100644
index da74f30..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/annotated.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/annotated.js b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/annotated.js
deleted file mode 100644
index 4ee9906..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/annotated.js
+++ /dev/null
@@ -1,18 +0,0 @@
-var annotated =
-[
- [ "arm_nn_double", "structarm__nn__double.html", "structarm__nn__double" ],
- [ "arm_nn_long_long", "unionarm__nn__long__long.html", "unionarm__nn__long__long" ],
- [ "arm_nnword", "unionarm__nnword.html", "unionarm__nnword" ],
- [ "cmsis_nn_activation", "structcmsis__nn__activation.html", "structcmsis__nn__activation" ],
- [ "cmsis_nn_context", "structcmsis__nn__context.html", "structcmsis__nn__context" ],
- [ "cmsis_nn_conv_params", "structcmsis__nn__conv__params.html", "structcmsis__nn__conv__params" ],
- [ "cmsis_nn_dims", "structcmsis__nn__dims.html", "structcmsis__nn__dims" ],
- [ "cmsis_nn_dw_conv_params", "structcmsis__nn__dw__conv__params.html", "structcmsis__nn__dw__conv__params" ],
- [ "cmsis_nn_fc_params", "structcmsis__nn__fc__params.html", "structcmsis__nn__fc__params" ],
- [ "cmsis_nn_per_channel_quant_params", "structcmsis__nn__per__channel__quant__params.html", "structcmsis__nn__per__channel__quant__params" ],
- [ "cmsis_nn_per_tensor_quant_params", "structcmsis__nn__per__tensor__quant__params.html", "structcmsis__nn__per__tensor__quant__params" ],
- [ "cmsis_nn_pool_params", "structcmsis__nn__pool__params.html", "structcmsis__nn__pool__params" ],
- [ "cmsis_nn_softmax_lut_s16", "structcmsis__nn__softmax__lut__s16.html", "structcmsis__nn__softmax__lut__s16" ],
- [ "cmsis_nn_svdf_params", "structcmsis__nn__svdf__params.html", "structcmsis__nn__svdf__params" ],
- [ "cmsis_nn_tile", "structcmsis__nn__tile.html", "structcmsis__nn__tile" ]
-];
\ No newline at end of file
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__avgpool__s16_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__avgpool__s16_8c.html
deleted file mode 100644
index 6fef3f0..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__avgpool__s16_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__avgpool__s8_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__avgpool__s8_8c.html
deleted file mode 100644
index 516c9ce..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__avgpool__s8_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__concatenation__s8__w_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__concatenation__s8__w_8c.html
deleted file mode 100644
index a832061..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__concatenation__s8__w_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__concatenation__s8__x_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__concatenation__s8__x_8c.html
deleted file mode 100644
index d25b204..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__concatenation__s8__x_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__concatenation__s8__y_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__concatenation__s8__y_8c.html
deleted file mode 100644
index 8f3816e..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__concatenation__s8__y_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__concatenation__s8__z_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__concatenation__s8__z_8c.html
deleted file mode 100644
index 7b444c0..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__concatenation__s8__z_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__convolve__1__x__n__s8_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__convolve__1__x__n__s8_8c.html
deleted file mode 100644
index f400e18..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__convolve__1__x__n__s8_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__convolve__1x1__HWC__q7__fast__nonsquare_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__convolve__1x1__HWC__q7__fast__nonsquare_8c.html
deleted file mode 100644
index 876e65e..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__convolve__1x1__HWC__q7__fast__nonsquare_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__convolve__1x1__s8__fast_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__convolve__1x1__s8__fast_8c.html
deleted file mode 100644
index 5ff94f0..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__convolve__1x1__s8__fast_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__convolve__HWC__q15__basic_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__convolve__HWC__q15__basic_8c.html
deleted file mode 100644
index 1320a95..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__convolve__HWC__q15__basic_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__convolve__HWC__q15__fast_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__convolve__HWC__q15__fast_8c.html
deleted file mode 100644
index f88e453..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__convolve__HWC__q15__fast_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__convolve__HWC__q15__fast__nonsquare_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__convolve__HWC__q15__fast__nonsquare_8c.html
deleted file mode 100644
index bfe88b8..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__convolve__HWC__q15__fast__nonsquare_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__convolve__HWC__q7__RGB_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__convolve__HWC__q7__RGB_8c.html
deleted file mode 100644
index 6068834..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__convolve__HWC__q7__RGB_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__convolve__HWC__q7__basic_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__convolve__HWC__q7__basic_8c.html
deleted file mode 100644
index 138051e..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__convolve__HWC__q7__basic_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__convolve__HWC__q7__basic__nonsquare_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__convolve__HWC__q7__basic__nonsquare_8c.html
deleted file mode 100644
index 2741d84..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__convolve__HWC__q7__basic__nonsquare_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__convolve__HWC__q7__fast_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__convolve__HWC__q7__fast_8c.html
deleted file mode 100644
index e628b2d..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__convolve__HWC__q7__fast_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__convolve__HWC__q7__fast__nonsquare_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__convolve__HWC__q7__fast__nonsquare_8c.html
deleted file mode 100644
index b3f9604..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__convolve__HWC__q7__fast__nonsquare_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__convolve__fast__s16_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__convolve__fast__s16_8c.html
deleted file mode 100644
index bf3e4c2..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__convolve__fast__s16_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__convolve__s16_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__convolve__s16_8c.html
deleted file mode 100644
index 0dd01a9..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__convolve__s16_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__convolve__s8_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__convolve__s8_8c.html
deleted file mode 100644
index 9dd495c..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__convolve__s8_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__convolve__wrapper__s16_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__convolve__wrapper__s16_8c.html
deleted file mode 100644
index 326ca4c..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__convolve__wrapper__s16_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__convolve__wrapper__s8_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__convolve__wrapper__s8_8c.html
deleted file mode 100644
index 5de856d..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__convolve__wrapper__s8_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__depthwise__conv__3x3__s8_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__depthwise__conv__3x3__s8_8c.html
deleted file mode 100644
index 6e0ef30..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__depthwise__conv__3x3__s8_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__depthwise__conv__fast__s16_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__depthwise__conv__fast__s16_8c.html
deleted file mode 100644
index da9c768..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__depthwise__conv__fast__s16_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__depthwise__conv__s16_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__depthwise__conv__s16_8c.html
deleted file mode 100644
index 642841d..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__depthwise__conv__s16_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__depthwise__conv__s8_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__depthwise__conv__s8_8c.html
deleted file mode 100644
index 2b7591f..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__depthwise__conv__s8_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__depthwise__conv__s8__opt_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__depthwise__conv__s8__opt_8c.html
deleted file mode 100644
index 3b4028f..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__depthwise__conv__s8__opt_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__depthwise__conv__u8__basic__ver1_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__depthwise__conv__u8__basic__ver1_8c.html
deleted file mode 100644
index 57930f9..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__depthwise__conv__u8__basic__ver1_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__depthwise__conv__wrapper__s16_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__depthwise__conv__wrapper__s16_8c.html
deleted file mode 100644
index 6df5e57..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__depthwise__conv__wrapper__s16_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__depthwise__conv__wrapper__s8_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__depthwise__conv__wrapper__s8_8c.html
deleted file mode 100644
index d7735f5..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__depthwise__conv__wrapper__s8_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__depthwise__separable__conv__HWC__q7_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__depthwise__separable__conv__HWC__q7_8c.html
deleted file mode 100644
index 869c212..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__depthwise__separable__conv__HWC__q7_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__depthwise__separable__conv__HWC__q7__nonsquare_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__depthwise__separable__conv__HWC__q7__nonsquare_8c.html
deleted file mode 100644
index b1e8660..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__depthwise__separable__conv__HWC__q7__nonsquare_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__elementwise__add__s16_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__elementwise__add__s16_8c.html
deleted file mode 100644
index 8ff59cc..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__elementwise__add__s16_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__elementwise__add__s8_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__elementwise__add__s8_8c.html
deleted file mode 100644
index f93a7ed..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__elementwise__add__s8_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__elementwise__mul__s16_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__elementwise__mul__s16_8c.html
deleted file mode 100644
index 098e4db..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__elementwise__mul__s16_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__elementwise__mul__s8_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__elementwise__mul__s8_8c.html
deleted file mode 100644
index 26116f4..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__elementwise__mul__s8_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__fully__connected__mat__q7__vec__q15_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__fully__connected__mat__q7__vec__q15_8c.html
deleted file mode 100644
index 8690b56..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__fully__connected__mat__q7__vec__q15_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__fully__connected__mat__q7__vec__q15__opt_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__fully__connected__mat__q7__vec__q15__opt_8c.html
deleted file mode 100644
index 0824895..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__fully__connected__mat__q7__vec__q15__opt_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__fully__connected__q15_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__fully__connected__q15_8c.html
deleted file mode 100644
index b2295d6..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__fully__connected__q15_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__fully__connected__q15__opt_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__fully__connected__q15__opt_8c.html
deleted file mode 100644
index 92b4886..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__fully__connected__q15__opt_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__fully__connected__q7_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__fully__connected__q7_8c.html
deleted file mode 100644
index 73be52a..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__fully__connected__q7_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__fully__connected__q7__opt_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__fully__connected__q7__opt_8c.html
deleted file mode 100644
index 884c2f4..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__fully__connected__q7__opt_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__fully__connected__s16_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__fully__connected__s16_8c.html
deleted file mode 100644
index 292b876..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__fully__connected__s16_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__fully__connected__s8_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__fully__connected__s8_8c.html
deleted file mode 100644
index b1a215c..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__fully__connected__s8_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__max__pool__s16_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__max__pool__s16_8c.html
deleted file mode 100644
index f27cc05..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__max__pool__s16_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__max__pool__s8_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__max__pool__s8_8c.html
deleted file mode 100644
index a4ce8d9..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__max__pool__s8_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__accumulate__q7__to__q15_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__accumulate__q7__to__q15_8c.html
deleted file mode 100644
index dc5236e..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__accumulate__q7__to__q15_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__activations__q15_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__activations__q15_8c.html
deleted file mode 100644
index 8c7b331..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__activations__q15_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__activations__q7_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__activations__q7_8c.html
deleted file mode 100644
index 3cc1248..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__activations__q7_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__add__q7_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__add__q7_8c.html
deleted file mode 100644
index 219ec6a..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__add__q7_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__depthwise__conv__nt__t__padded__s8_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__depthwise__conv__nt__t__padded__s8_8c.html
deleted file mode 100644
index a52f5e1..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__depthwise__conv__nt__t__padded__s8_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__depthwise__conv__nt__t__s16_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__depthwise__conv__nt__t__s16_8c.html
deleted file mode 100644
index 872e2fa..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__depthwise__conv__nt__t__s16_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__depthwise__conv__nt__t__s8_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__depthwise__conv__nt__t__s8_8c.html
deleted file mode 100644
index a7526eb..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__depthwise__conv__nt__t__s8_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__depthwise__conv__s8__core_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__depthwise__conv__s8__core_8c.html
deleted file mode 100644
index a4f9e17..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__depthwise__conv__s8__core_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__mat__mul__core__1x__s8_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__mat__mul__core__1x__s8_8c.html
deleted file mode 100644
index 71e5ae3..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__mat__mul__core__1x__s8_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__mat__mul__core__4x__s8_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__mat__mul__core__4x__s8_8c.html
deleted file mode 100644
index e903adb..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__mat__mul__core__4x__s8_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__mat__mul__kernel__s16_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__mat__mul__kernel__s16_8c.html
deleted file mode 100644
index ab5501a..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__mat__mul__kernel__s16_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__mat__mult__kernel__q7__q15_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__mat__mult__kernel__q7__q15_8c.html
deleted file mode 100644
index 42c3e9e..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__mat__mult__kernel__q7__q15_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__mat__mult__kernel__q7__q15__reordered_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__mat__mult__kernel__q7__q15__reordered_8c.html
deleted file mode 100644
index dca91ed..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__mat__mult__kernel__q7__q15__reordered_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__mat__mult__kernel__s8__s16_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__mat__mult__kernel__s8__s16_8c.html
deleted file mode 100644
index d5e96ef..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__mat__mult__kernel__s8__s16_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__mat__mult__nt__t__s8_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__mat__mult__nt__t__s8_8c.html
deleted file mode 100644
index 1019e03..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__mat__mult__nt__t__s8_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__mat__mult__s8_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__mat__mult__s8_8c.html
deleted file mode 100644
index 8ee7128..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__mat__mult__s8_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__math__types_8h.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__math__types_8h.html
deleted file mode 100644
index 53b1e49..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__math__types_8h.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__mult__q15_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__mult__q15_8c.html
deleted file mode 100644
index 021980d..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__mult__q15_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__mult__q7_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__mult__q7_8c.html
deleted file mode 100644
index 61d5209..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__mult__q7_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__softmax__common__s8_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__softmax__common__s8_8c.html
deleted file mode 100644
index 909fe74..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__softmax__common__s8_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__tables_8h.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__tables_8h.html
deleted file mode 100644
index 8219367..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__tables_8h.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__types_8h.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__types_8h.html
deleted file mode 100644
index d221e53..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__types_8h.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__vec__mat__mult__t__s16_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__vec__mat__mult__t__s16_8c.html
deleted file mode 100644
index f1da732..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__vec__mat__mult__t__s16_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__vec__mat__mult__t__s8_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__vec__mat__mult__t__s8_8c.html
deleted file mode 100644
index 9e4f1a3..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__vec__mat__mult__t__s8_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__vec__mat__mult__t__svdf__s8_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__vec__mat__mult__t__svdf__s8_8c.html
deleted file mode 100644
index f5be873..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nn__vec__mat__mult__t__svdf__s8_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nnfunctions_8h.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nnfunctions_8h.html
deleted file mode 100644
index 0e88cc1..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nnfunctions_8h.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nnsupportfunctions_8h.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nnsupportfunctions_8h.html
deleted file mode 100644
index 9906c6a..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nnsupportfunctions_8h.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nntables_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nntables_8c.html
deleted file mode 100644
index 0080f29..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__nntables_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__pool__q7__HWC_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__pool__q7__HWC_8c.html
deleted file mode 100644
index 76baf45..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__pool__q7__HWC_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__q7__to__q15__no__shift_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__q7__to__q15__no__shift_8c.html
deleted file mode 100644
index 862fb75..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__q7__to__q15__no__shift_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__q7__to__q15__reordered__no__shift_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__q7__to__q15__reordered__no__shift_8c.html
deleted file mode 100644
index f487da2..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__q7__to__q15__reordered__no__shift_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__q7__to__q15__reordered__with__offset_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__q7__to__q15__reordered__with__offset_8c.html
deleted file mode 100644
index 141cc67..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__q7__to__q15__reordered__with__offset_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__q7__to__q15__with__offset_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__q7__to__q15__with__offset_8c.html
deleted file mode 100644
index a41e71c..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__q7__to__q15__with__offset_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__relu6__s8_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__relu6__s8_8c.html
deleted file mode 100644
index badeb6b..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__relu6__s8_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__relu__q15_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__relu__q15_8c.html
deleted file mode 100644
index d3a6b69..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__relu__q15_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__relu__q7_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__relu__q7_8c.html
deleted file mode 100644
index 4a12b52..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__relu__q7_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__reshape__s8_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__reshape__s8_8c.html
deleted file mode 100644
index f0cd502..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__reshape__s8_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__softmax__q15_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__softmax__q15_8c.html
deleted file mode 100644
index 81569de..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__softmax__q15_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__softmax__q7_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__softmax__q7_8c.html
deleted file mode 100644
index 16aba18..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__softmax__q7_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__softmax__s16_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__softmax__s16_8c.html
deleted file mode 100644
index 81b155a..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__softmax__s16_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__softmax__s8_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__softmax__s8_8c.html
deleted file mode 100644
index 33e708b..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__softmax__s8_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__softmax__s8__s16_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__softmax__s8__s16_8c.html
deleted file mode 100644
index dc7fc76..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__softmax__s8__s16_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__softmax__u8_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__softmax__u8_8c.html
deleted file mode 100644
index ca88dea..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__softmax__u8_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__softmax__with__batch__q7_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__softmax__with__batch__q7_8c.html
deleted file mode 100644
index 7e47bec..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__softmax__with__batch__q7_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__svdf__s8_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__svdf__s8_8c.html
deleted file mode 100644
index 929fa0b..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__svdf__s8_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__svdf__state__s16__s8_8c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__svdf__state__s16__s8_8c.html
deleted file mode 100644
index e04689d..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/arm__svdf__state__s16__s8_8c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/bc_s.png b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/bc_s.png
deleted file mode 100644
index 224b29a..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/bc_s.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/bdwn.png b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/bdwn.png
deleted file mode 100644
index 940a0b9..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/bdwn.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/classes.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/classes.html
deleted file mode 100644
index 351f534..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/classes.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/closed.png b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/closed.png
deleted file mode 100644
index 98cc2c9..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/closed.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/cmsis.css b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/cmsis.css
deleted file mode 100644
index 586d4d2..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/cmsis.css
+++ /dev/null
@@ -1,1282 +0,0 @@
-/* The standard CSS for doxygen */
-
-body, table, div, p, dl {
- font-family: Lucida Grande, Verdana, Geneva, Arial, sans-serif;
- font-size: 13px;
- line-height: 1.3;
-}
-
-/* CMSIS styles */
-
-.style1 {
- text-align: center;
-}
-.style2 {
- color: #0000FF;
- font-weight: normal;
-}
-.style3 {
- text-align: left;
-}
-.style4 {
- color: #008000;
-}
-.style5 {
- color: #0000FF;
-}
-.style6 {
- color: #000000;
- font-style:italic;
-}
-.mand {
- color: #0000FF;
-}
-.opt {
- color: #008000;
-}
-.cond {
- color: #990000;
-}
-
-.choice
-{
- background-color:#F7F9D0;
-}
-.seq
-{
- background-color:#C9DECB;
-}
-.group1
-{
- background-color:#F8F1F1;
-}
-.group2
-{
- background-color:#DCEDEA;
-}
-
-
-ul ul {
- list-style-type: disc;
-}
-
-ul ul ul {
- list-style-type: disc;
-}
-
-ul.hierarchy {
- color: green;
-}
-
-em {
- color: #000000;
- font-style:italic;
-}
-
-
-
-/* CMSIS Tables */
-table.cmtab1 {
- padding: 4px;
- border-collapse: collapse;
- border: 1px solid #A3B4D7;
- text-align: justify;
- width:70%;
-}
-
-th.cmtab1 {
- background: #EBEFF6;
- font-weight: bold;
- height: 28px;
-}
-
-td.cmtab1 {
- padding:1px;
- text-align: left;
-}
-
-table.cmtable {
- border-collapse:collapse;
- text-align: justify;
-}
-
-table.cmtable td, table.cmtable th {
- border: 1px solid #2D4068;
- padding: 3px 7px 2px;
-}
-
-table.cmtable th {
- background-color: #EBEFF6;
- font-size: 110%;
- padding-bottom: 4px;
- padding-top: 5px;
- text-align:left;
-}
-
-td.MonoTxt {
- font-family:"Arial monospaced for SAP";
-}
-
-td.XML-Token
-{
- azimuth: 180;
- font-style:italic;
- color:Maroon;
- z-index:20;
-
-}
-
-span.XML-Token
-{
- azimuth: 180;
- font-style:italic;
- color:Maroon;
- z-index:20;
-
-}
-
-span.h2
-{
- font-size: 120%;
- font-weight: bold;
-}
-
-div.new
-{
- background-color:#ccffcc; /* light green */
-}
-
-div.mod
-{
- background-color:#ffe6cc; /* light amber */
-}
-
-div.del
-{
- background-color:#ffcccc; /* light red */
-}
-
-/* @group Heading Levels */
-
-h1 {
- font-size: 150%;
-}
-
-.title {
- font-size: 150%;
- font-weight: bold;
- margin: 10px 2px;
-}
-
-h2 {
- font-size: 120%;
-}
-
-h3 {
- font-size: 100%;
-}
-
-h1, h2, h3, h4, h5, h6 {
- -webkit-transition: text-shadow 0.5s linear;
- -moz-transition: text-shadow 0.5s linear;
- -ms-transition: text-shadow 0.5s linear;
- -o-transition: text-shadow 0.5s linear;
- transition: text-shadow 0.5s linear;
- margin-right: 15px;
-}
-
-h1.glow, h2.glow, h3.glow, h4.glow, h5.glow, h6.glow {
- text-shadow: 0 0 15px cyan;
-}
-
-dt {
- font-weight: bold;
-}
-
-div.multicol {
- -moz-column-gap: 1em;
- -webkit-column-gap: 1em;
- -moz-column-count: 3;
- -webkit-column-count: 3;
-}
-
-p.startli, p.startdd, p.starttd {
- margin-top: 2px;
-}
-
-p.endli {
- margin-bottom: 0px;
-}
-
-p.enddd {
- margin-bottom: 4px;
-}
-
-p.endtd {
- margin-bottom: 2px;
-}
-
-/* @end */
-
-caption {
- font-weight: bold;
-}
-
-span.legend {
- font-size: 70%;
- text-align: center;
-}
-
-h3.version {
- font-size: 90%;
- text-align: center;
-}
-
-div.qindex, div.navtab{
- background-color: #EBEFF6;
- border: 1px solid #A2B4D8;
- text-align: center;
-}
-
-div.qindex, div.navpath {
- width: 100%;
- line-height: 140%;
-}
-
-div.navtab {
- margin-right: 15px;
-}
-
-/* @group Link Styling */
-
-a {
- color: #3A568E;
- font-weight: normal;
- text-decoration: none;
-}
-
-.contents a:visited {
- color: #4464A5;
-}
-
-a:hover {
- text-decoration: underline;
-}
-
-a.qindex {
- font-weight: bold;
-}
-
-a.qindexHL {
- font-weight: bold;
- background-color: #9AAED5;
- color: #ffffff;
- border: 1px double #849CCC;
-}
-
-.contents a.qindexHL:visited {
- color: #ffffff;
-}
-
-a.el {
- font-weight: bold;
-}
-
-a.elRef {
-}
-
-a.code, a.code:visited {
- color: #4665A2;
-}
-
-a.codeRef, a.codeRef:visited {
- color: #4665A2;
-}
-
-/* @end */
-
-dl.el {
- margin-left: -1cm;
-}
-
-pre.fragment {
- border: 1px solid #C4CFE5;
- background-color: #FBFCFD;
- padding: 4px 6px;
- margin: 4px 8px 4px 2px;
- overflow: auto;
- word-wrap: break-word;
- font-size: 9pt;
- line-height: 125%;
- font-family: monospace, fixed;
- font-size: 105%;
-}
-
-div.fragment {
- padding: 4px;
- margin: 4px;
- background-color: #FBFCFD;
- border: 1px solid #C3CFE6;
-}
-
-div.line {
- font-family: monospace, fixed;
- font-size: 13px;
- line-height: 1.0;
- text-wrap: unrestricted;
- white-space: -moz-pre-wrap; /* Moz */
- white-space: -pre-wrap; /* Opera 4-6 */
- white-space: -o-pre-wrap; /* Opera 7 */
- white-space: pre-wrap; /* CSS3 */
- word-wrap: break-word; /* IE 5.5+ */
- text-indent: -53px;
- padding-left: 53px;
- padding-bottom: 0px;
- margin: 0px;
-}
-
-span.lineno {
- padding-right: 4px;
- text-align: right;
- border-right: 2px solid #0F0;
- background-color: #E8E8E8;
- white-space: pre;
-}
-span.lineno a {
- background-color: #D8D8D8;
-}
-
-span.lineno a:hover {
- background-color: #C8C8C8;
-}
-
-div.ah {
- background-color: black;
- font-weight: bold;
- color: #ffffff;
- margin-bottom: 3px;
- margin-top: 3px;
- padding: 0.2em;
- border: solid thin #333;
- border-radius: 0.5em;
- -webkit-border-radius: .5em;
- -moz-border-radius: .5em;
- box-shadow: 2px 2px 3px #999;
- -webkit-box-shadow: 2px 2px 3px #999;
- -moz-box-shadow: rgba(0, 0, 0, 0.15) 2px 2px 2px;
- background-image: -webkit-gradient(linear, left top, left bottom, from(#eee), to(#000),color-stop(0.3, #444));
- background-image: -moz-linear-gradient(center top, #eee 0%, #444 40%, #000);
-}
-
-div.groupHeader {
- margin-left: 16px;
- margin-top: 12px;
- font-weight: bold;
-}
-
-div.groupText {
- margin-left: 16px;
- font-style: italic;
-}
-
-body {
- background-color: white;
- color: black;
- margin: 0;
-}
-
-div.contents {
- margin-top: 10px;
- margin-left: 12px;
- margin-right: 8px;
-}
-
-td.indexkey {
- background-color: #EBEFF6;
- font-weight: bold;
- border: 1px solid #C3CFE6;
- margin: 2px 0px 2px 0;
- padding: 2px 10px;
- white-space: nowrap;
- vertical-align: top;
-}
-
-td.indexvalue {
- background-color: #EBEFF6;
- border: 1px solid #C3CFE6;
- padding: 2px 10px;
- margin: 2px 0px;
-}
-
-tr.memlist {
- background-color: #EDF1F7;
-}
-
-p.formulaDsp {
- text-align: center;
-}
-
-img.formulaDsp {
-
-}
-
-img.formulaInl {
- vertical-align: middle;
-}
-
-div.center {
- text-align: center;
- margin-top: 0px;
- margin-bottom: 0px;
- padding: 0px;
-}
-
-div.center img {
- border: 0px;
-}
-
-address.footer {
- text-align: right;
- padding-right: 12px;
-}
-
-img.footer {
- border: 0px;
- vertical-align: middle;
-}
-
-/* @group Code Colorization */
-
-span.keyword {
- color: #008000
-}
-
-span.keywordtype {
- color: #604020
-}
-
-span.keywordflow {
- color: #e08000
-}
-
-span.comment {
- color: #800000
-}
-
-span.preprocessor {
- color: #806020
-}
-
-span.stringliteral {
- color: #002080
-}
-
-span.charliteral {
- color: #008080
-}
-
-span.vhdldigit {
- color: #ff00ff
-}
-
-span.vhdlchar {
- color: #000000
-}
-
-span.vhdlkeyword {
- color: #700070
-}
-
-span.vhdllogic {
- color: #ff0000
-}
-
-blockquote {
- background-color: #F7F8FB;
- border-left: 2px solid #9AAED5;
- margin: 0 24px 0 4px;
- padding: 0 12px 0 16px;
-}
-
-/* @end */
-
-/*
-.search {
- color: #003399;
- font-weight: bold;
-}
-
-form.search {
- margin-bottom: 0px;
- margin-top: 0px;
-}
-
-input.search {
- font-size: 75%;
- color: #000080;
- font-weight: normal;
- background-color: #e8eef2;
-}
-*/
-
-td.tiny {
- font-size: 75%;
-}
-
-.dirtab {
- padding: 4px;
- border-collapse: collapse;
- border: 1px solid #A2B4D8;
-}
-
-th.dirtab {
- background: #EBEFF6;
- font-weight: bold;
-}
-
-hr {
- height: 0px;
- border: none;
- border-top: 1px solid #4769AD;
-}
-
-hr.footer {
- height: 1px;
-}
-
-/* @group Member Descriptions */
-
-table.memberdecls {
- border-spacing: 0px;
- padding: 0px;
-}
-
-.memberdecls td {
- -webkit-transition-property: background-color, box-shadow;
- -webkit-transition-duration: 0.5s;
- -moz-transition-property: background-color, box-shadow;
- -moz-transition-duration: 0.5s;
- -ms-transition-property: background-color, box-shadow;
- -ms-transition-duration: 0.5s;
- -o-transition-property: background-color, box-shadow;
- -o-transition-duration: 0.5s;
- transition-property: background-color, box-shadow;
- transition-duration: 0.5s;
-}
-
-.memberdecls td.glow {
- background-color: cyan;
- box-shadow: 0 0 15px cyan;
-}
-
-.mdescLeft, .mdescRight,
-.memItemLeft, .memItemRight,
-.memTemplItemLeft, .memTemplItemRight, .memTemplParams {
- background-color: #F9FAFC;
- border: none;
- margin: 4px;
- padding: 1px 0 0 8px;
-}
-
-.mdescLeft, .mdescRight {
- padding: 0px 8px 4px 8px;
- color: #555;
-}
-
-.memItemLeft, .memItemRight, .memTemplParams {
- border-top: 1px solid #C3CFE6;
-}
-
-.memItemLeft, .memTemplItemLeft {
- white-space: nowrap;
-}
-
-.memItemRight {
- width: 100%;
-}
-
-.memTemplParams {
- color: #4464A5;
- white-space: nowrap;
-}
-
-/* @end */
-
-/* @group Member Details */
-
-/* Styles for detailed member documentation */
-
-.memtemplate {
- font-size: 80%;
- color: #4464A5;
- font-weight: normal;
- margin-left: 9px;
-}
-
-.memnav {
- background-color: #EBEFF6;
- border: 1px solid #A2B4D8;
- text-align: center;
- margin: 2px;
- margin-right: 15px;
- padding: 2px;
-}
-
-.mempage {
- width: 100%;
-}
-
-.memitem {
- padding: 0;
- margin-bottom: 10px;
- margin-right: 5px;
- -webkit-transition: box-shadow 0.5s linear;
- -moz-transition: box-shadow 0.5s linear;
- -ms-transition: box-shadow 0.5s linear;
- -o-transition: box-shadow 0.5s linear;
- transition: box-shadow 0.5s linear;
-}
-
-.memitem.glow {
- box-shadow: 0 0 15px cyan;
-}
-
-.memname {
- font-weight: bold;
- margin-left: 6px;
-}
-
-.memname td {
- vertical-align: bottom;
-}
-
-.memproto, dl.reflist dt {
- border-top: 1px solid #A7B8DA;
- border-left: 1px solid #A7B8DA;
- border-right: 1px solid #A7B8DA;
- padding: 6px 0px 6px 0px;
- color: #233456;
- font-weight: bold;
- text-shadow: 0px 1px 1px rgba(255, 255, 255, 0.9);
- background-image:url('nav_f.png');
- background-repeat:repeat-x;
- background-color: #E2E7F3;
- /* opera specific markup */
- box-shadow: 5px 5px 5px rgba(0, 0, 0, 0.15);
- border-top-right-radius: 4px;
- border-top-left-radius: 4px;
- /* firefox specific markup */
- -moz-box-shadow: rgba(0, 0, 0, 0.15) 5px 5px 5px;
- -moz-border-radius-topright: 4px;
- -moz-border-radius-topleft: 4px;
- /* webkit specific markup */
- -webkit-box-shadow: 5px 5px 5px rgba(0, 0, 0, 0.15);
- -webkit-border-top-right-radius: 4px;
- -webkit-border-top-left-radius: 4px;
-
-}
-
-.memdoc, dl.reflist dd {
- border-bottom: 1px solid #A7B8DA;
- border-left: 1px solid #A7B8DA;
- border-right: 1px solid #A7B8DA;
- padding: 6px 10px 2px 10px;
- background-color: #FBFCFD;
- border-top-width: 0;
- background-image:url('nav_g.png');
- background-repeat:repeat-x;
- background-color: #FFFFFF;
- /* opera specific markup */
- border-bottom-left-radius: 4px;
- border-bottom-right-radius: 4px;
- box-shadow: 5px 5px 5px rgba(0, 0, 0, 0.15);
- /* firefox specific markup */
- -moz-border-radius-bottomleft: 4px;
- -moz-border-radius-bottomright: 4px;
- -moz-box-shadow: rgba(0, 0, 0, 0.15) 5px 5px 5px;
- /* webkit specific markup */
- -webkit-border-bottom-left-radius: 4px;
- -webkit-border-bottom-right-radius: 4px;
- -webkit-box-shadow: 5px 5px 5px rgba(0, 0, 0, 0.15);
-}
-
-dl.reflist dt {
- padding: 5px;
-}
-
-dl.reflist dd {
- margin: 0px 0px 10px 0px;
- padding: 5px;
-}
-
-.paramkey {
- text-align: right;
-}
-
-.paramtype {
- white-space: nowrap;
-}
-
-.paramname {
- color: #602020;
- white-space: nowrap;
-}
-.paramname em {
- font-style: normal;
-}
-
-.params, .retval, .exception, .tparams {
- margin-left: 0px;
- padding-left: 0px;
-}
-
-.params .paramname, .retval .paramname {
- font-weight: bold;
- vertical-align: top;
-}
-
-.params .paramtype {
- font-style: italic;
- vertical-align: top;
-}
-
-.params .paramdir {
- font-family: "courier new",courier,monospace;
- vertical-align: top;
-}
-
-table.mlabels {
- border-spacing: 0px;
-}
-
-td.mlabels-left {
- width: 100%;
- padding: 0px;
-}
-
-td.mlabels-right {
- vertical-align: bottom;
- padding: 0px;
- white-space: nowrap;
-}
-
-span.mlabels {
- margin-left: 8px;
-}
-
-span.mlabel {
- background-color: #708CC4;
- border-top:1px solid #5072B7;
- border-left:1px solid #5072B7;
- border-right:1px solid #C3CFE6;
- border-bottom:1px solid #C3CFE6;
- text-shadow: none;
- color: white;
- margin-right: 4px;
- padding: 2px 3px;
- border-radius: 3px;
- font-size: 7pt;
- white-space: nowrap;
-}
-
-
-
-/* @end */
-
-/* these are for tree view when not used as main index */
-
-div.directory {
- margin: 10px 0px;
- border-top: 1px solid #A8B8D9;
- border-bottom: 1px solid #A8B8D9;
- width: 100%;
-}
-
-.directory table {
- border-collapse:collapse;
-}
-
-.directory td {
- margin: 0px;
- padding: 0px;
- vertical-align: top;
-}
-
-.directory td.entry {
- white-space: nowrap;
- padding-right: 6px;
-}
-
-.directory td.entry a {
- outline:none;
-}
-
-.directory td.desc {
- width: 100%;
- padding-left: 6px;
- padding-right: 6px;
- border-left: 1px solid rgba(0,0,0,0.05);
-}
-
-.directory tr.even {
- padding-left: 6px;
- background-color: #F7F8FB;
-}
-
-.directory img {
- vertical-align: -30%;
-}
-
-.directory .levels {
- white-space: nowrap;
- width: 100%;
- text-align: right;
- font-size: 9pt;
-}
-
-.directory .levels span {
- cursor: pointer;
- padding-left: 2px;
- padding-right: 2px;
- color: #3A568E;
-}
-
-div.dynheader {
- margin-top: 8px;
- -webkit-touch-callout: none;
- -webkit-user-select: none;
- -khtml-user-select: none;
- -moz-user-select: none;
- -ms-user-select: none;
- user-select: none;
-}
-
-address {
- font-style: normal;
- color: #293C63;
-}
-
-table.doxtable {
- border-collapse:collapse;
- margin-top: 4px;
- margin-bottom: 4px;
-}
-
-table.doxtable td, table.doxtable th {
- border: 1px solid #2B4069;
- padding: 3px 7px 2px;
-}
-
-table.doxtable th {
- background-color: #EBEFF6;
- color: #000000;
- font-size: 110%;
- padding-bottom: 4px;
- padding-top: 5px;
-}
-
-table.fieldtable {
- width: 100%;
- margin-bottom: 10px;
- border: 1px solid #A7B8DA;
- border-spacing: 0px;
- -moz-border-radius: 4px;
- -webkit-border-radius: 4px;
- border-radius: 4px;
- -moz-box-shadow: rgba(0, 0, 0, 0.15) 2px 2px 2px;
- -webkit-box-shadow: 2px 2px 2px rgba(0, 0, 0, 0.15);
- box-shadow: 2px 2px 2px rgba(0, 0, 0, 0.15);
-}
-
-.fieldtable td, .fieldtable th {
- padding: 3px 7px 2px;
-}
-
-.fieldtable td.fieldtype, .fieldtable td.fieldname {
- white-space: nowrap;
- border-right: 1px solid #A7B8DA;
- border-bottom: 1px solid #A7B8DA;
- vertical-align: top;
-}
-
-.fieldtable td.fielddoc {
- border-bottom: 1px solid #A7B8DA;
- width: 100%;
-}
-
-.fieldtable tr:last-child td {
- border-bottom: none;
-}
-
-.fieldtable th {
- background-image:url('nav_f.png');
- background-repeat:repeat-x;
- background-color: #E2E7F3;
- font-size: 90%;
- color: #233456;
- padding-bottom: 4px;
- padding-top: 5px;
- text-align:left;
- -moz-border-radius-topleft: 4px;
- -moz-border-radius-topright: 4px;
- -webkit-border-top-left-radius: 4px;
- -webkit-border-top-right-radius: 4px;
- border-top-left-radius: 4px;
- border-top-right-radius: 4px;
- border-bottom: 1px solid #A7B8DA;
-}
-
-
-.tabsearch {
- top: 0px;
- left: 10px;
- height: 36px;
- background-image: url('tab_b.png');
- z-index: 101;
- overflow: hidden;
- font-size: 13px;
-}
-
-.navpath ul
-{
- font-size: 11px;
- background-image:url('tab_b.png');
- background-repeat:repeat-x;
- height:30px;
- line-height:30px;
- color:#889FCE;
- border:solid 1px #C1CDE5;
- overflow:hidden;
- margin:0px;
- padding:0px;
-}
-
-.navpath li
-{
- list-style-type:none;
- float:left;
- padding-left:10px;
- padding-right:15px;
- background-image:url('bc_s.png');
- background-repeat:no-repeat;
- background-position:right;
- color:#344D7E;
-}
-
-.navpath li.navelem a
-{
- height:32px;
- display:block;
- text-decoration: none;
- outline: none;
-}
-
-.navpath li.navelem a:hover
-{
- color:#6583BF;
-}
-
-.navpath li.footer
-{
- list-style-type:none;
- float:right;
- padding-left:10px;
- padding-right:15px;
- background-image:none;
- background-repeat:no-repeat;
- background-position:right;
- color:#344D7E;
- font-size: 8pt;
-}
-
-
-div.summary
-{
- float: right;
- font-size: 8pt;
- padding-right: 5px;
- width: 50%;
- text-align: right;
-}
-
-div.summary a
-{
- white-space: nowrap;
-}
-
-div.ingroups
-{
- margin-left: 5px;
- font-size: 8pt;
- padding-left: 5px;
- width: 50%;
- text-align: left;
-}
-
-div.ingroups a
-{
- white-space: nowrap;
-}
-
-div.header
-{
- background-image:url('nav_h.png');
- background-repeat:repeat-x;
- background-color: #F9FAFC;
- margin: 0px;
- border-bottom: 1px solid #C3CFE6;
-}
-
-div.headertitle
-{
- padding: 5px 5px 5px 7px;
-}
-
-dl
-{
- padding: 0 0 0 10px;
-}
-
-/* dl.note, dl.warning, dl.attention, dl.pre, dl.post, dl.invariant, dl.deprecated, dl.todo, dl.test, dl.bug */
-dl.section
-{
- margin-left: 0px;
- padding-left: 0px;
-}
-
-dl.note
-{
- margin-left:-7px;
- padding-left: 3px;
- border-left:4px solid;
- border-color: #D0C000;
-}
-
-dl.warning, dl.attention
-{
- margin-left:-7px;
- padding-left: 3px;
- border-left:4px solid;
- border-color: #FF0000;
-}
-
-dl.pre, dl.post, dl.invariant
-{
- margin-left:-7px;
- padding-left: 3px;
- border-left:4px solid;
- border-color: #00D000;
-}
-
-dl.deprecated
-{
- margin-left:-7px;
- padding-left: 3px;
- border-left:4px solid;
- border-color: #505050;
-}
-
-dl.todo
-{
- margin-left:-7px;
- padding-left: 3px;
- border-left:4px solid;
- border-color: #00C0E0;
-}
-
-dl.test
-{
- margin-left:-7px;
- padding-left: 3px;
- border-left:4px solid;
- border-color: #3030E0;
-}
-
-dl.bug
-{
- margin-left:-7px;
- padding-left: 3px;
- border-left:4px solid;
- border-color: #C08050;
-}
-
-dl.section dd {
- margin-bottom: 6px;
-}
-
-
-#projectlogo
-{
- text-align: center;
- vertical-align: bottom;
- border-collapse: separate;
-}
-
-#projectlogo img
-{
- border: 0px none;
-}
-
-#projectname
-{
- font: 300% Tahoma, Arial,sans-serif;
- margin: 0px;
- padding: 2px 0px;
-}
-
-#projectbrief
-{
- font: 120% Tahoma, Arial,sans-serif;
- margin: 0px;
- padding: 0px;
-}
-
-#projectnumber
-{
- font: 50% Tahoma, Arial,sans-serif;
- margin: 0px;
- padding: 0px;
-}
-
-#titlearea
-{
- padding: 0px;
- margin: 0px;
- width: 100%;
- border-bottom: 1px solid #5072B7;
-}
-
-.image
-{
- text-align: left;
-}
-
-.dotgraph
-{
- text-align: center;
-}
-
-.mscgraph
-{
- text-align: center;
-}
-
-.caption
-{
- font-weight: bold;
-}
-
-div.zoom
-{
- border: 1px solid #8EA4D0;
-}
-
-dl.citelist {
- margin-bottom:50px;
-}
-
-dl.citelist dt {
- color:#314877;
- float:left;
- font-weight:bold;
- margin-right:10px;
- padding:5px;
-}
-
-dl.citelist dd {
- margin:2px 0;
- padding:5px 0;
-}
-
-div.toc {
- padding: 14px 25px;
- background-color: #F4F6FA;
- border: 1px solid #D7DFEE;
- border-radius: 7px 7px 7px 7px;
- float: right;
- height: auto;
- margin: 0 20px 10px 10px;
- width: 200px;
-}
-
-div.toc li {
- background: url("bdwn.png") no-repeat scroll 0 5px transparent;
- font: 10px/1.2 Verdana,DejaVu Sans,Geneva,sans-serif;
- margin-top: 5px;
- padding-left: 10px;
- padding-top: 2px;
-}
-
-div.toc h3 {
- font: bold 12px/1.2 Arial,FreeSans,sans-serif;
- color: #4464A5;
- border-bottom: 0 none;
- margin: 0;
-}
-
-div.toc ul {
- list-style: none outside none;
- border: medium none;
- padding: 0px;
-}
-
-div.toc li.level1 {
- margin-left: 0px;
-}
-
-div.toc li.level2 {
- margin-left: 15px;
-}
-
-div.toc li.level3 {
- margin-left: 30px;
-}
-
-div.toc li.level4 {
- margin-left: 45px;
-}
-
-.inherit_header {
- font-weight: bold;
- color: gray;
- cursor: pointer;
- -webkit-touch-callout: none;
- -webkit-user-select: none;
- -khtml-user-select: none;
- -moz-user-select: none;
- -ms-user-select: none;
- user-select: none;
-}
-
-.inherit_header td {
- padding: 6px 0px 2px 5px;
-}
-
-.inherit {
- display: none;
-}
-
-tr.heading h2 {
- margin-top: 12px;
- margin-bottom: 4px;
-}
-
-@media print
-{
- #top { display: none; }
- #side-nav { display: none; }
- #nav-path { display: none; }
- body { overflow:visible; }
- h1, h2, h3, h4, h5, h6 { page-break-after: avoid; }
- .summary { display: none; }
- .memitem { page-break-inside: avoid; }
- #doc-content
- {
- margin-left:0 !important;
- height:auto !important;
- width:auto !important;
- overflow:inherit;
- display:inline;
- }
-}
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/cmsis_footer.js b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/cmsis_footer.js
deleted file mode 100644
index 9807a9a..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/cmsis_footer.js
+++ /dev/null
@@ -1,3 +0,0 @@
-function writeFooter() {
- document.write('Generated on Mon Dec 5 2022 07:22:56 for CMSIS-NN Version 4.0.0 by Arm Ltd. All rights reserved.');
-};
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/doxygen.css b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/doxygen.css
deleted file mode 100644
index f0f36f8..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/doxygen.css
+++ /dev/null
@@ -1,1366 +0,0 @@
-/* The standard CSS for doxygen 1.8.6 */
-
-body, table, div, p, dl {
- font: 400 14px/22px Roboto,sans-serif;
-}
-
-/* @group Heading Levels */
-
-h1.groupheader {
- font-size: 150%;
-}
-
-.title {
- font: 400 14px/28px Roboto,sans-serif;
- font-size: 150%;
- font-weight: bold;
- margin: 10px 2px;
-}
-
-h2.groupheader {
- border-bottom: 1px solid #879ECB;
- color: #354C7B;
- font-size: 150%;
- font-weight: normal;
- margin-top: 1.75em;
- padding-top: 8px;
- padding-bottom: 4px;
- width: 100%;
-}
-
-h3.groupheader {
- font-size: 100%;
-}
-
-h1, h2, h3, h4, h5, h6 {
- -webkit-transition: text-shadow 0.5s linear;
- -moz-transition: text-shadow 0.5s linear;
- -ms-transition: text-shadow 0.5s linear;
- -o-transition: text-shadow 0.5s linear;
- transition: text-shadow 0.5s linear;
- margin-right: 15px;
-}
-
-h1.glow, h2.glow, h3.glow, h4.glow, h5.glow, h6.glow {
- text-shadow: 0 0 15px cyan;
-}
-
-dt {
- font-weight: bold;
-}
-
-div.multicol {
- -moz-column-gap: 1em;
- -webkit-column-gap: 1em;
- -moz-column-count: 3;
- -webkit-column-count: 3;
-}
-
-p.startli, p.startdd {
- margin-top: 2px;
-}
-
-p.starttd {
- margin-top: 0px;
-}
-
-p.endli {
- margin-bottom: 0px;
-}
-
-p.enddd {
- margin-bottom: 4px;
-}
-
-p.endtd {
- margin-bottom: 2px;
-}
-
-/* @end */
-
-caption {
- font-weight: bold;
-}
-
-span.legend {
- font-size: 70%;
- text-align: center;
-}
-
-h3.version {
- font-size: 90%;
- text-align: center;
-}
-
-div.qindex, div.navtab{
- background-color: #EBEFF6;
- border: 1px solid #A3B4D7;
- text-align: center;
-}
-
-div.qindex, div.navpath {
- width: 100%;
- line-height: 140%;
-}
-
-div.navtab {
- margin-right: 15px;
-}
-
-/* @group Link Styling */
-
-a {
- color: #3D578C;
- font-weight: normal;
- text-decoration: none;
-}
-
-.contents a:visited {
- color: #4665A2;
-}
-
-a:hover {
- text-decoration: underline;
-}
-
-a.qindex {
- font-weight: bold;
-}
-
-a.qindexHL {
- font-weight: bold;
- background-color: #9CAFD4;
- color: #ffffff;
- border: 1px double #869DCA;
-}
-
-.contents a.qindexHL:visited {
- color: #ffffff;
-}
-
-a.el {
- font-weight: bold;
-}
-
-a.elRef {
-}
-
-a.code, a.code:visited, a.line, a.line:visited {
- color: #4665A2;
-}
-
-a.codeRef, a.codeRef:visited, a.lineRef, a.lineRef:visited {
- color: #4665A2;
-}
-
-/* @end */
-
-dl.el {
- margin-left: -1cm;
-}
-
-pre.fragment {
- border: 1px solid #C4CFE5;
- background-color: #FBFCFD;
- padding: 4px 6px;
- margin: 4px 8px 4px 2px;
- overflow: auto;
- word-wrap: break-word;
- font-size: 9pt;
- line-height: 125%;
- font-family: monospace, fixed;
- font-size: 105%;
-}
-
-div.fragment {
- padding: 4px 6px;
- margin: 4px 8px 4px 2px;
- background-color: #FBFCFD;
- border: 1px solid #C4CFE5;
-}
-
-div.line {
- font-family: monospace, fixed;
- font-size: 13px;
- min-height: 13px;
- line-height: 1.0;
- text-wrap: unrestricted;
- white-space: -moz-pre-wrap; /* Moz */
- white-space: -pre-wrap; /* Opera 4-6 */
- white-space: -o-pre-wrap; /* Opera 7 */
- white-space: pre-wrap; /* CSS3 */
- word-wrap: break-word; /* IE 5.5+ */
- text-indent: -53px;
- padding-left: 53px;
- padding-bottom: 0px;
- margin: 0px;
- -webkit-transition-property: background-color, box-shadow;
- -webkit-transition-duration: 0.5s;
- -moz-transition-property: background-color, box-shadow;
- -moz-transition-duration: 0.5s;
- -ms-transition-property: background-color, box-shadow;
- -ms-transition-duration: 0.5s;
- -o-transition-property: background-color, box-shadow;
- -o-transition-duration: 0.5s;
- transition-property: background-color, box-shadow;
- transition-duration: 0.5s;
-}
-
-div.line.glow {
- background-color: cyan;
- box-shadow: 0 0 10px cyan;
-}
-
-
-span.lineno {
- padding-right: 4px;
- text-align: right;
- border-right: 2px solid #0F0;
- background-color: #E8E8E8;
- white-space: pre;
-}
-span.lineno a {
- background-color: #D8D8D8;
-}
-
-span.lineno a:hover {
- background-color: #C8C8C8;
-}
-
-div.ah {
- background-color: black;
- font-weight: bold;
- color: #ffffff;
- margin-bottom: 3px;
- margin-top: 3px;
- padding: 0.2em;
- border: solid thin #333;
- border-radius: 0.5em;
- -webkit-border-radius: .5em;
- -moz-border-radius: .5em;
- box-shadow: 2px 2px 3px #999;
- -webkit-box-shadow: 2px 2px 3px #999;
- -moz-box-shadow: rgba(0, 0, 0, 0.15) 2px 2px 2px;
- background-image: -webkit-gradient(linear, left top, left bottom, from(#eee), to(#000),color-stop(0.3, #444));
- background-image: -moz-linear-gradient(center top, #eee 0%, #444 40%, #000);
-}
-
-div.groupHeader {
- margin-left: 16px;
- margin-top: 12px;
- font-weight: bold;
-}
-
-div.groupText {
- margin-left: 16px;
- font-style: italic;
-}
-
-body {
- background-color: white;
- color: black;
- margin: 0;
-}
-
-div.contents {
- margin-top: 10px;
- margin-left: 12px;
- margin-right: 8px;
-}
-
-td.indexkey {
- background-color: #EBEFF6;
- font-weight: bold;
- border: 1px solid #C4CFE5;
- margin: 2px 0px 2px 0;
- padding: 2px 10px;
- white-space: nowrap;
- vertical-align: top;
-}
-
-td.indexvalue {
- background-color: #EBEFF6;
- border: 1px solid #C4CFE5;
- padding: 2px 10px;
- margin: 2px 0px;
-}
-
-tr.memlist {
- background-color: #EEF1F7;
-}
-
-p.formulaDsp {
- text-align: center;
-}
-
-img.formulaDsp {
-
-}
-
-img.formulaInl {
- vertical-align: middle;
-}
-
-div.center {
- text-align: center;
- margin-top: 0px;
- margin-bottom: 0px;
- padding: 0px;
-}
-
-div.center img {
- border: 0px;
-}
-
-address.footer {
- text-align: right;
- padding-right: 12px;
-}
-
-img.footer {
- border: 0px;
- vertical-align: middle;
-}
-
-/* @group Code Colorization */
-
-span.keyword {
- color: #008000
-}
-
-span.keywordtype {
- color: #604020
-}
-
-span.keywordflow {
- color: #e08000
-}
-
-span.comment {
- color: #800000
-}
-
-span.preprocessor {
- color: #806020
-}
-
-span.stringliteral {
- color: #002080
-}
-
-span.charliteral {
- color: #008080
-}
-
-span.vhdldigit {
- color: #ff00ff
-}
-
-span.vhdlchar {
- color: #000000
-}
-
-span.vhdlkeyword {
- color: #700070
-}
-
-span.vhdllogic {
- color: #ff0000
-}
-
-blockquote {
- background-color: #F7F8FB;
- border-left: 2px solid #9CAFD4;
- margin: 0 24px 0 4px;
- padding: 0 12px 0 16px;
-}
-
-/* @end */
-
-/*
-.search {
- color: #003399;
- font-weight: bold;
-}
-
-form.search {
- margin-bottom: 0px;
- margin-top: 0px;
-}
-
-input.search {
- font-size: 75%;
- color: #000080;
- font-weight: normal;
- background-color: #e8eef2;
-}
-*/
-
-td.tiny {
- font-size: 75%;
-}
-
-.dirtab {
- padding: 4px;
- border-collapse: collapse;
- border: 1px solid #A3B4D7;
-}
-
-th.dirtab {
- background: #EBEFF6;
- font-weight: bold;
-}
-
-hr {
- height: 0px;
- border: none;
- border-top: 1px solid #4A6AAA;
-}
-
-hr.footer {
- height: 1px;
-}
-
-/* @group Member Descriptions */
-
-table.memberdecls {
- border-spacing: 0px;
- padding: 0px;
-}
-
-.memberdecls td, .fieldtable tr {
- -webkit-transition-property: background-color, box-shadow;
- -webkit-transition-duration: 0.5s;
- -moz-transition-property: background-color, box-shadow;
- -moz-transition-duration: 0.5s;
- -ms-transition-property: background-color, box-shadow;
- -ms-transition-duration: 0.5s;
- -o-transition-property: background-color, box-shadow;
- -o-transition-duration: 0.5s;
- transition-property: background-color, box-shadow;
- transition-duration: 0.5s;
-}
-
-.memberdecls td.glow, .fieldtable tr.glow {
- background-color: cyan;
- box-shadow: 0 0 15px cyan;
-}
-
-.mdescLeft, .mdescRight,
-.memItemLeft, .memItemRight,
-.memTemplItemLeft, .memTemplItemRight, .memTemplParams {
- background-color: #F9FAFC;
- border: none;
- margin: 4px;
- padding: 1px 0 0 8px;
-}
-
-.mdescLeft, .mdescRight {
- padding: 0px 8px 4px 8px;
- color: #555;
-}
-
-.memSeparator {
- border-bottom: 1px solid #DEE4F0;
- line-height: 1px;
- margin: 0px;
- padding: 0px;
-}
-
-.memItemLeft, .memTemplItemLeft {
- white-space: nowrap;
-}
-
-.memItemRight {
- width: 100%;
-}
-
-.memTemplParams {
- color: #4665A2;
- white-space: nowrap;
- font-size: 80%;
-}
-
-/* @end */
-
-/* @group Member Details */
-
-/* Styles for detailed member documentation */
-
-.memtemplate {
- font-size: 80%;
- color: #4665A2;
- font-weight: normal;
- margin-left: 9px;
-}
-
-.memnav {
- background-color: #EBEFF6;
- border: 1px solid #A3B4D7;
- text-align: center;
- margin: 2px;
- margin-right: 15px;
- padding: 2px;
-}
-
-.mempage {
- width: 100%;
-}
-
-.memitem {
- padding: 0;
- margin-bottom: 10px;
- margin-right: 5px;
- -webkit-transition: box-shadow 0.5s linear;
- -moz-transition: box-shadow 0.5s linear;
- -ms-transition: box-shadow 0.5s linear;
- -o-transition: box-shadow 0.5s linear;
- transition: box-shadow 0.5s linear;
- display: table !important;
- width: 100%;
-}
-
-.memitem.glow {
- box-shadow: 0 0 15px cyan;
-}
-
-.memname {
- font-weight: bold;
- margin-left: 6px;
-}
-
-.memname td {
- vertical-align: bottom;
-}
-
-.memproto, dl.reflist dt {
- border-top: 1px solid #A8B8D9;
- border-left: 1px solid #A8B8D9;
- border-right: 1px solid #A8B8D9;
- padding: 6px 0px 6px 0px;
- color: #253555;
- font-weight: bold;
- text-shadow: 0px 1px 1px rgba(255, 255, 255, 0.9);
- background-image:url('nav_f.png');
- background-repeat:repeat-x;
- background-color: #E2E8F2;
- /* opera specific markup */
- box-shadow: 5px 5px 5px rgba(0, 0, 0, 0.15);
- border-top-right-radius: 4px;
- border-top-left-radius: 4px;
- /* firefox specific markup */
- -moz-box-shadow: rgba(0, 0, 0, 0.15) 5px 5px 5px;
- -moz-border-radius-topright: 4px;
- -moz-border-radius-topleft: 4px;
- /* webkit specific markup */
- -webkit-box-shadow: 5px 5px 5px rgba(0, 0, 0, 0.15);
- -webkit-border-top-right-radius: 4px;
- -webkit-border-top-left-radius: 4px;
-
-}
-
-.memdoc, dl.reflist dd {
- border-bottom: 1px solid #A8B8D9;
- border-left: 1px solid #A8B8D9;
- border-right: 1px solid #A8B8D9;
- padding: 6px 10px 2px 10px;
- background-color: #FBFCFD;
- border-top-width: 0;
- background-image:url('nav_g.png');
- background-repeat:repeat-x;
- background-color: #FFFFFF;
- /* opera specific markup */
- border-bottom-left-radius: 4px;
- border-bottom-right-radius: 4px;
- box-shadow: 5px 5px 5px rgba(0, 0, 0, 0.15);
- /* firefox specific markup */
- -moz-border-radius-bottomleft: 4px;
- -moz-border-radius-bottomright: 4px;
- -moz-box-shadow: rgba(0, 0, 0, 0.15) 5px 5px 5px;
- /* webkit specific markup */
- -webkit-border-bottom-left-radius: 4px;
- -webkit-border-bottom-right-radius: 4px;
- -webkit-box-shadow: 5px 5px 5px rgba(0, 0, 0, 0.15);
-}
-
-dl.reflist dt {
- padding: 5px;
-}
-
-dl.reflist dd {
- margin: 0px 0px 10px 0px;
- padding: 5px;
-}
-
-.paramkey {
- text-align: right;
-}
-
-.paramtype {
- white-space: nowrap;
-}
-
-.paramname {
- color: #602020;
- white-space: nowrap;
-}
-.paramname em {
- font-style: normal;
-}
-.paramname code {
- line-height: 14px;
-}
-
-.params, .retval, .exception, .tparams {
- margin-left: 0px;
- padding-left: 0px;
-}
-
-.params .paramname, .retval .paramname {
- font-weight: bold;
- vertical-align: top;
-}
-
-.params .paramtype {
- font-style: italic;
- vertical-align: top;
-}
-
-.params .paramdir {
- font-family: "courier new",courier,monospace;
- vertical-align: top;
-}
-
-table.mlabels {
- border-spacing: 0px;
-}
-
-td.mlabels-left {
- width: 100%;
- padding: 0px;
-}
-
-td.mlabels-right {
- vertical-align: bottom;
- padding: 0px;
- white-space: nowrap;
-}
-
-span.mlabels {
- margin-left: 8px;
-}
-
-span.mlabel {
- background-color: #728DC1;
- border-top:1px solid #5373B4;
- border-left:1px solid #5373B4;
- border-right:1px solid #C4CFE5;
- border-bottom:1px solid #C4CFE5;
- text-shadow: none;
- color: white;
- margin-right: 4px;
- padding: 2px 3px;
- border-radius: 3px;
- font-size: 7pt;
- white-space: nowrap;
- vertical-align: middle;
-}
-
-
-
-/* @end */
-
-/* these are for tree view when not used as main index */
-
-div.directory {
- margin: 10px 0px;
- border-top: 1px solid #A8B8D9;
- border-bottom: 1px solid #A8B8D9;
- width: 100%;
-}
-
-.directory table {
- border-collapse:collapse;
-}
-
-.directory td {
- margin: 0px;
- padding: 0px;
- vertical-align: top;
-}
-
-.directory td.entry {
- white-space: nowrap;
- padding-right: 6px;
- padding-top: 3px;
-}
-
-.directory td.entry a {
- outline:none;
-}
-
-.directory td.entry a img {
- border: none;
-}
-
-.directory td.desc {
- width: 100%;
- padding-left: 6px;
- padding-right: 6px;
- padding-top: 3px;
- border-left: 1px solid rgba(0,0,0,0.05);
-}
-
-.directory tr.even {
- padding-left: 6px;
- background-color: #F7F8FB;
-}
-
-.directory img {
- vertical-align: -30%;
-}
-
-.directory .levels {
- white-space: nowrap;
- width: 100%;
- text-align: right;
- font-size: 9pt;
-}
-
-.directory .levels span {
- cursor: pointer;
- padding-left: 2px;
- padding-right: 2px;
- color: #3D578C;
-}
-
-div.dynheader {
- margin-top: 8px;
- -webkit-touch-callout: none;
- -webkit-user-select: none;
- -khtml-user-select: none;
- -moz-user-select: none;
- -ms-user-select: none;
- user-select: none;
-}
-
-address {
- font-style: normal;
- color: #2A3D61;
-}
-
-table.doxtable {
- border-collapse:collapse;
- margin-top: 4px;
- margin-bottom: 4px;
-}
-
-table.doxtable td, table.doxtable th {
- border: 1px solid #2D4068;
- padding: 3px 7px 2px;
-}
-
-table.doxtable th {
- background-color: #374F7F;
- color: #FFFFFF;
- font-size: 110%;
- padding-bottom: 4px;
- padding-top: 5px;
-}
-
-table.fieldtable {
- /*width: 100%;*/
- margin-bottom: 10px;
- border: 1px solid #A8B8D9;
- border-spacing: 0px;
- -moz-border-radius: 4px;
- -webkit-border-radius: 4px;
- border-radius: 4px;
- -moz-box-shadow: rgba(0, 0, 0, 0.15) 2px 2px 2px;
- -webkit-box-shadow: 2px 2px 2px rgba(0, 0, 0, 0.15);
- box-shadow: 2px 2px 2px rgba(0, 0, 0, 0.15);
-}
-
-.fieldtable td, .fieldtable th {
- padding: 3px 7px 2px;
-}
-
-.fieldtable td.fieldtype, .fieldtable td.fieldname {
- white-space: nowrap;
- border-right: 1px solid #A8B8D9;
- border-bottom: 1px solid #A8B8D9;
- vertical-align: top;
-}
-
-.fieldtable td.fieldname {
- padding-top: 3px;
-}
-
-.fieldtable td.fielddoc {
- border-bottom: 1px solid #A8B8D9;
- /*width: 100%;*/
-}
-
-.fieldtable td.fielddoc p:first-child {
- margin-top: 0px;
-}
-
-.fieldtable td.fielddoc p:last-child {
- margin-bottom: 2px;
-}
-
-.fieldtable tr:last-child td {
- border-bottom: none;
-}
-
-.fieldtable th {
- background-image:url('nav_f.png');
- background-repeat:repeat-x;
- background-color: #E2E8F2;
- font-size: 90%;
- color: #253555;
- padding-bottom: 4px;
- padding-top: 5px;
- text-align:left;
- -moz-border-radius-topleft: 4px;
- -moz-border-radius-topright: 4px;
- -webkit-border-top-left-radius: 4px;
- -webkit-border-top-right-radius: 4px;
- border-top-left-radius: 4px;
- border-top-right-radius: 4px;
- border-bottom: 1px solid #A8B8D9;
-}
-
-
-.tabsearch {
- top: 0px;
- left: 10px;
- height: 36px;
- background-image: url('tab_b.png');
- z-index: 101;
- overflow: hidden;
- font-size: 13px;
-}
-
-.navpath ul
-{
- font-size: 11px;
- background-image:url('tab_b.png');
- background-repeat:repeat-x;
- background-position: 0 -5px;
- height:30px;
- line-height:30px;
- color:#8AA0CC;
- border:solid 1px #C2CDE4;
- overflow:hidden;
- margin:0px;
- padding:0px;
-}
-
-.navpath li
-{
- list-style-type:none;
- float:left;
- padding-left:10px;
- padding-right:15px;
- background-image:url('bc_s.png');
- background-repeat:no-repeat;
- background-position:right;
- color:#364D7C;
-}
-
-.navpath li.navelem a
-{
- height:32px;
- display:block;
- text-decoration: none;
- outline: none;
- color: #283A5D;
- font-family: 'Lucida Grande',Geneva,Helvetica,Arial,sans-serif;
- text-shadow: 0px 1px 1px rgba(255, 255, 255, 0.9);
- text-decoration: none;
-}
-
-.navpath li.navelem a:hover
-{
- color:#6884BD;
-}
-
-.navpath li.footer
-{
- list-style-type:none;
- float:right;
- padding-left:10px;
- padding-right:15px;
- background-image:none;
- background-repeat:no-repeat;
- background-position:right;
- color:#364D7C;
- font-size: 8pt;
-}
-
-
-div.summary
-{
- float: right;
- font-size: 8pt;
- padding-right: 5px;
- width: 50%;
- text-align: right;
-}
-
-div.summary a
-{
- white-space: nowrap;
-}
-
-div.ingroups
-{
- font-size: 8pt;
- width: 50%;
- text-align: left;
-}
-
-div.ingroups a
-{
- white-space: nowrap;
-}
-
-div.header
-{
- background-image:url('nav_h.png');
- background-repeat:repeat-x;
- background-color: #F9FAFC;
- margin: 0px;
- border-bottom: 1px solid #C4CFE5;
-}
-
-div.headertitle
-{
- padding: 5px 5px 5px 10px;
-}
-
-dl
-{
- padding: 0 0 0 10px;
-}
-
-/* dl.note, dl.warning, dl.attention, dl.pre, dl.post, dl.invariant, dl.deprecated, dl.todo, dl.test, dl.bug */
-dl.section
-{
- margin-left: 0px;
- padding-left: 0px;
-}
-
-dl.note
-{
- margin-left:-7px;
- padding-left: 3px;
- border-left:4px solid;
- border-color: #D0C000;
-}
-
-dl.warning, dl.attention
-{
- margin-left:-7px;
- padding-left: 3px;
- border-left:4px solid;
- border-color: #FF0000;
-}
-
-dl.pre, dl.post, dl.invariant
-{
- margin-left:-7px;
- padding-left: 3px;
- border-left:4px solid;
- border-color: #00D000;
-}
-
-dl.deprecated
-{
- margin-left:-7px;
- padding-left: 3px;
- border-left:4px solid;
- border-color: #505050;
-}
-
-dl.todo
-{
- margin-left:-7px;
- padding-left: 3px;
- border-left:4px solid;
- border-color: #00C0E0;
-}
-
-dl.test
-{
- margin-left:-7px;
- padding-left: 3px;
- border-left:4px solid;
- border-color: #3030E0;
-}
-
-dl.bug
-{
- margin-left:-7px;
- padding-left: 3px;
- border-left:4px solid;
- border-color: #C08050;
-}
-
-dl.section dd {
- margin-bottom: 6px;
-}
-
-
-#projectlogo
-{
- text-align: center;
- vertical-align: bottom;
- border-collapse: separate;
-}
-
-#projectlogo img
-{
- border: 0px none;
-}
-
-#projectname
-{
- font: 300% Tahoma, Arial,sans-serif;
- margin: 0px;
- padding: 2px 0px;
-}
-
-#projectbrief
-{
- font: 120% Tahoma, Arial,sans-serif;
- margin: 0px;
- padding: 0px;
-}
-
-#projectnumber
-{
- font: 50% Tahoma, Arial,sans-serif;
- margin: 0px;
- padding: 0px;
-}
-
-#titlearea
-{
- padding: 0px;
- margin: 0px;
- width: 100%;
- border-bottom: 1px solid #5373B4;
-}
-
-.image
-{
- text-align: center;
-}
-
-.dotgraph
-{
- text-align: center;
-}
-
-.mscgraph
-{
- text-align: center;
-}
-
-.diagraph
-{
- text-align: center;
-}
-
-.caption
-{
- font-weight: bold;
-}
-
-div.zoom
-{
- border: 1px solid #90A5CE;
-}
-
-dl.citelist {
- margin-bottom:50px;
-}
-
-dl.citelist dt {
- color:#334975;
- float:left;
- font-weight:bold;
- margin-right:10px;
- padding:5px;
-}
-
-dl.citelist dd {
- margin:2px 0;
- padding:5px 0;
-}
-
-div.toc {
- padding: 14px 25px;
- background-color: #F4F6FA;
- border: 1px solid #D8DFEE;
- border-radius: 7px 7px 7px 7px;
- float: right;
- height: auto;
- margin: 0 20px 10px 10px;
- width: 200px;
-}
-
-div.toc li {
- background: url("bdwn.png") no-repeat scroll 0 5px transparent;
- font: 10px/1.2 Verdana,DejaVu Sans,Geneva,sans-serif;
- margin-top: 5px;
- padding-left: 10px;
- padding-top: 2px;
-}
-
-div.toc h3 {
- font: bold 12px/1.2 Arial,FreeSans,sans-serif;
- color: #4665A2;
- border-bottom: 0 none;
- margin: 0;
-}
-
-div.toc ul {
- list-style: none outside none;
- border: medium none;
- padding: 0px;
-}
-
-div.toc li.level1 {
- margin-left: 0px;
-}
-
-div.toc li.level2 {
- margin-left: 15px;
-}
-
-div.toc li.level3 {
- margin-left: 30px;
-}
-
-div.toc li.level4 {
- margin-left: 45px;
-}
-
-.inherit_header {
- font-weight: bold;
- color: gray;
- cursor: pointer;
- -webkit-touch-callout: none;
- -webkit-user-select: none;
- -khtml-user-select: none;
- -moz-user-select: none;
- -ms-user-select: none;
- user-select: none;
-}
-
-.inherit_header td {
- padding: 6px 0px 2px 5px;
-}
-
-.inherit {
- display: none;
-}
-
-tr.heading h2 {
- margin-top: 12px;
- margin-bottom: 4px;
-}
-
-/* tooltip related style info */
-
-.ttc {
- position: absolute;
- display: none;
-}
-
-#powerTip {
- cursor: default;
- white-space: nowrap;
- background-color: white;
- border: 1px solid gray;
- border-radius: 4px 4px 4px 4px;
- box-shadow: 1px 1px 7px gray;
- display: none;
- font-size: smaller;
- max-width: 80%;
- opacity: 0.9;
- padding: 1ex 1em 1em;
- position: absolute;
- z-index: 2147483647;
-}
-
-#powerTip div.ttdoc {
- color: grey;
- font-style: italic;
-}
-
-#powerTip div.ttname a {
- font-weight: bold;
-}
-
-#powerTip div.ttname {
- font-weight: bold;
-}
-
-#powerTip div.ttdeci {
- color: #006318;
-}
-
-#powerTip div {
- margin: 0px;
- padding: 0px;
- font: 12px/16px Roboto,sans-serif;
-}
-
-#powerTip:before, #powerTip:after {
- content: "";
- position: absolute;
- margin: 0px;
-}
-
-#powerTip.n:after, #powerTip.n:before,
-#powerTip.s:after, #powerTip.s:before,
-#powerTip.w:after, #powerTip.w:before,
-#powerTip.e:after, #powerTip.e:before,
-#powerTip.ne:after, #powerTip.ne:before,
-#powerTip.se:after, #powerTip.se:before,
-#powerTip.nw:after, #powerTip.nw:before,
-#powerTip.sw:after, #powerTip.sw:before {
- border: solid transparent;
- content: " ";
- height: 0;
- width: 0;
- position: absolute;
-}
-
-#powerTip.n:after, #powerTip.s:after,
-#powerTip.w:after, #powerTip.e:after,
-#powerTip.nw:after, #powerTip.ne:after,
-#powerTip.sw:after, #powerTip.se:after {
- border-color: rgba(255, 255, 255, 0);
-}
-
-#powerTip.n:before, #powerTip.s:before,
-#powerTip.w:before, #powerTip.e:before,
-#powerTip.nw:before, #powerTip.ne:before,
-#powerTip.sw:before, #powerTip.se:before {
- border-color: rgba(128, 128, 128, 0);
-}
-
-#powerTip.n:after, #powerTip.n:before,
-#powerTip.ne:after, #powerTip.ne:before,
-#powerTip.nw:after, #powerTip.nw:before {
- top: 100%;
-}
-
-#powerTip.n:after, #powerTip.ne:after, #powerTip.nw:after {
- border-top-color: #ffffff;
- border-width: 10px;
- margin: 0px -10px;
-}
-#powerTip.n:before {
- border-top-color: #808080;
- border-width: 11px;
- margin: 0px -11px;
-}
-#powerTip.n:after, #powerTip.n:before {
- left: 50%;
-}
-
-#powerTip.nw:after, #powerTip.nw:before {
- right: 14px;
-}
-
-#powerTip.ne:after, #powerTip.ne:before {
- left: 14px;
-}
-
-#powerTip.s:after, #powerTip.s:before,
-#powerTip.se:after, #powerTip.se:before,
-#powerTip.sw:after, #powerTip.sw:before {
- bottom: 100%;
-}
-
-#powerTip.s:after, #powerTip.se:after, #powerTip.sw:after {
- border-bottom-color: #ffffff;
- border-width: 10px;
- margin: 0px -10px;
-}
-
-#powerTip.s:before, #powerTip.se:before, #powerTip.sw:before {
- border-bottom-color: #808080;
- border-width: 11px;
- margin: 0px -11px;
-}
-
-#powerTip.s:after, #powerTip.s:before {
- left: 50%;
-}
-
-#powerTip.sw:after, #powerTip.sw:before {
- right: 14px;
-}
-
-#powerTip.se:after, #powerTip.se:before {
- left: 14px;
-}
-
-#powerTip.e:after, #powerTip.e:before {
- left: 100%;
-}
-#powerTip.e:after {
- border-left-color: #ffffff;
- border-width: 10px;
- top: 50%;
- margin-top: -10px;
-}
-#powerTip.e:before {
- border-left-color: #808080;
- border-width: 11px;
- top: 50%;
- margin-top: -11px;
-}
-
-#powerTip.w:after, #powerTip.w:before {
- right: 100%;
-}
-#powerTip.w:after {
- border-right-color: #ffffff;
- border-width: 10px;
- top: 50%;
- margin-top: -10px;
-}
-#powerTip.w:before {
- border-right-color: #808080;
- border-width: 11px;
- top: 50%;
- margin-top: -11px;
-}
-
-@media print
-{
- #top { display: none; }
- #side-nav { display: none; }
- #nav-path { display: none; }
- body { overflow:visible; }
- h1, h2, h3, h4, h5, h6 { page-break-after: avoid; }
- .summary { display: none; }
- .memitem { page-break-inside: avoid; }
- #doc-content
- {
- margin-left:0 !important;
- height:auto !important;
- width:auto !important;
- overflow:inherit;
- display:inline;
- }
-}
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/doxygen.png b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/doxygen.png
deleted file mode 100644
index 3ff17d8..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/doxygen.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/dynsections.js b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/dynsections.js
deleted file mode 100644
index ed092c7..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/dynsections.js
+++ /dev/null
@@ -1,97 +0,0 @@
-function toggleVisibility(linkObj)
-{
- var base = $(linkObj).attr('id');
- var summary = $('#'+base+'-summary');
- var content = $('#'+base+'-content');
- var trigger = $('#'+base+'-trigger');
- var src=$(trigger).attr('src');
- if (content.is(':visible')===true) {
- content.hide();
- summary.show();
- $(linkObj).addClass('closed').removeClass('opened');
- $(trigger).attr('src',src.substring(0,src.length-8)+'closed.png');
- } else {
- content.show();
- summary.hide();
- $(linkObj).removeClass('closed').addClass('opened');
- $(trigger).attr('src',src.substring(0,src.length-10)+'open.png');
- }
- return false;
-}
-
-function updateStripes()
-{
- $('table.directory tr').
- removeClass('even').filter(':visible:even').addClass('even');
-}
-function toggleLevel(level)
-{
- $('table.directory tr').each(function(){
- var l = this.id.split('_').length-1;
- var i = $('#img'+this.id.substring(3));
- var a = $('#arr'+this.id.substring(3));
- if (l
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ftv2blank.png b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ftv2blank.png
deleted file mode 100644
index 63c605b..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ftv2blank.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ftv2cl.png b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ftv2cl.png
deleted file mode 100644
index 132f657..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ftv2cl.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ftv2doc.png b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ftv2doc.png
deleted file mode 100644
index 17edabf..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ftv2doc.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ftv2folderclosed.png b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ftv2folderclosed.png
deleted file mode 100644
index bb8ab35..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ftv2folderclosed.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ftv2folderopen.png b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ftv2folderopen.png
deleted file mode 100644
index d6c7f67..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ftv2folderopen.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ftv2lastnode.png b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ftv2lastnode.png
deleted file mode 100644
index 63c605b..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ftv2lastnode.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ftv2link.png b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ftv2link.png
deleted file mode 100644
index 17edabf..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ftv2link.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ftv2mlastnode.png b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ftv2mlastnode.png
deleted file mode 100644
index 0b63f6d..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ftv2mlastnode.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ftv2mnode.png b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ftv2mnode.png
deleted file mode 100644
index 0b63f6d..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ftv2mnode.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ftv2mo.png b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ftv2mo.png
deleted file mode 100644
index 4bfb80f..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ftv2mo.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ftv2node.png b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ftv2node.png
deleted file mode 100644
index 63c605b..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ftv2node.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ftv2ns.png b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ftv2ns.png
deleted file mode 100644
index 72e3d71..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ftv2ns.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ftv2plastnode.png b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ftv2plastnode.png
deleted file mode 100644
index c6ee22f..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ftv2plastnode.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ftv2pnode.png b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ftv2pnode.png
deleted file mode 100644
index c6ee22f..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ftv2pnode.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ftv2splitbar.png b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ftv2splitbar.png
deleted file mode 100644
index fe895f2..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ftv2splitbar.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ftv2vertline.png b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ftv2vertline.png
deleted file mode 100644
index 63c605b..0000000
Binary files a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/ftv2vertline.png and /dev/null differ
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/functions.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/functions.html
deleted file mode 100644
index 3ffa2c8..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/functions.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/functions_vars.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/functions_vars.html
deleted file mode 100644
index 6efe536..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/functions_vars.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals.html
deleted file mode 100644
index 2db58a2..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_a.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_a.html
deleted file mode 100644
index 45cf753..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_a.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_c.html
deleted file mode 100644
index 6cd5d4d..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_d.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_d.html
deleted file mode 100644
index ecaa85d..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_d.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_defs.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_defs.html
deleted file mode 100644
index 93c32eb..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_defs.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_e.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_e.html
deleted file mode 100644
index 794932e..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_e.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_enum.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_enum.html
deleted file mode 100644
index 797f9a0..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_enum.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_eval.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_eval.html
deleted file mode 100644
index 27be460..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_eval.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_f.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_f.html
deleted file mode 100644
index 220c0e1..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_f.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_func.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_func.html
deleted file mode 100644
index 449d123..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_func.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_func_a.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_func_a.html
deleted file mode 100644
index 31a852b..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_func_a.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_func_c.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_func_c.html
deleted file mode 100644
index ab087da..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_func_c.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_func_d.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_func_d.html
deleted file mode 100644
index 619a906..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_func_d.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_func_e.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_func_e.html
deleted file mode 100644
index b84c92d..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_func_e.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_func_f.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_func_f.html
deleted file mode 100644
index 2a6e00e..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_func_f.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_func_l.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_func_l.html
deleted file mode 100644
index 03a0e14..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_func_l.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_func_m.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_func_m.html
deleted file mode 100644
index fa07cda..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_func_m.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_func_n.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_func_n.html
deleted file mode 100644
index 8b93d6d..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_func_n.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_func_q.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_func_q.html
deleted file mode 100644
index ec0efc0..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_func_q.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_func_r.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_func_r.html
deleted file mode 100644
index a2a2ea4..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_func_r.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_func_s.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_func_s.html
deleted file mode 100644
index ea79dd7..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_func_s.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_func_t.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_func_t.html
deleted file mode 100644
index a629b92..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_func_t.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_l.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_l.html
deleted file mode 100644
index 600a2a4..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_l.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_m.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_m.html
deleted file mode 100644
index e2b93c5..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_m.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_n.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_n.html
deleted file mode 100644
index 0d5c5aa..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_n.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_o.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_o.html
deleted file mode 100644
index 9ccd70c..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_o.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_p.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_p.html
deleted file mode 100644
index 66aa9d9..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_p.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_q.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_q.html
deleted file mode 100644
index 7fffd64..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_q.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_r.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_r.html
deleted file mode 100644
index bec8ca7..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_r.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_s.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_s.html
deleted file mode 100644
index e0820e3..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_s.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_t.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_t.html
deleted file mode 100644
index c3d8a0e..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_t.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_type.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_type.html
deleted file mode 100644
index b16938e..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_type.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_u.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_u.html
deleted file mode 100644
index e4ce19d..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_u.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_vars.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_vars.html
deleted file mode 100644
index c4aa788..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/globals_vars.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/group__Acti.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/group__Acti.html
deleted file mode 100644
index 1f8a8a3..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/group__Acti.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/group__BasicMath.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/group__BasicMath.html
deleted file mode 100644
index fa5154c..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/group__BasicMath.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/group__Concatenation.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/group__Concatenation.html
deleted file mode 100644
index f4034db..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/group__Concatenation.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/group__FC.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/group__FC.html
deleted file mode 100644
index 22dabff..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/group__FC.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/group__NNBasicMath.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/group__NNBasicMath.html
deleted file mode 100644
index bf6520d..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/group__NNBasicMath.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/group__NNConv.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/group__NNConv.html
deleted file mode 100644
index 38a8825..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/group__NNConv.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/group__Pooling.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/group__Pooling.html
deleted file mode 100644
index 5a398bb..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/group__Pooling.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/group__Reshape.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/group__Reshape.html
deleted file mode 100644
index 9686f63..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/group__Reshape.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/group__SVDF.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/group__SVDF.html
deleted file mode 100644
index c4aa0f7..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/group__SVDF.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/group__Softmax.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/group__Softmax.html
deleted file mode 100644
index 30180c7..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/group__Softmax.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/group__groupNN.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/group__groupNN.html
deleted file mode 100644
index 8e2e628..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/group__groupNN.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/group__nndata__convert.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/group__nndata__convert.html
deleted file mode 100644
index e8d86e2..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/group__nndata__convert.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/history_8txt.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/history_8txt.html
deleted file mode 100644
index d672c11..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/history_8txt.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-Redirect to the corresponding CMSIS-NN page after 0 seconds
-here or try to find corresponding topic described in CMSIS-NN resources .
-
-
-
diff --git a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/index.html b/external/CMSIS_5/CMSIS/DoxyGen/NN/html/index.html
deleted file mode 100644
index da4e129..0000000
--- a/external/CMSIS_5/CMSIS/DoxyGen/NN/html/index.html
+++ /dev/null
@@ -1,101 +0,0 @@
-
-
-
-CMSIS NN Software Library
-CMSIS-NN: CMSIS NN Software Library
-
-
-
-
-
-
- CMSIS-NN
-
-
-
- 
-
-
- 
-