Firmware/FreeRTOS-RISCV
8
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Initial version

Browse Source
This commit is contained in:
Eyck Jentzsch
2019-06-28 23:08:36 +02:00
commit 4d8973e20b
2426 changed files with 948029 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

389
FreeRTOSv10.2.1/FreeRTOS-Plus/Source/Reliance-Edge/doc/coding_style.txt Normal file
View File

@ -0,0 +1,389 @@
Datalight Coding Style
======================
This is a description of the Datalight Coding Style intended for third parties
who want to contribute code to Reliance Edge. This document is derived from the
DDSS Coding Guidelines, but only contains a subset of the content which is most
likely to be relevant to third party contributors.
Reliance Edge complies with the MISRA-C:2012 coding guidelines, which includes
many rules that affect coding style. Unfortunately the MISRA-C:2012 document is
not freely available, and is much too long to be effectively summarized, but if
you are familiar with the rules, adhere to them. A few important rules of
thumb: avoid the goto and continue keywords; avoid using more than one break
in a loop; and avoid having more than one return from a function (single point
of exit); default cases in every switch statement; avoid recursion; and make
generous use of parentheses. Outside of the file system driver, in tests and
host tools, the MISRA-C rules are relaxed.
Beyond MISRA-C, Datalight has a standard coding style. Most aspects of this
style are matters of preference, but when contributing code to Datalight an
effort should be made to use this style for the sake of consistency.
Below is an example function, which illustrates several key points of Datalight
Coding Style:
/** @brief One-sentence description of what this function does.
Additional description.
@param ulFirstParameter Description of the parameter.
@param pszPointer Description of the parameter.
@return Describe the return value.
@retval true Optional description of specific return value.
@retval false Optional description of specific return value.
*/
bool ExampleFunction(
uint32_t ulFirstParameter,
char *pszPointer)
{
bool fStatus = true;
/* This is a single-line comment.
*/
if(ulFirstParameter > 0U)
{
/* This is a multi-line comment. Filler text: Lorem ipsum dolor sit
amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt
ut labore et dolore magna aliqua.
*/
FunctionCall();
while(fStatus)
{
fStatus = AnotherFunction(ulFirstParameter, pszPointer);
}
}
return fStatus;
}
Tab Stop Conventions
--------------------
In all C code (.c/.h), use a tab width of four spaces, and use soft tabs (in
other words, tabs are expanded to spaces). In Makefiles, use hard tabs and a
tab width of 8.
Naming
------
Datalight uses CamelCase for functions and variables. Type names are generally
UPPERCASE, except for standard types like uint32_t. Preprocessor macros are
UPPERCASE, with words separated by underscores (for example, INODE_INVALID).
Doxygen Documentation
---------------------
Doxygen is used to document functions (including static functions), along with
types, structures, files, etc. For Doxygen tags, use '@' instead of a backslash
(thus "@param" not "\param").
Function Declarations
---------------------
Multi-line function declarations are preferred, as they tend to be more
readable. Use the following form:
static bool ExampleFunctionDeclaration(
uint32_t ulFirstParameter,
char *pszPointer,
uint8_t **ppbBuffer)
{
uint16_t uLocalVar; /* descriptive comment */
uint8_t *pbBuffer = NULL; /* descriptive comment */
Function body...
}
The following guidelines should be used:
- Align both the data-type and the variable names, for parameters and locals, at
the same level if practical.
- For pointer types, the '*' belongs to the variable name---it's not part of the
data-type, so keep it with the variable name.
- If useful, single line comments may be used to describe local variables (not
a requirement).
- For functions with no parameters, the "void" declaration does not need to be
on a separate line.
- Generally each variable should be declared on a separate line. This promotes
readability, and facilitates having a comment for each variable.
Function declarations should be spaced apart by two blank lines between the
closing brace which ends a function and the Doxygen comment which starts the
next.
Curly Braces
------------
Datalight lines up all curly braces vertically. As per MISRA-C, curly braces
are never omitted, even if the braces contain only a single statement.
For consistency, even structure declarations and initializations should use the
same style, with the curly braces lined up vertically. One exception is for
structure initializations where both the opening and closing curly braces can
fit on the same line. If so, do it.
Code Comments
-------------
Datalight uses the standard C style /* comments */. C++ style comments (//) are
never used. The Datalight standard comment style is shown below. This style
applies to all general comments within the code.
/* This is a single-line comment.
*/
if(ulFirstParameter > 0U)
{
/* This is a multi-line comment. Filler text: Lorem ipsum dolor sit amet,
consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore
et dolore magna aliqua.
*/
while(fStatus)
{
}
}
Note the characteristics:
- The /* and */ align with the natural 4 character indentation.
- The comment text is exactly indented another 4 characters.
- The comment text starts on the same line as the opening /*.
- The terminating */ is on its own line.
- There is usually a single blank line preceding the comment, however if the
preceding line is an opening curly brace, then an extra blank line is not
necessary.
- There is usually no blank line after the comment, but rather the closing */
"attaches" the comment to the code about which the comment refers.
- These comments should always fit with the standard 80 character margin.
Comments where the /* and */ are on the same line may be used in a few places:
- For variable or parameter descriptions, where the comment fits on the same
line as the declaration.
- For structure member declarations, where the comment fits on the same line as
the declaration.
- For macros or preprocessor logic, where the comment fits on the same line.
It is OK for such comments to exceed the 80 character margin by a small amount,
if necessary, as this sometimes promotes code readability.
Indentation Style
-----------------
The general paradigm used in Datalight code is that curly braces line up
vertically, and everything in between them is indented. This should include all
comments, labels, and preprocessor symbols. The only things which are aligned
at the left-most columns are:
- Symbols, variables, declarations, and preprocessor logic which are at the
module-scope (outside of a function)
- Comments which are outside of a function
- Function declarations
- Function open and closing curly braces
Typically comments are always lined up directly with the code to which they
apply.
Labels (when used; gotos are disallowed in driver code) are lined up two
characters to the left of the code they reside in, to make them stand out, while
as the same time, still remaining subservient to the level of curly braces in
which they reside. For example:
bool ExampleLabelUsage(void)
{
MutexLock();
Lots of complicated code...
Unlock:
MutexUnlock();
return fSuccess;
}
Preprocessor logic, such as controlling features which are conditionally
compiled in or out, should not disrupt the flow of the code, but rather should
be indented in similar fashion to the code it controls, but positioned two
characters to the left. For example, consider the following code snippet. The
preprocessor conditions are both indented relative to the outer curly braces,
but do not disrupt the normal code flow.
int32_t red_statvfs(
const char *pszVolume,
REDSTATFS *pStatvfs)
{
REDSTATUS ret;
ret = PosixEnter();
if(ret == 0)
{
uint8_t bVolNum;
ret = RedPathSplit(pszVolume, &bVolNum, NULL);
#if REDCONF_VOLUME_COUNT > 1U
if(ret == 0)
{
ret = RedCoreVolSetCurrent(bVolNum);
}
#endif
if(ret == 0)
{
ret = RedCoreVolStat(pStatvfs);
}
PosixLeave();
}
return PosixReturn(ret);
}
Note that, like anything else between curly brackets, the contents of a switch
statement are indented:
switch(ulSignature)
{
case META_SIG_MASTER:
fValid = (uFlags == BFLAG_META_MASTER);
break;
case META_SIG_IMAP:
fValid = (uFlags == BFLAG_META_IMAP);
break;
case META_SIG_INODE:
fValid = (uFlags == BFLAG_META_INODE);
break;
case META_SIG_DINDIR:
fValid = (uFlags == BFLAG_META_DINDIR);
break;
case META_SIG_INDIR:
fValid = (uFlags == BFLAG_META_INDIR);
break;
default:
fValid = false;
break;
}
Maximum Line Length
-------------------
The maximum line length for code need not be rigidly limited to the traditional
80 characters. Nevertheless the line lengths should be kept reasonable.
Anything longer than 100 to 120 characters should probably be broken up. The
most important consideration is readability---fitting on the screen is important
for readability, but equally important is facilitating an easy understanding of
the logical code flow.
There are a few exceptions on both sides of the issue. Generally comments
should be limited to 80 characters always. Some lines of code may exceed the
120 character length by a large margin, if it makes the code more understandable
and maintainable. This is especially true when dealing with code that generates
output which needs to be lined up.
Regardless of everything else, no lines should exceed 250 characters because
some editors cannot handle anything larger.
Maximum Display Output Line Length
----------------------------------
Any code which displays TTY style output, whether on a screen or a terminal,
should be constructed so the output is readable and wraps properly on an 80
character wide display. This primarily applies to the "standard" output from
various tests and tools as well as syntax output for those tests and tools;
debug output can violate this rule.
Preprocessor Notation
---------------------
Don't use preprocessor notation where the # is separated from the keyword by one
or more white spaces. For example, don't do:
#ifndef SYMBOL1
# define SYMBOL1
#endif
Instead, do:
#ifndef SYMBOL1
#define SYMBOL1
#endif
Hexadecimal Notation
--------------------
Use uppercase for any alphabetic hexadecimal digits, and lower case for the
notational element. For example:
#define HEXNUM 0x123abd /* Bad */
#define HEXNUM 0X123ABD /* Bad */
#define HEXNUM 0x123ABD /* Good */
Hungarian Notation
------------------
Datalight uses Hungarian notation. The following type prefixes are used:
Type Prefix | Meaning
----------- | -------
c | char
uc | unsigned char
i | int
n | unsigned int or size_t
b | uint8_t
u | uint16_t
ul | uint32_t
ull | uint64_t
sz | array of char that will be null-terminated
f | bool
h | A handle
fn | A function (always used with the "p" modifier)
There is no official Hungarian for int8_t, int16_t, int32_t, or int64_t,
although some code uses unofficial variants (like "ll" for int64_t).
The following modifiers may be used in combination with the type prefixes
defined above, or in combination with other types:
Modifier | Meaning
-------- | -------
a | An array
p | A pointer
g | A global variable
Notes:
- There is no standard Hungarian for structure declarations, however the use of
the "a" and "p" modifiers is completely appropriate (and expected).
- For those data types which do not have any standard defined Hungarian prefix,
using none is preferable to misusing another prefix which would lead to
confusion.
- The "p" pointer modifier must be used such that a variable which is a pointer
to a pointer uses multiple "p" prefixes. A general rule-of-thumb is that the
variable name should have the same number of "p" prefixes as the declaration
has asterisks. This allows pointer expressions to be easily decoded using
cancellation.
Variable Scope
--------------
Declare a variable in the narrowest scope in which it is meaningful.
Unnecessarily declaring all variables at the beginning of a function, where they
may be physically far from where they are actually used, makes the code harder
to maintain.
When multiple blocks of code share a variable, but not its value, declare the
variable separately for each code block.
For example, if two separate blocks contain loops indexed by a variable ulIndex
declare it separately in each block rather than declaring it once in a wider
scope and using it in both places.
Using distinct declarations in the two blocks allows the compiler to check for
failure to initialize the variable in the second block. If there is a single
declaration, the (now meaningless) value left over from the first block can be
used erroneously in the second block.

135
FreeRTOSv10.2.1/FreeRTOS-Plus/Source/Reliance-Edge/doc/release_notes.md Normal file
View File

@ -0,0 +1,135 @@
# Reliance Edge Release Notes
This file contains a list of updates made to Reliance Edge over the course of
recent releases and a list of known issues.
## Release History and Changes
### Reliance Edge v2.0, January 2017
- Added support for Linux as a host environment
- All "host" projects may now be built in either Windows or Linux using the
`make` command. The formatter and image builder are built, and the checker
and image copier are also built in the commercial kit.
- An additional host tool has been added for Linux only: `redfuse`. It is a
File System in User Space (FUSE) implementation, allowing a Reliance Edge
volume to be mounted directly on Linux for easy access. It is built from
the host project folder using the command `make redfuse`.
- The OS-specific API test (commercial kit only) is now ported to run on Linux
for the purpose of verifying the FUSE implementation.
- Fixed a bug that could leave a directory in an invalid state after removing
files. For example, an affected directory might report a non-zero length even
after all files had been deleted.
- Fixed a bug that would leave the driver in a bad state if a mount operation
failed due to missing or corrupt metaroot blocks.
### Reliance Edge v1.1 (Beta), November 2016
- Added support for a discard (trim) interface in the commercial kit. While
discards are not integral to the behavior of the filesystem, they allow
certain types of Flash drivers and media to perform at optimal speed and
efficiency. The commercial version of Reliance Edge now allows the user to
implement this interface for compatible storage media.
- This change added new fields to the configuration files redconf.h and
redconf.c. The configuration utility has been updated to version 1.1 and
existing configuration files must be updated using the updated utility.
- The configuration utility now has keyboard shortcuts for opening and saving
the configuration.
- The configuration utility now adds version macros to easily identify when an
outdated configuration file is used with Reliance Edge or vice versa.
### Reliance Edge v1.0.4, July 2016
- Added ARM mbed and ARM mbed OS support in the commercial kit, with an example
projects for ARM mbed OS on the NXP FRDM-K64F board.
- Some minor deficiencies in the POSIX-like API test suite have been addressed.
### Reliance Edge v1.0.3, June 2016
- Added support for static memory allocation configuration in FreeRTOS
version 9. No common code changes.
### Reliance Edge v1.0.2, February 2016
#### Common Code Changes
- A new per-volume configuration option has been added: users can specify a
number of times to retry a block device read, write or flush operation before
returning a failure. The configuration tool has been updated to version 1.0.2
with this change.
- This added a new field to the volume configuration in redconf.c: existing
redconf.c files from v1.0.1 and earlier must be updated to work with v1.0.2.
Open redconf.h and redconf.c with the configuration tool, enable
"Retry block device I/O on failure" for any volumes if desired, and save the
redconf files.
#### FreeRTOS Port Changes
- Added support for the STM32 HAL SD card driver in the FreeRTOS block device
interface. Two boards are supported out-of-the-box: the STM324xG-EVAL and the
STM32F746NG-Discovery. A sample project is included for the STM324xG-EVAL.
#### MQX Port Changes
- Fixed a bug which prevented Reliance Edge from compiling if the File System
Essentials API was selected in the configuration.
- Fixed a bug which would have returned an uninitialized value from
`RedOsBDevFlush()` for block devices that support flushing.
### Reliance Edge v1.0.1, October 2015
- Added MQX RTOS support in the commercial kit, with example projects for
the Kinetis Design Studio.
- Bug fix in the F_DRIVER implementation of the FreeRTOS block device service.
### Reliance Edge v1.0, July 2015
#### Common Code Changes
- First release of commercial kit and MISRA C:2012 Design Assurance Package.
The commercial kit includes many new tools and tests which were not previously
available.
- Overhauled parsing of command-line parameters to be consistent for all tools
and tests. Command-line tools now use Unix-style short and long options (such
as `-H` and `--help`) instead of DOS-style switches (such as `/?`).
- Renamed all os/\*/include/ostypes.h headers to os/\*/include/redostypes.h, so
that all headers use the product prefix. If you created a port using v0.9,
this header needs to be renamed and its header guard (#ifndef OSTYPES_H etc.)
should also be updated.
- Add a new header for OS-specific MISRA C:2012 deviation macros, located at
os/\*/include/redosdeviations.h. If you created a port using v0.9, copy the
template from os/stub/include/redosdeviations.h into the include directory.
- Eliminated support for sector sizes less than 256. If using a smaller sector
size (say for a RAM disk), this must now be emulated in the implementation of
the block device OS service.
- Added RedFseFormat() as an optional FSE API, allowing FSE applications to
format the volume at run-time.
- This added a new macro to redconf.h: existing redconf.h files from v0.9 must
be updated to work with v1.0. Open redconf.h with the configuration tool,
ignore the warning about the missing macro, and save it.
- Internal restructuring has renamed the macros for the string and memory
functions used in redconf.h. An existing redconf.h file from v0.9 will need
to be updated; for a file containing the old names, the new config tool will
default to using the (slow) Reliance Edge string/memory functions; to use the
C library or custom versions, this will need to be selected in the
configuration utility.
- Fix a bug which would result in an error when attempting to create a name with
one or more trailing path separators (such as `red_mkdir("/foo/bar/")`).
- Fix a bug where an open handle for an inode on one volume would prevent the
same inode number from being deleted on a different volume.
#### FreeRTOS Port Changes
- The implementation of the timestamp OS service no longer requires that
`configUSE_TIMERS` be set to `1`.
### Reliance Edge v0.9 (Beta), April 2015
First public release.
## Known Issues
### Visual Studio 2005
The Reliance Edge Win32 port (used for the host tools and the Win32 test
project) cannot be compiled by Visual Studio 2005. This is not going to be
fixed since VS2005 is an old toolset. Newer versions of Visual Studio, starting
with Visual Studio 2008, work just fine.

156
FreeRTOSv10.2.1/FreeRTOS-Plus/Source/Reliance-Edge/doc/release_notes.txt Normal file
View File

@ -0,0 +1,156 @@
RELIANCE EDGE RELEASE NOTES
This file contains a list of updates made to Reliance Edge over the
course of recent releases and a list of known issues.
Release History and Changes
Reliance Edge v2.0, January 2017
- Added support for Linux as a host environment
- All "host" projects may now be built in either Windows or Linux
using the make command. The formatter and image builder are built,
and the checker and image copier are also built in the
commercial kit.
- An additional host tool has been added for Linux only: redfuse. It
is a File System in User Space (FUSE) implementation, allowing a
Reliance Edge volume to be mounted directly on Linux for
easy access. It is built from the host project folder using the
command make redfuse.
- The OS-specific API test (commercial kit only) is now ported to run
on Linux for the purpose of verifying the FUSE implementation.
- Fixed a bug that could leave a directory in an invalid state after
removing files. For example, an affected directory might report a
non-zero length even after all files had been deleted.
- Fixed a bug that would leave the driver in a bad state if a mount
operation failed due to missing or corrupt metaroot blocks.
Reliance Edge v1.1 (Beta), November 2016
- Added support for a discard (trim) interface in the commercial kit.
While discards are not integral to the behavior of the filesystem,
they allow certain types of Flash drivers and media to perform at
optimal speed and efficiency. The commercial version of Reliance
Edge now allows the user to implement this interface for compatible
storage media.
- This change added new fields to the configuration files redconf.h
and redconf.c. The configuration utility has been updated to version
1.1 and existing configuration files must be updated using the
updated utility.
- The configuration utility now has keyboard shortcuts for opening and
saving the configuration.
- The configuration utility now adds version macros to easily identify
when an outdated configuration file is used with Reliance Edge or
vice versa.
Reliance Edge v1.0.4, July 2016
- Added ARM mbed and ARM mbed OS support in the commercial kit, with
an example projects for ARM mbed OS on the NXP FRDM-K64F board.
- Some minor deficiencies in the POSIX-like API test suite have
been addressed.
Reliance Edge v1.0.3, June 2016
- Added support for static memory allocation configuration in FreeRTOS
version 9. No common code changes.
Reliance Edge v1.0.2, February 2016
Common Code Changes
- A new per-volume configuration option has been added: users can
specify a number of times to retry a block device read, write or
flush operation before returning a failure. The configuration tool
has been updated to version 1.0.2 with this change.
- This added a new field to the volume configuration in redconf.c:
existing redconf.c files from v1.0.1 and earlier must be updated to
work with v1.0.2. Open redconf.h and redconf.c with the
configuration tool, enable "Retry block device I/O on failure" for
any volumes if desired, and save the redconf files.
FreeRTOS Port Changes
- Added support for the STM32 HAL SD card driver in the FreeRTOS block
device interface. Two boards are supported out-of-the-box: the
STM324xG-EVAL and the STM32F746NG-Discovery. A sample project is
included for the STM324xG-EVAL.
MQX Port Changes
- Fixed a bug which prevented Reliance Edge from compiling if the File
System Essentials API was selected in the configuration.
- Fixed a bug which would have returned an uninitialized value from
RedOsBDevFlush() for block devices that support flushing.
Reliance Edge v1.0.1, October 2015
- Added MQX RTOS support in the commercial kit, with example projects
for the Kinetis Design Studio.
- Bug fix in the F_DRIVER implementation of the FreeRTOS block
device service.
Reliance Edge v1.0, July 2015
Common Code Changes
- First release of commercial kit and MISRA C:2012 Design
Assurance Package. The commercial kit includes many new tools and
tests which were not previously available.
- Overhauled parsing of command-line parameters to be consistent for
all tools and tests. Command-line tools now use Unix-style short and
long options (such as -H and --help) instead of DOS-style switches
(such as /?).
- Renamed all os/*/include/ostypes.h headers to
os/*/include/redostypes.h, so that all headers use the
product prefix. If you created a port using v0.9, this header needs
to be renamed and its header guard (#ifndef OSTYPES_H etc.) should
also be updated.
- Add a new header for OS-specific MISRA C:2012 deviation macros,
located at os/*/include/redosdeviations.h. If you created a port
using v0.9, copy the template from os/stub/include/redosdeviations.h
into the include directory.
- Eliminated support for sector sizes less than 256. If using a
smaller sector size (say for a RAM disk), this must now be emulated
in the implementation of the block device OS service.
- Added RedFseFormat() as an optional FSE API, allowing FSE
applications to format the volume at run-time.
- This added a new macro to redconf.h: existing redconf.h files from
v0.9 must be updated to work with v1.0. Open redconf.h with the
configuration tool, ignore the warning about the missing macro, and
save it.
- Internal restructuring has renamed the macros for the string and
memory functions used in redconf.h. An existing redconf.h file from
v0.9 will need to be updated; for a file containing the old names,
the new config tool will default to using the (slow) Reliance Edge
string/memory functions; to use the C library or custom versions,
this will need to be selected in the configuration utility.
- Fix a bug which would result in an error when attempting to create a
name with one or more trailing path separators (such as
red_mkdir("/foo/bar/")).
- Fix a bug where an open handle for an inode on one volume would
prevent the same inode number from being deleted on a
different volume.
FreeRTOS Port Changes
- The implementation of the timestamp OS service no longer requires
that configUSE_TIMERS be set to 1.
Reliance Edge v0.9 (Beta), April 2015
First public release.
Known Issues
Visual Studio 2005
The Reliance Edge Win32 port (used for the host tools and the Win32 test
project) cannot be compiled by Visual Studio 2005. This is not going to
be fixed since VS2005 is an old toolset. Newer versions of Visual
Studio, starting with Visual Studio 2008, work just fine.