sergiotarxz/nuttx
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Update README files

Browse Source
This commit is contained in:
Gregory Nutt 2016-06-07 11:28:46 -06:00
parent db470d8ffd
commit d4c101d2cf
4 changed files with 261 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

80
configs/freedom-kl25z/README.txt
View File

@ -301,6 +301,86 @@ Where <subdir> is one of the following:
configuration. This configuration has far fewer features than the nsh configuration. This configuration has far fewer features than the nsh
configuration but is also a fraction of the size. 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: nsh:
--- ---
Configures the NuttShell (nsh) located at apps/examples/nsh. The Configures the NuttShell (nsh) located at apps/examples/nsh. The

80
configs/freedom-kl26z/README.txt
View File

@ -279,6 +279,86 @@ Where <subdir> is one of the following:
configuration. This configuration has far fewer features than the nsh configuration. This configuration has far fewer features than the nsh
configuration but is also a fraction of the size. 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: nsh:
--- ---
Configures the NuttShell (nsh) located at apps/examples/nsh. The Configures the NuttShell (nsh) located at apps/examples/nsh. The

80
configs/lpcxpresso-lpc1115/README.txt
View File

@ -687,6 +687,86 @@ Where <subdir> is one of the following:
configuration. This configuration has far fewer features than the nsh configuration. This configuration has far fewer features than the nsh
configuration but is also a fraction of the size. 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: STATUS:
2015-6-10 2015-6-10
The nuttx.bin minnsh firmware file size: The nuttx.bin minnsh firmware file size:

27
configs/stm32f103-minimum/README.txt
View File

@ -492,7 +492,7 @@ Where <subdir> is one of the following:
2016-06-07: As another experiment, I tried enabling just (1) the file 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 system, (2) the console device, and (3) the upper half serial driver in
the minnsh configuration. With these changes, NSH should behave better 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: configuration changes:
Enable the file system: Enable the file system:
@ -525,13 +525,28 @@ Where <subdir> is one of the following:
The resulting code was bigger as expected: The resulting code was bigger as expected:
$ arm-none-eabi-size nuttx $ arm-none-eabi-size nuttx
text data bss dec hex filename text data bss dec hex filename
20093 88 876 21057 5241 nuttx 19853 88 876 20817 5151 nuttx
I am sure that other things that could be disabled were also drawn into 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 the build, so perhaps this could be reduced. This amounts to a size
estimate, it looks like the cost of basic file system and serial console increase of around 7KB.
driver support is around 7+KB.
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: nsh:
--- ---