nuttx/nuttx-mirror
1
2
Fork 0
mirror of https://github.com/apache/nuttx.git synced 2025-01-13 06:18:40 +08:00
Code Issues Projects Releases Packages Wiki Activity Actions

New Kconfig convention: Extra indentation in comments will render as HTML preformatted text

Browse source
This commit is contained in:
Gregory Nutt 2013-04-22 09:10:58 -06:00
parent c23ad7963f
commit b553609351
9 changed files with 122 additions and 97 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

48
Kconfig
View file

@ -97,34 +97,32 @@ config APPS_DIR
directory and the NuttX directory each in separate directory
trees like this:
<pre>
build
|-nuttx
| |
| `- Makefile
`-application
|
`- Makefile
</pre>
build
|-nuttx
| |
| `- Makefile
`-application
|
`- Makefile
Then you would set CONFIG_APPS_DIR=../application.
The application direction must contain Makefile and this make
file must support the following targets:
libapps$(LIBEXT) (usually libapps.a). libapps.a is a static
1)libapps$(LIBEXT) (usually libapps.a). libapps.a is a static
library ( an archive) that contains all of application object
files.
clean. Do whatever is appropriate to clean the application
2)clean. Do whatever is appropriate to clean the application
directories for a fresh build.
distclean. Clean everthing -- auto-generated files, symbolic
3)distclean. Clean everthing -- 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.
depend. Make or update the application build dependencies.
4)depend. Make or update the application build dependencies.
When this application is invoked it will receive the setting TOPDIR like:
@ -240,13 +238,11 @@ config ARCH_STDBOOL_H
However, that header includes logic to redirect the inclusion of an
architecture specific header file like:
<pre>
#ifdef CONFIG_ARCH_STDBOOL_H
# include <arch/stdbool.h>
#else
...
#endif
</pre>
#ifdef CONFIG_ARCH_STDBOOL_H
# include <arch/stdbool.h>
#else
...
#endif
Recall that that include path, include/arch, is a symbolic link and
will refer to a version of stdbool.h at nuttx/arch/<architecture>/include/stdbool.h.
@ -259,15 +255,13 @@ config ARCH_MATH_H
However, it resides out-of-the-way at include/nuttx/math.h because it
conflicts too often with the system math.h. If ARCH_MATH_H=y is
defined, however, the top-level makefile will copy the redirecting
math.h header file from include/nuttx/math.h to include/math.h. math.h
math.h header file from include/nuttx/math.h to include/math.h. math.h
will then include the architecture-specific version of math.h that you
must provide at nuttx/arch/>architecture</include/math.h.
<pre>
#ifdef CONFIG_ARCH_MATH_H
# include <arch/math.h>
#endif
</pre>
#ifdef CONFIG_ARCH_MATH_H
# include <arch/math.h>
#endif
So for the architectures that define ARCH_MATH_H=y, include/math.h
will be the redirecting math.h header file; for the architectures
@ -282,7 +276,7 @@ config ARCH_FLOAT_H
point implementation. It would always be best to use your
toolchain's float.h header file but if none is avaiable, 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
there is no assurance that the settings in this float.h are actually
correct for your platform!
config ARCH_STDARG_H

2
arch/arm/Kconfig
View file

@ -188,7 +188,7 @@ config ARMV7M_USEBASEPRI
depends on ARCH_CORTEXM3 || ARCH_CORTEXM4
---help---
Use the BASEPRI register to enable and disable able interrupts. By
default, the PRIMASK register is used for this purpose. This
default, the PRIMASK register is used for this purpose. This
usually results in hardfaults that are properly handling by the
RTOS. Using the BASEPRI register will avoid these hardfault.
That is needed primarily for integration with some toolchains.

2
arch/arm/src/lpc17xx/Kconfig
View file

@ -540,7 +540,7 @@ config SDIO_WIDTH_D1_ONLY
---help---
Select 1-bit transfer mode. This may be selected to force the driver
operate with only a single data line (the default is to use all
4 SD data lines).Default: 4-bit transfer mode.
4 SD data lines).Default: 4-bit transfer mode.
endmenu

8
arch/mips/src/pic32mx/Kconfig
View file

@ -1076,8 +1076,8 @@ config PIC32MX_FETHIO
---help---
Ethernet I/O Pin Selection bit:
1 = Default Ethernet I/O Pins
0 = Alternate Ethernet I/O Pins
1 = Default Ethernet I/O Pins
0 = Alternate Ethernet I/O Pins
config PIC32MX_FMIIEN
int "Ethernet MII"
@ -1085,8 +1085,8 @@ config PIC32MX_FMIIEN
---help---
Ethernet MII Enable bit
1 = MII enabled
0 = RMII enabled
1 = MII enabled
0 = RMII enabled
endmenu

