Update README

This commit is contained in:
Gregory Nutt 2016-06-07 08:42:42 -06:00
parent c939bbe47a
commit db470d8ffd

View File

@ -428,6 +428,49 @@ Where <subdir> is one of the following:
configuration. This configuration has far fewer features than the nsh
configuration but is also a fraction of the size.
This minnsh configuration is a "proof-of-concept" and not very usable in
its current state. This configuration was created by disabling
everything possible INCLUDING file system support. Without file system
support, NuttX is pretty much crippled. Here are some of the
consequences of disabling the file system:
- All features that depend on the file system are lost: device drivers,
mountpoints, message queues, named semaphores.
- Without device drivers, you cannot interact with the RTOS using POSIX
interfaces. You would have to work with NuttX as with those other
tiny RTOSs: As a scheduler and a callable hardare abstraction layer
(HAL).
- You cannot use any of the NuttX upper half device drivers since they
depend on the pseudo-file system and device nodes. You can, of
course, continue to use the lower half drivers either directly. Or,
perhaps, you could write some custom minnsh upper half drivers that
do not depend on a file system and expose a HAL interface.
There is a special version of readline() the NSH uses when there is no
file system. It uses a special up_putc() to write data to the console
and a special function up_getc() to read data from the console.
- The current up_getc() implementationsa are a kludge. They are
analogous to the up_putc() implementations: They directly poll the
hardware for serial availability, locking up all lower priority tasks
in the entire system while they poll. So a version of NSH that uses
up_getc() essentially blocks the system until a character is received.
This, of course, could be fixed by creating a special, upper half
implementation of the interrupt-driven serial lower half (like
stm32_serial) that just supports single character console I/O
(perhaps called up_putc and up_getc?). The NSH could wait for serial
input without blocking the system. But then that would increase the
footprint too.
So although the minnsh configurations are a good starting point for
making things small, they not are really very practical. Why might
you want a NuttX minnsh solution? Perhaps you have software that runs
on a family of chips including some very tiny MCUs. Then perhaps having
the RTOS compatibility would justify the loss of functionality?
STATUS:
2016-06-03: Using that config I got this:
@ -446,6 +489,50 @@ Where <subdir> is one of the following:
Mem: 18624 2328 16296 16296
nsh>
2016-06-07: As another experiment, I tried enabling just (1) the file
system, (2) the console device, and (3) the upper half serial driver in
the minnsh configuration. With these changes, NSH should behave better
nd we preserve the device driver interface. I made the following
configuration changes:
Enable the file system:
CONFIG_NFILE_DESCRIPTORS=5
CONFIG_NFILE_STREAMS=5
Enable the console device:
CONFIG_DEV_CONSOLE=y
Disable most new NSH commands. Some like 'ls' are really mandatory
with a file system:
CONFIG_NSH_DISABLE_xxx=y
Enable the upper half serial driver:
CONFIG_SERIAL=y
CONFIG_STANDARD_SERIAL=y
Enable the USART1 serial driver:
CONFIG_STM32_USART1=y
CONFIG_STM32_USART1_SERIALDRIVER=y
CONFIG_USART1_SERIAL_CONSOLE=y
CONFIG_USART1_2STOP=0
CONFIG_USART1_BAUD=115200
CONFIG_USART1_BITS=8
CONFIG_USART1_PARITY=0
CONFIG_USART1_RXBUFSIZE=16
CONFIG_USART1_TXBUFSIZE=16
The resulting code was bigger as expected:
$ arm-none-eabi-size nuttx
text data bss dec hex filename
20093 88 876 21057 5241 nuttx
I am sure that other things that could be disabled were also drawn into
the build, so perhaps this could be reduced. But as a ballpark
estimate, it looks like the cost of basic file system and serial console
driver support is around 7+KB.
nsh:
---
Configures the NuttShell (nsh) located at apps/examples/nsh. This