Fix some typos in some documents
This commit is contained in:
Gregory Nutt
parent
e10ab85d1d
commit
74cb19cfb2
@ -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>
|
||||
|
||||
@ -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
|
||||
|
||||
10
Kconfig
10
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
|
||||
|
||||
10
arch/Kconfig
10
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
|
||||
|
||||
Loading…
Reference in New Issue
Block a user