forked from Archive/PX4-Autopilot
1929 lines
79 KiB
Plaintext
1929 lines
79 KiB
Plaintext
examples
|
|
^^^^^^^^
|
|
|
|
appconfig and CONFIG_APPS
|
|
|
|
The examples directory contains several sample applications that
|
|
can be linked with NuttX. The specific example is selected in the
|
|
configs/<board-name>/appconfig file via the CONFIGURED_APPS setting.
|
|
This setting provides the path to the directory containing the
|
|
application Makefile (this path is a relative to the apps/ top-
|
|
level directory). For example,
|
|
|
|
CONFIGURE_APPS += examples/ostest
|
|
|
|
Selects the examples/ostest example.
|
|
|
|
Built-In functions
|
|
|
|
Some of the examples may be built as "built-in" functions that
|
|
can be executed at run time (rather than as NuttX "main" programs).
|
|
These "built-in" examples can be also be executed from the NuttShell
|
|
(NSH) command line. In order to configure these built-in NSH
|
|
functions, you have to set up the following:
|
|
|
|
- CONFIG_NSH_BUILTIN_APPS - Enable support for external registered,
|
|
"named" applications that can be executed from the NSH
|
|
command line (see apps/README.txt for more information).
|
|
- CONFIG_EXAMPLES_XYZ_BUILTIN -- Build the XYZ example as a "built-in"
|
|
that can be executed from the NSH command line (where XYZ is
|
|
the specific example. See the following for examples that
|
|
support this option).
|
|
|
|
examples/adc
|
|
^^^^^^^^^^^^
|
|
|
|
A mindlessly simple test of an ADC devices. It simply reads from the
|
|
ADC device and dumps the data to the console forever.
|
|
|
|
This test depends on these specific ADC/NSH configurations settings (your
|
|
specific ADC settings might require additional settings).
|
|
|
|
CONFIG_ADC - Enabled ADC support
|
|
CONFIG_NSH_BUILTIN_APPS - Build the ADC test as an NSH built-in function.
|
|
Default: Built as a standalone problem
|
|
|
|
Specific configuration options for this example include:
|
|
|
|
CONFIG_EXAMPLES_ADC_DEVPATH - The default path to the ADC device. Default: /dev/adc0
|
|
CONFIG_EXAMPLES_ADC_NSAMPLES - If CONFIG_NSH_BUILTIN_APPS
|
|
is defined, then the number of samples is provided on the command line
|
|
and this value is ignored. Otherwise, this number of samples is
|
|
collected and the program terminates. Default: Samples are collected
|
|
indefinitely.
|
|
CONFIG_EXAMPLES_ADC_GROUPSIZE - The number of samples to read at once.
|
|
Default: 4
|
|
|
|
examples/buttons
|
|
^^^^^^^^^^^^^^^^
|
|
|
|
This is a simple configuration that may be used to test the board-
|
|
specific button interfaces. Configuration options:
|
|
|
|
CONFIG_ARCH_BUTTONS - Must be defined for button support
|
|
CONFIG_EXAMPLES_BUTTONS_MIN - Lowest button number (MIN=0)
|
|
CONFIG_EXAMPLES_BUTTONS_MAX - Highest button number (MAX=7)
|
|
|
|
CONFIG_ARCH_IRQBUTTONS - Must be defined for interrupting button support
|
|
CONFIG_EXAMPLES_IRQBUTTONS_MIN - Lowest interrupting button number (MIN=0)
|
|
CONFIG_EXAMPLES_IRQBUTTONS_MAX - Highest interrupting button number (MAX=7)
|
|
|
|
Name strings for buttons:
|
|
|
|
CONFIG_EXAMPLES_BUTTONS_NAME0, CONFIG_EXAMPLES_BUTTONS_NAME1,
|
|
CONFIG_EXAMPLES_BUTTONS_NAME2, CONFIG_EXAMPLES_BUTTONS_NAME3,
|
|
CONFIG_EXAMPLES_BUTTONS_NAME4, CONFIG_EXAMPLES_BUTTONS_NAME5,
|
|
CONFIG_EXAMPLES_BUTTONS_NAME6, CONFIG_EXAMPLES_BUTTONS_NAME7,
|
|
|
|
Additional architecture-/board- specific configuration settings may also
|
|
be required.
|
|
|
|
NOTE: This test exercises internal button driver interfaces. As such, it
|
|
relies on internal OS interfaces that are not normally available to a
|
|
user-space program. As a result, this example cannot be used if a
|
|
NuttX is built as a protected, supervisor kernel (CONFIG_NUTTX_KERNEL).
|
|
|
|
examples/can
|
|
^^^^^^^^^^^^
|
|
|
|
If the CAN device is configured in loopback mode, then this example can
|
|
be used to test the CAN device in loop back mode. It simple sinces a
|
|
sequence of CAN messages and verifies that those messages are returned
|
|
exactly as sent.
|
|
|
|
This test depends on these specific CAN/NSH configurations settings (your
|
|
specific CAN settings might require additional settings).
|
|
|
|
CONFIG_CAN - Enables CAN support.
|
|
CONFIG_CAN_LOOPBACK - A CAN driver may or may not support a loopback
|
|
mode for testing. The STM32 CAN driver does support loopback mode.
|
|
CONFIG_NSH_BUILTIN_APPS - Build the CAN test as an NSH built-in function.
|
|
Default: Built as a standalone problem
|
|
|
|
Specific configuration options for this example include:
|
|
|
|
CONFIG_EXAMPLES_CAN_DEVPATH - The path to the CAN device. Default: /dev/can0
|
|
CONFIG_EXAMPLES_CAN_NMSGS - If CONFIG_NSH_BUILTIN_APPS
|
|
is defined, then the number of loops is provided on the command line
|
|
and this value is ignored. Otherwise, this number of CAN message is
|
|
collected and the program terminates. Default: If built as an NSH
|
|
built-in, the default is 32. Otherwise messages are sent and received
|
|
indefinitely.
|
|
|
|
The default behavior assumes loopback mode. Messages are sent, then read
|
|
and verified. The behavior can be altered for other kinds of testing where
|
|
the test only sends or received (but does not verify) can messages.
|
|
|
|
CONFIG_EXAMPLES_CAN_READONLY - Only receive messages
|
|
CONFIG_EXAMPLES_CAN_WRITEONLY - Only send messages
|
|
|
|
examples/cdcacm
|
|
^^^^^^^^^^^^^^^
|
|
|
|
This very simple example shows how a USB CDC/ACM serial can be dynamically
|
|
connected and disconnected from a host. This example can only be used as
|
|
an NSH built-int command. If built-in, then two new NSH commands will be
|
|
supported:
|
|
|
|
1. sercon - Connect the CDC/ACM serial device
|
|
2. serdis - Disconnect the CDC/ACM serial device
|
|
|
|
Configuration prequisites (not complete):
|
|
|
|
CONFIG_USBDEV=y : USB device support must be enabled
|
|
CONFIG_CDCACM=y : The CDC/ACM driver must be built
|
|
CONFIG_NSH_BUILTIN_APPS : NSH built-in application support must be enabled
|
|
|
|
Configuration options specific to this example:
|
|
|
|
CONFIG_EXAMPLES_CDCACM_DEVMINOR : The minor number of the CDC/ACM device.
|
|
: i.e., the 'x' in /dev/ttyACMx
|
|
|
|
If CONFIG_USBDEV_TRACE is enabled (or CONFIG_DEBUG and CONFIG_DEBUG_USB, or
|
|
CONFIG_USBDEV_TRACE), then the example code will also initialize the USB trace
|
|
output. The amount of trace output can be controlled using:
|
|
|
|
CONFIG_EXAMPLES_CDCACM_TRACEINIT
|
|
Show initialization events
|
|
CONFIG_EXAMPLES_CDCACM_TRACECLASS
|
|
Show class driver events
|
|
CONFIG_EXAMPLES_CDCACM_TRACETRANSFERS
|
|
Show data transfer events
|
|
CONFIG_EXAMPLES_CDCACM_TRACECONTROLLER
|
|
Show controller events
|
|
CONFIG_EXAMPLES_CDCACM_TRACEINTERRUPTS
|
|
Show interrupt-related events.
|
|
|
|
Note: This example is only enables or disable USB CDC/ACM via the NSH
|
|
'sercon' and 'serdis' command. It will enable and disable tracing per
|
|
the settings before enabling and after disabling the CDC/ACM device. It
|
|
will not, however, monitor buffered trace data in the interim. If
|
|
CONFIG_USBDEV_TRACE is defined (and the debug options are not), other
|
|
application logic will need to monitor the buffered trace data.
|
|
|
|
examples/composite
|
|
^^^^^^^^^^^^^^^^^^
|
|
|
|
This example test a USB composite device. The only supported composite is
|
|
CDC/ACM serial with a USB mass storage device.
|
|
|
|
Required overall configuration:
|
|
|
|
CONFIG_USBDEV=y - USB device support
|
|
CONFIG_USBDEV_COMPOSITE=y - USB composite device support
|
|
CONFIG_COMPOSITE_IAD=y - Interface associate descriptor needed
|
|
|
|
CONFIG_CDCACM=y - USB CDC/ACM serial device support
|
|
CONFIG_CDCACM_COMPOSITE=y - USB CDC/ACM serial composite device support
|
|
CONFIG_CDCACM_IFNOBASE=0 - CDC/ACM interfaces start with number 0
|
|
CONFIG_CDCACM_STRBASE=4 - Base of string numbers (not really needed)
|
|
CONFIG_CDCACM_EPINTIN=1 - Endpoint numbers must be unique
|
|
CONFIG_CDCACM_EPBULKIN=2
|
|
CONFIG_CDCACM_EPBULKOUT=3
|
|
|
|
CONFIG_USBMSC - USB mass storage device support
|
|
CONFIG_USBMSC_COMPOSITE=y - USB mass storage composite device support
|
|
CONFIG_USBMSC_IFNOBASE=2 - USB mass storage interfaces start with number 2
|
|
CONFIG_USBMSC_STRBASE=4 - Base of string numbers (needed)
|
|
CONFIG_USBMSC_EPBULKOUT=4 - Endpoint numbers must be unique
|
|
CONFIG_USBMSC_EPBULKIN=5
|
|
|
|
CONFIG_NSH_BUILTIN_APPS
|
|
This example can be built as two NSH "built-in" commands if this option
|
|
is selected: 'conn' will connect the USB composite device; 'msdis'
|
|
will disconnect the USB composite device.
|
|
|
|
Configuration options unique to this example:
|
|
|
|
CONFIG_EXAMPLES_COMPOSITE_DEBUGMM
|
|
Enables some debug tests to check for memory usage and memory leaks.
|
|
|
|
CONFIG_EXAMPLES_COMPOSITE_NLUNS
|
|
Defines the number of logical units (LUNs) exported by the USB storage
|
|
driver. Each LUN corresponds to one exported block driver (or partition
|
|
of a block driver). May be 1, 2, or 3. Default is 1.
|
|
CONFIG_EXAMPLES_COMPOSITE_DEVMINOR1
|
|
The minor device number of the block driver for the first LUN. For
|
|
example, N in /dev/mmcsdN. Used for registering the block driver. Default
|
|
is zero.
|
|
CONFIG_EXAMPLES_COMPOSITE_DEVPATH1
|
|
The full path to the registered block driver. Default is "/dev/mmcsd0"
|
|
CONFIG_EXAMPLES_COMPOSITE_DEVMINOR2 and CONFIG_EXAMPLES_COMPOSITE_DEVPATH2
|
|
Similar parameters that would have to be provided if CONFIG_EXAMPLES_COMPOSITE_NLUNS
|
|
is 2 or 3. No defaults.
|
|
CONFIG_EXAMPLES_COMPOSITE_DEVMINOR3 and CONFIG_EXAMPLES_COMPOSITE_DEVPATH2
|
|
Similar parameters that would have to be provided if CONFIG_EXAMPLES_COMPOSITE_NLUNS
|
|
is 3. No defaults.
|
|
CONFIG_EXAMPLES_COMPOSITE_BUFLEN. Default 256.
|
|
|
|
CONFIG_EXAMPLES_COMPOSITE_TTYUSB - The minor number of the USB serial device.
|
|
Default is zero (corresponding to /dev/ttyUSB0 or /dev/ttyACM0). Default is zero.
|
|
CCONFIG_EXAMPLES_COMPOSITE_SERDEV - The string corresponding to
|
|
CONFIG_EXAMPLES_COMPOSITE_TTYUSB. The default is "/dev/ttyUSB0" (for the PL2303
|
|
emulation) or "/dev/ttyACM0" (for the CDC/ACM serial device).
|
|
CONFIG_EXAMPLES_COMPOSITE_BUFSIZE - The size of the serial I/O buffer in
|
|
bytes. Default 256 bytes.
|
|
|
|
If CONFIG_USBDEV_TRACE is enabled (or CONFIG_DEBUG and CONFIG_DEBUG_USB), then
|
|
the example code will also manage the USB trace output. The amount of trace output
|
|
can be controlled using:
|
|
|
|
CONFIG_EXAMPLES_COMPOSITE_TRACEINIT
|
|
Show initialization events
|
|
CONFIG_EXAMPLES_COMPOSITE_TRACECLASS
|
|
Show class driver events
|
|
CONFIG_EXAMPLES_COMPOSITE_TRACETRANSFERS
|
|
Show data transfer events
|
|
CONFIG_EXAMPLES_COMPOSITE_TRACECONTROLLER
|
|
Show controller events
|
|
CONFIG_EXAMPLES_COMPOSITE_TRACEINTERRUPTS
|
|
Show interrupt-related events.
|
|
|
|
examples/cxxtest
|
|
^^^^^^^^^^^^^^^^
|
|
|
|
This is a test of the C++ standard library. At present a port of the uClibc++
|
|
C++ library is available. Due to licensinging issues, the uClibc++ C++ library
|
|
is not included in the NuttX source tree by default, but must be installed
|
|
(see misc/uClibc++/README.txt for installation).
|
|
|
|
The NuttX setting that are required include:
|
|
|
|
CONFIG_HAVE_CXX=y
|
|
CONFIG_HAVE_CXXINITIALIZE=y
|
|
CONFIG_UCLIBCXX=y
|
|
|
|
Additional uClibc++ settings may be required in your build environment.
|
|
|
|
The uClibc++ test includes simple test of:
|
|
|
|
- iostreams,
|
|
- STL,
|
|
- RTTI, and
|
|
- Exceptions
|
|
|
|
examples/dhcpd
|
|
^^^^^^^^^^^^^^
|
|
|
|
This examples builds a tiny DCHP server for the target system.
|
|
|
|
NOTE: For test purposes, this example can be built as a
|
|
host-based DHCPD server. This can be built as follows:
|
|
|
|
cd examples/dhcpd
|
|
make -f Makefile.host TOPDIR=<nuttx-directory>
|
|
|
|
NuttX configuration settings:
|
|
|
|
CONFIG_NET=y - Of course
|
|
CONFIG_NSOCKET_DESCRIPTORS - And, of course, you must allocate some
|
|
socket descriptors.
|
|
CONFIG_NET_UDP=y - UDP support is required for DHCP
|
|
(as well as various other UDP-related
|
|
configuration settings)
|
|
CONFIG_NET_BROADCAST=y - UDP broadcast support is needed.
|
|
|
|
CONFIG_EXAMPLES_DHCPD_NOMAC - (May be defined to use software assigned MAC)
|
|
CONFIG_EXAMPLES_DHCPD_IPADDR - Target IP address
|
|
CONFIG_EXAMPLES_DHCPD_DRIPADDR - Default router IP addess
|
|
CONFIG_EXAMPLES_DHCPD_NETMASK - Network mask
|
|
|
|
See also CONFIG_NETUTILS_DHCPD_* settings described elsewhere
|
|
and used in netutils/dhcpd/dhcpd.c. These settings are required
|
|
to described the behavior of the daemon.
|
|
|
|
Applications using this example will need to provide an appconfig
|
|
file in the configuration driver with instruction to build applications
|
|
like:
|
|
|
|
CONFIGURED_APPS += uiplib
|
|
|
|
examples/discover
|
|
^^^^^^^^^^^^^^^^^
|
|
|
|
This example exercises netutils/discover utility. This example initializes
|
|
and starts the UDP discover daemon. This daemon is useful for discovering
|
|
devices in local networks, especially with DHCP configured devices. It
|
|
listens for UDP broadcasts which also can include a device class so that
|
|
groups of devices can be discovered. It is also possible to address all
|
|
classes with a kind of broadcast discover.
|
|
|
|
This example will automatically be built as an NSH built-in if
|
|
CONFIG_NSH_BUILTIN_APPS is selected. Otherwise, it will be a standalone
|
|
program with entry point "discover_main".
|
|
|
|
NuttX configuration settings:
|
|
|
|
CONFIG_EXAMPLES_DISCOVER_DHCPC - DHCP Client
|
|
CONFIG_EXAMPLES_DISCOVER_NOMAC - Use canned MAC address
|
|
CONFIG_EXAMPLES_DISCOVER_IPADDR - Target IP address
|
|
CONFIG_EXAMPLES_DISCOVER_DRIPADDR - Router IP address
|
|
CONFIG_EXAMPLES_DISCOVER_NETMASK - Network Mask
|
|
|
|
examples/elf
|
|
^^^^^^^^^^^^
|
|
|
|
This example builds a small ELF loader test case. This includes several
|
|
test programs under examples/elf tests. These tests are build using
|
|
the relocatable ELF format and installed in a ROMFS file system. At run time,
|
|
each program in the ROMFS file system is executed. Requires CONFIG_ELF.
|
|
Other configuration options:
|
|
|
|
CONFIG_EXAMPLES_ELF_DEVMINOR - The minor device number of the ROMFS block
|
|
driver. For example, the N in /dev/ramN. Used for registering the RAM
|
|
block driver that will hold the ROMFS file system containing the ELF
|
|
executables to be tested. Default: 0
|
|
|
|
CONFIG_EXAMPLES_ELF_DEVPATH - The path to the ROMFS block driver device. This
|
|
must match EXAMPLES_ELF_DEVMINOR. Used for registering the RAM block driver
|
|
that will hold the ROMFS file system containing the ELF executables to be
|
|
tested. Default: "/dev/ram0"
|
|
|
|
NOTES:
|
|
|
|
1. CFLAGS should be provided in CELFFLAGS. RAM and FLASH memory regions
|
|
may require long allcs. For ARM, this might be:
|
|
|
|
CELFFLAGS = $(CFLAGS) -mlong-calls
|
|
|
|
Similarly for C++ flags which must be provided in CXXELFFLAGS.
|
|
|
|
2. Your top-level nuttx/Make.defs file must also include an approproate definition,
|
|
LDELFFLAGS, to generate a relocatable ELF object. With GNU LD, this should
|
|
include '-r' and '-e main' (or _main on some platforms).
|
|
|
|
LDELFFLAGS = -r -e main
|
|
|
|
If you use GCC to link, you make also need to include '-nostdlib' or
|
|
'-nostartfiles' and '-nodefaultlibs'.
|
|
|
|
3. This example also requires genromfs. genromfs can be build as part of the
|
|
nuttx toolchain. Or can built from the genromfs sources that can be found
|
|
at misc/tools/genromfs-0.5.2.tar.gz. In any event, the PATH variable must
|
|
include the path to the genromfs executable.
|
|
|
|
4. ELF size: The ELF files in this example are, be default, quite large
|
|
because they include a lot of "build garbage". You can greatly reduce the
|
|
size of the ELF binaries are using the 'objcopy --strip-unneeded' command to
|
|
remove un-necessary information from the ELF files.
|
|
|
|
5. Simulator. You cannot use this example with the the NuttX simulator on
|
|
Cygwin. That is because the Cygwin GCC does not generate ELF file but
|
|
rather some Windows-native binary format.
|
|
|
|
If you really want to do this, you can create a NuttX x86 buildroot toolchain
|
|
and use that be build the ELF executables for the ROMFS file system.
|
|
|
|
6. Linker scripts. You might also want to use a linker scripts to combine
|
|
sections better. An example linker script is at nuttx/binfmt/libelf/gnu-elf.ld.
|
|
That example might have to be tuned for your particular linker output to
|
|
position additional sections correctly. The GNU LD LDELFFLAGS then might
|
|
be:
|
|
|
|
LDELFFLAGS = -r -e main -T$(TOPDIR)/binfmt/libelf/gnu-elf.ld
|
|
|
|
examples/ftpc
|
|
^^^^^^^^^^^^^
|
|
|
|
This is a simple FTP client shell used to exercise the capabilities
|
|
of the FTPC library (apps/netutils/ftpc). This example is configured
|
|
to that it will only work as a "built-in" program that can be run from
|
|
NSH when CONFIG_NSH_BUILTIN_APPS is defined.
|
|
|
|
From NSH, the startup command sequence is as follows. This is only
|
|
an example, your configration could have different mass storage devices,
|
|
mount paths, and FTP directories:
|
|
|
|
nsh> mount -t vfat /dev/mmcsd0 /tmp # Mount the SD card at /tmp
|
|
nsh> cd /tmp # cd into the /tmp directory
|
|
nsh> ftpc xx.xx.xx.xx[:pp] # Start the FTP client
|
|
nfc> login <name> <password> # Log into the FTP server
|
|
nfc> help # See a list of FTP commands
|
|
|
|
where xx.xx.xx.xx is the IP address of the FTP server and pp is an
|
|
optional port number.
|
|
|
|
NOTE: By default, FTPC uses readline to get data from stdin. So your
|
|
appconfig file must have the following build path:
|
|
|
|
CONFIGURED_APPS += system/readline
|
|
|
|
NOTE: If you use the ftpc task over a telnet NSH connection, then you
|
|
should set the following configuration item:
|
|
|
|
CONFIG_EXAMPLES_FTPC_FGETS=y
|
|
|
|
By default, the FTPC client will use readline() to get characters from
|
|
the console. Readline includes and command-line editor and echos
|
|
characters received in stdin back through stdout. Neither of these
|
|
behaviors are desire-able if Telnet is used.
|
|
|
|
You may also want to define the following in your configuration file.
|
|
Otherwise, you will have not feeback about what is going on:
|
|
|
|
CONFIG_DEBUG=y
|
|
CONFIG_DEBUG_VERBOSE=y
|
|
CONFIG_DEBUG_FTPC=y
|
|
|
|
examples/ftpd
|
|
^^^^^^^^^^^^^^
|
|
|
|
This example exercises the FTPD daemon at apps/netuils/ftpd. Below are
|
|
configurations specific to the FTPD example (the FTPD daemon itself may
|
|
require other configuration options as well).
|
|
|
|
CONFIG_EXAMPLES_FTPD_PRIO - Priority of the FTP daemon.
|
|
Default: SCHED_PRIORITY_DEFAULT
|
|
CONFIG_EXAMPLES_FTPD_STACKSIZE - Stack size allocated for the
|
|
FTP daemon. Default: 2048
|
|
CONFIG_EXAMPLES_FTPD_NONETINIT - Define to suppress configuration of the
|
|
network by apps/examples/ftpd. You would need to suppress network
|
|
configuration if the network is configuration prior to running the
|
|
example.
|
|
|
|
NSH always initializes the network so if CONFIG_NSH_BUILTIN_APPS is
|
|
defined, so is CONFIG_EXAMPLES_FTPD_NONETINIT (se it does not explicitly
|
|
need to be defined in that case):
|
|
|
|
CONFIG_NSH_BUILTIN_APPS - Build the FTPD daemon example test as an
|
|
NSH built-in function. By default the FTPD daemon will be built
|
|
as a standalone application.
|
|
|
|
If CONFIG_EXAMPLES_FTPD_NONETINIT is not defined, then the following may
|
|
be specified to customized the network configuration:
|
|
|
|
CONFIG_EXAMPLES_FTPD_NOMAC - If the hardware has no MAC address of its
|
|
own, define this =y to provide a bogus address for testing.
|
|
CONFIG_EXAMPLES_FTPD_IPADDR - The target IP address. Default 10.0.0.2
|
|
CONFIG_EXAMPLES_FTPD_DRIPADDR - The default router address. Default
|
|
10.0.0.1
|
|
CONFIG_EXAMPLES_FTPD_NETMASK - The network mask. Default: 255.255.255.0
|
|
|
|
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
|
|
|
|
Other FTPD configuration options thay may be of interest:
|
|
|
|
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:
|
|
512 bytes.
|
|
CONFIG_FTPD_DATABUFFERSIZE - The size of the I/O buffer for data
|
|
transfers. Default: 2048 bytes.
|
|
CONFIG_FTPD_WORKERSTACKSIZE - The stacksize to allocate for each
|
|
FTP daemon worker thread. Default: 2048 bytes.
|
|
|
|
The appconfig file (apps/.config) should include:
|
|
|
|
CONFIGURED_APPS += examples/ftpd
|
|
CONFIGURED_APPS += netutils/uiplib
|
|
CONFIGURED_APPS += netutils/ftpd
|
|
|
|
examples/hello
|
|
^^^^^^^^^^^^^^
|
|
|
|
This is the mandatory, "Hello, World!!" example. It is little more
|
|
than examples/null with a single printf statement. Really useful only
|
|
for bringing up new NuttX architectures.
|
|
|
|
* CONFIG_NSH_BUILTIN_APPS
|
|
Build the "Hello, World" example as an NSH built-in application.
|
|
|
|
examples/helloxx
|
|
^^^^^^^^^^^^^^^^
|
|
|
|
This is C++ version of the "Hello, World!!" example. It is intended
|
|
only to verify that the C++ compiler is functional, that basic C++
|
|
library suupport is available, and that class are instantiated
|
|
correctly.
|
|
|
|
NuttX configuration prerequisites:
|
|
|
|
CONFIG_HAVE_CXX -- Enable C++ Support
|
|
|
|
Optional NuttX configuration settings:
|
|
|
|
CONFIG_HAVE_CXXINITIALIZE -- Enable support for static constructors
|
|
(may not be available on all platforms).
|
|
|
|
NuttX configuration settings specific to this examp;le:
|
|
|
|
CONFIG_EXAMPLES_HELLOXX_BUILTIN -- Build the helloxx example as a
|
|
"built-in" that can be executed from the NSH command line.
|
|
CONFIG_EXAMPLES_HELLOXX_NOSTACKCONST - Set if the system does not
|
|
support construction of objects on the stack.
|
|
|
|
Also needed:
|
|
|
|
CONFIG_HAVE_CXX=y
|
|
|
|
And you may have to tinker with the following to get libxx to compile
|
|
properly:
|
|
|
|
CONFIG_CXX_NEWLONG=y or =n
|
|
|
|
The argument of the 'new' operators should take a type of size_t. But size_t
|
|
has an unknown underlying. In the nuttx sys/types.h header file, size_t
|
|
is typed as uint32_t (which is determined by architecture-specific logic).
|
|
But the C++ compiler may believe that size_t is of a different type resulting
|
|
in compilation errors in the operator. Using the underlying integer type
|
|
Instead of size_t seems to resolve the compilation issues.
|
|
|
|
examples/hidkbd
|
|
^^^^^^^^^^^^^^^^
|
|
|
|
This is a simple test to debug/verify the USB host HID keyboard class
|
|
driver.
|
|
|
|
CONFIG_EXAMPLES_HIDKBD_DEFPRIO - Priority of "waiter" thread. Default:
|
|
50
|
|
CONFIG_EXAMPLES_HIDKBD_STACKSIZE - Stacksize of "waiter" thread. Default
|
|
1024
|
|
CONFIG_EXAMPLES_HIDKBD_DEVNAME - Name of keyboard device to be used.
|
|
Default: "/dev/kbda"
|
|
CONFIG_EXAMPLES_HIDKBD_ENCODED - Decode special key press events in the
|
|
user buffer. In this case, the example coded will use the interfaces
|
|
defined in include/nuttx/input/kbd_codec.h to decode the returned
|
|
keyboard data. These special keys include such things as up/down
|
|
arrows, home and end keys, etc. If this not defined, only 7-bit print-
|
|
able and control ASCII characters will be provided to the user.
|
|
Requires CONFIG_HIDKBD_ENCODED && CONFIG_LIB_KBDCODEC
|
|
|
|
endif
|
|
examples/igmp
|
|
^^^^^^^^^^^^^
|
|
|
|
This is a trivial test of the NuttX IGMP capability. It present it
|
|
does not do much of value -- Much more is needed in order to verify
|
|
the IGMP features!
|
|
|
|
* CONFIG_EXAMPLES_IGMP_NOMAC
|
|
Set if the hardware has no MAC address; one will be assigned
|
|
* CONFIG_EXAMPLES_IGMP_IPADDR
|
|
Target board IP address
|
|
* CONFIG_EXAMPLES_IGMP_DRIPADDR
|
|
Default router address
|
|
* CONFIG_EXAMPLES_IGMP_NETMASK
|
|
Network mask
|
|
* CONFIG_EXAMPLES_IGMP_GRPADDR
|
|
Multicast group address
|
|
|
|
Applications using this example will need to provide an appconfig
|
|
file in the configuration driver with instruction to build applications
|
|
like:
|
|
|
|
CONFIGURED_APPS += uiplib
|
|
|
|
examples/json
|
|
^^^^^^^^^^^^^
|
|
|
|
This example exercises the cJSON implementation at apps/netutils/json.
|
|
This example contains logic taken from the cJSON project:
|
|
|
|
http://sourceforge.net/projects/cjson/
|
|
|
|
The example corresponds to SVN revision r42 (with lots of changes for
|
|
NuttX coding standards). As of r42, the SVN repository was last updated
|
|
on 2011-10-10 so I presume that the code is stable and there is no risk
|
|
of maintaining duplicate logic in the NuttX repository.
|
|
|
|
examples/keypadtest
|
|
^^^^^^^^^^^^^^^^^^^
|
|
|
|
This is a generic keypad test example. It is similar to the USB hidkbd
|
|
example, but makes no assumptions about the underlying keyboard interface.
|
|
It uses the interfaces of include/nuttx/input/keypad.h.
|
|
|
|
CONFIG_EXAMPLES_KEYPADTEST - Selects the keypadtest example (only need
|
|
if the mconf/Kconfig tool is used.
|
|
|
|
CONFIG_EXAMPLES_KEYPAD_DEVNAME - The name of the keypad device that will
|
|
be opened in order to perform the keypad test. Default: "/dev/keypad"
|
|
|
|
examples/lcdrw
|
|
^^^^^^^^^^^^^^
|
|
|
|
This example may be used to verify if you can or cannot read data
|
|
correctly from an LCD interface. At present, this supports only LCDs
|
|
with RGB565 color format.
|
|
|
|
* CONFIG_EXAMPLES_LDCRW_DEVNO
|
|
LCD device number. Default: 0
|
|
* CONFIG_EXAMPLES_LDCRW_XRES
|
|
LCD X resolution. Default: 240
|
|
* CONFIG_EXAMPLES_LDCRW_YRES
|
|
LCD Y resolution. Default: 320
|
|
|
|
NOTE: This test exercises internal lcd driver interfaces. As such, it
|
|
relies on internal OS interfaces that are not normally available to a
|
|
user-space program. As a result, this example cannot be used if a
|
|
NuttX is built as a protected, supervisor kernel (CONFIG_NUTTX_KERNEL).
|
|
|
|
examples/mm
|
|
^^^^^^^^^^^
|
|
|
|
This is a simplified version of the "built-in" memory manager test of
|
|
mm/mm_test.c. It is simplified because it does not have access to the
|
|
internals of the memory manager as does mm/mm_test.c, but it has the
|
|
advantage that it runs in the actual NuttX tasking environment (the
|
|
mm/mm_test.c only runs in a PC simulation environment).
|
|
|
|
examples/modbus
|
|
^^^^^^^^^^^^^^^
|
|
|
|
This is a port of the FreeModbus Linux demo. It derives from the
|
|
demos/LINUX directory of the FreeModBus version 1.5.0 (June 6, 2010)
|
|
that can be downloaded in its entirety from http://developer.berlios.de/project/showfiles.php?group_id=6120.
|
|
|
|
CONFIG_EXAMPLES_MODBUS_PORT, Default 0 (for /dev/ttyS0)
|
|
CONFIG_EXAMPLES_MODBUS_BAUD, Default B38400
|
|
CONFIG_EXAMPLES_MODBUS_PARITY, Default MB_PAR_EVEN
|
|
|
|
CONFIG_EXAMPLES_MODBUS_REG_INPUT_START, Default 1000
|
|
CONFIG_EXAMPLES_MODBUS_REG_INPUT_NREGS, Default 4
|
|
CONFIG_EXAMPLES_MODBUS_REG_HOLDING_START, Default 2000
|
|
CONFIG_EXAMPLES_MODBUS_REG_HOLDING_NREGS, Default 130
|
|
|
|
The FreeModBus library resides at apps/modbus. See apps/modbus/README.txt
|
|
for additional configuration information.
|
|
|
|
examples/mount
|
|
^^^^^^^^^^^^^^
|
|
|
|
This contains a simple test of filesystem mountpoints.
|
|
|
|
* CONFIG_EXAMPLES_MOUNT_DEVNAME
|
|
The name of the user-provided block device to mount.
|
|
If CONFIG_EXAMPLES_MOUNT_DEVNAME is not provided, then
|
|
a RAM disk will be configured.
|
|
|
|
* CONFIG_EXAMPLES_MOUNT_NSECTORS
|
|
The number of "sectors" in the RAM disk used when
|
|
CONFIG_EXAMPLES_MOUNT_DEVNAME is not defined.
|
|
|
|
* CONFIG_EXAMPLES_MOUNT_SECTORSIZE
|
|
The size of each sectors in the RAM disk used when
|
|
CONFIG_EXAMPLES_MOUNT_DEVNAME is not defined.
|
|
|
|
* CONFIG_EXAMPLES_MOUNT_RAMDEVNO
|
|
The RAM device minor number used to mount the RAM disk used
|
|
when CONFIG_EXAMPLES_MOUNT_DEVNAME is not defined. The
|
|
default is zero (meaning that "/dev/ram0" will be used).
|
|
|
|
examples/netttest
|
|
^^^^^^^^^^^^^^^^^
|
|
|
|
This is a simple network test for verifying client- and server-
|
|
functionality in a TCP/IP connection.
|
|
|
|
Applications using this example will need to provide an appconfig
|
|
file in the configuration driver with instruction to build applications
|
|
like:
|
|
|
|
CONFIGURED_APPS += uiplib
|
|
|
|
examples/nsh
|
|
^^^^^^^^^^^^
|
|
|
|
This directory provides an example of how to configure and use
|
|
the NuttShell (NSH) application. NSH is a simple shell
|
|
application. NSH is described in its own README located at
|
|
apps/nshlib/README.txt
|
|
|
|
Applications using this example will need to provide an appconfig
|
|
file in the configuration driver with instruction to build applications
|
|
like:
|
|
|
|
CONFIGURED_APPS += nshlib
|
|
|
|
NOTE: If the NSH serial console is used, then following is also
|
|
required to build the readline() library:
|
|
|
|
CONFIGURED_APPS += system/readline
|
|
|
|
And if networking is included:
|
|
|
|
CONFIGURED_APPS += uiplib
|
|
CONFIGURED_APPS += dhcpc
|
|
CONFIGURED_APPS += resolv
|
|
CONFIGURED_APPS += tftp
|
|
CONFIGURED_APPS += webclient
|
|
|
|
If the Telnet console is enabled, then the appconfig file (apps/.config)
|
|
should also include:
|
|
|
|
CONFIGURED_APPS += netutils/telnetd
|
|
|
|
Also if the Telnet console is enabled, make sure that you have the
|
|
following set in the NuttX configuration file or else the performance
|
|
will be very bad (because there will be only one character per TCP
|
|
transfer):
|
|
|
|
CONFIG_STDIO_BUFFER_SIZE - Some value >= 64
|
|
CONFIG_STDIO_LINEBUFFER=y
|
|
|
|
examples/nx
|
|
^^^^^^^^^^^
|
|
|
|
This directory contains a simple test of a subset of the NX APIs
|
|
defined in include/nuttx/nx/nx.h. The following configuration options
|
|
can be selected:
|
|
|
|
CONFIG_EXAMPLES_NX_BUILTIN -- Build the NX example as a "built-in"
|
|
that can be executed from the NSH command line
|
|
CONFIG_EXAMPLES_NX_VPLANE -- The plane to select from the frame-
|
|
buffer driver for use in the test. Default: 0
|
|
CONFIG_EXAMPLES_NX_DEVNO - The LCD device to select from the LCD
|
|
driver for use in the test: Default: 0
|
|
CONFIG_EXAMPLES_NX_BGCOLOR -- The color of the background. Default depends on
|
|
CONFIG_EXAMPLES_NX_BPP.
|
|
CONFIG_EXAMPLES_NX_COLOR1 -- The color of window 1. Default depends on
|
|
CONFIG_EXAMPLES_NX_BPP.
|
|
CONFIG_EXAMPLES_NX_COLOR2 -- The color of window 2. Default depends on
|
|
CONFIG_EXAMPLES_NX_BPP.
|
|
CONFIG_EXAMPLES_NX_TBCOLOR -- The color of the toolbar. Default depends on
|
|
CONFIG_EXAMPLES_NX_BPP.
|
|
CONFIG_EXAMPLES_NX_FONTID - Selects the font (see font ID numbers in
|
|
include/nuttx/nx/nxfonts.h)
|
|
CONFIG_EXAMPLES_NX_FONTCOLOR -- The color of the fonts. Default depends on
|
|
CONFIG_EXAMPLES_NX_BPP.
|
|
CONFIG_EXAMPLES_NX_BPP -- Pixels per pixel to use. Valid options
|
|
include 2, 4, 8, 16, 24, and 32. Default is 32.
|
|
CONFIG_EXAMPLES_NX_RAWWINDOWS -- Use raw windows; Default is to
|
|
use pretty, framed NXTK windows with toolbars.
|
|
CONFIG_EXAMPLES_NX_EXTERNINIT - The driver for the graphics device on
|
|
this platform requires some unusual initialization. This is the
|
|
for, for example, SPI LCD/OLED devices. If this configuration is
|
|
selected, then the platform code must provide an LCD initialization
|
|
function with a prototype like:
|
|
|
|
#ifdef CONFIG_NX_LCDDRIVER
|
|
FAR struct lcd_dev_s *up_nxdrvinit(unsigned int devno);
|
|
#else
|
|
FAR struct fb_vtable_s *up_nxdrvinit(unsigned int devno);
|
|
#endif
|
|
|
|
This test can be performed with either the single-user version of
|
|
NX or with the multiple user version of NX selected with CONFIG_NX_MULTIUSER.
|
|
If CONFIG_NX_MULTIUSER is defined, then the following configuration
|
|
options also apply:
|
|
|
|
CONFIG_EXAMPLES_NX_STACKSIZE -- The stacksize to use when creating
|
|
the NX server. Default 2048
|
|
CONFIG_EXAMPLES_NX_CLIENTPRIO -- The client priority. Default: 100
|
|
CONFIG_EXAMPLES_NX_SERVERPRIO -- The server priority. Default: 120
|
|
CONFIG_EXAMPLES_NX_LISTENERPRIO -- The priority of the event listener
|
|
thread. Default 80.
|
|
CONFIG_EXAMPLES_NX_NOTIFYSIGNO -- The signal number to use with
|
|
nx_eventnotify(). Default: 4
|
|
|
|
If CONFIG_NX_MULTIUSER is defined, then the example also expects the
|
|
following settings and will generate an error if they are not as expected:
|
|
|
|
CONFIG_DISABLE_MQUEUE=n
|
|
CONFIG_DISABLE_SIGNALS=n
|
|
CONFIG_DISABLE_PTHREAD=n
|
|
CONFIG_NX_BLOCKING=y
|
|
|
|
examples/nxconsole
|
|
^^^^^^^^^^^^^^^^^^
|
|
|
|
This directory contains yet another version of the NuttShell (NSH). This
|
|
version uses the NX console device defined in include/nuttx/nx/nxconsole.h
|
|
for output. the result is that the NSH input still come from the standard
|
|
console input (probably a serial console). But the text output will go to
|
|
an NX winbdow. Prerequisite configuration settings for this test include:
|
|
|
|
CONFIG_NX=y -- NX graphics must be enabled
|
|
CONFIG_NXCONSOLE=y -- The NX console driver must be built
|
|
CONFIG_NX_MULTIUSER=y -- NX multi-user support must be enabled.
|
|
CONFIG_DISABLE_MQUEUE=n -- Message queue support must be available.
|
|
CONFIG_DISABLE_SIGNALS=n -- Signals are needed
|
|
CONFIG_DISABLE_PTHREAD=n -- pthreads are needed
|
|
CONFIG_NX_BLOCKING=y -- pthread APIs must be blocking
|
|
CONFIG_NSH_CONSOLE=y -- NSH must be configured to use a console.
|
|
|
|
The following configuration options can be selected to customize the
|
|
test:
|
|
|
|
CONFIG_EXAMPLES_NXCON_VPLANE -- The plane to select from the frame-
|
|
buffer driver for use in the test. Default: 0
|
|
CONFIG_EXAMPLES_NXCON_DEVNO - The LCD device to select from the LCD
|
|
driver for use in the test: Default: 0
|
|
CONFIG_EXAMPLES_NXCON_BGCOLOR -- The color of the background. Default
|
|
Default is a darker royal blue.
|
|
CONFIG_EXAMPLES_NXCON_WCOLOR -- The color of the window. Default is a light
|
|
slate blue.
|
|
CONFIG_EXAMPLES_NXCON_FONTID -- Selects the font (see font ID numbers in
|
|
include/nuttx/nx/nxfonts.h)
|
|
CONFIG_EXAMPLES_NXCON_FONTCOLOR -- The color of the fonts. Default is
|
|
black.
|
|
CONFIG_EXAMPLES_NXCON_BPP -- Pixels per pixel to use. Valid options
|
|
include 2, 4, 8, 16, 24, and 32. Default is 32.
|
|
CONFIG_EXAMPLES_NXCON_TOOLBAR_HEIGHT -- The height of the toolbar.
|
|
Default: 16
|
|
CONFIG_EXAMPLES_NXCON_TBCOLOR -- The color of the toolbar. Default is
|
|
a medium grey.
|
|
CONFIG_EXAMPLES_NXCON_EXTERNINIT - The driver for the graphics device on
|
|
this platform requires some unusual initialization. This is the
|
|
for, for example, SPI LCD/OLED devices. If this configuration is
|
|
selected, then the platform code must provide an LCD initialization
|
|
function with a prototype like:
|
|
|
|
#ifdef CONFIG_NX_LCDDRIVER
|
|
FAR struct lcd_dev_s *up_nxdrvinit(unsigned int devno);
|
|
#else
|
|
FAR struct fb_vtable_s *up_nxdrvinit(unsigned int devno);
|
|
#endif
|
|
|
|
CONFIG_EXAMPLES_NXCON_MINOR -- The NX console device minor number.
|
|
Default is 0 corresponding to /dev/nxcon0
|
|
CONFIG_EXAMPLES_NXCON_DEVNAME -- The quoated, full path to the
|
|
NX console device corresponding to CONFIG_EXAMPLES_NXCON_MINOR.
|
|
Default: "/dev/nxcon0"
|
|
CONFIG_EXAMPLES_NXCONSOLE_PRIO - Priority of the NxConsole task.
|
|
Default: SCHED_PRIORITY_DEFAULT
|
|
CONFIG_EXAMPLES_NXCONSOLE_STACKSIZE - Stack size allocated for the
|
|
NxConsole task. Default: 2048
|
|
|
|
The following configuration settings determine how to set up the NX
|
|
server (CONFIG_NX_MULTIUSER):
|
|
|
|
CONFIG_EXAMPLES_NXCON_STACKSIZE -- The stacksize to use when creating
|
|
the NX server. Default 2048
|
|
CONFIG_EXAMPLES_NXCON_CLIENTPRIO -- The client priority. Default: 100
|
|
CONFIG_EXAMPLES_NXCON_SERVERPRIO -- The server priority. Default: 120
|
|
CONFIG_EXAMPLES_NXCON_LISTENERPRIO -- The priority of the event listener
|
|
thread. Default 80.
|
|
CONFIG_EXAMPLES_NXCON_NOTIFYSIGNO -- The signal number to use with
|
|
nx_eventnotify(). Default: 4
|
|
|
|
examples/nxffs
|
|
^^^^^^^^^^^^^^
|
|
|
|
This is a test of the NuttX NXFFS FLASH file system. This is an NXFFS
|
|
stress test and beats on the file system very hard. It should only
|
|
be used in a simulation environment! Putting this NXFFS test on real
|
|
hardware will most likely destroy your FLASH. You have been warned.
|
|
|
|
examples/nxflat
|
|
^^^^^^^^^^^^^^^
|
|
|
|
This example builds a small NXFLAT test case. This includes several
|
|
test programs under examples/nxflat tests. These tests are build using
|
|
the NXFLAT format and installed in a ROMFS file system. At run time,
|
|
each program in the ROMFS file system is executed. Requires CONFIG_NXFLAT.
|
|
|
|
examplex/nxhello
|
|
^^^^^^^^^^^^^^^^
|
|
|
|
A very simple graphics example that just says "Hello, World!" in the
|
|
center of the display.
|
|
|
|
The following configuration options can be selected:
|
|
|
|
CONFIG_EXAMPLES_NXHELLO_BUILTIN -- Build the NXHELLO example as a "built-in"
|
|
that can be executed from the NSH command line
|
|
CONFIG_EXAMPLES_NXHELLO_VPLANE -- The plane to select from the frame-
|
|
buffer driver for use in the test. Default: 0
|
|
CONFIG_EXAMPLES_NXHELLO_DEVNO - The LCD device to select from the LCD
|
|
driver for use in the test: Default: 0
|
|
CONFIG_EXAMPLES_NXHELLO_BGCOLOR -- The color of the background. Default
|
|
depends on CONFIG_EXAMPLES_NXHELLO_BPP.
|
|
CONFIG_EXAMPLES_NXHELLO_FONTID - Selects the font (see font ID numbers in
|
|
include/nuttx/nx/nxfonts.h)
|
|
CONFIG_EXAMPLES_NXHELLO_FONTCOLOR -- The color of the fonts used in the
|
|
background window. Default depends on CONFIG_EXAMPLES_NXHELLO_BPP.
|
|
CONFIG_EXAMPLES_NXHELLO_BPP -- Pixels per pixel to use. Valid options
|
|
include 2, 4, 8, 16, 24, and 32. Default is 32.
|
|
CONFIG_EXAMPLES_NXHELLO_EXTERNINIT - The driver for the graphics device on
|
|
this platform requires some unusual initialization. This is the
|
|
for, for example, SPI LCD/OLED devices. If this configuration is
|
|
selected, then the platform code must provide an LCD initialization
|
|
function with a prototype like:
|
|
|
|
#ifdef CONFIG_NX_LCDDRIVER
|
|
FAR struct lcd_dev_s *up_nxdrvinit(unsigned int devno);
|
|
#else
|
|
FAR struct fb_vtable_s *up_nxdrvinit(unsigned int devno);
|
|
#endif
|
|
|
|
examples/nximage
|
|
^^^^^^^^^^^^^^^^
|
|
|
|
This is a simple example that just puts the NuttX logo image in the center
|
|
of the display. This only works for RGB23 (888), RGB16 (656), RGB8 (332),
|
|
and 8-bit greyscale for now.
|
|
|
|
CONFIG_EXAMPLES_NXIMAGE_BUILTIN -- Build the NXIMAGE example as a "built-in"
|
|
that can be executed from the NSH command line
|
|
CONFIG_EXAMPLES_NXIMAGE_VPLANE -- The plane to select from the frame-
|
|
buffer driver for use in the test. Default: 0
|
|
CONFIG_EXAMPLES_NXIMAGE_DEVNO - The LCD device to select from the LCD
|
|
driver for use in the test: Default: 0
|
|
CONFIG_EXAMPLES_NXIMAGE_BPP -- Pixels per pixel to use. Valid options
|
|
include 8, 16, and 24. Default is 16.
|
|
CONFIG_EXAMPLES_NXIMAGE_XSCALEp5, CONFIG_EXAMPLES_NXIMAGE_XSCALE1p5,
|
|
CONFIG_EXAMPLES_NXIMAGE_XSCALE2p0 -- The logo image width is 160 columns.
|
|
One of these may be defined to rescale the image horizontally by .5, 1.5,
|
|
or 2.0.
|
|
CONFIG_EXAMPLES_NXIMAGE_YSCALEp5, CONFIG_EXAMPLES_NXIMAGE_YSCALE1p5,
|
|
CONFIG_EXAMPLES_NXIMAGE_YSCALE2p0 -- The logo image height is 160 rows.
|
|
One of these may be defined to rescale the image vertically by .5, 1.5,
|
|
or 2.0.
|
|
CONFIG_EXAMPLES_NXIMAGE_GREYSCALE -- Grey scale image. Default: RGB.
|
|
CONFIG_EXAMPLES_NXIMAGE_EXTERNINIT - The driver for the graphics device on
|
|
this platform requires some unusual initialization. This is the
|
|
for, for example, SPI LCD/OLED devices. If this configuration is
|
|
selected, then the platform code must provide an LCD initialization
|
|
function with a prototype like:
|
|
|
|
#ifdef CONFIG_NX_LCDDRIVER
|
|
FAR struct lcd_dev_s *up_nxdrvinit(unsigned int devno);
|
|
#else
|
|
FAR struct fb_vtable_s *up_nxdrvinit(unsigned int devno);
|
|
#endif
|
|
|
|
How was that run-length encoded image produced?
|
|
|
|
a. I used GIMP output the image as a .c file.
|
|
b. I added som C logic to palette-ize the RGB image in the GIMP .c file
|
|
c. Then I add some simple run-length encoding to palette-ized image.
|
|
|
|
NOTE: As of this writing, most of the pixel depth, scaling options, and
|
|
combinations thereof have not been tested.
|
|
|
|
examplex/nxlines
|
|
^^^^^^^^^^^^^^^^
|
|
|
|
A very simple graphics example that just exercised the NX line drawing
|
|
logic.
|
|
|
|
The following configuration options can be selected:
|
|
|
|
CONFIG_EXAMPLES_NXLINES_VPLANE -- The plane to select from the frame-
|
|
buffer driver for use in the test. Default: 0
|
|
CONFIG_EXAMPLES_NXLINES_DEVNO - The LCD device to select from the LCD
|
|
driver for use in the test: Default: 0
|
|
CONFIG_EXAMPLES_NXLINES_BGCOLOR -- The color of the background. Default
|
|
depends on CONFIG_EXAMPLES_NXLINES_BPP.
|
|
CONFIG_EXAMPLES_NXLINES_LINEWIDTH - Selects the width of the lines in
|
|
pixels (default: 16)
|
|
CONFIG_EXAMPLES_NXLINES_LINECOLOR -- The color of the central lines drawn
|
|
in the background window. Default depends on CONFIG_EXAMPLES_NXLINES_BPP
|
|
(there really is no meaningful default).
|
|
CONFIG_EXAMPLES_NXLINES_BORDERWIDTH -- The width of the circular border
|
|
drawn in the background window. (default: 16).
|
|
CONFIG_EXAMPLES_NXLINES_BORDERCOLOR -- The color of the circular border
|
|
drawn in the background window. Default depends on CONFIG_EXAMPLES_NXLINES_BPP
|
|
(there really is no meaningful default).
|
|
CONFIG_EXAMPLES_NXLINES_CIRCLECOLOR -- The color of the circular region
|
|
filled in the background window. Default depends on CONFIG_EXAMPLES_NXLINES_BPP
|
|
(there really is no meaningful default).
|
|
CONFIG_EXAMPLES_NXLINES_BORDERCOLOR -- The color of the lines drawn in the
|
|
background window. Default depends on CONFIG_EXAMPLES_NXLINES_BPP (there
|
|
really is no meaningful default).
|
|
|
|
CONFIG_EXAMPLES_NXLINES_BPP -- Pixels per pixel to use. Valid options
|
|
include 2, 4, 8, 16, 24, and 32. Default is 16.
|
|
CONFIG_EXAMPLES_NXLINES_EXTERNINIT - The driver for the graphics device on
|
|
this platform requires some unusual initialization. This is the
|
|
for, for example, SPI LCD/OLED devices. If this configuration is
|
|
selected, then the platform code must provide an LCD initialization
|
|
function with a prototype like:
|
|
|
|
#ifdef CONFIG_NX_LCDDRIVER
|
|
FAR struct lcd_dev_s *up_nxdrvinit(unsigned int devno);
|
|
#else
|
|
FAR struct fb_vtable_s *up_nxdrvinit(unsigned int devno);
|
|
#endif
|
|
|
|
CONFIG_NSH_BUILTIN_APPS - Build the NX lines examples as an NSH built-in
|
|
function.
|
|
|
|
examples/nxtext
|
|
^^^^^^^^^^^^^^^
|
|
|
|
This directory contains another simple test of a subset of the NX APIs
|
|
defined in include/nuttx/nx/nx.h. This text focuses on text displays on
|
|
the dispaly background combined with pop-up displays over the text.
|
|
The text display will continue to update while the pop-up is visible.
|
|
|
|
NOTE: This example will *only* work with FB drivers and with LCD
|
|
drivers that support reading the contents of the internal LCD memory
|
|
*unless* you define CONFIG_EXAMPLES_NXTEXT_NOGETRUN. If you notice
|
|
garbage on the display or a failure at the point where the display
|
|
should scroll, it is probably because you have an LCD driver that is
|
|
write-only.
|
|
|
|
The following configuration options can be selected:
|
|
|
|
CONFIG_EXAMPLES_NXTEXT_BUILTIN -- Build the NXTEXT example as a "built-in"
|
|
that can be executed from the NSH command line
|
|
CONFIG_EXAMPLES_NXTEXT_VPLANE -- The plane to select from the frame-
|
|
buffer driver for use in the test. Default: 0
|
|
CONFIG_EXAMPLES_NXTEXT_DEVNO - The LCD device to select from the LCD
|
|
driver for use in the test: Default: 0
|
|
CONFIG_EXAMPLES_NXTEXT_BGCOLOR -- The color of the background. Default
|
|
depends on CONFIG_EXAMPLES_NXTEXT_BPP.
|
|
CONFIG_EXAMPLES_NXTEXT_BGFONTID - Selects the font to use in the
|
|
background text (see font ID numbers in include/nuttx/nx/nxfonts.h)
|
|
CONFIG_EXAMPLES_NXTEXT_BGFONTCOLOR -- The color of the fonts used in the
|
|
background window. Default depends on CONFIG_EXAMPLES_NXTEXT_BPP.
|
|
CONFIG_EXAMPLES_NXTEXT_PUCOLOR -- The color of the pop-up window. Default
|
|
depends on CONFIG_EXAMPLES_NXTEXT_BPP.
|
|
CONFIG_EXAMPLES_NXTEXT_PUFONTID - Selects the font to use in the pop-up
|
|
windows (see font ID numbers in include/nuttx/nx/nxfonts.h)
|
|
CONFIG_EXAMPLES_NXTEXT_PUFONTCOLOR -- The color of the fonts used in the
|
|
background window. Default depends on CONFIG_EXAMPLES_NXTEXT_BPP.
|
|
CONFIG_EXAMPLES_NXTEXT_BPP -- Pixels per pixel to use. Valid options
|
|
include 2, 4, 8, 16, 24, and 32. Default is 32.
|
|
CONFIG_EXAMPLES_NXTEXT_NOGETRUN -- If your display is read-only OR if
|
|
reading is not reliable, then select this configuration to avoid
|
|
reading from the display.
|
|
CONFIG_EXAMPLES_NXTEXT_EXTERNINIT - The driver for the graphics device on
|
|
this platform requires some unusual initialization. This is the
|
|
for, for example, SPI LCD/OLED devices. If this configuration is
|
|
selected, then the platform code must provide an LCD initialization
|
|
function with a prototype like:
|
|
|
|
#ifdef CONFIG_NX_LCDDRIVER
|
|
FAR struct lcd_dev_s *up_nxdrvinit(unsigned int devno);
|
|
#else
|
|
FAR struct fb_vtable_s *up_nxdrvinit(unsigned int devno);
|
|
#endif
|
|
|
|
CONFIG_EXAMPLES_NXTEXT_BMCACHE - The maximum number of characters that
|
|
can be put in the background window. Default is 128.
|
|
CONFIG_EXAMPLES_NXTEXT_GLCACHE - The maximum nuber of pre-rendered
|
|
fonts that can be retained for the background window.
|
|
|
|
This test can be performed with either the single-user version of
|
|
NX or with the multiple user version of NX selected with CONFIG_NX_MULTIUSER.
|
|
If CONFIG_NX_MULTIUSER is defined, then the following configuration
|
|
options also apply:
|
|
|
|
CONFIG_EXAMPLES_NXTEXT_STACKSIZE -- The stacksize to use when creating
|
|
the NX server. Default 2048
|
|
CONFIG_EXAMPLES_NXTEXT_CLIENTPRIO -- The client priority. Default: 100
|
|
CONFIG_EXAMPLES_NXTEXT_SERVERPRIO -- The server priority. Default: 120
|
|
CONFIG_EXAMPLES_NXTEXT_LISTENERPRIO -- The priority of the event listener
|
|
thread. Default 80.
|
|
CONFIG_EXAMPLES_NXTEXT_NOTIFYSIGNO -- The signal number to use with
|
|
nx_eventnotify(). Default: 4
|
|
|
|
If CONFIG_NX_MULTIUSER is defined, then the example also expects the
|
|
following settings and will generate an error if they are not as expected:
|
|
|
|
CONFIG_DISABLE_MQUEUE=n
|
|
CONFIG_DISABLE_SIGNALS=n
|
|
CONFIG_DISABLE_PTHREAD=n
|
|
CONFIG_NX_BLOCKING=y
|
|
|
|
examples/null
|
|
^^^^^^^^^^^^^
|
|
|
|
This is the do nothing application. It is only used for bringing
|
|
up new NuttX architectures in the most minimal of environments.
|
|
|
|
examples/ostest
|
|
^^^^^^^^^^^^^^^
|
|
|
|
This is the NuttX 'qualification' suite. It attempts to exercise
|
|
a broad set of OS functionality. Its coverage is not very extensive
|
|
as of this writing, but it is used to qualify each NuttX release.
|
|
|
|
The behavior of the ostest can be modified with the following
|
|
settings in the configs/<board-name>/defconfig file:
|
|
|
|
* CONFIG_EXAMPLES_OSTEST_BUILTIN
|
|
Build the OS test example as an NSH built-in application.
|
|
* CONFIG_EXAMPLES_OSTEST_LOOPS
|
|
Used to control the number of executions of the test. If
|
|
undefined, the test executes one time. If defined to be
|
|
zero, the test runs forever.
|
|
* CONFIG_EXAMPLES_OSTEST_STACKSIZE
|
|
Used to create the ostest task. Default is 8192.
|
|
* CONFIG_EXAMPLES_OSTEST_NBARRIER_THREADS
|
|
Specifies the number of threads to create in the barrier
|
|
test. The default is 8 but a smaller number may be needed on
|
|
systems without sufficient memory to start so many threads.
|
|
* CONFIG_EXAMPLES_OSTEST_RR_RANGE
|
|
During round-robin scheduling test two threads are created. Each of the threads
|
|
searches for prime numbers in the configurable range, doing that configurable
|
|
number of times.
|
|
This value specifies the end of search range and together with number of runs
|
|
allows to configure the length of this test - it should last at least a few
|
|
tens of seconds. Allowed values [1; 32767], default 10000
|
|
* CONFIG_EXAMPLES_OSTEST_RR_RUNS
|
|
During round-robin scheduling test two threads are created. Each of the threads
|
|
searches for prime numbers in the configurable range, doing that configurable
|
|
number of times.
|
|
|
|
examples/pashello
|
|
^^^^^^^^^^^^^^^^^
|
|
|
|
This is "Hello, World" implemented via the Pascal P-Code interpreter. In
|
|
order to use this example, you must first download and install the
|
|
NuttX pascal module. After unpacking the pascal module, you can find
|
|
installation instructions in pascal/nuttx/README.txt.
|
|
|
|
The correct install location for the NuttX examples and build files is
|
|
apps/interpreters.
|
|
|
|
examples/pipe
|
|
^^^^^^^^^^^^^
|
|
|
|
A test of the mkfifo() and pipe() APIs.
|
|
|
|
* CONFIG_EXAMPLES_PIPE_STACKSIZE
|
|
Sets the size of the stack to use when creating the child tasks.
|
|
The default size is 1024.
|
|
|
|
examples/poll
|
|
^^^^^^^^^^^^^
|
|
|
|
A test of the poll() and select() APIs using FIFOs and, if available,
|
|
stdin, and a TCP/IP socket. In order to build this test, you must the
|
|
following selected in your NuttX configuration file:
|
|
|
|
CONFIG_NFILE_DESCRIPTORS - Defined to be greater than 0
|
|
CONFIG_DISABLE_POLL - NOT defined
|
|
|
|
In order to use the TCP/IP select test, you have also the following
|
|
additional things selected in your NuttX configuration file:
|
|
|
|
CONFIG_NET - Defined for general network support
|
|
CONFIG_NET_TCP - Defined for TCP/IP support
|
|
CONFIG_NSOCKET_DESCRIPTORS - Defined to be greater than 0
|
|
CONFIG_NET_NTCP_READAHEAD_BUFFERS - Defined to be greater than zero
|
|
|
|
CONFIG_EXAMPLES_POLL_NOMAC - (May be defined to use software assigned MAC)
|
|
CONFIG_EXAMPLES_POLL_IPADDR - Target IP address
|
|
CONFIG_EXAMPLES_POLL_DRIPADDR - Default router IP addess
|
|
CONFIG_EXAMPLES_POLL_NETMASK - Network mask
|
|
|
|
In order to for select to work with incoming connections, you
|
|
must also select:
|
|
|
|
CONFIG_NET_TCPBACKLOG - Incoming connections pend in a backlog until accept() is called.
|
|
|
|
In additional to the target device-side example, there is also
|
|
a host-side application in this directory. It can be compiled under
|
|
Linux or Cygwin as follows:
|
|
|
|
cd examples/usbserial
|
|
make -f Makefile.host TOPDIR=<nuttx-directory> TARGETIP=<target-ip>
|
|
|
|
Where <target-ip> is the IP address of your target board.
|
|
|
|
This will generate a small program called 'host'. Usage:
|
|
|
|
1. Build the examples/poll target program with TCP/IP poll support
|
|
and start the target.
|
|
|
|
3. Then start the host application:
|
|
|
|
./host
|
|
|
|
The host and target will exchange are variety of small messages. Each
|
|
message sent from the host should cause the select to return in target.
|
|
The target example should read the small message and send it back to
|
|
the host. The host should then receive the echo'ed message.
|
|
|
|
If networking is enabled, applications using this example will need to
|
|
provide an appconfig file in the configuration driver with instruction
|
|
to build applications like:
|
|
|
|
CONFIGURED_APPS += uiplib
|
|
|
|
examples/posix_spawn
|
|
^^^^^^^^^^^^^^^^^^^^
|
|
|
|
This is a simple test of the posix_spawn() API. The example derives from
|
|
examples/elf. As a result, these tests are built using the relocatable
|
|
ELF format installed in a ROMFS file system. At run time, the test program
|
|
in the ROMFS file system is spawned using posix_spawn().
|
|
|
|
Requires:
|
|
|
|
CONFIG_BINFMT_DISABLE=n - Don't disable the binary loader
|
|
CONFIG_ELF=y - Enable ELF binary loader
|
|
CONFIG_LIBC_EXECFUNCS=y - Enable support for posix_spawn
|
|
CONFIG_EXECFUNCS_SYMTAB="exports" - The name of the symbol table
|
|
created by the test.
|
|
CONFIG_EXECFUNCS_NSYMBOLS=10 - Value does not matter, it will be
|
|
corrected at runtime.
|
|
CONFIG_POSIX_SPAWN_STACKSIZE=768 - This default setting.
|
|
|
|
Test-specific configuration options:
|
|
|
|
CONFIG_EXAMPLES_POSIXSPAWN_DEVMINOR - The minor device number of the ROMFS
|
|
block. driver. For example, the N in /dev/ramN. Used for registering the
|
|
RAM block driver that will hold the ROMFS file system containing the ELF
|
|
executables to be tested. Default: 0
|
|
|
|
CONFIG_EXAMPLES_POSIXSPAWN_DEVPATH - The path to the ROMFS block driver
|
|
device. This must match EXAMPLES_POSIXSPAWN_DEVMINOR. Used for
|
|
registering the RAM block driver that will hold the ROMFS file system
|
|
containing the ELF executables to be tested. Default: "/dev/ram0"
|
|
|
|
NOTES:
|
|
|
|
1. CFLAGS should be provided in CELFFLAGS. RAM and FLASH memory regions
|
|
may require long allcs. For ARM, this might be:
|
|
|
|
CELFFLAGS = $(CFLAGS) -mlong-calls
|
|
|
|
Similarly for C++ flags which must be provided in CXXELFFLAGS.
|
|
|
|
2. Your top-level nuttx/Make.defs file must also include an approproate
|
|
definition, LDELFFLAGS, to generate a relocatable ELF object. With GNU
|
|
LD, this should include '-r' and '-e main' (or _main on some platforms).
|
|
|
|
LDELFFLAGS = -r -e main
|
|
|
|
If you use GCC to link, you make also need to include '-nostdlib' or
|
|
'-nostartfiles' and '-nodefaultlibs'.
|
|
|
|
3. This example also requires genromfs. genromfs can be build as part of the
|
|
nuttx toolchain. Or can built from the genromfs sources that can be found
|
|
at misc/tools/genromfs-0.5.2.tar.gz. In any event, the PATH variable must
|
|
include the path to the genromfs executable.
|
|
|
|
4. ELF size: The ELF files in this example are, be default, quite large
|
|
because they include a lot of "build garbage". You can greatly reduce the
|
|
size of the ELF binaries are using the 'objcopy --strip-unneeded' command to
|
|
remove un-necessary information from the ELF files.
|
|
|
|
5. Simulator. You cannot use this example with the the NuttX simulator on
|
|
Cygwin. That is because the Cygwin GCC does not generate ELF file but
|
|
rather some Windows-native binary format.
|
|
|
|
If you really want to do this, you can create a NuttX x86 buildroot toolchain
|
|
and use that be build the ELF executables for the ROMFS file system.
|
|
|
|
6. Linker scripts. You might also want to use a linker scripts to combine
|
|
sections better. An example linker script is at nuttx/binfmt/libelf/gnu-elf.ld.
|
|
That example might have to be tuned for your particular linker output to
|
|
position additional sections correctly. The GNU LD LDELFFLAGS then might
|
|
be:
|
|
|
|
LDELFFLAGS = -r -e main -T$(TOPDIR)/binfmt/libelf/gnu-elf.ld
|
|
|
|
examples/pwm
|
|
^^^^^^^^^^^^
|
|
|
|
A test of a PWM device driver. It simply enables a pulsed output for
|
|
a specified frequency and duty for a specified period of time. This
|
|
example can ONLY be built as an NSH built-in function.
|
|
|
|
This test depends on these specific PWM/NSH configurations settings (your
|
|
specific PWM settings might require additional settings).
|
|
|
|
CONFIG_PWM - Enables PWM support.
|
|
CONFIG_EXAMPLES_PWM_COUNT - Enabled PWM pulse count support (if the
|
|
hardware supports it).
|
|
CONFIG_NSH_BUILTIN_APPS - Build the PWM test as an NSH built-in function.
|
|
Default: Not built! The example can only be used as an NSH built-in
|
|
application
|
|
|
|
Specific configuration options for this example include:
|
|
|
|
CONFIG_EXAMPLES_PWM_DEVPATH - The path to the default PWM device. Default: /dev/pwm0
|
|
CONFIG_EXAMPLES_PWM_FREQUENCY - The initial PWM frequency. Default: 100 Hz
|
|
CONFIG_EXAMPLES_PWM_DUTYPCT - The initial PWM duty as a percentage. Default: 50%
|
|
CONFIG_EXAMPLES_PWM_DURATION - The initial PWM pulse train duration in seconds.
|
|
Used only if the current pulse count is zero (pulse count is only supported
|
|
if CONFIG_PWM_PULSECOUNT is defined). Default: 5 seconds
|
|
CONFIG_EXAMPLES_PWM_PULSECOUNT - The initial PWM pulse count. This option is
|
|
only available if CONFIG_PWM_PULSECOUNT is non-zero. Default: 0 (i.e., use
|
|
the duration, not the count).
|
|
|
|
examples/qencoder
|
|
^^^^^^^^^^^^^^^^^
|
|
|
|
This example is a simple test of a Quadrature Encoder driver. It simply reads
|
|
positional data from the encoder and prints it.,
|
|
|
|
This test depends on these specific QE/NSH configurations settings (your
|
|
specific PWM settings might require additional settings).
|
|
|
|
CONFIG_QENCODER - Enables quadrature encoder support (upper-half driver).
|
|
CONFIG_NSH_BUILTIN_APPS - Build the QE test as an NSH built-in function.
|
|
Default: Built as a standalone progrem.
|
|
|
|
Additional configuration options will mostly likely be required for the board-
|
|
specific lower-half driver. See the README.txt file in your board configuration
|
|
directory.
|
|
|
|
Specific configuration options for this example include:
|
|
|
|
CONFIG_EXAMPLES_QENCODER_DEVPATH - The path to the QE device. Default:
|
|
/dev/qe0
|
|
CONFIG_EXAMPLES_QENCODER_NSAMPLES - If CONFIG_NSH_BUILTIN_APPS
|
|
is defined, then the number of samples is provided on the command line
|
|
and this value is ignored. Otherwise, this number of samples is
|
|
collected and the program terminates. Default: Samples are collected
|
|
indefinitely.
|
|
CONFIG_EXAMPLES_QENCODER_DELAY - This value provides the delay (in
|
|
milliseonds) between each sample. If CONFIG_NSH_BUILTIN_APPS
|
|
is defined, then this value is the default delay if no other delay is
|
|
provided on the command line. Default: 100 milliseconds
|
|
|
|
examples/relays
|
|
^^^^^^^^^^^^^^^
|
|
|
|
Requires CONFIG_ARCH_RELAYS.
|
|
Contributed by Darcy Gong.
|
|
|
|
NOTE: This test exercises internal relay driver interfaces. As such, it
|
|
relies on internal OS interfaces that are not normally available to a
|
|
user-space program. As a result, this example cannot be used if a
|
|
NuttX is built as a protected, supervisor kernel (CONFIG_NUTTX_KERNEL).
|
|
|
|
examples/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
|
|
|
|
At present, the RGMP example folder contains only an empty rgmp_main.c file.
|
|
|
|
examples/romfs
|
|
^^^^^^^^^^^^^^
|
|
|
|
This example exercises the romfs filesystem. Configuration options
|
|
include:
|
|
|
|
* CONFIG_EXAMPLES_ROMFS_RAMDEVNO
|
|
The minor device number to use for the ROM disk. The default is
|
|
1 (meaning /dev/ram1)
|
|
|
|
* CONFIG_EXAMPLES_ROMFS_SECTORSIZE
|
|
The ROM disk sector size to use. Default is 64.
|
|
|
|
* CONFIG_EXAMPLES_ROMFS_MOUNTPOINT
|
|
The location to mount the ROM disk. Deafault: "/usr/local/share"
|
|
|
|
examples/sendmail
|
|
^^^^^^^^^^^^^^^^^
|
|
|
|
This examples exercises the uIP SMTP logic by sending a test message
|
|
to a selected recipient. This test can also be built to execute on
|
|
the Cygwin/Linux host environment:
|
|
|
|
cd examples/sendmail
|
|
make -f Makefile.host TOPDIR=<nuttx-directory>
|
|
|
|
Settings unique to this example include:
|
|
|
|
CONFIG_EXAMPLES_SENDMAIL_NOMAC - May be defined to use software assigned MAC (optional)
|
|
CONFIG_EXAMPLES_SENDMAIL_IPADDR - Target IP address (required)
|
|
CONFIG_EXAMPLES_SENDMAIL_DRIPADDR - Default router IP addess (required)
|
|
CONFIG_EXAMPLES_SENDMAILT_NETMASK - Network mask (required)
|
|
CONFIG_EXAMPLES_SENDMAIL_RECIPIENT - The recipient of the email (required)
|
|
CONFIG_EXAMPLES_SENDMAIL_SENDER - Optional. Default: "nuttx-testing@example.com"
|
|
CONFIG_EXAMPLES_SENDMAIL_SUBJECT - Optional. Default: "Testing SMTP from NuttX"
|
|
CONFIG_EXAMPLES_SENDMAIL_BODY - Optional. Default: "Test message sent by NuttX"
|
|
|
|
NOTE: This test has not been verified on the NuttX target environment.
|
|
As of this writing, unit-tested in the Cygwin/Linux host environment.
|
|
|
|
NOTE 2: This sendmail example only works for the simplest of
|
|
environments. Virus protection software on your host may have
|
|
to be disabled to allow you to send messages. Only very open,
|
|
unprotected recipients can be used. Most will protect themselves
|
|
from this test email because it looks like SPAM.
|
|
|
|
Applications using this example will need to provide an appconfig
|
|
file in the configuration driver with instruction to build applications
|
|
like:
|
|
|
|
CONFIGURED_APPS += uiplib
|
|
CONFIGURED_APPS += smtp
|
|
|
|
examples/serloop
|
|
^^^^^^^^^^^^^^^^
|
|
|
|
This is a mindlessly simple loopback test on the console. Useful
|
|
for testing new serial drivers. Configuration options include:
|
|
|
|
* CONFIG_EXAMPLES_SERLOOP_BUFIO
|
|
Use C buffered I/O (getchar/putchar) vs. raw console I/O
|
|
(read/read).
|
|
|
|
examples/telnetd
|
|
^^^^^^^^^^^^^^^^
|
|
|
|
This directory contains a functional port of the tiny uIP shell. In
|
|
the NuttX environment, the NuttShell (at apps/nshlib) supercedes this
|
|
tiny shell and also supports telnetd.
|
|
|
|
CONFIG_EXAMPLES_TELNETD_DAEMONPRIO - Priority of the Telnet daemon.
|
|
Default: SCHED_PRIORITY_DEFAULT
|
|
CONFIG_EXAMPLES_TELNETD_DAEMONSTACKSIZE - Stack size allocated for the
|
|
Telnet daemon. Default: 2048
|
|
CONFIG_EXAMPLES_TELNETD_CLIENTPRIO- Priority of the Telnet client.
|
|
Default: SCHED_PRIORITY_DEFAULT
|
|
CONFIG_EXAMPLES_TELNETD_CLIENTSTACKSIZE - Stack size allocated for the
|
|
Telnet client. Default: 2048
|
|
CONFIG_EXAMPLES_TELNETD_NOMAC - If the hardware has no MAC address of its
|
|
own, define this =y to provide a bogus address for testing.
|
|
CONFIG_EXAMPLES_TELNETD_IPADDR - The target IP address. Default 10.0.0.2
|
|
CONFIG_EXAMPLES_TELNETD_DRIPADDR - The default router address. Default
|
|
10.0.0.1
|
|
CONFIG_EXAMPLES_TELNETD_NETMASK - The network mask. Default: 255.255.255.0
|
|
|
|
The appconfig file (apps/.config) should include:
|
|
|
|
CONFIGURED_APPS += examples/telnetd
|
|
CONFIGURED_APPS += netutils/uiplib
|
|
CONFIGURED_APPS += netutils/telnetd
|
|
|
|
Also, make sure that you have the following set in the NuttX configuration
|
|
file or else the performance will be very bad (because there will be only
|
|
one character per TCP transfer):
|
|
|
|
CONFIG_STDIO_BUFFER_SIZE - Some value >= 64
|
|
CONFIG_STDIO_LINEBUFFER=y
|
|
|
|
examples/thttpd
|
|
^^^^^^^^^^^^^^^
|
|
|
|
An example that builds netutils/thttpd with some simple NXFLAT
|
|
CGI programs. see configs/README.txt for most THTTPD settings.
|
|
In addition to those, this example accepts:
|
|
|
|
CONFIG_EXAMPLES_THTTPD_NOMAC - (May be defined to use software assigned MAC)
|
|
CONFIG_EXAMPLES_THTTPD_DRIPADDR - Default router IP addess
|
|
CONFIG_EXAMPLES_THTTPD_NETMASK - Network mask
|
|
|
|
Applications using this example will need to provide an appconfig
|
|
file in the configuration directory with instruction to build applications
|
|
like:
|
|
|
|
CONFIGURED_APPS += uiplib
|
|
CONFIGURED_APPS += thttpd
|
|
|
|
examples/tiff
|
|
^^^^^^^^^^^^^
|
|
|
|
This is a simple unit test for the TIFF creation library at apps/graphic/tiff.
|
|
It is configured to work in the Linux user-mode simulation and has not been
|
|
tested in any other environment. Since the example also depends on some
|
|
other logic to mount a file system, currently it will only work as an NSH
|
|
built-on, i.e., if the following is defined:
|
|
|
|
CONFIG_NSH_BUILTIN_APPS=y
|
|
CONFIG_EXAMPLES_TIFF_BUILTIN=y
|
|
|
|
At a miniumum, to run in an embedded environment, you will probably have to
|
|
change the configured paths to the TIFF files defined in the example.
|
|
|
|
CONFIG_EXAMPLES_TIFF_OUTFILE - Name of the resulting TIFF file. Default is
|
|
"/tmp/result.tif"
|
|
CONFIG_EXAMPLES_TIFF_TMPFILE1/2 - Names of two temporaries files that
|
|
will be used in the file creation. Defaults are "/tmp/tmpfile1.dat" and
|
|
"/tmp/tmpfile2.dat"
|
|
|
|
The following must also be defined in your apps/ configuration file:
|
|
|
|
CONFIGURED_APPS += examples/tiff
|
|
CONFIGURED_APPS += graphics/tiff
|
|
|
|
examples/touchscreen
|
|
^^^^^^^^^^^^^^^^^^^^
|
|
|
|
This configuration implements a simple touchscreen test at
|
|
apps/examples/touchscreen. This test will create an empty X11 window
|
|
and will print the touchscreen output as it is received from the
|
|
simulated touchscreen driver.
|
|
|
|
CONFIG_EXAMPLES_TOUCHSCREEN_BUILTIN - Build the touchscreen test as
|
|
an NSH built-in function. Default: Built as a standalone problem
|
|
CONFIG_EXAMPLES_TOUCHSCREEN_MINOR - The minor device number. Minor=N
|
|
correspnds to touchscreen device /dev/input0. Note this value must
|
|
with CONFIG_EXAMPLES_TOUCHSCREEN_DEVPATH. Default 0.
|
|
CONFIG_EXAMPLES_TOUCHSCREEN_DEVPATH - The path to the touchscreen
|
|
device. This must be consistent with CONFIG_EXAMPLES_TOUCHSCREEN_MINOR.
|
|
Default: "/dev/input0"
|
|
CONFIG_EXAMPLES_TOUCHSCREEN_NSAMPLES - If CONFIG_EXAMPLES_TOUCHSCREEN_BUILTIN
|
|
is defined, then the number of samples is provided on the command line
|
|
and this value is ignored. Otherwise, this number of samples is
|
|
collected and the program terminates. Default: Samples are collected
|
|
indefinitely.
|
|
|
|
The following additional configurations must be set in the NuttX
|
|
configuration file:
|
|
|
|
CONFIG_INPUTP=y
|
|
(Plus any touchscreen-specific settings).
|
|
|
|
The following must also be defined in your apps configuration file:
|
|
|
|
CONFIGURED_APPS += examples/tiff
|
|
CONFIGURED_APPS += graphics/tiff
|
|
|
|
The board-specific logic must provide the following interfaces that will
|
|
be called by the example in order to initialize and uninitialize the
|
|
touchscreen hardware:
|
|
|
|
int arch_tcinitialize(int minor);
|
|
int arch_tcuninitialize(void);
|
|
|
|
examples/udp
|
|
^^^^^^^^^^^^
|
|
|
|
This is a simple network test for verifying client- and server-
|
|
functionality over UDP.
|
|
|
|
Applications using this example will need to provide an appconfig
|
|
file in the configuration driver with instruction to build applications
|
|
like:
|
|
|
|
CONFIGURED_APPS += uiplib
|
|
|
|
examples/uip
|
|
^^^^^^^^^^^^
|
|
|
|
This is a port of uIP tiny webserver example application. Settings
|
|
specific to this example include:
|
|
|
|
CONFIG_EXAMPLES_UIP_NOMAC - (May be defined to use software assigned MAC)
|
|
CONFIG_EXAMPLES_UIP_IPADDR - Target IP address
|
|
CONFIG_EXAMPLES_UIP_DRIPADDR - Default router IP addess
|
|
CONFIG_EXAMPLES_UIP_NETMASK - Network mask
|
|
CONFIG_EXAMPLES_UIP_DHCPC - Select to get IP address via DHCP
|
|
|
|
If you use DHCPC, then some special configuration network options are
|
|
required. These include:
|
|
|
|
CONFIG_NET=y - Of course
|
|
CONFIG_NSOCKET_DESCRIPTORS - And, of course, you must allocate some
|
|
socket descriptors.
|
|
CONFIG_NET_UDP=y - UDP support is required for DHCP
|
|
(as well as various other UDP-related
|
|
configuration settings).
|
|
CONFIG_NET_BROADCAST=y - UDP broadcast support is needed.
|
|
CONFIG_NET_BUFSIZE=650 - Per RFC2131 (p. 9), the DHCP client must be
|
|
(or larger) prepared to receive DHCP messages of up to
|
|
576 bytes (excluding Ethernet, IP, or UDP
|
|
headers and FCS).
|
|
|
|
Other configuration items apply also to the selected webserver net utility.
|
|
Additional relevant settings for the uIP webserver net utility are:
|
|
|
|
CONFIG_NETUTILS_HTTPDSTACKSIZE
|
|
CONFIG_NETUTILS_HTTPDFILESTATS
|
|
CONFIG_NETUTILS_HTTPDNETSTATS
|
|
|
|
Applications using this example will need to provide an appconfig
|
|
file in the configuration driver with instruction to build applications
|
|
like:
|
|
|
|
CONFIGURED_APPS += uiplib
|
|
CONFIGURED_APPS += dhcpc
|
|
CONFIGURED_APPS += resolv
|
|
CONFIGURED_APPS += webserver
|
|
|
|
NOTE: This example does depend on the perl script at
|
|
nuttx/tools/mkfsdata.pl. You must have perl installed on your
|
|
development system at /usr/bin/perl.
|
|
|
|
examples/usbserial
|
|
^^^^^^^^^^^^^^^^^^
|
|
|
|
TARGET CONFIGURATION:
|
|
|
|
This is another implementation of "Hello, World" but this one uses
|
|
a USB serial driver. Configuration options can be used to simply
|
|
the test. These options include:
|
|
|
|
CONFIG_EXAMPLES_USBSERIAL_INONLY
|
|
Only verify IN (device-to-host) data transfers. Default: both
|
|
CONFIG_EXAMPLES_USBSERIAL_OUTONLY
|
|
Only verify OUT (host-to-device) data transfers. Default: both
|
|
CONFIG_EXAMPLES_USBSERIAL_ONLYSMALL
|
|
Send only small, single packet messages. Default: Send large and small.
|
|
CONFIG_EXAMPLES_USBSERIAL_ONLYBIG
|
|
Send only large, multi-packet messages. Default: Send large and small.
|
|
|
|
If CONFIG_USBDEV_TRACE is enabled (or CONFIG_DEBUG and CONFIG_DEBUG_USB), then
|
|
the example code will also manage the USB trace output. The amount of trace output
|
|
can be controlled using:
|
|
|
|
CONFIG_EXAMPLES_USBSERIAL_TRACEINIT
|
|
Show initialization events
|
|
CONFIG_EXAMPLES_USBSERIAL_TRACECLASS
|
|
Show class driver events
|
|
CONFIG_EXAMPLES_USBSERIAL_TRACETRANSFERS
|
|
Show data transfer events
|
|
CONFIG_EXAMPLES_USBSERIAL_TRACECONTROLLER
|
|
Show controller events
|
|
CONFIG_EXAMPLES_USBSERIAL_TRACEINTERRUPTS
|
|
Show interrupt-related events.
|
|
|
|
Error results are always shown in the trace output
|
|
|
|
HOST-SIDE TEST PROGRAM
|
|
|
|
In additional to the target device-side example, there is also a
|
|
host-side application in this directory. This host side application
|
|
must be executed on a Linux host in order to perform the USBSERIAL
|
|
test. The host application can be compiled under Linux (or Cygwin?)
|
|
as follows:
|
|
|
|
cd examples/usbserial
|
|
make -f Makefile.host TOPDIR=<nuttx-directory>
|
|
|
|
RUNNING THE TEST
|
|
|
|
This will generate a small program called 'host'. Usage:
|
|
|
|
1. Build the examples/usbserial target program and start the target.
|
|
|
|
2. Wait a bit, then do enter:
|
|
|
|
dmesg
|
|
|
|
At the end of the dmesg output, you should see the serial
|
|
device was successfully idenfied and assigned to a tty device,
|
|
probably /dev/ttyUSB0 or /dev/ttyACM0 (depending on the configured
|
|
USB serial driver).
|
|
|
|
3. Then start the host application:
|
|
|
|
./host [<tty-dev>]
|
|
|
|
Where:
|
|
|
|
<tty-dev> is the USB TTY device to use. The default is
|
|
"/dev/ttyUSB0" (for the PL2303 emulation) or "/dev/ttyACM0" (for
|
|
the CDC/ACM serial device).
|
|
|
|
The host and target will exchange are variety of very small and very large
|
|
serial messages.
|
|
|
|
examples/usbstorage
|
|
^^^^^^^^^^^^^^^^^^^
|
|
|
|
This example registers a block device driver, then exports the block
|
|
the device using the USB storage class driver. In order to use this
|
|
example, your board-specific logic must provide the function:
|
|
|
|
void usbmsc_archinitialize(void);
|
|
|
|
This function will be called by the example/usbstorage in order to
|
|
do the actual registration of the block device drivers. For examples
|
|
of the implementation of usbmsc_archinitialize() see
|
|
configs/mcu123-lpc124x/src/up_usbmsc.c or
|
|
configs/stm3210e-eval/src/usbmsc.c
|
|
|
|
Configuration options:
|
|
|
|
CONFIG_EXAMPLES_USBMSC_BUILTIN
|
|
This example can be built as two NSH "built-in" commands if this option
|
|
is selected: 'msconn' will connect the USB mass storage device; 'msdis'
|
|
will disconnect the USB storage device.
|
|
CONFIG_EXAMPLES_USBMSC_NLUNS
|
|
Defines the number of logical units (LUNs) exported by the USB storage
|
|
driver. Each LUN corresponds to one exported block driver (or partition
|
|
of a block driver). May be 1, 2, or 3. Default is 1.
|
|
CONFIG_EXAMPLES_USBMSC_DEVMINOR1
|
|
The minor device number of the block driver for the first LUN. For
|
|
example, N in /dev/mmcsdN. Used for registering the block driver. Default
|
|
is zero.
|
|
CONFIG_EXAMPLES_USBMSC_DEVPATH1
|
|
The full path to the registered block driver. Default is "/dev/mmcsd0"
|
|
CONFIG_EXAMPLES_USBMSC_DEVMINOR2 and CONFIG_EXAMPLES_USBMSC_DEVPATH2
|
|
Similar parameters that would have to be provided if CONFIG_EXAMPLES_USBMSC_NLUNS
|
|
is 2 or 3. No defaults.
|
|
CONFIG_EXAMPLES_USBMSC_DEVMINOR3 and CONFIG_EXAMPLES_USBMSC_DEVPATH3
|
|
Similar parameters that would have to be provided if CONFIG_EXAMPLES_USBMSC_NLUNS
|
|
is 3. No defaults.
|
|
CONFIG_EXAMPLES_USBMSC_DEBUGMM
|
|
Enables some debug tests to check for memory usage and memory leaks.
|
|
|
|
If CONFIG_USBDEV_TRACE is enabled (or CONFIG_DEBUG and CONFIG_DEBUG_USB), then
|
|
the example code will also manage the USB trace output. The amount of trace output
|
|
can be controlled using:
|
|
|
|
CONFIG_EXAMPLES_USBMSC_TRACEINIT
|
|
Show initialization events
|
|
CONFIG_EXAMPLES_USBMSC_TRACECLASS
|
|
Show class driver events
|
|
CONFIG_EXAMPLES_USBMSC_TRACETRANSFERS
|
|
Show data transfer events
|
|
CONFIG_EXAMPLES_USBMSC_TRACECONTROLLER
|
|
Show controller events
|
|
CONFIG_EXAMPLES_USBMSC_TRACEINTERRUPTS
|
|
Show interrupt-related events.
|
|
|
|
Error results are always shown in the trace output
|
|
|
|
NOTE 1: When built as an NSH add-on command (CONFIG_EXAMPLES_USBMSC_BUILTIN=y),
|
|
Caution should be used to assure that the SD drive (or other storage device) is
|
|
not in use when the USB storage device is configured. Specifically, the SD
|
|
driver should be unmounted like:
|
|
|
|
nsh> mount -t vfat /dev/mmcsd0 /mnt/sdcard # Card is mounted in NSH
|
|
...
|
|
nsh> umount /mnd/sdcard # Unmount before connecting USB!!!
|
|
nsh> msconn # Connect the USB storage device
|
|
...
|
|
nsh> msdis # Disconnect USB storate device
|
|
nsh> mount -t vfat /dev/mmcsd0 /mnt/sdcard # Restore the mount
|
|
|
|
Failure to do this could result in corruption of the SD card format.
|
|
|
|
NOTE 2: This test exercises internal USB device driver interfaces. As such,
|
|
it relies on internal OS interfaces that are not normally available to a
|
|
user-space program. As a result, this example cannot be used if a
|
|
NuttX is built as a protected, supervisor kernel (CONFIG_NUTTX_KERNEL).
|
|
|
|
examples/usbterm
|
|
^^^^^^^^^^^^^^^^
|
|
|
|
This example implements a little USB terminal.. more of a USB "chat"
|
|
edited lines are received from the remote host connected via USB
|
|
serial and echoed out the target serial console. Edited lines from
|
|
the local target serial console are received and forwarded to the
|
|
remote host via USB serial.
|
|
|
|
Usage:
|
|
- Build the example and load into the target FLASH
|
|
- Connect on terminal to the target RS-232 connect and configure
|
|
for 115200 8N1. For example, suppose this Tera Term on a Windows
|
|
box.
|
|
- Power up the target board
|
|
- Connect the USB to a Linux box. Use the Linux dmesg command to
|
|
assure that the connect was successful. The USB CDC ACM device
|
|
should appear as /dev/ttyACM0
|
|
- On the Linux box, open minicom with tty=/dev/ttyACM0.
|
|
Configure minicom so that (1) local characters are echoed and (2)
|
|
so that no CR is required.
|
|
- Now what you type on the target Tera Term window should echo on
|
|
the Linux minicom window and, conversely, what you type on the
|
|
minicom winow should be echo in the target Tera Term window.
|
|
|
|
Configuration options:
|
|
|
|
CONFIG_EXAMPLES_USBTERM_BUILTIN - Build the usbterm example as an NSH
|
|
built-in command. NOTE: This is not fully functional as of this
|
|
writing.. It should work, but there is no mechanism in place yet
|
|
to exit the USB terminal program and return to NSH.
|
|
CONFIG_EXAMPLES_USBTERM_DEVINIT - If defined, then the example will
|
|
call a user provided function as part of its initialization:
|
|
int usbterm_devinit(void);
|
|
And another user provided function at termination:
|
|
void usbterm_devuninit(void);
|
|
CONFIG_EXAMPLES_USBTERM_BUFLEN - The size of the input and output
|
|
buffers used for receiving data. Default 256 bytes.
|
|
|
|
If CONFIG_USBDEV_TRACE is enabled (or CONFIG_DEBUG and CONFIG_DEBUG_USB, or
|
|
CONFIG_USBDEV_TRACE), then the example code will also manage the USB trace
|
|
output. The amount of trace output can be controlled using:
|
|
|
|
CONFIG_EXAMPLES_USBTERM_TRACEINIT
|
|
Show initialization events
|
|
CONFIG_EXAMPLES_USBTERM_TRACECLASS
|
|
Show class driver events
|
|
CONFIG_EXAMPLES_USBTERM_TRACETRANSFERS
|
|
Show data transfer events
|
|
CONFIG_EXAMPLES_USBTERM_TRACECONTROLLER
|
|
Show controller events
|
|
CONFIG_EXAMPLES_USBTERM_TRACEINTERRUPTS
|
|
Show interrupt-related events.
|
|
|
|
NOTE: By default, USBterm uses readline to get data from stdin. So your
|
|
appconfig file must have the following build path:
|
|
|
|
CONFIGURED_APPS += system/readline
|
|
|
|
NOTE: If you use the USBterm task over a telnet NSH connection, then you
|
|
should set the following configuration item:
|
|
|
|
CONFIG_EXAMPLES_USBTERM_FGETS=y
|
|
|
|
By default, the USBterm client will use readline() to get characters from
|
|
the console. Readline includes and command-line editor and echos
|
|
characters received in stdin back through stdout. Neither of these
|
|
behaviors are desire-able if Telnet is used.
|
|
|
|
Error results are always shown in the trace output
|
|
|
|
Other relevant configuration options: CONFIG_CDCACM selected by the
|
|
Prolifics emulation (not defined) and the CDC serial implementation
|
|
(when defined). CONFIG_USBDEV_TRACE_INITIALIDSET.
|
|
|
|
examples/watchdog
|
|
^^^^^^^^^^^^^^^^^
|
|
|
|
A simple test of a watchdog timer driver. Initializes starts the watchdog
|
|
timer. It pings the watchdog timer for a period of time then lets the
|
|
watchdog timer expire... resetting the CPU is successful. This
|
|
example can ONLY be built as an NSH built-in function.
|
|
|
|
This test depends on these specific Watchdog/NSH configurations settings (your
|
|
specific watchdog hardware settings might require additional settings).
|
|
|
|
CONFIG_WATCHDOG- Enables watchdog timer support support.
|
|
CONFIG_NSH_BUILTIN_APPS - Build the watchdog time test as an NSH
|
|
built-in function. Default: Not built! The example can only be used
|
|
as an NSH built-in application
|
|
|
|
Specific configuration options for this example include:
|
|
|
|
CONFIG_EXAMPLES_WATCHDOG_DEVPATH - The path to the Watchdog device.
|
|
Default: /dev/watchdog0
|
|
CONFIG_EXAMPLES_WATCHDOG_PINGTIME - Time in milliseconds that the example
|
|
will ping the watchdog before letting the watchdog expire. Default: 5000
|
|
milliseconds
|
|
CONFIG_EXAMPLES_WATCHDOG_PINGDELAY - Time delay between pings in
|
|
milliseconds. Default: 500 milliseconds.
|
|
CONFIG_EXAMPLES_WATCHDOG_TIMEOUT - The watchdog timeout value in
|
|
milliseconds before the watchdog timer expires. Default: 2000
|
|
milliseconds.
|
|
|
|
examples/wget
|
|
^^^^^^^^^^^^^
|
|
|
|
A simple web client example. It will obtain a file from a server using the HTTP
|
|
protocol. Settings unique to this example include:
|
|
|
|
CONFIG_EXAMPLES_WGET_URL - The URL of the file to get
|
|
CONFIG_EXAMPLES_WGET_NOMAC - (May be defined to use software assigned MAC)
|
|
CONFIG_EXAMPLES_WGET_IPADDR - Target IP address
|
|
CONFIG_EXAMPLES_WGET_DRIPADDR - Default router IP addess
|
|
CONFIG_EXAMPLES_WGET_NETMASK - Network mask
|
|
|
|
This example uses netutils/webclient. Additional configuration settings apply
|
|
to that code as follows (but built-in defaults are probably OK):
|
|
|
|
CONFIG_WEBCLIENT_GETMIMETYPE, CONFIG_WEBCLIENT_MAXHTTPLINE,
|
|
CONFIG_WEBCLIENT_MAXMIMESIZE, CONFIG_WEBCLIENT_MAXHOSTNAME,
|
|
CONFIG_WEBCLIENT_MAXFILENAME
|
|
|
|
Of course, the example also requires other settings including CONFIG_NET and
|
|
CONFIG_NET_TCP. The example also uses the uIP resolver which requires CONFIG_UDP.
|
|
|
|
WARNNG: As of this writing, wget is untested on the target platform. At present
|
|
it has been tested only in the host-based configuration described in the following
|
|
note. The primary difference is that the target version will rely on the also
|
|
untested uIP name resolver.
|
|
|
|
NOTE: For test purposes, this example can be built as a host-based wget function.
|
|
This can be built as follows:
|
|
|
|
cd examples/wget
|
|
make -f Makefile.host
|
|
|
|
Applications using this example will need to provide an appconfig
|
|
file in the configuration driver with instruction to build applications
|
|
like:
|
|
|
|
CONFIGURED_APPS += uiplib
|
|
CONFIGURED_APPS += resolv
|
|
CONFIGURED_APPS += webclient
|
|
|
|
examples/wget
|
|
^^^^^^^^^^^^^
|
|
|
|
Uses wget to get a JSON encoded file, then decodes the file.
|
|
|
|
CONFIG_EXAMPLES_WDGETJSON_MAXSIZE - Max. JSON Buffer Size
|
|
CONFIG_EXAMPLES_EXAMPLES_WGETJSON_URL - wget URL
|
|
|
|
examples/xmlrpc
|
|
^^^^^^^^^^^^^^^
|
|
|
|
This example exercises the "Embeddable Lightweight XML-RPC Server" which
|
|
is discussed at:
|
|
|
|
http://www.drdobbs.com/web-development/an-embeddable-lightweight-xml-rpc-server/184405364
|
|
|
|
Configuration options:
|
|
|
|
CONFIG_EXAMPLES_XMLRPC_BUFFERSIZE - HTTP buffer size. Default 1024
|
|
CONFIG_EXAMPLES_XMLRPC_DHCPC - Use DHCP Client. Default n. Ignored
|
|
if CONFIG_NSH_BUILTIN_APPS is selected.
|
|
CONFIG_EXAMPLES_XMLRPC_NOMAC - Use Canned MAC Address. Defaul n. Ignored
|
|
if CONFIG_NSH_BUILTIN_APPS is selected.
|
|
CONFIG_EXAMPLES_XMLRPC_IPADDR - Target IP address. Default 0x0a000002.
|
|
Ignored if CONFIG_NSH_BUILTIN_APPS is selected.
|
|
CONFIG_EXAMPLES_XMLRPC_DRIPADDR - Default Router IP address (Gateway).
|
|
Default 0x0a000001. Ignored if CONFIG_NSH_BUILTIN_APPS is selected.
|
|
CONFIG_EXAMPLES_XMLRPC_NETMASK - Network Mask. Default 0xffffff00
|
|
Ignored if CONFIG_NSH_BUILTIN_APPS is selected.
|