Merge branch 'apache:master' into boards/esp32/heltec_leds

Author: Shriyans406

.codespell-ignore-lines

@@ -178,3 +178,4 @@ libs/libc/tre-mem.c
 #define RTPROT_RA                        9    /* RDISC/ND router advertisements */
   /* Followed by one or more ND options */
    *    message using the Neighbor Discovery (ND) protocol. It then listens
+PIO   DUE SCHEM. PIN MAPPING    SAM3X       DUE SCHEM. BOARD LABEL

Documentation/applications/examples/lvglterm/index.rst

@@ -6,7 +6,6 @@ LVGL application that executes NuttShell (NSH) commands entered with a
 Touchscreen Keyboard and displays the NSH output. Prerequisite configuration
 settings:
 
-- ``CONFIG_NSH_ARCHINIT=n`` – NSH architecture initialization must be disabled.
 - ``CONFIG_NSH_CONSOLE=y`` – NSH must be configured to use a console.
 - ``CONFIG_LIBC_EXECFUNCS=y`` – posix_spawn() must be enabled.
 - ``CONFIG_PIPES=y`` – Pipes must be enabled.

Documentation/applications/nsh/config.rst

@@ -374,12 +374,6 @@ Configuration                        Description
  ``CONFIG_NSH_TELNET``               If ``CONFIG_NSH_TELNET`` is set to *y*, then a TELNET server
                                      front-end is selected. When this option is provided, you may log
                                      into NuttX remotely using telnet in order to access NSH.
-
- ``CONFIG_NSH_ARCHINIT``             Set ``CONFIG_NSH_ARCHINIT`` if your board provides architecture
-                                     specific initialization via the board-specific function
-                                     ``board_app_initialize()``. This function will be called early in
-                                     NSH initialization to allow board logic to do such things as
-                                     configure MMC/SD slots.
 ===================================  ==================================
 
 .. _nsh_vars_table:

Documentation/applications/nsh/customizing.rst

@@ -108,13 +108,6 @@ The NSH initialization function, ``nsh_initialize()``, be found in
      ``apps/nshlib/rc.sysinit.template``. The resulting ROMFS file system can be
      found in ``apps/nshlib/nsh_romfsimg.h``.
 
-  #. ``board_app_initialize()``: Next any architecture-specific NSH
-     initialization will be performed (if any). For the STM3240G-EVAL,
-     this architecture specific initialization can be found at
-     ``boards/arm/stm32/stm3240g-eval/src/stm32_appinit.c``. This it does
-     things like: (1) Initialize SPI devices, (2) Initialize SDIO, and (3)
-     mount any SD cards that may be inserted.
-
   #. ``nsh_netinit()``: The ``nsh_netinit()`` function can be found in
      ``apps/nshlib/nsh_netinit.c``.
 

Documentation/applications/nsh/installation.rst

@@ -6,11 +6,6 @@ Customizing NSH Initialization
 customize the NSH start-up behavior. Here they are presented in order of
 increasing difficulty:
 
-  #. You can extend the initialization logic in
-     ``boards/arm/stm32/stm3240g-eval/src/stm32_appinit.c``. The logic
-     there is called each time that NSH is started and is good place in
-     particular for any device-related initialization.
-
   #. You replace the sample code at ``apps/examples/nsh/nsh_main.c`` with
      whatever start-up logic that you want. NSH is a library at
      ``apps/nshlib``. ``apps.examples/nsh`` is just a tiny, example

Documentation/applications/system/nxcamera/index.rst

