NuttShell (NSH)Last Updated: October 20, 2012 |
Table of Contents |
1.0 Overview |
The apps/nshlib sub-directory contains the NuttShell (NSH)
library.
This library can easily to linked to produce a NSH application (See as an example apps/nshlib).
NSH is a simple shell application for NuttX.
1.1 Console/NSH Front End |
Using settings in the configuration file, NSH may be configured to use either the serial stdin/out or a telnet connection as the console or BOTH. When NSH is started, you will see the following welcome on either console:
NuttShell (NSH) nsh>
nsh> is the NSH prompt and indicates that you may enter a command
from the console.
1.2 Command Overview |
Simple, Re-directed, and Background Commands. The NuttShell (NSH) is a simple shell application. NSH supports the following commands forms:
| Simple command: | <cmd> |
| Command with re-directed output: |
<cmd> > <file> |
| Background command: | <cmd> & |
| Re-directed background command: |
<cmd> > <file> & |
Where:
<cmd> |
is any one of the simple commands listed later. |
<file> |
is the full or relative path to any writable object in the filesystem name space (file or character driver). Such objects will be referred to simply as files throughout this document. |
nice'd Background Commands
NSH executes at the mid-priority (128). Backgrounded commands can
be made to execute at higher or lower priorities using nice:
[nice [-d <niceness>>]] <cmd> [> <file>|>> <file>] [&]
Where <niceness> is any value between -20 and 19 where lower
(more negative values) correspond to higher priorities.
The default niceness is 10.
1.3 Conditional Command Execution |
An if-then[-else]-fi construct is also supported in order to
support conditional execution of commands. This works from the
command line but is primarily intended for use within NSH scripts
(see the sh commnd). The syntax is as follows:
if <cmd> then [sequence of <cmd>] else [sequence of <cmd>] fi
1.4 Built-In Variables |
$? |
The result of the last simple command execution. On backgrounded commands, this variable holds only the result of spawning the background command. |
1.5 Current Working Directory |
cd and pwd.
All path arguments to commands may be either an absolute path or a
path relative to the current working directory. The current working
directory is set using the cd command and can be queried either
by using the pwd command or by
using the echo $PWD
command.
1.6 Environment Variables |
Environment Variables:
PWD | The current working directory |
OLDPWD | The previous working directory |
1.7 NSH Start-Up Script |
NSH Start-Up Script.
NSH supports options to provide a start up script for NSH. In general
this capability is enabled with CONFIG_NSH_ROMFSETC, but has
several other related configuration options as described with the
NSH-specific configuration settings.
This capability also depends on:
CONFIG_DISABLE_MOUNTPOINT not set
CONFIG_NFILE_DESCRIPTORS > 4
CONFIG_FS_ROMFS enabled
Default Start-Up Behavior. The implementation that is provided is intended to provide great flexibility for the use of Start-Up files. This paragraph will discuss the general behavior when all of the configuration options are set to the default values.
In this default case, enabling CONFIG_NSH_ROMFSETC will cause
NSH to behave as follows at NSH startup time:
`--init.d/
`-- rcS
/etc, resulting in:
|--dev/
| `-- ram0
`--etc/
`--init.d/
`-- rcS
# Create a RAMDISK and mount it at XXXRDMOUNTPOUNTXXX mkrd -m 1 -s 512 1024 mkfatfs /dev/ram1 mount -t vfat /dev/ram1 /tmp
/etc/init.d/rcS at start-up (before the
first NSH prompt. After execution of the script, the root FS will look
like:
|--dev/ | |-- ram0 | `-- ram1 |--etc/ | `--init.d/ | `-- rcS `--tmp/
Modifying the ROMFS Image.
The contents of the /etc directory are retained in the file apps/nshlib/nsh_romfsimg.h OR, if CONFIG_NSH_ARCHROMFS is defined, include/arch/board/rcs.template).
In order to modify the start-up behavior, there are three things to study:
CONFIG_NSH_ROMFSETC configuration options
discussed with the other NSH-specific configuration settings.
tools/mkromfsimg.sh Script.
The script tools/mkromfsimg.sh creates nsh_romfsimg.h.
It is not automatically executed. If you want to change the
configuration settings associated with creating and mounting
the /tmp directory, then it will be necessary to re-generate
this header file using the tools/mkromfsimg.sh script.
The behavior of this script depends upon three things:
genromfs tool (available from http://romfs.sourceforge.net).
apps/nshlib/rcS.template
(OR, if CONFIG_NSH_ARCHROMFS is defined include/arch/board/rcs.template.
rcS.template.
The file apps/nshlib/rcS.template contains the general form
of the rcS file; configured values are plugged into this
template file to produce the final rcS file.
NOTE:
apps/nshlib/rcS.template generates the standard, default nsh_romfsimg.h file.
If CONFIG_NSH_ARCHROMFS is defined in the NuttX configuration file, then a custom, board-specific nsh_romfsimg.h file residing in configs/<board>/include will be used.
NOTE when the OS is configured, include/arch/board will be linked to configs/<board>/include.
All of the startup-behavior is contained in rcS.template. The
role of mkromfsimg.sh is to (1) apply the specific configuration
settings to rcS.template to create the final rcS, and (2) to
generate the header file nsh_romfsimg.h containg the ROMFS
file system image.
Further Information. See the section on Customimizing the NuttShell for additional, more detailed information about the NSH start-up script and how to modify it.
2.0 Commands |
2.1 Evaluate Expression (test) |
Command Syntax:
[ <expression> ] test <expression>
Synopsis.
These are two alternative forms of the same command. They support
evaluation of a boolean expression which sets $?.
This command is used most frequently as the conditional command following the
if in the if-then[-else]-fi construct.
Expression Syntax:
expression = simple-expression | !expression | expression -o expression | expression -a expression
simple-expression = unary-expression | binary-expression
unary-expression = string-unary | file-unary
string-unary = -n string | -z string
file-unary = -b file | -c file | -d file | -e file | -f file | -r file | -s file | -w file
binary-expression = string-binary | numeric-binary
string-binary = string = string | string == string | string != string
numeric-binary = integer -eq integer | integer -ge integer | integer -gt integer | integer -le integer | integer -lt integer | integer -ne integer
2.2 Concatenate Files (cat) |
Command Syntax:
cat<path>[<path>[<path>...]]
Synopsis.
This command copies and concatentates all of the files at <path>
to the console (or to another file if the output is redirected).
2.3 Change Current Working Directory (cd) |
Command Syntax:
cd [<dir-path>|-|~|..]
Synopsis.
Changes the current working directory (PWD). Also sets the
previous working directory environment variable (OLDPWD).
Forms:
cd <dir-path> |
sets the current working directory to <dir-path>. |
cd - |
sets the current working directory to the previous
working directory ($OLDPWD).
Equivalent to cd $OLDPWD. |
cd or cd ~ |
set the current working directory to the 'home'
directory. The home directory can be configured by setting
CONFIG_LIB_HOMEDIR in the configuration file. The default
home directory is /. |
cd .. |
sets the current working directory to the parent directory. |
2.4 Copy Files (cp) |
Command Syntax:
cp <source-path> <dest-path>
Synopsis.
Copy of the contents of the file at <source-path> to the location
in the filesystem indicated by <dest-path>.
2.5 Show or set the date and time (date) |
Command Syntax:
date [-s "MMM DD HH:MM:SS YYYY"]
Synopsis.
Show or set the current date and time.
This command is only supported if the platform supported RTC hardware (CONFIG_RTC=y).
Only one format is used both on display and when setting the date/time:
MMM DD HH:MM:SS YYYY. For example,
data -s "Sep 1 11:30:00 2011"
24-hour time is used.
2.6 Copy and Convert Files (dd) |
Command Syntax:
dd if=<infile> of=<outfile> [bs=<sectsize>] [count=<sectors>] [skip=<sectors>]
Synopsis. Copy blocks from <infile> to <outfile>. <infile> or <outfile> may be the path to a standard file, a character device, or a block device. Examples follow:
nsh> ls -l /dev /dev: crw-rw-rw- 0 zero nsh> dd if=/dev/zero of=/tmp/zeros bs=64 count=16 nsh> ls -l /tmp /tmp: -rw-rw-rw- 1024 ZEROS
nsh> ls -l /dev /dev: brw-rw-rw- 0 ram0 crw-rw-rw- 0 zero nsh> dd if=/dev/zero of=/dev/ram0
nsh> ls -l /dev /dev: crw-rw-rw- 0 null brw-rw-rw- 0 ram0 nsh> dd if=/dev/ram0 of=/dev/null
2.7 Show Volument Status (df) |
Command Syntax:
df
Synopsis. Show the state of each mounted volume. As an example:
nsh> mount
/etc type romfs
/tmp type vfat
nsh> df
Block Number
Size Blocks Used Available Mounted on
64 6 6 0 /etc
512 985 2 983 /tmp
nsh>
2.8 Echo Strings and Variables (echo) |
Command Syntax:
echo [<string|$name> [<string|$name>...]]
Synopsis. Copy the sequence of strings and expanded environment variables to console output (or to a file if the output is re-directed).
2.9 Execute User Code (exec) |
Command Syntax:
exec <hex-address>
Synopsis.
Execute the user logic at address <hex-address>. NSH will pause
until the execution unless the user logic is executed in background
via exec <hex-address> &.
2.10 Exit NSH (exit) |
Command Syntax:
exit
Synopsis.
Exit NSH. Only useful for the serial front end if you have started some other tasks (perhaps
using the exec command) and you would like to have NSH out of the
way. For the telnet front-end, exit terminates the telenet session.
2.11 Show Memory Manager Status (free) |
Command Syntax:
free
Synopsis. Show the current state of the memory allocator. For example,
nsh> free
total used free largest
Mem: 4194288 1591552 2602736 2601584
nsh>
Where:
total |
This is the total size of memory allocated for use by malloc in bytes. |
used |
This is the total size of memory occupied by chunks handed out by malloc. |
free |
This is the total size of memory occupied by free (not in use) chunks. |
largest |
Size of the largest free (not in use) chunk. |
2.12 Get File Via TFTP (get) |
Command Syntax:
get [-b|-n] [-f <local-path>] -h <ip-address> <remote-path>
Synopsis.
Copy the file at <remote-address> from the host whose IP address is
identified by <ip-address>.
Other options:
-f <local-path> |
The file will be saved relative to the current working directory
unless <local-path> is provided.
|
-b|-n |
Selects either binary ("octect") or test ("netascii") transfer mode. Default: text. |
2.13 Show Usage Command Usage (help) |
Command Syntax:
help [-v] [<cmd>]
Synopsis. Presents summary information about NSH commands to console.
Options:
-v |
how verbose output will full command usage. |
<cmd> |
Show full command usage only for this command. |
2.14 Show Network Configuration (ifconfig) |
Command Syntax:
ifconfig [nic_name [ip_address]]
Synopsis.
Two forms of the ifconfigcommand are supported:
With one or no arguments, ifconfig will shows the
current configuration of the network and, perhaps, the status of ethernet
device:
ifconfig ifconfig [nic_name]
As an example:
nsh> ifconfig
eth0 HWaddr 00:18:11:80:10:06
IPaddr:10.0.0.2 DRaddr:10.0.0.1 Mask:255.255.255.0
If uIP statistics are enabled (CONFIG_NET_STATISTICS), then
this command will also show the detailed state of uIP.
If both the network interface name and an IP address are supplied as arguments,
then ifconfig will set the address of the ethernet device:
ifconfig nic_name ip_address
2.15 Send a signal to a task (kill) |
kill -<signal> <pid>
Synopsis. Send the <signal> to the task identified by <pid>.
nsh> mkfifo /dev/fifo
nsh> cat /dev/fifo &
cat [2:128]
nsh> ps
PID PRI SCHD TYPE NP STATE NAME
0 0 FIFO TASK READY Idle Task()
1 128 FIFO TASK RUNNING init()
2 128 FIFO PTHREAD WAITSEM (51ea50)
nsh> kill -9 2
nsh: cat: open failed: 4
nsh> ps
PID PRI SCHD TYPE NP STATE NAME
0 0 FIFO TASK READY Idle Task()
1 128 FIFO TASK RUNNING init()
nsh>
NOTE:
NuttX does not support a FULL POSIX signalling system.
Standard signals like SIGCHLD, SIGINTR, SIGKILL, etc. do not exist in NuttX and sending those signal may not have the result that you expect.
Rather, NuttX supports only what are referred to as POSIX real-time signals.
These signals may be used to communicate with running tasks, may be use to waiting waiting tasks, etc.
But, as an example, kill -9 (SIGKILL) will not terminate a task.
2.16 Setup/teardown the Loop Device (losetup) |
Command Syntax 1:
losetup [-o] [-r] <dev-path> <file-path>
Synopsis.
Setup the loop device at <dev-path> to access the file at <file-path> as a block device.
In the following example a 256K file is created (dd) and losetup is
used to make the file accessible as a block device.
A FAT file system is created (mkfatfs) and mounted (mount).
Files can then be managed on the loop-mounted file.
nsh> dd if=/dev/zero of=/tmp/image bs=512 count=512 nsh> ls -l /tmp /tmp: -rw-rw-rw- 262144 IMAGE nsh> losetup /dev/loop0 /tmp/image nsh> ls -l /dev /dev: brw-rw-rw- 0 loop0 nsh> mkfatfs /dev/loop0 nsh> mount -t vfat /dev/loop0 /mnt/example nsh> ls -l /mnt ls -l /mnt /mnt: drw-rw-rw- 0 example/ nsh> echo "This is a test" >/mnt/example/atest.txt nsh> ls -l /mnt/example /mnt/example: -rw-rw-rw- 16 ATEST.TXT nsh> cat /mnt/example/atest.txt This is a test nsh>
Command Syntax 2:
losetup d <dev-path>
Synopsis. Teardown the setup for the loop device at <dev-path>.
2.17 List Directory Contents (ls) |
Command Syntax:
ls [-lRs] <dir-path>
Synopsis.
Show the contents of the directory at <dir-path>. NOTE:
<dir-path> must refer to a directory and no other filesystem
object.
Options:
-R |
Show the constents of specified directory and all of its sub-directories. |
-s |
Show the size of the files along with the filenames in the listing |
-l |
Show size and mode information along with the filenames in the listing. |
2.18 Access Memory (mb, mh, and mw) |
Command Syntax:
mb <hex-address>[=<hex-value>][ <hex-byte-count>] mh <hex-address>[=<hex-value>][ <hex-byte-count>] mw <hex-address>[=<hex-value>][ <hex-byte-count>]
Synopsis. Access memory using byte size access (mb), 16-bit accesses (mh), or 32-bit access (mw). In each case,
<hex-address>. |
Specifies the address to be accessed. The current value at that address will always be read and displayed. |
<hex-address>=<hex-value>. |
Read the value, then write <hex-value>
to the location.
|
<hex-byte-count>. |
Perform the mb, mh, or mw operation on a total
of <hex-byte-count> bytes, increment the <hex-address> appropriately
after each access
|
Example:
nsh> mh 0 16 0 = 0x0c1e 2 = 0x0100 4 = 0x0c1e 6 = 0x0110 8 = 0x0c1e a = 0x0120 c = 0x0c1e e = 0x0130 10 = 0x0c1e 12 = 0x0140 14 = 0x0c1e nsh>
2.19 Show Current Tasks and Threads (ps) |
Command Syntax:
ps
Synopsis. Show the currently active threads and tasks. For example,
nsh> ps
PID PRI SCHD TYPE NP STATE NAME
0 0 FIFO TASK READY Idle Task()
1 128 RR TASK RUNNING init()
2 128 FIFO TASK WAITSEM nsh_telnetmain()
3 100 RR PTHREAD WAITSEM <pthread>(21)
nsh>
2.20 Create a Directory (mkdir) |
Command Syntax:
mkdir <path>
Synopsis.
Create the directory at <path>.
All components of of <path> except the final directory name must exist on a mounted file
system; the final directory must not.
Limited to Mounted File Systems.
Recall that NuttX uses a pseudo filesystem for its root file
system.
The mkdir command can only be used to create directories in volumes set up with the
mount command; it cannot be used to create directories in the pseudo filesystem.
Example:
nsh> mkdir /mnt/fs/tmp nsh> ls -l /mnt/fs /mnt/fs: drw-rw-rw- 0 TESTDIR/ drw-rw-rw- 0 TMP/ nsh>
2.21 Create a FAT Filesystem (mkfatfs) |
Command Syntax:
mkfatfs <path>
Synopsis.
Format a fat file system on the block device specified by <path>.
NSH provides this command to access the mkfatfs() NuttX API.
This block device must reside in the NuttX pseudo filesystem and
must have been created by some call to register_blockdriver() (see include/nuttx/fs/fs.h).
2.22 Create a FIFO (mkfifo) |
Command Syntax:
mkfifo <path>
Synopsis.
Creates a FIFO character device anywhere in the pseudo file system, creating
whatever pseudo directories that may be needed to complete the <path>.
By convention, however, device drivers are place in the standard /dev directory.
After it is created, the FIFO device may be used as any other device driver.
NSH provides this command to access the mkfifo() NuttX API.
Example
nsh> ls -l /dev /dev: crw-rw-rw- 0 console crw-rw-rw- 0 null brw-rw-rw- 0 ram0 nsh> mkfifo /dev/fifo nsh> ls -l /dev ls -l /dev /dev: crw-rw-rw- 0 console crw-rw-rw- 0 fifo crw-rw-rw- 0 null brw-rw-rw- 0 ram0 nsh>
2.23 Create a RAMDISK (mkrd) |
Command Syntax:
mkrd [-m <minor>] [-s <sector-size>] <nsectors>
Synopsis.
Create a ramdisk consisting of <nsectors>, each of size
<sector-size> (or 512 bytes if <sector-size> is not specified.
The ramdisk will be registered as /dev/ram<n> (if <n> is not
specified, mkrd will attempt to register the ramdisk as /dev/ram0.
Example
nsh> ls /dev /dev: console null ttyS0 ttyS1 nsh> mkrd 1024 nsh> ls /dev /dev: console null ram0 ttyS0 ttyS1 nsh>
Once the ramdisk has been created, it may be formatted using
the mkfatfs command and mounted using the mount command.
Example
nsh> mkrd 1024 nsh> mkfatfs /dev/ram0 nsh> mount -t vfat /dev/ram0 /tmp nsh> ls /tmp /tmp: nsh>
2.24 Mount a File System (mount) |
Command Syntax:
mount -t <fstype> <block-device> <dir-path>
Synopsis.
The mount command performs one of two different operations.
If no paramters are provided on the command line after the mount command, then the mount command will enumerate all of the current mountpoints on the console.
If the mount parameters are provied on the command after the mount command, then the mount command will mount a file system in the NuttX pseudo-file system.
mount' performs a three way association, binding:
<fstype>' option identifies the type of
file system that has been formatted on the <block-device>.
As of this writing, vfat is the only supported value for <fstype>
<block-device> argument is the full or relative
path to a block driver inode in the pseudo filesystem.
By convention, this is a name under the /dev sub-directory.
This <block-device> must have been previously formatted with the same file system
type as specified by <fstype>
<dir-path>, is the location in the
pseudo filesystem where the mounted volume will appear.
This mount point can only reside in the NuttX pseudo filesystem.
By convention, this mount point is a subdirectory under /mnt.
The mount command will create whatever pseudo directories that may be needed to complete the
full path but the full path must not already exist.
After the volume has been mounted in the NuttX pseudo filesystem, it may be access in the same way as other objects in thefile system.
Examples:
Using mount to mount a file system:
nsh> ls -l /dev /dev: crw-rw-rw- 0 console crw-rw-rw- 0 null brw-rw-rw- 0 ram0 nsh> ls /mnt nsh: ls: no such directory: /mnt nsh> mount -t vfat /dev/ram0 /mnt/fs nsh> ls -l /mnt/fs/testdir /mnt/fs/testdir: -rw-rw-rw- 15 TESTFILE.TXT nsh> echo "This is a test" >/mnt/fs/testdir/example.txt nsh> ls -l /mnt/fs/testdir /mnt/fs/testdir: -rw-rw-rw- 15 TESTFILE.TXT -rw-rw-rw- 16 EXAMPLE.TXT nsh> cat /mnt/fs/testdir/example.txt This is a test nsh>
Using mount to enumerate mounts:
nsh> mount /etc type romfs /mnt/fs type vfat /tmp type vfat
2.25 Rename a File (mv) |
Command Syntax:
mv <old-path> <new-path>
Synopsis.
Rename the file object at <old-path> to <new-path>.
Both paths must reside in the same mounted filesystem.
2.26 Mount an NFS file system (nfsmount) |
Command Syntax:
nfsmount <server-address> <mount-point> <remote-path>
Synopsis. Mount the remote NFS server directory<remote-path> at <mount-point> on the target machine. <server-address> is the IP address of the remote server.
2.27 Check Network Peer (ping) |
Command Syntax:
ping [-c <count>] [-i <interval>] <ip-address>
Synopsis. Test the network communication with a remote peer. Example,
nsh> ping 10.0.0.1 PING 10.0.0.1 56 bytes of data 56 bytes from 10.0.0.1: icmp_seq=1 time=0 ms 56 bytes from 10.0.0.1: icmp_seq=2 time=0 ms 56 bytes from 10.0.0.1: icmp_seq=3 time=0 ms 56 bytes from 10.0.0.1: icmp_seq=4 time=0 ms 56 bytes from 10.0.0.1: icmp_seq=5 time=0 ms 56 bytes from 10.0.0.1: icmp_seq=6 time=0 ms 56 bytes from 10.0.0.1: icmp_seq=7 time=0 ms 56 bytes from 10.0.0.1: icmp_seq=8 time=0 ms 56 bytes from 10.0.0.1: icmp_seq=9 time=0 ms 56 bytes from 10.0.0.1: icmp_seq=10 time=0 ms 10 packets transmitted, 10 received, 0% packet loss, time 10190 ms nsh>
2.28 Send File Via TFTP (put) |
Command Syntax:
put [-b|-n] [-f <remote-path>] -h <ip-address> <local-path>
Synopsis.
Copy the file at <local-address> to the host whose IP address is
identified by <ip-address>.
Other options:
-f <remote-path> |
The file will be saved relative with the same name on the host
unless <remote-path> is provided.
|
-b|-n |
Selects either binary ("octect") or test ("netascii") transfer mode. Default: text. |
2.29 Show Current Working Directory (pwd) |
Command Syntax:
pwd
Synopsis. Show the current working directory.
nsh> cd /dev nsh> pwd /dev nsh>
nsh> echo $PWD /dev nsh>
2.30 Remove a File (rm) |
Command Syntax:
rm <file-path>
Synopsis.
Remove the specified <file-path> name from the mounted file system.
Recall that NuttX uses a pseudo filesystem for its root file
system.
The rm command can only be used to remove (unlink) files in volumes set up with the
mount command;
it cannot be used to remove names in the pseudo filesystem.
Example:
nsh> ls /mnt/fs/testdir /mnt/fs/testdir: TESTFILE.TXT EXAMPLE.TXT nsh> rm /mnt/fs/testdir/example.txt nsh> ls /mnt/fs/testdir /mnt/fs/testdir: TESTFILE.TXT nsh>
2.31 Remove a Directory (rmdir) |
Command Syntax:
rmdir <dir-path>
Synopsis.
Remove the specified <dir-path> directory from the mounted file system.
Recall that NuttX uses a pseudo filesystem for its root file
system.
The rmdir command can only be used to remove directories from volumes set up with the
mount command;
it cannot be used to remove directories from the pseudo filesystem.
Example:
nsh> mkdir /mnt/fs/tmp nsh> ls -l /mnt/fs /mnt/fs: drw-rw-rw- 0 TESTDIR/ drw-rw-rw- 0 TMP/ nsh> rmdir /mnt/fs/tmp nsh> ls -l /mnt/fs /mnt/fs: drw-rw-rw- 0 TESTDIR/ nsh>
2.32 Set an Environment Variable (set) |
Command Syntax:
set <name> <value>
Synopsis.
Set the environment variable <name> to the string <value>.
For example,
nsh> echo $foobar nsh> set foobar foovalue nsh> echo $foobar foovalue nsh>
2.33 Execute an NSH Script (sh) |
Command Syntax:
sh <script-path>
Synopsis.
Execute the sequence of NSH commands in the file referred
to by <script-path>.
2.34 Wait for Seconds (sleep) |
Command Syntax:
sleep <sec>
Synopsis.
Pause execution (sleep) for <sec> seconds.
2.35 Unmount a File System (umount) |
Command Syntax:
umount <dir-path>
Synopsis.
Un-mount the file system at mount point <dir-path>.
The umount command can only be used to un-mount volumes previously mounted using
mount command.
Example:
nsh> ls /mnt/fs /mnt/fs: TESTDIR/ nsh> umount /mnt/fs nsh> ls /mnt/fs /mnt/fs: nsh: ls: no such directory: /mnt/fs nsh>
2.36 Unset an Environment Variable (unset) |
Command Syntax:
unset <name>
Synopsis.
Remove the value associated with the environment variable
<name>. Example:
nsh> echo $foobar foovalue nsh> unset foobar nsh> echo $foobar nsh>
2.37 Wait for Microseconds (usleep) |
Command Syntax:
usleep <usec>
Synopsis.
Pause execution (sleep) of <usec> microseconds.
| 2.37 Get File Via HTTP (wget) |
Command Syntax:
wget [-o <local-path>] <url>
Synopsis.
Use HTTP to copy the file at <url> to the current directory.
Options:
-o <local-path> |
The file will be saved relative to the current working directory
and with the same name as on the HTTP server unless <local-path> is provided.
|
2.38 Hexadecimal dump (xd) |
Command Syntax:
xd <hex-address> <byte-count>
Synopsis.
Dump <byte-count> bytes of data from address <hex-address>.
Example:
nsh> xd 410e0 512 Hex dump: 0000: 00 00 00 00 9c 9d 03 00 00 00 00 01 11 01 10 06 ................ 0010: 12 01 11 01 25 08 13 0b 03 08 1b 08 00 00 02 24 ....%..........$ ... 01f0: 08 3a 0b 3b 0b 49 13 00 00 04 13 01 01 13 03 08 .:.;.I.......... nsh>
3.0 Configuration Settings |
The availability of the above commands depends upon features that may or may not be enabled in the NuttX configuration file. The following table indicates the dependency of each command on NuttX configuration settings. General configuration settings are discussed in the NuttX Porting Guide. Configuration settings specific to NSH as discussed at the bottom of this document.
Note that in addition to general NuttX configuation settings, each NSH command can be individually disabled via the settings in the rightmost column. All of these settings make the configuration of NSH potentially complex but also allow it to squeeze into very small memory footprints.
3.1 Command Dependencies on Configuration Settings |
Table. Command Dependencies on Configuration Settings
| Command | Depends on Configuration | Can Be Disabled with |
|---|---|---|
[ |
!CONFIG_NSH_DISABLESCRIPT |
CONFIG_NSH_DISABLE_TEST |
cat |
CONFIG_NFILE_DESCRIPTORS > 0 |
CONFIG_NSH_DISABLE_CAT |
cd |
!CONFIG_DISABLE_ENVIRON && CONFIG_NFILE_DESCRIPTORS > 0 |
CONFIG_NSH_DISABLE_CD |
cp |
CONFIG_NFILE_DESCRIPTORS > 0 |
CONFIG_NSH_DISABLE_CP |
date |
!CONFIG_DISABLE_CLOCK && CONFIG_RTC |
CONFIG_NSH_DISABLE_DATE |
dd |
CONFIG_NFILE_DESCRIPTORS > 0 |
CONFIG_NSH_DISABLE_DD |
df |
!CONFIG_DISABLE_MOUNTPOINT && CONFIG_NFILE_DESCRIPTORS > 0 && CONFIG_FS_READABLE3 |
CONFIG_NSH_DISABLE_DF |
echo |
CONFIG_NSH_DISABLE_ECHO |
|
exec |
CONFIG_NSH_DISABLE_EXEC |
|
exit |
CONFIG_NSH_DISABLE_EXIT |
|
free |
CONFIG_NSH_DISABLE_FREE |
|
get |
CONFIG_NET && CONFIG_NET_UDP &&
CONFIG_NFILE_DESCRIPTORS > 0 && CONFIG_NET_BUFSIZE >= 5581 |
CONFIG_NSH_DISABLE_GET |
help5 |
CONFIG_NSH_DISABLE_HELP |
|
ifconfig |
CONFIG_NET |
CONFIG_NSH_DISABLE_IFCONFIG |
kill |
!CONFIG_DISABLE_SIGNALS |
CONFIG_NSH_DISABLE_KILL |
losetup |
!CONFIG_DISABLE_MOUNTPOINT && CONFIG_NFILE_DESCRIPTORS > 0 |
CONFIG_NSH_DISABLE_LOSETUP |
ls |
CONFIG_NFILE_DESCRIPTORS > 0 |
CONFIG_NSH_DISABLE_LS |
mb,mh,mw |
CONFIG_NSH_DISABLE_MB,CONFIG_NSH_DISABLE_MH,CONFIG_NSH_DISABLE_MW
|
|
mkdir |
!CONFIG_DISABLE_MOUNTPOINT && CONFIG_NFILE_DESCRIPTORS > 0 && CONFIG_FS_WRITABLE4 |
CONFIG_NSH_DISABLE_MKDIR |
mkfatfs |
!CONFIG_DISABLE_MOUNTPOINT && CONFIG_NFILE_DESCRIPTORS > 0 && CONFIG_FS_FAT |
CONFIG_NSH_DISABLE_MKFATFS |
mkfifo |
CONFIG_NFILE_DESCRIPTORS > 0 |
CONFIG_NSH_DISABLE_MKFIFO |
mkrd |
!CONFIG_DISABLE_MOUNTPOINT && CONFIG_NFILE_DESCRIPTORS > 0 && CONFIG_FS_WRITABLE4 |
CONFIG_NSH_DISABLE_MKRD |
mount |
!CONFIG_DISABLE_MOUNTPOINT && CONFIG_NFILE_DESCRIPTORS > 0 && CONFIG_FS_READABLE3 |
CONFIG_NSH_DISABLE_MOUNT |
mv |
!CONFIG_DISABLE_MOUNTPOINT && CONFIG_NFILE_DESCRIPTORS > 0 && CONFIG_FS_WRITABLE3 |
CONFIG_NSH_DISABLE_MV |
nfsmount |
!CONFIG_DISABLE_MOUNTPOINT && CONFIG_NFILE_DESCRIPTORS > 0 && CONFIG_NET && CONFIG_NFS |
CONFIG_NSH_DISABLE_NFSMOUNT |
ping |
CONFIG_NET && CONFIG_NET_ICMP &&
CONFIG_NET_ICMP_PING && !CONFIG_DISABLE_CLOCK &&
!CONFIG_DISABLE_SIGNALS |
CONFIG_NSH_DISABLE_PING |
ps |
CONFIG_NSH_DISABLE_PS |
|
put |
CONFIG_NET && CONFIG_NET_UDP &&
CONFIG_NFILE_DESCRIPTORS > 0 && CONFIG_NET_BUFSIZE >= 5581,2 |
CONFIG_NSH_DISABLE_PUT |
pwd |
!CONFIG_DISABLE_ENVIRON && CONFIG_NFILE_DESCRIPTORS > 0 |
CONFIG_NSH_DISABLE_PWD |
rm |
!CONFIG_DISABLE_MOUNTPOINT && CONFIG_NFILE_DESCRIPTORS > 0 && CONFIG_FS_WRITABLE4 |
CONFIG_NSH_DISABLE_RM |
rmdir |
!CONFIG_DISABLE_MOUNTPOINT && CONFIG_NFILE_DESCRIPTORS > 0 && CONFIG_FS_WRITABLE4 |
CONFIG_NSH_DISABLE_RMDIR |
set |
!CONFIG_DISABLE_ENVIRON |
CONFIG_NSH_DISABLE_SET |
sh |
CONFIG_NFILE_DESCRIPTORS > 0 && |
CONFIG_NSH_DISABLE_SH |
sleep |
!CONFIG_DISABLE_SIGNALS |
CONFIG_NSH_DISABLE_SLEEP |
test |
!CONFIG_NSH_DISABLESCRIPT |
CONFIG_NSH_DISABLE_TEST |
umount |
!CONFIG_DISABLE_MOUNTPOINT && CONFIG_NFILE_DESCRIPTORS > 0 && CONFIG_FS_READABLE3 |
CONFIG_NSH_DISABLE_UMOUNT |
unset |
!CONFIG_DISABLE_ENVIRON |
CONFIG_NSH_DISABLE_UNSET |
usleep |
!CONFIG_DISABLE_SIGNALS |
CONFIG_NSH_DISABLE_USLEEP |
wget |
CONFIG_NET && CONFIG_NET_TCP &&
CONFIG_NFILE_DESCRIPTORS > 0 |
CONFIG_NSH_DISABLE_WGET |
xd |
CONFIG_NSH_DISABLE_XD |
1
Because of hardware padding, the actual required packet size may be larger
2
Special TFTP server start-up optionss will probably be required to permit
creation of files for the correct operation of the put command.
3
CONFIG_FS_READABLE is not a user configuration but is set automatically
if any readable filesystem is selected. At present, this is either CONFIG_FS_FAT
or CONFIG_FS_ROMFS.
4
CONFIG_FS_WRITABLE is not a user configuration but is set automatically
if any writable filesystem is selected. At present, this is only CONFIG_FS_FAT.
5
Verbose help output can be suppressed by defining CONFIG_NSH_HELP_TERSE.
In that case, the help command is still available but will be slightly smaller.
3.2 NSH-Specific Configuration Settings |
The behavior of NSH can be modified with the following settings in
the configs/<board-name>/defconfig file:
| Configuration | Description |
|---|---|
CONFIG_NSH_BUILTIN_APPS |
Support external registered, "named" applications that can be executed from the NSH command line (see apps/README.txt for more information). |
CONFIG_NSH_FILEIOSIZE |
Size of a static I/O buffer used for file access (ignored if there is no filesystem). Default is 1024. |
CONFIG_NSH_STRERROR |
strerror(errno) makes more readable output but strerror() is
very large and will not be used unless this setting is y.
This setting depends upon the strerror() having been enabled with CONFIG_LIBC_STRERROR.
|
CONFIG_NSH_LINELEN |
The maximum length of one command line and of one output line. Default: 80 |
CONFIG_NSH_NESTDEPTH |
The maximum number of nested if-then[-else]-fi sequences that
are permissable. Default: 3
|
CONFIG_NSH_DISABLESCRIPT |
This can be set to y to suppress support for scripting. This
setting disables the sh, test, and [ commands and the
if-then[-else]-fi construct. This would only be set on systems
where a minimal footprint is a necessity and scripting is not.
|
CONFIG_NSH_DISABLEBG |
This can be set to y to suppress support for background
commands. This setting disables the nice command prefix and
the & command suffix. This would only be set on systems
where a minimal footprint is a necessity and background command execution is not.
|
CONFIG_NSH_MMCSDMINOR |
If the architecture supports an MMC/SD slot and if the NSH
architecture specific logic is present, this option will provide
the MMC/SD minor number, i.e., the MMC/SD block driver will
be registered as /dev/mmcsdN where N is the minor number.
Default is zero.
|
CONFIG_NSH_ROMFSETC |
Mount a ROMFS filesystem at /etc and provide a startup script
at /etc/init.d/rcS. The default startup script will mount
a FAT FS RAMDISK at /tmp but the logic is
easily extensible.
|
CONFIG_NSH_CONSOLE |
If
Normally, the serial console device is a UART and RS-232 interface.
However, if
If there are more than one USB slots, then a USB device minor number may also need to be provided:
If USB tracing is enabled (
|
CONFIG_NSH_CONDEV |
If CONFIG_NSH_CONSOLE is set to y, then CONFIG_NSH_CONDEV
may also be set to select the serial device used to support the NSH console.
This should be set to the quoted name of a readable/write-able character driver such as:
CONFIG_NSH_CONDEV="/dev/ttyS1".
This is useful, for example, to separate the NSH command line from the system console
when the system console is used to provide debug output.
Default: stdin and stdout (probably "/dev/console")
/dev/console is used for a user interface,
(1) linefeeds (\n) will not be expanded to carriage return / linefeeds (\r\n).
You will need to configure your terminal program to account for this.
And (2) input is not automatically echoed so you will have to turn local echo on.
|
CONFIG_NSH_TELNET |
If CONFIG_NSH_TELNET is set to y, then a TELENET
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 nsh_archinitialize().
This function will be called early in NSH initialization to allow board logic to
do such things as configure MMC/SD slots.
|
If Telnet is selected for the NSH console, then we must configure the resources used by the Telnet daemon and by the Telnet clients.
| Configuration | Description |
|---|---|
CONFIG_NSH_TELNETD_PORT |
The telnet daemon will listen on this TCP port number for connections. Default: 23 |
CONFIG_NSH_TELNETD_DAEMONPRIO |
Priority of the Telnet daemon.
Default: SCHED_PRIORITY_DEFAULT
|
CONFIG_NSH_TELNETD_DAEMONSTACKSIZE |
Stack size allocated for the Telnet daemon. Default: 2048 |
CONFIG_NSH_TELNETD_CLIENTPRIO |
Priority of the Telnet client.
Default: SCHED_PRIORITY_DEFAULT
|
CONFIG_NSH_TELNETD_CLIENTSTACKSIZE |
Stack size allocated for the Telnet client. Default: 2048 |
One or both of CONFIG_NSH_CONSOLE and CONFIG_NSH_TELNET
must be defined. If CONFIG_NSH_TELNET is selected, then there some
other configuration settings that apply:
| Configuration | Description |
|---|---|
CONFIG_NET=y |
Of course, networking must be enabled. |
CONFIG_NSOCKET_DESCRIPTORS |
And, of course, you must allocate some socket descriptors. |
CONFIG_NET_TCP=y |
TCP/IP support is required for telnet (as well as various other TCP-related configuration settings). | CONFIG_NSH_IOBUFFER_SIZE |
Determines the size of the I/O buffer to use for sending/ receiving TELNET commands/reponses |
CONFIG_NSH_DHCPC |
Obtain the IP address via DHCP. |
CONFIG_NSH_IPADDR |
If CONFIG_NSH_DHCPC is NOT set, then the static IP
address must be provided.
|
CONFIG_NSH_DRIPADDR |
Default router IP address |
CONFIG_NSH_NETMASK |
Network mask |
CONFIG_NSH_NOMAC |
Set if your ethernet hardware has no built-in MAC address. If set, a bogus MAC will be assigned. |
CONFIG_NSH_MAX_ROUNDTRIP |
This is the maximum round trip for a response to a ICMP ECHO request. It is in units of deciseconds. The default is 20 (2 seconds). |
If you use DHCPC, then some special configuration network options are required. These include:
| Configuration | Description |
|---|---|
CONFIG_NET=y |
Of course, networking must be enabled. |
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 (or larger) |
Per RFC2131 (p. 9), the DHCP client must be prepared to receive DHCP messages of up to 576 bytes (excluding Ethernet, IP, or UDP headers and FCS). |
If CONFIG_NSH_ROMFSETC is selected, then the following additional
configuration setting apply:
| Configuration | Description |
|---|---|
CONFIG_NSH_ARCHROMFS |
May be defined to specify an alternative ROMFS image that can be found at configs/<board>/include/nsh_romfsimg.h.
|
CONFIG_NSH_ROMFSMOUNTPT |
The default mountpoint for the ROMFS volume is "/etc", but that
can be changed with this setting. This must be a absolute path
beginning with '/' and enclosed in quotes.
|
CONFIG_NSH_INITSCRIPT |
This is the relative path to the startup script within the mountpoint.
The default is "init.d/rcS". This is a relative path and must not
start with '/' but must be enclosed in quotes.
|
CONFIG_NSH_ROMFSDEVNO |
This is the minor number of the ROMFS block device. The default is
'0' corresponding to /dev/ram0.
|
CONFIG_NSH_ROMFSSECTSIZE |
This is the sector size to use with the ROMFS volume. Since the default volume is very small, this defaults to 64 but should be increased if the ROMFS volume were to be become large. Any value selected must be a power of 2. |
When the default rcS file used when CONFIG_NSH_ROMFSETC is
selected, it will mount a FAT FS under /tmp. The following selections
describe that FAT FS.
| Configuration | Description |
|---|---|
CONFIG_NSH_FATDEVNO |
This is the minor number of the FAT FS block device. The default is
'1' corresponding to /dev/ram1.
|
CONFIG_NSH_FATSECTSIZE |
This is the sector size use with the FAT FS. Default is 512. |
4.0 Customimizing the NuttShell |
Overview. The NuttShell (NSH) is a simple shell application that may be used with NuttX. It supports a variety of commands and is (very) loosely based on the bash shell and the common utilities used in Unix shell programming. The paragraphs in this appendix will focus on customizing NSH: Adding new commands, changing the initialization sequence, etc.
4.1 The NSH Library and NSH Initialization |
Overview.
NSH is implemented as a library that can be found at apps/nshlib.
As a library, it can be custom built into any application that follows the NSH initialization sequence described below.
As an example, the code at apps/examples/nsh/nsh_main.c illustrates how to start NSH and the logic there was intended to be incorporated into your own custom code.
Although code was generated simply as an example, in the end most people just use this example code as their application main() function.
That initialization performed by that example is discussed in the following paragraphs.
The NSH start-up sequence is very simple.
As an example, the code at apps/examples/nsh/nsh_main.c illustrates how to start NSH.
It simple does the following:
If you have C++ static initializers, it will call your implementation of up_cxxinitialize() which will, in turn, call those static initializers.
For the case of the STM3240G-EVAL board, the implementation of up_cxxinitialize() can be found at nuttx/configs/stm3240g-eval/src/up_cxxinitialize.c.
This function then calls nsh_initialize() which initializes the NSH library.
nsh_initialize() is described in more detail below.
If the Telnetconsole is enabled, it calls nsh_telnetstart() which resides in the NSH library.
nsh_telnetstart() will start the Telnet daemon that will listen for Telnet connections and start remote NSH sessions.
If a local console is enabled (probably on a serial port), then nsh_consolemain() is called.
nsh_consolemain() also resides in the NSH library.
nsh_consolemain() does not return so that finished the entire NSH initialization sequence.
nsh_initialize()
The NSH initialization function, nsh_initialize(), be found in apps/nshlib/nsh_init.c.
It does only three things:
nsh_romfsetc():
If so configured, it executes an NSH start-up script that can be found at /etc/init.d/rcS in the target file system.
The nsh_romfsetc() function can be found in apps/nshlib/nsh_romfsetc.c.
This function will (1) register a ROMFS file system, then (2) mount the ROMFS file system.
/etc is the default location where a read-only, ROMFS file system is mounted by nsh_romfsetc().
The ROMFS image is, itself, just built into the firmware.
By default, this rcS start-up script contains the following logic:
# Create a RAMDISK and mount it at XXXRDMOUNTPOUNTXXX mkrd -m XXXMKRDMINORXXX -s XXMKRDSECTORSIZEXXX XXMKRDBLOCKSXXX mkfatfs /dev/ramXXXMKRDMINORXXX mount -t vfat /dev/ramXXXMKRDMINORXXX XXXRDMOUNTPOUNTXXX
Where the XXXX*XXXX strings get replaced in the template when the ROMFS image is created:
XXXMKRDMINORXXX will become the RAM device minor number.
Default: 0
XXMKRDSECTORSIZEXXX will become the RAM device sector size
XXMKRDBLOCKSXXX will become the number of sectors in the device.
XXXRDMOUNTPOUNTXXX will become the configured mount point.
Default: /etc
By default, the substituted values would yield an rcS file like:
# Create a RAMDISK and mount it at /tmp mkrd -m 1 -s 512 1024 mkfatfs /dev/ram1 mount -t vfat /dev/ram1 /tmp
This script will, then:
Create a RAMDISK of size 512*1024 bytes at /dev/ram1,
Format a FAT file system on the RAM disk at /dev/ram1, and then
Mount the FAT filesystem at a configured mountpoint, /tmp.
This rcS template file can be found at apps/nshlib/rcS.template.
The resulting ROMFS file system can be found in apps/nshlib/nsh_romfsimg.h.
nsh_archinitialize():
Next any architecture-specific NSH initialization will be performed (if any).
For the STM3240G-EVAL, this architecture specific initialization can be found at configs/stm3240g-eval/src/up_nsh.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.
4.2 NSH Commands |
Overview. NSH supports a variety of commands as part of the NSH program. All of the NSH commands are listed in the NSH documentation above. Not all of these commands may be available at any time, however. Many commands depend upon certain NuttX configuration options. You can enter the help command at the NSH prompt to see the commands actual available:
nsh> help
For example, if network support is disabled, then all network-related commands will be missing from the list of commands presented by 'nsh> help'.
You can see the specific command dependencies in the table above.
New commands can be added to the NSH very easily. You simply need to add two things:
The implementation of your command, and
A new entry in the NSH command table
Implementation of Your Command.
For example, if you want to add a new a new command called mycmd to NSH, you would first implement the mycmd code in a function with this prototype:
The argc and argv are used to pass command line arguments to the NSH command.
Command line parameters are passed in a very standard way: argv[0] will be the name of the command, and argv[1] through argv[argc-1] are the additional arguments provided on the NSH command line.
The first parameter, vtbl, is special.
This is a pointer to session-specific state information.
You don't need to know the contents of the state information, but you do need to pass this vtbl argument when you interact with the NSH logic.
The only use you will need to make of the vtbl argument will be for outputting data to the console.
You don't use printf() within NSH commands.
Instead you would use:
void nsh_output(FAR struct nsh_vtbl_s *vtbl, const char *fmt, …);
So if you only wanted to output "Hello, World!" on the console, then your whole command implementation might be:
int cmd_mycmd(FAR struct nsh_vtbl_s *vtbl, int argc, char **argv)
{
nsh_output(vtbl, "e;Hello, World!"e;);
return 0;
}
The prototype for the new command should be placed in apps/examples/nshlib/nsh.h>.
Adding You Command to the NSH Command Table. All of the commands support by NSH appear in a single table called:
const struct cmdmap_s g_cmdmap[]
That table can be found in the file apps/examples/nshlib/nsh_parse.c.
The structure cmdmap_s is also defined in apps/nshlib/nsh_parse.c:
struct cmdmap_s
{
const char *cmd; /* Name of the command */
cmd_t handler; /* Function that handles the command */
uint8_t minargs; /* Minimum number of arguments (including command) */
uint8_t maxargs; /* Maximum number of arguments (including command) */
const char *usage; /* Usage instructions for 'help' command */
};
This structure provides everything that you need to describe your command:
Its name (cmd), the function that handles the command (cmd_mycmd()), the minimum and maximum number of arguments needed by the command,
and a string describing the command line arguments.
That last string is what is printed when enter "nsh> help".
So, for you sample commnd, you would add the following the to the g_cmdmap[] table:
{ "mycmd", cmd_mycmd, 1, 1, NULL },
This entry is particularly simply because mycmd is so simple.
Look at the other commands in g_cmdmap[] for more complex examples.
4.3 NSH "Built-In" Applications |
Overview. In addition to these commands that are a part of NSH, external programs can also be executed as NSH commands. These external programs are called "Built-In" Applications for historic reasons. That terminology is somewhat confusing because the actual NSH commands as described above are truly "built-into" NSH whereas these applications are really external to NuttX.
These applications are built-into NSH in the sense that they can be executed by simply typing the name of the application at the NSH prompt.
Built-in application support is enabled with the configuration option CONFIG_NSH_BUILTIN_APPS.
When this configuration option is set, you will also be able to see the built-in applications if you enter "nsh> help".
They will appear at the bottom of the list of NSH commands under:
Builtin Apps:
Note that no detailed help information beyond the name of the built-in application is provided.
Overview.
The underlying logic that supports the NSH built-in applications is called "Named Applications".
The named application logic can be found at apps/namedapp.
This logic simply does the following:
It supports registration mechanism so that named applications can dynamically register themselves at build time, and
Utility functions to look up, list, and execute the named applications.
Named Application Utility Functions.
The utility functions exported by the named application logic are prototyped in apps/include/apps.h.
These utility functions include:
int namedapp_isavail(FAR const char *appname);
Checks for availability of application registered as appname during build time.
const char *namedapp_getname(int index);
Returns a pointer to a name of built-in application pointed by the index.
This is the utility function that is used by NSH in order to list the available built-in applications when "nsh> help" is entered.
int exec_namedapp(FAR const char *appname, FAR const char **argv);
Executes built-in named application registered during compile time.
This is the utility function used by NSH to execute the built-in application.
Autogenerated Header Files. Application entry points with their requirements are gathered together in two files when NuttX is first built:
apps/namedapp/namedapp_proto.h:
Prototypes of application task entry points.
apps/namedapp/namedapp_list.h:
Application specific information and start-up requirements
Registration of Named Applications.
The NuttX build occurs in several phases as different build targets are executed:
(1) context when the configuration is established,
(2) depend when target dependencies are generated, and
(3) default (all) when the normal compilation and link operations are performed.
Named application information is collected during the make context build phase.
An example application that can be "built-in" is be found in the apps/examples/hello directory.
Let's walk through this specific cause to illustrate the general way that built-in applications are created and how they register themselves so that they can be used from NSH.
apps/examples/hello.
The main routine for apps/examples/hello can be found in apps/examples/hello/main.c.
The main routine is:
int hello_main(int argc, char *argv[])
{
printf("Hello, World!!\n");
return 0;
}
This is the built in function that will be registered during the context build phase of the NuttX build.
That registration is performed by logic in apps/examples/hello/Makefile.
But the build system gets to that logic through a rather tortuous path:
The top-level context make target is in nuttx/Makefile.
All build targets depend upon the context build target.
For the apps/ directory, this build target will execute the context target in the apps/Makefile.
The apps/Makefile will, in turn, execute the context targets in all of the configured sub-directories.
In our case will include the Makefile in apps/examples.
And finally, the apps/examples/Makefilewill execute the context target in all configured examplesub-directores, getting us finally to apps/examples/Makefile (which is covered below).
At the conclusion of the context phase, the apps/Makefile will touch a file called .context in the apps/ directory, preventing any further configurations during any subsequent context phase build attempts.
NOTE: Since this context build phase can only be executed one time, any subsequent configuration changes that you make will, then, not be reflected in the build sequence. That is a common area of confusion. Before you can instantiate the new configuration, you have to first get rid of the old configuration. The most drastic way to this is:
make distclean
But then you will have to re-configuration NuttX from scratch.
But if you only want to re-build the configuration in the apps/ sub-directory, then there is a less labor-intensive way to do that.
The following NuttX make command will remove the configuration only from the apps/ directory and will let you continue without re-configuring everything:
make apps_distclean
Logic for the context target in apps/examples/hello/Makefile registers the hello_main() application in the namedapp's namedapp_proto.hand namedapp_list.h files.
That logic that does that in apps/examples/hello/Makefile is abstracted below:
First, the Makefile includes apps/Make.defs:
include $(APPDIR)/Make.defs
This defines a macro called REGISTER that adds data to the namedapp header files:
define REGISTER
@echo "Register: $1"
@echo "{ \"$1\", $2, $3, $4 }," >> "$(APPDIR)/namedapp/namedapp_list.h"
@echo "EXTERN int $4(int argc, char *argv[]);" >> "$(APPDIR)/namedapp/namedapp_proto.h"
endef
When this macro runs, you will see the output in the build "Register: hello", that is a sure sign that the registration was successful.
The make file then defines the application name (hello), the task priority (default), and the stack size that will be allocated in the task runs (2K).
APPNAME = hello PRIORITY = SCHED_PRIORITY_DEFAULT STACKSIZE = 2048
And finally, the Makefile invokes the REGISTER macro to added the hello_main() named application.
Then, when the system build completes, the hello command can be executed from the NSH command line.
When the hello command is executed, it will start the task with entry point hello_main() with the default priority and with a stack size of 2K.
.context: $(call REGISTER,$(APPNAME),$(PRIORITY),$(STACKSIZE),$(APPNAME)_main) @touch $@
Other Uses of Named Application. The primary purpose of named applications is to support command line execution of applications from NSH. However, there are two other uses of named applications that should be mentioned.
Named Application Start-Up main() function.
A named application can even be used as the main, start-up entry point into your embedded software.
When the user defines this option in the NuttX configuration file:
CONFIG_BUILTIN_APP_START=<application name>
that application will be invoked immediately after system starts instead of the default CONFIG_USER_ENTRYPOINT() entry point.
Note that <application name> must be provided just as it would have been on the NSH command line.
For example, hello would result in hello_main() being started at power-up.
This option might be useful in some develop environments where you use NSH only during the debug phase, but want to eliminate NSH in the final product.
Setting CONFIG_BUILTIN_APP_START in this way will bypass NSH and execute your application just as if it were entered from the NSH command line.
binfs.
binfs is a tiny file system located at apps/namedapp/binfs.c.
This provides an alternative what of visualizing installed named applications.
Without binfs, you can see the installed named applications using the NSH help command.
binfs will create a tiny pseudo-file system mounted at /bin.
Using binfs, you can see the available named applications by listing the contents of /bin directory.
This gives some superficial Unix compatibility, but does not really add any new functionality.
By default, built-in commands started from the NSH command line will run asynchronously with NSH. If you want to force NSH to execute commands then wait for the command to execute, you can enable that feature by adding the following to the NuttX configuration file:
CONFIG_SCHED_WAITPID=y
This configuration option enables support for the standard waitpid() RTOS interface.
When that interface is enabled, NSH will use it to wait, sleeping until the built-in application executes to completion.
Of course, even with CONFIG_SCHED_WAITPID=y defined, specific applications can still be forced to run asynchronously by adding the ampersand (&) after the NSH command.
The appconfig File.
A special configuration file is used to configure which applications are to be included in the build.
The source for this file is saved at configs/<board>/<configuration>/appconfig.
The existence of the appconfig file in the board configuration directory is sufficient to enable building of applications.
The appconfig file is copied into the apps/ directory as .config when NuttX is configured.
.config is included by the top-level apps/Makefile.
As a minimum, this configuration file must define files to add to the CONFIGURED_APPS list like:
CONFIGURED_APPS += examples/hello
Changes in the Works.
There are changes in the works that will obsolete the appconfig file.
These changes will implement an automated configuration system for NuttX.
One consequence of this new configuration system is that the appconfig file will become obsolete and will be replaced by a new mechanism for selecting applications.
This new mechanism is not yet available, but is dicussed here: http://tech.groups.yahoo.com/group/nuttx/message/1604.
4.4 Customizing NSH Initialization |
Ways to Customize NSH Initialization. There are three ways to customize the NSH start-up behavior. Here they are presented in order of increasing difficulty:
You can extend the initialization logic in configs/stm3240g-eval/src/up_nsh.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.examplex/nsh is just a tiny, example start-up function (CONFIG_USER_ENTRYPOINT()) that that runs immediately and illustrates how to start NSH
If you want something else to run immediately then you can write your write your own custom CONFIG_USER_ENTRYPOINT() function and then start other tasks from your custom CONFIG_USER_ENTRYPOINT().
NSH also supports a start-up script that executed when NSH first runs. This mechanism has the advantage that the start-up script can contain any NSH commands and so can do a lot of work with very little coding. The disadvantage is that is is considerably more complex to create the start-up script. It is sufficiently complex that is deserves its own paragraph
First of all you should look at NSH Start-Up Script paragraph. Most everything you need to know can be found there. That information will be repeated and extended here for completeness.
NSH Start-Up Script.
NSH supports options to provide a start up script for NSH.
The start-up script contains any command support by NSH (i.e., that you see when you enter 'nsh> help').
In general this capability is enabled with CONFIG_NSH_ROMFSETC=y, but has several other related configuration options as described with the NSH-specific configuration settings paragraph.
This capability also depends on:
CONFIG_DISABLE_MOUNTPOINT=n.
If mount point support is disabled, then you cannot mount any file systems.
CONFIG_NFILE_DESCRIPTORS > 4.
Of course you have to have file descriptions to use any thing in the file system.
CONFIG_FS_ROMFS enabled.
This option enables ROMFS file system support.
Default Start-Up Behavior. The implementation that is provided is intended to provide great flexibility for the use of Start-Up files. This paragraph will discuss the general behavior when all of the configuration options are set to the default values.
In this default case, enabling CONFIG_NSH_ROMFSETC will cause NSH to behave as follows at NSH start-up time:
NSH will create a read-only RAM disk (a ROM disk), containing a tiny ROMFS filesystem containing the following:
`--init.d/
`-- rcS
Where rcS is the NSH start-up script.
NSH will then mount the ROMFS filesystem at /etc, resulting in:
|--dev/
| `-- ram0
`--etc/
`--init.d/
`-- rcS
By default, the contents of rcS script are:
# Create a RAMDISK and mount it at /tmp mkrd -m 1 -s 512 1024 mkfatfs /dev/ram1 mount -t vfat /dev/ram1 /tmp
NSH will execute the script at /etc/init.d/rcS at start-up (before the first NSH prompt).
After execution of the script, the root FS will look like:
|--dev/ | |-- ram0 | `-- ram1 |--etc/ | `--init.d/ | `-- rcS `--tmp/
Example Configurations.
Here are some configurations that have CONFIG_NSH_ROMFSETC=y in the NuttX configuration file.
They might provide useful examples:
configs/hymini-stm32v/nsh2
configs/ntosd-dm320/nsh
configs/sim/nsh
configs/sim/nsh2
configs/sim/nx
configs/sim/nx11
configs/sim/touchscreen
configs/vsn/nsh
In most of these cases, the configuration sets up the default /etc/init.d/rcS script.
The default script is here: apps/nshlib/rcS.template.
(The funny values in the template like XXXMKRDMINORXXX get replaced via sed at build time).
This default configuration creates a ramdisk and mounts it at /tmp as discussed above.
If that default behavior is not what you want, then you can provide your own custom rcS script by defining CONFIG_NSH_ARCHROMFS=y in the configuration file.
The only example that uses a custom /etc/init.d/rcS file in the NuttX source tree is this one: configs/vsn/nsh.
The configs/vsn/nsh/defconfig file also has this definition:
CONFIG_NSH_ARCHROMFS=y -- Support an architecture specific ROMFS file.
Modifying the ROMFS Image.
The contents of the /etc directory are retained in the file apps/nshlib/nsh_romfsimg.h OR, if CONFIG_NSH_ARCHROMFS is defined, include/arch/board/rcs.template.
In order to modify the start-up behavior, there are three things to study:
Configuration Options.
The additional CONFIG_NSH_ROMFSETC configuration options discussed with the other NSH-specific configuration settings.
tools/mkromfsimg.sh Script.
The script tools/mkromfsimg.sh creates nsh_romfsimg.h.
It is not automatically executed.
If you want to change the configuration settings associated with creating and mounting the /tmp directory, then it will be necessary to re-generate this header file using the tools/mkromfsimg.sh script.
The behavior of this script depends upon several things:
The configuration settings then installed configuration.
The genromfs tool(available from http://romfs.sourceforge.net) or included within the NuttX buildroot toolchain.
There is a snapshot here: misc/tools/genromfs-0.5.2.tar.gz.
The xxd tool that is used to generate the C header files (xxd is a normal part of a complete Linux or Cygwin installation, usually as part of the vi package).
The file apps/nshlib/rcS.template (OR, if CONFIG_NSH_ARCHROMFS is defined include/arch/board/rcs.template.
rcS.template.
The file apps/nshlib/rcS.template contains the general form of the rcS file; configured values are plugged into this template file to produce the final rcS file.
rcS.template.
The default rcS.template, apps/nshlib/rcS.template, generates the standard, default apps/nshlib/nsh_romfsimg.h file.
If CONFIG_NSH_ARCHROMFS is defined in the NuttX configuration file, then a custom, board-specific nsh_romfsimg.h file residing in configs/<board>/includewill be used.
NOTE when the OS is configured, include/arch/board will be linked to configs/<board>/include.
As mention above, the only example that uses a custom /etc/init.d/rcS file in the NuttX source tree is this one: configs/vsn/nsh.
The custom script for the configs/vsn case is located at configs/vsn/include/rcS.template.
All of the startup-behavior is contained in rcS.template.
The role of mkromfsimg.sh script is to (1) apply the specific configuration settings to rcS.template to create the final rcS, and (2) to generate the header file nsh_romfsimg.h containg the ROMFS file system image.
To do this, mkromfsimg.sh uses two tools that must be installed in your system:
The genromfs tool that is used to generate the ROMFS file system image.
The xxd tool that is used to create the C header file.
You can find the generated ROMFS file system for the configs/vsn case here: configs/vsn/include/rcS.template
Index |
|
exitfreeg_cmdmapgenromfsgethelpif-then[-else]-fiifconfigkilllosetupmbmhmwmkdirmkfatfsmkfifomkrdmkromfsimg.shmountmvmain()namedapp_getname()namedapp_isavail()namedapp_list.hnamedapp_proto.hnfsmountnicenshlib)nsh_archinitialize()nsh_consolemain()nsh_initialize()nsh_main()nsh_main.cnsh_netinit()nsh_output()nsh_romfsetc()nsh_telnetstart()nshlibOLDPWDpingpsputpwdPWDrcS.templatermrmdirsetshsleeptestumountunsetup_cxxinitialize()up_nsh.cusleepwaitpid()wgetxdxxd |