Fix some typos in some documents

4 files changed, 22 insertions, 22 deletions

diff --git a/nuttx/Documentation/NXGraphicsSubsystem.html b/nuttx/Documentation/NXGraphicsSubsystem.html
index 7d9c2d64e..7aa8ab03c 100644
--- a/nuttx/Documentation/NXGraphicsSubsystem.html
+++ b/nuttx/Documentation/NXGraphicsSubsystem.html
@@ -356,14 +356,14 @@
 
 <p>
   <sup>1</sup><small>NXMU and NXSU are interchangeable other than (1) certain start-up
-  and initializeation APIs (as described below), and (2) timing.  With NXSU, NX APIs
+  and initialization APIs (as described below), and (2) timing.  With NXSU, NX APIs
   execute immediately; with NXMU, NX APIs defer and serialize the operations and, hence,
   introduce different timing and potential race conditions that you would not experience
   with NXSU.</small>
 </p>
 
 <p><b>NXNULL?</b>
-  At one time, I also envisoned a <i>NULL</i> front-end that did not support windowing
+  At one time, I also envisioned a <i>NULL</i> front-end that did not support windowing
   at all but, rather, simply provided the entire framebuffer or LCD memory as one dumb window.
   This has the advantage that the same NX APIs can be used on the one dumb window as
   for the other NX windows.
