mirror of
https://git.rtems.org/rtems-docs/
synced 2025-07-24 02:02:29 +08:00
Eliminate UTF-8 characters except superscripted 2 in i2c
This commit is contained in:
parent
e24c5e9682
commit
6682434bf2
@ -9,7 +9,7 @@ Appendix: Core Qualification Artifacts/Documents
|
||||
|
||||
An effort at NASA has been performed to suggest a core set of artifacts
|
||||
(as defined by **BOTH** NASA NPR 7150.2B and DO-178B) that can be utilized
|
||||
by a mission as a baselined starting point for “pre-qualification”
|
||||
by a mission as a baselined starting point for "pre-qualification"
|
||||
for (open-source) software that is intended to be utilized for flight
|
||||
purposes. This effort analyzed the overlap between NPR 7150.2B
|
||||
and DO-178B and highlighted a core set of artifacts to serve as a
|
||||
@ -126,14 +126,14 @@ effort.
|
||||
| | Results | the results of software |
|
||||
| | | verification activities. |
|
||||
+----------------+-----------------------+---------------------------------+
|
||||
| Usability | Software User’s | The Software User Manual |
|
||||
| Usability | Software User's | The Software User Manual |
|
||||
| | Manual | defines user instructions for |
|
||||
| | | the software. |
|
||||
+----------------+-----------------------+---------------------------------+
|
||||
|
||||
In an effort to remain lightweight and sustainable for open-source
|
||||
projects, Table 1 above was condensed into a single artifact outline
|
||||
that encompasses the artifacts’ intents. The idea is that this living
|
||||
that encompasses the artifacts' intents. The idea is that this living
|
||||
qualification document will reside under RTEMS source control and be
|
||||
updated with additional detail accordingly. The artifact outline is
|
||||
as follows:
|
||||
|
@ -9,7 +9,7 @@ Licensing Requirements
|
||||
|
||||
All artifacts shall adhere to RTEMS Project licensing
|
||||
requirements. Currently, the preferred licenses are CC-BY-SA-4.0 license
|
||||
for documentation and “Two Paragraph BSD” for source code.
|
||||
for documentation and "Two Paragraph BSD" for source code.
|
||||
|
||||
Historically, RTEMS has been licensed under the GPL v2 with linking
|
||||
exception (https://www.rtems.org/license). It is preferred that new
|
||||
|
@ -14,13 +14,13 @@ applications. In some of these application domains, there are standards
|
||||
processes used to develop software and the associated artifacts. These
|
||||
standards typically do not specify software functionality but address
|
||||
topics like requirements definition, traceability, having a documented
|
||||
change process, coding style, testing requirements, and a user’s
|
||||
manual. During system test, these standards call for a review – usually
|
||||
by an independent entity – that the standard has been adhered too. These
|
||||
change process, coding style, testing requirements, and a user's
|
||||
manual. During system test, these standards call for a review - usually
|
||||
by an independent entity - that the standard has been adhered too. These
|
||||
reviews cover a broad variety of topics and activities, but the process
|
||||
is generally referred to as qualification, verification, or auditing
|
||||
against the specific standard in use. The RTEMS Project will use the
|
||||
term “qualification” independent of the standard.
|
||||
term "qualification" independent of the standard.
|
||||
|
||||
The goal of the RTEMS Qualification Project is to make RTEMS easier
|
||||
to review regardless of the standard chosen. Quite specifically,
|
||||
@ -36,8 +36,8 @@ the associated traceability to source code, tests, and documentation
|
||||
are needed.
|
||||
|
||||
The RTEMS Qualification Project is technically
|
||||
“pre-qualification”. True qualification must be performed on the
|
||||
project’s target hardware in a system context. The FAA has provided
|
||||
"pre-qualification." True qualification must be performed on the
|
||||
project's target hardware in a system context. The FAA has provided
|
||||
guidance for Reusable Software Components (FAA-AC20-148) and this
|
||||
effort should follow that guidance. The open RTEMS Project, with the
|
||||
assistance of domain experts, will possess and maintain the master
|
||||
@ -53,7 +53,7 @@ provided by the RTEMS Project. For example, the RTEMS Qualification could
|
||||
suggest specific improvements to code coverage reports. The teams focused
|
||||
on qualification should be able to provide resources for improving the
|
||||
automated project infrastructure and master technical data for RTEMS. The
|
||||
term “resources” is often used by open source projects to refer to
|
||||
term "resources" is often used by open source projects to refer to
|
||||
volunteer code contributions or funding. Although code contributions in
|
||||
this area are important and always welcome, funding is also important. At
|
||||
a minimum, ongoing funding is needed for maintenance and upgrades of
|
||||
@ -74,7 +74,7 @@ to the RTEMS Project.
|
||||
|
||||
It is expected that the RTEMS Qualification Project will create and
|
||||
maintain maps from the RTEMS master technical data to the various
|
||||
qualification standards. It will maintain “scorecards” which
|
||||
qualification standards. It will maintain "scorecards" which
|
||||
identify how the RTEMS Project is currently doing when reviewed per each
|
||||
standard. These will be maintained in the open as community resources
|
||||
which will guide the community in improving its infrastructure.
|
||||
|
@ -21,7 +21,7 @@ capabilities are part of the RTEMS Tester toolset.
|
||||
|
||||
Assuming that a requirements focused test suite is added to the open
|
||||
RTEMS, tools will be needed to assist in verifying that requirements are
|
||||
“fully tested.” A fully tested requirement is one which is implemented
|
||||
"fully tested." A fully tested requirement is one which is implemented
|
||||
and tested with associated logical tracing. Tools automating this analysis
|
||||
and generating reporting and alerts will be a critical part of ensuring
|
||||
the master technical data does not bit rot.
|
||||
|
@ -9,7 +9,7 @@ User's Manuals
|
||||
|
||||
TBD - write and link to useful documentation, potential URLs:
|
||||
|
||||
Reference the RTEMS C User’s Manual
|
||||
Reference the RTEMS Classic API Guide
|
||||
|
||||
* https://docs.rtems.org/doc-current/share/rtems/pdf/c_user.pdf
|
||||
|
||||
|
@ -25,9 +25,9 @@ SSH Access
|
||||
|
||||
Currently all committer's should have an ssh account on the main git server,
|
||||
dispatch.rtems.org. If you have been granted commit access and do have an
|
||||
account on dispatch.rtems.org one should be requested on the devel@… list.
|
||||
account on dispatch.rtems.org one should be requested on the devel@ list.
|
||||
SSH access for git uses key logins instead of passwords. The key should be at
|
||||
least 1024bits in length.
|
||||
least 1024 bits in length.
|
||||
|
||||
The public repositories can by cloned with
|
||||
|
||||
@ -42,7 +42,7 @@ Personal Repository
|
||||
Personal repositories keep the clutter away from the master repository. A
|
||||
user with a personal repository can make commits, create and delete branches,
|
||||
plus more without interfering with the master repository. Commits to the
|
||||
master repository generate email to the vc@… list and development type commits
|
||||
master repository generate email to the vc@ list and development type commits
|
||||
by a developer would only add noise and lessen the effectiveness of the commit
|
||||
list
|
||||
|
||||
|
@ -384,7 +384,7 @@ Rebasing
|
||||
|
||||
An alternative to the merge command is rebase, which replays the changes
|
||||
(commits) on one branch onto another. ``git rebase`` finds the common ancestor
|
||||
of the two branches, stores each commit of the branch you’re on to temporary
|
||||
of the two branches, stores each commit of the branch you are on to temporary
|
||||
files and applies each commit in order.
|
||||
|
||||
For example
|
||||
|
@ -56,7 +56,7 @@ The next two commands are used to link the fileio executable.The `-B` option
|
||||
signifies the use of the complete path to the required directory or file. Write
|
||||
the full path instead of the path file: `sparc-rtems5/erc32/lib/` in the
|
||||
following commands according to your installation. Also confirm the path of the
|
||||
fileio’s executable and object files in the last line of the command according
|
||||
fileio's executable and object files in the last line of the command according
|
||||
to your installation.
|
||||
|
||||
.. code:: shell
|
||||
|
@ -40,11 +40,11 @@ trace linker using a command to link the application executable. The trace
|
||||
linker uses the application files in compiled format (ELF) and the libraries
|
||||
used to build the application for performing this link.
|
||||
|
||||
Step 2: The RTEMS Trace Linker reads the user’s configuration file and that
|
||||
Step 2: The RTEMS Trace Linker reads the user's configuration file and that
|
||||
results in it reading the standard Trace Buffering Configuration files
|
||||
installed with the RTEMS Trace Linker. The trace linker uses the target
|
||||
compiler and linker to create the trace enabled application executable. It
|
||||
wraps the functions defined in the user’s configuration with code that captures
|
||||
wraps the functions defined in the user's configuration with code that captures
|
||||
trace records into the statically allocated buffer. The trace wrapper code is
|
||||
compiled with the target compiler and the resulting ELF object file is added to
|
||||
the standard link command line used to link the application and the application
|
||||
@ -53,7 +53,7 @@ is re-linked using the wrapping option of the GNU linker.
|
||||
Step 3: The trace linker creates an executable which is capable of running on
|
||||
the target hardware or simulator.
|
||||
|
||||
Step 4: RTEMS shell provides the “rtrace” command to display and save trace
|
||||
Step 4: RTEMS shell provides the "rtrace" command to display and save trace
|
||||
buffers.
|
||||
|
||||
.. comment: taken from https://devel.rtems.org/wiki/Developer/Tracing
|
||||
|
Loading…
x
Reference in New Issue
Block a user