2135 lines
101 KiB
Plaintext
2135 lines
101 KiB
Plaintext
Board-Specific Configurations
|
||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||
Table of Contents
|
||
^^^^^^^^^^^^^^^^^
|
||
|
||
o Board-Specific Configurations
|
||
o Summary of Files
|
||
o Configuration Variables
|
||
o Supported Architectures
|
||
o Configuring NuttX
|
||
o Building Symbol Tables
|
||
|
||
Board-Specific Configurations
|
||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||
|
||
The NuttX configuration consists of:
|
||
|
||
o Processor architecture specific files. These are the files contained
|
||
in the arch/<arch-name>/ directory.
|
||
|
||
o Chip/SoC specific files. Each processor processor architecture
|
||
is embedded in chip or System-on-a-Chip (SoC) architecture. The
|
||
full chip architecture includes the processor architecture plus
|
||
chip-specific interrupt logic, general purpose I/O (GIO) logic, and
|
||
specialized, internal peripherals (such as UARTs, USB, etc.).
|
||
|
||
These chip-specific files are contained within chip-specific
|
||
sub-directories in the arch/<arch-name>/ directory and are selected
|
||
via the CONFIG_ARCH_name selection
|
||
|
||
o Board specific files. In order to be usable, the chip must be
|
||
contained in a board environment. The board configuration defines
|
||
additional properties of the board including such things as
|
||
peripheral LEDs, external peripherals (such as network, USB, etc.).
|
||
|
||
These board-specific configuration files can be found in the
|
||
configs/<board-name>/ sub-directories and are discussed in this
|
||
README. Additional configuration information maybe available in
|
||
board-specific configs/<board-name>/README.txt files.
|
||
|
||
The configs/ subdirectory contains configuration data for each board. These
|
||
board-specific configurations plus the architecture-specific configurations in
|
||
the arch/ subdirectory completely define a customized port of NuttX.
|
||
|
||
Directory Structure
|
||
^^^^^^^^^^^^^^^^^^^
|
||
|
||
The configs directory contains board specific configurationlogic. Each
|
||
board must provide a subdirectory <board-name> under configs/ with the
|
||
following characteristics:
|
||
|
||
|
||
<board-name>
|
||
|-- README.txt
|
||
|-- include/
|
||
| `-- (board-specific header files)
|
||
|-- src/
|
||
| |-- Makefile
|
||
| `-- (board-specific source files)
|
||
|-- <config1-dir>
|
||
| |-- Make.defs
|
||
| |-- defconfig
|
||
| |-- appconfig*
|
||
| `-- setenv.sh
|
||
|-- <config2-dir>
|
||
| |-- Make.defs
|
||
| |-- defconfig
|
||
| |-- appconfig*
|
||
| `-- setenv.sh
|
||
...
|
||
|
||
*optional
|
||
|
||
Summary of Files
|
||
^^^^^^^^^^^^^^^^
|
||
|
||
README.txt -- This text file provides additional information unique to
|
||
each board configuration sub-directory.
|
||
|
||
include/ -- This directory contains board specific header files. This
|
||
directory will be linked as include/arch/board at configuration time and
|
||
can be included via '#include <arch/board/header.h>'. These header file
|
||
can only be included by files in arch/<arch-name>include/ and
|
||
arch/<arch-name>/src
|
||
|
||
src/ -- This directory contains board specific drivers. This
|
||
directory will be linked as arch/<arch-name>/src/board at configuration
|
||
time and will be integrated into the build system.
|
||
|
||
src/Makefile -- This makefile will be invoked to build the board specific
|
||
drivers. It must support the following targets: libext$(LIBEXT), clean,
|
||
and distclean.
|
||
|
||
A board may have various different configurations using these common source
|
||
files. Each board configuration is described by three files: Make.defs,
|
||
defconfig, and setenv.sh. Typically, each set of configuration files is
|
||
retained in a separate configuration sub-directory (<config1-dir>,
|
||
<config2-dir>, .. in the above diagram).
|
||
|
||
Make.defs -- This makefile fragment provides architecture and
|
||
tool-specific build options. It will be included by all other
|
||
makefiles in the build (once it is installed). This make fragment
|
||
should define:
|
||
|
||
Tools: CC, LD, AR, NM, OBJCOPY, OBJDUMP
|
||
Tool options: CFLAGS, LDFLAGS
|
||
|
||
When this makefile fragment runs, it will be passed TOPDIR which
|
||
is the path to the root directory of the build. This makefile
|
||
fragment should include:
|
||
|
||
$(TOPDIR)/.config : Nuttx configuration
|
||
$(TOPDIR)/tools/Config.mk : Common definitions
|
||
|
||
Definitions in the Make.defs file probably depend on some of the
|
||
settings in the .config file. For example, the CFLAGS will most likely be
|
||
different if CONFIG_DEBUG=y.
|
||
|
||
The included tools/Config.mk file contains additional definitions that may
|
||
be overriden in the architecture-specific Make.defs file as necessary:
|
||
|
||
COMPILE, ASSEMBLE, ARCHIVE, CLEAN, and MKDEP macros
|
||
|
||
defconfig -- This is a configuration file similar to the Linux
|
||
configuration file. In contains variable/value pairs like:
|
||
|
||
CONFIG_VARIABLE=value
|
||
|
||
This configuration file will be used at build time:
|
||
|
||
(1) as a makefile fragment included in other makefiles, and
|
||
(2) to generate include/nuttx/config.h which is included by
|
||
most C files in the system.
|
||
|
||
appconfig -- This is another configuration file that is specific to the
|
||
application. This file is copied into the application build directory
|
||
when NuttX is configured. See ../apps/README.txt for further details.
|
||
|
||
setenv.sh -- This is a script that you can include that will be installed at
|
||
the toplevel of the directory structure and can be sourced to set any
|
||
necessary environment variables. You will most likely have to customize the
|
||
default setenv.sh script in order for it to work correctly in your
|
||
environment.
|
||
|
||
Configuration Variables
|
||
^^^^^^^^^^^^^^^^^^^^^^^
|
||
|
||
Note. This section is deprecated. Documentation of NuttX configuration is
|
||
now provided in a separate, auto-generated Configuration Variable Document.
|
||
That configuration variable document is generated using the kconfig2html
|
||
tool. That tool analyzes the NuttX Kconfig files and generates the HTML
|
||
document. As a consequence, this file may not be present at any given time
|
||
but can be regenerated following the instructions in tools directory README
|
||
file.
|
||
|
||
The following variables are recognized by the build (you may also include
|
||
architecture/board-specific settings).
|
||
|
||
Architecture selection:
|
||
|
||
CONFIG_ARCH - Identifies the arch/ subdirectory
|
||
CONFIG_ARCH_name - For use in C code
|
||
CONFIG_ARCH_CHIP - Identifies the arch/*/chip subdirectory
|
||
CONFIG_ARCH_CHIP_name - For use in C code
|
||
CONFIG_ARCH_BOARD - Identifies the configs subdirectory and
|
||
hence, the board that supports the particular chip or SoC.
|
||
CONFIG_ARCH_BOARD_name - For use in C code
|
||
CONFIG_ENDIAN_BIG - define if big endian (default is little
|
||
endian)
|
||
CONFIG_ARCH_NOINTC - define if the architecture does not
|
||
support an interrupt controller or otherwise cannot support
|
||
APIs like up_enable_irq() and up_disable_irq().
|
||
CONFIG_ARCH_VECNOTIRQ - Usually the interrupt vector number provided
|
||
to interfaces like irq_attach() and irq_detach are the same as IRQ
|
||
numbers that are provied to IRQ management functions like
|
||
up_enable_irq() and up_disable_irq(). But that is not true for all
|
||
interrupt controller implementations. For example, the PIC32MX
|
||
interrupt controller manages interrupt sources that have a many-to-one
|
||
relationship to interrupt vectors. In such cases, CONFIG_ARCH_VECNOTIRQ
|
||
must defined so that the OS logic will know not to assume it can use
|
||
a vector number to enable or disable interrupts.
|
||
CONFIG_ARCH_IRQPRIO
|
||
Define if the architecture suports prioritizaton of interrupts
|
||
and the up_prioritize_irq() API.
|
||
CONFIG_ADDRENV
|
||
The CPU supports an MMU and CPU port supports provision of address
|
||
environments for tasks (making the, perhaps, processes).
|
||
|
||
Some architectures require a description of the RAM configuration:
|
||
|
||
CONFIG_DRAM_SIZE - Describes the installed DRAM.
|
||
CONFIG_DRAM_START - The start address of DRAM (physical)
|
||
CONFIG_DRAM_VSTART - The start address of DRAM (virtual)
|
||
|
||
General build options:
|
||
|
||
CONFIG_RRLOAD_BINARY - make the rrload binary format used with
|
||
BSPs from www.ridgerun.com using the tools/mkimage.sh script.
|
||
CONFIG_INTELHEX_BINARY - make the Intel HEX binary format
|
||
used with many different loaders using the GNU objcopy program
|
||
Should not be selected if you are not using the GNU toolchain.
|
||
CONFIG_MOTOROLA_SREC - make the Motorola S-Record binary format
|
||
used with many different loaders using the GNU objcopy program
|
||
Should not be selected if you are not using the GNU toolchain.
|
||
CONFIG_RAW_BINARY - make a raw binary format file used with many
|
||
different loaders using the GNU objcopy program. This option
|
||
should not be selected if you are not using the GNU toolchain.
|
||
CONFIG_HAVE_CXX - toolchain supports C++ and CXX, CXXFLAGS, and
|
||
COMPILEXX have been defined in the configurations Make.defs
|
||
file.
|
||
CONFIG_HAVE_CXXINITIALIZE - The platform-specific logic includes support
|
||
for initialization of static C++ instances for this architecture
|
||
and for the selected toolchain (via up_cxxinitialize()).
|
||
|
||
Building application code:
|
||
|
||
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
|
||
directory and the NuttX directory each in separate directory
|
||
trees like this:
|
||
|
||
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
|
||
library ( an archive) that contains all of application object
|
||
files.
|
||
- clean. Do whatever is appropriate to clean the application
|
||
directories for a fresh build.
|
||
- 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.
|
||
|
||
When this application is invoked it will receive the setting TOPDIR like:
|
||
|
||
$(MAKE) -C $(CONFIG_APPS_DIR) TOPDIR="$(TOPDIR)" <target>
|
||
|
||
TOPDIR is the full path to the NuttX directory. It can be used, for
|
||
example, to include makefile fragments (e.g., .config or Make.defs)
|
||
or to set up include file paths.
|
||
|
||
Two-pass build options. If the 2 pass build option is selected, then these
|
||
options configure the make system build a extra link object. This link object
|
||
is assumed to be an incremental (relative) link object, but could be a static
|
||
library (archive) (some modification to this Makefile would be required if
|
||
CONFIG_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
|
||
go anywhere.
|
||
|
||
CONFIG_BUILD_2PASS - Enables the two pass build options.
|
||
|
||
When the two pass build option is enabled, the following also apply:
|
||
|
||
CONFIG_PASS1_TARGET - The name of the first pass build target. This
|
||
can be specific build target, a special build target (all, default, etc.)
|
||
or may just be left undefined.
|
||
CONFIG_PASS1_BUILDIR - The path, relative to the top NuttX build
|
||
directory to directory that contains the Makefile to build the
|
||
first pass object. The Makefile must support the following targets:
|
||
- The special target CONFIG_PASS1_TARGET (if defined)
|
||
- and the usual depend, clean, and distclean targets.
|
||
CONFIG_PASS1_OBJECT - May be used to include an extra, pass1 object
|
||
into the final link. This would probably be the object generated
|
||
from the CONFIG_PASS1_TARGET. It may be available at link time
|
||
in the arch/<architecture>/src directory.
|
||
|
||
General OS setup
|
||
|
||
CONFIG_DEBUG - enables built-in debug options
|
||
CONFIG_DEBUG_VERBOSE - enables verbose debug output
|
||
CCONFIG_SYSLOG_ENABLE - Support an interface to enable or disable debug output.
|
||
CONFIG_DEBUG_SYMBOLS - build without optimization and with
|
||
debug symbols (needed for use with a debugger).
|
||
CONFIG_DEBUG_SCHED - enable OS debug output (disabled by
|
||
default)
|
||
CONFIG_DEBUG_MM - enable memory management debug output
|
||
(disabled by default)
|
||
CONFIG_DEBUG_NET - enable network debug output (disabled
|
||
by default)
|
||
CONFIG_DEBUG_USB - enable usb debug output (disabled by
|
||
default)
|
||
CONFIG_DEBUG_FS - enable filesystem debug output (disabled
|
||
by default)
|
||
CONFIG_DEBUG_LIB - enable C library debug output (disabled
|
||
by default)
|
||
CONFIG_DEBUG_BINFMT - enable binary loader debug output (disabled
|
||
by default)
|
||
CONFIG_DEBUG_GRAPHICS - enable NX graphics debug output
|
||
(disabled by default)
|
||
|
||
CONFIG_MM_REGIONS - If the architecture includes multiple
|
||
regions of memory to allocate from, this specifies the
|
||
number of memory regions that the memory manager must
|
||
handle and enables the API mm_addregion(heap, start, end);
|
||
CONFIG_MM_SMALL - Each memory allocation has a small allocation
|
||
overhead. The size of that overhead is normally determined by
|
||
the "width" of the address support by the MCU. MCUs that support
|
||
16-bit addressability have smaller overhead than devices that
|
||
support 32-bit addressability. However, there are many MCUs
|
||
that support 32-bit addressability *but* have internal SRAM
|
||
of size less than or equal to 64Kb. In this case, CONFIG_MM_SMALL
|
||
can be defined so that those MCUs will also benefit from the
|
||
smaller, 16-bit-based allocation overhead.
|
||
CONFIG_HEAP2_BASE and CONFIG_HEAP2_SIZE
|
||
Some architectures use these settings to specify the size of
|
||
a second heap region.
|
||
CONFIG_GRAN
|
||
Enable granual allocator support. Allocations will be aligned to the
|
||
granule size; allocations will be in units of the granule size.
|
||
Larger granules will give better performance and less overhead but
|
||
more losses of memory due to alignment and quantization waste.
|
||
NOTE: The current implementation also restricts the maximum
|
||
allocation size to 32 granaules. That restriction could be
|
||
eliminated with some additional coding effort.
|
||
CONFIG_GRAN_SINGLE
|
||
Select if there is only one instance of the granule allocator (i.e.,
|
||
gran_initialize will be called only once. In this case, (1) there
|
||
are a few optimizations that can can be done and (2) the GRAN_HANDLE
|
||
is not needed.
|
||
CONFIG_GRAN_INTR - Normally mutual exclusive access to granule allocator
|
||
data is assured using a semaphore. If this option is set then, instead,
|
||
mutual exclusion logic will disable interrupts. While this options is
|
||
more invasive to system performance, it will also support use of the
|
||
granule allocator from interrupt level logic.
|
||
CONFIG_DEBUG_GRAM
|
||
Just like CONFIG_DEBUG_MM, but only generates ouput from the gran
|
||
allocation logic.
|
||
|
||
CONFIG_ARCH_LOWPUTC - architecture supports low-level, boot
|
||
time console output
|
||
CONFIG_MSEC_PER_TICK - The default system timer is 100Hz
|
||
or MSEC_PER_TICK=10. This setting may be defined to
|
||
inform NuttX that the processor hardware is providing
|
||
system timer interrupts at some interrupt interval other
|
||
than 10 msec.
|
||
CONFIG_RR_INTERVAL - The round robin timeslice will be set
|
||
this number of milliseconds; Round robin scheduling can
|
||
be disabled by setting this value to zero.
|
||
CONFIG_SCHED_INSTRUMENTATION - enables instrumentation in
|
||
scheduler to monitor system performance
|
||
CONFIG_TASK_NAME_SIZE - Specifies that maximum size of a
|
||
task name to save in the TCB. Useful if scheduler
|
||
instrumentation is selected. Set to zero to disable.
|
||
CONFIG_SCHED_HAVE_PARENT - Remember the ID of the parent task
|
||
when a new child task is created. This support enables some
|
||
additional features (such as SIGCHLD) and modifies the behavior
|
||
of other interfaces. For example, it makes waitpid() more
|
||
standards complete by restricting the waited-for tasks to the
|
||
children of the caller. Default: disabled.
|
||
CONFIG_SCHED_CHILD_STATUS
|
||
If this option is selected, then the exit status of the child task
|
||
will be retained after the child task exits. This option should be
|
||
selected if you require knowledge of a child process' exit 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()).
|
||
|
||
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:
|
||
The above sequence will work if you disable pre-emption using
|
||
sched_lock() prior to starting the child task, then re-enable pre-
|
||
emption with sched_unlock() after the wait completes. This works
|
||
because the child task is not permitted to run until the wait is in
|
||
place.
|
||
|
||
The standard solution would be to enable CONFIG_SCHED_CHILD_STATUS. In
|
||
this case the exit status of the child task is retained after the
|
||
child exits and the wait will successful obtain the child task's
|
||
exit status whether it is called before the child task exits or not.
|
||
|
||
Warning: If you enable this feature, then your application must
|
||
either (1) take responsibility for reaping the child status with wait(),
|
||
waitpid(), or waitid(), or (2) suppress retention of child status.
|
||
If you do not reap the child status, then you have a memory leak and
|
||
your system will eventually fail.
|
||
|
||
Retention of child status can be suppressed on the parent using logic like:
|
||
|
||
struct sigaction sa;
|
||
|
||
sa.sa_handler = SIG_IGN;
|
||
sa.sa_flags = SA_NOCLDWAIT;
|
||
int ret = sigaction(SIGCHLD, &sa, NULL);
|
||
|
||
CONFIG_PREALLOC_CHILDSTATUS
|
||
To prevent runaway child status allocations and to improve
|
||
allocation performance, child task exit status structures are pre-
|
||
allocated when the system boots. This setting determines the number
|
||
of child status structures that will be pre-allocated. If this
|
||
setting is not defined or if it is defined to be zero then a value
|
||
of 2*MAX_TASKS is used.
|
||
|
||
Note that there cannot be more that CONFIG_MAX_TASKS tasks in total.
|
||
However, the number of child status structures may need to be
|
||
significantly larger because this number includes the maximum number
|
||
of tasks that are running PLUS the number of tasks that have exit'ed
|
||
without having their exit status reaped (via wait(), waitid(), or
|
||
waitpid()).
|
||
|
||
Obviously, if tasks spawn children indefinitely and never have the
|
||
exit status reaped, then you may have a memory leak! If you enable
|
||
the SCHED_CHILD_STATUS feature, then your application must take
|
||
responsibility for either (1) reaping the child status with wait(),
|
||
waitpid(), or waitid() or it must (2) suppress retention of child
|
||
status. Otherwise, your system will eventually fail.
|
||
|
||
Retention of child status can be suppressed on the parent using logic like:
|
||
|
||
struct sigaction sa;
|
||
|
||
sa.sa_handler = SIG_IGN;
|
||
sa.sa_flags = SA_NOCLDWAIT;
|
||
int ret = sigaction(SIGCHLD, &sa, NULL);
|
||
|
||
CONFIG_START_YEAR, CONFIG_START_MONTH, CONFIG_START_DAY -
|
||
Used to initialize the internal time logic.
|
||
CONFIG_GREGORIAN_TIME - Enables Gregorian time conversions.
|
||
You would only need this if you are concerned about accurate
|
||
time conversions in the past or in the distant future.
|
||
CONFIG_JULIAN_TIME - Enables Julian time conversions. You
|
||
would only need this if you are concerned about accurate
|
||
time conversion in the distand past. You must also define
|
||
CONFIG_GREGORIAN_TIME in order to use Julian time.
|
||
CONFIG_DEV_CONSOLE - Set if architecture-specific logic
|
||
provides /dev/console. Enables stdout, stderr, stdin.
|
||
This implies the "normal" serial driver provides the
|
||
console unless another console device is specified
|
||
(See CONFIG_DEV_LOWCONSOLE).
|
||
CONFIG_MUTEX_TYPES - Set to enable support for recursive and
|
||
errorcheck mutexes. Enables pthread_mutexattr_settype().
|
||
CONFIG_PRIORITY_INHERITANCE - Set to enable support for
|
||
priority inheritance on mutexes and semaphores.
|
||
Priority inheritance is a strategy for addressing priority
|
||
inversion.
|
||
CONFIG_SEM_PREALLOCHOLDERS: This setting is only used if priority
|
||
inheritance is enabled. It defines the maximum number of
|
||
different threads (minus one) that can take counts on a
|
||
semaphore with priority inheritance support. This may be
|
||
set to zero if priority inheritance is disabled OR if you
|
||
are only using semaphores as mutexes (only one holder) OR
|
||
if no more than two threads participate using a counting
|
||
semaphore. If defined, then this should be a relatively
|
||
large number because this is the total number of counts on
|
||
the total number of semaphores (like 64 or 100).
|
||
CONFIG_SEM_NNESTPRIO. If priority inheritance is enabled,
|
||
then this setting is the maximum number of higher priority
|
||
threads (minus 1) than can be waiting for another thread
|
||
to release a count on a semaphore. This value may be set
|
||
to zero if no more than one thread is expected to wait for
|
||
a semaphore. If defined, then this should be a relatively
|
||
small number because this the number of maximumum of waiters
|
||
on one semaphore (like 4 or 8).
|
||
CONFIG_FDCLONE_DISABLE. Disable cloning of all file descriptors
|
||
by task_create() when a new task is started. If set, all
|
||
files/drivers will appear to be closed in the new task.
|
||
CONFIG_FDCLONE_STDIO. Disable cloning of all but the first
|
||
three file descriptors (stdin, stdout, stderr) by task_create()
|
||
when a new task is started. If set, all files/drivers will
|
||
appear to be closed in the new task except for stdin, stdout,
|
||
and stderr.
|
||
CONFIG_SDCLONE_DISABLE. Disable cloning of all socket
|
||
desciptors by task_create() when a new task is started. If
|
||
set, all sockets will appear to be closed in the new task.
|
||
CONFIG_SCHED_WORKQUEUE. Create a dedicated "worker" thread to
|
||
handle delayed processing from interrupt handlers. This feature
|
||
is required for some drivers but, if there are not complaints,
|
||
can be safely disabled. The worker thread also performs
|
||
garbage collection -- completing any delayed memory deallocations
|
||
from interrupt handlers. If the worker thread is disabled,
|
||
then that clean will be performed by the IDLE thread instead
|
||
(which runs at the lowest of priority and may not be appropriate
|
||
if memory reclamation is of high priority). If CONFIG_SCHED_WORKQUEUE
|
||
is enabled, then the following options can also be used:
|
||
CONFIG_SCHED_WORKPRIORITY - The execution priority of the worker
|
||
thread. Default: 192
|
||
CONFIG_SCHED_WORKPERIOD - How often the worker thread checks for
|
||
work in units of microseconds. Default: 50*1000 (50 MS).
|
||
CONFIG_SCHED_WORKSTACKSIZE - The stack size allocated for the worker
|
||
thread. Default: CONFIG_IDLETHREAD_STACKSIZE.
|
||
CONFIG_SIG_SIGWORK - The signal number that will be used to wake-up
|
||
the worker thread. Default: 17
|
||
CONFIG_SCHED_LPWORK. If CONFIG_SCHED_WORKQUEUE is defined, then a single
|
||
work queue is created by default. If CONFIG_SCHED_LPWORK is also defined
|
||
then an additional, lower-priority work queue will also be created. This
|
||
lower priority work queue is better suited for more extended processing
|
||
(such as file system clean-up operations)
|
||
CONFIG_SCHED_LPWORKPRIORITY - The execution priority of the lower priority
|
||
worker thread. Default: 50
|
||
CONFIG_SCHED_LPWORKPERIOD - How often the lower priority worker thread
|
||
checks for work in units of microseconds. Default: 50*1000 (50 MS).
|
||
CONFIG_SCHED_LPWORKSTACKSIZE - The stack size allocated for the lower
|
||
priority worker thread. Default: CONFIG_IDLETHREAD_STACKSIZE.
|
||
CONFIG_SCHED_WAITPID - Enables the waitpid() interface in a default,
|
||
non-standard mode (non-standard in the sense that the waited for
|
||
PID need not be child of the caller). If SCHED_HAVE_PARENT is
|
||
also defined, then this setting will modify the behavior or
|
||
waitpid() (making more spec compliant) and will enable the
|
||
waitid() and wait() interfaces as well.
|
||
CONFIG_SCHED_ATEXIT - Enables the atexit() API
|
||
CONFIG_SCHED_ATEXIT_MAX - By default if CONFIG_SCHED_ATEXIT is
|
||
selected, only a single atexit() function is supported. That number
|
||
can be increased by defined this setting to the number that you require.
|
||
CONFIG_SCHED_ONEXIT - Enables the on_exit() API
|
||
CONFIG_SCHED_ONEXIT_MAX - By default if CONFIG_SCHED_ONEXIT is selected,
|
||
only a single on_exit() function is supported. That number can be
|
||
increased by defined this setting to the number that you require.
|
||
CONFIG_USER_ENTRYPOINT - The name of the entry point for user
|
||
applications. For the example applications this is of the form 'app_main'
|
||
where 'app' is the application name. If not defined, CONFIG_USER_ENTRYPOINT
|
||
defaults to user_start.
|
||
|
||
Signal Numbers:
|
||
|
||
CONFIG_SIG_SIGUSR1 - Value of standard user signal 1 (SIGUSR1).
|
||
Default: 1
|
||
CONFIG_SIG_SIGUSR2 - Value of standard user signal 2 (SIGUSR2).
|
||
Default: 2
|
||
CONFIG_SIG_SIGALARM - Default the standard signal used with POSIX
|
||
timers (SIGALRM). Default: 3
|
||
CONFIG_SIG_SIGCHLD - The SIGCHLD signal is sent to the parent of a child
|
||
process when it exits, is interrupted (stopped), or resumes after being
|
||
interrupted. Default: 4
|
||
|
||
CONFIG_SIG_SIGCONDTIMEDOUT - This non-standard signal number is used in
|
||
the implementation of pthread_cond_timedwait(). Default 16.
|
||
CONFIG_SIG_SIGWORK - SIGWORK is a non-standard signal used to wake up
|
||
the internal NuttX worker thread. Default: 17.
|
||
|
||
Binary Loaders:
|
||
CONFIG_BINFMT_DISABLE - By default, support for loadable binary formats
|
||
is built.
|
||
This logic may be suppressed be defining this setting.
|
||
CONFIG_BINFMT_CONSTRUCTORS - Build in support for C++ constructors in
|
||
loaded modules.
|
||
CONFIG_SYMTAB_ORDEREDBYNAME - Symbol tables are order by name (rather
|
||
than value).
|
||
CONFIG_NXFLAT. Enable support for the NXFLAT binary format. This format
|
||
will support execution of NuttX binaries located in a ROMFS filesystem
|
||
(see apps/examples/nxflat).
|
||
CONFIG_ELF - Enable support for the ELF binary format. This format will
|
||
support execution of ELF binaries copied from a file system and
|
||
relocated into RAM (see apps/examples/elf).
|
||
|
||
If CONFIG_ELF is selected, then these additional options are available:
|
||
|
||
CONFIG_ELF_ALIGN_LOG2 - Align all sections to this Log2 value: 0->1,
|
||
1->2, 2->4, etc.
|
||
CONFIG_ELF_STACKSIZE - This is the default stack size that will will
|
||
be used when starting ELF binaries.
|
||
CONFIG_ELF_BUFFERSIZE - This is an I/O buffer that is used to access
|
||
the ELF file. Variable length items will need to be read (such as
|
||
symbol names). This is really just this initial size of the buffer;
|
||
it will be reallocated as necessary to hold large symbol names).
|
||
Default: 128
|
||
CONFIG_ELF_BUFFERINCR - This is an I/O buffer that is used to access
|
||
the ELF file. Variable length items will need to be read (such as
|
||
symbol names). This value specifies the size increment to use each
|
||
time the buffer is reallocated. Default: 32
|
||
CONFIG_ELF_DUMPBUFFER - Dump various ELF buffers for debug purposes.
|
||
This option requires CONFIG_DEBUG and CONFIG_DEBUG_VERBOSE.
|
||
|
||
System Logging:
|
||
CONFIG_SYSLOG enables general system logging support.
|
||
CONFIG_SYSLOG_DEVPATH - The full path to the system logging device. Default
|
||
"/dev/ramlog" (RAMLOG) or "dev/ttyS1" (character device)
|
||
|
||
At present, there are two system loggins devices available. If CONFIG_SYSLOG
|
||
is selected, then these options are also available.
|
||
|
||
CONFIG_SYSLOG_CHAR - Enable the generic character device for the SYSLOG.
|
||
A disadvantage of using the generic character device for the SYSLOG is that
|
||
it cannot handle debug output generated from interrupt level handlers.
|
||
NOTE: No more than one SYSLOG device should be configured.
|
||
|
||
CONFIG_RAMLOG - Enables the RAM logging feature. The RAM log is a circular
|
||
buffer in RAM. NOTE: No more than one SYSLOG device should be configured.
|
||
CONFIG_RAMLOG_CONSOLE - Use the RAM logging device as a system console.
|
||
If this feature is enabled (along with CONFIG_DEV_CONSOLE), then all
|
||
console output will be re-directed to a circular buffer in RAM. This
|
||
is useful, for example, if the only console is a Telnet console. Then
|
||
in that case, console output from non-Telnet threads will go to the
|
||
circular buffer and can be viewed using the NSH 'dmesg' command.
|
||
CONFIG_RAMLOG_SYSLOG - Use the RAM logging device for the syslogging
|
||
interface. If this feature is enabled (along with CONFIG_SYSLOG),
|
||
then all debug output (only) will be re-directed to the circular
|
||
buffer in RAM. This RAM log can be view from NSH using the 'dmesg'
|
||
command. NOTE: Unlike the limited, generic character driver SYSLOG
|
||
device, the RAMLOG *can* be used to generate debug output from interrupt
|
||
level handlers.
|
||
CONFIG_RAMLOG_NPOLLWAITERS - The number of threads than can be waiting
|
||
for this driver on poll(). Default: 4
|
||
|
||
If CONFIG_RAMLOG_CONSOLE or CONFIG_RAMLOG_SYSLOG is selected, then the
|
||
following may also be provided:
|
||
|
||
CONFIG_RAMLOG_CONSOLE_BUFSIZE - Size of the console RAM log. Default: 1024
|
||
|
||
Kernel build options:
|
||
CONFIG_NUTTX_KERNEL - Builds NuttX as a separately compiled kernel.
|
||
CONFIG_SYS_RESERVED - Reserved system call values for use
|
||
by architecture-specific logic.
|
||
|
||
OS setup related to on-demand paging:
|
||
|
||
CONFIG_PAGING - If set =y in your configation file, this setting will
|
||
enable the on-demand paging feature as described in
|
||
http://www.nuttx.org/NuttXDemandPaging.html.
|
||
|
||
If CONFIG_PAGING is selected, then you will probabaly need CONFIG_BUILD_2PASS to
|
||
correctly position the code and the following configuration options also apply:
|
||
|
||
CONFIG_PAGING_PAGESIZE - The size of one managed page. This must
|
||
be a value supported by the processor's memory management unit.
|
||
CONFIG_PAGING_NLOCKED - This is the number of locked pages in the
|
||
memory map. The locked address region will then be from
|
||
CONFIG_DRAM_VSTART through (CONFIG_DRAM_VSTART +
|
||
CONFIG_PAGING_PAGESIZE*CONFIG_PAGING_NLOCKED)
|
||
CONFIG_PAGING_LOCKED_PBASE and CONFIG_PAGING_LOCKED_VBASE - These
|
||
may be defined to determine the base address of the locked page
|
||
regions. If neither are defined, the logic will be set the bases
|
||
to CONFIG_DRAM_START and CONFIG_DRAM_VSTART (i.e., it assumes
|
||
that the base address of the locked region is at the beginning
|
||
of RAM).
|
||
NOTE: In some architectures, it may be necessary to take some
|
||
memory from the beginning of this region for vectors or for a
|
||
page table. In such cases, CONFIG_PAGING_LOCKED_P/VBASE should
|
||
take that into consideration to prevent overlapping the locked
|
||
memory region and the system data at the beginning of SRAM.
|
||
CONFIG_PAGING_NPPAGED - This is the number of physical pages
|
||
available to support the paged text region. This paged region
|
||
begins at (CONFIG_PAGING_LOCKED_PBASE + CONFIG_PAGING_PAGESIZE*CONFIG_PAGING_NPPAGED)
|
||
and continues until (CONFIG_PAGING_LOCKED_PBASE + CONFIG_PAGING_PAGESIZE*(CONFIG_PAGING_NLOCKED +
|
||
CONFIG_PAGING_NPPAGED)
|
||
CONFIG_PAGING_NVPAGED - This actual size of the paged text region
|
||
(in pages). This is also the number of virtual pages required to
|
||
support the entire paged region. The on-demand paging feature is
|
||
intended to support only the case where the virtual paged text
|
||
area is much larger the available physical pages. Otherwise, why
|
||
would you enable on-demand paging?
|
||
CONFIG_PAGING_NDATA - This is the number of data pages in the memory
|
||
map. The data region will extend to the end of RAM unless overridden
|
||
by a setting in the configuration file.
|
||
NOTE: In some architectures, it may be necessary to take some memory
|
||
from the end of RAM for page tables or other system usage. The
|
||
configuration settings and linker directives must be cognizant of that:
|
||
CONFIG_PAGING_NDATA should be defined to prevent the data region from
|
||
extending all the way to the end of memory.
|
||
CONFIG_PAGING_DEFPRIO - The default, minimum priority of the page fill
|
||
worker thread. The priority of the page fill work thread will be boosted
|
||
boosted dynmically so that it matches the priority of the task on behalf
|
||
of which it peforms the fill. This defines the minimum priority that
|
||
will be used. Default: 50.
|
||
CONFIG_PAGING_STACKSIZE - Defines the size of the allocated stack
|
||
for the page fill worker thread. Default: 1024.
|
||
CONFIG_PAGING_BLOCKINGFILL - The architecture specific up_fillpage()
|
||
function may be blocking or non-blocking. If defined, this setting
|
||
indicates that the up_fillpage() implementation will block until the
|
||
transfer is completed. Default: Undefined (non-blocking).
|
||
CONFIG_PAGING_WORKPERIOD - The page fill worker thread will wake periodically
|
||
even if there is no mapping to do. This selection controls that wake-up
|
||
period (in microseconds). This wake-up a failsafe that will handle any
|
||
cases where a single is lost (that would really be a bug and shouldn't
|
||
happen!) and also supports timeouts for case of non-blocking, asynchronous
|
||
fills (see CONFIG_PAGING_TIMEOUT_TICKS).
|
||
CONFIG_PAGING_TIMEOUT_TICKS - If defined, the implementation will monitor
|
||
the (asynchronous) page fill logic. If the fill takes longer than this
|
||
number if microseconds, then a fatal error will be declared.
|
||
Default: No timeouts monitored.
|
||
|
||
Some architecture-specific settings. Defaults are architecture specific.
|
||
If you don't know what you are doing, it is best to leave these undefined
|
||
and try the system defaults:
|
||
|
||
CONFIG_PAGING_VECPPAGE - This the physical address of the page in
|
||
memory to be mapped to the vector address.
|
||
CONFIG_PAGING_VECL2PADDR - This is the physical address of the L2
|
||
page table entry to use for the vector mapping.
|
||
CONFIG_PAGING_VECL2VADDR - This is the virtual address of the L2
|
||
page table entry to use for the vector mapping.
|
||
CONFIG_PAGING_BINPATH - If CONFIG_PAGING_BINPATH is defined, then it
|
||
is the full path to a file on a mounted file system that contains
|
||
a binary image of the NuttX executable. Pages will be filled by
|
||
reading from offsets into this file that correspond to virtual
|
||
fault addresses.
|
||
CONFIG_PAGING_MOUNTPT - If CONFIG_PAGING_BINPATH is defined, additional
|
||
options may be provided to control the initialization of underlying
|
||
devices. CONFIG_PAGING_MOUNTPT identifies the mountpoint to be used
|
||
if a device is mounted.
|
||
CONFIG_PAGING_MINOR - Some mount operations require a "minor" number
|
||
to identify the specific device instance. Default: 0
|
||
CONFIG_PAGING_SDSLOT - If CONFIG_PAGING_BINPATH is defined, additional
|
||
options may be provided to control the initialization of underlying
|
||
devices. CONFIG_PAGING_SDSLOT identifies the slot number of the SD
|
||
device to initialize. This must be undefined if SD is not being used.
|
||
This should be defined to be zero for the typical device that has
|
||
only a single slot (See CONFIG_MMCSD_NSLOTS). If defined,
|
||
CONFIG_PAGING_SDSLOT will instruct certain board-specific logic to
|
||
initialize the media in this SD slot.
|
||
CONFIG_PAGING_M25PX - Use the m25px.c FLASH driver. If this is selected,
|
||
then the MTD interface to the M25Px device will be used to support
|
||
paging.
|
||
CONFIG_PAGING_AT45DB - Use the at45db.c FLASH driver. If this is selected,
|
||
then the MTD interface to the Atmel AT45DB device will be used to support
|
||
paging.
|
||
CONFIG_PAGING_BINOFFSET - If CONFIG_PAGING_M25PX or is CONFIG_PAGING_AT45DB
|
||
defined then CONFIG_PAGING_BINOFFSET will be used to specify the offset
|
||
in bytes into the FLASH device where the NuttX binary image is located.
|
||
Default: 0
|
||
CONFIG_PAGING_SPIPORT - If CONFIG_PAGING_M25PX CONFIG_PAGING_AT45DB is
|
||
defined and the device has multiple SPI busses (ports), then this
|
||
configuration should be set to indicate which SPI port the device is
|
||
connected. Default: 0
|
||
|
||
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.
|
||
|
||
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.
|
||
|
||
CONFIG_DISABLE_CLOCK, CONFIG_DISABLE_POSIX_TIMERS, CONFIG_DISABLE_PTHREAD.
|
||
CONFIG_DISABLE_SIGNALS, CONFIG_DISABLE_MQUEUE, CONFIG_DISABLE_MOUNTPOUNT,
|
||
CONFIG_DISABLE_ENVIRON, CONFIG_DISABLE_POLL
|
||
|
||
Misc libc settings
|
||
|
||
CONFIG_NOPRINTF_FIELDWIDTH - sprintf-related logic is a little smaller
|
||
if we do not support fieldwidthes
|
||
CONFIG_LIBC_FLOATINGPOINT - By default, floating point support in printf,
|
||
sscanf, etc. is disabled.
|
||
CONFIG_LIBC_STRERROR - strerror() is useful because it decodes 'errno'
|
||
values into a human readable strings. But it can also require
|
||
a lot of memory. If this option is selected, strerror() will still
|
||
exist in the build but it will not decode error values. This option
|
||
should be used by other logic to decide if it should use strerror() or
|
||
not. For example, the NSH application will not use strerror() if this
|
||
option is not selected; perror() will not use strerror() is this option
|
||
is not selected (see also CONFIG_NSH_STRERROR).
|
||
CONFIG_LIBC_STRERROR_SHORT - If this option is selected, then strerror()
|
||
will use a shortened string when it decodes the error. Specifically,
|
||
strerror() is simply use the string that is the common name for the
|
||
error. For example, the 'errno' value of 2 will produce the string
|
||
"No such file or directory" if CONFIG_LIBC_STRERROR_SHORT is not
|
||
defined but the string "ENOENT" if CONFIG_LIBC_STRERROR_SHORT is
|
||
defined.
|
||
CONFIG_LIBC_PERROR_STDOUT - POSIX requires that perror() provide its output
|
||
on stderr. This option may be defined, however, to provide perror() output
|
||
that is serialized with other stdout messages.
|
||
|
||
Allow for architecture optimized implementations
|
||
|
||
The architecture can provide optimized versions of the
|
||
following to improve system performance
|
||
|
||
CONFIG_ARCH_MEMCPY, CONFIG_ARCH_MEMCMP, CONFIG_ARCH_MEMMOVE
|
||
CONFIG_ARCH_MEMSET, CONFIG_ARCH_STRCMP, CONFIG_ARCH_STRCPY
|
||
CONFIG_ARCH_STRNCPY, CONFIG_ARCH_STRLEN, CONFIG_ARCH_STRNLEN
|
||
CONFIG_ARCH_BZERO
|
||
|
||
If CONFIG_ARCH_MEMCPY is not selected, then you make also select Daniel
|
||
Vik's optimized implementation of memcpy():
|
||
|
||
CONFIG_MEMCPY_VIK - Select this option to use the optimized memcpy()
|
||
function by Daniel Vik. Select this option for improved performance
|
||
at the expense of increased size. See licensing information in the
|
||
top-level COPYING file. Default: n
|
||
|
||
And if CONFIG_MEMCPY_VIK is selected, the following tuning options are available:
|
||
|
||
CONFIG_MEMCPY_PRE_INC_PTRS - Use pre-increment of pointers. Default is
|
||
post increment of pointers.
|
||
|
||
CONFIG_MEMCPY_INDEXED_COPY - Copying data using array indexing. Using
|
||
this option, disables the CONFIG_MEMCPY_PRE_INC_PTRS option.
|
||
|
||
CONFIG_MEMCPY_64BIT - Compiles memcpy for architectures that suppport
|
||
64-bit operations efficiently.
|
||
|
||
If CONFIG_ARCH_MEMSET is not selected, then the following option is
|
||
also available:
|
||
|
||
CONFIG_MEMSET_OPTSPEED - Select this option to use a version of memcpy()
|
||
optimized for speed. Default: memcpy() is optimized for size.
|
||
|
||
And if CONFIG_MEMSET_OPTSPEED is selected, the following tuning option is
|
||
available:
|
||
|
||
CONFIG_MEMSET_64BIT - Compiles memset() for architectures that suppport
|
||
64-bit operations efficiently.
|
||
|
||
The architecture may provide custom versions of certain standard header
|
||
files:
|
||
|
||
CONFIG_ARCH_STDBOOL_H - The stdbool.h header file can be found at
|
||
nuttx/include/stdbool.h. However, that header includes logic to redirect
|
||
the inclusion of an architecture specific header file like:
|
||
|
||
#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.
|
||
|
||
CONFIG_ARCH_STDINT_H - Similar logic exists for the stdint.h header
|
||
file can also be found at nuttx/include/stdint.h.
|
||
|
||
#ifdef CONFIG_ARCH_STDBOOL_H
|
||
# include <arch/stdinit.h>
|
||
#else
|
||
...
|
||
#endif
|
||
|
||
CONFIG_ARCH_MATH_H - There is also a re-directing version of math.h in
|
||
the source tree. However, it resides out-of-the-way at include/nuttx/math.h
|
||
because it conflicts too often with the system math.h. If CONFIG_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
|
||
will then include the architecture-specific version of math.h that you
|
||
must provide at nuttx/arch/>architecture</include/math.h.
|
||
|
||
#ifdef CONFIG_ARCH_MATH_H
|
||
# include <arch/math.h>
|
||
#endif
|
||
|
||
So for the architectures that define CONFIG_ARCH_MATH_H=y, include/math.h
|
||
will be the redirecting math.h header file; for the architectures that
|
||
don't select CONFIG_ARCH_MATH_H, the redirecting math.h header file will
|
||
stay out-of-the-way in include/nuttx/.
|
||
|
||
CONFIG_ARCH_FLOAT_H
|
||
If you enable the generic, built-in math library, then that math library
|
||
will expect your toolchain to provide the standard float.h header file.
|
||
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 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!
|
||
|
||
CONFIG_ARCH_STDARG_H - There is also a redirecting version of stdarg.h in
|
||
the source tree as well. It also resides out-of-the-way at include/nuttx/stdarg.h.
|
||
This is because you should normally use your toolchain's stdarg.h file. But
|
||
sometimes, your toolchain's stdarg.h file may have other header file
|
||
dependencies and so may not be usable in the NuttX build environment. In
|
||
those cases, you may have to create a architecture-specific stdarg.h header
|
||
file at nuttx/arch/>architecture</include/stdarg.h
|
||
|
||
If CONFIG_ARCH_STDARG_H=y is defined, the top-level makefile will copy the
|
||
re-directing stdarg.h header file from include/nuttx/stdarg.h to
|
||
include/stdarg.h. So for the architectures that cannot use their toolchain's
|
||
stdarg.h file, they can use this alternative by defining CONFIG_ARCH_STDARG_H=y
|
||
and providing. If CONFIG_ARCH_STDARG_H, is not defined, then the stdarg.h
|
||
header file will stay out-of-the-way in include/nuttx/.
|
||
|
||
CONFIG_ARCH_ROMGETC - In Harvard architectures, data accesses and
|
||
instruction accesses occur on different busses, perhaps
|
||
concurrently. All data accesses are performed on the data bus
|
||
unless special machine instructions are used to read data
|
||
from the instruction address space. Also, in the typical
|
||
MCU, the available SRAM data memory is much smaller that the
|
||
non-volatile FLASH instruction memory. So if the application
|
||
requires many constant strings, the only practical solution may
|
||
be to store those constant strings in FLASH memory where they
|
||
can only be accessed using architecture-specific machine
|
||
instructions.
|
||
|
||
If CONFIG_ARCH_ROMGETC is defined, then the architecture logic
|
||
must export the function up_romgetc(). up_romgetc() will simply
|
||
read one byte of data from the instruction space.
|
||
|
||
If CONFIG_ARCH_ROMGETC, certain C stdio functions are effected:
|
||
(1) All format strings in printf, fprintf, sprintf, etc. are
|
||
assumed to lie in FLASH (string arguments for %s are still assumed
|
||
to reside in SRAM). And (2), the string argument to puts and fputs
|
||
is assumed to reside in FLASH. Clearly, these assumptions may have
|
||
to modified for the particular needs of your environment. There
|
||
is no "one-size-fits-all" solution for this problem.
|
||
|
||
Sizes of configurable things (0 disables)
|
||
|
||
CONFIG_MAX_TASKS - The maximum number of simultaneously
|
||
active tasks. This value must be a power of two.
|
||
CONFIG_NPTHREAD_KEYS - The number of items of thread-
|
||
specific data that can be retained
|
||
CONFIG_NFILE_DESCRIPTORS - The maximum number of file
|
||
descriptors (one for each open)
|
||
CONFIG_NFILE_STREAMS - The maximum number of streams that
|
||
can be fopen'ed
|
||
CONFIG_NAME_MAX - Maximum number of bytes in a filename (not including
|
||
terminating null). Default: 32
|
||
CONFIG_PATH_MAX - Maximum number of bytes in a pathname, including the
|
||
terminating null character. Default: MIN(256,(4*CONFIG_NAME_MAX+1))
|
||
CONFIG_STDIO_BUFFER_SIZE - Size of the buffer to allocate
|
||
on fopen. (Only if CONFIG_NFILE_STREAMS > 0)
|
||
CONFIG_STDIO_LINEBUFFER - If standard C buffered I/O is enabled
|
||
(CONFIG_STDIO_BUFFER_SIZE > 0), then this option may be added
|
||
to force automatic, line-oriented flushing the output buffer
|
||
for putc(), fputc(), putchar(), puts(), fputs(), printf(),
|
||
fprintf(), and vfprintf(). When a newline is encountered in
|
||
the output string, the output buffer will be flushed. This
|
||
(slightly) increases the NuttX footprint but supports the kind
|
||
of behavior that people expect for printf().
|
||
CONFIG_NUNGET_CHARS - Number of characters that can be
|
||
buffered by ungetc() (Only if CONFIG_NFILE_STREAMS > 0)
|
||
CONFIG_PREALLOC_MQ_MSGS - The number of pre-allocated message
|
||
structures. The system manages a pool of preallocated
|
||
message structures to minimize dynamic allocations
|
||
CONFIG_PREALLOC_IGMPGROUPS - Pre-allocated IGMP groups are used
|
||
only if needed from interrupt level group created (by the IGMP server).
|
||
Default: 4.
|
||
CONFIG_MQ_MAXMSGSIZE - Message structures are allocated with
|
||
a fixed payload size given by this settin (does not include
|
||
other message structure overhead.
|
||
CONFIG_PREALLOC_WDOGS - The number of pre-allocated watchdog
|
||
structures. The system manages a pool of preallocated
|
||
watchdog structures to minimize dynamic allocations
|
||
CONFIG_DEV_PIPE_SIZE - Size, in bytes, of the buffer to allocated
|
||
for pipe and FIFO support
|
||
|
||
Filesystem configuration
|
||
|
||
CONFIG_FS_FAT - Enable FAT filesystem support
|
||
CONFIG_FAT_LCNAMES - Enable use of the NT-style upper/lower case 8.3
|
||
file name support.
|
||
CONFIG_FAT_LFN - Enable FAT long file names. NOTE: Microsoft claims
|
||
patents on FAT long file name technology. Please read the
|
||
disclaimer in the top-level COPYING file and only enable this
|
||
feature if you understand these issues.
|
||
CONFIG_FAT_MAXFNAME - If CONFIG_FAT_LFN is defined, then the
|
||
default, maximum long file name is 255 bytes. This can eat up
|
||
a lot of memory (especially stack space). If you are willing
|
||
to live with some non-standard, short long file names, then
|
||
define this value. A good choice would be the same value as
|
||
selected for CONFIG_NAME_MAX which will limit the visibility
|
||
of longer file names anyway.
|
||
CONFIG_FS_FATTIME: Support FAT date and time. NOTE: There is not
|
||
much sense in supporting FAT date and time unless you have a
|
||
hardware RTC or other way to get the time and date.
|
||
CONFIG_FS_NXFFS: Enable NuttX FLASH file system (NXFF) support.
|
||
CONFIG_NXFFS_ERASEDSTATE: The erased state of FLASH.
|
||
This must have one of the values of 0xff or 0x00.
|
||
Default: 0xff.
|
||
CONFIG_NXFFS_PACKTHRESHOLD: When packing flash file data,
|
||
don't both with file chunks smaller than this number of data bytes.
|
||
Default: 32.
|
||
CONFIG_NXFFS_MAXNAMLEN: The maximum size of an NXFFS file name.
|
||
Default: 255.
|
||
CONFIG_NXFFS_PACKTHRESHOLD: When packing flash file data,
|
||
don't both with file chunks smaller than this number of data bytes.
|
||
Default: 32.
|
||
CONFIG_NXFFS_TAILTHRESHOLD: clean-up can either mean
|
||
packing files together toward the end of the file or, if file are
|
||
deleted at the end of the file, clean up can simply mean erasing
|
||
the end of FLASH memory so that it can be re-used again. However,
|
||
doing this can also harm the life of the FLASH part because it can
|
||
mean that the tail end of the FLASH is re-used too often. This
|
||
threshold determines if/when it is worth erased the tail end of FLASH
|
||
and making it available for re-use (and possible over-wear).
|
||
Default: 8192.
|
||
CONFIG_FS_ROMFS - Enable ROMFS filesystem support
|
||
CONFIG_NFS - Enable Network File System (NFS) client file system support.
|
||
Provided support is version 3 using UDP. In addition to common
|
||
prerequisites for mount-able file systems in general, this option
|
||
requires UDP networking support; this would include CONFIG_NETand
|
||
CONFIG_NET_UDP at a minimum.
|
||
CONFIG_FS_RAMMAP - For file systems that do not support XIP, this
|
||
option will enable a limited form of memory mapping that is
|
||
implemented by copying whole files into memory.
|
||
|
||
RTC
|
||
|
||
CONFIG_RTC - Enables general support for a hardware RTC. Specific
|
||
architectures may require other specific settings.
|
||
CONFIG_RTC_DATETIME - There are two general types of RTC: (1) A simple
|
||
battery backed counter that keeps the time when power is down, and (2)
|
||
A full date / time RTC the provides the date and time information, often
|
||
in BCD format. If CONFIG_RTC_DATETIME is selected, it specifies this
|
||
second kind of RTC. In this case, the RTC is used to "seed" the normal
|
||
NuttX timer and the NuttX system timer provides for higher resoution
|
||
time.
|
||
CONFIG_RTC_HIRES - If CONFIG_RTC_DATETIME not selected, then the simple,
|
||
battery backed counter is used. There are two different implementations
|
||
of such simple counters based on the time resolution of the counter:
|
||
The typical RTC keeps time to resolution of 1 second, usually
|
||
supporting a 32-bit time_t value. In this case, the RTC is used to
|
||
"seed" the normal NuttX timer and the NuttX timer provides for higher
|
||
resoution time. If CONFIG_RTC_HIRES is enabled in the NuttX configuration,
|
||
then the RTC provides higher resolution time and completely replaces the
|
||
system timer for purpose of date and time.
|
||
CONFIG_RTC_FREQUENCY - If CONFIG_RTC_HIRES is defined, then the frequency
|
||
of the high resolution RTC must be provided. If CONFIG_RTC_HIRES is
|
||
not defined, CONFIG_RTC_FREQUENCY is assumed to be one.
|
||
CONFIG_RTC_ALARM - Enable if the RTC hardware supports setting of an
|
||
alarm. A callback function will be executed when the alarm goes off
|
||
|
||
CAN driver
|
||
|
||
CONFIG_CAN - Enables CAN support (one or both of CONFIG_STM32_CAN1 or
|
||
CONFIG_STM32_CAN2 must also be defined)
|
||
CONFIG_CAN_EXTID - Enables support for the 29-bit extended ID. Default
|
||
Standard 11-bit IDs.
|
||
CONFIG_CAN_FIFOSIZE - The size of the circular buffer of CAN messages.
|
||
Default: 8
|
||
CONFIG_CAN_NPENDINGRTR - The size of the list of pending RTR requests.
|
||
Default: 4
|
||
CONFIG_CAN_LOOPBACK - A CAN driver may or may not support a loopback
|
||
mode for testing. If the driver does support loopback mode, the setting
|
||
will enable it. (If the driver does not, this setting will have no effect).
|
||
|
||
SPI driver
|
||
|
||
CONFIG_SPI_OWNBUS - Set if there is only one active device
|
||
on the SPI bus. No locking or SPI configuration will be performed.
|
||
It is not necessary for clients to lock, re-configure, etc..
|
||
CONFIG_SPI_EXCHANGE - Driver supports a single exchange method
|
||
(vs a recvblock() and sndblock ()methods)
|
||
|
||
SPI-based MMC/SD driver
|
||
|
||
CONFIG_MMCSD_NSLOTS - Number of MMC/SD slots supported by the
|
||
driver. Default is one.
|
||
CONFIG_MMCSD_READONLY - Provide read-only access. Default is
|
||
Read/Write
|
||
CONFIG_MMCSD_SPICLOCK - Maximum SPI clock to drive MMC/SD card.
|
||
Default is 20MHz.
|
||
|
||
SDIO/SDHC driver:
|
||
|
||
CONFIG_SDIO_DMA - SDIO driver supports DMA
|
||
CONFIG_SDIO_MUXBUS - Set this SDIO interface if the SDIO interface
|
||
or hardware resources are shared with other drivers.
|
||
CONFIG_SDIO_WIDTH_D1_ONLY - Select 1-bit transfer mode. Default:
|
||
4-bit transfer mode.
|
||
CONFIG_MMCSD_MULTIBLOCK_DISABLE - Use only the single block transfer method.
|
||
This setting is used to work around buggy SDIO drivers that cannot handle
|
||
multiple block transfers.
|
||
|
||
SDIO-based MMC/SD driver
|
||
|
||
CONFIG_FS_READAHEAD - Enable read-ahead buffering
|
||
CONFIG_FS_WRITEBUFFER - Enable write buffering
|
||
CONFIG_MMCSD_MMCSUPPORT - Enable support for MMC cards
|
||
CONFIG_MMCSD_HAVECARDDETECT - SDIO driver card detection is
|
||
100% accurate
|
||
|
||
RiT P14201 OLED driver
|
||
|
||
CONFIG_LCD_P14201 - Enable P14201 support
|
||
CONFIG_P14201_SPIMODE - Controls the SPI mode
|
||
CONFIG_P14201_FREQUENCY - Define to use a different bus frequency
|
||
CONFIG_P14201_NINTERFACES - Specifies the number of physical P14201
|
||
devices that will be supported.
|
||
CONFIG_P14201_FRAMEBUFFER - If defined, accesses will be performed
|
||
using an in-memory copy of the OLEDs GDDRAM. This cost of this
|
||
buffer is 128 * 96 / 2 = 6Kb. If this is defined, then the driver
|
||
will be fully functional. If not, then it will have the following
|
||
limitations:
|
||
- Reading graphics memory cannot be supported, and
|
||
- All pixel writes must be aligned to byte boundaries.
|
||
The latter limitation effectively reduces the 128x96 disply to 64x96.
|
||
|
||
Nokia 6100 Configuration Settings:
|
||
|
||
CONFIG_NOKIA6100_SPIMODE - Controls the SPI mode
|
||
CONFIG_NOKIA6100_FREQUENCY - Define to use a different bus frequency
|
||
CONFIG_NOKIA6100_NINTERFACES - Specifies the number of physical Nokia
|
||
6100 devices that will be supported.
|
||
CONFIG_NOKIA6100_BPP - Device supports 8, 12, and 16 bits per pixel.
|
||
CONFIG_NOKIA6100_S1D15G10 - Selects the Epson S1D15G10 display controller
|
||
CONFIG_NOKIA6100_PCF8833 - Selects the Phillips PCF8833 display controller
|
||
CONFIG_NOKIA6100_BLINIT - Initial backlight setting
|
||
|
||
The following may need to be tuned for your hardware:
|
||
CONFIG_NOKIA6100_INVERT - Display inversion, 0 or 1, Default: 1
|
||
CONFIG_NOKIA6100_MY - Display row direction, 0 or 1, Default: 0
|
||
CONFIG_NOKIA6100_MX - Display column direction, 0 or 1, Default: 1
|
||
CONFIG_NOKIA6100_V - Display address direction, 0 or 1, Default: 0
|
||
CONFIG_NOKIA6100_ML - Display scan direction, 0 or 1, Default: 0
|
||
CONFIG_NOKIA6100_RGBORD - Display RGB order, 0 or 1, Default: 0
|
||
|
||
Required LCD driver settings:
|
||
CONFIG_LCD_NOKIA6100 - Enable Nokia 6100 support
|
||
CONFIG_LCD_MAXCONTRAST - must be 63 with the Epson controller and 127 with
|
||
the Phillips controller.
|
||
CONFIG_LCD_MAXPOWER - Maximum value of backlight setting. The backlight
|
||
control is managed outside of the 6100 driver so this value has no
|
||
meaning to the driver. Board-specific logic may place restrictions on
|
||
this value.
|
||
|
||
Input Devices
|
||
|
||
CONFIG_INPUT
|
||
Enables general support for input devices
|
||
|
||
CONFIG_INPUT_TSC2007
|
||
If CONFIG_INPUT is selected, then this setting will enable building
|
||
of the TI TSC2007 touchscreen driver.
|
||
CONFIG_TSC2007_MULTIPLE
|
||
Normally only a single TI TSC2007 touchscreen is used. But if
|
||
there are multiple TSC2007 touchscreens, this setting will enable
|
||
multiple touchscreens with the same driver.
|
||
|
||
CONFIG_INPUT_STMPE811
|
||
Enables support for the STMPE811 driver (Needs CONFIG_INPUT)
|
||
CONFIG_STMPE811_SPI
|
||
Enables support for the SPI interface (not currenly supported)
|
||
CONFIG_STMPE811_I2C
|
||
Enables support for the I2C interface
|
||
CONFIG_STMPE811_MULTIPLE
|
||
Can be defined to support multiple STMPE811 devices on board.
|
||
CONFIG_STMPE811_ACTIVELOW
|
||
Interrupt is generated by an active low signal (or falling edge).
|
||
CONFIG_STMPE811_EDGE
|
||
Interrupt is generated on an edge (vs. on the active level)
|
||
CONFIG_STMPE811_NPOLLWAITERS
|
||
Maximum number of threads that can be waiting on poll() (ignored if
|
||
CONFIG_DISABLE_POLL is set).
|
||
CONFIG_STMPE811_TSC_DISABLE
|
||
Disable driver touchscreen functionality.
|
||
CONFIG_STMPE811_ADC_DISABLE
|
||
Disable driver ADC functionality.
|
||
CONFIG_STMPE811_GPIO_DISABLE
|
||
Disable driver GPIO functionlaity.
|
||
CONFIG_STMPE811_GPIOINT_DISABLE
|
||
Disable driver GPIO interrupt functionality (ignored if GPIO
|
||
functionality is disabled).
|
||
CONFIG_STMPE811_SWAPXY
|
||
Reverse the meaning of X and Y to handle different LCD orientations.
|
||
CONFIG_STMPE811_TEMP_DISABLE
|
||
Disable driver temperature sensor functionality.
|
||
CONFIG_STMPE811_REGDEBUG
|
||
Enabled very low register-level debug output. Requires CONFIG_DEBUG.
|
||
CONFIG_STMPE811_THRESHX and CONFIG_STMPE811_THRESHY
|
||
STMPE811 touchscreen data comes in a a very high rate. New touch positions
|
||
will only be reported when the X or Y data changes by these thresholds.
|
||
This trades reduces data rate for some loss in dragging accuracy. The
|
||
STMPE811 is configure for 12-bit values so the raw ranges are 0-4095. So
|
||
for example, if your display is 320x240, then THRESHX=13 and THRESHY=17
|
||
would correspond to one pixel. Default: 12
|
||
|
||
Analog Devices
|
||
|
||
CONFIG_DAC
|
||
Enables general support for Digital-to-Analog conversion devices.
|
||
CONFIG_ADC
|
||
Enables general support for Analog-to-Digital conversion devices.
|
||
CONFIG_ADC_ADS125X
|
||
Adds support for the TI ADS 125x ADC.
|
||
|
||
ENC28J60 Ethernet Driver Configuration Settings:
|
||
|
||
CONFIG_ENC28J60 - Enabled ENC28J60 support
|
||
CONFIG_ENC28J60_SPIMODE - Controls the SPI mode
|
||
CONFIG_ENC28J60_FREQUENCY - Define to use a different bus frequency
|
||
CONFIG_ENC28J60_NINTERFACES - Specifies the number of physical ENC28J60
|
||
devices that will be supported.
|
||
CONFIG_ENC28J60_STATS - Collect network statistics
|
||
CONFIG_ENC28J60_HALFDUPPLEX - Default is full duplex
|
||
|
||
Networking support via uIP
|
||
|
||
CONFIG_NET - Enable or disable all network features
|
||
CONFIG_NET_NOINTS -- CONFIG_NET_NOINT indicates that uIP not called from
|
||
the interrupt level. If CONFIG_NET_NOINTS is defined, critical sections
|
||
will be managed with semaphores; Otherwise, it assumed that uIP will be
|
||
called from interrupt level handling and critical sections will be
|
||
managed by enabling and disabling interrupts.
|
||
CONFIG_NET_MULTIBUFFER - Traditionally, uIP has used a single buffer
|
||
for all incoming and outgoing traffic. If this configuration is
|
||
selected, then the driver can manage multiple I/O buffers and can,
|
||
for example, be filling one input buffer while sending another
|
||
output buffer. Or, as another example, the driver may support
|
||
queuing of concurrent input/ouput and output transfers for better
|
||
performance.
|
||
CONFIG_NET_IPv6 - Build in support for IPv6
|
||
CONFIG_NSOCKET_DESCRIPTORS - Maximum number of socket descriptors
|
||
per task/thread.
|
||
CONFIG_NET_NACTIVESOCKETS - Maximum number of concurrent socket
|
||
operations (recv, send, etc.). Default: CONFIG_NET_TCP_CONNS+CONFIG_NET_UDP_CONNS
|
||
CONFIG_NET_SOCKOPTS - Enable or disable support for socket options
|
||
|
||
CONFIG_NET_BUFSIZE - uIP buffer size
|
||
CONFIG_NET_TCPURGDATA - Determines if support for TCP urgent data
|
||
notification should be compiled in. Urgent data (out-of-band data)
|
||
is a rarely used TCP feature that is very seldom would be required.
|
||
CONFIG_NET_TCP - TCP support on or off
|
||
CONFIG_NET_TCP_CONNS - Maximum number of TCP connections (all tasks)
|
||
CONFIG_NET_MAX_LISTENPORTS - Maximum number of listening TCP ports (all tasks)
|
||
CONFIG_NET_TCP_READAHEAD_BUFSIZE - Size of TCP read-ahead buffers
|
||
CONFIG_NET_NTCP_READAHEAD_BUFFERS - Number of TCP read-ahead buffers
|
||
(may be zero to disable TCP/IP read-ahead buffering)
|
||
CONFIG_NET_TCP_RECVDELAY - Delay (in deciseconds) after a TCP/IP packet
|
||
is received. This delay may allow catching of additional packets
|
||
when TCP/IP read-ahead is disabled. Default: 0
|
||
CONFIG_NET_TCPBACKLOG - Incoming connections pend in a backlog until
|
||
accept() is called. The size of the backlog is selected when listen()
|
||
is called.
|
||
CONFIG_NET_UDP - UDP support on or off
|
||
CONFIG_NET_UDP_CHECKSUMS - UDP checksums on or off
|
||
CONFIG_NET_UDP_CONNS - The maximum amount of concurrent UDP
|
||
connections
|
||
CONFIG_NET_ICMP - Enable minimal ICMP support. Includes built-in support
|
||
for sending replies to received ECHO (ping) requests.
|
||
CONFIG_NET_ICMP_PING - Provide interfaces to support application level
|
||
support for sending ECHO (ping) requests and associating ECHO
|
||
replies.
|
||
CONFIG_NET_IGMP - Enable IGMPv2 client support.
|
||
CONFIG_PREALLOC_IGMPGROUPS - Pre-allocated IGMP groups are used
|
||
only if needed from interrupt level group created (by the IGMP server).
|
||
Default: 4.
|
||
CONFIG_NET_PINGADDRCONF - Use "ping" packet for setting IP address
|
||
CONFIG_NET_STATISTICS - uIP statistics on or off
|
||
CONFIG_NET_RECEIVE_WINDOW - The size of the advertised receiver's
|
||
window
|
||
CONFIG_NET_ARPTAB_SIZE - The size of the ARP table
|
||
CONFIG_NET_ARP_IPIN - Harvest IP/MAC address mappings from the ARP table
|
||
from incoming IP packets.
|
||
CONFIG_NET_BROADCAST - Incoming UDP broadcast support
|
||
CONFIG_NET_MULTICAST - Outgoing multi-cast address support
|
||
|
||
SLIP Driver. SLIP supports point-to-point IP communications over a serial
|
||
port. The default data link layer for uIP is Ethernet. If CONFIG_NET_SLIP
|
||
is defined in the NuttX configuration file, then SLIP will be supported.
|
||
The basic differences between the SLIP and Ethernet configurations is that
|
||
when SLIP is selected:
|
||
|
||
* The link level header (that comes before the IP header) is omitted.
|
||
* All MAC address processing is suppressed.
|
||
* ARP is disabled.
|
||
|
||
If CONFIG_NET_SLIP is not selected, then Ethernet will be used (there is
|
||
no need to define anything special in the configuration file to use
|
||
Ethernet -- it is the default).
|
||
|
||
CONFIG_NET_SLIP -- Enables building of the SLIP driver. SLIP requires
|
||
at least one IP protocols selected and the following additional
|
||
network settings: CONFIG_NET_NOINTS and CONFIG_NET_MULTIBUFFER.
|
||
CONFIG_NET_BUFSIZE *must* be set to 296. Other optional configuration
|
||
settings that affect the SLIP driver: CONFIG_NET_STATISTICS.
|
||
Default: Ethernet
|
||
|
||
If SLIP is selected, then the following SLIP options are available:
|
||
|
||
CONFIG_CLIP_NINTERFACES -- Selects the number of physical SLIP
|
||
interfaces to support. Default: 1
|
||
CONFIG_SLIP_STACKSIZE -- Select the stack size of the SLIP RX and
|
||
TX tasks. Default: 2048
|
||
CONFIG_SLIP_DEFPRIO - The priority of the SLIP RX and TX tasks.
|
||
Default: 128
|
||
|
||
UIP Network Utilities
|
||
|
||
CONFIG_NET_DHCP_LIGHT - Reduces size of DHCP
|
||
CONFIG_NET_RESOLV_ENTRIES - Number of resolver entries
|
||
CONFIG_NET_RESOLV_MAXRESPONSE - This setting determines the maximum
|
||
size of response message that can be received by the DNS resolver.
|
||
The default is 96 but may need to be larger on enterprise networks
|
||
(perhaps 176).
|
||
|
||
THTTPD
|
||
|
||
CONFIG_THTTPD_PORT - THTTPD Server port number
|
||
CONFIG_THTTPD_IPADDR - Server IP address (no host name)
|
||
CONFIG_THTTPD_SERVER_ADDRESS - SERVER_ADDRESS: response
|
||
CONFIG_THTTPD_SERVER_SOFTWARE - SERVER_SOFTWARE: response
|
||
CONFIG_THTTPD_PATH - Server working directory
|
||
CONFIG_THTTPD_CGI_PATH - Path to CGI executables
|
||
CONFIG_THTTPD_CGI_PATTERN - Only CGI programs matching this
|
||
pattern will be executed. In fact, if this value is not defined
|
||
then no CGI logic will be built.
|
||
CONFIG_THTTPD_CGI_PRIORITY - Provides the priority of CGI child tasks
|
||
CONFIG_THTTPD_CGI_STACKSIZE - Provides the initial stack size of
|
||
CGI child task (will be overridden by the stack size in the NXFLAT
|
||
header)
|
||
CONFIG_THTTPD_CGI_BYTECOUNT - Byte output limit for CGI tasks.
|
||
CONFIG_THTTPD_CGI_TIMELIMIT - How many seconds to allow CGI programs
|
||
to run before killing them.
|
||
CONFIG_THTTPD_CHARSET- The default character set name to use with
|
||
text MIME types.
|
||
CONFIG_THTTPD_IOBUFFERSIZE -
|
||
CONFIG_THTTPD_INDEX_NAMES - A list of index filenames to check. The
|
||
files are searched for in this order.
|
||
CONFIG_AUTH_FILE - The file to use for authentication. If this is
|
||
defined then thttpd checks for this file in the local directory
|
||
before every fetch. If the file exists then authentication is done,
|
||
otherwise the fetch proceeds as usual. If you leave this undefined
|
||
then thttpd will not implement authentication at all and will not
|
||
check for auth files, which saves a bit of CPU time. A typical
|
||
value is ".htpasswd"
|
||
CONFIG_THTTPD_LISTEN_BACKLOG - The listen() backlog queue length.
|
||
CONFIG_THTTPD_LINGER_MSEC - How many milliseconds to leave a connection
|
||
open while doing a lingering close.
|
||
CONFIG_THTTPD_OCCASIONAL_MSEC - How often to run the occasional
|
||
cleanup job.
|
||
CONFIG_THTTPD_IDLE_READ_LIMIT_SEC - How many seconds to allow for
|
||
reading the initial request on a new connection.
|
||
CONFIG_THTTPD_IDLE_SEND_LIMIT_SEC - How many seconds before an
|
||
idle connection gets closed.
|
||
CONFIG_THTTPD_TILDE_MAP1 and CONFIG_THTTPD_TILDE_MAP2 - Tilde mapping.
|
||
Many URLs use ~username to indicate a user's home directory. thttpd
|
||
provides two options for mapping this construct to an actual filename.
|
||
1) Map ~username to <prefix>/username. This is the recommended choice.
|
||
Each user gets a subdirectory in the main web tree, and the tilde
|
||
construct points there. The prefix could be something like "users",
|
||
or it could be empty.
|
||
2) Map ~username to <user's homedir>/<postfix>. The postfix would be
|
||
the name of a subdirectory off of the user's actual home dir,
|
||
something like "public_html".
|
||
You can also leave both options undefined, and thttpd will not do
|
||
anything special about tildes. Enabling both options is an error.
|
||
Typical values, if they're defined, are "users" for
|
||
CONFIG_THTTPD_TILDE_MAP1 and "public_html"forCONFIG_THTTPD_TILDE_MAP2.
|
||
CONFIG_THTTPD_GENERATE_INDICES
|
||
CONFIG_THTTPD_URLPATTERN - If defined, then it will be used to match
|
||
and verify referrers.
|
||
|
||
FTP Server
|
||
|
||
CONFIG_FTPD_VENDORID - The vendor name to use in FTP communications.
|
||
Default: "NuttX"
|
||
CONFIG_FTPD_SERVERID - The server name to use in FTP communications.
|
||
Default: "NuttX FTP Server"
|
||
CONFIG_FTPD_CMDBUFFERSIZE - The maximum size of one command. Default:
|
||
128 bytes.
|
||
CONFIG_FTPD_DATABUFFERSIZE - The size of the I/O buffer for data
|
||
transfers. Default: 512 bytes.
|
||
CONFIG_FTPD_WORKERSTACKSIZE - The stacksize to allocate for each
|
||
FTP daemon worker thread. Default: 2048 bytes.
|
||
|
||
Other required configuration settings: Of course TCP networking support
|
||
is required. But here are a couple that are less obvious:
|
||
|
||
CONFIG_DISABLE_PTHREAD - pthread support is required
|
||
CONFIG_DISABLE_POLL - poll() support is required
|
||
|
||
USB device controller driver
|
||
|
||
CONFIG_USBDEV - Enables USB device support
|
||
CONFIG_USBDEV_COMPOSITE
|
||
Enables USB composite device support
|
||
CONFIG_USBDEV_ISOCHRONOUS - Build in extra support for isochronous
|
||
endpoints
|
||
CONFIG_USBDEV_DUALSPEED -Hardware handles high and full speed
|
||
operation (USB 2.0)
|
||
CONFIG_USBDEV_SELFPOWERED - Will cause USB features to indicate
|
||
that the device is self-powered
|
||
CONFIG_USBDEV_MAXPOWER - Maximum power consumption in mA
|
||
CONFIG_USBDEV_TRACE - Enables USB tracing for debug
|
||
CONFIG_USBDEV_TRACE_NRECORDS - Number of trace entries to remember
|
||
|
||
USB host controller driver
|
||
|
||
CONFIG_USBHOST
|
||
Enables USB host support
|
||
CONFIG_USBHOST_NPREALLOC
|
||
Number of pre-allocated class instances
|
||
CONFIG_USBHOST_BULK_DISABLE
|
||
On some architectures, selecting this setting will reduce driver size
|
||
by disabling bulk endpoint support
|
||
CONFIG_USBHOST_INT_DISABLE
|
||
On some architectures, selecting this setting will reduce driver size
|
||
by disabling interrupt endpoint support
|
||
CONFIG_USBHOST_ISOC_DISABLE
|
||
On some architectures, selecting this setting will reduce driver size
|
||
by disabling isochronous endpoint support
|
||
|
||
USB host HID class driver. Requires CONFIG_USBHOST=y,
|
||
CONFIG_USBHOST_INT_DISABLE=n, CONFIG_NFILE_DESCRIPTORS > 0,
|
||
CONFIG_SCHED_WORKQUEUE=y, and CONFIG_DISABLE_SIGNALS=n.
|
||
|
||
CONFIG_HIDKBD_POLLUSEC
|
||
Device poll rate in microseconds. Default: 100 milliseconds.
|
||
CONFIG_HIDKBD_DEFPRIO
|
||
Priority of the polling thread. Default: 50.
|
||
CONFIG_HIDKBD_STACKSIZE
|
||
Stack size for polling thread. Default: 1024
|
||
CONFIG_HIDKBD_BUFSIZE
|
||
Scancode buffer size. Default: 64.
|
||
CONFIG_HIDKBD_NPOLLWAITERS
|
||
If the poll() method is enabled, this defines the maximum number
|
||
of threads that can be waiting for keyboard events. Default: 2.
|
||
CONFIG_HIDKBD_RAWSCANCODES
|
||
If set to y no conversion will be made on the raw keyboard scan
|
||
codes. Default: ASCII conversion.
|
||
CONFIG_HIDKBD_ALLSCANCODES'
|
||
If set to y all 231 possible scancodes will be converted to
|
||
something. Default: 104 key US keyboard.
|
||
CONFIG_HIDKBD_NODEBOUNCE
|
||
If set to y normal debouncing is disabled. Default:
|
||
Debounce enabled (No repeat keys).
|
||
|
||
USB host mass storage class driver. Requires CONFIG_USBHOST=y,
|
||
CONFIG_USBHOST_BULK_DISABLE=n, CONFIG_NFILE_DESCRIPTORS > 0,
|
||
and CONFIG_SCHED_WORKQUEUE=y
|
||
|
||
USB serial device class driver (Prolific PL2303 Emulation)
|
||
|
||
CONFIG_PL2303
|
||
Enable compilation of the USB serial driver
|
||
CONFIG_PL2303_EPINTIN
|
||
The logical 7-bit address of a hardware endpoint that supports
|
||
interrupt IN operation
|
||
CONFIG_PL2303_EPBULKOUT
|
||
The logical 7-bit address of a hardware endpoint that supports
|
||
bulk OUT operation
|
||
CONFIG_PL2303_EPBULKIN
|
||
The logical 7-bit address of a hardware endpoint that supports
|
||
bulk IN operation
|
||
CONFIG_PL2303_NWRREQS and CONFIG_PL2303_NRDREQS
|
||
The number of write/read requests that can be in flight
|
||
CONFIG_PL2303_VENDORID and CONFIG_PL2303_VENDORSTR
|
||
The vendor ID code/string
|
||
CONFIG_PL2303_PRODUCTID and CONFIG_PL2303_PRODUCTSTR
|
||
The product ID code/string
|
||
CONFIG_PL2303_RXBUFSIZE and CONFIG_PL2303_TXBUFSIZE
|
||
Size of the serial receive/transmit buffers
|
||
|
||
USB serial device class driver (Standard CDC ACM class)
|
||
|
||
CONFIG_CDCACM
|
||
Enable compilation of the USB serial driver
|
||
CONFIG_CDCACM_COMPOSITE
|
||
Configure the CDC serial driver as part of a composite driver
|
||
(only if CONFIG_USBDEV_COMPOSITE is also defined)
|
||
CONFIG_CDCACM_IFNOBASE
|
||
If the CDC driver is part of a composite device, then this may need to
|
||
be defined to offset the CDC/ACM interface numbers so that they are
|
||
unique and contiguous. When used with the Mass Storage driver, the
|
||
correct value for this offset is zero.
|
||
CONFIG_CDCACM_STRBASE
|
||
If the CDC driver is part of a composite device, then this may need to
|
||
be defined to offset the CDC/ACM string numbers so that they are
|
||
unique and contiguous. When used with the Mass Storage driver, the
|
||
correct value for this offset is four (this value actuallly only needs
|
||
to be defined if names are provided for the Notification interface,
|
||
CONFIG_CDCACM_NOTIFSTR, or the data interface, CONFIG_CDCACM_DATAIFSTR).
|
||
CONFIG_CDCACM_EP0MAXPACKET
|
||
Endpoint 0 max packet size. Default 64.
|
||
CONFIG_CDCACM_EPINTIN
|
||
The logical 7-bit address of a hardware endpoint that supports
|
||
interrupt IN operation. Default 2.
|
||
CONFIG_CDCACM_EPINTIN_FSSIZE
|
||
Max package size for the interrupt IN endpoint if full speed mode.
|
||
Default 64.
|
||
CONFIG_CDCACM_EPINTIN_HSSIZE
|
||
Max package size for the interrupt IN endpoint if high speed mode.
|
||
Default 64.
|
||
CONFIG_CDCACM_EPBULKOUT
|
||
The logical 7-bit address of a hardware endpoint that supports
|
||
bulk OUT operation
|
||
CONFIG_CDCACM_EPBULKOUT_FSSIZE
|
||
Max package size for the bulk OUT endpoint if full speed mode.
|
||
Default 64.
|
||
CONFIG_CDCACM_EPBULKOUT_HSSIZE
|
||
Max package size for the bulk OUT endpoint if high speed mode.
|
||
Default 512.
|
||
CONFIG_CDCACM_EPBULKIN
|
||
The logical 7-bit address of a hardware endpoint that supports
|
||
bulk IN operation
|
||
CONFIG_CDCACM_EPBULKIN_FSSIZE
|
||
Max package size for the bulk IN endpoint if full speed mode.
|
||
Default 64.
|
||
CONFIG_CDCACM_EPBULKIN_HSSIZE
|
||
Max package size for the bulk IN endpoint if high speed mode.
|
||
Default 512.
|
||
CONFIG_CDCACM_NWRREQS and CONFIG_CDCACM_NRDREQS
|
||
The number of write/read requests that can be in flight.
|
||
CONFIG_CDCACM_NWRREQS includes write requests used for both the
|
||
interrupt and bulk IN endpoints. Default 4.
|
||
CONFIG_CDCACM_VENDORID and CONFIG_CDCACM_VENDORSTR
|
||
The vendor ID code/string. Default 0x0525 and "NuttX"
|
||
0x0525 is the Netchip vendor and should not be used in any
|
||
products. This default VID was selected for compatibility with
|
||
the Linux CDC ACM default VID.
|
||
CONFIG_CDCACM_PRODUCTID and CONFIG_CDCACM_PRODUCTSTR
|
||
The product ID code/string. Default 0xa4a7 and "CDC/ACM Serial"
|
||
0xa4a7 was selected for compatibility with the Linux CDC ACM
|
||
default PID.
|
||
CONFIG_CDCACM_RXBUFSIZE and CONFIG_CDCACM_TXBUFSIZE
|
||
Size of the serial receive/transmit buffers. Default 256.
|
||
|
||
USB Storage Device Configuration
|
||
|
||
CONFIG_USBMSC
|
||
Enable compilation of the USB storage driver
|
||
CONFIG_USBMSC_COMPOSITE
|
||
Configure the mass storage driver as part of a composite driver
|
||
(only if CONFIG_USBDEV_COMPOSITE is also defined)
|
||
CONFIG_USBMSC_IFNOBASE
|
||
If the CDC driver is part of a composite device, then this may need to
|
||
be defined to offset the mass storage interface number so that it is
|
||
unique and contiguous. When used with the CDC/ACM driver, the
|
||
correct value for this offset is two (because of the two CDC/ACM
|
||
interfaces that will precede it).
|
||
CONFIG_USBMSC_STRBASE
|
||
If the CDC driver is part of a composite device, then this may need to
|
||
be defined to offset the mass storage string numbers so that they are
|
||
unique and contiguous. When used with the CDC/ACM driver, the
|
||
correct value for this offset is four (or perhaps 5 or 6, depending
|
||
on if CONFIG_CDCACM_NOTIFSTR or CONFIG_CDCACM_DATAIFSTR are defined).
|
||
CONFIG_USBMSC_EP0MAXPACKET
|
||
Max packet size for endpoint 0
|
||
CONFIG_USBMSCEPBULKOUT and CONFIG_USBMSC_EPBULKIN
|
||
The logical 7-bit address of a hardware endpoints that support
|
||
bulk OUT and IN operations
|
||
CONFIG_USBMSC_NWRREQS and CONFIG_USBMSC_NRDREQS
|
||
The number of write/read requests that can be in flight
|
||
CONFIG_USBMSC_BULKINREQLEN and CONFIG_USBMSC_BULKOUTREQLEN
|
||
The size of the buffer in each write/read request. This
|
||
value needs to be at least as large as the endpoint
|
||
maxpacket and ideally as large as a block device sector.
|
||
CONFIG_USBMSC_VENDORID and CONFIG_USBMSC_VENDORSTR
|
||
The vendor ID code/string
|
||
CONFIG_USBMSC_PRODUCTID and CONFIG_USBMSC_PRODUCTSTR
|
||
The product ID code/string
|
||
CONFIG_USBMSC_REMOVABLE
|
||
Select if the media is removable
|
||
|
||
USB Composite Device Configuration
|
||
|
||
CONFIG_USBDEV_COMPOSITE
|
||
Enables USB composite device support
|
||
CONFIG_CDCACM_COMPOSITE
|
||
Configure the CDC serial driver as part of a composite driver
|
||
(only if CONFIG_USBDEV_COMPOSITE is also defined)
|
||
CONFIG_USBMSC_COMPOSITE
|
||
Configure the mass storage driver as part of a composite driver
|
||
(only if CONFIG_USBDEV_COMPOSITE is also defined)
|
||
CONFIG_COMPOSITE_IAD
|
||
If one of the members of the composite has multiple interfaces
|
||
(such as CDC/ACM), then an Interface Association Descriptor (IAD)
|
||
will be necessary. Default: IAD will be used automatically if
|
||
needed. It should not be necessary to set this.
|
||
CONFIG_COMPOSITE_EP0MAXPACKET
|
||
Max packet size for endpoint 0
|
||
CONFIG_COMPOSITE_VENDORID and CONFIG_COMPOSITE_VENDORSTR
|
||
The vendor ID code/string
|
||
CONFIG_COMPOSITE_PRODUCTID and CONFIG_COMPOSITE_PRODUCTSTR
|
||
The product ID code/string
|
||
CONFIG_COMPOSITE_SERIALSTR
|
||
Device serial number string
|
||
CONFIG_COMPOSITE_CONFIGSTR
|
||
Configuration string
|
||
CONFIG_COMPOSITE_VERSIONNO
|
||
Interface version number.
|
||
|
||
Graphics related configuration settings
|
||
|
||
CONFIG_NX
|
||
Enables overall support for graphics library and NX
|
||
CONFIG_NX_MULTIUSER
|
||
Configures NX in multi-user mode
|
||
CONFIG_NX_NPLANES
|
||
Some YUV color formats requires support for multiple planes,
|
||
one for each color component. Unless you have such special
|
||
hardware, this value should be undefined or set to 1.
|
||
CONFIG_NX_DISABLE_1BPP, CONFIG_NX_DISABLE_2BPP,
|
||
CONFIG_NX_DISABLE_4BPP, CONFIG_NX_DISABLE_8BPP,
|
||
CONFIG_NX_DISABLE_16BPP, CONFIG_NX_DISABLE_24BPP, and
|
||
CONFIG_NX_DISABLE_32BPP
|
||
NX supports a variety of pixel depths. You can save some
|
||
memory by disabling support for unused color depths.
|
||
CONFIG_NX_PACKEDMSFIRST
|
||
If a pixel depth of less than 8-bits is used, then NX needs
|
||
to know if the pixels pack from the MS to LS or from LS to MS
|
||
CONFIG_NX_LCDDRIVER
|
||
By default, NX builds to use a framebuffer driver (see
|
||
include/nuttx/fb.h). If this option is defined, NX will
|
||
build to use an LCD driver (see include/nuttx/lcd/lcd.h).
|
||
CONFIG_LCD_MAXPOWER - The full-on power setting for an LCD
|
||
device.
|
||
CONFIG_LCD_MAXCONTRAST - The maximum contrast value for an
|
||
LCD device.
|
||
CONFIG_LCD_LANDSCAPE, CONFIG_LCD_PORTRAIT, CONFIG_LCD_RLANDSCAPE,
|
||
and CONFIG_LCD_RPORTRAIT - Some LCD drivers may support
|
||
these options to present the display in landscape, portrait,
|
||
reverse landscape, or reverse portrait orientations. Check
|
||
the README.txt file in each board configuration directory to
|
||
see if any of these are supported by the board LCD logic.
|
||
CONFIG_NX_MOUSE
|
||
Build in support for mouse input.
|
||
CONFIG_NX_KBD
|
||
Build in support of keypad/keyboard input.
|
||
CONFIG_NXTK_BORDERWIDTH
|
||
Specifies with with of the border (in pixels) used with
|
||
framed windows. The default is 4.
|
||
CONFIG_NXTK_BORDERCOLOR1 and CONFIG_NXTK_BORDERCOLOR2
|
||
Specify the colors of the border used with framed windows.
|
||
CONFIG_NXTK_BORDERCOLOR2 is the shadow side color and so
|
||
is normally darker. The default is medium and dark grey,
|
||
respectively
|
||
CONFIG_NXTK_AUTORAISE
|
||
If set, a window will be raised to the top if the mouse position
|
||
is over a visible portion of the window. Default: A mouse
|
||
button must be clicked over a visible portion of the window.
|
||
CONFIG_NXFONTS_CHARBITS
|
||
The number of bits in the character set. Current options are
|
||
only 7 and 8. The default is 7.
|
||
|
||
CONFIG_NXFONT_SANS23X27
|
||
This option enables support for a tiny, 23x27 san serif font
|
||
(font ID FONTID_SANS23X27 == 1).
|
||
CONFIG_NXFONT_SANS22X29
|
||
This option enables support for a small, 22x29 san serif font
|
||
(font ID FONTID_SANS22X29 == 2).
|
||
CONFIG_NXFONT_SANS28X37
|
||
This option enables support for a medium, 28x37 san serif font
|
||
(font ID FONTID_SANS28X37 == 3).
|
||
CONFIG_NXFONT_SANS39X48
|
||
This option enables support for a large, 39x48 san serif font
|
||
(font ID FONTID_SANS39X48 == 4).
|
||
CONFIG_NXFONT_SANS22X29B
|
||
This option enables support for a small, 22x29 san serif bold font
|
||
(font ID FONTID_SANS22X29B == 5).
|
||
CONFIG_NXFONT_SANS28X37B
|
||
This option enables support for a medium, 28x37 san serif bold font
|
||
(font ID FONTID_SANS28X37B == 6).
|
||
CONFIG_NXFONT_SANS40X49B
|
||
This option enables support for a large, 40x49 san serif bold font
|
||
(font ID FONTID_SANS40X49B == 7).
|
||
CONFIG_NXFONT_SERIF22X29
|
||
This option enables support for a small, 22x29 font (with serifs)
|
||
(font ID FONTID_SERIF22X29 == 8).
|
||
CONFIG_NXFONT_SERIF29X37
|
||
This option enables support for a medium, 29x37 font (with serifs)
|
||
(font ID FONTID_SERIF29X37 == 9).
|
||
CONFIG_NXFONT_SERIF38X48
|
||
This option enables support for a large, 38x48 font (with serifs)
|
||
(font ID FONTID_SERIF38X48 == 10).
|
||
CONFIG_NXFONT_SERIF22X28B
|
||
This option enables support for a small, 27x38 bold font (with serifs)
|
||
(font ID FONTID_SERIF22X28B == 11).
|
||
CONFIG_NXFONT_SERIF27X38B
|
||
This option enables support for a medium, 27x38 bold font (with serifs)
|
||
(font ID FONTID_SERIF27X38B == 12).
|
||
CONFIG_NXFONT_SERIF38X49B
|
||
This option enables support for a large, 38x49 bold font (with serifs)
|
||
(font ID FONTID_SERIF38X49B == 13).
|
||
|
||
NX Multi-user only options:
|
||
|
||
CONFIG_NX_BLOCKING
|
||
Open the client message queues in blocking mode. In this case,
|
||
nx_eventhandler() will never return.
|
||
CONFIG_NX_MXSERVERMSGS and CONFIG_NX_MXCLIENTMSGS
|
||
Specifies the maximum number of messages that can fit in
|
||
the message queues. No additional resources are allocated, but
|
||
this can be set to prevent flooding of the client or server with
|
||
too many messages (CONFIG_PREALLOC_MQ_MSGS controls how many
|
||
messages are pre-allocated).
|
||
|
||
Stack and heap information
|
||
|
||
CONFIG_BOOT_RUNFROMFLASH - Some configurations support XIP
|
||
operation from FLASH but must copy initialized .data sections to RAM.
|
||
CONFIG_BOOT_COPYTORAM - Some configurations boot in FLASH
|
||
but copy themselves entirely into RAM for better performance.
|
||
CONFIG_ARCH_RAMFUNCS - Other configurations may copy just some functions
|
||
into RAM, either for better performance or for errata workarounds.
|
||
CONFIG_STACK_ALIGNMENT - Set if the your application has specific
|
||
stack alignment requirements (may not be supported
|
||
in all architectures).
|
||
CONFIG_IDLETHREAD_STACKSIZE - The size of the initial stack.
|
||
This is the thread that (1) performs the inital boot of the system up
|
||
to the point where user_start() is spawned, and (2) there after is the
|
||
IDLE thread that executes only when there is no other thread ready to
|
||
run.
|
||
CONFIG_USERMAIN_STACKSIZE - The size of the stack to allocate
|
||
for the main user thread that begins at the user_start() entry point.
|
||
CONFIG_PTHREAD_STACK_MIN - Minimum pthread stack size
|
||
CONFIG_PTHREAD_STACK_DEFAULT - Default pthread stack size
|
||
|
||
Supported Boards
|
||
^^^^^^^^^^^^^^^^
|
||
|
||
configs/amber
|
||
This is placeholder for the SoC Robotics Amber Web Server that is based
|
||
on the Atmel AVR ATMega128 MCU. There is not much there yet and what is
|
||
there is untested due to tool-related issues.
|
||
|
||
configs/avr32dev1
|
||
This is a port of NuttX to the Atmel AVR32DEV1 board. That board is
|
||
based on the Atmel AT32UC3B0256 MCU and uses a specially patched
|
||
version of the GNU toolchain: The patches provide support for the
|
||
AVR32 family. That patched GNU toolchain is available only from the
|
||
Atmel website. STATUS: This port is functional but very basic. There
|
||
are configurations for NSH and the OS test.
|
||
|
||
configs/c5471evm
|
||
This is a port to the Spectrum Digital C5471 evaluation board. The
|
||
TMS320C5471 is a dual core processor from TI with an ARM7TDMI general
|
||
purpose processor and a c54 DSP. It is also known as TMS320DA180 or just DA180.
|
||
NuttX runs on the ARM core and is built with a GNU arm-nuttx-elf toolchain*.
|
||
This port is complete and verified.
|
||
|
||
configs/cloudctrl
|
||
Darcy's CloudController board. This is a small network relay development
|
||
board. Based on the Shenzhou IV development board design. It is based on
|
||
the STM32F107VC MCU.
|
||
|
||
configs/compal_e88 and compal_e99
|
||
These directories contain the board support for compal e88 and e99 phones.
|
||
These ports are based on patches contributed by Denis Carikli for both the
|
||
compal e99 and e88. The patches were made by Alan Carvalho de Assis and
|
||
Denis Carikli using the Stefan Richter's Osmocom-bb patches.
|
||
|
||
configs/demo9s12ne64
|
||
Freescale DMO9S12NE64 board based on the MC9S12NE64 hcs12 cpu. This
|
||
port uses the m9s12x GCC toolchain. STATUS: (Still) under development; it
|
||
is code complete but has not yet been verified.
|
||
|
||
configs/ea3131
|
||
Embedded Artists EA3131 Development board. This board is based on the
|
||
an NXP LPC3131 MCU. This OS is built with the arm-nuttx-elf toolchain*.
|
||
STATUS: This port is complete and mature.
|
||
|
||
configs/ea3152
|
||
Embedded Artists EA3152 Development board. This board is based on the
|
||
an NXP LPC3152 MCU. This OS is built with the arm-nuttx-elf toolchain*.
|
||
STATUS: This port is has not be exercised well, but since it is
|
||
a simple derivative of the ea3131, it should be fully functional.
|
||
|
||
configs/eagle100
|
||
Micromint Eagle-100 Development board. This board is based on the
|
||
an ARM Cortex-M3 MCU, the Luminary LM3S6918. This OS is built with the
|
||
arm-nuttx-elf toolchain*. STATUS: This port is complete and mature.
|
||
|
||
configs/ekk-lm3s9b96
|
||
TI/Stellaris EKK-LM3S9B96 board. This board is based on the
|
||
an EKK-LM3S9B96 which is a Cortex-M3.
|
||
|
||
configs/ez80f0910200kitg
|
||
ez80Acclaim! Microcontroller. This port use the Zilog ez80f0910200kitg
|
||
development kit, eZ80F091 part, and the Zilog ZDS-II Windows command line
|
||
tools. The development environment is Cygwin under WinXP.
|
||
|
||
configs/ez80f0910200zco
|
||
ez80Acclaim! Microcontroller. This port use the Zilog ez80f0910200zco
|
||
development kit, eZ80F091 part, and the Zilog ZDS-II Windows command line
|
||
tools. The development environment is Cygwin under WinXP.
|
||
|
||
configs/fire-stm32v2
|
||
A configuration for the M3 Wildfire STM32 board. This board is based on the
|
||
STM32F103VET6 chip. See http://firestm32.taobao.com . Version 2 and 3 of
|
||
the boards are supported but only version 2 has been tested.
|
||
|
||
configs/hymini-stm32v
|
||
A configuration for the HY-Mini STM32v board. This board is based on the
|
||
STM32F103VCT chip.
|
||
|
||
configs/kwikstik-k40.
|
||
Kinetis K40 Cortex-M4 MCU. This port uses the FreeScale KwikStik-K40
|
||
development board.
|
||
|
||
configs/lincoln60
|
||
NuttX port to the Micromint Lincoln 60 board.
|
||
|
||
configs/lm3s6432-s2e
|
||
Stellaris RDK-S2E Reference Design Kit and the MDL-S2E Ethernet to
|
||
Serial module.
|
||
|
||
configs/lm3s6965-ek
|
||
Stellaris LM3S6965 Evaluation Kit. This board is based on the
|
||
an ARM Cortex-M3 MCU, the Luminary/TI LM3S6965. This OS is built with the
|
||
arm-nuttx-elf toolchain*. STATUS: This port is complete and mature.
|
||
|
||
configs/lm3s8962-ek
|
||
Stellaris LMS38962 Evaluation Kit.
|
||
|
||
configs/lm4f120-launchpad
|
||
This is the port of NuttX to the Stellaris LM4F120 LaunchPad. The
|
||
Stellaris<69> LM4F120 LaunchPad Evaluation Board is a low-cost evaluation
|
||
platform for ARM<52> Cortex<65>-M4F-based microcontrollers from Texas\
|
||
Instruments.
|
||
|
||
configs/lpcxpresso-lpc1768
|
||
Embedded Artists base board with NXP LPCExpresso LPC1768. This board
|
||
is based on the NXP LPC1768. The Code Red toolchain is used by default.
|
||
STATUS: Under development.
|
||
|
||
configs/lpc4330-xplorer
|
||
NuttX port to the LPC4330-Xplorer board from NGX Technologies featuring
|
||
the NXP LPC4330FET100 MCU
|
||
|
||
configs/m68322evb
|
||
This is a work in progress for the venerable m68322evb board from
|
||
Motorola. This OS is also built with the arm-nuttx-elf toolchain*. STATUS:
|
||
This port was never completed.
|
||
|
||
configs/mbed
|
||
The configurations in this directory support the mbed board (http://mbed.org)
|
||
that features the NXP LPC1768 microcontroller. This OS is also built
|
||
with the arm-nuttx-elf toolchain*. STATUS: Contributed.
|
||
|
||
configs/mikroe-stm32f4
|
||
This is the port of NuttX to the MikroElektronika Mikromedia for STM32F4
|
||
development board. Contributed by Ken Petit.
|
||
|
||
configs/mcu123-lpc214x
|
||
This port is for the NXP LPC2148 as provided on the mcu123.com
|
||
lpc214x development board. This OS is also built with the arm-nuttx-elf
|
||
toolchain*. The port supports serial, timer0, spi, and usb.
|
||
|
||
configs/micropendous3
|
||
This is a port to the Opendous Micropendous 3 board. This board may
|
||
be populated with either an AVR AT90USB646, 647, 1286, or 1287 MCU.
|
||
Support is configured for the AT90USB647.
|
||
|
||
configs/mirtoo
|
||
This is the port to the DTX1-4000L "Mirtoo" module. This module uses MicroChip
|
||
PIC32MX250F128D. See http://www.dimitech.com/ for further information.
|
||
|
||
configs/mx1ads
|
||
This is a port to the Motorola MX1ADS development board. That board
|
||
is based on the Freescale i.MX1 processor. The i.MX1 is an ARM920T.
|
||
STATUS: This port is nearly code complete but was never fully
|
||
integrated due to tool-related issues.
|
||
|
||
configs/ne64badge
|
||
Future Electronics Group NE64 /PoE Badge board based on the
|
||
MC9S12NE64 hcs12 cpu. This port uses the m9s12x GCC toolchain.
|
||
STATUS: Under development. The port is code-complete but has
|
||
not yet been fully tested.
|
||
|
||
configs/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
|
||
|
||
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
|
||
|
||
NuttX operates on the ARM9EJS of this dual core processor.
|
||
STATUS: This port is code complete, verified, and included in the
|
||
NuttX 0.2.1 release.
|
||
|
||
configs/nucleus2g
|
||
This port uses the Nucleus 2G board (with Babel CAN board). This board
|
||
features an NXP LPC1768 processor. See the 2G website (http://www.2g-eng.com/)
|
||
for more information about the Nucleus 2G.
|
||
|
||
configs/nutiny-nuc120
|
||
This is the port of NuttX to the NuvoTon NuTiny-SDK-NUC120 board. This
|
||
board has the NUC120LE3AN chip with a built-in NuLink debugger.
|
||
|
||
configs/olimex-lpc1766stk
|
||
This port uses the Olimex LPC1766-STK board and a GNU GCC toolchain* under
|
||
Linux or Cygwin. STATUS: Complete and mature.
|
||
|
||
configs/olimex-lpc2378
|
||
This port uses the Olimex-lpc2378 board and a GNU arm-nuttx-elf toolchain* under
|
||
Linux or Cygwin. STATUS: ostest and NSH configurations available.
|
||
This port for the NXP LPC2378 was contributed by Rommel Marcelo.
|
||
|
||
configs/olimex-stm32-p107
|
||
This port uses the Olimex STM32-P107 board (STM32F107VC) and a GNU arm-nuttx-elf
|
||
toolchain* under Linux or Cygwin. See the https://www.olimex.com/dev/stm32-p107.html
|
||
for further information. Contributed by Max Holtzberg. STATUS: Configurations
|
||
for the basic OS test and NSH are available and verified.
|
||
|
||
configs/olimex-strp711
|
||
This port uses the Olimex STR-P711 board and a GNU arm-nuttx-elf toolchain* under
|
||
Linux or Cygwin. See the http://www.olimex.com/dev/str-p711.html" for
|
||
further information. STATUS: Configurations for the basic OS test and NSH
|
||
are complete and verified.
|
||
|
||
configs/pcblogic-pic32mx
|
||
This is the port of NuttX to the PIC32MX board from PCB Logic Design Co.
|
||
This board features the MicroChip PIC32MX460F512L.
|
||
The board is a very simple -- little more than a carrier for the PIC32
|
||
MCU plus voltage regulation, debug interface, and an OTG connector.
|
||
STATUS: Code complete but testing has been stalled due to tool related problems
|
||
(PICkit 2 does not work with the PIC32).
|
||
|
||
configs/p112
|
||
The P112 is notable because it was the first of the hobbyist single board
|
||
computers to reach the production stage. The P112 hobbyist computers
|
||
were relatively widespread and inspired other hobbyist centered home brew
|
||
computing projects such as N8VEM home brew computing project. The P112
|
||
project still maintains many devoted enthusiasts and has an online
|
||
repository of software and other information.
|
||
|
||
The P112 computer originated as a commercial product of "D-X Designs Pty
|
||
Ltd" of Australia. They describe the computer as "The P112 is a stand-alone
|
||
8-bit CPU board. Typically running CP/M (tm) or a similar operating system,
|
||
it provides a Z80182 (Z-80 upgrade) CPU with up to 1MB of memory, serial,
|
||
parallel and diskette IO, and realtime clock, in a 3.5-inch drive form factor.
|
||
Powered solely from 5V, it draws 150mA (nominal: not including disk drives)
|
||
with a 16MHz CPU clock. Clock speeds up to 24.576MHz are possible."
|
||
|
||
The P112 board was last available new in 1996 by Dave Brooks. In late 2004
|
||
on the Usenet Newsgroup comp.os.cpm, talk about making another run of P112
|
||
boards was discussed. David Griffith decided to produce additional P112 kits
|
||
with Dave Brooks blessing and the assistance of others. In addition Terry
|
||
Gulczynski makes additional P112 derivative hobbyist home brew computers.
|
||
Hal Bower was very active in the mid 1990's on the P112 project and ported
|
||
the "Banked/Portable BIOS".
|
||
|
||
Dave Brooks was successfully funded through Kickstarter for and another
|
||
run of P112 boards in November of 2012.
|
||
|
||
configs/pic32-starterkit
|
||
This directory contains the port of NuttX to the Microchip PIC32 Ethernet
|
||
Starter Kit (DM320004) with the Multimedia Expansion Board (MEB, DM320005).
|
||
See www.microchip.com for further information.
|
||
|
||
configs/pic32mx7mmb
|
||
This directory will (eventually) contain the port of NuttX to the
|
||
Mikroelektronika PIC32MX7 Multimedia Board (MMB). See
|
||
http://www.mikroe.com/ for further information.
|
||
|
||
configs/pirelli_dpl10
|
||
This directory contains the board support for Pirelli "Discus" DP-L10 phones.
|
||
It is a variant of the compal_e88 config with the small changes for the
|
||
differences in the board.
|
||
|
||
configs/pjrc-8051
|
||
8051 Microcontroller. This port uses the PJRC 87C52 development system
|
||
and the SDCC toolchain. This port is not quite ready for prime time.
|
||
|
||
configs/qemu-i486
|
||
Port of NuttX to QEMU in i486 mode. This port will also run on real i486
|
||
hardwared (Google the Bifferboard).
|
||
|
||
configs/rgmp
|
||
RGMP stands for RTOS and GPOS on Multi-Processor. RGMP is a project for
|
||
running GPOS and RTOS simultaneously on multi-processor platforms. You can
|
||
port your favorite RTOS to RGMP together with an unmodified Linux to form a
|
||
hybrid operating system. This makes your application able to use both RTOS
|
||
and GPOS features.
|
||
|
||
See http://rgmp.sourceforge.net/wiki/index.php/Main_Page for further information
|
||
about RGMP.
|
||
|
||
configs/sam3u-ek
|
||
The port of NuttX to the Atmel SAM3U-EK development board.
|
||
|
||
configs/sam4l-xplained
|
||
The port of NuttX to the Atmel SAM4L-Xplained development board.
|
||
|
||
configs/sim
|
||
A user-mode port of NuttX to the x86 Linux platform is available.
|
||
The purpose of this port is primarily to support OS feature development.
|
||
This port does not support interrupts or a real timer (and hence no
|
||
round robin scheduler) Otherwise, it is complete.
|
||
|
||
configs/shenzhou
|
||
This is the port of NuttX to the Shenzhou development board from
|
||
www.armjishu.com. This board features the STMicro STM32F107VCT MCU.
|
||
|
||
configs/skp16c26
|
||
Renesas M16C processor on the Renesas SKP16C26 StarterKit. This port
|
||
uses the GNU m32c toolchain. STATUS: The port is complete but untested
|
||
due to issues with compiler internal errors.
|
||
|
||
configs/stm3210e-eval
|
||
STMicro STM3210E-EVAL development board based on the STMicro STM32F103ZET6
|
||
microcontroller (ARM Cortex-M3). This port uses the GNU Cortex-M3
|
||
toolchain.
|
||
|
||
configs/stm3220g-eval
|
||
STMicro STM3220G-EVAL development board based on the STMicro STM32F407IG
|
||
microcontroller (ARM Cortex-M3).
|
||
|
||
configs/stm3240g-eval
|
||
STMicro STM3240G-EVAL development board based on the STMicro STM32F103ZET6
|
||
microcontroller (ARM Cortex-M4 with FPU). This port uses a GNU Cortex-M4
|
||
toolchain (such as CodeSourcery).
|
||
|
||
configs/stm32f100rc_generic
|
||
STMicro STM32F100RC generic board based on STM32F100RC high-density value line
|
||
chip. This "generic" configuration is not very usable out-of-box, but can be
|
||
used as a starting point to creating new configs with similar STM32
|
||
high-density value line chips.
|
||
|
||
configs/stm32f4discovery
|
||
STMicro STM32F4-Discovery board based on the STMIcro STM32F407VGT6 MCU.
|
||
|
||
configs/sure-pic32mx
|
||
The "Advanced USB Storage Demo Board," Model DB-DP11215, from Sure
|
||
Electronics (http://www.sureelectronics.net/). This board features
|
||
the MicroChip PIC32MX440F512H. See also
|
||
http://www.sureelectronics.net/goods.php?id=1168 for further
|
||
information about the Sure DB-DP11215 board.
|
||
|
||
configs/teensy
|
||
This is the port of NuttX to the PJRC Teensy++ 2.0 board. This board is
|
||
developed by http://pjrc.com/teensy/. The Teensy++ 2.0 is based
|
||
on an Atmel AT90USB1286 MCU.
|
||
|
||
configs/twr-k60n512
|
||
Kinetis K60 Cortex-M4 MCU. This port uses the FreeScale TWR-K60N512
|
||
development board.
|
||
|
||
configs/ubw32
|
||
|
||
This is the port to the Sparkfun UBW32 board. This port uses the original v2.4
|
||
board which is based on the MicroChip PIC32MX460F512L. See
|
||
http://www.sparkfun.com/products/8971. This older version has been replaced
|
||
with this board http://www.sparkfun.com/products/9713. See also
|
||
http://www.schmalzhaus.com/UBW32/.
|
||
|
||
configs/us7032evb1
|
||
This is a port of the Hitachi SH-1 on the Hitachi SH-1/US7032EVB1 board.
|
||
STATUS: Work has just began on this port.
|
||
|
||
configs/vsn
|
||
ISOTEL NetClamps VSN V1.2 ready2go sensor network platform based on the
|
||
STMicro STM32F103RET6. Contributed by Uros Platise. See
|
||
http://isotel.eu/NetClamps/
|
||
|
||
configs/xtrs
|
||
TRS80 Model 3. This port uses a vintage computer based on the Z80.
|
||
An emulator for this computer is available to run TRS80 programs on a
|
||
linux platform (http://www.tim-mann.org/xtrs.html).
|
||
|
||
configs/z16f2800100zcog
|
||
z16f Microcontroller. This port use the Zilog z16f2800100zcog
|
||
development kit and the Zilog ZDS-II Windows command line tools. The
|
||
development environment is Cygwin under WinXP.
|
||
|
||
configs/z80sim
|
||
z80 Microcontroller. This port uses a Z80 instruction set simulator.
|
||
That simulator can be found in the NuttX GIT at
|
||
http://sourceforge.net/p/nuttx/git/ci/master/tree/misc/sims/z80sim.
|
||
This port also uses the SDCC toolchain (http://sdcc.sourceforge.net/")
|
||
(verified with version 2.6.0).
|
||
|
||
configs/z8encore000zco
|
||
z8Encore! Microcontroller. This port use the Zilog z8encore000zco
|
||
development kit, Z8F6403 part, and the Zilog ZDS-II Windows command line
|
||
tools. The development environment is Cygwin under WinXP.
|
||
|
||
configs/z8f64200100kit
|
||
z8Encore! Microcontroller. This port use the Zilog z8f64200100kit
|
||
development kit, Z8F6423 part, and the Zilog ZDS-II Windows command line
|
||
tools. The development environment is Cygwin under WinXP.
|
||
|
||
configs/zp214xpa
|
||
This port is for the NXP LPC2148 as provided on the The0.net
|
||
ZPA213X/4XPA development board. Includes support for the
|
||
UG-2864AMBAG01 OLED also from The0.net
|
||
|
||
configs/zkit-arm-1769
|
||
Zilogic System's ARM development Kit, ZKIT-ARM-1769. This board is based
|
||
on the NXP LPC1769. The Nuttx Buildroot toolchain is used by default.
|
||
|
||
Configuring NuttX
|
||
^^^^^^^^^^^^^^^^^
|
||
|
||
Configuring NuttX requires only copying
|
||
|
||
configs/<board-name>/<config-dir>/Make.def to ${TOPDIR}/Make.defs
|
||
configs/<board-name>/<config-dir>/setenv.sh to ${TOPDIR}/setenv.sh
|
||
configs/<board-name>/<config-dir>/defconfig to ${TOPDIR}/.config
|
||
|
||
And if configs/<board-name>/<config-dir>/appconfig exists in the board
|
||
configuration directory:
|
||
|
||
Copy configs/<board-name>/<config-dir>/appconfig to <app-dir>/.config
|
||
echo "APPS_LOC=\"<app-dir>\"" >> "${TOPDIR}/.config"
|
||
|
||
tools/configure.sh
|
||
There is a script that automates these steps. The following steps will
|
||
accomplish the same configuration:
|
||
|
||
cd tools
|
||
./configure.sh <board-name>/<config-dir>
|
||
|
||
There is an alternative Windows batch file that can be used in the
|
||
windows native enironment like:
|
||
|
||
cd ${TOPDIR}\tools
|
||
configure.bat <board-name>\<config-dir>
|
||
|
||
See tools/README.txt for more information about these scripts.
|
||
|
||
And if configs/<board-name>/<config-dir>/appconfig exists and your
|
||
application directory is not in the standard loction (../apps), then
|
||
you should also specify the location of the application directory on the
|
||
command line like:
|
||
|
||
cd tools
|
||
./configure.sh -a <app-dir> <board-name>/<config-dir>
|
||
|
||
Building Symbol Tables
|
||
^^^^^^^^^^^^^^^^^^^^^^
|
||
|
||
Symbol tables are needed at several of the binfmt interfaces in order to bind
|
||
a module to the base code. These symbol tables can be tricky to create and
|
||
will probably have to be tailored for any specific application, balancing
|
||
the number of symbols and the size of the symbol table against the symbols
|
||
required by the applications.
|
||
|
||
The top-level System.map file is one good source of symbol information
|
||
(which, or course, was just generated from the top-level nuttx file
|
||
using the GNU 'nm' tool).
|
||
|
||
There are also common-separated value (CSV) values in the source try that
|
||
provide information about symbols. In particular:
|
||
|
||
nuttx/syscall/syscall.csv - Describes the NuttX RTOS interface, and
|
||
nuttx/lib/lib.csv - Describes the NuttX C library interface.
|
||
|
||
There is a tool at nuttx/tools/mksymtab that will use these CSV files as
|
||
input to generate a generic symbol table. See nuttx/tools/README.txt for
|
||
more information about using the mksymtab tool.
|