Merged in mjkoch/nuttx/mjkoch (pull request #841)
Correct a few tpyos Approved-by: Gregory Nutt <gnutt@nuttx.org>
This commit is contained in:
parent
92554257b9
commit
1b325342f4
@ -43,10 +43,10 @@ arch/<arch-name>/arch.h as described below).
|
||||
Directory Structure
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The arch directory contains architecture specific logic. The complete
|
||||
board port in is defined by the architecture-specific code in this
|
||||
directory (plus the board-specific configurations in the config/
|
||||
subdirectory). Each architecture must provide a subdirectory <arch-name>
|
||||
The arch/ directory contains architecture-specific logic. The complete
|
||||
board port is defined by the architecture-specific code in this
|
||||
directory plus the board-specific configurations in the config/
|
||||
subdirectory. Each architecture must provide a subdirectory <arch-name>
|
||||
under arch/ with the following characteristics:
|
||||
|
||||
|
||||
@ -81,16 +81,16 @@ include/types.h
|
||||
|
||||
_int8_t, _uint8_t, _int16_t, _uint16_t, _int32_t, _uint32_t
|
||||
|
||||
and if the architecture supports 64-bit integers.
|
||||
and if the architecture supports 64-bit integers:
|
||||
|
||||
_int24_t, _uint24_t, int64_t, uint64_t
|
||||
_int24_t, _uint24_t, _int64_t, _uint64_t
|
||||
|
||||
NOTE that these type names have a leading underscore character. This
|
||||
file will be included(indirectly) by include/stdint.h and typedef'ed to
|
||||
the final name without the underscore character. This roundabout way of
|
||||
doings things allows the stdint.h to be removed from the include/
|
||||
directory in the event that the user prefers to use the definitions
|
||||
provided by their toolchain header files
|
||||
provided by their toolchain header files.
|
||||
|
||||
irqstate_t
|
||||
|
||||
@ -101,10 +101,10 @@ include/types.h
|
||||
available to all files.
|
||||
|
||||
include/irq.h
|
||||
This file needs to define some architecture specific functions (usually
|
||||
inline if the compiler supports inlining) and structure. These include:
|
||||
This file needs to define some architecture-specific functions (usually
|
||||
inline if the compiler supports inlining) and structures. These include:
|
||||
|
||||
- struct xcptcontext. This structures represents the saved context
|
||||
- struct xcptcontext. This structure represents the saved context
|
||||
of a thread.
|
||||
|
||||
- irqstate_t up_irq_save(void) -- Used to disable all interrupts.
|
||||
@ -113,7 +113,7 @@ include/irq.h
|
||||
enables to the same state as before up_irq_save was called.
|
||||
|
||||
NOTE: These interfaces are not available to application code but can
|
||||
only be used withint the operating system code. And, in general,
|
||||
only be used within the operating system code. And, in general,
|
||||
these functions should *never* be called directly, not unless you
|
||||
know absolutely well what you are doing. Rather you shoudl typically
|
||||
use the wrapper functions enter_critical_section() and leave_critical_section()
|
||||
|
@ -12,11 +12,11 @@ Contents:
|
||||
Files in this directory
|
||||
^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
dev_null.c, dev_urandom, and dev_zero.c
|
||||
These files provide the standard /dev/null, /dev/urandom, and /dev/zero
|
||||
devices. See include/nuttx/drivers/driers.h for prototypes of functions
|
||||
that should be called if you want to register these devices
|
||||
(devnull_register(), devurandom_register(), and devzero_register()).
|
||||
dev_null.c and dev_zero.c
|
||||
These files provide the standard /dev/null and /dev/zero devices. See
|
||||
include/nuttx/drivers/driers.h for prototypes of functions that should
|
||||
be called if you want to register these devices (devnull_register()
|
||||
and devzero_register()).
|
||||
|
||||
ramdisk.c
|
||||
Can be used to set up a block of memory or (read-only) FLASH as
|
||||
@ -56,7 +56,8 @@ contactless/
|
||||
to contactless cards and tags.
|
||||
|
||||
crypto/
|
||||
Contains crypto drivers and support logic.
|
||||
Contains crypto drivers and support logic, including the /dev/urandom
|
||||
device.
|
||||
|
||||
eeprom/
|
||||
An EEPROM is a form of Memory Technology Device (see drivers/mtd).
|
||||
|
@ -161,7 +161,7 @@ static int binfs_open(FAR struct file *filep, FAR const char *relpath,
|
||||
index = builtin_isavail(relpath);
|
||||
if (index < 0)
|
||||
{
|
||||
ferr("ERROR: Builting %s does not exist\n", relpath);
|
||||
ferr("ERROR: Built-in %s does not exist\n", relpath);
|
||||
return -ENOENT;
|
||||
}
|
||||
|
||||
|
@ -7,7 +7,7 @@ README
|
||||
|
||||
In the two pass build, the application logic is built during the first
|
||||
phase, pass 1. In that phase, the application may generate and install
|
||||
source files in the pass1/directory.
|
||||
source files into the pass1/ directory.
|
||||
|
||||
The operating system is built during phase 2 of the build. At that time,
|
||||
those source files in the pass1/ directory will be built and incorporated
|
||||
|
Loading…
Reference in New Issue
Block a user