[PATCH] Eliminate UTF-8 characters
Joel Sherrill
joel at rtems.org
Wed Dec 19 16:42:49 UTC 2018
---
bsp-howto/i2c.rst | 5 ++++-
eng/appendix-a.rst | 6 +++---
eng/license-requirements.rst | 2 +-
eng/prequalification.rst | 16 ++++++++--------
eng/test-plan.rst | 2 +-
eng/users-manuals.rst | 2 +-
eng/vc-authors.rst | 6 +++---
eng/vc-users.rst | 15 ++++++++-------
user/tracing/examples.rst | 2 +-
user/tracing/introduction.rst | 6 +++---
10 files changed, 33 insertions(+), 29 deletions(-)
diff --git a/bsp-howto/i2c.rst b/bsp-howto/i2c.rst
index db21486..42e4209 100644
--- a/bsp-howto/i2c.rst
+++ b/bsp-howto/i2c.rst
@@ -6,7 +6,10 @@
I2C Driver
**********
-The Inter-Integrated Circuit (I2C, I²C, IIC) bus drivers should use the
+.. COMMENT: Figure out how to do I2C with 2 superscript and stick to ASCII
+.. COMMENT: characters. Should be :sup:`2` per online Sphinx docs but ....
+
+The Inter-Integrated Circuit (I2C, IIC, etc.) bus drivers should use the
`I2C bus framework <https://git.rtems.org/rtems/tree/cpukit/dev/include/dev/i2c/i2c.h>`_.
For example drivers see the
`Cadence I2C driver <https://git.rtems.org/rtems/tree/bsps/arm/xilinx-zynq/i2c/cadence-i2c.c>`_,
diff --git a/eng/appendix-a.rst b/eng/appendix-a.rst
index 540a2a0..83a145e 100644
--- a/eng/appendix-a.rst
+++ b/eng/appendix-a.rst
@@ -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:
diff --git a/eng/license-requirements.rst b/eng/license-requirements.rst
index 1acc2d4..7fe3ff4 100644
--- a/eng/license-requirements.rst
+++ b/eng/license-requirements.rst
@@ -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
diff --git a/eng/prequalification.rst b/eng/prequalification.rst
index 4055f70..62e859e 100644
--- a/eng/prequalification.rst
+++ b/eng/prequalification.rst
@@ -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.
diff --git a/eng/test-plan.rst b/eng/test-plan.rst
index c85efd2..c992150 100644
--- a/eng/test-plan.rst
+++ b/eng/test-plan.rst
@@ -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.
diff --git a/eng/users-manuals.rst b/eng/users-manuals.rst
index e3b102d..a6010c0 100644
--- a/eng/users-manuals.rst
+++ b/eng/users-manuals.rst
@@ -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
diff --git a/eng/vc-authors.rst b/eng/vc-authors.rst
index 7e6e763..9fd80bd 100644
--- a/eng/vc-authors.rst
+++ b/eng/vc-authors.rst
@@ -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
diff --git a/eng/vc-users.rst b/eng/vc-users.rst
index efa29e0..524107d 100644
--- a/eng/vc-users.rst
+++ b/eng/vc-users.rst
@@ -53,7 +53,7 @@ the command:
This will create a local branch named "rtems410", containing the rtems-4.10
release, that will track the remote branch "rtems-4-10-branch" in origin
-(​git://git.rtems.org/rtems.git). The ``git branch`` command prints a list of
+(git://git.rtems.org/rtems.git). The ``git branch`` command prints a list of
the current local branches, indicating the one currently checked out.
If you want to switch between local branches:
@@ -284,10 +284,11 @@ git reset
``git reset`` is a powerful and tricky command that should only be used on
local (un-pushed) branches): A good description of what it enables to do can be
-found ​here. The following are a few useful examples. Note that adding a ~
-after HEAD refers to the most recent commit, and you can add a number after
-the ~ to refer to commits even further back; HEAD by itself refers to the
-current working directory (changes since the last commit).
+found online and in the standard git documentation. The following are
+a few useful examples. Note that adding a ~ after HEAD refers to the most
+recent commit, and you can add a number after the ~ to refer to commits
+even further back; HEAD by itself refers to the current working directory
+(changes since the last commit).
.. code-block:: shell
@@ -384,7 +385,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
@@ -545,7 +546,7 @@ Troubleshooting
---------------
Some restrictive corporate firewalls block access through the Git protocol
-(​git://). If you are unable to reach the server ​git://git.rtems.org/ you can
+(git://). If you are unable to reach the server git://git.rtems.org/ you can
try accessing through http. To clone the rtems repository using the http
protocol use the following command:
diff --git a/user/tracing/examples.rst b/user/tracing/examples.rst
index a694bff..cf06cdf 100644
--- a/user/tracing/examples.rst
+++ b/user/tracing/examples.rst
@@ -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
diff --git a/user/tracing/introduction.rst b/user/tracing/introduction.rst
index 27de441..d45b109 100644
--- a/user/tracing/introduction.rst
+++ b/user/tracing/introduction.rst
@@ -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
--
1.8.3.1
More information about the devel
mailing list