@@ -1,3 +1,111 @@
-============================================
-``nxcamera`` NxCamera video test application
-============================================
+=============================================
+``nxcamera`` Camera/Video Stream Test Command
+=============================================
+
+Introduction
+============
+
+``nxcamera`` is a command-line utility for testing camera devices and video
+stream capture in NuttX. It is built on top of the NuttX video subsystem
+(using a V4L2-style interface) and is typically used to:
+
+- Enumerate and open video device nodes such as ``/dev/video0`` and
+  ``/dev/video1``
+- Configure capture parameters including resolution and pixel format
+- Capture video frames for validation, debugging, or simple data dumping,
+  depending on platform support and build configuration
+
+Usage
+=====
+
+``nxcamera`` is an interactive command-line program. Start it from NSH, then
+enter commands at the ``nxcamera>`` prompt:
+
+.. code-block:: console
+
+   nsh> nxcamera
+   nxcamera>
+
+Tip: Execute NSH Commands (Hidden)
+==================================
+
+At the ``nxcamera>`` prompt you can run an NSH command by prefixing it with
+``!``. This is useful for quickly checking system state or invoking other
+utilities without exiting ``nxcamera``.
+
+.. code-block:: console
+
+   nxcamera> !ls /dev
+   /dev:
+    console
+    fb0
+    gpio0
+    gpio1
+    gpio2
+    gpio3
+    loop
+    null
+    oneshot
+    ram0
+    ram1
+    ram2
+    video0
+    video1
+    zero
+   nxcamera> !poweroff
+   bash>
+
+A typical workflow at the prompt is:
+
+- ``input /dev/video0`` to set the input video node.
+- ``output /dev/fb0`` to set the output node, for example a framebuffer.
+- ``stream 640 480 30 NV12`` to start streaming with ``width height fps
+  format``.
+- ``stop`` to stop streaming.
+
+You may just copy-paste the commands below to get started:
+
+.. code-block:: console
+
+  nxcamera
+  input /dev/video0
+  output /dev/fb0
+  stream 640 480 30 YUYV # or NV12 on macOS
+
+Pixel Format
+============
+
+For the ``stream`` command, the pixel format depends on the platform. On the
+macOS ``sim`` platform you may use ``NV12``, while on Linux systems ``YUYV``
+is more commonly used.
+
+Examples
+========
+
+1. Start ``nxcamera`` and configure a typical interactive capture session:
+
+.. code-block:: console
+
+   nsh> nxcamera
+   nxcamera> input /dev/video0
+   nxcamera> output /dev/fb0
+   nxcamera> stream 640 480 30 NV12
+   nxcamera> stop
+
+.. figure:: nxcamera_macos_sim.png
+   :alt: nxcamera running on the macOS SIM platform
+   :align: center
+
+   ``nxcamera`` using the macOS AVFoundation backend on the SIM platform.
+
+Features and Updates
+====================
+
+- Multiple camera instances are supported, allowing several cameras to be
+  exposed as different device nodes such as ``/dev/video0`` and
+  ``/dev/video1``. This makes it easier to select and validate different
+  video input sources on the same system.
+- On the ``sim`` platform, support has been added for the macOS
+  AVFoundation backend. This enables camera capture and functional
+  verification on macOS hosts, subject to build configuration and host
+  permission settings.

Documentation/applications/system/nxcamera/nxcamera_macos_sim.png

@@ -2,6 +2,16 @@
 Quadrature Encoder Drivers
 ==========================
 
+A Quadrature Encoder (QE) is a kind of sensor normally used to read
+angular rotation of a motor or other turning device.
+
+NuttX supports internal QE peripheral that exists in some microcontrollers
+like ESP32, iMXRT, STM32, nRF5x, TIVA, and others, and also supports
+Magnetic Rotary Encoders like AS5048, MT6816, etc.
+
+Internal Peripheral Quadrature Encoder
+======================================
+
 NuttX supports a low-level, two-part Quadrature Encoder driver.
 
 #. An "upper half", generic driver that provides the common
@@ -28,6 +38,46 @@ following locations:
    for the specific processor ``<architecture>`` and for the
    specific ``<chip>`` Quadrature Encoder peripheral devices.
 