68
arch/z80/src/z180/Kconfig
View file

@ -55,26 +55,26 @@ config Z180_BANKAREA_VIRTBASE
NuttX Memory Organization:
Common Area 0: This area holds the common NuttX code that is
directly call-able from all application threads. Common Area
always starts at virtual address 0x0000 and extends to the
Bank Area
Common Area 0: This area holds the common NuttX code that is
directly call-able from all application threads. Common Area
always starts at virtual address 0x0000 and extends to the
Bank Area
Base Area: This area holds the common NuttX data (including the
share-able heap) that is accessible from all applications and
extends to Common Area 1.
Base Area: This area holds the common NuttX data (including the
share-able heap) that is accessible from all applications and
extends to Common Area 1.
NOTE: That is execution from RAM, the common NuttX code and
data may be contiguous and lie in the same region (either
Common Area 0 or the Bank Area). The two regions above would
apply in a ROM'ed system, where Common Area 1 is ROM and the
Base Area is RAM.
NOTE: That is execution from RAM, the common NuttX code and
data may be contiguous and lie in the same region (either
Common Area 0 or the Bank Area). The two regions above would
apply in a ROM'ed system, where Common Area 1 is ROM and the
Base Area is RAM.
Common Area 1: This area holds the code and data that is unique
to a particular task. his area extends to the end of the virtual
address space. All tasks share the same virtual Common Area 2
virtual address (but each has a unique mapping to different,
underlying physical addresses).
Common Area 1: This area holds the code and data that is unique
to a particular task. his area extends to the end of the virtual
address space. All tasks share the same virtual Common Area 2
virtual address (but each has a unique mapping to different,
underlying physical addresses).
config Z180_BANKAREA_PHYSBASE
hex "Physical Start of Bank Area"
@ -93,26 +93,26 @@ config Z180_COMMON1AREA_VIRTBASE
NuttX Memory Organization:
Common Area 0: This area holds the common NuttX code that is
directly call-able from all application threads. Common Area
always starts at virtual address 0x0000 and extends to the
Bank Area
Common Area 0: This area holds the common NuttX code that is
directly call-able from all application threads. Common Area
always starts at virtual address 0x0000 and extends to the
Bank Area
Base Area: This area holds the common NuttX data (including the
share-able heap) that is accessible from all applications and
extends to Common Area 1.
Base Area: This area holds the common NuttX data (including the
share-able heap) that is accessible from all applications and
extends to Common Area 1.
NOTE: That is execution from RAM, the common NuttX code and
data may be contiguous and lie in the same region (either
Common Area 0 or the Bank Area). The two regions above would
apply in a ROM'ed system, where Common Area 1 is ROM and the
Base Area is RAM.
NOTE: That is execution from RAM, the common NuttX code and
data may be contiguous and lie in the same region (either
Common Area 0 or the Bank Area). The two regions above would
apply in a ROM'ed system, where Common Area 1 is ROM and the
Base Area is RAM.
Common Area 1: This area holds the code and data that is unique
to a particular task. his area extends to the end of the virtual
address space. All tasks share the same virtual Common Area 2
virtual address (but each has a unique mapping to different,
underlying physical addresses).
Common Area 1: This area holds the code and data that is unique
to a particular task. his area extends to the end of the virtual
address space. All tasks share the same virtual Common Area 2
virtual address (but each has a unique mapping to different,
underlying physical addresses).
config Z180_PHYSHEAP_START
hex "Physical Start of Free Memory"

4
configs/Kconfig
View file

@ -288,12 +288,12 @@ config ARCH_BOARD_NTOSD_DM320
This port uses the Neuros OSD v1.0 Dev Board with a GNU arm-nuttx-elf
toolchain*: see
http://wiki.neurostechnology.com/index.php/OSD_1.0_Developer_Home
http://wiki.neurostechnology.com/index.php/OSD_1.0_Developer_Home
There are some differences between the Dev Board and the currently
available commercial v1.0 Boards. See
http://wiki.neurostechnology.com/index.php/OSD_Developer_Board_v1
http://wiki.neurostechnology.com/index.php/OSD_Developer_Board_v1
NuttX operates on the ARM9EJS of this dual core processor.
STATUS: This port is code complete, verified, and included in the

2
libc/math/Kconfig
View file

