style/Document: remove unnecessary trailing whitespace
N/A Signed-off-by: chao.an <anchao@xiaomi.com>
This commit is contained in:
parent
b5692d8034
commit
fe915679b1
@ -1,20 +1,20 @@
|
||||
Apache NuttX is an effort undergoing incubation at The Apache Software Foundation (ASF),
|
||||
sponsored by the Apache Incubator. Incubation is required of all newly accepted projects
|
||||
until a further review indicates that the infrastructure, communications, and decision
|
||||
making process have stabilized in a manner consistent with other successful ASF projects.
|
||||
While incubation status is not necessarily a reflection of the completeness or stability
|
||||
Apache NuttX is an effort undergoing incubation at The Apache Software Foundation (ASF),
|
||||
sponsored by the Apache Incubator. Incubation is required of all newly accepted projects
|
||||
until a further review indicates that the infrastructure, communications, and decision
|
||||
making process have stabilized in a manner consistent with other successful ASF projects.
|
||||
While incubation status is not necessarily a reflection of the completeness or stability
|
||||
of the code, it does indicate that the project has yet to be fully endorsed by the ASF.
|
||||
|
||||
Some of the incubating project's releases may not be fully compliant with ASF policy. For
|
||||
example, releases may have incomplete or un-reviewed licensing conditions. What follows is
|
||||
a list of known issues the project is currently aware of (note that this list, by definition,
|
||||
is likely to be incomplete):
|
||||
Some of the incubating project's releases may not be fully compliant with ASF policy. For
|
||||
example, releases may have incomplete or un-reviewed licensing conditions. What follows is
|
||||
a list of known issues the project is currently aware of (note that this list, by definition,
|
||||
is likely to be incomplete):
|
||||
|
||||
* Releases may have incomplete licensing conditions.
|
||||
* Some ASF files still have BSD headers. Most of the top contributors have signed an ICLA and
|
||||
we are working on updating the headers and getting approvals from other copyright holders.
|
||||
|
||||
If you are planning to incorporate this work into your product/project, please be aware that
|
||||
you will need to conduct a thorough licensing review to determine the overall implications of
|
||||
including this work. For the current status of this project through the Apache Incubator
|
||||
you will need to conduct a thorough licensing review to determine the overall implications of
|
||||
including this work. For the current status of this project through the Apache Incubator
|
||||
visit: https://incubator.apache.org/projects/nuttx.html
|
||||
|
20
LICENSE
20
LICENSE
@ -199,7 +199,7 @@
|
||||
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
||||
See the License for the specific language governing permissions and
|
||||
limitations under the License.
|
||||
|
||||
|
||||
------------------------------------------------------------------------------
|
||||
|
||||
uIP
|
||||
@ -353,24 +353,24 @@ apps/testing/scanftest/scanftest_main.c
|
||||
Derives from the cc65 Project which has a zlib license:
|
||||
|
||||
Copyright (C) 2005-01-26, Greg King (https://github.com/cc65)
|
||||
|
||||
|
||||
Original License:
|
||||
This software is provided 'as-is', without any express or implied warranty.
|
||||
In no event will the authors be held liable for any damages arising from
|
||||
the use of this software.
|
||||
|
||||
|
||||
Permission is granted to anyone to use this software for any purpose,
|
||||
including commercial applications, and to alter it and redistribute it
|
||||
freely, subject to the following restrictions:
|
||||
|
||||
|
||||
1. The origin of this software must not be misrepresented; you must not
|
||||
claim that you wrote the original software. If you use this software in
|
||||
a product, an acknowledgment in the product documentation would be
|
||||
appreciated but is not required.
|
||||
|
||||
|
||||
2. Altered source versions must be plainly marked as such, and must not
|
||||
be misrepresented as being the original software.
|
||||
|
||||
|
||||
3. This notice may not be removed or altered from any source distribution.
|
||||
|
||||
apps/webserver
|
||||
@ -382,11 +382,11 @@ apps/webserver
|
||||
|
||||
Copyright (c) 2001, Adam Dunkels.
|
||||
All rights reserved.
|
||||
|
||||
|
||||
Redistribution and use in source and binary forms, with or without
|
||||
modification, are permitted provided that the following conditions
|
||||
are met:
|
||||
|
||||
|
||||
1. Redistributions of source code must retain the above copyright
|
||||
notice, this list of conditions and the following disclaimer.
|
||||
2. Redistributions in binary form must reproduce the above copyright
|
||||
@ -398,7 +398,7 @@ apps/webserver
|
||||
4. The name of the author may not be used to endorse or promote
|
||||
products derived from this software without specific prior
|
||||
written permission.
|
||||
|
||||
|
||||
THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS
|
||||
OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
|
||||
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
||||
@ -447,7 +447,7 @@ canutils/candump
|
||||
|
||||
Includes five dual licensed third part files from Volkswagon with
|
||||
licensing as follows (Copyright dates vary from file-to-file):
|
||||
|
||||
|
||||
SPDX-License-Identifier: (GPL-2.0-only OR BSD-3-Clause)
|
||||
|
||||
Copyright (c) 2002-2009 Volkswagen Group Electronic Research
|
||||
|
@ -162,7 +162,7 @@ project. One must:
|
||||
|
||||
Q: Has anyone come up with a tidy way to build NuttX with board- specific pieces
|
||||
outside the source tree?
|
||||
|
||||
|
||||
A: Here are three:
|
||||
|
||||
1) There is a make target called `make export`. It will build NuttX, then
|
||||
@ -226,9 +226,9 @@ A: Here are three:
|
||||
You could, for example, create a script called `install.sh` that installs
|
||||
a custom application, configuration, and board specific directory:
|
||||
|
||||
a) Copy `MyBoard` directory to `boards/MyBoard`.
|
||||
b) Add a symbolic link to `MyApplication` at `apps/external`.
|
||||
c) Configure NuttX, usually by:
|
||||
a) Copy `MyBoard` directory to `boards/MyBoard`.
|
||||
b) Add a symbolic link to `MyApplication` at `apps/external`.
|
||||
c) Configure NuttX, usually by:
|
||||
|
||||
```bash
|
||||
tools/configure.sh MyBoard:MyConfiguration
|
||||
|
@ -1042,9 +1042,9 @@ the display. This only works for `RGB23` (`888`), `RGB16` (`656`), `RGB8`
|
||||
|
||||
How was that run-length encoded image produced?
|
||||
|
||||
1. I used GIMP output the image as a `.c` file.
|
||||
2. I added some C logic to palette-ize the RGB image in the GIMP `.c` file.
|
||||
3. Then I add some simple run-length encoding to palette-ized image.
|
||||
1. I used GIMP output the image as a `.c` file.
|
||||
2. I added some C logic to palette-ize the RGB image in the GIMP `.c` file.
|
||||
3. Then I add some simple run-length encoding to palette-ized image.
|
||||
|
||||
But now there is a tool that can be found in the NxWidgets package at
|
||||
`NxWidgets/tools/bitmap_converter.py` that can be used to convert any graphics
|
||||
|
@ -133,18 +133,18 @@ Hopefully we can agree that's not a lot of code? There's no overhead, no
|
||||
unnecessary setup. Look at test.c for a bunch of nice examples, mostly all
|
||||
ripped off the json.org site, and a few from elsewhere.
|
||||
|
||||
What about manual mode? First up you need some detail.
|
||||
Let's cover how the cJSON objects represent the JSON data.
|
||||
cJSON doesn't distinguish arrays from objects in handling; just type.
|
||||
What about manual mode? First up you need some detail.
|
||||
Let's cover how the cJSON objects represent the JSON data.
|
||||
cJSON doesn't distinguish arrays from objects in handling; just type.
|
||||
Each cJSON has, potentially, a child, siblings, value, a name.
|
||||
|
||||
The root object has: Object Type and a Child
|
||||
The Child has name "name", with value "Jack ("Bee") Nimble", and a sibling:
|
||||
Sibling has type Object, name "format", and a child.
|
||||
That child has type String, name "type", value "rect", and a sibling:
|
||||
Sibling has type Number, name "width", value 1920, and a sibling:
|
||||
Sibling has type Number, name "height", value 1080, and a sibling:
|
||||
Sibling hs type False, name "interlace", and a sibling:
|
||||
The root object has: Object Type and a Child
|
||||
The Child has name "name", with value "Jack ("Bee") Nimble", and a sibling:
|
||||
Sibling has type Object, name "format", and a child.
|
||||
That child has type String, name "type", value "rect", and a sibling:
|
||||
Sibling has type Number, name "width", value 1920, and a sibling:
|
||||
Sibling has type Number, name "height", value 1080, and a sibling:
|
||||
Sibling hs type False, name "interlace", and a sibling:
|
||||
Sibling has type Number, name "frame rate", value 24
|
||||
|
||||
Here's the structure:
|
||||
|
@ -13,5 +13,5 @@ The files in this directory are released to the Public Domain.
|
||||
|
||||
## Acknowledgements
|
||||
|
||||
The panel library was originally provided by
|
||||
The panel library was originally provided by
|
||||
Warren Tucker <wht@n4hgf.mt-park.ga.us>
|
||||
|
@ -246,11 +246,11 @@ The contents of the `/etc` directory are retained in the file
|
||||
`include/arch/board/rcS.template`). In order to modify the start-up behavior,
|
||||
there are three things to study:
|
||||
|
||||
1. Configuration Options.
|
||||
1. Configuration Options.
|
||||
The additional `CONFIG_NSH_ROMFSETC` configuration options discussed in the
|
||||
final section of this README.
|
||||
|
||||
2. `tools/mkromfsimg.sh` Script.
|
||||
2. `tools/mkromfsimg.sh` Script.
|
||||
The script `tools/mkromfsimg.sh` creates `nsh_romfsimg.h`. It is not
|
||||
automatically executed. If you want to change the configuration settings
|
||||
associated with creating and mounting the `/tmp` directory, then it will be
|
||||
@ -281,7 +281,7 @@ All of the startup-behavior is contained in `rcS.template`. The role of
|
||||
|
||||
## Simple Commands
|
||||
|
||||
- `[ <expression> ]`
|
||||
- `[ <expression> ]`
|
||||
`test <expression>`
|
||||
|
||||
These are two alternative forms of the same command. They support evaluation
|
||||
@ -313,8 +313,8 @@ All of the startup-behavior is contained in `rcS.template`. The role of
|
||||
integer -lt integer | integer -ne integer
|
||||
```
|
||||
|
||||
- `addroute <target> [<netmask>] <router>`
|
||||
`addroute default <ipaddr> <interface>`
|
||||
- `addroute <target> [<netmask>] <router>`
|
||||
`addroute default <ipaddr> <interface>`
|
||||
|
||||
This command adds an entry in the routing table. The new entry
|
||||
will map the IP address of a router on a local network(`<router>`)
|
||||
@ -343,17 +343,17 @@ All of the startup-behavior is contained in `rcS.template`. The role of
|
||||
|
||||
Access the OS ARP table.
|
||||
|
||||
- `-a <ipaddr>`
|
||||
- `-a <ipaddr>`
|
||||
Will show the hardware address that the IP address `<ipaddr>` is mapped to.
|
||||
|
||||
- `-d <ipaddr>`
|
||||
- `-d <ipaddr>`
|
||||
Will delete the mapping for the IP address `<ipaddr>` from the ARP table.
|
||||
|
||||
- `-s <ipaddr> <hwaddr>`
|
||||
- `-s <ipaddr> <hwaddr>`
|
||||
Will set (or replace) the mapping of the IP address `<ipaddr>` to the
|
||||
hardware address `<hwaddr>`.
|
||||
|
||||
- `-t`
|
||||
- `-t`
|
||||
Will dump the entire content of the ARP table. This option is only
|
||||
available if `CONFIG_NETLINK_ROUTE` is enabled.
|
||||
|
||||
@ -632,10 +632,10 @@ All of the startup-behavior is contained in `rcS.template`. The role of
|
||||
Use TFTP to copy the file at `<remote-address>` from the host whose IP
|
||||
address is identified by `<ip-address>`. Other options:
|
||||
|
||||
- `-f <local-path>`
|
||||
- `-f <local-path>`
|
||||
The file will be saved relative to the current working directory unless
|
||||
`<local-path>` is provided.
|
||||
- `-b|-n`
|
||||
- `-b|-n`
|
||||
Selects either binary (_octet_) or text (_netascii_) transfer mode. Default:
|
||||
text.
|
||||
|
||||
@ -643,10 +643,10 @@ All of the startup-behavior is contained in `rcS.template`. The role of
|
||||
|
||||
Presents summary information about NSH commands to console. Options:
|
||||
|
||||
- `-v`
|
||||
- `-v`
|
||||
Show verbose output will full command usage.
|
||||
|
||||
- `<cmd>`
|
||||
- `<cmd>`
|
||||
Show full command usage only for this command.
|
||||
|
||||
- `hexdump <file or device>`
|
||||
@ -838,9 +838,9 @@ All of the startup-behavior is contained in `rcS.template`. The role of
|
||||
|
||||
- `md5 [-f] <string or filepath>`
|
||||
|
||||
- `mb <hex-address>[=<hex-value>][ <hex-byte-count>]`
|
||||
`mh <hex-address>[=<hex-value>][ <hex-byte-count>]`
|
||||
`mw <hex-address>[=<hex-value>][ <hex-byte-count>]`
|
||||
- `mb <hex-address>[=<hex-value>][ <hex-byte-count>]`
|
||||
`mh <hex-address>[=<hex-value>][ <hex-byte-count>]`
|
||||
`mw <hex-address>[=<hex-value>][ <hex-byte-count>]`
|
||||
|
||||
Access memory using byte size access (`mb`), 16-bit accesses (`mh`),
|
||||
or 32-bit access (`mw`). In each case,
|
||||
@ -922,7 +922,7 @@ All of the startup-behavior is contained in `rcS.template`. The role of
|
||||
device driver. NSH provides this command to access the `mkfifo()` NuttX API.
|
||||
|
||||
**Example**:
|
||||
|
||||
|
||||
```
|
||||
nsh> ls -l /dev
|
||||
/dev:
|
||||
@ -971,7 +971,7 @@ All of the startup-behavior is contained in `rcS.template`. The role of
|
||||
command and mounted using the `mount` command.
|
||||
|
||||
**Example**:
|
||||
|
||||
|
||||
```
|
||||
nsh> mkrd 1024
|
||||
nsh> mkfatfs /dev/ram0
|
||||
@ -1040,7 +1040,7 @@ All of the startup-behavior is contained in `rcS.template`. The role of
|
||||
/mnt/fs type vfat
|
||||
```
|
||||
|
||||
- `mv <old-path> <new-path>`
|
||||
- `mv <old-path> <new-path>`
|
||||
|
||||
Rename the file object at `<old-path>` to `<new-path>`. Both paths must
|
||||
reside in the same mounted file system.
|
||||
@ -1110,11 +1110,11 @@ All of the startup-behavior is contained in `rcS.template`. The role of
|
||||
Copy the file at <local-address> to the host whose IP address is
|
||||
identified by <ip-address>. Other options:
|
||||
|
||||
- `-f <remote-path>`
|
||||
- `-f <remote-path>`
|
||||
The file will be saved with the same name on the host unless
|
||||
unless `<local-path>` is provided.
|
||||
|
||||
- `-b|-n`
|
||||
- `-b|-n`
|
||||
Selects either binary (_octet_) or test (_netascii_) transfer
|
||||
mode. Default: text.
|
||||
|
||||
@ -1502,7 +1502,7 @@ There are several built-in appliations in the `apps/` repository. No attempt is
|
||||
made here to enumerate all of them. But a few of the more common built- in
|
||||
applications are listed below.
|
||||
|
||||
- `ping [-c <count>] [-i <interval>] <ip-address>`
|
||||
- `ping [-c <count>] [-i <interval>] <ip-address>`
|
||||
`ping6 [-c <count>] [-i <interval>] <ip-address>`
|
||||
|
||||
Test the network communication with a remote peer. Example:
|
||||
@ -1579,7 +1579,7 @@ mkfatfs | !`CONFIG_DISABLE_MOUNTPOINT` && `CONFIG_FSUTILS_MKFATFS`
|
||||
mkfifo | `CONFIG_PIPES` && `CONFIG_DEV_FIFO_SIZE` > 0
|
||||
mkrd | !`CONFIG_DISABLE_MOUNTPOINT`
|
||||
mount | !`CONFIG_DISABLE_MOUNTPOINT`
|
||||
mv | !`CONFIG_DISABLE_MOUNTPOINT` || !`CONFIG_DISABLE_PSEUDOFS_OPERATIONS`
|
||||
mv | !`CONFIG_DISABLE_MOUNTPOINT` || !`CONFIG_DISABLE_PSEUDOFS_OPERATIONS`
|
||||
nfsmount | !`CONFIG_DISABLE_MOUNTPOINT` && `CONFIG_NET` && `CONFIG_NFS`
|
||||
nslookup | `CONFIG_LIBC_NETDB` && `CONFIG_NETDB_DNSCLIENT`
|
||||
password | !`CONFIG_DISABLE_MOUNTPOINT` && `CONFIG_NSH_LOGIN_PASSWD`
|
||||
@ -1675,7 +1675,7 @@ The behavior of NSH can be modified with the following settings in the
|
||||
- `CONFIG_NSH_READLINE` – Selects the minimal implementation of `readline()`.
|
||||
This minimal implementation provides on backspace for command line editing.
|
||||
|
||||
- `CONFIG_NSH_CLE`
|
||||
- `CONFIG_NSH_CLE`
|
||||
|
||||
Selects the more extensive, EMACS-like command line editor. Select this option
|
||||
only if (1) you don't mind a modest increase in the FLASH footprint, and (2)
|
||||
@ -1703,7 +1703,7 @@ The behavior of NSH can be modified with the following settings in the
|
||||
this feature to save a little memory on FLASH challenged platforms. Default:
|
||||
`n`
|
||||
|
||||
- `CONFIG_NSH_CMDPARMS`
|
||||
- `CONFIG_NSH_CMDPARMS`
|
||||
|
||||
If selected, then the output from commands, from file applications, and from
|
||||
NSH built-in commands can be used as arguments to other commands. The entity
|
||||
@ -1727,7 +1727,7 @@ The behavior of NSH can be modified with the following settings in the
|
||||
- `CONFIG_NSH_MAXARGUMENTS` – The maximum number of NSH command arguments.
|
||||
Default: `6`
|
||||
|
||||
- `CONFIG_NSH_ARGCAT`
|
||||
- `CONFIG_NSH_ARGCAT`
|
||||
|
||||
Support concatenation of strings with environment variables or command
|
||||
output. For example:
|
||||
@ -1743,7 +1743,7 @@ The behavior of NSH can be modified with the following settings in the
|
||||
footprint results but then also only simple environment variables like `$FOO`
|
||||
can be used on the command line.
|
||||
|
||||
- `CONFIG_NSH_VARS`
|
||||
- `CONFIG_NSH_VARS`
|
||||
|
||||
By default, there are no internal NSH variables. NSH will use OS environment
|
||||
variables for all variable storage. If this option, NSH will also support
|
||||
@ -1765,7 +1765,7 @@ The behavior of NSH can be modified with the following settings in the
|
||||
`unset <a>` | Unsets environment var `a`. | Unsets both environment var and NSH var `a`.
|
||||
`export <a> <b>` | Causes an error. | Unsets NSH var `a`. Sets environment var `a` to `b`.
|
||||
`export <a>` | Causes an error. | Sets environment var `a` to NSH var `b` (or `""`). <br> Unsets local var `a`.
|
||||
`env` | Lists all environment variables. | Lists all environment variables (only).
|
||||
`env` | Lists all environment variables. | Lists all environment variables (only).
|
||||
|
||||
- `CONFIG_NSH_QUOTE` – Enables back-slash quoting of certain characters within
|
||||
the command. This option is useful for the case where an NSH script is used to
|
||||
@ -1816,11 +1816,11 @@ The behavior of NSH can be modified with the following settings in the
|
||||
if `CONFIG_USBDEV` is defined, then a USB serial device may, instead, be used
|
||||
if the one of the following are defined:
|
||||
|
||||
- `CONFIG_PL2303` and `CONFIG_PL2303_CONSOLE`
|
||||
- `CONFIG_PL2303` and `CONFIG_PL2303_CONSOLE`
|
||||
Sets up the Prolifics PL2303 emulation as a console device at
|
||||
`/dev/console`.
|
||||
|
||||
- `CONFIG_CDCACM` and `CONFIG_CDCACM_CONSOLE`
|
||||
- `CONFIG_CDCACM` and `CONFIG_CDCACM_CONSOLE`
|
||||
Sets up the CDC/ACM serial device as a console device at `/dev/console`.
|
||||
|
||||
- `CONFIG_NSH_USBCONSOLE` – If defined, then the an arbitrary USB device may
|
||||
|
@ -1,4 +1,4 @@
|
||||
System / `trace` Task Tracer
|
||||
============================
|
||||
|
||||
See https://nuttx.apache.org/docs/latest/guides/tasktraceuser.html
|
||||
System / `trace` Task Tracer
|
||||
============================
|
||||
|
||||
See https://nuttx.apache.org/docs/latest/guides/tasktraceuser.html
|
||||
|
@ -38,11 +38,11 @@ Configuration options:
|
||||
- `CONFIG_SYSTEM_USBMSC_DEVPATH1` – The full path to the registered block
|
||||
driver. Default is `/dev/mmcsd0`
|
||||
|
||||
- `CONFIG_SYSTEM_USBMSC_DEVMINOR2` and `CONFIG_SYSTEM_USBMSC_DEVPATH2`
|
||||
- `CONFIG_SYSTEM_USBMSC_DEVMINOR2` and `CONFIG_SYSTEM_USBMSC_DEVPATH2`
|
||||
Similar parameters that would have to be provided if
|
||||
`CONFIG_SYSTEM_USBMSC_NLUNS` is `2` or `3`. No defaults.
|
||||
|
||||
- `CONFIG_SYSTEM_USBMSC_DEVMINOR3` and `CONFIG_SYSTEM_USBMSC_DEVPATH3`
|
||||
- `CONFIG_SYSTEM_USBMSC_DEVMINOR3` and `CONFIG_SYSTEM_USBMSC_DEVPATH3`
|
||||
Similar parameters that would have to be provided if
|
||||
`CONFIG_SYSTEM_USBMSC_NLUNS` is `3`. No defaults.
|
||||
|
||||
|
@ -54,7 +54,7 @@ you can delete `foo/repos/apache-mynewt-nimble` and simply make a
|
||||
link to the `mynewt-nimble` directory, so that you can work on the
|
||||
nimBLE code directly.
|
||||
|
||||
Now you can make any changes to the `yml` files such as
|
||||
Now you can make any changes to the `yml` files such as
|
||||
`porting/targets/nuttx/syscfg.yml`. Finally, you can build with:
|
||||
|
||||
$ newt build @apache-mynewt-nimble/porting/targets/nuttx
|
||||
@ -67,7 +67,7 @@ the `nuttx` target directory:
|
||||
$ cp bin/@apache-mynewt-nimble/porting/targets/nuttx/generated/include/logcfg/logcfg.h \
|
||||
repos/apache-mynewt-nimble/porting/examples/nuttx/include/logcfg
|
||||
$ cp bin/@apache-mynewt-nimble/porting/targets/nuttx/generated/include/syscfg/syscfg.h \
|
||||
repos/apache-mynewt-nimble/porting/examples/nuttx/include/syscfg
|
||||
repos/apache-mynewt-nimble/porting/examples/nuttx/include/syscfg
|
||||
|
||||
If these changes are done to fix a problem with NuttX porting layer in nimBLE, you
|
||||
should open a pull-request to nimBLE repository to include the updated header files.
|
||||
|
Loading…
Reference in New Issue
Block a user