+Magnetic Rotary Encoder
+=======================
+
+Although technically a Magnetic Rotary Encoder is not a Quadrature Encoder,
+usually uses the QE Lower Half driver to export a device compatible with
+quadrature encoder. This way an application using an ordinary QE encoder
+could use a Magnetic Rotary Encoder with any modification, just need to
+enable and initialize the Magnetic Rotary Encoder on their board.
+
+This is how a board powered by STM32 will initialize a MT6816 Magnetic
+Rotary Encoder:
+
+.. code-block:: c
+
+   /* Initialize the SPI bus connected to MT6816 */
+
+   spi = stm32_spibus_initialize(spi_busno);
+   if (spi == NULL)
+     {
+       return -ENODEV;
+     }
+
+   /* Initialize MT6816 using `spi` and a `device number` starting from 0 */
+
+   dev = mt6816_initialize(spi, (uint16_t) devno);
+   if (dev == NULL)
+     {
+       return -ENODEV;
+     }
+
+   /* Use the returned qe lower half to register /dev/qe# (# => devno) */
+
+   ret = qe_register(qe_path, dev);
+   if (ret < 0)
+     {
+       snerr("ERROR: Failed to register MT6816 qe%d driver: %d\n",
+             devno, ret);
+       ret = -ENODEV;
+     }
+
 Application Programming Interface
 =================================
 

Documentation/components/drivers/character/quadrature.rst

@@ -498,8 +498,7 @@ To enable this feature, set the following configuration options:
    CONFIG_TIMER=y
    CONFIG_TIMER_WDOG=y
 
-Then call ``timer_wdog_initialize()`` from your board initialization code
-(typically in ``board_late_initialize()`` or ``board_app_initialize()``):
+Then call ``timer_wdog_initialize()`` from your board initialization code.
 
 .. code-block:: c
 

Documentation/components/drivers/character/timers/timer.rst

@@ -8,7 +8,7 @@ USB Host-Side Drivers
    ``struct usbhost_connection_s`` defined in
    ``include/nuttx/usb/usbhost.h``.
 
-   -  ``struct usbhost_driver_s`` provides the interface between 
+   -  ``struct usbhost_driver_s`` provides the interface between
       the USB host driver and the USB host class driver.
 
    -  ``struct usbhost_connection_s`` provides the interface between
@@ -91,9 +91,6 @@ USB Host-Side Drivers
       registered USB host class driver to the USB host controller
       driver.
 
-      **Examples**: The function ``nsh_waiter()`` in the file
-      ``boards/arm/lpc17xx_40xx/olimex-lpc1766stk/src/lpc17_40_appinit.c``.
-
    #. As part of its operation during the binding operation, the
       USB host class driver will register an instances of a
       standard NuttX driver under the ``/dev`` directory. To
@@ -106,3 +103,37 @@ USB Host-Side Drivers
       **Examples**: See the call to ``register_blockdriver()`` in
       the function ``usbhost_initvolume()`` in the file
       ``drivers/usbhost/usbhost_storage.c``.
+
+CDC-ECM Host Class Driver
+=========================
+
+The CDC-ECM (Ethernet Control Model) host class driver
+(``drivers/usbhost/usbhost_cdcecm.c``) supports USB devices that expose
+a network interface using the USB Communications Device Class Ethernet
+Control Model. Common device types include:
+
+-  **USB-to-Ethernet adapters** that implement CDC-ECM, providing wired
+   Ethernet connectivity over a USB port.
+
+-  **Cellular modems and similar devices** that expose a CDC-ECM
+   interface for IP connectivity, such as LTE modems operating in USB
+   tethering mode.
+
+When a compatible device is connected and enumerated, the driver
+registers a standard NuttX Ethernet network interface — for example
+``eth0`` — and integrates with the NuttX networking stack in exactly the
+same way as any on-board Ethernet driver. Normal network configuration
+can then be applied to the interface using standard NSH commands::
+
+    ifup eth0
+    ifconfig eth0 192.168.1.10 netmask 255.255.255.0
+
+Or with DHCP via the ``netinit`` daemon when
+``CONFIG_NETINIT_DHCPC=y`` is selected.
+
+The driver is registered by calling ``usbhost_cdcecm_initialize()``
+during board initialization, before the USB host waiter thread begins
+enumerating devices.
+
+**Examples**: ``drivers/usbhost/usbhost_cdcecm.c``,
+``boards/arm/stm32h5/nucleo-h563zi/configs/nshusbnet/defconfig``.