@ -18,7 +18,7 @@ config LIBM
Another possibility is that you have a custom, architecture-specific math
libary and that the corresponding math.h file resides at arch/<architecture>/include/math.h.
The option is selected via ARCH_MATH_H. If ARCH_MATH_H is selected,then the include/nuttx/math.h
header file will be copied to include/math.h where it can be used by your applications.
header file will be copied to include/math.h where it can be used by your applications.
If ARCH_MATH_H is not defined, then this option can be selected to build a generic,
math library built into NuttX. This math library comes from the Rhombus OS and

43
sched/Kconfig
View file

@ -11,15 +11,15 @@ config BOARD_INITIALIZE
custom initialization logic:
1) <arch>_boardinitialize(): This function is used only for
initialize of very low-level things like configuration of
GPIO pins, power setting. The OS has not been initialized
at this point, so you cannot allocate memory or initialize
device drivers at this phase.
initialize of very low-level things like configuration of
GPIO pins, power setting. The OS has not been initialized
at this point, so you cannot allocate memory or initialize
device drivers at this phase.
2) The next level of initialization is performed by a call to
up_initialize() (in arch/<arch>/src/common/up_initialize.c).
The OS has been initialized at this point and it is okay to
initialize drivers in this phase.
up_initialize() (in arch/<arch>/src/common/up_initialize.c).
The OS has been initialized at this point and it is okay to
initialize drivers in this phase.
3) And, finally, when the user application code starts.
@ -88,8 +88,8 @@ config SCHED_CHILD_STATUS
Without this setting, wait(), waitpid() or waitid() may fail. For
example, if you do:
1) Start child task
2) Wait for exit status (using wait(), waitpid(), or waitid()).
1) Start child task
2) Wait for exit status (using wait(), waitpid(), or waitid()).
This can fail because the child task may run to completion before
the wait begins. There is a non-standard work-around in this case:
@ -317,19 +317,19 @@ config DISABLE_OS_API
bool "Disable NuttX interfaces"
default y
---help---
The following can be used to disable categories of
APIs supported by the OS. If the compiler supports
weak functions, then it should not be necessary to
disable functions unless you want to restrict usage
of those APIs.
The following can be used to disable categories of
APIs supported by the OS. If the compiler supports
weak functions, then it should not be necessary to
disable functions unless you want to restrict usage
of those APIs.
There are certain dependency relationships in these
features.
There are certain dependency relationships in these
features.
o mq_notify logic depends on signals to awaken tasks
waiting for queues to become full or empty.
o pthread_condtimedwait() depends on signals to wake
up waiting tasks.
1) mq_notify logic depends on signals to awaken tasks
waiting for queues to become full or empty.
2) pthread_condtimedwait() depends on signals to wake
up waiting tasks.
config DISABLE_CLOCK
bool "Disable clock interfaces"
@ -478,7 +478,7 @@ config PREALLOC_WDOGS
---help---
The number of pre-allocated watchdog structures. The system manages a
pool of preallocated watchdog structures to minimize dynamic allocations
config PREALLOC_TIMERS
int "Number of pre-allocated POSIX timers"
default 8
@ -516,4 +516,3 @@ config PTHREAD_STACK_DEFAULT
default 2048
---help---
Default pthread stack size

42
tools/kconfig2html.c
View file

@ -1100,10 +1100,13 @@ static inline void process_help(FILE *stream)
bool blank;
bool done;
bool newpara;
bool preformatted;
/* Read each comment line */
newpara = true;
preformatted = false;
for (;;)
{
/* Read the next line of comment text */
@ -1165,7 +1168,7 @@ static inline void process_help(FILE *stream)
if (!newpara)
{
body("</p>\n");
body("\n</p>\n");
newpara = true;
}
@ -1193,16 +1196,45 @@ static inline void process_help(FILE *stream)
if (newpara)
{
body("</p>\n");
body("<p>\n");
newpara = false;
}
body(" %s", htmlize_text(ptr));
/* Lines that are indented at greater levels are assumed to be
* pre-formatted text. This is not part of the Kconfig language but
* rather simply a NuttX Kconfig convention.
*/
if (indent > help_indent)
{
if (!preformatted)
{
body("\n <ul><pre>\n");
preformatted = true;
}
body("%s\n", htmlize_text(ptr));
}
else
{
if (preformatted)
{
body("</pre></ul>\n");
preformatted = false;
}
body(" %s", htmlize_text(ptr));
}
}
if (!newpara)
{
body("</p>\n");
body("\n</p>\n");
}
if (preformatted)
{
body("</pre></ul>\n");
}
}
@ -1761,7 +1793,7 @@ static inline char *process_choice(FILE *stream, const char *kconfigdir)
const char *paranum;
char *token = NULL;
char *ptr;
bool help;
bool help = false;
int i;
/* Get the choice information */