Update README files
This commit is contained in:
parent
db470d8ffd
commit
d4c101d2cf
|
@ -301,6 +301,86 @@ 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?
|
||||
|
||||
You can re-enable the file system and (true) serial console with
|
||||
these settings:
|
||||
|
||||
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
|
||||
|
||||
With these changes, NSH should behave better and we preserve the device
|
||||
driver interface. But this result in a total size increase of about
|
||||
7KB: That is about 5KB of additional OS support for the file system and
|
||||
serial console PLUS about 2KB for the 'ls' command logic (including OS
|
||||
support for opendir(), readdir(), closedir(), stat(), and probably other
|
||||
things).
|
||||
|
||||
nsh:
|
||||
---
|
||||
Configures the NuttShell (nsh) located at apps/examples/nsh. The
|
||||
|
|
|
@ -279,6 +279,86 @@ 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?
|
||||
|
||||
You can re-enable the file system and (true) serial console with
|
||||
these settings:
|
||||
|
||||
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
|
||||
|
||||
With these changes, NSH should behave better and we preserve the device
|
||||
driver interface. But this result in a total size increase of about
|
||||
7KB: That is about 5KB of additional OS support for the file system and
|
||||
serial console PLUS about 2KB for the 'ls' command logic (including OS
|
||||
support for opendir(), readdir(), closedir(), stat(), and probably other
|
||||
things).
|
||||
|
||||
nsh:
|
||||
---
|
||||
Configures the NuttShell (nsh) located at apps/examples/nsh. The
|
||||
|
|
|
@ -687,6 +687,86 @@ 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?
|
||||
|
||||
You can re-enable the file system and (true) serial console with
|
||||
these settings:
|
||||
|
||||
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
|
||||
|
||||
With these changes, NSH should behave better and we preserve the device
|
||||
driver interface. But this result in a total size increase of about
|
||||
7KB: That is about 5KB of additional OS support for the file system and
|
||||
serial console PLUS about 2KB for the 'ls' command logic (including OS
|
||||
support for opendir(), readdir(), closedir(), stat(), and probably other
|
||||
things).
|
||||
|
||||
STATUS:
|
||||
2015-6-10
|
||||
The nuttx.bin minnsh firmware file size:
|
||||
|
|
|
@ -492,7 +492,7 @@ Where <subdir> is one of the following:
|
|||
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
|
||||
and we preserve the device driver interface. I made the following
|
||||
configuration changes:
|
||||
|
||||
Enable the file system:
|
||||
|
@ -525,13 +525,28 @@ Where <subdir> is one of the following:
|
|||
The resulting code was bigger as expected:
|
||||
|
||||
$ arm-none-eabi-size nuttx
|
||||
text data bss dec hex filename
|
||||
20093 88 876 21057 5241 nuttx
|
||||
text data bss dec hex filename
|
||||
19853 88 876 20817 5151 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.
|
||||
the build, so perhaps this could be reduced. This amounts to a size
|
||||
increase of around 7KB.
|
||||
|
||||
One major part of this size increase is due to the addition of the NSH
|
||||
'ls' command. Now, if I disable the 'ls' command, I get:
|
||||
|
||||
$ arm-none-eabi-size nuttx
|
||||
text data bss dec hex filename
|
||||
17804 80 864 18748 493c nuttx
|
||||
|
||||
Or an increase of only 5.1 KB. This, of course, not only excludes the
|
||||
'ls' command logic, but also the things that were drawn into the link
|
||||
when 'ls' was enabled: opendir(), readdir(), closedir(), stat(), and
|
||||
probably other things.
|
||||
|
||||
So I think we can say that the cost of the file system and true serial
|
||||
console device was about 5 KB (primarily OS support) and the cost of
|
||||
the NSH 'ls' command (including OS support) is about 2KB.
|
||||
|
||||
nsh:
|
||||
---
|
||||
|
|
Loading…
Reference in New Issue