px4-firmware/apps/examples/README.txt

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.

    - CONFIG_NSH_BUILTIN_APPS - Build the ADC test as an NSH built-in function.
      Default: Built as a standalone problem
    - CONFIG_EXAMPLES_ADC_DEVPATH - The 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_EXAMPLE_BUTTONS_MIN         - Lowest button number (MIN=0)
  CONFIG_EXAMPLE_BUTTONS_MAX         - Highest button number (MAX=7)

  CONFIG_ARCH_IRQBUTTONS             - Must be defined for interrupting button support
  CONFIG_EXAMPLE_IRQBUTTONS_MIN      - Lowest interrupting button number (MIN=0)
  CONFIG_EXAMPLE_IRQBUTTONS_MAX      - Highest interrupting button number (MAX=7)

  Name strings for buttons:
  
    CONFIG_EXAMPLE_BUTTONS_NAME0, CONFIG_EXAMPLE_BUTTONS_NAME1,
    CONFIG_EXAMPLE_BUTTONS_NAME2, CONFIG_EXAMPLE_BUTTONS_NAME3,
    CONFIG_EXAMPLE_BUTTONS_NAME4, CONFIG_EXAMPLE_BUTTONS_NAME5,
    CONFIG_EXAMPLE_BUTTONS_NAME6, CONFIG_EXAMPLE_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 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.
 
  Specific configuration options for this example include:
 
    CONFIG_NSH_BUILTIN_APPS - Build the CAN test as an NSH built-in function.
       Default: Built as a standalone problem
    CONFIG_CAN_LOOPBACK
    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.

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_EXAMPLE_DHCPD_NOMAC     - (May be defined to use software assigned MAC)
    CONFIG_EXAMPLE_DHCPD_IPADDR    - Target IP address
    CONFIG_EXAMPLE_DHCPD_DRIPADDR  - Default router IP addess
    CONFIG_EXAMPLE_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/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: The ftpc task uses the system console for input/output.  It will
  not work from NSH over a telnet NSH connection (Well, it will work you 
  just won't be able to access the command line).

  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/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.

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 settings:

    CONFIG_EXAMPLES_HELLOXX_BUILTIN -- Build the helloxx example as a
      "built-in"  that can be executed from the NSH command line.
    CONFIG_EXAMPLES_HELLOXX_NOSTATICCONST - Set if system does not support
      static constructors.
    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.
    CONFIG_EXAMPLES_HIDKBD_STACKSIZE - Stacksize of "waiter" thread.

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_EXAMPLE_IGMP_NOMAC
      Set if the hardware has no MAC address; one will be assigned
  * CONFIG_EXAMPLE_IGMP_IPADDR
      Target board IP address
  * CONFIG_EXAMPLE_IGMP_DRIPADDR
      Default router address
  * CONFIG_EXAMPLE_IGMP_NETMASK
      Network mask
  * CONFIG_EXAMPLE_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/lcdrw
^^^^^^^^^^^^^^

  This example may be used to verify if you can or cannot read data
  correct from an LCD interface.  At present, this supports only LCDs
  with RGB565 color format.

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/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

  And if networking is included:

  CONFIGURED_APPS += uiplib
  CONFIGURED_APPS += dhcpc
  CONFIGURED_APPS += resolv
  CONFIGURED_APPS += tftp
  CONFIGURED_APPS += webclient

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/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_BUILTIN -- Build the NXLINES example as a "built-in"
      that can be executed from the NSH command line    
    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: 4).
    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

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_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.

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_EXAMPLE_POLL_NOMAC         - (May be defined to use software assigned MAC)
  CONFIG_EXAMPLE_POLL_IPADDR        - Target IP address
  CONFIG_EXAMPLE_POLL_DRIPADDR      - Default router IP addess
  CONFIG_EXAMPLE_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/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.

    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
    CONFIG_EXAMPLES_PWM_DEVPATH - The path to the 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 sectonds.
       as a percentage.  Default: 5 seconds

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 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_EXAMPLE_SENDMAIL_NOMAC     - May be defined to use software assigned MAC (optional)
    CONFIG_EXAMPLE_SENDMAIL_IPADDR    - Target IP address (required)
    CONFIG_EXAMPLE_SENDMAIL_DRIPADDR  - Default router IP addess (required)
    CONFIG_EXAMPLE_SENDMAILT_NETMASK  - Network mask (required)
    CONFIG_EXAMPLE_SENDMAIL_RECIPIENT - The recipient of the email (required)
    CONFIG_EXAMPLE_SENDMAIL_SENDER    - Optional. Default: "nuttx-testing@example.com"
    CONFIG_EXAMPLE_SENDMAIL_SUBJECT   - Optional. Default: "Testing SMTP from NuttX"
    CONFIG_EXAMPLE_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/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_EXAMPLE_THTTPD_NOMAC    - (May be defined to use software assigned MAC)
    CONFIG_EXAMPLE_THTTPD_DRIPADDR - Default router IP addess
    CONFIG_EXAMPLE_THTTPD_NETMASK  - Network mask

  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 += 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_EXAMPLE_UIP_NOMAC     - (May be defined to use software assigned MAC)
    CONFIG_EXAMPLE_UIP_IPADDR    - Target IP address
    CONFIG_EXAMPLE_UIP_DRIPADDR  - Default router IP addess
    CONFIG_EXAMPLE_UIP_NETMASK   - Network mask
    CONFIG_EXAMPLE_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

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.

    3. Then start the host application:

         ./host [<tty-dev>]

       Where:

         <tty-dev> is the USB TTY device to use.  The default is /dev/ttyUSB0.

    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 usbstrg_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 usbstrg_archinitialize() see
  configs/mcu123-lpc124x/src/up_usbstrg.c or
  configs/stm3210e-eval/src/usbstrg.c

  Configuration options:

  CONFIG_EXAMPLES_USBSTRG_BUILTIN
    This example can be built as two NSH "built-in" commands if this option
    is selection: 'msconn' will connect the USB mass storage device; 'msdis'
    will disconnect the USB storage device.
  CONFIG_EXAMPLES_USBSTRG_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_USBSTRG_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_USBSTRG_DEVPATH1
    The full path to the registered block driver.  Default is "/dev/mmcsd0"
  CONFIG_EXAMPLES_USBSTRG_DEVMINOR2 and CONFIG_EXAMPLES_USBSTRG_DEVPATH2
    Similar parameters that would have to be provided if CONFIG_EXAMPLES_USBSTRG_NLUNS
    is 2 or 3.  No defaults.
  CONFIG_EXAMPLES_USBSTRG_DEVMINOR3 and CONFIG_EXAMPLES_USBSTRG_DEVPATH3
    Similar parameters that would have to be provided if CONFIG_EXAMPLES_USBSTRG_NLUNS
    is 3.  No defaults.
  CONFIG_EXAMPLES_USBSTRG_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_USBSTRG_TRACEINIT
    Show initialization events
  CONFIG_EXAMPLES_USBSTRG_TRACECLASS
    Show class driver events
  CONFIG_EXAMPLES_USBSTRG_TRACETRANSFERS
    Show data transfer events
  CONFIG_EXAMPLES_USBSTRG_TRACECONTROLLER
    Show controller events
  CONFIG_EXAMPLES_USBSTRG_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_USBSTRG_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_UBSTERM_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.

  Error results are always shown in the trace output

  Other relevant configuration options:  CONFIG_CDCSER selected by the
  Prolifics emulation (not defined) and the CDC serial implementation
  (when defined). CONFIG_USBDEV_TRACE_INITIALIDSET.

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_EXAMPLE_WGET_URL       - The URL of the file to get
    CONFIG_EXAMPLE_WGET_NOMAC     - (May be defined to use software assigned MAC)
    CONFIG_EXAMPLE_WGET_IPADDR    - Target IP address
    CONFIG_EXAMPLE_WGET_DRIPADDR  - Default router IP addess
    CONFIG_EXAMPLE_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