RISC-V BL602 Book中的Apache NuttX应用程序

# Examples ### Selecting Examples The examples directory contains several sample applications that can be linked with NuttX. The specific example is selected in the `boards/<arch-name>/<chip-name>/<board-name>/configs/<config>/defconfig` file via the `CONFIG_EXAMPLES_xyz` setting where `xyz` is the name of the example. For example: ```conf CONFIG_EXAMPLES_HELLO=y ``` Selects the `examples/hello` _Hello, World!_ 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.md` for more information). ## `adc` Read from 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 program. 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` – 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`. ## `ajoystick` Analog Joystick This is a simple test of the analog joystick driver. See details about this driver in `nuttx/include/nuttx/input/ajoystick.h`. Configuration Pre-requisites: - `CONFIG_AJOYSTICK` – The analog joystick driver. Example Configuration: - `CONFIG_EXAMPLES_AJOYSTICK` – Enabled the analog joystick example. - `CONFIG_EXAMPLES_AJOYSTICK_DEVNAME` – Joystick device name. Default `/dev/adjoy0`. - `CONFIG_EXAMPLES_AJOYSTICK_SIGNO` – Signal used to signal the test application. Default `13`. ## `alarm` RTC Alarm A simple example that tests the alarm IOCTLs of the RTC driver. Dependencies: - `CONFIG_RTC_DRIVER` – RTC driver must be initialized to allow user space access to the RTC. - `CONFIG_RTC_ALARM` – Support for RTC alarms must be enabled. Configuration: - `CONFIG_EXAMPLES_ALARM` – Enable the RTC driver alarm test. - `CONFIG_EXAMPLES_ALARM_PROGNAME` – This is the name of the program that will be used when the NSH ELF program is installed. - `CONFIG_EXAMPLES_ALARM_PRIORITY` – Alarm daemon priority. - `CONFIG_EXAMPLES_ALARM_STACKSIZE` – Alarm daemon stack size. - `CONFIG_EXAMPLES_ALARM_DEVPATH` – RTC device path (`/dev/rtc0`). - `CONFIG_EXAMPLES_ALARM_SIGNO` – Alarm signal. ## `apa102` Rainbow on `APA102` LED Strip Rainbow example for `APA102` LED Strip. ## `bastest` Bas BASIC Interpreter This directory contains a small program that will mount a ROMFS file system containing the BASIC test files extracted from the Bas `2.4` release. See `examples/bastest/README.md` for licensing and usage information. - `CONFIG_EXAMPLES_BASTEST_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 BASIC files to be tested. Default: `0`. - `CONFIG_EXAMPLES_BASTEST_DEVPATH` – The path to the ROMFS block driver device. This must match `EXAMPLES_BASTEST_DEVMINOR`. Used for registering the RAM block driver that will hold the ROMFS file system containing the BASIC files to be tested. Default: `/dev/ram0`. ## `bridge` Network Bridge A simple test of a system with multiple networks. It simply echoes all UDP packets received on network `1` and network `2` to network `2` and network `1`, respectively. Interface `1` and interface may or may not lie on the same network. - `CONFIG_EXAMPLES_BRIDGE` – Enables the simple UDP bridge test. There identical configurations for each of the two networks, `NETn` where `n` refers to the network being configured `n={1,2}`. Let `m` refer to the other network. - `CONFIG_EXAMPLES_BRIDGE_NETn_IFNAME` – The register name of the network `n` device. Must match the previously registered driver name and must not be the same as other network device name, `CONFIG_EXAMPLES_BRIDGE_NETm_IFNAME`. - `CONFIG_EXAMPLES_BRIDGE_NETn_RECVPORT` – Network `n` listen port number. - `CONFIG_EXAMPLES_BRIDGE_NETn_SNDPORT` – Network `2` send port number. - `CONFIG_EXAMPLES_BRIDGE_NETn_IOBUFIZE` – Size of the network `n` UDP send/receive I/O buffer. - `CONFIG_EXAMPLES_BRIDGE_NETn_STACKSIZE` – Network `n` daemon stacksize. - `CONFIG_EXAMPLES_BRIDGE_NETn_PRIORITY` – Network `n` daemon task priority. If used as a NSH add-on, then it is assumed that initialization of both networks was performed externally prior to the time that this test was started. Otherwise, the following options are available: - `CONFIG_EXAMPLES_BRIDGE_NETn_NOMAC` – Select of the network `n` hardware does not have a built-in MAC address. If selected, the MAC address. provided by `CONFIG_EXAMPLES_BRIDGE_NETn_MACADDR` will be used to assign the MAC address to the network n device. - `CONFIG_EXAMPLES_BRIDGE_NETn_DHCPC` – Use DHCP Client to get the network n IP address. - `CONFIG_EXAMPLES_BRIDGE_NETn_IPADDR` – If `CONFIG_EXAMPLES_BRIDGE_NETn_DHCPC` is not selected, then this is the fixed IP address for network `n`. - `CONFIG_EXAMPLES_BRIDGE_NETn_DRIPADDR` – Network `n` default router IP address (Gateway). - `CONFIG_EXAMPLES_BRIDGE_NETn_NETMASK` – Network `n` mask. ## `buttons` Read GPIO Buttons To be provided. ## `can` CAN Device Test 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 program. Specific configuration options for this example include: - `CONFIG_EXAMPLES_CAN_DEVPATH` – The path to the CAN device. Default: `/dev/can0`. - `CONFIG_EXAMPLES_CAN_NMSGS` – This number of CAN message is collected and the program terminates. Default: 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. ## `canard` Example application for `canutils/libcarnard`. ## `cctype` Verifies all possible inputs for all functions defined in the header file `cctype`. ## `chat` AT over TTY Demonstrates AT chat functionality over a TTY device. This is useful with AT modems, for example, to establish a `pppd` connection (see the related `pppd` example). Moreover, some AT modems – such as ones made by u-blox – have an internal TCP/IP stack, often with an implementation of TLS/SSL. In such cases the chat utility can be used to configure the internal TCP/IP stack, establish socket connections, set up security (e.g., download base64-encoded certificates to the modem), and perfo