@@ -765,7 +765,7 @@ int nxgl_splitline(FAR struct nxgl_vector_s *vector, FAR struct nxgl_trapezoid_s
 <p>
   <b>Description:</b>
   In the general case, a line with width can be represented as a parallelogram with a triangle at the top and bottom.
-  Triangles and parallelograms are both degenerate versions of a trapeziod.
+  Triangles and parallelograms are both degenerate versions of a trapezoid.
   This function breaks a wide line into triangles and trapezoids. 
   This function also detects other degenerate cases:
 </p>
@@ -777,7 +777,7 @@ int nxgl_splitline(FAR struct nxgl_vector_s *vector, FAR struct nxgl_trapezoid_s
     If <code>x1 == x2</code> then the line is vertical and also better represented as a rectangle.
   </li>
   <li>
-    If the width of the line is 1, then there are no triangles at the top and bottome
+    If the width of the line is 1, then there are no triangles at the top and bottom
     (this may also be the case if the width is narrow and the line is near vertical).
   </li>
   <li>
@@ -1321,7 +1321,7 @@ int nx_eventnotify(NXHANDLE handle, int signo);
   the client must observe the rules for using <code>mq_notifiy()</code>:
   <ul>
     <li>
-      Only one event is signaled.  Upon receipt of the signal, if the client
+      Only one event is signalled.  Upon receipt of the signal, if the client
       wishes further notifications, it must call <code>nx_eventnotify()</code> again.
     </li>
     <li>
@@ -1425,7 +1425,7 @@ int nx_requestbkgd(NXHANDLE handle,
 <ul>
   <li>
     If you want to implement a windowless solution.  The single screen
-    can be used to creat a truly simple graphic environment.  In this
+    can be used to create a truly simple graphic environment.  In this
     case, you should probably also de-select <code>CONFIG_NX_MULTIUSER</code> as well.
   </li>
   <li>
@@ -3430,7 +3430,7 @@ int nxf_convert_32bpp(FAR uint32_t *dest, uint16_t height,
       That interface may be driven by window callback functions so that keyboard input <i>only</i> goes to the top window.
     <dt><code>CONFIG__NXCONSOLE_KBDBUFSIZE</code>:
       <dd>If <code>CONFIG_NXCONSOLE_NXKBDIN</code> is enabled, then this value may be used to
-      define the size of the per-window keyboar input buffer.  Default: 16
+      define the size of the per-window keyboard input buffer.  Default: 16
     <dt><code>CONFIG_NXCONSOLE_NPOLLWAITERS</code>:
       <dd>The number of threads that can be waiting for read data available.
       Default: 4
@@ -3473,7 +3473,7 @@ int nxf_convert_32bpp(FAR uint32_t *dest, uint16_t height,
   <li>
     <p>
       Use the <i>bdf-converter</i> program to convert the BDF font to the NuttX font format.
-      This will result in a C header file containing defintions.
+      This will result in a C header file containing definitions.
       That header file should be installed at, for example, <code>graphics/nxfonts/nxfonts_myfont.h</code>.
     </p>
   </li>
diff --git a/nuttx/Documentation/NuttxUserGuide.html b/nuttx/Documentation/NuttxUserGuide.html
index 621c4c8c1..9c8b5adb0 100644
--- a/nuttx/Documentation/NuttxUserGuide.html
+++ b/nuttx/Documentation/NuttxUserGuide.html
@@ -723,7 +723,7 @@ int execv(FAR const char *path, FAR char *const argv[]);
 <p>
    Note the inefficiency when <code>execv()</code> or <code>execl()</code> is called in the normal, two-step process:
    (1) first call <code>vfork()</code> to create a new thread, then (2) call <code>execv()</code> or <code>execl()</code> to replace the new thread with a program from the file system.
-   Since the new thread will be terminated by the <code>execv()</code> or <code>execl()</code> call, it really served no purpose other than to support Unix compatility.
+   Since the new thread will be terminated by the <code>execv()</code> or <code>execl()</code> call, it really served no purpose other than to support Unix compatibility.
 </p>
 <p>
    The non-standard binfmt function <code>exec()</code> needs to have (1) a symbol table that provides the list of symbols exported by the base code, and (2) the number of symbols in that table.
@@ -1000,7 +1000,7 @@ int posix_spawn_file_actions_destroy(FAR posix_spawn_file_actions_t *file_action
 </pre></ul>
 <p>
   <b>Description:</b>
-  The <code>posix_spawn_file_actions_destroy()</code> function destroys the object referenced by <code>file_actions</code> which was previously initializeed by <code>posix_spawn_file_actions_init()</code>, returning any resources obtained at the time of initialization to the system for subsequent reuse.
+  The <code>posix_spawn_file_actions_destroy()</code> function destroys the object referenced by <code>file_actions</code> which was previously initialized by <code>posix_spawn_file_actions_init()</code>, returning any resources obtained at the time of initialization to the system for subsequent reuse.
   A <code>posix_spawn_file_actions_t</code> may be reinitialized after having been destroyed, but must not be reused after destruction, unless it has been reinitialized.
 </p>
 <p>
@@ -1931,8 +1931,8 @@ interface of the same name.
 
 <p>
   <b>Description:</b>
-  <code>sched_rr_get_interval()</code>  writes  the timeslice interval
-  for task identified by <code>pid</code> into  the timespec structure
+  <code>sched_rr_get_interval()</code>  writes the timeslice interval
+  for task identified by <code>pid</code> into the timespec structure
   pointed to by <code>interval</code>.  If pid is zero, the timeslice
   for the calling process is written into 'interval.  The
   identified process should be running under the SCHED_RR
diff --git a/nuttx/Kconfig b/nuttx/Kconfig
index fb08f3289..1bf91e2a5 100644
--- a/nuttx/Kconfig
+++ b/nuttx/Kconfig
@@ -94,7 +94,7 @@ config APPS_DIR
 		Identifies the directory that builds the
 		application to link with NuttX.  Default: ../apps This symbol must be assigned
 		to the path to the application build directory *relative* to
-		the NuttX top build direcory. If you had an application
+		the NuttX top build directory. If you had an application
 		directory and the NuttX directory each in separate directory
 		trees like this:
 
@@ -118,7 +118,7 @@ config APPS_DIR
 		2)clean. Do whatever is appropriate to clean the application
 		directories for a fresh build.
 		
-		3)distclean. Clean everthing -- auto-generated files, symbolic
+		3)distclean. Clean everything -- auto-generated files, symbolic
 		links etc. -- so that the directory contents are the same as
 		the contents in your configuration management system.
 		This is only done when you change the NuttX configuration.
@@ -145,7 +145,7 @@ config BUILD_2PASS
 		library (archive) (some modification to this Makefile would be required if
 		PASS1_TARGET generates an archive). Pass 1 1ncremental (relative) link
 		objects should be put into the processor-specific source directory (where other
-		link objects will be created).  If the pass1 obect is an archive, it could
+		link objects will be created).  If the pass1 object is an archive, it could
 		go anywhere.
 
 if BUILD_2PASS
@@ -277,7 +277,7 @@ config ARCH_FLOAT_H
 	---help---
 		The float.h header file defines the properties of your floating
 		point implementation.  It would always be best to use your
-		toolchain's float.h header file but if none is avaiable, a default
+		toolchain's float.h header file but if none is available, a default
 		float.h header file will provided if this option is selected.  However
 		there is no assurance that the settings in this float.h are actually
 		correct for your platform!
@@ -329,7 +329,7 @@ config DEBUG_VERBOSE
 	bool "Enable Debug Verbose Output"
 	default n
 	---help---
-		Enables verbose debug output (assuming debug featurses are enabled).
+		Enables verbose debug output (assuming debug features are enabled).
 		As a general rule, when DEBUG is enabled only errors will be
 		reported in the debug SYSLOG output.  But if you also enable
 		DEBUG_VERBOSE, then very chatty (and often annoying) output will be
diff --git a/nuttx/arch/Kconfig b/nuttx/arch/Kconfig
index 643283403..2a63c61d7 100644
--- a/nuttx/arch/Kconfig
+++ b/nuttx/arch/Kconfig
@@ -154,7 +154,7 @@ config ARCH_IRQPRIO
 
 		NOTE: The use of interrupt priorities implies that you also have
 		support for nested interrupts.  Most architectures do not support
-		nesting of interupts or, if they do, they only supported nested
+		nesting of interrupts or, if they do, they only supported nested
 		interrupts with certain configuration options.  So this selection
 		should be used with caution.
 
@@ -212,7 +212,7 @@ config ARCH_CALIBRATION
 	---help---
 		Enables some built in instrumentation that causes a 100 second delay
 		during boot-up.  This 100 second delay serves no purpose other than it
-		allows you to calibratre BOARD_LOOPSPERMSEC.  You simply use a stop
+		allows you to calibrate BOARD_LOOPSPERMSEC.  You simply use a stop
 		watch to measure the actual delay then adjust BOARD_LOOPSPERMSEC until
 		the actual delay is 100 seconds.
 
@@ -387,7 +387,7 @@ config RAM_START
 	help
 		The physical start address of primary installed RAM.  "Primary" RAM
 		refers to the RAM that you link program code into.  If program code
-		does not excecute out of RAM but from FLASH, then you may designate
+		does not execute out of RAM but from FLASH, then you may designate
 		any block of RAM as "primary."
 
 config RAM_VSTART
@@ -397,7 +397,7 @@ config RAM_VSTART
 	help
 		The virtual start address of installed primary RAM. "Primary" RAM
 		refers to the RAM that you link program code into.  If program code
-		does not excecute out of RAM but from FLASH, then you may designate
+		does not execute out of RAM but from FLASH, then you may designate
 		any block of RAM as "primary."
 
 config RAM_SIZE
@@ -406,7 +406,7 @@ config RAM_SIZE
 	help
 		The size in bytes of the installed primary RAM. "Primary" RAM
 		refers to the RAM that you link program code into.  If program code
-		does not excecute out of RAM but from FLASH, then you may designate
+		does not execute out of RAM but from FLASH, then you may designate
 		any block of RAM as "primary."
 
 if BOOT_RUNFROMFLASH && ARCH_HAVE_MMU